| 00:18 | <smaug____> | interesting. Blink leaks closed shadow DOM via focus event's relatedTarget |
| 00:19 | <smaug____> | it also propagates focus event from shadow DOM |
| 00:24 | <smaug____> | hayato: ^ |
| 00:36 | <smaug____> | some old Safari version has similar issues, but I should update my macbook (which I boot perhaps twice a year :)). |
| 00:39 | <smaug____> | (except that apparently I can't update it. oh well) |
| 01:39 | MikeSmith | discovers https://timothygu.me/es-howto/ |
| 01:40 | <MikeSmith> | bravo TimothyGu |
| 03:30 | <hayato> | smaug____: That's bad news for us. :( Could you share a test case? Does it happen only for focus events? |
| 03:30 | <hayato> | I am assuming it is not spec's issue. It's the bug of the implementation. |
| 05:49 | <annevk> | Krinkle: it is |
| 06:16 | <Krinkle> | annevk: Thx, also, it seems it didn't actually switch protocols. Or at least I couldn't reproduce it. |
| 06:16 | <Krinkle> | So http:foo is the same as 'foo', and ignores http vs https. |
| 06:23 | <annevk> | Krinkle: oh yeah, that is right, no switch in scheme |
| 07:24 | <MikeSmith> | gotta love Crockford’s commit message for the related change |
| 07:24 | <MikeSmith> | https://github.com/douglascrockford/JSLint/commit/0e5065a51a7602499aa500c1db4125145f5dbeb3 |
| 07:24 | <MikeSmith> | one letter |
| 07:26 | <annevk> | That whole commit log is performance art |
| 07:26 | <MikeSmith> | heh |
| 07:26 | <annevk> | And rather useless for future maintainers |
| 07:27 | <MikeSmith> | style trumps utility |
| 07:29 | <MikeSmith> | anyway I hope he can make time to write a new/updated essay about how to fix HTML |
| 07:29 | <MikeSmith> | (speaking of performance art) |
| 07:32 | annevk | finds https://www.crockford.com/html/ |
| 07:33 | <MikeSmith> | holy god it’s been 10 years |
| 07:33 | <MikeSmith> | hard to believe |
| 07:34 | <MikeSmith> | definitely overdue for new one |
| 07:47 | <ricea> | I never realised until now that gzip eliminates the size argument against UTF-8. Obvious in retrospect. |
| 08:34 | <annevk> | It seems we did adopt that one, restricting things to UTF-8 |
| 08:34 | <annevk> | Although it's not enforced |
| 08:35 | <annevk> | ricea: btw, I'm in Tokyo most of next week; I don't think we need to discuss anything in person, but since I'll be at the Google office on Monday and Tuesday for the Web Components meeting maybe we should try and say hi |
| 09:13 | <smaug____> | looks like Safari preview leaks closed shadow dom too via focus event's relatedTarget |
| 09:13 | <smaug____> | or am I testing something wrong http://mozilla.pettay.fi/shadow_focus.html |
| 09:16 | <annevk> | smaug____: yeah, seems like a bug |
| 09:16 | <smaug____> | happens in blink too |
| 09:16 | <annevk> | smaug____: you raised a bug against DOM too about that needing to be redesigned, right? |
| 09:16 | <annevk> | smaug____: that is, more computation ahead of time or some such |
| 09:17 | <annevk> | https://github.com/whatwg/dom/issues/562 |
| 09:17 | <smaug____> | hmm, was it about this |
| 09:17 | <annevk> | no |
| 09:17 | <smaug____> | there is the issue related to touch.target |
| 09:17 | <annevk> | just related |
| 09:17 | <smaug____> | I'm still trying to understand how focus should work |
| 09:18 | <smaug____> | webkit and blink seem to do something very different what is in the specs |
| 09:19 | <annevk> | Sigh, I thought all this had tests |
| 09:19 | <annevk> | Not enough I guess |
| 09:20 | <annevk> | smaug____: if there are no tests for this, feel free to file it as a whatwg/dom issue |
| 09:20 | <smaug____> | well, relatedTarget should be just not exposing shadow DOM |
| 09:20 | <smaug____> | and |
| 09:20 | <smaug____> | where does it say that focus event is composed? |
| 09:20 | <annevk> | smaug____: I guess maybe there aren't tests because it's hard to automate these |
| 09:21 | <smaug____> | perhaps I'm missing the latter thing somewhere |
| 09:21 | <annevk> | smaug____: it should be composed because it's a UI event, but not sure if that's explicitly stated atm |
| 09:21 | <smaug____> | DOM spec explicitly says event shouldn't be composed by default |
| 09:22 | <annevk> | smaug____: yeah, I'll file a bug against HTML to make focus events composed |
| 09:22 | <smaug____> | and https://html.spec.whatwg.org/multipage/interaction.html#fire-a-focus-event doesn't make focus event composed |
| 09:22 | <smaug____> | thanks |
| 09:25 | <annevk> | smaug____: also added you to the whatwg/components team |
| 09:25 | <smaug____> | k |
| 09:26 | <smaug____> | whatever that means :) |
| 09:27 | <annevk> | smaug____: you get more GitHub notifications about custom elements / shadow tree related issues |
| 09:27 | <annevk> | (your welcome) |
| 09:27 | <annevk> | 😛 |
| 09:28 | <annevk> | Hmm, now I'm reminded we still haven't defined focusin/out |
| 09:29 | <smaug____> | there we'll need to follow the broken model now implemented I guess in all the engines |
| 09:29 | <smaug____> | and not the reasonable model IE had |
| 09:32 | <annevk> | At least everyone agrees they are composed |
| 09:32 | <annevk> | smaug____: any idea why onfocusin/onfocusout do not exist? |
| 09:38 | <smaug____> | perhaps because focusin/out bubble, but focus/blur don't |
| 09:38 | <smaug____> | and onfoo are added to bubble phase |
| 09:38 | <smaug____> | just guessing |
| 09:39 | <smaug____> | might be confusing to get focusins/outs not targeted to your element using event handlers... I don't know. |
| 09:40 | <annevk> | I think we have lots of events like that which do have event handlers |
| 09:40 | <annevk> | This is probably just an oversight as they haven't been properly standardized thus far |
| 09:49 | <smaug____> | well, I was thinking the focus not bubbling and focusin bubbling difference in particular, not random event handler |
| 09:49 | <smaug____> | but yeah, dunno |
| 09:54 | <annevk> | smaug____: in Firefox if I invoke .focus() and then .remove() an element in the same task I don't seem to be getting both a focus and a blur event for it |
| 09:54 | <annevk> | smaug____: this works in Chrome (also fails in Safari) |
| 09:55 | <smaug____> | there is existing bug, IIRC, to dispatch events if focused element is removed from DOM |
| 09:55 | <annevk> | okay |
| 09:55 | <annevk> | I guess I'll just use .blur() for now |
| 10:17 | <annevk> | smaug____: so in https://searchfox.org/mozilla-central/source/dom/base/nsFocusManager.cpp#2254 we dispatch focus/focusin and blur/focusout |
| 10:17 | <annevk> | smaug____: focus/blur are done as script runner so presumably fire later therefore |
| 10:17 | <annevk> | smaug____: are there any other effects of them being added as a script runner? |
| 10:27 | <smaug____> | well, they don't technically fire sync, but just once the stack has unwound enough |
| 10:27 | <smaug____> | but no, there shouldn't be other differences |
| 10:28 | <smaug____> | except, if there are other scriptrunners waiting to be executed |
| 10:28 | <annevk> | smaug____: hmm, it seems focus fires before focusin |
| 10:28 | <smaug____> | the model is all broken |
| 10:28 | <smaug____> | isn't is explained in some github issue |
| 10:28 | <annevk> | smaug____: I guess https://w3c.github.io/uievents/#events-focusevent-event-order is not really implemented |
| 10:28 | <smaug____> | https://github.com/w3c/uievents/issues/88 |
| 10:29 | <annevk> | Thanks, I only knew about https://www.w3.org/Bugs/Public/show_bug.cgi?id=25897 |
| 10:29 | <annevk> | I think we should just move all of focus into HTML |
| 10:29 | <smaug____> | oh, maybe https://github.com/jquery/jquery/issues/3123 |
| 14:36 | <annevk> | foolip: can you r+ https://github.com/w3c/web-platform-tests/pull/5188? |
| 16:35 | <csarven> | I'd love to cite "Please leave your sense of logic at the door, thanks!" with a preferred URL. Currently using https://blog.whatwg.org/ |
| 16:36 | <csarven> | AFAIK, the statement is pretty old, but if anyone has a better URL, that'd be great |
| 17:03 | <annevk> | csarven: I don't think there's a canonical URL, it started here as a topic |
| 17:03 | <annevk> | (iirc) |
| 17:06 | <MikeSmith> | zcorpan: about https://github.com/validator/validator/issues/195, what’s the expected result for checking <input pattern="foo\'bar" name=x> |
| 17:08 | <zcorpan> | mathiasbynens: you're the regex expert :D ^ |
| 17:10 | <zcorpan> | MikeSmith: "ES6 requires more strict syntax when "u" flag is specified for RegExp (see the difference between [+U] and [~U] there), and it rejects some patterns that was working without "u" flag." from https://github.com/whatwg/html/issues/439 |
| 17:10 | <zcorpan> | MikeSmith: so \' should be a syntax error |
| 17:10 | <MikeSmith> | OK |
| 17:11 | <MikeSmith> | well if the JS parser is supposed to throw/reject for `new RegExp("foo\'bar", "u")`, no parser I’ve tested actually does that |
| 17:12 | <MikeSmith> | https://mathiasbynens.be/notes/es6-unicode-regex#support seems to indicate that Firefox, Chrome, and WebKit all should |
| 17:13 | <MikeSmith> | or maybe doing just `new RegExp("foo\'bar", "u")` is not the way to test it? |
| 17:13 | <csarven> | annevk: Thanks. I suppose I could use an irc: URL ;) The http: URL is nice though given a snapshot of the blog from Internet Archive |
| 17:20 | <gsnedders> | MikeSmith: are you sure you aren't wanting "foo\\'bar"? |
| 17:20 | <gsnedders> | MikeSmith: because "foo\'bar" is the same as "foo'bar"? |
| 17:20 | <MikeSmith> | oh |
| 17:20 | gsnedders | can't remember much about ES6 regexps tho |
| 17:28 | <MikeSmith> | gsnedders: OK, thanks, yeah Firefox, Chrome, and WebKit all throw for `new RegExp("foo\\'bar", "u")` |
| 17:29 | <gsnedders> | (I can't remember what the semantics of /foo\'bar/u would be, I think that would also throw?) |
| 17:36 | <MikeSmith> | dunno |
| 18:31 | <tobie> | Are there constants on globals beyond window.TEMPORARY and window.PERSISTENT? |
| 18:32 | <TimothyGu> | MikeSmith: thanks! please let as many people know about it as possible. it's difficult |
| 19:04 | <foolip> | annevk: done and merged! |
| 19:04 | <foolip> | tobie: depends on what you'd classify as a constant. window.offscreenBuffering is always true |
| 19:06 | <tobie> | foolip: IDL constants. |
| 19:07 | <foolip> | tobie: I know of no others. Mark Dittmer might be able to search to confirm absence more widely |
| 19:07 | <tobie> | I’ll give searchfox a spin too. |
| 19:16 | <zcorpan> | MikeSmith: yeah `new RegExp("foo\\'bar", "u")` is the right test |
| 21:47 | <MikeSmith> | zcorpan: OK, thanks |