Missed a handful of clear downsides: It obviously doesn't work at all if the useragent disables web fonts (as, frankly, all clients should). The colors cannot be remapped as they are part of the...
Missed a handful of clear downsides:
It obviously doesn't work at all if the useragent disables web fonts (as, frankly, all clients should).
The colors cannot be remapped as they are part of the font. Want to apply style overrides? Text in the colored font will immediately become illegible with no workaround (other than disabling the font altogether).
That font is going to contain a lot of glyphs and substitution rules which are not used on any given page. (I hope the format can reuse outlines between different-colored glyphs!) And on the sort of page which would use this technique, that's probably going to be a meaningful contributor to page weight.
It's neat that you can do this, I suppose, but at least my immediate reaction is "I absolutely do not want my fonts to have those capabilities".
It's a stupendous attack surface for pretty marginal benefits, and a bunch of the code for handling fonts was originally written in the 80s, when (a) nobody cared about security, (b) Adobe...
It's a stupendous attack surface for pretty marginal benefits, and a bunch of the code for handling fonts was originally written in the 80s, when (a) nobody cared about security, (b) Adobe specifically really didn't care about security, and (c) it verged on implausible for an average user to ever encounter a font which wasn't shipped by their OS vendor.
Windows, which embedded font rendering in the kernel for some ungodly reason, has semi-regular kernel RCEs from font parsing vulnerabilities.
... and also I have a perfectly good default font set in my browser, and I would like websites to use that, because I find it more readable than whatever trash they picked to match their Brand Image.
... and also I have a perfectly good default font set in my browser, and I would like websites to use that, because I find it more readable than whatever trash they picked to match their Brand Image.
Very limited for anything but simple use cases. But, I was not even aware you could achieve this with fonts alone, and think it is a very neat demonstration.
Very limited for anything but simple use cases. But, I was not even aware you could achieve this with fonts alone, and think it is a very neat demonstration.
It would be interesting to see some measure of the performance impact of this option. My assumption is that the font file is going to be fairly large - probably larger than most syntax...
It would be interesting to see some measure of the performance impact of this option.
My assumption is that the font file is going to be fairly large - probably larger than most syntax highlighting libraries would be, once you account for all the different syntaxes that are generally available. Font files are generally pretty chunky in my experience - for a lot of static sites, the fonts will be the single largest downloaded file on the page, doubly so if there are multiple fonts.
In addition, rendering complex fonts isn't free - presumably the more syntax highlighting that happens, the more work the browser needs to do to render the text. This will normally be pretty efficient, but I could believe that adding too many substitution rules could create a pathological case and tank the performance. It would be interesting to see what the limits of this are and if you can write a font that would render more slowly than Javascript.
Right now the syntax highlighter applies HTML, CSS, and JS highlighting on the same text, which in this case probably isn't so bad as they're fairly different languages. I wonder if you could toggle each language on and off using variable font settings - that way you could support a lot more languages in the same font while still having the result be coherent (although you'd end up with a huge file at the end).
Very cool, but in my opinion highlights how HTML has not kept pace with the web. HTML is badly in need of a long list of primitives to cut down on boilerplate and redundancy and make JS more...
Very cool, but in my opinion highlights how HTML has not kept pace with the web. HTML is badly in need of a long list of primitives to cut down on boilerplate and redundancy and make JS more optional.
With how common code snippets are on technical corners of the web, a <code> element capable of basic syntax highlighting that has corresponding additions to CSS for customization makes a lot of sense and should probably be on that list.
Missed a handful of clear downsides:
It's neat that you can do this, I suppose, but at least my immediate reaction is "I absolutely do not want my fonts to have those capabilities".
(See also llama.ttf.)
Hot take! Why do you feel this way?
It's a stupendous attack surface for pretty marginal benefits, and a bunch of the code for handling fonts was originally written in the 80s, when (a) nobody cared about security, (b) Adobe specifically really didn't care about security, and (c) it verged on implausible for an average user to ever encounter a font which wasn't shipped by their OS vendor.
Windows, which embedded font rendering in the kernel for some ungodly reason, has semi-regular kernel RCEs from font parsing vulnerabilities.
... and also I have a perfectly good default font set in my browser, and I would like websites to use that, because I find it more readable than whatever trash they picked to match their Brand Image.
Shoutout to OpenDyslexic.
Very limited for anything but simple use cases. But, I was not even aware you could achieve this with fonts alone, and think it is a very neat demonstration.
It would be interesting to see some measure of the performance impact of this option.
My assumption is that the font file is going to be fairly large - probably larger than most syntax highlighting libraries would be, once you account for all the different syntaxes that are generally available. Font files are generally pretty chunky in my experience - for a lot of static sites, the fonts will be the single largest downloaded file on the page, doubly so if there are multiple fonts.
In addition, rendering complex fonts isn't free - presumably the more syntax highlighting that happens, the more work the browser needs to do to render the text. This will normally be pretty efficient, but I could believe that adding too many substitution rules could create a pathological case and tank the performance. It would be interesting to see what the limits of this are and if you can write a font that would render more slowly than Javascript.
Right now the syntax highlighter applies HTML, CSS, and JS highlighting on the same text, which in this case probably isn't so bad as they're fairly different languages. I wonder if you could toggle each language on and off using variable font settings - that way you could support a lot more languages in the same font while still having the result be coherent (although you'd end up with a huge file at the end).
A really cool concept though!
Very cool, but in my opinion highlights how HTML has not kept pace with the web. HTML is badly in need of a long list of primitives to cut down on boilerplate and redundancy and make JS more optional.
With how common code snippets are on technical corners of the web, a
<code>element capable of basic syntax highlighting that has corresponding additions to CSS for customization makes a lot of sense and should probably be on that list.