| 01:22 | <Domenic> | tobie: what's the status on getting https://github.com/tobie/specref/pull/250 re-landed? What broke in prod, and can I help fix it? |
| 11:34 | <nox> | TabAtkins: Is element.matches("> *") supposed to be valid? |
| 11:37 | <nox> | TabAtkins: Seems like that method didn't get updated in DOM to use "Parse A Relative Selector" instead of "Parse a Selector". |
| 13:48 | <tobie> | Domenic: Some aliasing is broken somewhere. I'd need to think it through again and make sure I'm around to check the logs when we push it. |
| 13:59 | <annevk> | philipj: around? Any more thoughts on https://github.com/whatwg/html/pull/695? |
| 14:39 | <Domenic> | tobie: hmm I guess I was hoping I could stand up a server locally and debug failures |
| 14:47 | <tobie> | Domenic: you could of course totally do that. Don't know what I was thinking. |
| 14:47 | <tobie> | Domenic: I obv have a bit much on my plate atm. |
| 14:47 | gsnedders | buys tobie a bigger plate |
| 14:49 | <tobie> | gsnedders: ty |
| 14:49 | <gsnedders> | tobie: I'm always here looking for useful suggestions |
| 14:50 | <tobie> | Domenic: I can't remember the precise issues I was having, and the logger I use doesn't keep more than 24hrs of logs in its free version |
| 14:50 | <tobie> | Domenic: it had to do with some alises being broken |
| 14:51 | <Domenic> | tobie: so e.g. browser around the site and watch the logs for errors with the word "alias" in them> |
| 14:51 | <Domenic> | ? |
| 14:51 | <tobie> | Domenic: possibly because of calling the search API used by specref.org |
| 14:51 | <Domenic> | hmmm |
| 14:52 | <tobie> | well, just run node index.js with whatever old version of node this thing requires |
| 14:52 | <tobie> | then just curl the different APIs for stuff related to the changes |
| 14:52 | <tobie> | Domenic: iirc it failed spectacularly and pretty quickly too |
| 14:53 | <Domenic> | philipj: how can you not think the warning helps for sync XHR given this trendline? https://www.chromestatus.com/metrics/feature/timeline/popularity/465 |
| 14:54 | <Domenic> | philipj: at this rate it should be at 0 in 1.5 more years, literally! |
| 14:55 | <gsnedders> | Domenic: I can't imagine it dying till Fetch because practically usable |
| 14:55 | <annevk> | that alone shows how much the warning is worth |
| 14:56 | <annevk> | so much less synchronous IO |
| 14:57 | <tobie> | when was the warning introduced? |
| 15:02 | <annevk> | Quite a while ago, and every now and then someone gets upset with it and tells me how wrong I am and that for their particular niche synchronous IO is justified |
| 15:03 | <annevk> | Heck, even Brendan wants me to remove the warning |
| 15:04 | <gsnedders> | imo the big advantage of sync IO is the reduction of boilerplate with XHR |
| 15:05 | <tobie> | so why does this graphic prove that the warning has had an impact? |
| 15:05 | <annevk> | tobie: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg232 |
| 15:06 | <tobie> | All I'm seeing is a initial spike which is probably when the fist measures where taken, followed by a regular gradual decline. |
| 15:06 | <tobie> | To prove the warning works, you'd need a measurable acceleration in decline from the point at which it was introduced, no? |
| 15:07 | <annevk> | tobie: why? |
| 15:07 | <gsnedders> | there's been plenty of other evangelisation about the badness of sync IO |
| 15:08 | <gsnedders> | hence I'm with tobie here, the causation hasn't been shown |
| 15:08 | <tobie> | gsnedders: precisely. |
| 15:09 | <annevk> | I guess that's fair |
| 15:10 | <annevk> | I've seen plenty of anecdotal evidence that this warning helps folks decide, but I guess you can't really tell from that graph per se |
| 15:19 | <Domenic> | It certainly isn't hurting |
| 15:26 | <jyasskin> | mounir: Have you figured out which version of Tidy you're running yet? |
| 15:26 | <jyasskin> | It's frustrating to have https://github.com/w3c/permissions/blob/gh-pages/contributing.md tell me to use it, and then have patches rejected because I did. |
| 15:35 | <annevk> | Domenic: I care quite strongly about moving towards "then" |
| 15:35 | <annevk> | Domenic: 😃 |
| 15:35 | <annevk> | Domenic: was there anything else that I missed due to it being hidden or can I land? |
| 15:35 | <Domenic> | annevk: I'd like to do a second pass later today, sorry |
| 15:36 | <annevk> | Domenic: sure, no rush |
| 15:46 | <annevk> | We're at a low point for outstanding PRs btw, been a while |
| 16:02 | <Domenic> | yeah it warms my heart |
| 16:59 | <annevk> | "195 bugs found." \o/ |
| 16:59 | <annevk> | Of course, we now have well over 200 issues... |
| 17:12 | <philipj> | Domenic: I don't doubt that it has *some* effect, but there are non-deprecated things that are also slowly decreasing and I've never been able to see a clear connection between deprecation date and change in usage for anything else, so I just don't know what explains the decreasing usage |
| 17:13 | <philipj> | Whatever is driving the decrease, I'd expect it to show some kind of half-life decay and not linear decrease, so getting down to 0.01% or could take a very long time. |
| 17:13 | <philipj> | So, I think something more aggressive will be needed to get anywhere with this in a reasonable time frame |
| 17:14 | <philipj> | Maybe setting a timeout that's continuously decreased so that only 0.01% of page loads have a synx XHR timeout because of it, so that it's less and less reliable |
| 17:15 | <Domenic> | philipj: you don't buy my trendline argument that we only need 1.5 more years? :) |
| 17:15 | <philipj> | Domenic: oh, didn't realize you were bein tongue in cheek :) |
| 17:18 | <philipj> | one could also imagine an intervention where certain user interactions cause a timeout, but that might not be fun to debug for developers |
| 17:22 | <gsnedders> | philipj: you're still at Opera, right? |
| 17:24 | <annevk> | Is SharedWorker still not supported outside Window? https://www.w3.org/Bugs/Public/show_bug.cgi?id=28504 |
| 17:25 | <annevk> | TabAtkins: where is https://www.w3.org/Bugs/Public/show_bug.cgi?id=28080 tracked on the CSS side? |
| 17:27 | <TabAtkins> | nox: I'd think .matches() is *supposed* to use an absolute selector. Where's the context it would be applying a relative selector to? (It's not the element; that's checked against the resulting subjects of the selector.) |
| 17:28 | <gsnedders> | philipj: nvm, realised what I need probably wasn't on t anyway |
| 17:29 | <TabAtkins> | annevk: Hm, I dropped the ball on that, sorry. I'll bring it back up. |
| 17:42 | <philipj> | gnarf: yep! |
| 17:43 | <philipj> | I mean gsnedders ^ |
| 17:43 | <philipj> | gsnedders: I assume you know about presto-testo though? |
| 17:45 | <annevk> | Domenic: does your blocked element thing supersede https://www.w3.org/Bugs/Public/show_bug.cgi?id=23960? |
| 17:46 | <Domenic> | annevk: not really. Although the delegatesFocus stuff for shadow DOM might help a lot. |
| 17:48 | <annevk> | slightlyoff: do you know if anyone from Google is working on an undomanager? https://www.w3.org/Bugs/Public/show_bug.cgi?id=14337#c14 |
| 17:48 | <gsnedders> | philipj: yeah |
| 17:49 | <gsnedders> | philipj: tl;dr: was thinking I wanted stuff from t/resources, actually need stuff from spartan-server |
| 17:54 | <philipj> | gsnedders: I'm not sure that's around any longer |
| 17:57 | <gsnedders> | philipj: oh, it will be |
| 18:01 | <annevk> | Domenic: also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24718 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=24720 |
| 18:12 | <Domenic> | annevk: what replaced "in a composed document"? |
| 18:13 | <annevk> | Domenic: in a shadow-including document |
| 18:13 | <annevk> | Domenic: which in turn is defined in terms of shadow-including root |
| 18:13 | <annevk> | Domenic: both already in DOM |
| 18:14 | <Domenic> | \o/ |
| 18:19 | <nox> | TabAtkins: There are varions tests with such selectors un WPT, hence the question. |
| 18:19 | <TabAtkins> | That sounds like a bug in the tests! |
| 18:31 | <Domenic> | annevk: it would be minorly helpful if you could define "connected" |
| 18:32 | <annevk> | Domenic: you mean the IDL attribute? |
| 18:32 | <Domenic> | annevk: nah just the concept. But presumably you'd do both at the same time. |
| 18:32 | <annevk> | Domenic: isn't the concept just "in a shadow-including document"? |
| 18:33 | <Domenic> | annevk: hmm I guess so. It would be nicer if the author-facing API matched the concepts. |
| 18:35 | <annevk> | Domenic: I can still rename that easily |
| 18:39 | <gsnedders> | TabAtkins: wait you have the power to necro stuff? shit. |
| 18:39 | <TabAtkins> | I am a great and powerful sorceror. |
| 18:54 | <nox> | TabAtkins: Ok. |
| 20:45 | <smaug____> | annevk: Domenic: has it been written down somewhere that boolean attributes should be avoided in APIs unless it is absolutely clear what true/false mean in that context? |
| 20:45 | smaug____ | is looking at directory-upload spec, and proposes using dictionary for the recursive param, not a boolean |
| 20:46 | <Domenic> | smaug____: it's in Web IDL |
| 20:47 | <Domenic> | smaug____: oh, no, I am misremembering. Web IDL just warns against booleans defaulting to true. |
| 20:47 | <Domenic> | smaug____: http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html is my favorite reference, but maybe we should add it to https://w3ctag.github.io/design-principles/ |
| 20:47 | <TabAtkins> | yes plz |
| 20:49 | <smaug____> | Domenic: thanks, http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html is a good one |
| 21:45 | <tobie> | +1 |
| 21:45 | <tobie> | TabAtkins: just curious if you use boilerplate beyond what bikeshed offers for your CSS specs. |
| 21:45 | <TabAtkins> | In what way? |
| 21:45 | <tobie> | TabAtkins: I'm not starting to work on spec'ing the concrete sensors (Gyroscope, AmbientLight, etc.) |
| 21:46 | <tobie> | TabAtkins: and there's a lot of stuff that are going to be common to each, even though I've stuck as much of it as I could in the generic sensor spec. |
| 21:48 | <tobie> | TabAtkins: for example, they'll all need to define the following: https://w3c.github.io/sensors/#definition-reqs |
| 21:48 | <TabAtkins> | Okay, gotcha. |
| 21:48 | <TabAtkins> | No, I don't do anything else. Dont' need to - the existing CSSWG boilerplate is plenty. |
| 21:48 | <TabAtkins> | But if you need such, there are a few ways to do it. |
| 21:49 | <tobie> | TabAtkins: well, not only do I think it's worthwhile for me, it might also be something nice to offer other editor who want to expose sensors |
| 21:49 | <TabAtkins> | Most obvious is to set up some new boilerplate for yourself, derived from the dap boilerplate. Adjust whatever's necessary. |
| 21:51 | <tobie> | TabAtkins: sure, but that's lightly different, though. I feel like I need scaffolding more than boilerplate |
| 21:51 | <tobie> | *slightly |
| 21:51 | <TabAtkins> | Another way, probably better for your needs, is to build an inclusion file, and just include that into your specs via a <pre class=include> (which I realized a few days ago wasn't documented). |
| 21:51 | <TabAtkins> | Hmm, scaffolding is *way* more difficult. |
| 21:51 | <TabAtkins> | Well, actually, maybe not. Depends on how complex you mean. |
| 21:51 | <tobie> | I'm not sure, yet, actually. :-/ |
| 21:51 | <TabAtkins> | So, again this isn't documented yet because I'm a bad person, so bear with me, when including a file you can set up some custom macros that will be available inside the included file. |
| 21:51 | <TabAtkins> | So if it's it's just a matter of "here's a template, fill in the holes", then that's totally possible. |
| 21:52 | <tobie> | Maybe that's what I'm looking for. |
| 21:52 | <TabAtkins> | If it's any more diverse, tho, then there's really nothing that can be done mechanically, and the right thing is just to document what each specific sensor is expected to provide. |
| 21:53 | <tobie> | Sure. But it would be pretty cool if I could write the specifics of each as YAML or JSON or whatnot and have a whole bunch of things generated. |
| 21:54 | <TabAtkins> | Like I said, if it's just a matter of a template with holes that will be filled with text, I can do that. (If the holes are *large* it's not *convenient* currently, but can be done.) |
| 21:54 | <TabAtkins> | Any more complex and I'd have to invent something new, and I'm wary to try and do that without more examples to inform the design. |
| 21:55 | <tobie> | oh, I wasn't asking for work on your side |
| 21:56 | <tobie> | Just curious as to what can be done with the existing tool and in which direction I should poke |
| 21:56 | <tobie> | I'll start off mostly manual with the first spec |
| 21:58 | <tobie> | then try to extract commonalities from it. |
| 21:58 | <tobie> | Thanks for the pointers |
| 21:59 | <TabAtkins> | np |
| 22:47 | <slightlyoff> | annevk: I don't. I think that stopped when rniwa went to apple |