- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Oct 2019 16:48:18 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Adding a 'size' shorthand for 'width'/'height'`, and agreed to the following: * `RESOLVED: We are redefining the size property in @page to be called page-size. Also defining that size in the page context parses into page-size. The size property is a shorthand for width and height` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Adding a 'size' shorthand for 'width'/'height'<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/820<br> <dael> TabAtkins: discussed in past. Useful b/c size often set together. @page rule has a size declaration and we can't collide names.<br> <dael> TabAtkins: fantasai had a great suggestion to unblock. Rename @page declaration to page-size. Define @page has a parse time alias of size turning into page-size and that frees up size.<br> <dael> TabAtkins: Any existing pages using size will work. Anyone using CSSOM to page @page will see a page-size property. I suspect that's almost 0 since @page is only useful in printing. Printing doesn't have much JS support. Almost no possible breakage and this will let us do the size thing we've wanted to do for at least a decade.<br> <dael> TabAtkins: Clever way to get what we want.<br> <dael> florian: I think you're slightly overstating lack of JS support, but I agree with the argument<br> <dael> Rossen_: It's a cool proposal. I'm in favor. Other opinions?<br> <dael> dauwhe: I'll try and contact Prince about this<br> <dael> dauwhe: They're a PDF formatter that uses @page and supports JS<br> <dael> Rossen_: Should we wait?<br> <dael> dauwhe: No, go ahead<br> <dael> Rossen_: Thanks for the reach out<br> <dael> florian: Since this is new aliasing should we be explicit about how it can be used<br> <dael> fantasai: It's defined at parse time and you never see the other name.<br> <dael> florian: Of CSS file?<br> <dael> AmeliaBR: Does become a question. If you use cssom method to pase string that's parsed that is also parse time. Need defined somewhere. Need to define it somewhere for explaining relationship of MS prefixed force-colors vs new force-color<br> <dael> florian: WE have general aliasing, but this alias is weird<br> <dael> TabAtkins: Normal is shorthanding based. Property then does show up in all contexts. THis would be not that. Does need clarification. Happy to work to see exactly what to clarify.<br> <dael> emilio: If can put width and height in @page this would be quirky because size means one thing in @page<br> <dael> emilio: Can set width and height in @page rule. Means size does something different in @page then everywhere else.<br> <dael> TabAtkins: That's why we can't overlap. b/c size is not a shorthand in @page<br> <dael> fantasai: Confusion from naming property anything other than 'size' is higher then size in @page not being width and height<br> <dael> florian: Dev tools should be warning about this. If page-width exists and you try and use size you should be warned.<br> <dael> TabAtkins: I don't think any browser respects @page size declaration<br> <dael> florian: Chrome does<br> <dael> TabAtkins: Okay. Cool. I think spec should clarify that it's page-size and it's required to do this parsing. And I'll file a bug on our dev tools that we should have a maybe use something else<br> <dael> Rossen_: Prop: Add size as a shorthand for width and height for everywhere by @page?<br> <dael> fantasai: Several things. 1) We are redefining the size property in @page to be called page-size.<br> <dael> Rossen_: Let's resolve there first<br> <dael> fantasai: Also defining that size in the page context parses into page-size<br> <dael> fantasai: Once that's resolved, then the size property is a shorthand for width and height<br> <dael> Rossen_: Objections to these three steps?<br> <dael> RESOLVED: We are redefining the size property in @page to be called page-size. Also defining that size in the page context parses into page-size. The size property is a shorthand for width and height<br> <AmeliaBR> (To clarify my earlier comment, the similarity to forced color was that any rule inside the `@media (-ms-high-contrast)` would include an implicit `forced-color-adjust: none` declaration added at parse time. But doesn't look like that got included in the spec, it was just a suggestion of how MS could handle internally.)<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-542792268 using your GitHub account
Received on Wednesday, 16 October 2019 16:48:19 UTC