W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2016

[csswg-drafts] [Selectors] Numeric or Typed Attribute Value and Pseudo Attribute Selectors

From: Christoph Päper via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 Jul 2016 16:33:54 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-168140285-1469723632-sysbot+gh@w3.org>
Crissov has just created a new issue for 

== [Selectors] Numeric or Typed Attribute Value and Pseudo Attribute 
Selectors ==
The [CSS WG Wiki](http://wiki.csswg.org/spec/selectors4) already 
mentions numeric comparisons of attribute values for [Selectors Level 
4](https://drafts.csswg.org/selectors-4/#attribute-selectors) (or 5). 
@LeaVerou brought it back up in [November 
 and cites a post by @alastc from [January 
 I’ve provided an overview of more or less intuitive operands in 
 which I will partially repeat below, so it gets properly tracked.

## Existing attribute selectors

As of 2016, attribute values are matched as (parts of) **character 
strings** only.

* `=` exact match

    We also have the [`i` modifier 
suffix](https://drafts.csswg.org/selectors-4/#attribute-case) for 
explicit case-insensitive comparisons. I would have liked it better if
 that would have been the default (despite host language conventions) 
and `==` would have been used for case-sensitive values; or if a colon
 indicated a case-insensitive “pseudo” value `=:`. Please, let’s *not*
 add more single-letter grep-like suffixes.

* `^=` starts with

* `$=` ends with

* `*=` contains

* `~=` in (space-separated) list

* `|=` exact or starts with followed by dash anything

    The pseudo-class `:lang()` already is more complex than what this 
similar attribute value operand  allows for.

## Proposed operands for attribute value selectors

Instead of complex `:not()` phrases, it would be handy to have 
**negated comparisons**, e.g.:
* `!=` or `=!` and `!==` or `==!` or `=!=`
* `!~=` or `~!=` or `~=!`
* `!|=` or `|!=` or `|=!`
*`!^=` or `^!=`  or `^=!`
* `!$=` or `$!=` or `$=!`
* `!*=` or `*!=` or `*=!`

As mentioned in the intro, others have already noted that it would be 
useful to have **numeric equality comparison** where ‘0’ = ‘0.0’ = 
‘.0’ = ‘00’ = `0x0` = ‘0e1’ = ‘’. Since we probably need to 
distinguish this from string comparisons explicitly, let’s just add 
another character:

* `#=` or
* `==` or
* `%=` if also  ‘0.5’ = ‘50%’

Numeric attribute selectors should be able to do simple **greater and 
lesser than comparisons**, of course. They’re not as useful for string
 comparisons, so we could spare the added character from above:

* `<`  = `!>=` or `=!>` but neither `>!=` nor `>=!`
* `>`  = `!<=` or `<!=` but neither `=!<` nor `<=!`
* ‘≤’: `<=` or `=<` = `!>`
* ‘≥’: `>=` or `=>` = `!<`

I don’t think we’d need `calc()`-like dynamic arithmetic expressions 
on either side of the operand, because authors should be able to 
adjust the static selector value accordingly, although some might want
 to specify rounding or precision. With step-based values, follows and
 precedes may be useful:

* ‘≺’: `<<` or `<=<` or `-=`
* ‘≻’: `>>` or `>=>` or `+=`

As has been correctly observed, not all such comparisons are between 
simple scalars. *Dates and times* can be converted to single numbers 
(e.g. in spreadsheet applications, Unix timestamps or Julian Day 
Numbers), but are usually expressed as tuples for human readability 
even in code (but at least usually within the same calendar system). 
Another case are strongly typed values with *units*, e.g. ‘25.4mm’ = 
‘1in’ = ‘72pt’ in CSS, and yet another are values with *multiple 
components* or channels like colors, e.g. ‘#FF0000’ = ‘red’.

Preferably, these should *just work* when using a single equals sign 
`=` and literal comparison would be invoked by doubling it `==` (or 
tripling `===` if `#=` wasn’t accepted), but I’m fine with the 
inverse, too. If another, different character was needed to mark a 
comparison as possibly involving unit or base conversion (i.e. opt-in 
and don’t treat `2016-07-28` as 1981 or `28/7/16` as 0.25), I’ve 
previously suggested the underscore, but I think pseudo-attributes 
would actually be more useful:

* `_=` etc.

A **boolean** or **binary logic attribute selector** could handle 
(case-insensitive) values like ‘yes’ = ‘true’ = ‘1’ = ‘on’ = 
_attribute-name_ and ‘no’ = ‘false’ = ‘0’ = ‘off’ = null, possibly 
depending on the host language:

* `?=`

## Pseudo-attribute selectors

I’ve previously mentioned an **assertion attribute selector** using 
`:=` that could be used to test whether a value would be legal, but I 
can’t come up with a use case for it. Sub-values are more realistic, 
e.g. `[color:red>50%]` or `[href:protocol=http]` and these could be 
generalized to pseudo-attribute selectors, e.g. `[:value]`, 
`[:datetime]`, `[:url]` or `[:class=foo]` == `.foo` and `[:name=foo]` 
or `[:ID=foo]` == `#foo`.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/354 using your GitHub 
Received on Thursday, 28 July 2016 16:34:08 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:00 UTC