Really struggling with CSS Layout (not gsap specific)

[Grandpaw Broon]

Hi! 

 

I have used Greensock for many years in my Flash days, it is a standard library which all projects used in some way for some amazing reason.  But Flash Decline left me reeling for a couple of years.  I am back to the awesome of greensock! 
 

As a Flash Developer, I had a Stage. I had StageScaleMode.NO_SCALE applied always, and I had a scene graph.  When a resize of the Flash Player took place, it was my job to respond to the stage.stageWidth and stage.stageHeight in order to validate the layout. That is how I understand applications or games to be made.

 

As a JavaScript Developer, I have a HTMLCanvasElement.  I chose to use PIXI which is also a scene graph. When a resize of the canvas takes place, it is my job to respond to the width and height in order to validate the layout within that Scene Graph. This uses the same concepts as being a Flash Developer.

 

These 2 above things are identical in how you would program a "responsive layout". 

 

As an aspiring HTML Developer, I have a HTMLDocument and this also looks like a scene graph. I have read a book on the DOM and it just seems to be made up of nodes.  I get the properties of the box model, and I kind of get document flow. 

 

However, I keep fighting, on every single task with layout.  Literally every element I am writing takes me a weekend to figure out why it is appearing somewhere random on the screen! 

How do I get my "coordinate space" back?  If I add 100 trees to the document, I want to see 100 overlapping trees in the top left of my screen.  If each tree has 100 apples, those 100 apples were positioned relative to the Tree.  Each apple has 100 worms, and each worm is relative to the Apple...... 

 

How does one setup this style of development? It is like I want Absolute and Relative positioning, but there is some "Document Flow" thing going on which I am fighting against and changing the parent positions of things in an edit fest just spawns all kinds of new problems everywhere else. 

Thanks for reading, and if you feel this topic should not be here (as its not gsap specific) feel free to remove!

Thanks!

[GreenSock]

I feel your pain. A few years ago I was in the same spot, confounded by the lack of an absolute coordinate system for everything the way Flash delivered one. However, I'm confident you'll find your way after some growing pains Hang in there. 

 

You can technically set the css style "position:absolute" for everything and you'll get that same sort of behavior but I'd encourage you to embrace some of the "weirdness" of the DOM layout engine because it can be quite useful. But I think your question was focused on how to get absolute positioning and that's the answer - set position:absolute in CSS. 

 

Think of a <div> kinda like a MovieClip in Flash - you can nest stuff inside that and then when you move the <div>, everything inside of it moves too. Make sure you're using transforms as much as possible (which, in GSAP, simply means properties like x, y, scaleX, scaleY, rotation, etc.) instead of "top" and "left" because they perform much better and their context will behave more like what you're used to in Flash.

 

Happy tweening!

[OSUblake]

When I first started learning positioning, most of my problems revolved around not setting the position of the parent element to either relative or absolute. If you try to position an element relative to its parent and there is no position defined on it, its going to keep going up the document tree looking for a parent that has a position defined on it. If there are none, it's going to position it relative to the body.

 

Another problem I had was not setting the initial top/left CSS properties for an element that was positioned absolute. If you place an an element with position:absolute directly underneath an element with position:relative, it's not going to be in the top-left corner like where you might be expecting it to be. Setting the top and left to 0 will place back in the top-left corner.

[PointC]

Positioning in animation is always tricky, but trying to design a website/animation that looks perfect from a widescreen monitor down to a smartphone is downright maddening sometimes. 

 

Have you experimented with any SVG animation yet? 

 

We're switching nearly all of our animations to SVG . The beauty (beyond the obvious scaling of the vectors) is you can set up an entire 'stage' in Illustrator or any other vector based program with all your elements at their desired starting (or ending) position and animate them with GreenSock while having complete control over the CSS. Each element is sitting at it's own zero/zero coordinates so if you move one of the items to {x:400} it will move 400 units from it's current position. The really awesome part is that when the SVG scales down for smaller screens, that tween doesn't need to change - all the animations stay in proportion. Just start at the largest size you'll need and work from there.

 

Quite often, I'll start with a nice size document - say 1600px by 1000px and layout all my vectors on that stage to set the scene. I then bring that into my HTML via an inline SVG and set all my GreenSock tweens. Set your main SVG to 100% width and everything scales down beautifully. Another big plus to an SVG workflow is adding new elements after you've started your animation. Simply go back to your original vector illustration and add your new items anywhere on that stage you'd like them to start. After that, simply save a new SVG with only that element selected (and a background rectangle the same size as your stage), cut/paste the new SVG into your existing HTML and presto - its now part of the master SVG. 

 

To me, the whole process is a lot like making a Flash animation. You just have to wrap your head around the viewBox of the SVG. Once that makes sense, you load up your GreenSock, layout some SVGs, grab some snacks and create something awesome. Honestly, between GreenSock and SVGs, I'm like a kid in a toy store - the possibilities are endless. 

 

Best of luck to you.

[GreenSock]

Great points Blake and PointC. 

 

I'm curious, PointC, have you struggled at all with SVG performance? I love the scalability of SVG and the coordinate system like you described, but what I'm not thrilled with is the rendering performance (which is totally unrelated to GSAP). There is inherently more work for the browser to do when it's dealing with vectors and scalable artwork because it can't just proportionally scale all the pixels. In most projects, it's not a big deal, but if you're trying to do a ton of animation on many SVG elements at once (especially if they take up a large portion of the screen), it can be noticeable. 

[PointC]

Hey Jack,

 

I'm not seeing anything performance wise that I can't live with, but I'm also not animating/scaling hundreds of elements at the same time. Most of our work has maybe a dozen elements moving at once. You always have to think about the end user and browser performance so I try to keep my SVGs as clean and simple as possible while still getting the client's message delivered. Most of the scaling I was referring to was just the initial size of the users screen. I don't usually scale too many elements up to the full stage size, but even when we do, I think it looks pretty good in most browsers. Scaling everything to full screen at once can be a bit noticeable. That's why I was excited to see your viewBox animating addition in the new TweenMax. I don't know if there will be any performance/rendering difference between changing the viewBox vs scaling the entire SVG, but I'm excited to give it a whirl. 

 

BTW - Sara Soueidan just posted a new entry about the viewBox and it's power: http://sarasoueidan.com/blog/svg-art-direction-using-viewbox/

 

The bottom line for us is: SVG is the future so we're embracing it with open arms. Hopefully browsers will improve rendering performance with each new release. If we want to deliver a Flash-like experience with searchable text that is SEO friendly I'm not seeing another way right now so we're all in.

 

Of course, most of our web animation work wouldn't even be possible if not for GreenSock so thanks for an awesome product!

[GreenSock]

Glad to hear things are performing well for you. It sounds like you've done a lot of tire-kicking and SVG makes sense for your projects. Excellent. 

 

I share your sentiments about hoping browsers get better and better at SVG rendering performance but I'm pretty confident there is a ceiling beyond which it's simply impossible to get past because it's the nature of the beast. Imagine a 100x100 circle; for raster images, you can just shove those pixels to the GPU and then tell it to scale/stretch/move/rotate those very easily, and it's blazingly fast. Scale to 200x200 and the pixels get twice as big, but GPUs are optimized to eat that for breakfast, doing it thousands of times per second without breaking a sweat. However, with vector artwork you get beautiful scalability at the cost of performance because now the CPU has to fabricate NEW pixels when that circle gets scaled to 200x200, then ship those off to the GPU that does the rendering. It's inherently an exponentially more expensive operation. 

 

Flash had the same issue which is why they introduced the "cacheAsBitmap" feature which essentially said "okay, take this vector artwork and turn it into a raster image and even if it scales/rotates/whatever, just use those pixels instead of calculating new ones" which made things look all chunky when scaled up, but at least you got the improved speed. 

 

Anyway, all that's to say that I want SVG to succeed and I'm sure the browser vendors can improve performance from where we're at today, but I doubt they'll ever get close to the speed of raster images which is a bummer. There's so much to love about SVG.