I did setup an HTML page where I use z-index to set the elements "visual" order.
It works as expected; but breaks when I use transform: scale().
#blocks-both{
transform: scale(0.9);
}
I make a simplified example here : http://codepen.io/anon/pen/LNYrar
I read a lot of messages regarding this particular problem, but I can't find a solution to make my design work.
I guess I don't understand something regarding this.
Could someone help ?
Thanks !
This is a known issue:
css z-index lost after webkit transform translate3d
webkit-transform breaks z-index on Safari
webkit-transform overwrites z-index ordering in Chrome 13
You can read more about it here as it offers in depth explanation.
In addition to opacity, several newer CSS properties also create stacking contexts. These include: transforms, filters, css-regions, paged media, and possibly others. As a general rule, it seems that if a CSS property requires rendering in an offscreen context, it must create a new stacking context.
You could avoid this issue by moving the transform properties from #blocks-both to #block-main and #block-sidebar like this:
#block-main, #block-sidebar {
transform: scale(0.9);
}
#block-main {
transform-origin: 100% 0;
}
#block-sidebar {
transform-origin: 0 0;
}
I've also edited your example.
Related
I am experiencing some weird issues with CSS scale transitions. The scaling works fine, however there are some weird lines around the scaled element, which disappear after scrolling. This happened in a Chrome browser and in Microsoft Edge. And I don't assume it has something to do with margin, padding, the z-index, colors or anything else along those lines, because it happened with and without these properties being included in the relevant CSS.
This is the relevant CSS as a quick draft:
.element {
background-color:black;
transition: transform 0.5s;
transform:scale(1, 1, 1);
}
.element:hover {
transform:scale(1.1, 1.1);
}
Here is a quick recording to demonstrate that: https://streamable.com/cyvkjm
Here is also a screenshot for those who can't see the video for some reason:
Your streamable link worked fine for me. I remember having a problem similar to that a while ago, and it was something to do with using 3d scaling
Check this out though, I'm fairly certain backface-visibility: hidden and the -webkit equivalent will fix it. As I can't reproduce this I can't be of much more help
CSS transition on element leaving lines
Edit: after reproducing the problem we found a fix. Tested and works in Chrome/Edge/Firefox. perspective(1000px) seems to work better than perspective(0)
.element {
transform: scale(1) perspective(1000px);
}
.element:hover {
transform: scale(1.1) perspective(1000px);
}
What is the difference between -webkit-transform: perspective and -webkit-perspective (given on -webkit- as the vendor.)
I tried this in the same case, but they return different result. Anyone know if it actually gives any difference?
I think this is a pretty clear explanation:
The -webkit-perspective property applies the same transform as the perspective() transform function, except that it applies only to the children of the element, not to the transform on the element itself.
Source: CSS property: -webkit-perspective
I'm just doing codeschool and they told me:
SORRY, TRY AGAIN
transform must be defined last, after the browser prefix styles.
and here is my code:
img:hover {
-webkit-transform: translate(10px,20px);
-o-transform: translate(10px,20px);
transform: translate(10px,20px);
-moz-transform: translate(10px,20px);
}
As I always do I start to playing with my code and discover that I don't need this line of code:
transform: translate(10px,20px);
at all! Everything is working without it! Then I tried to delete all these stuff
-webkit-transform: translate(10px,20px);
-o-transform: translate(10px,20px);
-moz-transform: translate(10px,20px);
and leave
transform: translate(10px,20px);
only. What a surprise! it doesn't work! So here is my first question:
Why do I have to define line transform: translate(10px,20px); without -o-/-webkit-/-moz-
if it doesn't work at all?
and than second:
WHy codeschool tells that
SORRY, TRY AGAIN
transform must be defined last, after the browser prefix styles.
Why?
CodeSchool is forcing you to use a CSS best practice. This one is has a good reason: future-proofing. Why/how?
CSS3 isn't quite standard yet, but that hasn't stopped the people at Google or Mozilla from trying to implement the features. Problem is, since CSS3 is changing, those guys aren't quite sure how it works. To get around this, the non-standard prefix notation (-moz- or -o- rules) were created as transitional rules to use while the CSS3 spec is slowly finalized.
But this created a new problem: "what to do with these rules once CSS3 is finalized?" That is what the 'Cascade' in CSS is for: rules lower-down take priority over those higher up. By adding the 'standard' rule below the extension ones, it will override the browser-specific ones only when the browser supports it.
Thus, we can use features bleeding-edge browsers today, while being ready for the standards tomorrow, and do it with the same CSS file!
the -o-/-moz- etc.. are browser specific declarations which are in place to allow browsers that don't support the native property but have their own implementation.
You should always have the regular property without the prefix. Prefixes are only their to extend the range of browsers that will apply the property.
The specific order of the properties will have no effect on the page output, however depending on how strict a validator is it may tell you that it's not valid unless the unprefixed property is written last
I am building a multi-lingual website. Some languages (like Hebrew) read from right-to-left. Besides the actual text, those users are used to having navigation and other visual clues reversed.
For example the main menu on top would be aligned to the right. "back" button would point forward, logo on the top right instead of top left, etc.
One solution is of course to create a whole new design, however that would mean I'd have to maintain 2 templates. Not ideal.
I was just thinking, would it be possible to flip the entire design in CSS? Like looking in a mirror?
I'm also opened to better solutions if this seems far fetched.
Technologies used: PHP, Yii, Less.css, jQuery
It is possible to flip the entire site exactly as you describe with but a few lines of CSS see here: http://jsbin.com/aduqeq/5/edit
CSS:
body {
margin: 0 auto;
width: 300px;
-moz-transform: scaleX(-1);
-o-transform: scaleX(-1);
-webkit-transform: scaleX(-1);
transform: scaleX(-1);
filter: FlipH;
-ms-filter: "FlipH";
}
There are a few downsides to this approach however:
1) While it works Fine in Firefox + Chrome, it only sort of works in IE8+ (the text looks very strange to me in IE) expect support to be a bit patchy (this is a new CSS3 feature)
2) There are obvious semantic disadvantages here
3) Some people seem to have a thing about vendor prefixes
Overall using RTL on the body and using a different stylesheet might be a much better alternative here, even thought it's more cumbersome for you, the end user is provided with a better experience (unfortunately the quick fixes we want aren't always available)
A lot of sites consist of a menu bar and a content area. These are usually the main areas of focus for flipping. Should be easy with 3 lines of CSS :
html[dir="rtl"] #menu {
float: right;
}
This same CSS code can easily be adapted to match other areas that should be moved. There's really no need to maintain 2 sets of templates, unless you hardcoded coordinates (which was a bad idea anyway).
Of course, make sure to set <html dir="rtl">
html {
direction:rtl;
}
This will reverse everything on page from right to left. You need to adjust this for every element in your page.
You can try:
body {
direction:rtl;
}
But that would just give you a starting point to start from...
Hope it helps.
The developers of MediaWiki, the software that powers Wikipedia in hundreds of languages, developed a tool called CSSJanus, which can cleverly flip your CSS on the fly for right-to-left languages:
https://github.com/cssjanus
This is successfully used for Wikipedias in right-to-left languages, and as a result they require very little duplicate maintenance of CSS.
You can flip the entire website using Seandunwoody his answer but that would reverse the text and icons and images and such as well.
Provided that you place your content in <p> and <h1> 2 and 3 tags, which you do not put into each other (so no <p><p></p></p>) you can apply the css like this:
body,p,h1,h2,h3 {
margin: 0 auto;
width: 300px;
-moz-transform: scaleX(-1);
-o-transform: scaleX(-1);
-webkit-transform: scaleX(-1);
transform: scaleX(-1);
filter: FlipH;
-ms-filter: "FlipH";
}
What it does is basically the double mirror trick, it mirrors the complete website and then it mirrors all the small paragraph and titles which contain your text and images back to the original orientation but still in the position of the reversed website.
Hacky but it works (not so nice on IE though).
*You also need to add the dir='rtl' to the html or body tag to make sure the text is alligned to the right and hebrew is reversed (english characters will stay left to right but allign right).
There is a great Magic Tool for that called rtlcss
TLDR;
long time ago, I got away with doing the following:
1. if an element has a direction:rtl -> remove it
2. if an element have no direction:rtl -> add one
in most cases, add direction:rtl to body
4. if element has align:right/left' -> switch left/right
5. if element hasmargin-right/left` -> switch left/right
Limitations which are not handled:
1. Statically placed elements may not be placed right
2. Relative placements may not be placed right
3. Styles in the HTML should be taken care of (if exists, suggest to move into the CSS)
be careful if you plan on using Find & Replace as right & left can be found in mysterious places.
e.g. .copyright { ... } can become .copyleft { ... }
Searching today (Jan '18) i found this great tool that do all the above for you:
Take a look at RTLCSS Website
I used it as command line, as i needed to RTL a library CSS i had once, but it can be bundled in your build steps.
I agree to Sean's answer, it actually works! But there's one thing I'd like to mention: he needs to remove the "margin" and the "width" in order to make the page more readable but still flipping.
body { -moz-transform: scaleX(-1); -o-transform: scaleX(-1); -webkit-transform: scaleX(-1); transform: scaleX(-1); filter: FlipH; -ms-filter: "FlipH"; }
I'm trying to apply some CSS3 transitions on some headers in a website I'm working on, but there's something about transitions on elements that contain text that really bugs me: in browsers that apply hinting or grid-fit a font's glyphs (which I guess is most of them, bar perhaps Safari), there is a noticable 'jump' at the beginning and end of a transition where you can see that text is snapped back to the pixel grid, as demonstrated in this jsfiddle: http://jsfiddle.net/8csA9/20/ (part of this is probably a momentary 'blur' due to filtering, but there's definitely some shape modification going on here, at least in FF and Chrome)
Normally I'd not even consider messing with the intricacies of font-rendering, but considering the glyphs are so large I feel that it doesn't really matter in this case, and was wondering if there is either a way to disable hinting, or some other way of making these transitions a bit smoother. Does anyone know if this can be done, and how?
PS: This question actually extends a bit beyond just transitions, just applying a static rotation also makes at least Firefox continue to hint the text, and the result ends up looking rather.. odd
PPS: There does seem to exist (or have existed) a '-webkit-font-smoothing' property, but the CSS3-fonts draft appears to have dropped the rule it was based on (font-smooth), and it seems it only ever worked on Chrome for the Mac
Use backface-visibility: hidden;
**Update: webkit moz mz and the standard
http://jsfiddle.net/jugularkill/58S2z/4/
More on backface visibility:
http://www.w3schools.com/cssref/css3_pr_backface-visibility.asp
This worked like a charm for me. I added "backface-visibility:hidden" (plus major browser prefixes) to the elements with the transition property, and it fixed the jump/jitter I was experiencing during the transition. I tested in Firefox, IE (9/10) and Chrome.
One thing I noticed though: Make sure you add the property to the element's natural state, as opposed to the pseudo-class (e.g. hover, active...) of an element.
For me I found that I needed to add both backface-visibility: hidden and transform-style: preserve-3d to the element that contained jumpy content.
For example:
.element-with-jumpy-content {
-webkit-transform-style: preserve-3d;
-moz-transform-style: preserve-3d;
transform-style: preserve-3d;
-webkit-backface-visibility: hidden;
-moz-backface-visibility: hidden;
backface-visibility: hidden;
}
If you're using Bootstrap you can use this class:
.backface-visibility(hidden);
Adding transform: translate3d(0, 0, 0); or transform: translateZ(0); often helps to fix transition bugs, because it forces browser to use hardware-accelerated 3D transitions.