- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Mar 2025 16:56:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] Adding a 'size' shorthand for 'width'/'height'`, and agreed to the following: * `RESOLVED: Add a 'size' shorthand property (for 'width'/'height'), no relation to @page's 'size' descriptor` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fantasai: wow this was old.<br> <TabAtkins> fantasai: not clear what to do here, but people want it solved<br> <TabAtkins> fantasai: complication is there's an existing size proeprty in @page rules<br> <TabAtkins> fantasai: and it's not equivalent to setting width/height<br> <TabAtkins> fantasai: width/height apply to the page area<br> <TabAtkins> fantasai: this is implemented by PDF renderers<br> <TabAtkins> fantasai: added this after chatting with emilio, who suggested maybe we just treat 'size' in @page specially, so they set a different size property, while everywhere else it's a shorthand<br> <oriol> q+<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/820#issuecomment-810626883<br> <TabAtkins> fantasai: so wanted to know if it's viable<br> <ntim> i like the idea<br> <TabAtkins> astearns: seems a little icky to have different processing based on where 'size' comes up<br> <JoshT> q+<br> <TabAtkins> astearns: but maybe in this case its' reasonable<br> <emilio> q+<br> <TabAtkins> (I think there's not really any better solution. Also slightly icked but okay with it for the benefit.)<br> <astearns> ack oriol<br> <TabAtkins> florian: Yeah, unfortunate, but since the weirdness is so scoped it's probaqbly okay<br> <TabAtkins> oriol: in @page, it has descriptors not properties<br> <JoshT> q- Was going to make the same point<br> <TabAtkins> oriol: so a name conflict isn't *great* but not a big deal technically. can just say that 'size' descriptor and 'size' shorthand are different<br> <JoshT> q-<br> <astearns> ack emilio<br> <ntim> q+<br> <TabAtkins> emilio: i think this is the onlyw ay to make it work<br> <TabAtkins> emilio: but maybe it could be cool to make 'size' in @page a legacy alias for some other name, like 'page-size'?<br> <TabAtkins> emilio: that would be easier to implement, I think, then I don't need to deal with the name conflict as much.<br> <florian> +1<br> <TabAtkins> emilio: and maybe less confusing long term<br> <TabAtkins> astearns: do you have a mechanism to only apply an alias in one at-rule context?<br> <TabAtkins> emilio: yes, easily<br> <TabAtkins> emilio: just within the @page descriptor, if descriptor name is 'size' return 'page-size'<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to reply to emilio<br> <ntim> p+<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/820#issuecomment-544582026<br> <TabAtkins> fantasai: we'd previously resolved to make it an alias and have page-size be the name<br> <TabAtkins> fantasai: response we got was some products support JS and 'size' has been supported as long as PDF renderers have existed<br> <TabAtkins> fantasai: so we could do aliasing, but would have to make sure it doesn't break CSSOM<br> <TabAtkins> emilio: yeah, aliases already work nicely for that<br> <astearns> ack ntim<br> <TabAtkins> ntim: any usage data on 'size'? i guess elika has answered the question<br> <TabAtkins> ntim: any browser have data?<br> <TabAtkins> fantasai: primary usage isn't in browsers, it's in pdf renderers. so big market difference in both content and userbase<br> <TabAtkins> emilio: i think browsers do support 'size' in printing, it's fairly used<br> <TabAtkins> iank_: yeah people generate PDFs from brwosers all the time, and do use the 'size' descriptor<br> <TabAtkins> iank_: so the markets are acteually pretty overlapping<br> <TabAtkins> florian: and epub readers too<br> <TabAtkins> florian: at least notionally, interactive pages user agents<br> <TabAtkins> ntim: common on web sites tho?<br> <TabAtkins> florian: when you print a web site, yeah, reasonably<br> <TabAtkins> iank_: very common in enterprise use-cases to have printable pages<br> <TabAtkins> iank_: and they use @page on those<br> <fantasai> https://www.w3.org/TR/css-cascade-5/#aliasing<br> <TabAtkins> ntim: i ask because in webkit, @page is pretty poorly maintained and we haven't seen many bug reports<br> <TabAtkins> iank_: I suspect we have the best support among browsers here, and enterprises are just targetting Chrome for printing webapps<br> <TabAtkins> astearns: so proposed resolution is we add 'size' shorthand proeprty that has nothing to do with '@page/size'<br> <TabAtkins> astearns: concerns?<br> <TabAtkins> RESOLVED: Add a 'size' shorthand property (for 'width'/'height'), no relation to @page's 'size' descriptor<br> <TabAtkins> ntim: woudl longhand be physical or logical<br> <TabAtkins> fantasai: i think would have to be physical because that's how we generally handle shorthand properties with both directions<br> <TabAtkins> fantasai: we map to the physical directions by default<br> <TabAtkins> florian: would be good to have a switch but we dont' have yet<br> <TabAtkins> ntim: possible confusion with inline-size/block-size, versus width/height<br> <TabAtkins> ntim: but otherwise fine with this<br> <TabAtkins> emilio: should we discuss the alias in @page?<br> <TabAtkins> astearns: separate issue<br> <TabAtkins> emilio: i'll file one<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/820#issuecomment-2718529948 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 March 2025 16:56:27 UTC