In bug 1099557, we implemented visible (hexbox) rendering for spurious control characters in content, but because other browsers were not yet ready to ship this behavior, we put it behind a pref (layout.css.control-characters.visible) which defaults to false on beta/release. So currently the characters are visible (correct behavior per CSS) on Nightly/Aurora, to help raise webdev/author awareness of where they're occurring, but are hidden on Beta/Release to avoid annoying users. According to https://mobile.twitter.com/RickByers/status/818211518680539138 this will be appearing in Chrome 56 shortly; and it's in Edge behind a flag (https://mobile.twitter.com/gregwhitworth/status/817225600817430530). With Chrome 56 shipping this change, I think it's time for us to also flip the pref on beta/release and expose this to the world.

Hmm, despite the RickByers note mentioned above, I just looked and I'm _not_ seeing control chars made visible in Chrome 56 beta or Canary on macOS. So we should check what the status really is before we move ahead here.

According to Koji, Chrome has shipped this change since 56, like what was mentioned in comment 0, and I can confirm that it at least shows up in my local Chrome 62 stable. This is the test page I'm using. Except that Chrome renders an empty square while Firefox renders hex inside, the behavior seems to be identical otherwise.

Which platform are you on? Could you attach a screenshot, please? Your test page displays completely blank for me in Chrome 62.0.3202.94 on macOS 10.12....

It is Chrome 62.0.3202.94 on Windows 10.

And... yeah it seems that this doesn't work on macOS. My Chrome install on macOS 10.12 doesn't show anything either.

Nor does my Chrome on Linux. I think what you're seeing may be that they are simply passing the characters through to the rendering system and drawing whatever the current font offers, which on Windows turns out to be ".notdef" glyph boxes, but could be zero-width invisible glyphs or blank spaces or whatever happens to be in the font. That doesn't seem a very satisfactory implementation to me.

I've copied your comment to w3c/csswg-drafts#1990.

Hmm, turns out my Chrome on Linux was pretty old, so not a fair test. I tried downloading the latest stable, though, and now it just fails to launch for me..... so I'm not sure what the status actually is there.

Aha, I got the new Chrome running on Linux, and now I see boxes similar to your Windows screenshot. And proof (or something like it) that all they're doing is "rendering" the control characters as if they were printable chars is provided by setting font-family:NanumGothic on your testcase, which (with the fonts on my Ubuntu system, at least) makes them all disappear (although they still occupy space), because NanumGothic has whitespace glyphs for those codepoints.

Just to follow up, Koji confirmed in https://github.com/w3c/csswg-drafts/issues/1990#issuecomment-347256752 that Blink has not yet implemented this in the intended manner; they're just painting whatever glyph the font happens to provide for the given character code (often .notdef, which is most commonly a box of some kind, but may be blank, or some other more arbitrary graphic -- I've seen occasional fonts with "dingbat-like" .notdef glyphs).