| 00:06 | <MikeSmith> | it's actually great just to hear that you have wptrunner working at all already with Edge |
| 08:44 | <annevk> | Seems like a bit of a bug that HTML's syntax section doesn't describe <template> as as special kind of element |
| 08:48 | <gsnedders> | annevk: which subsection? the writing HTML? or…? |
| 08:48 | <gsnedders> | annevk: because it's in the list of special elements |
| 08:48 | <annevk> | gsnedders: yeah, writing talks about five different kinds of elements |
| 08:49 | <annevk> | gsnedders: <template> ends up classified as Normal |
| 08:50 | <annevk> | But maybe syntax-wise it is indeed normal, just seems a bit odd |
| 09:38 | <nox> | annevk: I think I saw somewhere template qualified as special. |
| 09:39 | <nox> | annevk: Weird that you would mention this, I just started implementing it in html5ever. :) |
| 09:39 | <annevk> | nox: for the parser it's special |
| 09:39 | <annevk> | nox: for syntax it's not |
| 09:39 | <annevk> | which was the weird part for me :-) |
| 09:39 | <nox> | Where is the syntax part? |
| 09:40 | <nox> | That's not it? https://html.spec.whatwg.org/multipage/syntax.html#the-stack-of-open-elements:stack-of-open-elements-4 |
| 09:42 | <annevk> | https://html.spec.whatwg.org/multipage/syntax.html#elements-2 |
| 09:45 | <nox> | annevk: I see. I guess they aren't special from that POV, right? |
| 09:55 | <JakeA> | annevk: did DOM promises use microtasks? |
| 09:55 | <annevk> | JakeA: nope |
| 09:55 | <annevk> | nox: I guess not |
| 09:56 | <JakeA> | annevk: tasks instead? |
| 09:56 | <annevk> | JakeA: yeah, but nobody ever implemented from that specification |
| 09:56 | <annevk> | JakeA: the problem is ES15 |
| 09:57 | <JakeA> | cool, just getting an impression of the history. Microsoft have asked that I make it clear in my blogpost that they're not "wrong", because it isn't specced that promises should be microtasks |
| 09:57 | <nox> | ES15? |
| 09:57 | <nox> | Did I miss 9 revisions of it? |
| 09:57 | <annevk> | nox: "proper" name for ES6 |
| 09:58 | <annevk> | JakeA: well they have a point in that the specifications are unclear, but they also never asked so they're wrong as far as being engaged goes |
| 09:58 | <nox> | annevk: Your scare quotes are scary. ;) |
| 09:59 | <annevk> | nox: heh, I just meant to indicate I think renaming ECMAScript 6 to ECMAScript 2015 was rather silly |
| 10:00 | <nox> | annevk: So I missed 2006 revisions?! |
| 10:00 | <nox> | :P |
| 10:01 | <annevk> | 2009* |
| 10:01 | annevk | hides |
| 10:42 | <JakeA> | annevk: on task queues… having different queues is mentioned in the spec, but when a task is queued it doesn't really say what queue it goes into. Is this a UA free-for-all? |
| 10:43 | <annevk> | JakeA: often specifications have a default task queue |
| 10:43 | <annevk> | JakeA: so it might be mentioned someplace else |
| 10:43 | <annevk> | JakeA: perhaps we should change that convention though, since it's rather vague |
| 10:44 | <annevk> | I think it might be better if we always had "Queue a task on /task queue/ to do X" |
| 10:44 | <JakeA> | Ahh I see, IDB specifies its own task source etc |
| 10:44 | <JakeA> | Agreed |
| 10:45 | <JakeA> | Or at least, I'd have found that easier to follow |
| 10:48 | <annevk> | Yeah, also, a lot of specification authors forget about task sources... |
| 12:34 | <annevk> | JakeA: btw, as for processes, it's basically a process per https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-similar-origin-browsing-contexts |
| 12:35 | <annevk> | JakeA: different tabs can be different processes, even with localStorage, but you'll get race conditions in implementations that don't do storage mutex (Chrome, and every other implementation that will get processes, since I don't think anyone wants to implement that mutex thing) |
| 12:36 | <JakeA> | ahh gotcha, cheers! |
| 12:48 | <annevk> | Hmm, URLUtils is even more messed up than I thought :-( |
| 12:50 | <nox> | annevk: Hah. |
| 12:50 | <nox> | annevk: What's the problem this time? |
| 12:50 | <annevk> | I think the parser overrides effectively have to go... |
| 12:51 | <annevk> | Since modifying the underlying URL is not how this works at all... |
| 12:52 | <annevk> | The URL Standard has had that design since 2012 and nobody noticed... |
| 13:28 | wanderview | finally figured out how to make a w3c account. |
| 14:59 | <annevk> | I can probably get away by making some changes to the URL parser and keeping the modification of the underlying URL |
| 15:24 | <Ms2ger> | Anyone know a dictionary with a non-nullable interface member? |
| 15:26 | <annevk> | Ms2ger: most of the dictionaries I design these days don't have one |
| 15:27 | <annevk> | Ms2ger: https://fetch.spec.whatwg.org/#requestinit |
| 15:31 | <TabAtkins> | annevk: Shitting newlines and indents all over my *code* would be terrible. I'd have to take tons of easy, simple appendChild() calls and sprinkle "\n"s around, and let's not even talk about indentation. It's absolutely not a simple thing to do, and it would massively reduce code readability in those parts. |
| 15:32 | <annevk> | But instead you're doing it for everyone else their code |
| 15:33 | <TabAtkins> | I agree that the current HTML output isn't ideal; like I said, I have an issue to fix it up. But that's an output file. ^_^ |
| 15:33 | <annevk> | The output file is what gets rendered, so it's fairly important to review |
| 15:33 | <TabAtkins> | I virtually never look at the actual raw HTML. When I review, I do it on the rendered output. |
| 15:34 | <annevk> | I guess that's where we differ |
| 15:34 | <TabAtkins> | Sure. And like I said, I've no problem with fixing it. |
| 15:44 | <wanderview> | annevk: the username and password components of a URL are different from the Request.credentials attribute, right? |
| 15:46 | <annevk> | wanderview: yes |
| 15:46 | <annevk> | wanderview: note that username/password are forbidden in fetch() |
| 15:46 | <annevk> | wanderview: at least when you pass in a URL |
| 15:46 | <wanderview> | annevk: oh? I can't create a Request with them? |
| 15:47 | <annevk> | wanderview: step 13, substep 3 |
| 15:49 | wanderview | files a bug |
| 15:50 | <SimonSapin> | What should html5lib do with <template>, ideally? Provide separate subtrees? |
| 15:51 | <annevk> | SimonSapin: yes |
| 15:53 | <wanderview> | annevk: so to test that we block username/password during interception with redirection and CORS mode... I need to use XHR or a navigation or something? |
| 15:53 | <wanderview> | I guess not a navigation |
| 15:53 | <wanderview> | since thats manual |
| 15:57 | <SimonSapin> | annevk: Thanks. A contributor is implementing it for html5ever :) |
| 15:57 | <annevk> | wanderview: no, because it's about the contents of the Location header |
| 15:57 | <annevk> | wanderview: which are not constrained by the Request constructor |
| 15:57 | <SimonSapin> | oh hi nox |
| 15:57 | <annevk> | wanderview: I should update that line though to use "include credentials" |
| 15:58 | <wanderview> | annevk: oh, I see! |
| 15:58 | <nox> | SimonSapin: Hello there. |
| 15:58 | nox | is said contributor. |
| 15:58 | <wanderview> | annevk: the credentials in the location URL are ok for a manual redirect? they will show in the opaqueredirect URL? |
| 15:59 | <wanderview> | no... will still be opaqueredirect's Location header |
| 15:59 | <wanderview> | which is filtered |
| 15:59 | <wanderview> | but the navigation will see it |
| 15:59 | <wanderview> | right? |
| 16:00 | <annevk> | wanderview: the navigate algorithm will see it |
| 16:00 | <annevk> | wanderview: I suppose it might allow them, too |
| 16:00 | <Domenic> | annevk: regarding https://github.com/whatwg/url/issues/62#issuecomment-132202394 I don't have any concrete suggestions, but are you sure that you're not just irrationally attached to the "internal URL" concept, even though it might not work that well? |
| 16:01 | <Domenic> | E.g., have you checked what browsers do? It sounds like they are significantly more lazy, with less internal fields |
| 16:01 | <wanderview> | thanks... this stuff is confusing |
| 16:01 | <annevk> | Domenic: I think it makes sense to keep it for URL/Location/WorkerLocation |
| 16:01 | <annevk> | Domenic: as per the next comment |
| 16:02 | <Domenic> | annevk: oh OK, I think I see. Processing... |
| 16:02 | <annevk> | Domenic: and I think we might need to keep it for <a> if we really wanted blob URLs to work nicely and somewhat deterministically |
| 16:03 | <Domenic> | annevk: why is it important for Location? Location seems very similar to <a> to me. |
| 16:03 | <annevk> | Domenic: Location is very different from <a> |
| 16:03 | <Domenic> | Hmm in jsdom we implement them the same (and I am pretty sure we follow the spec) |
| 16:03 | <Domenic> | Let me dig up the code and explain that a bit more |
| 16:03 | <annevk> | Domenic: the spec is wrong, which is why it needs a new design |
| 16:04 | <Domenic> | well, we follow browsers, is what i meant |
| 16:04 | <annevk> | Domenic: so when you set .pathname on Location you don't change the pathname of Location? |
| 16:04 | <Domenic> | oh, nope, that we don't do :-/ |
| 16:04 | <annevk> | Domenic: and getting pathname keeps returning the old value? |
| 16:04 | <annevk> | sounds like you could have used some test cases ;-) |
| 16:04 | <Domenic> | ok, i guess i'll try to re-read your comments again... |
| 16:05 | <Domenic> | well, we mostly don't support navigation, so it's all a little bonkers anyway :P |
| 16:05 | <Domenic> | re-reading the comment... the setters only do side-effects, and do not do any actual setting? |
| 16:06 | <Domenic> | that's almost certainly not true for the hash setter... /me tests |
| 16:06 | <annevk> | yeah hash might be a special case, interesting point |
| 16:07 | <Domenic> | yeah it is |
| 16:07 | <Domenic> | hmm how does .contentWindow.location behave, I wonder |
| 16:08 | <annevk> | I think bholley is writing a spec for that when it's cross-origin |
| 16:08 | <annevk> | Stuff gets rather involved :-/ |
| 16:09 | <Domenic> | jeez |
| 16:09 | <Domenic> | it errors in firefox, works in chrome (for hash) |
| 16:09 | <Domenic> | time to test somtehing more interesting than hash |
| 16:11 | <Domenic> | Chrome appears to censor iframe locations (even same-origin ones)?? |
| 16:11 | <Domenic> | https://jsbin.com/kewuv/1/edit?html,console,output |
| 16:14 | <annevk> | Domenic: because the URL you use redirects |
| 16:15 | <annevk> | Still, the reason .hash does change is because navigate in that case is synchronous |
| 16:15 | <annevk> | Not because it has anything to do with the Location object, which just observes the document's url |
| 16:16 | <wanderview> | Domenic: does internet explorer 10 really have the new streams API? I think someone is confused (usually me) https://dev.modern.ie/platform/status/streamsapi/ |
| 16:16 | <annevk> | wanderview: it points to http://www.w3.org/TR/streams-api/ which is not at all what streams ended up being |
| 16:17 | <wanderview> | annevk: it also says chrome is implementing it |
| 16:17 | <wanderview> | seems a bit confusing to people looking at it |
| 16:17 | <annevk> | wanderview: I suspect whoever wrote that is confused |
| 16:18 | <Domenic> | annevk: but the Location object retains identity even during navigation, when changing hash |
| 16:18 | <Domenic> | wanderview: yeah I tried ot correct them about this, let me find the bug... |
| 16:18 | <wanderview> | I guess I could write a pull request against their status page... but I'm lazy |
| 16:18 | <annevk> | Domenic: only because navigate doesn't create a new document when you change the hash |
| 16:18 | <Domenic> | sure |
| 16:19 | <Domenic> | https://github.com/MicrosoftEdge/Status/issues/108 |
| 16:20 | <annevk> | Note that the document URL can also change through pushState() |
| 16:20 | <annevk> | which is reflected by Location |
| 16:20 | <wanderview> | ah, thnaks |
| 16:20 | <annevk> | it's just that any change to Location triggers navigate instead |
| 16:20 | <Domenic> | right |
| 16:21 | <Domenic> | so Location having no internal URL, but instead using the document's URL, makes more sense to me |
| 16:34 | <Domenic> | wanderview: wouldn't hurt for you to ping them on https://github.com/MicrosoftEdge/Status/issues/108 :) |
| 16:36 | <Ms2ger> | "apply the URL parser algorithm to the absolute URL of the new resource" |
| 16:36 | <Ms2ger> | Huh |
| 16:37 | <annevk> | TabAtkins: if you could fix the output of Bikeshed that'd be great |
| 16:37 | <Domenic> | I like how status.modern.ie just randomly chooses W3C statuses to apply to WHATWG specs |
| 16:37 | <annevk> | TabAtkins: that would also make it significantly easier to rewrite existing specifications and compare the output |
| 16:37 | <Domenic> | Tempted to poke them to add an actual living standard status but that would probably be counterproductive |
| 16:38 | <annevk> | Domenic: they have to pretend we don't exist presumably |
| 16:38 | <Domenic> | annevk: I always have to use htmldiff to compare bikeshed spec outputs |
| 16:38 | <Domenic> | annevk: nah check this out: https://dev.modern.ie/platform/status/fetchapi/ |
| 16:38 | <Domenic> | annevk: this one is my favorite: https://dev.modern.ie/platform/status/fullscreenapi/ |
| 16:39 | <Domenic> | annevk: but yeah along hte lines of picking random statuses, https://dev.modern.ie/platform/status/urlapi/ |
| 16:40 | <annevk> | heh |
| 16:40 | <annevk> | I'm surprised that last one doesn't point to http://www.w3.org/TR/url/ |
| 16:41 | <annevk> | I believe it did earlier |
| 16:41 | <annevk> | That they point to whatwg.org is actually news to me |
| 16:42 | <Domenic> | oooh another one https://dev.modern.ie/platform/status/mutationobservers/ |
| 16:42 | <Ms2ger> | "Established standard"? What does that even mean? |
| 16:43 | <Domenic> | hehehe |
| 16:46 | <Domenic> | annevk: MikeSmith: can we get /TR/url to redirect to https://url.spec.whatwg.org/ yet? The out-of-dateness is strong. |
| 17:12 | <nox> | Ms2ger: You reviewing my stuff? I feel your pain. |
| 17:31 | <annevk> | Domenic: I doubt the W3C would be interested in that |
| 17:31 | <annevk> | Domenic: besides, they put out this new charter of some mega group that's supposedly going to work on it... |
| 17:32 | <annevk> | Domenic: http://www.w3.org/2015/07/web-platform-wg.html "The Group MAY provide a specification defining the syntax, process and error handling for resolving URL, along with its API." |
| 17:32 | <annevk> | Grammar is not a thing they care about it seems... |
| 17:33 | <annevk> | Also, why does the charter uppercase MAY while not referencing RFC2119? |
| 17:33 | <annevk> | Meh |
| 17:33 | <Domenic> | I mean, that group is supposedly going to work on a lot of things |
| 17:34 | <Domenic> | Doesn't mean they have an editor for them |
| 17:34 | <annevk> | They don't |
| 17:35 | <annevk> | There's only a couple of folks interested in editing in the first place. The number of folks interested in maintaining infrastructure is a fraction of that. So... |
| 17:43 | <jgraham> | I think "interested" is not always the limiting factor |
| 17:43 | <jgraham> | "competent, and able to make a living" |
| 17:44 | <annevk> | Fair, but if competent, we should be able to find a sponsor... |
| 17:46 | <jgraham> | Well it's ahrd to prove you're competent if you don't spend any time doing it |
| 17:46 | <jgraham> | There are exceptions ofc |
| 17:48 | <annevk> | Yeah, this is a problem for open source software too |
| 18:04 | <Domenic> | I am annoyed at trying to get Google to sponsor this kind of work ... they don't want to sponsor working from home or remote work, which has lost a couple candidates already. |
| 18:23 | <annevk> | wow |
| 18:33 | <Ms2ger> | Boo |
| 18:43 | <Ms2ger> | TabAtkins, re: your tweet: "zit nog altijd vast" means "is still in jail" |
| 19:48 | <wanderview> | JakeA: do we no longer require a scope to be at or below the location of a service worker? I can't find it in the spec any more |
| 19:48 | <wanderview> | maybe I'm blind |
| 19:50 | <wanderview> | ah, its in the update algorithm... never mind |
| 19:54 | <wanderview> | JakeA: another question... can I have SWs registered at both scope /a/b and scope /a/b/c? |
| 19:57 | <Mek> | wanderview: given that the "Match Service Worker Registration" explicitly tries to find the longest matching scope, I'm pretty sure the answer is yes |
| 20:01 | <wanderview> | Mek: I'm wondering if that is intended to match /some/scopeislong against /some/scope |
| 20:01 | <wanderview> | where there is no path separator... matching within path elements |
| 20:02 | <annevk> | TabAtkins: what is Shepherd? |
| 20:03 | <Mek> | I think it is indeded to just find the longest scope that matches the clientURLString, although the text does indeed seem a bit oddly phrased... |
| 20:03 | <Mek> | *intended |
| 20:04 | <wanderview> | I think its very surprising that it searches within the final token in the patch |
| 20:04 | <wanderview> | means I can't have separate service workers for peers in my directory tree structure if they have similar names |
| 20:04 | <annevk> | wanderview: you can have a service worker for a file, so yes, they are different |
| 20:05 | <wanderview> | annevk: ok... I'm writing a spec bug |
| 20:05 | <wanderview> | (I think you just agreed with me) |
| 20:05 | <annevk> | wanderview: no I didn't? |
| 20:05 | <annevk> | wanderview: /x/ and /x are different |
| 20:06 | <wanderview> | annevk: the wording for this matching does not distinguish for trailing slash at all |
| 20:06 | <wanderview> | annevk: and I believe those would probably get normalized to the same URL string by parsing the URL? |
| 20:06 | <Mek> | well, the wording for the matching just compares string serializations of URLs |
| 20:08 | <Mek> | except that the "the longest key [...] starting with the value of clientURLString" seems to imply the key(scope) should start with the client URL instead of the other way around... |
| 20:08 | <wanderview> | I think the spec language is crazy... I'm writing an issue |
| 20:08 | <annevk> | wanderview: no they wouldn't |
| 20:09 | <annevk> | wanderview: the spec should probably talk about this in terms of the URL Standard |
| 20:09 | <wanderview> | annevk: ok... but thats still not the case I was talking about... I'm talking about /some/scope and /some/scopeislong |
| 20:09 | <annevk> | wanderview: sure, those are different |
| 20:10 | <TabAtkins> | annevk: Shepherd is the separate tool that plinss runs that parses specs periodically and extracts all their anchors for me. |
| 20:10 | <wanderview> | https://github.com/slightlyoff/ServiceWorker/issues/734 |
| 20:10 | <annevk> | TabAtkins: so based on that list of specs, that's only done for a set of specs? |
| 20:10 | <annevk> | TabAtkins: and that's what causing the mismatch in references for selectors4 vs selectors-4, dom vs dom-ls, etc. |
| 20:10 | <TabAtkins> | Yeah, but it's not based on that list. There's another list managed through the Shepherd UI. |
| 20:11 | <annevk> | hmm |
| 20:11 | <annevk> | guess I need to study that |
| 20:11 | <TabAtkins> | That latter issue is actually Bikeshed. It's fixable with some more hacks by me. |
| 20:11 | <TabAtkins> | And I'm fine with those hacks. |
| 20:11 | <TabAtkins> | annevk: It's not accessible to people in general. I have admin to it, tho. |
| 20:21 | <annevk> | I see |
| 20:24 | <annevk> | TabAtkins: so the cross-specification cross-reference database is not publicly available? Are the tools? |
| 20:24 | <annevk> | TabAtkins: does Bikeshed have any other non-public dependencies? |
| 20:25 | <TabAtkins> | As far as I know, Shepherd's source isn't publicly available. |
| 20:26 | <TabAtkins> | Other than the dependencies in Bikeshed's install, it only additionally depends on SpecRef (on GH) and Shepherd (not). |
| 20:26 | <annevk> | Guess I should ask plinss if he can fix that somehow |
| 20:27 | <annevk> | TabAtkins: so SpecRef is exclusively for the references section? |
| 20:27 | <TabAtkins> | Yeah. |
| 20:28 | <TabAtkins> | SpecRef provides biblio data, Shepherd provides anchor/spec/testsuite data. |
| 20:28 | <annevk> | Both have been behaving badly :-/ |
| 20:29 | <TabAtkins> | The DOM https issue is my fault - I put it into Shepherd as http. Trying to change it now. |
| 20:40 | <JakeA> | wanderview: /x/ and /x are different scopes if you want them to be |
| 20:41 | <JakeA> | If you want to restrict to a path, end the scope in / |
| 20:41 | <wanderview> | JakeA: I'm not interested in the case... I'm interested in /some/scopeislong and /some/scope being separate |
| 20:42 | <wanderview> | but I think I'm convinced my actual problem is a gecko issue somewhere |
| 20:44 | <JakeA> | wanderview: they should be able to be separate scopes yeah |
| 21:09 | <TabAtkins> | annevk: Got dom changed to https. Give it a few minutes and then `bikeshed update` to get things fixed. |
| 22:15 | <nox> | In <https://html.spec.whatwg.org/multipage/syntax.html#markup-declaration-open-state>;, in which case can there be no adjusted current node, and in which case can that node not be an element at all? |
| 22:21 | <gsnedders> | nox: the start of parsing a document |
| 22:21 | <gsnedders> | nox: it's always an element |
| 22:21 | <gsnedders> | (or null) |
| 22:22 | <gsnedders> | nox: <!dcotype><html>foo, for example, hits that case |
| 22:22 | <gsnedders> | or <!kjdfg> etc. |
| 22:22 | <nox> | gsnedders: Thanks. |
| 22:23 | <gsnedders> | nox: I /think/ that's the only case where that's true |
| 22:23 | <gsnedders> | (I don't really have the parsed in my head at the moment) |
| 22:23 | <gsnedders> | *parser |
| 22:48 | <nox> | In <https://html.spec.whatwg.org/multipage/syntax.html#cdata-section-state>;, shouldn't the switch be the second step? |
| 22:49 | <nox> | Cf. https://html.spec.whatwg.org/multipage/syntax.html#bogus-comment-state |
| 23:37 | <gsnedders> | nox: the positioning of the switch is irrelevant, unless there's an explicit "stop executing these steps" |
| 23:38 | <gsnedders> | nox: note in most of the states you have the matching of the consumed character, then for each character the first thing done is changing the state |
| 23:38 | <nox> | Still looks inconsistent with bogus comment though. |