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: Fri, 16 Dec 2016 10:27:05 -0800
Message-ID: <CAAkH_kMN3=p3S4LFiGdS4TcWhWxXJRQ_5TAdi5tHmudhgCwXew@mail.gmail.com>
To: Steve Claflin <steve@steveclaflin.com>
Cc: Yoav Weiss <yoav@yoav.ws>, Simon Pieters <simonp@opera.com>, Greg Whitworth <gwhit@microsoft.com>, Tommy Hodgins <tomhodgins@gmail.com>, "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 Bell <alex@bellandwhistle.net>, Jonathan Kingston <jonathan@jooped.co.uk>
Yoav's right. I think I had slipped a gear and was thinking art direction
variations, which is handled by the <source> element.

Developer confusion is something that we should avoid and I'm OK with
making things clear although I'm not a huge fan of hyphenated attribute
names without reason. Perhaps, however, following in the footsteps of
data-, we might have hint-aspect on the assumption that at some future date
we might add other hinting attributes for external resources. I can't see
what that might be but my lack of foresight doesn't mean it won't happen.
data- is basically a less verbose namespace, and I think we might want to
resuse that notion.

On Fri, Dec 16, 2016 at 6:46 AM, <steve@steveclaflin.com> wrote:

> Totally agree with this perspective.  To complete what may be implied, in
> picture each separate source could have it's own aspect, but I would then
> say that every url listed in the srcset for one source should share that
> aspect value.
> As a separate note, to avoid developer confusion between initial layout
> hints (HTML) with required layout behavior (CSS), maybe the attribute
> should be something that indicates its nature, like aspect-hint,
> expected-aspect, native-aspect, or something else slightly more verbose but
> clearer.
> On 2016-12-16 00:17, Yoav Weiss wrote:
>> On Thu, Dec 15, 2016 at 11:49 PM Adam van den Hoven
>> <adam@littlefyr.com> wrote:
>> 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
>> That's really not required. There is reason to expect all resources
>> inside of srcset are of the same aspect ratio, as they are supposed to
>> be interchangeable, differing from one another only in dimensions and
>> density (and potentially compression quality). The browser can pick
>> one or the other based on heuristics. If you have different aspect
>> ratios for resources in different dimensions, you should use picture.
>> So I'm suggesting (starting from the Mozilla docs on img [1]):
>>> <img src="clock-demo-thumb-200.png"
>>> aspect="0.75"
>>> alt="Clock"
>>> 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?
>> Yup
>> Links:
>> ------
>> [1]
>> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im
>> g#Example_4_Using_the_srcset_and_sizes_attributes
Received on Friday, 16 December 2016 18:27:41 UTC

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