- From: Marc Wilson <marcwilson@google.com>
- Date: Tue, 22 Dec 2009 15:52:54 +0000
- To: fd@w3.org
- Cc: public-bpwg-comments@w3.org
Dominique, François et al., Thanks for taking my comments on board. I agree with your responses and the subsequent changes made. Cheers -Marc On Thu, Dec 17, 2009 at 10:45 AM, <fd@w3.org> wrote: > > 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 Tuesday, 22 December 2009 15:55:57 UTC