It’s the time of year again when browser makers ask which shiny new features they should implement in preference to addressing outstanding bugs and omissions. Apologies for the cynicism, but having attempted to participate in the process over the past few years, that’s the way it seems to me.

None-the-less, I’m trying again with these submissions. Many I’ve tried to get into Interop before, but all have fallen on deaf ears. They all refer to existing, stable CSS properties that have been documented as part of the spec for many years (in one case for 28 years!).

My asks are mostly typographic, as you might expect, but in some cases really important in that there are harmful implementations that need to be addressed. I’ve listed them in order of priority, based on severity, impact and age.

If you’d like to see browser makers agree to fix and implement any of these please click through to the Interop submission and voice your support (give it a thumbs up at least).

Required to stop the web sucking

font-variant-position

This is the most problematic as the lack of full support can make some text either misunderstood or incomprehensible. I’ve written about the issues before. The property tells browsers to choose proper OpenType subscript and/or superscript glyphs if they are available in the font. This works across the board, however only Firefox supports the most important part of the specification which says:

Because of the semantic nature of subscripts and superscripts, when the value [of font-variant-position] is either sub or super for a given contiguous run of text, if a variant glyph is not available for all the characters in the run, simulated glyphs should be synthesised for all characters using reduced forms of the glyphs that would be used without this feature applied.

What happens without supporting this part of the spec, is this is that the subscript and superscript glyphs are displayed as regular full size characters, thus you lose all the visual semantics provided by superscripts and subscripts.

For me, this is exactly the kind of thing that should be in Interop, as the current partial implementations make use of the property problematic to say the least.

Up-vote the Interop request for font-variant-position.

break-after: avoid

This one breaks my heart. It affects multicolumn layout and all EPUB ebooks (which use HTML & CSS, and include all ebooks not on a Kindle), as well as printed media.

As it stands browsers will happily render a heading at the bottom of a column or page, with the following paragraph starting on the next column or out of sight on the next page. This is a typographic no-no, and has been for  six centuries. Far better for the reader to have the heading attached to its paragraph on the next page, even if that means leaving some redundant whitespace in its place.

Since 1997(!) and the early drafts of CSS2, there has been an easy way to tell browsers not insert a page break directly after a heading:

h2 {
    page-break-after: avoid;
}

Nowadays the modern way to do that is defined in the CSS Fragmentation Module Level 3 even more simply as:

h2 {
    break-after: avoid;
}

This 28 year old bug (and counting) affects all of the millions of ebooks which have subheadings, and is only fixed in Chromium.

Up-vote the Interop request for break-after:avoid

Overdue implementation

Advanced hyphenation

There is more to setting hyphenation than just turning on the hyphens. The CSS Text Module Level 4 has introduced the same kind of hyphenation controls provided in the likes of InDesign and even Word. These controls provide different ways to define how much hyphenation occurs through your text.

While not a deal-breaker it would be great to see these in browsers, especially as the current implementations vary from non-existent to patchy or using deprecated properties.

Up-vote the Interop request for advanced hyphenation

Nice to have

Hanging punctuation

This particularly refers to the quote marks used with blockquotes and pull-quotes. When quotation marks appear at the beginning of a line they nudge the start of the text inwards, causing an unsightly gap and unevenness within the paragraph, which can make reading a slightly jerky experience. If you open a blockquote with a quotation mark, the first letter should be aligned with the first letter of all the other lines. To do so, you hang the opening quote mark by moving it into the margin or indent. For example:

One more attribute the modern typographer must have: the capacity for taking great pains with seemingly unimportant detail. To them, one typographical point must be as important as one inch, and they must harden their heart against the accusation of being too fussy.

But more than that, if the text is centred, the browsers should effectively ignore the presence of the opening and closing punctuation, and lay out the text as if the quote marks weren't present, and add them in afterwards. Similarly fully justified text (including the final line) should have the final quote hanging in the margin too.

The hanging-punctuation property makes that trivial to do so without resorting to negative margins, text indents and magic numbers. There is partial support in Safari, but only for opening quotes not closing ones.

Up-vote the Interop request for hanging punctuation

wrap-inside

This property addresses the situation where you have sequences of text whose lines you may want to break only at particular points, and preferably not at all. To achieve this currently, you may resort to inserting non-breaking spaces to keep text together, but this is a very manual and fragile approach. You could be introducing problems brought on by automated translation, or end up with text disappearing off the side of a screen.

By using wrap-inside:avoid you can try to prevent text in a phrase from wrapping. You can use this property on any inline element, that is to say a tag such as <em> or <span> that is used to mark up a phrase rather than a block of text like a paragraph.

Another typographic nicety, but one that removes manual intervention and fragility. Again, it would be handy to know it works across browsers (there’s no support currently).

Up-vote the Interop request for wrap-inside