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

Status

I retract the comment on Status (on the force of the pubrules), but suggest that the
W3C adjusts slightly its boilerplate to disambiguate the word "this":
------
This document was produced by a group operating under the 5 February 2004 W3C
Patent Policy. The present document is informative only.
------
Whatever. Nobody will die because of "this", I guess.



3.4.6

> End-user latency is the key motivator for spriting images. I know that they
> are used extensively in the development of all the mobile Web applications
> I've been involved with, but if we want concrete figures somebody needs to
> volunteer to do that experiment.

And that is the crux of the issue: those figures should _already_ exist, since
we are talking about a very specific optimization technique (not a general 
approach), unambiguously measurable both in terms of units (s or ms) and in terms
of its scope (latency), and which is advertised as used extensively in mobile
applications so as to be proposed as a best practice. It is surprising that none 
of the proponents of sprites is able to dig up existing quantitative evidence on
how much the optimization technique really helps.

All being said: I will not block the publication of the MWABP because of this point.
I find it somewhat questionable from a software engineering viewpoint, but if the
W3C is ok with it, then let it be.



3.5.2.2

> i can add a note if you like, but there are trade-offs in all these BPs
> and if we attempt to explicitly call out every one of them then the document
> will be unreadable. In this case my feeling is that the trade-offs are
> sufficiently obvious to omit.

In the case of 3.5.2.2, none of the other bullet points has such delicate 
consequences and difficult trade-offs. What about this addition:
-------
Developers should pre-fetch resources carefully at judicious time points, in order
to avoid increasing the latency of user transactions, impacting start-up time 
(section 3.5.1), or generating excessive network traffic because of prefetch
misses (section 3.4.4).
-------



3.6.1.2

> Do you think this is worth calling out explicitly ?
> Please provide some proposed text.

Here:
-------
Accept-Charset header field: the list of character encodings is especially
important when dealing with internationalization, and may help in selecting
or generating appropriate variant representations of multilingual applications.
Developers should be wary when the list contains "*", suggesting that the device
can accept every possible character encoding.
-------
And:
-------
Some user agents send proprietary HTTP header fields containing information about
terminal capabilities. Refer to RFC4229 for a list of such fields registered in
the IANA HTTP repository.
-------


E.Casais

Received on Monday, 22 June 2009 13:02:51 UTC