Edit comment LC-1648 for Mobile Web Best Practices Working Group

Quick access to LC-1578 LC-1579 LC-1580 LC-1581 LC-1582 LC-1583 LC-1585 LC-1586 LC-1587 LC-1588 LC-1589 LC-1591 LC-1592 LC-1593 LC-1594 LC-1596 LC-1597 LC-1598 LC-1599 LC-1600 LC-1601 LC-1602 LC-1604 LC-1605 LC-1606 LC-1607 LC-1608 LC-1609 LC-1610 LC-1611 LC-1612 LC-1613 LC-1614 LC-1615 LC-1616 LC-1617 LC-1618 LC-1619 LC-1620 LC-1621 LC-1622 LC-1623 LC-1624 LC-1625 LC-1626 LC-1627 LC-1628 LC-1629 LC-1630 LC-1631 LC-1632 LC-1633 LC-1634 LC-1635 LC-1636 LC-1637 LC-1638 LC-1639 LC-1640 LC-1641 LC-1642 LC-1643 LC-1644 LC-1645 LC-1646 LC-1647 LC-1648 LC-1649 LC-1650 LC-1651 LC-1652 LC-1653 LC-1654 LC-1655 LC-1656 LC-1658 LC-1659 LC-1660 LC-1661 LC-1662 LC-1663 LC-1664

Comment LC-1648

Comment Shortname:

Commenter: Bert Bos <bert@w3.org> on behalf of CSS Working Group

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeW3C mobileOK Basic Tests 1.0 Abstract Status of this Document Table of Contents 1 Introduction 1.1 Levels of mobileOK 1.1.1 mobileOK Basic 1.1.2 mobileOK 1.1.3 Out of Scope 1.1.4 Beyond mobileOK 1.2 Applicability 1.3 Claiming mobileOK conformance 2 Conformance 2.1 Validity of the Tests 2.2 Testing Outcomes 2.3 Conduct of Tests 2.3.1 Order of Tests 2.3.2 HTTP Request 2.3.3 HTTP Response 2.3.4 CSS Style 2.3.5 Included Resources 2.3.6 Included Stylesheet Resources 2.3.7 Visible Linked Resources 3 mobileOK Basic Tests 3.1 AUTO_REFRESH (partial) and REDIRECTION 3.2 CACHING 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE 3.4 CONTENT_FORMAT_SUPPORT 3.5 DEFAULT_INPUT_MODE 3.6 EXTERNAL_RESOURCES 3.7 GRAPHICS_FOR_SPACING 3.8 IMAGE_MAPS 3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE 3.10 LINK_TARGET_FORMAT 3.11 MEASURES 3.12 MINIMIZE 3.13 NO_FRAMES 3.14 NON-TEXT_ALTERNATIVES (partial) 3.15 OBJECTS_OR_SCRIPT (partial) 3.16 PAGE_SIZE_LIMIT 3.17 PAGE_TITLE (partial) 3.18 POP_UPS 3.19 PROVIDE_DEFAULTS (partial) 3.20 SCROLLING (partial) 3.21 STYLE_SHEETS_SUPPORT (partial) 3.22 STYLE_SHEETS_USE 3.23 TABLES_ALTERNATIVES 3.24 TABLES_LAYOUT (partial) 3.25 TABLES_NESTED 3.26 VALID_MARKUP A Acknowledgements (Non-Normative) B References (Non-Normative) C Best Practices' Relation to mobileOK Tests (Non-Normative)
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

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.

Related issues: (space separated ids)

WG Notes: CSS allows a great deal of leeway in errors to be contained in a CSS file and specifies how these are to be handled in the specification. It seems futile to be more "perfect" than the specification and such I suggest reword as "If the Internet media type is "text/css" and the content is not CSS that is conformant to the specification (contains mismatching brackets or illegal characters), FAIL"

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

(Please make sure the resolution is adapted for public consumption)