On Wed, Aug 31, 2022 at 6:02 PM Alex Russell <slightly...@chromium.org> wrote:
> We discussed this at today's API OWNERs meeting and, while I realise I > should perhaps be directing most of these comments at the CSS WG more > broadly, I'm concerned that the bundle of features that this function is > designed to support are not clearly articulated, which argues for an > explainer and perhaps a TAG review. > > Specifically: > > > - What problems do the "variations", "palettes", and "incremental" > values address? There should be clear enunciation of those issues in an > explainer, a discussion of considered alternatives, and example code > describing how this specfic design best meets those needs. > - Related, why is "tech()" overloaded for whatever those values do as > well as explict named technologies and sub-features? > - Since we're going first, and the only group that seems to have > looked at this is the CSS WG, shouldn't there be a TAG review? > > Dominik has updated <https://github.com/w3c/csswg-drafts/commit/abfb7674c5e74761d74e9f0bd710091c53e3e929> the explainer and as it turns out the original TAG review <https://github.com/w3ctag/design-reviews/issues/666> even covered this aspect under the older syntax. Given that, I don't think it's meaningful to ask the TAG about this again. Alex, would you agree in light of the new information? > The CSS WG continues to work outside of our incubation and explainer-based > model for feature development, and as a general matter it's not OK. > > I realise this feature is hostage to a bad work mode and it isn't the > developer's of this syntax's fault, but we need to break the cycle. > > Future CSS features that do not incubate, center developer feedback > (perhaps through OT), and show signs of incubation may also invoke delays > from me. > To avoid misattribution, this framing isn't something that the API owners jointly agreed to in the meeting. As for my 2c, our launch process <https://www.chromium.org/blink/launching-features/> doesn't require people to incubate outside of a WG, and indeed the "existing standard" path allows for additions/changes to existing specs in WGs, and this is very commonly how we ship new features. There's nothing preventing us or others from doing all the right things while doing the spec work in the CSSWG. Best regards, Philip -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdUKJUx8CEvK6yYHq7H-KD_Q1h6Brbz4G_i0ebZXLKC_w%40mail.gmail.com.
