{
  "category": "JavaScript",
  "flag_name": null,
  "id": 4580748730040320,
  "milestone": 141,
  "name": "[WebRTC getStats] Align implementations on when RTP stats should be created",
  "summary": "RTP stats objects, of type \"outbound-rtp\" or \"inbound-rtp\" in this case, represents a WebRTC stream. The identifier of this stream is the SSRC (a number). We should collect stats for streams that \"exist\", but implementations and spec has disagreed on when the stream should exist: if the SSRC information is conveyed via SDP, does the stream still exist before packets are sent or received? https://crbug.com/406585888 tries to reach alignment between browsers and spec."
}

{
  "category": "JavaScript",
  "flag_name": null,
  "id": 5067126381215744,
  "milestone": 142,
  "name": "activeViewTransition property on document",
  "summary": "View Transitions API allows developers to start visual transitions between different states. The primary SPA entry point to this is `startViewTransition()` which returns a transition object. This object contains several promises and functionality to track the transition progress, as well as allow manipulations such as skipping the transition or modifying its types.\r\n\r\nThe proposal here is ergonomic in nature: instead of requiring that users store this object in some sort of way for easy access, provide a `document.activeViewTransition` property that represents this object, or null if there is no transition ongoing.\r\n\r\nNote this similarly applies to MPA transitions, where the object is only available via `pageswap` and `pagereveal` events. In this proposal `document.activeViewTransition` would be set to this object for the duration of the transition."
}

{
  "category": "JavaScript",
  "flag_name": null,
  "id": 6229300214890496,
  "milestone": 143,
  "name": "EditContext: TextFormat underlineStyle and underlineThickness",
  "summary": "Chromium shipped https://developer.mozilla.org/en-US/docs/Web/API/EditContext with a bug where the https://developer.mozilla.org/en-US/docs/Web/API/TextFormat object supplied by the https://developer.mozilla.org/en-US/docs/Web/API/EditContext/textformatupdate_event provides incorrect values for the underlineStyle and underlineThickness properties. In Chromium the possible values are {“None”, “Solid”, “Dotted”, “Dashed”, “Squiggle”} and {“None”, “Thin”, “Thick”}, when per https://w3c.github.io/edit-context/#dom-underlinestyle they should be {“none”, “solid”, “dotted”, “dashed”, “wavy”} and {“none”, “thin”, “thick”}. This Intent covers switching TextFormat.underlineStyle and TextFormat.underlineThickness to use the spec values.\n\nThis change is valuable because it aligns these attributes with existing CSS https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration-style and the https://www.w3.org/TR/design-principles/#casing-rules. Since the purpose of the TextFormat properties is to be used in applying these text styles to text being composed on behalf of an IME, it will be more convenient for developers if the underlineStyle value can be applied directly from the event to CSS without need for a remapping. For both underlineStyle and underlineThickness, matching the platform lower-case convention will reduce the likelihood of developer confusion."
}

{
  "category": "JavaScript",
  "flag_name": null,
  "id": 5143313833000960,
  "milestone": 143,
  "name": "ICU 77 (supporting Unicode 16)",
  "summary": "The Unicode support library ICU (International Components for Unicode) is upgraded from version 74.2 to 77.1, adding support for Unicode 16 and updating locale data. Two changes could pose some risk for web applications that assume a specific format from the Intl JS APIs:\n\nThe default Italian number formatting changed to omit the thousand separator for 4-digit numbers. For example `new Intl.NumberFormat(\"it\").format(1234)` will return \"1234\" instead of \"1.234\". The old behavior can be achieved with the useGrouping parameter for the Intl.NumberFormat constructor.\nIn some English locales (en-AU, en-GB, and en-IN) a comma was added after full-length weekdays, for example changing \"Saturday 30 April 2011\" to \"Saturday, 30 April 2011\". Web applications should avoid relying on the precise formatting of dates and they may \n\nIntl and RegExp (V8): Lots of small changes. The change of Italian number formatting is the riskiest and has a dedicated flag, see compat risk section.\n\nIDNA: Generally more things are allowed, and this upgrade improves our overall test results in WPT.\n\nText segmentation: The most interesting change is better Japanese line breaking when using `word-break: auto-phrase`, related to https://chromestatus.com/feature/5133892532568064."
}

{
  "category": "JavaScript",
  "flag_name": "harmony_remove_intl_locale_info_getters",
  "id": 5148228059398144,
  "milestone": 143,
  "name": "Deprecate getters of Intl Locale Info",
  "summary": "Intl Locale Info API is a Stage 3 ECMAScript TC39 proposal to enhance the Intl.Locale object by exposing Locale information, such as week data (first day in a week, weekend start day, weekend end day, minimun day in the first week), and text direction hour cycle used in the locale.\r\nhttps://github.com/tc39/proposal-intl-locale-info\r\n\r\nWe ship our implementation in m99 (https://chromestatus.com/feature/5566859262820352 ) . But later on the propose made some change in Stage 3 and move several getters to functions. We need to remove the deprecated getters and relaunch the renamed functions\r\n"
}