text-rendering: optimizeLegibility breaks layout

[144288]

It appears having body {text-rendering: optimizeLegibility} breaks the layout. It drops the last .unit onto the next line in Safari and Chrome. Firefox works however.

Found this using normalize.css instead of meyer's reset.

any ideas?

[robertpiira]

That's interesting.

My bet would be that optimizeLegibility (in this case) add some extra whitespace in between the units, as the units are inline-block elements (inline-block = inherit from inline element behavior).

Could it be that the maths of letter-spacing: -0.31em; word-spacing: -0.43em; need some re-calculating when optimizeLegibility is set(?).

The quickest fix could/would be to be specific and target paragraphs or headings directly and give them optimizeLegibility that way. say p {text-rendering: optimizeLegibility} instead of body {text-rendering: optimizeLegibility}...

hmmm, interesting! Let me know if you find any solutions.

[robertpiira]

Did a minimal research trip around the nets and did some tests locally.

It seems that webkit does some something weird on the inline-block units when text-rendering is set to optimizeLegibility and the inline-block elements have a negative word-spacing (word-spacing: -0.43em).

Removing the negative word-spacing fixed the issue...

Seems to be a webkit only thing though, or did you use some other browser/os?

[A note on negative word-spacing for inline-blocks in Ingrid. This is a classic inline-block whitespace workaround. the negative word-spacing is for Opera and the negative letter-spacing is set for the rest. The thing is, I'm running Opera 11.61 and on this version the negative word-spacing is not needed anymore. So could this declaration be removed from Ingrid?]

[144288]

for the moment I've set .ingrid to {text-rendering: optimizeSpeed;} until I can look into it further.

Could you explain the .31 and .43 values? Maybe that will help.

[robertpiira]

Sure,

when an element has display: inline-block, it (i guess) inherits some inline like behavior. In this case the .units get some additional whitespace on each side. the negative letter- / word-space is there to remove that this white-space.

and then we have to set the letter- / word-space to normal again for the content within each .unit.

the exact values .31em and .43em gives the most correct cross-browser spacing between .units. (not pixel-perfect cross-browser, but perfect enough).

Yui grids use the same measurements for their grids.

But like I said in the earlier comment. It's the combination of optimizeLegibility and the negative word-space that makes webkit do some weird stuff on the inline-block units. Maybe it's a bug(?), or maybe we could remove the word-space declaration because Opera seems to do just fine without it(?), well at least from version 11.61.

[robertpiira]

Oh, Yui grids have the same layout "bug" with text-rendering: optimizeLegibility; as you found in Ingrid.

and now that new versions of Opera seem to be happy without the negative word-space declaration... we could remove this declaration. Then webkit would be happy also.

This means that we could propably do just fine with only the negative letter-spacing for all browser (if not supporting for older Opera is not an issue?).

But I would really have to do some more testing and tweaking on this. So we will see what's the best solution for this. As for now, I would target optimizeLegibility on more specific typographic elements and not global containers.

Good call on this issue though! Thanks alot.

[144288]

Interesting! I tested minimially, and it works fine in webkit with word-spacing removed, but not letter-spacing. FF needs one or the other, but both can't be removed.

[robertpiira]

the negative letter-spacing is needed, no doubt about that.

My view on the word-spacing was that it used to be needed for at least Opera (have to verify this for IE also).

...and like I said, Opera 11+ seems to do just fine without the word-spacing also.

Would be cool though, if this indeed was some kind of webkit bug and that it would be fixed. It seems like optimizeLegibility has had some similar issues with letter-spacing and such before (according to my earlier googling on this issue) :)