Re: [csswg-drafts] [css-sizing] Adding a 'size' shorthand for 'width'/'height' (#820)

Documents accessing the `size` property of an `@page` rule in the CSSOM via JS will stop working. So at least technically the change is breaking. We do not have enough data for a detailed estimate on the magnitude of the actual negative effects, but there definitively will be more than none. (We also offer a Paged Media based editing framework, which allows more direct access to the CSSOM for more complex integrations. Those customers would also be affected. So it is not only JavaScript.)

Thanks for pointing out that in the Paged Media specification `width` and `height` already affect the page size, specifically the page area (page content box). However, there is practically no support for this in user agents while `size` is supported and essential in all Paged Media based ones. Also we are not sure about the use cases for basing the page size on its area/content size. So, in our opinion, changing `width` and `height` looks preferable to changing `size`.

Also the behavior of `width` and `height` already depends on the context in multiple cases, like inline or table related boxes. Having them affect the margin size, instead of the one from `box-sizing`, when used in `@page` is not a complex or confusing special case. (It may even be what authors expect, but that is speculation.)

We also agree that paper sizes like `A4` can be handled at the shorthand level and think that would be an elegant solution, also allowing to style any box to have one of the standardized sizes.

Overall the approach of having the shorthand in all cases, including `@page`, may have more positive effects and opportunities than negative ones.

GitHub Notification of comment by bernhardf-ro
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 22 October 2019 10:51:14 UTC