Re: please reivew mobileOK Basic Tests 1.0

On Monday, June 11, 2007 at 12:04 PM, Henri Sivonen wrote:
> 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.
> [...]
> 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.

This is a fundamental criticism I have of the mobileOK guidelines. Mobile 
phone networks here in the UK have been promoting their "access the whole 
Web on your phone" capabilities for years. They can even do scripting [1].

Because so much web content is text/html, surely it is more useful to work 
on improving support for that in UAs? Mainstream mobile UAs already have 
better support for HTML than XHTML, many having no support at all for XHTML 
[2]. I can browse the text/html Web fine on my mobile phone in the 
here-and-now.

PDF and Word documents are also more common than XML formats on the web, in 
my experience. Improving support for them would surely be the next logical 
priority after HTML?

Advising against W3C technologies such as HTML and PNG seems like a strange 
move for a W3C Working Group to take. Especially since these technologies 
are already implemented widely.

Sorry if I have misunderstood the guidelines.

[1] <http://alastairc.ac/2006/10/mobile-browsing/>
[2] <http://simon.html5.org/articles/mobile-results>

Ben 'Cerbera' Millard
--------------------
http://projectcerbera.com

----- Original Message ----- 
From: "Henri Sivonen" <hsivonen@iki.fi>
To: <public-bpwg-comments@w3.org>
Cc: <public-html@w3.org>
Sent: Monday, June 11, 2007 12:04 PM
Subject: Re: please reivew mobileOK Basic Tests 1.0


>
> On Jun 7, 2007, at 19:45, Dan Connolly wrote:
>
>> I recently realized that this spec has various things
>> to say about how people should use HTML, so this working
>> group should be looking at it:
>>
>>   W3C mobileOK Basic Tests 1.0
>>   http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/
>>   W3C Working Draft 25 May 2007
>>   comments due to public-bpwg-comments@w3.org by 22 June 2007
> ...
>> If you have any comments that you think should be endorsed
>> by this Working Group, also send them here.
>
> Further quotes from the draft:
>
>>    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.
>
>> 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.
>
>> 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.
>
>>      * 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.
>
>>      * Include an Accept-Charset header indicating that only UTF-8 is
>>        accepted by sending exactly this header:
>> Accept-Charset: UTF-8
>
> Cool.
>
>>      * 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.
>
>>  (note that use of the style attribute is deprecated in XHTML Basic  1.1)
>
> Obsoleted, actually.
>
>>    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.
>
>>    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.
>
>> 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.
>
>>    If any cache related header contains an invalid value, warn
>
> Why not fail?
>
>> 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
>>
>>    The DDC is defined to support only UTF-8 encoding,
>
> Cool.
>
>> and hence this test
>>    fails if a resource cannot be encoded in UTF-8.
>
> s/cannot be/is not/
>
>>    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?
>
>>    If the HTTP Content-Type header specifies an Internet media type
>>    starting with "text/":
>
> This should apply to text/html.
>
>>    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.
>
>>    If character encoding is specified in more than one way, and not  all
>>    values are the same, FAIL
>
> Excellent.
>
>>    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?
>
>>    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.
>
>>    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.
>
>>    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?
>
>>    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.
>
>>    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.
>
>>    If the innermost nested object element content consists only of  white
>>    space, FAIL
>
> See above.
>
>>    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.
>
>>    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.
>
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>
>
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 
> 269.8.13/843 - Release Date: 10/06/2007 13:39
>

Received on Monday, 11 June 2007 16:56:10 UTC