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
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
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
box-sizing and related
max- properties (which are different from proposed
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.
I posted a question about this on SO 3 years ago, happy to see this being proposed.
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
@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?
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
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™.
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.
[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).
This specifies that:
- one ‘…-size-dimension’ specifies inline/block-size to be the same
- two ‘…-size-dimension’ specifies them each respectively
- ‘inline-size’/‘block-size’ respecively
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?
I have created a quick demo of how the attribute would work here:
(Works in Chrome and Firefox, Safari not currently supported)
@jonathank, would you like to begin formal incubation? If so, I’ve sent you an invite to the WICG so you can transfer the repository over.
Would you be willing to continue to drive it? Eventually it would need to go to the CSS WG.
Yup totally happy to move it over and drive it. The RICG is interested in the outcome of the work as well as coming up with usecases for implementing aspect ratios:
Also Github requires me to have admin access to move the repo over now
As a quick update the demo has moved: https://wicg.github.io/logical-sizing-properties/demo/index.html
And the draft proposal: https://wicg.github.io/logical-sizing-properties/