Re: The attribute selectors [x|=a] and [x~=a]

On Wed, 15 Apr 1998, Ian Hickson wrote about the ~= and |= operators being
nasty design.

Jonathan Lang wrote:
>It could be made less dangerous by saying that the default seperator is
>whitespace (so [att=val], [att =val], [att= val], [att = val], etc. would
>all mean the same thing), while the seperator can be specifically set to a
>non-whitespace character (or possibly string) by prepending the desired
>seperator to the =.


That's a much better idea. In fact, we could do away with the exact match,
or use an altogether different construct for it.

Steven Pemberton wrote:
>Just to give you some insight into how the operators developed, the
>original suggestion was "==" for equality, and "=" for space separated
>lists.
Sensible so far, if not very extendible.

>However, it was felt that "==" was too geeky, so they were changed to
>"=" for equality (fair enough I think you'll agree),
Makes sense.

>and "~=" for space separated equality ("sort of equal").
This is where it starts to get dodgy.

But it's the next bit which scares me:
>Later there was a requirement to be able to match on language codes
>for the LANG attribute, which have the form "en" "en-uk" "en-us"
>"en-uk-cockney", and you want to be able to match on all LANGs that
>start "en", or "en-uk". So "|=" was introduced for this. Note that
>"|=" has an extra semantic property that the other two don't, namely
>that it matches case insensitively, so they aren't really a
>cooperating set of operators.

I still think there is a deep WRONGness about this almost adhoc design. It
doesn't "feel" right. (Am I the only one who thinks this? I'm getting kinda
worried it's something wrong with me!).

The attribute selector operator (note, singular) should be of extendible
design - even if only a limited set of seperators is allowed. For example a
syntax like this:

[att=(SEPERATOR,CASESENSITIVE,FROMSTARTONLY)="val"]

with seperator (a single character) defaulting to space, case sensitivity
defaulting to sensitive (Case is boolean, 1 or 0) and matching from the
start only defaulting to false (also boolean).

case sensitive item match in a space separated list (default): att=val
case insensitive item match at the start of a hyphen separated list:
att=(-,0,1)=val
case sensitive exact match (there is no seperator given): att=(,1)=val
case sensitive item match in a space separated list (explicitly stated):
att=(\20,1,0)=val

Now for what we can't yet do in the current scheme:
case insensitive item match in a carriage return separated list:
att=(\A,0)=val
case sensitive item match at the start of a slash separated list:
att=(/,0,1)=val

If you want it simplified, simply state that in CSS2 the only possible
combinations are
 =           equivalent to current ~=
 =(\20,0,0)= equivalent to current ~=
 =(,1)=      equivalent to current =
 =(-,0,1)=   equivalent to current |=

I'm just giving an idea here. I know it looks ugly, but lets face it, it's
more extendible than the current easy to learn but inherently unobvious and
dead end system.

Sorry if I've offended anyone, I'm just trying my hardest to help before it
becomes ratified... tomorrow...
--
Ian Hickson
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12   Info: www.geekcode.com
GIT/M/S d->-- s+: a--->? C++(+++)>$ U>*++++ P L+>+++++ E(+)>+++ W+++ N(+) o?
K? w@ O- !M V- PS+ PE- Y+ PGP>+ t 5+++>++++ X- R+(+++) tv b++(+++) DI++
D++(---)>++++ G>+++ e(*)>+++++ h!()(--) !r y?
------END GEEK CODE BLOCK------

Received on Monday, 20 April 1998 17:07:07 UTC