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.
Related
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.
I have a very elaborate header that uses lettering.js to style each individual letter.
Changing the text size with media queries would force me to change other aspect such as top, and right (relative) position as well as rotation and other styles separately.
I've found in webkit transform: scale() works well and scales all aspects of the design, not just the font size.
Do other browsers have bugs that make this a bad solution? It seems to have reasonably good browser support, but I'm worried about bugs and pixelization on other browsers and rendering engines.
What are the (if any) drawbacks of using CSS3 transform: scale on text for responsive headers?
There are two issues that I can think of:
The element will still take up its original size in the document, so you may need to use negative margins to deal with that. Here's a demonstration: http://jsfiddle.net/joshnh/MwMYT/
Some browsers don't render scaled elements very well. Chrome is notorious for this (although it is most noticeable when transitioning the scale of an element). They are getting better though!
With that being said, I think your proposed solution is a reasonable one, and the drawbacks are certainly manageable!
I don't think there's any, apart from browser support. CSS transform is good because it's hardware accelerated, so it's faster, and smoother.
So, I'm looking to do a background image in CSS using a sprite sheet. And just to be clear, no I am not going for this effect. I have a full sprite sheet, and I would like to take a 16px by 16px square on the sheet and set it as the background that will be repeated.
At some point in the future, I hope to be able to do this via spacial dimensions using media fragments in the URL parameter, but since this isn't supported yet I'm looking for an alternative. Is there any way to get this same effect via modern CSS techniques or hacks?
Some notes:
I don't need to support old browsers, just the latest FF or Chrome will do.
I would prefer pure CSS solutions. I can and will create a JS/Canvas solution with data:URI's if I need to but considering how many elements I may need this for, I would prefer to not have to do that if I can get better results via pure CSS.
Need to repeat in both x and y directions
Looking for solution that takes advantage of a single image in memory/cache so that I don't have to load the sprite-sheet for every sprite I want to insert
Here's a pure CSS solution that works in Firefox only, but seems to meet all your requirements.
body{ background-image: -moz-image-rect(
url('http://placekitten.com/500/500'),
0,100,100,0
); }
Example at http://jsfiddle.net/47CMr/2/
There is only one method that falls under your conditions (the hardest one is the need to repeat): using the border-image.
The dabblet with the demo: http://dabblet.com/gist/1635890
The point is: you can mark the part that you want to use using the border-image-slice part of the border-image property. The syntax is a bit tricky, but using it you could create different repeating paterns from border-images. Also, when the needed parts are not on the edge, or when you need to repeat the image both on X and Y, you'll need a clip property, so you'll need a block to be absolute positioned. All these things work even in Opera.
But, there is one bad, bad thing: the rendering of central part of border-image is a kelly hell: there is a difference not only between webkit and mozilla, but even between the Safari and Chrome, so I added a lot of hacks there.
In conclusion: the goal can be achieved, but with a hell of a hacks.
So, I'd advice you to use the data:uri, 'cause there are no other ways to do this in webkits and Fx both (in Fx-only you could use the -moz-image-rect as mentioned above).
So I'm looking at a specific application for a web browser which requires me to express color as a straight alpha channel with a black and white alpha channel as a separate element. (an example of both types
I know many moons ago, IE supported some perverse filter options, but since I'm doing css3 transforms, I need this to work in a modern browser, preferably Chrome.
Basically what I'd like to do is have an element with CSS transforms applied, specifically rotation most likely, then I'd like to take that and copy it to another equivalently sized element which has the black / white transformation applied. An additional bonus would be setting the original element to use straight alpha, but I can live without that for now.
I haven't been able to find any routes with which to start investigating. If you have one, I'd be super grateful. My last resort is to start doing things in WebGL or Canvas and modifying the output there.
Two or three different elements stacked on top of each other using absolute positioning and z-index? This would require you to save two different images which I'm guessing you're trying to avoid.
You can do CSS 3D transforms. Browser support is basically there in newer IE, Chrome, Firefox, iOS and Android.
where can you use them
how to use them
MDN
I've actually figured out the answer... it's CSS Shaders.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html
Not yet available, but soon.
The reason not to use Canvas is for simplicity in authoring. (Long story.)
Sencha Animator is using CSS3 animations exclusively.
RaphaelJS is using SVG animations.
I wonder what are the similarities and differences between SVG and CSS3 animations?
Could one be used instead of the other or are they for difference tasks?
Ok. I have a whole presentation with an introduction to CSS Animations and A little on SVG.
But here are the oversimplified essentials:
The CSS Animation spec (per se) is just equipping you to declare "key frames" or multi-step transitions between Styles.
"Styles" in CSS3 includes "Transform" which specifies the scale, rotation, skew and position offset of a page element.
It's possible to "Transition" between styles, and specify the time and pace of that transition, to the extent, even, of declaring a cubic bezier timing function.
Combining Animations, transitions and transforms gives you an easy, declarative way of moving and transforming ANY page element (an img, a div, a video etc.) in a very rich way, that also progressively degrades nicely in older browsers (as long as you're sane about things).
BUT every element is essentially treated as an undifferentiated 2d rectangle for the purposes of animation, so its really all about animating sprites. At Sencha, as you've noted, we've even built a whole CSS Animation tool around this. And you should take a look at some of the demos there because it shows that you can really do a lot with the small set of primitives that CSS gives you. - Product Discontinued.
SVG Animation can be performed using the built in SVG animation capabilities (animate, animateelement etc.), SMIL (a declarative animation description similarish to CSS Animations) or JavaScript), has a richer set of capabilities than CSS Animation, but only because you're creating SVG Objects and changing their properties. You can't use SVG "animation" to, for example, animate an existing piece of HTML.
But it's also much richer. The biggest gain in SVG is that you're declaring drawing paths and fills with great flexibility (lines, arcs, quadratic arcs, cubic bezier arcs etc. etc.) and you can change the value of these properties over time using transforms and key splines (similar to timing functions in CSS Transitions)) This allows you to perform "rigging" animation rather than sprite animation. (I'm not an animator, I'm just using the terms I think are appropriate). So you can actually draw things like this cat walking across the screen, using line animations impossible to perform with CSS Animation (or impossible to perform for people of reasonable sanity - if insane people want to declare large numbers of zero height divs with border radii and use transforms to simulate arcs, then it's a free country.)
On the other hand, SVG is a PITA if you're writing it unassisted (verbose XML style with XHTML dtd). I'd highly recommend Raphael if you're a JavaScripter - Raphael has the benefit of degrading to VML vector graphics in older IE. SMIL (declarative animation for SVG) is a nice idea but it's not properly supported in many places. Also many browsers don't properly support SVG and those that do, often support it incompletely, particularly when you try to animate properties.
Update: there are many more updated animation libraries nowadays including snap.svg, greensock and others.
And there's no SVG support in Android 2.x, so if you want web animations that work on phones you're stuck with CSS Animations.
Having taught myself the basics of SVG animation in order to develop the intro presentation linked at the top, I can give a hearty thumbs down to hand-writing SVG. It's hard to remember, it's non-intuitive and because its XML, it tends to either work completely or fail completely, making it frustrating to debug.
They are completely different.
SVG is a vector image format. It is used to create infinite-resolution images using paths and basic shapes:
CSS3 animations, however, are just web browsers smoothly interpolating CSS properties like color, padding, font-size, etc. As you can see, the scope of CSS3's animations is very limited.