[MWABP] was: good practice for login forms

I agree with the general feeling that the MWABP document should make it clear
what kind of environment it assumes (device capabilities, network, perhaps even
users -- with, without disabilities for instance).

Section 1.3.4 indicates that "most best practices assume devices with basic 
XHTML, JavaScript, and CSS compliance." Which level of compliance for CSS or 
Javascript is left open. "Basic XHTML" is ambiguous: is it XHTML basic? Which 
version? Is XHTML mobile profile a "basic XHTML"? If so, note that for XHTML 
mobile profile 1.0 (one of the most widespread form of XHTML in the mobile Web),
Java/ECMA scripting is not standard. Then there is the curious mention in 1..3.2
of "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. Is this really intended? Though
widgets are mentioned in 1.3.2, no best practice seems to be based on them, 
neither on the increasingly popular Flash/Flash lite. Why not?

Throughout the document, one gets the impression that practices are intended
for high-end devices running Web 2.0-like applications; they do not seem 
particularly mobile-specific. But then come sections 3.6.3 and 3.6.4 which 
suggest supporting "bucket 1" (surely "category" is meant here) devices with 
"Basic XHTML support, no or very basic scripting. No AJAX support", and that 
"essentially this BP states that it is favourable to support "Bucket 1" devices
as defined above if at all possible". Which has several consequences:

a) If I return to the origin of the thread (passwords in forms), this means
proposing practices for devices with only phone keypads and no fancy virtual 
keyboards -- not just high-end devices with a full keyboard.

b) And if several categories of devices are to be supported, then some form of
casuistry seems unavoidable in the best practices -- although I duly appreciate
why Adam and François want to eschew that kind of approach.

There are other considerations where finer distinction are required. Thus,
section 3.4.7 suggests that "in some circumstances performance is improved if 
JavaScript and CSS style sheet resources are included in the HTML page, 
eliminating the need for additional HTTP requests to fetch the external files".
Section 3.4.7.2 list factors, but one is clearly missing: the capabilities of
the device itself. Let us remember that XHTML basic 1.0 does not support the
style element, whereas many i-mode XHTML devices neither support that element, 
nor external style sheets.

Furthermore, 3.4.7.2 could be clearer as to the direction, and ideally, give
values based on experience of the factors. This is especially important since, 
for instance, Steve Souders (from Google) in High-Performance Web Sites (CACM, 
vol.51, nr.2, 2008-12) clearly settles on "Rule 8: make JavaScript and CSS 
external" and substantiates it. From this perspective, 3.4.7 is an exceptional
practice that must be carefully justified. Of course, Luca Passani in "Global 
Authoring Practices for the Mobile Web", 2008-11, states exactly the contrary:
"[SIMPLE_CSS] Only use simple in-line CSS or none", based on the observation
that "XHTML MP mobile devices have different levels of support for the WCSS 
standard" and "it is not unusual that buggy (but nevertheless popular) devices 
simply do not cache CSS retrieved in previous requests, which ends up slowing 
the rendering for every page". However, he is also clear that "this practice 
may not apply in case the baseline is restricted to higher-end devices with 
more solid CSS support" -- which seem to be the main target of the MWABP.
 
All good reasons to define a DDC.


E.Casais

Received on Thursday, 5 February 2009 13:14:05 UTC