[css-highlight-api] Support for some font styles and decorations

[fabiospampinato]

I'm currently building a new code editor for the web that uses the CSS Custom Highlight API for syntax highlighting, with the idea being that it would simplify things significantly while at the same time improve performance.

But, some basic forms of font styles and decoration (italic, bold, underline, strikethrough) are not supported by this API. As I understand it only properties that can be applied efficiently are supported, but arguably a subset of the font-style and font-decoration properties can be applied efficiently in some scenarios, even if this capability were limited to monospaced fonts it would unconstraint my use case, which would be amazing.

As far as I know the folks at VS Code are also exploring using highlights for syntax highlighting, which would potentially enable optimized syntax highlighting for millions of developers worldwide, so it'd be extra nice if highlights could be used for 100% of normal grammar-based syntax highlighting, rather than the current 99%.

[SebastianZ]

Decorations like underlines and strikethroughs are already supported via text-decoration.
The spec. currently explicitly excludes layout-affecting properties.

Sebastian

[fabiospampinato]

Oh nice! I was basing my assumption on an outdated article apparently.

A way to make text italic and/or bold seems to be the only thing missing before this API can be used fully for syntax highlighting then. I mean it's not the end of the world if those are not supported, but ideally a modern syntax highlighter should support those.

[sanketj]

Custom highlights support the same set of properties as all other highlight pseudos. These are defined in the CSS pseudo spec: https://drafts.csswg.org/css-pseudo-4/#highlight-styling.

@fantasai Has adding support for bold/italic come up in past discussions?

[samuelbradshaw]

I would like to see this as well. However, I suspect that bold and italic would be considered "layout-affecting" because font weight and style can make things wider or narrower.

[fabiospampinato]

@samuelbradshaw not if the font is monospaced, presumably. Like in an editor kind of situation we want each character to have the same height and width as any other character, it doesn't matter if it's italic or bold or not.

[frivoal]

To avoid being layout affecting, we'd need more than just a monospaced font. We'd need the two fonts we're swapping from/to to be:

• fonts with the same x-height
• fonts with the same leading
• fonts with the same monospace advance measure
• really monospace: not just monospace over the ascii range, and varying results over the whichever other part of unicode is supported
• fonts with the same unicode coverage (otherwise, they might trigger fallback on different characters, and unless those fallbacks are also monospaced / same x-height / same leading / … we're back to square one)
  …

All in all, swapping fonts is, in the general case, layout affecting, and I doubt that's going to be practical here.

[fabiospampinato]

I feel like this could be special cased in practice though, like if the user explicitly wants to make the font bold or italic via custom highlights then hopefully the browser could measure the box that a regular character would occupy, render the bold or italic character in there, and chop away anything that overflows, forcing the highlight to not be layout affecting, whether it would have been layout affecting all things considered or not.

Like I think there's enough good that would be unlocked by this capability that is worth considering.

[fabiospampinato]

Another property missing seems opacity. Which presumably would make the text more transparent, which won't cause any layout shifts. Though I think that need would disappear once color-mix is able to manipulated inherited colors, if that ships.

[fabiospampinato]

text-decoration-color seems missing too, which is a bit annoying because it makes highlighting the same thing with the same colors, but once with normal CSS and once with custom highlights, slightly inconsistent with each other.

[schenney-chromium]

All of the text-decoration-* properties are supported, including color. From the Pseudos 4 spec: "text-decoration ... and its associated properties (including text-underline-position and text-underline-offset)". The spec is only calling out the text decoration properties that begin with text-underline- to be clear that those are decoration properties.

[fabiospampinato]

@schenney-chromium empirically under Chrome v116.0.5845.97, under Electron v26.1.0, text-decoration-color inside a custom highlight is just not working for me 🤷‍♂️

[yisibl]

Is it possible to support background-image?