Repository navigation
[css-text-3] Make U+0000 invisible? #7249
Description
Chrome and Firefox make it invisible, and WebKit has compat issues about it.
https://bugs.webkit.org/show_bug.cgi?id=235559
See discussion in that pull request. Opening this issue to track the discussion and
- confirm implementation plans for handling control characters generally
- figure out what we want to do about U+0000 specifically
- figure out if we need any kind of coordinated release of these behaviors
Activity
[-][css-text-3] Make U+0000 invisible[/-][+][css-text-3] Make U+0000 invisible?[/+]jfkthame commentedon May 6, 2022
To clarify a bit: Chrome (if I understand correctly) just passes the codepoint through to the current font, so it may be invisible or render as tofu depending on the font in use.
Firefox makes it invisible in Release/Beta versions, as the
layout.css.control-characters.visiblesetting defaults tofalse, but renders it as a hexbox glyph in Nightly builds as the pref defaults totruethere. (See https://searchfox.org/mozilla-central/rev/4274cdc16531e42b061d3091e0d146a62ff63b9b/modules/libpref/init/StaticPrefList.yaml#7516-7521.)I don't think there is any compelling reason to treat U+0000 any differently from other "spurious" control characters; they should all be rendered visible, as per CSS WG resolution. Depending on the current font (as Chrome currently does) is not a robust implementation approach.
css-meeting-bot commentedon May 25, 2022
The CSS Working Group just discussed
U+0000 invisible?, and agreed to the following:RESOLVED: No changeThe full IRC log of that discussion
<TabAtkins> Topic: U+0000 invisible?<TabAtkins> github: https://github.com//issues/7249
<TabAtkins> fantasai: Do we have Myles and jfkthame on the call?
<TabAtkins> astearns: Have jfkthame, not Mayles
<TabAtkins> smfr: Can probably speak for Myles
<TabAtkins> astearns: So we had previous resolution to amke all the CC characters visible
<TabAtkins> smfr: We had an issue on one Apple website, the text had U+0000 bytes in it
<TabAtkins> smfr: I'm guessing it's not *that* uncommon to have 0 bytes by mistake, due to server bugs? But we'd probably be okay with no change.
<TabAtkins> astearns: So you're suggesting close no change, and continue to specify they're displayed?
<TabAtkins> smfr: Think that's okay unless we have evidence the problem is more widespread.
<TabAtkins> emilio: I don't recall seeing issues with this in Nightly/Beta and we've had it for a long time
<TabAtkins> jfkthame: Also think we should ship it. Do occasionally see characters show up in Nightly that are invisible elsewhere, but it's rare.
<TabAtkins> jfkthame: And in all cases the users are better served by sites fixing their broken data
<TabAtkins> fantasai: We'd previously discussed doing a coordinated ship of this behavior - that was years ago, guess this didn't happen?
<TabAtkins> florian: Think we prepped coord but didn't pull the trigger.
<TabAtkins> florian: Firefox impl'd, Chrome impl'd partially (but leaves it to the font to render), Safari didn't impl.
<TabAtkins> astearns: But I think we can agree to resolve on this issue.
<TabAtkins> astearns: Any objections to no change on rendering of U+0000?
<TabAtkins> RESOLVED: No change
<TabAtkins> astearns: What can we do to coordinate making this part of the spec interoperable?
<TabAtkins> jfkthame: Think we need Blink to fix impl to not depend on the font's rendering.
<TabAtkins> astearns: Do we know if there's a blink issue?
<TabAtkins> jfkthame: There is, don't have it offhand
<fantasai> Maybe send that issue link to chrishtr and he can coordinate?
<TabAtkins> astearns: Suggest we find the issue number and post it here, see if we can get a response from Blink engineers
<TabAtkins> Yes, chrishtr is the right contact for coordinating this
<TabAtkins> smfr: We might be in a similar situation to Blink where it depends on the font, not sure
<TabAtkins> smfr: But this seems rare eough that I don't think coordinating shipping is necessary, seems hard to do for us in WebKit anyway
<TabAtkins> fantasai: I think we should open a separat eissue for the coordination
<TabAtkins> astearns: So we can close this issue witht he resolution we got, and continue coordination discussion later on.