Re: Recommended practice on selector compatibility

On Tuesday, December 3, 2002, 10:57:25 PM, Christian wrote:


CR> Hello,

CR> I have a question on any guidelines or recommended practices on the issue
CR> of selector compatibility between CSS1, CSS2 and CSS3 and HTML and XML.
CR> Mainly, this is on the .name class selector of CSS1 and its equivalent,
CR> [class=name] resp. [class~=name] in CSS2.

(CSS2 also has the .name class selector, of course)

CR> Situation:

CR> - suppose you need to have class attribute values containing spaces or
CR> any Unicode character

any other Unicode character is fine; spaces separate the components of
the class (the sets of which this element is a member). So class="foo
bar baz" means the element is a member of three sets foo, bar and baz.

CR> - suppose you need to create a stylesheet that works both with XML and HTML
CR> - suppose you need to create a stylesheet that works in CSS1, CSS2 and CSS3

CR> How does one best formulate the selector for a class named 'heading 1'?

For a class attribute that contains the text "heading 1", it would be
a member of two sets, heading and 1. If you want to have a single set
it would need to be called heading1 or use some other non-syntactic
space such as non-breaking space, ideographic space, and so on.  SDo,
lets concentrate on the other part of your question, the 'or any other
Unicode character'.

CR> Possibilities I have come up with:

CR> (1) .heading\20 1 { ... }
CR> (2) .heading\00201 { ... }
CR> (3) .heading\0000201 { ... }
CR> (4) *[class=heading\0000201] { ... }

CR> ad 1:
CR> The CSS validator <http://jigsaw.w3.org/css-validator/> issues an error
CR> for this stating that the ~= selector may not contain a class name that
CR> includes a space.

It is correct. The space is syntactically meaningful, both in the
attribute value and in the selector.

CR> However, I need to separate the '1' from the rest with
CR> a space to not have it interpreted as belonging to the escape.

You would also need to escape the space in the actual class attribute
(or better, use some other character).  But yes, the fact that escape
sequences in CSS are not terminated and were extended to siz
characters in CSS3 makes them unweildy and difficuklt to use for both
implementors and stylesheet authors.

CR> ad 2:
CR> This validates, but will this work in CSS3 where the maximum escape
CR> sequence has been extended to six hex characters? How do I tell a CSS3
CR> parser that \0020 is a CSS2 conformant, maximum 4 char escape sequence
CR> and the trailing '1' is the next literal character?

This is probably why numeric character references in XML have a
semicolon terminator, and why most other constructs in CSS use a
functional notation with an explicit closing parenthesis.

unicode() would have been a better escape mechanism.


CR> ad 3:
CR> Opposite of (2), there is no way to make a CSS2 parser interpret the
CR> escape correctly; it will stop after 4 chars and treat the rest as
CR> literal again.

That sounds correct.

CR> ad 4:
CR> CSS1 does not support this kind of selector.


CR> Also, the .classname shorthand seems only to be defined for HTML
CR> documents (so I cannot use this notation for XML),

No, this is not correct. Its true that not all XML grammars will have
an attribute called class, and they may have NMTOKENS attributes
called other things, for which the more verbose syntax with the
explicit attribute name is more useful; but there is nothing
preventing the use of .class form in XML and it is already widely
used.

CR>  whereas the XML
CR> equivalent *[class=heading\0000201] is not usable in CSS1-supporting HTML
CR> browsers (due to (4)).


CR> What I have thought of would be something like

CR>   .heading\00201, *[class=heading\0000201] { ... }

CR> Is this correct CSS and, more specifically, is this a viable solution? In
CR> connection with XML, the UA should disregard the .classname variant and
CR> use the second simple selector, whereas in HTML, it would be the other
CR> way round.

No, you would be better doing that as two separate rules, the CSS2
form followed by the CSS1 form, assuming you can find a CSS1 parser
that implements the forward compatible parsing rules correctly.

CR> The above solution would still not solve the 4-char vs. 6-char maximum
CR> length escape sequences problem.

True.

CR>  Or am I missing something?

No, you do not seem to be missing something, but CSS does seem to be
missing something and CSS3 should probably be corrected.

-- 
 Chris                            mailto:chris@w3.org

Received on Wednesday, 4 December 2002 07:50:18 UTC