Repository navigation
[css-sizing-4] Use cases for explicit intrinsic-size #4585
Description
This issue is to collect use cases for overriding the intrinsic size of an element with some other value. Branched off of #4531 (comment)
This issue is to collect use cases for overriding the intrinsic size of an element with some other value. Branched off of #4531 (comment)
Activity
chrishtr commentedon Dec 19, 2019
@dbaron @bfgeek
Quick reminder to add use cases you can think of.
chrishtr commentedon Jan 2, 2020
Second quick reminder. The plan of record is to review found use cases at the CSSWG meeting next week and use the results to choose the API shape for intrinsic-size in #4531 .
dbaron commentedon Jan 16, 2020
So Mozilla bug 433621 was filed to request such a property. It came from Mozilla bug 402567 which was about choosing different options for whether to pass intrinsic width up through scrollframes. This feature seemed to be requested specifically for tables in Mozilla bug 409736, and also in Mozilla bug 415533, which seems to be about the particular case of tables that vary in width but wish to clip/scroll the content of cells when they're wide, but still size to the content of those cells if they're narrow. These were also tied to Mozilla bug 407257 which was a layout bug in Firefox in GMail's contacts pane. A similar behavior was also explicitly requested by a developer in Mozilla bug 442330.
dbaron commentedon Jan 16, 2020
I'd note, however, that the scrollframes thing came up multiple times specifically because we changed behavior, so developers saw that multiple options were possible and wanted the ability to choose between them. I still think there are other usecases that exist but that people aren't raising because they don't see the possibilities.
cbiesinger commentedon Jan 23, 2020
So I think dbaron's use case is actually pretty different from what we want for the contain:size version of the property.
For contain-intrinisic-size, we want to be able to specify explicit lengths to apply while contain:size is present.
For dbaron's use case, you want 2-3 keywords to control how intrinsic sizes bubble upwards. Sort of, but perhaps not exactly, like the auto vs legacy keywords in the draft.
So I would propose:
These are pretty independent from each other and can be shipped separately.
Unfortunately I'll have to miss the discussion at tomorrow's f2f.
fantasai commentedon Sep 30, 2020
So far I'm seeing several desired behaviors:
None of these are explicit values, though, just different behaviors. So what we'd be looking at is a property with keyword values.
fantasai commentedon Oct 5, 2020
@jensimmons brought up an interesting use case around responsive typography, e.g. using variable axes to reduce the width of the text in the top row to match the size of a column whose width is dictated by the rest of its contents and not the content in the top row.
Looking deeper, however, this would be a case where dropping all the way down to zero isn't actually what we'd want: that would create overflow if the rest of the contents were too narrow and/or make the text unreadably narrow. So what's really desired in this case is to set the min-content size to a percentage of what it otherwise would be, e.g. if the text is 25% compressible without affecting readability, set the min-content size to 75% of what it otherwise would be. So another possibility we might consider is allowing the the min-content size property to take a percentage, which represents that percentage of what it otherwise would be. (Alternatively, maybe the min-content calculations can themselves account for the compressability. But just wanted to note the use case here for further thought.)
css-meeting-bot commentedon Oct 20, 2020
The CSS Working Group just discussed
Sizing.RESOLVED: Adopt a property to solve the requested property and values from issue 4585
The full IRC log of that discussion
<fantasai> Topic: Sizing<Rossen_> github:https://github.com//issues/4585
<fantasai> https://github.com//issues/4585#issuecomment-701595999
<tantek> Rossen_: who wants to summarize?
<tantek> fantasai: we created this issue to collect use-cases for the control over use-cases over intrinsic sizes of boxes
<tantek> ... we have 3 maybe 4
<tantek> ... one is webkit like behavior
<tantek> ... another is zeroing out the ... of scrolling containers
<cbiesinger> s/.../min-content contribution/
<tantek> ... another one is zeroing out the max content contribution when there is a zero size or max size in that axis
<cbiesinger> s/max content/min content/
<tantek> ... someone wanted to have a box that had the same behavior as a replaced element
<tantek> ... they were able to replicate a lot with our aspect ratio stuff
<tantek> ... but this is a quirk of how replaced elements behave
<Rossen_> q
<tantek> fantasai: q to wg, do we want to design a property to switch between these different values?
<tantek> ... q2 to wg, are there are other cases we should add to this
<tantek> Rossen_: opinions?
<fantasai> s/behave/behave that's unrelated to aspect ratios/
<tantek> (awkward silence)
<tantek> Rossen_: do we care enough about this? or we can also move on if there is not enough interest here
<tantek> ... there was interest here. in terms of behavior what do we want?
<tantek> ... dbaron also dumped a bunch of mozilla bugs that were a good indicator that we need to look into solving this
<tantek> ... i don't see anyone on the queue or engaging
<tantek> ... shall we close the issue with no change?
<tantek> cbiesinger: i would really like to have this property
<tantek> ... the second part was requested by me because I know some people who want to use this on their websites
<tantek> ... to set the min content to zero to act like replaced elements
<tantek> ... seems like useful behavior to get the regular size normally but when you shrink the window you can shrink the element with it
<tantek> ... that's my case for it
<tantek> fantasai: proposed resolution: define a property to switch between these behaviors and hope someone comes up with sensible keywords
<tantek> Rossen_: better than the ones currently in the issue
<tantek> jensimmons: I also think this is a really good idea
<tantek> ... I can see... it's sort of an advanced feature ... authors need to wrap their heads around sizing period. it requires understanding how layout works first.
<tantek> ... to me the big use-case is you have multiple grid items in a grid track, and the track itself is going to be based on something in the track, and you can say don't base it on the headline, base it on something else
<tantek> ... you set its intrinsic size to 0 or 100px
<tantek> ... that could be very powerful
<tantek> ... the columns will be the size of the content in it, except not this content or this content
<tantek> Rossen_: thank you. other opinions or objections to adopting such a property. name and value names tbd
<tantek> ... i see some nodding of heads
<tantek> ... no objections
<tantek> Rossen_: RESOLVED: Adopt a property to solve the requested property and values from issue 4585
[css-sizing-4] Add property to switch among behaviors for zeroing out…