I'm not going all pull-requesty on this since maybe you don't want to make all these changes. Also this is a mix of typo stuff and style stuff, and don't think I don't love y'all just because I'm picky about word choices and sentence phrasing. A lot of this is straight-up Strunk&White sentence construction and "omit needless words" sort of stuff.
General note - We need to standardize the capitalization of all the H1s and H2s; right now they are a mix of Title Caps and Sentence capitalization schemes. I don't think it matters which one to go with, just pick one and run with it!
line 103 This document reflects the efforts of the Responsive Images Community Group (RICG) to present a comprehensive set of responsive image use case descriptions to the W3C and WHATWG (see bug 17061).
103 The RICG's goal for this document is to capture a complete set of developer requirements for responsive images.
97 These changes in media features and media type can reduce an image's ability to communicate effectively (e.g. images become blurry or pixelated).
99 As the number and varieties of high-density screens has increased (both on mobile and desktop devices), web developers have created custom solutions ...
115 Reliance on semantically inappropriate elements and CSS backgrounds
[The audience for this is people who love/create web standards, right? So we want to drive home that we're currently being forced to ignore standards.]
117 images in HTML without hacking a solution. [or maybe 'hacking together'?]
117 Developers have resorted to using div and other container elements to achieve the desired functionality.
130 The following use cases represent situations in which Web developers see a need for a browser-based solution for working with responsive images.
3.1 Art Direction
Web developers often need to provide different versions of the same image in order to communicate effectively across the wide range of screen resolutions and densities available on today's devices. If the screen is small and the image is scaled down, its details cannot be seen. Conversely, if the screen is large a larger image that depicts more information can be shown.
For example, in the left-most image in Figure 1, it is difficult to discern the man's facial expressions, where in the center image his face and gestures are clear. The image on the far right show the poor quality of an over-scaled image.
Fig. 1 Three images showing how zoom and crop can enhance or diminish the effectiveness of an image.
A typical use is to change the crop of an image so it can be targeted towards the features of a particular display (or set of displays):
A related use case is when orientation determines the source of the image, the crop, and how text flows around the image based on the size of the viewport. For example, on the Nokia Browser page describing the Meego browser, the Nokia Lumia is...
Bryan and Stephanie Rieger, the designers of the site, explained that on a wide screen,...
3.2 Design Breakpoints
In Web development, a breakpoint is one of a series of CSS Media Queries that update the styles of a page based on logical matching of media features. A single breakpoint represents a rule (or set of rules) that determines the point at which the contents of that media query are applied to a page’s layout.
[The whole Example & bullets about em's seem misplaced here? It feels redundant to section 3.6, and also more like a requirement - that we need to be able to use the same query params for CSS and images - rather than a use case.]
3.4 Monochrome and high-contrast
Displaying a color image on monochrome media (e.g., e-ink displays) can be problematic; different colors with similar luminosity are impossible to distinguish on monochrome media. Additionally, Microsoft has proposed a "high-contrast" media feature, which would enable developers to know if the user agent is operating in a high-contrast mode. Developers need to be able to serve images specifically designed for monochrome or high-contrast viewing modes.
3.5 Mobile-first and desktop-first responsive design
Many responsive designs use the “mobile-first” development pattern: starting with a simple, linear layout and using media queries to increase layout complexity for larger screen sizes. In such designs, web developers generally serve small images first and increase the size of images as required.
“Desktop-first” responsive design takes the opposite approach, starting with the large-screen design and using media queries to simplify for smaller displays. With this approach the default images served are usually the largest, with smaller images being called when necessary.
Both approaches are based on a single image having multiple source files, where media queries determine which version of the image should be displayed.
[Not sure we need another reminder that our current solutions suck. I mean, the reader is already 60% into this document at this point. If we don't already have them on that point, we're doomed.]
3.6 Relative Units
...when a user zooms into a design, proportionally scaled images can be blurry or pixelated, affecting the image's impact and function.
3.7 Dynamically acquired image data [note singular 'image' in this title]
There are cases where the image data is dynamically generated (e.g., using canvas element and related APIs) or is acquired from the device itself (e.g., from the camera on a phone or tablet). Developers need practical means to interface programmatically with the source of an image or a set of images.
8: The solution must afford developers the ability to define which version of the image should be used as the fallback image.
9: The solution must allow developers match the media queries used in their design, including using min-width or max-width, and relative units (e.g., em, rem) or fixed units (e.g., px).
[Maybe that should include a link to the part of the CSS spec that talks about what can be used in media queries? Ideally we want them to match 1:1, right? It would suck to be that one person who's actually using min-height and have this solution fail because we only declared it needed to work with width.]
10: - The solution must be responsive to environmental changes in relative units (e.g., when the user increases the base font size of the browser).
[This one may be superfluous if 9 is adjusted to say "everything we can do in a media query, we need to do here."]
Great, I'm glad it was helpful! Yeah, we totally need a standardized way to comment on a spec - it gets a little hairy when some of the edits are wholesale rewrites of a sentence, but others are only tiny word changes. And though WYSIWYG editors are gross, it's pretty hard to read through a giant list of changes when all the text is the same weight and indentation.
Re "legibility": I actually like that word specifically because of its reading connotation - a lot of images contain text (ads are the biggest example that come to mind) and shrinking them really is a matter of being able to read them. A responsive ad might contain a bigger font in the small versions, or fewer words. So I think the original legibility was a great choice.
I am assuming that the word "merely" in "merely a public working draft" is not your doing? It looks like it's... added through JS maybe? "Merely" makes me sad :( like we don't believe in ourselves. I'd edit it out if I could. :)
You can use "Eileen Webb", since it is my name. :)
Re 'legibility', the phrase "ability to communicate effectively" feels a little clunky; if you decide you don't want legibility you could simplify the whole thing to "On smaller screens, shrinking the image can reduce its relevance and usability."
Yep, I'm totally with you on the whole draft vs spec vs other-draft thing. It might be nice to have a timeline available for people to see (uh... assuming there is a timeline)? So that people who are only peripherally involved could see that progress is being made, and that if they want to get involved in some particular aspect they need to do it by X date, etc.
Closing bug. Eileen, please reopen if you have anything further (or file a new bug). Thank you again for all your help!!!