- From: Adam Connors <adamconnors@google.com>
- Date: Mon, 4 May 2009 17:32:30 +0100
- To: Francois Daoust <fd@w3.org>
- Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
- Message-ID: <393b77970905040932q7cfbcd25u20a59a8ff1d33a11@mail.gmail.com>
On Tue, Apr 28, 2009 at 5:53 PM, Francois Daoust <fd@w3.org> wrote: > Hi Adam, > > Here are a few typos and a comments, which can be addressed after the > publication of a new draft. > > > Typos > ----- > 3.1.3.2 "HTML5 provides a provides a" > 3.2.1.2 "instead" appears twice in the sentence > 3.4.1.2 "Most images (especially JPEGs) does not" -> "do not" done > > 3.4.7.1 "be weighed" -> "be weighted" i believe this is correct as is. > > 3.6.4.2 "in some cases" appears in the same sentence as "sometimes", or are > we saying it's not a good idea? > done > > > 3.2.1 Do not execute untrusted Javascript > ----- > 3.2.1.2 could perhaps mention the fact that HTTP spoofing attacks are still > possible. A widget would typically have access to sensitive device APIs, but > could still use HTTP to retrieve JSON strings, so any man-in-the-middle here > could gain access to the same sensitive APIs in theory. This is particularly > relevant to mobile devices because access to the Web more and more relies on > a priori untrusted public Wifi networks. OK, I might have become crazy about > security-related topics... > sounds interesting -- can you explain a little more, i'm not sure i understand the issue sufficiently to write up. > > 3.4.3 Avoid Redirects > ----- > About "Try not to use more than two redirects for any request. If further > redirects are required". > Why not simply "Try not to use redirects. If more than two redirects are > required, [...]"? The first formulation seems to mean that one redirect for > each and every resource is just fine. > done. > > > 3.4.10 Don't Send Cookie Information Unnecessarily > ----- > The example in 3.4.10.2 could benefit from some more context (as in: where > is that "Set-Cookie" instruction supposed to go? Ah, it's a header in the > HTTP response, ok ok). I guess we should action someone to review examples > with a non-techie eye to ensure there can be understand by as many people as > possible. > sounds good... do you want to raise an action ? > > 3.5.8 Consider Mobile Specific Technologies for Initiating Web Applications > ----- > The term "push" is used slightly inconsistently. 3.5.8.1 talks exclusively > mentions "network-initiated push methods but then "QR codes" mentioned in > 3.5.8.2 are not exactly what I would call "network-initiated" or related to > "push" whatsoever. I think we should broaden the description of the BP to > match its title or stick to real push methods. > agreed -- can't think of wording right now, will address in future draft. > > > 3.5.10 Use viewport Meta Tag To Identify Desired Screen Size > ----- > The example in 3.5.10.2 should perhaps not disallow scaling of the page. It > removes the possibility to zoom in/zoom out I think, and thus it also means > that a user who finds the font too small can't do much about it. That's not > necessarily a good practice IMO. > the comment says that scaling is disallowed to prevent scaling when an input box is clicked... i can't remember where i got this from right now but will double check. agree that this tag needs some work to figure out exactly what the right recommendation is. > > > 3.6.1 Use Server-side Capability Detection for Static Device Capabilities > ----- > DDR is mentioned in 3.6.1.2 but is specifically linked to the "User-Agent" > header. Although that's probably true for the time being, nothing prevents a > DDR from using other headers. The term coined in DDR Simple API is > "evidence": > http://www.w3.org/TR/2008/REC-DDR-Simple-API-20081205/#sec-Evidence > In short, DDR applies to all the mentioned possibilities (possibly taken > together). > Eduardo had some issues with these... i'll raise an issue to discuss @ next call. > > > Francois. > > Thanks, Adam.
Received on Monday, 4 May 2009 16:33:10 UTC