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

On Sat, 7 Oct 2000, 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.

That goes against the behaviour of every UI I know of. For instance, on
Windows, OK buttons don't have the dotted focus rectangle when a field is
focussed (they have a black outline instead). On Mac, the ok-button
equivalents have a thick outline, but it is not in the highlight colour,
as fields do when they have focus. (AFAICT on the Mac buttons can't
actually _get_ focus.)

 
>|> a[!href]
>|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.

I am only proposing two, and one 'doesn't count'.

The syntax proposed for the pseudo-classes is simply to use the current
syntax, with the english word 'not' prefixed. This is not 'new syntax' per
se, it's a whole set of new pseudo-classes (which are all negligably easy
to implement, since they are just negating a test that already exists.)

The only really new syntax I am proposing is for the attribute selectors,
the exclamation mark prefix.


> 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.

The :subject pseudo-... is an abdomination. It is not a pseudo-class (it
doesn't "match" anything). It has no scope for extending its syntax so
that in future levels of CSS it can be used in more complex selectors. And
it overloads the pseudo-class syntax with extra semantics that _parsers_
must be aware of in the same draft that gives pseudo-elements a different
syntax to ease the burden on parse-time error checking. [1]

That :matches() pseudo-class solves all of these problems:

   :matches(SELECTOR) - at its simplest, matches elements if the
   selector so far with SELECTOR appended to it would match that
   element or one of its descendants.

     H1:matches(+P)
     matches H1s that are followed by paragraphs

     BODY:matches(BLOCKQUOTE P IMG.signature)
     matches BODY elements that contain one or more BLOCKQUOTEs
     containing a P containing an IMG element of class "signature".

     P:matches(:focus) 
     matches paragraphs that have a child with the focus.

   NOTE: I suggest that in the initial specification of :matches(),
   this selector must be the last selector in the chain. This makes it
   directly equivalent to the :subject selector in the CSS3 Selectors
   WD, with the only syntactic differences being the brackets:

     X:subject A
     X:matches(A)

   Then, in later specifications, the :matches() pseudo-class can be
   extended to allow it to appear anywhere in a selector:

     X:matches(A) B

   ...which cannot be done using the :subject pseudo-thing.

   This means that the initial implementation burden on implementors
   is no greater for :subject as for :matches, and should thus remove
   must objections.


[1] since  a:subject b:subject  is illegal.

-- 
Ian Hickson                                     )\     _. - ._.)       fL
Netscape, Standards Compliance QA              /. `- '  (  `--'
+1 650 937 6593                                `- , ) -  > ) \
irc.mozilla.org:Hixie _________________________  (.' \) (.' -' __________

Received on Friday, 6 October 2000 23:31:08 UTC