Barry Pannebaker | 1 Oct 03:43 2006

[css3-selectors] Multiclass selectors

In "6.3.1. Attribute presence and values selectors", in the Examples, could the text, "Multiple attribute selectors can be used to represent several attributes of an element, or several conditions on the same attribute." be moved out of the example block so that it becomes normative?

 

The following selectors do not work, at least in IE6; both paragraphs incorrectly take on both red and underlining.  (Test file attached.)

 

*.aquablock { background-color: aqua; }

*.aquablock.notice { text-decoration: underline; }

*.limeblock { background-color: lime; }

*.limeblock.notice { color: red; }

 

<p class="aquablock notice">This text should be underlined, but should <em>not</em> be red.</p>

 

<p class="limeblock notice">This text should be red, but should <em>not</em> be underlined.</p>

 

If the "Multiple attribute...." statement were made normative, perhaps it would be implemented.

 

What I’m suggesting might read something like the following.  (Note, if you just broke the Example box, and put the normative text in where it presently falls, all of the following examples would presumably be examples of that normative statement, and they’re not.  But, perhaps you could move the "Multiple attribute...." statement to the end, as below.)

 

|          DIALOGUE[character=juliet]

|___________________________

 

Multiple attribute selectors can be used to represent several attributes of an element, or several conditions on the same attribute.

____________________________

|

|     Example:

|

|     Here, the selector represents a span element whose hello attribute has exactly the value "Cleveland" and whose goodbye attribute has exactly the value "Columbus":

|          span[hello="Cleveland"][goodbye="Columbus"]

|____________________________....

 

Really, the most helpful place to have an example of multiclass selectors would be in section “6.4. Class selectors”.  Especially helpful would be an example that uses the universal selector, (or just implies it).  Perhaps, after the current example in the second example block:

 

|     The following rule matches ANY element whose "class" attribute has been assigned a list of whitespace-separated values that includes "insert" and "warning":

|

|          .insert.warning { color: red }

|

|     This rule matches when class="expense insert warning blue" but does not match for class="insert announcement".

|_____________________________

 

Thank you for your consideration,

Barry

This text should be underlined, but should not be red.

This text should be red, but should not be underlined.

Kelly | 1 Oct 04:07 2006
Picon

Re: [css3-selectors] Multiclass selectors


On Saturday,  September 30, 2006 9:43 pm, Barry Pannebaker wrote:
> The following selectors do not work, at least in IE6; both paragraphs
> incorrectly take on both red and underlining.  (Test file attached.)

Using Internet Explorer 6 to check standards support isn't a fantastic idea; 
this is a known bug, and one that has been fixed in the IE7 beta.  It's also 
implemented in every other browser I know of that has CSS support.

--

-- 
http://www.mozilla.org/products/firefox/ - Get Firefox!
http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox!

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Barry Pannebaker | 1 Oct 04:32 2006

Re: [css3-selectors] Multiclass selectors

Kelly,

 

Thank you for your reply.  I’m glad to know other UA’s support multiclass selectors, and that MS7beta does, too.

 

I use IE6 assuming most of my clients’ customers use it, and I have to make my sites work on their machines.

 

Thanks,

Barry

fantasai | 1 Oct 02:04 2006
Picon

Re: [css3-namespace] XML Core WG's review


Grosso, Paul wrote:
> 
> This is the XML Core WG's review of the 2006-08-28 draft of the 
> CSS Namespaces module.  
> 
> 1) At the point in 3.3 where namespace prefixes are said to be
> case-insensitive, we'd like it pointed out (a) why this is so and (b)
> that even though XML documents have case-sensitive prefixes, there
> is no conflict, because the prefixes in the CSS need not be identical
> with those in the XML.

Prefixes are case-insensitive because CSS is case-insensitive. The only
parts of a style sheet that are case sensitive are the parts that involve
string matching against something outside of CSS (e.g. URLs, XML element
names).

I've added a note after the case-insensitivity statement:

  # Note, this does not cause any conflict with languages that use case-sensitive
  # prefixes because _only the expanded name matters_, not the prefix, and
  # therefore the prefixes need not be identical for the names to match.

where the link goes to the last paragraph of
   http://www.w3.org/TR/css3-namespace/#declaration

> (We realize you make this point later.)

s/later/earlier/

Let me know if this addresses your comment.

~fantasai

fantasai | 1 Oct 01:54 2006
Picon

Re: [css3-namespace] url() syntax


karl <at> w3.org wrote:
> 
> About http://www.w3.org/TR/2006/WD-css3-namespace-20060828/#syntax
> 
> The specification goes on defining that the namespace can be expressed
> as a string or a URI with the construct [STRING|URI] then later on the
> specification seems to discouraged the use of URI construct.
> 
> 	[[[
> 	A URI string parsed from the url() syntax must be 
> 	treated as a literal string: no URI-specific 
> 	normalization is applied. For this reason the string 
> 	syntax is recommended, and the url()  syntax discouraged 
> 	deprecated?.
> 	]]]
> 
> Why the original syntax is not:
> 
>   : NAMESPACE_SYM S* [namespace_prefix S*]? STRING S* ';' S*

Because support for the url() syntax has already been widely implemented,
and telling UAs not to support it would break backward compatibility. At
the same time, I feel the string syntax is a clearer representation of
how the namespace is processed (because the namespace need not be a url,
and because no url-specific processing is applied to it).

> Does the litteral string has to be a valid URI?

As far as CSS is concerned, no.

Let me know if this addresses your comment.

~fantasai

fantasai | 1 Oct 01:52 2006
Picon

Re: [css3-namespace] XML Core WG's review


Grosso, Paul wrote:
> 
> 3) The last paragraph of 3.1 is very unclear.  We believe it is essential,
> and a consequence of XML Namespaces 1.x, that namespace names must never
> be normalized in any way.  The reference to string syntax vs. url()
> syntax is unclear to us: whichever syntax is permitted, no normalization
> should be done.  We consider this a point that must be clarified in the
> next draft.

Well, there will always be some level of normalization in these two syntaxes:
CSS's backslash escapes, at the very least, must be replaced with the actual
character. So I can't say "no normalization", but I can reinforce that URI
normalization doesn't apply to the string syntax either. I've added "as with
the STRING syntax" to the sentence, so it now reads:

  # A URI string parsed from the <code>URI</code> syntax must be treated as
  # a literal string: as with the <code>STRING</code> syntax, no URI-specific
  # normalization is applied.

Let me know if this addresses your comment.

~fantasai

Jo-W | 1 Oct 21:53 2006
Picon

Re: [css3-selectors] :parent selector


What about taking an entirely different approach:

when writing:
  div p span { ... }

the css code will be applied to the last element in the selector, <span>.

I propose a "applies-to" selector:

writing:
  div |p| span { ... }

would apply the css code on the <p> element instead of the <span> element.

This should not have the same inefficiency (and less confusion when a
human reads the selector).

L. David Baron | 1 Oct 23:19 2006

Re: [css3-selectors] :parent selector

On Sunday 2006-10-01 21:53 +0200, Jo-W wrote:
> I propose a "applies-to" selector:
> 
> writing:
>  div |p| span { ... }
> 
> would apply the css code on the <p> element instead of the <span> element.
> 
> 
> This should not have the same inefficiency (and less confusion when a
> human reads the selector).

It does have the same ineffeciency.  The inefficiency is in the concept,
not the syntax.

It is, however, easier to understand.  And, not surprisingly, it's
already been proposed before.  The two main reasonably-well-designed
proposals for ancestor selectors are the proposals for :subject (which
your proposal is similar to, and which was in early drafts of
css3-selectors[1]) and the proposal for :matches() [2].

A comparison of the two is available at [3].

-David

[1] http://www.w3.org/TR/2000/WD-css3-selectors-20001005/#subject-pseudo
[2] http://lists.w3.org/Archives/Public/www-style/2003Apr/0146
[3] http://lists.w3.org/Archives/Public/www-style/2002May/0018

--

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation
Boris Zbarsky | 2 Oct 00:16 2006
Picon

Re: [css3-selectors] :parent selector


Jo-W wrote:
> I propose a "applies-to" selector:
> 
> writing:
>  div |p| span { ... }
> 
> would apply the css code on the <p> element instead of the <span> element.
> 
> This should not have the same inefficiency

Actually, it would.  It's exactly equivalent to some of the other proposals from 
a logical standpoint.  Just changing the syntax doesn't change the work that 
needs to be done.

-Boris

Boris Zbarsky | 2 Oct 01:09 2006
Picon

Re: [css3-selectors] Multiclass selectors


Barry Pannebaker wrote:
> In "6.3.1. Attribute presence and values selectors", in the Examples, 
> could the text, "Multiple attribute selectors can be used to represent 
> several attributes of an element, or several conditions on the same 
> attribute." be moved out of the example block so that it becomes normative?

There is already normative text in the spec to that effect.

> The following selectors do not work, at least in IE6

That's because IE6 has a buggy implementation of various normative parts of the 
spec in question.

-Boris


Gmane