- 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