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

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)

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.

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

In this and the one on objects think we should check that the text is not solely white space

should we explain restricting forms with ACTION GET or should we add ACTION=POST as well?

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.

Does the DDC support cookies, if so then mobileOK should refer to cookies and should discuss under 2.3.2 HTTP Request

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

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.

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?

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

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

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 http://www.w3.org/TR/mobileOK-basic10-
tests/#http_request
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.

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

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

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?

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

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

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

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

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?

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

the example xml declaration is missing the mandatory version attribute

Do we need to be more specific about what we mean by valid utf-8, css, jpeg, gif and xhtml validation?

real = actual

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