Hey all, Note: If future versions of this API re-use the Element.prototype.setHTML method in new ways, there may be potential for breakage. Transcend ships a popular client-side firewall tool called airgap.js that regulates (wraps) setHTML. We don't plan to unship this integration soon and even if we did, our customers choose when to upgrade their airgap.js SDK version. We regulate setHTML as it is a unique network sink by itself, and thus is in need of our network regulation controls.
Eli On Wednesday, August 30, 2023 at 9:19:52 AM UTC-7 Alex Russell wrote: > Hey all, > > We had a long conversation about this in today's API OWNERS meeting, and > per my previous note, I'm going to LGTM3 this with conditions because: > > - Usage is low, but growing > - The spec changes have been merged into HTML, reducing risk for > moving to the new API somewhat > - While we could require compatible additions only, and I think that's > the better path, that's a policy question for Chris Wilson or Jeff Yasskin > (cc'd) as I'm not your Standards TL > > On conditions, there is still a diversity of views around how to proceed. > I'm not inclinded to allow the new spelling of this feature to ship without > significantly less risk than last time, and that may mean that we may ask > you put the new design into OT until other vendors' implementations hit > stable (assumign you'd like to make it simultaneously available as other > vendors ship). > > Obviously, I dislike this as it hands the pen to vendors who weren't > willing to engage in the design early enough to prevent this sort of > bikeshedding in the first place. You'll need to be prepared for a longer > dicussion about how to proceed at I2E/I2S time for the replacement. For > continuity's sake, I'd also encourage y'all to get an OT for the new design > into place ASAP so that sites that depended on the old design can migrate > while we sort out the ship plan in conversation. > > Best, > > Alex > > On Wednesday, August 23, 2023 at 8:00:01 AM UTC-7 Jack J wrote: > >> > Adding in Jack as the author of the mentioned article at >> https://web.dev/sanitizer/. It might be worthwhile to add a big red >> warning aside. >> Yes, It's easy for me to add red warning to article "do not use". But we >> need more concrete details for developer. >> >> Is this deprecation will have Deprecation Trials ? It would provide >> detailed insight into the actual usage of the API in the real world. >> It also provide transition period for API user, and once problems are >> found that cannot be ignored, the plan itself will need to be changed. >> >> If deprecation trial will happen, we'd need to write one more article >> about it like below >> "Breaking change for Sanitizer API and what you need to do" >> - what happening on current API >> - why it's deprecated >> - how / where to transition >> - OT plan schedule >> - when the new API coming >> - etc >> >> Old article will have link to New article in red warning. Only a link to >> this I2D would not be sufficient. >> >> Jack >> >> On Wednesday, August 23, 2023 at 3:17:40 AM UTC+9 Rick Byers wrote: >> >>> Note that our compat principles >>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.x5bhg5grhfeo> >>> >>> say "Generally we avoid breaking any use cases which cannot be shown to >>> have a reasonable alternate implementation". While 0.000000492% is tiny, >>> it's still non-zero. Is it possible that there's some real-world site >>> benefiting from this API? I suppose the fallback of a JS library isn't that >>> much worse, so perhaps we're OK from a "reasonable alternate >>> implementation" perspective. >>> >>> I also want to get to an interoperable implementation quickly and am >>> more supportive than Alex is of the idea that API shapes sometimes need to >>> change to get to consensus. Our compat principles >>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.enldekz90vw> >>> >>> also say "Sometimes Blink chooses explicitly to ship despite higher interop >>> risk, and we accept responsibility for that risk by being more willing to >>> take on compat risk in the future if the consensus of the web platform >>> community is that the API should change.". >>> >>> But, like Alex, I also don't like the precedent of unshipping an >>> imperfect API while the replacement is still under design debate and also >>> not shipped in any other engine. Typically the above principle is used to >>> apply after some other engine has shipped an API they feel is better, and >>> we move to it in the name of interop. How quickly do we think we could ship >>> the new API and Frederik, do you have a timeline for when you think Firefox >>> might be able to ship it too? To what extent would it increase the >>> engineering costs for your team Daniel to have both forms shipping >>> simultaneously vs. removing the old one prior to shipping the new one? >>> >>> Is this >>> <https://chromestatus.com/metrics/feature/timeline/popularity/3814> the >>> right graph for the Sanitizer API UseCounter? Other than a temporary bump >>> (one popular site perhaps?) it doesn't seem to be growing too quickly >>> despite being in Chrome for a year. If we're actually on a near-term path >>> to consensus and multi-engine support, would a couple more months of the >>> old API existing really add much risk? If usage is non-zero (regardless how >>> small) I always think it's a more defensible position with web developers >>> to say we're removing something because a better alternative has shipped in >>> Chrome for at least one milestone (even if "better" is mostly limited to >>> "likely to also have support in Firefox"). >>> >>> Rick >>> >>> On Tue, Aug 22, 2023 at 6:54 AM Yoav Weiss <[email protected]> wrote: >>> >> LGTM2 >>>> >>>> On Mon, Aug 21, 2023 at 6:17 PM Chris Harrelson <[email protected]> >>>> wrote: >>>> >>> LGTM1 to remove in favor of a revised, interoperable AIP in the future. >>>>> >>>>> On Mon, Aug 21, 2023 at 6:38 AM 'Daniel Vogelheim' via blink-dev < >>>>> [email protected]> wrote: >>>>> >>>> Hi Luke & Thomas, >>>>>> >>>>>> On Wed, Aug 16, 2023 at 12:49 PM Thomas Steiner <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Adding in Jack as the author of the mentioned article at >>>>>>> https://web.dev/sanitizer/. It might be worthwhile to add a big red >>>>>>> warning aside. >>>>>>> >>>>>>> On Tue, Aug 15, 2023, 23:37 Luke <[email protected]> wrote: >>>>>>> >>>>>>>> Just to chime in here. If there's a chance this API is going to be >>>>>>>> removed or even heavily changed its potentially worth making an effort >>>>>>>> to >>>>>>>> take down any documentation regarding it to try to prevent any chance >>>>>>>> of >>>>>>>> its usage going up. For example the mdn page on it seems an easy one >>>>>>>> to >>>>>>>> remove. Likewise the web.dev article. This may not be as important >>>>>>>> if the usage is far below any thresholds. >>>>>>>> >>>>>>> >>>>>> Yes, noted and agreed. Adjusting or even removing the docs has come >>>>>> up before, and I hesitated to act on it because we didn't yet have >>>>>> clarity >>>>>> on how to proceed with the Sanitizer API. The reason for writing this >>>>>> intent-to-deprecate is to get agreement on how to proceed, and to decide >>>>>> whether we'll keep supporting the current API in the future or not. If >>>>>> it's >>>>>> okay with you, I'd like to let this discussion run its course, and then >>>>>> adjust the docs depending on how api owners have decided here. >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>> >>>>> >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMrdkH5Br_useiWyt3b8gXVWkzYi9tdL2DSJ9MTwefTjA%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMrdkH5Br_useiWyt3b8gXVWkzYi9tdL2DSJ9MTwefTjA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> 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 [email protected]. >>>> >>>> >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_bxEMv20aYBqJoquxdty_2_-6EnszXipt1CP6MN7LqWQ%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_bxEMv20aYBqJoquxdty_2_-6EnszXipt1CP6MN7LqWQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVNC%2BqEMqMQ1UofPsN23_34y9kEc8MoZtJXLG_rQib%3D3g%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVNC%2BqEMqMQ1UofPsN23_34y9kEc8MoZtJXLG_rQib%3D3g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7ce6edff-7738-497a-aecb-56c8213939e9n%40chromium.org.
