Skip to content
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

[css-sizing-4] Use cases for explicit intrinsic-size #4585

Closed
fantasai opened this issue Dec 11, 2019 · 8 comments
Closed

[css-sizing-4] Use cases for explicit intrinsic-size #4585

fantasai opened this issue Dec 11, 2019 · 8 comments

Comments

@fantasai
Copy link
Collaborator

This issue is to collect use cases for overriding the intrinsic size of an element with some other value. Branched off of #4531 (comment)

@chrishtr
Copy link
Contributor

@dbaron @bfgeek

Quick reminder to add use cases you can think of.

@chrishtr
Copy link
Contributor

chrishtr commented 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
Copy link
Member

dbaron commented 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
Copy link
Member

dbaron commented 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
Copy link

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
Copy link
Collaborator Author

fantasai commented 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
Copy link
Collaborator Author

fantasai commented 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
Copy link
Member

css-meeting-bot commented 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants