W3C

Disposition of comments for the Mobile Web Best Practices Working Group

Single page view

1-20 21-31

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2279 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We think that this limitation is obsolete and that the best practice is good in the generic case. We do not think that we can recommend an explicit size limit as this is likely to evolve over time. yes
LC-2275 Marc Wilson <marcwilson@google.com> (archived comment)
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
We understand the point but think that this would complicate things for authors who would then have to maintain different variants of their applications for different browsers. yes
LC-2280 Marc Wilson <marcwilson@google.com> (archived comment)
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 think that both best practices address cookies in very different ways and would not benefit from referencing each other. yes
LC-2271 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We disagree with the claim that there is no mobile-specific aspect to cookies (the shifting of data is mobile-specific). Generic privacy issues are considered out of scope of this document yes
LC-2265 Arthur Barstow <art.barstow@nokia.com> (archived comment)
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.
]]
We will follow the precedent set by various Recommendations which are guidelines, e.g. the Mobile Web Best Practices, and have Exit Criteria which shows that each Best Practice is implemented and therefore implementable.

Precise Exit Criteria have not been agreed upon as of today. The group expects to ask for at least two independently sourced implementations of each Best Practice.
yes
LC-2266 Arthur Barstow <art.barstow@nokia.com> (archived comment)
Re the use of "Non-Normative" in the titles of Appendix A and B:
given the SotD clearly states the document is non-normative, it seems
a bit redundant to restate it in the titles [hint: delete "(Non-
Normative)".
We agree and have removed "Non-Normative". yes
LC-2272 Marc Wilson <marcwilson@google.com> (archived comment)
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 will add text to 3.1.2.1. stating that work is in progress to unify these apis and pointing to the work of WebApps and Device API WGs.

Regarding the need to add UI treatment, we think we make sufficient comment about progress indications elsewhere in the spec.
yes
LC-2273 Marc Wilson <marcwilson@google.com> (archived comment)
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).
We agree but note the text already mentions that the JSON datafeed has to be suitably escaped when the eval() function is used. yes
LC-2274 Marc Wilson <marcwilson@google.com> (archived comment)
3.3.1.1
nit: double period at the end of first sentence
Thanks. Double period removed and sentence completed. yes
LC-2276 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We agree that the wording is too strong and have replaced "must" by "should". yes
LC-2277 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We agree but think that the current text in the "How to do it" already addresses this need. We have added a note to emphasize that a sign-out link should be also provided if automatic sign-in is enabled. yes
LC-2278 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We agree and have added the suggestion to the list. yes
LC-2281 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We agree and have reworded the section to remove mention of a specific DOM size. yes
LC-2282 Marc Wilson <marcwilson@google.com> (archived comment)
3.5.1.1
App Cache link should now point to: http://www.w3.org/TR/html5/offline.html

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.
Ref. App Cache, thank you, we have updated the reference.
Ref. initiating network requests before JS parsing, we think it depends on what the Javascript is supposed to be doing. Section 3.5.2.2 on minimizing perceived latency mentions moving Javascript to the bottom of the page. We also note that there is ongoing research on that topic.
yes
LC-2283 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We agree with the comment but think the current text already addresses such cases. yes
LC-2284 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We agree and have updated the example accordingly. yes
LC-2285 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We agree and have fixed the example and the text. yes
LC-2286 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We agree, note that the classification depends on the type of application being considered, and have added a second example with the suggested touch screen class. yes
LC-2287 Marc Wilson <marcwilson@google.com> (archived comment)
3.6.4
There was no mention of <noscript>. Is this deliberate?
We agree and have added text regarding the use of <noscript>. yes
LC-2288 Marc Wilson <marcwilson@google.com> (archived comment)
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.
We agree and have removed the reference to the 406 status code. yes

1-20 21-31


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:44:00 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org