| 07:40 | <hsivonen> | is there an online tool for browsing git blame for the HTML spec? |
| 07:42 | <hsivonen> | a searchfox-like UI would be very useful |
| 07:43 | <annevk> | hsivonen: unless there's something like that for arbitrary GitHub repositories, no |
| 07:43 | <hsivonen> | annevk: ok. :-( |
| 07:44 | <hsivonen> | I wonder if billm would be willing to add the HTML spec to searchfox |
| 07:44 | <annevk> | hsivonen: searchfox does seem to have useful UX, I had not really noticed the blame aspects |
| 07:45 | <annevk> | hsivonen: it might increase the load quite a bit due to the size of the resource |
| 07:46 | <annevk> | hsivonen: if searchbox is sufficiently generic it's not out of the question we could try to host our own instance for all WHATWG repositories |
| 07:49 | <hsivonen> | annevk: hosting it looks complicated: https://github.com/bill-mccloskey/searchfox |
| 07:50 | <hsivonen> | annevk: but most of the machinery for understanding C++, etc., is irrelevant for WHATWG spec sources |
| 07:52 | <hsivonen> | I sent email to ask about hosting on searchfox.org |
| 07:52 | <annevk> | hsivonen: it seems that it might only be needed for the HTML Standard |
| 07:52 | <annevk> | hsivonen: GitHub has a blame viewer, e.g., https://github.com/whatwg/fetch/blame/master/fetch.bs |
| 07:52 | <annevk> | hsivonen: but "source" is too large a resource |
| 07:53 | <gsnedders> | annevk: FWIW, POSIX OSes don't really use unicode for file names; they use bytes and then it gets displayed in the UI dependent on the locale's encoding |
| 07:53 | <annevk> | gsnedders: true, but I think the locale's encoding is pretty much always UTF-8 these days |
| 07:54 | <hsivonen> | does GitHub turn off these limits at some paid tier? |
| 07:54 | <gsnedders> | annevk: well it means you probably want to test non-UTF-8 byte strings too |
| 07:54 | <annevk> | hsivonen: good question |
| 07:55 | <annevk> | gsnedders: that's a good point about testing OS input vs just creating synthetic File objects, though we might not care too much about those final details |
| 07:55 | <annevk> | hsivonen: the WHATWG organization has the cheapest paid account (for free) |
| 07:56 | <gsnedders> | hsivonen: pretty sure the answer is no |
| 07:57 | <annevk> | https://help.github.com/articles/what-is-my-disk-quota/ does not say anything about this (and gives the impression larger resources are supported) |
| 07:58 | <annevk> | hsivonen: I'll email GitHub |
| 07:58 | <gsnedders> | the problem with large blames is the CPU cost of computing them |
| 07:58 | <gsnedders> | which I'd assume if the reason to disallow them |
| 07:59 | <hsivonen> | gsnedders: kinda annoying if there isn't a way to pay for that CPU time |
| 08:08 | <hsivonen> | So many "clean-up sweep" changesets to navigate over in blame... |
| 08:10 | <annevk> | Yeah, those are not great |
| 08:11 | <annevk> | hsivonen: if it takes too much time just file an issue and I'll figure it out for you |
| 08:13 | <hsivonen> | I located the original changeset |
| 08:18 | <annevk> | I got a new Mac keyboard and the \ being above the return key is rather baffling |
| 08:19 | <annevk> | And especially annoying in Terminal where I want to escape a space and instead end up running things that are not ready to be run |
| 08:22 | <annevk> | GitHub already replied saying it's not supported; I've now asked about throwing money at it |
| 08:25 | <hsivonen> | TIL: "When called with 3 or more arguments, document.open() calls window.open()." How did I not know that by now? |
| 08:26 | <annevk> | I'd consider that a win |
| 08:29 | <hsivonen> | the spec says, informatively, about document.write: "And to make matters even worse, the exact behavior of this method can in some cases be dependent on network latency, which can lead to failures that are very hard to debug." |
| 08:29 | <hsivonen> | what makes it depend on network latency? |
| 08:30 | <hsivonen> | this Chrome intervention thing that made it to the spec? https://html.spec.whatwg.org/#document-written-scripts-intervention |
| 08:30 | <hsivonen> | or something else, too? |
| 08:31 | <hsivonen> | I'm rather annoyed that after great effort to remove latency dependencies, Chrome adds them. |
| 08:32 | <annevk> | hsivonen: I vaguely recall that always being there |
| 08:33 | <hsivonen> | annevk: the id even has the word "intervention", which is a recent Chrome term |
| 08:34 | <annevk> | hsivonen: https://github.com/whatwg/html/commit/32ad4034dace4f1cfe88b71e50cae4ff84c71851 |
| 08:36 | <annevk> | hsivonen: the sentence before that about not executing script elements inserted via document.write is new |
| 08:36 | <annevk> | hsivonen: that's https://github.com/whatwg/html/commit/15b258dc74ffe1ba321b81a1c876f129681a97c2 |
| 08:37 | <annevk> | hsivonen: that probably deserves to be reverted as https://github.com/whatwg/html/pull/1400 was merged without support from two implementers |
| 08:51 | <hsivonen> | I think it's not cool that Chrome inserts non-determinism into the platform like this. OTOH, when they do, it's useful know. |
| 08:51 | <hsivonen> | so I feel conflicted about it being in the spec |
| 08:52 | <annevk> | hsivonen: are you subscribed to blink-dev? Even if not, sharing this sentiment every now and then might help |
| 08:52 | <hsivonen> | not sure what's the best way to deal with documenting "when they do" in a way that's visible to other implementors |
| 08:52 | <hsivonen> | annevk: I'm subscribed but don't have the time to read it actively |
| 08:58 | <annevk> | hsivonen: k, I'll see what I can do if things like this come up again |
| 08:58 | <annevk> | hsivonen: wycats has complained about this as well, but I don't think they've gotten much pushback on it otherwise |
| 09:06 | <wycats> | It's not even clear how to spec ir |
| 09:06 | <wycats> | How would you write a test? |
| 09:07 | <annevk> | wycats: ir? |
| 09:07 | <wycats> | It* |
| 09:08 | <annevk> | ah |
| 09:25 | <annevk> | smaug____: slot-in-closed-tree is supposed to be false when the event is dispatched on the slot element itself, right? |
| 09:26 | <smaug____> | right |
| 09:26 | <annevk> | smaug____: I'm working on a spec algorithm |
| 09:26 | <annevk> | smaug____: what I think I'll do is just store the current node a little longer if it's assigned and then use that in the next loop |
| 09:27 | <annevk> | smaug____: since if it's assigned the next loop will always be the slot |
| 09:27 | <smaug____> | right |
| 09:27 | <annevk> | smaug____: I hadn't quite realized that yet |
| 10:04 | <annevk> | hsivonen: GitHub confirmed that throwing money at the problem won't solve it, but they'll log a feature request |
| 10:05 | <annevk> | I continue to be quite impressed with GitHub's ability to give speedy replies |
| 10:14 | <hsivonen> | annevk: thanks |
| 16:10 | <annevk> | rbyers: re blink-dev; I think the "on the backlog" tag indicates the Edge team will implement in due course |
| 16:25 | <pombreda> | Howdy :) |
| 16:26 | <pombreda> | I am eventually creating a bunch of URL schemes here: https://github.com/nexB/scancode-toolkit/issues/805#issuecomment-340313273 to use as software package identifiers and locators |
| 16:27 | <pombreda> | what the best practice or not require a // after the scheme? |
| 16:28 | <pombreda> | e.g should I use npm:google/angular⊙1 or npm://google/angular⊙1 ? |
| 16:28 | <pombreda> | in my case the // are good looking IMHO but serve no purpose at all and can be omitted |
| 16:29 | <pombreda> | * what is the best practice to require or not require a // after the scheme:? |
| 16:30 | <pombreda> | annevk: what's your take there? |
| 17:52 | <annevk> | pombreda: depends on whether you want scheme-relative URLs or not |
| 17:53 | <annevk> | pombreda: it also influences a bit API-wise how components get parsed out of your URL |
| 18:07 | <pombreda> | annevk: these would never be scheme-relative URLs. e.g. the scheme must always be specified |
| 19:21 | <rbyers> | annevk: What the Edge folks have told me is that items on their platform status page (https://developer.microsoft.com/en-us/microsoft-edge/platform/status/?q=EventTarget) with "under consideration" and priority medium or above can be considered "public support". |
| 19:23 | <rbyers> | I don't see EventTarget listed there at all. |
| 19:25 | <annevk> | rbyers: it might not be considered a big enough thing; judging from how they use the backlog label it seems like they want to do it, but would be better if they said so explicitly I suppose |
| 19:25 | <rbyers> | annevk: I'm sitting next to Jacob Rossi right now, I'll ask him ;-) |
| 19:25 | <rbyers> | (when we get a break...) |
| 19:58 | <gsnedders> | does img fire a load event? where is that defined? |
| 20:02 | <gsnedders> | oh, there |
| 21:59 | <rniwa> | smaug____: yt? |
| 21:59 | <rniwa> | annevk: yt? |
| 21:59 | <smaug____> | rniwa: pong |
| 22:00 | <rniwa> | smaug____: so SVG use element says we should be using open shadow tree: https://svgwg.org/svg2-draft/struct.html#UseElement |
| 22:00 | <rniwa> | smaug____: we don't think it's a good idea |
| 22:00 | <smaug____> | hmm hmm, |
| 22:00 | <rniwa> | smaug____: any opinions about this? |
| 22:01 | <smaug____> | I'm not familiar... I thought I knew SVG 1.1 use |
| 22:01 | <smaug____> | looking |
| 22:03 | <rniwa> | smaug____: ok |
| 22:03 | <rniwa> | smaug____: we should be interested in joining us at SVG WG? |
| 22:03 | <rniwa> | smaug____: i'm about to make a point that we shouldn't do this in WG. |
| 22:03 | <smaug____> | rniwa: where does it say open shadow |
| 22:04 | <rniwa> | smaug____: look for the string "The shadow tree is open" |
| 22:04 | <rniwa> | smaug____: it's https://svgwg.org/svg2-draft/struct.html#UseShadowTree |
| 22:04 | <smaug____> | aha, there |
| 22:04 | <smaug____> | that is weird |
| 22:04 | <rniwa> | smaug____: the third paragraph after the list of items |
| 22:04 | <smaug____> | why it is open |
| 22:04 | <smaug____> | open but readonly |
| 22:04 | <smaug____> | what is that |
| 22:04 | <smaug____> | this is weird |
| 22:05 | <rniwa> | smaug____: it is |
| 22:05 | <rniwa> | smaug____: the crazy part is that it doesn't even define what it means to be readonly |
| 22:05 | <smaug____> | rniwa: do you know the reasoning for this? |
| 22:05 | <rniwa> | smaug____: i have no idea |
| 22:05 | <smaug____> | yeah, what is readonly dom |
| 22:05 | <smaug____> | and what things would actually throw NoModificationAllowedError |
| 22:05 | <smaug____> | that all is undefined |
| 22:05 | <rniwa> | smaug____: "Any attempt to directly modify the elements, attributes, and other nodes in the shadow tree must throw a NoModificationAllowedError." is the only definition i can find |
| 22:05 | <rniwa> | smaug____: indeed. |
| 22:06 | <rniwa> | smaug____: so just make it closed, we're all good |
| 22:06 | <smaug____> | right |
| 22:06 | <rniwa> | smaug____: if someone wanted to make this an open shadow tree, it's going to be controversial but whoever does that at least should define what it does... |
| 22:06 | <rniwa> | Domenic: ^ |
| 22:07 | <smaug____> | yeah, I think this is all nonsense |
| 22:07 | <smaug____> | was the SVG meeting there already? |
| 22:07 | <rniwa> | smaug____: it's happening right now |
| 22:07 | <rniwa> | smaug____: so you can join if you'd like (assuming the chair is okay with it) |
| 22:08 | <smaug____> | aha, please ask about this. There might be some reasoning. But as of now, this is weird and broken. |
| 22:08 | <smaug____> | getting a bit too late here, sorry |
| 22:08 | <rniwa> | smaug____: indeed. |
| 22:08 | <smaug____> | it is already tomorrow here ;) |
| 22:08 | <rniwa> | smaug____: so you're not gonna join the meeting but interested about the reasoning afterwards? |
| 22:08 | <rniwa> | smaug____: from minutes, etc...? |
| 22:09 | <smaug____> | sure |
| 22:09 | <rniwa> | smaug____: okay, will do. |
| 22:09 | <smaug____> | rniwa: and I could say so that trying to implement this is in Gecko would give r- from me |
| 22:09 | <rniwa> | smaug____: indeed. |
| 22:10 | <smaug____> | s/is// |
| 22:10 | <smaug____> | sget |
| 22:10 | <smaug____> | aösldfkjasdf |
| 22:10 | <smaug____> | apparently too late, can't type |
| 22:10 | <rniwa> | smaug____: i mean... i'm not even sure if it's implementable given the behavior isn't really well defined. |
| 22:10 | <smaug____> | yup. And I don't want that kind of weird readonly thingie, if it is just for svg |
| 22:11 | <rniwa> | smaug____: cool, that's almost exactly the same reason i was going to give |
| 22:11 | <smaug____> | rniwa: any mozilla folks in the meeting? |
| 22:11 | <rniwa> | smaug____: yes |
| 22:12 | <smaug____> | rniwa: who? |
| 22:12 | <rniwa> | Jet is supposed to be here |
| 22:12 | <rniwa> | smaug____: we don't see him though... |
| 22:15 | <smaug____> | rniwa: even with close shadow DOM, what if some script inside shadow DOM modifies it. How are the changes to the original supposed to be mapped to the clones? "However, these cloned element instances remain linked to the referenced source and reflect DOM mutations in the original." |
| 22:16 | <smaug____> | jet said "lots of crusty bits in that spec. I'll see the SVG folks at TPAC later to clarify" |
| 22:23 | <rniwa> | smaug____: okay, so basically everyone wants this sentence go away and use closed shadow tree |
| 22:23 | <rniwa> | smaug____: so we're good to go |
| 22:23 | <smaug____> | rniwa: well, there is still the issue how the clones are mapped to the original one |
| 22:24 | <smaug____> | or original to the clones |
| 22:24 | <smaug____> | if there are say onfoo attributes in the tree and they modify the clone and then the original is also modified |
| 22:24 | <rniwa> | smaug____ : they can't because the event target is adjusted to the use element which has that clone |
| 22:24 | <rniwa> | smaug____: and script elements inside a cloned tree won't run |
| 22:25 | <smaug____> | I see. I wasn't reading about that event target special case |