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.
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.
Comment ID | Comment | Resolution from BPWG | Status |
---|---|---|---|
LC-1855 Bryan Sullivan |
| No We take your point but we don't think any ambiguity is introduced by this. | OK |
LC-1857 Bryan Sullivan |
|
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 |
|
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 |
|
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 |
|
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 |
|
Yes, it causes this test to fail -- this was the intent of this sentence, right. | OK |
LC-1854 Bryan Sullivan |
|
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 |
|
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 |
|
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 |
|
Will fix this, thanks. | OK |
LC-1897 Johannes Koch |
|
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 |
|
In both cases the relevant specification says case insensitive, so "yes" | OK |
LC-1899 Johannes Koch |
|
Yes, I will add the attribute names as appropriate. Case-insensitive is correct. | OK |
LC-1900 Johannes Koch |
|
The method is not case-sensitive, yes. I will clarify. | OK |
LC-1901 Johannes Koch |
|
Yes we will make a small clarification here. | OK |
LC-1904 Johannes Koch |
|
Yes, probably a corner case but a good point. | OK |
LC-1906 Johannes Koch |
|
Yes, a missing charset parameter would be considered inconsistent too. We will clarify. | OK |
LC-1907 Johannes Koch |
|
OK. | OK |
LC-1908 Johannes Koch |
|
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 |
|
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 |
Comment ID | Comment | Resolution from BPWG | Status |
---|---|---|---|
LC-1723 Anne van Kesteren |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
The text is appropriate as it stands as "starting with text/" includes text/html. | Commenter didn't respond |
LC-1709 Henri Sivonen |
|
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 |
|
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 |
|
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 |
|
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 |
|
We encourage people to use CSS and hence a warn is justified. | Commenter didn't respond |
LC-1781 Jonathan Jeon |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
There is no N/A outcome from mobileOK. | Commenter didn't respond |
LC-1751 Shadi Abou-Zahra on behalf of ERT Working Group |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
The term innermost nested was chosen deliberately. | Commenter didn't respond |
LC-1720 Simon Pieters |
|
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 |
|
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 |
|
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 |
|
'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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Reworded to work around this. | Commenter didn't respond |
LC-1706 Henri Sivonen |
|
Change "cannot be" to "is not". | Commenter didn't respond |
LC-1712 Henri Sivonen |
|
A note has been added to clarify what this means under 3.4. | Commenter didn't respond |
LC-1727 Jon Ribbens |
|
That is a typo, thanks for pointing it out. | Commenter didn't respond |
LC-1729 Jon Ribbens |
|
Reworded to work around this. | Commenter didn't respond |
LC-1730 Jon Ribbens |
|
That is a typo, thanks for pointing it out. | Commenter didn't respond |
LC-1731 Jon Ribbens |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Add text - URIs specified with other schemes MUST be ignored. | Commenter didn't respond |
LC-1745 Shadi Abou-Zahra |
|
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 |
|
Add clarification along the lines suggested. | Commenter didn't respond |
LC-1747 Shadi Abou-Zahra |
|
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 |
|
Change GET to POST in this section as indicated | Commenter didn't respond |
LC-1749 Shadi Abou-Zahra |
|
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 |
|
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 |
|
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 |
|
Thanks that was indeed a typo | Commenter didn't respond |
LC-1755 Shadi Abou-Zahra |
|
We mean html as the root element and will add a clarification to that effect. | Commenter didn't respond |
LC-1756 Shadi Abou-Zahra |
|
It's reworded to refer to the genenral algorithm which contains the FAIL already. | Commenter didn't respond |
LC-1757 Shadi Abou-Zahra |
|
The clarification suggested under LC-1756 covers this point too. | Commenter didn't respond |
LC-1758 Shadi Abou-Zahra |
|
Thanks, yes. | Commenter didn't respond |
LC-1759 Shadi Abou-Zahra |
|
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 |
|
Add a reference to white space definition in 3.12 3.15 and 3.17 | Commenter didn't respond |
LC-1762 Shadi Abou-Zahra |
|
Change GET to POST in this section as indicated | Commenter didn't respond |
LC-1763 Shadi Abou-Zahra |
|
Clarify as suggested | Commenter didn't respond |
LC-1765 Shadi Abou-Zahra |
|
THanks, that change has been made. | Commenter didn't respond |
LC-1767 Shadi Abou-Zahra |
|
THanks that bit has been re-written and removed | Commenter didn't respond |
Comment ID | Comment | Resolution from BPWG | Status |
---|---|---|---|
LC-1654 on behalf of I18N Working Group |
|
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 |
|
The DDC offers CSS Level 1 + @media support only | Commenter didn't respond |
LC-1630 Bruno von Niman |
|
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 |
|
We feel that enough caveats have been given earlier in the document to cover this | OK |
LC-1632 Bruno von Niman |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 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 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 |
|
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 <> |
|
Leave text as is. | Commenter didn't respond |
LC-1658 Jo Rabin |
|
No not clear | OK |
LC-1625 Kai Hendry |
|
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 |
|
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 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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
We accept this comment for the next version of the BP document. | Commenter didn't respond |
LC-1608 Loretta Guarino Reid |
|
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 |
|
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 |
|
Resolve Yes, pending further group discussion | Commenter didn't respond |
LC-1652 on behalf of I18N Working Group |
|
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 |
|
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 |
|
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 |
|
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 |
|
See group resolution | Commenter's replies taken into account in following LC |
LC-1614 Carlos Iglesias on behalf of ERT Working Group |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
We will change the test to check that the value of the inputmode attribute is something valid. | OK |
LC-1662 Dominique Hazael-Massieux |
|
Yes and appropriate changes will be made to the document to reflect. | OK |
LC-1664 Dominique Hazael-Massieux |
|
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 |
|
Resolved to adopt above text on call of 2007-02-08 | OK |
LC-1588 Jo Rabin |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Propose resolve No (leave this as is). Actually, resolve yes. Editors to effect the change. |
OK |
LC-1599 Jo Rabin |
|
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 |
|
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 |
|
Leave test as is but add explanatory text regarding why POST is not tested. | OK |
LC-1605 Jo Rabin |
|
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 |
|
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 |
|
See updates following from this comment. | OK |
LC-1639 Micah Dubinko |
|
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 |
|
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 |
|
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 |
|
Yes it should be mentioned -- exact text to be created by editors. | OK |
LC-1585 Timo Skytta |
|
Resolved on Feb. 8 to adopt Jo / Phil's proposed text. | OK |
LC-1651 on behalf of I18N Working Group |
|
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 |
|
Thanks this was a typo | Commenter didn't respond |
LC-1609 Carlos Iglesias on behalf of ERT Working Group |
|
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 |
|
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 |
|
Yes, thanks, this is a typo. | OK |
LC-1618 Carlos Iglesias on behalf of ERT Working Group |
|
Thanks, we agree. | OK |
LC-1579 Christophe Strobbe |
|
Yes, thanks we will use the term URI. | OK |
LC-1587 Jo Rabin |
|
OK | |
LC-1597 Jo Rabin |
|
Corrected the typo. | OK |
LC-1602 Jo Rabin |
|
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 |
|
Thank you for your perspicacious observation, Mr Rabin. | OK |
LC-1636 Micah Dubinko |
|
Change to "mobileOK conformant content" | Commenter didn't respond |