On Wed, Nov 1, 2023 at 2:41 AM Elijah Grey <[email protected]> wrote:
> 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. > Thanks for the note. I expect the future setHTML to follow the current Sanitizer explainer <https://github.com/WICG/sanitizer-api/blob/main/explainer.md>, and to be quite similar to the one we now remove. While I don't fully understand your use case, I suspect you can treat them largely the same. That said, I understand there's a risk to this. 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/CALG6KPORegoUYwJ5wB%3DaWuiQaPdu6vPjNh%2B2cV%3DQZx7Bbt8ymQ%40mail.gmail.com.
