- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 19 Dec 2016 12:16:54 +0100
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: "Adam van den Hoven" <adam@littlefyr.com>, "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 Mon, 19 Dec 2016 04:29:18 +0100, L. David Baron <dbaron@dbaron.org> wrote: > On Thursday 2016-12-15 22:32 +0100, Simon Pieters wrote: >> On Thu, 15 Dec 2016 19:49:37 +0100, Greg Whitworth >> <gwhit@microsoft.com> wrote: >> > > 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. > > I don't think this is necessarily the desired approach here. > > I think it was a design mistake in the early days of HTML that the > height and width attributes on img overrode the intrinsic sizes of > the image, rather than just being hints for when the image was > loading. This has led to many unintentionally-scaled images, and > a decent number of images that use way more bandwidth than needed. > > Had that mistake not been made, mapping the height and width > attributes on img into the 'height' and 'width' CSS properties > wouldn't have made sense. They would have instead mapped to > intrinsic dimensions (as defined in > https://drafts.csswg.org/css-images/#sizing-terms ). > > > Wanting a way to describe the intrinsic size of an external resource > so that relayout doesn't happen when the resource loads is a useful > goal. Making the mechanism for that have effects after the resource > has loaded, or interacting with the CSS model in any way other than > providing intrinsic dimensions (as defined above, including > intrinsic aspect ratio) prior to the resource being loaded, > complicates the mechanism and causes it to have undesired effects > for the simple (and important) use case of avoiding relayout. > > This seems like it might become more important as developers do more > responsive things with images using some of the new mechanisms > available in CSS (e.g., object-fit/object-position, flexbox, grid, > and correct implementation of min/max-height/width). Yeah, I think you are right. We also still have an opportunity to map to intrinsic dimensions for <source>. Still, the behavior you describe could also be (new) CSS properties, possibly useful for generated content. -- Simon Pieters Opera Software
Received on Monday, 19 December 2016 11:17:38 UTC