W3C

List of comments on “Mobile Web Best Practices 1.0” (dated 12 April 2006)

Quick access to

There are 15 comments (sorted by their types, and the section they are about).

substantive comments

Comment LC-456: Not using PNG
Commenter: Karl Dubost <karl@w3.org> on behalf of QA (archived message)
Context: test2 in (Graphics formats/PNG)
assigned to Giles Payne
Resolution status:

Hi,
This is a QA Review comment for "Mobile Web Best Practices 1.0"
http://www.w3.org/TR/2006/WD-mobile-bp-20060412/
Tue, 11 Apr 2006 12:18:21 GMT
Last Call WD

Did you have chosen these formats because it's really supported
everywhere?
I was wondering about PNG.

[[[
Image Format Support

JPEG
GIF 89a (non-interlaced, non-transparent, non-animated).
]]]
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-453
Commenter: Karl Dubost <karl@w3.org> on behalf of QA (archived message)
Context: 1.1 Purpose of the Document
assigned to Jo Rabin
Resolution status:

Hi,
This is a QA Review comment for "Mobile Web Best Practices 1.0"
http://www.w3.org/TR/2006/WD-mobile-bp-20060412/#iddiv2220152400
Tue, 11 Apr 2006 12:18:21 GMT
Last Call WD


I wonder if this following part should be in the status section. The
sentence will not bear the same meaning once you would have actually
published the companion documents. Or maybe you could modify the
sentence in a way that will not imply a future: "will be".


[[[
mobileOK and techniques for implementing the Best Practice
recommendations will be discussed in companion documents.
]]]
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-455
Commenter: Karl Dubost <karl@w3.org> on behalf of QA (archived message)
Context: 1.5 Relationship to other Best Practices and recommendations
assigned to Jo Rabin
Resolution status:

Hi,
This is a QA Review comment for "Mobile Web Best Practices 1.0"
http://www.w3.org/TR/2006/WD-mobile-bp-20060412/
Tue, 11 Apr 2006 12:18:21 GMT
Last Call WD

I have the same comment than previously about history. The "will
develop" seems not to be at the right place in a specification.

[[[
The BPWG will develop a companion document describing techniques
[Techniques] by which the Best Practice statements in this document
can be implemented.
]]]
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-452
Commenter: West, Mark Andrew <mawest2@bsu.edu> (archived message)
Context: [CAPABILITIES] Explo...
assigned to Jo Rabin
Resolution status:

I have read the current draft of the Best Practices document. Overall it is a good summation of all the guidelines (esp. OpenWave) I have been using under the Mobile Development Project at Ball State University Libraries.

While I have a few minor problems with the guidelines (GIF really ought to be put on pension since most mobile Web browsers can handle PNG), I take issue with the capabilities guideline (5.1.2): "Do not take a least common denominator approach."

As the mobile developer, my primary concern is to make library information and services available to the largest number of mobile users. I started with no knowledge of mobile devices; with a clunky development environment (IIS/Visual Studio/FrontPage); and with a vague idea of what devices were in use on campus. (Several attempts at an online survey of mobile devices fell flat.) Nonetheless I have created a mobile Web site for the University Libraries, that looks and works perfectly well using a strategy that the Best Practices document has labelled "least common denominator".

Perhaps you can add a "How To Do It" section under the capabilities guideline, or at least explain why following a LCD approach could result in a lesser experience for mobile users.

The University Libraries mobile Web site is http://www.bsu.edu/libraries/mobile/.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-442
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: [DEFICIENCIES] Take ...
assigned to Jo Rabin
Resolution status:

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.
88
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-443
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: [SUITABLE] Ensure th...
assigned to Jo Rabin
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-444
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: 5.4.5.2 How to do it
assigned to Jo Rabin
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-448
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: Document as a whole
assigned to Jo Rabin
Resolution status:

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."
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-454
Commenter: Karl Dubost <karl@w3.org> on behalf of QA (archived message)
Context: 1.4 Scope
assigned to Jo Rabin
Resolution status:

Hi,
This is a QA Review comment for "Mobile Web Best Practices 1.0"
http://www.w3.org/TR/2006/WD-mobile-bp-20060412/
Tue, 11 Apr 2006 12:18:21 GMT
Last Call WD


* Why the document scope has a direct reference only and not a link
in the reference section?
* I haven't figured out if it was troublesome to have the scope of a
specification in a W3C Note. It seems strange. At the same time, you
are making an abstract of it.

[[[
The scope of these Best Practices is laid out in "Scope of Mobile Web
Best Practices" [Scope]. In summary, this document refers primarily
to the extension of Web browsing onto mobile devices.
]]]
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-445
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: 5.4.5 Non-Text Items
assigned to Jo Rabin
Resolution status:

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.]
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-446
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: 5.4.9 Style Sheets
assigned to Jo Rabin
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-449
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: [CHARACTER_ENCODING_...
Not assigned
Resolution status:

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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-447
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: 5.4.12.2 How to do it
assigned to Jo Rabin
Resolution status:

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."
114
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-450
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: 5.4.16 Fonts
assigned to Jo Rabin
Resolution status:

5.4.16 Fonts. (Minor) I would move this section closer to "Style
sheets"
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-451
Commenter: Ian B. Jacobs <ij@w3.org> (archived message)
Context: 5.5.3 Labels
assigned to Jo Rabin
Resolution status:

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."
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org