[css-sizing] Adding a 'size' shorthand for 'width'/'height'

[tabatkins]

Many people thruout the years have requested a 'size' property as a shorthand for 'width' and 'height', for the common cases when you want to set them both to the same value. (Either making the element square, or making it a similar rectangle to the containing block with percentages, or using the same keyword for both.)

This seems mildly useful, but it has a naming problem - the @page rule already has a 'size' property, and it's not a shorthand for the 'width' and 'height' properties @page also has. ('size' sets the size of the margin box, while 'width' and 'height' set the content box.)

Other suggestions for names?

[astearns]

dimensions (probably too long and difficult to spell)
area (not quite the right meaning)
embiggedness (the real reason I'm adding this comment)

I've added this to the list of mistakes

[frivoal]

Also, just to put it out there, how bad would it be if we added this under the size name and kept @page's size stay the way it is, effectively making the size shorthand unavailable in @page?

On the one hand, this is dirty and there is no precedent for properties meaning completely different things in different context, on the other hand, the usages seem really disconnected, and authors would likely cope just fine.

(and on the third hand, it isn't entirely clear why size in @page is considered a property rather than a descriptor, but it doesn't really make much of a difference anyway, so ignore my 3 handed monster).

[Crissov]

box, content-box …, box-size

[frivoal]

Not content-box, as that would be the wrong name when box-sizing: border-box is on.
As for box, it doesn't seem wrong, but it's awfully generic.

[inoas]

I don't see the benefit. I'd rather not pollute the property space with property names that yield little benefit. If you want to set both, then just set both.

p.s.: What would be more interesting is aspect-ratio values for height and width (behaving similar to auto, insofar as that they will scale when one value is set or the other).

[Crissov]

Without added features beyond a shorthand, such a new property would be nonsense anyway.

<box>: [ <width> <height>? | <width> <box-aspect> | <box-aspect> <height> ] || <box-sizing>
<box-aspect>: <<number>> | <<integer>> '/' <<integer>> | 'golden' | 'sqrttwo'

PS: Maybe box-ratio makes more sense than box-aspect.

[inoas]

What would take precedence if width/height and new-property are set and values are conflicting?

I'd argue something like this would make sense:

.block {
  height: 640px; /* change this through MQ */
  width: 480px;  /* change this through MQ */
}
img.some {
  display: block;
  width: 100%;
  height: aspect(0.5);      /* set's the height to half of the width */
  height: auto(0.5);        /* set's the height to half of the width */
  height: auto-aspect(0.5); /* set's the height to half of the width */

  height: aspect-ratio(0.5);  /* set's the height to half of the width */
  height: aspect-ratio(golden);  /* set's the height to golden cut */
  height: aspect-ratio(calc(9/16));  /* set's the height to 16:9 */
}

[tabatkins]

This topic is not about a theoretical aspect-ratio property; please move any such discussion to a different issue. (There might already be one started for that.)

[inoas]

@tabatkins so on the constructive side:
What would take precedence if width/height and new-property are set and values are conflicting?
What are the functional benefits?

[Crissov]

The issues are connected however, @tabatkins, because it could make sense to name them all box-* and combine them in a box shorthand property – or only add that. The syntax of an aspect ratio property or function should be discussed separately, though.

<box>: <box-size> || <box-sizing>
<box-size>: [ <width> <height>? | <width> <box-aspect> | <box-aspect> <height> | <box-aspect> ] /* = */
<box-size>: [ <width> [ <height> | <box-aspect> ]? | <box-aspect> <height>? ]

[inoas]

@Crissov then the rule would be whatever is set as a property (with the same or higher specificity, obviously) overwrites each other? E.g. would this hold true?

div {
  dimensions: 100px 200px; /* width: 100px, height 200px */
  width: 50px;  /* width: 50px, height: 200px */
  dimensions: 100px; /* width: 100px, height: 200px */

  /* Related / Off-Topic: */
  dimensions: 100px aspect-ratio(calc(9/16)); /* width: 100px, height: 56.26px */
}

[Crissov]

I'd say that a single length makes the box square – assuming 1:1 is the default aspect ratio that the shorthand resets to:
100px × 200px @ 1:2 → 50px × 200px or 50px × 100px → 100px × 100px.

It could also keep the current AR, hence
100px × 200px → 50px × 200px → 100px × 400px.

Alas, then width before should do, too, i.e.
100px × 200px @ 1:2 → 50px × 100px → 100px × 400px.

Otherwise, yes box and box-size would work like other shorthand properties. The WG would decide the most useful and compatible approach.

[fantasai]

@inoas Precedence is calculated by the cascade, as size would be a shorthand property. See https://www.w3.org/TR/css-cascade/#shorthand-property

@Crissov As Tab said, please take discussion of aspect ratios elsewhere. This issue is literally just a naming conflict issue.

[fantasai]

@inoas Oh, as for the benefit: there are many times when one wants to set both width and height, or both min/max-width and min/max-height, to the same thing. It's not commonly desired for length values (since that would always make a square), but for keywords and percentages it is.

[Crissov]

@fantasai The detour to aspect ratios was necessary, for me at least, to prefer box-size over just box as an alternative to size. @tabatkins didn’t specify the exact syntax or scope of the shorthand nor link to one, so it’s difficult to suggest an alternative without considering such side issues.

[fantasai]

It would be size: <'height'> <'width'>? with omitted <'width'> taken from <'height'>. Basically your standard shorthand.

[inoas]

@fantasai <'height'> <'width'>? would be consistent with how padding and margin with 2 values works in terms of the direction (horizontal, vertical), however elsewhere sizes are usually defined width first then height. That's the only thing that would make me worry a little tiny bit.

Thanks for pointing to the shorthand block. I just wasn't aware of the nomenclature. That clears the conflicting (that isn't there!).

Edit: box-size is too close to box-sizing and can easily be confused, IMHO.

[jonathantneal]

this is dirty and there is no precedent for properties meaning completely different things in different context

Are there other concerns with @frivoal’s suggestion that the @page at-rule could define its own context where size uses the existing meaning? To me, this seems worth exploring, as the alternatives seem far from the cowpath.

[Crissov]

@inoas The similarity of box-size and box-sizing would be a feature, not a bug, in my opinion – also possible:

box-size: <'height'> <'width'>? || <'box-sizing'>?

or, of course,

box-size: <'width'> <'height'>? || <'box-sizing'>?

[fantasai]

Note also that inline-size and block-size use the word size, so using any other term would be inconsistent with those.

[tabatkins]

Conclusion from today's call: currently tabling this issue. We can unblock it with:

• implementor interest in using 'size', despite the minor implementation concerns that it brings due to context-difference between normal styles and @page
• a new name that meets broad agreement.

[jonathantneal]

What does implementor interest look like? Are outsiders (those who don’t work with browser vendors) capable of helping in this area?

If an implementor is interested, how blocking is the later issue. I’m just not clear if this is an either/or list.

[astearns]

It's an either/or list.

If we can come up with a name that isn't 'size' that is really good for the author experience, then it's relatively easy to spec and implement.

Or if there is enough author convenience in a shorthand named 'size' that convinces implementors to take it on, we can progress with that name. My understanding (as a non-implementor) is that this approach is slightly more complicated, and no one has (yet) considered this shorthand worth the effort to implement. Bugs, blog posts and bribes are needed.

[upsuper]

I have another concern for serialization. If we add size (or whatever it would be called), the following block

div {
  width: 200px;
  height: 100px;
}

would suddently be serialized to something like size: 200px 100px;.

Code may be broken if they rely on parsing the serialization themselves. Not sure how usual this can be, though.

[bernhardf-ro]

Getting some feedback from other printing software would be useful here.

We also hope for more parties commenting on this. Maybe adding [css-page-3] to the title would draw the necessary attention.

If it is any help, we found that of 4 user agents that support size (Chrome, PDFreactor, Prince, AH Formatter), 3 do not support width and height at all and the remaining one, AH Formatter, does not resize the page as per the specification.
So, while there is one implementation that does not ignore width and height, its behavior deviates far enough from the specification that making it compliant to the current specification would be as much of a change as adapting it to our proposal.

[what exactly retrieving size should return]

Returning 2 lengths, even after setting an identifier, looks like the best solution to us. Most script authors that have to retrieve the size would benefit from a consistent format and most likely prefer always getting lengths.
For example, size: A4, just like size: 210mm 297mm, should result in width: 210mm; height: 297mm and, in turn, in size: 210mm 297mm.

On the other hand, to keep the identifier if (and only if) it has been set, would be possible, but require passing it to width and height, e.g. width: A4; height: A4, which we consider excessive. It would create a lot of additional work for the sake of symmetry.

[Crissov]

Paper size approximation

Regarding standard page sizes being stored with the canonical unit px (in browsers at least, hopefully not in CSS-to-PDF software): since 24px = 0.25in, US sizes, which are all based on full, half or quarter inches, do not have the problem, but calc(96px/25.4) and calc(25.4mm/96) yield indeed awfully odd numbers, roughly 3.78px and 0.265mm. A4, i. e. 297 mm × 210 mm, would become c. 1122.52px × 793.79px, which, if first rounded to the nearest CSS pixel, converts back to 297.12mm × 210.08mm.

Many PDFs exhibit a similar issue, wherein ISO page dimensions have been converted to an integer number of DTP points, resulting in 297.04 mm × 209.9 mm for instance.

However, ISO 216 specifies tolerances for cut paper sizes that are well beyond such rounding effects: ±1 mm for the sizes that have keywords in CSS if I remember correctly. Also, the sizes are iteratively rounded (floored?) from theoretical √2-based values to an integer number of millimeters anyway. The theoretical size of A4 would be about 297.302mm × 210.224mm or ca. 1123.66px × 794.55px.

In other words, if width and length are within 1mm of an ISO size after having been converted from a px, itʼs pretty safe to assume that the size originally specified was indeed the respective standard format.

New size keywords

This reminded that there are other common sizes that may deserve keywords. (See #328 for paper sizes.) Iʼm not sure theyʼre worth the cost, because their actual values are often at least as familiar as their names and abbreviations, but Iʼm thinking of vga = 640px 480px and the like. Besides <page-size>, size should then also learn orientation modifiers landscape and portrait from @page.

PS: These days, I’d also expect standard (IAB) ad sizes.

• leaderboard = 728px 90px
• large-leaderboard = 970px 90px
• large-rectangle = 336px 280px
• medium-rectangle = 300px 250px
• small-rectangle = 180px 150px
• vertical-rectangle = 240px 400px
• tablet-landscape, full-screen = 1024px 768px
• tablet-portrait = 768px 1024px
• banner = 468px 60px 39:5
• half-banner = 234px 60px
• vertical-banner = 120px 240px
• mobile-landscape = 480px 320px
• mobile-portrait = 320px 480px
• mobile-leaderboard = 320px 50px
• mobile-leaderboard-double = 320px 100px
• mobile-banner = 300px 50px
• mobile-banner-double = 300px 100px
• half-page = 300px 600px
• wide-skyscraper = 160px 600px
• skyscraper = 120px 600px
• square = 250px 250px
• small-square = 200px 200px
• square-button = 125px 125px
• button = 120px 60px
• small-button = 88px 31px
• panorama = 980px 120px
• top-banner = 930px 180px
• netboard = 580px 400px
• triple-widescreen = 250px 360px

[XiBOR]

Wouldn't it be more convenient to make reductions for all properties at once?
For example:

size: 10px; // width: 10px, height: 10px || min-width: 10, max-width: 10, min-height: 10, max-height: 10
size: 10px 20px; // width: 10px, height: 20px || min-width: 10, max-width: 10, min-height: 20, max-height: 20
size: 10px 20px 30px 40px; // min-width: 10, max-width: 20, min-height: 30, max-height: 40

[Crissov]

size: 10px could also be a shorthand for roughly size: 7.07px 7.07px with an aspect ratio of 1:1, i. e. specify the diagonal or diameter.

[Loirooriol]

@Crissov You can use calc(10px * cos(atan(1/1))) and calc(10px * sin(atan(1/1))) for that.
Overcomplicating size with diagonals would be very confusing and unexpected.

[Crissov]

Diagonals would of course only make sense if one could also set the aspect ratio within size:

size: [<'width'> <'height'>] 
    | [<length> || <'aspect-ratio'>] 

[tabatkins]

I'm downloading AH Formatter right now (well, I'm requesting a trial download, we'll see), so I can see what they actually do with 'width'/'height' on pages, per @bernhardf-ro's comment that they're the only implementor that has those descriptors at all, and they do something different than the spec anyway.

Changing the definition of @page/width and @page/height seems like the most viable way forward here, since no one's come up with a reasonable alternate name for 'size'.

[jsnkuhn]

Would there be a need for min-size and max-size properties as shorthands for min-width/min-height and max-width/max-height? Or would the use of size: clamp() or size: clamp() clamp() be enough to cover all of that?

[SebastianZ]

Using clamp(), min(), and max() should be sufficient to cover all use cases of min-width, min-height, max-width, and max-height.

Sebastian

[Loirooriol]

Note that width: 100px; max-width: 0% and width: min(100px, 0%) have different intrinsic contributions when the containing block is intrinsically sized. https://drafts.csswg.org/css-sizing/#cyclic-percentage-contribution

[jonathantneal]

I see this issue now has the tag Needs Design / Proposal. What might that design or proposal look like? Would it look like a new issue with the proposed changes as they might appear in a bikeshed document? Or as a PR?

Perhaps some of us can help with this. 😄

[MurakamiShinyu]

I am not opposed to changing the definition of @page/width and @page/height. However, we still need a way to specify the width and height of the page-area. For example, what about the following new syntax? (@page-area for the page area definition):

@page {
  size: A5;
  margin: auto;
  @page-area {
    width: 32rem;
    height: 29rlh;
  }
}

BTW, our implementation, Vivliostyle, has supported @page/width and @page/height in the same way as Antenna House Formatter since 2015.

See our sample stylesheet using width and height on @page :
https://github.com/vivliostyle/vivliostyle_doc/blob/gh-pages/samples/gon/scss/base/_format.scss#L23-L32
(View the sample with Vivliostyle Viewer: https://vivliostyle.org/viewer/#src=https://vivliostyle.github.io/vivliostyle_doc/samples/gon/index.html )

[fantasai]

I chatted with @emilio about this back in December. IIRC, it seems it's possible to just have size in an @page context just be handled specially. It would be a little bit confusing that outside of @page it's a shorthand for width+height, but within @page it's a special property, but I think it might be the best option. I'd rather not define @page width/height in a way that's incompatible with the CSS-to-PDF renderers that have implemented it so far. And we've failed to come up with a better term than size for the width+height shorthand. If that seems practical to other implementers, maybe we can move forward with that.

@MurakamiShinyu @faceless2 What do you think?

[MurakamiShinyu]

@fantasai I agree that would be the best option, to keep the current definitions in @page context while allowing the new size shorthand in other context.

[faceless2]

It's not ideal, but I agree it's probably the simplest option.

[Crissov]

Isn’t size inside @page more like a descriptor than like a property anyway?

[bernhardf-ro]

We discussed this internally again and still think that just making size a shorthand and having page margin box size be affected by width and height would be the ideal solution.
Making the property a shorthand depending on its context in the CSS-OM would add complexity that may well be disproportionate to the gain.
However, we don't see any issues on the implementation side that would prevent us from implementing it if it is decided on.

[jsnkuhn]

CSS Grid has a grid shorthand property that allows for defining display: grid; related properties in one line could there similarly be a block property related to display: block; that covers width/height, alignment, margin/padding?

https://developer.mozilla.org/en-US/docs/Web/CSS/grid

[ggedde]

Maybe I am missing something here, but can't @page {size} just get ignored if the values are in (px, em, rem, %, etc) and vise versa for block {size} if the values are in (A5, A4, Letter, mm, in, etc)

[cdoublev]

It seems it's possible to just have size in an @page context just be handled specially. It would be a little bit confusing that outside of @page it's a shorthand for width+height, but within @page it's a special property, but I think it might be the best option.

Specs do not seem to preclude handling it specially. CSS Syntax requires that a CSS rule taking <declaration-list> define the properties and descriptors it accepts: @page does not accept the size property but accepts a size descriptor.

From this perspective, I do not see where CSSOM prevents a context-specific handling (even if CSSPageRule.style, ie. CSSStyleDeclaration, is defined with all properties). font-style already has a slightly different syntax depending on if it is declared in a style rule or @font-face, and CSSFontFaceRule.style.setPropertyValue('font-style') is supposed to be supported (style and setPropertyValue() are misleading).

Fwiw, what confuses me is not that a property grammar could be different depending on the context, but it is this differentiation between property and descriptor, which I cannot find in any other language, and to support CSSPageRule.style.setPropertyValue('size') at the same time (style is misleading).

[tabatkins]

Fwiw, what confuses me is not that a property grammar could be different depending on the context, but it is this differentiation between property and descriptor, which I cannot find in any other language,

It's largely a legacy separation. For whatever reason, the original editors thought it was valuable to draw a distinction between the two, and we've continued with it since then.