There are 7 comments (sorted by their types, and the section they are about).
substantive comments
editorial comments
Comment LC-2408
Commenter: Francois Daoust <fd@w3.org> (archived message ) Context: 3.4.6 Aggregate Static Images into a Single Composite Resource (Sprites)
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Hi,
This is a small comment on section 3.4.6 Aggregate Static Images into a Single Composite Resource (Sprites) of the second last call working draft of Mobile Web Application Best Practices:
http://www.w3.org/TR/2010/WD-mwabp-20100713/#bp-conserve-sprites
The best practice does not explicitly restrict its usage to "decorative" images. It does so implicitly through the use of examples "icons, buttons".
When applied to informative images that appear as <img> tags within the markup, this best practice would result in a mix between content and layout, since CSS then becomes mandatory to render the correct portion of the image and thus to carry the information.
I suggest to clarify the current text in the "What it means" subsection:
"Web applications often depend on a number of *decorative* images to provide icons, buttons, etc."
... instead of:
"Web applications often depend on a number of static images to provide icons, buttons, etc."
I also suggest to start the "How to do it" subsection by:
"Define candidate images as CSS background images and combine them into a single image for transfer (spriting)"
... instead of:
"Combine images into a single image for transfer (spriting)"
This has been discussed back in May 2009 from an accessibility angle, which essentially boils down to the same thing, but although there seemed to be agreement that restrictions to decorative images for this technique was a good thing, it doesn't seem to have been integrated in to the document:
http://lists.w3.org/Archives/Public/public-bpwg/2009May/0039.html
... started from Jo's question and Alan's response:
http://lists.w3.org/Archives/Public/public-bpwg/2009May/0034.html
Thanks,
Francois.
Related issues: (space separated ids)
WG Notes: Notes from fd (2010-08-24):
Well, of course, it's a fantastic comment ;)
Discussion and resolution at:
http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2408
RESOLUTION: ref LC-2408 resolve as editorial and partial, add a reminder that informational image require alternative text (whereas decorative images don't)
Resolution: The group partially agrees with the comment and decided to add a reminder that informational image require alternative text (whereas decorative images don't). (Please make sure the resolution is adapted for public consumption)
Comment LC-2413
Commenter: Michael Cooper <cooper@w3.org> (archived message ) Context: 3.5.2 Minimize Perceived Latency
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Comment 1
> 3.5.3 Design for Multiple Interaction Methods 3.5.3.1 What it means …
> • Focus Based: The browser focus "jumps" from link to link;
and
> 3.5.3.2 How to do it Focus Based: …
> Focus area will jump automatically from one selectable element to
> another (e.g. from link to link) without affecting usability even
> when widely spaced.
Suggest changing "from link to link" to "from element to element."
Related issues: (space separated ids)
WG Notes: Notes from fd (2010-08-24):
Sounds correct. I would leave the second part intact though, as selectable elements are typically links, so that's a good example of behavior.
Discussion and resolution at:
http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2413
RESOLUTION: ref. LC-2413, mark as editorial and resolve partial. Update the text to read "The browser focus jumps from element to element". Leave the example "from link to link" in 3.5.3.2 intact though as it's a good example of mobile browser behavior.
Resolution: The group partially agrees with the comment. The text in 3.5.3.1 has been updated as suggested. However, the group decided to keep "e.g. from link to link" in 3.5.3.2 on the grounds that it is a typical example of how such mobile browsers behave on simple Web pages. See updated text in latest editor's draft:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-presentation-interaction (Please make sure the resolution is adapted for public consumption)
Comment LC-2416
Commenter: Michael Cooper <cooper@w3.org> (archived message ) Context: 3.5.3 Design for Multiple Interaction Methods
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Comment 4
Suggest adding a fourth type of interaction method to 3.5.3.2:
Assistive Technology Based:
• Follow recommendations outlined in the Web Content Accessibility
Guidelines 2.0 [http://www.w3.org/TR/WCAG20/]
• For mobile web applications that allow creation of web content, follow
recommendations outlined in the Authoring Tool Accessibility Guidelines
2.0 [http://www.w3.org/TR/ATAG20/]
• Once the spec reaches CR, follow recommendations outlined in
Accessible Rich Internet Applications 1.0 [http://www.w3.org/TR/wai-aria/]
• Elements should be operable through means outside the primary
interaction method for each device. For example, on a device where the
primary interaction model is touch-based, assistive technology software
may operate using a focus-based interaction model even though there is
no concept of focus in the primary interaction model.
Related issues: (space separated ids)
WG Notes: Notes from fd (2010-08-24):
resolution follows from resolution on LC-2414.
Discussion and resolution at:
http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2416
RESOLUTION: ref LC-2416, mark as editorial and resolve partial. Add wording along the lines of "Other guidelines and best practices are available. For instance, WCAG2.0". Do not reference ATAG as it's for authoring tools implementers and not Web developers.
Resolution: Following the resolution of Comment 2 (LC-2414), the group partially agrees with the comment and added a reference to Web Content Accessibility Guidelines 2.0 as an example of available guidelines and best practices to address other types of interaction methods. See updated text in latest editor's draft:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-presentation-interaction
While the Mobile Web Application Best Practices specification encourages tool developers to read the document, the main audience of the specification is Web application developers. As such, the text does not reference the Authoring Tool Accessibility Guidelines. (Please make sure the resolution is adapted for public consumption)
Comment LC-2414
Commenter: Michael Cooper <cooper@w3.org> (archived message ) Context: 3.5.3 Design for Multiple Interaction Methods
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Comment 2
Suggest adding a fourth type of interaction method to 3.5.3.1:
Assistive Technology Based: Events are controlled by a software
application (e.g. screen reader or voice control application) acting on behalf of the user.
Related issues: (space separated ids)
WG Notes: Notes from fd (2010-08-24):
Not a bad idea to include a reference to "voice" somewhere, although I don't think it qualifies as a "main interaction method".
Discussion and resolution at:
http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2414
RESOLUTION: ref. LC-2414, mark as editorial and resolve partial. Add a reference to assistive technology and voice controlled applications as examples of other types of possible interaction methods, noting that new interaction methods are likely to emerge in the future.
Resolution: The group partially agrees with the comment. While it does not feel that a fourth type of interaction method needs to be added to the list of the main interaction methods so far, it acknowledges the importance of mentioning other types of interaction methods - including assistive technology and voice controlled applications - and updated the text consequently. The text also emphasizes that new interaction methods may emerge and become prevalent in the future. See updated text in the latest editor's draft:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-presentation-interaction (Please make sure the resolution is adapted for public consumption)
Comment LC-2415
Commenter: Michael Cooper <cooper@w3.org> (archived message ) Context: 3.5.3.2 How to do it
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Comment 3
> 3.5.3.2 How to do it Touch Based: … Selectable elements must be large
> enough to be easily selected (e.g. list items should have a height of
> at least 30px);
Suggest using a physical size rather than a pixel size, as device
resolutions and DPI scale can vary from device to device, or explain in better detail that this is not referring to physical screen pixels.
Mobile devices today range from less than 72 dpi to greater than 300 dpi.
Related issues: (space separated ids)
WG Notes: Notes from fd (2010-08-24):
That's a good point. Although everyone understands what a pixel means, it does not mean much in practice on mobile phones (a CSS pixel, a real pixel?).
Discussion and resolution at:
http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2415
RESOLUTION: ref LC-2415, mark as editorial and resolve yes. Replace 30px by physical size of a fingertip.
Resolution: The group agrees with the comment. The text was updated to mention "the physical size of a fingertip". See updated in latest editor's draft:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-presentation-interaction (Please make sure the resolution is adapted for public consumption)
Comment LC-2407
Commenter: Erik Wilde <dret@berkeley.edu> (archived message ) Context: 3.5.6 Make Telephone Numbers "Click-to-Call"
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :hello.
http://www.w3.org/TR/2010/WD-mwabp-20100713/#bp-interaction-uri-schemes
recommends to use tel: URIs for telephone numbers. tel: is definitely
more widely known, but there also is a URI scheme for SMS, defined by
RFC 5724. mentioning it might be useful for those mobile web app authors
who like to better support SMS-based messaging in their apps.
kind regards,
erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
dret@berkeley.edu - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)
Related issues: (space separated ids)
WG Notes: Discussion and resolution at:
http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2407
RESOLUTION: ref LC-2407, mark as editorial and resolve yes. Mention the sms URI scheme with a link to the appropriate RFC with a warning that implementation vary very widely.
Resolution: The group agrees with the comment, and added a link to the SMS URI scheme together with a reference to RFC5724. The text includes a warning for developers about potential discrepancies in implementations at this stage. See updated text in latest editor's draft:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20100901#bp-interaction-uri-schemes (Please make sure the resolution is adapted for public consumption)
Add a comment .