Re: Re: please reivew mobileOK Basic Tests 1.0

 Dear Henri Sivonen ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the W3C mobileOK Basic
Tests 1.0 (2nd Last Call) published on 25 May 2007. Thank you for having
taken the time to review the document and to send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070928/.

Please review it carefully and let us know if you agree with it or not
before 19 October 2007. In case of disagreement, you are requested to
provide a specific solution for or a path to a consensus with the Working
Group. If such a consensus cannot be achieved, you will be given the
opportunity to raise a formal objection which will then be reviewed by the
Director during the transition of this document to the next stage in the
W3C Recommendation Track.

Thanks,

For the Mobile Web Best Practices Working Group,
Dominique Hazaël-Massieux
Michael(tm) Smith
W3C Staff Contacts

 1. http://www.w3.org/mid/CF7F7D96-B4BB-4412-9987-442F70D81008@iki.fi
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/


=====

Your comment on the document as a whole:
> >    mobileOK Basic is a scheme for assessing whether Web resources
> (Web
> >    content) can be delivered in a manner that is conformant with  
> > Mobile
> >    Web Best Practices [BestPractices] to a simple and largely
> >    hypothetical mobile user agent, the Default Delivery Context.
> 
> The draft is premised on a vision about mobile browsing that assumes  
> special mobile content. Instead of implying a separate Mobile Web, I  
> think the W3C should push for one World Wide Web with mobile browsers 
> 
> that can access general Web content.
> 
> Mobile access to general Web content can be accomplished in at least  
> two ways:
> 1) Putting a World Wide Web-ready browser engine on the mobile device 
> 
> (e.g. Minimo, the new S60 Browser, Opera for Mobile)
> 2) Using a distributed UA that puts a thin front end on the mobile  
> and keeps the main engine on an intermediate server (e.g. Opera Mini)
> 
> The premise of mobileOK seems to be that you take the non-Web-ready  
> thin browser and expect origin servers out there take special steps  
> to accommodate it.


Working Group Resolution:
The draft does not require mobile-specific content. It describes certain
requirements for content (which can be served to the web at large) in
order for that content to work even on basic mobile devices. Whether this
is achieved by having simple content (one possible approach) or by
adapting server side adaptation, or by use of client side capability like
@media rules and object elements, or some other mechanism is left
completely open to the content provider. This allows the content provider
to choose the approach to ensuring their content works on mobile that best
suits their situation, without forcing them to develop a specific mobile
version.

----

Your comment on the document as a whole:
> > It is not a test for browsers, user agents or mobile devices,
> >    and is not intended to imply anything about the way these should
> >    behave.
> 
> In practice, the draft is implying expectations about UA behavior.
> 
> >    Content passing the tests demonstrates that the content provider 
> 
> > has
> >    taken basic steps to provide a functional experience for mobile  
> > users.
> 
> I don't like the implication that pointy-haired managers are likely  
> to take statements like this and bother their teams about hunting a  
> badge of approval instead of testing that their sites work with  
> browsers that run on mobile devices and are capable of browsing the  
> real World Wide Web.


Working Group Resolution:
Proposed Resolution:

1. In practice, the draft is implying expectations about UA behavior.

In order to test Web sites some UA behaviour must be exhibited, there is
no implication that ALL UAs should exhibit this behavor.

2. I don't like the implication that pointy-haired managers are likely  
to take statements like this and bother their teams about hunting a  
badge of approval instead of testing that their sites work with  
browsers that run on mobile devices and are capable of browsing the  
real World Wide Web.

That is a concern. We make it clear that enhanced experience should be
made available and that all experiences should be tested on real phones.
Neither of those considerations devalues the need for a test for
suitability for a very basic device.

----

Your comment on 1.3 Claiming mobileOK conformance:
> > 1.3 Claiming mobileOK conformance
> >
> >    A standard mechanism will be defined that allows content  
> > providers to
> >    claim that a URI or group of URIs, such as a Web site, conforms
> to
> >    mobileOK Basic or mobileOK Pro. It will be possible to make  
> > claims in
> >    a machine-processable form. It will also be possible to notify
> end
> >    users of the presence of the claim by means of a human-readable  
> > mark.
> 
> I think testing content along the lines of mobileOK should be part of 
> 
> the internal quality assurance process of content providers. I think  
> it should not be part of the external marketing process.
> 
> When people are just hunting the badge for marketing purposes, they  
> may make silly workarounds to please the testing software while  
> actually making the user experience worse.


Working Group Resolution:
There is work in progress which will create guidelines for the usage of
mobileOK logos and trustmarks. For now, there is no real badge. We create
the badge as an incentive for following the guidelines, to reward
adoption. That's OK -- the problem comes when passing the tests requires
doing something actually harmful in the end. It's for this reason that
we've been a little more inclined to create warnings rather than failures.

----

Your comment on 2.3.2 HTTP Request:
> >      * Include an Accept header indicating that Internet media types
> >        understood by the default delivery context are accepted by  
> > sending
> >        exactly this header:
> > Accept: application/xhtml+xml,text/html;q=0.1,application/ 
> > vnd.wap.xhtml+xml;q=0
> > .1,text/css,image/jpeg,image/gif
> 
> The main request should not include the CSS type. The requests for  
> style sheets should only list the CSS type. Requests for images  
> should only list image types.
> 
> It is rather sad that the supported image formats do not include PNG.


Working Group Resolution:
We think that the request headers indicate general capabilities not
specific capabilities for any particular request. In the case of the
"main" request, it cannot be said for sure that the resource under test is
not a css resource. The tester takes no view aobut the format of a resource
under test when it requests it, it is only after it receives it that it
checks that it is valid HTML etc. In general we believe this is consistent
with User Agent behaviour which is not to assume that a resource is of any
particular format.

PNG is not included in the request header because it is defined as being
unsupported by the DDC. That in turn results from support not being as
widespread as other formats.

----

Your comment on 2.3.2 HTTP Request:
> >      * Check for consistency with HTTP headers, as follows:
> >        For each meta element with an http-equiv attribute:
> >        If a matching HTTP response header does not exist, warn
> >        If a matching HTTP response header exists but its value
> differs
> >        from the content attribute value, warn
> 
> These two should not apply at all to Refresh as Refresh is not used  
> on the HTTP level in the real world. On the other hand, they should  
> both be failures for the cache control because caching proxies should 
> 
> be able to work on the HTTP level without looking inside payload. For 
> 
> XML media types, the meta charset is always bogus so both cases  
> should fail to avoid people depending on the bogus meta charset. For  
> text/html, the case where the real HTTP header and the meta charset  
> disagree should be a failure, because the disagreement is a symptom  
> of something being wrong in the content production or serving process.


Working Group Resolution:
Our experience shows that Refresh is indeed used as an HTTP header. 

We note under CACHING that using meta http-equiv is undesirable for the
reasons you state. We have taken the view that it is undesirable to FAIL
implementations that cannot change their http headers but that make some
attempt to indicate their preference using meta http-equiv.

Your point about meta and charsets we believe is reflected under the rules
specified at 3.3 character encoding.

----

Your comment on 2.3.5 CSS Style:
> >    In the course of assembling the CSS Style:
> >      * observe the CSS Level 1 cascade
> 
> Specs written today should probably reference CSS 2.1 instead of  
> Level 1.


Working Group Resolution:
We encourage people to use CSS 2.1 where they know it is supported. If
they do not know it is supported then the DDC profile is defined to only
support CSS 1 and @media.

----

Your comment on 2.3.10 White Space:
> >    For XML 1.1 [XML11] it is defined in section 1.3 as consisting  
> > of the
> >    same characters with the addition of NEL (#x85) and the Unicode  
> > line
> >    separator character, (#x2028).
> 
> Surely an XML 1.1 document cannot get mobileOK approval.


Working Group Resolution:
Proposed Resolution:

If a document describes itself as XML 1.1 and passes the other tests then
it is eligible for mobileOK.

(status changed to resolved partial to reflect resolution on LC-1716)

----

Your comment on 3.2 CACHING:
> >    If any cache related header contains an invalid value, warn
> 
> Why not fail?


Working Group Resolution:
Many of the cache-related headers, like Cache-Control, can take on new
values in the future. Expires, for example, has defined behavior even on
values that are not dates. So 'invalid' is hard to define; all values have
a defined behavior and no known adverse effect, so we wish to be
conservative and not fail.

----

Your comment on 3.2 CACHING:
> > 3.2 CACHING
> >
> >    In the following, note that HTTP headers should be used rather
> than
> >    meta elements with http-equiv attributes, which are commonly not 
> 
> > taken
> >    into account by proxies.
> 
> The "should" should probably be a "must" for consistent results.


Working Group Resolution:
Reworded to work around this.

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> >    If the HTTP Content-Type header specifies an Internet media type
> >    starting with "text/":
> 
> This should apply to text/html.


Working Group Resolution:
The text is appropriate as it stands as "starting with text/" includes
text/html.

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> >    If there is no meta element with http-equiv attribute that  
> > specifies
> >    UTF-8 character encoding, FAIL
> 
> Note that the current HTML 5 draft uses an attribute called charset.
> 
> Having a meta charset in a document that is served using an XML type  
> (text/xml, application/xml and */*+xml) should probably be a warn at  
> minimum considering that a charset meta in XML is bogus.


Working Group Resolution:
Under 3.3 we specify that meta is only considered in respect of charset if
the content is served as text/html in which case it is required for the
benefit of non-XML processors. We think it is unreasonable to penalize its
presence in documents served as XML media types as it will be ignored in
practice and the content provider may have no knowledge or control over
the content type attached to their content.

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> >    If the HTTP Content-Type header does not specify a character  
> > encoding:
> >
> >    If there is no XML declaration, or UTF-8 character encoding is
> not
> >    specified in the XML declaration, FAIL
> 
> XML provides an unambiguous default. Is there a practical reason, due 
> 
> to broken real-world UAs perhaps, not to PASS defaulted UTF-8?


Working Group Resolution:
Right, we're asking content to go ahead and specify the default to give
every possible hint to the UAs, and stop them from ever trying to
second-guess the default and choose another encoding. Plus if the encoding
is not specified in the HTTP Header then that can mean that a non-UTF-8
default could be inferred. So we require explicit definition of the
encoding somewhere.

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> >    If the document's Internet media type is "text/html" or
> >    "application/vnd.wap.xhtml+xml", warn
> 
> What's wrong with HTML served as text/html?


Working Group Resolution:
XHTML Basic 1.1 is what's assumed and required, which should be served
as application/xhtml+xml, but may be served as these other types.
That's the reasoning behind the warn.

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> >    If the document does not contain a DOCTYPE declaration, FAIL
> 
> I think the W3C should promote doctypelessness for application/xhtml 
> +xml. See http://hsivonen.iki.fi/doctype/#xml
> 
> However, documents that rely on the WAP dollar substitution must have 
> 
> a doctype that activates the dollar substitution in Opera. Still,  
> relying on the dollar substitution is a bad idea.


Working Group Resolution:
It is not in our remit to alter existing specifications or to create new
specifications. Since XHTML Basic and XHTML MP both require a DOCTYPE to
be specified so do we. If dollar-substituion is a reference to WAP 1.x and
WML, then that is out of scope for mobileOK at the moment.

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> >    For each included resource (see 2.3.6 Included Resources):
> >
> >    If the response specifies an Internet media type that is not
> >    "text/css", "image/jpeg" or "image/gif", FAIL
> 
> Is there a good reason to exclude PNG?


Working Group Resolution:
The DDC is defined as not supporting PNG consequently it does not indicate
support for PNG in the request. Consequently receipt of PNG causes a FAIL.
At the time the DDC was specified there was consensus that PNG was not
widely enough supported on devices.

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> >    If the document is an HTML document and it fails to validate  
> > according
> >    to its given DOCTYPE, FAIL
> >
> >    If (regardless of its stated DOCTYPE) the document does not  
> > validate
> >    against the XHTML Basic 1.1 DTD:
> >
> >    If it does not validate against the XHTML-MP 1.2 DTD, FAIL
> 
> The spec is lacking sufficient guidance on how to validate an HTML  
> document against an XML DTD. Should perhaps an HTML5 parser be used  
> with a DTD validator that is decoupled from an XML parser?
> 
> Requiring content to validate against a mobile profile DTD does not  
> promote the unity of the World Wide Web.


Working Group Resolution:
A note has been added to clarify what this means under 3.4.

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> > and hence this test
> >    fails if a resource cannot be encoded in UTF-8.
> 
> s/cannot be/is not/


Working Group Resolution:
Change "cannot be" to "is not".

----

Your comment on 3.5 DEFAULT_INPUT_MODE:
> >    If the element's value attribute is missing or empty, and an  
> > inputmode
> >    attribute is not present, warn
> 
> This seems excessive as it is quite likely that things will be just  
> fine without content micromanaging the input mode on the UA.


Working Group Resolution:
The test is based on the Best Practices. We warn (not fail) in the absence
of an inputmode attribute.

----

Your comment on 3.14 NON-TEXT_ALTERNATIVES (partial):
> >    If an alt attribute is not present or consists only of white
> space,
> >    FAIL
> 
> This is a bad idea because it encourages badge hunters to include  
> bogus alt text that actually harms accessibility. Tests like this  
> only lead to an arms race where the placeholder data always gets a  
> step more complicated than what the testing tools can detect as a  
> placeholder.


Working Group Resolution:
The test specifically allows empty ALT tags which is the accepted way of
indicating that there is no appropriate ALT text.

----

Your comment on 3.15 OBJECTS_OR_SCRIPT (partial):
> >    If the innermost nested object element content consists only of  
> > white
> >    space, FAIL
> 
> See above.
> 
> (Where above is:)
> 
> >    For XML 1.1 [XML11] it is defined in section 1.3 as consisting  
> > of the
> >    same characters with the addition of NEL (#x85) and the Unicode  
> > line
> >    separator character, (#x2028).


Working Group Resolution:
Whitespace remains defined according to the document's XML version, but we
will remove informational reference to XML 1.1 to avoid confusion. We
intend to remain silent on version of XML used.

RESOLUTION: The meaning of the last resolution on LC-1703 and LC-1716 was
to remove the reference to XML1.1 and to stick with the text: Several
tests refer to white space. White space has the same definition in this
document as in XML. For XML 1.0 [XML10] it is defined in
http://www.w3.org/TR/REC-xml/#sec-common-syn  as being: S ::= (#x20 | #x9
| #xD | #xA)+ i.e. the characters SP, TAB, CR and LF.

----

Your comment on 3.21 STYLE_SHEETS_USE:
> >    If the document contains any b, big, i, small, sub, sup or tt
> >    elements, warn
> 
> These elements are relatively common and harmless in practice. This  
> warning seems excessive.


Working Group Resolution:
We encourage people to use CSS and hence a warn is justified.

----

Your comment on 3.21 STYLE_SHEETS_USE:
> >    If the document contains any basefont, bdo, center, del, dir,
> font,
> >    ins, menu, s, strike or u elements, FAIL
> 
> del and ins are legitimate in both HTML 4.01 and in the current HTML  
> 5 draft. menu is legitimate in HTML 5.


Working Group Resolution:
These tags are not defined in XHTML Basic or MP and therefore not
supported by the DDC or mobile phones in the marketplace.

----

Received on Thursday, 4 October 2007 15:27:38 UTC