[cssom-view] Define additional feature names
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 4.9k
- Forks
- 816
- PR merge metrics
- PR metrics pending
Description
https://drafts.csswg.org/cssom-view/#the-features-argument-to-the-open()-method
See the thread at https://github.com/whatwg/html/issues/2464.
Note also the conversation at https://github.com/whatwg/html/issues/1902#issuecomment-335220972 though. In particular, it seems that passing features at all (even if invalid) ought to trigger a different code path from passing no features. I don't see that reflected in the current algorithm.
Furthermore, given that some of these features impact the BarProp attributes, it seems these should either move to CSSOM View as well or perhaps we should define all in HTML?
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
Start with the CSSOM View section on the features argument to open(), then read the linked WHATWG HTML issues 2464 and 1902. Resolve which feature names and algorithm paths are needed, including the distinction between invalid features and no features, and decide where BarProp-related definitions belong. Done means the specification ownership and behavior are agreed and reflected consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css, html
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100