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: Wed, 14 Dec 2016 15:27:00 -0800
Message-ID: <CAAkH_kOObMAnq1OwAr3ZSWRNESJ1Uj_b2Om6b+0sukMfg80jWw@mail.gmail.com>
To: Tommy Hodgins <tomhodgins@gmail.com>
Cc: Yoav Weiss <yoav@yoav.ws>, "Hall, Charles (DET-MRM)" <Charles.Hall@mrm-mccann.com>, Greg Whitworth <gwhit@microsoft.com>, "public-respimg@w3.org" <public-respimg@w3.org>, Jason Grigsby <jason@cloudfour.com>, Paul Deschamps <pdescham49@gmail.com>, Simon Pieters <simonp@opera.com>, alex@bellandwhistle.net, Jonathan Kingston <jonathan@jooped.co.uk>, steve@steveclaflin.com
sorry I just changed a few things to be somewhat clearer in that HTML
example.

On Wed, Dec 14, 2016 at 3:21 PM, Adam van den Hoven <adam@littlefyr.com>
wrote:

> I'm not saying that you don't *need* a more reliable way than JS or
> padding top on a pseudo element to say that this thing should have an
> aspect ratio of 4/3 or 9/16 or 4/4 or whatever. I'm saying that for the use
> case whereby you want to give the browser enough information to correctly
> layout a page before loading all the resources, signalling the aspect ratio
> (or the true dimensions) of those resources in the HTML is the best and
> only solution (maybe a manifest file that maps resources URLs to a specific
> size but that may be tricky to do efficiently).
>
> Your problem, "I want visual element to have a fixed aspect ratio," is an
> important problem to solve (particularly if you know the height, not the
> width), but its a generalized CSS problem. Aspect ratio of resources
> (images and video) is a different problem that also needs solving. That's
> the problem the alex, I think, is grappling with.
>
> Imagine the following HTML: https://jsfiddle.net/littlefyr/173xmov9/
>
> Simple (naive, I know bear with me) layout. Now imagine that for various
> reasons those images take noticeable time to load.
>
> Your CSS solution cannot give the browser enough information to avoid
> reflow once the images load (which for a non-trivial layout may be hugely
> problematic). The value is *different* for each individual image
> (notwithstanding that I'm using two images twice, pretend I'm not lazy) and
> you cannot reliably put in your external CSS. You'd have to do it for all
> your images on the site (imagine flickr) and it would be painful.
>
> Your only solution (if the only available approach is CSS) is to *inline* the
> aspect ratio on the element. The fact that you have to do this tells you
> that its a CONTENT issue not a design issue. I take it for granted that we
> should try to solve content issues with HTML and design issues with CSS.
>
> Now it may be that a CSS aspect-ratio *may* be a pragmatic solution if it
> only requires ONE set of changes, not two. That's a bit of different
> question, however (how todo something, not what to do).
>
>
> On Wed, Dec 14, 2016 at 2:42 PM, Tommy Hodgins <tomhodgins@gmail.com>
> wrote:
>
>> I'm envisioning this being useful for a lot more than just photographs
>> and pixel-based images or video!
>>
>> It would be a huge benefit to CSS for *all sorts* of use cases to be
>> able to define a desired aspect ratio for any element in a way that's easy
>> to override with other CSS, able to be set or changed with @media queries,
>> and works with the normal states the browser and CSS are aware of for
>> styling, like hover.
>>
>> The HTML attribute doesn't really help me with my responsive design, it
>> seems like I'd still have to do all those hacks and JavaScript juggling for
>> layout stuff, wishing there was an aspect-ratio property in CSS 😟
>>
>>
>> On Dec 14, 2016, at 5:34 PM, Adam van den Hoven <adam@littlefyr.com>
>> wrote:
>>
>> Tommy,
>>
>> What happens when the image that is given that CSS is this one:
>> https://marketplace.canva.com/MAB1YTyBMXY/1/0/thumbnail
>> _large/canva-butterfly-timeline-infographic-MAB1YTyBMXY.jpg (which
>> picked at random from a google search). You're trying to say it is
>> something it is not. Or what if #demo-5 has text in it?
>>
>> CSS should not be concerned with what something *is* only with how the
>> DOM element should appear. Using aspect-ratio in this context makes as much
>> sense as having a file-size attribute to allow the browser to prioritize
>> things.
>>
>> But your demo only *shortcutting* a difficult calculation. Except for
>> the first case, there is no reason not to specify the height and width in
>> both. its always the same fixed number. Its only when you have relative
>> dimension (100% as in demo1) that this has any utility. And I agree that
>> this syntax is better than the padding tricks we do now for that problem.
>>
>> But this is the use case I mean, which I realize is a better answer to
>> Yoav:
>>
>> Given an image of arbitrary aspect ratio, how can I give the browser
>> enough information to lay out the page correctly before loading the image
>> resource if that image is created AFTER I publish the CSS.
>>
>>
>>
>>
>> On Wed, Dec 14, 2016 at 1:28 PM, Tommy Hodgins <tomhodgins@gmail.com>
>> wrote:
>>
>>> I'm curious if it was to be defined in an HTML attribute how you would
>>> target it with a @media query, or with pseudo-classes like :hover? If
>>> it needs to be present in an HTML attribute, can you use it with a
>>> pseudo-element like :before or :after?
>>>
>>> The way I can see this working would be as a CSS property:
>>>
>>> #demo-1 {
>>>   aspect-ratio: 16/9;
>>> }
>>>
>>> #demo-2 {
>>>   width: 200px;
>>>   aspect-ratio: 16/9;
>>> }
>>>
>>> #demo-3 {
>>>   height: 200px;
>>>   aspect-ratio: 16/9;
>>> }
>>>
>>> #demo-4 {
>>>   width: 200px;
>>>   height: 200px;
>>>   aspect-ratio: 16/9;
>>> }
>>>
>>> #demo-5 {
>>>   width: 200px;
>>>   height: 200px;
>>>   aspect-ratio: 16/9 !important;
>>> }
>>>
>>> With a demo here
>>> <https://tomhodgins.github.io/aspect-ratio-spec/demo.html> of what
>>> these should do
>>>
>>> On Dec 14, 2016, at 4:21 PM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>
>>> Can you clarify your use-case? Maybe provide a link for a page that
>>> demonstrates it?
>>>
>>> I'm not clear on which parts should be defined (from your perspective)
>>> in HTML and which in CSS. (e.g. where is width defined? where is height
>>> defined? Are the images constrained by their container? etc)
>>>
>>> On Wed, Dec 14, 2016 at 10:02 PM Adam van den Hoven <adam@littlefyr.com>
>>> wrote:
>>>
>>>> The problem with CSS arises with what you are trying to say. If you are
>>>> saying that the image should be laid our with a certain aspect ratio, then
>>>> the value belongs in the CSS. If, however, you are saying that the image
>>>> resource has a specific aspect ratio then it should come from the resource.
>>>> The HTML is closest to the resource (in a cms, for example) so it should be
>>>> able to declare the aspect ratio.
>>>>
>>>> If we're talking logos or anything that is constant through the life of
>>>> a site (relatively speaking) the CSS is fine. But for content, and content
>>>> is the prime use case I would think, you can't know at "design time" what
>>>> the aspect ratio of all your resources are because content creators either
>>>> don't listen or they forget or they just get it wrong (scaling gave them
>>>> 640 x 479 for some reason).
>>>>
>>>> Allowing the aspect ratio to come from HTML, means your CMS, which may
>>>> already know the aspect ratio, can set it dynamically. Dynamically
>>>> generating CSS is really difficult on a page by page basis (you end up
>>>> rendering the page twice so it's slow).
>>>>
>>>> To be clear. I'm ignoring the idea of inline CSS on the assumption that
>>>> if the dominant use case is inline CSS, then you've just chosen awkward
>>>> syntax for declaring it in HTML. There might be other reasons to do it in
>>>> CSS I just don't think the arguments against doing it in HTML in this
>>>> thread are sufficiently argued.
>>>>
>>>> Is also possible that I'm missing some piece of information
>>>>
>>>>
>>>> On Dec 14, 2016 2:46 AM, "Yoav Weiss" <yoav@yoav.ws> wrote:
>>>>
>>>> I'd like to +1 Greg's concerns regarding adding this to HTML. There's
>>>> no real technical reason to do that (i.e. there are no performance benefits
>>>> to doing so) and the aspect-ratio is required for display of all elements,
>>>> so it makes sense for it to be part of CSS.
>>>>
>>>> On Fri, Dec 2, 2016 at 2:34 PM Simon Pieters <simonp@opera.com> wrote:
>>>>
>>>> On Tue, 29 Nov 2016 17:03:07 +0100, <alex@bellandwhistle.net> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > I’ve been lurking here and just wanted to put two cents in about
>>>> > aspect-ratio.
>>>> >
>>>> > Like most devs here I’ve often dreamed of a way to hint the browser
>>>> > about image proportions during page load, but without fixing either
>>>> > dimension.  I often use padding-boxes for above-the-fold images, to
>>>> > limit layout jumps during load. It works, but it’s a pretty miserable,
>>>> > time-consuming pattern. It seems to me that this is the really urgent
>>>> > use case. Speaking as a user, when I accidentally tap on the wrong
>>>> link
>>>> > because an image just above my finger has suddenly loaded, the
>>>> > irritation factor is really high.
>>>> >
>>>> > Putting together lots of what’s been said, it seems that solution
>>>> needs
>>>> > to be:
>>>> >
>>>> > 1) Attribute-based. The CSS aspect-ratio proposals solve different,
>>>> more
>>>> > complicated problems. They are harder to understand, harder to
>>>> > implement, harder to polyfill. I don’t want to wait five years. Since
>>>> > the ratio is a property of the asset, it should be marked up with the
>>>> > image/video.
>>>> >
>>>> > 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.
>>>> >
>>>> > 3) Distinct from sizes attribute. I don’t see a way to add onto the
>>>> > existing sizes syntax without backwards-incompatible changes. zcorpan,
>>>> > correct me if I’m wrong here? Even if there were a way to do it, I’m
>>>> > worried it would be hard to read.
>>>>
>>>> We can add new things to sizes="" in a backwards-compatible way; the
>>>> sizes
>>>> parsing algorithm was specifically designed to make this possible. In
>>>> particular, items in the list that fail to parse get dropped, so the
>>>> subsequent items can be used as fallback. For example:
>>>>
>>>> <img
>>>>     sizes="(min-width: 40em) something new, (min-width: 60em) something
>>>> new, something new,
>>>>            (min-width: 40em) 60vw         , (min-width: 60em)
>>>> 80vw,          100vw"
>>>>     srcset="examples/images/medium.jpg 375w,
>>>>             examples/images/large.jpg 480w,
>>>>             examples/images/extralarge.jpg 768w"
>>>>     alt="…">
>>>>
>>>>
>>>> > I suggest a syntax that closely parallels sizes, e.g.:
>>>> >
>>>> > <img
>>>> >    sizes="(min-width: 40em) 60vw, (min-width: 60em) 80vw, 100vw"
>>>> >    aspect-ratio=“(min-width: 40em) 3:2, (min-width: 60em) 16:9, 4:3”
>>>> >    srcset="examples/images/medium.jpg 375w,
>>>> >            examples/images/large.jpg 480w,
>>>> >            examples/images/extralarge.jpg 768w"
>>>> >    alt="…">
>>>> >
>>>> >
>>>> > This has the advantage of being familiar, and handles the the
>>>> > “art-direction” use case easily.
>>>>
>>>> If you have different aspect ratios for different breakpoints, then you
>>>> are probably doing art direction, and should be using <picture><source
>>>> media>, not srcset+sizes. I think it makes more sense to have a single
>>>> aspect ratio apply to all assets in `srcset`.
>>>>
>>>> --
>>>> Simon Pieters
>>>> Opera Software
>>>>
>>>>
>>>>
>>>
>>
>>
>
Received on Wednesday, 14 December 2016 23:27:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 14 December 2016 23:27:36 UTC