I worry that this might be over reaching:

"Provide user agents with information they need to select the most appropriate image source given low bandwidth situations"

As it reads, to me, it appears you want this spec to do some kind of adaptive bandwidth detection. As Floarian pointed out in his email, that is extremely problematic.

I think this goal needs to be rewritten or further considered.

The following "goal" describes fairly explicit behaviour:

The appropriate asset must be fetched by way of a single request, initially. A change in window size causing the media attribute to match an alternate source should trigger a request for said source (to be retrieved from the browser cache, if possible).

As I've mentioned in other bugs, this should really be in an algorithm.

So, although this repo started as a side project to help us get organised, it's kinda becoming our defacto home. However, the name "draft-prop" is kinda served it's purpose so it might be time to rename or move this project.

Minor: fulls stops missing in bullet points.

Not clear how picture interacts with image maps.

Do we want to refer to window resizes in the spec?
When should the browser replace the current resource with a different one?
Should it do that every time that the matching MQ is no longer the current one and the matching MQ indicates a screen bigger then the current one?

We certainly don't want the browser to reload the image when the window is downsized.
Including the resources' dimensions in the markup (e.g. <source height=X width=Y>) can help browser make an informed decision whether they should download the resource or not, but they'd be a hassle for web devs.

Quick bug: Missing hyperlink to "art direction use case" in last para of intro :)

The spec says (my emphasis):

This proposal allows content authors to provide user agents with the information they need to select the best image source.

The word "best" there is problematic, as it's really the algorithmically "most suitable". Either the terminology needs to be changed or "best" needs to be formally defined.

Additionally, the assertion above does not answer the question "for what?"... as in "the best image source for [...primary use case goes here...] ".

Then says (again, my emphasis):

The best image source may be an image sized appropriately for the display size or pixel density. Or the best image source may be a different version of an image that has been modified by the author to be suitable for a particular use (see: art direction use case).

The above attempts to begin a formal definition for "best image source". I think it is problematic to do this in the introduction (or at least in it's current form).

The spec duplicated attribute definitions from HTML5 for source element. It actually also copied the source element into this spec. It's not good to replicate text, so I have removed it and only left "the srcset" attribute.

The specification fails to identify a product. We may chose to have one or two products. To follow HTML, we should probably have two products:

This specification describes the conformance criteria for user agents (relevant to implementors) and documents (relevant to authors and authoring tool implementors).

The first example of the <picture> element should not show the source attribute. It should show just how it can be used on its own.

Excuse my ignorance, but can we really reuse <source>? We are adding a new attribute (srcset), and that may end up confusing authors.

For example, what if an author now thinks they can use the srcset attributes on <video>'s <source>? As in, "ok cool, I'll deliver a custom video too for iPad! awesome <source srcset=... >". That might not be a bad idea :)

My worry is that we are changing the behaviour of an element to be very context specific so that might warrant a specific <imgsource> elelment. Just thinking/questioning out loud here.

Sorry if this has been discussed before!

We need to show how the solutions compare with each other with meeting the above use case.

There may be some issues with picture elements interacting with forms (relating to input type=image). Need to investigate further.

We need to show how the solutions compare with each other with meeting the above use case.

The name of the spec is wrong, should be "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"; not "Media Queries" :)

Where possible, avoid versioning for citations/refs (e.g., HTML5 -> HTML, CSS4-IMAGES -> CSS-IMAGES).

In "The image-set notation micosyntax " section, the following are not defined in the ABNF.

color = ??
url = ??
string = ??
resolution =

We need to define the use cases (if any) for returning media that matched the selection of an image.
That is:

var resimg = $("#myresimg"); 
//which media matches 
if(resimg.media .... ){
  // 
}

We have the option to either return a string or a MediaList. We need to investigate which one we want to use.

var resimg = $("#myresimg"); 
//which media matches 
if(resimg.mediaText === "screen"){
  // 
}

Media lists are cool because they have the following:

[Constructor(DOMString text)]
interface MediaList {
    stringifier attribute DOMString mediaText;
    readonly attribute unsigned long length;
    DOMString item (unsigned long index);
    void appendMedium (DOMString medium);
    void deleteMedium (DOMString medium);
};

We need to show how the solutions compare with each other with meeting the above use case.

Currently it seems like the HTMLImageElement also handles the <input type="image> case (it needs a form element as part of its constructor, which can be NULL)
I'm guessing we do not want to add a <input type="picture"> with multiple sources at this point. Right?

HTMLPictureElement probably needs to the following:

       attribute unsigned long width;
       attribute unsigned long height;
readonly attribute unsigned long naturalWidth;
readonly attribute unsigned long naturalHeight;

Width and height are the CSS pixels (as per style), and the natural ones are the intrinsic width and height of the image being displayed.

The spec says:

type = MIME type The type of the media resource (used for helping the UA determine, before fetching this media resource, if it can play it). A string that identifies a valid MIME media type.

UA's don't need this, particularly on picture (its compatibility is determined reliably by content type sniffing and Content-Type HTTP header).

Also, type already defined as an attribute of source (where it can be more helpful as part of the selection process).

I recommend we remove this from the spec.

We need to show how the solutions compare with each other with meeting the above use case.

We need to show how the solutions compare with each other with meeting the above use case.

We need to show how the solutions compare with each other with meeting the above use case.

General bug, will need to be broken into multiple tasks.

The algorithm section needs to be rewritten to be more precise. Needs to define all error handling states for when stuff is missing, in error, etc.

This should be backed by a 1-to-1 reference implementation and test suite.

The source element is lacking WebIDL that defines its DOM Interface. As currently specified, the interface will be suplemental. Need to describe how the algorithms are triggered when attributes are set... and if there are any special methods associated with the interface.

The HTML 5 specification defines dimensional attributes, but it is restricted to certain elements and attributes (hence, it leaves the picture element out in the cold).

If we get <picture> buy-in from the HTMLWG, we will need to update HTML5 to add picture to the "dimensional attributes" section.

The source element should be defined in way similar to HTML's source element.

The ABNF (is it ABNF?) of the srcset attribute has "em" elements around srcset-delc component. The should be removed.

If the syntax is ABNF, then we should reference ABNF (and test it with abnfgen).

We currently lack an eventing model... the eventing model will closely resemble that of audio/video for source elements + img. We also need to check that whatever eventing model we use meets the use cases (whatever those may be... I don't think we have captured event related use cases in the document).

The spec says:

Evaluate media/src/srcset attributes on the parent picture element first.

But does not define evaluate. It also doesn't say if they are missing, in error, etc.

Does the type attribute allow you to specify more than one media type? As in:

<picture>
     <source type="image/jpg, image/png, image/svg" 
             srcset="image1.png 1x, image.svg 2x, image.svg 3x">
</picture>

Getting the following issues from Respec. This means we need to update the W3C bibliography.

Bad ref: ALT-TECHNIQUES, count = 1
Bad ref: CSS4-IMAGES, count = 1

No biggy... but slightly annoying. If we format the references as JSON and send it to Robin, he can update it for us... or if someone does it, I can updated them at the w3c... or wherever they are held now.

The picture element is lacking WebIDL the describes the DOM interface.

Question: "Respond to user zoom on image resource" is not clear (to me)? I think that goal should be expanded a bit.

(Please note, I'm just going to file bugs initially and then propose fixes for discussion. Please wait for me to do that before responding or fixing stuff).

spec says:

This proposal adds new elements and attribute to [HTML5] to enable different sources of images based on browser and display characteristics. The proposal addresses multiple use cases such as images used in responsive web designs and different images needed for high density displays.

There are a few issues with the above:

1. "elements and attribute" reads strangely and doesn't say what those elements are.
2. The algorithm for responsive selection is not really "based on browser" so that's kinda confusing.
3. Display characteristics is a bit ambiguous.
4. "such as images used in responsive web designs " is not an example of a "use case"... not the way it's currently written.
5. same applies for "different images needed for high density displays" - the case is valid, but needs to be reframed (specially as it becomes problematic with regards to mobile delivery and high density/resolution displays on mobile devices with limited bandwidth).

If we add:

    [ NamedConstructor=Picture(),
    NamedConstructor=Picture(unsigned long width),
    NamedConstructor=Picture(unsigned long width, unsigned long height) ]

would give us:

   var pic = new Picture(); 

Oh yeah! :) Would make it consistant with Image and Audio named constructors.

As the Goals section is explicitly non-normative, you can't use "RFC2119" language there (i.e., MUST, SHOULD, MAY can't appear here or anywhere non-normative).

I think everything after and including:

Additionally, a conforming user agent must meet the following requirements...

is redundant (i.e., not needed). The reason it is not needed is that all those points are going to be part of the algorithms that make up the spec.

Having said that, I think we need to keep these points but in a very informal section (or as bugs or milestones in Github) to make sure that the desired user agent behaviour actually gets reflected in the spec.

The dependencies section is really about dependent definitions in other specs - maybe it should be renamed as such. Also, not all the dependent specifications are in the Normative Refs sections.

Note that the way the spec is currently written, you would have duplicates for the Normative References section and the "Dependencies".

Its not really clear to me why dependencies is a sub-section of the Conformance section?

Let's assume for a minute that we had the definitive responsive image format today (be it hierarchical encoding in JPEG/WebP, progressive JPEG (if it's good enough), unicorn coding, whatever).

What are the advantages of an <img> tag with such a format over <picture>?
It is much less hassle for authors and window resizes can simply download the "diff" instead of re-downloading the entire resource all over again.

The downsides are that with the best fetching mechanism I could come up with, we're still doubling the number of HTTP requests. (the browser needs info on the image's internal layers in order to download the byte range it needs)

What if we combine <picture> with a responsive img format and allow a single src attribute that would indicate the file's URL and the different <source> tags indicating the range that each MQ needs to download.

What do you say?

Forgive me if I'm hallucinating too much.

The usual scenario the picture element was conceived to resolve is the "download & shrink" scenario. The browser downloads a high quality image and then resizes it, therefore wasting bandwidth and time.
Another common scenario in responsive design is the "download & hide" scenario (@guypod's terminology from his "implications of mobile design" talk). This is the scenario where certain areas of the page are hidden using "display: none" under certain media queries.
<picture> can easily cover that scenario by defining that when no <source> media query is matched, no resource is downloaded. Alternatively, we could define that a <source> without any resources (i.e. no src or srcset) results in no download.
This is probably how browsers would implement such scenarios anyway, but it is better to explicitly add that to the spec to notify both web authors and browsers vendors what the expected behavior should be.

In the spec, the <picture> element should be defined exactly the same way that elements are defined in HTML5. That is, picture should look like video or similar - with Category, context in which it can be used, etc..

This means folding section "Picture Elements permitted attributes" into the formal definition for the element above.

We need to show how the solutions compare with viewport sizes.

We need to show how the solutions compare with each other with meeting the above use case.

Spec says:

Note that all supplied sources for a given picture element SHOULD represent the same subject matter, while cropping and zooming may differ.

Can't use RFC2119 language there (does not identify a valid product). Notes are non-normative.

Global comment/bug: When using RFC2119 keywords, a conformance requirement must identify an explicit product (we only have one product: a "user agent" - I will add a separate bug to add that to the Conformance section).

In other words, any conformance requirement that uses an RFC 2119 keyword must have the following structure:

A user agent [ MUST | SHOULD | MAY ] ... do something testable.

From the above, note that use of active voice. Specs should always be written in active voice unless the subject is ambiguous (or the editor is purposely trying to hide something). I.e., never write, for example,
"appropriate asset MUST be fetched", but instead "The user agent MUST fetch..."

The use of the SHOULD keyword needs to be avoided as much as humanly possible (it's an explicit interoperability breaker). In theory, MAY should never appear in a spec.

The following two are very similar:

Provides a purely client-side solution which can include JavaScript, but doesn’t require it

And:

As with the video and audio elements, this solution must not require any client-side scripting, server-side technologies, or headers to reliably deliver content tailored for the end user’s context.

Maybe could be merged.

The current way we are serving the spec does not reflect the changes without "doing work"(tm). We should move the spec of github pages.