Skip to content

Instantly share code, notes, and snippets.

@bjankord
Last active December 24, 2015 10:08
  • Star 5 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save bjankord/6781503 to your computer and use it in GitHub Desktop.

Creating a new element named picture or pic that mirrors the img element would allow for an easier responsive image element to polyfill.

When polyfilling srcN paired with the image element, legacy browsers which don't support srcN would download the image from the src attr and the matching srcN attr. This would result in dual downloads in legacy browser which need the srcN polyfill. These "legacy browsers" are every browser today.

A few ways around this would be to leave the img src attr empty. Or remove it all togher.

From Riloadr docs, Túbal Martín has some concerning notes about leaving the src attr empty on img elements.

Warning!: Do not set an empty string for the value of src src="". Some browsers react to this by assuming the empty string means src="/", and consequently the browser re-requests the current >HTML page and tries to stuff it into the element. This is bad news for performance.

So leaving the src attr empty is a no go. I'm not 100% sure if there are issues with removing the src attribute altogher from the img element. I feel like some browsers will add the attribute back which would leave us with an empty src attribute.

I've put a demo together to do some testing when the img src is empty/removed altogether which can be found here.

If you could use scrN on a element besides img, it would resolve some concerns with polyfilling a srcN solution.

Update 0.1.0

It looks like in IE, IE11 - IE7, no image icons show up if you leave the src attr empty on an image or leave it off altogher. This may be a mute point as the src attribute would be populated or added back with the polyfill. Users without JS will see all those lovely icons in IE though. IE users and users without JS, two groups people really care about.

I've reached out to Tubal to see if he can give some more info about what browsers have issues with empty src attributes on the img element. I've also updated the markup to use pic instead of picture per request.

Update 0.1.1

Additional resources:

http://www.nczonline.net/blog/2009/11/30/empty-image-src-can-destroy-your-site/

http://www.nczonline.net/blog/2010/07/13/empty-string-urls-browser-update/

https://github.com/Wilto/srcn-polyfills

https://github.com/jonathantneal/respimg

scottjehl/Device-Bugs#3 Read note about "or the image src is invalid"

Creating a new element would allows us to leave the oddities of images with empty or no src attribute behind.

// Default use
<pic src-1="(min-width: 1150px) pic-large.jpg"
src-2="(min-width: 500px) pic-medium.jpg"
src="pic-small.jpg"
alt="Obama talking to a soldier in hospital scrubs.">
// No JS fallback/Markup used to build polyfill
<pic src-1="(min-width: 1150px) pic-large.jpg"
src-2="(min-width: 500px) pic-medium.jpg"
src="pic-small.jpg"
alt="Obama talking to a soldier in hospital scrubs.">
<noscript><img src="pic-small.jpg" alt="Obama talking to a soldier in hospital scrubs."></noscript>
@marcoscaceres
Copy link

I'm confused as to why you would remove src?

The example above is bad (and yes, I know Tab has it in the spec) because it assumes you serve the big image to legacy browsers. Legacy browsers should only get either small or a well compressed medium.

@scottjehl
Copy link

A small src image might be a more appropriate default for RWD/mobile-first thinking, but it'd work either way right? picture[src] isn't a legacy concern like img[src] is.

@beep
Copy link

beep commented Oct 1, 2013

+1 @scottjehl.

I really like this proposal, FWIW. Feels like a great compromise, and avoids the doubled-up request liability of srcN.

@bjankord
Copy link
Author

bjankord commented Oct 1, 2013

@marcoscaceres Someone had done some research on this a while back, but the basic idea is that in some browsers, removing the src attr from an img element resulted in either browser creating a 404 http request I believe for the img, or other odd issues.

@scottjehl Yea, small image would be the way to go. I grabbed the srcN markup from Tabs spec, but I would personally start with a mobile image for my default.

@beep - Thanks, yeah the main thing here is preventing extra http requests and other issues with pairing srcN with a img element.

@zigotica
Copy link

zigotica commented Oct 1, 2013

i like it overall. much cleaner than current polyfill. what about something like:

// Default use

<picture src="pic-small.jpg"
         sources="(min-width: 400px) pic-medium.jpg,
                    (min-width: 1000px) pic-large.jpg"
         alt="Obama talking to a soldier in hospital scrubs.">

// No JS fallback/Markup used to build polyfill

<picture src="pic-small.jpg"
         sources="(min-width: 400px) pic-medium.jpg,
                    (min-width: 1000px) pic-large.jpg"
         alt="Obama talking to a soldier in hospital scrubs.">
<noscript><img src="pic-small.jpg" alt="Obama talking to a soldier in hospital scrubs."></noscript>

since we will be using javascript anyway to build the thing, keeping one attribute only is much cleaner/easier to parse (split ,)

@bjankord
Copy link
Author

bjankord commented Oct 1, 2013

@zigotica, I like the sources attribute idea. I'm not familiar with the browser implementation side to say if that would be better or not, but from a developer side, I like it.

@bjankord
Copy link
Author

bjankord commented Oct 1, 2013

@marcoscaceres I guess you wouldn't need to remove the src if srcN is used on a new element like picture/pic. I've also reworked the example so it's mobile-first. I'm curious to see Tab's and Hixie's feedback on this.

@Wilto
Copy link

Wilto commented Oct 1, 2013

@zigotica: Splitting on commas would break data-URIs (and splitting on Nth-spaces will lead to authoring chaos), so I get the appeal of stand-alone srcN attributes or source elements.

Also worth noting that the srcN pattern introduces an author-controlled selection order (“First match, starting with src1 and working up”), rather than just source order.

@zigotica
Copy link

zigotica commented Oct 1, 2013

@Wilto hmmm, i see :(
still, much cleaner and less verbose than current picturefill

@zigotica
Copy link

zigotica commented Oct 1, 2013

…current picturefill which i love, just for the record @scottjehl :)

@nwtn
Copy link

nwtn commented Oct 1, 2013

to re-iterate a point i made on twitter: since there's already a syntax we know/love as picture, maybe this could use pic or something else for the time-being, just so we have an easy way of distinguishing it in discussion from the existing picture syntax. (and also possibly avoiding some of the picture animosity that's out there.)

@bjankord
Copy link
Author

bjankord commented Oct 1, 2013

@nwtn I've switched the markup to use pic instead of picture to make it more clear when talking about responsive image solutions.

@adamdbradley
Copy link

@bjankord @nwtn <imagen> ?? (bonus points for being the spanish word for image)

@nwtn
Copy link

nwtn commented Oct 1, 2013

@bjankord Awesome. I'm really digging this.

One of my reservations with src-N was the ability to do file type switching, but Tab has tweeted about that. I'm not familiar enough with image-set to know if the same idea would work here. Thoughts?

@tabatkins
Copy link

Yes, it would work fine. You'd just do something like src-1="foo.webp 1x type('image/webp'), ...". The source selection algorithm would delete images with unknown types, and reject the whole attribute (moving on to the next) if nothing was known at all.

@bjankord
Copy link
Author

bjankord commented Oct 1, 2013

@nwtn Yes, I hadn't seen much on file type negotiation that was in picture with scrN yet, but I think it is very important to a responsive image markup solution. Curious to see what Tab comes up with.

@zigotica
Copy link

zigotica commented Oct 1, 2013

@Wilto what about splitting on semicolons? ie sources="(min-width: 400px) pic-medium.jpg;(min-width: 1000px) pic-large.jpg;(…);foo.webp 1x type('image/webp')" kind of thinggie. Isn't src-N still too verbose?

@johnholtripley
Copy link

This still has every MQ repeated for every image which isn't very DRY. Presumably there's no reason for this not working with MQ variables though?
http://lists.w3.org/Archives/Public/public-respimg/2013Sep/0036.html

@ShaneHudson
Copy link

There has been much (or not enough, depending on who you talk to) discussion about using CMSes as the primary way to create content. So in that respect, the MQ being repeated on every image would quite easily be able to be a variable... not the perfect solution, but one that would work for the majority of cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment