00:54:40 RRSAgent has joined #whatwg 00:54:44 logging to https://www.w3.org/2025/11/11-whatwg-irc 00:54:45 Zakim, this is WHATWG 00:54:45 got it, cwilso 00:54:48 q? 00:55:06 present+ 00:55:11 foolip_ has joined #whatwg 00:55:12 what is the doc where scribing is happening? 00:55:18 zcorpan has joined #whatwg 00:55:22 snek has joined #whatwg 00:55:22 https://docs.google.com/document/d/1XQLLjETtdBPv-xGiGPRALR4X7hgSb_Lk13bdBucEJ_g/edit?tab=t.0#heading=h.51akrqmzup50 00:55:27 nicolo-ribaudo_ has joined #whatwg 00:55:38 cwilso2 has joined #whatwg 00:55:41 anne has joined #whatwg 00:55:44 nicolo-ribaudo has joined #whatwg 00:55:45 schenney has joined #whatwg 00:55:48 jjaschke has joined #WHATWG 00:56:25 foolip has joined #whatwg 00:56:32 mjackson has joined #whatwg 00:56:37 mjackson has left #whatwg 00:56:37 Itoe has joined #WHATWG 00:56:39 theparkagen has joined #WHATWG 00:56:47 rniwa has joined #whatwg 00:57:13 hayato has joined #whatwg 00:58:08 scribenick: foolip 00:58:46 leo: presenting slideas 00:59:01 mjackson2 has joined #whatwg 00:59:01 Itoe5 has joined #WHATWG 00:59:05 mjackson2 has left #whatwg 00:59:16 leo: the proposal is a new FormControlRange, extending AbstractRange 00:59:24 mjackson has joined #whatwg 00:59:46 leo: FormControlRange is live and automatically updates, like how Range tracks changes 01:00:05 leo: this is inspired by Keith Cirkel's Richer Text Fields proposal 01:00:36 leo: it's different enough from Range to justify creating a new type 01:00:52 leo: would like to get your thoughts on this 01:01:19 leo: there are restrictions on the start/end point that are hard to enforce with the Range API 01:01:44 leo: if we did use Range, maybe we could add a parameter to all methods, but that seems messy 01:02:00 leo: that's the context 01:02:03 q? 01:02:44 rniwa: Range.selectNodeContents() isn't on AbstractRange I think 01:03:11 anne: if use Range directly we have a bunch of problems like this 01:04:03 leo: what we're proposing is this (presenting Example 1) 01:04:28 adekker has joined #whatwg 01:04:35 rniwa: should the Selection API be updated? 01:04:38 leo: it would be live 01:04:54 leo: but would getSelection() getters return these new objects? 01:05:23 leo: I would say yes, return this new FormControlRange 01:05:30 Steven has joined #WHATWG 01:05:37 smaug: I'm not sure we want to change what those things return 01:05:53 emilio: is that interoperable right now? 01:06:05 smaug: no, there are differences 01:06:22 rniwa: there may be some compatibility issues then, needs to be discussed in conjunction with the Selection API 01:06:29 smaug: I thought this was more about the Highlight API 01:06:35 leo: custom highlight, yes 01:07:10 rniwa: calling it custom highlights and not interacting with selection is an option 01:07:18 anne: we could also have that be an opt-in 01:07:31 emilio: something added to getRangeAt() 01:07:37 anne: or flip a bit on the Selection object 01:07:45 zcorpan: or a new method 01:07:55 smaug: something something Shadow DOM 01:08:12 q+ 01:08:12 rniwa: form-associated custom elements wouldn't be able to work with this API 01:08:20 q? 01:08:36 leo: how can we overcome that? 01:08:58 rniwa: need to make it more generic so that custom elements can use this 01:09:15 rniwa: maybe it wouldn't be called FormControlRange 01:09:23 leo: do we have consensus that a new interface is needed? 01:09:51 ack em 01:09:52 rniwa: my concern is a brand new API that doesn't work with custom elements, but if we make it work that would be OK. 01:10:12 emilio: one more option is something that operates directly on a single text node, these controls effectively operate on a string. 01:10:24 emilio: that could also work with contenteditable=plaintext-only 01:10:41 emilio: this new Range isn't very special, except that you don't have access to the string it's pointing into 01:10:45 anne: StringRange, TextRange? 01:10:56 emilio: yes. 01:11:06 jmdyck has joined #WHATWG 01:11:07 anne: maybe set the range through ElementInternals? 01:11:22 rniwa: ideally we want to be able to map the selection from within the shadow root dynamically 01:11:45 rniwa: if it's a calendar widget you want a selection in date/month/year separately, so it's not necessarily a 1:1 map. 01:11:54 smaug: but this is only for text inputs 01:12:06 emilio: it feels like a regular range that operates on a text node. 01:12:28 emilio: maybe 3 different text ranges for date/month/year in that case, and the custom element exposes all 3? 01:12:47 q+ 01:12:49 emilio: maybe it's also useful for cases where you do have access to the underlying node 01:13:11 ack sch 01:13:25 schenney: the issue links to Keith's doc with a bunch of use cases for this 01:13:45 https://open-ui.org/components/richer-text-fields.explainer/ 01:14:04 rrsagent, make minutes 01:14:05 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 01:14:22 RRSAgent, make logs public 01:14:25 leo: our original intention was to start with just text and be open to custom elements in the future 01:14:48 Mike5 has joined #whatwg 01:15:16 smaug: there is a risk that we'd have to introduce another range type 01:15:26 q? 01:15:39 anne: it depends on whether custom elements just need parity with built-in elements or need to do more than that 01:15:45 RRSAgent, make minutes 01:15:46 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html Mike5 01:15:56 rniwa: we probably don't want to expose the Text node itself 01:15:57 anne: no 01:16:14 emilio: how about PlainTextRange? 01:16:20 LeoL has joined #WHATWG 01:16:28 https://open-ui.org/components/richer-text-fields.explainer/ 01:16:29 emilio: we could easily create a constructor to create a PlainTextRange from a Text node? 01:17:17 emilio: I'm not sure why input and textarea can't just have a getter returning the live range for the current selection? why a constructor? 01:17:25 smaug: because there can be multiple ones for highlighting 01:18:02 rniwa: regular ranges have a clone() method 01:18:31 rniwa: but it would be awkward to create new ranges with offsets, need to clone and edit 01:18:45 leo: we're trying to align with the current APIs 01:18:50 q? 01:20:02 cwilso, can you encourage usage of the queue? 01:20:56 q+ 01:22:16 q+ 01:22:33 ack cwilso 01:22:46 ack rn 01:22:51 anne has joined #whatwg 01:22:52 To be clear, what I'm proposing, something like: `TextRange HTMLTextAreaElement.getTextRange(unsigned start, unsigned end);` 01:23:09 rniwa: my question is if we have an interface with a constructor taking a host and two numbers, that only works for text field-like custom elements 01:23:22 rniwa: is there an alterantive where it would work with multiple editable regions? 01:23:24 anne2 has joined #whatwg 01:23:27 And then custom elements could do something like `new TextRange(); textRange.setTextRange(myMonthNode, 0, 2); return textRange;` or so 01:23:30 sorvell has joined #whatwg 01:23:48 rniwa: ideally we'd have one solution that would work for multiple use cases 01:23:58 q+ 01:24:05 leo: you're saying it doesn't work because it doesn't work with multiple ranges? 01:24:24 rniwa: maybe we could add a name that specifies which selectable area it refers to 01:24:35 q- 01:24:44 ack em 01:24:47 emilio: I pasted the example above of what I mean 01:24:50 andreubotella has joined #whatwg 01:25:24 q? 01:25:29 emilio: as long as we don't expose the actual Text node in the interface I think it would work on both inputs and custom elements 01:25:47 rniwa: that might be a good design 01:26:40 rniwa: one thing to consider is a calendar widget is some way to "forward"... but maybe it's OK 01:26:48 q? 01:27:28 anne: then the other properties can't expose the boundary points, because they'd be in the shadow tree 01:27:34 anne: not sure what abstract range currently does 01:27:37 emilio: that would be important 01:27:39 chikamune has joined #WHATWG 01:28:05 rniwa: we could also return a host 01:28:19 zcorpan: makes more sense than returning which is what Range does :) 01:29:23 zcorpan: maybe the constructor needs to have a parameter for the host? 01:29:49 emilio: the other alterantive would be to just return the text node, but that exposes it from the text node 01:29:54 anne: we can't do that 01:30:09 zcorpan: return the text node data? 01:30:43 [scribe is having difficulties scribing back and forth] 01:31:05 cwilso: we are at time! 01:31:21 leo: are we closer to a solution? 01:31:40 anne: I think we need a design for the form-associated case, but it doesn't need to be included in v0 01:31:49 anne: we have some alterantives 01:31:55 rniwa: I think we can come up with something 01:32:05 [general rejoicing and optimism in the room] 01:32:24 leo: we'll go back and have a look 01:32:29 anne: I'm happy to help 01:32:36 scribenick: zcorpan 01:32:44 Topic: AsyncContext 01:33:42 rrsagent, make minutes 01:33:43 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 01:34:10 andreubotella: Proposal https://github.com/tc39/proposa-async-context/ 01:34:27 andreubotella: trying to figure out integration between tc39 and whatwg 01:34:52 https://github.com/tc39/proposal-async-context/ 01:35:32 q+ not be too prescriptive 01:35:34 andreubotella: Open question how the stages processes map to each other 01:35:40 q+ 01:36:23 andreubotella: What AsyncContext does, it propagates... has AsyncContext.Variable class 01:36:45 andreubotella: run() method 01:37:12 andreubotella: showing await example 01:37:23 andreubotella: gets propagated through await 01:37:50 andreubotella: set a new value in the stack 01:38:16 andreubotella: setTimeout example 01:39:36 andreubotella: asyncVar.get() returns same value from setTimeout() in run() as sync in run() 01:40:03 andreubotella: useful to keep track of state across disconnected parts of an application, calling to other third-party code 01:40:11 andreubotella: which async operation they are in 01:40:21 andreubotella: which async branch 01:40:37 andreubotella: parallel to localStorage 01:41:06 andreubotella: used to instrument ??? 01:41:29 For the minutes: the parallel was to ThreadLocalStorage in C++, not to the web localStorage 01:41:31 andreubotella: would allow authors to instrument their applications, would be more performant for users 01:41:55 andreubotella: trying to see if this works as an explainer for the whatwg stages process 01:41:56 s/???/ThreadLocalStorage in C++, not to the web localStorage 01:42:32 ack nic 01:42:41 nicolo-ribaudo: tc39 want to be formal about stages 01:43:09 nicolo-ribaudo: suggest being loose on whatwg side 01:43:25 nicolo-ribaudo: advance roughly at the same time 01:44:18 andreubotella: for stage 3 it signals that it's ready for implementation, should be in sync 01:44:53 q+ to ask if we have stage 1 01:45:10 andreubotella: tc39 might advance to stage 3 at the time whatwg advances 01:45:25 nojmack has joined #WHATWG 01:45:48 andreubotella: whatwg stage 3 could signal tc39 stage 2.7 01:45:49 ack nic 01:45:49 nicolo-ribaudo, you wanted to ask if we have stage 1 01:46:04 nicolo-ribaudo: requesting whatwg stage 1 01:46:24 nicolo-ribaudo: believe the proposal fulfills the requirements 01:46:50 cwilso: in general, bring it to the triage meeting, group can object or agree 01:47:02 rniwa: what happens with multiple values 01:47:16 andreubotella: have single map to a value 01:47:30 andreubotella: if you use immutable map, do await or setTimeout, store reference 01:47:51 andreubotella: multiple values are variable 01:48:00 anne: can you use multiple Variables? 01:48:02 andreubotella: yes 01:48:31 ???: restored after await 01:48:58 andreubotella: single asynccontext are variable. Have internal map, not user exposed 01:49:02 (name of the person who spoke is jridgewell, for the minutes) 01:49:26 s/???/jridgewell/ 01:49:30 q+ 01:49:40 andreubotella: better if it's mutable 01:49:52 anne: better if you didn't explain in terms of impl 01:50:00 anne: explain what web dev can observe 01:50:19 rniwa: want to have multiple values, return some unique value, map to some value at that moment 01:50:34 nicolo-ribaudo: map is internal impl detail 01:50:45 nicolo-ribaudo: multiple variables, multiple keys 01:50:57 nicolo-ribaudo: set them one by one 01:51:44 mmocny: Similar to normal valiables 01:51:51 rniwa has joined #whatwg 01:51:58 ack sm 01:52:03 smaug: status, i think stage 1 is fine 01:52:29 q+ 01:52:29 michaelficarra has joined #whatwg 01:52:54 smaug: hoping webkit folks would review, from integration with web apis POV, and memory management 01:53:00 ack ni 01:53:12 nicolo-ribaudo: do you think we can go through the current document 01:53:21 nicolo-ribaudo: setTimeout has an obvious answer 01:53:59 smaug: need to go through all apis 01:54:18 nicolo-ribaudo: would be good to have participation from all browser engines 01:54:39 anne: should there be something for AbortSignals? 01:54:45 nicolo-ribaudo: just an event? 01:54:47 anne: yes 01:54:55 andreubotella: events are most complicated part 01:55:03 andreubotella: work different in different situations 01:55:40 andreubotella: events are sync, (missed), 01:55:53 andreubotella: loadend event 01:56:45 andreubotella: there are many of those events, if we decide to propagate those, from the same agent and same origin it's propagated 01:56:45 s/(misssed),/browser originated events have no obvious context to propagate, like `onload` 01:56:52 andreubotella: maybe not expected by developers 01:57:05 michaelficarra has joined #whatwg 01:57:13 andreubotella: observers, not fully figured out 01:57:22 andreubotella: to be discussed during stage 1 01:57:47 andreubotella: maybe can simplify if it's too complicated 01:58:13 andreubotella: a lot of web apis that do async things 01:58:48 domfarolino: the notes says, propagating .... same result as ... 01:58:54 zakim, make minutes 01:58:54 I don't understand 'make minutes', cwilso 01:59:01 rrsagent, make minutes 01:59:02 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 01:59:08 domfarolino: idea is, the snapshot is taken after callback is run 01:59:25 domfarolino: can snapshot happen different time? 01:59:39 domfarolino: ran callback ... 01:59:49 nicolo-ribaudo: difficult to do from different context 01:59:59 domfarolino: do something after callback has run 02:00:16 domfarolino: is it possible to get disconnected from scheduler api 02:00:32 nicolo-ribaudo: if you postmessage a worker 02:00:47 domfarolino: how would this work with observables 02:01:03 domfarolino: create an observable in callback 02:01:13 domfarolino: later on, run subscribe 02:01:27 domfarolino: what is the value of Variable? 02:01:35 domfarolino: overridden by run? 02:01:46 nicolo-ribaudo: when you call next() it propagates 02:02:00 domfarolino: wondering if there's something that makes sense 02:02:13 domfarolino: not obvious what the right behavior is 02:02:21 smaug: general issue 02:02:33 domfarolino: some apis are tricky 02:02:33 q+ have the same problem with other observers 02:02:53 snek: precise semantics how asynccontext works 02:02:55 q+ to break 02:02:57 q> 02:03:00 q? 02:03:10 snek: any ambiguities, documentation about what we want to happen 02:03:25 domfarolino: it is what we define for each api 02:03:46 snek: if observable is going through a web api, but in other cases can define from first principles for the api 02:03:58 ack me 02:03:58 cwilso, you wanted to break 02:04:15 jridgewell: similar issue already for observer-type apis 02:04:15 rrsagent, make minutes 02:04:16 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 02:19:54 sakito has joined #whatwg 02:21:57 kizu has joined #whatwg 02:34:04 alisonmaher has joined #whatwg 02:34:08 present+ 02:34:16 kbabbitt has joined #whatwg 02:34:55 present+ 02:35:05 topic: OpenUI/WHATWG issues 02:36:16 anne has joined #whatwg 02:36:37 frehner has joined #whatwg 02:36:37 jjaschke has joined #WHATWG 02:36:42 present+ 02:36:42 ydaniv has joined #whatwg 02:36:49 fantasai has joined #whatwg 02:36:52 ntim has joined #whatwg 02:37:32 zcorpan has joined #whatwg 02:37:34 where is the agenda 02:38:01 fantasai has changed the topic to: https://github.com/whatwg/html/issues/11711#issuecomment-3499143498 02:38:25 scribenick: ntim 02:39:18 fantasai: These issues are all related, mainly about anchor positioning. Affordances useful for accessibility 02:39:51 ...create a connection with popover API for accessibility, also with anchor positioning for presentation 02:40:07 fantasai: what about non popovers? how to express those relationships 02:40:19 Itoe has joined #WHATWG 02:40:22 gorohash has joined #whatwg 02:40:29 q+ 02:40:30 (popovers use popovertarget) 02:41:20 domfarolino has joined #whatwg 02:41:39 mjackson has joined #whatwg 02:41:56 domfarolino: IIUC, do we need markup to associate non-popover to its anchor? 02:42:10 oriol has joined #whatwg 02:42:11 Haruki has joined #whatwg 02:42:13 Ananya has joined #whatwg 02:42:22 present+ 02:42:42 westbrook has joined #whatwg 02:43:12 present+ 02:43:17 ack ki 02:43:17 fantasai: ARIA has a lot of mental load. Anchor positioning has both presentational use cases where the bindings shouldn't be expressed, and has cases like popover where the link needs to be expressed in the a11y tree. There are going to be cases where the semantic relationship needs to be expressed, but it is not a popover. What is the markup for those? 02:43:43 +1 fantasai. making the anchoring relationship more explicit in markup with a more memorable attribute (for both popover and non-popover), rather than re-using ARIA, is a more developer-ergonomic approach. 02:43:48 vmpstr has joined #whatwg 02:44:08 sakito has joined #whatwg 02:47:30 kizu: What are the use cases? tooltips, common use case is where side notes where you position notes on the left of the content. There are many potential use cases where the content is always visible, and does not pop over. You want to put notes that is displayed along side the main content. On mobile, you could use display: none to make them popover, but if you display them as side notes, keyboard order is not going to be the same. 02:47:30 kizu: So if we had this mapping, it would be useful 02:47:44 saku has joined #whatwg 02:47:44 kizu: two ideas: still use popover, removing the default style of display: none, e.g. making it visible, but not a popover by default. 02:54:48 we need to think about aria/keyboard order 02:54:52 second idea: allow making a popover open by default, but semantically different from just an in-flow element. 02:54:52 How do we handle an use case like side notes ? 02:54:52 q? 02:54:52 anne: I like the use cases 02:54:52 anne: it doesn't work if you have multiple notes for one content 02:54:52 kizu: anchor positioning can do this with min/max calculations 02:54:52 +1 anne. multiple footnotes for the same content / point in the text (I've had examples of this in my blog, and this is common in Wikipedia too) 02:54:52 kizu: one issue is the bottom of the doc, where overlapping can happen 02:54:52 fantasai: point is, we have a layout mechanism but not markup support for it 02:54:52 `.sidenote { anchor-name: --sidenode; top: max(anchor(--note1 top), calc(1em + anchor(--sidenote bottom))); }` 02:54:52 ^^^ Sit next to the anchor, or below any preceding sidenotes. 02:54:52 anne: using popover seems a bit wrong, i could imagine the aria mapping could get jarring for assistive tools 02:54:52 domfarolino: you probably don't want the top layer stuff 02:54:52 fantasai: you might want to introduce something else than popover, but what would that be 02:54:52 -> https://github.com/whatwg/html/pull/9144 02:54:52 fantasai: there's an existing PR for the anchor attribute but only does rendering bindings 02:54:52 +1 anne. being able to go from the ref to the footnote to the footnote and back to the ref. this is a common Wikipedia use-case. 02:54:52 anne: maybe it should impact focus, in addition to layout. The other thing you want for footnotes is going back to the content. 02:54:52 fantasai: There's two types of navigations if you have footnotes, you might want to navigate and skip through the notes, or you want to see the footnote now. 02:54:58 domfarolino: could we do something that expands the anchor attribute to handle focus stuff? 02:54:58 anne: needs more thought 03:38:22 RRSAgent has joined #whatwg 03:38:24 logging to https://www.w3.org/2025/11/11-whatwg-irc 03:38:27 rrsagent, make minutes 03:38:28 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 03:38:29 See https://github.com/WICG/html-in-canvas for details 03:38:45 [foolip is going over the details] 03:39:05 westbrook has joined #whatwg 03:39:19 scribe+ 03:39:38 foolip: Text is a complex problem. People currently have to ship HarfBuzz to render text properly on canvas 03:39:53 foolip: it's hard to make accessible 03:40:30 [foolip loads a demo] 03:40:49 foolip: Chrome Canary, you can test this 03:41:10 foolip: What I'm showing here is a bunch of form controls rendered into a . It looks just like if it was rendered outside the canvas. 03:41:18 foolip: The markup is just all the form controls wrapped in a 03:41:27 foolip: And we call JS context.drawElement(...) 03:41:44 foolip: And I can interact with the element, edit the text, interact with the form controls, etc. because the hit testing is wired up to make it work 03:42:01 foolip: Here's a more complicated example, obvious it's not just HTML 03:42:20 foolip: We're seeing some text rotated 30deg. It has alink, Arabic, vertical Chinese, an nline image, svg, emojis, etc. 03:43:27 foolip: Source is just a
with all the text, svg, etc. marked up all inside a 03:44:14 foolip: As you can see, hyperlinks work. You can right-click and save the wolf image here. Everything Just Works! 03:44:33 Brandel has joined #whatwg 03:44:35 foolip: here's another demo. Two cards, one on the left, one on the right. 03:44:52 foolip: In between the cards I've painted a circle. You can mix canvas content and HTML, because your'e drawing these things. 03:44:58 foolip: That's the point. 03:46:14 foolip: We had a proposal to add a specific hit-testing API, but we found a better idea recently, so I will show the source 03:46:35 foolip: Source is the two cards, each is a
that's the child of the 03:47:03 foolip: By default, all elements are painted at the top left (0,0) so if we want them elsewhere we have to move them. 03:47:32 foolip: We draw the element, adjust by devicePixelRatio, and then use a CSS transform property to move it. 03:47:47 foolip: But this is something, we would like to just call getTransform and have it do the right thing 03:48:06 foolip: But need to work on this. Set up the transform automatically when you call drawEleentImage or something 03:48:49 foolip: Hoping to also discuss the internals of this, implementation concerns in other engines to make this work 03:48:56 foolip: Want to discuss hit testing and the processing model. 03:49:10 foolip: This paints the element immediately, and then you can read back the pixels, so you need a clean layout state 03:49:30 foolip: Given how we expect devs to use it, we don't think it's going to be a problem, since theyr'e likely to use resizeObserver etc. 03:49:39 foolip: But there's some concerns around timing 03:49:42 q+ 03:49:46 q+ 03:49:50 q+ 03:49:51 foolip: So that's the demo! Let's do some discussing! 03:49:57 ack next 03:50:01 masonf: how are the elements exposed in the AT tree? 03:50:01 masonf: Can you talk a bit aobut how the elements are exposed in the a11y tree? 03:50:33 foolip: Both hit testing and a11y tree, there's an opt in here. There's a new attribute on the element (currently called 'layoutsubtree'). The attribute lets us change some defaults. 03:50:50 foolip: if you use the attribute, everything will be hit tested, and everything will be exposed to a11y tree 03:50:53 q+ to ask about how content outside of HTML-in-canvas is exposed to accessibility, canvas fallback content 03:50:59 q? 03:51:01 masonf: Only children, or all? 03:51:11 q+ 03:51:13 foolip: Problem is we can't know when you stop drawing an element 03:51:27 foolip: So rather than putting it in the a11y tree and hit testing when you draw it 03:51:37 foolip: Would need to hide it or something 03:51:37 q+ to ask about accessibility hit testing (if Jamie didn't already) 03:51:46 foolip: We want a very strong incentive to keep that subtree in sync with reality 03:51:51 q+ 03:51:54 foolip: ... 03:52:12 foolip: Making them hit-testable, people will be more likely to notice there's a problem and remove them from the tree as they should. 03:52:16 q- 03:52:19 ack next 03:52:42 emilio: Seems to assume you can paint on main thread with all the CSS rendering, and do synchronously 03:52:47 ... it constrains how you can implement it 03:53:11 ... We've made a lot of effort to move a lot of rendering to the GPU, and this prevents or causes a synchronous round trip to compositor, which is not great 03:53:15 ... forces us to draw on main thread 03:53:20 jugglinmike has joined #whatwg 03:53:22 ... Definitely better than what people do now for small stuff 03:53:30 ... but if point of this API is to make these interactive use cases very easy to do 03:53:36 ... people will inevitably use it for a lot of interactive stuff 03:53:45 ... and problem with canvas is then you need to repaint every frame 03:53:53 ... and you don't get a lot of the painting optimizations you'd otherwis eget 03:54:11 ... I think it would be better if we came up with a way that you could still draw the element on the compositor 03:54:24 ... It's annoying for WebGL, because you need the texture size up from, but seems workable 03:54:39 ... API shape would need to change 03:54:56 ... but if you say hey, drawElement, it could stash a reference ot the element in a way and re-use the normal rendering pipeline to eventually get that into the 03:55:10 ... That's a bunch of constraints like you can't immediately read pixels... 03:55:28 jake: [missed] 03:55:48 s/[missed]/why does it need to be synchronous? 03:55:50 emilio: also the fact that you're supposed to draw the element in the current state that you need to paint. You drawElement and then change innerText. Can't wait for regular rendering to update 03:56:04 ... want to use the same compositing round trip 03:56:10 foolip: Would love to hear from other impls 03:56:33 ack next 03:56:46 smaug: cross-origin iframes creates a problem 03:56:51 ... not even painting, but just hit-testing is an issue 03:57:03 foolip: What should happen is having no effect that you can observe 03:57:12 ... should be as if not there 03:57:26 schenney: In Chrome right now cross-origin iframes are not drawn and not hit-tested 03:57:27 ack next 03:57:28 Jamie, you wanted to ask about how content outside of HTML-in-canvas is exposed to accessibility, canvas fallback content 03:57:44 ???: So it's hit-testable the same way normal HTML is hit-testable. That would translate to a11y just fine 03:57:52 q+ 03:58:01 ... But ocntent outside the HTML canvas, not accessible. Except fallback which is not hit-testable 03:58:16 ... If we are seeing more content insied HTML that's not accessible, seems a problem 03:58:21 s/???/Jamie 03:58:32 q+ lunch 03:58:34 foolip: Do you mean for cases that mix fallback content and rendered content? 03:58:42 Jamie: [missed explanation] 03:58:52 ... Seems like we'd get only half the accessibility 03:59:00 foolip: Let's say it's complicate, and game with WebGL menu 03:59:02 I can answer to some extent. 03:59:06 q- 03:59:06 ... you'd have a problem with how to expose those bits 03:59:26 Jamie: We'd say the stuff inside is accessible, but not the other stuff 03:59:34 foolip: Expose other content 03:59:39 Jamie: Then you'd have a hit-testing problem 03:59:48 Jamie: We need to solve this one way or another. Happy to be part of the conversation. 04:00:02 foolip: People talking about using this, use case where you have UI drawn in canvas is not that big 04:00:08 ... more like text with some graphical effects 04:00:18 Jamie: Yes, but if people can use it they wil 04:00:48 schenney: Follow up on a11y 04:00:52 ... we definitely won't be making it any worse 04:01:08 ... One advantage of hit-testing canvas children is that you're more likely to notice if your fallback content is incorrect because you'll hit-test it 04:01:19 ... Weak argument but worse to not see at all 04:01:29 ack sc 04:01:35 ... If you want HTML to stack right to hit test, you'd need to put some DIV or something to represent the canvas in the middle 04:01:44 ... You will need some text to put in that node to put in that drawn layer 04:01:47 ... So that will also help 04:01:59 ... By no means do we claim this will fix all the canvas a11y problems, definitely more to be done there. 04:02:09 ack nt 04:02:32 ntim: I heard some talk around cross-origin iframes. Are there any security considerations? 04:02:47 jake: Anything sensitive isn't drawn. Cross-origin images, iframes, not drawn. 04:03:24 foolip: [shows spec] This is list of things we would not draw: cross-origin data, system colors, spelliing and grammar markers, search text, visited link info, autofill info 04:03:25 q+ 04:03:33 jake: You lose functionality if you paint a form 04:03:50 q+ 04:03:55 foolip: A little bit yes, but with ?? options is to build everything with JS or they use system theme color in those form previes 04:04:09 ... but we're building form for other peopel to use. If it has default style, it's stil lusable 04:04:12 ... But [missed] 04:04:30 emilio: Is the attack here being able to read the pixels, or more subtle like timing attack? 04:04:43 ... As a developer it might be a good compromise to ... 04:05:01 ack em 04:05:07 ... similarly, async thing, that needs to prevent readback, but that forces you to keep your ocntent unmodified if you want it to be drawn 04:05:23 ... otherwise your hit testing breaks, if you drawElement, change content, and drawElement again 04:05:40 foolip: Issue is you can't taint WebGL. It goes into a shader, can extract information 04:05:47 ... So we want to work without tainting first 04:05:54 ... but open to a tainting mode 04:06:06 ... but trying to make as useful as possible without tainting, and it looks like we can get pretty far 04:06:25 ack zc 04:06:29 zcorpan: Have you thought about not leaking sensitive info injected by web extensions? 04:06:35 +1 zcorpan 04:06:39 schenney: I'd have to think about that 04:06:51 chrishtr: If injected into DOM, the site can read it anyway 04:06:58 emilio: Could put it into a closed shadow root 04:07:23
04:07:57 rrsagent, make minutes 04:07:58 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 04:39:27 daniel-mac has joined #whatwg 04:42:58 Penny has joined #whatwg 05:03:34 daniel-mac has joined #whatwg 05:18:58 daniel-mac has left #whatwg 05:21:26 Adam_Page has joined #whatwg 05:21:29 noamr has joined #whatwg 05:21:42 present+ 05:22:19 jan has joined #WHATWG 05:26:03 Jxck has joined #whatwg 05:28:43 topic: Some recent Naivgation API spec issues 05:29:48 present+ 05:29:54 rrsagent, make minutes 05:29:56 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 05:30:12 topic: Some recent Navigation API spec issues 05:30:14 topic: Some recent Navigation API spec issues 05:30:18 rrsagent, make minutes 05:30:19 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 05:31:44 westbrook has joined #whatwg 05:31:49 noamr5 has joined #whatwg 05:33:35 smaug: Navigation API is part of Interop 2025 05:34:02 chikamune has joined #WHATWG 05:34:05 smaug: it's been in the spec many years as well as some tests 05:34:18 smaug: however, those tests don't _always_ match the spec 05:34:37 mjackson has joined #whatwg 05:34:40 smaug: specifically in some timing issues 05:34:57 q+ 05:35:27 smaug: how do we ensure that when we write tests they follow the spec and how do you get right to submitting an issue when we find issues with the spec 05:35:38 q- 05:36:00 smaug: is there something in our processes that do not require us to review the tests that we write? 05:36:13 smaug: are we not following the active changes of the specs over time? 05:36:51 domfarolino has joined #whatwg 05:37:03 anne: we mainly trust the implementation process, which isn't always great 05:37:31 zcorpan has joined #whatwg 05:37:35 anne: sometimes even coverage isn't sufficient to follow the actual implementation/spec in other implementations 05:38:05 q+ 05:38:11 q+ 05:38:31 anne: these cross implementation processes are hard, so following the other engines in their native processes can be awkward 05:38:49 smaug: what can each of our orgs do to make this easier for other teams 05:39:14 smaug: this has shown itself in various recent things, not just the Navigation API spec 05:39:33 anne: in this case, maybe it was igalia that did much of the early implementation 05:39:54 anne: webkit maybe simply followed the tests when they came behind 05:40:03 q+ 05:40:07 ack next 05:40:36 noamr: when we make tentative tests into non-tentative tests, maybe this is a better point to align across implementors and spec on these features 05:40:46 miketaylr has joined #whatwg 05:40:50 noamr: coverages, correctness, etc. before getting into phase 3 05:41:12 noamr: it's possible in large specs like Navigation API might not be possible to fix 05:41:18 q+ 05:41:24 noamr: the bigger the change, the bigger the chance for human error 05:42:02 noamr: the first implementation has a large number of interaction loops (internal, with the spec, with origin trials, etc) that can lead to misalignment in general 05:42:19 ack next 05:42:31 anne: I've seen the same with Scoped Custom Element Registries, being ahead of others at implementation time can be difficult 05:42:58 foolip: chromium looking into what a "comprehensive test suite" looks like in ensuring that their contributions are hitting some similar bars in this area 05:43:06 foolip: can share examples 05:43:17 anne has joined #whatwg 05:43:48 foolip: experimentally, I've attempted to use AI to test alignment between specs and WPT tests that reports bugs, misalignments, etc as a high level comparison 05:44:13 foolip: won't internalize how things work or intersect with each other, but can call out "ooopsies" around things not tested, etc. 05:44:23 Jayson has joined #whatwg 05:44:37 foolip: possible that this sort of process with even a 20% failure rate would be a good step up from current approaches 05:44:55 example report from the AI tool: https://gist.github.com/foolip/cfa35117bb379b8b0f3bfc1b49d1119e 05:44:55 ack next 05:45:23 saku has joined #whatwg 05:45:37 zcorpan: if there's a review item that involves relating changes in the implementations back to spec issues/changes that would be helpful 05:45:52 zcorpan: maybe as implementation gets further from the core of a team this isn't happening quite as much 05:45:54 sakito has joined #whatwg 05:46:09 zcorpan: less likely to happen during incubation time 05:46:10 This is the kind of prompt that I used, which also includes our WIP definition of "comprehensive test suite": https://gist.github.com/foolip/2cb9484572fa5f5c2fa0c632d5719771 05:46:26 ack next 05:46:47 smaug: mozilla has started doing line by line comments around what they've implemented and how it related to the spec 05:47:16 domfarolino: trying to pair fast iteration locally with tests in WPT 05:47:40 domfarolino: this API is huge and the fact that it came together with just 14 bugs is great 05:47:58 smaug: yes, but why was the next implementor required to open them 05:48:14 smaug: realized this reality quite late in the process 05:48:35 domfarolino: did Chromium maybe not run into the same issue that Gecko did during implementation time 05:48:54 domfarolino: did igalia do most of the implementation? 05:49:03 Penny has joined #whatwg 05:49:15 q+ 05:49:18 anne: igalia not here after most of the work, but webkit follow behind what was there 05:49:23 q+ 05:49:28 ack next 05:49:53 mjackson has joined #whatwg 05:49:53 foolip: in interop when tests are in a specific area that don't match the spec then we take them out 05:50:17 foolip: there's a test change proposal process for changing them and keeping them, but start with getting them off the sheet if they're not inline with the spec 05:50:36 foolip: that doesn't resolve the larger interop problem between the implementations 05:50:58 smaug: should we then exclude these 7 failing tests? 05:51:15 smaug: would the 4 after that need to change? 05:51:32 smaug: foolip: shared an additional test beyond that that is misaligned 05:52:17 smaug: the spec is very clear, but the tests are testing chromium's implementation 05:52:34 smaug: there's an extra microtask in the implementation there 05:52:50 q? 05:52:52 q+ 05:53:08 noamr: I wanted to make sure that I agree with that process because it is the only spec'd case where there's only one microtask instead of 2 05:53:35 noamr: we can decide on either, no strong opinnion 05:53:43 Penny has joined #whatwg 05:54:03 ack next 05:54:15 miketaylr: this process issue, is it more acute during "Interop" or is it general across other APIs 05:54:48 smaug: see trusted types, even though there were a lot of tests, they we're all in alignments/passing in implementations 05:55:10 miketaylr: can we then simply correct the tests 05:55:29 anne: sometimes yes, but that hurts "Interop" and _sometimes_ web compat. 05:55:41 gorohash has joined #whatwg 05:55:48 noamr: yes, we want to ensure that following the spec allows for not breaking compat. 05:56:01 ack next 05:56:25 foolip: have you submitted PR with the changes required to match the spec? 05:56:38 foolip: that would be needed at some point. 05:57:07 foolip: you might just merge the PR, and if it just gets blocked on interop the team will review it on about the weekly basis 05:57:15 foolip: there's less paper work that way 05:57:39 anne: if you do that, if you upstream updated tests from your local implementation doesn't that cause issues? 05:57:55 foolip: we have this with chromium, things being blocked for a week aren't that big of a deal 05:58:01 anne: what if there are further tests? 05:58:16 foolip: harder, requires the team to interceed, but doesn't happen that much 05:58:42 noamr: the removal of "waitforall" woudl likely be best at the Interop level, so we have time to confirm we don't break compat 05:59:08 noamr: we can find the places that require the current timing and x-browser confirm their reliance on it 05:59:22 zcorpan: we've run similar and not found issues so far 05:59:51 foolip: is the issue that waitforall is one microtask or two? 06:00:00 noamr: alters the order of events and nativations 06:00:13 zcorpan: especially if you have two sync navigations 06:00:24 zcorpan: changes the communicated results of the algorithm 06:00:33 noamr: but still mostly an edge case. 06:01:00 noamr: feels a little better running through these things together 06:01:09 s/noamr/smaug 06:01:22 smaug: we'll submit PRs removing these tests 06:01:43 noamr: not failing sites that use these APIs make removing these from Interop feel good. 06:01:49 foolip: then can we just change the tests? 06:02:02 noamr: change the tests and exclude them! 06:02:18 jugglinmike has joined #whatwg 06:02:29 mjackson has joined #whatwg 06:03:17 present+ 06:03:20 noamr4 has joined #whatwg 06:03:25 ScribeNick noamr4 06:03:52 topic: Optimization to avoid duplicate navigations 06:03:59 scribenick: noamr4 06:04:10 q? 06:04:14 Rakina: Rakina from Chrome, optimizing navigations 06:04:18 kouhei2 has joined #whatwg 06:04:27 ... navigation, and soon after another one 06:04:57 ... potentially wasteful. first request sent, second is a dup 06:05:17 ... proposal is to not waste the ongoing navigation. based on some criteria 06:05:28 ... url, initiator, cookies, headers, start delta within a timeframe 06:05:52 ... decreases the response from the server. decreases latency 06:06:18 ... we see decreases in exact duplicates, server responses that were never shown to the user (tested by a beacon) 06:06:41 ... various approaches on how to do this; ignoring the 2nd nav entirely; this is web observable 06:07:22 ... e.g. webdriver events, service workers, navigation timing timestamps, click handler fired twice but navigated once 06:08:04 ... opt-in? URL with specific params? headers? needs to be before. URL 06:08:43 ... approach 2: transform the first nav to be the 2nd nav. pretend that the first cancel the first nav, but really ignore the 2nd and transform the 1st to the 2nd 06:09:14 ... can also be weird if fetchStart/navigationStart are flipped 06:09:34 ... approach 3: network layer. cancel the 1st navigation but pass the network pipe to the second navigation 06:09:37 q+ 06:09:55 ... can be kind of like prefetch 06:10:05 ... complex in spec/impl 06:10:18 ann has joined #WHATWG 06:10:18 anne: how is this different from 2? 06:10:33 rakina: it's updating the properties of the navigation 06:10:54 ... in all those approaches SW is not visible 06:11:10 ... wanted to get some thoughts 06:11:12 q+ 06:11:33 ... which layer? navigation layer? network layer? criteria? 06:12:05 sisidovski7 has joined #WHATWG 06:12:08 ... same URL, referer, history, GET, <=3s, cookies 06:12:19 ack next 06:12:34 domfarolino: 1 vs. 2, we're still dropping one of the navs. 06:12:45 rakina: 1/2 mostly matters in implementation 06:12:51 q+ 06:13:13 rakina: for (2) we actually cancel the 1st navigation 06:13:41 domfarolino: (1) seems more logical. it's weird to cancel the 1st 06:13:55 ... hard to judge the differences 06:14:30 anne: all this only applies before the navigaiton is committed 06:14:43 domfarolino: with (3) what would be the navigation timing 06:14:50 ... do we get 2 results? 06:15:01 rakina: it's only visible once you committed 06:15:15 e.g. fetchStart 06:15:16 q+ 06:15:32 rakina: maybe (1) is the simplest approach 06:16:00 anne: the problem with (1) is that the cookie check is async 06:16:22 domfarolino: either way it would be parallel 06:16:34 ack next 06:16:41 smaug: about the problem itself, I wonder if this is just a UI issue 06:16:53 ...: you probably don't know that you're navigating/loading anything 06:17:09 q+ 06:17:32 rakina: might be. sometimes it's a matter of milliseconds 06:18:20 rakina: we collect the timestamps when initiating the navigations 06:18:24 ack next 06:18:25 euclid: so usage statitics? 06:18:27 rakina: yes 06:18:50 zcorpan: in option 2/3 re. navigationStart, would it be from the 2nd navigation in (2) (3) and the 1st navigation for (1)? 06:19:10 ack next 06:19:11 rakina: we might need to expose navigationStart 06:19:12 scribe+ cwilso 06:19:40 noamr: specwise we can do this already, deal with it as if it was the HTTP cahce. 06:20:11 ... someplaces we do things differently, since fetch doesn't specify exactly what the cache is. 06:20:24 ...in some case, the response might not be there already. 06:20:35 ...it's vague what's happening in HTTP cache. 06:20:55 zcorpan: it's the model with the cache, stored with the full response, use it while streaming 06:21:11 noamr: I guess that's not allowed in the model, but that's what we want, too. 06:21:44 sisidovski has joined #WHATWG 06:21:47 ... it would look like there are two separate fetches, the second would be an immediate navigation.that would expose that it wasn't immediate. 06:22:18 ... I think we should do something similar to option 3. there are some places where in flight you could call this...??? 06:22:34 ...preloads are before service workers. 06:22:52 anne: fetch describes fetch layer and network layer separately. 06:23:19 noamr: with preload specifically it doesn't do another fetch 06:23:43 ack next 06:23:58 maybe pretend that the first navigation was a nav prefetch 06:24:05 LeoLee has joined #whatwg 06:24:05 kouhei: strong for option (1) is that it's most straightforward 06:24:39 kouhei: service worker is before HTTP cache, so it would be before SW, so a new cache layer 06:24:50 ... so my preference would be option (1) 06:25:17 domfarolino: also for option 1 06:25:31 zcourpan: we can pretend it's a speculationrules prefetch 06:25:39 zcorpan: only in the web exposed sense 06:26:45 zcorpan: like option (1), and add activationStart for the timing of the 2nd navigation 06:27:08 domfarolino: what does webdriver do? 06:27:21 zcorpan: if we cancel (2), it would look like the 2nd nav was cancelled 06:27:40 domfarolino: why expose it as a prefetch? 06:27:59 zcorpan: it's the closest thing I could think of 06:28:50 domfarolino: I think we should cancel the 2nd navigation and point navigation timing to the 1st. It's the most consistent 06:29:26 rrsagent, make minutes 06:29:28 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 06:29:32 anne: could we race the navigation? do you have metrics like network topology changing between navigations? What if the user ends up pressing refresh? Is that a bypass? 06:30:03 rakina: there is a time threshold 06:30:05 kouhei has joined #whatwg 06:30:13 q+ 06:30:45 ack next 06:31:24 kouhei: can we leave some of this to be implementation defined? 06:31:33 domfarolino: I would be fine with that 06:31:41 ^ specifically about the timing threshold 06:31:43 zcorpan: I prefer it to be specified and interoperable 06:31:53 zcorpan: might be web compat issues 06:32:55 takashi: what if the nav opens a new tab 06:33:03 rakina: we check if the frame is the same 06:33:47 domfarolino: can we resolve on option 1, and try to spec that with some threshold we agree on later in an offline discussion? 06:34:40 rakina: currently it applies also to programattic navigations 06:35:20 domfarolino: we should not do this for user-involved navigations 06:35:56 anne: not sure about that 06:35:59 q+ 06:36:04 cwilso: let's follow up on this as a detail 06:36:24 https://github.com/whatwg/html/issues/11819 06:36:56 anne has joined #whatwg 06:37:05 Topic: Allow deferring commit of a same-origin cross-document navigation 06:37:17 scribenick: anne 06:37:18 scribe+ 06:37:18 https://github.com/w3c/csswg-drafts/blob/main/css-view-transitions-2/two-phase-transition-explainer.md#allowing-the-author-to-control-the-commit-scheduling 06:38:16 [noamr explains the link above] 06:38:59 westbrook has joined #whatwg 06:40:33 q- sisi 06:40:48 noamr: we want to experiment with pre-rendering the subsequent document in the background 06:40:53 rrsagent, make minutes 06:40:56 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 06:41:48 noamr: and we want to let the old document delay the navigation commit so it can finish some processing 06:42:07 noamr: all of this with the goal of reducing the transition time between two same-origin documents the end user navigates between 06:43:41 YY has joined #WHATWG 06:44:33 tnak has joined #WHATWG 06:45:57 anne: with the possible usage example, how does the deferCommit know when the next document is ready? 06:46:10 noamr: it doesn't, it only renders a skeleton 06:47:03 noamr: this is not directly related to view transitions, but it's useful for view transitions 06:47:11 q+ 06:47:22 noamr: as. they're the only API that let's you customize the navigation experience 06:47:30 ack next 06:47:53 sisidovski: what's nextDocumentReadyToRender? 06:48:06 noamr: I think bfcache or pre-rendered 06:48:17 kouhei has joined #whatwg 06:48:52 jake: what happens if you go back, as now the skeleton would be there which makes the document unusable 06:49:01 noamr: example is incomplete, you'd need to do more 06:49:26 noamr: could use some improvement 06:50:37 Takeshi(?): do you have more future plans or if you just want to do this we could also extend view transitions? 06:51:21 noamr: you might want to defer for non-UI reasons, such as storing app state 06:52:26 noamr: I'll make it a proposal and propose for Stage 1 06:53:46 Penny has joined #whatwg 07:09:17 Penny has joined #whatwg 07:11:28 tantek has joined #whatwg 07:12:34 Jxck has joined #whatwg 07:28:17 Jxck has joined #WHATWG 07:30:50 jugglinmike has joined #whatwg 07:32:16 Adam_Page has joined #whatwg 07:32:18 present+ 07:32:37 anne has joined #whatwg 07:32:43 scribe+ 07:32:46 topic: Out-of-order HTML streaming #11542 07:32:47 LeoLee has joined #whatwg 07:32:55 rrsagent, make minutes 07:32:56 I have made the request to generate https://www.w3.org/2025/11/11-whatwg-minutes.html cwilso 07:33:10 topic: out of order html streaming 07:33:13 github: https://github.com/whatwg/html/issues/11542 07:33:40 ann has joined #WHATWG 07:34:42 Penny has joined #whatwg 07:34:49 presenting https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md 07:34:55 noamr has joined #whatwg 07:35:00 https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#interleaved-patching 07:35:03 jan has joined #WHATWG 07:35:09 zcorpan has joined #whatwg 07:35:37 noamr: this is about out of order streaming, discussed at WHATNOT a few times 07:35:43 ... a lot of frameworks / websites do 07:36:03 ... they put some parts of the HTML first, and as the server knows more stuff they bring that stuff in 07:36:17 ... right now that works with inline script tags and such, which is not as fast as it should 07:36:28 ... so would be good if sites wouldn't have to reinvent it 07:36:41 ... we settled on this approach, a placeholder with contentname 07:36:48 ... and a template with contentmethod attribute 07:37:12 ... the internal children would have the same tagname and contentname, and children would stream directly into the placeholder 07:37:23 ... forcing the same tagname causes the parser not to change considerably 07:37:31 ... don't have to change raw text or anything like that 07:37:36 ... we have 4 content methods 07:37:46 ... replacechildren, replacewith, prepend and append 07:37:55 kouhei has joined #whatwg 07:37:59 ... this is about it in terms of content for the first iteration of it 07:38:07 Steven has joined #WHATWG 07:38:12 foolip: [screenshares example] 07:38:17 hsivonen has joined #whatwg 07:39:09 q+ 07:39:27 foolip: lots of internal details we could talk about 07:39:28 q+ 07:39:38 scribe+ 07:39:40 q+ 07:40:04 emilio: in this replace example, would you actually replace the domnode or just change the attributes? 07:40:45 foolip: we have this wireframe example with the classname 07:40:59 rniwa has joined #whatwg 07:41:05 ... and replace would end up "removing the attribute" 07:41:14 ack em 07:41:30 ack next 07:41:43 q+ 07:42:01 anne: This would change the node identity 07:42:04 emilio: that was the question, thanks 07:42:18 westbrook: you can get this by attaching a shadow root on the body and attach out of order content via slots 07:42:47 noamr: that solves only some of the use cases 07:42:53 westbrook: what's the use case for append / prepend 07:42:54 q+ 07:43:46 Incrementally streaming unknowably many children into the content, interleaved with streaming to other content 07:44:16 ann: can you elaborate on the slot stuff? 07:44:38 emilio: you can have a shadow root on the with different s and stream the body content into each slot separately 07:44:50 ... which achieves the same thing 07:44:50 keithamus has joined #whatwg 07:45:02 ack next 07:45:14 JakeA has joined #whatwg 07:45:18 YY: looks like this example the parsing comes before 07:45:23 ... we try to do the patching after the rendering 07:45:27 Example of the above shadow DOM approach: https://ooo.lamplightdev.workers.dev/ 07:45:29 ... and patching would change the contents 07:45:46 foolip: you mean after the document would be parsed already? 07:46:04 noamr: Rendering can happen during this time, but if you finished parsing already you can't [...] 07:46:26 ... we first had it as one proposal, with javascript streaming, which would do what you want 07:46:40 ... we made those proposal totally different in terms of spec or api 07:46:58 foolip: for your use case just keeping the stream open for longer would be more useful 07:47:13 q+ 07:48:02 YY: I want to just render a template but after rendering patching the contents 07:48:05 ... is that supported? 07:48:18 noam: As long as the response didn't close yes 07:48:38 ... whether that's the optimal architecture vs closing and starting a new stream not sure, not opinionated 07:48:54 foolip: you could combine it with the JS API to stream templates to modify the existing document too 07:49:03 ... and use the same markup 07:49:05 ack next 07:49:12 q+ 07:49:19 rniwa: one question, in the example you had a template element instead of an