| 01:55 | <MikeSmith> | does anybody happen to now if IE/Edge supports new XPathEvaluator() ? |
| 01:57 | <MikeSmith> | hmm a search seems to indicate it's not in IE 11 at least, so I guess not in Edge either |
| 02:33 | <deltab> | MikeSmith: Edge but not IE: https://dev.modern.ie/platform/status/domlevel3xpath/?filter=f3f0000bf&search=xpath |
| 02:48 | <MikeSmith> | deltab: oh, thanks |
| 02:48 | MikeSmith | looks |
| 02:49 | <MikeSmith> | nice |
| 02:50 | <MikeSmith> | Domenic: https://github.com/YuzuJS/setImmediate/commit/ab4d23262270222aace074ca526b311f094ac27b is excellent |
| 02:51 | <Domenic> | Domo! |
| 03:23 | <MikeSmith> | Domenic: btw about the HTML build, I don't know if you saw when mkwst and I were chatting here yesterday or so, but there's an issue with error reporting related to using the remote wattsi service vs running wattsi locally. |
| 03:24 | <MikeSmith> | Specifically the issue is that if you use the remote service you won't see any errors that wattsi reports. |
| 03:24 | <MikeSmith> | Right? |
| 03:26 | <MikeSmith> | So yesterday when mkwst was making his changes locally and building, he wasn't seeing some wattsi errors about some markup issues in his changes. |
| 03:28 | <MikeSmith> | So anyway, I would guess we can fix it easily just be writing the stderr to a build.log file on the server side, and packaging that up with wattsi output, and then on the local side when we upack that wattsi build, we just have the build script cat that build.log file. |
| 04:05 | <MikeSmith> | botie, inform Ms2ger http://logs.glob.uno/?c=mozilla%23mdn#c32485 |
| 04:05 | <botie> | will do |
| 06:09 | <annevk> | mkwst: I need to work through HTML before being 100% sure, working on that, but it's a lot of work |
| 06:09 | <mkwst> | Ok. |
| 06:29 | <MikeSmith> | gsnedders: FYI https://github.com/lxml/lxml/pull/174#issuecomment-138795020 |
| 06:30 | <MikeSmith> | annevk: apologies for the giant mess that's been made of the ruby stuff |
| 06:30 | <MikeSmith> | I should have done more to stop that |
| 06:31 | <MikeSmith> | but fwiw I am in the process of completely exiting from any involvement in that forking business going forward |
| 06:32 | <MikeSmith> | I still hope to convince others to just stop doing it, and I'm optimistic that I have a chance of doing that, and good arguments against it (like this ruby case) |
| 06:33 | <MikeSmith> | but if I can't convince them to stop it, at least I can choose not to even indirectly faciliate it any longer |
| 06:33 | <MikeSmith> | enough is enogh |
| 06:40 | <JakeA> | wanderview: sorry, was in a bar without reception, then panic-packing for a trip. |
| 06:43 | <botie> | Ms2ger, at 2015-09-09 04:05 UTC, MikeSmith said: http://logs.glob.uno/?c=mozilla%23mdn#c32485 |
| 06:43 | <Ms2ger> | Yessir |
| 06:44 | <Ms2ger> | MikeSmith, "ask an admin", I think |
| 06:44 | <MikeSmith> | Ms2ger: happy to talk on #mdn if you have guidance on that |
| 06:44 | <MikeSmith> | oh |
| 06:44 | <MikeSmith> | thanks! |
| 06:44 | <Ms2ger> | Np |
| 06:44 | <MikeSmith> | Ms2ger: who's the EU-hours admin? teoli? |
| 06:45 | <Ms2ger> | Sounds plausiblr |
| 06:45 | <Ms2ger> | ble |
| 06:45 | <MikeSmith> | k |
| 06:47 | <MikeSmith> | Ms2ger: does mozilla IRC have any message-bot-like thingey that people use? e.g., like botie. Or do people use MsgServ? Or they just wait? |
| 06:47 | MikeSmith | is just wondering what the culture is and doesn't want to step on toes |
| 06:48 | <Ms2ger> | fennecbot has that feature |
| 06:48 | <MikeSmith> | ah cool |
| 06:48 | <Ms2ger> | It's not very widely used, though |
| 06:49 | <MikeSmith> | ok |
| 07:10 | <annevk> | MikeSmith: thanks, but it's not your fault |
| 07:34 | <annevk> | wanderview: did you see https://github.com/whatwg/fetch/pull/119? |
| 07:34 | <annevk> | wanderview: if you don't have time to look at it that's fine, but then I'll start merging the Streams stuff in and hope for more review later on |
| 08:28 | <annevk> | o_O, http://www.w3.org/TR/xhtml/ redirects to /Markup/ |
| 08:35 | Ms2ger | schedules a party on 17 December |
| 08:42 | <annevk> | Ms2ger: significance? |
| 08:43 | <Ms2ger> | 5 years since the XHTML2 WG died |
| 08:46 | <annevk> | There must be better reasons to organize parties |
| 08:57 | <MikeSmith> | annevk: where should http://www.w3.org/TR/xhtml/ go? |
| 08:57 | <MikeSmith> | I can't change what http://www.w3.org/TR/xhtml/ redirects to but I can make https://www.w3.org/MarkUp/ redirect to somewhere useful |
| 08:58 | <annevk> | MikeSmith: I dunno, was just trying to find the XHTML specification for a date citation on dev.platform |
| 08:58 | <annevk> | MikeSmith: found it by going to /TR/xhtml1/ |
| 08:58 | <MikeSmith> | annevk: ah I guess you were rightly hoping that http://www.w3.org/TR/xhtml/ would take you to the XHTML spec |
| 08:58 | <MikeSmith> | yeah |
| 08:59 | <annevk> | MikeSmith: made sense in my mind |
| 08:59 | <MikeSmith> | I will make /Markup redirect there |
| 08:59 | <annevk> | MikeSmith: wouldn't the /Markup/ folks get upset then about their history? |
| 08:59 | <MikeSmith> | dunno maybe |
| 09:00 | <MikeSmith> | I guess if they don't it will be an indication that nobody uses that page |
| 09:00 | <MikeSmith> | long-term I guess I can ask for http://www.w3.org/TR/xhtml/ to be symlinked to /TR/xhtml1 instead |
| 09:01 | <Ms2ger> | MikeSmith, why not to html.s.w.o? :) |
| 09:13 | <jgraham> | I guess MikeSmith still likes his job :) |
| 09:29 | <nox> | gsnedders: Managed to make sense out of yesterday's test case? |
| 09:33 | <schalkneethling> | annevk: so, the crossorigin attribute on the video element. That is not implemented by anyone yet right? |
| 09:33 | <annevk> | schalkneethling: I would think it is |
| 09:34 | <schalkneethling> | oh, great. I thought because of your comment yesterday and pointer to the issue on Github it might not be |
| 09:36 | <annevk> | schalkneethling: that issue is mostly about refactoring |
| 09:36 | <schalkneethling> | ah ok, got it |
| 09:39 | <MikeSmith> | annevk: fwiw https://www.w3.org/TR/xhtml/ now redirects to the right place (thanks to a haz-root friend on the systeam fast-tracking the update to the symlink) |
| 09:39 | <MikeSmith> | and People Who Like https://www.w3.org/MarkUp/ can remain happy |
| 09:41 | <Ms2ger> | MikeSmith, righter, at least :)( |
| 09:43 | <MikeSmith> | Ms2ger: Progress Not Perfection |
| 09:43 | <MikeSmith> | One Day At a Time |
| 09:43 | <Ms2ger> | A variant of w3c's slogan, "Process Not Perfection"? |
| 09:44 | <MikeSmith> | oh burn |
| 09:44 | <MikeSmith> | my wife asking me what I'm laughing about and why I have silly grin on my face |
| 09:45 | <MikeSmith> | Ms2ger: that is your best material in a long time |
| 09:45 | <MikeSmith> | you should take that one the road |
| 09:45 | <MikeSmith> | did you just spontaneously come up with that one right now? |
| 09:45 | <Ms2ger> | Eh, the good ones are few and far between :) |
| 09:45 | <MikeSmith> | indeed |
| 09:48 | <nox> | gsnedders: It's related to the step "If inner loop counter is greater than three and node is in the list of active formatting elements, then remove node from the list of active formatting elements." |
| 09:48 | <Ms2ger> | Ah, the "Magic Step" |
| 09:49 | <nox> | gsnedders: nox 1 Blink 0 |
| 09:49 | <nox> | I think I found their bug. |
| 09:49 | <Ms2ger> | Just the one? |
| 09:49 | <nox> | https://github.com/nwjs/blink/blob/be948afff52a140cdb9339c918e62fc71759904e/Source/core/html/parser/HTMLTreeBuilder.cpp#L1533-L1534 |
| 09:50 | <nox> | Ms2ger: <b><em><foo><foo><foo><aside></b></em> |
| 09:50 | <nox> | Ms2ger: Blink keeps <em> as an active formatting element. |
| 09:50 | <nox> | Note how the loop is done, |
| 09:50 | <nox> | it increments after the iteration, |
| 09:50 | <nox> | while the spec says to increment when before each of them. |
| 09:50 | <nox> | Ultimately resulting in off-by-one errors on the iteration limit check. |
| 09:52 | <nox> | It's a bit of a PITA that they don't even follow the spec exactly in their code flow. |
| 09:52 | <zcorpan> | hmm, looks like the spec doesn't have a name for this magic step |
| 09:57 | <nox> | I don't even know why they use the 3 as the iteration limit. |
| 09:57 | <nox> | It's not what the spec says. :( |
| 09:58 | <nox> | The spec says to do something magical when iteration count is greater than 3, sure, but that's not stopping the loop at 3 iterations. |
| 09:59 | <nox> | I also like how it's called "step 9", when in the spec it's "step 13". |
| 10:03 | <annevk> | nox: but that's not exactly the latest blink code, is it? |
| 10:03 | <nox> | annevk: That's what I'm checking. |
| 10:04 | <nox> | annevk: https://chromium.googlesource.com/chromium/blink/+/master/Source/core/html/parser/HTMLTreeBuilder.cpp |
| 10:04 | <nox> | Can't link to lines, but it looks the same. |
| 10:05 | <nox> | https://chromium.googlesource.com/chromium/blink/+/master/Source/core/html/parser/HTMLTreeBuilder.cpp#1531 |
| 10:17 | <nox> | https://github.com/html5lib/html5lib-tests/pull/67#issuecomment-138864769 |
| 10:20 | <schalkneethling> | annevk: if you have a moment I would love your comments on this https://github.com/schalkneethling/exploring-html/blob/master/embedded_content/video.html#L91 |
| 10:20 | <schalkneethling> | thanks |
| 10:22 | <annevk> | schalkneethling: note that you also need to use crossorigin if you want to load cross-origin video and inspect certain metadata |
| 10:23 | <schalkneethling> | ah, thought there might be a link there. Are there some docs on this? |
| 10:23 | <schalkneethling> | So does the crossorigin attribute on the video element override what is set in the CSP policy? Or is this not related? |
| 10:24 | schalkneethling | trying to think if you can control more than css an js and seem to think you can |
| 10:25 | <annevk> | schalkneethling: well, the spec is a doc |
| 10:25 | <annevk> | schalkneethling: CSP is not related |
| 10:26 | <schalkneethling> | sure, let me have a read over that again |
| 10:26 | <zcorpan> | schalkneethling: loop="true" is invalid, should be just loop (or loop="" or loop="loop") |
| 10:27 | <zcorpan> | same for muted |
| 10:27 | <schalkneethling> | oh, ok. spec suggested value is a boolean? |
| 10:27 | <schalkneethling> | http://www.w3.org/TR/html5/embedded-content-0.html#attr-media-loop |
| 10:27 | <schalkneethling> | oooooh |
| 10:27 | <zcorpan> | schalkneethling: no, it says it's a "boolean attribute" |
| 10:27 | <schalkneethling> | ok, no I read it correctly |
| 10:27 | <schalkneethling> | now |
| 10:27 | <schalkneethling> | got it, so the same goes for muted |
| 10:28 | <schalkneethling> | thanks for the feedback zcorpan |
| 10:28 | <zcorpan> | you may want to read html.spec.whatwg.org instead |
| 10:36 | <MikeSmith> | anybody know what plans, if any, WebKit has for actually implementing document.execCommand("cut"/"copy") |
| 10:36 | <MikeSmith> | I found https://bugs.webkit.org/show_bug.cgi?id=146336, which has an amusing summary but is otherwise not terrifically enlightening |
| 10:37 | <MikeSmith> | it's implemented now everywhere else, right? |
| 10:37 | <MikeSmith> | gecko, blink, edge |
| 10:58 | <mkwst> | annevk: Any ideas about the right way to address https://www.w3.org/Bugs/Public/show_bug.cgi?id=27190? |
| 11:23 | <mkwst> | annevk: also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27146. |
| 11:28 | <annevk> | mkwst: the latter seems doable |
| 11:28 | <annevk> | mkwst: the former is still unclear on what invariants we want to preserve |
| 11:28 | <annevk> | mkwst: I emailed public-webappsec about that as well at some point but to no avail |
| 11:29 | <mkwst> | annevk: yeah. fixing the latter would be nice, since it seems straightforward. |
| 11:29 | <annevk> | mkwst: I'm in the midst of trying to do Fetch refactoring and it's going rather slowly |
| 11:30 | <mkwst> | annevk: For the former, I've updated the algorithm a bit to define behavior for workers and sharedworkers that I think is sane: https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-secure step 2.*. |
| 11:30 | <mkwst> | annevk: If you're fine with the change, I'll poke at it. No reason for you to do it. |
| 11:33 | <annevk> | mkwst: yeah that seems like a good change to make |
| 11:34 | <mkwst> | Did you kill Request/Response's TLS state? |
| 11:34 | <mkwst> | I don't see them in Fetch anymore. |
| 11:35 | <mkwst> | Ah, "HTTPS state". |
| 11:36 | <annevk> | OE ruined the term TLS for me |
| 11:43 | <mkwst> | Yup. Totally understood. |
| 11:47 | <Ms2ger> | OE? |
| 11:48 | <mkwst> | opportunistic encryption |
| 11:48 | <Ms2ger> | Ah |
| 13:42 | <MikeSmith> | so I am going to experiment with using the term "the Web runtime" in conversations instead of "the Web platform" |
| 13:44 | <MikeSmith> | the reason being that I am increasingly running into people who are using "the Web platform" to mean either just "the Web" or else basically whatever they want it to mean such that there pet technology is part of it |
| 13:44 | <MikeSmith> | e.g., claims that EPUB is part of the Web platform |
| 13:45 | <MikeSmith> | or that Linked Data is part of the Web platform |
| 13:45 | <MikeSmith> | etc. |
| 13:46 | <wanderview> | annevk: I have not had a chance to look at the pull request and probably won't in the next couple weeks... feeling the crunch trying to get service workers in 43 |
| 13:47 | <annevk> | wanderview: ok, thank you |
| 14:09 | <gsnedders> | nox: takk |
| 14:11 | <annevk> | MikeSmith: see HTML5 and other terms |
| 14:11 | <annevk> | MikeSmith: uphill battle |
| 14:11 | <MikeSmith> | true |
| 14:12 | <annevk> | Man, image fetching is complicated |
| 14:12 | <MikeSmith> | but the advantage "the Web runtime" is that it's not an attractive term for others to try to shoehorn their non-Web junk into |
| 14:12 | <jgraham> | I'm not sure why not |
| 14:13 | <jgraham> | The point is that it's a popular thing, not the specific choice of words |
| 14:13 | <MikeSmith> | sure |
| 14:13 | <annevk> | If we're going to pick new terms I guess I'd go with Web Kernel |
| 14:13 | <jgraham> | I'm sure ePub or whoever would happilly talk about "HTML5 technology" whilst requiring XHTML1.1 or similar |
| 14:14 | <MikeSmith> | well that's exactly the case with epub currently |
| 14:15 | <jgraham> | "Kernel" seems like a misuse of the term. Plus it makes me think of matricies. And nuts. |
| 14:15 | <MikeSmith> | it's well-formed XHTML only |
| 14:15 | <MikeSmith> | I like it |
| 14:15 | <MikeSmith> | Kernel |
| 14:15 | <MikeSmith> | you can't pile tons of crap into the kernal |
| 14:16 | <jgraham> | Well that pretty much precludes the web from using it then :p |
| 14:16 | <MikeSmith> | it implies something bounded |
| 14:16 | <MikeSmith> | hah |
| 14:16 | <MikeSmith> | zing |
| 14:20 | <nox> | gsnedders: For what? |
| 14:20 | <gsnedders> | nox: https://github.com/html5lib/html5lib-tests/pull/67#issuecomment-138864769 |
| 14:21 | <nox> | gsnedders: Blink TC? |
| 14:21 | <gsnedders> | nox: your two tests are equivilant to the Blink test case |
| 14:23 | <nox> | gsnedders: Right. |
| 14:23 | <nox> | gsnedders: I suppose in Blink all three produce the same tree shape? |
| 14:23 | <gsnedders> | yeah |
| 14:23 | <nox> | gsnedders: We agree that Blink is broken, then? |
| 14:24 | <gsnedders> | Yes. |
| 14:24 | <nox> | gsnedders: lol @ that isindex test. |
| 14:25 | <nox> | gsnedders: Could you enforce that tests should only be appended to the existing tests, btw? |
| 14:26 | <nox> | gsnedders: To ignore the ones we don't pass in html5ever, we use their index in the file. |
| 14:28 | <gsnedders> | nox: IMO that doesn't make so much sense as putting stuff as close to possible to a similar test |
| 14:29 | <Ms2ger> | That sounds like a bad idea :) |
| 14:29 | <gsnedders> | nox: I suggest you use some simple hashing function to reference them |
| 14:29 | <nox> | Ms2ger: The enumeration? That's not me. |
| 14:30 | <gsnedders> | Anyhow, I'm going out for a bit. |
| 15:36 | <Domenic> | annevk: regarding ruby https://github.com/whatwg/html/pull/101#issuecomment-138949170 can you confirm with a live-dom-viewer test case that WebKit and Gecko currently differ? |
| 15:38 | <Domenic> | I guess I can use my iPad |
| 15:38 | <Domenic> | <rtc><rb> right? |
| 15:46 | <annevk> | Domenic: yeah, I did that the other day |
| 15:46 | <Domenic> | annevk: They apparently do not differ, for <rtc><rp> |
| 15:46 | <Domenic> | children in both |
| 15:47 | <annevk> | Domenic: do you have <ruby> in scope? |
| 15:48 | <Domenic> | Oh, no, didn't test that :P |
| 15:48 | <Domenic> | dammit |
| 15:49 | <annevk> | heh |
| 15:50 | <annevk> | I'm going to be splitting some of this Fetch stuff out, will be too much at once otherwise I'm afraid |
| 15:50 | <annevk> | and I'm getting nowhere near completion working on a big patch like this, so hopefully that's somewhat fruitful |
| 15:52 | <caitp> | you can do it |
| 15:55 | <annevk> | Domenic: http://trac.webkit.org/changeset/172834/trunk/Source/WebCore/html/parser/HTMLTreeBuilder.cpp mentioned by Koji is relevant |
| 15:55 | <annevk> | Domenic: also https://github.com/w3c/html/commit/c61397b989b28235ee2228f280aa8d475f3b9ebf |
| 15:55 | <Domenic> | annevk: so is the idea that this just hasn't made it into Safari yet? |
| 15:55 | <annevk> | Domenic: that's the relevant change between HTML5 and HTML51 |
| 15:55 | <Domenic> | Maybe someone with OS X beta can test |
| 15:55 | <annevk> | Domenic: I'm guessing that indeed stable Safari is over a year old |
| 15:55 | <caitp> | is webkit nightly not good enough for testing? |
| 15:56 | <annevk> | When I tried WebKit nightly a long time ago I couldn't really get it to work |
| 15:56 | <Domenic> | Not on PCs it's not |
| 15:56 | <annevk> | Maybe I should try again |
| 15:56 | <caitp> | i didn't know there was a pc version, since it just hijacks safari I think |
| 15:57 | <Domenic> | I was being oblique. The reason I can't test is because there is no PC version. |
| 15:57 | <Domenic> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cruby%3E%3Crtc%3E%3Crp%3E for anyone with WebKit nightly or Safari beta |
| 15:57 | <Domenic> | But regardless sounds like there's consensus |
| 15:57 | <annevk> | I'm surprised Ryosuke r+'d http://trac.webkit.org/changeset/172834/trunk/Source/WebCore/html/parser/HTMLTreeBuilder.cpp given that it didn't reference a stable draft |
| 15:57 | <annevk> | </troll> |
| 16:16 | <Domenic> | Wow, some very aggressive URL issue filing going on |
| 16:26 | <Domenic> | Ah somehow I knew this would go in the tone policing direction the moment we called her out on harassment |
| 16:31 | <annevk> | Domenic: what do you call something that doesn't depend on global state? |
| 16:31 | tantek | perks up at tone policing and harrassment. |
| 16:31 | <Domenic> | ahhh there is a term for this |
| 16:31 | <tantek> | Domenic: URL? |
| 16:31 | <annevk> | Pure |
| 16:31 | <Domenic> | http://c2.com/cgi/wiki?GlobalVariablesAreBad |
| 16:31 | <tantek> | annevk: stateless ? |
| 16:32 | <Domenic> | stateless is the one you want yeah |
| 16:32 | <nox> | Domenic: Link? |
| 16:32 | <Domenic> | pure is pretty good too |
| 16:32 | <tantek> | pure sounds too fluffy |
| 16:32 | <annevk> | well, https://en.wikipedia.org/wiki/Pure_function |
| 16:33 | <tantek> | wow what - that seems completely made up |
| 16:33 | <tantek> | yesh "This article needs additional citations for verification. " |
| 16:34 | <tantek> | I'd have to ask Knuth about his opinion on this |
| 16:35 | <Domenic> | She's unleashed her Twitter on us by the way, in case you wonder where the randoms come from |
| 16:35 | <tantek> | Domenic: URL? |
| 16:35 | <Domenic> | https://github.com/whatwg/url/issues/71 |
| 16:35 | <tantek> | also re: pure http://mathematica.stackexchange.com/questions/64577/why-does-the-documentation-call-functions-pure/64624#64624 " In the Wikipedia article it is a term extracted by analogy from the increasingly popular term "purely functional" which refers (mainly) to deterministic programming free of side-effects." |
| 16:36 | <tantek> | Domenic: wow wtf |
| 16:36 | <Domenic> | pure function is a pretty well established term... |
| 16:36 | <annevk> | I remember reaching out to some part of the community before, e.g., I discussed this with wycats |
| 16:36 | Ms2ger | sighs at people who think sending their twitter followers into a bug trackers does anything else than make them look like idiots |
| 16:36 | <annevk> | And es-discuss, etc. |
| 16:37 | <Ms2ger> | tantek, what do you think a pure function is, then? |
| 16:37 | <tantek> | Ms2ger: see above mathematica article - is the term needed? |
| 16:37 | <tantek> | also, maybe I should try sending Twitter followers into a CSS discussion |
| 16:39 | <tantek> | huh - that issue 71 was more interesting than I expected |
| 16:40 | <tantek> | I'm for not depending on window.location - because - hey, there's no window.location in Node.js right? URL is intended to be used there too right? |
| 16:40 | <tantek> | this doesn't seem like a matter of defaults or not |
| 16:41 | <tantek> | but rather of predictable / consistent behavior |
| 16:41 | <Domenic> | yeah wasn't sure whether to bring that up, but yeah, URL is a generic URL processing library. |
| 16:42 | <nox> | I've had sufficiently unexpected relative URL crap happening to think that this is a bad idea, global variables or not. |
| 16:42 | <caitp> | wouldn't it be doable to have a wrapper on top of the URL primitive which does the relative URL thing? |
| 16:42 | <caitp> | or like a static method or something |
| 16:42 | <annevk> | yeah |
| 16:42 | <Domenic> | Your points would be appreciated in the thread, as her Twitter horde has descended with the Lea-is-right viewpoint |
| 16:43 | <annevk> | though you could also just pass in document.baseURI or some such |
| 16:43 | <annevk> | location seems actually wrong |
| 16:43 | <Domenic> | or document.URL |
| 16:43 | <Domenic> | which one? who knows |
| 16:43 | tantek | gets the popcorn |
| 16:43 | <ato> | annevk: I have no idea whether this is valid criticism: https://twitter.com/LeaVerou/status/641641311427100676 |
| 16:43 | <tantek> | good defaults for UIs, not APIs. sheesh |
| 16:44 | <ccardona-work> | : Good morning/afternoon/evening WHATWG crew o/ |
| 16:45 | <MikeSmith> | "The W3C priority of constituencies puts theoretical purity at the very bottom" |
| 16:45 | tantek | can't tell if slightlyoff is serious or not. |
| 16:45 | <annevk> | tantek: I think he is |
| 16:45 | <caitp> | there was no :p in his comment |
| 16:46 | <slightlyoff> | actually serious |
| 16:46 | <annevk> | Given how strong the JavaScript default library likes to avoid global state I'm somewhat surprised by those comments |
| 16:46 | <tantek> | indeed |
| 16:46 | <annevk> | But you know, I guess folks care about different things which is alright |
| 16:46 | <annevk> | And I guess asking people to be polite is no longer done :-( |
| 16:47 | <slightlyoff> | annevk: TC39 hasn't yet accepted it works on a web language and that origins are our security model...which is maddening |
| 16:47 | <annevk> | slightlyoff: orthogonal |
| 16:47 | <slightlyoff> | but whatwg is under no pressure to replicate those mistskes |
| 16:48 | <tantek> | anyone looked at the URL objects in other languages? or do I need to go get my big table again? |
| 16:49 | <caitp> | most other languages don't have the same relationship with an origin |
| 16:51 | <wanderview> | Domenic: fwiw, she raised the issue on twitter first and I asked her to file the issue |
| 16:51 | <caitp> | the `location.relativeURL()` idea seems pretty good |
| 16:54 | <slightlyoff> | yeah, I suggested statics in the bug to separate out relative/absolute parsing behaviour. Might also split the types to prevent inadvertent mixing |
| 16:54 | <slightlyoff> | (this type feels overloaded and should unpack the "has a"s from the "is a" s) |
| 16:55 | <Domenic> | this type is about absolute URLs |
| 16:55 | <annevk> | slightlyoff: overloaded? How? |
| 16:55 | <Domenic> | it's not overloaded but people's conception of URLs is overloaded so they think it can do multiple things it cannot normally do |
| 16:56 | <annevk> | Yeah, so far from that thread it seems folks are confused about URLs |
| 16:56 | <Domenic> | One of the stronger practical arguments for me is that half the time you want document.URL and half the time you want document.baseURI |
| 16:57 | <Domenic> | afk for lunch, don't blow up the internet |
| 16:57 | <annevk> | I feel a bit sad about it escalating so quickly. I wonder how to approach something like this next time around |
| 16:58 | <TabAtkins> | annevk: Imma see if I can chat at Lea and ask her not to escalate to mob immediately. :/ |
| 17:03 | <wanderview> | annevk: I know it may not be fair, but I think trying to look past insults ("no hci training") and focus on the technical reasons for the decision helps keep things from escalating |
| 17:07 | <annevk> | wanderview: yeah, I guess I should've not gone into that |
| 17:07 | <annevk> | wanderview: it felt a bit unfair |
| 17:07 | <wanderview> | annevk: it is unfair! I only mentioned it since you asked about avoiding escalation |
| 17:08 | <wanderview> | I try to think about it like the old browser networking rule... be thick skinned about what you receive and use a light touch with what you send |
| 17:14 | <TabAtkins> | No, it was quite unfair. Lea jumps in with her qualifications when it's relevant; assuming non-qualifications on others (and then calling tone-police when it's pointed out) was somewhat shitty. :/ |
| 17:20 | <TabAtkins> | Is window.location changeable? Without navigating? |
| 17:20 | <TabAtkins> | I forget what exactly is mutatable here, because it doesn't make sense. |
| 17:20 | jgraham | refuses to listen to anyone without a CS degree |
| 17:21 | <annevk> | TabAtkins: pushState() |
| 17:21 | <TabAtkins> | Right, thanks. |
| 17:22 | <annevk> | TabAtkins: but window.location seems wrong since it doesn't take into account <base> |
| 17:22 | <gsnedders> | jgraham: Oh, good to know we should refuse to listen to you. |
| 17:22 | <annevk> | TabAtkins: which is part of why it's magical, since folks assume location, but that'd be really bad |
| 17:22 | <annevk> | I dunno |
| 17:22 | <slightlyoff> | annevk: overloaded in the sense that there are folks trying to use relative URL fragments and absolute URLs inside the same programs. URL (today) have a `pathname` component, but that's only a look-alike |
| 17:23 | <annevk> | slightlyoff: I'm not following you |
| 17:23 | <slightlyoff> | annevk: and anyone who wants to parse parts of a URL without committing to creating an absolute URL is SOL |
| 17:23 | <annevk> | slightlyoff: we don't have a relative URL primitive in the platform today |
| 17:24 | <slightlyoff> | ...hence people trying to use URL for things that aren't what you've spec'd the API to to include are finding it difficult to work with = ) |
| 17:25 | <TabAtkins> | And hence why URL, which is trying to handle absolute urls, shouldn't try to handle relative urls. |
| 17:25 | <caitp> | getting rid of the 2nd parameter entirely and just adding a static method for that seems easier to understand |
| 17:25 | <TabAtkins> | caitp: That's another option, yeah (and I think it's better ergonomics). |
| 17:27 | <annevk> | slightlyoff: are you saying folks want a relative URL primitive? |
| 17:28 | <annevk> | hmm, gotta go |
| 17:28 | <slightlyoff> | I'm asking you to look more deeply into what she's trying to accomplish in this case |
| 17:28 | <slightlyoff> | and instead of writing her off, ask why the current system seemed broken |
| 17:28 | <slightlyoff> | maybe the form of what she's asking for is wrong |
| 17:28 | <slightlyoff> | (I suggested statics because I'd find that clearer) |
| 17:29 | <slightlyoff> | but it may be that a RelativeURL or URLComponent would help clarify things |
| 17:30 | <caitp> | seems like it would make things more complicated, tbh |
| 17:31 | <caitp> | unless it was just a subclass of URL with an extra `base` attribute or something |
| 17:35 | <TabAtkins> | I mean, being able to pass around relative urls seems potentially useful. I'd have to dig for use-cases, but I can see it theoretically, with an explicit resolve() method to turn it into a URL. |
| 17:35 | <TabAtkins> | Probably want to not give it a toString(), to make it harder to misuse. |
| 17:35 | <gsnedders> | I for one would expect URL to act like any href in a document, FWIW. |
| 17:36 | <caitp> | tell that to the node-compat people =p |
| 17:36 | <botie> | will do |
| 17:36 | <TabAtkins> | gsnedders: THAT'S THE PROBLEM |
| 17:36 | <gsnedders> | If I can claim to be a web developer nowadays. |
| 17:36 | <TabAtkins> | href in a document depends on <base> |
| 17:36 | <gsnedders> | TabAtkins: STOP TONE-POLICING ME. |
| 17:36 | <TabAtkins> | href outside a document depends on window.location |
| 17:36 | <TabAtkins> | Neither is the origin. |
| 17:36 | <gsnedders> | wait, what |
| 17:37 | <gsnedders> | what's the second case? |
| 17:37 | <gsnedders> | href *outside* a document? |
| 17:37 | <gsnedders> | when is that? |
| 17:37 | <TabAtkins> | An <a> created in script and not inserted into a document. |
| 17:37 | <gsnedders> | so its ownerDocument doesn't matter here? huh. |
| 17:37 | <TabAtkins> | Yeah. |
| 17:37 | <caitp> | really? that might have an impact on all those URL polyfills then |
| 17:37 | <TabAtkins> | Or maybe ownerDocument does, but at least <base> doesn't. |
| 17:38 | <gsnedders> | ok, shit, you've just made everything more complicated. |
| 17:38 | <jgraham> | You sound surprised |
| 17:38 | <TabAtkins> | Or it does? Man, I dunno. Shit's complicated, yes. |
| 17:38 | <gsnedders> | jgraham: I only have half a degree in CS. You should be ignoring half of what I say. |
| 17:39 | <gsnedders> | jgraham: And hence either I'm surprised but you don't know what about, or you know what I'm talking about but not that I'm surprised. |
| 17:39 | <caitp> | did you tear the paper in half? |
| 17:39 | <jgraham> | gsnedders: If I'm to ignore half of what you say, which parts would you like me to start paying attention to? |
| 17:40 | <slightlyoff> | TabAtkins: if you don't give it a toString (which is pretty punitive), then the lack of equality method in URLs comes glaring through |
| 17:40 | <TabAtkins> | True fact! That's because relative urls, without a notion of where they're resolved against, have a very shaky notion of "equality"! |
| 17:40 | <gsnedders> | caitp: I have what en-us would call a joint major. |
| 17:41 | <caitp> | oh I see |
| 17:41 | <TabAtkins> | Grabbing a relative url from an <a> and from a background-image mean different things, even if they stringify the same. |
| 17:41 | <caitp> | probably a better choice in that case |
| 17:42 | <TabAtkins> | slightlyoff: Relative urls are fraught with footguns, despite (rather, due to) their usability. |
| 17:43 | <gsnedders> | TabAtkins: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3630 |
| 17:43 | <TabAtkins> | Yeah, I was just experimenting with it, too. |
| 17:43 | <TabAtkins> | Which makes it EVEN WORSE, as defaulting to location would *not* correspond to what <a> does! |
| 17:44 | <gsnedders> | tl;dr: I'd expect URL to resolve against the same thing new_a does. |
| 17:44 | <slightlyoff> | same |
| 17:44 | gsnedders | comments as such |
| 17:45 | <tantek> | usually I like convenient defaults, in this case the predictability of code makes me prefer (as an *author*) that bugs show up as errors sooner, thus no auto-magic relative URL resolution |
| 17:45 | <tantek> | I think it's bad idea to grandfather the rushed APIs of new_a etc. into URL |
| 17:45 | <gsnedders> | As an author I'd expect consistency with new_a etc. |
| 17:45 | <jgraham> | FWIW I think we have been bitten over and over again by dwim in APIs |
| 17:45 | <gsnedders> | dwim? |
| 17:46 | <jgraham> | Do What I Mean |
| 17:46 | gsnedders | only skimmed the first half of this conversation |
| 17:46 | <tantek> | gsnedders: that's a way to write code that fails silently and late |
| 17:46 | <caitp> | here's an idea: what if the primitive is totally separate from Location and stuff, and has nothing whatsoever to do with those, and instead other interfaces provide helpers for constructing URL objects resolved the way they would |
| 17:46 | <gsnedders> | tantek: perhaps. :) |
| 17:46 | <tantek> | gsnedders: when have you used new_a on what site? |
| 17:46 | <caitp> | that way everyone is happy |
| 17:47 | <tantek> | gsnedders: I much prefer writing code that I have more confidence in "leaving alone" and knowing there is less chance of it failing later silently |
| 17:47 | <TabAtkins> | caitp: location.relativeURL(), document.relativeURL() ^_^ |
| 17:47 | <caitp> | exactly |
| 17:47 | <TabAtkins> | document.styleSheets[0].relativeURL() |
| 17:47 | <TabAtkins> | Make a mixin interface for relative urls, apply it to any interface that has a notion of "base url". |
| 17:48 | <caitp> | I'd find that pretty easy to use, without accidentally making bogus URLs |
| 17:48 | <nox> | I would just add that to URLUtilsReadOnly and URLUtils. |
| 17:49 | <gsnedders> | nox: you Rust people and your immutability! :P |
| 17:49 | <nox> | What? |
| 17:50 | <gsnedders> | nox: you're just extending mutability from the type-system to object-indentity in other languages! |
| 17:50 | <nox> | gsnedders: For starters, I fancy immutability because I come from the terse land of Erlang. :P |
| 17:51 | <nox> | gsnedders: And why would putting relativeURL() in URLUtils{,ReadOnly} related to my taste for immutability? |
| 17:51 | <gsnedders> | nox: it's having the real only variant in the first place |
| 17:52 | <nox> | gsnedders: Oh! |
| 17:52 | <nox> | gsnedders: When I wrote "URLUtils{,ReadOnly}" I thought "why didn't I put them in alphabetic order previously?". |
| 17:52 | <nox> | That explains things. |
| 17:52 | <TabAtkins> | We can have a readonly variant when we can have object equality work properly, and not a moment before. |
| 17:53 | <gsnedders> | TabAtkins: does .valueOf not work for this? |
| 17:53 | <nox> | TabAtkins: URLUtilsReadOnly exists already. |
| 17:53 | <TabAtkins> | gsnedders: Nope, not if you're comparing two objects. |
| 17:53 | <TabAtkins> | Two objects => immediate pointer comparison. |
| 17:53 | <caitp> | doesn't object equality work well when you're only dealing with absolute urls? |
| 17:53 | <TabAtkins> | valueOf/toString are only invoked when comparing against primitives. |
| 17:53 | <gsnedders> | TabAtkins: bah, it's been too long |
| 17:53 | <caitp> | I mean |
| 17:54 | <caitp> | apart from not being able to overload the equality operator |
| 17:54 | <TabAtkins> | caitp: That's the entire point. ^_^ |
| 17:54 | <nox> | caitp: Yeah, I'm not sure why relative URLs matter here, aren't we discussing urlutils.relativeURL(string) -> URL? |
| 17:54 | <gsnedders> | TabAtkins: can you tell I haven't touched a JS engine in three years? |
| 17:54 | <nox> | TabAtkins: I thought relativeURL() would return a new absolute URL, resolving its argument against the context object? |
| 17:54 | <caitp> | URL.is(url1, url2) ? |
| 17:55 | <caitp> | :< |
| 17:55 | <TabAtkins> | caitp: Yeah, that exists now. |
| 17:55 | <caitp> | didn't know that |
| 17:55 | <gsnedders> | can we just throw JS out and start with a new language? #trollololol |
| 17:56 | <TabAtkins> | nox: Yes, correct. |
| 17:56 | <TabAtkins> | Maybe better to call it "resolveURL()" |
| 17:56 | <caitp> | I don't actually see that mentioned in the spec though |
| 17:56 | <nox> | TabAtkins: Oh I see, you are just saying == doesn't do the thing we want, |
| 17:56 | <TabAtkins> | To not imply that it returns a relative url object. |
| 17:56 | <TabAtkins> | Yeah. |
| 17:56 | <gsnedders> | TabAtkins: hasn't it already shipped? |
| 17:56 | <caitp> | "resolveURL" is probably more confusing to authors though |
| 17:56 | <nox> | TabAtkins: but how is this related to whether we put it on the ReadOnly interface? |
| 17:56 | <TabAtkins> | URL("http://example.com";) == URL("http://example.com";) is false |
| 17:56 | <gsnedders> | TabAtkins: there again, you do like renaming things at LC… |
| 17:56 | <nox> | I suggest sympathise(), |
| 17:56 | <TabAtkins> | nox: It's... not? |
| 17:57 | <nox> | stands for relate(). |
| 17:57 | <gsnedders> | TabAtkins: (no, we're not letting you forget this) |
| 17:57 | <TabAtkins> | gsnedders: Hasn't what already shipped? |
| 17:57 | <nox> | TabAtkins: I don't understand "We can have a readonly variant when we can have object equality work properly, and not a moment before." then. :) |
| 17:58 | <caitp> | maybe value types will be a thing some day |
| 17:58 | <TabAtkins> | nox: Oh! That's about value objects. Value objects are readonly, and get structural equality automatically, *and* can overload == if they want. |
| 17:58 | <nox> | TabAtkins: Oh, ok. |
| 17:58 | <caitp> | i thought they just had structural equality |
| 17:58 | <TabAtkins> | caitp: They're absolutely coming - we've got people working on them. |
| 17:58 | <caitp> | when did the overloading == thing come in? |
| 17:58 | <nox> | TabAtkins: I had mentioned URLUtilsReadOnly just before, so I was lost. |
| 17:58 | <TabAtkins> | nox: Yeah, sorry about that confusion. |
| 17:58 | <gsnedders> | TabAtkins: all the URL stuff? |
| 17:59 | <TabAtkins> | caitp: Operator overloading has been part of the value objects proposal since forever. It's still... hard, but it'll happen. |
| 17:59 | <TabAtkins> | They're not super useful without. |
| 17:59 | <nox> | TabAtkins: No problem. |
| 17:59 | <caitp> | Tab: I recall it was always problematic to overload equality ops in particular because of invariant violations (also certain other ops) |
| 17:59 | <TabAtkins> | If you have to do .add(), etc when you use an int64, that's shitty. |
| 17:59 | <caitp> | did that change? |
| 17:59 | <TabAtkins> | caitp: Nah, === is *not* overridable, nor is != (it's derived from ==). |
| 18:00 | <nox> | (Later on Twitter: "Goddammit, TabAtkins can't talk intelligibly from his ivory tower!!1!) |
| 18:00 | <TabAtkins> | That's enough. |
| 18:00 | <caitp> | I guess we'll have to change jshint to stop warning about === then |
| 18:00 | <TabAtkins> | Why would it warn about ===? |
| 18:00 | <caitp> | er, == vs === |
| 18:00 | <caitp> | if you need == for structural equality, I mean |
| 18:00 | <TabAtkins> | Nah, === is *always* structural equality. == defaults to that, but can be overridden. |
| 18:01 | <TabAtkins> | Best of primitives and objects, in one thing. |
| 18:01 | <caitp> | and I assume it fast-cases if objects are reference-equal |
| 18:01 | <caitp> | words are hard I need coffee |
| 18:12 | <nox> | annevk: Are PRs that just simplify algorithms while keeping current behaviour welcomed? |
| 18:13 | <smaug____> | as a spec reader and reviewer, I'd say those are most welcome |
| 18:18 | <tantek> | indeed |
| 19:16 | <TabAtkins> | caitp: Yeah, that's all under the covers. Same-object is obviously structurally equal. |
| 19:23 | <annevk> | nox: yes |
| 19:25 | <annevk> | slightlyoff: I'm not opposed to adding things, I just disagreed that new URL shouldn't be a pure function |
| 19:26 | <annevk> | slightlyoff: all about layering |
| 19:33 | <slightlyoff> | What? |
| 19:34 | <slightlyoff> | nothing about changing the (default) inputs of the function invalidates the notion of a "pure function" here |
| 19:34 | <slightlyoff> | (same inputs generating the same output w/o side effects) |
| 19:35 | <slightlyoff> | Again, happy to see other ways to untangle this (e.g. static) |
| 19:35 | <caitp> | couldn't asking for an attribute of location or document be considered a side effect |
| 19:35 | <slightlyoff> | s/static/statics/ |
| 19:36 | <slightlyoff> | only if that changes something about the state of the world; i.e. if it invokes a getter that does stuff, but we're talking about JS here, the notion of a "pure function" in JS is pretty laughable most of the time...you only get it through convention in this language |
| 19:36 | <slightlyoff> | (i.e. we don't have value types) |
| 19:38 | <slightlyoff> | for instance: https://url.spec.whatwg.org/#constructors seems to coerce to a string |
| 19:38 | <slightlyoff> | which means you're calling toString() on some object, which can have whatever side-effects you can imagine (boiling of oceans on distant moons) |
| 19:38 | <annevk> | slightlyoff: yeah, what it doesn't mean though is that URL needs to depend on DOM |
| 19:39 | <annevk> | slightlyoff: or HTML or some such |
| 19:39 | <slightlyoff> | so that's a *totally differet* objection |
| 19:39 | <slightlyoff> | (different) |
| 19:39 | <annevk> | slightlyoff: well, I might have several then |
| 19:40 | <annevk> | slightlyoff: new URL not depending on global state seems like a good thing too, for portability reasons and understanding what it actually does |
| 19:41 | <slightlyoff> | now we're getting somewhere |
| 19:42 | <slightlyoff> | you think it's easier to understand, others (seem to?) disagree. That's fine. I've asked Lea to outline her use-case in more depth |
| 19:42 | <annevk> | I don't know, you, wycats, and I discussed this a long time ago and agreed |
| 19:42 | <wycats> | which thing? |
| 19:42 | <slightlyoff> | but we can't talk about this as being some bedrocky CS principle when it's all ergonomics and choices under uncertainty |
| 19:42 | <annevk> | wycats: about URL constructors |
| 19:43 | <wycats> | slightlyoff: I don't have a ton of time, but choosing not to call toString on something is a heavy choice |
| 19:43 | <wycats> | it better be worth it |
| 19:43 | <caitp> | it's clear that on the web you probably do want to get the url resolved relative to <base>, what if you want a different one resolved relative to origin, or a different one resolved relative to file |
| 19:44 | <slightlyoff> | wycats: I'm not saying we shouldn't call toString |
| 19:44 | <tantek> | even such bedrocky CS principles are supposed to be based in practical needs - so if you can't explain it in terms of such, then perhaps it's a misapplication of the principle |
| 19:44 | <slightlyoff> | wycats: I'm arguing that you obviously should (and do) |
| 19:44 | <wycats> | is the question what the default base is? |
| 19:44 | <slightlyoff> | wycats: yes; that's the debate |
| 19:44 | <wycats> | why not just give host environments a hook to configure it and call it a day |
| 19:45 | <wycats> | node probably wants something different anyawy |
| 19:45 | <wycats> | anyway* |
| 19:45 | <caitp> | because then it will make the api behave differently in different environments, and then joe's "orthogonal JS" won't do the right thing |
| 19:45 | tantek | suspects any sentence with "just" |
| 19:45 | <caitp> | orthogonal? |
| 19:45 | <caitp> | wrong word, not enough sleep :< |
| 19:45 | <slightlyoff> | yeah, I'm up for that. I think annevk is opposed. Regardless I think we need to think about what statics URL needs for convenience as lots of people are tripped up trying to accomplish a lot of different goals by the "construct a URL, and first read up on all the details of URL" thing |
| 19:46 | <annevk> | slightlyoff: I think ergonomics are important, but simple building blocks are too |
| 19:46 | <annevk> | slightlyoff: would folks expect that invoking pushState() changes how new URL() works? |
| 19:47 | <wycats> | annevk: at minimum, we could have an option that explicitly asks for "host specified base" |
| 19:47 | <annevk> | slightlyoff: or would that be called "magic" and the platform trying to be clever again? |
| 19:47 | <wycats> | which seems useful |
| 19:47 | <annevk> | wycats: well that's the second argument |
| 19:47 | <wycats> | annevk: can you say "whatever the host thinks a good option is"? |
| 19:47 | <wycats> | annevk: I don't really understand the universal JS point |
| 19:48 | <wycats> | presumably if there's no host-configured base, and you pass a relative URL, you'd get an exception? |
| 19:48 | <annevk> | wycats: if you don't pass a base URL, yes |
| 19:48 | <slightlyoff> | annevk: its' only "clever" if we're trying to predict use as opposed to responding to existing user needs |
| 19:48 | <wycats> | annevk: so then slightlyoff is right |
| 19:48 | <wycats> | why are you giving a relative URL if you want "agnostic" behavior |
| 19:48 | <wycats> | that doesn't make any sense |
| 19:48 | <wycats> | a relative URL must be relative to something |
| 19:49 | <annevk> | wycats: you might want to actually make sure you're given an absolute URL |
| 19:49 | <annevk> | wycats: there's a ton of places in the platform that want this |
| 19:49 | <wycats> | sounds like a good utility to include, which iirc we do |
| 19:49 | <wycats> | you should not be invoking the constructor to get an exception to learn that |
| 19:49 | <wycats> | that's silly |
| 19:49 | slightlyoff | frames wycats saying I was right about something |
| 19:49 | <wycats> | lololol |
| 19:49 | <wycats> | the lack of a URL.isAbsolute(url) seems like the problem here |
| 19:50 | <annevk> | Yeah, we should probably offer that |
| 19:51 | <caitp> | do you differentiate between absolute and fully qualified |
| 19:51 | <annevk> | I'm not sure what the distinction would be |
| 19:51 | <annevk> | But absolute URL per spec is syntax |
| 19:51 | <annevk> | The outcome of the parser is a URL record https://url.spec.whatwg.org/#concept-url |
| 19:52 | <caitp> | absolute urls in <a> terms would be relative to base |
| 19:52 | <caitp> | versus fully qualified which include scheme/host/etc |
| 19:52 | <annevk> | well if they're absolute the base is irrelevant |
| 19:52 | <annevk> | I think you're confusing things |
| 19:52 | <annevk> | You might be thinking about path-absolute URLs? |
| 19:52 | <caitp> | it's not a confusion, they're different things |
| 19:53 | <annevk> | I guess what you're calling absolute the spec calls path-absolute and what you're calling fully qualified the spec either calls absolute or URL records... |
| 19:54 | <annevk> | wycats: so I guess you changed your mind too or maybe I misremembered |
| 19:54 | <wycats> | annevk: I have to go momentarily, but do you get my basic point? |
| 19:54 | <wycats> | if it would be an exception anyway, it seems ok to configure it |
| 19:55 | <wycats> | as long as there's a way to defend yourself if you really care |
| 19:55 | <annevk> | wycats: I'm not sure if we can still change this at this point, but perhaps we could make it configurable... |
| 19:55 | <wycats> | if it's an exception now, we can surely change it c/d |
| 19:55 | <wycats> | confirm/deny |
| 19:55 | <annevk> | wycats: folks might use it for the absolute URL test |
| 19:56 | <wycats> | it's so new we can get away with it |
| 19:56 | <wycats> | the fact that ppl are using that test should have been a hint to add a predicate ;) |
| 19:56 | <annevk> | wycats: I'm not sure if they are :-) |
| 19:56 | <wycats> | then we're safe to change it ;) |
| 19:56 | <wycats> | I hear FF has telemetry ;) |
| 19:58 | <nox> | What's wrong with the relativeURL() idea? |
| 19:58 | <wycats> | it makes sense to have a reflection of <a> in the URL spec |
| 19:58 | <nox> | Why? |
| 19:58 | <wycats> | O_o |
| 19:58 | <wycats> | new URL is fine, so is URL.platform() |
| 19:58 | <nox> | Should the URL href setter behave like on <a> too? |
| 19:59 | <wycats> | nox: because having to build everything up from primitives all the time is extremely annoying? |
| 19:59 | <caitp> | how many methods are you shoving into this thing |
| 19:59 | <wycats> | nox: no, you only need one |
| 19:59 | <wycats> | wut |
| 19:59 | <wycats> | do you even EWM? |
| 19:59 | <nox> | What? |
| 19:59 | <annevk> | wycats: well, I was trying, but now you want a dependency on <base> |
| 19:59 | <wycats> | https://extensiblewebmanifesto.org/ |
| 19:59 | <wycats> | annevk: I think URL.platform() is a good solution |
| 19:59 | <annevk> | wycats: which just o_O (but bigger O) me |
| 20:00 | <wycats> | the point of EWM is not to make everyone rebuild the whole platform all the time |
| 20:00 | <caitp> | mr. dalton can always publish lodash-url.js if the *.relativeURL() idea doesn't work out |
| 20:00 | <wycats> | it's to give you the primitives the platform uses in layers |
| 20:00 | <nox> | Sure, but the URL object already seem to have a different purpose than the others implementors of URLUtils. |
| 20:00 | <annevk> | wycats: this object that is returned, would it also continue to observe the base URL if you change any of its properties? As <a> does? |
| 20:01 | <annevk> | wycats: which is rather magical (imo) behavior |
| 20:01 | <nox> | For example, the other implementors never return failure in the href setter, URL does. |
| 20:01 | <annevk> | wycats: and change whenever <base> changes? As <a> does? |
| 20:01 | <wycats> | you're taking me too literally, and nitpicking |
| 20:01 | <wycats> | annevk: unsure about that one |
| 20:01 | <nox> | Nitpicking about specs sounds on point. |
| 20:01 | <annevk> | wycats: I'm just curious |
| 20:01 | <wycats> | annevk: I think maybe yes if you .platform() |
| 20:02 | <wycats> | but via a host hook |
| 20:02 | <wycats> | the spec doesn't have to know |
| 20:02 | <wycats> | but no is also ok |
| 20:02 | <annevk> | wycats: well it gets rather complicated, since for DOM/HTML we need specific <base> changed notifications |
| 20:02 | <wycats> | but having to do a bunch of busywork to detect relative URLs is annoying |
| 20:02 | <annevk> | wycats: so you need to be able to get a base, and you need to take action when it changes |
| 20:02 | <wycats> | yeah |
| 20:03 | <wycats> | it's not critical |
| 20:03 | <wycats> | I don't literally mean it's the <a> tag |
| 20:03 | <nox> | Just don't detect them, and add a method on URLUtils that resolves a string against its url and returns a new URL. |
| 20:03 | <wycats> | what I basically mean is that it's: var div = document.createElement("div"); div.innerHTML = `<a href="${url}"></a>`; div.firstChild.href |
| 20:04 | <wycats> | that isn't live updated |
| 20:04 | <wycats> | but it does respect base |
| 20:06 | <annevk> | wycats: seems fairly reasonable; could even have URL.host(relativeURL) that varies per host |
| 20:06 | <wycats> | yeah |
| 20:06 | <wycats> | that's what I meant re: platform |
| 20:06 | <wycats> | host seems fine |
| 20:06 | <annevk> | wycats: and it's up to hosts to provide that method if they want to |
| 20:06 | <annevk> | wycats: and if URL ever becomes ES-ified it would likely not have .host() |
| 20:06 | <wycats> | annevk: yeah |
| 20:07 | <wycats> | annevk: right |
| 20:07 | <wycats> | although if node wants it we might specify it as a hook with some basic requirements |
| 20:07 | <annevk> | wycats: sure |
| 20:17 | <TabAtkins> | slightlyoff: No, pulling in global state does invalidate purity. |
| 20:37 | <wycats> | what does purity have to do with anything? |
| 20:42 | <TabAtkins> | wycats: I'm just correcting Alex. Pure functions are easy to reason about, and purity *does* require no connection to mutable global state. |
| 20:42 | <wycats> | yes, can confirm |
| 20:42 | <slightlyoff> | your window location isn't mutable |
| 20:42 | <slightlyoff> | (for the purposes of a base URL) |
| 20:43 | <TabAtkins> | Yes it is! |
| 20:43 | <slightlyoff> | it might as well be an environment variable |
| 20:43 | <TabAtkins> | replaceState() |
| 20:43 | <wycats> | it basically is an environment variable :P |
| 20:43 | <slightlyoff> | so now you have a design decision: would you use the original to preserve "purity"? |
| 20:44 | <TabAtkins> | ...no, you use *neither* to preserve purity, *because it's global mutable state, and error-prone to depend on when you're not expecting it*. |
| 20:44 | <TabAtkins> | And window.location isn't even the thing that <a>.href works on. |
| 20:45 | <slightlyoff> | so we just covered why at least one of those statements is suspect |
| 20:45 | <TabAtkins> | There's no particular reason to assume that a random URL used in a script *intends* to pay attention to a <base> element on the page. |
| 20:45 | <slightlyoff> | and symmetry with <a>.href is interesting! |
| 20:46 | <TabAtkins> | The <a>.href behavior is almost certainly accidental, and I'd be completely unsurprised if it broke some pages accidentally and people had to work around it. |
| 20:46 | <TabAtkins> | (It's clearly intentional for <a>; it's accidental for the general "parse a url" behavior.) |
| 20:49 | <TabAtkins> | There's just so many contexts within the web platform that are totally reasonable to resolve a url against, that people work with every day. I don't think there's any answer that is *sufficiently likely to be correct* that it can be set as the default. |
| 20:50 | <TabAtkins> | (I'm not all for purity in all cases; it's totally fine for, like, us to invent element constructors that imply a connection to the current script's document. But that's almost certain to be right.) |
| 21:32 | <MikeSmith> | Domenic: http://stackoverflow.com/questions/25794905/why-does-set-e-true-false-true-not-exit |
| 21:33 | <MikeSmith> | "Why does set -e; true && false && true not exit?" |
| 21:33 | <MikeSmith> | I remember now running into this before |
| 21:33 | <MikeSmith> | it's by design |
| 21:34 | <MikeSmith> | set -e is supposed to be only for "uncaught" exceptions |
| 21:34 | <Domenic> | Ah... |
| 21:34 | <Domenic> | So use less &&s and more if, I guess? |
| 21:35 | <MikeSmith> | maybe |
| 21:35 | <MikeSmith> | or just switch back to || exit 1 |
| 21:35 | <MikeSmith> | which is ugly but shell scripts are fundamentally ugly anyway |
| 21:36 | <Domenic> | yeah |
| 21:36 | <Domenic> | yet somehow nothing is as good |
| 21:36 | <MikeSmith> | "worse is better" |
| 21:36 | <Domenic> | I once tried to rewrite https://github.com/whatwg/streams/blob/master/deploy.sh in Node.js. Got like 10 lines in before I realized this was not going to be fun. |
| 21:36 | MikeSmith | looks |
| 21:37 | <MikeSmith> | yeah |
| 21:37 | <MikeSmith> | I'm the same way with existing makefiles I have that I've tried to port to other task runners |
| 21:38 | <MikeSmith> | always reach the point of "just ain't gonna happen" |
| 21:38 | <MikeSmith> | I guess it's just the fact that the shell lets you do pretty much anything |
| 21:38 | <MikeSmith> | and other task runners really don't |
| 21:39 | <MikeSmith> | and makefiles are just ways to do anything you want with the shell as part of a build |
| 21:41 | <MikeSmith> | anyway I guess we should leave it alone for a bit and let some actual other users help find where the odd failures are |
| 21:41 | <MikeSmith> | this is not major stuff anyway, as far as making it easier to run and use |
| 21:41 | <MikeSmith> | the major thing I would still hope we can fix soon is the XML::Parser install requirement |
| 21:41 | <MikeSmith> | because that is just harsh |
| 21:42 | <Domenic> | yes agreed |
| 21:42 | <Domenic> | I wonder if python comes with xml parser by default |
| 21:42 | <MikeSmith> | yeah I think it does |
| 21:42 | <MikeSmith> | bindings to libxml2 |
| 21:43 | <Domenic> | is libxml2 installed by default though |
| 21:43 | <MikeSmith> | gsnedders or maybe even TabAtkins would know better |
| 21:43 | <MikeSmith> | oh |
| 21:43 | <MikeSmith> | hmm, yeah, maybe not |
| 21:44 | <MikeSmith> | I think for now we could be OK just putting the cldr.inc file on whatwg.org somewhere and just manually re-generating/updating it when the upstream Unicode stuff changes |
| 21:45 | <MikeSmith> | either that or like I mentioned we could just check it into the repo |
| 21:45 | <MikeSmith> | I was surprised to see that it's only 25K |
| 21:46 | <Domenic> | i mean we *could* set up another build server endpoint like we did with wattsi |
| 21:46 | <MikeSmith> | yeah but it might be overkill for this, to rebuild it each time for each user |
| 21:46 | tantek | tries to read scrollback |
| 21:46 | <MikeSmith> | not a good use of bandwith I think |
| 21:47 | <MikeSmith> | the back-and-forth |
| 21:47 | <Domenic> | maybe |
| 21:47 | <MikeSmith> | it is worth if for the wattsi case, clearly |
| 21:47 | <MikeSmith> | hola tantek |
| 21:47 | <MikeSmith> | we talking about the build script for the HTML spec |
| 21:48 | <tantek> | yay spec plumbing |
| 21:48 | tantek | bows to the hardwork y'all put into that. |
| 21:50 | <gsnedders> | Domenic: there's multiple xml parsers! |
| 21:50 | <MikeSmith> | yeah it's fun to write stuff to try to make things as easy as possible for other people |
| 21:51 | <gsnedders> | Domenic: https://docs.python.org/3/library/xml.html#module-xml |
| 21:52 | MikeSmith | admires Domenic's relentlesseness towards clearing away as many hurdles as possible for others |
| 21:52 | <Domenic> | :) you did most of the hard work on this one |
| 21:53 | <MikeSmith> | anyway for now I think I'll instead try to spend my free time tonight/tomorrow making a couple actual patches/contributions/PRs to the spec |
| 21:53 | <MikeSmith> | get some of the remaining low-hanging fruit picked |
| 21:54 | <Domenic> | gsnedders: well this is just a scary page full of scary things. |
| 21:54 | <Domenic> | I guess I should go down to the Apple store and run some tests on clean macs to see if any of these python xml things work out of the box |
| 21:54 | <gsnedders> | Domenic: you want either xml.etree.cElementTree or lxml (not in stdlib) |
| 21:55 | <MikeSmith> | eventually I guess we're going to run out of the low-hanging fruit and it'll be like waking up with a bad hangover, staring at the list of remaining bugzilla bugs |
| 21:55 | <gsnedders> | Domenic: unless you need a streaming parser |
| 21:55 | <Domenic> | gsnedders: xml.etree.cElementTree sounds reasonable |
| 21:55 | <MikeSmith> | gsnedders: what streaming parser is there? |
| 21:57 | <MikeSmith> | gsnedders: incidentally, do you know how I can pass namespaceHTMLElements=False to the lxml html5parser? |
| 21:57 | <gsnedders> | MikeSmith: xml.sax or xml.parsers.expat |
| 21:58 | <MikeSmith> | ah ok |
| 21:58 | <gsnedders> | MikeSmith: I suspect it should work, I don't know |
| 21:58 | <gsnedders> | MikeSmith: lxml has a streaming one too |
| 21:58 | <MikeSmith> | yeah I was thinking HTML parser and had forgotten that the subject at hand is XML parsing |
| 22:00 | <MikeSmith> | gsnedders: about namespaceHTMLElements=False, in that bug he makes it sound like it's sorta obvious how to do it. but I don't see where it's exposed |
| 22:00 | <MikeSmith> | I guess I need to read the docs more |
| 22:01 | <gsnedders> | MikeSmith: gimme a few mins |
| 22:01 | <MikeSmith> | that guy is somewhat Ms2ger/annevk-ish with regard to the brevity and enigmatic nature of some of his responses |
| 22:01 | <MikeSmith> | hai |
| 22:01 | <gsnedders> | oh, he's like that IRL too :) |
| 22:02 | <MikeSmith> | ah you met him |
| 22:02 | <MikeSmith> | would be nice to meet him some time. I guess he's in Germany somewhere? |
| 22:04 | MikeSmith | suspects that Domenic is thinking about re-writing one of Hixie's perl scripts in python, hands him a box of tissue in preparation for the tears he's going to need to spend time wiping away |
| 22:05 | <Domenic> | yepppp |
| 22:06 | <gsnedders> | MikeSmith: yeah, forget where |
| 22:06 | <gsnedders> | MikeSmith: often at EuroPython |
| 22:09 | <MikeSmith> | y'all #whatwg python mavens make me want to be a better python hacker. I actually really like writing in python more than any other language, but I do very little of it |
| 22:29 | <TabAtkins> | libxml2 is *not* installed by default. >_< |
| 22:30 | <TabAtkins> | But anyone willing to install Bikeshed has it. ^_^ |
| 22:31 | <TabAtkins> | MikeSmith: Like `doc = html5lib.parse(text, treebuilder='lxml', namespaceHTMLElements=False)` |
| 22:32 | <MikeSmith> | TabAtkins: I mean lxml interface to it |
| 22:32 | <TabAtkins> | Oh, dunno how html5lib invokes the lxml parser. |
| 22:32 | <MikeSmith> | http://lxml.de/html5parser.html |
| 22:33 | <MikeSmith> | yeah I know how (I even made a PR to patch the lxml sources) but I just don't see where it exposes it |
| 22:36 | MikeSmith | resorts to re-reading teh sources |
| 23:18 | <MikeSmith> | gsnedders: ↓ |
| 23:18 | <MikeSmith> | $ cat test.py |
| 23:18 | <MikeSmith> | from lxml.html import html5parser, tostring |
| 23:18 | <MikeSmith> | parser = html5parser.HTMLParser(namespaceHTMLElements=False) |
| 23:18 | <MikeSmith> | print tostring(html5parser.fromstring("<html>", parser)) |
| 23:18 | <MikeSmith> | $ python test.py |
| 23:18 | <MikeSmith> | <html:html xmlns:html="http://www.w3.org/1999/xhtml"><html:head></html:head><html:body></html:body></html:html>; |
| 23:39 | <gsnedders> | MikeSmith: hmm, okay, maybe not |
| 23:40 | <gsnedders> | MikeSmith: that should work, I thought? |
| 23:40 | <gsnedders> | and it looks like it should work |
| 23:40 | <gsnedders> | given **kwargs are passed through |
| 23:45 | <Krinkle> | Is there a simple and reliable way to defer code execution until after window-onload if you don't know whether that event has happened already? |
| 23:46 | <TabAtkins> | MikeSmith: I'd think that would work, yeah. Confusing. |
| 23:46 | <Krinkle> | I can't for the life of me figure it out, short of polling performance.timing.loadEventEnd |
| 23:46 | <TabAtkins> | Krinkle: In the ideal future, we'll have a .ready() promise on document that reflects the onload event. |
| 23:46 | <TabAtkins> | This is why events are not the correct abstraction for single-occurence things. |
| 23:47 | <Krinkle> | yeah |
| 23:47 | <Krinkle> | I want jQuery document.ready for window.onload |
| 23:47 | <Krinkle> | basically |
| 23:48 | <Krinkle> | I would settle for a simple way to know whether it's "safe" to add an event listener to window.onload (e.g. has it already started), and then know to either schedule or inoke callback now |
| 23:51 | <Krinkle> | I just realised today that a fair number of Navigation Timing metrics werent' being delivered from browser clients using Wikipedia because the event logging code used window.onload |
| 23:51 | <Krinkle> | which sometimes had already happened :facepalm: |