Text Rendering on Modals

[jnowland]

Text rendering changes when an element is animated to make the transition as smooth as possible. The problem is however after the animation ends the text is currently still rendering in the animation mode (text-rendering: optimizeSpeed I think.)

I was wondering how we were going to tackle this problem? As quality is obviously a important element for this project.

See blow screenshot below highlighting this problem.

[AaronLayton]

I noticed this aswell.. As we are not changing this property would this be a bug in Blink @paulirish ? should fall back to the nicely drawn one at the end of the animation.

As a work around we could put text-rendering: optimizeLegibility on the last keyframe and make all animations go to 99.9%?

[chriscoyier]

Note exact lines: https://github.com/h5bp/Effeckt.css/blob/master/scss/modules/modals.scss#L23-L27

Originals suffer from this blur as well: http://tympanus.net/Development/ModalWindowEffects/ Its just mitigated a bit because of the color choices.

[chriscoyier]

We may be able to:

• Use fixed size modals and center using negative margins instead of transform
• Center with display table type stuff
• Some other fix like the text-rendering thing or blur(0)

We just need to make sure

• Performance can still be good
• the transforms on the modal innards don't still cause same problem

[AaronLayton]

Hmm that depends how much implementation we provide for them? The translate trick is great but if we start to center by negative margins then we will either have to give them a set size model, or provide instructions to update the margin...

[chriscoyier]

This is a philosophical thing kinda. I feel like the aim of the project is "we'll do whatever we have to do to make sure things are performant" - but also ideally do it the "good" way too and note why it's not working well so browser can address it.

Perhaps a "bad kid holding pen" for all the demos that fit that category.

[grayghostvisuals]

The quick and dirty way as I said when I raised this issue originally is to set -webkit-filter: blur(0px) to those buttons. You could even put that in a shame.css file ;)

[jbeja]

Oh god, this one is so smelly.

[AaronLayton]

@grayghostvisuals if that fix works then I an for putting it in, we can always remove it once vendors fix

[chriscoyier]

Before we add it, see this comment :: #48 (comment)

[AaronLayton]

Ah yeah sorry, I read that comment the other day aswell :-S suggestions?

[grayghostvisuals]

@AaronLayton
Don't buy a hi-rez screen ;) Forgot about that comment. Hmm... Well it's a bug on Chrome so I guess the choice is the following...

1. Find the fix for the time being to battle that bug
2. Disregard the bug as just that. A bug that is not our fault and implement the style rule above.
3. Jump off a bridge

[AaronLayton]

Maybe a js fix for the time being. That leaves the implementation side upto each person and means when the issue is fixed by vendors we wont have to worry about it?

[chriscoyier]

One fix we might consider is just using a fixed pixel size for the modals and then just negative margins to center. Not a sexy as "centered no matter what size it is" but stops the blur.

[jkneb]

Have someone tried this approach? Looks pretty rad.
https://twitter.com/iamwarry/status/354595007937789954

[chriscoyier]

Nice find on the clever technique, unfortunately it didn't pan out.

My investigation here: 30973fa

I fixed the blur issue by just forcing the size of the modal. A bummer, but I think these are the choices that need to be made to keep the promise of quality and performance.