W3C home > Mailing lists > Public > www-style@w3.org > October 2000

Re: selector negation (was: Re: New version of the Selectors module of CSS3)

From: Jonas Sicking <sicking@bigfoot.com>
Date: Mon, 9 Oct 2000 00:37:54 +0200
Message-ID: <01cd01c03178$66542140$3110f7d4@ericsson.se>
To: <www-style@w3.org>
Bjoern Hoehrmann wrote
> * "Ian Hickson" <ianh@netscape.com> wrote:
> | > The button accepts keyboard events, so it has the focus. Thats what
the
> | > spec says. There is no need for a new pseudo-class.
> |
> | But the input field accepts keyboard events too. Are you seriously
saying
> | that you think two elements at once have focus???
>
> Since there are two elements that accept keyboard events, yes, that
exactly
> what I think.

When a button has focus (at least on windows) the action assosiated with the
button is fired when the user presses space. But when you enter data in a
textfield the submit button does not fier when you press space (fortuantly),
so the button does not have focus. Also the button does not recive
DOMFocusIn/DOMFocusOut when the textfield recieves/looses focus. (besides
the simple fact that it would be really confusing if two widgets had focus
at the same time..)


> | Right -- but that means you have to explicitly style the links too.
That's
> | the whole problem. What if you don't know what their style should be?
>
> I agree that this is a problem.

And this is one reason for having class-inversion.
However a bigger reason is that it would allow cleaning up stylesheets a
lot. Most of the times the exact same effects can be accomplised by using
two rules instead of classinversion, such as

P.recipe { border: 1px solid black }
P.recipe:contains("foo") { border: none }

is the same as

P.recipe:not-contains("foo") { border: 1px solid black }

But is much harder to read.
I'd guess that the WG has recogniced the need for class inversion since the
CSS3 drafts has contained inversion of some of the classes. What I'm asking
for is to make inversion generic on *all* pseudo classes by saying "any
pseudoclass can be inverted by putting not- infront of it" rather then
adding some specific classes that are inverted. That way it could also be
possible to have the CSS parser handle the inversion and thus making css
renderers a bit slimmer.

One thing to keep in mind is that the :subject pseudoclass can not be
inverted. However I don't really thing that :subject should be called a
psuedoclass since it does something compleatly different from all other
pseudoclasses. (And I think that Ian's :matches proposal is better, but not
perfect...)

> | > If you get pseudo-class inversion i want to have attribute inversion
like
> | > 'not
> | > equal', 'does not end with', 'has no attribute' and so on like
> | >
> | > a[!href]
> | > a[href^!"http://www.w3.org"]
> | > ...
> |
> | I have also proposed this (using the first syntax you gave!).
>
> There should be only one syntax for negation not two or three or even
more. I
> don't know the allowed grammar, so I cannot make a proposal.
>
> The negation selector has a relation to the :subject pseudo class (as it
> changes the semantic of the given selector), maybe they should have a
similar
> syntax.

Nop, they have no relation. the inverted pseudoclasses are just like a set
of new pseudoclasses whereas the :subject pseudoclass changes the target of
a rule.

About having two ways of doing inversion (not- on classes and ! on attribute
matches):
The WG didn't seem to like the ! syntax on classes (:!hover, :!root etc) due
to it looked a bit messy. One of the goals of CSS has been to make it easy
to humanly read and write.

On attribute matches I think it would be ok to use ! as inversion since
foo!="bar" is IMO just as logical as foo="bar". But I propose using
a[href!^="http://" rather then a[href^!"http://"]. But this is just syntax
and it dosn't really matter to me as long as the functionallity is there...


One thing that could be more challenging is to find a good syntax for rules
such as "any A element not a children of a P element":

!P > A { ... }

/ Jonas Sicking
Received on Sunday, 8 October 2000 18:36:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:06 GMT