- From: Adam van den Hoven <adam@littlefyr.com>
- Date: Wed, 14 Dec 2016 15:27:00 -0800
- 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
- Message-ID: <CAAkH_kOObMAnq1OwAr3ZSWRNESJ1Uj_b2Om6b+0sukMfg80jWw@mail.gmail.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