Open Crissov opened 8 years ago
Another useful attribute value selector would be in list, although this is already possible to express more verbosely:
[foo=bar], [foo=baz]
[foo,=bar,baz]
#6042To numerically compare attribute values today, authors can work around this by:
data-*
attributes.[attribute~=value]
) on those data-*
attributes.I’ve detailed this nasty and cumbersome hack back in the day over at https://www.bram.us/2016/10/13/css-attribute-value-less-than-greater-than-equals-selectors/.
With the security considerations #5092 and type hints in attr()
being refined #10437 and therefore possibly soon finally becoming available in browsers, I believe more advanced attribute selectors will gain more demand from authors, so this ancient topic (and several similar ones linking to it) should be reevaluated in a timely manner.
The CSS WG Wiki already mentions numeric comparisons of attribute values for Selectors Level 4 (or 5). @LeaVerou brought it back up in November 2015 and cites a post by @alastc from January 2007. I’ve provided an overview of more or less intuitive operands in April 2011 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 matchWe also have the
i
modifier suffix 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 anythingThe 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 treat2016-07-28
as 1981 or28/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
.