RE: Selector Readabiliitiy [WAS: Backwards compatibility of new

On Thursday, December 04, 1997 9:24 AM, Neil St.Laurent 
[SMTP:neil@bigpic.com] wrote:
> Is there any reason why this overloading is a problem?

As an interface/readability issue, yes. Overloading the meaning of a symbol 
means the specific meaning of mean of an instant must be derived solely 
form the context the language.  This may be fine for a computer, which 
probably treats the context as a state, but people don't make good state 
machines. It is even unlikely there reading it completely linearly.

> >  DIV.sect / //H2/ ~ P /
>
> This doesn't have any ambiguity as far as I can see since /H2/ has no
> meaning, it can only be seen as //H2/ and thus the remaining /'s
> correspond well.

I didn't mean to imply ambiguity. And looking back, 'impossible' was a huge 
over exaggeration.  Difficult. It adds a unneeded complexity to the parser. 
But maybe I'm just clueless (as I haven't taken a compiler class yet). At 
minimum there can be trouble with people parsing it, hence readability.

> >  /MATH ~P/ {...}
> >  /H1 ~H2/ {...}
> >  DIV ~//P/ {...}
>
> That makes it appear as a unary operator instead, and isn't quite as
> clean.

Clean it what way?

> Addressing pseudo elements, while it may seem logical  to use pseduo
> elements to denote first, last, or otherwise, it isn't as clean as
> arelationship based system as proposed.  And also note that a
> pseudo-element is an ELEMENT and cannot be used on selectors:



> /H1 ~ //P/ / { ... }
> is ?equivalent to?

Doesn't make sense because H1 is implicitly before the P as a sibling. 
Probably closer to your intent would be:

H1:first ~P {...}

> /H1 ~ //P EM/ / { ... }
> can't be represented with a pseudo element first-child.

It isn't even apparent this is possible from the specification since it 
does not use any examples with multiple selectors in the 'first' notation 
or explicitly say this is allowed.  My assume from that was it was not. 
Admittedly, this is not possible in my idea.

> Not to be annoying but that seems very cryptic in nature, more like C
> code than a human readable CSS file.

And the CSS-2 spec is any better?!?!?!?

> Your operators would REQUIRE the introduction of bracketed
> subexerpsions:
>
> H1 ~(DIV P)
> as opposed to
> /H1 ~ /DIV P//
> or whatever.

How is your expression any different than:

H1 ~DIV P /* P descendants of a DIV child of H1. Awkward, but whatever... 
*/

Even so, at least then you aren't change the standard meaning of a 
parenthesis.  Personally, I have no problem with that.

> Plus using those unary like operators precludes syntax like:
>
> H1 ~ P ~ B ~ EM
> which is very clear in the current model as to what is means.

The only change I recommended with regards to the tilde was with respect to 
spacing. So:

H1 ~P ~B ~EM

Would mean the same thing (although it doesn't make much sense to have a P 
child of H1, IMO)


Andrew n marshall
  student - artist - programmer
    http://www.media-electronica.com/anm-bin/anm
      "Everyone a mentor,  Everyone a pupil"

Received on Thursday, 4 December 1997 16:02:52 UTC