Is it still necessary for a UA to preserve some aspects of form controls even if the `appearance` is `none`?
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 4.9k
- Forks
- 816
- PR merge metrics
- PR metrics pending
Description
User Interface Module Level 4 has the following statements:
However, the UA must preserve aspects of the form control which are necessary to operate the control with its original semantics. This does not include aspects of a control which are merely needed to observe the state the control is in, only those that are needed for the user to be able to modify the state of the control. The UA may however give them a different look and feel as long as it remains possible to operate the control. For example, the slider of an
input type=rangeis preserved (or replaced by an equivalent mechanism) even if appearance is none as it would otherwise not be possible to change the value of the range with the mouse or touchscreen.
The statements aren't true any longer, as a slider of an input element is now possible to be elegantly represented and operated, without writing a hacky click listener for the input element itself or creating a hacky element in the document for its slider(It can now be done by applying attr() to a ::before or ::after pseudo-element to represent the slider button, and utilizing Shadow DOM to create a transparent stacking context above the real control to deal with operations).
Also, I cannot think of a control which has original semantics outside of its attributes so it must rely on the platform to render; or I am happy to be proven wrong if somebody gives an example of a controls of such kind.
And further, in theory, the "preservation" statments underdefine the appearance of every control whose appearance is none would possibly be(unless the spec clearly enumrates all the preservation senarios).
So I would like to suggest the spec drops the "preservation" statments, because it's not necessary any longer(we can represent them with new standards), authors needs to be garanteed that they really completely manage representation of any control on which they set appearance to none.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the CSS UI Level 4 definition of appearance, especially the preservation statements and the input type=range example. Compare the proposed ::before/::after, attr(), and Shadow DOM approach with other form controls, then document whether the preservation language should be removed or clarified and provide any counterexamples.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css
- Domain
- web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100