CSS WG comments

Here are the comments from the CSS WG on
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests
-20070130/

[The deadline was yesterday, but I forgot to send them
before going 
home. Sorry.]


section 2.3.4:
    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?


section 3.4:
    "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.

[2] 
http://www.
w3.org/TR/2001/REC-xhtml-modularization-20010410/dtd_module_
defs.html#a_module_Style_Sheet


For the CSS WG,
Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people
/bos                               W3C/ERCIM
  bertw3.org                             2004 Rt des
Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis
Cedex, France

Thanks Bert, I added your comments to our list of comments
to process
for the last call draft. Yes you are right about the typo
for sure.

Sean

On 3/14/07, Bert Bos <bertw3.org> wrote:
>
> Here are the comments from the CSS WG on
> http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests
-20070130/
>
> [The deadline was yesterday, but I forgot to send them
before going
> home. Sorry.]
>
>
> section 2.3.4:
>     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?
>
>
> section 3.4:
>     "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.
>
> [2]
> http://www.
w3.org/TR/2001/REC-xhtml-modularization-20010410/dtd_module_
defs.html#a_module_Style_Sheet
>
>
> For the CSS WG,
> Bert
> --
>   Bert Bos                                ( W 3 C ) http://www.w3.org/
>   http://www.w3.org/people
/bos                               W3C/ERCIM
>   bertw3.org                             2004 Rt des
Lucioles / BP 93
>   +33 (0)4 92 38 76 92            06902 Sophia
Antipolis Cedex, France
>
>

 Dear Bert Bos ,

The Mobile Web Best Practice Working Group has reviewed the
comments you
sent [1] on the Last Call Working Draft [2] of the W3C
mobileOK Basic
Tests 1.0 published on 30 Jan 2007. Thank you for having
taken the time to
review the document and to send us comments!

The Working Group's response to your comment is included
below, and has
been implemented in the new version of the document
available at:
http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests
-20070525/

Please review it carefully and let us know if you agree with
it or not
before 22 June 2007. In case of disagreement, you are
requested to provide
a specific solution for or a path to a consensus with the
Working Group. If
such a consensus cannot be achieved, you will be given the
opportunity to
raise a formal objection which will then be reviewed by the
Director
during the transition of this document to the next stage in
the W3C
Recommendation Track.

Thanks,

For the Mobile Web Best Practice Working Group,
Michael(tm) Smith
W3C Staff Contact

 1. http://
www.w3.org/mid/200703141553.47013.bertw3.org
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests
-20070130/


=====

Your comment on 2.3.4 CSS Style:
> 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?


Working Group Resolution:
Thanks this was a typo

----

Your comment on 3.4 CONTENT_FORMAT_SUPPORT:
> "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.


Working Group 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.w
3.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

----