| 00:58 | <MikeSmith> | https://stackoverflow.com/questions/52791470/how-to-package-or-import-html-templates-without-html-imports |
| 14:11 | <annevk> | So I want to add rel="" to <form> |
| 14:11 | <annevk> | Should I recast <form> as a hyperlink? |
| 14:11 | <annevk> | That seems pretty reasonable from my perspective, but maybe folks think that's nonsense? |
| 14:12 | <annevk> | Domenic: MikeSmith: ^^ |
| 14:12 | <nox> | annevk: I’m going to push a PR to the insert algo of the DOM spec either later today or next week. |
| 14:12 | <annevk> | nox: sounds exciting |
| 14:13 | <nox> | annevk: https://gist.github.com/nox/0bb2a3f5f0223b3ec273d97d586db7eb |
| 14:13 | <nox> | According to a pedantic reading of the spec, that should log null. |
| 14:13 | <nox> | Err, a collection of length 0 |
| 14:14 | <annevk> | nox: oh, so that's a pretty complicated issue |
| 14:14 | <nox> | annevk: Is there an issue already? |
| 14:14 | <nox> | Safari seems to follow the spec and the others not. |
| 14:14 | <annevk> | nox: https://github.com/whatwg/dom/issues/575 and variants |
| 14:15 | <annevk> | nox: it basically seems that some browsers have an additional queue to do script things from |
| 14:15 | <nox> | annevk: I see the issue a bit differently. |
| 14:15 | <MikeSmith> | annevk: I think even if the rel="" thing hadn’t come up, it could make sense to recast <form> as a hyperlink |
| 14:15 | <annevk> | nox: I ran out of time/interest last time I attempted to fix it |
| 14:16 | <annevk> | MikeSmith: cool |
| 14:16 | <nox> | annevk: To me it is more about Chrome/Firefox making no difference between two children of a fragment and two children of a div being added to the tree. |
| 14:17 | <nox> | E.g., they don’t run insertion steps etc until every child of the fragment are added to the tree where they belong. |
| 14:17 | <nox> | annevk: It reminds me of a change I did for adopting a node, where a single loop was changed into two separate loops for running the adopting steps. |
| 14:18 | <MikeSmith> | annevk: yeah, since <form> navigates, it also makes sense for to associate link types with it |
| 14:18 | <MikeSmith> | but as far as noopener and noreferrer too, I think those never should have become link types to begin with |
| 14:18 | <MikeSmith> | I realize it’s a lost cause now |
| 14:20 | <annevk> | MikeSmith: it did stray a bit from the original relationship angle, indeed |
| 14:20 | <annevk> | MikeSmith: I guess the main thing we don't want with <form> is for it to match :link and :visited though |
| 14:20 | <MikeSmith> | yeah if you consider that the semantics of putting rel=stylesheet href=foo into a document is that it means the resource at foo is a stylesheet for the document |
| 14:20 | <annevk> | It seems those pseudo-classes are pretty clearly defined in terms of those elements |
| 14:20 | <MikeSmith> | oh |
| 14:21 | <MikeSmith> | right |
| 14:21 | <annevk> | nox: I don't think that's correct |
| 14:21 | <annevk> | nox: the insertion/removal steps are run, but scripts/styles are done later in a separate queue |
| 14:22 | <annevk> | nox: I found a way to observe this difference somewhere, I initially also thought the fix was what you're suggesting there |
| 14:22 | <annevk> | nox: I might be mistaken, it's been a while, but I'm pretty sure it was not that "simple" |
| 14:29 | <nox> | annevk: I think you are mistaken. |
| 14:30 | <nox> | annevk: Let me give you another snippet |
| 14:31 | <nox> | annevk: https://gist.github.com/nox/520dd79ff14023888e6d02f10f800ec2 |
| 14:32 | <nox> | annevk: If it just delayed running the script, wouldn't the element not be upgraded? |
| 14:42 | <annevk> | nox: imagine you insert a document fragment containing an script followed by an iframe, when the script executes the iframe already needs to have its nested browsing context et al created |
| 14:42 | <nox> | annevk: https://gist.github.com/nox/cb5cd57ac2c07966b6f19767a6e29d4e |
| 14:43 | <nox> | annevk: This prints 0 in Safari and 1 in Firefox. |
| 14:44 | <nox> | annevk: AFAIK, changing selectedness of options and whatnot is part of insertion steps, right? |
| 14:44 | <annevk> | I don't know |
| 14:44 | <nox> | https://html.spec.whatwg.org/multipage/form-elements.html#the-select-element:nodes-are-inserted |
| 14:47 | <nox> | annevk: I'll comment with my few snippets. |
| 14:48 | <annevk> | nox: it might mean that none of this quite makes sense, but I'm pretty sure Gecko at least has an additional queue of sorts |
| 14:48 | <nox> | annevk: Yes it does. |
| 14:48 | <annevk> | nox: perhaps it does selectedness differently |
| 14:48 | <nox> | annevk: No, using a additional queue would definitely make the script run after selectedness was handled. |
| 14:49 | <nox> | (Printing 1 means it printed the index after it was handled) |
| 14:49 | <nox> | annevk: I'm looking into that because I randomly found we introduced a similar concept of delaying the execution of scripts in Servo and it doesn't interact very well with insertion steps. |
| 14:49 | <annevk> | I'd be glad if we could sort this out somehow since not having script execution defined is not great of course |
| 14:50 | <annevk> | There's similar issues on the whatwg/html side around the parser and scripts |
| 14:59 | <annevk> | nox: https://github.com/whatwg/dom/pull/576 does indeed have that iframe/script example as to why running insertion steps later doesn't work |
| 15:01 | <nox> | annevk: It is *so* weird. |
| 15:02 | <nox> | annevk: https://gist.github.com/nox/78b0034279dbdc902e2786ee99fee75c |
| 15:02 | <nox> | This prints 1, according to the spec it should print 0. |
| 15:03 | <nox> | Ah never mind, I'm dumb dumb. |
| 15:04 | <nox> | Forgot how promises get run, hah. |
| 15:06 | <nox> | annevk: https://gist.github.com/nox/78b0034279dbdc902e2786ee99fee75c This prints 0/constructed/connected in Safari and constructed/connected/1 in Firefox, which to me makes absolutely no sense. |
| 15:07 | <nox> | 0/constructed/connected, to me, is what the spec currently says to do, |
| 15:07 | <nox> | OTOH constructed/connected/1 sounds really really weird to me. |
| 15:07 | <annevk> | nox: I'm not sure why you keep referencing the spec, it's not reliable for these things |
| 15:08 | <nox> | annevk: Sure, let's forget about the spec! |
| 15:08 | <nox> | annevk: Do you have any clue why Firefox and Chrome would construct/connect the custom element before being able to say there is 1 custom-element in the tree? |
| 15:09 | <nox> | annevk: AAAAAH, ignore me. |
| 15:09 | <nox> | annevk: Never realised that defining a custom element would upgrade every existing element which was already in the tree… |
| 15:09 | <nox> | That explains a lot. |
| 15:09 | <annevk> | nox: define() runs [CEReactions] |
| 15:09 | <annevk> | nox: right |
| 15:10 | <nox> | annevk: I referenced the spec because it doesn't seem to me like Safari isn't aligned with it in any circumstance. |
| 15:11 | <nox> | annevk: But the latest issue you linked with style/script does show that Safari doesn't follow the spec in that case, so thanks. |
| 15:12 | <annevk> | nox: it seems to me the spec is broken for several cases, also iframe/script |
| 15:12 | <annevk> | nox: hmm, maybe not for iframe |
| 15:20 | <nox> | annevk: https://github.com/whatwg/dom/pull/576 |
| 15:21 | <nox> | "annevk requested a review from nox on 21 Feb 2018" 😂 |
| 15:22 | <annevk> | nox: aha, now I don't even have to apologize for leaving this unsolved |
| 15:25 | <nox> | annevk: Hah! |
| 16:02 | <annevk> | Domenic: if you could have another look at revising event loops that'd be great |
| 16:03 | <annevk> | Domenic: another thing I thought of is that we could require 1:1, but allow user agents (when it's safe) to block one loop on another via a line of prose |
| 16:03 | <annevk> | Domenic: that would simplify the spec model and also give us a way out for worklets |
| 16:04 | <annevk> | Domenic: and to be clear, the reason I'm working on event loops is primarily to get rid of unit of related browsing contexts and friends |
| 16:04 | <annevk> | Domenic: it's effectively the last major dependency on that |
| 16:17 | <Domenic> | annevk: I'll try to find time before the weekend. |
| 16:17 | <Domenic> | I'll be sure to run your new idea past our implementers, but so far they have preferred a spec that reflects implementations, and I think that is the correct priority of constituencies even if one that is more theoretically pure would make our jobs as spec authors simpler. |
| 16:17 | <annevk> | Domenic: thanks, would be nice to be able to get back to it directly after |
| 16:18 | <annevk> | Domenic: note that currently we already have different loops for worklets and windows |
| 16:18 | <annevk> | Domenic: unless they want to write a patch that fixes that, I think my approach is the only way forward there |
| 16:19 | <Domenic> | Yeah, lots of confusion caused by that already, unfortunately :( |
| 16:19 | <annevk> | Domenic: unless you want to block the refactoring on me fixing a bug someone else introduced, which seems rather unfair |
| 16:19 | <annevk> | Domenic: and at that point I'd like some kind of escalation of talking directly to the people involved |
| 16:19 | <Domenic> | Heh, isn't it you who always says we should fix our foundations before building on them? |
| 16:21 | <annevk> | Domenic: so yes, but 1) I still don't really see this as being problematic 2) I think unit of related browsing contexts is a far bigger problem and worth fixing sooner |
| 16:22 | <Domenic> | Sure, we all have different priorities. |
| 16:23 | <annevk> | Domenic: that's rather dismissive |
| 16:23 | <Domenic> | No, I'm just saying, please try to see both sides. |
| 16:23 | <annevk> | Domenic: so why isn't Google putting resources into fixing the worklet mess? |
| 16:24 | <annevk> | Domenic: afaik only Google is shipping worklets... |
| 16:24 | <annevk> | Domenic: maybe we should take that out instead? |
| 16:24 | <Domenic> | I'm finding this conversation unproductive and hard to deal with first thing in the morning, and I have a meeting in 5, so I would ask that we resume it at a later time. |
| 16:25 | <annevk> | Domenic: I basically only have European office hours |
| 16:29 | <astearns> | annevk: could you summarize or send pointers to explain "the worklet mess"? I haven't been following what's getting messed up there |
| 16:30 | <annevk> | astearns: basically, must worklets always be concurrent, or not? I think it depends on the type of worklet, but the spec gives them all the same concurrent event loop |
| 16:30 | <astearns> | thanks |
| 16:31 | <annevk> | astearns: however, if they'd sometimes have to share a window event loop, that would undermine a bunch of infrastructure, which makes assumptions about window event loops (currently browsing context event loops) |
| 16:32 | <annevk> | astearns: and I think it's more complicated, it's that in principle they're allowed to be concurrent, but some types are also allowed to be interweaved |
| 16:32 | <annevk> | (but eg audio is prolly not, at least, that'd seem bad) |
| 16:42 | <annevk> | Domenic: so would it work if we kept the existing wording, except replaced it to say similar-origin window agent, and leave the security issue and worklets as a follow-up? |
| 16:42 | <annevk> | Domenic: then there wouldn't be a regression |
| 16:44 | <annevk> | Domenic: anyway, it would be good to know what exactly would unblock this since I'm not really sure what to do given the current text and the problems I keep running into with it and thus far you haven't really gotten concrete |
| 16:44 | <annevk> | Domenic: and despite this apparently being a priority for Google I don't see any issues about it, which is odd? |
| 21:04 | <TabAtkins> | annevk: form-as-hyperlink reads well to me. I... *may* have done exactly that to get a POST-ing "link" before... |
| 21:31 | <annevk> | TabAtkins: 🎉 |
| 21:34 | <annevk> | I’m somewhat surprised this analogy has not been made before |
| 21:58 | <TabAtkins> | A <form action=GET><button /></> and an <a /> are basically identical semantically. |