Closed webmeadow closed 12 years ago
@Eileen, this is really great! Thanks for doing such a detailed review. The document is 100x better now. One minor thing: it's hard to match line numbers to comments once I start changing the document. What I usually do is I quote the sentence from the original document and then suggest a change immediately underneath. That way, the editor can just do a find a replace or the erroneous sentence/paragraph. For example,
the spec says:
"The foo is bar."
Should say: "The bar is a foo."
(optional) justification: Because bars are directly related to foos.
You did provide justifications using "[ ]" as convention :) Maybe we need a guide on how to review a spec? :)
On Friday, October 12, 2012 at 8:12 PM, Eileen wrote:
I'm not going all pull-requesty on this since maybe you don't want to make all these changes.
pull-requesty … my new favorite word :D
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!
Went with first upper and all rest lower.
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).
yuck! who wrote that?! >_< … oh, me :)
103 The RICG's goal for this document is to capture a complete set of developer requirements for responsive images.
Much better, thank you! but I wanted to keep wording about W3C and the link to the bug number though. I've mixed your wording and mine.
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).
Better also. Added.
99 As the number and varieties of high-density screens has increased (both on mobile and desktop devices), web developers have created custom solutions ...
Added.
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.]
Added this paragraph: "In other words, developers are being forced to work around, or completely ignore, authoring requirements of [[!HTML5]]"
117 images in HTML without hacking a solution. [or maybe 'hacking together'?]
added together.
117 Developers have resorted to using div and other container elements to achieve the desired functionality.
Rejected: didn't flow well.
121 Some approaches rely on JavaScript libraries or server-side solutions - both of which add unnecessary complexity to the development process.
It wasn't quite right… went with: The techniques rely on either JavaScript or a server-side solution (or both), which adds complexity and redundant HTTP requests to the development process
130 The following use cases represent situations in which Web developers see a need for a browser-based solution for working with responsive images.
Much better :) used yours.
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.
Adapted yours slightly.
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.
Added.
Fig. 1 Three images showing how zoom and crop can enhance or diminish the effectiveness of an image.
added.
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):
Said: "In a responsive design, it is typical to change the crop of an image so it can be targeted towards the features of a particular display (or set of displays):"
On large screens, a large image (e.g. of a figure with a broad background) is shown. On smaller screens, shrinking the image can reduce its relevance, usefulness, or legibility.
Used, but adapted a little bit … used "ability to communicate effectively" instead "legibility". Legibility connotes text to me… yes, an image is a "text", but don't I want to get all semiotic about it :)
The developer may want to show an alternate crop or layout of the same image.
The above sentence is now redundant, so I removed it.
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...
Used your text.
Bryan and Stephanie Rieger, the designers of the site, explained that on a wide screen,...
Added
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.
Nice, added :)
[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.]
I think we need to keep them because they outline fundamental challenges that developers face. I'm trying to rework the section a bit in light of your feedback (i.e., should definitely not sound like a requirements, but should explain why developers do certain things and the problems they encounter in doing so).
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.
Rewrote the section to point out that there is no practical way to swap images for the sake of print.
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.
See next comment…
“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.
The desktop/mobile first section is redundant. It's just another take on Art Direction so I killed it.
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.]
Ah good, the point is getting across :) Hixie specifically requested we do it this way. The use cases will be eventually split into individual bugs.
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.
Used your text.
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.
Used your text.
- Requirements
8 (https://github.com/ResponsiveImagesCG/ri-usecases/issues/8): The solution must afford developers the ability to define which version of the image should be used as the fallback image.
Merged with requirement 2: "The solution MUST degrade gracefully on legacy user agents by, for example, falling back on the img element and by relying on [[HTML5]] built-in fallback mechanisms. Additionally, the solution SHOULD afford developers the ability to define which version of the image needs to be used as the fallback image."
(I also changed the requirements listing to be an ordered list, so we can refer to them as numbers…. will probably formally label them, like the widget requirements spec does. See http://www.w3.org/TR/widgets-reqs/)
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).
This requirement is already in the document: "The solution MUST afford developers the ability to match image sources with particular media features and/or media types - and have the user agent update the source of an image as the media features and media types of the browser environment change dynamically over time. "
[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.]
That was my intention with the first requirement.
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 is covered by requirement 1.
[This one may be superfluous if #9 is adjusted to say "everything we can do in a media query, we need to do here."]
Agreed.
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. :)
On Monday, 15 October 2012 at 18:46, Eileen wrote:
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.
I've added a meta bug: https://github.com/ResponsiveImagesCG/meta/issues/1
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.
It's growing on me - and those are very good points. It just that it draws attention to itself on its own, which is why I'm hesitant to include it… it took me out of the flow when I read it (i.e., it almost feels too clever). Know what I mean?
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. :)
Once we move it to the W3C, it gets a fancier boilerplate with stronger wording (as there it gets "Editor Draft" status, and it does indeed, reflect the consensus of the Community Group). See, for instance, the other spec (though admittedly, it has not been reviewed, nor does it have the consensus of the CG >_< ):
http://dvcs.w3.org/hg/html-proposals/raw-file/tip/responsive-images/responsive-images.html
We want to keep the current model as it gives us freedom to experiment in the spec without (hopefully) anyone freaking out if we add anything stupid. I.e., only reviewed drafts become Editor's Drafts and eventually real specifications.
We will try to have one editor's draft per week. We are still working out the kinks with the publication model. If you have any thoughts or comments about that, would like to hear them.
Also, want to thank you in the specification for your help. What name should I use?
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.
On Tuesday, October 16, 2012 at 9:02 PM, Eileen wrote:
You can use "Eileen Webb", since it is my name. :)
Done :)
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."
Ok, you win … legibility it is :)
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.
Good point. I've added a "Changes since last publication" section… for now, it just points to the github history and closed bugs. In time, I'll look to improve this to give a better reflection of what has changed.
Closing bug. Eileen, please reopen if you have anything further (or file a new bug). Thank you again for all your help!!!
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.
121 Some approaches rely on JavaScript libraries or server-side solutions - both of which add unnecessary complexity to the development process.
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.
4. Requirements
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."]