W3C

Disposition of Comments for mobileOK Basic Tests 1.0
2007-10 Transition to CR

This is a combined record of the Disposition of Comments for all three Last Call rounds of the W3C mobileOK Basic Tests 1.0 specification. The tables below record details for each comment, including the resolution for each comment, as well as the status of that resolution with respect to the original commenter.

In total, the BPWG received and responded to 184 comments on the mobileOK Basic Tests 1.0 document: 82 comments for Last Call round 1, 82 comments Last Call round 2, and 20 comments for Last Call round 3. The BPWG believes that they as a group have responded to all comments in good faith and resolved them satisfactorily.

Key to color indicators

In the Resolution from BPWG column, red indicates that the Best Practices Working Group didn't agree with the comment, green indicates the working group agreed with the comment, and yellow indicates partial agreement.

In the Status column, green indicates that the BPWG sent a reply to the commenter with the resolution indicated, and -- possibly after further discussion and refinement to arrive at a satisfactory final resolution -- the commenter did not object to the final resolution.

Note that two other states in the Status column are possible: red to indicate that after discussion of the resolution from the BPWG, the commenter objected to the final resolution, and yellow to indicate that either that the commenter did not respond to the request for feedback or that it was not possible for the BPWG to determine whether the resolution would be satisfactory to the commenter.

Last Call round 3

Comment IDCommentResolution from BPWGStatus
LC-1855 Bryan Sullivan
"The tests do not assess usability, rather, they assess whether the content can be provided in a way that is likely to achieve a basic level of interoperability with mobile devices":
[bryan] The tests seem to contradict this statement. There are aspects of usability and efficiency as well as interoperability that seem to be the focus of some of the MWBP recommendations, and in the MOT, the tests. For example:
3.1 AUTO_REFRESH and REDIRECTION (efficiency)
3.2 CACHING (efficiency)
3.5 DEFAULT_INPUT_MODE (usability)
3.6 EXTERNAL_RESOURCES (efficiency)
3.7 GRAPHICS_FOR_SPACING (efficiency, unless variations in spacing as rendered are meant as an interoperability problem)
3.12 MINIMIZE (efficiency)
3.14 NON-TEXT_ALTERNATIVES (usability)
3.16 PAGE_SIZE_LIMIT (efficiency, related to to the sum of all responses from an initial request)
3.17 PAGE_TITLE (usability)
3.19 PROVIDE_DEFAULTS (usability)
No We take your point but we don't think any ambiguity is introduced by this.OK
LC-1857 Bryan Sullivan
"If the HTTP status indicates redirection... If the response relates to a request for the resource under test... Include the size of the response in the total described under 3.16 PAGE_SIZE_LIMIT":
[bryan] The size of response headers and content in 3xx responses should not count toward the page size total. Page size limitations in the DDC should relate to only the ultimate page returned in response to the original request (e.g. 2xx response page) and all its embedded or referenced objects that have to be retrieved (e.g. style sheets). The size of content or headers in 3xx responses is irrelevant, unless there is some transient response handling limitation (these are most commonly related to the size of the Location header URI, or excessive cookies set in the 3xx response). This comment also applies to the section for status code 401 ("Include the size of the response in the total...") and ("Include this response under the count...).
We are keen to minimize rounds trips and reduce the overall data transfer burden which is why it is like it is. Commenter disagreed, but didn't object
LC-1859 Laurens Holst
Jo Rabin schreef:
>
> Laurens
>
>
>
> Thanks for your further reply on this. Ref RFC2616
>
>
>
> Accept headers *can* be used to specify certain media
>
> types which are acceptable for the response. …
>
>
>
> Not “should” or “must”.
>

I think you’re misinterpreting that sentence, it “can” be used because
the Accept header is optional. It does not imply the Accept header can
be used differently than described, and that you can just put any kind
of nonsense in there and still expect it to work.

> And if the server needs to respond with a 3xx, 4xx or 5xx response
> code, in principle it would not know how to do that if the request did
> not contain a range of content types.
>

I don’t understand how that would be. Different content types are just
different representations of data. A single resource can be represented
by several content types. If you’re going to indicate to the server that
you accept certain representations, then the server can send any of
them. However regardless of the content type, the server knows perfectly
well when a response of 3xx, 4xx or 5xx is needed for that resource
(e.g. when it has moved or is unavailable). They’re two separate things,
and unrelated.

I do not understand the resistance against just sending the correct
Accept headers. That is how the protocol is designed, and it’s also how
browsers implement it.

Also, you’re completely glossing over my statement that sending
incorrect Accept headers *breaks* servers which correctly handle content
negotiation, because the accepted content types are not correctly
indicated by the test. Thus, with this test the W3C would force web
sites to not use content negotiation if they want to get your label for
‘correctness’.
Behavior as specified does not
contravene HTTP. In practice, it is consistent with most mobile UAs
behavior and is desirable on practical grounds for a tester to emulate.
It should not be inferred from the way the checker behaves that real
browsers either should or should not behave that way.
Commenter initially disagreed, but didn't respond to final response, and didn't object
LC-1902 Johannes Koch
* "If the HTTP response contains neither an Expires nor Cache-Control
header"
Is "nor Pragma" missing here?
Pragma is an HTTP 1.0 artifact, and for our purposes here we don't want to consider this alone to be a sufficient communication of cacheability, so yes we want to leave out Pragma. OK
LC-1903 Johannes Koch
* "In the following, an "html document" is a document that has "html" as
its root element."
Are there any restrictions on the html element's namespace URI
(http://www.w3.org/1999/xhtml)?
No there are no restrictions -- the test is intended to proceed to test any document that appears to be an HTML variant, and here that means any document starting with <html> regardless of namespace. OK
LC-1905 Johannes Koch
* "FAILures that occur in the course of making this assessment
contribute to the result of this test."
Does this mean that a failure from the algorithm specified in 2.4.3
(http_response-x) creates another failure for 3.6 (EXTERNAL_RESOURCES-1)?
Yes, it causes this test to fail -- this was the intent of this sentence, right. OK
LC-1854 Bryan Sullivan
This should explain what "PASS" "WARN" "FAIL" imply and how these relate to the MWBP, e.g. (a) "PASS" means the content is fully compatible with the MWBP for the DDC; (b) "WARN" means the content MAY result in problems in the DDC; (c) "FAIL" means the content does not comply with the MWBP for the DDC.
Yes, we think a note of clarification is warranted e.g. that it can't be determined, that it may be because it is dubious practice that in some circumstances can't be avoided. OK
LC-1856 Bryan Sullivan
[bryan] This seems to be a client behavior criteria. Since the focus of the tests is whether the *content* is interoperable, this client behavior seems to be out of scope. If this is meant as design criteria for a test client only (a client specifically designed to support this testing), then this should be clarified in "2.4 Conduct of Tests" (e.g. some description of the following "test conduct" statements as relating to the client/server test environment, and that HTTP-related aspects of the statements are not meant as criteria for DDC-compliant clients generally).
I think you understand it right, that it is a requirement for the *tester* client, yes. This doc is specifying what a tester has to do, and the tests are specifying what the mobileOK content / server has to do. I think a note of clarification can't hurt, since a number of people have mistaken all of this as a requirement on mobile browsers (e.g. as if they say, mobile browsers should never accept > 20K of content or something) OK
LC-1858 Bryan Sullivan
[bryan] To be consistent with the other "test environment failure" (e.g. "certificate is invalid") cases, this should result in a FAIL. For example, in this case, one would not expect a valid URI request to result in 4xx/5xx in a working test environment.
The behavior is deliberate in order to allow for the testing of error pages. We will add a note clarifying this. OK
LC-1896 Johannes Koch
in Note: "have the have either the" -> "have either the"
Will fix this, thanks. OK
LC-1897 Johannes Koch
* The algorithm does specify whether tests have to be carried out on
responses with 3xx, 401, 404, 407 and 5xx status codes. Is does _not_
specify whether tests have to be carried out on responses with 1xx, 2xx
and 4xx (other than 401, 404 and 407).

It does specifiy whether the resource size/count totals have to be
updated for 3xx, 401, 407 status codes. Is does _not_ specify whether
the resource size/count totals have to be updated for 1xx, 2xx, 4xx
(other than 401 and 407) and 5xx status codes.
Yes, we will clarify that tests should proceed on 1xx (weird as that is) or 2xx responses. The last lines of this section indicate that most 4xx and 5xx responses will FAIL. OK
LC-1898 Johannes Koch
* Are values "all" and "handheld" meant case-insensitively?

* Are "stylesheet" and "alternate" meant case-insensitively?

* Is "UTF-8" meant case-insensitively?
In both cases the relevant specification says case insensitive, so "yes" OK
LC-1899 Johannes Koch
* While section 2.4.7 lists element/attribute combinations (e.g. href
attribute of a element), section 2.4.6 does not provide attributes for
the elements:
* img elements (src attribute?)
* object elements (data attribute? some special param, e.g. value
attribute of param element with name="src"?
* link elements and xml-stylesheet processing instructions (href
(pseudo-) attribute?)

* Are values "all" and "handheld" meant case-insensitively?
Yes, I will add the attribute names as appropriate. Case-insensitive is correct. OK
LC-1900 Johannes Koch
* "GET" -> "get"
Or is it meant case-insensitively?
The method is not case-sensitive, yes. I will clarify. OK
LC-1901 Johannes Koch
* " CSS

A resource is considered a valid CSS resource if it conforms to the
grammar defined in [CSS], Appendix B (see note below).

Note:

The presence of at-rules, properties or values or combinations of
properties and values that are not specified in [CSS] does not
constitute a validity failure for CSS. See 3.21 STYLE_SHEETS_USE for
treatment of such values. In addition, the @media at-rule and the
presentation media qualifiers for the @import at-rule are taken into
account when evaluating CSS."

This is a contradiction: The CSS1 grammar does not allow at-rules other
than @import. How about the following wording (if that's what you mean)?

"A resource is considered a valid CSS resource if it conforms to the
grammar defined in [CSS], Appendix B, apart from possible uses of @media
at-rules with optional presentation media qualifiers."
Yes we will make a small clarification here. OK
LC-1904 Johannes Koch
* "For each input element with attribute type whose value is "text" or
"password""
Does a missing type attribute in the markup assume the default value
"text" as per the document type definition?
Yes, probably a corner case but a good point. OK
LC-1906 Johannes Koch
* "If the Content-Type header value of the HTTP response is not
consistent with the Accept-Charset header in 2.4.2 HTTP Request, warn"
What to do here if there is no charset parameter in the Content-Type header?
Yes, a missing charset parameter would be considered inconsistent too. We will clarify. OK
LC-1907 Johannes Koch
* "If the innermost nested object element content consists only of white
space (see 2.4.9 White Space), FAIL"
"consists" -> "contains"?
OK. OK
LC-1908 Johannes Koch
* "If the CSS Style contains a property with a value that is
inappropriate to it, warn

If the CSS Style contains a property with a value that requires a unit
or a percentage:

If the unit (or percentage) is not present, warn

If the unit (or percentage) is inappropriate to the value, warn"

Does this only apply to properties specified in CSS1? Do newer
properties have to be ignored here?
The intention was that the test can only reasonably be expected to know whether a property requires a unit if the property is known to the test, and so far we have limited the test to CSS 1. OK
LC-1909 Johannes Koch
* "If a table element exists," -> "For each table element"?
Otherwise there would be at most one message for
"TABLES_ALTERNATIVES-1", "TABLES_LAYOUT-1", "TABLES_LAYOUT-2",
"TABLES_LAYOUT-3" and "TABLES_NESTED-1" per checked URI.
We'll change 3.23 and 3.24. I think the current wording is OK for 3.22 since that test check for existence of tables, period. OK

Last Call round 2

Comment IDCommentResolution from BPWGStatus
LC-1723 Anne van Kesteren
> 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.
We don't agree that the HTTP RFC requires this interpretation. We believe that if a user agent includes an accept header that specifies text/css in a request, that is an indication not that text/css is an acceptable response for an image but that it can process text/css in some circumstances. In general the User Agent does not know what type of resource to anticipate when it makes a request. It is a special case when it does, as a result in this case of making a retrieval linked to a specific element in a resource already retrieved. Commenter didn't agree, but didn't object either, nor responded to final response from the WG
LC-1700 Henri Sivonen
> * 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.
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.
Commenter didn't respond
LC-1701 Henri Sivonen
> * 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.
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.
Commenter didn't respond
LC-1702 Henri Sivonen
> 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.
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. Commenter didn't respond
LC-1705 Henri Sivonen
> If any cache related header contains an invalid value, warn

Why not fail?
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. Commenter didn't respond
LC-1708 Henri Sivonen
> If the HTTP Content-Type header specifies an Internet media type
> starting with "text/":

This should apply to text/html.
The text is appropriate as it stands as "starting with text/" includes text/html. Commenter didn't respond
LC-1709 Henri Sivonen
> 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.
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. Commenter didn't respond
LC-1714 Henri Sivonen
> 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.
The test is based on the Best Practices. We warn (not fail) in the absence of an inputmode attribute. Commenter didn't respond
LC-1715 Henri Sivonen
> 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.
The test specifically allows empty ALT tags which is the accepted way of indicating that there is no appropriate ALT text. Commenter didn't respond
LC-1717 Henri Sivonen
> 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.
These tags are not defined in XHTML Basic or MP and therefore not supported by the DDC or mobile phones in the marketplace. Commenter didn't respond
LC-1718 Henri Sivonen
> 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.
We encourage people to use CSS and hence a warn is justified. Commenter didn't respond
LC-1781 Jonathan Jeon
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.

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

mobileOK Basic does not require use of UTF-8 in all cases; the test only verifies that you *can* use UTF-8 when requested. At this point we are not in a position to revise the DDC description in Mobile Web Best Pratices, and mobileOK Basic is intended to reflect what is in MWBP. It is useful to encourage all sites to support globally-interoperable encodings like UTF-8, even if they also support a more appropriate local encoding. OK
LC-1782 Jonathan Jeon
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) mobileOK Basic is supposed to be based on Best Practices doc and so we must reflect its values, 2) nothing precludes delivering a 'fancy' experience; mobileOK only asks you be able to create a 'non-fancy' experience, 3) based on Google mobile web data the current numbers are reasonable; we don't yet have data in support of higher limits OK
LC-1783 Jonathan Jeon
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]
1) mobileOK Basic is supposed to be based on Best Practices doc and so we must reflect its values, 2) nothing precludes delivering a 'fancy' experience; mobileOK only asks you be able to create a 'non-fancy' experience, 3) based on Google mobile web data the current numbers are reasonable; we don't yet have data in support of higher limits OK
LC-1693 Laurens Holst
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.
We allow users to specifiy for the requested document which encoding should be used to nonetheless attempt conformance to mobileOK. In the specific cases that are noted - character set, caching the detail of the test itself makes sure that this is the least preferred option and that a warn in issued if it is the only means by which the authors intentions are indicated. Commenter didn't respond
LC-1695 Laurens Holst
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*
> )
> with the |Accept-Charset| header in *2.3.2 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.
This test covers external resources, which are
possibly outside the author's control. Some members of the group felt strongly that one shouldn't FAIL on account of an external
resource. Whether the resource displays usefully is a difficult question for a machine test to answer, and it may be that checking this aspect becomes a mobileOK Pro test.
Commenter didn't respond
LC-1696 Laurens Holst
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.
There are a couple of use cases which are admittedly marginal where this makes sense. It does not seem acceptable to exclude those use cases, no matter how marginal, since they are valid and out of scope for a test on pop-ups. Commenter didn't respond
LC-1732 Nir Dagan
"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.
We do not allow HTML documents, only those that validate as XHTML Basic 1.1 (or XHTML MP). Commenter didn't respond
LC-1742 Shadi Abou-Zahra
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
There is no N/A outcome from mobileOK. Commenter didn't respond
LC-1751 Shadi Abou-Zahra on behalf of ERT Working Group
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 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
No change is required as nbsp is used by authors to indicate non-redundant white space, that it has semantic content. Detecting whether its abused or nonsensical gets difficult and is beyond the scope of the current test. Commenter didn't respond
LC-1754 Shadi Abou-Zahra
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:
No, the resource must be requested in order to determine its size, to assess their validity and for images their dimensions. Commenter didn't respond
LC-1764 Shadi Abou-Zahra
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
We decided not to try to parse the Javascipt - recognising that this would mean that possible window.open statements were present, on the basis that the DDC does not support script. and the presence of script triggers a warn under objects or script Commenter didn't respond
LC-1721 Simon Pieters
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).
Most mobile browsers do not support everything HTML defines. Our experience is that XHTML Basic delivered with application/xhtml+xml is more likely to result in a functional user experience than other combinations. Commenter didn't respond
LC-1724 Anne van Kesteren
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.
We accept that real browsers have to adopt many heuristics and take a pragmatic approach. The intention of mobileOK Basic is to point out to content providers that mislabeling the content is an error. We certainly do not endorse the mislabeling. Commenter didn't respond
LC-1719 Ben Cerbera Millard
> 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.
Our understanding and experience is that XHTML Basic delivered with the content type application/xhtml+xml succeeds in the largest number of cases. Our objective is not to specify improvements to mobile devices, though we hope that happens, it is to help content providers achieve a functional user expeirences on the widest range of mobile devices. We encourage content providers to work towards a harmonised experience on devices that have more advanced capabilties. Commenter didn't respond
LC-1725 Ben Cerbera Millard
> 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. :-)
The DDC is defined as the minimum specification for a device which can provide a usable user experience of the Web. As such it has enduring value irrespective of considerations of availability of increasing capabilities of devices in some markets. Our understanding is that such devices represent the only means of access to the Web in some areas of the world. It it arguable that even in markets in which more capable devices are common, people will choose not to carry such devices all the time and may wish to use alternative lighter weight solutions more appropriate to the context (sport, leisure etc.) Commenter didn't respond
LC-1726 Ben Cerbera Millard
> 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].
Proposed Resolution: We perceive a need for use of Basic today - note that cHTML is an example of successful mobile markup. It's possible that this need will disappear in the future. If it does, then the need for that specification will diminish. Commenter didn't respond
LC-1697 Henri Sivonen
> 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.
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. Commenter didn't respond
LC-1698 Henri Sivonen
> 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.
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.
Commenter didn't respond
LC-1699 Henri Sivonen
> 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.
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. Commenter didn't respond
LC-1707 Henri Sivonen
> 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?
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. Commenter didn't respond
LC-1710 Henri Sivonen
> 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?
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.
Commenter didn't respond
LC-1711 Henri Sivonen
> 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.
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. Commenter didn't respond
LC-1713 Henri Sivonen
> 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?
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. Commenter didn't respond
LC-1691 Laurens Holst
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.
The basis on which the spec is written is that a checker emulates a hypothetical device - the DDC - which has exactly the capabilities specified. The tests ensure that a Web site is capable of responding to the needs of such a device. We encourage content providers to support more than the needs of the basic device and take advantage of greater functions and capabilities where they can. Commenter didn't respond
LC-1735 Nir Dagan
"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".
The term innermost nested was chosen deliberately. Commenter didn't respond
LC-1720 Simon Pieters
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.
We don't doubt that implementations and feature sets are improving, costs coming down and so on. However, that has far from universally happened, and even if it did, we believe that the context of the mobile user will often make it desirable to present an interface that is sympathetic to that context. In particular it is possible to pass mobileOK Basic while using <script>; it merely generates a warn. More generally, we're not saying you can't use <script>, just that you need to be able to deliver an experience to baseline devices that works without script. You may do whatever you like to other devices. Commenter didn't respond
LC-1716 Henri Sivonen
> 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).
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.
Commenter didn't respond
LC-1786 Jo Rabin
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
>
>
>
Amend CONTENT_FORMAT_SUPPORT and VALID_MARKUP to FAIL if the xhtml namespace is not present on the html element. OK
LC-1728 Jon Ribbens
| 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.
'URI specified in the content attribute' should not be read to imply it is the sole content of the attribute. We will clarify along the lines of 'If the URI specified as part of the content attribute is not the current resource's URI...' OK
LC-1690 Laurens Holst
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.
We do not think it is wrong to specify the headers in the way we do, however we accept that we do not properly check that the right sort of content has come back in response to the request. In other words, if the request is made because of an img tag then the response should be an image. We did not test for that in the draft you reviewed and we will amend accordingly. In particular, in 3.4, <img> tags that retrieve valid CSS delivered as text/css should for example FAIL too. Commenter didn't respond
LC-1694 Laurens Holst
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.
We will add that if the resource is expected to be a stylesheet, it must be text/css (and be valid CSS), and likewise for images and FAIL if it is not - also that Objects need to be images in this case. Commenter didn't respond
LC-1733 Nir Dagan
"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?
We specify that the size of images is specified in the HTML markup and not in CSS to allow the browser the chance to render only once. If the image size is specified in CSS that does not achieve the same effect. Add a note under this test commenting on this issue. Commenter didn't respond
LC-1734 Nir Dagan
"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?
Per LC-1739 we don't think that we should look at CSS white space in this iteration of the document anhd will add a note clarifying that it is not handled. Commenter didn't respond
LC-1737 Shadi Abou-Zahra
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
- ERT WG RESPONSE:
For 300 Multiple Choices a page could be displayed. Apparently this
depends on client capabilities. It's important to clarify how to
handle 300 response codes where the page is displayed.
We will add a note clarifying that when a 3xx response is received the value of the Location header should be used to redirect. If no Location header is present, FAIL. Commenter didn't respond
LC-1738 Shadi Abou-Zahra
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.
RESOLUTION: Modify measures to state that px measures are tested only CSS level 1 properties.

CSS Properties that take a <length> are: font-size, background-position, word-spacing, letter-spacing, text-indent, line-height, width and height (as well as margin, borders and padding). The BPWG did not consider that these other properties justified an exclusion from this test.
Commenter didn't respond
LC-1739 Shadi Abou-Zahra
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.
RESOLUTION: The clarification of meaning of white space has been handled under LC-1703 and we don't think that we should look at CSS white space in this iteration of the document anhd will add a note clarifying that it is not handled Commenter didn't respond
LC-1740 Shadi Abou-Zahra
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).
RESOLUTION: Under LINK_TARGET_FORMAT check for invalid document internal references and # and warn if present / invalid Commenter didn't respond
LC-1760 Shadi Abou-Zahra
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"
Add to STYLE_SHEET_USE:
If the CSS Style contains a property with a value that is inappropriate to it, FAIL
If the CSS Style contains a property with a value that requires a unit or a percentage:
If the unit (or percentage) is not present, FAIL
If the unit (or percentage) is inappropriate to the value, FAIL
Commenter didn't respond
LC-1766 Shadi Abou-Zahra
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).
It's intended that the warnings be generated for non-level 1 . We take your point on @import and will add text to 2.3.6 and to 3.21 and will change the wording in 3.21 to avoid the use of "valid" and will also adjust CSS Validity to take account of the media type on import. Commenter didn't respond
LC-1722 Simon Pieters
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]
No, an empty ALT tag does not cause a fail for the reasons you cite. We will add a clarifying note. Commenter didn't respond
LC-1703 Henri Sivonen
> 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.
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)
Commenter didn't respond
LC-1704 Henri Sivonen
> 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.
Reworded to work around this. Commenter didn't respond
LC-1706 Henri Sivonen
> and hence this test
> fails if a resource cannot be encoded in UTF-8.

s/cannot be/is not/
Change "cannot be" to "is not". Commenter didn't respond
LC-1712 Henri Sivonen
> 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.
A note has been added to clarify what this means under 3.4. Commenter didn't respond
LC-1727 Jon Ribbens
| 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.
That is a typo, thanks for pointing it out. Commenter didn't respond
LC-1729 Jon Ribbens
| 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.
Reworded to work around this. Commenter didn't respond
LC-1730 Jon Ribbens
| 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.
That is a typo, thanks for pointing it out. Commenter didn't respond
LC-1731 Jon Ribbens
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.
We will change 2.3.8 to state more clearly how to submit forms - use empty values where no default is supplied. Commenter didn't respond
LC-1692 Laurens Holst
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.
We will insert a reference in 2.3.2 referring to 2.3.8 to make it clearer that POST is definitely allowed as a form action in mobileOK content but that it is simply not tested, for fear of the tester causing unwanted side effects. Commenter didn't respond
LC-1736 Shadi Abou-Zahra on behalf of ERT
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.
We intend to identify each FAIL and warn with a specific identifier and the messages produced by the checker will refer to these references in mobileOK - the relevant section in mobileOK refers to the section in the BP document from which it derives. Commenter didn't respond
LC-1741 Shadi Abou-Zahra
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.
We agree that the wording of 2.3.1 could be improved to clarify that PASS means stop. FAIL means FAIL the whole test but try to continue in order to generate as much info as possible. If a FAIL has been encountered, encountering a subsequent PASS does not reverse that state.

In addition, we have provided a unique ID for each warn and FAIL as noted in response to another of your comments.
Commenter didn't respond
LC-1743 Shadi Abou-Zahra
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.
We agree that submission of forms needs clarification, and will adjust the text of 2.3.8 visible linked resources to reflect this. Commenter didn't respond
LC-1744 Shadi Abou-Zahra
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?
Add text - URIs specified with other schemes MUST be ignored. Commenter didn't respond
LC-1745 Shadi Abou-Zahra
#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
Add the text "if the URI identified by the Location header is not an absolute URI, warn, and create an absolute URI by combining the Location header value with the absolute URI of the request. Commenter didn't respond
LC-1746 Shadi Abou-Zahra
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
Add clarification along the lines suggested. Commenter didn't respond
LC-1747 Shadi Abou-Zahra
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.
Add clarification along the lines suggested in fact 2.3.7 is done away with as a separate section. Commenter didn't respond
LC-1748 Shadi Abou-Zahra
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
Change GET to POST in this section as indicated Commenter didn't respond
LC-1749 Shadi Abou-Zahra
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.
Add a note under 2.3.3 - at the point where GET is specified - saying See also 2.3.8 on submission of forms. Commenter didn't respond
LC-1750 Shadi Abou-Zahra
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).
Add test to 2.3.9 stating that the @media rule is also allowed. Also add a note saying that properties that are not defined in CSS Level 1 do not cause a validity failure. Change text in 3.21 STYLE_SHEET_USE to remove the reference to Validity and 'valid CSS Level 1' and replace with text stating that properties and values that are not defined in CSS Level 1 cause the warn Commenter didn't respond
LC-1752 Shadi Abou-Zahra
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:
This has been reworded and a reference inserted to the discussion of meta in section 2 which makes it clear that only in three cases are meta http-equiv elements taken into account Commenter didn't respond
LC-1753 Shadi Abou-Zahra
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:
Thanks that was indeed a typo Commenter didn't respond
LC-1755 Shadi Abou-Zahra
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.
We mean html as the root element and will add a clarification to that effect. Commenter didn't respond
LC-1756 Shadi Abou-Zahra
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
It's reworded to refer to the genenral algorithm which contains the FAIL already. Commenter didn't respond
LC-1757 Shadi Abou-Zahra
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:
The clarification suggested under LC-1756 covers this point too. Commenter didn't respond
LC-1758 Shadi Abou-Zahra
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:
Thanks, yes. Commenter didn't respond
LC-1759 Shadi Abou-Zahra
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
We removed % in an earlier draft as it is not a unit. Clarify by rephrasing as If the value is non-zero has a unit and the unit is not "em" or "ex" (and the value is not a percentage) Commenter didn't respond
LC-1761 Shadi Abou-Zahra
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"
Add a reference to white space definition in 3.12 3.15 and 3.17 Commenter didn't respond
LC-1762 Shadi Abou-Zahra
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"
Change GET to POST in this section as indicated Commenter didn't respond
LC-1763 Shadi Abou-Zahra
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
Clarify as suggested Commenter didn't respond
LC-1765 Shadi Abou-Zahra
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
THanks, that change has been made. Commenter didn't respond
LC-1767 Shadi Abou-Zahra
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:
THanks that bit has been re-written and removed Commenter didn't respond

Last Call round 1

Comment IDCommentResolution from BPWGStatus
LC-1654 on behalf of I18N Working Group
Comment from the i18n review of: mobileOK Basic


Comment 3
Editorial/substantive: S
Owner: RI

Location in reviewed document:
3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

Comment:
[[If character encoding is specified in more than one way, and not all values are the same, FAIL]]


I'm not personally familiar with transcoding scenarios, but I've heard people often quoting them as justification for using the HTTP header to declare encodings and for the HTTP declaration to have higher precedence in HTML than the in-document declarations. As I understand it, the rationale is that a transcoding server can change the encoding of the document as it passes through, but doesn't change in the internal encoding declaration. Since HTTP declarations beat in-document declarations, this is supposed to be OK. I've also heard that this kind of thing happens particularly when serving documents to mobile devices. If this is true, then I guess there must be occasions when it is permissible for the HTTP header declaration to be different from the other two?
Transcoding and adaptation are orthogonal questions. mobileOK is concerned with content delivered to a device, regardless of how it was created. Transcoders that behave in this way may well cause a resource to fail mobileOK tests. Commenter didn't respond
LC-1656 on behalf of Felix Sasaki
Comment from the i18n review of: mobileOK Basic

Comment 6
Editorial/substantive: S
Owner: FS

Location in reviewed document:
3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE
6.3.1 Annotation element

Comment:
A personal comment from Felix Sasaki, not endorsed by the i18n core WG.


[[For each external resource as defined in 2.3.5 Included Resources: Request the URI indicated by the href attribute If the HTTP response Content-Type header value specifies an Internet media type starting with "text/" but does not specify UTF-8 encoding(e.g. "text/css" only instead of "text/css;charset=UTF-8"), warn PASS]]


Should a @charset rule in an included CSS stylesheet be taken into account? I.e., should there also be a warning if such a rule specifies an encoding different that UTF-8?
The DDC offers CSS Level 1 + @media support only Commenter didn't respond
LC-1630 Bruno von Niman
Comment #1: In the perspective of the above, we believe that this may be understood as
(strongly) misleading consumers, who will have other, natural assumptions about the
meaning of the trust mark. Assumably, if a mobile Web site is declared to be “mobileOK"?,
consumers will assume the trust mark to is some kind of guarantee for aspects that will mean
OK to them. In other words, it may well be assumed as a guarantee for reliable content, safe
access, and trustable connections with a fair usability and some minimum levels of
accessibility. Furthermore, depending on the consumer’s age, assumptions may even be
made about the some kind of appropriateness of the content, when accessed by young
children.
An analogy to the above is TV sets marketed as “HD ready"?. Even if this is only a declaration
of one of the TV set’s capabilities, consumers (typically uninterested in details of this and
other technologies) will naturally assume this to be a declaration of compatibility and
capabilities for receiving and displaying high definition TV broadcasts without further needs to
buy additional products (such as a set-top box) and most probably, subscriptions (that will
also imply a considerable monthly fee). Consumers are often not aware that HD displays will
only display an HD picture when connected to an HD receiver (set-top box).
This will lead to consumer disappointment and the product may even be handed back. To
continue with the analogy, “Real HD ready"? TV sets are now marketed and the situation is
becoming very confusing…what was “HD ready"?? And what may be next? False marketing
does not aid the successful uptake of new consumer technologies.
Therefore, we suggest the re-branding of the mobileOK™ and mobileOK Basic™ trust marks
in some way that reflects their true and proper meanings. Due to the complexity of the
required branding, this may be a challenging task but worth the effort. It is not our task, nor
competence area to propose alternative names that would work properly on a global market
but wording that consumers would understand may include:
• Ready for mobile use;
• Mobile device adapted site;
• This content displays OK on mobile devices.
We believe that third party provisioning (or certification) is the only way to provide a reliable
trust mark information to consumers as often, products do not match qualities declared by
manufacturers, entailing a loss of consumer confidence. ANEC therefore encourages third-
party certification.
It is not possible to fit all of this meaning in a short brand name, and any given name will have potential problems. That is why sections 1.1.1 and 1.1.2 explain in detail what mobileOK Pro and mobileOK Basic mean. We'd welcome better terms, but as you say you don't have a better idea.

We have to choose something, and the names "mobileOK Basic" and "mobileOK Pro" were selected as the most appropriate ones, as they are fairly universal, short, and do not directly imply incorrect interpretations. "mobileSafe" would have been a poor choice for example. "mobileOK" itself seems to address the three points you believe consumers should understand.

mobileOK Pro will be third-party certified. We believe that specifying *only* third-party-certified trustmarks will severely limit adoption, to the point that concerns about consumer understanding are moot. Hence a the machine-verifiable "mobileOK Basic" trustmark exists.
OK
LC-1631 Bruno von Niman
Comment #2: The above is a valuable statement to developers but, again, misleading to
consumers, who should understand the trust mark in the right way.
We feel that enough caveats have been given earlier in the document to cover this OK
LC-1632 Bruno von Niman
Comment #3: In addition to the above information recommended for provision, the consumer
should be informed about the reason of failure in an understandable way. Additional
information relating to other functionalities should also be provided. Furthermore and in
addition, a technical reason or code may be provided to help the operator or creator of the
implementation to identify the source of the error.
Last but not least, consumers should be able to contact customer services through a single
point of access per modality (e.g. by calling the “usual"? number for all issues).
mobileOK Basic Tests is not a consumer facing product. It's up to mobileOK checkers to provide informative error messages. Where it is not clear what the point of a FAIL is we will consider additional information OK
LC-1633 Bruno von Niman
Comment #4: We would like the WG to confirm if the consequences of applying and using
CSS have been examined with regard to mobile Web accessibility (possibly in collaboration
with the WAI/WCAG Activity)?
No, we believe that the work is orthogonal to WAI and have already included new text at WAI's request to clarify that OK
LC-1634 Bruno von Niman
Comment #5: We believe that the UTF-8 coding support should be studied in more detail, as
it may have implications on the displayable text and the data transmission.
According with the text in test CHARACTER_ENCODING_SUPPORT / CHARACTER_ENCODING_USE "The test does not require that resource always be encoded in UTF-8; the test merely checks that the resource is available in UTF-8 encoding, if requested. Resources may be delivered to devices in other encodings where appropriate. This test verifies that a DDC-like device which only accepts UTF-8 encoding may access the resource in UTF-8 encoding". OK
LC-1611 Carlos Iglesias on behalf of ERT Working Group
#3: 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.
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. Commenter's replies taken into account in following LC
LC-1616 Carlos Iglesias on behalf of ERT Working Group
#8: Section "2.4 CONTENT_FORMAT_SUPPORT" reads: "If the response specifies an Internet media type that is not "text/css", "image/jpeg" or "image/gif", FAIL"

As currently defined, if you use content formats like "image/png" or "application/svg+xml" that are not included in the DDC (default delivery context) you can't get the mobileOK label. This could be a limitation for the evolution of content formats in the mobile web, and for the label itself as it only promotes basic content formats and other formats will be always excluded. Is there any plan to support a more flexible mechanism similar to the WCAG 2.0 "baseline concept" [4]?
Narrowly speaking, you can use such formats in the object element. However those formats were intentionally excluded from the DDC.

We anticipate updating the definition of the DDC from time to time.

We do not plan, at present, to support a WCAG 2.0 style Baseline Concept. We are investigating this idea for a subsequent version.
Commenter's replies taken into account in following LC
LC-1617 Carlos Iglesias on behalf of ERT Working Group
#9: Section "3.4 CONTENT_FORMAT_SUPPORT" reads: "If the Internet media type is "text/css" and the content is not well-formed CSS (contains mismatching brackets or illegal characters), FAIL"

We think "contains mismatching brackets or illegal characters" is not a good example for nor a definition of well-formedness in CSS. Grammar conformance (e.g. CSS1, CSS2...) is apparently the suitable requirement.
We will clarify the wording to make it clearer and reference the appropriate specifications. Commenter's replies taken into account in following LC
LC-1619 Carlos Iglesias on behalf of ERT Working Group
#11: 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.
We agree with the basic point but we will address it in the next phase of the Best Practices document instead. Commenter's replies taken into account in following LC
LC-1621 Carlos Iglesias on behalf of ERT Working Group
#13: 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 '#' [5]) 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.
We think that there are valid uses for allowing # as the href, such as a link to the top of the page. Commenter's replies taken into account in following LC
LC-1622 Carlos Iglesias on behalf of ERT Working Group
#14: Section "3.17 PAGE_TITLE"

A max_size warn may also make sense here.
The group cannot determine a valid value for such a limit. Commenter didn't respond
LC-1624 Carlos Iglesias on behalf of ERT Working Group
#16: 3.8 IMAGE_MAPS, 3.14 NON-TEXT_ALTERNATIVES, 3.22 SYTLE_SHEETS_USE and 3.25 TABLES_NESTED

All of them are designed so that there's certain "overlap" between test cases because all their conditions are also XHTML Basic 1.1 validation conditions. Once XHTML Basic 1.1 validation is required at 3.4 CONTENT_FORMAT_SUPPORT, if test 3.4 pass all the previously mentioned (3.8, 3.14, 3.22 and 3.25) are also going to pass so, are they necessary?
mobileOK tests are intentionally expressed in an independent way. Section 2.3.1 (Order of tests) says that "mobileOK Basic does not prescribe the order in which tests are to be carried out as they may be executed independently". In order to keep the independence of test, each test description is seen as a unit. Of course, it is obvious that implementations will benefit from tests previously executed on a URI so subsequent tests applied to that same URI can be done taking as few time and computer resources as possible. Commenter didn't respond
LC-1645 Christoph Richter
We changed from UTF-8 to the desired ISO encoding (we deliver the specific encoding depending on the user language – currently we have 27 languages) because there are some handset incompatibilities.

Some handsets send the header, that they support UTF-8, but then produce error’s with this encoding.

Since these handsets were from different manufactures and also in our top 20 handsets we decided to produce only ISO encodings.



This was a decision nearly a Year ago. Maybe this has changed. And I think this will definitely in the future no problem, but currently we leave it as is.

I cannot remember exactly what phones that were, but I think one of them was Sony Ericsson K700i.
UTF-8 is used when nothing is known of the device and
user. Using ISO encoding requires some
knowledge of the user and the device. Using UTF-8 is a compromise and
there will be devices which do not
support it properly, however, of the choices available in this situation (nothing known of the device and user)
we believe UTF-8 is the one that works in most cases.

If the device is known not to support UTF-8 correctly then this should be dealt with per DEFICIENCIES.
Commenter's replies taken into account in following LC
LC-1578 Christophe Strobbe
The draft states: "This test does not determine whether the user is
able to opt out of refresh."
Is the possibility of opting out going to be covered elsewhere?
Using <meta http-equiv="refresh" content="..." /> fails three
different success criteria of the Web Content Accessibility
Guidelines 2.0 (see failure F40 in "Techniques for WCAG 2.0" [2]).
This is because screen readers will start reading from the top of the
page again when the page refreshes, thereby taking away control from
the user over his interaction with a page.
Server-side redirects [3] are preferable, but WCAG 2.0 currently also
allows client-side redirects if they have no timeout: see techniques
G110 (Using an instant client-side redirect [4]) and H76 (Using meta
refresh to create an instant client-side redirect [5]).
Yes, opt out will be covered in the test that is part of mobileOK Pro since this part of the test is not machine verifiable. We acknowledge the undesirability of refresh from a WCAG point of view but the functionality has been discussed at length in the WG and is desirable from a mobile point of view. OK
LC-1581 Christophe Strobbe
This prohibits the definition of image size in style sheets [6]. Is
that intentional or an oversight?
This is intentional. The best practice is to define the size of image in MARKUP so that the browser can allocate the right amount of space when it initially renders the document. Markup in style sheets can mean that the browser needs to re-render the page on receipt of the style sheet. OK
LC-1582 Christophe Strobbe
The draft states: "This test does not determine whether the
alternative text is meaningful." Why not? Doesn't a meaningless text
alternative defeat the purpose of the alt attribute?
Note that the current working draft of WCAG 2.0 requires: "text
alternatives serve the same purpose and present the same information
as the non-text content. If text alternatives cannot serve the same
purpose, then text alternatives at least identify the purpose of the
non-text content" (this is just part of success criterion 1.1.1 [7]).
The test for meaningful text will come in mobileOK Pro, not mobileOK Basic. Basic can only test if it's present and not empty since it consists of machine-verifiable tests. OK
LC-1583 Christophe Strobbe
The draft states: "This test does not catch all cases where tables
are used for layout purposes." I agree. "Techniques for WCAG 2.0"
also has a test for layout tables [8]:
"Check for layout tables: determine whether the content has a
relationship with other content in both its column and its row. If
'no,' the table is a layout table. If 'yes,' the table is a data table."
Would that be a better fit? Obviously, the test from WCAG 2.0 cannot
be automated.
This text may be valuable for a human test specified in mobileOK Pro, but not for machine tests in mobileOK Basic. OK
LC-1601 Jo <>
In this test we look for target attribute on Link elements but under link target format we do not take account of any link elements at all, which may be inconsistent
Leave text as is. Commenter didn't respond
LC-1658 Jo Rabin
This test should be extended to catch WIDTH and HEIGHT attributes that are not expressed as percentages.
No not clear OK
LC-1625 Kai Hendry
First off, why the application/xhtml+xml? Do you have any idea about the
problems with this
? When will you see the light with HTML?


I would love to know of a single mobile phone sporting a conforming XML
processor. :)
We recognize that there are not many conforming XML processors, but recommend the use of application/xhtml+xml because that is what is recommended by device manufacturers. In addition we permit the use of text/html and application/vnd.wap.xhtml+xml Commenter didn't respond
LC-1626 Kai Hendry
Why not support text/plain in CONTENT_FORMAT_SUPPORT? :)
The point of mobileOK is to demonstrate that the content provider has taken basic steps to provide a functional user experience. We don't consider text/plain to qualify as taking basic steps as retrieval of a text/plain document may leave the mobile user in a difficult navigational position. Commenter didn't respond
LC-1627 Kai Hendry
PAGE_SIZE_LIMIT size is slowly becoming a less of an issue, it's more
latency with mobiles. Can't you see you're writing a document doomed to
be become obsolete?
Page size limit refers both to the physical capacity of devices and to the ergonomics of user access to larger pages. The WARN at 10K reflects this. The FAIL at 20K will over time need to be updated as devices become more capable. Commenter didn't respond
LC-1628 Kai Hendry
Many issues here (SCROLLING, POP_UPS etc.) could be handled by a smart
UA (and proxy esp for imgs). Telling authors they can't have tables more
that 2x2 seems a little daft. You will risk content developers creating
separate mobile device targeted Web pages. Is that what you want to see
happen?

So many of these failures could be warnings IMO, in order not to scare
content creators.
Yes we believe that in most cases a single page can't serve both mobile and web users adequately, and this requires specialized treatment of mobile devices. Whether you author a separate resource without tables, or use an adaptation engine to remove tables is an implementation decision left to the author. This group's output by definition assumes that one needs to think about mobile separately, but is only concerned with what is delivered to mobile devices and not how it is authored. Commenter didn't respond
LC-1629 Kai Hendry
Anyway it would be good if some mobile developing hints were just
implemented by a normal W3C HTML validator
or Unicorn. Anyone working on that? Banging out this bureaucratic
document "W3C mobileOK Basic Tests 1.0" seems a waste of time and
resources.

You need to evolve faster.
Thank you for your comment. We feel this is out of scope for this group as we focus on mobile specifically, and mobile is different enough from the web to warrant separate attention and tools right now. However, the reference implementation for mobileOK checker (based on mobileOK Basic Tests) may be become part of a future general HTML validation scheme if appropriate, and will hopefully replace the implementation behind validator.w3.org/mobile Commenter didn't respond
LC-1607 Loretta Guarino Reid
We like the similarity in approach to the descriptions of these test
and WCAG2 techniques. For MobileOK Basic Tests 1.0, the tests are
written in "programmatic" style. Test outcomes for MobileOK Basic 1.0
tests are pass, fail, and informative warnings. WCAG2.0 test outcomes
are "true", or "false". It would be worth exploring whether we could
use consistent language.
Consistency is important, all else being equal, but here we believe that "pass" and "fail" are more understandable as test outcomes. The EARL specification also uses these terms, and we would also like to remain consistent with EARL. OK
LC-1635 Micah Dubinko
Overall impression

The overall impression the tests give me is that, given a non-whitelisted device, the safer alternative is to exclude all CSS. This seems like the wrong impression to give mobile developers.
No we don't see how the document supports this interpretation.

The only tests related to CSS styles are:

MEASURES: This test set a restriction on using only relative measures of length.

STYLE_SHEETS_SUPPORT: This tests searches properties such as position, display or float getting a warning in the worst case. In addition, a human test should verify if the page is readable without style sheet.

STYLE_SHEETS_USE: This test looks for elements not supported in XHTML Basic.

From these tests, we think that you cannot infer that the safer alternative is to exclude all CSS. It is only STYLE_SHEETS_SUPPORT which recommends that a page should be readable without style sheets, which is really helpful in devices not supporting them or just configured by the user in order to not use them.
Commenter didn't respond
LC-1638 Micah Dubinko
3.7 GRAPHICS_FOR_SPACING

Would it make sense to fail on > 1 transparent image (instead of going by size)? Having 20 2px by 2xp images is still bad.
In this case you only get a warn. We think that it would not make sense to fail on strictly more than one transparent images because it is known that some sites uses more than one transparent image in order to report several other companies about hit information.

It would be difficult to fix a strict number and also to distinguish between tracking purposes images from positioning ones. These kinds of subjective criteria should be dealt with by human experts and they might be refined in mobileOK (Plus?)

Also from "3.6 EXTERNAL_RESOURCES" [1], 10 external resources (including images, then) generates a warn, 20 generates a fail. So 20 2x2 images will generate a fail anyway.
Commenter didn't respond
LC-1640 Micah Dubinko
3.11 MEASURES

Should the 'outline' properies, which work much like the 'border' properties, be mentioned here?
One main difference between 'border' properties and 'outline' properties is the consumption of space. Outline properties do not take extra space. So if you had an image that was 50 pixels wide, with a 2 pixel border, it would take up 54 pixels (2 pixels for each side border). That same image with a 2 pixel outline would take up only 50 pixels width on your page, the outline would display over the outside edge of the image. Commenter didn't respond
LC-1641 Micah Dubinko
3.16 PAGE_SIZE_LIMIT

10k is extremely limited, and dates the document. What are the plans for updates?
We do acknowledge that size limits of 10kb for markup and 20kb for total (including external references) is rather small and limiting. However, the rationale behind the Default Delivery Context and page size limit is to provide guidance as to how to develop content that will work in largest possible numbers of devices already out on the marketplace.

As the marketplace today is still dominated mostly by devices with limited memory resources, we think this recommendation is a valid one within this context. If confronted with facts proving this guideline wrong we are more than happy to change it. This is a guideline that needs to evolve over time.
Commenter didn't respond
LC-1642 Micah Dubinko
3.17 PAGE_TITLE (partial)

If <title> is missing, the document is invalid. So redundant w/ VALID_MARKUP
Fair point. We had deliberately allowed some redundancy in cases where it makes the test results clearer. You are correct that a missing <title> yields a failure in VALID_MARKUP, but it felt odd to not cause a failure in PAGE_TITLE too since it's specifically testing <title> Commenter didn't respond
LC-1650 Raymond Sonoff
3. Allow for incorporating hyperlinks to external (non-mobileOK) Web site's
pages.

3. I may not be correct on the way that I stated this third request, but it
appears from what I understand or interpret as the status of MWBP Testing
results that external-to-the-.mobi-Web-site-domain pages are expected to be
mobileOK-focused as well, are checked by W3C's MobileOK Best Practices
Checker software, and failure, of course. If this is a correct
interpretation, then I feel that this restriction from allowing hyperlinks
to other Web site's should be removed or in some way modified. The best
example I can give for where this situation seems not to be a reasonable one
is that hyperlinks to sonoffconsulting.com-based Web pages are not
considered acceptable yet they pass the above-stated conditions that reflect
a superset of the mobileOK Basic tests.
We do not specify that content which is linked to from a mobileOK page must, in it self, be also mobileOK. It merely states that if the content that is delivered from such a URI is /*not*/ of the media type the device has announced as being able to handle, then you should warn with this test. Commenter didn't respond
LC-1643 Roland Gülle
[DEFAULT_INPUT_MODE]
Why I have to use a inputmode attribute, when I send a XHTML/MP 1.0
page?
Only when you use XHTML Basic 1.1 (or other Markups that supports the
inputmode attribute), the attribute should be checked.
Today, most devices supports XHTML MP and not XHTML Basic 1.1 (still
a Working Draft).
We take your point, but it is only a WARN. We'd prefer people to specify Basic 1.1 and use inputmode and that will remove the WARNings. OK
LC-1646 Christoph Richter
And btw, because of the Measures point, there is always an need to define 1px size of whatever for lines. And since we can produce for each handset the right page for their resolution we make everything in pixel…
We accept this comment for the next version of the BP document. Commenter didn't respond
LC-1608 Loretta Guarino Reid
MobileOK Basic 1.0 limits itself to machine-testable properties, while
WCAG2 includes human-testable as well as machine-testable properties.
There may be occasions where MobileOK Basic tests can be used to test
all or part of a WCAG2 technique.
Leave text as is. Shadi from the EARL WG is participating in the checker activity so hopefully this will be an outcome. OK
LC-1637 Micah Dubinko
3.4 CONTENT_FORMAT_SUPPORT

Is the intent that all WML content is excluded from the possibility of being mobileOK? In some regions, WML devices still represent the majority of mobile UAs. To ask another way, it the intent of these tests to specifically exclude testable guidelines for WML?
The answer is that if you can't respond with XHTML then no you are not mobileOK. There's nothing stopping you providing WML in addition. Commenter didn't respond
LC-1593
"If the document contains a CSS style element but no external style, warn"

Although the Best Practices advocate use of external style unless the device is known not to support it, I think we should drop this warn as a document containing only internal style seems fine to me. The only point of the warn is to say that you should consider centralising your style.
Resolve Yes, pending further group discussion Commenter didn't respond
LC-1652 on behalf of I18N Working Group
Comment from the i18n review of: mobileOK basic

Comment 2

Editorial/substantive: S
Owner: RI

Location in reviewed document:
3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

Comment:
[[If character encoding is not explicitly specified in at least one of these ways, FAIL]]


Given the goals of this test, shouldn't this say "If the UTF-8 character encoding is not explicitly specified..." ?
Change text to simplify and remove other reference to UTF-8 in same passage. Commenter didn't respond
LC-1653 on behalf of I18N Working Group
Comment from the i18n review of: mobileOK Basic


Comment 4
At
Editorial/substantive: S
Owner: RI

Location in reviewed document:
3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

Comment:
[[If any character encoding specified is not "UTF-8", FAIL


If the document is not valid UTF-8, FAIL]]


How are people to test this?
We intend to clarify the meaning of validity and we will point to the relevant specification which spells out valid byte sequences in UTF-8 Commenter didn't respond
LC-1655 on behalf of I18N Working Group
Comment from the i18n review of: mobileOK Basic

Comment 5

Editorial/substantive: S
Owner: RI

Location in reviewed document:
3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

Comment:
It would be great if you could add a reference to the article Multilingual Forms. It contains among others a Perl regular expression testing for UTF-8.
yes, and include a brief note and link to this article in the explanatory notes for this test. Commenter didn't respond
LC-1648 Bert Bos on behalf of CSS Working Group
"If the Internet media type is "text/css" and the content is not
well-formed CSS (contains mismatching brackets or illegal
characters), FAIL" should probably be rewritten, because CSS doesn't
define the term "well-formed."

But it is not immediately clear what it should be rewritten as. The
CSS spec is written to (1) allow future extensions and (2) to make
the meaning well-defined for as large a set of inputs as possible. A
visual UA will ignore the (legal) 'cue' property the same way it
ignores the (misspelled) 'magrin' property. There is no need for CSS
to say that one is legal and the other an error.

Illegal characters and unparsable input are explicitly undefined in
CSS, so there is no doubt that those must not be "mobileOK." On the
other hand, the handling of unbalanced parentheses *is*
well-defined. Informally, the wording suggests that unbalanced
parentheses are worse errors than unknown properties, but in the
spec they are handled the same way, viz., with rules to throw away
parsed tokens.

Maybe: "If [...] content triggers at least one CSS parsing error as
defined in the CSS specification, FAIL."

CSS 2.1 has a section 4.2 called "parsing errors," but there are
errors defined in other sections, too. CSS 2.1 section 4.2 has this:

- Unknown properties
- Illegal values
- Malformed declarations
- Invalid at-keywords (*)
- Unexpected end of style sheet
- Unexpected end of string
- (by reference to 4.1.7:) Invalid selector

(* already separated out in MobileOK section 3.22)

Other errors are defined in section 4.1:

- Input that cannot be tokenized or parsed (section 4.1.1)
- Vendor-specific extensions (4.1.2.1)
- U+0 character (4.1.3)
- Non-Unicode characters (4.1.3)

For example, a style sheet that consists of just this

;;;

cannot be parsed.
Yes, and adopt text: "If the Internet media type is "text/css" and the content is not CSS that conforms to the grammar specified in Appendix B of CSS Level 1 FAIL" - note also that we intend to clarify what we mean by Valid in general Commenter didn't respond
LC-1612 Carlos Iglesias on behalf of ERT Working Group
#4: 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)
See group resolution Commenter's replies taken into account in following LC
LC-1614 Carlos Iglesias on behalf of ERT Working Group
#6: Section "2.3.5 Included resources" reads: "Images included by background-image properties in the CSS Style"

Is there any reason to exclude other CSS-referenceable resources like images referenced by the list-style-image property or .ico cursors (CSS cursor property)?
The list-style-image property should have been included. The cursor property is not referenced as it is not CSS Level 1.

Checked for references in CSS level 1 for URL() and there is nothing besides background-image (background etc) and list-style-image (list-style etc)
Commenter's replies taken into account in following LC
LC-1615 Carlos Iglesias on behalf of ERT Working Group
#7: Section "2.3.6 Included Stylesheet Resources"

Do the restrictions (not alternate, charset, type, media) also apply to xml-stylesheet PIs?
the xml stylesheet processing instruction takes broadly the same attributes as the link element and we will update the document to reflect the same restrictions, so yes. Commenter's replies taken into account in following LC
LC-1620 Carlos Iglesias on behalf of ERT Working Group
#12: Section "3.12 MINIMIZE"

The definition of whitespace characteres should be clarified, does it include CR (carriage return) for example?
Additionally, it would make sense to consider also CSS in the minimization.
We accept the clarification and point to XML definition for white space

However, we exclude style regions for the current document but revisit for the next Best Practices document.
Commenter's replies taken into account in following LC
LC-1623 Carlos Iglesias on behalf of ERT Working Group
#15: Section "3.19 PROVIDE_DEFAULTS" reads: "If the document contains no input element whose name attribute's value matches that of this radio input and whose checked attribute is set to some value..."

We find the wording of this test complex and confusing in general.
The current test generates multiple warnings for each radio button in a group and the algorithm doesn't check that the rest of input elements are also radio buttons, in addition "checked" and "selected" are boolean attributes which only valid value is "checked" and "selected" respectively in XHTML or nothing in HTML (not "some value")

Proposed new wording:

For each radio button group (input elements with type="radio" that share the same name attribute value):
If not exactly one input element within this group is checked
(checked="checked"), warn

For each select element:
If there is no nested option element that is selected
(selected="selected"), warn

PASS

Furthermore, what happens if there is more than one nested option element whose selected attribute is set to some value but the "multiple" attribute is not set? Currently is a PASS, should it be this way?
We'll make edits to first stanza, yes, with a little editorial rewording. Commenter's replies taken into account in following LC
LC-1580 Christophe Strobbe
People are aware of validators for HTML, XHTML and CSS, but how do
you check if an image is valid according to GIF89A or JPEG? Do image
editors check this or do they just check whether the images are "good
enough" for the editor? Could you provide pointers to tools that are
reliable "validators" for GIF89A and JPEG?
Suggested resolution is to provide a pointer to the normative references for JPEG and GIF89A
We will not recommend a specific validator or implementation of these specs in mobileOK Basic, but, many such implementations do exist.
OK
LC-1661 Dominique Hazael-Massieux
It occurred to me that while mobileOK is encouraging the use of the
inputmode attribute [1], it doesn't make any check that the actual value
of the inputmode matches what XHTML Basic 1.1 allows


It is also pretty important given that the DTD doesn't actually enforce
these values.
We will change the test to check that the value of the inputmode attribute is something valid. OK
LC-1662 Dominique Hazael-Massieux
Reviewing the test for OBJECT_OR_SCRIPTS in mobileOK basic [1] doesn't
take into account the nested fallback mechanism allowed by the object
element.

It should:
* explain that the objects can be nested and that the tester needs to
look into each of the nested object until it find a proper fallback
* a proper fallback could be an <object> itself and not only an <img> or
some text
* the object element can contain a number of child elements (<param>
among others); how does this affect the test :
"If element body is non-empty and does not consist of text or an img
element that refers to an image in a supported format"
(in particular, it's not exactly clear what "element body" means here)
Yes and appropriate changes will be made to the document to reflect. OK
LC-1664 Dominique Hazael-Massieux
Another set of small bugs regarding "3.22 STYLE_SHEETS_USE":
* "@media rule" should read "@media at-rule"
* it makes no sense to restrict the warning on the fact that there is
only a single @media screen rule; I think what was meant was: if all the
CSS rules only apply to the screen media type, warn
* HTML 4.01 (which defines the rules that apply for XHTML 1.x as far as
I know) defines that the default value of the media attribute (both for
<style> and <link>) is "screen"

; in other words, if nothing is specified, the default is that the rules only apply to screen; that's probably worth clarifying explicitly in the test
* relatedly, if we do assume the media attribute defaults to "screen",
this means that a conformant user agent only reading @media handset
wouldn't read anything in the following <style>:
<style type="text/css">
@media handset {
..red { color:red;}
}
</style>

(because this style should be assumed to be in media screen, and so
wouldn't even need to be parsed by a handset);

I doubt this is what happens in practice, though; but at least, this may
deserve some clarification in the document.
1. editorial
2. we will warn if css rules apply only to screen media type
3. we will clarify that styles that have no media descriptor actually refer to all, not to screen.
OK
LC-1586 Jo Rabin
Current Text:

3.11 MEASURES

For each property in the CSS Style (2.3.4 CSS Style) whose value is a
numeric measure of length:

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

PASS

Proposed Text:

3.11 MEASURES

For each property in the CSS Style (2.3.4 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 (see also 3.20
SCROLLING (partial)), FAIL

[The point being that % is not in fact a unit and the case of line height
which can be a multiplier and % are ruled out by looking only at those
numeric units of measure that are stated together with a unit.

The case of a bald number (no unit) being used incorrectly will be picked up
by the CSS validity check]
Resolved to adopt above text on call of 2007-02-08 OK
LC-1588 Jo Rabin
What to do about 3xx, 4xx and 5xx HTTP status codes
Proposal by Sean and Jo

PROPOSED RESOLUTION: Do not carry out checks on pages attached to 3xx response codes"

PROPOSED RESOLUTION: Carry out checks on pages with 4xx and 5xx status and WARN

PROPOSED RESOLUTION: Add a note that checkers should implement authentication mechanisms so pages behind 401 status can be checked.
OK
LC-1589 Jo Rabin
Should we take account of meta http-equiv cache-control for people who can't change their headers?
proposal from Sean and Jo

PROPOSED RESOLUTION: Modify the text to say that if a meta http-equiv with cache-control is present, reduce the FAIL to a WARN in the case that it is not present in the HTTP headers
OK
LC-1591 Jo Rabin
I've seen people use max-age=-1 so think the test should be changed to look for max-age<=0 or an invalid value
From Sean and Jo:

PROPOSED RESOLUTION: check for invalid values in cache control header (e.g. 'ham-sandwich' as a value, negative on max-age ... ) and "warn" if present
OK
LC-1592 Jo Rabin
This test is very complex and will take a lot to implement. The most it will ever do is warn. We don't think that it is sufficiently accurate complete or useful to justify the cost of implementation.
Sean and Jo have slightly different takes on this:

Sean's PROPOSED RESOLUTION: Remove all. Replace with a check of CSS style for width specified in pixels greater than 120 and check all HTML width attributes for greater than 120. FAIL if present.
Check Table rows for width on TD elements and fail if sum > 120.

Jo's Proposed Resolution: Remove altogether as all cases are caught by other BPs anyway.
OK
LC-1594 Jo Rabin
and are also not supported in XHTML Basic => some of which are not supported (to take account of the inclusion - so far without deprecation - of b, big, i, small ... etc. from XHTML-MP
Resolve yes. "This test looks for elements in the Text Extension Modules defined by [XHTMLModularization], some of which are not supported in XHTML Basic. It also looks for commonly-used elements that were deprecated in HTML 4, and are not supported in XHTML Basic." OK
LC-1596 Jo Rabin
If the document does not validate against the XHTML Basic 1.1 DTD => if the document does not validate against the XHTML Basic 1.1 DTD then if also does not validate against the XHTML MP 1.2 DTD FAIL

(to take account of the remaining minor difference viz the start attribute on ol)
Resolved yes. "If the document does not validate against the XHTML Basic 1.1 DTD and in a subsequent test does not validate against the XHTML-MP 1.2 DTD. (regardless of its stated DOCTYPE), FAIL" OK
LC-1598 Jo Rabin
if the character-encoding is specified in more than one way and the values are not all the same

means that we will fail if there is a content-type header of text/html and a meta element with text/html; charset="UTF-8" which is not what we want.
Propose resolve No (leave this as is).

Actually, resolve yes. Editors to effect the change.
OK
LC-1599 Jo Rabin
add a test
if the character encoding is not specified as being supported in the request header, warn

(also Internet Media Types should be capitalized?)
Yes this is consistent with testing the content-type. Editors to adjust text.

[check character encoding per the source document for HTML and per CSS loading]
OK
LC-1600 Jo Rabin
In this and the one on objects think we should check that the text is not solely white space
Change PAGE_TITLE and OBJECTS_OR_SCRIPT to check that non-empty <title> and <object> text is not only whitespace. OK
LC-1604 Jo Rabin
should we explain restricting forms with ACTION GET or should we add ACTION=POST as well?
Leave test as is but add explanatory text regarding why POST is not tested. OK
LC-1605 Jo Rabin
So, given that the documents are supposed to be XML, and given that we
can refer to various STRONGLY RECOMMENDED clauses, should we insist on
the XML declaration being present and specifying an explicit encoding if
it is not explicitly set in the Content-Type header?

i.e. how much would we lose if we removed the META provision in 3.3?

Well, one possible answer is that if the content is delivered as
text/html then it is assumed not to be XML and the XML header may be
ignored. In this case having the META there is a kind of belt and
braces, though in practice it may be meaningless.

On reflection I think that in the case of text/html and no charset
parameter - we should check for BOTH the XML declaration and the META.
In the case of application/*+xml we should insist only on the XML
declaration and ignore the META.

Oh dear, this one won't lie down quietly.
Nous vous proposons:

If the character encoding is not explicitly specified in the HTTP header:

1. then it MUST be specified in an XML declaration.

2. if the content is delivered as text/html then it MUST in addition be specified in a META HTTP-EQUIV
OK
LC-1659 Jo Rabin
Does the DDC support cookies, if so then mobileOK should refer to cookies and should discuss under 2.3.2 HTTP Request
Yes, we don't rely on cookies we don't rely on cookies so we should spell out in 2.3.2 that the checker should not send them OK
LC-1606 Loretta Guarino Reid
We are concerned that the statement "Content which passes the tests
has taken some steps to provide a functional user experience for
users of basic mobile devices whose capabilities at least match those
of the Default Delivery Context (DDC)." would lead authors to conclude
that these guidelines will also meet the basic functional needs of
users with disabilities who use basic mobile devices. here is much in
common but these guidelines do not cover all of WCAG. We recommend
adding "To accommodate users with disabilities, WCAG should also be
met.", or "You should follow other guidelines that are applicable to
Web content, including the Web Content Accessibility Guidelines."
See updates following from this comment. OK
LC-1639 Micah Dubinko
3.10 LINK_TARGET_FORMAT

Should this mention non-200 responses? 404, 500, etc..? In the case where the linked resource is a form submit with method="post", a GET request might properly fail.
Yes, we will mention non 200 responses.

No we do not test form submit with method POST, and this is covered in section 2.3.7 (Visible linked resources)...
Commenter didn't respond
LC-1649 Raymond Sonoff
1. Increase the Page Limits from 10K for markup to at least 20K (preferably
40K), along with a commensurate increase for the total Page Limit to at
least 40K.

1. I wish to provide more than a token amount of content to anyone who
accesses any Web site that I develop, refine, and make available to
visitors, users, clients, prospects, or customers to those Web sites.
Providing alternative text, title text, and wanting to offer two Cascading
Style Sheets (one for the screen; the second, for print-related operations
-- as are currently exemplified for all Web pages in the
sonoffconsulting.com domain), the current upper limits are overly
restrictive and something has to be sacrificed (unnecessarily, I feel) to
pass that test element. QUESTION: Why not allow for the multi-CSS
stylesheets to allow for "intelligent word-wrapped" printing as a Web Best
Practice for everyone to incorporate into their Web site designs?
Stylesheets that are not targeted at mobile are not included in the total byte count. We will clarify the text at 2.3.5 and 2.36 to this effect. In respect of the upper limit of 10KB, this applies only to the DDC, if you are delivering to non-mobile devices then a higher limit may be appropriate. Commenter didn't respond
LC-1644 Roland Gülle
[STYLE_SHEETS_USE]
If the document contains any basefont, bdo, center, del, dir,
font, ins, menu, s, strike or u elements, FAIL
This is correct, but is this not part of the markup validation?
If so, why is there no DOCTYPE test?

If any element has a style attribute, warn
Why don't use style attributes on input boxes like:
<input type="text" name="number" value="" style="-wap-input-
format:NN" />
if you use a special textbox only on a special page?

If the document contains a CSS style element but no externally
linked CSS Style, warn
Why I should only use externally linked CSS Styles? If I use special
CSS information on one separate page only,
why I have to add them in the 'default' or separate external CSS?
1. MobileOK tests are intentionally expressed in an independent way.
Section 2.3.1 (Order of tests) says that "mobileOK Basic does not prescribe the order in which tests are to be carried out as they may be executed independently". In order to keep the independence of test, each test description is seen as a unit.

2. No ref style attribute - good point but it is deprecated in Basic 1.1

3. Yes per LC-1593 on dropping external style as a requirement
OK
LC-1660 Sean Owen
We noted today in our implementation meeting that moblieOK Basic should say something about accessing https URIs:

- Implementations must be prepared to access https URIs
- Implementations must fail if the certificate is invalid
- Implementations should warn if the certificate presented is expired
- Self-signed certificates are allowed; the signer never generates a warning or fail
Yes it should be mentioned -- exact text to be created by editors. OK
LC-1585 Timo Skytta
Hi,

This is kind of a stupid feedback, but I think I should mention it since
I have
now faced the problem several times.....

I have gotten a lot of feedback from people who have misunderstood that
the MOK Basic
test doc is setting requirements for a mobile web browser, like for
example people are
wondering why in 2.3.2

we define such a limited HTTP Request etc....

So I have had to explain people that this doc is about defining how a
web site can be tested
for it's ability to deliver content based on the limitations set forth
by DDC and selected BPs
we chose to test. Meaning that the doc is about how to exercise a web
site with an imaginary
DDC client which MOK tester pretends to be to see if indeed the web site
can deliver MOK
content. Also I needed to make it clear to them that the doc is NOT
about testing a mobile
browser for MOK or setting any requirements to a mobile browser.....

I wonder if we should somewhere in the doc, like on the Abstract or on
the Introduction make it
clear that MOK is not about testing a mobile browser or setting any
requirements for it, but it is
about testing a web site and setting requirements for it.

Or maybe people providing me feedback are ignorant enough not to read
the doc in enough details...

-------------
Jo Rabin says:

I agree that if this is a common misconception then that misconception
should be put to rest. However, I think that what is missing is mainly a
statement of what mobileOK _is_ rather than a statement about what it is
_not_.

Also under 1.3 Claiming mobileOK conformance, we say "mobileOK does not
imply endorsement or suitability ... or is appropriate for children".

That statement is actually out of place (in that it is not about
claiming mobileOK conformance), so we should move it and put it with a
"not user agent test" disclaimer, to a proper section.

I think the right place is in section 1 Introduction. I suggest:

Current Text:

This document describes W3C mobileOK Basic tests, which are based on
Mobile Web Best Practices [BestPractices].

mobileOK Basic is the lesser of two levels of claim, the greater level
being mobileOK (W3C mobileOK?), described separately. Claims to be W3C
mobileOK Basic are represented using content labels, also described
separately.

The intention of mobileOK is to help catalyze development of Web sites
that provide a functional user experience in a mobile context.

Proposed Text:

mobileOK is a scheme for assessing whether Web resources (Web pages) can
be delivered in a manner that is conformant with Mobile Web Best
Practices [BestPractices].

This document describes W3C mobileOK Basic tests. mobileOK Basic is the
lesser of two levels of claim, the greater level being mobileOK (W3C
mobileOK?), described separately. Claims to be W3C mobileOK Basic are
represented using content labels, also described separately.

The intention of mobileOK is to help catalyze development of Web sites
that provide a functional user experience in a mobile context.

mobileOK does not imply endorsement or suitability of content. For
example, it must not be assumed that mobileOK content is of higher
informational value, is more reliable, more trustworthy or is
appropriate for children.

mobileOK is not a test for user agents and is not intended to imply
anything about the way that user agents should behave.

---------------------

Yes, thanks, I think there is an important aspect of Sean's proposal
that I missed out which is that the DDC needs significant mention. I
don't think that the tests 'emulate a request' as such. Rather they
describe how to emulate the DDC when making a request and how to assess
content delivered as a result.

So forgive me but I have a further elaboration:

Proposed Text:

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 [DDC].

This document describes W3C mobileOK Basic tests for delivered content,
and describes how to emulate the DDC when requesting that content.

mobileOK Basic is the lesser of two levels of claim, the greater level
being mobileOK (W3C mobileOK?), described separately. Claims to be W3C
mobileOK Basic are represented using content labels, also described
separately.

The intention of mobileOK is to help catalyze development of Web content
that provides a functional user experience in a mobile context. 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.

mobileOK does not imply endorsement or suitability of content. For
example, it must not be assumed that mobileOK content is of higher
informational value, is more reliable, more trustworthy or is
appropriate for children.
Resolved on Feb. 8 to adopt Jo / Phil's proposed text. OK
LC-1651 on behalf of I18N Working Group
Comment from the i18n review of: mobileOK Basic


Comment 1
Editorial/substantive: E
Owner: RI

Location in reviewed document:
3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE

Comment:
[[
- Content-Type header (e.g. "application/xhtml+xml;charset=UTF-8")

- XML declaration (e.g. "<?xml encoding="UTF-8"?>")

- meta element that is the first child of the document's head element, and whose http-equiv attribute is "Content-Type", and whose content attribute specifies a character encoding as above (e.g. "<metahttp-equiv="Content-Type" content="application/xhtml+xml;charset=UTF-8"/>)
]]

Since this test is testing for UTF-8 support, it should be made clearer that the reason 'e.g.' is used rather than 'i.e.' has to do with the other parts of the construct, rather than the encoding declaration itself.
Yes, change to "i.e.", but, also boldface the important parts of the given strings: "application/xhtml+xml** ;charset=UTF-8**" Commenter didn't respond
LC-1647 Bert Bos on behalf of CSS Working Group
The "not" in "style elements whose type attribute is not
"text/css"" is erroneous since the type attribute on the style
element is REQUIRED as per [2]. Maybe just a typo?
Thanks this was a typo Commenter didn't respond
LC-1609 Carlos Iglesias on behalf of ERT Working Group
#1: Section "1.2 Applicability" reads: "The tests apply to a URI. Passing the tests means that _under the right circumstances_, resolving a URI will retrieve conformant content that is deliverd in a conformant manner."

It's not clear what "under the right circumstances" is intended to mean. What's the formal definition of "right circumstances"? Or, What are the wrong circumstances?
Reword as " ... Passing the tests means that *when accessed as described in [2.3.2 HTTP Request]*, resolving a URI will retrieve conformant content that is delivered in a conformant manner." Commenter's replies taken into account in following LC
LC-1610 Carlos Iglesias on behalf of ERT Working Group
#2: Section "1.3 Claiming mobileOK conformance"

There is an issue with POST parameters, which are not part of a URI. This is a general issue with content labelling, that could be solved with HTTP-in-RDF [3], but there's some doubt about whether POST requests are forbidden for mobile web content due to the requirement at section 2.3.2 "Use the HTTP GET method when making requests". Are POST requests forbidden for mobile web content?
No, POST requests are not forbidden but we don't test them as they are not assumed to be "idempotent". We have clarified the document. Commenter's replies taken into account in following LC
LC-1613 Carlos Iglesias on behalf of ERT Working Group
#5: Section "2.3.4 CSS Style" reads: "Style elements whose type attribute _is not_ text/css"

Souldn't be "Style elements whose type attribute _is_ text/css?
Yes, thanks, this is a typo. OK
LC-1618 Carlos Iglesias on behalf of ERT Working Group
#10: Section "3.7 GRAPHICS_FOR_SPACING" reads: "If image height and width are both less than 2 pixels, warn"

As 2x2 images are allowed ("at most 2x2" in the prose), the test should be: "If image height and width are both less than _or equal to_ 2 pixels, warn" to be in agreement with the prose.

Moreover, shouldn't also non-transparent graphics for spacing be considered?
Thanks, we agree. OK
LC-1579 Christophe Strobbe
Note that the if statements for the meta element and the HTTP refresh
header are different: one refers to "the current resources's URI",
while the second refers to "the current page". Shouldn't the same
wording be used in both cases?
Yes, thanks we will use the term URI. OK
LC-1587 Jo Rabin
Various editorial comments

1.1.4 Beyond mobileOK

Many devices' capabilities => The capabilities of many devices

1.2 Applicability

Resolving a URI will retrieve => resolving a URI will result in

1.3 Claiming mobileOK conformance

of the mechanism will => of the mechanism for claiming mobileOK conformance will

2.3.3 HTTP Response


"Sometimes" [two occurrences in succeeding sentences, would read better if re-phrased in one of them]

Test implementations should respect only HTTP response headers => with the exception of http-equiv content-type as detailed below under CHARACTER_ENCODING_ ... test implementations should respect


2.3.4 CSS Style

(note that use of the style attribute is deprecated)

3. mobileOK tests

Occurs earliest in dictionary order => occurs first in dictionary order

3.3 CHARENC

I think we need a note that we do not take account of defaults. So if for example the Content-Type HTTP header is text/html and the META http-equiv is text/html; charset="UTF-8" these are not seen as being inconsistent with each other


3.6 External resources

301 or 302 => 3xx


3.9 Images resizing

Height and width can be e.g. 24 (meaning pixels) or 25% - do we need to make this clearer? i.e. where the text says "specify a size in pixels" add "(note that the height and width attributes take an integer without units, meaning pixels)"

3.22 STYLE

Reword to: 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, warn


3.24

If no tr element contains at least two td elements => If no tr element contains more than one td element
OK
LC-1597 Jo Rabin
the example xml declaration is missing the mandatory version attribute
Corrected the typo. OK
LC-1602 Jo Rabin
Do we need to be more specific about what we mean by valid utf-8, css, jpeg, gif and xhtml validation?
Editors to draft a new section on validity explaining where to find the definitive specifications and to note that issues around specifying validators is to be resolved by the checker group. OK
LC-1663 Jo Rabin
real = actual
Thank you for your perspicacious observation, Mr Rabin. OK
LC-1636 Micah Dubinko
1.2 Applicability

"The tests apply to a URI. Passing the tests means that under the right circumstances, resolving a URI will retrieve conformant content"

What is "conformant content"?
Change to "mobileOK conformant content" Commenter didn't respond