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

Re: Responses to MWABP LC comments from Marc Wilson.

From: Marc Wilson <marcwilson@google.com>
Date: Mon, 23 Nov 2009 12:38:01 +0000
Message-ID: <b578e9ef0911230438v92acc89vc607c3a1eb43d97a@mail.gmail.com>
To: Adam Connors <adamconnors@google.com>
Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>, Jo Rabin <jrabin@mtld.mobi>
On Fri, Nov 20, 2009 at 12:19 PM, Adam Connors <adamconnors@google.com> wrote:
> Hi Marc,
>
> Thanks for the detailed comments. Ultimately we'll make formal resolutions
> on each and do our best to answer your points in the document. In the
> meantime though I was asked to make initial responses directly (and on the
> mailing) list to stimulate some discussion.
>
> Note that these are just my thoughts / opinions -- we'll use this email (and
> any follow-up responses you might want to send) as the basis for discussion
> on our next call.
>
> (Nb also, a few other people have open issues on the LC list for MWABP which
> will get the same treatment, I'm just starting here because you have so far
> made the most comments).
>
>
>
> thanks,
>
> Adam.
>
> 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.
>
>
> I agree that many of the issues around cookies and mobile seem less
> relevant with newer devices, but the additional complexity of the MNO
> interfering with requests probably means it's worth still calling this out.
>
>
> Regards security, yes, we had some comments on this in earlier drafts
> of the document but ultimately cut them since security is such a tricky
> issue to engage with. The issue of location, for example, doesn't just
>
> apply with cookies... Would you go so far as recommending that all
> requests containing location information should be encrypted ? That might
> be overkill in some scenarios.
>
> I have to admit we've slightly chickened out here in the absence of any
>
> concrete recommendations that we all felt comfortable making.
>
>
> 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.
>
> We have another comment on these references so we'll look into it. The goal
> is not to make this document dependent on any particular technology, hence
>
> the smorgasbord of references.
>
> I agree on the "uncommitted" comment and think we should add a sentence
> to cover this.
>
> 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).
>
> That's kind of what I meant, "ensure that user-generated content is
>
> correctly escaped", I'll add "on the server" to the end of this sentence.
>
> 3.3.1.1
>
> nit: double period at the end of first sentence
>
> Fixed
>
>
> 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
>
> I'd be concerned this would just complicate things -- you'd then wonder
>
> whether you had to produce a different variant of your application for
> different
> browsers, which we know no-one will ever really do for this kind of thing...
> (or
> at least, I wouldn't). I hope the phrasing "an icon is usually sufficient"
> is suitably
>
> relaxed that no-one will take this as a strong recommendation to implement
> features
> that might not be necessary in some scenarios.
>
>
> 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.
>
> Agreed. I'll change must to should. (Must has rather specific meanings in
>
> w3c anyway which are best avoided in this context).
>
> 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.
>
> This is a good point. I think we should add something along these lines.
>
>
>
> 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.
>
> Good point. I think we should add that to the list of suggestions.
>
>
> 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.
>
> You mean because a document > 25kb won't get cached... Is that still an
> issue
>
> on iPhone... The 25kb thing I thought was just a pathological screw-up in
> very
> first versions and had been resolved now...

I haven't been able to find a definitive source, but
http://rambleon.org/2009/09/05/iphone-caching-redux/
seems to indicate that it might not be an issue on iPhone any more.
If I get time I'll do some investigation of my own.

> I wouldn't want to put in a warning in response to a bug in a specific
> handset, though
>
> I think a "within reason" comment could be called for.
>
> 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
>
> We had it like this in an earlier draft and decided to call out separately
> since the
>
> intent of the recommendation is sufficiently different.
>
>
> 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)
>
>
> This number came from the people who built a certain well known mobile
>
> Web email-client based on their iphone / android testing... I agree that
> this BP is
> hard to act on for all the reasons you raise however, so I think we should
> tighten
> up the language here.
>
> If you have any suggestions for how to improve this BP that would be much
>
> appreciated.

Maybe rather than a size in bytes, a metric in terms a number of DOM
elements is more understandable. It may not capture the full memory
footprint, but it is something easily understandable and calculable.

>
> 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.
>
> The intent of "clip content" was kind of what you describe: e.g. If a user
> has 3000 emails
>
> don't try to display them all on the screen, display the first 10, and a
> link to dynamically load
> the next 10... We should tidy up the language here to avoid this confusion.
>
>
> 3.5.1.1
> App Cache link should now point to: http://www.w3.org/TR/html5/offline.html
>
> Will do.
>
>
> 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.
>
> Good point.
>
>
> 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.
>
> Agreed. The thing that this BP warns against is quite pathological, and it
>
> inadvertently might discourage people from changing focus in legitimate
> use-cases.
>
>
>
> 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.
>
> Yep, for convenience I think this is worth calling out in this doc since it
>
> would be an easy mistake to make.
>
>
> 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.
>
> Good point. Will remove.
>
>
> 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.
>
> Fair point. We'll have to discuss. These 3 classes started out
> WML/XHTML/AJAX
>
> but we shunted them up since WML isn't very relevant to a doc on Web
> Application
> BPs... Agree that the distinction between 2/3 is not very relevant at this
> point in time.
>
> Perhaps we should just have two device classes in this example.
>
>
>
> 3.6.4
> There was no mention of <noscript>. Is this deliberate?
>
> 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.
>
> Both good questions, I can't remember the outcome. We'll discuss in the
> group.
>
>
>
>
>
> thanks, please get back to me with any follow-up questions / clarifications
> / or if you have
> a suggestion for 3.4.11 (or any other BPs for that matter).
>
>
> Regards,
>
> Adam.
>
>
>
Received on Monday, 23 November 2009 12:42:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:03 UTC