Re: small selector syntax addition

fantasai wrote:
> 
> Equivalency works both ways

If A is a subset of B, then items in A can be equivalent to items in B while 
items in B are not (all) equivalent to items in A.

But whatever.


>> It doesn't complicate parsing that much. If your sequence of simple
>> selectors consists of exactly '#' then you have the special symbol,
>> otherwise '#' will mean the start of an ID. Considering how trivial
>> that is, I don't think it's worth using a whole other symbol.
> 
> That may take care of the computer, but you missed the person.  A fluently
> literate person doesn't read by scanning each character one by one, like
> a computer, but picks up visual patterns in a not-strictly-linear
> fashion. # stands out, but it's already associated with IDs.

It's also associated with colours, but that's no problem.

People are cleverer than computers. A '#' on its own doesn't look like a hash. 
Like you say, humans don't scan by character. They scan the whole line at once.


>   # -> surrounded by space?
>         - yes -> subject indicator
>         - no -> followed by a-z? 
>                  - yes -> ID selector
>                  - no -> surrounded by ~, +, or >?
>                           - yes -> subject indicator
>                           - no -> invalid

That's not how humans work. At least, it's not how I and the humans I know work.


> Using different symbols is much less complicated and allows one to
> pick up either one faster and more easily.

Using different symbols adds to the complexity of the language by making it look 
  scary. That's not a good thing. (Think of what the typical reaction is to Perl.)


 > If they both referred to descriptors, it wouldn't be a big deal,
 > but the subject indicator is pivotal in determining the structure
 > of the selector and thus in understanding the expression.

In my version, it's not really a subject selector, not in the way that :subject, 
(...) and $ are. Within the :matches() argument nothing is being "selected", 
it's just a comparison against the document, anchored at one node.


> You've done some scripting with Perl, haven't you? Perl uses $ to
> indicate the start of a variable name.

It also uses @ and %. However, they are always followed by something, not used 
on their own. Which, to me at least, makes them totally different.


>> I just noticed that the '#' character also looks like a placeholder
>> more than a '$' character -- compare:
>>
>>    A:matches(B + # + C)
>>
>>    A:matches(B + $ + C)
> 
> 
> It does not look that way to me. This is a very subjective means of
> judgement, however.

The '#' is like a box. You fill the box in with the element on the outside of 
the :matches() element.


>> Where else does it say how to handle a '#' somewhere other than at the end?
> 
> It's implied.

We learned a long time ago not to leave stuff implied in CSS specs. People 
always manage to imply the wrong thing.


> All the other examples you give translate a more abstract,
> mathematical expression into English. I fail to see how ~implying~ '#' at
> the beginning of a selector makes it simpler or easier to understand.

    a:has(b)

...vs

    a:matches(# b)

The first looks closer to English to me.


Either way, if you don't like :has(), don't use it. It's just syntactic sugar.


> I think that how something "looks" is irrelevant to its superiority as
> a syntax.

I think how it looks is one of the key criteria. Lisp has a great syntax, 
technically speaking, but it doesn't _look_ good, and is one of the reasons I 
couldn't use Lisp for long term projects, despite the fact that it is in many 
respects a good language.

Similarly, I have opted to not use some features of Perl in my projects because 
they look awful.


 > If you analyze your sentence there and explain -why- it looks
> better, then you'd have an argument.

It's subjective, as you said.


> My reasoning for why it looks -bad- is as follows:
> In every programming language --

CSS is not a programming language.


> -- I have ever encountered (which, of course,
> is not so very many), the argument to a function is always a -complete-
> expression --  one which evaluates to an actual value, be it a number, or a
> string, or an aggregate of data, or a pointer to a memory location.

Or a string, which is then concatenated with another string and evaluated?


> Now, you can argue that the '#' is implied. Very well. If you are so keen
> on implying this vital piece of the expression, why should it not be
> implied at the beginning of any :matches() argument that begins with a
> combinator instead?

It's implied at the _end_ :matches().

And the common use case for :has() is with the ' ' combinator, so that

    :has(b)

...is equivalent to

    :matches(# b)

...which can't be distinguished from

    :matches(b)

...if you drop :has().


>>    p:has(strong)
> 
> Which encourages people to use that instead of p:has(>strong) even when
> the child selector would be more appropriate.

The child selector is rarely more appropriate in this case.

-- 
Ian Hickson
``The inability of a user agent to implement part of this specification due to
the limitations of a particular device (e.g., non interactive user agents will
probably not implement dynamic pseudo-classes because they make no sense
without interactivity) does not imply non-conformance.'' -- Selectors, Sec13

Received on Friday, 17 May 2002 04:48:15 UTC