You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
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.
@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).
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.