> On the level of interest, there was no reaction on https://github.com/whatwg/html/issues/9046 after you asked. Is there other communication that makes you relatively sure the interest is there?
I should have filed standards positions first. I have done so now: - https://github.com/WebKit/standards-positions/issues/263 - https://github.com/mozilla/standards-positions/issues/901 > It sounds like the idea is to prove this web compatible by shipping it, before updating the spec I intend to get positive signals from Gecko and WebKit first before actually shipping this. I already have an HTML spec PR open, so the spec could be updated at any time. There is a risk for web compatibility, although I was convinced that this should just improve the consistency of the event timing. If there is significant breakage, I will disable this change via finch and revert the spec changes. On Fri, Oct 6, 2023 at 4:12 AM Philip Jägenstedt <foo...@chromium.org> wrote: > It sounds like the idea is to prove this web compatible by shipping it, > before updating the spec. On the level of interest, there was no reaction > on https://github.com/whatwg/html/issues/9046 after you asked. Is there > other communication that makes you relatively sure the interest is there? > > On Fri, Oct 6, 2023 at 3:34 AM Joey Arhar <jar...@chromium.org> wrote: > >> Contact emailsjar...@chromium.org >> >> Explainerhttps://github.com/whatwg/html/issues/9046 >> >> Specificationhttps://github.com/whatwg/html/pull/9775 >> >> Summary >> >> The toggle events for the popover attribute and the details element, as >> well as the close event for dialog elements, currently post a task to the >> DOM manipulation task source to fire these events asynchronously. This >> means that the event could fire before or after the next render, which >> could lead to flaky rendering for one frame. By using microtasks instead, >> the event will always fire before the next render. This was suggested in >> this HTML spec issue: https://github.com/whatwg/html/issues/9046 >> >> >> Blink componentBlink>DOM >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM> >> >> TAG reviewThis is a very small change so I'm not making a TAG review. >> >> TAG review statusNot applicable >> >> Risks >> >> >> Interoperability and Compatibility >> >> If websites are relying on the slower event timing somehow, then we could >> run into problems. >> >> >> *Gecko*: Positive? >> https://github.com/whatwg/html/issues/9046#issuecomment-1724509340 >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> None >> >> >> Debuggability >> >> None >> >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)?Yes >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?Yes >> >> Flag name on chrome://flagsNone >> >> Finch feature nameNone >> >> Non-finch justification >> >> I am not interested in any metrics changes for this feature, it should >> just make the behavior more consistent for web developers. Should it prove >> to have issues, I can disable it with a finch killswitch. >> >> >> Requires code in //chrome?False >> >> Adoption expectationIf we ship this without breaking websites, then I >> think the other browsers will feel interested in implementing this as well. >> >> Adoption planThis change modifies several WPTs which the other browsers >> are likely watching, which will help encourage them to implement this as >> well. >> >> Estimated milestones >> >> No milestones specified >> >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> None >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5123249231101952 >> >> 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 blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJKWcg_ZCnSAs%3DML37a0Ov80V-gxcscbRwtCou15LE66w%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJKWcg_ZCnSAs%3DML37a0Ov80V-gxcscbRwtCou15LE66w%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJNTUOjxei_03FT87TvbsVU2cny-RE%3DSpRz6jNFTEQN%2BA%40mail.gmail.com.
