New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tabatkins opened this Issue Dec 19, 2016 · 36 comments

Comments

Projects
None yet
@tabatkins
Member

tabatkins commented Dec 19, 2016

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

This comment has been minimized.

Member

astearns commented Dec 19, 2016

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

This comment has been minimized.

Contributor

frivoal commented Dec 20, 2016

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

This comment has been minimized.

Contributor

Crissov commented Dec 20, 2016

box, content-box …, box-size

@frivoal

This comment has been minimized.

Contributor

frivoal commented Dec 20, 2016

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

This comment has been minimized.

inoas commented Dec 20, 2016

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

This comment has been minimized.

Contributor

Crissov commented Dec 20, 2016

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

This comment has been minimized.

inoas commented Dec 20, 2016

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 comment has been minimized.

Member

tabatkins commented Dec 22, 2016

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

This comment has been minimized.

inoas commented Dec 22, 2016

@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

This comment has been minimized.

Contributor

Crissov commented Dec 23, 2016

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

This comment has been minimized.

inoas commented Dec 23, 2016

@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

This comment has been minimized.

Contributor

Crissov commented Dec 23, 2016

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

This comment has been minimized.

Contributor

fantasai commented Dec 27, 2016

@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

This comment has been minimized.

Contributor

fantasai commented Dec 27, 2016

@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

This comment has been minimized.

Contributor

Crissov commented Dec 27, 2016

@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

This comment has been minimized.

Contributor

fantasai commented Dec 28, 2016

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

@inoas

This comment has been minimized.

inoas commented Dec 28, 2016

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

@fantasai fantasai added the Agenda+ label Feb 16, 2017

@jonathantneal

This comment has been minimized.

Contributor

jonathantneal commented Feb 22, 2017

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

This comment has been minimized.

Contributor

Crissov commented Feb 22, 2017

@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

This comment has been minimized.

Contributor

fantasai commented Feb 22, 2017

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

@tabatkins

This comment has been minimized.

Member

tabatkins commented Feb 22, 2017

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.

@astearns astearns removed the Agenda+ label Feb 22, 2017

@jonathantneal

This comment has been minimized.

Contributor

jonathantneal commented Feb 22, 2017

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

This comment has been minimized.

Member

astearns commented Feb 22, 2017

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

This comment has been minimized.

Member

upsuper commented Feb 23, 2017

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

This comment has been minimized.

Contributor

Crissov commented Feb 23, 2017

Naming isn’t really something that implementers, i.e. browser vendors, should have the last say in. Like @astearns says, it’s about the “author experience”.

Module interactions

This module extends the width, height, min-width, min-height, max-width, max-height, […] features defined in [CSS21] chapter 10 […]

The respective level-3 module to replace the level-2 reference would be [CSS-BOX] if I’m not mistaken. At the risk of sounding annoying, the box- prefix (and box shorthand) seems appropriate to me, although it is implied in most properties currently.

(Fun fact: box-sizing was put into [CSS-UI] back in the day – i.e. 200X –, just because it was thought to be one of the earliest modules to reach REC status that wasn’t feature-frozen already.)

@frivoal

This comment has been minimized.

Contributor

frivoal commented Feb 24, 2017

( Fun fact: box-sizing was put into [CSS-UI] back in the day – i.e. 200X –, just because it was thought to be one of the earliest modules to reach REC status that wasn’t feature-frozen already.)

While many modules have made a lot of progress since, not many have reached REC, so this may still be true :) </digression>

@cvrebert

This comment has been minimized.

Member

cvrebert commented Aug 17, 2017

More possible names: diameter, breadth

@jonathantneal

This comment has been minimized.

Contributor

jonathantneal commented Aug 17, 2017

@fantasai, @tabatkins, was box-size presented as a name? I don’t see where it was disqualified. Is there an the issue? It also seems to address these concerns (repeated below):

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

@Crissov

This comment has been minimized.

Contributor

Crissov commented Aug 17, 2017

@jonathantneal Yes, in this very thread.

@tomhodgins

This comment has been minimized.

tomhodgins commented Aug 17, 2017

I've toyed around with this idea too - using a shorthand for both width and height called size that sets a value for both, kind of like how JavaScript can express either of these:

var width = 100
var height = 100

and also:

var width = height = 100

However, I don't think what I was really searching for was actually a size property, but a syntax that would let me 'chain' properties that share the same value. While I think the most-often requested use case for property chaining would be the size property, what if chaining was the new feature instead of just one new 'chained' property? Imagine this:

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

Can already become something like this thanks to CSS variables:

div {
  --size: 100px;
  width: var(--size);
  height: var(--size);
}

That functions the same way we want, but you have to write more CSS to make them share the same variable here than just setting them to the same number separately. But what about something like:

div {
  width, height: 100px;
}

I've just used a comma , here for a delimiter (maybe there's a better way) but this might be a more flexible solution for expressing this sort of thing than inventing new combined properties one at a time like width + height = size. What if CSS authors had the expressive ability to chain any two or more properties to set the same value?

@jonathantneal

This comment has been minimized.

Contributor

jonathantneal commented Aug 17, 2017

@Crissov, ah, sorry, I meant in a CSSWG meeting. See https://twitter.com/csswg/status/897994427859214336

@tomhodgins

This comment has been minimized.

tomhodgins commented Aug 17, 2017

I was inspired to build a little demo of this using --size:

<div>Demo</div>

<style>
    div {
    background: lime;
    --size: 50vmin;
  }
</style>

<script>
  function sizer() {

    var tag = document.querySelectorAll('body *')

    tag.forEach(function(tag) {

      var currentStyle = window.getComputedStyle(tag)
      var sizeProperty = currentStyle.getPropertyValue('--size')

      tag.style.width = sizeProperty
      tag.style.height = tag.offsetWidth + 'px'

    })

  }

  window.addEventListener('load', sizer)
  window.addEventListener('resize', sizer)
  window.addEventListener('input', sizer)
  window.addEventListener('click', sizer)
</script>

Demo: https://codepen.io/tomhodgins/pen/WEdmMM

@jonjohnjohnson

This comment has been minimized.

jonjohnjohnson commented Mar 31, 2018

Just adding a reference between this discussion and the issue created by @fantasai for "aspect ratio".
[css-grid][css-sizing] Aspect Ratio - https://github.com/w3c/csswg-drafts/issues/333

@battaglr

This comment has been minimized.

battaglr commented Mar 31, 2018

@tabatkins, is this still being considered?

If we added size —or whatever it would be called— shouldn't we also consider adding min-size and max-size?

@fantasai fantasai added the Agenda+ F2F label Apr 4, 2018

@battaglr

This comment has been minimized.

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Apr 10, 2018

The Working Group just discussed Adding a 'size' shorthand for 'width'/'height', and agreed to the following resolutions:

  • RESOLVED: Add a note to the spec explaining this problem and move this issue to level 4
The full IRC log of that discussion <dael> Topic: Adding a 'size' shorthand for 'width'/'height'
<dael> github: https://github.com//issues/820
<dael> fantasai: Shorthands are nice. We have them for many things, but not combo of width and height.
<dael> fantasai: We hadn't added that because there's a size property like thing that the app page has tht does not behave anything like this shorthand would. That sets the size of the writing box.
<dael> fantasai: Options are do something wierd where size doesn't work for @page. Other option is some other word then size. "box-size" is the current issue in the suggestion.
<dael> fantasai: It would be for block-size and inline-size. min-box-size would be the other.
<dael> florian: Naming conflict is that bad?
<dael> fantasai: It's a descriptor but operating on a box that accepts other boxes. It'll be weird forever.
<dael> TabAtkins: Weird because page takes width and height and size should be a property there. Conflict itself is weird but especially in the exact case.
<dael> TabAtkins: box-sizing is close.
<dael> dbaron: box and block might be confused by some.
<tantek> indeed
<dael> Rossen: What is the motivation here?
<dael> TabAtkins: People want to set width and height together.
<dael> florian: When people want to says omething different they repeat themselves.
<dael> fantasai: It's likely you'll want both to a keyword like auto or 100% or contain.
<dael> TabAtkins: Equal sizing is reasonable.
<dael> Rossen: The short shorthand is always going to give you squares.
<dael> florian: If you do % it will not.
<dael> TabAtkins: Unless box-size 50% is same for height and width.
<dael> fantasai: If we didn't have a naming conflict this would be in the spec.
<dael> florian: I'd ignore the naming conflict and say you can't use it in @page rule
<dael> astearns: I don't like that because if you don't know anything about @page it's surprising.
<dael> astearns: Here I've found I have to use it and the styles I set up perfectly are no longer good.
<dael> florian: It's the code you wrote to size the page that would be weird.
<fantasai> @page { size: 8.5in 11in; }
<dael> rune_: Page doesn't match any elements?
<dael> florian: no
<fantasai> @page { size: letter; }
<dael> astearns: I'm thinking copying from another container.
<dael> emilio: I think having a shorthand for page rule isn't worth it.
<dael> plinss: First comment TabAtkins said is people have been asking for this and it would be mildly useful. I'm not sure mildy is worth it.
<dael> fantasai: I've had people bug me for this. Those people are not sitting here.
<astearns> s/plinss/astearns/
<emilio> s/a shorthand/a special-case for @page rule/ above
<dael> astearns: I'm not hearing consensus on using size or another name. I'm not hearing huge enthusiasm for solving this
<dael> astearns: Might be worth a note in the spec saying we've considered a shorthand and have not found enough motivation for dealing witht he problems and outline what the problems are.
<dael> astearns: Objections?
<dael> RESOLVED: Add a note to the spec explaining this problem and move this issue to level 4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment