Bugs on img@srcset filed

Hi All,
The following bugs were filed on behalf of the RICG. If you are listed as an owner, please add yourself to the CC of the bug.

Huge thanks to everyone who logged into the ether pad and helped out with the wording of each.

What happens now?
Mat and I will be reaching out individually to browser makers to comment on each bug. WHATWG (Hixie) has made it pretty clear that without clear backing from browser vendors none of the bugs will receive any attention (or will be closed with no action).

IMPORTANT: If you know someone who works for a browser maker, now is the time to lobby them about the importance of these bugs. Browser makers are not required to say that they will implement any of them, but it is important that they provide their opinion (either for or against).

Bug 20172 - “Art direction” use case not well supported
===========================================
URL: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20172
Owners: Aaron Gustafson

Although img@srcset supports the resolution matching use case in a limited way, it does not fully support the art direction use case. To support the the art direction use case, there needs to be some mechanism in place to force the browser to display a given image when a condition is met. This is akin to the use case for CSS's !important rule.

See: http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ )

For detailed description of use case, see also: http://usecases.responsiveimages.org/#art-direction

Bug 20173 - No way to determine which source is being displayed
================================================
URL: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20173
Owners: Marcos Cáceres

The img@srcset spec lacks a script-based means to determine what resource the image element is displaying (if any). The use case for this is for testing and generally for a developer to know what is going on.
See: http://usecases.responsiveimages.org/#api-to-manipulate-sources


Bug 20174 - Lacks way to support different image types
=========================================
Owners: Agustin Amenabar
URL: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20174

The img@srcset spec currently lacks a way for alternative image formats to be supported. This means that content negotiation must be done on the server, which is known to be problematic ( see: http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Nov/0309.html ). Or it must be done on the client using a whole bunch of nasty hacks (e.g., downloading a 1x1 pixel image, seeing if it's supported, etc.).

See also: http://lists.w3.org/Archives/Public/public-respimg/2012Oct/0069.html


Bug 20175 - Lacks means to sensibly manipulate sources
==========================================
Owners: Marcos Cáceres
URL: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20175

The img@srcset solution lacks a means to programmatically interface with image resources, as well as access relevant attributes and methods that make the solution practical to work with (i.e., it shouldn't require Regex or nested loops to manipulate values).

See: https://gist.github.com/9f3ced6a91d7390b080d

Bug 20176 - Syntax only supports mobile first
==============================
Owners: grigs?
URL: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20176

The img@srcset does not afford developers the ability to define the breakpoints for images as either minimum values (mobile first) or maximum values (desktop first) to match the media queries used in their design.

See: “Secret src” http://adactio.com/journal/5474/

Bug 20177 - Spaces in candidates
=========================
Owners: ???
URL: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20177

The img src attribute and srcset behaves different when presented with spaces: for example, "Screenshot 10.2.2012 100 1x 2x Funny Cat.jpeg" in @srcset results in "Screenshot" as the candidate. However, when fed to img@src, the resource name is parsed as expected.

Confirmed by: http://responsiveimagescg.github.com/picture-refimp/demo/?srcset=Screenshot+10.2.2012+100+1x+2x+Funny+Cat.jpeg  

--  
Marcos Caceres

Received on Friday, 30 November 2012 16:52:29 UTC