| 09:19 | <annevk> | philipj: does it matter what order I fix the attributeNode issues in? |
| 09:20 | <annevk> | philipj: seems relatively straightforward to fix the alias one |
| 09:24 | <philipj> | annevk: no, the order doesn't matter to me, but when I make the change in Blink I'd like to have a good sense that the spec, Blink and Gecko have precisely the same behavior as a goal |
| 09:24 | <philipj> | Which is looking pretty hopeful right now. |
| 09:24 | <annevk> | philipj: I thought we were aligning the spec with Blink? |
| 09:25 | <annevk> | philipj: oh, the other bits |
| 09:25 | <annevk> | makes sense |
| 09:25 | <philipj> | annevk: sorry, by order I mean the order of fixing issues :) |
| 09:46 | <Ms2ger> | philipj, and tests? :) |
| 09:48 | <philipj> | Ms2ger: for this attribute mess I was actually thinking I'd to it web-platform-tests style, yeah |
| 10:07 | <Ms2ger> | annevk, did location/workerlocation ever have searchparams? |
| 10:08 | <annevk> | Ms2ger: not sure about WorkerLocation, but yes |
| 10:08 | <annevk> | Ms2ger: it's a security hole though |
| 10:08 | <Ms2ger> | All the more reason to add a test it's not supported, then :) |
| 10:29 | <Ms2ger> | annevk, r? https://github.com/w3c/web-platform-tests/pull/2371 |
| 10:30 | <annevk> | Ms2ger: worker.js is a convention for worker-only tests? |
| 10:31 | <Ms2ger> | annevk, a bit more than that; it automatically sets up the main-thread side |
| 10:31 | <Ms2ger> | Like http://w3c-test.org/XMLHttpRequest/XMLHttpRequest-withCredentials.worker |
| 10:32 | <annevk> | Ms2ger: neat |
| 10:32 | <annevk> | Ms2ger: r+ |
| 10:33 | <annevk> | Ms2ger: is there a bug on the directory listing not supporting this feature? |
| 10:33 | <Ms2ger> | I don't think so |
| 10:33 | <Ms2ger> | I'll file that |
| 10:33 | <annevk> | thank you |
| 10:35 | <annevk> | yoav: any ETA on https://github.com/whatwg/dom/pull/114? |
| 10:36 | <annevk> | yoav: it's not a big deal since I assume all implementers are still aware, but it might become one |
| 10:37 | <Ms2ger> | https://github.com/w3c/wpt-tools/issues/42 |
| 10:37 | <yoav> | annevk: I was under the impression that it's still under active discussion regarding the best return values |
| 10:38 | <yoav> | but maybe I haven't throughly checked the latest news on that thread (been offline during WE and yesterday) |
| 10:38 | <yoav> | I'll go over all replies later today and align the PR accordingly |
| 10:46 | <zcorpan> | annevk: why is searchParams a security hole on location? |
| 10:49 | <annevk> | zcorpan: because Location can be seen cross-origin to some extent |
| 10:49 | <annevk> | zcorpan: and is all kinds of complicated |
| 10:49 | <annevk> | yoav: I see |
| 10:49 | <annevk> | yoav: ta |
| 10:51 | <annevk> | philipj: I don't understand your comment in https://github.com/whatwg/dom/issues/115 about losing order |
| 10:54 | <annevk> | zcorpan: https://github.com/annevk/html-cross-origin-objects/ has some notes on defining Location more accurately |
| 10:55 | <zcorpan> | annevk: so the problem is that it's an object and we don't want to figure out how to support it in a secure way, because location is complicated enough already? |
| 10:59 | <annevk> | zcorpan: it would basically amount to introducing a new kind of URLSearchParams that is safe |
| 11:00 | <philipj> | annevk: commented again, does it make sense now? |
| 11:00 | <annevk> | zcorpan: at which point it seems better to just require var loc = new URL(location); /* manipulation here */ location = loc to do some manipulation |
| 11:01 | <zcorpan> | annevk: ok. thx |
| 11:01 | <annevk> | philipj: it seems with the getAttributeNamesNS API you wouldn't lose that, right? |
| 11:03 | <philipj> | annevk: oh, you mean that would return *all* the attributes? |
| 11:03 | <philipj> | I assumed you would split them into two buckets |
| 11:04 | <annevk> | philipj: the first would return all the qualified names |
| 11:04 | <annevk> | philipj: but yes, both would return all |
| 11:04 | <annevk> | philipj: just like setAttribute / setAttributeNS also both operate on all |
| 11:05 | <zcorpan> | can't the implementation avoid creating the Attrs if you only access the .name? or is that kind of lazy creation super-hard for some reason? |
| 11:11 | <annevk> | Try to implement it in JavaScript and see how easy it is? :-) I'm sure that kind of thing can be done, the question I guess is how much complexity should we put in the engine when we can expose something that wasn't really well-exposed thus far that would avoid doing all that... |
| 11:21 | <zcorpan> | annevk: i wouldn't be surprised if Presto does something like this |
| 11:22 | <Ms2ger> | zcorpan, what would you access the name on, then? |
| 11:24 | <Ms2ger> | Or do you mean var name = element.attributes[0].name; would magically collapse to fetching the name from somewhere else, or something? |
| 11:24 | <zcorpan> | Ms2ger: magic? proxy something? i dunno |
| 11:24 | <Ms2ger> | Sounds hard in SpiderMonkey, at least |
| 11:25 | <zcorpan> | ok |
| 14:46 | <gsnedders> | Why are we using a bash file instead of a Makefile for the building stuff? |
| 14:48 | <jgraham> | Wow, talk about out of the frying pan and into the fire |
| 14:50 | <jgraham> | Although the answer seems to be "becase that's what Hixie did" |
| 15:04 | <gsnedders> | :) |
| 15:04 | <gsnedders> | That's what I thought. |
| 15:05 | <gsnedders> | There's just so many comments like "We need to check if x file has changed before we avoid doing this". Which is, well, what Make is great at. |
| 15:19 | <MikeSmith> | it's great for saving time if the compile times are significant |
| 15:19 | <MikeSmith> | which they're not in our case |
| 15:20 | <MikeSmith> | so IMHO it'd be overkill to change it now |
| 15:21 | <MikeSmith> | though that said, myself I would have written it as a makefile to begin with |
| 15:21 | <MikeSmith> | I guess one argument is that it's easy to write a makfile that's not portable |
| 15:22 | <MikeSmith> | or that at least will break on windows/dos |
| 15:22 | <MikeSmith> | I mean, easy to accidentally write one that won't work on windows |
| 15:22 | <MikeSmith> | or won't work without GNU make |
| 15:23 | <Ms2ger> | As opposed to bash? :) |
| 15:23 | <MikeSmith> | yeah, good point |
| 15:23 | <jgraham> | It's also easy to write a write-only makefile |
| 15:23 | <MikeSmith> | fair enough |
| 15:23 | <MikeSmith> | jgraham: true that too |
| 15:24 | <MikeSmith> | anyway, ain't broke don't fix it and all that |
| 15:25 | <gsnedders> | aye |
| 15:25 | <MikeSmith> | at least we're not at maven vs gradle vs sbt |
| 15:26 | <gsnedders> | I do want to reach to a point where you can checkout the spec at a given revision and get the spec at that revision. With so many external deps, it can be hard to tell when things actually changed |
| 15:26 | <gsnedders> | I don't really care about the caniuse and bugzilla stuff, I only mean the normative content |
| 15:34 | <Ms2ger> | Pretty sure the html spec doesn't do reproducible builds |
| 15:35 | <Ms2ger> | Neither does any other spec, of course |
| 15:35 | <Ms2ger> | Maybe WebIDL |
| 15:39 | <gsnedders> | only because of xspec xref though, right? |
| 15:41 | <Ms2ger> | Also bikeshed/anolis/... versions |
| 15:41 | <Ms2ger> | And obviously the datestamp, but let's ignore that |
| 15:42 | <gsnedders> | really the build tools don't change enough for that to really be relevant, IMO |
| 21:15 | <Krinkle> | JakeA: Any chance https://code.google.com/p/chromium/issues/detail?id=393466 could get a little push? it'd be nice to drop the user-agent sniffing based polyfill we have for it now. |
| 22:15 | <Domenic> | Krinkle: might have better luck in Mozilla IRC #accessibility; I hear that is where a11y browser engineers hang out |
| 22:21 | <Krinkle> | Domenic: OK. Note though that despite its name, accesskeys are imho not an accessibility feature. More a power user feature. At least on Wikipedia it's historically been a feature much used, and never with javascript. |
| 22:25 | <tantek> | yeah that sounds about right |
| 22:34 | <Domenic> | Krinkle: sounds like a feature that will not be prioritized by a browser that is focused on mobile... |
| 22:35 | <Krinkle> | It should be a simple patch though. And it's part of the DOM spec. These kind of random gaps make it suck to develop for the web. |
| 22:37 | <Krinkle> | or maybe we should remove it from the spec. But this cycle of things being added to the spec, one browser implementing it, and then usually years of silence and uncertainty of whether the rest is going to follow is just weird from an outsider perspective. This feature in particular is probably "old enough" that it "would be done differently" if it were |
| 22:37 | <Krinkle> | proposed today, but I really hope there is some kind of process by which vendors are involved earlier so that there's more ability to optimise for the future. |
| 22:41 | <Domenic> | Krinkle: ever considered contributing to Chrome? :) |
| 22:42 | <Krinkle> | I have. But I simply don't have the capacity to add that. I'm already working a full time job with lots of open-source activity outside of that. |