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/0f639a08-efc7-4177-852e-cb77e9fd92ebn%40chromium.org.

Reply via email to