W3C home > Mailing lists > Public > public-respimg@w3.org > December 2016

Re: aspect ratio as an attribute

From: Adam van den Hoven <adam@littlefyr.com>
Date: Thu, 15 Dec 2016 14:49:15 -0800
Message-ID: <CAAkH_kP888-QD04qixzKR75=SOJhBNNju_qg1CnYVK5xLD3bhA@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Greg Whitworth <gwhit@microsoft.com>, Tommy Hodgins <tomhodgins@gmail.com>, Yoav Weiss <yoav@yoav.ws>, "Hall, Charles (DET-MRM)" <Charles.Hall@mrm-mccann.com>, "public-respimg@w3.org" <public-respimg@w3.org>, Jason Grigsby <jason@cloudfour.com>, Paul Deschamps <pdescham49@gmail.com>, "alex@bellandwhistle.net" <alex@bellandwhistle.net>, Jonathan Kingston <jonathan@jooped.co.uk>, "steve@steveclaflin.com" <steve@steveclaflin.com>
On Thu, Dec 15, 2016 at 1:32 PM, Simon Pieters <simonp@opera.com> wrote:

> On Thu, 15 Dec 2016 19:49:37 +0100, Greg Whitworth <gwhit@microsoft.com>
> wrote:
> I submit that if you're using a CMS with non-technical content authors who
>>> are not the designer (that is every commercial website ever created, and
>>> most blogs run by non-technical folks with some free Wordpress theme) then
>>> have no guarantee that the image as uploaded to the CMS will possess the
>>> specified aspect ratio without some sort of distortion (either by CSS or by
>>> some server process that crops the image accordingly).
>> I don’t understand how HTML solves this problem, whether it’s in CSS or
>> HTML the hint will need to be provided by the site author and yes will
>> probably be done via a server side process.
>> In his original post, Alex said: "2) Only a hint during load. Once the
>>> asset (metadata) is loaded successfully, the actual aspect-ratio of the
>>> asset takes over. If the image fails to load, the image’s box retains the
>>> hint. This fails gracefully, in cases of sloppy authoring. It also allows
>>> conventional stretching via CSS, as Tommy Hodgins has requested. Basically,
>>> it should do its job and then get out of the way." (emphasis mine)
>> This is a great point, that said there is nothing stopping us from making
>> it so that the CSS property can accomplish this and we should ensure that
>> the CSS property is able to do this. I would prefer to not have an HTML
>> attribute that behaves differently than the CSS property.
> It would not need to behave differently. If there are good reasons to have
> an HTML attribute (I recall someone mentioning lint checkers being able to
> check HTML attributes but not so much parse and apply CSS), we can define
> it as a "presentational hint" attribute that just maps to the CSS property.
> A lot of HTML presentational attributes do this.
> We probably need to come up with something for <source> if we want to be
> able to specify different aspect ratios for different <source>s, though...
> Styling the source element itself is no good. :-)

srcset also poses a problem (there's no reason to expect that a particular
sized resource has the same aspect ratio as the rest) but if the
aspect-ratio that alex proposed only describes the aspect ratio of the
resource in src, an add aspect-ratio-set that matches src values in src set
with an aspect ratio, we'd have a consistent solution. the hyphation in the
attribute names are a pain so i'd use aspect and aspectset

So I'm suggesting (starting from the Mozilla docs on img

<img src="clock-demo-thumb-200.png"
      srcset="clock-demo-thumb-200.png 200w, clock-demo-thumb-400.png 400w,
clock-demo-thumb-unknown.png 500w"
      aspectset ="0.75, 1, default"
      sizes="(min-width: 600px) 200px, 50vw">

The logic being, if only aspect-ratio exists, it applies to all the src
values (src and srcset). If defined aspect-ratio-source only applies to the
srcset items. the default keyword is "we don't know what it its", ie the
current behaviour. If there are more srcset values than aspectset values,
either apply the last value, or the aspect value or maybe start over from
the first and apply them in turn. Not sure what's best. (I'm agnostic about
implying computation with 4/3 vs 1.333)

But that's possibly making it a LOT more complex than necessary?

> Simon Pieters
> Opera Software
Received on Thursday, 15 December 2016 22:49:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:20 UTC