Disposition of comments for the Mobile Web Best Practices Working Group

> One sub-point I'd like to make is that it's not wrong for the user
> agent to say nothing about what it accepts. It's also not wrong to
> list everything it accepts every time, according to HTTP. If a request
> for a CSS file retrieves a text/html document, well, sounds like the
> site is quite broken. This is not a user agent problem.

I think I interpret this rather different from you. That is, the user
agent indicates which types it supports for a particular request. So if it
says text/html when it fetches a style sheet it indicates it can process
text/html as a style sheet for the current page. Or if it fetches an image
that it can show text/html resources as images.

> * 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.

> * 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.

> 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.

> If any cache related header contains an invalid value, warn

Why not fail?

> 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 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 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.

3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

The DDC is defined to support only UTF-8 encoding, which means that this test fails if a resource cannot be encoded in UTF-8. It is reasonable to recommend that default character encoding should use UTF-8. But it is not good that all of another character encoding except UTF-8 should be FAIL.

In many cases, if some country does not use English as a native language, they are using various character encoding schemes. For example, EUC is a multibyte character encoding system used primarily for Japanese, Korean, and simplified Chinese. The EUC-KR and EUC-JP(ISO-2022) encoding is heavily used in Korea and Japan. [1]

UTF-8 is not widely used in Korea. EUC-KR is more popular character encoding scheme in Korea (maybe more than 90% of Wired and Mobile web contents). It is the most widely used legacy character encoding in Korea on all three major platforms. Therefore, if we support only UTF-8, more than 90% of sites and contents will be ‘FAIL’.

So, it is proposed to consider additional character encodings. It is proposed to modify the section 3.3 as below:

PROPOSED TEXT:
------------------------
If the HTTP Content-Type header specifies a character encoding:
If character encoding is default-character-encoding, PASS
If character encoding is not default-character-encoding, warn
If the HTTP Content-Type header does not specify a character encoding:
If there is no XML declaration, or default character encoding or any character encoding is not specified in the XML declaration, FAIL
If the HTTP Content-Type header specifies an Internet media type starting with "text/":
If there is no meta element with http-equiv attribute that specifies default character encoding or any character encoding, FAIL
If character encoding is specified in more than one way, and not all values are the same, FAIL
If the document is not valid default character encoding or any character encoding (see 2.3.9 Validity), FAIL
For each resource specified by 2.3.6 Included Resources:
Request the resource
If the HTTP Content-Type header value of the response starts with "text/" but does not specify default character encoding or any character encoding character encoding, warn
PASS
------------------------

[1] http://lists.w3.org/Archives/Member/member-bpwg/2007Jul/0047.html

3.6 EXTERNAL_RESOURCES

Currently, the condition value is too small. So it is hard to support normal UI with this condition.

It is proposed to increase the value, about 50 (this value derived from the statistical results of Korean CPs)

PROPOSED TEXT:
------------------------
For each such resource:
Request the resource, and add one to a running count
Add to the count the number of HTTP redirects (HTTP 3xx status responses) that must be followed and authentication requests that must be made until the resource itself is successfully retrieved
If this total exceeds 20, warn
If this total exceeds 50, FAIL
PASS
------------------------

[1] http://lists.w3.org/Archives/Member/member-bpwg/2007Jul/0047.html

3.16 PAGE_SIZE_LIMIT

Currently, the condition value is too small. It may not appropriate to use in some countries such as Korea.

It is proposed to increase the values, about 50K (this value derived from the statistical results of Korean CPs)

PROPOSED TEXT:
------------------------
If the size of the document's markup exceeds 20 kilobytes, FAIL
For each included resource, as defined in 2.3.6 Included Resources:
Request the referenced resource
Add the size of the response body to a running total (for nested object elements count only the first object that matches the headers specified in 2.3.2 HTTP Request, if there is one)
If the total exceeds 50 kilobytes, FAIL
PASS
------------------------

[1] http://lists.w3.org/Archives/Member/member-bpwg/2007Jul/0047.html

Fourth, section 2.3.4 Meta http-equiv Elements: why are these supported
at all, especially Content-Type and Cache-Control? In section 3.3, a
<meta> element is listed as an option to indicate character encoding,
given that there is an XML declaration and this <meta> only complicates
character set detection, I do not see a reason for allowing this.

Sixth, in 3.10 LINK_TARGET_FORMAT, it states:

> If the |Content-Type| header value of the HTTP response is not
> consistent (determined in the same way as specified in *3.3
> CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE*
> <http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#test_character_encoding_support>)
> with the |Accept-Charset| header in *2.3.2 HTTP Request*
> <http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070525/#http_request>,
> *warn*

This should be a FAIL condition. Character set mismatches are very
undesirable (especially from an i18n perspective) and will create
significant hindrances for most non-English users, whose languages have
accents or even do not use our alphabet at all.

If you want to support ISO-8859-1 in some way to make it easier for
existing sites to server with the mobileOK label, ISO-8859-1 should
simply be processed appropriately and added to the Accept-Charset header.

Seventh, in section 3.18 POP_UPS, target attributes on links with values
"_self", "_parent", or "_top" are accepted. All of these should FAIL,
however, since their presence does not make sense (and is a waste of
bandwidth) considering the requirements put forth in 3.13 NO_FRAMES.

"3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP

...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"

Comment:
This does not allow for valid HTML documents. In HTML end tags for elements
declared EMPTY is forbidden, while XHTML requires end tags for all elements.

COMMENT B.2:
- comment nature: [substantial]
- location: All the tests
- current wording: There is no reference to the applicability condition
or prerequisites (when relevant) in the pseudo-code
- suggested revision: Include this applicability rules in the algorithms
when relevant
- rationale: Some times could be not clear when to produce a N/A output
vs. a Pass/Fail one. This is also a good practice for the shake of
completeness in the algorithm

COMMENT B.10:
- comment nature: [clarification]
- location: 2.3.10 White space
- current wording: "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"
- suggested revision: Should &nbsp; entities (#xA0) be considered?
- rationale: This entity is frequently used (and abused) and having a
look at the related test (3.15, 3.17 and maybe 3.12) it makes even more
sense

COMMENT B.13:
- comment nature: [clarification]
- location: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
and elsewhere where the message body is not involved (3.6, 3.10, 3.16)
- current wording: For each resource specified by 2.3.6 Included Resources:
Request the resource
- suggested revision: Would a HEAD instead of GET request be sufficient?
- rationale:

COMMENT B.23:
- comment nature: [substantial]
- location: 3.18 POP_UPS
- current wording: "If a target attribute is present,..."
- suggested revision: What about JS popups? (window.open)
- rationale: JS popups should be taken into consideration as there are
already other JS related verifications

The tests require XHTML. What is the rationale for this? My research[1]
shows that all tested mobile browsers support HTML, and also that many
treat application/xhtml+xml as if it were text/html (i.e., they don't use
XML parsers). Therefore, for compatibility with existing mobile browsers,
the guideline for authors should be to use HTML, or if they use XHTML to
follow appendix C of XHTML 1.0 (even when using application/xhtml+xml).

On another point, Content-Type of the response for both image and style
sheet requests is simply ignored. The image type is determined through
sniffing and in case of a linked style sheet it is simply parsed as CSS.
This is more or less required for user agents if they want to support web
pages out there.

> 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.

> I do think it's feasible to write once for the desktop and some kind
> of portable device, but such a device is substantially different from
> what people have in their average phone / browser.

Perhaps the Default Delivery Context (DDC) is out of date? It seems to be
based on mobile phones produced in the mid-1990's. They have become
radically more capable in the decade since then. My experience is mainstream
mobiles getting closer to desktop browsers each year (Opera [1] and Webkit
[2] being industry leaders in this regard).

The mobile industry's aims are clear from their actions: make the whole web
available [3][4]. Surely W3C's MWI should be centered on making that happen
faster and more effectively? The current work seems to be on degrading
current content to accomodate a DDC akin to decade-old phones which, AFAIK,
no longer exist.

Vodafone [5], T-Mobile [3] and Three [6] already have a flat rate for web
access in the UK (as Simon Pieters speculated on). So for one thing, the
financial cost of page downloads is being solved by market factors...just
like it did for desktop PCs. :-)

> If "HTML Basic" existed I think there would be a good argument to
> specify it instead.

Since text/html work has started again at W3C in the form of the HTMLWG,
perhaps an "HTML Basic" spec would now be feasible? Then again, the 1998
attempt at this [7] didn't take off, so reduced HTML was not the solution
even with devices *that* limited. And since current mobiles handle full HTML
websites, degrading content at the origin server seems ever more unnecessary
(the network can do this on-the-fly if it needs to be done).

Sincere thanks for taking the feedback from the new HTMLWG seriously. I too
hope HTMLWG will add more practical value to the W3C's Mobile Web Initiative
(MWI) [8].

> 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.

> 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 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.

> 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?

Second, in that same section, I think saying that UAs must send
‘exactly’ this header is not desirable. That would prevent UAs from
handling additional media types, such as image/png or image/svg, and
limit innovation. After all, the UA would not be able to claim a
mobileOK label anymore. The spec should say that UAs must send exactly
this or a superset of this header.

"3.15 OBJECTS_OR_SCRIPT (partial)
...
If an object element is present and has no object element ancestor,

If the innermost nested object element is empty, warn

If the innermost nested object element content consists only of white space,
FAIL..."

Comment:
Rather than "the innermost nested object" it is simpler to state "an
object".

As I understand it, the tests suggest that authors use a separate version
for desktop and for mobiles. I can understand that doing so can be
desireable today for the following reasons:

1. Users have to pay per byte for browsing on the mobile.
2. The connection speed on mobiles is slow.
3. Many mobile browsers have bad support for CSS.

On the longer term, (1) should be addressed by providers offering monthly
fees; (2) should be addressed by improving mobile networks, and (3) by
improving the implementations. (2) and (3) are already happening, and I
wouldn't be surprised if (1) happened soon. When these have been
addressed, there is little reason for authors to provide separate versions
for mobiles and for desktop, as opposed to using one version that works
for both.

The tests warn for things that are not supported on some mobile devices,
such as scripting, even though it is possible to provide fallback content
for UAs without scripting and including scripts doesn't harm UAs that
don't support it. I would suggest not warning for things that don't harm
mobile browsers and could benefit other UAs, in the interest of not
putting unnecessary strain on authors.

> 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).

I'm just catching up on this thread:

The reason the mobileOK doc says nothing about the namespace is that Dom said ages ago (and consistently with his previous message on this thread) that the DTD has the value as FIXED. Consequently, failing if the namespace is absent not right.

The specs all say that the namespace declaration should be present. So I suggest we go back, amend the mobileOK doc, and FAIL if a namespace declaration is not present on the html element.

Jo




> -----Original Message-----
> From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> checker-request@w3.org] On Behalf Of Roland Gülle
> Sent: 25 July 2007 18:52
> To: Dominique Hazael-Massieux
> Cc: Sean Owen; public-mobileok-checker
> Subject: Re: F2F demo: html / xhtml namespace
>
>
>
> > In terms of the checker, I think this means we should default a root
> > element whose name is "html" and has no defined namespace to be in the
> > XHTML namespace (so that we can parse is as if it was XHTML), while
> > throwing an error to the user - I thought there was a specific error
> > triggered in mobileOK for this, but I don't see it in there in a quick
> > read.
> +1 to your proposed solution and found also nothing about XHTML
> namespaces in the mobileOK basic doc.
>
> roland
>
>
>

| 3.1 AUTO_REFRESH (partial) and REDIRECTION

This section does not say what to do if no URL is specified in the
meta content. In fact, the "Mobile Web Best Practices" document itself
seems confused as to how the 'refresh' header works. The header
contains a time-delay in seconds, and an optional URL. The "Mobile"
documents seem to think it just contains a URL.

First, section 2.3.2 HTTP Request states:

> *
>
> 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
>
>

I think this is incorrect, text/css should NOT be included in the Accept
header, and image/jpeg and image/gif ONLY if the UA is expected to
support showing these images independantly of a document (the mobileOK
tests should explicitly check whether this is supported). The client
after all does not know how to handle a text/css file independently of
XML markup.

Instead, it should send an "Accept: text/css" header when the CSS files
that are linked using <link rel="stylesheet">, <?xml-stylesheet?> or
@include. Similarly, images referenced from <img> should send an
"Accept: image/jpeg,image/gif" header. Aside from checking the Accept
header for the main page, the mobileOK tests should also check that
Accept headers send these values for stylesheet and image requests.

Fifth, in 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP it does not
distinguish included resources by type, that is, if it’s a stylesheet
include, only the text/css media type should be accepted (otherwise
FAIL), and if it’s an image include, only image/gif or image/jpeg is
accepted and not text/css. If it’s an object include, unless the UA is
expected to support CSS there by showing it somehow, text/css should
also not be accepted.

"3.11 MEASURES

For each property in the CSS Style (2.3.5 CSS Style) whose value is a
numeric measure of length stated together with a unit:

If the value is non-zero and the unit is not "em" or "ex", and the property
is not a margin, border or padding box property, FAIL

PASS"

Comment:
What about specifying the width and height of images with intristic pixel
size?

"3.12 MINIMIZE

Count number of white space characters in a sequence of more than one white
space character (not counting the first), which exist outside of a pre,
style, script element, or XML comment

Add to this count the number of characters comprising XML comments. This
total is the number of extraneous characters in the document."

Comment:
Why are script and style comments and extra spaces within a script or a
stylesheet are not added to the count?

COMMENT A.2:
- ERT WG COMMENT:
Section "2.3.3 HTTP Response"
"If an HTTP request fails for any reason during a test (network-level
error, DNS resolution error, non-HTTP response, or server returns an
HTTP 4xx or 5xx status), the test outcome should be considered FAIL"
You can (and should) evaluate any content received from the server,
error messages included as they're also content. When the server returns
4xx or 5xx the result of the test should not fail, because otherwise the
website as a hole could never be Mobile OK compliant (e.g. you can
always make a request that will produce an 404 and thus a fail)
- BPWG RESOLUTION:
See http://lists.w3.org/Archives/Member/member-bpwg/2007Feb/0070.html
- ERT WG RESPONSE:
For 300 Multiple Choices [1] a page could be displayed. Apparently this
depends on client capabilities [2]. It's important to clarify how to
handle 300 response codes where the page is displayed.
-[1] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1>
-[2] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12.2>

COMMENT A.3:
- ERT WG COMMENT:
Section "3.10 MEASURES" reads: "If the value is non-zero and the unit is
not "em", "ex" or "%", and the property is not a margin, border or
padding box property (see also 3.20 SCROLLING (partial) ), FAIL"
There are other CSS properties where px values may be allowed as the
background-position or the outline-width.
- BPWG RESOLUTION:
We agree with the basic point but we will address it in the next phase
of the Best Practices document instead.
- ERT WG RESPONSE:
We acknowledge the dependency of this test on the wording of the related
BP. However, we think this is an important issue that needs to be
addressed in this document before it reaches Recommendation status. As
currently defined, this test could produce a fail outcome where it
should be a pass. This could also lead to ambiguity amongst different
checker tools.

COMMENT A.4:
- ERT WG COMMENT:
Section "3.12 MINIMIZE"
The definition of whitespace characters should be clarified, does it
include CR (carriage return) for example?
Additionally, it would make sense to consider also CSS in the minimization.
- BPWG RESOLUTION:
We accept the clarification and point to XML definition for white space:
http://www.w3.org/TR/REC-xml/#sec-common-syn
However, we exclude style regions for the current document but revisit
for the next Best Practices document.
- ERT WG RESPONSE:
While we think that handling extraneous white space in external CSS
would be useful at this stage, we recommend to at least add a clear note
about how it is (not) handled in the current document.

COMMENT A.5: - ERT WG COMMENT: Section "3.15 OBJECTS_OR_SCRIPT" "If the value of the href attribute begins with the "javascript:" scheme, FAIL" At least, href attributes with "#" (or any number of '#') value should also fail as it's a widely used value. A wider definition which discourages any misuse of href values in general would be desirable. - BPWG RESOLUTION: We think that there are valid uses for allowing # as the href, such as a link to the top of the page. - ERT WG RESPONSE: Although being a valid URI, the behaviour of href="#" is not defined. Several user agents have the behaviour describe above, but we think this shouldn't be considered a good practice and the linking to the top of a page should be done using a real (not empty) anchor (fragment ID).

COMMENT B.19:
- comment nature: [clarification]
- location: 3.11 MEASURES
- current wording: "For each property in the CSS Style whose value is a
numeric measure of length stated together with a unit
If the value is non-zero and the unit is not "em" or "ex"..."
- suggested revision: The current wording could give the impression that
numeric measures without units are allowed, which in general is not a
good idea with some exceptions.
- rationale: Although this issue could be already covered by CSS
validation, redundancy could be helpfull for the shake of
completeness in this test as "mobileOK tests are intentionally expressed
in an independent way"

COMMENT B.25:
- comment nature: [substantial]
- location: 3.21 STYLE_SHEETS_USE and 2.3.9 Validity
- current wording: If the CSS Style contains at-rules (other than the
@media at-rule), properties, or values that are not recognized as being
valid CSS Level 1 (2.3.9 Validity), warn
...
CSS
A resource is considered a valid CSS resource if it conforms to the
grammar defined in [CSS], Appendix B
- suggested revision: The definition of CSS validity should include in
some way allowed at-rules, properties and values.
- rationale: Test 3.4 fails for content that is not valid CSS with
validity being defined as conforming to the CSS 1 grammar (syntax).
Test 3.21 seems to use the phrase "valid CSS 1" in a sense that is not
just grammar conformance.
So right now, CSS 2 that conforms to the CSS 1 grammar passes 3.4, but
you'll get a lot of warnings, because the grammar does not define
properties and values (3.21)
Additionally,
@import "foo.css" handheld;
would fail 3.4 because of the media type, which is not part of the CSS 1
grammar, while the rule should be considered when collecting the
"Included Resources" (2.3.6).

3.14 NON-TEXT_ALTERNATIVES (partial) says:

For each img element:

If an alt attribute is not present or consists only of white space,
FAIL

PASS

Does this imply that the empty string is also a FAIL? If so, I think this
test should be removed; there are a number of cases where the empty string
is the appropriate alt text (e.g., when an image is illustrative or merely
repeating the previous paragraph). [2]

> 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.

> and hence this test
> fails if a resource cannot be encoded in UTF-8.

s/cannot be/is not/

> 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.

| 2.3.8 Visible Linked Resources
| ...
| Note that forms with method get are permissible in documents under
| test, but must not be checked in case posting caused unwanted side
| effects such as the addition of unwanted records to a database.

I think that's probably meant to say 'forms with method *post*'.
Either way, it doesn't make sense in context as-is.

| 3,2 CACHING
| ...
| If no meta http-equiv element is present, referring to those
| headers, FAIL
| warn, and continue the test using the value from the meta content
| attribute.

The last line above is missing something, probably an "Else," at the
beginning.

I am not sure that the fact that this section is mandating warnings
whenever content is specified as uncacheable is a good idea. Even if
it is, it should be made explicitly clear that that is the intent
- especially for example on the "Pragma" header, where people might
think that it is the Pragma header itself which is being warned about.

| 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
| ...
| HTTP Content-Type headre
| application/xhtml+xml; charset=UTF-8"

Extraneous " at the end of the line.

On Fri, Jun 22, 2007 at 02:52:41PM +0200, Johannes Koch wrote:
> apart from the GET vs. POST typo issue, Jon mentioned:
>
> >Well, theoretically since GET is idempotent you can safely try, for
> >example, simply submitting the form with its default values.
>
> I may have missed it, but does the mobileOK draft describe how to handle
> GET forms? Only use default values?

It's very vague. 'Use default values' is my own opinion (and is what
we do in the web-checking tool our company provides). Section 2.3.8
might possibly be intended to mean that the URL in the 'action'
attribute should be taken and fetched unchanged with no form parameters
at all, but that would be highly inadvisable (there is essentially no
other circumstance, other than a mobileOK test, where that URL would
be requested).

I feel that clarification of this is quite important.

I have CC'ed this message to public-bpwg-comments, as today is
apparently the last day for comments.

Third, in that same section, there is a requirement that only HTTP GET
methods can only be used. What about form submissions with POST? Forcing
forms to be sent with the GET method seems undesirable and impairs the
HTTP functionality. It seems a silly limitation too, because if a
mobileOK Basic application must support HTTP and HTTPS, and Basic and
Digest HTTP authentication, then surely support for POST would be
trivial. The mobileOK tests should provide tests for checking proper
cache clearing after a POST request has been done on a URL.

COMMENT A.1: - ERT WG COMMENT: Section "2.2 Testing outcomes" The MWBP group have know made clear that warnings are _no_ test outcomes but it was also said that the group do not want to specify _which_ warning may be generated. In order for the tool developer to create a reasonable warning, it would help him to know at least the specific purpose why a warning has to be generated. - BPWG RESOLUTION: The checker will provide a reference implementation of what the warning/error text should be for each warning or error, also linking back to appropriate reference material. - ERT WG RESPONSE: It's not clear what you mean with "linking back to appropriate reference material". What will the appropriate reference material be? Is the intention just to link back to the mOK or BP documents as-is? We think the point here is not to provide the text of a warning, but to ensure that it is clear what the potential problem associated with a warning is.

COMMENT B.1:
- comment nature: [substantial]
- location: All the tests
- current wording: It looks like PASSES and FAILS are defined as "final
states" that interrupt the algorithm (otherwise all the algorithms will
always produce a PASS, as it's always the last instruction)
- suggested revision: Tests algorithms should be describe in a way that
provide messages for every fail or warning
- rationale: If they not do so, then the algorithm would be useless for
tracking reasons, you can use them to know if something PASS or FAIL,
but not to know the details.

COMMENT B.3:
- comment nature: [clarification]
- location: 2.3.2 HTTP Request
- current wording: Use the HTTP GET method when making requests.
- suggested revision: Clarify how to proceed while testing GET requests.
E.g. use only default values
- rationale: It's quite clear now (see related #7 comment) what are the
reasons to leave POST requests out, nevertheless there's no clear
indication on how to proceed while testing GET requests.

COMMENT B.4:
- comment nature: [clarification]
- location: 2.3.2 HTTP Request
- current wording: Use Implementations must support URIs with both http
and https scheme components.
- suggested revision: Clarify how to proceed with different URI schemes.
- rationale: It's not clear what should be done when you find a
different URI scheme. Ignore it?

#5 COMMENT
- comment nature: [clarification]
- location: 2.3.3 HTTP Response
- current wording: If the HTTP status indicates redirection (status code
3xx):
Do not carry out tests on the response
- suggested revision: It's not clear what to do with invalid location
header values (URIs that are not absolute.
absoluteURI = scheme ":" ( hier_part | opaque_part )
- rationale: Quite a lot of servers create
Location: /foo.bar
instead of
Location: http://www.example.org/foo.bar

COMMENT B.5:
- comment nature: [editorial]
- location: 2.3.5 CSS Style
- current wording: resources linked by xml-stylesheet processing
instructions
- suggested revision: resources linked by xml-stylesheet processing
instructions, as defined in 2.3.7 Included Style Sheet Resources"
- rationale: It make sense to reference the normative definition

COMMENT B.6:
- comment nature: [clarification]
- location: 2.3.5, 2.3.6, 2.3.7
- current wording: At 2.3.5 is said that the CSS style must be assemble
using @import rules among others, and at 2.3.6 this rules are also
included in the definition of included resources, but at 2.3.7 there in
no mention to @import while defining included style sheets that are
taken into account when calculating the page size.
- suggested revision: Include @import rules into the page size calculation
- rationale: If CSS provided by @import rules is going to be analysed
then it should also be taken into account while calculating the page size.

COMMENT B.7:
- comment nature: [typo]
- location: 2.3.8
- current wording: Note that forms with method _get_ are permissible in
documents under test, but must not be checked in case posting caused
unwanted side effects such as the addition of unwanted records to a
database.
- suggested revision: Note that forms with method _POST_ are permissible
in documents under test, but must not be checked in case posting caused
unwanted side effects such as the addition of unwanted records to a
database.
*rationale: We think it's a typo as currently POST is the method that
it's not been checked

COMMENT B.8:
- comment nature: [editorial]
- location: 2.3.8
- current wording: Note that forms with method POST are permissible in
documents under test, but must not be checked in case posting caused
unwanted side effects such as the addition of unwanted records to a
database.
- suggested revision: Add a similar note before 2.3.2 HTTP Request
*rationale: We think this clarification should also be done before as
it's also quite relevant to correctly understand why at 2.3.2 the use of
GET method is required.

COMMENT B.9:
- comment nature: [clarification]
- location: 2.3.9 Validity
- current wording: "CSS > A resource is considered a valid CSS resource
if it conforms to the grammar defined in [CSS], Appendix B."
- suggested revision: Include all the properties that are allowed in the
definition of Valid CSS
- rationale: It's not clear what CSS properties are allowed as, apart
from those in the CSS1 Recommendation, there are mentions at least to
@media (3.21) and position (3.20).

COMMENT B.11:
- comment nature: [clarification]
- location: 3.2 CACHING
- current wording: 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. Where both a meta element
and the corresponding header are found the value of the header must be used.
- suggested revision: Clarify what to do in the absence of HTTP headers,
should meta elements be used?
- rationale:

COMMENT B.12:
- comment nature: [typo]
- location: 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
- current wording: application/xhtml+xml; charset=UTF-8"
- suggested revision: Remove '"'
- rationale:

COMMENT B.14:
- comment nature: [clarification]
- location: 3.4 CONTENT_FORMAT_SUPPORT and VALID_MARKUP
- current wording: If the document is an HTML document
- suggested revision: What is "an HTML document" here? Which
characteristics are to be checked?
- rationale: Is not clear if there's any algorithm to check whether
something is an HTML document or not as it's not clear what you should
look for in absence of an HTML document definition.

COMMENT B.15:
- comment nature: [editorial]
- location: 3.6 EXTERNAL_RESOURCES
- current wording: "Note that if an HTTP request is unsuccessful while
conducting this test, the result is FAIL"
- suggested revision: Include this condition in the general algorithm
- rationale: It's the only condition that affects to the result and it's
out of the general algorithm, this way it could be easily leave out

COMMENT B.16:
- comment nature: [clarification]
- location: 3.6 EXTERNAL_RESOURCES
- current wording: "Note that if an HTTP request is unsuccessful while
conducting this test"
- suggested revision: Clarify what means unsuccessful here
- rationale:

COMMENT B.17:
- comment nature: [typo]
- location: 3.6 EXTERNAL_RESOURCES
- current wording: Count the total number of unique included resources,
as defined in 2.3.6 Included Resources
- suggested revision: Add '.'
- rationale:

COMMENT B.18:
- comment nature: [clarification]
- location: 3.11 MEASURES
- current wording: "For each property in the CSS Style whose value is a
numeric measure of length stated together with a unit
If the value is non-zero and the unit is not "em" or "ex"..."
- suggested revision: Why has been % left out? is it not considered an unit?
- rationale: As currently expressed it's not clear what to do with
percentages

COMMENT B.20:
- comment nature: [editorial]
- location: 3.12 MINIMIZE 3.15 OBJECTS_OR_SCRIPT 3.17 PAGE_TITLE
- current wording: "white space"
- suggested revision: Link to the "normative" definition of white space
at 2.3.10 White Space
- rationale: Once you have a "normative" definition it make sense to
link to it as it's been done with "Validity"

COMMENT B.21:
- comment nature: [typo]
- location: 3.13 NO_FRAMES
- current wording: "If the document contains a frame, frameset or iframe
element or object element..."
- suggested revision: "If the document contains a frame, frameset or
iframe element or _an_ object element..."
- rationale: Apparently there is a missing "an"

COMMENT B.22:
- comment nature: [clarification]
- location: 3.16 PAGE_SIZE_LIMIT
- current wording: If the size of the document's markup exceeds 10 kilobytes
- suggested revision: Does "size of the document's markup" mean "the
markup document's length"?
- rationale: Although this is the most sensible, it could also mean
"count only tags" or other things

COMMENT B.24:
- comment nature: [editorial]
- location: 3.19 PROVIDE_DEFAULTS
- current wording: "If there is no nested option element whose selected
attribute is set to some value, warn"
- suggested revision: "If there is no nested option element whose
selected attribute is set to _"selected"_, warn"
- rationale: This is the only valid value for this attribute and it's
been already included in the next condition of the algorithm

COMMENT B.26:
- comment nature: [editorial]
- location: 3.21 STYLE_SHEETS_USE
- current wording: If the CSS Style contains at-rules (other than the
@media at-rule), properties, or values that are not recognized as being
valid CSS Level 1 2.3.9 Validity, warn
- suggested revision: Add () around the link "2.3.9 Validity".
- rationale: