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

[heycam]

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.

[css-meeting-bot]

The CSS Working Group just discussed make clear that Shadow Parts for built-in elements should not be supported without standardization, and agreed to the following:

• RESOLVED: Add such a note -- no exposing parts of form controls without standardization

The full IRC log of that discussion

<emilio> Topic: make clear that Shadow Parts for built-in elements should not be supported without standardization
<emilio> github: https://github.com//issues/3674
<fantasai> heycam: This is a small request, we had a request internally to make it clear that the ::part pseudo-element is not a kind of free-for-all extension point for engines to expose parts of built-in form control elements
<fantasai> heycam: There was soem concern in the past that engines were happy to expose parts of form controls through pseudo-elements, and of course that's a big compat problem for us, maybe others
<fantasai> heycam: We don't want to repeat with env(), which also takes an ident, and we ended upw ith things being implemented that we then had to implement and then spec afterwards, which is the reverse of the standards process.
<fantasai> heycam: I like that theis psec doesn't talk about built-in file controls
<florian> I fully agree with heycam
<fantasai> heycam: But it's an attractive bit of syntax for exposing this stuff, so we'd appreciate a note in the spec that this isn't to be used to expose parts of standard form controls until we go through the normal standards process
<Rossen> s/theis psec/the spsec/
<fantasai> TabAtkins: I accept the change on behalf of fergal
<fantasai> heycam: Unless ppl have plans to start exposing things through ::part()...?
<tantek> +1
<fantasai> AmeliaBR: Questions from authoring side. One of big complaitns with all fo the custom pseudo-elements was that it messed up your selector and you had to have separate ruels for every browser
<fantasai> AmeliaBR: Is the invalidity rule such that ::part() is always valid regardless of arg?
<fantasai> TabAtkins: As long as syntax matches what's syntactically allowed it's valid
<fantasai> AmeliaBR: So if someone watned to test out a prefixed part, it'll be a nicer flow for authors to build on
<fantasai> AmeliaBR: Agree that ppl shouldn't ship experimental things until there's a standardization discussion
<fantasai> AmeliaBR: In some cases maybe we'll say, your datepicker is so specialized that you should have a prefixed part?
<fantasai> TabAtkins: Yeah, fine to do, because syntax space is wide open
<fantasai> RESOLVED: Add such a note -- no exposing parts of form controls without standardization

[dbaron]

For the record, in #9951 we effectively decided not to do any such standardization, but instead to make new pseudo-elements.