Comments on Mobile Web Best Practices 1.0 (17 October)

Some comments on http://www.w3.org/TR/2005/WD-mobile-bp-20051017/
follow.  Some are editorial, some are not.

Section 1.2 (Audience) uses the term "players" to refer to all parties
involved in use of the Web on mobile devices.  While this is a
reasonable use of the term, I've frequently heard the term used to refer
to browsers, especially in the SVG and Flash communities.  It would
probably be better to avoid using a term that could be misinterpreted;
"participants" or "parties" (although it doesn't work as well
grammatically) would probably be better.

Section 1.3.3.9 (Best Practices refer to Server Implementations not
Clients) seems to use the word "server" with a meaning different from
the common use (referring to a machine at one end of a transaction).  A
more general word should probably be found here.

Section 1.4 (Baseline Client) says "Some opinion states that WML should
be assumed."  If these best practices are describing how to write
content that can be viewed on both mobile and desktop devices (which I
think they should be), then it can't, since typical desktop browsers do
not support WML.

It also says "Some opinions support the notion that a minimum row and
column availability for text presentation needs to be specified."  If
such a thing were to be specified, it seems likely to be script and
perhaps even language-dependent.

The "Maximum Page Weight" device characteristic, if defined, would need
to state whether it's describing the maximum page weight that can be
displayed quickly and without degrading usability or whether it's
describing the maximum page weight that can be displayed without causing
application failure (either crash or failure to display the entire
page).  It's currently unclear to me which of those two is being
discussed, if not both at the same time.

Section 1.6 (Relationship to other best practices and recommendations)
refers to all of the work of the DI working group; it would probably be
clearer to refer to specific documents, whether extant or expected in
the future.

Section 2 (How the Best Practices are Organized) seems to me to have
limited value, especially this far into the document.  It seems to be
describing not the organization of the best practices, but the
organization of the document itself.  Would it be better to move each
sentence of description to the beginning of the section described?

Section 3 (Requirements) says the requirements are divided into user
experience and device limitations.  However, these are the titles of 2
out of the 7 subsections of this section; the placement of the remainder
into these categories is not entirely clear.

Section 3.1 (User Experience) spends most of the section describing a
device limitation: screen size, and it is the only part of Section 3
that does so directly.  Perhaps the screen size device limitation should
have its own section?

Section 3.4 (Content Type) should be retitled: its title is dangerously
similar to that of 5.5.11 (Content Types), which is referring to the
commonly known meaning of the term.  Perhaps "User Goals" or at the very
least, "Types of Content"?

In response to the request for comments in Section 4.2, which says "The
group seeks public feedback on the desirability of stating that, in
practice, adaptation is required for delivery to mobile devices; and
that consequently, in view of the desirability of making content widely
accessible across a broad range of devices, all Web development requires
adaptation.", I would respond by saying that expecting all documents on
the Web to be adapted on the server is completely unrealistic.  There is
a huge amount of content on the Web; much of the volume of content
(although not the most visited content) fits within the original purpose
of HTML (documents rather than user interface).  If site-wide
navigational content could be better separated from content unique to
the page, much of the content on the Web should not (given correct use
of existing standards) require adaptation, at least assuming that device
limitations on page size are not too small.  This huge volume of content
is one of the things that makes the Web so useful.  If it's not
accessible to mobile devices, then the mobile Web isn't really the Web.
(Note that I don't consider the presentation of additional user
interface and document splitting based on heading (HTML <Hn>) structure
to be adaptation in a strict sense: it's well within the conformance
requirements for HTML4.)

Section 5.3.5 (Navigation Mechanisms) suggests that content authors
provide navigation mechanisms in a consistent manner.  They would be
much more consistent for users if they are instead provided by the
browser, based on things like heading structure.

I'm skeptical of the usability of author-assigned access keys, which are
promoted by section 5.3.6 (Access Keys).  Have they really been shown to
be usable on mobile devices?  (Section 5.6.2 (Tab Order), which is a
similar issue, does seem to take the position I prefer: browser-defined
rather than author-defined.)

Section 5.4.4.2 (Scrolling / How to do it) should also mention the
alternative of preferring layout models where width information is input
to the process of laying out child elements (e.g., CSS block layout)
over layout models that depend on intrinsic withs (e.g., tables, CSS
floats).

The first guideline in section 5.4.8 (Background Images) seems to
provide advice that is too extreme.  There is no need to avoid
background images when a device can't support them:  they should simply
have a color behind them (background-color on the same element) that
also yields readable text.  (That said, avoiding background images on
all mobile devices for readability and bandwidth reasons seems like
reasonable advice.)

Section 5.5.6 (Valid Markup) should probably be broader: the content
should be conformant to the relevant specifications.  Having a guideline
suggesting validation as a way to *help* ensure this is good, but
validation does not ensure conformance, and nonconformant content that
is valid can cause just as many problems as nonconformant content that
is not.

Section 5.5.12.2 (Character Set / How to do it) should also mention how
to use @charset rules in CSS.

Section 5.6.2 (Tab Order) could be more explicit that relying on
browser-defined tab order leads to a more consistent user experience
than when authors define tab order.

Section B (Acknowledgements) has "*" next to many names, but doesn't say
what it means.  The word acknowledgments is also perhaps misspelled, or
at least using the less preferred spelling.

-David

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation