Hi again Joey, Can you bump this thread when you'd like to ship it?
Best regards, Philip On Fri, Oct 6, 2023 at 7:38 PM Joey Arhar <jar...@chromium.org> wrote: > > 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/CAARdPYde%2BRE1TdkpjihAz_UXJjxJPaqzy4BKqhqygdNzM%2BMk8g%40mail.gmail.com.
