| 07:07 | <kochi> | There are several ways to create HTMLDocument that is not connected to browsing context (e.g. DOMImplementation.createHTMLDocument(), DOMParser API, XHR) but I'm wondering what's the meaningful use case for creating an "HTML document" (vs a DocumentFragment or a plain node tree), where we don't have an API like window.document.swap(otherDocument) or something to display the document. |
| 08:13 | <annevk> | Before JSON documents where somewhat popular to exchange data |
| 08:13 | <annevk> | Still are to some extent I suppose |
| 08:34 | <kochi> | hmm, I see, maybe like XML, or SOAP -like use cases. |
| 08:47 | <annevk> | kochi: yeah, not especially compelling though |
| 08:47 | <annevk> | kochi: I only ever do it myself to test edge cases and break browsers |
| 08:47 | <annevk> | kochi: having said that, I have heard that folks still run into these kind of formats and would actually like to have some kind of DOM in workers... |
| 08:57 | <hsivonen> | Is it possible for an event to fire synchronously while another event's handler is being run? |
| 08:57 | <annevk> | hsivonen: yes |
| 08:58 | <annevk> | hsivonen: e.g., the handler can run obj.dispatchEvent(...) |
| 08:58 | <hsivonen> | annevk: ok, so the window.event stuff should restore the previous window.event afterwards instead of just setting to undefined |
| 08:59 | <annevk> | hsivonen: yeah, I think in review of that PR it was suggested that you store the current value, then set it to the event, then run the callback, then set it to the stored value |
| 08:59 | <hsivonen> | annevk: why is it set and restored for each callback separately? |
| 09:00 | <annevk> | hsivonen: oh, I guess you can do it for a whole currentTarget |
| 09:00 | <hsivonen> | annevk: Is the shadow DOMness not known before the whole capture and bubble stuff starts? |
| 09:01 | <annevk> | hsivonen: it is, that part isn't specced yet |
| 09:01 | <annevk> | hsivonen: basically the whole path is known and it has some annotations about boundary crossing |
| 09:02 | <annevk> | hsivonen: so when you set it to the event it needs to be conditional upon information from that path |
| 09:02 | <hsivonen> | annevk: in that case, it would be really nice the shadow DOMness could be decided using the "target" that Gecko has before it traverses the events path |
| 09:02 | <hsivonen> | oh, it needs information from the path :-( :-( |
| 09:02 | <annevk> | hsivonen: as I understand it Firefox also has the path pre-dispatch |
| 09:03 | <annevk> | hsivonen: perhaps in a different form, but that's basically a per-requisite for many bits of dispatching |
| 09:05 | <hsivonen> | annevk: my problem mainly is that I'm unfamiliar with this stuff, so locating the interesting points of code that are not too soon and not too late isn't obvious |
| 09:06 | <annevk> | hsivonen: okay, as I understand it from Olli we have all the information before we call into JavaScript |
| 09:06 | <hsivonen> | annevk: yeah, smaug____ known this code. I don't. |
| 09:07 | <annevk> | hsivonen: e.g., whether the node we are firing listeners for was in a shadow tree at the time dispatch started |
| 09:07 | <annevk> | hsivonen: based on that we'd like to set window.event |
| 09:08 | <annevk> | hsivonen: the crucial bit here is that if something was in a shadow tree at the time of dispatch and one listener moves it into the main document, when the next listener runs window.event should still be its original value |
| 09:11 | <hsivonen> | annevk: what's "original value"? original as in before the whole dispatch thing or the one decided before the node was moved during this dispatch? |
| 09:12 | <hsivonen> | annevk: Is there a test case for that? |
| 09:12 | <annevk> | hsivonen: I don't know, Mike Taylor wanted to work on this so I haven't been involved much |
| 09:12 | <hsivonen> | annevk: ok |
| 09:12 | <annevk> | hsivonen: if this is high priority suddenly maybe I should take over a bit |
| 09:13 | <hsivonen> | annevk: my understanding is that this is a priority now |
| 09:14 | <annevk> | By original value I meant the value it currently has |
| 09:14 | <annevk> | Basically we only change the value if the current target was not in a shadow root determined at dispatch time before any JavaScript along the path is executed |
| 09:15 | <annevk> | (I tried to look around a bit in Mozilla's event code, but it seems very polymorphic so hard to find the right location for all this...) |
| 09:15 | <hsivonen> | annevk: that suggests the current PR has the setting and unsetting of window.event too deep in the algorithm |
| 09:16 | <annevk> | hsivonen: yeah I recommend not looking at the current PR, especially if you want to consider shadow trees |
| 09:17 | <annevk> | hsivonen: I'll have a look at rebasing the current PR and splitting out srcElement and returnValue, which are now elsewhere |
| 09:17 | <annevk> | I did check with Mike and he seemed okay with me doing some work on window.event |
| 09:19 | <hsivonen> | annevk: in the spec, step 16 checks shadow DOMness |
| 09:20 | <hsivonen> | annevk: Do I understand correctly that `target` may have changed via retargeting after step 11? |
| 09:22 | <annevk> | hsivonen: that question is a bit ambiguous, the target passed to dispatch doesn't really change; but as the event gets dispatched, it might have multiple targets due to shadow trees |
| 09:23 | <annevk> | hsivonen: note that the current spec at https://dom.spec.whatwg.org/#dispatching-events doesn't have a step 16 |
| 09:23 | <annevk> | hsivonen: (it changed a whole lot due to review from smaug____) |
| 09:24 | <hsivonen> | I meant step 16 in the PR preview |
| 09:24 | hsivonen | looks at the actual spec |
| 09:24 | <annevk> | hsivonen: yeah as I said, that PR is out-of-date and needs rebasing |
| 09:24 | <annevk> | hsivonen: I can work on that now |
| 09:25 | <annevk> | This does seem like a fairly complex thing to work on given that other changes (including to Firefox) are also in flight |
| 09:25 | <annevk> | Unless you own all of those changes I think smaug____ should give some specific directions here |
| 09:26 | smaug____ | is |
| 09:26 | <hsivonen> | annevk: I don't own other changes. I basically know nothing other than I'm supposed to make window.event happen |
| 09:27 | <hsivonen> | maybe I should upload my current code |
| 09:42 | <hsivonen> | annevk: there's now code on the bug. It works in the non-shadow DOM case and it checks for shadow DOMness, but it might check for shadow DOMness at the wrong time |
| 10:04 | <annevk> | hsivonen: hmm, the other thing that's worth testing here is how the global object is found |
| 10:05 | <annevk> | hsivonen: e.g. if I run a function in an <iframe> that dispatches an event, which global has its event set |
| 10:10 | <hsivonen> | annevk: also, is window.event supposed to be reachable via the outer window |
| 10:11 | <annevk> | https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5853 suggests yes? |
| 10:13 | <annevk> | https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5854 suggests maybe it's just the target's relevant global object |
| 10:13 | <annevk> | that'd certainly make sense |
| 10:16 | <hsivonen> | OK. That already works with my patch. |
| 10:26 | <annevk> | hsivonen: I updated the PR to be a bit more accurate, the main thing missing is still the shadow tree stuff |
| 10:26 | <annevk> | hsivonen: gonna take a break for a bit and then I'll look into your work on Firefox and the tests and such |
| 10:46 | <annevk> | hsivonen: what does https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5855 do? log the event as well? |
| 10:46 | <annevk> | (tracking that in https://github.com/heycam/webidl/issues/540) |
| 11:25 | <hsivonen> | annevk: the 5855 case logs undefined with my patch |
| 11:26 | <annevk> | hsivonen: that is diff from Chrome, but might be unrelated |
| 11:26 | <annevk> | hsivonen: not clear to me what correct is there |
| 11:27 | <hsivonen> | annevk: OK. I'm not properly familiar with the mechanism that makes WindowProxy work at all with my patch |
| 13:47 | <annevk> | hsivonen: I created a test for moving the element during listener callbacks: https://github.com/w3c/web-platform-tests/pull/10329 |
| 19:03 | <michael2> | hi, can anyone clarify what this sentence in HTML spec on paragraph elements means? |
| 19:03 | <michael2> | "No p element in scope but a p end tag seen." |
| 19:03 | <michael2> | section in docs: |
| 19:03 | <michael2> | https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element |
| 19:05 | <michael2> | sorry I pasted the wrong sentence - I was actually wanting clarification on this sentence: |
| 19:05 | <michael2> | "The solution is to realize that a paragraph, in HTML terms, is not a logical concept, but a structural one." |
| 19:14 | <Domenic> | michael2: I think the note and example nearby that sentence spell it out in more detail |
| 19:22 | <michael2> | they spell out the difference between the specs definitions "logic" and "structure"? I don't see it? |
| 19:23 | <michael2> | I understand "logical" in HTML to be machine parsable information derived from the tags |
| 19:23 | <michael2> | I guess structure is the differnce between a "header" and an <aside> ? |
| 19:27 | <railgun> | michael2: I think you're overthinking it, I can understand the section but I can't understand how you described it |
| 19:28 | <michael2> | ok, thanks |