[css-text-3] The web de-facto requires NULL U+0000 to not be visible #6983

litherum · 2022-01-25T06:33:07Z

Chrome and Firefox make it invisible, and WebKit has compat issues about it.

https://bugs.webkit.org/show_bug.cgi?id=235559

Chrome and Firefox make it invisible, and WebKit has compat issues about it. https://bugs.webkit.org/show_bug.cgi?id=235559

https://bugs.webkit.org/show_bug.cgi?id=235559 <rdar://problem/87268956> Reviewed by Darin Adler. LayoutTests/imported/w3c: * web-platform-tests/html/canvas/element/drawing-text-to-the-canvas/null-character-expected.txt: Added. * web-platform-tests/html/canvas/element/drawing-text-to-the-canvas/null-character.html: Added. Source/WebCore: Chrome and Firefox render U+0000 NULL as invisible. We should do the same, despite it technically being classified as a control character. w3c/csswg-drafts#6983 Test: imported/w3c/web-platform-tests/html/canvas/element/drawing-text-to-the-canvas/null-character.html * platform/graphics/WidthIterator.cpp: (WebCore::WidthIterator::applyCSSVisibilityRules): Canonical link: https://commits.webkit.org/246392@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@288564 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=235559 <rdar://problem/87268956> Reviewed by Darin Adler. LayoutTests/imported/w3c: * web-platform-tests/html/canvas/element/drawing-text-to-the-canvas/null-character-expected.txt: Added. * web-platform-tests/html/canvas/element/drawing-text-to-the-canvas/null-character.html: Added. Source/WebCore: Chrome and Firefox render U+0000 NULL as invisible. We should do the same, despite it technically being classified as a control character. w3c/csswg-drafts#6983 Test: imported/w3c/web-platform-tests/html/canvas/element/drawing-text-to-the-canvas/null-character.html * platform/graphics/WidthIterator.cpp: (WebCore::WidthIterator::applyCSSVisibilityRules): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@288564 268f45cc-cd09-0410-ab3c-d52691b4dbfc

REGRESSION(r281419): iCloud.com Notes web app fonts render incorrectly https://bugs.webkit.org/show_bug.cgi?id=235559 <rdar://problem/87268956> Reviewed by Darin Adler. LayoutTests/imported/w3c: * web-platform-tests/html/canvas/element/drawing-text-to-the-canvas/null-character-expected.txt: Added. * web-platform-tests/html/canvas/element/drawing-text-to-the-canvas/null-character.html: Added. Source/WebCore: Chrome and Firefox render U+0000 NULL as invisible. We should do the same, despite it technically being classified as a control character. w3c/csswg-drafts#6983 Test: imported/w3c/web-platform-tests/html/canvas/element/drawing-text-to-the-canvas/null-character.html * platform/graphics/WidthIterator.cpp: (WebCore::WidthIterator::applyCSSVisibilityRules): Canonical link: https://commits.webkit.org/246392@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@288564 268f45cc-cd09-0410-ab3c-d52691b4dbfc Canonical link: https://commits.webkit.org/245886.126@safari-613-branch git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-613-branch@289306 268f45cc-cd09-0410-ab3c-d52691b4dbfc

css-meeting-bot · 2022-02-23T17:53:14Z

The CSS Working Group just discussed NULL must be visible for web-compat.

The full IRC log of that discussion

<TabAtkins> Topic: NULL must be visible for web-compat
<TabAtkins> github: https://github.com//pull/6983
<TabAtkins> florian: It's simple. Currently specs require every control character to be made visible. It turns out it's not web-compatible to make NULL visible. He requests we add this to the list of characters that can be invisible.
<TabAtkins> florian: Chrome and Firefox currently do that anyway.
<PeterC> What's the spec text that this proposal would impact?
<TabAtkins> florian: So to the extent that's true, I'd agree.
<TabAtkins> jfkthame_: I'd lik to see content that was affected; there doesn't appear to be examples in the webkit bug
<TabAtkins> smfr: Looks like it affected iCloud Notes
<TabAtkins> smfr: Not sure why a null character got in there
<TabAtkins> jfkthame_: It's not something we've discussed in Firefox, but I'd personally entertain making it visible in FF.
<TabAtkins> jfkthame_: Wonder if apply can't just fix iCloud if there's a problem there
<TabAtkins> jfkthame_: stray control characters in content are generally a bad thing; even worse if people can't tell they're there
<TabAtkins> astearns: That's why we had the resolution to make things visible
<TabAtkins> astearns: Has FF tried to make the other control characters visible?
<TabAtkins> jfkthame_: My recollection is we do at least on prerelease channels; unsure if we've turned it on in release. Think we've had trouble getting other browsers to line up.
<TabAtkins> astearns: Anyone from Blink have comments?
<TabAtkins> iank_: Will have to check with koji.
<TabAtkins> florian: I think there was a point in Blink where they were visible if there was a character in the font for them.
<florian> s/a character/a visible glyph/
<TabAtkins> astearns: I suggest we loop in koji or whoever else in Blink; jfkthame_ please check the state of the visible-chars code in Firefox; we'll see if there are any other compat concerns besides iCloud notes.
<TabAtkins> astearns: And we'll come back to this on a later call.
<florian> s/for them./for them, but as that's generally not the case, they were still invisible. Not sure if that got fixed./

bfgeek · 2022-02-23T17:53:47Z

@kojiishi - Can you describe what our current behaviour is here, and what we've done in the past?

kojiishi · 2022-02-24T14:59:51Z

Blink renders all characters in the DOM since crbug.com/530342. This caused crbug.com/550275, I have not identified why L-SEP U+2008 is visible only in Blink.

Blink doesn't do anything special to U+0000 either, but also doesn't do anything special to make sure it's visible when calling the underlying HarfBuzz or platform APIs, so it's possible that the behavior is platform and/or API dependent; i.e., if the platform API requires C-style string, it may disappear.

From a quick test, DOM and canvas measureText render U+0000 on Win10, but they don't render on mac.
https://output.jsbin.com/nuqate
I have not investigated where this difference comes from, fonts or code, yet.

jfkthame · 2022-02-25T12:54:32Z

Firefox has an about:config setting layout.css.control-characters.visible that controls whether control characters are rendered visibly. Currently, this is enabled in Nightly builds, but disabled for the Beta and Release channels.

When layout.css.control-characters.visible is set to true, U+0000 is rendered as a visible "hexbox" glyph just like other control characters. I'm not aware of any reports of this being noticed in the wild (as has occasionally happened for other control codes), though perhaps shipping it more widely will unearth a few cases.

jfkthame · 2022-02-25T13:00:52Z

Blink renders all characters in the DOM since crbug.com/530342.

Note that (if I'm understanding correctly) Blink simply passes the control characters through the same rendering pipeline as printable characters, so the result may be visible or not depending on the particular font being used. Some fonts map control-character codepoints to invisible glyphs, and in this case they'll remain invisible in Blink, while other fonts may render a .notdef box or even some other graphical representation.

This is not consistent with the CSS Text requirement, which says:

Control characters (Unicode category Cc)—other than tabs (U+0009), line feeds (U+000A), carriage returns (U+000D) and sequences that form a segment break—must be rendered as a visible glyph which the UA must synthesize if the glyphs found in the font are not visible

jfkthame · 2022-02-25T16:56:54Z

@litherum Can you clarify what the compat concern here is about? I've tried signing in to iCloud Notes using Firefox Nightly, where the layout.css.control-characters.visible setting is true (and so any occurrences of U+0000 would appear as hexbox glyphs), but I didn't notice anything untoward. Is there a specific scenario to look at?

litherum · 2022-02-25T18:19:25Z

This came up because the Notes app on iCloud.com assumes that .notdef is invisible and has zero width. I’m assuming this one website is not the only one.

jfkthame · 2022-02-25T18:23:18Z

This came up because the Notes app on iCloud.com assumes that .notdef is invisible and has zero width. I’m assuming this one website is not the only one.

But where/why does the Notes app try to render .notdef? Isn't that just a bug in the iCloud Notes app?

kojiishi · 2022-03-01T07:57:27Z

@jfkthame

Note that (if I'm understanding correctly) Blink simply passes the control characters through the same rendering pipeline as printable characters, so the result may be visible or not depending on the particular font being used. Some fonts map control-character codepoints to invisible glyphs, and in this case they'll remain invisible in Blink, while other fonts may render a .notdef box or even some other graphical representation.

Correct. Blink has not implemented that part yet, so mac users do not complain about visible L-SEP (crbug.com/550275) until we implement it.

@litherum

This came up because the Notes app on iCloud.com assumes that .notdef is invisible and has zero width. I’m assuming this one website is not the only one.

While Blink does not check U+0000, it does check glyph 0, so maybe that's what you observed in icloud.com? The glyph id 0 is .notdef as long as the font follows the Recommendations for OpenType Fonts. Blink has some places that assume all fonts follow this recommendation, such as here.

fantasai

r- until this is resolved by the WG (and also any such change needs to go into css-text-4 as well). Opened #7249 to track it as an issue.

fantasai · 2022-12-28T03:14:36Z

CSSWG rejected this change, see minutes: https://lists.w3.org/Archives/Public/www-style/2022May/0009.html
Closing out.

[css-text-3] The web de-fact requires NULL U+0000 to not be visible

175519a

Chrome and Firefox make it invisible, and WebKit has compat issues about it. https://bugs.webkit.org/show_bug.cgi?id=235559

litherum requested review from frivoal, fantasai and kojiishi January 25, 2022 06:33

litherum changed the title ~~[css-text-3] The web de-fact requires NULL U+0000 to not be visible~~ [css-text-3] The web de-facto requires NULL U+0000 to not be visible Jan 25, 2022

frivoal added Agenda+ css-text-3 Current Work labels Jan 31, 2022

astearns removed the Agenda+ label Feb 23, 2022

fantasai mentioned this pull request May 4, 2022

[css-text-3] Make U+0000 invisible? #7249

Closed

fantasai requested changes May 4, 2022

View reviewed changes

fantasai closed this Dec 28, 2022

frivoal added Closed Rejected as Wontfix by CSSWG Resolution Testing Unnecessary Memory aid - issue doesn't require tests labels Dec 28, 2022

fujii mentioned this pull request Apr 15, 2024

ComplexTextController: Control characters should be rendered as visible glyphs WebKit/WebKit#26668

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-text-3] The web de-facto requires NULL U+0000 to not be visible #6983

[css-text-3] The web de-facto requires NULL U+0000 to not be visible #6983

litherum commented Jan 25, 2022

css-meeting-bot commented Feb 23, 2022

bfgeek commented Feb 23, 2022

kojiishi commented Feb 24, 2022 •

edited

Loading

jfkthame commented Feb 25, 2022

jfkthame commented Feb 25, 2022

jfkthame commented Feb 25, 2022

litherum commented Feb 25, 2022 •

edited

Loading

jfkthame commented Feb 25, 2022

kojiishi commented Mar 1, 2022

fantasai left a comment

fantasai commented Dec 28, 2022

[css-text-3] The web de-facto requires NULL U+0000 to not be visible #6983

[css-text-3] The web de-facto requires NULL U+0000 to not be visible #6983

Conversation

litherum commented Jan 25, 2022

css-meeting-bot commented Feb 23, 2022

bfgeek commented Feb 23, 2022

kojiishi commented Feb 24, 2022 • edited Loading

jfkthame commented Feb 25, 2022

jfkthame commented Feb 25, 2022

jfkthame commented Feb 25, 2022

litherum commented Feb 25, 2022 • edited Loading

jfkthame commented Feb 25, 2022

kojiishi commented Mar 1, 2022

fantasai left a comment

Choose a reason for hiding this comment

fantasai commented Dec 28, 2022

kojiishi commented Feb 24, 2022 •

edited

Loading

litherum commented Feb 25, 2022 •

edited

Loading