Conversation
|
I think https://drafts.csswg.org/css-display-3/#transformations should say that blockifying causes the element to establish a new formatting context. Then there would be no need to explicitly say that e.g. flex items are both blockified and establish a new formatting context, the former would imply the later. Edit: filed #2598 |
|
@Loirooriol Could you file that as a separate issue? This is kind of related, but it seems to me to be an independent decision to make, so a separate issue seems better (also, this issue that this pull request is based on is already way too long). |
css-display-3/Overview.bs
Outdated
| without further precision as to the type of formatting context or how to do so. | ||
| This operation is not applicable to | ||
| non-atomic inline-level boxes | ||
| nor to boxes with a layout-internal display-type. |
There was a problem hiding this comment.
The correct terminology seems "display type" without hyphen. And I reiterate that display types should probably belong only to elements (and pseudo-elements), not boxes, but this problem is all over the spec.
… which (Follow up on 1457)
These specs used the "establish a [new] formatting context" terminology. Link to the exported definition now that there is one. This change is editorial. This is a follow up on w3c#1457
Grid and Flexbox used to need a sentence to say what kind of formatting context grid/flex items would establish. Since that is now part of the definition of "establishing a [new] formatting context", just link to it. This change is editorial.
instead of using correct-but-unique phrasing to do the same thing. This change is editorial.
|
We had to do some substantial rewriting on this, so closing this PR. (We'll link to it when we commit our results.) |
As discussed in the resolution of #1457 we should add to css-display a linkable definition for establishing a (new) formatting context without explicitely saying which kind, and still have the right thing happen unambiguously when possible, while being explicit that it is a spec bug to invoke this definition in the cases where it's not meaningful/possible.
This PR attempts to add this definition, and to update all the specs that should use it to do so.
I am not particularly attached to the phrasing I am proposing here. I believe it to be correct, but certainly welcome more elegant ways of saying the same thing if anyone has suggestions.
Review from @fantasai or @tabatkins (but particularly @fantasai) appreciated.
Changes in css-contain css-multicol css-align and css-rhythm should be particularly safe, since this is just adding a link without rephrasing anything.
Changes to the other specs are meant to be no-ops that merely unify the way we talk about this, without any normative effect.