| 06:56 | <tobie> | heycam: just emailed you the webhook details right now. No hurry, I'm on parental duty today. :) |
| 06:56 | <heycam> | tobie: just saw it :) |
| 06:58 | <tobie> | heycam: while you're at it, can you check: Enforce HTTPS at the bottom of the settings page? |
| 06:59 | <tobie> | heycam: at the bottom of https://github.com/heycam/webidl/settings |
| 06:59 | <heycam> | tobie: ok added, it tells me it sent a ping message, for which the hook returned a 502 page whose title is "Heroku | Welcome to your new app!" |
| 06:59 | <heycam> | ticked. |
| 07:01 | <tobie> | Yeah, need to deploy the bot. |
| 07:01 | <tobie> | heycam: which I'll find time for later (hopefully) |
| 07:01 | <heycam> | cool cool |
| 07:03 | <annevk> | sigh |
| 07:04 | <annevk> | johanneswilm keeps at it with premature closing of issues |
| 07:04 | <tobie> | heycam: thanks a bunch |
| 07:04 | <heycam> | np! |
| 07:25 | <MikeSmith> | annevk: which issue? |
| 07:26 | <annevk> | MikeSmith: https://github.com/w3c/input-events/issues/38 |
| 08:07 | <annevk> | "Beyond that, it doesn't really matter what it returns, or whether it differs from implementation to implementation." |
| 08:07 | <annevk> | longer sigh |
| 08:20 | <annevk> | miketaylr_: seen anything about outerText yet? |
| 08:21 | <annevk> | Ms2ger: Gecko not getting a bug report for outerText might not mean which with respect to "mobile web" |
| 08:21 | <annevk> | Ms2ger: at this point if it's everyone-but-Gecko it'll only disappear from the web if someone else starts actively removing |
| 08:22 | <annevk> | Ms2ger: asking for data and they'll just be like "shrug" |
| 08:22 | <Ms2ger> | Don't we have people at Google who like to add use counters now? |
| 08:24 | <Ms2ger> | I guess I wouldn't be surprised if the response ended up being "too high, won't remove", but it feels like it's worth checking |
| 08:27 | <annevk> | I guess you could ask @foolip |
| 09:15 | <annevk> | No overnight feedback on the click event business unfortunately |
| 12:27 | <annevk> | Maybe for the best, since I found some mistakes |
| 12:27 | <annevk> | smaug: it seems other implementations do not traverse the whole path to run "activation behavior" |
| 12:28 | <annevk> | smaug: they only do it for the first instance |
| 12:28 | <annevk> | smaug: also, I can't figure out how <label> works |
| 12:29 | <smaug> | it depends on the case I think |
| 12:29 | <smaug> | Gecko may have a bug with <a> / <input> |
| 12:30 | <smaug> | well, basically input |
| 12:30 | <annevk> | smaug: I also get different behavior for click() and synthetic events |
| 12:30 | <smaug> | to not mark the event handled so that <a> doesn't try to handle it |
| 12:30 | <annevk> | https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A...%3Ca%20href%3D%2F%3Ex%3Cinput%20type%3Dcheckbox%3E%3Cdiv%3Ex%3C%2Fdiv%3E%3C%2Fa%3E%0A%3Cscript%3E%0Adocument.querySelector(%22input%22).dispatchEvent(new%20MouseEvent(%22click%22))%0A%3C%2Fscript%3E |
| 12:30 | <annevk> | Now replace the dispatchEvent stuff with click() |
| 12:31 | <annevk> | From your explanation of how click() should work (just run dispatchEvent()) it seems like there's a bug there? |
| 12:32 | <annevk> | Oh, maybe it's because of bubbling? |
| 12:32 | smaug | wonders what bug he is looking at |
| 12:33 | <annevk> | smaug: classify bug? |
| 12:33 | <smaug> | ah, in chrome there might be a bug it seems |
| 12:33 | <smaug> | annevk: you said there is a bug :) |
| 12:33 | <annevk> | smaug: there's a lot of different behavior |
| 12:33 | <smaug> | bug = "inconsistency" in this case |
| 12:35 | <annevk> | smaug: so the other thing seems to indeed be about bubbling |
| 12:36 | <annevk> | smaug: but that means that for the pre-click stuff we should also look at bubbling, no? |
| 12:37 | <smaug> | I'm lost now what you're talking about |
| 12:39 | <annevk> | Compare |
| 12:39 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0Avar%20input%20%3D%20document.createElement(%22input%22)%0Ainput.type%20%3D%20%22checkbox%22%0Ainput.appendChild(new%20Text(%22x%22))%0Ainput.firstChild.dispatchEvent(new%20MouseEvent(%22click%22))%0Aw(input.checked)%0A%3C%2Fscript%3E |
| 12:39 | <annevk> | https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ca%20href%3D%2F%3Ex%3C%2Fa%3E%0A%3Cscript%3E%0Adocument.querySelector(%22a%22).firstChild.dispatchEvent(new%20MouseEvent(%22click%22))%0A%3C%2Fscript%3E |
| 12:39 | <annevk> | Why does the former check the checkbox, but the latter not follow the link? |
| 12:43 | <smaug> | annevk: ah, that. Ok, input checked is changed during pre-handling |
| 12:43 | <annevk> | smaug: I know |
| 12:43 | <smaug> | and link triggered during post-handling, but we don't bubble from the textnode to <a> |
| 12:43 | <smaug> | so yes, bubble needs to be taken account |
| 12:43 | <smaug> | as far as I see |
| 12:44 | smaug | tries to find some code in blink which was very unexpected... dealing with some of this stuff |
| 12:45 | <annevk> | smaug: but this means that if you cancel that click event the post-handling steps don't run for the input |
| 12:45 | <smaug> | Can't find the code in blink now |
| 12:46 | <smaug> | but anyhow, looks like they have similar handling for bubbling as gecko: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/events/EventDispatcher.cpp?sq=package:chromium&l=297 |
| 12:46 | <annevk> | smaug: that is, we change checkedness of the input due to a non-bubbling click on a descendant, but you can't cancel that as you could if it bubbled |
| 12:46 | <smaug> | right |
| 12:47 | <annevk> | smaug: so logically, it seems you'd want to take bubbling into account for pre-handling too |
| 12:47 | <smaug> | annevk: well, this is very edge case. <input type=checkbox> is odd beast, and that element doesn't usually have child nodes |
| 12:47 | <annevk> | (not that it matters much in practice, since <input> almost never has children, but it would make the logic better in the spec, since you can determine the "activation element" just once) |
| 12:48 | <annevk> | that is, if we determine the activation element just once, we don't have to traverse the path multiple times |
| 12:52 | <annevk> | smaug: thoughts on that? |
| 12:56 | <smaug> | annevk: if it helps with spec'ing and only change browsers would need to do is change default handling when event is coming from a child node of an <input> element, sounds ok to me. .... are there other cases when pre-handling is used? |
| 12:56 | <annevk> | smaug: I only found pre-click handling and post-canceled-click handling in HTML for <input type=checkbox> and <input type=radio> |
| 13:06 | <hsivonen> | annevk: fwiw, the Encoding Standard's big5 encoder can produce output that glibc thinks is valid Big5-HKSCS but not valid Big5 |
| 13:07 | <hsivonen> | annevk: we probably don't care, but still interesting considering that the Encoding Standard is trying to be conservative on the encoder side |
| 13:07 | <annevk> | hsivonen: foolip basically designed that encoding; I suspect that he wanted to be mostly conservative, but also not make it too hard on himself |
| 13:08 | <annevk> | hsivonen: or effectively, require two tables |
| 13:08 | <hsivonen> | let's avoid two tables |
| 13:10 | <smaug> | (ah, right, the weird blink case was something about hit testing and when to dispatch click. So, not really about this case) |
| 14:39 | <gsnedders> | how does "Add links to tests from requirements (beta)" work? |
| 14:45 | <Ms2ger> | In XHR? |
| 14:45 | <Ms2ger> | xpath in the tests |
| 14:46 | <gsnedders> | ewwww |
| 14:47 | <gsnedders> | it just looks /so/ fragile |
| 14:47 | <gsnedders> | ids would be so much better :\ |
| 14:47 | <gsnedders> | maybe I've been in CSS-land too long thinking that it's better |
| 14:52 | <annevk> | gsnedders: if you get stable IDs |
| 14:59 | <gsnedders> | annevk: sure, but IDs are more likely stable than '"following::dfn[2] following::dfn[3] following::dfn[4] following::dfn[5] following::dfn[6]' |
| 15:00 | <gsnedders> | annevk: and it's far easier to make IDs stable |
| 15:00 | <annevk> | gsnedders: I'm agreeing with you |
| 15:01 | <annevk> | gsnedders: does require adding IDs to places and making them discoverable (inspect element is not liked) |
| 15:01 | <gsnedders> | oh, ok :) |
| 15:01 | <gsnedders> | well even with inspect element it's more discoverable than the current XPath paths |
| 15:01 | <annevk> | That's prolly the main difficulty, bz is asking for a lot more (discoverable) IDs in HTML too |
| 15:02 | <annevk> | We could prolly do some through Wattsi, once someone starts hacking on it more seriously, but not sure about per-paragraph and keeping those stable |
| 15:08 | <gsnedders> | what's the motivation to stick with wattsi for HTML when nothing else is using it? just the time/effort taken to move away? |
| 15:09 | <annevk> | gsnedders: yeah, and likely speed of alternatives |
| 15:13 | <jgraham> | Rewrite bikeshed in Rust, obviously |
| 15:29 | <nox> | jgraham: You have 2 hours. |
| 15:35 | <jgraham> | nox: As fun as that sounds instead I have to work on javascript angular crap |
| 15:35 | <nox> | jgraham: Heh. |
| 15:38 | <gsnedders> | jgraham: Angular? That's so 2015. |
| 15:38 | <jgraham> | gsnedders: Well 2014 in this case I think |
| 15:38 | <jgraham> | There seems to be a drive to put some React in our angular |
| 15:38 | <gsnedders> | jgraham: you haven't redone the website in *two years*?! WTF. How do you still have customers? |
| 15:38 | <jgraham> | For maximum buzzword compliance |
| 15:38 | <gsnedders> | jgraham: And I mean you're never going to get VC funding with such an outdated tech stack |
| 15:38 | <jgraham> | gsnedders: "captive audience" |
| 15:39 | <jgraham> | No VC funding you say? |
| 15:39 | <jgraham> | Excellent |
| 15:39 | <jgraham> | Fuck that |
| 15:40 | <gsnedders> | Don't you care about your valuation!? |
| 16:06 | <TabAtkins> | Domenic: https://drafts.csswg.org/css-forms/ |
| 16:07 | <Domenic> | that was it, thanks! |
| 16:10 | <TabAtkins> | gsnedders: Yeah, tho I've recently done some major perf-hacking on HTML-using-Bikeshed, it still takes almost a full minute on my high-powered workstation. |
| 16:11 | <TabAtkins> | (Almost all of the time is spent in the initial HTML parse, the final HTML serialization, and evaluating selectors between those two, in roughly equal amounts.) |
| 16:39 | <gsnedders> | In Fx/Ch land, does a single build go from Beta -> Stable, or does it have a different version number? |
| 16:43 | <annevk> | Not a single build all the way through, but same major version |
| 16:43 | <gsnedders> | yeah, I just mean the final move from beta to stable? |
| 16:43 | <gsnedders> | or is there no RC-phase where you have essentially the final build in its final config before it lands on stable? |
| 16:47 | <annevk> | gsnedders: I think we still land stuff post beta and RC is at the end of stable |
| 16:48 | <annevk> | gsnedders: have not really looked into this much though |
| 16:48 | <gsnedders> | annevk: I mean really what I want to know is can I take a version number (from the UA string) and tell what channel it's on? |
| 16:50 | <annevk> | gsnedders: oh, dunno, maybe |
| 17:31 | <annevk> | hsivonen: you'll enjoy reading through https://github.com/whatwg/html/commit/76f88a4015d55273749c34238d250b7bdb1aff62 |
| 17:32 | <annevk> | (prolly most people here would, but, you know, hsivonen wrote a whole thing about it back in the day: https://hsivonen.fi/vendor-prefixes/ ) |
| 17:41 | <Domenic> | annevk: wait so is trusted the default? |
| 17:41 | <Domenic> | ah i see it is in DOM |
| 17:41 | <Domenic> | HTML just doesn't re-state that. |
| 18:40 | <annevk> | Domenic: default for spec-dispatched stuff |
| 18:41 | <annevk> | Domenic: click(), maybe reset(), are exceptions |
| 18:41 | <annevk> | Domenic: hopefully all clear soonish |
| 18:55 | <annevk> | Domenic: I was thinking of also defining a special "create" for event classes for specs, that would give them a trusted variant |
| 18:56 | <annevk> | Domenic: but click stuff first |
| 20:02 | <Savago> | Good morning (UGT: Universal Greeting Time). 2 questions: is there a place used to track compatibility issues between browsers (like https://github.com/whatwg/compat)? Can anyone open issues there? |
| 20:14 | <astearns> | Savago: not exactly what you're asking for, but try https://browser-issue-tracker-search.appspot.com/ |
| 20:15 | <Domenic> | Savago: there is some repo that the Edge and Mozilla folks use a lot to report specific websites that fail due to cross-browser compat problems... I think I've seen paul_irish using it too. Can't remember what it was called... |
| 20:16 | <Savago> | astearns, that is a pretty handy site. Thanks. :-) |