Csswg-drafts: [selectors] :user-error or :user-invalid?

Created on 6 May 2017  路  7Comments  路  Source: w3c/csswg-drafts

Selectors spec sometimes uses :user-error and sometimes :user-invalid, presumably to refer to the same thing.

2. Selectors Overview

| Pattern | Represents | Section | Level |
|---------|------------|---------|-------|
| E:user-error | a user-altered user-input element E with incorrect input (invalid, out-of-range, omitted-but-required) | 搂12.3.4 The User-interaction Pseudo-class: :user-invalid | 4 |

12.3.4 The User-interaction Pseudo-class: :user-invalid (https://drafts.csswg.org/selectors/#user-error-pseudo)

The :user-invalid pseudo-class represents an element with incorrect input, but only after the user has significantly interacted with it. The :user-error pseudo-class must match [...] For example, a UA may choose to have :user-error match [...]

Example 38
For example, the input in the following document fragment [...] won鈥檛 match :user-error [...]

搂 Terms defined by this specification

:user-invalid, in 搂12.3.4

This problem was noticed in #579, which was closed by mistake, so I'm posting this new issue so that it's not lost. Feel free to close this and reopen the old one.

Closed Accepted as Obvious Bugfix selectors-4

All 7 comments

They were definitely meant to refer to the same thing, but it seems that choosing the right name for it was problematic from the very beginning (https://lists.w3.org/Archives/Public/www-style/2012Aug/0749.html). IIRC, at some point there was another discussion about renaming it, but I can't find the link. Maybe the current state of the section is the result of the attempt of such renaming that wasn't finished?

But I found a similar question in the www-style maillist: https://lists.w3.org/Archives/Public/www-style/2016Jun/0166.html.

They were meant to be different per the discussion in https://lists.w3.org/Archives/Public/www-style/2012Aug/0749.html

However that was five years ago, and since, I don't think the concept of :user-error has made any progress (no implementations AFAIK), whereas :user-invalid has been long prototyped (and used) in Firefox as :-moz-ui-invalid for many years https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-ui-invalid

Thus at this point, we should wrap-up selectors-4 with :user-invalid, and remove / postpone any separate :user-error for a future draft.

@tantek, the discussion you link to is about a distinction between :user-error and :user-interacted, and we decided not to take your suggestion for adding the latter. The resolution then describes adding :user-error as equivalent to :-moz-ui-invalid. So I don't understand your comment...

(Fwiw, the reason Tab and I suggested :user-error rather than :user-invalid was because :invalid doesn't handle requiredness, whereas this pseudo-class--as described on MDN for :-moz-ui-invalid--does.)

Given the leeway in when this is allowed to match it's tricky to write tests for this. Are there any cases where everyone agrees that it should match, so that tests can be written for that at least? For example, typing at least one character and then moving the focus to another input element?

Anyway, a test to check for being supported at all was simple, review appreciated: https://github.com/w3c/web-platform-tests/pull/8899

Context: me looking at a normative spec change without tests every week this quarter.

@foolip Yes, I think your example counts. :) It's a judgement call, but that doesn't mean we can't test it: we pick a reasonable interpretation, and if a UA fails because it disagrees with that reasoning it can argue for the test to be altered. Otherwise it needs to pass it. ;)

As for the PR: parsing support tests are dangerous when there is no corresponding functional test. It encourages browsers to support parsing without supporting the function--it's been a problem in the past, and it seriously breaks CSS's forwards-compatible parsing invariants.

Was this page helpful?
0 / 5 - 0 ratings