CSS transform vs position - css

Can some please explain to me the difference in transitioning the positional left or right properties or the -transform: translateX(n), as the both seem to achieve the same thing yet can be applied independently. I understand about the possibility of hardware acceleration but that's dependent on implementation.
// psuedo code;
#box {
-transition-property: all;
-transition-duration: 1s;
}
// javascript
box.style.transform = "translateX(200px)";
vs
box.style.left = "200px";
What's the advantage of one over the other?
Thanks,
p

The drawing order of rendering layers is:
layout layer
paint layer
compositor layer
A redraw in a layer will trigger redraw in subsequent layers.
Changing left or margin will trigger a redraw in layout layer (which, in turn, will trigger redraws in the other two layers) for the animated element and for subsequent elements in DOM.
Changing transform will trigger a redraw in compositor layer only for the animated element (subsequent elements in DOM will not be redrawn).
The difference in performance (hence in frames per second or, in simple terms, in animation smoothness) is tremendous. Using the first technique will often result in jittery animations even on good machines (when the processor is busy), while the second will likely run smoothly even on systems with limited resources.
Another advantage of using transforms is compositor redraws are heavily optimized (animations to multiple elements result in one redraw for all), while changing layout layer will trigger a redraw after each change of each element.
For a more detailed explanation on rendering techniques and rendering performance I recommend Google's Web Fundamentals.

Position is dependant on what the position is set to, transform works from the element itself. So you could see transform as being identical to position:relative;.
However, you can still use transform on an absolutely positioned element (to position it relatively without needing an additional element or resorting to margins), as well as transform being CSS3 so if you can use position instead you should.

top and left CSS properties work only on elements positioned relative, absolute or fixed. Also, top and left properties rely on the parent's position (relative it, absolute or static). Translations are not affected by that settings.
Translation transformations are "identical" to applying top and left when element has position: relative. In any other case they aren't the same operations.

As mention above:
position:relative and translate can achieve the same effect in a different way
position:relative happen in the layout phase which means it can interact with other elements in terms of layout
while translate happens when all the layout process complete, further it even already painted, what is remaining is a matter where to put the element, so it has no interaction with the existing layout
consider the following example which will present an obvious visual difference by using the two methods
.container {
width: 300px;
height: 300px;
overflow: scroll;
background: red;
}
.child {
width: 280px;
height: 280px;
background: green;
}
<div class="container">
<div class="child"></div>
</div>
By setting position:relative;top:100px to the child element, the container has no enough space to hold the child, and because of the fact that overflow is set as scroll, the scroll bar will present
On the other hand, By setting transform:translateY(100px), it has nothing to do with the layout, so the scrollbar will not present
Like the spec said:
However, if relative positioning causes an 'overflow:auto' or
'overflow:scroll' box to have overflow, the UA must allow the user to
access this content (at its offset position), which, through the
creation of scrollbars, may affect layout
To conclude, position is involved in layout, while transform not, which means transform can have better performance.
prefer transform to position when the layout is not your concern

Related

will-change breaks showing position absolute div on :hover

I have an issue with will-change. I have no idea why it causes this problem but when I add will-change on wrapper in which I have list with hidden divs (which should show up on hover) it breaks showing that divs. t shows part of it or not at all (depends on browser). Do you have any idea why it breaks that functionality?
Link -> http://jsbin.com/rukanajugi/1/edit?html,css,output
Contrary to common belief, the will-change property may actually have an impact on the visual appearance of the element, as it creates a new CSS Stacking Context if used with Stacking Context Creating Properties (e.g. position, opacity, transform) BEFORE the actual transformation was made.
This may therefore change the layout, as the order of the layers (which element is above which one) may be changed.
In your case, the creation of the new Stacking Context through will-change: opacity, causes the layout issue. The hidden divs are positioned absolute, therefore don't increase the size of their parents/grandparents and are therefore cropped by the .menu-wrapper, which now has a stacking context.
You have multiple solutions for this, e.g.
Use .menu-wrapper { overflow: visible; }
Increase the Size like this: .menu-wrapper { height: 200px; }
Do not use Stacking Context creating properties on the will-changeattribute. E.g. using .menu-wrapper { will-change: border-width; } won't create any Stacking Context. As Soon as your .menu-wrapper gets properties, which create a Stacking Context (e.g. opacity: 0.9999), it will break again, however.

Parallax (relative) layer groups overlay eachother

I don't get why this is happening:
I have:
https://jsfiddle.net/d5jehq02/1
<div class="para_group">
<div class="para_layer para_layer_back">
<h2>background</h2>
</div>
<div class="para_layer para_layer_front">
<h2>forefront</h2>
</div>
</div>
I am trying to create a parallax scrolling effect and although the 2 parent layers (class='para_group') have position='relative', still onr of the child divs - specifically seems to overlap its parent layer...
If you see the example link above, you will realize that the background layer from the 2nd group - seems to overlap the first group all together - when it shouldn't - the group's position is set to relative - therefore block objects (the parent divs) should appear one below the other...
I cannot get my mind around this one :(
The relativity of the conventional html positioning in here is seriously disturbed by the fact that the layer_back elements AND layer_front elements are actually moved into 3d context and scaled.
To achieve the parallax effect, what is done in here is:
Setting 1px perspective (camera set 1px away from the rendering plane).
.parallax {
perspective: 1px;
}
Moving the background layers 1px deeper into the field of view while at the same time scaling them to be twice as large.
.para_layer_back {
transform: translateZ(-1px) scale(2);
}
^ This is the heart of the parallax effect, as moving the elements 1px deeper when we have perspective set at 1px, positions the elements twice as far from the camera as the front layers which are translateZ'd by 0. This produces the parallax effect while scrolling, but also makes the elements appear smaller, because they're further away (the perspective effect).
That's why they are scale(2)'d so they appear in their original size.
Thing is, they're moved away from the camera without changing their relative positions (they're right next to each other then), and then they're scaled in-place, the scale operation having transform-origin set at their centers, makes them get larger and overlap each other.
What you could do to solve the problem is to work on first moving them away from each other before scaling them.
Take a look at the forked and updated fiddle where I've removed the "scale(2)" part on the back layers, they are in the back, and they are positioned properly (without overlapping).
http://jsfiddle.net/3x150vsx/1/
.para_layer_back {
transform: translateZ(-1px) scale(1);
}
The solution to your problem lies in moving them away from each other before you try to scale them up.
Good luck :>

Bootstrap 3, Three-column fixed layout breaks in Chrome

I have tried everything within my repetoire to fix this. I fall on my knees with open hands!
You can view a draft of the page here:
www.barrettcv.com/draft_so.html
If you would like the gist of how the page should work, simply view it in Firefox (with browser window smaller than 992 and scroll down. The side panels start off attached, and then 'fix' to become static while the rest of the content moves. This is the correct behaviour
Main problem.
The problem arises in Chrome. When the menu column and the details column 'fix,' (scroll down the page a little) all digital hell breaks loose.
Secondary problem.
When the view window is about 1200px, the space between the menu column and the main content panel doubles up. This isn't as big a deal as the first problem (which has had me attempting to destroy my flat's retaining wall with my forehead) - but it's got me relatively flumoxed, as I'm sure there must be a more elegant solution that forcing it back into position with media queries
It looks like you are coming up against an issue in how the different browsers calculate the position of fixed position elements when no positional CSS properties are defined for the element e.g. top and left. From the spec:
...user agents are free to make a guess at its probable position.
For the purposes of calculating the static position, the containing
block of fixed positioned elements is the initial containing block
instead of the viewport...
I think the only way around this is to choose a different positioning scheme. You can remove the .col-md-pull-* and .col-md-push-* classes and reposition the Bootstrap columns by using absolute positioning (depending on media queries to arrange those columns how you want for different viewport sizes). In this case it appears all browsers honour the position of the fixed element.
.row {
position: relative;
}
/* apply to the details column */
.push-9 {
position: absolute;
left: 75%;
}
Example: http://bootply.com/92096
What you need to do is to fix both left and right column, starting from that you will have a much better way of controlling your divs (since you want them fixed as I can see).
So, sumarizing: you need to add position:fixed to both your left and right columns. Modify your left: x% and right: x% so that they match your criteria.

What has bigger priority: opacity or z-index in browsers?

I'm coding a "popup window" in JavaScript and I've come across an interesting thing:
The navy square under the popup window is visible even though I would expect it to be hidden. The popup was added after the square, so it should be on the top.
CSS opacity property of the navy square is 0.3. From what I've tried, it seems that every number from the interval (0,1) would yield the same result. If I change it to 1, then it behaves as expected (i.e. the part of the square under the popup is hidden).
I've tried to set the z-index property to 10 for the square and 100 for the popup, but it doesn't change anything.
What am I missing? Why is part of square displayed?
Tested browsers:
Firefox 3.6.x
Chrome 4
This is not a bug and is actually how it's supposed to work. It's a bit confusing as the elaborate description of Stacking Contexts doesn't mention anything about it. However, the visual formatting module links to the color module where this particular gotcha can be found (emphasis mine):
Since an element with opacity less than 1 is composited from a single
offscreen image, content outside of it cannot be layered in z-order
between pieces of content inside of it. For the same reason,
implementations must create a new stacking context for any element
with opacity less than 1. If an element with opacity less than 1 is
not positioned, implementations must paint the layer it creates,
within its parent stacking context, at the same stacking order that
would be used if it were a positioned element with ‘z-index: 0’ and
‘opacity: 1’. If an element with opacity less than 1 is positioned,
the ‘z-index’ property applies as described in [CSS21], except that
‘auto’ is treated as ‘0’ since a new stacking context is always
created. See section 9.9 and Appendix E of [CSS21] for more
information on stacking contexts. The rules in this paragraph do not
apply to SVG elements, since SVG has its own rendering model ([SVG11],
Chapter 3).
It's not a problem of opacity being more important than z-index, rather than z-index being relative to their stacking context (see z-index in the CSS2 specification).
In other words, z-index are only significant within the context of a positioned ancestor (whether its relative, absolute or fixed). What you need to do to fix your problem is add a position: relative; to the element that contain both your popup and your navy square, and probably add it a z-index: 1; . Seeing your screenshot it will probably be a top element such as a wrapper div.
Workaround for two elements, like divs: add a 0.99 opacity to your top element, and the order of both is reestablished.
opacity: 0.99;
An alternative to using opacity, is to use a transparent colour (with an alpha value)
So, rather than using
{
background: gray;
opacity: 0.5;
}
You could try
{
background: rgba(128,128,128,0.5);
}
It isn't identical, but I was encountering the same issue you were having, and the above fixed it.
Example code might be needed to debug this problem.
You might put overflow: hidden and possibly position: relative in a DIV which surrounds all the editor objects to try to force the elements to only be drawn within that DIV, e.g:
<div style="overflow: hidden; position: relative">
(Editor object buttons go here)
</div>
As a last resort, you could also try a iframe in between the two elements to try to stop them seeping through.
You might try to set the popup window's DIV like this using !important so the style doesn't change on applying new style or class:
background-color: white !important;
z-index: 100 !important;
opacity: 1.0 !important;
Then, make new CSS class:
.PopupElement
{
z-index: inherited;
opacity: inherited;
}
And add class to all elements in the window, like this for example:
<input value="posx" class="some_class PopupElement"/>
My guess is that this would work, since there is no priority in applying CSS attributes... as far as I know. =)
I had the same issue. Using rgba instead of color/opacity solved my problem. Working with LESS (in the Bootstrap framework), the fade() function did the conversion for me.
Although #Guillaume Esquevin already gave a great answer, I will try to expand on it in case someone ignores what a stacking context is (like I did).
As you can read here, there is something called stacking context, which refers to a group of elements sharing a parent that move together in the stack. An example could be a div and all its children.
There are three ways to create a stacking context: in the root of the document (the html element), by positioning the parent element, and by changing the opacity of the parent to something lower than 1.
Then, if you have a div with opacity lower than 1 and you want some sibling element of this div to appear behind it (and its children), you can create a new stacking context on such sibling by setting its position to relative or by changing its opacity as well.

IE 6 & IE 7 Z-Index Problem

http://madisonlane.businesscatalyst.com
I'm trying to get the div#sign-post to sit above the div#bottom. This works fine in all browsers except IE6 & IE7. Can anyone see what the problem is here?
Also IE6 is displaying an additional 198px to the top of div#bottom.
Most of the answers here are wrong; some work, but not for the reason they state. Here is some explanation.
This is how z-index should work according to the spec:
you can give a z-index value to any element; if you don't, it defaults to auto
positioned elements (that is, elements with a position attribute different from the default static) with a z-index different from auto create a new stacking context. Stacking contexts are the "units" of overlapping; one stacking context is either completely above the another (that is, every element of the first is above any element of the second) or completely below it.
inside the same stacking context, the stack level of the elements is compared. Elements with an explicit z-index value have that value as a stack level, other elements inherit from their parents. The element with the higher stack level is displayed on top. When two elements have the same stack level, generally the one which is later in the DOM tree is painted on top. (More complicated rules apply if they have a different position attribute.)
In other words, when two elements have z-index set, in order to decide which will show on top, you need to check if they have any positioned parents which also have z-index set. If they don't, or the parents are common, the one with the higher z-index wins. If they do, you need to compare the parents, and the z-index of the children is irrelevant.
So the z-index decides how the element is placed compared to other children of its "stacking parent" (the closest ancestor with a z-index set and a position of relative, absolute or fixed), but it doesn't matter when comparing to other elements; it is the stacking parent's z-index (or possibly the z-index of the stacking parent's stacking parent, et cetera) which counts. In a typical document where you use z-index only on a few elements like dropdown menus and popups, none of which contains the other, the stacking parent of all the elements which have a z-index is the whole document, and you can usually get away with thinking of the z-index as a global, document-level ordering.
The fundamental difference with IE6/7 is that positioned elements start new stacking contexts, whether they have z-index set or not. Since the elements which you would instinctively assign z-index values to are typically absolutely positioned and have a relatively positioned parent or close ancestor, this will mean that your z-index-ed elements won't be compared at all, instead their positioned ancestors will - and since those have no z-index set, document order will prevail.
As a workaround, you need to find out which ancestors are actually compared, and assign some z-index to them to restore the order you want (which will usually be reverse document order). Usually this is done by javascript - for a dropdown menu, you can walk through the menu containers or parent menu items, and assign them a z-index of 1000, 999, 998 and so on. Another method: when a popup or dropdown menu becomes visible, find all its relatively positioned ancestors, and give them an on-top class which has a very high z-index; when it becomes invisible again, remove the classes.
Agree with validator comment - validating usually helps. But, if it doesn't heres a few pointers for z-index in IE:
1) elements who's z-index you're manipulating should be on the same level ie. you should be setting the z-index of #bottom and #body
if this is not feasible then
2) IE sometimes wont apply the z-index correctly unless the elements ou are applying it to have a position:relative. Try applying that property to #bottom and #body (or #signpost)
let me know how that works out
Darko
I just had this problem and the fix I found (thanks to Quirksmode) was to give the direct parent of the node you are trying to set a z-index of it's own z-index that is at less than the z-index of the node you are trying to set. Here is a quick example that should work in IE6
<html>
<head>
<style type="text/css">
#AlwaysOnTop {
background-color: red;
color: white;
width: 300px;
position: fixed;
top: 0;
z-index: 2;
}
#Header {
color: white;
width: 100%;
text-align: center;
z-index: 1;
}
</style>
</head>
<body>
<div id="Header">
<div id="AlwaysOnTop">This will always be on top</div>
</div>
<div id="Content">Some long amount of text to produce a scroll bar</div>
</body>
</html>
Welcome, I solved the problem with:
.header {
position: relative;
z-index: 1001;
}
.content {
position: relative;
z-index: 1000;
}
Looks to me like you have some malformed HTML in there. I tried counting, and perhaps I lost count of the opening and closing tags, but it looks like div#container isn't closed. Try running your page through a validator (such as W3C's HTML Validator, or something) and fixing some of the errors. That's helped me with these sorts of problems in the past. Good luck!
I've recently had an ongoing problem displaying one layer above another. In my case I was programmatically creating two layers in Javascript, one for diaplaying a custom control and one for creating a full screen layer behind it. FF was fine, bu IE displayed the full screen layer always on top of everything else.
After numerous trawls over the interweb, trying everyone's suggestions, the only way I eventually get it working was to remove position: attributes from both layers, and tweak the margin-top: attribute until I got a satisfactory result.
A bit of a hash, but it works and it'll be fine until IE 8 sorts out all of the current bugs......
the only reliable solution is, to put the top elements below in the code and then push them over the other stuff with absolute positioning.
e.g. Wordpress:
put the navigation in the footer file, but still inside the page wrapper.
might also bring some advantages for search engines, because they can directly start with the content, without crawling through the menu first...
UPDATE:
I need to correct myself. While putting the element below and then pushing it over is still the easiest way, there are certain cases when this is not possible in reasonable time. Then you have to make sure that each and every parent element has some kind of positioning and some senseful z-index. Then the z-index should work again even in IE7.

Resources