Shorthand for width/height CSS longhands


What if we add the size CSS-property as a shorthand for width and height?

PostCSS has already implemented the size property via the postcss-size plugin (annoucement in the official PostCSS twitter).

For example:

.foo {size: 10px; }

would set both width and height properties to 10px, so being an exact equivalent to:

.foo {
    width:  10px;
    height: 10px;


.bar {size: 2em 3em; }

would set width and height to 2em and 3em respectively (or height and width if “first vertical then horizontal” order has been chosen in line with margin / padding instead of e.g. background-position).

The reasoning is the same as for other shorthands like margin or padding:

  • preventing from repeating yourself if longhands have the same value (that’s what I’m mostly interested in);
  • specifying multiple values more compact way (a common feature of shorthands).

This can be (and is) implemented via a preprocessor like SCSS:

@mixin size($value) {
    width:  $value;
    height: $value;

But preprocessors exist just to overcome current CSS shortcomings, while it makes sense to overcome them on CSS-itself level to make CSS itself more usable and self-contained in the long term.

(This has originally been proposed in www-style a year ago, but has been ignored by decision makers.)

Display an image at device’s physical resolution

Would this double as indicating an element’s aspect ratio? (The fact that the old padding-box trick is still alive is kind of sad.)


I agree that having ability to maintain aspect ratios (for example, to prevent image distortion when width and height are both specified in conjunction with max-width) would be a useful feature (feel free to post a separate proposal for it), but the size here is solely intended as just a shorthand for existing width and height.

So what I propose is an exact equivalent to what is currently achieved using a preprocessor mixin.


After a month, it’s obvious the proposal has been ignored by decision makers like the original one at www-style.

What an exciting selective blindness of CSSWG.


Hi MT, thanks for putting together the sizes proposal. I’d like to kindly remind you that the WICG is a community-driven organization, hence there are no “decision makers” ignoring your proposal (because there are no “decision makers”!). In order to get your proposal adopted, you do need the support of browser vendors, and the community at large tho.

Hang in there: if your proposal has merit, and it’s useful, then it will get traction. However, you need to also be prepared to accept that it might not get picked up for whatever reason. That’s ok, tho. Most (~95-99%) standards proposals don’t go anywhere for a number of reasons: like it might not provide enough benefit, it might be too hard to implement, etc.

I know it can be frustrating to feel you are being ignored - but trust me, you are not! Lots of things are happening all the time in standards land, and it’s hard for things to bubble up. However, please refrain from using inflammatory language like accusing the CSSWG of “selective blindness” - or conjuring up conspiracy theories about “decision makers”. That won’t win you any friends or supporters for your proposal.

Hope that helps!


Hi, Marcos. Thanks for your feedback, though I believe it would generally be better to send such off-topic messages privately. But since your message is public, I’m forced to reply publicly as well.

thanks for putting together the sizes proposal.

The proposal has nothing to do with the sizes HTML attribute. The proposal is about a shorthand for width and height CSS properties.

the WICG is a community-driven organization, hence there are no “decision makers”

WICG is basically a discussion platform. Of course WICG itself does not have decision makers related to standards. CSSWG does (the WG members / spec editors are decision makers — some of them are here on WICG — e.g. Tab Atkins and Florian Rivoal) — that’s exactly what I meant.

The first proposal iteration posted at www-style had nothing to do with WICG at all.

if your proposal has merit, and it’s useful, then it will get traction.

This is probably not quite an accurate assumption. There are subtle, minor things that don’t get much explicit traction by non-decision-makers (especially via a specific and not yet quite popular discussion platform) while this does not mean such minor proposals are useless. BTW, size property is already implemented via a PostCSS plugin.

I have multiple much more (to say the least) serious ideas, but it looks not making much sense to spend time to make corresponding proposals since even much more trivial proposals are ignored by decision makers.

inflammatory language like accusing the CSSWG of “selective blindness”

I have not been accusing anyone. To be clear: my comment after a month is not about just the WICG iteration of the proposal, instead it’s about both iterations made via www-style and WICG.


I’ve found with my own proposals you really have to play the role of “proposal champion” yourself. Everyone’s busy with competing proposals and other spec work, so you have to take on a sort of promotional role yourself.

The very best thing you can do to further your own proposal is draft the spec then ask implementers to review it. It can be quite a lot of work to get a draft spec written up with the right tools and guidelines, and sitting around waiting hoping for someone else to do it means hoping someone else will do a lot of unpaid work on your idea. It’s probably not going to happen like that. So I would encourage you to learn how the spec writing process works, start writing the specs, and bump your thread with a spec draft rather than a complaint.


I’ve found with my own proposals you really have to play the role of “proposal champion” yourself.

Hi, Ashley. I’m not sure I understand you correctly. FWIW, I have just 2 (two) proposals here on WICG for now.

(Edit: in a private conversation, Ashley has clarified that he thought he “saw the term ‘champion’ used somewhere else in a spec context” and meant that the proposal author himself is who is responsible to “promote” the proposal; so the unclear ambiguous term ‘champion’ is apparently just accidentally used inappropriately.)

best thing you can do to further your own proposal is draft the spec

It does not make sense to write a full-fledged spec (though I’m open in general to do this once the basic idea is accepted) if its horizons are unclear and could easily be clarified on a just-an-idea stage.

(BTW, we’ve already seen what happens when someone writes a spec after being encouraged by a WG member, and then no WG members give attention to the spec.)

I absolutely don’t expect that someone would write a spec for the feature I’ve proposed. What would be enough is just a short explicit yes/no/why opinion by a CSSWG member.

P.S. Please consider using the private-message feature (or the contact form on my site) to send off-topic comments, so that the relevant information didn’t get lost among irrelevant text. Thanks.


Tab and I are here, most other CSSWG people are not. www-style is probably the right place for this. I am sorry you got ignore the first time. Tagging your mail with the spec that this proposal belongs to might have helped it getting noticed. Maybe you could try resending or responding to it, adding [css-sizing] in the title.

www-style is a busy mailing list, and it is nobody’s job in particular to make sure that nothing falls between the cracks. It’s bad when it happens, but it does.

Most people including seasoned “decision makers” regularly send mails that don’t get answers, due the randomness of other participants calendar. Just go at it again, and eventually you should get feedback.

As to this proposal in particular, I don’t think there’s anything problematic about it. It sounds like a neat convenience to have. At the same time, it does not introduce any new capability, and while it saves some typing, it’s not a lot. And you can roll your own equivalent using custom properties. So while I wouldn’t oppose it, I would also not be surprised if browser vendors considered it (very) low priority.


Hi, Florian. Thank you for the constructive comment and the tip about the [css-sizing] prefix (unfortunately, it’s not always obvious what spec module the feature belongs to, while a wrong prefix would probably be even worse than no prefix).


Note sure about that. Very few people read all mails to www-style. Most regulars have filters to prioritize reading mails that are relevant to their specs. So a mail without a tag might be seen by nobody. A mail with the wrong tag might be seen by someone who can point out it’s the wrong tag and suggest a better one.


Good point, thanks Florian.


I like this idea. Pairing that with hardware acceleration when possible would be nice too!




As a mere shorthand to level 1 width and height properties, a new property size would probably not be worth the effort, because it would induce a lot of backwards-compatibility friction, i.e. future authors will rely on size (or dimensions) but current and older UAs won’t understand it albeit still being in use.

It would have slightly larger benefits, hence chances, if it (optionally) included more functionality. The three things first springing to my mind are aspect-ratio, box-sizing and related min- and max- properties (which are different from proposed min() and max() pseudo functions).

size: 300px; /* shorthand setting
    width = height = 300px
    min-width = min-height = 0? or 300px?
    max-width = max-height = 300px? or auto
    aspect-ratio = 1
    box-sizing = content-box */

size: 400px 300px border-box;  /* shorthand setting, among others,
    width = 400px, height = 300px
    aspect-ratio = 1.333… 
    box-sizing = border-box */

size: 400px/30em/600px 4:3; /* shorthand setting
    min-width = 400px, min-height = 300px
    width = 30em, height = 22.5em
    max-width = 600px, max-height = 450px
    aspect-ratio = 1.333… */


“Mere shorthand” is the most easy thing that could be done with almost no effort.

Given that browsers are currently often updated, this does not matter much. Moreover, any new feature could be considered undesired just due to its “backward incompatibility”, but this would mean we should not add new features at all which is impossible and absolutely not what backward compatibility is about.

In practice, overcomplicating a feature actually decreases chances of standardizing it. Additional subfeatures could be introduced later, once the basic shorthand is specced and implemented.


A shorthand on its own is not a new feature! Forget it, without further benefits for authors or users or implementers – preferably more than one of these – it ain’t gonna happen, because it would be too harmful, even if people agreed that it would have been the right thing to do in level 1.

Also, the big screen on my desk at home doesn’t get any OS or default browser updates any more, yet is still perfectly sufficient as a write, read, watch, listen and browse machine unless intentionally broken – and I’m not an extreme case by all means. In many (even large) companies and institutions, browsers don’t get updated as regularly as you’d think (or want).


It’s surely a syntax-level feature.

As long as you are not a WG member nor a browser vendor, it’s out of your responsibility to state such things for sure.

To be clear, my purpose with this proposal was exactly to propose a thing that’s as simple as possible (I wouldn’t actually be too emotional over whether this specific idea itself would draw any attention by WG members) just because more complicated things are typically unfortunately ignored by those responsible for speccing and/or implementing as long as the proposals are not by WG members or implementors. (But as I’ve figured out some time ago, WICG itself is currently not a too appropriate place to expect too much (if any) feedback by decision makers. www-style mailing list and/or W3C’s bug tracker are currently probably a better choice. Of course as long as you have some unneeded time which I currently don’t.)


“Forget it [unless …]” is a word of advice coming from someone who participated in www-style for years (though currently inactive) and thus saw many good ideas and objections being shot down on grounds of practicability, compatibility or just eloquent stubbornness – and sometimes picked up again 5 or 10 years later (but usually dead is dead). You’re of course free to choose to ignore my expertise/experience, but then don’t whine about the WG ignoring your ideas as you did above.


FWIW, I did participate/spectate in www-style and public-html for years as well.

It’s unlikely appropriate (and moreso helpful) to use such unfriendly terminology here. As I said, after (but not before) Florian’s comment, I’ve already figured out that WICG is as dead place compared with W3C’s official discussion/proposal ways (mailing lists and bug tracker) like WebPlatform was dead as a documentation source compared with MDN. I had no plans to up this topic (nor posting other proposals) again here, so your another attempt to mentor is unneeded. But looks like you haven’t read all the comments and just hurried to comment to show your “expertise”. Please stop.