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

31 views
Skip to first unread message

Chris Harrelson

unread,
Aug 24, 2020, 7:08:01 PM8/24/20
to blink-api-owners-discuss
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

unread,
Aug 27, 2020, 5:34:23 PM8/27/20
to blink-api-owners-discuss
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

unread,
Sep 2, 2020, 1:45:48 AM9/2/20
to Chris Harrelson, blink-api-owners-discuss
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

unread,
Sep 10, 2020, 8:59:40 PM9/10/20
to TAMURA, Kent, Alex Russell, blink-api-owners-discuss
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

unread,
Sep 14, 2020, 7:19:01 AM9/14/20
to Chris Harrelson, TAMURA, Kent, Alex Russell, blink-api-owners-discuss
One comment: For TC39 stage 3 features, IMO there's no need for a TAG review, even if we're the first to ship.

Reply all
Reply to author
Forward
0 new messages