W3C home > Mailing lists > Public > public-bpwg@w3.org > May 2009

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

From: Adam Connors <adamconnors@google.com>
Date: Mon, 4 May 2009 17:32:30 +0100
Message-ID: <393b77970905040932q7cfbcd25u20a59a8ff1d33a11@mail.gmail.com>
To: Francois Daoust <fd@w3.org>
Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC