Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
fantasai opened this issue May 4, 2022 · 2 comments
Closed

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

fantasai opened this issue May 4, 2022 · 2 comments
Labels

Comments

@fantasai
Copy link
Collaborator

fantasai commented May 4, 2022

In #6983 @litherum writes:

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
@fantasai fantasai changed the title [css-text-3] Make U+0000 invisible [css-text-3] Make U+0000 invisible? May 4, 2022
@jfkthame
Copy link
Contributor

jfkthame commented May 6, 2022

Chrome and Firefox make it invisible

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.visible setting defaults to false, but renders it as a hexbox glyph in Nightly builds as the pref defaults to true there. (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
Copy link
Member

The CSS Working Group just discussed U+0000 invisible?, and agreed to the following:

  • RESOLVED: No change
The 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants