Re: [blink-dev] Re: Intent to Prototype: Responsive iframes

wrote: > On Tue, May 20, 2025 at 12:05 AM Jake Archibald > wrote: > >> I think the "one shot" nature of this means it misses a lot of use-cases, >> such as the Discus case given in the explainer. Could the size be updated >> continually with the same constra

[blink-dev] Re: Intent to Prototype: Responsive iframes

I think the "one shot" nature of this means it misses a lot of use-cases, such as the Discus case given in the explainer. Could the size be updated continually with the same constraints applied to CSS containers? This would also allow size to be set sooner than the load event, which would perfor

[blink-dev] Re: Intent to Ship: view-transition-name: auto

TAG have switched their resolution to "unsatisfied" when it comes to `auto`. They're happy with `match-element`. https://github.com/w3ctag/design-reviews/issues/1001#issuecomment-2803634513 On Wednesday, 2 April 2025 at 13:14:14 UTC+1 Jake Archibald wrote: > My conce

[blink-dev] Re: Intent to Ship: view-transition-name: auto

My concerns about this are summarised here , and subsequent comments on the thread. I think this is different to the usual risks around IDs. Usually IDs are referenced directly by their full name, in HTML like , in links

Re: [blink-dev] Re: Intent to Ship: Auto-generated view transition names

rk cross-document, but will not give the same results as a same-document transition. I'm sad that the reasoning given for shipping this is "well, Apple just went ahead and shipped it so I suppose we should too". On Mon, 24 Mar 2025 at 20:46, Jake Archibald wrote: > The example I

[blink-dev] Re: Intent to Ship: view-transition-name: match-element

Although I think `view-transition-name: auto` is a mistake, I support `match-element` landing. I don't think web developers as a whole have a good understanding of DOM node equality, and as folks use it outside of small demos they'll likely be caught out by nodes being unexpectedly unequal, due

Re: [blink-dev] Re: Intent to Ship: Auto-generated view transition names

I've summarised the issues with this proposal in the TAG thread . On Tue, 25 Mar 2025 at 10:44, Noam Rosenthal wrote: > >> >> *Until this feature (correct me if I'm wrong), adding a unique ID to an >> element was safe

Re: [blink-dev] Re: Intent to Ship: Auto-generated view transition names

On Tue, 25 Mar 2025 at 10:31, Yoav Weiss wrote: > On Tuesday, March 25, 2025 at 5:12:17 AM UTC-4 Jake Archibald wrote: > > This issue wouldn't happen if any of the following was done instead: > > >- Each element was assigned a unique view-transition-name ident >

Re: [blink-dev] Re: Intent to Ship: Auto-generated view transition names

als*: >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applica

[blink-dev] Re: Intent to Ship: Auto-generated view transition names

I think `view-transition-name: auto` is poorly designed. It's an invitingly-named value that comes with footguns, and introduces unnecessary behavioural differences between cross-document and same-document transitions. `view-transition-name: auto` is basically `view-transition-name: match-elem

Re: [blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

I guess the result of the above is that rendering is blocked longer than expected, since it renders when the document readiness is no longer "loading"? Yeah, it'd be nice to follow the spec here and allow #target-id to be decided even if it isn't inserted by the parser. This is important for "ren

[blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

ck with the conclusion. >> >> On Tue, Mar 11, 2025 at 11:25 AM Jiacheng Guo wrote: >> >>> Yes, the design and the implementation allows the critical content >>> elements to be added via JS as well. I'll update the chromestatus and the >>> expl

[blink-dev] Re: Intent to Prototype: Full frame rate render blocking attribute

On Wednesday, 5 March 2025 at 05:23:20 UTC Chromestatus wrote: Contact emails g...@google.com Explainer https://github.com/whatwg/html/issues/11070 Specification None Summary We propose to add a new render blocking token full-frame-rate to the blocking attributes. When the renderer is blo

Re: [blink-dev] Re: Intent to Ship: Observable API

all out here that we have not >> yet sought or received any kind of formal "sign-off" by ECMAScript editors >> on our proposal. >> >> On Thu, Feb 27, 2025 at 1:00 AM Domenic Denicola >> wrote: >> >>> I looked into >>> <https://github.com/

[blink-dev] Re: Intent to Ship: Observable API

it might be because I'm not used to the patterns, and they're well understood elsewhere. > If you need a new subscriber to be created on each subscription, you'll > need to basically take a closure over the Observable-vending API and call > each `subscribe()` on it, which

[blink-dev] Re: Intent to Ship: Observable API

I'm struggling a little to get my head around how this works. https://codepen.io/jaffathecake/pen/raNWMmK?editors=0012 - it seems inconsistent that two of the calls to ob.map create a new subscriber, whereas the other picks up the observable half way through. If I put the .complete call in a se

[blink-dev] Re: Intent to Prototype: Scoped view transitions

This is great to see. I get a lot of questions around "why do view transitions break z-indexing?", and it's cases where on-top content that isn't going to be part of the transition ends up flattened into the root group, and therefore appears underneath transitioning content. This will be things

[blink-dev] Re: Intent to Ship: Document Render-Blocking

The design of this looks great. Filed a couple of very minor spec nuts https://github.com/whatwg/html/issues/10180 On Monday 4 March 2024 at 16:36:43 UTC vmp...@chromium.org wrote: > Contact emailsvmp...@chromium.org, nrose...@chromium.org > > Explainer > https://github.com/WICG/view-transitions

Re: [blink-dev] Re: Intent to Ship: The Popover API

DOMPurify seems to block the popover attribute, and I don't see any code for handling it specifically, so I assume it's not on an allowlist. On Mon, Mar 20, 2023 at 10:26 AM Philip Jägenstedt wrote: > Hi Noam, > > Do you know if these sanitizers generally wo

Re: [blink-dev] Intent to Ship: The Popover API

On Sat, Mar 18, 2023 at 2:53 PM Mason Freed wrote: > On Sat, Mar 18, 2023 at 1:39 AM Jake Archibald > wrote: > >> https://github.com/whatwg/html/issues/9045 - I don't think show/hide >> should throw if the popover is already shown/hidden. However, dialog has >>

Re: [blink-dev] Intent to Ship: The Popover API

https://github.com/whatwg/html/issues/9045 - I don't think show/hide should throw if the popover is already shown/hidden. However, dialog has this same issue, and going from throw to not-throw is generally a backwards compatible change. https://github.com/whatwg/html/issues/9046 - I don't think th

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

An important part of this for us was to ensure that we didn't 'design ourselves in a corner'. A part of this, we sketched out many additional features we want to add to ensure the current design is future-compatible: - https://github.com/WICG/view-transitions/blob/main/scoped-transitions.