Is there a reason one would want to use calc() over the transform property when placing an element, or vise versa, when the size of the element is known?
For example...
.element {
bottom: 100%;
transform: translateY(-9px);
}
Produces the same results as:
.element {
bottom: calc(100% + 9px);
}
If the size of the element is not known, I see the advantage of using transform. However, if the size is known (as above) I can just as easily use calc() to adjust.
"calc() uses just one line, while transform requires two lines"
Fair enough. But (in my case) I'm already using transform to adjust along the other axis (because I don't know the initial size), so I could easily combine the translateY() and translateX() to actually reduce the number of lines.
"Because browser support"
Assume we have full browser support across both solutions.
Is there a standard, or performance situation, that would suggest one solution is better than the other?
transform is a monster capable of doing much more powerful things than simple translations.
Therefore, it has some collateral effects like establishing a containing block for its descendants, even if they are in a fixed position!
Therefore, as a rule of thumb, when you only want simple translations, I would recommend to avoid transform. I prefer calc(), margins, etc.
Transforms can be affected by other transforms, which may cause a difference in rendering. For example, if you were using the perspective transform, translateY() would take place inside that perspective. So, the perspective would be applied, and then the element would be transformed according to the vanishing point you set.
If you were using calc(), instead, the element would be positioned on the page irrespective of the set perspective. It’s probably a subtle difference, but it’s there.
If you’re not using a 3D transform like perspective, however, or if translate() is the only transform you’re using, I don’t think there’s a difference.
Related
As the title says, what are the differences between transform: translate(x, y) and position: relative.
Since they both accomplish the same thing (position elements) anyway, then how do they differ in purpose and application?
I read an article about centering elements using "transform: translate;" that said it is better to use "transform" due to GPU and optimization reason, but I don't really see the problem since it's not a big deal anyway if you're just re-positioning an element and not animating it.
So in the end, how are they both different and in what ways?
Basically translate relies on CSS3 2D Transforms while the position property is a CSS2 level.
In browser that support it has been said that using translate will boost the entire graphical peformance of the browser,
but not all browser do support it,
so if you care to give widespread browser support CSS2 position is surely better,
while transform:translate() is the future.
I want to compose two separate CSS keyframe animations to make an image vibrate and rotate (see http://jsfiddle.net/3zAeZ/). The problem I believe I'm running into is: I'm setting the transform attribute in both keyframe rules, therefore one rule is clobbering the other.
I know this works using top & left instead of translate, but the keyframes rule will be much easier to reuse in the future if I do a transform (for example, in case I ever need to position the image differently).
I'm stumped. Can I do this? Is there a better way I should be doing it?
You can use multiple transforms like
transform: rotate(1337deg) scale(1.5) translate(6em, 300px);
Now I realize that you need two different animation durations as well.
So the best I can come up with is using two elements http://jsfiddle.net/3zAeZ/1/
I created a mockup to demonstrate my problem. I fear the solution falls in what I did with the first example (box1).
Just not sure why I can't apply a css transform to a parent element and avoid applying it to the child element or at least override it.
Let me know if there is a way to get the effect of the first example using the transform property. I don't want the second image to be scaled as well. Just the parent div.
Note
I'm trying to use this property to enable GPU acceleration.
Have not played with this in any other browser but the chrome.
But it looks like overflow hidden set on parent element implies resizing inheritance on image.
So if you set overflow auto on the boxes to which animation is applied, it should fix the resizing inheritance.
http://jsfiddle.net/gnrlbzik/5Q8EC/ tests the overflow set to auto, that keeps image dimensions in tact.
To be semantic I don't think you should be able to stop it from transforming a child element being you are transforming/scaling it's container, not resizing it. A transform is not just animating the width like the example on box 1, it scales the x.
I believe this question is about trying to gain some performance boost by using features that use the GPU to process animations. This is possible, I believe, by effectively treating the elements as an image that the GPU then animates. Thus you are not able to have an element inside that dynamically keeps its size/shape during an animation. Maybe there is a way to counter the animation by transforming the element within that you would like to keep static, but this will probably not be efficient nor effective.
Note: I am not well versed in the actual technology webkit uses to render these transformations. So sorry if the finer details of the rendering are not quite accurate. I will update this if anyone comments with a better description of how transform works.
I wanted to use -transform to get the GPU performance perk. I guess I'll continue to use the width animation: http://jsfiddle.net/Vyaf3/22/ but with applying a css3 property that would enable the GPU acceleration.
fellow earthians.
I, relatively sane of body and mind, hereby give up understanding CSS positioning by myself.
The online resources about CSS go to great length to explain that the "color" attribute lets you set the "color" of stuff. Unmöglish.
Then, that if you want to put something to the left of something else (crazy idea, right?), all you have to do is to set it to float to the left provided you set the "relative" flag on its parent block which has to have a grand-father node with the "absolute" flag set to true so that it's positionned relatively to an other container that may-or-not contain anything, have a position, a size, or not, depending on the browser, the size of other stuff, and possibly the phases of the moon. (CSS experts are advised not to take the previous paragraph seriously. I'm pretty sure someone will point out that my rant is not valid, or w3c-compliant - and that it only applies to the swedish beta version of IE6)
Joking apart, I'm looking for any resource that explains the root causes of all the crazyness behind layout in CSS. In essence, something that would be to CSS what Crockford's articles are to Javascript.
In this spirit, let me point out that I'm not looking for css libraries or grid frameworks like blueprint, or for CSS extension languages like lesscss. I've been using those to ease my sufferings, but I'm afraid it would be like telling someone to "just use jQuery" when they say they can't wrap their mind around prototype inheritence in JS.
If all you can point me to is http://shop.oreilly.com/product/9781565926226.do , I guess I'll consider myself doomed.
Thanks in advance.
EDIT : I probably should not have talked about "positioning" (thanks to all who've explained again that 'position:relative' does not mean 'relative to your container' and that 'position:absolute' means relative to something. I've never been so close to making a monty python script out of a SO questions). I think I meant layout in general (positioning + floats + baselines + all the nonsense required to put stuff on a straight line).
Also please excuse the ranting tone, I'm trying to pour some humour into frustration. I would use zen techniques to calm down if I could, but this only reminds me of
this.
It seems most others have not quite understood the gist of your post. I'll break it down for you:
CSS positiong is complex because it was designed by many different groups of people over a long period of time, with various versions, and legacy compatibility issues.
The first attempts were to keep things simple. Just provide basic styling. Colors, fonts, sizes, magins, etc.. They added floats to provide the basic "cutout" functionality where text wraps around an image. Float was not intended to be used as a major layout feature as it currently is used.
But people were not happy with that. They wanted columns, and grids, boxes, and shadows, and rounded corners, and all kinds of other stuff, which was added in various stages. All while trying to maintain compatibility with previous bad implementations.
HTML has suffered from two opposing factions warring it out. One side wanted simple (compared to existing SGML anyways) solutions, another side wanted rich applications. So CSS has this sort of schitzophrenic nature to it sometimes.
What's more, features were extended to do things they weren't initially intended to do. This made the existing implementations all very buggy.
So what does that mean for you, a mere human? It means you are stuck dealing with everyone elses dirty laundry. It means you have to deal with decade old implementation bugs. It means you either have to write different CSS for different browsers, or you have to limit yourself to a common "well supported" featureset, which means you can't take full advantage of what the latest CSS can do (nor can you use the features there were designed to add some sanity to the standard).
In my opinion, there is no better book for a "mere human" to undrstand CSS than this:
http://www.amazon.com/Eric-Meyer-CSS-Mastering-Language/dp/073571245X
It's simple, concise, and gives you real world examples in a glossy "easy on the eyes" format, and lacking most of the nasty technical jargon. It is 10 years old, and doesn't cover any of the new stuff, but it should allow you to "grok" the way things work.
Positioning is easy to understand:
relative positioning -- Render the page exactly as your normally would. Once done, anything with relative positioning gets moved, relative to where it initially was. Nothing else is affected.
absolute positioning -- Removes the item from the page flow. Other things render as if this weren't there, i.e. they fill in the space that this item took up. They are now positioned absolutely to the nearest element with position: relative OR position: absolute set. In many cases this means they are positioned absolute to the body tag.
You then position things with top, right, bottom and left in CSS.
If something has absolute positioning set:
positioned relative to the top left of the page when using top and left. Positioned relative to the bottom right of the page when using bottom and right.
its width/height can be controlled with a combination of top / bottom or left / right, e.g.: top: 100px; bottom: 100px will make an item that is 100% - 200px of its parent's height (unless you specify a height too in which case top and height are used and bottom is ignored).
There's more to the positioning that just the position property. You need to understand how floats work as well.
http://coding.smashingmagazine.com/2009/10/19/the-mystery-of-css-float-property/
http://coding.smashingmagazine.com/2007/05/01/css-float-theory-things-you-should-know/
These two articles should get you going.
Read a bit on display properties as well, since they're likely to be one of the problematic areas in any given html/css.
this link is mainly about z-index but IMO it does a pretty good job of explaining how things are positioned on a page
http://coding.smashingmagazine.com/2009/09/15/the-z-index-css-property-a-comprehensive-look/
This link is more focused on positioning but it is important to understand the z axis in order to understand the rest of the positioning puzzle
http://kilianvalkhof.com/2008/css-xhtml/understanding-css-positioning-part-1/
Have you checked out this great book? http://shop.oreilly.com/product/9781565926226.do
just kidding.
I don't think you need an entire resource devoted to this one question. It's rather simple once it clicks.
Think of CSS positioning as a way to position items either relatively to themsevels (wherever they fall on the page) or absolutely from on an X/Y coordinate.
You can position something relative and it will either move up or to the right with a positive number, or down and to the left with a negative number.
If you position an element absolutely it will remove itself from the layout altogether (the other elements will not recognize it as being on the screen) and then do one of two things. It will either:
1 - position itself from the top left of the page and either go up/down right/left as I mentioned before depending on whether the numbers are +/-.
2- if the PARENT element is either positioned absolute or relative it will position itself from the top left "corner" of the parent element, NOT the browser window.
Think of z-index as layers in photoshop. With 0 being the bottom (and newer browsers recognize negative z index for even more fun). and 100 as the top later (newer browsers recognize an infinite amount of numbers). The z-index only works with position: relative and absolute.
So if I position something absolute, and it happens to fall underneath another element, I can give it z-index: 100 and it will position itself on top. Keep in mind that the element itself is a rectangle, and the height/width of the element may inhibit you from clicking on the element beneath. You can't do angles,circles, etc. with pure CSS.
Does that help?
These two courses from code academy should explain CSS positioning well:
First, Second.
Can we make cross browser css layouts with CSS positioning, without using float? What are the bad and good points of usin css positioning over Float+margin+padding? I want to make layout compatible with all A-Grade Browser and with IE6 Also? IN dreamweaver we have a layer functionaliy to make css layout quickly but it's uses absolution position. is this technique bad?
If you don't care how it looks if the browser is larger or smaller than you designed for then absolute positioning it great. :)
But, in most cases, if you are designing for a browser that may be on a 17" - 30" monitors, so it may be fullscreen, then float is helpful.
Now, if you are changing the positions to scale to the size of the window dynamically, and can handle a resize, then absolute will work well.
I think absolute positioning would be more work than it is worth, if you want to get rid of float.
When I put together a page, I consider the elements I am putting together and the kind of physical structure they form. If elements are lined up together, like a row of books, I will use floats to "press" them up against one another. If I have more sparse elements, like post-it notes on a sheet of paper, I will use absolute positioning because the position of one element is not closely tied to the position of another.
I also look at what I know about the elements and what I don't. If I have things that change in size, like elements with varying amounts of content in them, I will use floats to position them. This way the elements still "stack" up together in some orderly fashion. Positioning an element of arbitrary size can be tricky, since you can end up exceeding a container's boundaries and breaking a layout or displaying/hiding some content in a place you don't want it.
Of course, you can combine the two techniques together, too - it's all about what you need to put together.
Can we make cross browser css layouts with CSS positioning, without using float?
Certainly, if you like. Floats and positioning are just two more CSS properties, they are not mutually exclusive. For complex layouts you may often be mixing both.
IN dreamweaver we have a layer functionaliy to make css layout quickly but it's uses absolution position. is this technique bad?
Yes. Except for things that are naturally fixed-size like images, using exact page-pixel absolute positioning is a bad move, one that automated tools tend to produce because it's easy to do with a WYSIWYG interface but one which degrades badly for text.