W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2009

MWABP question: Is it possible to do some primary research into some ?of these BPs ?

From: Adam Connors <adamconnors@google.com>
Date: Tue, 17 Mar 2009 09:35:02 +0000
Message-ID: <393b77970903170235q6fcc9348lb0aa120ae4bfc7ba@mail.gmail.com>
To: casays@yahoo.com, "Appelquist, Daniel, VF-Group" <Daniel.Appelquist@vodafone.com>
Cc: public-bpwg@w3.org
Apologies for late response Eduardo...

> 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).

I think this is a crucial point. I agree this is an issue and if we can
resolve this question in the F2F next week the document will start to become
much more self-consistent.

Regarding your other points... I think what this document seriously lacks is
primary research... Many of the BPs mentioned are a summary of practical
experiences (what we are actually doing internally at Google right now) but
this isn't backed up by structured research across a range of platforms to
ensure it really qualifies as a best-practice.

I can only talk from personal experience, but I'd love for some of these
techniques to be validated / contradicted by some more structured study.

@dan -- Apologies that I can't make this afternoon's meeting but can you
maybe raise the question of whether we could find some bandwidth in the
group to do some concrete research into some of the proposed BPs... I'm
happy to take an action to put together a proposal for what we might want to
look at so long as we can find a willing volunteer to conduct some
research... I know it feels quite late in the day to start such a thing, but
without it I wonder at how much real value this document is providing.

On Thu, Feb 5, 2009 at 1:13 PM, Eduardo Casais <casays@yahoo.com> wrote:

> 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
> 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 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, 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 Tuesday, 17 March 2009 09:35:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:53 UTC