On Wed, 7 Feb 2024 at 12:26, Domenic Denicola <dome...@chromium.org> wrote:
> > > On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly <fer...@google.com> wrote: > >> On Tue, 6 Feb 2024 at 15:13, Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> I am happy with the spec progress here and don't think it's a >>> significant blocker for the Intent at this point. >>> >>> On the tests and implementation: >>> >>> - I found >>> performance-navigation-timing-navigation-failure.tentative.window.js >>> >>> <https://github.com/web-platform-tests/wpt/blob/master/performance-timeline/not-restored-reasons/performance-navigation-timing-navigation-failure.tentative.window.js> >>> which seems like it needs to be updated from "error-document" to >>> "navigation-failure". That's worth looking into in case it means the >>> implementation is also not yet updated. >>> - I also found that the Chromium test directory is full of >>> -expected.txt files >>> >>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/abort-block-bfcache.window-expected.txt?q=NotRestoredReasonDetails&ss=chromium%2Fchromium%2Fsrc&start=21>, >>> which seem to match up with the failures on wpt.fyi >>> >>> <https://wpt.fyi/results/performance-timeline/not-restored-reasons?label=master&label=experimental&aligned&q=performance-timeline%2Fnot-restored-reasons>. >>> Will those be addressed before shipping? >>> - I found a nonstandard toJSON() in NotRestoredReasonDetails >>> >>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/not_restored_reasons.idl;l=12;drc=6211b1c8268b239694bd84d7a99e508a15dc6dea> >>> in >>> Chromium. Was the intent to specify that? >>> - Can you confirm that Chromium does not plan to ship any >>> nonstandard not restored reason strings, beyond the specified "fetch", >>> "navigation-failure", "parser-aborted", "websocket", "lock", and >>> "masked"? >>> >>> I don't know specifically what is there right now but I would expect >> that we will ship others. E.g. BroadcastChannel blocks BFCache on Chrome >> and Mozilla but not WebKit and there is currently disagreement. Why would >> it be better to show "masked" for that case? >> > > The idea is to follow the standards and not ship nonstandard behavior. The > current spec PR actually only allows sending "masked" in the cross-origin > case, and doesn't allow sending it for BroadcastChannel. If the intention > is to send some value in the BroadcastChannel case (which is this part of > the spec > <https://html.spec.whatwg.org/multipage/browsing-the-web.html#document-state:~:text=User%20agents%20may,keeping%20it%20cached.>) > then that needs to be specified in the spec PR before shipping such a value > in Chromium. > BFCaching is never required by spec. That means any browser can block BFCache at any time, for any reason and still be in spec. I think what's missing is that said we would maintain a registry of reasons that were not in the spec so that when we block for unspecced reasons, we don't proliferate a bunch of undocumented names. I'm not sure how to express that in the spec, F > > >> >> F >> >> >> >>> >>> >>> >>> On Mon, Feb 5, 2024 at 5:38 PM Yuzu Saijo <yu...@google.com> wrote: >>> >>>> This is now ready to ship, now that we have all the approvals on the >>>> ChromeStatus >>>> <https://chromestatus.com/feature/5684908759449600?gate=6535221965488128>and >>>> the spec draft <https://github.com/whatwg/html/pull/9360> is close to >>>> agreement. >>>> >>>> Can you please take a look at this again? >>>> Thanks! >>>> >>>> On Saturday, September 30, 2023 at 5:00:51 AM UTC+9 Chris Harrelson >>>> wrote: >>>> >>>>> Please also make sure to complete all of the other shipping gate >>>>> reviews >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/bqvB1oap0Yc/m/YlO8DEHgAQAJ> >>>>> . >>>>> >>>>> Thanks! >>>>> Chris >>>>> >>>>> On Thu, Aug 10, 2023 at 8:46 AM 'Yuzu Saijo' via blink-dev < >>>>> blin...@chromium.org> wrote: >>>>> >>>>>> Sounds good, I will create a list on the explainer >>>>>> <https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md> >>>>>> for the "may block" reasons then. >>>>>> >>>>>> Re: exposing NotRestoredReasons interface instead of object in idl: >>>>>> I'm working on the implementation in this CL >>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/4770594>. >>>>>> This might be a basic question, but is there any difference on how to >>>>>> call the API from users' perspective, when the exposed attribute is an >>>>>> interface vs object? >>>>>> >>>>>> On Thursday, August 10, 2023 at 10:06:49 AM UTC+9 dom...@chromium.org >>>>>> wrote: >>>>>> >>>>>>> On Wed, Aug 9, 2023 at 6:44 PM Fergal Daly <fer...@google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On Wed, 9 Aug 2023 at 12:01, Domenic Denicola <dom...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I think specifying these reasons is important. As noted in the >>>>>>>>> linked issue >>>>>>>>> <https://github.com/WICG/bfcache-not-restored-reason/issues/2>, I >>>>>>>>> think the end goal should be: >>>>>>>>> >>>>>>>>> - Every reason that a browser ever emits, is found in a >>>>>>>>> specification somewhere. (It doesn't have to be the HTML spec, >>>>>>>>> e.g. the >>>>>>>>> speech synthesis reason could live in the speech synthesis spec.) >>>>>>>>> >>>>>>>>> There's no intrinsic reason for speech synthesis to block BFCache. >>>>>>>> It just happens that Chrome blocked it. There's no spec reason for >>>>>>>> unload >>>>>>>> to block BFCache, in fact the spec says that it doesn't. >>>>>>>> >>>>>>>> I think it's good for us to have agreed names, e.g. >>>>>>>> "unload-event-handler". Should we put into various specs "if an >>>>>>>> implementer >>>>>>>> chooses to block BFCache because X has been used, they should use the >>>>>>>> reason `Y`"? >>>>>>>> >>>>>>>> >>>>>>>>> - If browsers prevent bfcache restoration for a reason not >>>>>>>>> found in a spec, it is always translated to a standardized reason >>>>>>>>> such as >>>>>>>>> "unknown". >>>>>>>>> >>>>>>>>> This avoids the usual interop problems with vendor-specific >>>>>>>>> extensions to the web platform, such as: no clear specification for >>>>>>>>> what >>>>>>>>> strings to use; no clear point at which the reason is added to the >>>>>>>>> document's reasons list; etc. Although you claim these reasons are >>>>>>>>> idiosyncratic to Chrome, that won't necessarily be the case; e.g. >>>>>>>>> Firefox >>>>>>>>> has unload handler as a reason, and I suspect most user agents have >>>>>>>>> memory >>>>>>>>> limitations or similar. >>>>>>>>> >>>>>>>> >>>>>>>> Chrome has over 100 reasons. I'd say at least 50 of them are >>>>>>>> actionable such that you wouldn't want to lump them into an opaque >>>>>>>> "unknown" category. >>>>>>>> >>>>>>>> I do not relish the idea of updating 50 places in spec to insert a >>>>>>>> name to be used if you decide to block. >>>>>>>> >>>>>>>> How about maintaining a central list of reasons with low friction >>>>>>>> to add new reasons even if they are browser-specific? The cases where >>>>>>>> you >>>>>>>> *must* block should still be inline in spec (and also on the list), >>>>>>>> >>>>>>> >>>>>>> That sounds great to me. We should probably make this separation >>>>>>> clear in the spec, e.g. the "must" list will have cross-references you >>>>>>> can >>>>>>> follow, whereas the "may" list ends up only being cross-referenced from >>>>>>> some generic location like >>>>>>> https://html.spec.whatwg.org/multipage/browsing-the-web.html#note-bfcache:~:text=User%20agents%20may,keeping%20it%20cached. >>>>>>> . >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> F >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> We could have a discussion about allowing vendor-specific >>>>>>>>> information in the API *in addition* to the standardized reasons. >>>>>>>>> For example, we could have one of the standardized reasons be >>>>>>>>> "user-agent-specific", and then add an additional field >>>>>>>>> userAgentSpecificInfo. But I would like to see significantly more >>>>>>>>> discussion with other vendors before going that route. >>>>>>>>> >>>>>>>>> On Tue, Aug 8, 2023 at 9:56 PM Yuzu Saijo <yu...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> +bfcache-dev >>>>>>>>>> >>>>>>>>>> I was talking to Fergal today and discussed this, and I am not >>>>>>>>>> sure about adding browser-specific reasons to the spec. >>>>>>>>>> For example, some reasons like "speech synthesis API is used" / >>>>>>>>>> "unload handler" are completely specific to Chrome, and it doesn't >>>>>>>>>> really >>>>>>>>>> make sense to add them to the spec, even with the namespace >>>>>>>>>> (x-speechsysthesis / x-unloadhandler). >>>>>>>>>> Maybe we can document the reasons somewhere in a shared list but >>>>>>>>>> not in the spec? >>>>>>>>>> >>>>>>>>>> I think the API would be more useful if it can give as much >>>>>>>>>> information as possible, not limited to the specced reasons. >>>>>>>>>> Please let me know what you think! >>>>>>>>>> >>>>>>>>>> Yuzu >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thursday, August 3, 2023 at 12:39:17 PM UTC+9 Yuzu Saijo wrote: >>>>>>>>>> >>>>>>>>>>> Sorry for the delayed response. >>>>>>>>>>> >>>>>>>>>>> *> there doesn't appear to be any NotRestoredReasons interface >>>>>>>>>>> defined in Chromium?* >>>>>>>>>>> Let me address this implementation and delay the shipping until >>>>>>>>>>> the chromium implementation matches the proposed spec. Thanks for >>>>>>>>>>> pointing >>>>>>>>>>> it out! >>>>>>>>>>> Same for WPT. I will add tests for all the standardized reasons. >>>>>>>>>>> >>>>>>>>>>> *> Can you confirm that you're only shipping the specified four?* >>>>>>>>>>> We do have ~50 not restored reasons, and in theory we will be >>>>>>>>>>> able to remove most of them except for the standardized four >>>>>>>>>>> reasons. >>>>>>>>>>> However, in reality it will take time for us to support all the >>>>>>>>>>> reasons and we need to keep blocking on them for a while. >>>>>>>>>>> In the meantime, our plan was to expose the non-standardized >>>>>>>>>>> reasons too, but in a way that's distinguishable from standardized >>>>>>>>>>> reasons as >>>>>>>>>>> you suggested here >>>>>>>>>>> <https://github.com/WICG/bfcache-not-restored-reason/issues/2>. >>>>>>>>>>> I realized that we need to add browser specific reasons to the >>>>>>>>>>> spec as well. Let me add that and send a review request again. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> Yuzu >>>>>>>>>>> On Thursday, July 13, 2023 at 12:07:05 PM UTC+9 >>>>>>>>>>> dom...@chromium.org wrote: >>>>>>>>>>> >>>>>>>>>>>> Also, checking the tests, it seems like the >>>>>>>>>>>> currently-implemented reasons don't match the spec. E.g. this >>>>>>>>>>>> test >>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/performance-navigation-timing-bfcache-reasons-stay.tentative.window.js> >>>>>>>>>>>> requires >>>>>>>>>>>> the reason to be "WebSocket", but the specification says >>>>>>>>>>>> "websocket" >>>>>>>>>>>> (lowercase). I couldn't find tests for the other three reasons... >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jul 13, 2023 at 12:04 PM Domenic Denicola < >>>>>>>>>>>> dom...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I have some questions about how well the implementation here >>>>>>>>>>>>> matches up with the spec. >>>>>>>>>>>>> >>>>>>>>>>>>> First, there doesn't appear to be any NotRestoredReasons >>>>>>>>>>>>> interface defined in Chromium? The relevant attribute on >>>>>>>>>>>>> PerformanceNavigationTiming returns object? >>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/performance_navigation_timing.idl;l=33?q=NotRestoredReasons%20file:%5C.idl&ss=chromium>. >>>>>>>>>>>>> That seems like a problematic mismatch... >>>>>>>>>>>>> >>>>>>>>>>>>> Second, I can't find exactly where the list of script-exposed >>>>>>>>>>>>> not restored reasons are. But, I'll note that Chromium seems >>>>>>>>>>>>> to have ~50 such reasons >>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:content/browser/renderer_host/back_forward_cache_metrics.h;drc=6754d1409bf5099314eea7e87e896622ade9bc0f;l=49>, >>>>>>>>>>>>> whereas you've only specified 4 (fetch, navigation-failure, >>>>>>>>>>>>> parser-aborted, >>>>>>>>>>>>> websocket). Can you confirm that you're only shipping the >>>>>>>>>>>>> specified four? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jul 13, 2023 at 12:11 AM Yoav Weiss < >>>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Jul 6, 2023 at 7:28 AM 'Yuzu Saijo' via blink-dev < >>>>>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> yu...@google.com, yu...@chromium.org, fer...@chromium.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Specification >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/whatwg/html/pull/9360 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Design docs >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NotRestoredReason API will report the list of reasons why a >>>>>>>>>>>>>>> page is not served from BFcache in a frame tree structure, via >>>>>>>>>>>>>>> PerformanceNavigationTiming API. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Blink component >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> UI>Browser>Navigation>BFCache >>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3ENavigation%3EBFCache> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/739 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TAG review status >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Issues addressed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Gecko: Defer ( >>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/766) >>>>>>>>>>>>>>> Once issues (standardized reasons & unsalvageable documents), >>>>>>>>>>>>>>> they would >>>>>>>>>>>>>>> switch to positive. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems like the "standardized reasons" part is addressed in >>>>>>>>>>>>>> your PR. Is the same true for the second point? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WebKit: No signal ( >>>>>>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/154) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Web developers: Positive ( >>>>>>>>>>>>>>> https://github.com/w3c/navigation-timing/issues/171#issuecomment-1062672989 >>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Other signals: Positive from Origin Trial users: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> How likely are you to keep using this feature? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 92% answered likely, 8% (1 vote) is unsure >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Security >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We do not report detailed information about cross-origin >>>>>>>>>>>>>>> iframes. See Security and Privacy section >>>>>>>>>>>>>>> <https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md#security-and-privacy> >>>>>>>>>>>>>>> in the explainer. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In DevTools console, try: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> performance.getEntriesByType('navigation')[0].notRestoredReasons; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NotRestoredReasons API is available on all platforms >>>>>>>>>>>>>>> including WebView, but back/forward cache is not enabled on >>>>>>>>>>>>>>> WebView. So on >>>>>>>>>>>>>>> WebView, NotRestoredReasons API should always say that the page >>>>>>>>>>>>>>> is blocked >>>>>>>>>>>>>>> from being restored from bfcache with the reason being >>>>>>>>>>>>>>> something like “not >>>>>>>>>>>>>>> supported”. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (Currently it reports null due to a bug >>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1459533> >>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DevTrial instructions >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/rubberyuzu/bfcache-not-retored-reason/blob/main/HowToTest.md >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Flag nameblink RunTimeEnabledFeature: >>>>>>>>>>>>>>> BackForwardCacheSendNotRestoredReasons >>>>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5;l=423?q=BackForwardCacheSendNotRestoredReasons%20-f:out&ss=chromium> >>>>>>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> False >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1326344 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Launch bug >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://launch.corp.google.com/launch/4200848 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shipping on desktop >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 116 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OriginTrial desktop last >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 114 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OriginTrial desktop first >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 109 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DevTrial on desktop >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 108 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shipping on Android >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 116 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OriginTrial Android last >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 114 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OriginTrial Android first >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 109 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DevTrial on Android >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 108 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shipping on WebView >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 116 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OriginTrial WebView last >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 114 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OriginTrial WebView first >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 109 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DevTrial on WebView >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 108 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>>>>>>>> compat or interop issues. Please list open issues. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/whatwg/html/pull/9360 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://chromestatus.com/feature/5684908759449600 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Intent to prototype: >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoGAzjUjzv3WmxcRpUSBgnA-AHQ05kh9gXc%2BQB8pRM6%2BfA%40mail.gmail.com >>>>>>>>>>>>>>> Intent to Experiment: >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoHe391sAB2PdbEVw9uiSPFxTB_EYsRizcPpZ7-pg16O0A%40mail.gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Intent to Extend Experiment: >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e698QcKZSthm%3Dz_4pi8cOzi4kfbx-AXveC%2BAKimUh-tMycA%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+...@chromium.org. >>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoHYpT3sxWV%2BEipL5NcNSWy8fOdDdAroucmNb%3DZvxJWRBA%40mail.gmail.com >>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoHYpT3sxWV%2BEipL5NcNSWy8fOdDdAroucmNb%3DZvxJWRBA%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+...@chromium.org. >>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXtkH6O82W%2BWm9ckCyYasSJt2cbs9VA4VZAmYhtivgj4g%40mail.gmail.com >>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXtkH6O82W%2BWm9ckCyYasSJt2cbs9VA4VZAmYhtivgj4g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>> . >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "bfcache-dev" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to bfcache-dev...@chromium.org. >>>>>>>>> To view this discussion on the web, visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CAM0wra-P3NxELP28%3Dgh%3D3ROC35m8ijS_5RRcStyjFew1AXNyEg%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CAM0wra-P3NxELP28%3Dgh%3D3ROC35m8ijS_5RRcStyjFew1AXNyEg%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+...@chromium.org. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/43e32f0e-454e-4525-b317-cbe492e2f23bn%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/43e32f0e-454e-4525-b317-cbe492e2f23bn%40chromium.org?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/CAAozHLnWwsSJG4%3DR7fg8ax79c6J0QAs2xTVprW3JLrpW%3DyVFeA%40mail.gmail.com.
