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 11:29:20 -0800
Message-ID: <CAAkH_kMMwDmJUnPQDRU1Yf9mRRg8hg=z4q5eFBhtO=APu7iX=A@mail.gmail.com>
To: Greg Whitworth <gwhit@microsoft.com>
Cc: 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>, Simon Pieters <simonp@opera.com>, "alex@bellandwhistle.net" <alex@bellandwhistle.net>, Jonathan Kingston <jonathan@jooped.co.uk>, "steve@steveclaflin.com" <steve@steveclaflin.com>
There are all sorts of things you *could* put into CSS but we don't because
they rightly belong in content. We dont do it because it doesn't make
sense.

I tend to apply the following rules when deciding whether something should
be CSS or HTML:

   - If something is content, it belongs in HTML, if its style it belongs
   in CSS
   - If something varies page by page or day by day its content, otherwise
   its style.

Since the resource being shown will vary page by page, its content so
*ideally* you put it in HTML.

That is just to say that it's not *wrong* to put it in HTML, and I would
argue its preferred. HTML/CSS/JS have suffered because something was
naively put into the wrong spec (<font>, <blink> come to mind). Since the
intrinsic aspect ratio is something unique to the resource indicated in the
src attribute (and only images and videos have an intrinsic aspect ratio)
and that property of the resource is independent of how or where its used
in any given page of your site (just like the alt text is independent
metadata of the resource not the <img> the image is referenced in) we
should *prefer* to put it in HTML unless a good argument can be made
otherwise.

I don't think that, "well we want to do similar things with any element so
lets glom them together because they look alike" is a sufficient argument.

Arguments about spec purity can be more harmful than beneficial, I realize,
but I think that the mixing of uses here warrants some more discussion.

Adam

On Thu, Dec 15, 2016 at 10:49 AM, 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.
>
>
>
> We could potentially solve the hinting issue by allowing something like
> this:
>
>
>
>      aspect-ratio: 4:3 auto
>
>
>
> So if it is a replaced image and on our first pass we don’t have enough
> information from the image we layout with an aspect ratio of 4:3, once the
> image loads we fallback to what the image’s aspect ratio is. If you are
> wanting to ensure that this is guaranteed to be in the first layout then
> yes you’ll probably want to inline it rather than it be an external
> stylesheet. That makes the CSS prop a 1:1 equivalent to the HTML attribute,
> but has the power of now being able to control other boxes that don’t have
> an intrinsic aspect ratio but you want to ensure they maintain one.
>
>
>
> ~Greg
>
>
>
> *From:* Adam van den Hoven [mailto:adam@littlefyr.com]
> *Sent:* Thursday, December 15, 2016 9:55 AM
> *To:* Greg Whitworth <gwhit@microsoft.com>
> *Cc:* Tommy Hodgins <tomhodgins@gmail.com>; Yoav Weiss <yoav@yoav.ws>;
> Hall, Charles (DET-MRM) <Charles.Hall@mrm-mccann.com>;
> 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
>
> *Subject:* Re: aspect ratio as an attribute
>
>
>
> Ok, you can, but only if you do something like:
>
>
>
> img[src=/image/foo.png]{aspect-ratio: 3220/562;}
>
> img[src=/image/logo.png]{aspect-ratio: 100/210;}
>
> img[src=/image/logo-large.png]{aspect-ratio: 1000/500;}
>
>
>
>
>
> And so on. That is if you want to say that the source image is a specific
> aspect ratio, you have to list all the image files and explicitly state
> their aspect ratios. While photos tend to have a narrow range of aspect
> ratios, creative images (logos, infographics, etc) have no intrinsic aspect
> ratios so in *practice* you have to list all the images. if you're going
> to put that into your external CSS then you have list all the images on
> your site and any externals that might be loaded. If you're Flickr, that's
> a HUGE file.
>
>
>
> Your only real choice would be to inline the css: (<img
> src='/image/foo.png' style='aspect-ratio:3220/562' />) but this makes it a
> content issue, even though we've set it in CSS. Except for ease of
> implementation, there is no benefit to <img src='/image/foo.png'
> style='aspect-ratio:3220/562' /> vs <img src='/image/foo.png'
> aspect-ratio='3220/562' />
>
>
>
> Keep in mind, I'm trying to say "The source image has this aspect ratio,
> take this into account when laying out the page" vs. "I want this element
> to be laid out so that it has this aspect ratio". The two are not
> *necessarily* the same thing. Its *likely* the same thing unless you want
> to distort the image or its a well build SVG, but unless you have *a
> priori* knowledge of those aspect ratios you're hooped. 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).
>
>
>
> And here's the other thing to consider.
>
>
>
> 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)
>
>
>
> Nothing of what, for example, Tommy suggested can meet that requirement,
> and rightly so. A CSS attribute should be permanent property of the thing
> it is assigned to. It *should* make sense to allow
>
>
>
> .mediabox{
>
> aspect-ratio: 1/1;
>
> }
>
> .mediabox:hover{
>
> aspect-ratio: 3/4;
>
> }
>
>
>
> For this very reason (unless you want aspect ratio to have a *different* meaning
> for replaced elements which I think we can agree is a bad idea) a CSS
> property doesn't solve the problem alex raises. You would need to have
> something like aspect-ratio-hint to distinguish the two different purposes.
>
>
>
>
>
>
>
>
>
> On Thu, Dec 15, 2016 at 9:14 AM, Greg Whitworth <gwhit@microsoft.com>
> wrote:
>
> Maybe I’m missing something, but why is this the case?
>
>
>
> > Your CSS solution cannot give the browser enough information…
>
>
>
> ~Greg
>
>
>
> *From:* Adam van den Hoven [mailto:adam@littlefyr.com]
> *Sent:* Wednesday, December 14, 2016 3:27 PM
> *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; 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
> *Subject:* Re: aspect ratio as an attribute
>
>
>
> 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 Thursday, 15 December 2016 19:29:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 December 2016 19:29:57 UTC