- 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
Crissov has just created a new issue for
https://github.com/w3c/csswg-drafts:
== [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
2015](https://lists.w3.org/Archives/Public/www-style/2015Nov/0009.html)
and cites a post by @alastc from [January
2007](https://lists.w3.org/Archives/Public/www-style/2007Jan/0080.html).
I’ve provided an overview of more or less intuitive operands in
[April
2011](https://lists.w3.org/Archives/Public/www-style/2011Apr/0817.html)
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
account
Received on Thursday, 28 July 2016 16:34:08 UTC