We've moved to the Responsive Images Community Group Organization.
draft-prop's Introduction
draft-prop's People
Forkers
responsiveimagescgdraft-prop's Issues
Goals: low bandwidth situations
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.
Goal: describes fetching/adaptive behaviour
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.
Github project name... and moving work formally to github
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.
Goals: full stops
Minor: fulls stops missing in bullet points.
Image maps and picture element
Not clear how picture interacts with image maps.
Refer to screen resizes
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.
Introduction: Art direction use case not linked
Quick bug: Missing hyperlink to "art direction use case" in last para of intro :)
Introduction: What is "best image source"?
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).
Source element: Duplicate attribute definitions
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.
Conformance: missing product
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).
Picture element: example should not show source element
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.
Can we really re-use source element?
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!
Alternate Print Sources - Show how <picture> and img@srcset compare
We need to show how the solutions compare with each other with meeting the above use case.
Responsive images and forms
There may be some issues with picture elements interacting with forms (relating to input type=image). Need to investigate further.
Matching image source breakpoints to design breakpoints - Show how <picture> and img@srcset compare
We need to show how the solutions compare with each other with meeting the above use case.
Dependencies: RFC2046 name of spec is wrong
The name of the spec is wrong, should be "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"; not "Media Queries" :)
General: avoid versioning in references
Where possible, avoid versioning for citations/refs (e.g., HTML5 -> HTML, CSS4-IMAGES -> CSS-IMAGES).
The image-set notation micosyntax: Color, url, string, resolution in ABNF are not defined
In "The image-set notation micosyntax " section, the following are not defined in the ABNF.
color = ??
url = ??
string = ??
resolution =
Reflecting matched media
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);
};
Mobile Networks - Show how <picture> and img@srcset compare
We need to show how the solutions compare with each other with meeting the above use case.
input type="picture"???
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: should it have its own height and width?
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.
Type attribute of picture should be removed
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.
Art Direction - Show how <picture> and img@srcset compare
We need to show how the solutions compare with each other with meeting the above use case.
Mobile-first and desktop-first responsive design - Show how <picture> and img@srcset compare
We need to show how the solutions compare with each other with meeting the above use case.
User Zoom - Show how <picture> and img@srcset compare
We need to show how the solutions compare with each other with meeting the above use case.
Algorithms - needs more detail...
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.
Source Element: DOM Interface
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.
HTML5 dimensional attributes should list picture
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.
Source Element: should be defined like in HTML5
The source element should be defined in way similar to HTML's source
element.
Srcset attribute: typo and reference
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).
Eventing model for responsive images
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).
Algorithms: Evaluate is not defined
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.
type attribute on source for picture might be unhelpful
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>
Biblio: Missing references
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.
Picture Element: Needs DOM interface
The picture element is lacking WebIDL the describes the DOM interface.
Goals: Respond to user zoom on image resource
Question: "Respond to user zoom on image resource" is not clear (to me)? I think that goal should be expanded a bit.
Abstract is ambiguous
(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:
- "elements and attribute" reads strangely and doesn't say what those elements are.
- The algorithm for responsive selection is not really "based on browser" so that's kinda confusing.
- Display characteristics is a bit ambiguous.
- "such as images used in responsive web designs " is not an example of a "use case"... not the way it's currently written.
- 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).
Do we want named constructors on Picture?
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.
Goals: erroneous use RFC2119 language
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.
Dependencies: rename to definitions?
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?
Responsive image format thought experiment
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.
Add a goal: avoiding the "download&hide" scenario
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.
Picture Element: needs to be defined like in HTML5
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.
Viewport Sizes - Show how <picture> and img@srcset compare
We need to show how the solutions compare with viewport sizes.
Relative Units - Show how <picture> and img@srcset compare
We need to show how the solutions compare with each other with meeting the above use case.
Source element: Note uses RFC2119 language
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.
General use of RFC2119 keywords
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.
Goals: duplicate goals?
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.
Move spec to Github pages
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.