#581: Formal Review Request for CSS Text Level 3

Visit on Github.

Opened Dec 3, 2020

HIQaH! QaH! TAG!

I'm requesting a TAG review of CSS Text Level 3. This CSS module defines properties for text manipulation and specifies their processing model. It covers line breaking, justification and alignment, white space handling, and text transformation.

Further details:

  • [on my todo list, but I read the CSS part] I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: <br> Would be really nice to have this transition to CR before the end of year moratorium, given we actually managed to hit zero open issues for the first time since 2002...
  • The group where the work on this specification is currently being done: CSSWG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSSWG
  • Major unresolved issues with or opposition to this specification: None
  • This work is being funded by: W3C, Microsoft, Mozilla, HP, EAST Japan, Opera Software, Bloomberg, Google, Apple, probably forgot some others.

You should also know that this specification is the product of existing features in CSS2, proprietary features that shipped in IE and WebKit, i18n needs, and an attempt to keep it all as coherent as possible given those constraints.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

Discussed Dec 7, 2020 (See Github)

Elika: Internationalisation and accessibility implications.

... text transformation may have accessibility implications. Accessibility group signed off. Transformed text to AT or not?

... Justification may make things hard to read; CSS3 adds a new value to turn it off, without affecting ability to align text left and right.

... how we handle whitespace and control characters may be of interest here, as well as privacy and security

... whitespace processing and control codes probably most relevant for TAG in terms of interactions

Peter: none of the properties and values make sense, for historical reasons :(

Elika: It's taken a lot of effort to make it makes sense. Florian's video, linked from the issue, goes into it.

... TAG's review is the last step before CR transition.

Comment by @fantasai Dec 14, 2020 (See Github)

Since we're down to only a few editorial issues, I'm planning to request permission from the CSSWG to transition this specification to CR this week. If the TAG would like to prevent that transition, please let me know. We will of course continue to process issues raised during CR. CC @plinss @torgo

Comment by @plinss Dec 14, 2020 (See Github)

The TAG is in recess through the end of the year, but has no objection to CSS Text Level 3 transitioning to CR at this time.

We'll be taking a deeper look in the future, but will file issues as we find them.

Discussed Jan 1, 2021 (See Github)

Rossen: was a previous discussion at a face-to-face, which Elika joined. We asked her to list concerns, she talked about things that could be improved... so we didn't sign off then. I'm not concerned with anything here.

Rossen: I'd be comfortable proposing to close this one.

David: One interesting thing in here is auto-hyphenation requiring authors to specify the content language. I wonder if this is something that the spec should require in other places, or something that should be more visible.

David: ... but I'm fine with proposing to close this.

https://github.com/w3ctag/design-reviews/issues/581#issuecomment-767211799

Comment by @dbaron Jan 26, 2021 (See Github)

@atanassov and I just discussed this in a breakout. I think we're both fine with closing this; this spec has already gotten a lot of review.

One thing I was thinking about is that one interesting thing in here is that auto hyphenation doesn't work if the page doesn't specify the content language. I think this is good -- it's probably good that heavily language-dependent features don't depend on UAs using heuristics to guess the content's language. But this made me wonder two things: first, whether this is something that should be done for any other language-dependent features, and second, whether it's something that should be a tiny bit more visible in the specification (or maybe elsewhere). (@atanassov wonders if we have a list of such language-dependent features.)

Comment by @dbaron Jan 26, 2021 (See Github)

We discussed this in our mini-plenary during our virtual face-to-face meeting and agreed to close. There are a number of folks on the TAG who have already reviewed this spec at other points in its development and we didn't think it needed additional review from the TAG as part of its CR phase.

(See also w3ctag/design-principles#266 which was filed based on the discussion of my previous comment.)