WHATWG on 2024-10-31

08:37	<Maxim Vaarwel>	Good evening. Can anyone give some examples of opaque path? The URL spec is stingy on this.
08:39	<Domenic>	Good evening. Can anyone give some examples of opaque path? The URL spec is stingy on this. https://url.spec.whatwg.org/#example-url-components 3rd example
08:43	<Maxim Vaarwel>	Thanks, but I have extra question. Is it possible to use the `new URL` constructor to create a url that will have opaque path in the first argument and base URL in the second?
08:45	<Domenic>	Sure. `new URL("urn:isbn:9780307476463", "https://example.com/")`.
08:49	<Maxim Vaarwel>	Sure. `new URL("urn:isbn:9780307476463", "https://example.com/")`. The result of the URL structure is funny, there is nothing left from the base URL. In any case, thank you very much for such a quick response.
13:00	<Noam Rosenthal>	(and just having consistency is good in general) Perhaps a cleaner take on this would be to wait to fire this event till the next focusing steps, which would be at the next frame (latest). That way we don't bombard with events during DOM ops
13:02	<Noam Rosenthal>	Basically we mark the element as "moved while focused" and in the next focusing steps we use this flag to determine whether the event needs to be fired.
14:31	<Noam Rosenthal>	we don't even have to mark the element, just mark a boolean on the document and read it in the focus fixup
14:31	<smaug>	Not sure which one is easier to understand. Firing asap would be easier to implement, I think (and would be closer to the model focus() has). keithamus might have an opinion. (I don't have a strong opinion)
14:32	<Noam Rosenthal>	I think both would be easy to implement, or at least spec... my worry was having a batch of DOM operations with `moveBefore` inside that end up firing lots of events
14:32	<smaug>	oh, you'd clear the boolean if some other focusing is happening?
14:32	<Noam Rosenthal>	yea
14:33	<Noam Rosenthal>	well, if some other focusing is happening, the new element would get the focus and you'll get a blur
14:33	<smaug>	Are there cases when you do want to know asap if activeElement has changed?
14:33	<Noam Rosenthal>	you can check `activeElement`
14:34	<smaug>	but you don't get any notification it being changed
14:34	<Noam Rosenthal>	I think you can't really rely on this ASAP thing because focus fixup might change things
14:34	<Noam Rosenthal>	and one thing we reallly don't want to do is add forced style calculations
14:35	<Noam Rosenthal>	if you're in frameworks etc, you most likely are doing a batch of DOM operations and then the rendering step would come, you don't need multiple events during the batch
14:37	<Noam Rosenthal>	so I am pretty confident that "eventually" (as in, by the next frame or earlier) having your focus events catch up with your active element is good enough for people relying on these events. But happy to hear keithamus and others of course!
14:39	<smaug>	So document.querySelectorAll(":focus-within") would temporarily be broken?
14:39	<Noam Rosenthal>	yea, but it's temporarily broken today in many cases
14:39	<Noam Rosenthal>	though we can move the `:focus-within` flag synchronously, it's kind of a separate question
14:40	<smaug>	true
14:46	<smaug>	would it be weird to get key events for subtree which hasn't ever gotten focus event? (That might be an issue already in the spec, I need to check in which case the focus stuff runs around rendering update)
14:52	<Noam Rosenthal>	I think you'd need a focus fixup before you can determine who gets the keys anyway
14:52	<Noam Rosenthal>	it would be weird if an element got `display: none` due to a DOM change but you received key events before calculating its style
14:54	<Noam Rosenthal>	the intermediate unfixed focus state is really only for javascript introspection
14:54	<smaug>	But that update doesn't need to happen during rendering update steps
14:54	<Noam Rosenthal>	it can also happen due to calling `focus()`
14:55	<Noam Rosenthal>	but that forces a style calculation and would trigger the focusing steps
14:55	<smaug>	browsers try to dispatch key events before rendering update (or I'm not sure about webkit's scheduling)
14:55	<Noam Rosenthal>	so that would probably need a forced style calc and focus fixup like the one done inside update the rendering
14:56	<Noam Rosenthal>	(we're not adding anything new to that)
14:56	<smaug>	and we'd dispatch focus at that point?
14:56	<Noam Rosenthal>	yea
14:56	<smaug>	that might work
15:00	<Noam Rosenthal>	In HTML spec land, the change would be that when we run the focusing steps, if the target focus element is the current one and we haven't focused since moving the focused element, we first reset the current focused element to the viewport (as if that element was removed). This is simple enough and should cover all the weird cases I think
15:28	<keithamus>	Firing the event some time later seems okay to me. I think practical cases might be for eg wanting to hide UI if focus moves out. That kind of UI change isn’t really impacted by even microtask timing IMO. But not firing at all might break it.