w3c / w3c/csswg-drafts

[css-shadow-parts] make clear that Shadow Parts for built-in elements should not be supported without standardization

Open
#3,674 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Closed Accepted by CSSWG Resolution css-shadow-parts-1 Needs Edits
Dominant language
Bikeshed
Stars
4.9k
Forks
816
PR merge metrics
PR metrics pending

Description

https://drafts.csswg.org/css-shadow-parts/

The ::part() pseudo-element looks to be a natural syntax to use to expose access to bits of built-in HTML form controls, such as the button in an <input type=file>. We at Mozilla have a concern that this syntax will be used to expose parts of built-in elements (i.e. not custom element defined elements) without going through the standardization process. We have seen in the past that engines have readily exposed ::-webkit-* and ::-moz-* pseudo elements so that authors can style bits of built-in elements. Solving the HTML form element stylability problem is a big task, and we would like to avoid vendors exposing their built-in element internals through ::part() without discussion in an appropriate standards group. We request that a note be added to the spec clarifying that ::part() is not to be used as a general implementation defined extension mechanism, and that any exposure of built-in element parts should be done by going through the regular standardization process.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked CSS Shadow Parts draft, especially the section defining the ::part() pseudo-element and its intended scope. Add a note clarifying that built-in element parts should not be exposed through ::part() without regular standardization, then verify the wording fits the surrounding specification text.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, html
Domain
documentation, web-dev
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.