W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > April to June 2006

Re: Comments on 12 Apr 2006 MWI BP [Was: Last Call Comments on "Mobile Web Best Practices 1.0" (13 Jan 2006 draft)

From: <dom@w3.org>
Date: Thu, 18 May 2006 15:58:02 +0000 (GMT)
To: Ian B.Jacobs <ij@w3.org>
Cc: public-bpwg-comments@w3.org
Message-Id: <20060518155802.A1F136636C@dolph.w3.org>

Your comment on the document as a whole:
There are three practices that use the word "document" (31,

   40, and 43). Because most of the document refers to "content"

   rather than "documents", I recommend using "content" in the

   remaining three. If there was some reason for using "document"

   instead of "content," please make that clear in the spec.


   The same applies to the word "application" or other terms that

   are intended to be synonyms of "content"; one may think that

   the terms are used to refer to something other than "content."

Working Group Resolution:
The majority of uses of the word document are in reference to the BP

document itself or similar interpretations of the word document. 

In the following instances:

"[STRUCTURE] Use features of the markup language to indicate logical

document structure."

"[VALID_MARKUP] Create documents that validate to published formal


"[STYLE_SHEETS_SUPPORT] Organize documents so that they may be read
without style sheets."

We really do mean "document". There are a couple of places where document
is used in set phrases such as "document order" and "XML document". There
is one instance where you could argue that the word content should be
changed to document.

"Ensure that content is encoded using a character encoding that is known
to be supported by the target device."

But even in this case it is followed by

"Where possible, send content in a preferred format."

and we believe that it reads better as it stands, with this in mind.

Also, "application" is used appropriately and used in the sense of talking
about where the content comes from, rather than being specific that it
comes from a Web Server.


Your comment on [DEFICIENCIES] Take ...:
1) 5.1.3 Work around deficient implementations.

   Question: If I conform to standards without looking further,

   do I satisfy this practice?

   If the answer is "yes" then I am satisfied and ask only that

   this be made clear in the document.

   If the answer is "no, you have to do more than conform to

   standards," then I have an issue. I think it places an

   unreasonable burden on authors to have to learn about the

   diverse landscape of browsers, platforms, and bugs. There may

   be large organizations that have resources to do this, but I

   believe that for the millions of individuals or small

   organizations that will likely wish to satisfy this document

   (or be required to, who knows), this is an unreasonable


   Instead, I suggest: "Even if it means that you have to deviate

   from standards, you MAY work around deficient

   implementations."  I realize that the group is creating "best

   practices" and considers this to be good practice. However,

   even if satisfying this requirement is possible for a few

   content providers, I think it will be very difficult for

   ordinary authors.

   If content that conforms to the standards that define the

   default delivery context satisfies this requirement, then

   please make that abundantly clear. However, because authors

   are asked to do more than design for the default delivery

   context (practice #2), it still sounds like one is forced to go

   beyond the defaults in order to conform.

   Lastly, I believe a desirable property of conforming content

   is that once it conforms, it always conforms. Because browser

   bugs vary over time, content that once conformed may not

   conform in the future. One way to handle this is to date

   conformance claims, but that does not improve on the fact that

   the content's conformance status may vary over time.

Working Group Resolution:
The main point here is that no one is forcing anyone to do anything. So
there is no implication of 'have to' and there is a strong element of it
being a good thing to do. 

We note that it is a particular challenge to provide work-arounds and
where we say that deviation may be necessary we make the point in quite a
limited way [It is recognized that content providers may need to violate
specific Best Practices in order to support their intentions on devices
that exhibit deficiencies in implementation.]

However we use very strong language to encourage standards compliance [If
a device is not known to have specific limitations then content providers
must comply with Best Practices.] 

In summary, these comments are very relevant to mobileOK and should
feature largely in that thinking. However as noted above, the BP as it
stands is clear enough that it is an escape hatch for those that wish to
do better than the bare minimum.


Your comment on [SUITABLE] Ensure th...:
5.3.1 Page content. The practice says: "Ensure that content is

   _suitable for use in a mobile context_"

   I believe the purpose of this document is to explain what one

   needs to do to create content that is suitable for use in a

   mobile context. Requirements such as "avoid long sentences" or

   "prioritize information that relates to mobility" tell me what

   to do to achieve that goal.  "Ensure that content is suitable

   for use in a mobile context" tells me nothing and merely

   restates the project of the entire document. If you have

   specific ideas in mind here, please replace the current

   practice with those more specific requirements.

Working Group Resolution:
We have decided to clarify the point and satisfy Ian's need for examples
by providing a link to User Goals :

[Mobile users typically have different interests to users of fixed or

desktop devices. They are likely to have more immediate and goal-directed
intentions than desktop Web users. Their intentions are often to find out
specific pieces of information that are relevant to their context. An
example of such a goal-directed application might be the user requiring
specific information about schedules for a journey they are currently

and to the section on One Web: 

[Some services have a primarily mobile appeal (location based services,
for example). Some have a primarily mobile appeal but have a complementary
desktop aspect (for instance for complex configuration tasks). Still others
have a primarily desktop appeal but a complementary mobile aspect (possibly
for alerting). Finally there will remain some Web applications that have a
primarily desktop appeal (lengthy reference material, rich images, for


Your comment on 5.4.5 Non-Text Items:
5.4.5 Non-text items. What is the definition of "non-text


   I strongly recommend defining this in the document and using

   the latest WCAG definition. As a sample of why the definition

   poses challenges, consider these questions:

    * Is ASCII art text content or non-text content? 

    * Is a script that generates text considered non-text content

      or text content?

  [This term has years of discussion behind it in WAI.]

Working Group Resolution:
We have added a link to the WCAG text explaining what non-text item means.


Your comment on How to do it: How to do it: "Design pages as though they were to be

   displayed on a text-only browser."

   I believe a reader might misinterpret this sentence to mean

   "Design text-only pages" which I do not believe is your

   intention.  In the area accessibility, there is a

   misconception that text-only pages are accessible pages and

   therefore one should limit oneself to designing text-only

   pages to ensure that they are accessible. My concern is that

   the above sentence will perpetuate that misconception and

   introduce it into the MWI context.

   Proposal: "Design pages that transform gracefully when

   rendered in a text-only environments. Test your content with a

   variety of browsers, including text-only browsers in order to

   learn how some users will perceive them."  I recommend

   adopting the latest WCAG verbiage on this topic.

Working Group Resolution:
We think this is a fair point and have decided to update the BP to read

Design pages so that they are useful when rendered as text only. See also

And we have updated [Testing] to suggest that download of images is
disabled as part of testing.

"Content providers should also test with specific features disabled, such
as using text-only modes and with scripting disabled."


Your comment on 5.4.9 Style Sheets:
5.4.9 Style sheets. The first two practices are:

     "Use style sheets to control layout and presentation,

     unless the device is known not to support them."

     "Organize documents so that they may be read without style



   If I read these practices carefully, I think they probably

   don't conflict. But I think some readers might read these too

   quickly as "Use style sheets" and then "Don't use style

   sheets." For instance, suppose I want to achieve a particular

   layout. The right thing to do is to use style sheets (practice

   1) but if I use a feature in a particular way so that turning

   the feature off would cause the content to become unreadable

   (practice 2), then I probably should not use the feature. But

   then have I violated practice 1 by not using it? I can't quite

   put my finger on it, but I think there is some dependency

   between the practices that needs to be made more explicit. For

   instance, I could read them as:

    Use style sheets to control layout and presentation

       (1) unless the device is known not to support them,


       (2) do so in a manner such that when turned off, 

           the content remains readable.

   I wonder if this is an improvement:

     "Use style sheets to control layout and presentation,

     unless the device is known not to support them."

     "When using style sheets to control layout and presentation,

      organize content so that if the style sheets are turned off

      or not supported, the content may still be read."

   It is probably too long. Nonetheless, I think a slight

   clarification would help avoid confusion.

Working Group Resolution:
We agree and have reworded the best practice to:

"Organize documents so that if necessary they may be read without style


Your comment on [CHARACTER_ENCODING_...:
5.4.12 Character encoding. (Minor). The phrase "target device" is 

   used here where "device" is used elsewhere. It seems as though 

   "device" would suffice

Working Group Resolution:
Thanks for pointing out this anomaly. Target does appear to be redundant
here and in several other places too, so the document has been updated to
make the usage consistent - in the text of the best practices themselves.


Your comment on How to do it
: "All applications should support UTF-8". I think the

   word "application" may be confusing because it sounds like

   "software", and these are content guidelines, not user agent

   (software) guidelines. I read this as "Content providers, you

   can expect that software will support your UTF-8 content."

   Was there a particular reason behind the choice of the word

   "application?" Possible rewrite:

     "Content providers should make available at least a UTF-8

     encoding of content."

Working Group Resolution:
We feel that the word 'application' which is used in several other places
in the document with the same meaning is appropriate.

The text has changed slightly in this revision as a result of other
comments: "Since the Default Delivery Context specifies use only of UTF-8,
all applications should support UTF-8."


Your comment on 5.4.16 Fonts:
5.4.16 Fonts. (Minor) I would move this section closer to "Style 


Working Group Resolution:
The grouping is somewhat arbirary. We're reluctant to change the order as
the condensed list of BP's has been out for a little while and an
improvement in the consistency of the ordering would be at the expense of
consistency between revisions.


Your comment on 5.5.3 Labels:
5.5.3 Labels. (Minor) The practices in this section are about

   "Labels for Form Controls." I think that would be a clearer

   title. Also, I propose that you use "form control" instead of

   the bare word "control."

Working Group Resolution:
We agree and have made the relevant changes.

Received on Thursday, 18 May 2006 16:02:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:50 UTC