PR Request for CSS Box Model Level 3

[fantasai]

Document title, URLs, estimated publication date

https://www.w3.org/TR/css-box-3/
https://drafts.csswg.org/css-box-3/
At your convenience

Abstract

https://www.w3.org/TR/css-box-3/#abstract

Status

CR

Will new features be allowed to be incorporated in the Recommendation?

No

Link to group's decision to request transition

https://lists.w3.org/Archives/Public/www-style/2022Oct/0022.html

Changes

Only editorial (mostly markup)

Requirements satisfied

yes

Dependencies met (or not)

CSS2, CSS Writing Modes L3

Wide Review

#300

Issues addressed

None

Formal Objections

None

Implementation

All browser engines, as proven in the CSS2 and CSS Writing Modes L3 test suites.

Patent disclosures

None

[swickr]

What is the resolution of the 'at risk' features? They appear to be retained; what tests demonstrate they have been implemented as specified?

[fantasai]

@swickr Hm, we're in an interesting bit of dependency here:

• The ruby spec, which is less mature, defines some new types of boxes.
• Like internal table boxes, and unlike most CSS boxes, some of these new ruby layout boxes don't have margins or padding.
• The margin/padding property definitions, which otherwise say margin/padding applies to “all” CSS boxes, were updated to specifically exclude these boxes.

We have two choices here:

• Keep the spec as-is
• Remove any mention of ruby layout boxes from the spec to remove the dependency; but then since margin/padding are defined to “all” boxes, there would be an implication that they apply to these particular ruby boxes.

I suspect the former would be more helpful to developers; the latter would remove any dependency on the Ruby Module. What would you prefer we do here?

[swickr]

I understand that the interpretation of "at risk" here is not whether the properties do apply but whether they should apply once ruby containers are fully specified.

If the intent of the spec is that the properties should be ignored when applied to ruby containers then there could be tests that demonstrate which implementations do (or do not) ignore.

If this interpretation is correct then I would be comfortable leaving the "applies to ... except" language in the spec with tests that show what implementations are actually doing. And consider adding an editorial note where the properties are defined stating that the behavior w.r.t ruby containers may change in the future.

We found propdef-margin that look applicable.

In any case, the "at risk" language in SoTD is no longer appropriate at Proposed Recommendation stage.

Separately, the Proposed Rec seems to want to refer to several Working Drafts. Other than Ruby, what risks to CSS Box Model Level 3 spec are there if those dependent specs change?

[fantasai]

@swickr Here's a testcase. Note that it only makes sense in Firefox, because the other browsers don't support ruby text containers / ruby base containers at all.

So I think we've got two options here:

• commit the testcase to WPT, and add a note that behavior might change
• remove the normative statement about ruby boxes, add a note stating that behavior for ruby layout is undefined in this level

Maybe the second is cleaner?

Wrt references, all of them can be downgraded as necessary. They're mostly just pulling basic CSS terminology from the latest version of the module that defines it.

[plehegar]

The second approach is cleaner indeed.

Assuming the normative text are removed, respective note(s) is/are added, and the SOTD 'at-risk' paragraph is also removed, the transition is approved.

[svgeesus]

@fantasai could you summarize where we are on this. Is it ready to be published now?

[fantasai]

@svgeesus Edits made, over to you. :)

[svgeesus]

Publication requested 14 Feb expected 16 Feb

[svgeesus]

Published 16 Feb 2023