| 01:42 | <Domenic> | I tend to feel multiple methods is nicer. Minimizing the number of methods doesn't seem like an important goal to me. |
| 07:13 | <Noam Rosenthal> | If we go all the way with multiple methods, it would be something like this: setHTML setHTMLUnsafe streamHTML streamHTMLUnsafe htmlBefore htmlBeforeUnsafe streamHTMLBefore streamHTMLBeforeUnsafe appendHTML appendHTMLUnsafe streamAppendHTML streamAppendHTMLUnsafe |
| 07:13 | <Noam Rosenthal> | (not saying it as something good vs bad) |
| 07:46 | <Noam Rosenthal> | Added this as an alternative in the OP |
| 09:41 | <Luke Warlow> | I tend to feel multiple methods is nicer. Minimizing the number of methods doesn't seem like an important goal to me. I think minimising the number of legacy methods we create should be taken into account. .innerHTML had to be replaced for setHTMLUnsafe so it could take arguments. But if we have existing functions upgrading them rather than replacing would seem good. Else we'll have a lot of widely used but at least partially duplicated methods. |
| 09:48 | <Luke Warlow> | Is it also worth considering stuff like https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/srcdoc that can't be sanitized yet. There's also https://w3c.github.io/editing/docs/execCommand/#the-inserthtml-command which can do a partial replacement. |
| 09:56 | <Domenic> | Why would we create legacy methods at all? Just create new non-legacy methods. |
| 10:03 | <Luke Warlow> | Why would we create legacy methods at all? Just create new non-legacy methods. |
| 10:03 | <Noam Rosenthal> | That would happen regardless of how many methods we're adding though |
| 10:04 | <Domenic> | Oh I see. I don't personally think that's a great idea, since the existing functions are pretty messy. |
| 10:04 | <Luke Warlow> | That would happen regardless of how many methods we're adding though |
| 10:05 | <Luke Warlow> | Oh I see. I don't personally think that's a great idea, since the existing functions are pretty messy. Yeah that is fair, it might be that it just isn't doable. Just think it's worth considering and maybe noting that as a deliberate decision |
| 10:06 | <Noam Rosenthal> | There's a lot of discussio nabout this in https://github.com/whatwg/html/issues/10122 |
| 10:07 | <Noam Rosenthal> | (insertAdjacentHTML is the only thing that's being "deprecated", as innerHTML is already kind of deprecated by setHTML and setHTMLUnsafe) |
| 10:07 | <Luke Warlow> |
|
| 10:08 | <Noam Rosenthal> | execCommand hooks into createContextualFragment |
| 10:09 | <Noam Rosenthal> | which I guess is also kind of deprecated by setHTML |
| 10:09 | <Luke Warlow> | execCommand hooks into createContextualFragment |
| 10:10 | <Luke Warlow> | It'll be similar regardless I guess |
| 10:10 | <Noam Rosenthal> | I guess having multiple methods with different APIs feels like it might get messy again, and might feel messy for developers in terms of discovery and linting. |
| 10:12 | <Noam Rosenthal> | They're built in a way where they all receive the same options dictionary for sanitation etc. so it should be OK, but I'm ambivalent about whether it feels nicer |
| 10:13 | <Noam Rosenthal> | It is nice that for the simple case we don't have to create a dictionary in terms of overhead |
| 11:47 | <Noam Rosenthal> | OTOH devs mostly dislike catch-alls like splice and reduce and the 4-method version is a bit like those |
| 11:50 | <Noam Rosenthal> | btw it might end up being 20 methods: (prepend/append/before/after/replace) * (stream/set) * (safe/unsafe) setHTML htmlBefore htmlAfter appendHTML prependHTML streamHTML streamHTMLBefore streamHTMLAfter appendHTMLStream prependHTMLStream (each with a *Unsafe version) |
| 11:54 | <freddy> | Question about streaming HTML parsing and edge cases. Right now, when you parse something like <table><b><tr><td>aaa</td></tr>bbb</table>ccc , the parser moves the <b> before the table element. (https://html.spec.whatwg.org/multipage/parsing.html#unexpected-markup-in-tables). How would that behave? If the "table" is already created, could that cause issues if the parser later on creates another element that is placed before it? |
| 11:55 | <freddy> | I think the more general question is: how much interactivity can we allow with the elements that have been received piece-by-piece over streaming? It seems to me that interacting with the context element (eg. body) or the table and b elements might be rather dangerous, as long as we are uncertain of the resulting tree structure |
| 12:00 | <annevk> | I don't think 20 methods would be a big deal, but the positional arguments enable use cases that the 20 methods would not, which make me a bit torn. But maybe they can be addressed by multiple method calls instead. |
| 12:03 | <Noam Rosenthal> | We can have additional 4 for splicing a range, with 2 arguments outside the dictionary (but it might not be that necessary/popular) |
| 12:06 | <Noam Rosenthal> | you mean if we allow streaming into an element? It would behave like setting innerHTML directly ("fragment-mode") |
| 12:07 | <Noam Rosenthal> | I think in this case it allows <table><b>...</b></table> |
| 12:08 | <Noam Rosenthal> | ... or expose those 4 in Range |
| 12:10 | <annevk> | Do you have an idea for how you're going to deal with the stack of open elements and the insertion point and such? |
| 12:13 | <Noam Rosenthal> | yea, we've prototyped this and it's not so different from how the fragment-mode parser works today, except the tokenizer is fed incrementally |
| 12:13 | <Noam Rosenthal> | (if this was addressed to me about stream-to-element) |
| 12:13 | <Noam Rosenthal> | ... and the result goes directly to the element and not to an intermediate DocumentFragment |
| 12:17 | <annevk> | Noam Rosenthal: the fragment-mode parser very much relies on the parsing happening in an isolated environment which is then copied over. The details of how this is done do matter quite a bit so when you can share more that'd be great. |
| 12:18 | <Noam Rosenthal> | foolip ^^ |
| 12:27 | <foolip> | Yes, it was not a big change at all in terms of implementation, but we'll have to see if this maps to the spec. |
| 12:28 | <foolip> | The main thing is the addition of the place to insert nodes, of course. |
| 12:29 | <foolip> | But I'm also not sure if https://html.spec.whatwg.org/#the-stack-of-open-elements and https://html.spec.whatwg.org/#the-list-of-active-formatting-elements should start out empty, or if we should make an effort to make it just as if the content was parsed at the insertion point. |
| 12:30 | <annevk> | Has it been fuzzed? Especially with script execution the main parser is extremely tricky. |
| 12:30 | <Noam Rosenthal> | One thing we didn't do in the prototype is streaming "before" something. When there is a "before" the stream is buffered |
| 12:30 | <Noam Rosenthal> | ... and it currently runs with script execution turned off |
| 12:31 | <annevk> | Sure a <script> inserted through this won't run, but scripts can still run presumably as they also called the API? |
| 12:31 | <freddy> | "script execution turned off" meaning that an inline script wouldn't run (similar to innerHTML=). But I would be concerned about existing scripts in the document observing/holding on to an element that is received via streaming |
| 12:32 | <freddy> | I should let anne talk. He's clearly typing faster :) |
| 12:32 | <Noam Rosenthal> | how is that different from inserting those elements separately, or using detached document streaming |
| 12:33 | <annevk> | Because the insertion point and stack of elements can get out-of-sync and such. |
| 12:33 | <Luke Warlow> | I would be worried about the script element protection provided by trusted types too. That has some wonkiness related to scripts that are amended during parse time, which this might run into? |
| 12:33 | <Noam Rosenthal> | yea but that can happen in the main parser as well, right? |
| 12:33 | <Noam Rosenthal> | or when you use detached document streaming or whatever |
| 12:34 | <Noam Rosenthal> | I don't see what fragment parsing has to do with it or what makes this new |
| 12:35 | <annevk> | That's a rather worrisome statement. I guess I'll just wait. |
| 12:57 | <Noam Rosenthal> | annevk: sure; we will share once we have something more concrete |
| 13:02 | <Noam Rosenthal> | Specifically to answer this, the streaming API in chromium (behind a flag) is being fuzzed in the last 2 months or so. We had a couple of crashes early on but nothing "tricky" so far. Of course things could come up down the line. |
| 13:09 | <annevk> | Part of the difficulty here is that the HTML parser is currently rather poorly specified as reusable component. I'm also not entirely sure what happens if you move insertion points between documents today. hsivonen and maybe Jake Archibald prolly do. |
| 13:10 | <Jake Archibald> | I think it executes script, but let me check |
| 13:18 | <annevk> | And you can end up with multiple streams for a single document I guess? I haven't seen that much test coverage for those cases though. |
| 13:19 | <Jake Archibald> | https://developer.mozilla.org/en-US/play?id=QfShUNJ1gJqC4kgSoSDNV%2FsT724NONcZ3SXOv6QogT2hGATvZ2lQtS2hJK7p3MTCy0OeLSAl72JYRZxy - it doesn't execute script. I'm pretty sure it did in Chrome at some point. |
| 13:19 | <Jake Archibald> | Oh, it does execute script in Safari |
| 13:20 | <Noam Rosenthal> | For a single context element you can have one stream at a time, and the next one will abort the old one |
| 13:20 | <zcorpan> | The spec was changed at some point to prevent running those scripts (matching gecko) |
| 13:24 | <annevk> | Noam Rosenthal: I'm just talking about what you can do with the existing setup. (At least that statement was and the one prior.) |
| 13:25 | <Noam Rosenthal> | ah gotcha. you mean if people today would have multiple detached document streams at the same time etc |
| 14:03 | <Jake Archibald> | mfreed: I'm not sure if this should be in HTML or CSS, but there's a difference between the spec and intent here https://github.com/whatwg/html/issues/11694 |
| 15:51 | <hsivonen> | annevk Jake Archibald My recollection is that when the parser was specified, it was specified to execute scripts that ended up in a different document than the one that the parser was associated with, and I wrote code to deal with that case. Then, IIRC, at some point we decided that risks of that complexity were not worth it and that Web compat didn't actually require supporting executing scripts that had moved. |
| 22:54 | <jarhar> | annevk: i think this is ready to merge, barring a webkit objection. want to take a look? https://github.com/whatwg/html/pull/11460 |