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

Re: Responses to MWABP LC comments from Marc Wilson.

From: Adam Connors <adamconnors@google.com>
Date: Mon, 23 Nov 2009 12:46:01 +0000
Message-ID: <393b77970911230446h88d905o760158a87c0a7eb1@mail.gmail.com>
To: Marc Wilson <marcwilson@google.com>
Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>, Jo Rabin <jrabin@mtld.mobi>
Thanks Marc,

The text of this section has now been tightened up to be more explicit
without referring to any specific numbers because a) They'll quickly go out
of date; b) We have no easy way of  describing how to check them...
Hopefully the new version will answer your concerns. I'll send you a link as
soon as the updated version is published.

Regards,

Adam.

On Mon, Nov 23, 2009 at 12:38 PM, Marc Wilson <marcwilson@google.com> wrote:

> 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:46:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:54 UTC