Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

File bugs at the W3C against individual use cases. #22

Wilto opened this Issue Nov 14, 2012 · 4 comments


None yet
2 participants

marcoscaceres commented Nov 16, 2012

@Wilto can you post some text for each use case that we can then file as bugs? Either here or on and etherpad. That way, we can have a few more folks contribute.


marcoscaceres commented Nov 28, 2012

@Wilto and I started work on this: https://etherpad.mozilla.org/tRAjqKY1XG


marcoscaceres commented Nov 28, 2012

Emailed list for feedback.


marcoscaceres commented Dec 1, 2012

Bugs filed. Details are on the mailing list.

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

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