Shorthand for width/height CSS longhands


#8

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.


#9

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.


#10

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


#11

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.


#12

Good point, thanks Florian.


#13

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


#14

+1


#15

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… */

#16

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


#17

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


#18

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


#19

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


#20

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.


#21

I posted a question about this on SO 3 years ago, happy to see this being proposed.


#22

At the risk of upsetting people for reopening an old topic, I thought I would mention I think this has lot benefit especially as logical properties come in rather than writing inline-size and block-size.

@Crissov’s proposal of making the shorthand more useful as in #15 makes sense to me:[quote=“Crissov, post:15, topic:1160”] 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… */ [/quote]

Where: height = block-size width = inline-size min-height = min-block-size min-width = min-inline-size max-height = max-block-size max-width = max-inline-size

Currently aspect ratios are defined as a hack using padding it would be nice to assist these in a single property @tabatkins has there been any progression of aspect-ratio I can’t see anything on the mailing list since 2014?


#23

Considering de-facto tempos of considering interesting ideas™ (moreso third-party proposals) in the world of web standards, a year or two ago is far from being old, it is a very, very recent. For example, after 10 years, we still don’t have a way to override a specific background layer without having to respecify all the layers.

Substantively, complicating things usually may make sense after a simpler thing is already accepted, specced, and implemented, but we are far even from that here.

As for aspect ratio (which I believe should be discussed in a separate topic though, as long as discussing anything at WICG makes sense at all), ability to preserve aspect ratio without a necessity to specify an explicit ratio in CSS would be useful on its own:

currently, if an image has both width and height specified (to reserve page space for the image so that page jumps once the image has been loaded are prevented), there is no way to preserve original aspect ratio when e.g. max-width is applied to the image, effectively overriding the original width while not affecting the original height. To prevent having disfigured proportions in such situations, we could use something like aspect-ratio: preserve (or aspect-ratio: original, or anything else, exact keyword doesn’t matter). But I’m almost sure there will be no such ability for many more years since those responsible are busy working hard on more important things™. :wink:


#24

You don’t have to be a dick about…

width/height shorthand is a great idea if you ask me. WICG was called to life to not make things last a gazillion years before they’re specced or implemented.


#25

[quote=“Michiel, post:24, topic:1160”]width/height shorthand is a great idea if you ask me.[/quote]Fwiw, I don’t care much about the size shorthand itself (this proposal was more like a sort of WICG test for me), but I’m glad you think this would be useful.

[quote=“Michiel, post:24, topic:1160”]WICG was called to life to not make things last a gazillion years before they’re specced or implemented.[/quote]We can have very good goals, but what actually matters is substantive results. For now, WICG looks like just a way to separate community of web-developers from community of implementors and spec editors (who are still using mailing lists).


#26

I roughed out a specification for this here which clears up @tabatkins’s definition of aspect ratio using newer terms as found in logical properties and the in-flow and out-of-flow usage in flex etc.

This specifies that:

  • one ‘…-size-dimension’ specifies inline/block-size to be the same
  • two ‘…-size-dimension’ specifies them each respectively

…-size-dimension:

  • ‘inline-size’/‘block-size’ respecively
  • ‘aspect-ratio’
  • ‘min-…-size’/‘max-…-size’
  • ‘min-…-size’/‘inline-size’/‘max-…-size’

This should alow developers to quickly specify max and min without needing to specify the main size.

@marcosc would you be able to have a quick look over this when/if you get a chance?


#27

I have created a quick demo of how the attribute would work here:

https://jonathankingston.github.io/logical-sizing-properties/demo/index.html

(Works in Chrome and Firefox, Safari not currently supported)