-
Notifications
You must be signed in to change notification settings - Fork 641
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
Comments
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 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. |
The CSS Working Group just discussed
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. |
In #6983 @litherum writes:
See discussion in that pull request. Opening this issue to track the discussion and
The text was updated successfully, but these errors were encountered: