W3C

Disposition of comments for the Mobile Web Best Practices Working Group

Single page view

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2412 David Campbell <dcampbell@owasp.org> (archived comment)
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
draft recommendation.

Please feel free to contact me directly with any questions, comments or
concerns.

Cheers,

David Campbell
Open Web Application Security Project
dcampbell@owasp.org
www.owasp.org
The group partially agrees with the comment.

The Mobile Web Application Best Practices is explicitly scoped to best practices that have some specific impact on the mobile context:
http://www.w3.org/TR/mwabp/#mobile-context

The Working Group acknowledges that most "desktop" security-related best practices also apply to mobile devices and updated the introduction text of the "Security and Privacy" section to reflect that the one best practice listed in that section is definitely not the end of it. The Working Group has also decided to reference the OWASP TOP 10 work as example of usual security measures in this text. See updated text in latest editor's draft:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-security

The group does not feel it has the expertise to review and select other best practices related to security and decided against adding more best practices to the section. A future version of the best practices should probably include a more comprehensive set of best practices related to security.

The best practice listed in this category was chosen on the grounds that it was the most obvious client-side security hole to bridge in a mobile Web application that might have access to personal information. In particular, a mobile Widget could perhaps be allowed to send SMS or make phone calls while the device is connected to an "untrusted" public Wifi connection, thus enabling potential man-in-the-middle attacks.
tocheck
LC-2407 Erik Wilde <dret@berkeley.edu> (archived 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)
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
yes
LC-2408 Francois Daoust <fd@w3.org> (archived 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.
The group partially agrees with the comment and decided to add a reminder that informational image require alternative text (whereas decorative images don't). yes
LC-2413 Michael Cooper <cooper@w3.org> (archived 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."
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
yes
LC-2414 Michael Cooper <cooper@w3.org> (archived 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.
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
yes
LC-2415 Michael Cooper <cooper@w3.org> (archived 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.
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
yes
LC-2416 Michael Cooper <cooper@w3.org> (archived 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.
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.
yes

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:44:04 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org