"ou" is fine too, actually. See the proposal p. 14 (=16 in the PDF): https://www.bunka.go.jp/seisaku/bunkashingikai/sokai/pdf/942...

(To differentiate between the case where it's actually two vowels, you have to put an apostrophe inbetween; their example is 小唄 -> ko'uta.)

The "other standard" in this case being IBM-944. (At least looking at https://www.unicode.org/versions/Unicode1.0.0/ch06.pdf p. 574 (=110 in the PDF) I only see a mapping from U+212A to that one.)

The ICU mappings files have entries for U212A in the following files:

    gb18030.ucm
    ibm-1364_P110-2007.ucm
    ibm-1390_P110-2003.ucm
    ibm-1399_P110-2003.ucm
    ibm-16684_P110-2003.ucm
    ibm-933_P110-1995.ucm
    ibm-949_P110-1999.ucm
    ibm-949_P11A-1999.ucm

w3m doesn't support chafa for inline image display.

(You can set a custom w3mimgdisplay command, but it has to speak the same protocol as w3mimgdisplay. If you're feeling adventurous, you can try modifying https://github.com/uobikiemukot/sdump/tree/master/yaimg-sixe....)

> which aren't just free to use, but explicitly use the modern SIL Open Font License.

Unifont is also dual-licensed under GPLv2/SIL OFL.

> It would also be nice to have something like `default-styles: none` so I don't have to deal with browsers having differing defaults.

This already exists:

    *, ::before, ::after { all: unset }

The greatest mistake IMO is the way float state leaks out of blocks, as this is both extremely unintuitive and undesirable for performance reasons.[1] Floats should've been restricted to inline formatting contexts, with all in-flow blocks behaving as if they had `clear: both' set.

I also don't understand why they never specced the (much simpler) `text-align: -moz-left/-moz-right/-moz-center' which already had precedent in HTML with `<div align=left/right/center>'. It's the saddest part of the "center a div" saga, all the W3C had to do to fix it is to assign a standard keyword to a feature that everybody already implemented, but to this day it still hasn't happened.[2]

[1]: https://pcwalton.github.io/_posts/2014-02-25-revamped-parall...

[2]: After many long decades, they did finally specify block-level `justify-items'. Two problems: a) it's backwards-incompatible with text-align, b) it still doesn't work in Gecko.

I actually wonder if transpiling calc/min/max/etc. expressions to JS is a viable path to implementation, considering that you already need a fast interpreter for these.

> just new ones that no automation depends on

Except for automations that happen to create new repositories.

> Rendering Markdown is relatively simple

Markdown is a superset of HTML, so your assertion cannot be true. But even an HTML-less subset is very hard to parse efficiently (or, at all) because of the various grammatical ambiguities. And then there's the various competing definitions...

> And then there's the various competing definitions...

Someone always bring this up whenever a permutation of this thread comes up, but I don't see the problem. You choose a definition and make that the spec. Even Hacker News only supports a very limited subset of Markdown.

Popular browsers support tabs. When you have many tabs open, it's hard to show a meaningful title for each one. An icon takes up less place and is easier to scan for visually.

Mozilla Firefox doesn't shrink tabs any further, but instead lets the tab list go off screen and you can scroll. I think that is a Google Chrome specific thing.

I've just tried and when I open a bunch of new tabs, Firefox truncates the "new tab" text to "new" and a Firefox logo. Same thing happens with other titles.

(Then at some point it stops truncating and scrolls off the screen.)

That's true, it's more without the favicon. It is configurable with browser.tabs.tabMinWidth. Not sure if it is configurable elsewhere in the UI, I normally don't bother with that.