Re: target-attr() and /reference combinator/ proposals

> >>    A /attribute/ B
> >> Is anyone violently disgusted by this combinator proposal?
> > At least there shouldn't be a space between A and /attribute/
>
> Why? This is a _combinator_, like "+" and ">", and whitespace is
> allowed around combinators:
>
>    A B
>    A + B
>    A > B
>    A ~ B
>    A /attr/ B

...So

C A /attr/ B

would match an element B that is pointed to by an element A,
and A has an ancestor C.


C (A /attr/ B)
- or -
A /attr/ (C B)

would match an element B that is pointed to by an element A,
and B has an ancestor C.


A:: /attr/ (C B)
A:matches(/attr/ (C B))

would match an element A that is points to an element B,
and B has an ancestor C.


(C:: A) /attr/ B
C:matches(A) /attr/ B

would match an element B that is pointed to by an element C,
and C has an descendant A.


(C:: A):: /attr/ B
(C:: /attr/ B):: A
C:matches(A):matches(/attr/ B)
C:matches(/attr/ B):matches(A)

would match an element C that is points to an element B,
and C has an descendant A.
(Here :matches() wins in clarity!)


C:: A /attr/ B
C:matches(A /attr/ B)

would match an element B that is pointed to by an element A,
and A has an ancestor C.


OK, I think I get it now. And indeed, :matches() is clearer than ::,
although I still think pseudo-elements should be different from
pseudo-classes, mainly becuase pseudo-elements can appear only once in a
selector. In fact, pseudo-elements have nothing to do with selecting, it's
about creating. I would like to see something like:

selector {
  color: green;
  @pseudo-element before {
    content: "[";
  }
  @pseudo-element after {
    content: "]";
  }
}

That's also because different pseudo-elements will be used together with the
same selector at the same time. (often both 'before' and 'after' will be
used f.e.)

Sjoerd

Received on Monday, 24 January 2000 17:28:02 UTC