Skip to content

[css-contain-2] Clarify how sizing containment works #5643

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

Merged
merged 4 commits into from
Nov 11, 2020

Conversation

frivoal
Copy link
Collaborator

@frivoal frivoal commented Oct 21, 2020

This is not meant to change the expected behavior, however the original text was not very clearly phrased, hence this rewrite.

This is an attempt to solve #4931, along the lines of the so-called option α of #4931 (comment). It is currently written against level 2, but to be back ported to the L1 REC if we like it.

The diff is reasonably hard to read, so for ease of review, here's the resulting new section 3.1: http://files.florian.rivoal.net/css-contain-2/Overview.html#containment-size

Also note the commented out line in the source, which would allow us to let other specs opt into excluding some properties from the sizing as if empty phase, in order to do the so-called option β of #4931 (comment)

This is not meant to change the expected behavior,
however the original text was not very clearly phrased,
hence this rewrite.
@frivoal frivoal dismissed tabatkins’s stale review October 26, 2020 09:05

Applied the change requested, but github isn't noticing, so marking the review as stale.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-contain-2] Clarify how sizing containment works, and agreed to the following:

  • RESOLVED: Uncomment possibility of an exception and accept the PR
The full IRC log of that discussion <dael> Topic: [css-contain-2] Clarify how sizing containment works
<dael> github: https://github.com//pull/5643
<dael> florian: A while back Mats pointed out the text of size continanment wasn't clear. Phrasing was handwavy. Long discussion in github of how it could be interpreted and which is right.
<dael> florian: Made a PR which clarifies. Reviewed by fantasai and I think TabAtkins. Reasonably confident it's good
<dael> florian: There was a longer dicussion that maybe original intent wasn't right b/c possibility size containment was toward container queries and maybe wanted to ignore things like grid-track-sizing instead of treat grid as empty. That would make it nicer for when element quries are a thing.
<dael> florian: Sep GH about if container queries is possible here
<dael> florian: Could have css contain open a door for possible exceptions in other specs. size as if empty but we apply all properties unless stated otherwise in other specs.
<dael> florian: Specs like grid are further back in rec track so we don't consider it in css contain or we close the door now
<dael> florian: Expect for that I'm confident text is good. DIdn't get review from Mats unfortunately. Hard to read as a diff because a lot of red but there's a link to read
<dael> florian: Would like approval to merge unless comments
<dael> fantasai: contain 1 as well?
<dael> florian: Yes. Editorial compred to intent of spec. Editorial compared to text is debatable. But yes to get into L1
<dael> chrishtr: Does the PR make it any different from browser behavior?
<dael> florian: Nothing interop changes. corner cases about size containement to grid container with sized tracks which are different between FF and Chrome which would change
<dael> chrishtr: Are they ennumeratate?
<dael> florian: I know them and can write them down. I plan to write tests to expose details
<dael> astearns: Not currently any text?
<dael> s/text/test
<dael> florian: Tests that fail in FF and remain valid. Test are for original intent which was not clearly expressed
<dael> florian: Now it's more precise we can write more tests
<dael> astearns: Usually when we have an issue and decide on a fix we close and put needs test cases. Since this is a PR I'm worried someone looking for test cases wouldn't find it to write. I wonder if it would make sense to create an issues for testing where it enumerates the new cases
<dael> florian: I intend to write tests in a day or two of resolution, but I'm okay to have more
<dael> astearns: If that's the case then no need
<dael> astearns: Any other comments?
<dael> heycam: I can ping Mats but don't want to block
<dael> astearns: Prop: Accept the edits and create tests
<dael> florian: With open possibilities for other specs to exempt from the rules or close the door?
<dael> heycam: Always possible for specs to override?
<dael> florian: It's nicer to call it out, but even if we don't you can still do it
<dael> astearns: Since it's not clear we'll go ahead maybe leave it in as a we don't know yet
<dael> astearns: Other opinions?
<dael> astearns: PR has the exceptions can be made?
<dael> florian: Commented out. I need to un-comment
<dael> astearns: Prop: Uncomment possibility of an exception and accept the PR
<dael> astearns: Objections?
<dael> RESOLVED: Uncomment possibility of an exception and accept the PR
<dael> florian: Thank you

Normally, properties applied on a size-contained element itself do
affect the size of the element. There may be an interest in exempting
some properties, like grid track sizing properties, from that, but it is
currently undecided. For now, just spec the simple behavior without
exemptions, but allow exemptions in other specs to exist.
@tabatkins tabatkins merged commit b4ce42b into master Nov 11, 2020
@tabatkins tabatkins deleted the contain-4931-option-alpha branch November 11, 2020 23:38
@frivoal frivoal added Closed Accepted by CSSWG Resolution Tested Memory aid - issue has WPT tests labels Dec 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants