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

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

From: Ian B. Jacobs <ij@w3.org>
Date: Thu, 20 Apr 2006 10:42:45 -0500
To: dom@w3.org
Cc: public-bpwg-comments@w3.org
Message-Id: <1145547765.10706.141.camel@jebediah>
On Wed, 2006-04-12 at 17:05 +0000, dom@w3.org wrote:
>   Dear Ian Jacobs ,
> 
> The Mobile Web Best Practice Working Group has reviewed the comments you
> sent [1] on the Last Call Working Draft [2] of the Mobile Web Best
> Practices 1.0 published on 13 January 2006 Thank you for having taken the
> time to review the document and to send us comments!
> 
> This message holds the disposition of the said comments on which the
> Working Group has agreed. This disposition has been implemented in the new
> version of the document available at:
> http://www.w3.org/TR/2006/WD-mobile-bp-20060412/
> 
> Please review it carefully and let us know if you agree with it or not
> before 3 May 2006. 

[snip]

Dear MWBP WG,

Thank you very much for your consideration of my comments on the 13
January 2006 draft! I am satisfied with all of your replies to my
comments (even if I do not agree with all of them). I have read the
12 April draft and have a MUCH SMALLER set of comments on that
document. I appreciate your diligence in managing the input you have
received and look forward to your rapid progress to Recommendation.

Please consider my comments below on your second Last Call document.
Thank you,

 _ Ian

----------------
Important issues
----------------

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

   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.

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

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

---------------------
Seeking clarification
---------------------

1) 5.4.5 Non-text items. What is the definition of "non-text
   element?"  

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

2) 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
     sheets."
     
   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,

       AND

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

3) 5.4.12.2 "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."

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

--------------
Minor Comments
--------------

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

2) 5.4.16 Fonts. (Minor) I would move this section closer to "Style 
   sheets"

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

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Thursday, 20 April 2006 15:43:19 UTC

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