WHATWG
2023-10-13
plaintext logs
prev next
source on github
05:45
<sbastiandev>
Hi all,
05:48
<sbastiandev>
I wanted to let you guys know that I open-sourced a Java implementation of WhatWg-Url. It passes relevant Web platform tests (url parsing, setters) and is up to date with the September 2023 spec. Any feedback is more than welcome ;) over here=> https://github.com/stephanebastian/whatwg-url
06:03
<Domenic>
That's great!!
06:33
<sbastiandev>
Thx 😃
07:07
<sideshowbarker>
I wanted to let you guys know that I open-sourced a Java implementation of WhatWg-Url. It passes relevant Web platform tests (url parsing, setters) and is up to date with the September 2023 spec. Any feedback is more than welcome ;) over here=> https://github.com/stephanebastian/whatwg-url
I may end up wanting to switch the https://validator.w3.org/nu/ HTML checker to using your implementation rather than the one we are currently using — https://github.com/smola/galimatias (which stopped being maintained years ago).
07:08
<sideshowbarker>
sbastiandev: Does yours implement error reporting?
07:09
<sbastiandev>
Whooa cool ! :)
07:09
<sbastiandev>
For error reporting there is the method Url.validationErrors() returning all validation errors or failures
07:10
<sideshowbarker>
Thanks, I see https://github.com/stephanebastian/whatwg-url#how-to-get-validation-errors now
07:16
<sbastiandev>
sideshowbarker: Obviously, dont't hesitate to contact me if you've got remarks/questions/feedback or ideas for improvements
07:23
<annevk>
sbastiandev: minor nit, we prefer WHATWG, all capitals (it stands for Web Hypertext Application Technology Working Group, but like W3C it's mostly used as its own "word")
07:29
<sbastiandev>
annevk: Sure, I updated the README, should be ok now. Thanks
10:26
<smaug>
keithamus: that relatedTarget issue is interesting. Maybe invoke event should use different name for that, since I think we don't want the event propagation to stop at shadow boundary
10:27
<keithamus>
Yes I was just commenting in the issue smaug; I think it's okay because the invoke event doesn't bubble by default and so if you force it with manual dispatch in userland then you'll be dealing with the caveats that come with it. There is precedent of this behaviour with focusin/focusout which does bubble and also has a relatedTarget and so sometimes won't propagate across the shadow boundary.
10:28
<smaug>
bubbling isn't interesting
10:28
<smaug>
(I mean, there is always capture phase)
10:29
<keithamus>

For me the important use cases (slash my opinions on this) are:

  • invoke dispatches in light dom as you'd expect
  • a button invoking into a shadowroot shouldn't really be possible
  • a button within a shadowroot invoking an element outside the shadowroot should be possible, but the relatedtarget should be retargeted to the host
10:31
<smaug>
A question is that if invoke is dispatched to a shadow element, should the user of the web component be able to call preventDefault()
10:31
<keithamus>
They should
10:32
<keithamus>
But I believe an invoke event can only be dispatched to a shadow element from a shadow element in the same tree, or a tree within that tree.
10:33
<smaug>
I don't think any other cancelable event has .relatedTarget
10:33
<keithamus>
Does that become a problem?
10:34
<smaug>
Just that this is a new case
10:35
<smaug>
What if you explicitly set invokeTargetElement to point to some element in another shadow dom?
10:35
<keithamus>
My opinion is that I am okay with that not working.
10:36
<keithamus>
I think shadow->"light" light->"light " and sub-shadow->shadow should work but adjacent shadow trees or light->shadow seems like an odd thing to do, IMO.
10:37
<keithamus>
in other words the "shadow-including inclusive ancestor" rule applies, I believe.
10:38
<smaug>
So the user of a web component couldn't prevent invoke if it was triggered inside the shadow dom, but can if it was triggered outside
10:38
<smaug>
Isn't that a bit odd
10:39
<keithamus>
Are the two mutually inclusive? Does cancelable relate to the event's path?
10:40
<smaug>
outside world can't get access to the event to cancel it
10:40
<smaug>
so yes, they are related
10:40
<keithamus>
I see, that's why I think it shouldn't dispatch from within a shadow tree. Only from outside
10:41
<smaug>
What you mean with "shouldn't dispatch from within a shadow tree" ?
10:42
<keithamus>
A button with an invokeTargetElement pointing to an element inside of a shadow tree that is not an inclusive ancestor should be a noop
10:44
<keithamus>
<button> <div> <template shadowrootmode=open> <dialog> </template> </div>

^- it should not be possible to wire the button up to the dialog.

<dialog> <div> <template shadowrootmode=open> <button> </template> </div>

^- it should be possible to wire the button up to the dialog here

10:44
<smaug>
So having a shadowroot with two child elements, one button which has invoketargetElement pointing to the other one. That wouldn't work?
10:44
<keithamus>
Within a shadowroot it should be possible
10:45
<keithamus>
<div> <template shadowrootmode=open> <button> <dialog> </template> </div> ^- it should be possible too wire the button up to the dialog
10:45
<smaug>
right, but user of the web component can't cancel invoke
10:45
<smaug>
in that case
10:45
<keithamus>
Oh, the user as in the consumer of a third party WC?
10:46
<smaug>
So user of the web component could cancel some invokes, but not others
10:46
<smaug>
right
10:46
<keithamus>
I wonder if that's okay...
10:48
<keithamus>
the user of the web component could cancel invokers if they happen outside of the shadow tree, but they'll never see invoke events from within shadow trees. If a web component author wanted to allow control they'd need to dispatch a separate event for that
10:48
<keithamus>
or... is the click event composed+bubbles? They can prevent that to prevent the invoke
10:48
<smaug>
bubbling doesn't matter 😉
10:48
<smaug>
click is composed
10:48
<keithamus>
yes sorry
10:49
<keithamus>
so the way to cancel an invoke (per current design) would be to cancel the click
10:49
<smaug>
well, if they then need to use click, we end up using the old style events, and not invoke.
10:49
<keithamus>
I believe this relates to the discussion we had at TPAC then ;)
10:50
<keithamus>
Do you have a resolution in mind? We could make the invoke composed? Would that suffice?
10:53
<smaug>
Would it be bad to have something else than .relatedTarget? Perhaps .invoker or some such which does itself get the usually retargeting when accessed, so that we don't leak anything from possible shadow DOM. But the event itself wouldn't have related target to stop propagation.
10:53
<smaug>
Since I thought invoke would be something which could be used to replace click usage
10:54
<keithamus>
This is specifically because of 5.9.7 and the fact that the name relatedTarget is intrinsic to the event dispatch algo?
10:55
<smaug>
not perhaps the name, but the concept
10:55
<smaug>
but yes
10:57
<keithamus>

The nice thing about relatedTarget is that it aligns nicely to the existing concepts I had internalized around focus/mouse events. I can envision a conversation in the future telling a developer that even though it behaves very similarly to relatedTarget it is called something different because of a very specific rule in the dispatch algo.

But if that's necessary then that's necessary.

10:58
<smaug>
But if it didn't work like mouse/focus events in event dispatch, then it would be rather inconsistent and would be hard to explain how event dispatch works
10:58
<keithamus>
yes that's also true
10:59
<smaug>
Are there reasons why invoke propagation should stop at shadow boundary?
10:59
<smaug>
and if so, why it is ok that click does propagate through?
10:59
<keithamus>
I don't have a strong stance, and so I'm quite happy if it does propagate.
11:01
<keithamus>
If we change from relatedTarget will this require changes to the event dispatch specification to allow for re-targeting of the new property?
11:02
<keithamus>
Because the property will be dependent from where the event listener resides, no?
11:03
<keithamus>
I suppose the new property can make that affordance in the get steps?
11:14
<smaug>
it is not about dispatch but accessing the property would need to go through https://dom.spec.whatwg.org/#retarget
11:15
<smaug>
so, similar to many other properties
11:15
<keithamus>
given the currenttarget and the invoker?
11:15
<smaug>
yeah
12:25
<canadahonk>
If a lazy loading iframe has a different base URI at parse-time, then is set as eager loading later before becoming in view, should it use the now current base URI (I think this) or the base URI from parse-time? (Double checking as adding WPT for it)
12:35
<annevk>
canadahonk: I thought Dominic Farolino had tests for this already; the setup should be such that the base URL is determined at parse-time
13:05
<canadahonk>
canadahonk: I thought Dominic Farolino had tests for this already; the setup should be such that the base URL is determined at parse-time
No tests for lazy -> eager checking base URI (sorry for taking long, Matrix died)
13:13
<annevk>
canadahonk: it's still parse time per https://html.spec.whatwg.org/#attr-iframe-loading
13:13
<annevk>
canadahonk: because you use the resumption steps
13:14
<canadahonk>
thanks!