01:20
<rbyers>
annevk: regarding your question Friday about observing event listeners (sorry I was out for the day): Yes I did update the touch events spec but it's pretty handy-wavy: https://w3c.github.io/touch-events/#cancelability
01:21
<rbyers>
What we actually implement here is pretty special (been this way for ages - passive doesn't change that really) but the other browsers all seem to have similar similarly special (with different details). Rather than explicitly walk the event path as you suggest, we compute layer regions as a list of rectangles and update on layout.
01:22
<rbyers>
This is because the compositor thread doesn't have access to the DOM.
01:25
<rbyers>
For 'passive' the main thing we did was opt-out of this fancy (and somewhat hacky) system and just tracking a single bit indicating that there are passive touch listeners somewhere (to continue to support an additional minor CPU optimization for the case when there are really no listeners at all).
01:26
<rbyers>
We could probably define that in terms of some sort of algorithm on the DOM at event dispatch time, but it would look nothing like the implementation and so be tricky to verify. Perhaps it's more useful to try to define properties of the behavior (and associated web-platform-tests) rather than to try to actually specify an algorithm here?
01:28
<rbyers>
And again, my understanding is this isn't just blink - Safari, Edge and Firefox have something similar with the details depending on the design of each browser's threaded compositing system. So, unlike most of DOM, this is the sort of thing that is probably hard to specify as an algorithm that'll bear any semblance to any mainstream implementation :-)
04:20
<annevk>
rbyers: passive somewhere? But what about a mix of passive and non-passive?
05:11
<annevk>
rbyers: in any event, passive has been great in unblocking some new event listener primitives
06:51
<annevk>
Ms2ger: hey, I want to change the topic again
06:56
<annevk>
GPHemsley: the wiki is acting up, when trying to login I get a cached copy of sorts
06:56
<annevk>
GPHemsley: "This is a cached copy of the requested page, and may not be up to date.", "Sorry! This site is experiencing technical difficulties.", at https://wiki.whatwg.org/index.php?title=Special:UserLogin&returnto=Main+Page
07:40
<annevk>
Why did https://github.com/coonsta disappear?
08:02
<MikeSmith>
annevk: apparently renamed to https://github.com/dominiccooney
08:02
<MikeSmith>
https://github.com/dominiccooney?tab=activity
08:02
<MikeSmith>
I guess github doesn’t automatically redirect in that case
08:03
<annevk>
Ta, that's useful to know
08:35
<annevk>
hayato: hey, if you're still awake could you have one more look at the slotchange issue?
08:36
<annevk>
hayato: I'm going to write a patch for the DOM Standard today
09:04
<annevk>
hayato: thank you!
14:11
<smaug____>
lovely, github has rather horrible bug with lists
14:11
<smaug____>
https://github.com/w3c/webcomponents/issues/184#issuecomment-210474769
14:11
<smaug____>
those numbers aren't 1, 2, 3, 4
14:11
<smaug____>
but 4, 5, 6, 7
14:28
<annevk>
Yeah, noticed that. It's nice if you edit a long list that you don't have to update the following numbers, but if you actually mean a certain number it's a little annoying.
14:38
<annevk>
Teehee, I think slotchange is done
14:38
<annevk>
So tomorrow, shadow event extensions and <slot>, perhaps?
14:39
<annevk>
And then change all the features one-by-one...
14:43
<hsivonen>
annevk: fwiw, I think it's possible to implement the decoders in the Encoding Standard with less buffering that you previously said was needed
14:44
<hsivonen>
annevk: in encoding-rs, I have the capability to unread only the current byte
14:44
<hsivonen>
annevk: in addition to that, I need to have a specialy one-byte "buffer" for gb18030 and ISO-2022-JP
14:45
<hsivonen>
annevk: but in both cases, the value of the byte is pretty restricted, so manually inlining its handling to the top of the decode function is pretty easy
14:47
<hsivonen>
annevk: the key insight is that if there's a bogus byte when gb18030 third is already non-zero, gb18030 second goes into the special one-byte buffer to be output as Basic Latin code point and third becomes first, since the range of third and first is the same.
14:47
<annevk>
jsbell might be interested to hear about that
14:48
<hsivonen>
https://github.com/hsivonen/encoding-rs/blob/master/src/iso_2022_jp.rs#L57 and https://github.com/hsivonen/encoding-rs/blob/master/src/gb18030.rs#L44
14:51
<annevk>
hsivonen: wait, but if you have 3 variables for gb18030 that's more than a two-byte buffer, no?
14:58
<annevk>
I think I see what you mean now. You can only unread, not prepend, so you need an alternative strategy for that
14:59
<annevk>
Maybe we should add the trick to the standard at some point in a note
14:59
<hsivonen>
annevk: the trick is that "third" becomes the new "first" and "second" becomes a "pending ASCII" that's going to get out of the way before "first" is checked for non-zero
15:02
<annevk>
hsivonen: could you comment on https://github.com/whatwg/encoding/issues/42?
15:45
<MikeSmith>
about the design questions for the canvas hit regions API, I would think Rik Cabanier would be the one who knows
15:45
<MikeSmith>
I thought he was the one who specced it
15:51
<annevk>
According to junov Frank was mostly responsible
15:51
<MikeSmith>
ah OK yeah I was just reading more of it
15:52
<MikeSmith>
so I guess if it was Rik that specced it out originally he just did it based on the requirements that had been given
20:01
<smaug____>
is there some way to know which wpt tests are passed by which browsers
20:02
<smaug____>
hmm, or, jgraham_, can I run wpt tests I have in local mozilla-inbound tree using other browsers?
20:25
<jgraham_>
smaug____: You can!
20:25
<jgraham_>
But it's not really a well cleared path :(
20:25
<jgraham_>
smaug____: https://developer.mozilla.org/en-US/docs/Mozilla/QA/web-platform-tests#Chrome has instructions for Chrome
20:26
<jgraham_>
Safari doesn't work afaik
20:26
<smaug____>
ok, let me try
20:26
<jgraham_>
Edge needs some code that never got reviewed
20:26
<smaug____>
pip?
20:26
smaug____
doesn't know what pip is
20:26
<smaug____>
some python thingie I assume
20:26
<smaug____>
oh, I have it
20:34
<smaug____>
jgraham_: is there some way to run just some particular test from github or something like that
20:39
<jgraham_>
smaug____: Pass the path to the test? Or if you are just running a single test and it's already upstream http://w3c-test.org/tools/runner/index.html
20:39
<jgraham_>
Maybe should add that to the wiki
20:45
<smaug____>
jgraham_: I mean without those instructions in MDN
20:45
smaug____
tries http://w3c-test.org/tools/runner/index.html
20:48
<Domenic>
Ooh I didn't know about http://w3c-test.org/tools/runner/index.html. I always just browsed to the HTML files directly.
20:48
<smaug____>
how does one then see which test failed?
20:50
<smaug____>
I guess looking at the json
20:50
<smaug____>
jgraham_: ok, thanks. Verified there is a buggy test. fix it coming to mozilla tree first
20:50
<jgraham_>
smaug____: Thanks!
22:23
<rodneyrehm>
Which part of the DOMTokenList IDL (https://dom.spec.whatwg.org/#domtokenlist) reflects the "tokenlist[index]" shown in the next Note block? is that implicitly defined by .item()?
22:24
<TabAtkins>
rodneyrehm: It has "supported property indices" defined for it.
22:25
<rodneyrehm>
right, second paragraph below the Note box, found it, thanks!
22:25
<TabAtkins>
rodneyrehm: And yeah, the "getter ..." line actually defines it. (And happens to also define that .item() is a method that does the same thing)
22:26
TabAtkins
should linkify "getter" appropriately in Bikeshed.
22:27
<rodneyrehm>
yes please :)