| 00:43 | <jmdyck> | The second-most-recent commit in HTML main added a reference to undefined insertedOption in https://html.spec.whatwg.org/#concept-option-disabled. I guess it's supposed to be just option? |
| 00:45 | <jmdyck> | ^ @jarhar ? |
| 06:38 | <annevk> | nicolo-ribaudo: thank you, that makes a lot of sense! There's a proposal for declarative CSS modules and the proposal is currently to represent style type=module element as data: URLs in the module map. But that requiring that representation (due to it being observable) seems highly inefficient for implementations. |
| 06:42 | <annevk> | jarhar see jmdyck's comment above ^^ |
| 06:46 | <annevk> | zaggy1024: I would file an issue. The processing model for media elements leaves a lot to be desired in general. |
| 06:58 | <nicolo-ribaudo> | nicolo-ribaudo: thank you, that makes a lot of sense! There's a proposal for declarative CSS modules and the proposal is currently to represent |
| 07:00 | <annevk> | Yeah, it would have to be something like that. Or we allow for the module map to contain element references or some such. Either way it will be more involved to define, but should be doable. |
| 10:53 | <annevk> | I wonder if people will use HTML patching to workaround limitations imposed by insertion modes. E.g., it would allow giving a tr element a custom element child. It'd be very cumbersome to write, possibly more cumbersome than writing the equivalent script, but it would be possible. |
| 11:01 | <Noam Rosenthal> | We could probably disable that option if it's important. When we open the template we know where the content is going to, and there is a finite number of insertion modes |
| 11:04 | <annevk> | I think making the template element even more complex parsing-wise would be something we will regret. (Although maybe we have to do it at some point for SVG.) |
| 11:06 | <Noam Rosenthal> | Maybe... though it's only for template with contentfor. At least in the blink prototype so far this is pretty well contained within "patching" |
| 11:07 | <Noam Rosenthal> | Specifically, we could make it so that https://html.spec.whatwg.org/multipage/parsing.html#clear-the-stack-back-to-a-table-context fails the patch if it reaches a <template contentfor> when popping. We could apply this kind of behavior in all of those special cases and in general stop patching in certain scenarios |
| 11:10 | <Noam Rosenthal> | One of the main advantages for using <template> is that the default behavior in browsers that don't support patching is a noop and that it's already set up to be a container for any other content (pretty much). Also it's in the spirit of the element, something that holds HTML content that's supposed to be used elsewhere. |
| 11:13 | <annevk> | It does raise a question as to what the API ends up doing for these cases. |
| 11:15 | <Noam Rosenthal> | I think that if you see this: <table> <tr contentname="some-tr"> </table> <template contentfor="some-tr"> <td>new-content</td> <tr><td>Another row</td></tr> </template> you should end up with: <table><tr contentname="some-tr"><td>new-content</td></tr></table> <template contentfor="some-tr"> <tr><td>Another row</td>\/tr> </template> |
| 11:16 | <Noam Rosenthal> | (the moment something fishy comes up parser-wise, patching terminates and the rest proceeds as a normal template) |
| 11:18 | <Noam Rosenthal> | (sorry element is botching my markup) |
| 11:18 | <annevk> | That would be very different from how template works today. Today the tr start tag would be ignored. |
| 11:19 | <Noam Rosenthal> | That's also an option, perhaps better |
| 11:21 | <Luke Warlow (ooo till 20th)> | Sorry slightly tangential but should the attribute be contentid instead of contentname, other for attributes work with IDs so it might feel wrong that is for a name? |
| 11:21 | <Noam Rosenthal> | but yea, <template contentfor> parses differently than template because it uses the target as a context node of sorts. |
| 11:22 | <Noam Rosenthal> | It's more similar to form elements etc where it's not necessarily unique. But we can bikeshed it |
| 11:22 | <Luke Warlow (ooo till 20th)> | I think making the |
| 11:26 | <Noam Rosenthal> | annevk: a solution we thought about at some point is to force having a tag name identical to the target element at the beginning of the template to set the context. This way there is even less of an exotic parsing mode. But it's also a bit less ergonomic |
| 11:27 | <Noam Rosenthal> | ... this would also fix the "patching into script" issue |
| 11:29 | <Noam Rosenthal> | e.g.: <script contentname=myscript></script> <template contentfor=myscript> <script> console.log("This is the new content of myscript"); </script> </template> |
| 11:56 | <Noam Rosenthal> | Or even have it so that the template only has "contentmethod" and everything else is in the direct children: <table><tr contentname="my-tr"></table> <template contentmethod="replace-children"> <tr contentname=my-tr> <td> <!-- the following would not go into "my-tr" as it would be parsed as being a direct child of the patch without contentname --> <tr> </template> |
| 12:03 | <Noam Rosenthal> | (Come to think of it, this is perhaps a better design... much less exotic changes to template, only the "contentmethod" attribute that diverts the insertion point) |
| 12:44 | <annevk> | Noam Rosenthal: yeah, that might be a better shape. Need to think about it a bit. |
| 12:45 | <Noam Rosenthal> | will do the same, thanks! |
| 12:47 | <annevk> | Noam Rosenthal: what do you mean with contentname not being unique btw? What happens if there's a duplicate? |
| 12:49 | <Noam Rosenthal> | It's not necessarily unique in the document. Since patching is scoped to the parent of the template, the first element in tree order within that scope would be selected |
| 12:50 | <annevk> | Gotcha. Though is it tightly scoped or only for the initial search? |
| 12:50 | <Noam Rosenthal> | It is searched once when the patch is discovered |
| 12:51 | <Noam Rosenthal> | (which also makes it different from all the existing IDREFs) |
| 12:51 | <annevk> | <html><head contentname=blah><body><template><head contentname=blah> would fail then? |
| 12:56 | <Noam Rosenthal> | patches that are direct children of the body are special-cased to be document-scoped |
| 13:07 | <Noam Rosenthal> | We can also avoid both contentname and contentid and call it contentoutlet. |
| 13:52 | <annevk> | contentwendys (sir this is the HTML standard) |
| 14:24 | <jarhar> | thanks! https://github.com/whatwg/html/pull/11772 |
| 14:54 | <Luke Warlow (ooo till 20th)> | Is this something we can have tooling to check for? Feels doable now we have the algorithm scopes. |