| 09:58 | <kraftwer1> | Kaiido, Jake Archibald I've just found out that even this static HTML <details open> already fires an event. |
| 09:59 | <kraftwer1> | Jake Archibald: do you know of any other HTML elements that fire events on programmatic changes? I'm specifically asking for elements, not "non-element" APIs like Navigation, LocalStorage, etc. |
| 10:03 | <hsivonen> | I suppose I will have to look at engine compat anyway regarding https://github.com/web-platform-tests/wpt/blob/master/FileAPI/url/sandboxed-iframe.html , but surely it's not OK for a test that doesn't specifically test how srcless iframe behaves to depend on what happens to happen between the iframe insertion and the subsequent script execution. |
| 10:22 | <Jake Archibald> | kraftwer1: close on <dialog>. load and error on lots of elements. Lots of events on <video> and <audio>. Even more fire events in response to method calls, like focus(), blur(), click(), selection changes etc etc. |
| 10:43 | <Domenic> | Indeed, I think almost all events on elements are in response to programmatic changes, with the exception of <input> and other form controls which have very unusual behavior. |
| 10:46 | <Domenic> | I suppose I will have to look at engine compat anyway regarding https://github.com/web-platform-tests/wpt/blob/master/FileAPI/url/sandboxed-iframe.html , but surely it's not OK for a test that doesn't specifically test how srcless iframe behaves to depend on what happens to happen between the iframe insertion and the subsequent script execution. |
| 10:47 | <hsivonen> | It just seems like the test is assuming some basic conformance to other areas of specs? Similar to how it assumes that, e.g., JS syntax works as specced. I don't see anything "not OK" here; it's not like the test is assuming some specific implementation-defined behavior. |
| 11:12 | <kraftwer1> | Domenic Jake Archibald Thanks!
|
| 11:18 | <Jake Archibald> | I imagine it was because of the infinite loop issue. My preference would be to always fire 'change' events when things change. And, to avoid the infinite loop case, provide a way for values to be transformed during a single change. Fwiw, I don't think the toUpperCase() example does infinite-loop, since on the second run, it wouldn't result in a change. |
| 11:24 | <kraftwer1> | (...is there even any infinite loop case?) |
| 11:25 | <Jake Archibald> | You could .value += 'YAY', but I can't think of a real-world case |
| 11:46 | <annevk> | I think <details open> is indeed special and there is an existing issue on it. There's no other parser input that fires an event like that. |
| 11:53 | <kraftwer1> | Jake Archibald: agreed. Oh and btw. close on <dialog> doesn't fire (it's even mentioned in the spec), however close() does... |
| 11:54 | <Jake Archibald> | Ahh yeah, I should have put that under "method calls" |
| 12:45 | <Kaiido> | Yes, IMM all the focus(), blur(), click() and al. are very different in that they can be seen as wrappers around a call to dispatchEvent(). I think it's semantically quite obvious. If such a call was hidden inside the .value setter that would be a lot more obscure. load, error and media events are completely unrelated, they are for most triggered by network responses or something alike, not by script per se... I still do believe <details> and its attribute reaction is pretty unique here, and I still doubt it's a model that should be followed. |
| 13:10 | <kraftwer1> | numericInputEl.stepUp() doesn't fire "input" (probably being a form element with "unusual behavior") |
| 13:13 | <kraftwer1> | Ok thanks a lot to all of you participating. I think I've stolen enough of your precious time. My initial motivation was to understand the whole underlaying concept. But I think there's none. Honestly I think the spec of <details> is ambiguous. It doesn't clearly say an event should be fired on programmatic change - and it also doesn't clearly say otherwise. To sum up I conclude that there are simply different tags with different behavior. |
| 13:15 | <Jake Archibald> |
I think the spec is pretty clear here. https://html.spec.whatwg.org/multipage/interactive-elements.html#details-notification-task-steps |
| 13:16 | <Jake Archibald> | It says the event should be fired "Whenever the open attribute is added to or removed from a details element" |
| 13:17 | <Jake Archibald> | The spec doesn't need to say "even if the change is programmatic" any more than it needs to say "even if it's raining outside" |
| 13:18 | <kraftwer1> | Jake Archibald: not to me. It handles "task queue" and how to handle coalescing. The dialog spec is much more clear: https://html.spec.whatwg.org/multipage/interactive-elements.html#the-dialog-element |
| 13:20 | <Jake Archibald> | The close steps of <dialog> don't say "even if the change is programmatic" either https://html.spec.whatwg.org/multipage/interactive-elements.html#close-the-dialog |
| 13:21 | <kraftwer1> | Jake Archibald: true, but it says it indirectly on when an event is not fired. |
| 13:23 | <Jake Archibald> | You mean the non-normative note? |
| 13:26 | <kraftwer1> | "To honor a request for the information to be hidden, the user agent must remove the open attribute from the element." --> the specs talk about what the "user agent" must do "Whenever the open attribute is added to or removed from a details element" --> here's my misunderstandig. As a reader, I'm still in the context of "what the user agent must do". I have no implication that the writer of the spec now also talks about the "program". But yes I guess we could argue back and forth to what is clear or not. :-) |
| 13:28 | <Jake Archibald> | Yes, IMM all the selectionchange firing when the content of a <textarea> changes, and changes the current selection? |
| 13:29 | <Jake Archibald> | kraftwer1: the user agent is the browser. I'm not sure what the "program" is |
| 13:29 | <kraftwer1> | Jake Archibald: the program is dialogEl.open = true |
| 13:30 | <Jake Archibald> | kraftwer1: Script runs in the user agent |
| 13:30 | <Kaiido> | How do you feel about the |
| 13:33 | <Jake Archibald> | kraftwer1: specs don't really say what your script should do, they say what the user agent (browser) should do in reaction to your script, or in reaction to other things like user interaction, OS interaction, etc etc. |
| 13:37 | <kraftwer1> | Jake Archibald: totally understand your point. Unclear whether you understood mine. As a reader of both the specs it was obvious to me what the intention of the event was for dialog. Not so much about details. Yes, it was only a non-formative note. Maybe I'm the only one affected by this, so consider it a nevermind. |
| 13:44 | <Jake Archibald> | Yeah, I was just pointing out that specs don't need to say that an event must happen even if the change is programmatic. The normative spec should be clear about the cases where the event fires. Eg, the setter for .value does not fire events https://html.spec.whatwg.org/multipage/input.html#dom-input-value |
| 13:53 | <kraftwer1> | Ah look at the very bottom of the page you've linked: "[...] without having to then filter out the script's own changes to avoid an infinite loop.)" ==> I'd really wonder about this infinite loop case. |
| 22:06 | <sideshowbarker> | annevk: https://annevankesteren.nl/ timing out |