LC-1601
|
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. |
tocheck |
---|
LC-1658
|
This test should be extended to catch WIDTH and HEIGHT attributes that are not expressed as percentages.
|
No not clear |
tocheck |
---|
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 |
tocheck |
---|
LC-1652
<ishida@w3.org> on behalf of I18N Working Group (archived comment) |
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..." ?
|
Change text to simplify and remove other reference to UTF-8 in same passage. |
tocheck |
---|
LC-1653
<ishida@w3.org> on behalf of I18N Working Group (archived comment) |
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?
|
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 |
tocheck |
---|
LC-1655
<ishida@w3.org> on behalf of I18N Working Group (archived comment) |
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.
|
yes, and include a brief note and link to this article in the explanatory notes for this test. |
tocheck |
---|
LC-1648
Bert Bos <bert@w3.org> on behalf of CSS Working Group (archived comment) |
"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 (http://www.w3.org/TR/REC-CSS1#appendix-b) of CSS Level 1 FAIL" - note also that we intend to clarify what we mean by Valid in general |
tocheck |
---|
LC-1614
Carlos Iglesias <carlos.iglesias@fundacionctic.org> on behalf of ERT Working Group (archived comment) |
#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) |
tocheck |
---|
LC-1615
Carlos Iglesias <carlos.iglesias@fundacionctic.org> on behalf of ERT Working Group (archived comment) |
#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. |
tocheck |
---|
LC-1620
Carlos Iglesias <carlos.iglesias@fundacionctic.org> on behalf of ERT Working Group (archived comment) |
#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: 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. |
tocheck |
---|
LC-1580
Christophe Strobbe <christophe.strobbe@esat.kuleuven.be> (archived comment) |
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:
http://www.w3.org/Graphics/JPEG/itu-t81.pdf
http://www.w3.org/Graphics/GIF/spec-gif89a.txt
We will not recommend a specific validator or implementation of these specs in mobileOK Basic, but, many such implementations do exist. |
tocheck |
---|
LC-1661
Dominique Hazael-Massieux <dom@w3.org> (archived comment) |
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.
|
We will change the test to check that the value of the inputmode attribute is something valid. |
tocheck |
---|
LC-1662
Dominique Hazael-Massieux <dom@w3.org> (archived comment) |
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. |
tocheck |
---|
LC-1664
Dominique Hazael-Massieux <dom@w3.org> (archived comment) |
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.
|
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. |
tocheck |
---|
LC-1586
Dominique Hazael-Massieux <dom@w3.org> |
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 |
tocheck |
---|
LC-1588
Dominique Hazael-Massieux <dom@w3.org> |
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. |
tocheck |
---|
LC-1589
Dominique Hazael-Massieux <dom@w3.org> |
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 |
tocheck |
---|
LC-1591
Dominique Hazael-Massieux <dom@w3.org> |
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 |
tocheck |
---|
LC-1592
Dominique Hazael-Massieux <dom@w3.org> |
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. |
tocheck |
---|
LC-1594
Dominique Hazael-Massieux <dom@w3.org> |
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." |
tocheck |
---|