A few comments on latest draft of Mobile Web Application Best Practices

Hi Adam,

Here are a few typos and a comments, which can be addressed after the 
publication of a new draft.

----- "HTML5 provides a provides a" "instead" appears twice in the sentence "Most images (especially JPEGs) does not" -> "do not" "be weighed" -> "be weighted" "in some cases" appears in the same sentence as "sometimes", or 
are we saying it's not a good idea?

3.2.1 Do not execute untrusted Javascript
----- 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...

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.

3.4.10 Don't Send Cookie Information Unnecessarily
The example in 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.

3.5.8 Consider Mobile Specific Technologies for Initiating Web Applications
The term "push" is used slightly inconsistently. talks 
exclusively mentions "network-initiated push methods but then "QR codes" 
mentioned in 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.

3.5.10 Use viewport Meta Tag To Identify Desired Screen Size
The example in 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.

3.6.1 Use Server-side Capability Detection for Static Device Capabilities
DDR is mentioned in 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":
In short, DDR applies to all the mentioned possibilities (possibly taken 


Received on Tuesday, 28 April 2009 16:54:09 UTC