Re: Stretchy images shouldn't require media queries

First of all, sorry for entering into this rather late and thanks for pointing me to some of the earlier discussions; it's perhaps comforting to know that arguments for layout-independent responsive image markup have been made before.


On Tuesday, November 6, 2012 at 10:30 AM, Matthew Wilcox wrote:

> That is something I have brought up previously, but after much consideration there wasn't a clear idea of how to address the problem without introducing great complexity (the only solution I could come up with has its own issues, and could well be a rabbit hole, but if you're interested: http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ ). I believe DRY principles were deemed too problematic at the moment and focus was put onto getting a working <picture> instead, with the aim to address the DRY problem later. Which I think is the most practical way to go about it at the moment, but if you have any ideas I for one would love to hear them.


I'm all for HTML variables. I'll hazard a complete & wild guess that it hasn't happened because most of the repetition that happens in HTML is already being mitigated via variables in php or ruby or whatever language people are using to dynamically generate most of the HTML that gets sent over the wires.

Being able to set these variables via media-queries and have them available in css/js would be totally new, though, and totally handy for all sorts of things (at the cost of portability and self-containment). Unfortunately, it wouldn't allow us to mark up content images in a completely layout-agnostic way… you simply end up with one layout-dependent set of media queries in the <head> to change instead of dozens and dozens of repetitive ones in your <source>s or srcset=""s. Cleaner & easier: surely, but still fragile re: layout changes.  

> > You seem to suggest that it's not simply a problem of waiting until the CSS is in, but something more fundamental? My hacky little script seems to be working (it decides which resource to load based on the parent element's width & the viewport's height, calced after jQuery's 'ready' event)… I'm trying to conjure scenarios in which a paradoxical-circular-definition comes into play, but can't quite wrap my brain around it. Any examples?
>  
> The problem was discussed here: http://www.w3.org/community/respimg/2012/05/16/shouldnt-we-be-defining-content-not-context/ You might find the discussion useful, and it'd be great if you had any further insights into it :)
  
*If* we're okay with waiting for the CSS (a big if, apparently) wouldn't it simply be a matter of defining default styling for <picture> or <img srcset=''"> elements? Every flow-content element has default styles. They make a certain sort of sense but are essentially arbitrary:

<div>
width: 100%; height auto; (height expands to contain descendants)

<span>
width: auto, height: auto; (expands to contain descendants)

<img>
width: auto; height: auto; (fits dimensions of src content in cs-px)

...perhaps most arbitrarily...

<canvas>
width: 300px; height: 150px; (falls back on 1 css-px per unit in the canvas coordinate system, and if there is none specified via height="" and width="" attributes this defaults to 300x150, just to default to something…)

A possible set of defaults for a responsive images element:

<picture>
width: 100%; height: auto; (height expands to show the whole image)

<picture style="display: inline;">
width: auto; height: auto (fits dimensions of smallest image resource in css-px)

I could see an argument for adding an implicit max-width: (width of largest resource in css-px), too.


—eric

Received on Saturday, 10 November 2012 19:01:17 UTC