Re: srcN - Alternative to picture and srcset

Catching up on the proposal today. Happy to see the stuff John Mellor
mentioned on the WhatWG list almost a year ago finally getting addressed.

One thing I wondered about was the syntax in the viewport use case (
http://tabatkins.github.io/specs/respimg/Overview.html#viewport). Here is
Tab's example code:


  <img src-1="100 30em 400 70em 50%;
             pic50.png 50, pic100.png 100, pic200.png 200,
             pic400.png 400, pic800.png 800, pic1600.png 1600,
             pic3200.png 3200">

I find the first part of this to be difficult to parse. '100 30em 400 70em
50%' In order to read it, I have to pair off each. And it will get more
confusing if the author doesn't conveniently switch between pixels for
image sizes and ems for media queries.

May I suggest commas to clarify which sizes and viewports values are paired:


  <img src-1="100 30em, 400 70em, 50%;
             pic50.png 50, pic100.png 100, pic200.png 200,
             pic400.png 400, pic800.png 800, pic1600.png 1600,
             pic3200.png 3200">

-Jason




On Tue, Oct 1, 2013 at 11:30 AM, Marcos Caceres <marcos@marcosc.com> wrote:

>
>
>
> On Friday, September 27, 2013 at 6:15 PM, matmarquis.com wrote:
>
> > [ snip ]
> >
> > >
> > > >
> > > > > 3. In non-supporting browsers, the src image always will be http
> > > > > prefetched,meaning a polyfill for this syntax may not be able to
> avoid
> > > > > wasteful overhead. Element based approaches like picture can avoid
> overhead
> > > > > through use of noscript wrappers on fallback content. Could srcN be
> > > > > polyfilled without waste?
> > > >
> > > >
> > > > To an extent. If you avoid use of src entirely and polyfill with
> > > > script in downlevel browsers, you'll get good behavior in new
> > > > browsers, okay (script-gated) behavior in older browsers running
> > > > script, and failure in older browsers without JS.
> > > >
> > > > Alternately, a similar strategy to what you described can be used:
> > > >
> > > > <img src1="..." src2="...">
> > > > <noscript><img src="..."></noscript>
> > > >
> > > > This is then similar to the behavior of your proposal - it's good in
> > > > up-level browsers running script and down-level browsers not running
> > > > script, okay in down-level browsers running script, and bad in
> > > > up-level browsers not running script (as both images will be shown).
> > > > This last problem could probably be worked around by adding a
> > > > src1="0x0_image.png" to the fallback, so the image still shows up in
> > > > the page, but doesn't display.
> > > >
> > > > ~TJ
> > >
> > >
> > > I can dig it up to confirm, but I thought there were existing
> (popular) browsers that will make a wasteful HTTP request on <img> even if
> a src attr is omitted? Perhaps someone else can chime in.
> >
> > It looks as it if isn’t entirely uncommon, based on
> http://www.nczonline.net/blog/2010/07/13/empty-string-urls-browser-update/
> >
> > I wrote up some of my initial thoughts on potential polyfill patterns at
> https://etherpad.mozilla.org/polyfilling-srcN — I’d love to get more eyes
> on it.
> Some more discussions going on here:
> https://gist.github.com/bjankord/6781503
>
>
>


-- 
+1 (503) 290-1090 o | +1 (503) 502-7211 m | http://cloudfour.com