Re: Belated comments on MWABP ( LC-2290 LC-2291 LC-2292 LC-2293 LC-2294 LC-2295 LC-2296 LC-2297 LC-2298 LC-2299 LC-2300)

 Dear Robin Berjon ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the Mobile Web Application
Best Practices published on 6 Oct 2009. Thank you for having taken the time
to review the document and to send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20091210.

Please review it carefully and let us know by email at
public-bpwg-comments@w3.org if you agree with it or not before 5 January
2010. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Mobile Web Best Practices Working Group,
Dominique Hazaël-Massieux
François Daoust
W3C Staff Contacts

 1. http://www.w3.org/mid/09C4E1CB-D3D9-49B0-BF1D-D2A3DFE0EC7F@berjon.com
 2. http://www.w3.org/TR/2009/WD-mwabp-20091006/


=====

Your comment on 1.3.2 Web Application:
> 1.3.2: "Web Widgets Effort" that would be the "W3C Widgets effort", or
> perhaps the "W3C Widgets family of specifications" (as WebApps call
> them).


Working Group Resolution (LC-2290):
We agree and have updated the text.

----

Your comment on 1.5 Terminology:
> 1.5: "The implicit reference to XML suggested by the names is commonly
> accepted to be an historical anomaly." It's historical for sure, but
> it's not really an anomaly: it really corresponded to what people were
> thinking of at the time.


Working Group Resolution (LC-2291):
We agree and have removed that comment.

----

Your comment on 3.1.2 Use Appropriate Client-Side Storage Technologies for
Local Data:
> 3.1.2.1: Storage has been split from HTML5, and there are several
> parallel local storage efforts in WebApps. In general it would be good
> to be more precise: "BONDI [BONDI], HTML5 [HTML5], and Opera Widgets
> [OPERA]" isn't very helpful. For instance, are you thinking of the BONDI
> address book interface? Or the file system interface? The calendar API?
> They can all store local data.


Working Group Resolution (LC-2292):
We will add text to 3.1.2.1. stating that work is in progress to unify
these apis and reference the work of WebApps and Device API WGs. We note
that most storage APIs are dealt with by the WebApps WG but think the File
System API addressed by DAP falls into the storage spec category.

----

Your comment on 3.2.1 Do not Execute Unescaped or Untrusted JSON data:
> 3.2.1.2: Note that some browsers now ship with native JSON parsing.


Working Group Resolution (LC-2293):
We agree and have removed the parenthetical comment on performance issues
with JSON parser.

----

Your comment on 3.3 User Awareness and Control:
> 3.3: "Browsers may have access to information such as: • Pictures,
> music, and video clips; • Contacts, calendar (PIM data); • Call
> history; • System data (battery, coverage, roaming, location); •
> Media recording (record audio/video clip, get new picture); • Device
> context (e.g. location, connectivity, profile setting)."
> 
> I am not aware that there are any plans to grant browsers access to
> such information gratuitously. They may be granted within web runtimes,
> but even then with clear restrictions. In general this seems to address
> implementers more than authors.


Working Group Resolution (LC-2294):
The best practices of this document do not address implementers. We have
added some text in section 3.3 to explain that the best practices in this
section provide further advice on appropriate application behaviour in
situations where the native functionality of the browser may not be
sufficient.

----

Your comment on 3.3.1 Inform the User About Automatic Network Access:
> 3.3.1: Also seems to be more for implementers than authors. This
> information should be provided in a consistent manner by the UI, not the
> app. The BP I expected here is the one in 3.3.2.


Working Group Resolution (LC-2295):
The Best Practices address authors as precised in section 1.1 Purpose of
the Document, and do not address browser implementers. We have added some
clarification text to the beginning of section 3.3 to say that where
possible it is preferable.to rely on the browser's native functionality to
notify the user.

----

Your comment on 3.3.3 Ensure the User is Informed About Use of Personal
and Device Information:
> 3.3.3: Again, implementer-orientated. I think that it would be more
> useful to have separate documents for authors and implementers. Also,
> the notion that putting notices about usage of a user's personal
> information in help pages implements a best practice is somewhat
> dubious. It's hard to find users accessing help pages on a desktop, I
> don't believe anyone ever does on a mobile (in fact, I'm not sure where
> I'd find such things).


Working Group Resolution (LC-2296):
This document is for authors as mentioned in section 1.1 Purpose of the
Document. We agree that putting information in help pages is not a best
practice and have removed the text.

----

Your comment on 3.4.1 Use Transfer Compression:
> 3.4.1.2 This should also mention that EXI has been registered as an HTTP
> content coding, and can be used. It has the substantial advantage that
> in most configurations it is smaller while also requiring fewer cycles
> to decode.
> 
> "For very small files (e.g. <1k) the negative impact of processing may
> outweigh any small transport gains." Note that for very small files,
> gzip will render them larger anyway.


Working Group Resolution (LC-2297):
We agree and have updated the text to mention EXI as a technology to watch
out and changed the note on very small files accordingly.

----

Your comment on 3.4.11 Keep DOM Size Reasonable:
> 3.4.11.1: "Keep the DOM size below 10MB to avoid browser crashes."
> Providing numbers without telling people how to measure them doesn't
> help a lot.


Working Group Resolution (LC-2298):
We agree and have removed the mention of a precise DOM size that was
empirical and would not help authors making a decision.

----

Your comment on 3.5.10 Consider Use of Canvas Tag or SVG For Dynamic
Graphics:
> 3.5.10 "Consider Use of Canvas Tag". I think you mean the "canvas
> Element" (the same mistake is made several times).
> 
> "graphic primatives" -> primitives
> 
> """
> SVG is well-suited for graphics that must be scalable and whose
> components need to be modified (e.g. panning and zooming a map) whereas
> Canvas is best suited for cases where a static bitmap is sufficient
> (e.g. drawing a scatter-chart, visual effects, reflections etc).
> 
> In most cases Canvas is faster and should be preferred if it meets
> requirements.
> """
> 
> These arguments are all sort of flaky, and sort of wrong. I'd recommend
> that users look into these options, but not try to contrast them —
> that's the topic of a Web Graphics Best Practices document.


Working Group Resolution (LC-2299):
Thanks for the typos.

We will not make any further change to the wording of the Best Practice on
Canvas and SVG but have moved it to a "Further Considerations" section to
acknowledge that the best practice is more something to consider than an
actionable statement.

----

Your comment on 3.6.4 Support a non-JavaScript Variant if Appropriate:
> 3.6.4.2: Returning a bland 406 is rude (and hard to understand for
> users). If a 406, then it ought to be a 406 with a human readable
> payload explaining why the error is being produced.


Working Group Resolution (LC-2300):
We agree and have removed the reference to the 406 status code.

----

Received on Thursday, 17 December 2009 10:45:58 UTC