Re: small selector syntax addition

Ian Hickson wrote:
> 
> fantasai wrote:
> >>
> >> 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.

No, it's not a problem because it appears in a completely
different context. Every character within the property-value
list has a different significance than in the selector space
before the braces; you might as well be using a different
language, for all the similarity between the two syntaxes.

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

I don't understand what you mean by this.

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

I separated spaces and symbols because spaces are more easily
distinguished from all other characters than any other two
characters from each other. You can detect that a hash is
surrounded by spaces faster than that it is surrounded by any
other given character. It's also quicker to discern a character
to be one of the letters than one of three arbitrarily given
symbols. The latter grouping is ingrained over years of reading,
and while symbols as a group are likewise distinguished, that
particular set of three is not.

What's your hypothesis?
 
> > 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.)

Perl doesn't look scary because it has so many different
characters. It looks scary because it has so many characters.
I doubt it would look so intimidating if variables weren't
prefixed with a symbol, but were instead declared once with
the symbol before use. (Yes, I know that wouldn't work with
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.

The anchor, then. s/subject/anchor/

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

You're thinking as a coder, that's why. Try thinking like a
novice CSS user--a non-programmer who uses the language with
a reference tutorial and who doesn't read the specification,
much less analyze it. Explain the situation to someone who's
not technically involved with computers and see what they
think about using the same symbol to express two different,
unrelated concepts in the same "sentence".

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

If you say so. It's always looked like a piece of wire gauze to me.
(This is like that psychiatrist's game with the blobs. What do you
see?)

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

Not to imply the meaning or behavior of something, yes.
But you're specifying details of the implementation. Why
shouldn't I be able to implement :matches() by selecting
random nodes from the tree and making tables instead of
walking the tree like a sane programmer? And you're only
specifying this for patterns after the anchor, not before,
which is oddly inconsistent.

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

See bottom.

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

What bothers you about Lisp's looks? Do you have an aversion
to parentheses? (How about some sample annoying code here?)

> Similarly, I have opted to not use some features of Perl
> in my projects because they look awful.
> 
> > > I think [A:has( + B)] looks better than A:matches(# + B).
> >
> > If you analyze your sentence there and explain -why- it
> > looks better, then you'd have an argument.
> 
> It's subjective, as you said.

I said whether a character looks like something or not is
subjective. I didn't say that your affinity for a
particular syntax is necessarily subjective.

Look over my arguments. I could have said my affinity for
the $a > .b:matches(c,d) type of syntax is subjective--
which it very well may be, in some measure--but have I not
provided at least some objective backing for every aspect
of this preference? If you are being purely subjective,
then why insist on bloating the language with :has()?

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

Yes, but parts of its syntax have a striking resemblance
to the syntax of common programming languages, even to
the point of having similar concepts relating to those
parts of the syntax. It is thus, in many aspects of its
syntax, analogous to 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?

Right. Extra processing. To what purpose? Clarifying
the concept of a selector with an anchor by hiding
the anchor?

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

Oh, it is? I didn't know that. So a:matches(b > .c +) would match

<b>
  <q class="c"/>
  <a>this node</a>
</b>

?

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

:has(b) actually doesn't bother me, except insofar as it is redundant.
It's when you extend it to other relationships with those dangling 
combinators that I begin to revile the idea. :has(sibling, a) or
something like that wouldn't bother me so much (although I don't see
the point).

Received on Tuesday, 18 June 2002 15:03:21 UTC