New Draft of MWABP uploaded (13th March) / Comments

My previous post on this topic 
lists.w3.org/Archives/Public/public-bpwg/2009Feb/0059.html
is still relevant.


Section 1.3.2

"Web pages delivered over HTTP which use either server-side or client-side 
processing".

This explicitly excludes applications that have a scripting component both on 
the client and on the server (e.g. AJAX). Is this really intended? If not, then
the correct formulation is "...which use server-side or client-side processing".


Section 1.3.4 

"Most best practices assume devices with basic XHTML, JavaScript, and CSS 
compliance".

The level of compliance for CSS or Javascript is left open. It is important to
clearly specify the type (XHTML basic? XHTML mobile profile? i-Mode XHTML? W3C
XHTML?) and version of XHTML (many possibilities), or the capabilities (e.g.
support for <script>, <object>, etc) considered. Thus, XHTML mobile profile 
support Javascript/ECMAScript only since version 1.1.


Section 3.1.2

"If HTML5 is supported".

Has the specification of HTML5 been finalized? How many browsers, commercially
deployed, implement HTML5? I would eliminate explicit references to HTML5, and
generalize the best practice to browsers that "support a client-side storage API"
-- these may be proprietary, of course.


Section 3.1.3.2

"Mobile Web applications should use these events to control the asynchronous 
replication of data back to the server".

Once again, specific features of a future technology are presented not as a 
solution, but as a best practice. I strongly advise asking experts for 
information on how synchronization is achieved _currently_ -- any relation with
SyncML?


Section 3.3.2

"When automatic network activity is disabled, periodically prompt the user to 
make network requests".
"Consider allowing the user to adjust the polling schedule and to control which
activities are allowed to initiate network requests".

This section seems to be mixing two cases:
a) exceptional network accesses occurring at unspecifiable times (e.g. error
reporting);
b) periodic network accesses by well-understood operations (synchronization,
polling).
The first recommendation relates to (a), whereas the second one to (b); they 
should probably be separated into two different best practices.


Section 3.4.2.2

"The working group is seeking recommendations for the best / most-commonly used
tools to reference in this section".

Do not use Minify; this utility is known to break applications, especially code
written in Javascript. In general, avoid tools that rely upon pattern matching
instead of proper lexical and syntactic analysis.


Section 3.4.6

"In some circumstances performance is improved if JavaScript and CSS style sheet
resources are included in the HTML page".

Well, let us put it this way: the actual best practice is "Keep common scripts
and style sheets as external resources, do not include them directly in pages".
The practice 3.4.6, right from its formulation, makes it clear this is not a 
best practice, but rather an exceptional one ("consider...", "in some 
circumstances..."). 

In fact, unbundling common resources from markup is recommended because:
1) It is more manageable (modifications of style sheets and scripts are 
centralized, rather than scattered in application templates or individual pages).
2) It improves caching, between different devices (network cache), and between
pages accessed by the same device (device cache).
3) Page sizes on mobile devices varies a lot (anything from 10K to 400K); 
scripts and styling reduce the payload available for markup.
4) In some devices, large pages are not cached (apparently, some versions of the
iPhone do not cache pages larger than 25K).

Bundling scripting and styling with the markup is usually done because 
5) The content is produced by an authoring tool that automatically includes or
generates styles and scripts directly inside the markup, and the tool cannot be
configured to keep these elements separate.
6) The target browser cannot use external resources (example: many i-Mode devices
cannot use external style sheets).
7) The target browser incorrectly retrieves external resources from the server,
instead of looking them up in the local cache.


Section 3.6.3.2

"The following is a typical configuration of application classes".

Given the focus of the document on applications, which usually require some form
of scripting and API, possibly AJAX, other typologies might be more relevant. In
practice, one will often see "horizontal" partitions that distinguish, for 
instance, between Windows Mobile devices (HTML + JScript), Series60 (XHTML + 
ECMAScript), and Blackberries.


Section 3.6.4

"Essentially this BP states that it is favourable to support 'Class 1' devices 
as defined above if at all possible".

Given the focus of the document, the number of practices that somehow deal with
scripting, AJAX, JSON, SVG, I wonder about the impact of this best practice.


E.Casais

Received on Friday, 13 March 2009 17:00:27 UTC