Re: [csswg-drafts] [css-shadow-parts] make clear that Shadow Parts for built-in elements should not be supported without standardization (#3674)

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> Topic: make clear that Shadow Parts for built-in elements should not be supported without standardization<br>
&lt;emilio> github: https://github.com/w3c/csswg-drafts/issues/3674<br>
&lt;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<br>
&lt;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<br>
&lt;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.<br>
&lt;fantasai> heycam: I like that theis psec doesn't talk about built-in file controls<br>
&lt;florian> I fully agree with heycam<br>
&lt;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<br>
&lt;Rossen> s/theis psec/the spsec/<br>
&lt;fantasai> TabAtkins: I accept the change on behalf of fergal<br>
&lt;fantasai> heycam: Unless ppl have plans to start exposing things through ::part()...?<br>
&lt;tantek> +1<br>
&lt;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<br>
&lt;fantasai> AmeliaBR: Is the invalidity rule such that ::part() is always valid regardless of arg?<br>
&lt;fantasai> TabAtkins: As long as syntax matches what's syntactically allowed it's valid<br>
&lt;fantasai> AmeliaBR: So if someone watned to test out a prefixed part, it'll be a nicer flow for authors to build on<br>
&lt;fantasai> AmeliaBR: Agree that ppl shouldn't ship experimental things until there's a standardization discussion<br>
&lt;fantasai> AmeliaBR: In some cases maybe we'll say, your datepicker is so specialized that you should have a prefixed part?<br>
&lt;fantasai> TabAtkins: Yeah, fine to do, because syntax space is wide open<br>
&lt;fantasai> RESOLVED: Add such a note -- no exposing parts of form controls without standardization<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3674#issuecomment-467569382 using your GitHub account

Received on Tuesday, 26 February 2019 19:04:53 UTC