- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Jan 2020 16:59:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `intrinsic-size`, and agreed to the following:
* `RESOLVED: add a property called contain-intrinsic-size`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> Topic: intrinsic-size<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4531<br>
<emilio> ScribeNick: emilio<br>
<emilio> chrishtr: in december we discussed and concluded that if we couldn't find other use cases we should add a property specific to the size-contained case<br>
<emilio> ... since then dbaron has come up with some use-cases related to scrolling<br>
<emilio> ... so now the question is what to do with this information<br>
<emilio> ... whether adding two separate properties (which I'd recommend), or just one<br>
<emilio> dbaron: I would've preferred one property, but if you found a decent name for the contain-specific one I'm ok with two<br>
<emilio> astearns: what's the name of that?<br>
<emilio> chrishtr: contain-intrinsic-size, credit to fantasai<br>
<fantasai> If there are two properties, what's the interaction?<br>
<emilio> TabAtkins: none or two lengths<br>
<emilio> (or one)<br>
<fantasai> should be a shorthand for the various sizing longhands<br>
<emilio> TabAtkins: re. interaction: This only interact iff the element is size-contained<br>
<fantasai> right, but that could happen<br>
<emilio> ... so I think the most consistent behavior would be that the contain-specific one wins, as contain: size already prevents a lot of other sizing-related calculations<br>
<fantasai> it doesn't prevent 'width' and 'height' from doing things<br>
<emilio> astearns: fantasai also asked about it being a shorthand for the sizing props<br>
<fantasai> so I'm not convinced about that<br>
<emilio> TabAtkins: definitely disagree with it being a shorthand<br>
<fantasai> e.g. contain-intrinsic-width<br>
<TabAtkins> specifically, since our use-cases want the "general" to do things like cause scrollbars, which is similar to it having a big child, and contain:size alreayd ignores children, I think it's most consistent to have contain:size cause that to be ignored.<br>
<emilio> TabAtkins: ah, ok, sure...<br>
<fantasai> ?<br>
<emilio> fantasai: (about the shorthand thing)<br>
<smfr> do we need contain-intrinsic-aspect-ratio too?<br>
<emilio> dbaron: do we also want logical versions?<br>
<fantasai> smfr, no<br>
<emilio> TabAtkins: I guess so, we'd all all of them<br>
<fantasai> smfr, aspect-ratio already exists, why would we need contain-intrinsic-aspect-ratio?<br>
<emilio> chrishtr: what happens if you only specify one of them? The current proposal doesn't allow that<br>
<emilio> Rossen: auto?<br>
<emilio> TabAtkins: there's no auto<br>
<fantasai> chrishtr, same in that dimension as if you didn't specify the property?<br>
<emilio> TabAtkins: given we need 4 longhands and such, can we skip it for now and see if it's necessary later?<br>
<emilio> chrishtr: I don't see downsides with that<br>
<fantasai> as long as the shorthand is consistent with the size shorthand ...<br>
<fantasai> which we still don't have<br>
<emilio> TabAtkins: we have good behavior turning something into a longhand later<br>
<emilio> into a shorthand*<br>
<fantasai> There's also an issue around what order the values go in, if there are two of them<br>
<emilio> astearns: issues, concerns?<br>
<TabAtkins> fantasai, yes, I imagine it'll be consistent.<br>
<fantasai> @page { size: width height; } is currently the order there<br>
<TabAtkins> fantasai: and yes indeed, we'll discuss which order to put the things in<br>
<fantasai> which puts us inconsistent with grid shorthand and alignment ...<br>
<emilio> RESOLVED: add a property called contain-intrinsic-size<br>
<fantasai> which is a mess, because we didn't listen to bradkemper<br>
<chris_> rrsagent, here<br>
<RRSAgent> See https://www.w3.org/2020/01/24-css-irc#T16-55-26<br>
<emilio> TabAtkins: we should try to decide the order between the values<br>
<emilio> ... I think we should do block/inline<br>
<fantasai> I think we should do width/height<br>
<fantasai> because all of our shorthands are physical<br>
<fantasai> because 'size' is already physical in paged media<br>
<fantasai> and it's width/height<br>
<fantasai> and physical shorthands with two axes are width/height<br>
<fantasai> not height/width<br>
<emilio> emilio: I think I agree with fantasai<br>
<emilio> TabAtkins: we're going to be inconsistent with some amount of properties regardless<br>
<emilio> ... because we have examples of both<br>
<fantasai> Not really<br>
<fantasai> Everything with physical longhands is consistent<br>
<fantasai> everything that doesn't is consistent<br>
<fantasai> the two sets are inconsistent<br>
<fantasai> and size has physical longhands<br>
<fantasai> so it goes in the first category<br>
<emilio> TabAtkins: we can defer this to the next meeting and discuss in the issue with now<br>
<emilio> emilio: should we discuss now the other use cases that dbaron brought?<br>
<emilio> TabAtkins: if dbaron wants, sure<br>
<fantasai> My 2nd worst mistake in CSS is definitely the ordering of the grid shorthand<br>
<emilio> dbaron: not sure we need to right now<br>
<emilio> TabAtkins: ok, we mostly wanted to see whether these concepts were separable<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4531#issuecomment-578214122 using your GitHub account
Received on Friday, 24 January 2020 16:59:52 UTC