RE: New MWABP draft. (LC candidate ?) / comments

Status

--------
This document was produced by a group operating under the 5 February 2004 W3C Patent
Policy. This document is informative only.
--------

To avoid confusion, perhaps the following text would be suitable:

The present document was produced by a group operating under the 5 February 2004 W3C
Patent Policy; the latter document is informative only.

Although, is it true that the patent policy document is informative only? Is it not
binding upon the work of the various W3C groups?



3.1.1.1

Complement
--------
See BP1 [COOKIES] Do not rely on cookies being available for more cookie related 
caveats.
--------
as follows:
--------
See BP1 [COOKIES] Do not rely on cookies being available for more cookie related 
caveats and approaches to work around their unavailability.
--------



3.2.1.2

-------
JSON parsers are approximately x10 slower than eval and may be impractical for large
datafeeds
-------
Just to clarify: what is meant with a "large data feed"?
a) is it a reference to a limit on the size of the JSON fragments that are passed to
the terminal (i.e. the parser cannot handle large objects)
b) or a reference to the throughput of the feed to the terminal? (i.e. the parser 
cannot handle the numerous and frequent arrivals of JSON data efficiently)
>From the discussion on the speed of Javascript parsers, I presume it is (b).



3.3.3.1

The following practice
-------
These notices should be provided when the user first accesses the Web application,
on first access to user information, or in help pages.
-------
means that a valid way to implement it is to let the application access the personal
information, just mentioning that such accesses are performed in some hidden corner
of the help menu. Is this what is intended?



3.4.6

Well, the discussion on sprites still leaves me wondering whether we are trading a
reduction in network latency (less HTTP transactions to retrieve images) for an
increase on terminal CPU latency (because of interpreting more complex CSS and
rendering images in more complex ways), so that the net gain might not be as
substantial as suggested. There were enough hints in Stephanie's message (and in
other places as well) that sprites require careful optimization on the client side,
so all this nourishes my suspicions. Furthemore, the effects of caching reduce the
amortized cost of not using sprites (also in the light of 3.5.1). So once again,
where are the figures?

Note that even if latency is not reduced significantly, this does not mean that
sprites are useless: reducing the _number_ of I-O requests to handle is a benefit
for _servers_ (and one that gets mentioned by developers), while sprites might have
advantages for content management (I will not attempt to settle the discussion
between Stephanie and Rotan on this point). All these could make for best practices,
though not for the reduction of end-user latency.



3.4.10.2

"unneeded cookie information" => "superfluous cookies".



3.4.11

-------
Keep the DOM size below 10MB to avoid browser crashes.
-------
Just curious: is this limit based on experience reports?



3.5.2.2

With pre-fetching
-------
Preload Probable Next Views: If the flow of a particular Web application means
certain paths through the application are more probable, preload these views so
they can be displayed immediately when the user requests them.
-------
the difficulty is when to do it.
a) It increases start-up time when done during application initialization (against
   3.5.1).
b) It increases latency when done during a user-originated request (against 3.5.2 
   itself).
c) When done in the background, at times when the user is interacting with the 
   application but not the network, it goes against 3.4.4 and might raise issues
   with 3.3.1).
Some additional recommendation or warning is needed here.



3.5.8.1

Editorial:
-------
Data updated on one devices should be viewable consistently on other devices.
-------
should be "updated on one device".



3.6.1.2

Two remarks:
a) The header field "Accept-Charset" is relevant and important as well.
b) Various browsers (notably IE Mobile and Opera) send proprietary header fields
containing information about the device capabilities. The Microsoft-specific fields
are of particular relevance, as they are well-established and recorded in the IANA
provisional HTTP registry and in its associated RFC4229.



3.6.2.2

I always have some difficulties to include technologies, such as DCCI and OMA DPE,
which are just being standardized, have few, if any, implementations, and for which
no experience is available to derive best practices.

I suggest separating DCCI and DPE from the Javascript and CSS bullet points (the
latter are "available to the developer", the former are not), and prefix them with
the following sentence:
-------
Other emerging techniques that may become relevant to the developer are:
[... put here DCCI and DPE bullet points ...]
-------



E.Casais

Received on Monday, 22 June 2009 10:08:33 UTC