- From: <fd@w3.org>
- Date: Thu, 17 Dec 2009 10:45:18 +0000
- To: Marc Wilson <marcwilson@google.com>
- Cc: public-bpwg-comments@w3.org
Dear Marc Wilson , 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/b578e9ef0911100216r57efe60fq7f6f0ea8bd7727a7@mail.gmail.com 2. http://www.w3.org/TR/2009/WD-mwabp-20091006/ ===== Your comment on 3.1.1 Use Cookies Sparingly: > 3.1.1.1 > Cookies being disabled by devices isn't a mobile specific issue as it > also applies to desktop. New devices Android, iPhone, Nokia s60 and > beyond, Palm, etc.. all ship with cookies enabled by default. > Maybe it is covered elsewhere but there is no mention of privacy > issues sending data back to the server via cookies, only the network > concern. With access to very sensitive data like location this might > be worth flagging for mobile. Working Group Resolution (LC-2271): We disagree with the claim that there is no mobile-specific aspect to cookies (the shifting of data is mobile-specific). Generic privacy issues are considered out of scope of this document ---- Your comment on 3.1.2 Use Appropriate Client-Side Storage Technologies for Local Data: > 3.1.2.1 > Given that HTML5 is now drafting specs for a Web Storage and Web > Database that is shipping in iPhone 3.x and Android 2.x it seems odd > to me to mention Bondi and Opera widgets in this context, especially > given the focus of this document is for applications in a browser. > The second point of "making updates locally at first" should be > supplemented with a need to add UI treatment to make it clear to the > user that their data is uncommitted. Working Group Resolution (LC-2272): We will add text to 3.1.2.1. stating that work is in progress to unify these apis and pointing to the work of WebApps and Device API WGs. Regarding the need to add UI treatment, we think we make sufficient comment about progress indications elsewhere in the spec. ---- Your comment on 3.2.1 Do not Execute Unescaped or Untrusted JSON data: > 3.2.1.2 > One way to be able to eval() untrusted data is to perform the JSON > escaping on the server where the processing power is less constrained > than on the client since we are downloading the data anyway > (presumably). Working Group Resolution (LC-2273): We agree but note the text already mentions that the JSON datafeed has to be suitably escaped when the eval() function is used. ---- Your comment on 3.3.1 Inform the User About Automatic Network Access: > 3.3.1.2 > AFAIK some devices will provide UI indications in their status bar of > network activity, with a spinner or mobile data flow indicators. While > informing users of background network usage may be desirable, it might > be overkill to have 3 separate indicators. Maybe you could suggest to > provide UI on devices where the browser does not do it natively Working Group Resolution (LC-2275): We understand the point but think that this would complicate things for authors who would then have to maintain different variants of their applications for different browsers. ---- Your comment on 3.3.1 Inform the User About Automatic Network Access: > 3.3.1.1 > nit: double period at the end of first sentence Working Group Resolution (LC-2274): Thanks. Double period removed and sentence completed. ---- Your comment on 3.3.2 Provide Sufficient Means to Control Automatic Network Access: > 3.3.2.2 > "must" seems a bit strong here. Some applications that inherently > require network access (think IM, mapping, etc..) will not be usable > with no network access, so providing such an option should not be > mandatory. Working Group Resolution (LC-2276): We agree that the wording is too strong and have replaced "must" by "should". ---- Your comment on 3.3.4 Enable Automatic Sign-in: > 3.3.4 > Consider adding something along the lines of > "If devices persist authentication tokens then the server MUST > invalidate them if the user changes or resets their password" > This is especially important with mobile devices that are often > lost/stolen and provides a user with a way to after the fact lock the > phone out of web applications it had previously been authorised for. Working Group Resolution (LC-2277): We agree but think that the current text in the "How to do it" already addresses this need. We have added a note to emphasize that a sign-out link should be also provided if automatic sign-in is enabled. ---- Your comment on 3.4.4 Optimize Network Requests: > 3.4.4.2 > One suggestion to add here is to prioritise your network requests and > throttle the number of connections in order to ensure that high > priority requests are not blocked or slowed by lower priority > requests, if they are unable to be batched. Working Group Resolution (LC-2278): We agree and have added the suggestion to the list. ---- Your comment on 3.4.5 Minimize External Resources: > 3.4.5.1 > This is a dangerous recommendation when even modern browsers like > mobile safari on iPhone have a limited browser cache entry size of > 25kb uncompressed. It is a good recommendation but relies partially on > the assumption that the caching of a single large resource is no worse > than multiple single resources. Working Group Resolution (LC-2279): We think that this limitation is obsolete and that the best practice is good in the generic case. We do not think that we can recommend an explicit size limit as this is likely to evolve over time. ---- Your comment on 3.4.10 Don't Send Cookie Information Unnecessarily: > 3.4.10 > Although this is a different point to 3.1.1 they are related and maybe > should be merged, colocated or reference each other Working Group Resolution (LC-2280): We think that both best practices address cookies in very different ways and would not benefit from referencing each other. ---- Your comment on 3.4.11 Keep DOM Size Reasonable: > 3.4.11 > I don't like this recommendation. > What does "reasonable" mean? What about "manageable"? > What is a 10Mb DOM? > How should people measure it? > Why was this value chosen? (Recent high end browser handle much larger > DOMs) > > It is unclear what the recommendation to "Clip content and separate > content onto separate pages" means. > Are you saying to make top level URL changes to download new pages > (and parse new JS)? If you are I think that is a bad recommendation as > the latency hit is quite bad. > Typically a better solution is to rather than hide non visible DOM > elements, to instead remove these elements from the DOM altogether and > recreate them as needed. Working Group Resolution (LC-2281): We agree and have reworded the section to remove mention of a specific DOM size. ---- Your comment on 3.5.1 Optimize For Application Start-up Time: > 3.5.1.1 > App Cache link should now point to: > http://www.w3.org/TR/html5/offline.html > > 3.5.1.2 > I like these recommendations. Good stuff. > > One thing you could add is to initiate any network requests before JS > parsing begins, so that the network request is in flight while the > parse occurs. This can work well for applications that require fresh, > rather than, cached data to be useful as it parallelises the network > request and JS parse. Working Group Resolution (LC-2282): Ref. App Cache, thank you, we have updated the reference. Ref. initiating network requests before JS parsing, we think it depends on what the Javascript is supposed to be doing. Section 3.5.2.2 on minimizing perceived latency mentions moving Javascript to the bottom of the page. We also note that there is ongoing research on that topic. ---- Your comment on 3.5.4 Preserve Focus on Dynamic Page Updates: > 3.5.4 > The tone of this recommendation is odd. I agree that the user > shouldn't be warped away from their current view but there are cases > where programatically setting the focus is very desirable if the next > user action is expected to be character input and setting the focus in > these cases should be recommended. Working Group Resolution (LC-2283): We agree with the comment but think the current text already addresses such cases. ---- Your comment on 3.5.6 Make Telephone Numbers "Click-to-Call": > 3.5.6.2 > Maybe a mention of the format of the number used in the tel: URI > A best practice is to use a full international number prefixed by + > and a country code. > This is recommended in the RFC so it isn't necessary to include it > here, but it is currently quite common for people to use tel: URIs > with only local numbers that don't work in a different calling prefix > or different country. Working Group Resolution (LC-2284): We agree and have updated the example accordingly. ---- Your comment on 3.5.11 Use viewport Meta Tag To Identify Desired Screen Size: > 3.5.11.2 > Setting minimum-scale=1.0,maximum-scale=1.0 has accessibility impacts > as it usually makes it impossible to manually zoom into the screen, > which can be useful for visually impaired users. Working Group Resolution (LC-2285): We agree and have fixed the example and the text. ---- Your comment on 3.6.3 Use Device Classification to Simplify Content Adaptation: > 3.6.3.2 > Class 2 and 3 are very similar, the difference being the advanced APIs > available in class 3. For example, the iPhone v2.0 browser was class 2 > and v3.0 is class 3 by your classification. Typically these > differences don't require different variants, the class 3 device just > has a richer and faster experience. A more useful axis is touch screen > v non touch screen. Working Group Resolution (LC-2286): We agree, note that the classification depends on the type of application being considered, and have added a second example with the suggested touch screen class. ---- Your comment on 3.6.4 Support a non-JavaScript Variant if Appropriate: > 3.6.4 > There was no mention of <noscript>. Is this deliberate? Working Group Resolution (LC-2287): We agree and have added text regarding the use of <noscript>. ---- Your comment on 3.6.4 Support a non-JavaScript Variant if Appropriate: > 3.6.4.2 > Are we really recommending to send the user back a HTTP error code > that essentially provides no information to the user as to why their > request is "Not Acceptable". I understand this may be the 'correct' > behaviour, but the UX it results in is hideous. Working Group Resolution (LC-2288): We agree and have removed the reference to the 406 status code. ----
Received on Thursday, 17 December 2009 10:46:00 UTC