[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.

[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.

[andruud]

What is blocking us here now?

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.

Yes, pagerule.getPropertyValue('size') would stop working; this is indeed a breaking API change.

Is it the above? If yes, can't we "just" do the following?

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.

Making a distinction between property/descriptor seems acceptable, especially with recent developments in CSSOM.

[benface]

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

Just a thought: if size is introduced as a shorthand, the inline-size and block-size properties would be slightly inconsistent with other logical properties where the inline and block keywords follow the shorthand name, rather than precede it (e.g. padding-inline, margin-block, etc.). So I think it would make sense to also introduce size-inline and size-block aliases as well.

[phaux]

@benface gap also has its more specific versions the other way around: row-gap and column-gap

[mohsinnawaz04]

Instead of naming it as size, we should name it length. For example,
div { length: width height; }

[css-meeting-bot]

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

The full IRC log of that discussion

<TabAtkins> fantasai: wow this was old.
<TabAtkins> fantasai: not clear what to do here, but people want it solved
<TabAtkins> fantasai: complication is there's an existing size proeprty in @page rules
<TabAtkins> fantasai: and it's not equivalent to setting width/height
<TabAtkins> fantasai: width/height apply to the page area
<TabAtkins> fantasai: this is implemented by PDF renderers
<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
<oriol> q+
<fantasai> https://github.com//issues/820#issuecomment-810626883
<TabAtkins> fantasai: so wanted to know if it's viable
<ntim> i like the idea
<TabAtkins> astearns: seems a little icky to have different processing based on where 'size' comes up
<JoshT> q+
<TabAtkins> astearns: but maybe in this case its' reasonable
<emilio> q+
<TabAtkins> (I think there's not really any better solution. Also slightly icked but okay with it for the benefit.)
<astearns> ack oriol
<TabAtkins> florian: Yeah, unfortunate, but since the weirdness is so scoped it's probaqbly okay
<TabAtkins> oriol: in @page, it has descriptors not properties
<JoshT> q- Was going to make the same point
<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
<JoshT> q-
<astearns> ack emilio
<ntim> q+
<TabAtkins> emilio: i think this is the onlyw ay to make it work
<TabAtkins> emilio: but maybe it could be cool to make 'size' in @page a legacy alias for some other name, like 'page-size'?
<TabAtkins> emilio: that would be easier to implement, I think, then I don't need to deal with the name conflict as much.
<florian> +1
<TabAtkins> emilio: and maybe less confusing long term
<TabAtkins> astearns: do you have a mechanism to only apply an alias in one at-rule context?
<TabAtkins> emilio: yes, easily
<TabAtkins> emilio: just within the @page descriptor, if descriptor name is 'size' return 'page-size'
<astearns> ack fantasai
<Zakim> fantasai, you wanted to reply to emilio
<ntim> p+
<fantasai> https://github.com//issues/820#issuecomment-544582026
<TabAtkins> fantasai: we'd previously resolved to make it an alias and have page-size be the name
<TabAtkins> fantasai: response we got was some products support JS and 'size' has been supported as long as PDF renderers have existed
<TabAtkins> fantasai: so we could do aliasing, but would have to make sure it doesn't break CSSOM
<TabAtkins> emilio: yeah, aliases already work nicely for that
<astearns> ack ntim
<TabAtkins> ntim: any usage data on 'size'? i guess elika has answered the question
<TabAtkins> ntim: any browser have data?
<TabAtkins> fantasai: primary usage isn't in browsers, it's in pdf renderers. so big market difference in both content and userbase
<TabAtkins> emilio: i think browsers do support 'size' in printing, it's fairly used
<TabAtkins> iank_: yeah people generate PDFs from brwosers all the time, and do use the 'size' descriptor
<TabAtkins> iank_: so the markets are acteually pretty overlapping
<TabAtkins> florian: and epub readers too
<TabAtkins> florian: at least notionally, interactive pages user agents
<TabAtkins> ntim: common on web sites tho?
<TabAtkins> florian: when you print a web site, yeah, reasonably
<TabAtkins> iank_: very common in enterprise use-cases to have printable pages
<TabAtkins> iank_: and they use @page on those
<fantasai> https://www.w3.org/TR/css-cascade-5/#aliasing
<TabAtkins> ntim: i ask because in webkit, @page is pretty poorly maintained and we haven't seen many bug reports
<TabAtkins> iank_: I suspect we have the best support among browsers here, and enterprises are just targetting Chrome for printing webapps
<TabAtkins> astearns: so proposed resolution is we add 'size' shorthand proeprty that has nothing to do with '@page/size'
<TabAtkins> astearns: concerns?
<TabAtkins> RESOLVED: Add a 'size' shorthand property (for 'width'/'height'), no relation to @page's 'size' descriptor
<TabAtkins> ntim: woudl longhand be physical or logical
<TabAtkins> fantasai: i think would have to be physical because that's how we generally handle shorthand properties with both directions
<TabAtkins> fantasai: we map to the physical directions by default
<TabAtkins> florian: would be good to have a switch but we dont' have yet
<TabAtkins> ntim: possible confusion with inline-size/block-size, versus width/height
<TabAtkins> ntim: but otherwise fine with this
<TabAtkins> emilio: should we discuss the alias in @page?
<TabAtkins> astearns: separate issue
<TabAtkins> emilio: i'll file one

[stof]

should size be a shorthand for <width> <height> or for <inline-size> <block-size> ?

[mstensho]

This means that this version of size can never be part of https://drafts.csswg.org/css-page-3/#page-property-list , which is a bit weird, given that its longhands width and height are on that list.

[hacknug]

should size be a shorthand for <width> <height> or for <inline-size> <block-size> ?

Only for <width> <height> atm. From the meeting logs:

ntim: woudl longhand be physical or logical
fantasai: i think would have to be physical because that's how we generally handle shorthand properties with both directions
fantasai: we map to the physical directions by default
florian: would be good to have a switch but we dont' have yet
ntim: possible confusion with inline-size/block-size, versus width/height
ntim: but otherwise fine with this

[JoshTumath]

should size be a shorthand for <width> <height> or for <inline-size> <block-size> ?

That was asked in the call as well. It would need to be width and height, to follow the president set by other shorthands like margin and padding. There is a separate issue, #1282, to solve that problem.

This means that this version of size can never be part of https://drafts.csswg.org/css-page-3/#page-property-list , which is a bit weird, given that its longhands width and height are on that list.

@emilio has filed #11925 to make a new property to replace size for @page.

[astearns]

This means that this version of size can never be part of https://drafts.csswg.org/css-page-3/#page-property-list , which is a bit weird, given that its longhands width and height are on that list.

@emilio has filed #11925 to make a new property to replace size for @page.

If we do alias size in @page as that issue suggests, we would still not be able to use the property version of size as a descriptor in @page