W3C

List of comments on “Mobile Web Application Best Practices” (dated 6 October 2009)

Quick access to

There are 31 comments (sorted by their types, and the section they are about).

1-20 21-31

general comment comments

Comment LC-2265
Commenter: Arthur Barstow <art.barstow@nokia.com> (archived message)
Context: Status of this Document
Not assigned
Resolution status:

Re Status of the Document (SotD) section: given this document is
purely non-normative, why is this document "expected to become a W3C
Recommendation" rather than a Working Group note? For example, how
would this document ever be able to meet the following entrance
criteria for Proposed Recommendation:

[[
http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

2. Shown that each feature of the technical report has been implemented.
]]
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

typo comments

Comment LC-2274
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.3.1 Inform the User About Automatic Network Access
Not assigned
Resolution status:

3.3.1.1
nit: double period at the end of first sentence
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2271
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.1.1 Use Cookies Sparingly
Not assigned
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2279
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.4.5 Minimize External Resources
Not assigned
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2290
Commenter: Robin Berjon <robin@berjon.com> (archived message)
Context: 1.3.2 Web Application
Not assigned
Resolution status:

1.3.2: "Web Widgets Effort" that would be the "W3C Widgets effort", or perhaps the "W3C Widgets family of specifications" (as WebApps call them).
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2291
Commenter: Robin Berjon <robin@berjon.com> (archived message)
Context: 1.5 Terminology
Not assigned
Resolution status:

1.5: "The implicit reference to XML suggested by the names is commonly accepted to be an historical anomaly." It's historical for sure, but it's not really an anomaly: it really corresponded to what people were thinking of at the time.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2272
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.1.2 Use Appropriate Client-Side Storage Technologies for Local Data
Not assigned
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2292
Commenter: Robin Berjon <robin@berjon.com> (archived message)
Context: 3.1.2 Use Appropriate Client-Side Storage Technologies for Local Data
Not assigned
Resolution status:

3.1.2.1: Storage has been split from HTML5, and there are several parallel local storage efforts in WebApps. In general it would be good to be more precise: "BONDI [BONDI], HTML5 [HTML5], and Opera Widgets [OPERA]" isn't very helpful. For instance, are you thinking of the BONDI address book interface? Or the file system interface? The calendar API? They can all store local data.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2293
Commenter: Robin Berjon <robin@berjon.com> (archived message)
Context: 3.2.1 Do not Execute Unescaped or Untrusted JSON data
Not assigned
Resolution status:

3.2.1.2: Note that some browsers now ship with native JSON parsing.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2273
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.2.1 Do not Execute Unescaped or Untrusted JSON data
Not assigned
Resolution status:

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).
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2294
Commenter: Robin Berjon <robin@berjon.com> (archived message)
Context: 3.3 User Awareness and Control
Not assigned
Resolution status:

3.3: "Browsers may have access to information such as: • Pictures, music, and video clips; • Contacts, calendar (PIM data); • Call history; • System data (battery, coverage, roaming, location); • Media recording (record audio/video clip, get new picture); • Device context (e.g. location, connectivity, profile setting)."

I am not aware that there are any plans to grant browsers access to such information gratuitously. They may be granted within web runtimes, but even then with clear restrictions. In general this seems to address implementers more than authors.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2295
Commenter: Robin Berjon <robin@berjon.com> (archived message)
Context: 3.3.1 Inform the User About Automatic Network Access
Not assigned
Resolution status:

3.3.1: Also seems to be more for implementers than authors. This information should be provided in a consistent manner by the UI, not the app. The BP I expected here is the one in 3.3.2.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2275
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.3.1 Inform the User About Automatic Network Access
Not assigned
Resolution status:

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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2276
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.3.2 Provide Sufficient Means to Control Automatic Network Access
Not assigned
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2296
Commenter: Robin Berjon <robin@berjon.com> (archived message)
Context: 3.3.3 Ensure the User is Informed About Use of Personal and Device Information
Not assigned
Resolution status:

3.3.3: Again, implementer-orientated. I think that it would be more useful to have separate documents for authors and implementers. Also, the notion that putting notices about usage of a user's personal information in help pages implements a best practice is somewhat dubious. It's hard to find users accessing help pages on a desktop, I don't believe anyone ever does on a mobile (in fact, I'm not sure where I'd find such things).
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2277
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.3.4 Enable Automatic Sign-in
Not assigned
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2297
Commenter: Robin Berjon <robin@berjon.com> (archived message)
Context: 3.4.1 Use Transfer Compression
Not assigned
Resolution status:

3.4.1.2 This should also mention that EXI has been registered as an HTTP content coding, and can be used. It has the substantial advantage that in most configurations it is smaller while also requiring fewer cycles to decode.

"For very small files (e.g. <1k) the negative impact of processing may outweigh any small transport gains." Note that for very small files, gzip will render them larger anyway.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2278
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.4.4 Optimize Network Requests
Not assigned
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2280
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.4.10 Don't Send Cookie Information Unnecessarily
Not assigned
Resolution status:

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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2281
Commenter: Marc Wilson <marcwilson@google.com> (archived message)
Context: 3.4.11 Keep DOM Size Reasonable
Not assigned
Resolution status:

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)

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-31

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org