This is particularly unfortunate since one of the strengths of view units is the ability to set variable font size.
Now. I'm not totally sure this is a bug in Webkit since unfortunately Internet Explorer 10 does the exact same thing.
It might be in the spec that way.
But, what you'd think *could* be done, would be that even if resizing the font continuously would be a performance issue, surely you could at least avoid the need for a manual refresh by the user by simply queuing a request to do this recalc maybe 500ms after any window resize. That way while the window was being resized, it wouldn't trigger 'cause it'd continually be pushed back. But as soon as it was done resizing, we'd get a nicely sized font.
Created attachment 160150 [details]
demo of problem
Added a delay to the workaround, in the interests of performance.
Now of course, the workaround might well screw up web pages. Reloading does do that.
If anyone knows of a way to trigger this recalc without reloading, do let me know. I'd love a "nicer" JS workaround.
Hm... Doing any change to the content seems to work too. Sweet.
Going to try a subtle adjustment of colour for forcing a recalc.
Actually, that wasn't enough. Toggling styles was enough in the Chrome dev tool, but didn't seem to have any effect in JS.
Sooo, resorted to removing the rule and adding it back in.
Updated http://m8y.org/tmp/testcase273.xhtml accordingly.
BTW, recreating the rule doesn't seem to be enough for IE10 either, soo, going to have to try and find some other workaround there.
Oh. That is. location.reload() (ugh) *does* work in IE10 but removing the rule doesn't seem to, unless the delay matters.
Probably not too interesting to the webkit guys, but maybe interesting to other page creators who run into this bug.
So, Firefox now has this in nightlies, implemented correctly.
Of the two other major browsers, IE10's brokenness is more irritating to fix, but if you guys would fix Webkit, maybe that would
put pressure on them?