What if the height of the container is some odd number pixels?
Let's say you have
height: 145pxand your
translateYproperty will be like
transform:translateY(72.5px)which means you're not pixel-perfect anymore. Your texts, icons, pictures will be all blurred.
Use it if pixel perfection doesn't matter.
PS: Table method is also 3 lines and it's cross browser already :)
display: table; /* parent*/ display: table-cell; /*child */ vertical-align: middle; /*child */ ``
You drive a hard bargain, sir! Didn't think of that at all.
This is also a good method, but if the parent or child has to have display set to something other than table/table-cell, the linked method is best.
I sure am glad there are multiple ways to do the same thing.
what's linked method?
Oh, the article this stream of comments is about.
I'm also a fan of this method
Let's say you have height: 145px and your translateY property will be like transform:translateY(72.5px) which means you're not pixel-perfect anymore. Your texts, icons, pictures will be all blurred.
I decided to put this to the test. (In Chrome and Firefox.)
Transform: translateY(–50%) actually translates –50% of the element height it’s declared on (ie. the child height), not the container/parent height.
So I tested 2 screenshots:
- 99x99px kitten without translateY
- 99x99px kitten with translateY(–50%)
I overlaid these screenshots and found the rendering to be identical. In other words, translateY(–50%) applied to a 99px image (odd pixel value for height) did not result in blurry rendering… as you suggested it should by the resulting (alleged) –49.5px translation.
I also did a couple tests with text, but I noticed no blurring. (The only blurring seems to occur during CSS transitions.)
Perhaps Chrome and Firefox are auto-rounding, but it seems we don’t needs to worry about "pixel perfection" using this technique (in Chrome/Firefox with images and text). I have not tested SVG or any other pertinent elements, or other browsers.
Anyone want to continue the experiment? :)
The problem is not specifically on the fonts, but in the rest. If the child has an odd height, all its elements will be blurred. Again, the fonts are not the issue because it's a different kind of rendering. Take a look at this example and notice the border above the text on the second item: http://codepen.io/lucasmotta/pen/hBcEw
I've been through that in the past and, trust me, it's not worth the fight.
Interesting, thanks for sharing this.
So text and images render fine, but borders get destroyed. Do you know what else doesn’t play nice?
Edit: I removed the border and changed the background color of the children, and its top edge is also blurred. I bet pseudo elements get blurred too. I’m curious about SVG…
I just updated my pen to show what happens with SVGs – unfortunately they also get blurred :(
It's normal. Browser converts everything (except fonts, under some conditions) to raster images so anything will be blurred.
Moving forward, flexbox is making a lot of these classic CSS gotchas easy to solve. Also, the syntax is as clean. Checkout this article for a good example.
I thought the same thing when reading this. I started learning flexbox late last year by building my Ghost themes with it. I love it so far. Can't wait to explore more and more complex uses for it.
Nothing is easy with flexbox. Between the three major changes in the spec, and every browser implementing the random parts from each spec they want, it's surprising that anybody can get anything accomplished with flexbox. That said, it is incredibly powerful, and will be great when everyone can get on the same page.
Not to mention there are (were?) some serious performance related issues.
This is true but the compatibility with browsers is way lower!
When I transitioned from print to digital, lack of vertical alignment 'support' was the thing that most made me say "you have got to f*@#ing kidding me" for my first 6 months.
I saw this article and applied to an app I'm building. Friggin' awesome. I showed my boss and he was impressed.
Very cool. Thanks for sharing.
I agree its pretty clever. But I still think that the display:table method is the way to go since that won't work on like most IE browsers
The article states that this works down to IE9. According to http://caniuse.com/usage_table.php, global usage of IE8 and less is about 6%. Of course, depending on your users, this could be higher or lower.
Nice technique, but occasionally you can't get away with relative positioning. In that case this is pretty robust http://codepen.io/alexmorris/full/IycHs