On Mon, Mar 4, 2024 at 5:36 PM Vladimir Levin <vmp...@chromium.org> wrote:
> Contact emailsvmp...@chromium.org, nrosent...@chromium.org > > Explainer > https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md#blocking-element-id > Thanks for the explainer. It's very useful!! The explainer mentions console warnings in case authors included an ID that wasn't encountered, resulting in waiting for the fill document. Was this implemented? Will render blocking also happen in cases where no transition took place? (e.g. on landing pages) > > > Specification > https://html.spec.whatwg.org/multipage/links.html#link-type-expect > > Summary > > This feature enables authors to block rendering of a Document until the > critical content has been parsed, ensuring a consistent first paint across > all browsers. Without this feature, the first paint's state depends on the > heuristics for parser yielding which can vary across browsers. This is > particularly important for View Transitions where the parsed DOM state on > the first frame can drastically change the transition created. Note that > this feature specifically implements a `<link rel=expect href="#id">` > syntax that allows a link element to reference another expected element on > the page. The rendering is then blocked until the expected element is fully > parsed. This supersedes previous implementation of html attribute that > allows the whole document to be render blocked. > > > Blink componentBlink>ViewTransitions>MPA > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EViewTransitions%3EMPA> > > TAG reviewhttps://github.com/w3ctag/design-reviews/issues/886 > > TAG review statusIssues addressed > > Risks > > > Interoperability and Compatibility > > None > > > *Gecko*: Positive ( > https://github.com/mozilla/standards-positions/issues/875) > > *WebKit*: No signal ( > https://github.com/WebKit/standards-positions/issues/245) > > *Web developers*: Positive (https://github.com/whatwg/html/issues/9332) > There are some discussions between implementors and developers on this > issue. This feature is also a requisite feature for cross-document View > Transition adoption, which has strong positive signals ( > https://daverupert.com/2023/05/getting-started-view-transitions/). > > *Other signals*: > > Ergonomics > > This feature would be used frequently with cross-document View > Transitions, because it allows the browser to wait for necessary content to > be parsed. > > > Activation > > This feature can be used directly. > > > 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? > > There are no WebView application risks > > > Debuggability > > None > See question above about console warnings.. Might also be worthwhile to consider a reporting API or a performance observer for this, to enable developers to catch such instances in the wild. > > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, 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 > > > https://wpt.fyi/results/html/dom/render-blocking?label=master&label=experimental&aligned&q=element-render-blocking > Note that we will be renaming these from .tentative shortly > Lots of tests are failing there.. > > > Flag name on chrome://flagsNone > > Finch feature nameDocumentRenderBlocking > > Requires code in //chrome?False > > Adoption expectationThis feature is expected to be adopted by developers > using cross-document View Transitions > > Estimated milestones > Shipping on desktop 124 > Shipping on Android 124 > Shipping on WebView 124 > > 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/5113053598711808 > > Links to previous Intent discussionsIntent to prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUzNfD4MRk0bR1yTZ5F6NzcpETrUU3Vy9GmANZRQd7%3DE4A%40mail.gmail.com > > 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/CADsXd2MZaRt_2k5-Hny9crxJSgZbgEJau0my%3DW9_7-pp0OqKUw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MZaRt_2k5-Hny9crxJSgZbgEJau0my%3DW9_7-pp0OqKUw%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/CAOmohSK6pj%2B4K_CgXz3GKNiJmFBUs%2BWmPgtcuT43x5pc_rL1Tg%40mail.gmail.com.
