This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:Mobile Web Best Practices Working Group
Other specs in this tool
Mobile Web Best Practices Working Group's Issue tracker
Quick access to LC-2407
There are 7 comments (sorted by their types, and the section they are about).
Dear Sir or Madam:
I represent the Global Industry Committee of the Open Web Application
Security Project (OWASP) and we are keenly interested in your
forthcoming Mobile Web Application Best Practices recommendation.
Attached please find a PDF document containing our comments on your
Please feel free to contact me directly with any questions, comments or
Open Web Application Security Project
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:
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:
... started from Jo's question and Alan's response:
> 3.5.3 Design for Multiple Interaction Methods 220.127.116.11 What it means â€¦
> â€¢ Focus Based: The browser focus "jumps" from link to link;
> 18.104.22.168 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."
Suggest adding a fourth type of interaction method to 22.214.171.124:
Assistive Technology Based: Events are controlled by a software
application (e.g. screen reader or voice control application) acting on behalf of the user.
Suggest adding a fourth type of interaction method to 126.96.36.199:
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
â€¢ 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.
> 188.8.131.52 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.
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.
erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
firstname.lastname@example.org - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)
Add a comment.