Disposition of comments for the Mobile Web Best Practices Working Group

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

This test should be extended to catch WIDTH and HEIGHT attributes that are not expressed as percentages.

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

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/

Comment 2
At http://www.w3.org/International/reviews/0703-mobileok/
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..." ?

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/

Comment 4
At http://www.w3.org/International/reviews/0703-mobileok/
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?

Comment from the i18n review of:
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/

Comment 5
At http://www.w3.org/International/reviews/0703-mobileok/
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 [http://www.w3.org/International/questions/qa-forms-utf-8]. It contains among others a Perl regular expression testing for UTF-8.

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

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

#7: Section "2.3.6 Included Stylesheet Resources"

Do the restrictions (not alternate, charset, type, media) also apply to xml-stylesheet PIs?

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

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?

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:
http://www.w3.org/TR/2006/WD-xhtml-basic-20060705/#s_inputmode

It is also pretty important given that the DTD doesn't actually enforce
these values.

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)

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":
http://www.w3.org/TR/1999/REC-html401-19991224/present/styles.html#adef-media ; 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.

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]

What to do about 3xx, 4xx and 5xx HTTP status codes

Should we take account of meta http-equiv cache-control for people who can't change their headers?

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

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.

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