WHATWG on 2022-08-23

02:39	<Lorin>	Are there plans to allow the pseudo-element `content` prop to use `var()` in its value - so I can set a piece of content much higher in the DOM chain and display it?
02:41	<Lorin>	at the moment it's a bit limited with just `attr()`
06:48	<Kaiido>	But then doing something as simple as `input.oninput = (evt) => { evt.preventDefault(); input.value = input.value.toUpperCase(); }` would end up in an infinite loop unless you had super complicated/ugly machinery to avoid it. If you need ComponentB to let the other scripts know that it made some changes, it can still dispatch the event manually.
08:24	<Jake Archibald>	Kaiido: in your example, some piece of code wants to ensure the input text is uppercase. Presumably, that's true regardless of whether the input is from the user, or programatic from some other piece of code. Relying on that other piece of code to pretend it's user input is hacky.
08:25	<Kaiido>	But that's not the point. The issue is that if the script does the change in response to the event it will itself trigger the same event.
08:26	<Jake Archibald>	It is the point 😀. The model is bad because it works in some cases but not in others.
08:26	<Kaiido>	To know if an event came from the user or from a script we have the isTrusted property.
08:27	<Jake Archibald>	`BroadcastChannel` works really well here, since each component can have its own instance. Compare this to storage events which have the same global problem.
08:29	<Jake Archibald>	To know if an event came from the user or from a script we have the isTrusted property. It isn't as black and white as that. Something can be started by user input, and then modified by script. So the origin of the change is still the user, but it's been influenced by script. `isTrusted` is more useful to know if the event is directly from the browser, but I don't think that helps in the case we're talking about
08:29	<Kaiido>	Ok, so you're saying the whole EventTarget model is broken. I think I could agree with that. But firing events from script changes on that model without changing it all won't work.
08:30	<Jake Archibald>	I'm not saying the whole `EventTarget` model is broken. I just pointed to `BroadcastChannel` as working well, and that uses… `EventTarget`
08:30	<Kaiido>	I highly doubt the one precedent details created is something we should follow.
08:31	<Jake Archibald>	It isn't one precedent. There are many events on the platform that are script-triggered
08:31	<Kaiido>	But it works well because each component can have its own target. right?
08:32	<Jake Archibald>	Yes. And the input case (and similar cases like storage events) work badly because it assumes that it's owned by one component
08:33	<Jake Archibald>	It's better to fire change events when things are changed, then provide a way to avoid firing events, for changes that are transformations of changes.
08:35	<Jake Archibald>	The `formdata` event on forms is a good model here. There, listeners make modifications via the event itself. It's built for transforming the user input, so it works well for transformations.
08:37	<Jake Archibald>	An equivalent would be an event on `<input>` where the new value could be transformed by listeners on the event object itself. That way, it's clear it shouldn't fire an additional change event, since the change is being made as part of the event.
08:43	<Kaiido>	I must admit I'm not as familiar with all these APIs as you are. For instance if by "storage events" you talk about the onstorage one, do you mean it's broken because we could for instance access the other page's handler from a `window.open()` call? That sounds like a far more complicated way to shoot you in the foot than my input.value example. And unfortunately I think that even with a new event like the one you propose where the value is passed and transformable from the event itself, it would still be very easy to shoot ourselves in the foot by using the input's `.value` there too. Btw, is it possible to change the form's formdata from outside of the event?
09:22	<Jake Archibald>	I do mean `onstorage`. If `localStorage` is used to store state, and ComponentA makes a change, ComponentB doesn't find out about it if they're in the same window.
09:22	<Jake Archibald>	is it possible to change the form's formdata from outside of the event? Well, you can change form inputs, which are later used to create the `FormData` object.
10:24	<Kaiido>	is it possible to change the form's formdata from outside of the event? Well, you can change form inputs, which are later used to create the `FormData` object. But you're not modifying the same FormData object, only a future one.
10:31	<Kaiido>	Ok, I guess I can see the point. I still believe dispatchEvent is a quite ok workaround for that case though. Moreover if that would mean that the same component had to filter out the events it did trigger.
11:36	<Jake Archibald>	Kaiido: I think you only need to filter it out in the circular case, where the change is in response to the change. Take the Navigation API https://developer.chrome.com/docs/web-platform/navigation-api/ - this works really well because there's one central place to handle navigations, regardless of whether the navigation was caused by script or directly by the user. This is one of the things that makes the Navigation API easier to use than the old History API, where your logic ends up split depending on how the navigation was triggered.
15:59	<annevk>	sideshowbarker: I filed a ticket with DreamHost for html5.org, seems it affects all my sites
16:00	<annevk>	sideshowbarker: we could potentially keep the existing domain name but point it to GitHub for hosting...
23:29	<Kaiido>	I didn't had the occasion to play with this new API yet, so pardon my ignorance here. From fast-reading your article, doesn't this model work well because it's assumed that a single point will handle all these events? I have the feeling this model wouldn't scale very well for the case of two different components trying to handle events on a single target either. I made a very quick test and it seems that two intercept handlers could actually run at the same time, in parallel, without any apparent way of knowing that the event was already intercepted. Did I miss something there? Shouldn't `.intercept()` at least set the `defaultPrevented` to true or a new `isIntercepted` flag? I now see this was discussed in #89 and #94 to some extents (based on the previous `respondWith()` model), but I don't see any mention of letting the other handlers know they're not alone. One could still append that flag on the event manually, but that requires coordination. Also, I don't have a use-case for this, so you may very well just ignore me ;-)