Conditions for skipping TAG review on an intent-to-prototype

[Chris Harrelson]

There were some offline discussions about this, but on reflection I wonder if there is a relatively simple decision tree that we can try out. How about this:

If your feature meets these conditions, a TAG review can be skipped:

* The feature is already specified by a standards body 

* The feature is shipped in at least one other browser, or the feature is already more-or-less shipped in Chrome and this is just fixing it to improve spec compliance or correctness, or the feature is a new or improved syntax for an existing feature

Otherwise you need to submit a TAG review.

Hypothetical examples that don't need TAG:

1. Shipping colors: super-bright, where Firefox already shipped it and it's in a spec.

2. Unprefixing colors: -webkit-super-bright where there is a colors: super-bright spec that is basically the same as -webkit-super-bright, and no other browser implements it.

3. Fixing a corner case of colors: super-bright to improve interop or spec compliance

4. Shipping colors: super-duper-bright because the spec body decided that's better than colors: super-bright and the latter is already shipped in at least one browser.

However you'd need a TAG review in this situation:

1. Shipping colors: super-bright because the CSSWG agreed to put in a spec, and colors: super-bright is only 20 lines of code that bumps up brightness by 10%. TAG review is required here because it has not shipped in any browser.

I added this example because it seems one where there would be disagreement about whether a TAG review in this case is a waste of time.

Chris

[Chris Harrelson]

I think the intent sent today (Intent to Prototype: Add support for CSS properties "overflow: clip" and "overflow-clip-margin") is a good testcase for this discussion. It's something where (a) there is a thing that has been in a CSSWG spec for a while (overflow:clip in particular) and there is an addition of a "small" thing to control the margin of the clip. Firefox is also about to ship overflow:clip.

The intent currently does not include a TAG review..

[TAMURA, Kent]

Thank you for the draft decision tree.

On Tue, Aug 25, 2020 at 8:08 AM Chris Harrelson <chri...@chromium.org> wrote:

There were some offline discussions about this, but on reflection I wonder if there is a relatively simple decision tree that we can try out. How about this:

If your feature meets these conditions, a TAG review can be skipped:

* The feature is already specified by a standards body 

* The feature is shipped in at least one other browser, or the feature is already more-or-less shipped in Chrome and this is just fixing it to improve spec compliance or correctness, or the feature is a new or improved syntax for an existing feature

This sounds reasonable.

Does a TAG review work well for a feature removal?

 

Otherwise you need to submit a TAG review.

Hypothetical examples that don't need TAG:

1. Shipping colors: super-bright, where Firefox already shipped it and it's in a spec.

2. Unprefixing colors: -webkit-super-bright where there is a colors: super-bright spec that is basically the same as -webkit-super-bright, and no other browser implements it.

3. Fixing a corner case of colors: super-bright to improve interop or spec compliance

4. Shipping colors: super-duper-bright because the spec body decided that's better than colors: super-bright and the latter is already shipped in at least one browser.

However you'd need a TAG review in this situation:

1. Shipping colors: super-bright because the CSSWG agreed to put in a spec, and colors: super-bright is only 20 lines of code that bumps up brightness by 10%. TAG review is required here because it has not shipped in any browser.

I added this example because it seems one where there would be disagreement about whether a TAG review in this case is a waste of time.

These examples are very helpful. We should publish them!

 

Chris

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZsLhZU3MkbKPh%3DTS30gz5jzULd0%3DnWY6PTOaG_NKSjzXg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Chris Harrelson]

On Tue, Sep 1, 2020 at 10:45 PM TAMURA, Kent <tk...@chromium.org> wrote:

Thank you for the draft decision tree.

On Tue, Aug 25, 2020 at 8:08 AM Chris Harrelson <chri...@chromium.org> wrote:

There were some offline discussions about this, but on reflection I wonder if there is a relatively simple decision tree that we can try out. How about this:

If your feature meets these conditions, a TAG review can be skipped:

* The feature is already specified by a standards body 

* The feature is shipped in at least one other browser, or the feature is already more-or-less shipped in Chrome and this is just fixing it to improve spec compliance or correctness, or the feature is a new or improved syntax for an existing feature

This sounds reasonable.

Does a TAG review work well for a feature removal?

I don't think a TAG review is needed for a pure feature removal. Can anyone think of a reason to want that?

 

Otherwise you need to submit a TAG review.

Hypothetical examples that don't need TAG:

1. Shipping colors: super-bright, where Firefox already shipped it and it's in a spec.

2. Unprefixing colors: -webkit-super-bright where there is a colors: super-bright spec that is basically the same as -webkit-super-bright, and no other browser implements it.

3. Fixing a corner case of colors: super-bright to improve interop or spec compliance

4. Shipping colors: super-duper-bright because the spec body decided that's better than colors: super-bright and the latter is already shipped in at least one browser.

However you'd need a TAG review in this situation:

1. Shipping colors: super-bright because the CSSWG agreed to put in a spec, and colors: super-bright is only 20 lines of code that bumps up brightness by 10%. TAG review is required here because it has not shipped in any browser.

I added this example because it seems one where there would be disagreement about whether a TAG review in this case is a waste of time.

These examples are very helpful. We should publish them!

At the API owner meeting today, we discussed the underlying issue quite a bit. +Alex Russell is going to write up some text and share it around.

[Yoav Weiss]

One comment: For TC39 stage 3 features, IMO there's no need for a TAG review, even if we're the first to ship.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZtqn9WCExYopyDsebWDYbVeiRRcnE4SMO9AVvrf%2Bym85w%40mail.gmail.com.