Thanks for the usage information. I'm still not happy with seeing more renaming, but given the low use, LGTM3.
On Wednesday, May 13, 2026 at 7:59:56 AM UTC-7 Daniel Bratell wrote: > Milestones are about to become 2 weeks each so I think 6 is actually not > excessive, while 3 is too tight. > > LGTM2 > > /Daniel > On 2026-05-13 09:30, Nidhi Jaju wrote: > > > > On Tue, May 12, 2026 at 10:18 PM Philip Jägenstedt <[email protected]> > wrote: > >> My LGTM is conditional on a removal milestone for the old names >> asrequested by Daniel. Since aliases are extremely cheap to keep around. >> https://www.chromium.org/blink/launching-features/ suggests "as many >> milestones as possible to respond to the deprecation" but more than 6 >> milestones would seem excessive to me. I'd suggest 3 milestones. >> > > Thank you, 3 milestones makes sense. @[email protected] > <[email protected]>, can you make the necessary adjustments? > > >> >> On Tue, May 12, 2026 at 3:14 PM Philip Jägenstedt <[email protected]> >> wrote: >> >>> Hi Nidhi, >>> >>> Given the very low usage, that this was already agreed to in the WG, and >>> that it's not merely cosmetic but matches reality better, LGTM1. >>> >>> Best regards, >>> Philip >>> >>> On Tue, May 12, 2026 at 10:26 AM Nidhi Jaju <[email protected]> >>> wrote: >>> >>>> Hi Alex, >>>> >>>> My understanding is that when WebTransport was initially shipped in >>>> Chromium, the core functionality of the W3C spec was considered fairly >>>> stable, and the decision was made to launch prior to Candidate >>>> Recommendation status. On the path to Candidate Recommendation, there have >>>> been some updates in response to implementation experience from other >>>> implementors and needs from use cases like MoQ. While we don't want to >>>> casually rename attributes for minor cosmetic reasons, this rename updates >>>> the attribute's name so that its meaning aligns with the reality of the >>>> functionality it provides. >>>> >>>> The WebTransport API overall is used by 0.0025% of page loads >>>> <https://chromestatus.com/metrics/feature/timeline/popularity/3472>, >>>> and the highWaterMark attribute can only be a subset of that. However, >>>> we're starting to see some adoption in the ecosystem, especially with the >>>> specs nearing completion and other major browsers shipping WebTransport >>>> implementations, so we'd like to make these changes while there's still an >>>> opportunity to minimize developer and compatibility impact. >>>> >>>> WebTransport is also included in Interop 2026, so we're expecting to >>>> make additional updates to align our implementation with the current state >>>> of the spec as it enters Candidate Recommendation status. >>>> >>>> Best, >>>> Nidhi >>>> >>>> On Tue, May 12, 2026 at 3:45 AM Alex Russell <[email protected]> >>>> wrote: >>>> >>>>> Hey Nidhi, >>>>> >>>>> Thanks for all of this background. I'm sure naming alignment might be >>>>> nice, but it doesn't seem obvious to me that we should agree to a change >>>>> post-launch, particularly without usage data. In general, the I2S process >>>>> should be thought of as pouring concrete; everything's fluid until it has >>>>> set. As a result, we have a dislike of this sort of casual renaming >>>>> post-launch. The evidentiary bar to support a rename is high, although >>>>> you >>>>> might be able to support strict aliasing with less pushback. >>>>> >>>>> Best, >>>>> >>>>> Alex >>>>> >>>>> On Friday, May 8, 2026 at 6:17:00 AM UTC-7 Nidhi Jaju wrote: >>>>> >>>>>> > Why was this renamed? Why would we agree to a cosmetic change after >>>>>> shipping? >>>>>> >>>>>> While we shipped our initial implementation of WebTransport in 2021, >>>>>> the specification has evolved since then as it progressed through the >>>>>> IETF >>>>>> and W3C, other browsers have also brought implementation experience, and >>>>>> other groups like Media over QUIC (MoQ) have highlighted the need for >>>>>> updates/additions to the spec. >>>>>> >>>>>> https://github.com/w3c/webtransport/issues/723 explains some of the >>>>>> reasoning behind this change. In the Streams API, a "high water mark" is >>>>>> a >>>>>> signal for backpressure and flow control, whereas in WebTransport, these >>>>>> attributes actually represent a hard cap on the number of datagrams >>>>>> retained in the queue. If this limit is exceeded, datagrams are dropped >>>>>> rather than just signaling backpressure, so the new names avoid >>>>>> developer >>>>>> confusion by more accurately describing the behavior. >>>>>> >>>>>> Best, >>>>>> Nidhi >>>>>> >>>>>> On Tuesday, April 14, 2026 at 3:36:22 AM UTC+9 Alex Russell wrote: >>>>>> >>>>>>> Why was this renamed? Why would we agree to a cosmetic change after >>>>>>> shipping? >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> On Wednesday, April 8, 2026 at 7:58:36 AM UTC-7 Daniel Bratell wrote: >>>>>>> >>>>>>>> Do you have a suggested "removal milestone"? >>>>>>>> >>>>>>>> We have found that unless we name a specific milestone, many people >>>>>>>> ignore deprecation warnings and then they pile up and we get warning >>>>>>>> fatigue. >>>>>>>> >>>>>>>> Also, do you have usage data? Use Counters or some other kind of >>>>>>>> upper limit on how many might be affected? >>>>>>>> >>>>>>>> /Daniel >>>>>>>> On 2026-04-08 11:29, Chromestatus wrote: >>>>>>>> >>>>>>>> *Contact emails* >>>>>>>> [email protected] >>>>>>>> >>>>>>>> *Explainer* >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Specification* >>>>>>>> >>>>>>>> https://w3c.github.io/webtransport/#dom-webtransportdatagramduplexstream-incomingmaxbuffereddatagrams,https://github.com/web-platform-tests/wpt/pull/58612/changes >>>>>>>> >>>>>>>> >>>>>>>> *Summary* >>>>>>>> The incomingHighWaterMark and outgoingHighWaterMark attributes on >>>>>>>> WebTransportDatagramDuplexStream are deprecated in favor of >>>>>>>> incomingMaxBufferedDatagrams and outgoingMaxBufferedDatagrams, >>>>>>>> following a >>>>>>>> spec rename. The attribute type also changes from long to unsigned >>>>>>>> long. >>>>>>>> Developers should migrate to the new attribute names. The old names >>>>>>>> will >>>>>>>> show a console deprecation warning and will be removed in a future >>>>>>>> release. >>>>>>>> >>>>>>>> *Blink component* >>>>>>>> Blink>Network>WebTransport >>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EWebTransport%22> >>>>>>>> >>>>>>>> *Web Feature ID* >>>>>>>> webtransport <https://webstatus.dev/features/webtransport> >>>>>>>> >>>>>>>> *Motivation* >>>>>>>> The WebTransport specification renamed two attributes on >>>>>>>> WebTransportDatagramDuplexStream: - incomingHighWaterMark → >>>>>>>> incomingMaxBufferedDatagrams - outgoingHighWaterMark → >>>>>>>> outgoingMaxBufferedDatagrams The attribute type was also changed from >>>>>>>> long >>>>>>>> to unsigned long. The new names better describe the attributes' >>>>>>>> purpose >>>>>>>> (they control the maximum number of buffered datagrams, not a >>>>>>>> byte-based >>>>>>>> high water mark). The new attribute names are already exposed >>>>>>>> alongside the >>>>>>>> old ones. The old names should be deprecated and removed to align with >>>>>>>> the >>>>>>>> specification and avoid developer confusion from having two names for >>>>>>>> the >>>>>>>> same thing. >>>>>>>> >>>>>>>> *Initial public proposal* >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Goals for experimentation* >>>>>>>> None >>>>>>>> >>>>>>>> *Debuggability* >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Requires code in //chrome?* >>>>>>>> False >>>>>>>> >>>>>>>> *Tracking bug* >>>>>>>> https://issues.chromium.org/issues/494380213 >>>>>>>> >>>>>>>> *Estimated milestones* >>>>>>>> >>>>>>>> No milestones specified >>>>>>>> >>>>>>>> >>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>> >>>>>>>> https://chromestatus.com/feature/5143839699501056?gate=4911413786181632 >>>>>>>> >>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>> <https://chromestatus.com>. >>>>>>>> >>>>>>>> -- >>>>>>>> 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 visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69d61ffa.050a0220.1c79a0.099e.GAE%40google.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69d61ffa.050a0220.1c79a0.099e.GAE%40google.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 visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANHu1%3DUq-6f_fbXN0h%2BwXnN%2Bbkp5QLhRfcpGUw_U99Cvg%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANHu1%3DUq-6f_fbXN0h%2BwXnN%2Bbkp5QLhRfcpGUw_U99Cvg%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fc6b0119-8959-496d-bc53-72a415a71201n%40chromium.org.
