w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.48k stars 659 forks source link

[Selectors] Numeric or Typed Attribute Value and Pseudo Attribute Selectors #354

Open Crissov opened 8 years ago

Crissov commented 8 years ago

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.

Instead of complex :not() phrases, it would be handy to have negated comparisons, e.g.:

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:

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:

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:

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:

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:

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.

Crissov commented 3 years ago

Another useful attribute value selector would be in list, although this is already possible to express more verbosely:

bramus commented 2 years ago

To numerically compare attribute values today, authors can work around this by:

  1. Injecting all the values that the item is not equal to, using data-* attributes.
  2. Using the CSS Attribute “Value Contains” Selector (e.g. [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/.

Crissov commented 1 week ago

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.