- 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
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
grammars."
"[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
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.
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
undertaking.]
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
example).].
----
Your comment on 5.4.5 Non-Text Items:
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.]
Working Group Resolution:
We have added a link to the WCAG text explaining what non-text item means.
----
Your comment on 5.4.5.2 How to do it:
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.
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
[TESTING].
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
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.
Working Group Resolution:
We agree and have reworded the best practice to:
"Organize documents so that if necessary they may be read without style
sheets."
----
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 5.4.12.2 How to do it
:
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."
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
sheets"
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