| 00:17 | <nox> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18794 |
| 00:27 | <nox> | annevk: https://github.com/w3c/webcomponents/commit/c3c46d87f9764a746523ec17853b0a5eb5ed46e0 |
| 02:35 | <Liki> | hello, i'm trying to use github/fetch but have a question about how to capture an event from the response? |
| 02:35 | <Liki> | more specifically, i'm uploading a file and it returns the progress event |
| 02:44 | <MikeSmith> | Liki: add an event listenert for "fetch", use respondWith() to do something? |
| 02:44 | <MikeSmith> | ah, progress event |
| 03:19 | <Liki> | Hi so there is no such event mechanism just like those in Superagent? |
| 03:22 | <MikeSmith> | Liki: dunno what Superagent is |
| 03:22 | <MikeSmith> | that github/fetch library is just a polyfill isn't it? |
| 03:22 | <MikeSmith> | that is, it just provides exactly the same API as what's in the Fetch standard |
| 03:22 | <MikeSmith> | and nothing additional |
| 03:23 | <MikeSmith> | e.g., no convenience methods or whatever |
| 03:23 | <MikeSmith> | Liki: have you read the spec? https://fetch.spec.whatwg.org/ |
| 03:24 | <MikeSmith> | botie, inform Liki https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch |
| 03:24 | <botie> | will do |
| 03:24 | <MikeSmith> | (in case he comes back) |
| 04:07 | <annevk> | nox: well, maybe I know what I'm doing after all |
| 04:34 | <mkwst> | annevk: Morning. :) |
| 04:34 | <mkwst> | annevk: For MIX: how do I check whether a request is targeting an iframe? I used to look at the frame type, now I need to ... what? Look at the client's document's ancestors? |
| 04:35 | <mkwst> | s/document/browsing context/ |
| 05:34 | <annevk> | mkwst: yes, basically |
| 05:35 | <annevk> | mkwst: you need to check the ancestor anyway right for its URL? |
| 05:50 | <annevk> | So Directory Upload should really just be a patch to HTML |
| 05:50 | <annevk> | Anyone want to point that out? |
| 05:51 | <annevk> | And the webkit* stuff might need to be added to compat.spec.whatwg.org by miketaylr or also straight to HTML... |
| 05:54 | <mkwst> | annevk: Is the client for a request that's navigating an iframe the iframe itself, or the document embedding the iframe.? |
| 05:56 | <annevk> | mkwst: that's a good question, there was a similar thing with your "originating origin" or some such right? |
| 05:56 | <annevk> | mkwst: I learned recently Gecko has two principals, requesting and loading or some such... I guess we might need both? |
| 05:57 | <mkwst> | Probably. I'm just confused about what I'm supposed to be looking at now. |
| 05:57 | <mkwst> | I guess? Previously, I was just relying on magical 'frame type' settings. |
| 05:57 | <mkwst> | That was simpler, as it pushed the complexity onto you/HTML. :) |
| 05:57 | <annevk> | mkwst: what's the setup in Chrome? |
| 05:59 | <mkwst> | Currently? Still frame type. :) |
| 05:59 | <annevk> | mkwst: so it matters for referrer for instance |
| 06:00 | <annevk> | if you have a link in parent that targets the child and follow that, the referrer is the parent |
| 06:00 | <annevk> | if you have a link in child that targets the child/parent and follow that, the referrer is the child |
| 06:00 | <mkwst> | We throw all the data we need for Referrer into the request, and then do any stripping in the network stack. |
| 06:01 | <mkwst> | which boils down to the requesting URL and policy. |
| 06:02 | <mkwst> | Because the network stack lives way above Blink, and has no way of digging back down into the execution.context. |
| 06:02 | <annevk> | Yeah that makes sense |
| 06:02 | <annevk> | But we currently set referrer to "client" |
| 06:03 | <annevk> | Hmm... |
| 06:04 | <annevk> | And then the referrer specification does all kinds of tricks with request's client |
| 06:04 | <annevk> | But you want to do tricks with the "loading" client |
| 06:04 | <mkwst> | That is what the spec does. I'm not sure if any browser does. :) |
| 06:05 | <annevk> | Yeah, I guess we could pull some of that logic back in HTML too... |
| 06:05 | <annevk> | I'm just trying to figure out what a better setup would be |
| 06:06 | <annevk> | I think the easiest would be to introduce an additional client |
| 06:06 | <annevk> | Since service workers also wants the "loading" client, afaict |
| 06:06 | <annevk> | JakeA: ^^ |
| 06:06 | <annevk> | I'm somewhat surprised nobody noticed this before |
| 06:06 | <annevk> | Well maybe I shouldn't be, review of Fetch and Service Workers is notoriously poor |
| 06:07 | <mkwst> | The whole integration with navigation seems a bit hand-wavey. |
| 06:07 | <mkwst> | But hey! We can fix it all now! |
| 06:10 | <JakeA> | We're punting fetchEvent.client to v2, so we can make changes here |
| 06:11 | <annevk> | So either we introduce "requesting client" or "loading client" next to "client" but some specifications will need to change |
| 06:11 | <annevk> | Oooh |
| 06:12 | <annevk> | I know |
| 06:12 | <annevk> | Well, hmm, I was thinking "navigating client" as the client that initiates the navigation, but that might as well refer to the client that is navigating... |
| 06:13 | <annevk> | "navigate requesting client"? |
| 06:13 | <annevk> | Because this is only needed for Fetch resulting from a navigate attempt... It would mean that referrer policy needs to if/else on the two clients |
| 06:14 | <annevk> | But that doesn't seem too bad? |
| 06:14 | <annevk> | It also means that mkwst can just continue to use client as he wants to in Mixed Content and that the current Service Worker setup is correct too |
| 06:14 | <annevk> | And this should be what CSP wants too |
| 06:19 | <mkwst> | I think that sounds right. Let me get to my desk and think about it. |
| 06:38 | <annevk> | Domenic: mind if I take over your top-links work and finish it? |
| 06:39 | <annevk> | mkwst: certainly, once you tentatively approve I'll file a bug on Fetch and Referrer |
| 06:39 | <annevk> | mkwst: thankfully you got to this before I started rewriting HTML |
| 06:40 | <mkwst> | I'm only looking at it now because you're making me rewrite MIX. So, thank _you_, I guess? :) |
| 06:40 | <Domenic> | annevk: ah, I knew there was something I dropped on the floor in the last couple days. Sure, go ahead, since now is supposedly sleepytime for me. |
| 06:43 | <Domenic> | The other thing on my to do list is to respond to https://github.com/whatwg/html/issues/62 ... we shouldn't leave issues unanswered like that for too long |
| 06:44 | <annevk> | Fortunately mkwst hangs out here |
| 06:44 | <annevk> | My main problem there is lack of interest from other vendors |
| 06:45 | <mkwst> | So, for MIX, I thing I really only care about the context making the request. iframes don't actually matter, because they're just like every other blockable subresource request. |
| 06:45 | <mkwst> | For CSP, I need to know both the context making the request (to apply the correct policy), and that the request is targeting an iframe (to know to apply `child-src`) |
| 06:46 | <mkwst> | Referrer Policy needs to know the context making the request (for the origin/cross-origin distinction, and the referrer policy). I'm not sure it needs to care what context is being targeted. |
| 06:47 | <mkwst> | Domenic: What annevk said. I floated that proposal a million years ago on Specifiction and WHATWG. Crickets. |
| 06:47 | <mkwst> | Domenic: Once Firefox has a reasonable process model they may be more interested, as one of the things it would allow us to do is to keep passwords in the browser process, so that a corrupted renderer couldn't get direct access. |
| 06:48 | <mkwst> | Domenic: And it's a mild protection against XSS stealing form data directly. |
| 06:48 | <mkwst> | Domenic: Since it's trivial to implement, I think it's worth doing. Especially since the opaque FormData bits of it are necessary for credential management anyway. |
| 06:49 | <mkwst> | So it's really just more or less defining an attribute, and cutting off JavaScript access to `value`. |
| 06:51 | <Domenic> | Yeah but it's kind of a question of should it be in the spec if only one browser does it or is planning on doing it |
| 06:51 | <mkwst> | Not disagreeing with you. :) |
| 06:51 | <Domenic> | Which is a somewhat broader problem |
| 06:52 | <Domenic> | I am having vague 3am visions of rendered spec diffs or checkboxes to turn on experimental awaiting-implementations features while viewing the spec or something. |
| 06:52 | <dan2k3k4> | :o |
| 06:53 | <mkwst> | Go to bed. ;) |
| 06:53 | <Domenic> | Basically something better than these micro specs that monkeypatch HTML all over the place because they're extending HTML in some way |
| 06:53 | <Domenic> | At least I stayed up late for a good cause, namely computer games. |
| 06:54 | <mkwst> | Domenic: But I love monkey patching HTML! It's all I do! |
| 06:54 | <Domenic> | hehehe |
| 06:54 | <Domenic> | nn |
| 06:56 | <annevk> | mkwst: *waves hand* there is no context |
| 06:57 | <mkwst> | "context" => "{browsing, execution} context" |
| 06:58 | <annevk> | mkwst: ah okay, so it sounds like we're in agreement |
| 06:59 | <annevk> | Hopefully many years from now bz will look at this (because he's trying to sort something out) and will be not be like "what were you thinking?!" |
| 07:00 | <mkwst> | I'm going to need you to review the fetch bits in MIX. They're getting much more complicated than I'd like. |
| 07:00 | <annevk> | That's the kind of stuff that keeps you up at night |
| 07:13 | <mkwst> | I lied. I need the target context in MIX. |
| 07:14 | <mkwst> | Otherwise I can't exclude top-level navigation from mixed content checks. |
| 07:16 | <annevk> | Right, that client's corresponding browsing context is what you call "target context" I think |
| 07:16 | <annevk> | s/that// |
| 07:17 | <annevk> | I would call that "loading browsing context" or some such |
| 07:17 | <mkwst> | I thought `client` was the browsing context making the request? |
| 07:17 | <annevk> | No, that would be the new "navigate requesting client" |
| 07:18 | <annevk> | "navigate-requesting client" |
| 07:19 | <mkwst> | ok. so that will either be null (in the case that the request's target is not "document"), or the client that initiated the navigation? |
| 07:21 | <mkwst> | Hrm. This is somewhat strange. If I'm navigating an iframe, do I have an environment settings object yet? I don't think I do. |
| 07:21 | <mkwst> | Is `client` the settings object of the page that was previously in the frame? That I'm navigating away from? |
| 07:24 | <annevk> | mkwst: I think <iframe> will due to about:blank magic |
| 07:24 | <annevk> | mkwst: the top-level browsing might not always |
| 07:25 | <annevk> | mkwst: but yeah, maybe that's a bad setup |
| 07:26 | <annevk> | ugh |
| 07:26 | vigneshh | slaps vigneshh around a bit with a large fishbot |
| 07:35 | <mkwst> | annevk: Sanity check https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-fetch? |
| 07:41 | <annevk> | mkwst: that looks about right, with the caveat that client for <iframe> is broken |
| 07:43 | <mkwst> | Does it also make sense, or do I need to add more explanatory notes? |
| 07:46 | <annevk> | mkwst: 2.4.2 does not seem to be needed |
| 07:47 | <annevk> | mkwst: or is 2.4.2 specifically about same-origin? might be better to check for that then... |
| 07:48 | <mkwst> | We block insecure CORS requests in 2.3, so I guess 2.4.2 is probably irrelevant, yeah. |
| 07:48 | <annevk> | mkwst: it makes sense to me, but I'm not sure what that's worth |
| 07:49 | <mkwst> | annevk: if you, having written Fetch, didn't understand what I was doing, then it's hopeless. :) |
| 07:58 | <yhirano_> | annevk: I run "make" on the fetch spec repo, and it complains that some specs don't exist. Do I need to modify data/specs.json in the anolis directory? Is there any specs.json for the fetch spec uploaded? |
| 07:59 | <annevk> | yhirano_: do you have the xref repository? |
| 07:59 | <annevk> | yhirano_: that is, did you read https://wiki.whatwg.org/wiki/GitHub#Makefile? |
| 08:00 | <yhirano_> | annevk: thanks, i didn't, i will. |
| 08:04 | <yhirano_> | annevk: it works, thank you! |
| 08:05 | <annevk> | yhirano_: no worries, looking forward to the PR! |
| 09:13 | <annevk> | gsnedders: why did https://github.com/html5lib/html5lib-python/pull/126 never land? |
| 09:44 | <Titi_Alone> | Hello, |
| 09:44 | <Titi_Alone> | I've a question about the URL living standard, who should I contact? |
| 09:45 | <Ms2ger> | Ask |
| 09:46 | <Titi_Alone> | In the Ipv6 perser |
| 09:46 | <Titi_Alone> | *parser |
| 09:46 | <hsivonen> | nox: I didn't write <template> parsing support. wchen did. I don't have anything more useful to say than pointing at the code. Sorry. |
| 09:47 | <hsivonen> | annevk: I'm writing the Big5 stuff in Java first, since I want to have an Encoding Standard impl. in Java, too, eventually. |
| 09:47 | <Titi_Alone> | In the Ipv6 parser section, the only thing to do if Ipv4 is the things written on line 8? |
| 09:47 | <hsivonen> | annevk: also, it's nicer to deal with bugs in Java first and then port over to C++, since it's easier to test an individual class in isolation in the Java context than in the XPCOM context |
| 09:48 | <annevk> | Titi_Alone: what do you mean by "If IPv4"? |
| 09:48 | <hsivonen> | annevk: I'm not autotranslating to C++ this time, though. Doing it manually. |
| 09:48 | <annevk> | Titi_Alone: the IPv4 part of an IPv6 address is handled by steps 8-10 |
| 09:48 | <hsivonen> | annevk: as for Python, even rust-encoding uses Python to turn the indexes into array literals |
| 09:49 | <annevk> | hsivonen: do you use JSON as the input? |
| 09:49 | <hsivonen> | annevk: yes |
| 09:49 | <Titi_Alone> | Yes, that was my question, I thing the spec is unclear on this point |
| 09:49 | <hsivonen> | annevk: having JSON in the spec repo is awesome |
| 09:50 | <annevk> | Titi_Alone: "IPv4" there is just a marker |
| 09:50 | <hsivonen> | annevk: I use the .txt indeces only in a browser tab for visualizing patterns and for searching for interesting cases |
| 09:50 | <annevk> | Titi_Alone: if you have suggestions though, please file an issue :-) |
| 09:51 | <annevk> | hsivonen: yeah, me too, perhaps at some point we should flip what is normative |
| 09:51 | <Titi_Alone> | Don't you think that 9 and 10 should be substeps of 8? |
| 09:51 | <annevk> | Titi_Alone: no |
| 09:52 | <Titi_Alone> | Why? That's the case for Finale and Main. |
| 09:52 | <annevk> | Titi_Alone: no Finale is also steps 12 and 13 |
| 09:53 | <annevk> | Titi_Alone: and Main is also step 7 |
| 09:53 | <Titi_Alone> | Ok, that's really unclear for me. |
| 09:54 | <annevk> | Titi_Alone: it's just there so you can write "Jump to X" |
| 09:54 | <Titi_Alone> | The instructions for the marker to another marked belongs to the first marker ? |
| 09:54 | <annevk> | Titi_Alone: they don't mean anything else |
| 09:54 | <annevk> | Titi_Alone: when reading a specification you should never try to read meaning into things, only read what it says, literally |
| 09:56 | <Titi_Alone> | I'll try, but here, I was thinking Ipv4 was just the instruction 8. |
| 09:57 | <Titi_Alone> | Thanks for telling me that was not the case, anyway. |
| 09:58 | <annevk> | Titi_Alone: no worries, and again, if you have a way of saying the same thing but clearer, don't hesitate to let me know :-) |
| 09:58 | <annevk> | Titi_Alone: or provide a PR, even |
| 09:59 | <Titi_Alone> | annevk: Maybe precising somewhere at the begin or at the end of the spec that these are juste markers? |
| 10:00 | <annevk> | Titi_Alone: would it have helped you if there was a note just after the IPv6 parser algorithm saying so? |
| 10:00 | <annevk> | Titi_Alone: I can add such a note right now |
| 10:01 | <Titi_Alone> | annevk: What do you mean, a note? |
| 10:02 | <annevk> | <p class="note no-backref">To be clear, <a lt='IPv6 parser Main'>Main</a>, |
| 10:02 | <annevk> | <a lt='IPv6 parser IPv4'>IPv4</a>, and <a lt='IPv6 parser Finale'>Finale</a> are simple markers. |
| 10:02 | <annevk> | They serve no purpose other than being a location the algorithm can jump to. |
| 10:02 | <annevk> | Titi_Alone: something like that ^^ |
| 10:03 | <Titi_Alone> | annevk: Yes, that would be really helpful. |
| 10:03 | <annevk> | Titi_Alone: should I list you as "Titi_Alone" in the acknowledgments or would you prefer another nick or actual name? |
| 10:04 | <annevk> | Titi_Alone: see https://url.spec.whatwg.org/#acknowledgments |
| 10:05 | <Titi_Alone> | annevk: Yes, Titi_Alone suits me |
| 10:07 | <Titi_Alone> | Is there another point where there are such markers in the spec? |
| 10:08 | <annevk> | Titi_Alone: I think only IPv6 uses them |
| 10:08 | <annevk> | Titi_Alone: committed the note |
| 10:10 | <Titi_Alone> | Thanks, that clarifies the spec. |
| 10:12 | <Titi_Alone> | annevk: I also have another question, when a "living standard" becomes a standard? |
| 10:12 | <Ms2ger> | It is a standard |
| 10:13 | <Ms2ger> | It says so right in the name: "Living >>>Standard<<<" |
| 10:14 | <Titi_Alone> | But why is it living? |
| 10:14 | <Titi_Alone> | *"living" |
| 10:14 | <annevk> | Titi_Alone: because it's never done |
| 10:14 | <Titi_Alone> | So it will always be a living standard? |
| 10:15 | <annevk> | Titi_Alone: ideally, unless URLs somehow disappear in which case it would become a Dead Standard, but that seems unlikely |
| 10:16 | <Titi_Alone> | Ok, that's great, thanks you. |
| 10:41 | <nox> | annevk: Shouldn't we just kill the references to DOM-Parsing and define innerHTML and outerHTML ourselves? |
| 10:42 | <annevk> | nox: we used to: https://github.com/whatwg/domparsing |
| 10:42 | <annevk> | nox: but Ms2ger gave up |
| 10:42 | <nox> | annevk: What do you mean? |
| 10:43 | <annevk> | nox: the W3C forked our work and made a better standard |
| 10:44 | <annevk> | nox: I do think it would be better to have this defined as part of HTML/DOM, but there's many things to fix |
| 10:45 | <nox> | annevk: Ok. |
| 10:45 | <nox> | annevk: I just meant that for innerHTML and outerHTML btw. |
| 10:46 | <nox> | Or just innerHTML, it's only 2 steps, |
| 10:47 | <annevk> | nox: well, there's also a getter |
| 10:47 | <nox> | Mmh, right. |
| 10:47 | <annevk> | nox: anyway, not sure it makes sense to define those separately and separately from createContextualFragment() and such |
| 10:47 | <nox> | Sure. |
| 10:47 | <annevk> | nox: and you might be forgetting about innerHTML on XML nodes |
| 10:47 | <nox> | Right. |
| 10:48 | <annevk> | also, PRs accepted |
| 10:48 | <nox> | annevk: So we won't chnage anything in the syntax chapter, right? |
| 10:48 | <annevk> | nox: for <template>? |
| 10:48 | <nox> | Yes. |
| 10:48 | <annevk> | I haven't seen any issues reported against it |
| 10:49 | <nox> | annevk: Cool. |
| 10:49 | <nox> | annevk: Just asked to close the corresponding html5ever bug. :) |
| 11:01 | <zcorpan> | what do we do with bugs like https://www.w3.org/Bugs/Public/show_bug.cgi?id=29041 |
| 11:03 | <hsivonen> | zcorpan: how did Chrome come to allow that? bug? they just made stuff up without a spec bug? |
| 11:03 | <hsivonen> | also, allowing <template> in <frameset> seems sad |
| 11:04 | <nox> | The real question is, why did they even need such a thing? |
| 11:04 | <nox> | Feel free to ping me when you see things about templates that are wrong in the spec, given I implemented them in Servo this week, I would prefer if my implementation is interoperable. :) |
| 11:04 | <mkwst> | hsivonen: You can't trust Chrome folks. They're crazy. |
| 11:17 | <annevk> | zcorpan: we should get Chrome to fix it |
| 11:17 | <annevk> | zcorpan: and maybe test it in html5lib? |
| 11:17 | <annevk> | s/maybe// |
| 11:18 | annevk | added a comment to the bug |
| 11:18 | <zcorpan> | hsivonen: i don't know |
| 11:20 | <annevk> | hsivonen: https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fwhatwg%2Fhtml%2Fpull%2F101&sa=D&sntz=1&usg=AFQjCNHcrkfoj8uLlM7mfH07I6NwiQtJOA |
| 11:20 | <annevk> | hsivonen: https://github.com/whatwg/html/pull/101 |
| 11:20 | <annevk> | hsivonen: ignore that first link |
| 11:22 | <zcorpan> | it looks like chrome implemented the early template spec. http://www.w3.org/TR/2013/WD-html-templates-20130214/#in-frameset-addition - http://w3c-test.org/html/semantics/scripting-1/the-template-element/template-element/template-descendant-frameset.html |
| 11:23 | zcorpan | files a bug |
| 11:32 | <annevk> | zcorpan: ta |
| 11:39 | <gsnedders> | annevk: because of all the html5lib tests being broken |
| 11:39 | <gsnedders> | annevk: because html5lib-python is miles behind in implementation terms |
| 11:40 | <annevk> | gsnedders: oh that sounds bad |
| 11:40 | <gsnedders> | annevk: so I have no trust that the PR doesn't break other things |
| 11:40 | <annevk> | gsnedders: that PR is actually wrong compared to other impls |
| 11:40 | <gsnedders> | can you comment as much? |
| 11:42 | <annevk> | gsnedders: done |
| 11:43 | <gsnedders> | thanks |
| 11:44 | <gsnedders> | fixing html5lib-python is a fair way down to to-do list |
| 11:44 | <gsnedders> | stuff dealing with html5lib-tests is currently at the top |
| 12:00 | <nox> | annevk: insertAdjacentHTML should be patched too, I think. |
| 12:16 | <annevk> | nox: yeah, seems like it |
| 12:17 | <annevk> | gsnedders: perhaps you should make sure html5lib-tests covers http://w3c-test.org/html/semantics/scripting-1/the-template-element/template-element/template-descendant-frameset.html too |
| 13:00 | <gsnedders> | annevk: yeah, we're probably missing a fair bit of stuff |
| 13:00 | <gsnedders> | annevk: esp. around template |
| 13:01 | <nox> | annevk: The good thing is that we don't really need tests for template fragments. |
| 13:01 | <annevk> | nox: heh, I guess there's always an upside of sorts |
| 13:01 | <nox> | In html5lib-tests I mean. |
| 13:02 | <gsnedders> | nox: why not? |
| 13:02 | <nox> | We should have some for the template insertion modes, but that's small. |
| 13:02 | <nox> | gsnedders: I mean the behaviour of setting innerHTML, that's outside of the scope of the tree builder tests, right? |
| 13:05 | <gsnedders> | nox: we have tests for that! |
| 13:05 | <gsnedders> | nox: #document-fragment, etc. |
| 13:05 | <nox> | gsnedders: Yes but that's not innerHTML, is it? |
| 13:05 | <gsnedders> | nox: ok, not /quite/ |
| 13:06 | <gsnedders> | it's the fragment parsing algorithm |
| 13:06 | <nox> | The parsing of a template fragment doesn't involve the template contents of said template. |
| 13:06 | <nox> | Yes. |
| 13:07 | <gsnedders> | https://html.spec.whatwg.org/#parsing-html-fragments is what we have tests for |
| 13:07 | <gsnedders> | which IIRC innerHTML is a tiny wrapper around |
| 13:07 | <nox> | Yes. With a special case for templates. |
| 13:10 | <gsnedders> | where's the special case there? |
| 13:10 | <gsnedders> | the spec doesn't define one AFAICT? |
| 13:11 | <zcorpan> | r? https://critic.hoppipolla.co.uk/r/5785 |
| 13:19 | <gsnedders> | nox: I can't see any special case for templates in the innerHTML spec? |
| 13:19 | <nox> | gsnedders: https://github.com/w3c/DOM-Parsing/issues/1 |
| 13:20 | <nox> | gsnedders: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18794 |
| 13:20 | <nox> | https://github.com/w3c/webcomponents/commit/c3c46d87f9764a746523ec17853b0a5eb5ed46e0 |
| 13:21 | <gsnedders> | why aren't we patching this a tthe HTML level? |
| 13:21 | <nox> | gsnedders: Because innerHTML is defined there. It used to be patched at the HTML level when webcomponents was a thing. |
| 13:22 | <nox> | Anyway, I was just saying that's not a matter for the fragment parsing algorithm itself. |
| 13:22 | <gsnedders> | my point is why doesn't the fragment parsing algorithm fix it? |
| 13:22 | <gsnedders> | because surely that's the common point where all these things go through? |
| 13:26 | <nox> | gsnedders: Because it would be extremely weird. |
| 13:26 | <nox> | gsnedders: The fragment parsing just parses. |
| 13:26 | <nox> | gsnedders: Now it would need to replace all the template contents of some template node. |
| 13:30 | <Ms2ger> | annevk, r? https://github.com/whatwg/html/pull/103 |
| 13:39 | <Ms2ger> | TabAtkins, ~1500 person-days to implement the entire HTML spec? |
| 13:42 | <jgraham> | 6 people 1 year? |
| 13:42 | <jgraham> | Sounds implausible |
| 13:42 | jgraham | doesn't know the context |
| 13:48 | <espadrine> | the context is https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Sep/0019.html |
| 13:49 | <espadrine> | and https://twitter.com/brucel/status/639720876099944448 |
| 13:50 | <nox> | Ms2ger: Just saw https://github.com/whatwg/html/pull/103, nice! |
| 13:51 | <nox> | Ms2ger: It is blocked by a DOM issue though. |
| 13:51 | <nox> | Ms2ger: https://github.com/whatwg/dom/pull/66 |
| 13:53 | <Ms2ger> | I guess it is, yes |
| 14:22 | <Ms2ger> | https://twitter.com/webkit/status/639800468475125760 |
| 14:22 | <Ms2ger> | Now import them all |
| 14:30 | <gsnedders> | nox: oh, right, because it just returns the child nodes of root |
| 14:30 | <gsnedders> | nox: I'm an idiot |
| 14:30 | <gsnedders> | nox: ignore me |
| 14:30 | <Ms2ger> | gsnedders, news? :) |
| 14:30 | <gsnedders> | Ms2ger: shush you |
| 14:30 | <nox> | Ah ah. |
| 14:31 | <gsnedders> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3620 — why does Gecko's parsing alter with the removal of one <foo> tag? |
| 14:31 | <gsnedders> | I don't think that should hit an AAA limit? |
| 14:31 | <gsnedders> | But I don't have the AAA swapped in atm |
| 14:32 | <gsnedders> | or is this hitting the inner loop counter? |
| 14:32 | <gsnedders> | hmmm |
| 14:34 | <gsnedders> | also why does the aside end up as a child of the div? is that AAA reparenting again? |
| 14:34 | <gsnedders> | Reviewing these tests seems to be AAA hell :) |
| 14:40 | <gsnedders> | nox: so I'm not entirely sure what exactly the document-fragment tests are meant to test now :P |
| 14:41 | <gsnedders> | nox: I think it's the return value of the document fragment parsing algorithm |
| 14:41 | <nox> | gsnedders: What do you mean? |
| 14:42 | <gsnedders> | jgraham: is there any way to force Critic to let it review "own" changes |
| 14:42 | <jgraham> | gsnedders: Yeah, if you mark yourself as a reviewer |
| 14:45 | <gsnedders> | jgraham: https://critic.hoppipolla.co.uk/r/5781 won't let me review? |
| 14:46 | <Ms2ger> | I don't know that I ever got that to work |
| 14:46 | <jgraham> | gsnedders: Now? |
| 14:47 | <gsnedders> | wfm now |
| 14:47 | <gsnedders> | jgraham: what did you do? |
| 14:47 | <jgraham> | I went to "manage assignments" and unchecked/checked you for all files |
| 14:48 | <gsnedders> | how do I select text in Critic again? holding down shift is doing weird stuff |
| 14:49 | <jgraham> | Hold down some key that doesn't do weid stuff? Popup a dialog and select in the other content |
| 14:49 | <jgraham> | ? |
| 14:50 | <Ms2ger> | Alt |
| 14:53 | <annevk> | TabAtkins: :-( |
| 14:53 | <annevk> | TabAtkins: I update Bikeshed |
| 14:54 | <annevk> | TabAtkins: now EventTarget links to http://www.w3.org/TR/uievents/#interface-EventTarget rather than staying an internal link |
| 14:54 | <annevk> | TabAtkins: CustomEvent too |
| 14:55 | <annevk> | TabAtkins: even Event |
| 14:55 | <TabAtkins> | lolwut |
| 14:57 | <annevk> | I mean it's great that we got spaces back, but ... |
| 14:58 | <TabAtkins> | That sounds super weird. I'll check it out. |
| 14:59 | <annevk> | It also adds trailing whitespace... |
| 14:59 | <annevk> | E.g., <td><a data-link-type="dfn" href="https://encoding.spec.whatwg.org/#iso_8859_5">iso-8859-5</a>; gets a space added at the end |
| 15:02 | <TabAtkins> | Inside of the <a>, or after? |
| 15:05 | <TabAtkins> | annevk: Well, I'll check it out. Current DOM source? |
| 15:05 | <annevk> | TabAtkins: yes |
| 15:06 | <annevk> | TabAtkins: after </a> |
| 15:16 | Krinkle | risks asking a dangerously stupid question. With w3c and whatwg both being on github now, the borders between them seem fuzzier than they used to be. |
| 15:16 | <Hixie> | where the data is stored doesn't really have any bearing on how different they are :-) |
| 15:17 | <Krinkle> | Previously it appeared the key specs were maintained by whatwg to eventually be approved/published on w3 later. |
| 15:17 | <Hixie> | it's been a long time since any of the whatwg editors agreed to that really |
| 15:17 | <Krinkle> | but now e.g. preload is drafted under w3c directly |
| 15:18 | <Hixie> | most web specs are written at the w3c directly, they're a much bigger organisation :-) |
| 15:18 | <Hixie> | e.g. the csswg alone produces more spec than the entire whatwg |
| 15:18 | <Krinkle> | Oh you mean whatwg is, you know, a wg? |
| 15:19 | <Krinkle> | The rouge clan that left the nest :P |
| 15:19 | <Hixie> | dunno about rouge |
| 15:19 | <Krinkle> | Hehe |
| 15:19 | <gsnedders> | jgraham, Ms2ger: sorry for the email spam |
| 15:20 | <Ms2ger> | More specs or more spec? :) |
| 15:21 | <Krinkle> | Anyhow, I think I like the end result. There seems to be more harmony now. In that both entities seem to have authority (as recognised by developers and vendors) over their respective specs. E.g. new stuff in dom goes in whatwg/dom and is implemented from there. |
| 15:21 | <Hixie> | Krinkle: there's a lot of history between the two groups, and 12+ years of the people involved in the whatwg trying to work with the w3c in various ways |
| 15:21 | <Hixie> | so there's no simple story to tell |
| 15:21 | <Hixie> | while the w3c fork the whatwg html spec, though, i wouldn't proclaim world peace. |
| 15:24 | <Krinkle> | It's great that these things can happen though. Vendors are not obligated to any sort of W3 license. Consensus and in the end, the users/vendors decide what they implement for the open web. |
| 15:25 | <Krinkle> | I was mostly asking in the context of source maps, which I'd like to see moved from google docs to a git repo. |
| 15:25 | <gsnedders> | more template, table fun… |
| 15:25 | <Krinkle> | Hixie: Is it obvious to you which entity would maintain that? (And if so, how can you tell?) |
| 15:26 | <gsnedders> | nox, annevk: is there any easy way to find all your recent template bugs? |
| 15:26 | <annevk> | gsnedders: that DOM-Parsing one ended up being the only one |
| 15:26 | <nox> | gsnedders: I linked the relevant bits in the DOM-Parsing one. |
| 15:26 | <annevk> | gsnedders: well, and there was that issue jgraham spotted this morning, about <frameset> and <template> |
| 15:27 | <Hixie> | Krinkle: not sure what you mean. maintain what? |
| 15:27 | <jgraham> | s/jgraham/zcorpan/? |
| 15:27 | <gsnedders> | annevk: think I've found another… |
| 15:27 | <Krinkle> | Hixie: The Source Maps standard. If that were to become a spec, is there a natural fit in either w3c or whatwg, based on who authors it or based on the subject matter..? |
| 15:28 | <annevk> | jgraham: yes |
| 15:28 | <annevk> | gsnedders: oh, please tell! |
| 15:28 | <gsnedders> | have as a doc: "<template><a><table><a>". consider the execution of "appropriate place for inserting a node" during the second <a>. |
| 15:28 | <Hixie> | Krinkle: dunno what that is |
| 15:28 | <annevk> | Krinkle: no, it's more about what you care about as editor |
| 15:29 | <gsnedders> | We hit "If last table has a parent node, then let adjusted insertion location be inside last table's parent node, immediately before last table, and abort these substeps." |
| 15:29 | <Krinkle> | http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?hl=en_US&pli=1&pli=1 |
| 15:29 | <annevk> | Krinkle: e.g., one of the things I care about is CC0 |
| 15:29 | <annevk> | Krinkle: the W3C won't have it |
| 15:29 | <gsnedders> | but we aren't really inserting it within last table's parent node |
| 15:29 | <annevk> | Krinkle: another thing I care about is not being subject to the whims of the W3C AC |
| 15:30 | <nox> | gsnedders: How is it not last table's parent node? |
| 15:30 | <gsnedders> | nox: compare with what step 3 says |
| 15:30 | <Krinkle> | annevk: Right. So in terms of subject, it could fall under either. But it's up to the spec authors to choose where they want it, and to w3c/whatwg whether they want to own it. |
| 15:31 | <bblfish> | hi |
| 15:31 | <gsnedders> | nox: we want something like "if last table has a parent node and it is a template element, then let adjusted insertion location be inside last table's parent node's template contents, immediately before last table, and abort these substeps." |
| 15:32 | <bblfish> | How does one discuss security misunderstandings if one cannot do so publically? |
| 15:32 | <Hixie> | Krinkle: the whatwg doesn't really "own" the specs it publishes. it just asks the specs' editors to commit to keeping the specs maintained. |
| 15:32 | <bblfish> | In particular https://github.com/whatwg/html/issues/102 |
| 15:33 | <Krinkle> | Hixie: Hm.. I see. |
| 15:33 | <Krinkle> | Does whatwg hire employees or contractors, or is it all volunteer based? |
| 15:34 | <Hixie> | Krinkle: entirely voluntary (if you count companies like google paying people to work on things "volunteering") |
| 15:34 | <Krinkle> | Right |
| 15:34 | <Hixie> | Krinkle: i pay the hosting costs out of pocket, iirc anne pays the certificate costs out of pocket |
| 15:34 | <Hixie> | i think that's it, cost-wise |
| 15:34 | <Krinkle> | but whatwg as its own entity does not have spendings on human resources. |
| 15:34 | <Krinkle> | cool |
| 15:34 | <Hixie> | whatwg as its own entity is not really an entity at all :-) |
| 15:35 | <annevk> | Yeah, we're not a legal entity, just a community |
| 15:35 | <Krinkle> | Yeah, I forgot for a second that many of the whatwg rock stars are full-time employed with this as part of their job. |
| 15:36 | <Krinkle> | Cool. |
| 15:36 | <Hixie> | bblfish: generally one gets a job as a security vendor and then talks about it with other security vendors :-) |
| 15:36 | <Krinkle> | I suspected as much, but wasn't sure. It's well organised :) |
| 15:37 | <Hixie> | bblfish: i'm only tangentially involved with security discussions so i'm not really the one to ask |
| 15:37 | <bblfish> | that sounds like the Australian rule that security has to be government licences. Crazy. |
| 15:37 | <annevk> | Krinkle: well, the nice thing about being able to set your own course is that you can do things properly and are not subject to folks that are not actually involved much |
| 15:38 | <annevk> | Krinkle: that was a major problem for me at the W3C |
| 15:38 | <annevk> | Krinkle: very hard to change things, whereas here you're much more empowered to tackle things |
| 15:38 | <Hixie> | bblfish: i certainly admit that in this case anyone using <keygen> is probably so hosed that it doesn't really matter either way |
| 15:39 | <bblfish> | @Hixie I understand. I hope you can see how secrecy in security can be used to make decisions that are bad for security. |
| 15:39 | <Hixie> | bblfish: secrecy anywhere can be used to make bad decisions. Transparency in security can also be used to steal billions of dollars. |
| 15:39 | <Hixie> | unlike in most other places. |
| 15:39 | <gsnedders> | annevk: do you want a bug for the above? |
| 15:40 | <annevk> | gsnedders: issue, please |
| 15:40 | <gsnedders> | annevk: on gh? |
| 15:40 | <annevk> | gsnedders: and thank you |
| 15:40 | <annevk> | gsnedders: https://github.com/whatwg/html/issues/new |
| 15:40 | <annevk> | gsnedders: Bugzilla is closed for business |
| 15:41 | <bblfish> | Hixie: that's all upside down. Security only works through transparency. That is why people use open protocols and mathematics for security. It's well known that security through obscurity is the worst. |
| 15:41 | <gsnedders> | annevk: bah, I use bug/issue interchangably :) |
| 15:41 | <Hixie> | bblfish: ok. if i ever accidentally come across your bank credentials, i should make sure to discuss these on a public list, yes? and for full transparency i should include them all. |
| 15:42 | <bblfish> | Furthermore the flaws in MD5 were demonstrated openly by top cryptographers working very carefully in 2008 |
| 15:42 | <bblfish> | here we are not discussing a flaw: we are discussing a non existent flaw |
| 15:42 | <bblfish> | Ie a misunderstanding of how things work |
| 15:42 | <bblfish> | there is no security problem |
| 15:43 | <bblfish> | but the feat that there may be one is being used to remove security aspects from browsers. |
| 15:43 | <bblfish> | Just think about how crazy that is. |
| 15:43 | <Hixie> | so if I come across your bank password but think it's not your bank password, I should feel free to discuss it anyway? even if it turns out to actually be your bank password? |
| 15:43 | <Hixie> | the security issue really isn't why <keygen> is being removed |
| 15:43 | <Hixie> | it's just a minor issue amongst many bigger ones |
| 15:44 | <Hixie> | honestly i'm shocked that anyone is using <keygen>. Until I unilaterally decided to spec it, it was entirely non-standard. |
| 15:44 | <Hixie> | and nobody, nobady at ALL, was making the SLIGHTEST complaint about that fact. |
| 15:44 | <gsnedders> | jgraham: https://critic.hoppipolla.co.uk/r/5781 — can you review the two lines that are pending? |
| 15:44 | <gsnedders> | jgraham: because, like, they genuinely are my work |
| 15:44 | <bblfish> | The MD5 argument is part of a number of bad arguments being launched against keygen. It's a matter of divide and conquer. |
| 15:45 | <bblfish> | You should be ashamed to be putting such arguments forward. |
| 15:45 | <bblfish> | And even more so of not allowing discussion of it. |
| 15:45 | <Hixie> | ok. in the interests of solving this issue, please consider that i now think <keygen> is entirely secure. |
| 15:46 | <Hixie> | are you satisfied with the current situation, or does that not change anything? |
| 15:46 | <bblfish> | That's a step forward. |
| 15:48 | <bblfish> | If we make more steps like this we'll be able to get at the root of the issue, and perhaps find a solution that will allow browsers to be more secure and compete correcly against apps. |
| 15:48 | <bblfish> | and also help solve some major issues of security on the web. |
| 15:48 | <Hixie> | not really, since the reason the spec says it's going to be removed is that the browser vendors said it was going to be removed, and i'm not a browser vendor |
| 15:49 | <bblfish> | It's not brwoser vendors per se. It's a vocal group of people in the browser vendor space who are playing a dangerous game |
| 15:49 | <Hixie> | the only thing that would change my mind regarding whether the spec's current text is appropriate is finding out that it was wrong, which would mean finding out that the browser vendors were in fact NOT planning on removing it. |
| 15:49 | <Hixie> | the "vocal group of people in the browser vendor space" are "the people who get to make that decision" |
| 15:49 | <bblfish> | YEs, but for that to happen we need to make sure that the arguments are clear |
| 15:50 | <Hixie> | the fact that they're "vocal" is useful for us, but they could just as easily have silently removed the feature without comment and it wouldn't affect this situation (well, I guess it would have removed the feature faster rather than having a warning put in place first) |
| 15:50 | <Hixie> | the only argument i care about is "what are the browsers doing". so arguing with me about the technical aspects of the feature does nothing. |
| 15:51 | <bblfish> | what is happening seems a type of social hacking (cracking): you play one group against an other, and keep things in the dark to get something done that nobody would accept if they understood the full issue. |
| 15:51 | <Hixie> | i'm really not trying to play any group against any other |
| 15:51 | <Hixie> | i'm not even trying to play |
| 15:51 | <bblfish> | yes, you are not. Other people are doing the social hacking. |
| 15:51 | <Hixie> | ok... not sure why you're bringing it up with me though :-) |
| 15:51 | <bblfish> | But you are allowing it to happen, by for example closing issues like https://github.com/whatwg/html/issues/102 within 15 minutes. |
| 15:52 | <bblfish> | Wait that was not you who close it. |
| 15:52 | <Hixie> | that issue was entirely unactionable |
| 15:52 | <Hixie> | it made zero requests for change to the spec, and presented no arguments to justify any changes to the spec. |
| 15:52 | <Hixie> | as such, that it stayed open for 15 minutes means we were slacking :-) |
| 15:53 | <bblfish> | I am not a WHATWG professional. Perhaps one could find a way to diffuse the MD5 fear with some text. |
| 15:54 | <bblfish> | That keygen part is missing a diagram explaining how keygen is actually used. |
| 15:54 | <Hixie> | the keygen spec is only very barely a spec |
| 15:54 | <bblfish> | it works though. |
| 15:54 | <gsnedders> | jgraham: thx |
| 15:55 | <Hixie> | see above regarding how i unilaterally wrote it based on what scant documentation i could find |
| 15:55 | <Hixie> | despite nobody seeming to care one wit about whether it was specced or not |
| 15:55 | <bblfish> | thanks for doing that. |
| 15:55 | <bblfish> | I cared |
| 15:55 | <bblfish> | Tim Berners Lee cared |
| 15:55 | <Hixie> | lol no he didn't |
| 15:55 | <gsnedders> | jgraham: …now for trying to work out that one remaining issue |
| 15:55 | <Hixie> | he's the director of a standards organisation that ignored it for 10+ years |
| 15:55 | <bblfish> | he opened a thread on the Technical Architecture Group about it https://lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html |
| 15:56 | <Hixie> | if he cared, he would have done something about it, rather than just accidentally forking my work when i did it |
| 15:56 | <Hixie> | i mean nobody cared when i specced it |
| 15:56 | <Hixie> | it's cheap to care when it's being removed |
| 15:56 | <Hixie> | it means nothing |
| 15:56 | <bblfish> | I did not myself understand the misunderstandings that the current text could lead to |
| 15:56 | <Hixie> | (and the TAG means nothing too, so posting to the TAG about a removal is like the Inception of meaning nothing) |
| 15:57 | <Hixie> | the md5 thing really isn't the issue here. |
| 15:57 | <Hixie> | anyway. this has exceeded my quota for such discussions for the day. |
| 15:57 | <bblfish> | I think people were expecting the security specialists to help out here. |
| 15:57 | <Hixie> | this conversation cannot cause the spec to change. |
| 15:58 | <TabAtkins> | The md5 thing is *part* of why *browsers* want to remove it. It has nothing to do with why the spec is removing it - that's because the browsers want to remove it. |
| 15:58 | <bblfish> | yes, but it is a mistaken part |
| 15:58 | <bblfish> | and the other parts are IMHO mistaken too. |
| 15:59 | <TabAtkins> | Telling us won't help anything. |
| 15:59 | Ms2ger | yawns |
| 15:59 | Hixie | hands the baton over to tab and goes to take a shower (unrelated to this conversation!) |
| 15:59 | <TabAtkins> | Hixie: But I need to take a shower too! Noooooooo! |
| 15:59 | <gsnedders> | The spec probably isn't the right place to convince the browsers who want to remove it. |
| 15:59 | <Hixie> | mwuhahaha |
| 15:59 | <bblfish> | yes, that is indeed why a discussion at the TAG is helpful |
| 15:59 | <gsnedders> | Because likely nobody who is removing it from browsers will notice. |
| 15:59 | <Ms2ger> | Uhuh |
| 15:59 | <bblfish> | Security is a complex area. |
| 15:59 | <Ms2ger> | Because the TAG has been so effective |
| 15:59 | <bblfish> | IT really requires all to work together. |
| 15:59 | <gsnedders> | And nobody who is removing it from browsers will ntoice a discussion a t the TAG. |
| 16:00 | <bblfish> | Well if you know of better avenues for discussion I am ready |
| 16:00 | <TabAtkins> | Well, new TAG is useful. It also supports <keygen> removal. ^_^ |
| 16:00 | <gsnedders> | bblfish: I'd speak to those who made the decision to remove it from browsers |
| 16:01 | <Ms2ger> | You can always try to convince people in the bink-dev thread |
| 16:01 | <Domenic> | TAG is a pretty good black hole for such discussions |
| 16:01 | <espadrine> | bblfish: whatever fundamental reason that webid can no longer be implemented (in js or otherwise) without keygen is an issue you should raise to browser vendors |
| 16:01 | <espadrine> | clinging to keygen is likely hopeless |
| 16:01 | <bblfish> | You mean Harry Halpin does. He has a vested interest as he pushed the JS crypto spec. But these don't actually solve the problem as written as they are missing Chrome ( ie User Interface ) elements. |
| 16:01 | <Domenic> | People who do not implement can argue in circles with each other on www-tag and feel like they've accomplished a lot |
| 16:01 | <Ms2ger> | It's the new public-html |
| 16:02 | <bblfish> | What is needed is a forum where all the different pieces can be looked at together. |
| 16:02 | <Domenic> | hah. so true. |
| 16:02 | <bblfish> | IT could be the WHATWG, but you only do what browsers appear to want. |
| 16:02 | <TabAtkins> | bblfish: No, what's needed is to convince the browser vendors to change their mind. |
| 16:03 | <TabAtkins> | Literally nothing else will do anything at all. |
| 16:03 | <bblfish> | yes, and where do you do that? |
| 16:03 | <Domenic> | blink-dev, moz.platform, Edge UserVoice, Safari ... Twitter? |
| 16:03 | <TabAtkins> | blink-dev, mozilla-dev, webkit-dev, wherever IE likes talking to people |
| 16:03 | <Domenic> | right that |
| 16:03 | <Ms2ger> | IE doesn't like talking to people |
| 16:04 | <Ms2ger> | But try blink/webkit first |
| 16:04 | <Domenic> | Edge is quite friendly these days; I'd prefer we not perpetuate old prejudices. |
| 16:04 | <bblfish> | ok, so there are a number of different forums. And one forum is WHATWG. There is a bit of text about MD5 that could help with discussions in the other forums. |
| 16:04 | <ato> | Does anyone know about UUID’s here? There are different versions of it (1 though 5) and I’m wondering if it is sufficient to talk about “UUID” (as defined in RFC 4122) as a general concept, or if one should talk specifically about one version. |
| 16:04 | Ms2ger | is subscribed to the Gecko equivalent and would prefer to avoid more email about it |
| 16:05 | <gsnedders> | ato: They're all UUIDs and all interchangeable |
| 16:05 | <gsnedders> | ato: the type is encoded within the UUID |
| 16:05 | <gsnedders> | ato: generally you pick what type depending on a number of factors (anonmity of the generator, etc.) |
| 16:06 | <ato> | gsnedders: Does it make sense to pick the type? |
| 16:06 | <gsnedders> | ato: in a spec? why? |
| 16:07 | <ato> | gsnedders: To add some context, I don’t care about the interchange between UUIDs of different versions/types, as long as one type is inherently cohesive. |
| 16:07 | <gsnedders> | ato: they aren't really different "versions", they're different ways to generate a UUID |
| 16:08 | <ato> | gsnedders: Okay I see. |
| 16:08 | <nox> | gsnedders: I'm not sure I understand. |
| 16:08 | <gsnedders> | nox: about what? :) |
| 16:08 | <nox> | 17:31 <gsnedders> nox: we want something like "if last table has a parent node and it is a template element, then let adjusted insertion location be inside last table's parent node's template contents, immediately before last table, and abort these substeps." |
| 16:08 | <nox> | "and abort these substeps." |
| 16:08 | <ato> | gsnedders: Thanks (-: |
| 16:09 | <nox> | Step 3 is "If the adjusted insertion location is inside a template element, let it instead be inside the template element's template contents, after its last child (if any)." |
| 16:09 | <gsnedders> | nox: step three doesn't apply here, no? |
| 16:09 | <ato> | gsnedders: Do you mind if I reference what you said? |
| 16:09 | <gsnedders> | ato: go ahead |
| 16:09 | <nox> | gsnedders: "substeps". |
| 16:09 | <ato> | gsnedders: Cheers |
| 16:09 | <nox> | The foster parenting substeps in step 2. |
| 16:10 | <TabAtkins> | ato: What kind of monster does reversed smilies? |
| 16:10 | <nox> | Mmmh, but actually, it doesn't apply anyway. |
| 16:10 | <TabAtkins> | ato: Particularly ones where all the characters exist in the normal orientation! |
| 16:10 | <ato> | TabAtkins: (-:{ |
| 16:10 | <TabAtkins> | blocked |
| 16:10 | <ato> | TabAtkins: That’s my conspicuous smiley. |
| 16:11 | <TabAtkins> | In the real world, that's a mustachiod man wearing an umbrella hat. Get with the program. |
| 16:11 | <nox> | gsnedders: What's the issue exactly? |
| 16:11 | <ato> | TabAtkins: lol |
| 16:11 | <csarven> | Hixie Surely you've read my email now. Here it is in case it made it to the bin: https://gist.github.com/csarven/e5d190e82015f5f41b18 -- The point is that, WHATWG raised a concerned which was then clarified by bblfish. |
| 16:11 | <nox> | Actually, shouldn't it just be "If last table has a parent node, then let adjusted insertion location be inside last table's parent node, immediately before last table, and abort these substeps."? |
| 16:12 | <nox> | gsnedders: If the table was in a template, its parent node isn't the template anyway. |
| 16:12 | <gsnedders> | nox: am I being an idiot here? I think I am. |
| 16:12 | <nox> | gsnedders: Both. The spec too. |
| 16:12 | <nox> | We are discussing a Web spec anyway. We must be not very smart. |
| 16:12 | <gsnedders> | nox: So I think <template><table><a> is where the bug really is. |
| 16:13 | <nox> | gsnedders: If a table is parsed in a template, its parent cannot be a template. |
| 16:13 | <MikeSmith> | mkwst: I found a markup syntax error in your pr 93 source; is it OK with you if I just push a fix to the branch? |
| 16:13 | <nox> | Its parent can be a document fragment, in which case foster parenting should just work. |
| 16:13 | <MikeSmith> | mkwst: and in the future is that OK? |
| 16:13 | <nox> | Or another element, and that's not a problem either. |
| 16:13 | <gsnedders> | nox: why not? |
| 16:13 | <nox> | gsnedders: Because the parser never puts things in a template. |
| 16:13 | <gsnedders> | oh, right |
| 16:14 | <gsnedders> | that's not my confusion, gimmie a moment |
| 16:14 | <MikeSmith> | mkwst: (would take less time for me to just fix it, and generated less gihtub notification spam, etc.) |
| 16:15 | <Hixie> | csarven: see my comment earlier. please assume that i believe <keygen> is entirely secure. |
| 16:15 | <MikeSmith> | Hixie: wattsi error reporting is nice |
| 16:15 | <gsnedders> | nox: how does it's parent node because a document fragment? |
| 16:15 | <gsnedders> | nox: where in the spec is this? |
| 16:15 | <Hixie> | csarven: you can also assume that i think that <keygen> is the epitome of good design in every way. |
| 16:15 | <Hixie> | csarven: since it doesn't impact the discussion in the slightest |
| 16:15 | <Hixie> | MikeSmith: yeah? |
| 16:16 | <nox> | gsnedders: When you parse <table> after <template>, |
| 16:16 | <Hixie> | MikeSmith: anything in particular? it was a bit hit or miss in my experience :-) |
| 16:16 | <nox> | gsnedders: target is the current node, so <template>, |
| 16:16 | <MikeSmith> | Hixie: well it's helped me catch markup errors |
| 16:16 | <MikeSmith> | e.g., "Parse Error: (14571,170) unexpected end tag" |
| 16:16 | <nox> | gsnedders: Foster parenting is off (AFAICT), |
| 16:16 | <MikeSmith> | from mkwst PR 93 |
| 16:16 | <Hixie> | MikeSmith: i know the build.sh script has some specific things to prevent ms2ger from getting annoyed at you :-) |
| 16:17 | <MikeSmith> | heh |
| 16:17 | <nox> | gsnedders: so directly step 3, |
| 16:17 | <MikeSmith> | Hixie: yeah, notcied that |
| 16:17 | <Hixie> | MikeSmith: ah, yeah, i had it output line,col so that emacs would jump to the problem spot |
| 16:17 | <gsnedders> | "If the adjusted insertion location is inside a template element, let it instead be inside the template element's template contents, after its last child (if any)."… does that make it's parent node the template contents? |
| 16:17 | <nox> | gsnedders: and thus <table> is inserted in the template contents. |
| 16:17 | <MikeSmith> | Hixie: it gets the job done |
| 16:17 | <Hixie> | MikeSmith: iirc i never fixed it to correct the line numbers to handle merging in other files though. :-( |
| 16:17 | <MikeSmith> | oh |
| 16:18 | <gsnedders> | nox: to me it's not clear that the "parent node" of something in the template contents *is* the template contents |
| 16:18 | <nox> | gsnedders: The template contents is a document fragment. |
| 16:18 | <gsnedders> | nox: where is /that/ defined? |
| 16:18 | <nox> | gsnedders: https://html.spec.whatwg.org/multipage/scripting.html#template-contents |
| 16:19 | <nox> | Follow the links, Luke. :P |
| 16:19 | <gsnedders> | bah! |
| 16:19 | <gsnedders> | the problem with following the links is you end up in an infinite loop! |
| 16:19 | <csarven> | Hixie Those opinions are in fact irrelevant to the discussion. Again, the point is that WHATWG raised 2nd hand concerns. It is pointed out that they are not based on facts, and that an appropriate explanation was provided. Therefore, why does the discussion suddenly stop :) Will you be issuing a new email stating that your previous statements had no grounds and that you acknowledge the explanation on Github? And yes, we can assume your |
| 16:19 | <csarven> | view on keygen and the changes to the spec as is. |
| 16:21 | <Hixie> | the point is my opinions here are entirely irrelevant |
| 16:21 | <Hixie> | the reason the spec changed is that the browser vendors said they were going to remove it |
| 16:21 | <Hixie> | end of rationale |
| 16:21 | <Hixie> | everything else is a distraction |
| 16:22 | <csarven> | Okie dokie. |
| 16:22 | <nox> | gsnedders: Anyway, I don't see how a template can be the parent of an element on the stack of open elements. |
| 16:24 | <gsnedders> | nox: does the template contents ever get pushed to the stack? |
| 16:25 | gsnedders | looks closely |
| 16:26 | <gsnedders> | nox: afaict, the template contents DocumentFragment never gets pushed onto the stack of open elements |
| 16:26 | <gsnedders> | probably in part because it's not an element :) |
| 16:33 | <nox> | gsnedders: Not a matter AFAICT. |
| 16:34 | <nox> | gsnedders: check is about the table parent, not the stack. |
| 16:35 | <nox> | gsnedders: Sorry missed that it was a just question. No I don't think it's ever pushed on the stack. And it shouldn't because it's not an element as you said. |
| 16:42 | <MikeSmith> | maybe we can get the www-tag cranks interested in discussing <applet> deprecation too |
| 16:54 | <annevk> | wanderview: wow, quick turnaround on setting User-Agent support |
| 16:54 | <wanderview> | annevk: it was not set as a priority... but mystor took it to get started with SW |
| 16:55 | <wanderview> | he's pretty fast :-) |
| 16:55 | <gsnedders> | nox: yeah, indeed |
| 16:56 | <MikeSmith> | mkwst: nm I forgot that PR branch is in your fork (so I can't push to it anyway) |
| 16:56 | <nox> | gsnedders: So parsing itself has no bug, AFAICT. |
| 16:56 | <MikeSmith> | we need a way to raise PRs against PRs! |
| 16:57 | <nox> | MikeSmith: You can do that already. |
| 16:57 | <MikeSmith> | nox: oh! |
| 16:57 | <nox> | Just make a PR against the branch tip. |
| 16:57 | <MikeSmith> | how? |
| 16:57 | <MikeSmith> | ok |
| 16:57 | MikeSmith | tries |
| 16:57 | <nox> | MikeSmith: But if the PR is merged, upstream is probably going to ask for a rebase or whatever. |
| 16:58 | <MikeSmith> | ah |
| 16:58 | <nox> | Because then you will have a PR merge in your PR. |
| 17:00 | <MikeSmith> | ok |
| 17:00 | MikeSmith | throws caution to the wind |
| 17:02 | <MikeSmith> | hmm, but in github I can't have a fork of somebody else's fork of an upstream repo I already have a fork of myself, right? |
| 17:03 | <MikeSmith> | I guess i'll just fork it to one of my other orgs/accounts |
| 17:05 | <nox> | MikeSmith: Yes you can. |
| 17:06 | <MikeSmith> | hmm, I don't see how in the GH UI |
| 17:06 | <nox> | MikeSmith: I'm pretty sure you can make PR on repositories that you didn't even fork. |
| 17:07 | <MikeSmith> | hmm, dunno how to do that, so I will just proceed with forking |
| 17:07 | <nox> | https://github.com/<user>/<repos>/compare/<base>...<PR user>:<PR branch> |
| 17:07 | <nox> | AFAIK, there is a link somewhere to do that from the UI, but I can't remember where it is. |
| 17:07 | <nox> | MikeSmith: Oh right, on the branches page, the Compare buttons. |
| 17:08 | <nox> | MikeSmith: You arrive on the compare view, but with 4 form controls instead of 2. |
| 17:08 | MikeSmith | looks |
| 17:08 | <nox> | The difference in the UI seems to be from /compare/<base> vs /compare/<base>...<PR user>:<PR branch> |
| 17:08 | <MikeSmith> | yeah |
| 17:09 | <nox> | MikeSmith: I don't know if that still exists, |
| 17:09 | <nox> | MikeSmith: but through the GH API you used to be able to upgrade your issues into PR too. |
| 17:09 | <MikeSmith> | oh |
| 17:09 | <annevk> | Hixie: thanks for the feedback on <ruby> |
| 17:09 | <MikeSmith> | nox: that's a nice feature |
| 17:09 | <nox> | http://stackoverflow.com/questions/4528869/how-do-you-attach-a-new-pull-request-to-an-existing-issue-on-github |
| 17:09 | <annevk> | Maybe I should figure out if I can have a chat with Richard, I think he's in my timezone roughly |
| 17:10 | <nox> | annevk: What's the feedback btw? Missed some backlog I guess. |
| 17:10 | <annevk> | nox: it was on GitHub |
| 17:10 | <annevk> | nox: to just make Ruby conforming |
| 17:10 | <nox> | annevk: So with the two missing tags? |
| 17:11 | <annevk> | nox: yeah, I wrote a patch for the parser, but made the elements non-conforming |
| 17:12 | <annevk> | nox: making the elements conforming is probably gonna be some work |
| 17:12 | <nox> | annevk: Where is that? Sorry can't find the issue/PR. |
| 17:19 | <annevk> | nox: there's only five open PRs :-) https://github.com/whatwg/html/pull/101 |
| 17:20 | <nox> | annevk: Ok, I didn't expect HTML to get 4 PRs on the same day, so I looked only at the first, sorry. :P |
| 17:22 | <nox> | What's HTML51? :( |
| 17:23 | <jgraham> | It's the one that's 46 better |
| 17:23 | <nox> | lol |
| 17:23 | <annevk> | nox: http://www.w3.org/TR/html51/ (sometimes returns an error) |
| 17:24 | <nox> | Yeah saw it, but how does it fit in the grand scheme of things? |
| 17:24 | <annevk> | This might be the wrong place to ask that question |
| 17:24 | <annevk> | It's the W3C's semi-active fork of HTML, with some changes |
| 17:25 | <nox> | annevk: Ok. |
| 17:25 | <annevk> | As Hixie mentioned earlier we're not really happy that they continue to fork, but we don't want to prevent them doing it legally, since that would hurt other efforts |
| 17:26 | <nox> | Who is "they"? |
| 17:27 | <annevk> | The W3C |
| 17:44 | <MikeSmith> | http://stackoverflow.com/questions/32403763/combined-vim-modeline-emacs-local-variables-line-on-a-single-line |
| 17:44 | <MikeSmith> | by me |
| 17:44 | <MikeSmith> | I wish I could put a phat bounty on my own SO question and then pay myself all the points back |
| 17:45 | <MikeSmith> | nox: thanks for the SO link |
| 17:45 | <annevk> | MikeSmith: heh, do we need the closing --> |
| 17:45 | <annevk> | MikeSmith: because the comment actually continue I see |
| 17:46 | <MikeSmith> | we don't need the closing --> on that line as far as vim or emacs is concerned |
| 17:46 | <annevk> | MikeSmith: okay, do you want to make the change too? |
| 17:46 | <annevk> | :-) |
| 17:46 | <MikeSmith> | sure |
| 17:47 | <MikeSmith> | but I don't want to comment on that PR for fear of upsetting Domenic in his meeting while he's playing games on his mobile and the GH notifications interrupt his mobile gaming |
| 17:48 | <MikeSmith> | (but I will change it later, quietly) |
| 17:48 | <MikeSmith> | (after merging) |
| 17:49 | <MikeSmith> | (or before merging, if you want me to merge it) |
| 17:49 | <MikeSmith> | (which I can if you want) |
| 17:49 | <annevk> | MikeSmith: you could just do "Fix #105: Emacs config" and it'll close automatically |
| 17:49 | <MikeSmith> | sure |
| 17:50 | <MikeSmith> | but I mean I can pull it locally and make the additional fix in my branch with an --amend before I push it |
| 17:50 | <annevk> | Personally I think it's fine to bikeshed small changesd |
| 17:50 | <annevk> | Helps folks prepare for larger changes |
| 17:51 | <annevk> | MikeSmith: I'd prefer one commit, don't really care how you go about that though |
| 17:51 | <MikeSmith> | ok |
| 17:52 | <MikeSmith> | and yeah I don't mind a little small-change bikeshedding now and then either, but I want to be considerate of other peoples' workflow and avoid pain points/annoyances (however minor) |
| 17:53 | <MikeSmith> | also, about forking and for the benefit of people here, I should say: |
| 17:54 | <MikeSmith> | I am not happy about the W3C forks of WHATWG specs |
| 17:54 | <MikeSmith> | (where "not happy" would be a gross understatement) |
| 17:55 | <MikeSmith> | and what's more I plan to do a lot more to stop them from happening than I have in the past |
| 17:55 | annevk | unsubscribes from www-tag |
| 17:56 | <MikeSmith> | my strategy in the past was just to get mad and yell at people, but that obviously hasn't been effective so far |
| 17:56 | <MikeSmith> | so my new plan is to try to remain calm and be smarter about it |
| 17:56 | <annevk> | heh |
| 17:58 | <MikeSmith> | but all that said, I think there are some quality changes that got made in the W3C fork of the HTML spec |
| 17:58 | <MikeSmith> | principally by Steve Faulkner |
| 17:59 | <MikeSmith> | and we should review those and see if/how many we can port |
| 17:59 | <hsivonen> | annevk: I'm not opposed to speccing rtc if Blink and WebKit already special-case it in their parser(s) |
| 18:00 | <hsivonen> | annevk: I think I won't have time to actually review the PR tonight |
| 18:00 | <annevk> | hsivonen: Gecko doesn't? I thought we did too |
| 18:00 | <annevk> | hsivonen: there's no great rush, though the parser part of that PR is complete afaict |
| 18:07 | <hsivonen> | annevk: I don't recall what Gecko does |
| 18:26 | <hsivonen> | hmm. we have a python port of the "universal" chardet in m-c |
| 18:26 | <hsivonen> | TIL: "big5han" is a collation supported by the JS i18n API |
| 18:47 | <MikeSmith> | I wish github had a way that a repo could allow people to create and push to PR branches in that repo but not to master (or to whatever the default branch for the repo is) |
| 18:48 | <MikeSmith> | but I guess it's git that prevents that (not github) |
| 18:52 | <hsivonen> | the old HTML parser wasn't the only piece of Netscape-era code that's hard to follow and that is surprising in that it works/worked |
| 18:52 | <hsivonen> | annevk: did you take a look at the encoding converter code while writing the spec? |
| 19:09 | <nox> | MikeSmith: Mmmh, |
| 19:09 | <nox> | MikeSmith: the latest changes are going towards that. |
| 19:09 | <Philip`> | MikeSmith: That's not a fundamental limitation of git - e.g. you can use gitolite to add branch-based access control |
| 19:09 | <nox> | MikeSmith: https://github.com/blog/2051-protected-branches-and-required-status-checks |
| 19:09 | <Philip`> | (or Gerrit) |
| 19:10 | <nox> | "Can't be force pushed" + "Can't have changes merged into them until required status checks pass" are weird though. |
| 19:10 | <MikeSmith> | nox: thanks |
| 19:10 | <MikeSmith> | Philip`: ah, OK |
| 19:10 | <MikeSmith> | (hi Philip` btw) |
| 19:11 | <nox> | You can push, but you can't merge things through their UI, from my understanding. |
| 19:11 | <Philip`> | (Hello) |
| 19:12 | <MikeSmith> | ah https://github.com/blog/2051-protected-branches-and-required-status-checks looks great |
| 19:12 | <MikeSmith> | timely |
| 19:23 | <nox> | gsnedders: What are the serializer tests? Do they actually test "serialize document fragments"? |
| 19:31 | <annevk> | hsivonen: I'm not sure which encoding converter you're referring to |
| 19:32 | <annevk> | hsivonen: big5 was mostly based on research by philipj |
| 19:33 | <annevk> | MikeSmith: yes, that would be great, branches but not master |
| 19:36 | <annevk> | "Are you arguing that MD5 is secure because you don't understand how it's not secure?" |
| 19:36 | <annevk> | <3 sleevi |
| 20:42 | <TabAtkins> | annevk: So, "trailling space" on that <a> is just a result of me omitting </td>; I omit all the end-tags I can get away with. |
| 20:42 | <TabAtkins> | Where are you seeing it as a problem? |
| 20:44 | <TabAtkins> | And when I generate the spec, I'm getting CustomEvent/etc linking locally like they should. |
| 20:44 | <TabAtkins> | Oh wait, let me update the data files. |
| 20:47 | <TabAtkins> | wtf, that is broken. |
| 20:47 | <TabAtkins> | wtf is this crap |
| 20:48 | <TabAtkins> | What the shit, this is something bizarre happening with anchor resolution. (Nothing to do with any recent changes.) |
| 21:02 | <TabAtkins> | annevk: Ah, found it. Ugh, UI Events has a <dfn> *pointing to DOM* (well, to DOM 4) that Shepherd now detects, and so DOM says "whoops, this interface is already defined, let's just link to it". |
| 21:04 | <TabAtkins> | Okay, so first step is for me to add the error-check from a while ago, forcing you to either add "partial" (denoting it should link) or one of the things indicating that this is forced. |
| 21:04 | <TabAtkins> | Second, I need to get UI Events editted to no-export that entire section. |
| 21:14 | <zcorpan> | maybe we should no-export the Dependencies section in html also |
| 21:29 | <TabAtkins> | Yes plz |