Then there are guilty hacks like when you find some way to achieve something with three lines of jQuery, but feel (rightfully) guilty for not achieving it from the code-behind or not being able to justify it in your documentation.
And then there are plain ugly hacks that you'll just never, ever use, no matter how cool the result is.
I'm inclined to classify this as a member of the third type.
The author is pretty open about this not being anywhere near ready. It would be better if they were open about the possibility of this loophole being patched up in the spec, making this a pretty useless trick.
One of the problems could be that you have javascript running on the page that takes decisions based on the size of fonts. Now if those fonts are loaded asynchronously in the background, your page may end up looking garbled. Unless, of course, the loading of the css triggers a re-evaluation of the javascript code. But this makes the code even more hairy.
This would be better as a simple script block with 'defer' and a js GET, with a noscript link tag fallback. This way is likely to fail in so many places.
Then there are guilty hacks like when you find some way to achieve something with three lines of jQuery, but feel (rightfully) guilty for not achieving it from the code-behind or not being able to justify it in your documentation.
And then there are plain ugly hacks that you'll just never, ever use, no matter how cool the result is.
I'm inclined to classify this as a member of the third type.