2016-06-01 [17:43:17.0000] you could always require the spambots to pick out photos of specific kinds of boats, to prove they're human [17:43:59.0000] anyone willing to actually go through that crap would probably really, really want you do fix their spec issue [17:44:00.0000] "Pick the one called Boaty McBoatFace" [06:16:43.0000] MikeSmith: are you interested in implementing https://github.com/whatwg/html/pull/1356 for v.nu? would be nice to sanity-check against the test cases [06:17:06.0000] /me looks [06:17:50.0000] I think that might a change to the parser but regardless yeah I would be willing to implement it for testing [06:19:07.0000] cool [07:20:54.0000] Hey! [07:21:32.0000] First time at IRC [08:18:23.0000] hi - what's the current status of the Custom Element APIs; can https://github.com/w3c/webcomponents/pull/405 be considered final? [08:20:07.0000] if so, have polyfill maintainers indicated that they'll update? (AFAIK there's the Polymer-based stuff at webcomponents.org as well as https://github.com/WebReflection/document-register-element) [08:22:57.0000] FND: yes; custom elements have been upstreamed into HTML (and parts into DOM). See https://html.spec.whatwg.org/multipage/scripting.html#custom-elements. I believe Polymer is working on an updated polyfill, although some things are much harder to polyfill in the new version. [08:24:07.0000] thanks Domenic - can you elaborate on the polyfill difficulties; what will this mean for users? [08:25:41.0000] FND: well, they depend on ES6 class syntax, including aspects that are impossible to transpile in general. So I believe Polymer is investigating things like an extra transpiler pass or advising authors to add an extra line to their constructor (which they won't need in native implementations) in order to work with Polymer. I am not the expert here though; [08:25:42.0000] let me see if I can summon a Polymer person. [08:27:25.0000] tbh, I'm not actually that interested in Polymer-specific aspects, as I prefer to use vanilla custom elements (is that a term?) [08:27:38.0000] (though I realize their solution might well be generally applicable) [08:27:39.0000] Yeah, but they maintain a custom elements polyfill [08:27:43.0000] gotcha [08:28:27.0000] the ES6 dependency actually sounds promising in a way, as so far Babel and the polyfills (either of them) didn't cooperate [08:28:58.0000] (Babel injects some sort of class check that fails on HTMLElement, not sure about the details right now) [08:29:17.0000] Yeah, I think the polyfill will involve overwriting window.HTMLElement [08:30:12.0000] FND: OK, so it sounds like the best place to get info about the Polymer custom elements polyfill will be https://groups.google.com/forum/#!forum/polymer-dev or https://polymer-slack.herokuapp.com [08:30:25.0000] It sounds like they're still in the planning stages for the update [08:30:39.0000] roger, thank you [08:41:57.0000] FWIW, the Babel vs. polyfill issue is because polyfilled `HTMLElement` is not a constructor, which trips up Babel's inheritance check: [08:42:02.0000] if (typeof superClass !== "function" && superClass !== null) { throw new TypeError(…) } [08:49:43.0000] also, in case anyone cares: looks like WebReflection's polyfill _might_ be updated https://github.com/WebReflection/document-register-element/issues/58 [08:58:36.0000] trackbot, start meeting [08:58:45.0000] /me grr [09:55:01.0000] Does Edge still do www..com on ctrl-enter in address bar? [12:40:38.0000] I wonder... if page A opens a new window B and B adds event listener to its opener, and then B is closed [12:41:01.0000] GC can't (or at least shouldn't) collect anything from B [12:41:15.0000] (GC or CC or whatever UA has) [13:28:58.0000] hmm, without looking at the spec or trying stuff, what would you expect the output of the following code to be: let c = new MessageChannel(); c.port1.onmessage = e => { console.log(e.data); c.port1.close(); }; c.port2.postMessage('foo'); c.port2.postMessage('bar'); [13:55:25.0000] Mek: ignoring my "this is a trick question" instincts, I'd expect 'foo' only [13:55:40.0000] wellll [13:55:43.0000] Domenic: both spec and implementation say to print both... [13:55:50.0000] it depends on whether onmessage is async [13:55:56.0000] if it's async i would expect both [13:56:28.0000] basically i expect .close() to be a "graceful close" that allows processing queued up messages [13:56:41.0000] i'm just unclear on whether .close() happens before or after 'bar' gets queued [13:57:10.0000] for BroadcastChannel the spec seems to be the same (postMessage synchronously figures out the set of non-closed destinations, and then queues tasks to all of them), but the firefox implementation doesn't behave that way, so I'm trying to figure out if I should file a firefox or a spec bug... [13:58:57.0000] Mehhh... spec bug might get a broader audience of people with expectations, and as a bonus Firefox people will probably show up there anyway? [13:59:41.0000] true... [14:29:52.0000] Hm.. is "The" supposed to fall behind the main title? https://whatwg.org/specs/ [15:29:49.0000] Krinkle: I doubt it. ^_^ Domenic annevk [15:30:11.0000] I dunno, looks intentional to me [15:30:19.0000] We can check with Hixie [15:44:13.0000] it's just a creatively-kerned "ThWeeb" [15:48:50.0000] is there a good way to find all the CSS properties that allow url? [15:52:39.0000] There's some CSS index, not sure if it's good for that purpose... [15:53:05.0000] terinjokes: https://drafts.csswg.org/indexes/#properties will get you halfway there, but yeah, not quite what you need [15:53:29.0000] astearns: Domenic: http://i.imgur.com/DVxSe8z.png [15:53:46.0000] Krinkle: yes, that looks intentional to me. Deemphasizing the pronoun [15:54:39.0000] k :) [15:54:49.0000] It most certainly does not read as "ThWeeb" however. [16:06:32.0000] it's intentional [16:06:36.0000] also, i have no design sense [16:06:37.0000] so... 2016-06-02 [17:09:50.0000] dbaron: thank you so much!! (re fixing :target to respect pushState) [17:15:08.0000] terinjokes: Yeah, we don't yet have a great index of property values. Coming in the nearish future. [18:23:45.0000] it would be great if somebody has time to post a comment correcting http://stackoverflow.com/questions/37521172/is-javascript-location-href-call-is-asynchronous/37521290#37521290 and/or post an actual right answer [18:29:09.0000] i would if I could understand the spec conventions in html [18:54:41.0000] hey caitp [18:55:07.0000] what do the spec conventions in HTML have to do with it [18:57:26.0000] not sure how else i'd produce an accurate answer for something that isn't really my domain [18:57:52.0000] spec conventions would have to do with understanding the specified algorithm enough to answer correctl [18:57:54.0000] y [04:14:01.0000] no zcorpan [04:52:46.0000] Can anyone try http://w3c-test.org/domparsing/createContextualFragment.html on Edge and tell me if 'Namespace generally shouldn't matter' and ' in a different namespace shouldn't be special' pass? [05:58:15.0000] annevk: 👍🏻 [06:57:40.0000] mathiasbynens: are you here? 😊 [07:08:49.0000] annevk: Ping? [07:09:08.0000] annevk: http://logs.glob.uno/?c=mozilla%23content&s=2+Jun+2016&e=2+Jun+2016#c378961 https://github.com/w3c/web-platform-tests/issues/3103 [07:11:22.0000] nox: that looks complicated [07:11:29.0000] Heh. [07:11:34.0000] annevk: Not urgent. [07:11:47.0000] annevk: But I think the spec contradicts the tests for this. Or the opposite. [07:11:48.0000] nox: maybe zcorpan can help? I'm at a conf, back Monday [07:11:53.0000] annevk: Have fun. [08:35:21.0000] annevk: unfortunately not — watched the livestream though [10:31:09.0000] nox: those two pass, first test and last two tests fail [10:31:26.0000] Domenic: Ok thanks. [10:34:47.0000] does Chrome have something similar to FF's about:memory? [10:35:06.0000] Domenic: Btw, https://github.com/whatwg/html/issues/1376 [10:35:36.0000] nox: yeah... too much to do... [10:36:51.0000] smaug____: maybe this? https://developer.chrome.com/devtools/docs/heap-profiling?csw=1 [10:38:55.0000] thanks [10:39:03.0000] /me kicks chrome and its data: handling [10:40:46.0000] and now it crashed [10:41:05.0000] MikeSmith: I'm pretty sure that answer is correct - the navigation is async, so the page will continue executing things until it gets unloaded. [10:43:32.0000] TabAtkins: ah, OK 2016-06-03 [23:08:21.0000] TabAtkins: it'd be great if LINK ERROR came with a line number [02:06:16.0000] /me gives up on public-webapps [02:45:33.0000] I was thinking the same [02:46:50.0000] Apparently I had already given up on it, but looking at the thread titles, I guess I have an inkling of why there might be a mass exodus [03:02:42.0000] /me wonders if there will be real world use for es symbols [04:52:08.0000] Should a placeholder disappear the moment its input is focused? [04:56:38.0000] nox: up to UX [04:57:01.0000] annevk: No recommandation at all? [04:57:46.0000] annevk: Ain't that inconsistent with the spec for :placeholder-shown? [04:58:14.0000] Hmm don't think so [04:58:41.0000] Err no, can't read. [04:58:50.0000] The spec for placeholder says "User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string, especially if the control is not focused.", so yeah. [06:53:16.0000] /me +1 to Ms2ger [07:05:04.0000] What's wrong with public-webapps. [07:05:06.0000] ?* [07:19:55.0000] signal/noise [07:20:14.0000] astearns: 😊 [07:24:34.0000] What's the TL;DR for 'is' in createElement()? [07:29:54.0000] nox: probably like the "is" attribute, which afaik is necessary to avoid custom elements in tables from being orphaned (or similar things like that)? [07:30:05.0000] I see. [07:45:06.0000] nox, `is` is custom elements [07:45:23.0000] Ms2ger: Should I close the Servo issue? [07:46:35.0000] I just did :) [07:47:02.0000] Ms2ger: Thanks. [09:00:38.0000] its too bad nobody wants to break the web to get rid of that orphaning crap entirely, since it's terrible ._. [09:16:33.0000] JakeA: your SW modules issue reminded me of this... do you think its a problem? https://github.com/slightlyoff/ServiceWorker/issues/894 [09:18:38.0000] ah, yes, good spot [10:15:26.0000] annevk: It'd be great if *all* the errors came with line numbers. Haven't been able to crack that nut so far; it's apparently a well-known problem that lxml drops its line numbers. [10:15:38.0000] (I only get a line number for the element; all the rest have None.) [10:27:13.0000] At this point I'm *this* close to just regex-parsing for opening tags in the original HTML and adding a line-number attribute manually. On the upside, that would avoid me having to coordinate tons of "corrections" as I do various text-munging (mostly Markdown processing) before the HTML parser runs. [10:34:53.0000] Fuck it, I'm gonna do that (behind a command-line flag, so if it fucks anything up you can just not use it). [11:16:02.0000] TabAtkins: lxml sounds sad [11:16:09.0000] It is and I hate it [11:16:42.0000] But it offers the only half-decent tree api that's html5lib-compatible and CSSParser-compatible. [11:17:02.0000] So I just soldier on, and reinvent most of DOM on top of it so I have a sane API to work with. [13:04:05.0000] annevk: still around? Someone is asking in https://bugzilla.mozilla.org/show_bug.cgi?id=289714 if an empty response labelled as XML should fire xhr.onerror .. [13:04:44.0000] I'm not sure but I guess I should RTFS ("read the fantastic spec" ;)) [13:19:37.0000] hallvors: not sure [13:19:56.0000] hallvors: don't think so [13:20:04.0000] annevk: I've just written a comment, hope it makes enough sense [13:20:23.0000] hallvors: broken XML does not fire it either [13:21:00.0000] Indeed, that's what I figured out [13:22:11.0000] hallvors: looks good, don't think we want to change DOMParser at this point either [13:22:40.0000] hallvors: pretty sure web depends on parseerror element and is part of spec [13:23:02.0000] really? which spec? [13:23:35.0000] imho parsererror elements are just weird [13:23:38.0000] :-p [13:24:15.0000] and should die :-] [13:33:59.0000] hallvors: DOM Parsing [13:37:19.0000] if you killed everything weird that should die about the web, there might not be much of a web left [13:45:58.0000] caitp: lol [13:46:57.0000] annevk: then it gets a bit inconsistent - if we mandate the odd parsererror document for a DOMParser, but do NOT want it for XHR responseXML.. [13:47:41.0000] thought whatever.. [13:53:18.0000] hallvors: yeah, jl complained about this too in the good old days [13:53:52.0000] hallvors: no layering or consistency 😢 [13:54:31.0000] But yeah, just have to suck it up and do a better job going forward [14:50:47.0000] annevk: I've tried to sum up the content addressable caching discussions in a blog post, since I found it hard to find all the relevant information in an easily accessible way: https://mntr.dk/2016/content-addressable-browser-caching/ [15:48:57.0000] I think the spec for querySelectorAll is wrong. [15:49:34.0000] nox: How so? [15:49:40.0000] It seems to me that element.querySelectorAll("*") should include element, but user agents don't. [15:52:37.0000] TabAtkins: Specifically, the scope-filtered method says to filter to the scoping root and its descendants. [15:52:52.0000] yup, you're right. as specified it should indeed include element. [15:53:04.0000] But that's not the intention nor does it match impls. So it's a DOM bug. [15:53:10.0000] TabAtkins: Checked in Safari and Firefox. [15:54:51.0000] Chrome agrees too. [15:55:07.0000] File a bug on DOM so annevk can fix it [15:56:35.0000] Yeah will do tomorrow. [15:56:45.0000] Reviewing the failing tests in Servo. [15:56:53.0000] (WPT agrees with UAs already.) [16:06:45.0000] did it for you [16:55:13.0000] TabAtkins: Thanks! [16:59:48.0000] nox: "will do tomorrow" is usually code for "i've already forgotten about it", at least when I say it ^_^ 2016-06-04 [17:00:12.0000] Heh. Nah I planned to do it, but thanks anyway I'm happy to not have things to do. :D [06:31:24.0000] I think I found a bug in the event dispatcher in the spec. [06:31:44.0000] Does the spec ever says to reset the stop propagation flag once dispatch is done? [06:32:31.0000] Maybe it's a test and Firefox bug though. [06:32:38.0000] http://w3c-test.org/dom/events/Event-dispatch-multiple-stopPropagation.html Can someone check that on IE11 and Edge? [06:32:52.0000] Safari, Chrome and Servo pass it, [06:32:56.0000] err, fail it. [06:33:01.0000] Firefox is the only one to pass it so far. [06:35:02.0000] nox: that is a known open bug yeah. There are open bugs on wpt and on dom for it [06:35:21.0000] The spec and wpt don't match, which is bad 2016-06-05 [20:30:48.0000] about the data at https://www.chromestatus.com/features on implementation status in other UAs, does anybody know wherethe source for that data maintained? [04:26:28.0000] Hello everyone [05:43:40.0000] Hi, is there a non-legacy reason for input.files to be readonly? [05:46:45.0000] Maybe the idea is for it to be allowed to append File objects once input.files no longer yields a FileList, but an Array instead? [05:52:51.0000] I think I found another bug with Range.createContextualFragment. [05:53:17.0000] Step 4 says to unmark all scripts in fragment node as already started, so that when they get executed when inserted in a document afterwards [05:53:48.0000] But https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model:prepare-a-script-4 says that we should only prepare scripts when connecting them in a tree if it isn't marked as parser-inserted. [05:54:02.0000] Step 4 should probably say that they should be marked as parser-inserted again. [05:54:32.0000] Because step 7 of "prepare" says 'If was-parser-inserted is true, then flag the element as "parser-inserted" again, and set the element's "non-blocking" flag to false.'. [07:42:34.0000] Looks like input.files is not actually readonly on Chrome. [07:42:44.0000] It still is conformant on Firefox, though. [08:26:40.0000] espadrine: can you construct a FileList somehow? [08:27:01.0000] espadrine: there are various open issues on this, iirc [08:27:46.0000] annevk: Not through a constructor, although you can fetch one from a different input element or from a drop zone. [08:29:04.0000] I’d welcome a link to an issue; I tried searching for one. [08:30:17.0000] espadrine: against IDL perhaps? On my phone, so can't really search well [11:13:35.0000] boolean attributes are best without values ain't it? Can I get a reference link to prove this too? [11:58:02.0000] silverdust: http://heycam.github.io/webidl/#dfnReturnLink-2 [11:58:23.0000] Oh wait, attributes, I read argument. [12:01:16.0000] re: input.files, I made an issue https://github.com/whatwg/html/issues/1391 [12:51:44.0000] yes attributes. Is there any good reason to assign values to attributes like required, checked? Perhaps some browser support? [15:34:13.0000] silverdust: https://html.spec.whatwg.org/multipage/infrastructure.html#boolean-attributes might help. [15:34:38.0000] silverdust: there is no reason to require values; you can use the name of the attribute as a value if you want but it does nothing different than the empty string or omitting the value entirely [15:39:23.0000] Thanks Domenic 2016-06-06 [17:16:13.0000] silverdust: I think something like IE3 or NN3 required the attribute value in full; regardless of what, we're talking twenty year old browsers here [23:27:48.0000] Pro tip: don't cut your index finger [23:28:16.0000] Such a massive pain with the trackpad [23:33:13.0000] annevk: use the other hand… [23:34:03.0000] MikeSmith: for some reason I'm used to use my right hand for this, and even though I'm left-handed that feels very unnatural [23:34:17.0000] MikeSmith: so I'll use my middle finger to point at things [02:21:35.0000] https://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html is pretty interesting [02:21:49.0000] Didn't really know Facebook was also into the typing game these days [02:30:02.0000] Is Flow from Facebook? [02:30:27.0000] Are they unable to name any programming language with something else than a common word? [02:31:07.0000] WHATWG is guilty of that too, so... [02:31:24.0000] Oh? Which languages? I'm curious. [02:31:42.0000] I was thinking of their ML-like language named Reason. [02:31:57.0000] Not languages, but say "Fetch", "Encoding", "Fullscreen", "Notifications", "Streams" [02:32:30.0000] Mmmh true. I guess I'm less surprised because they are specs. [02:33:26.0000] I think generally picking a word is better than picking many words, context is usually sufficient [02:33:42.0000] Also, dude, Mozilla named its language Rust [02:34:02.0000] Uh,"Go"? [02:43:45.0000] annevk: Less common than reason and flow. :) [03:08:06.0000] Yeah "Rust Programming" seems reasonably easy to search, "Flow Programming" less so [05:02:59.0000] https://github.com/w3c/DOM-Parsing/issues/15 [05:04:55.0000] Also, filed https://github.com/whatwg/html/issues/1394 again. [05:56:18.0000] /me kicks blink and its silly data: handling [06:10:17.0000] hrm, I added a comment to a pull :/ [10:29:45.0000] Very happy https://github.com/tc39/ecma262/issues/573 is happening even though I've little to contribute [10:30:15.0000] Just feels so good to finally get to the bottom of certain engine disputes, or at least make some progress on them [10:36:17.0000] ShadowDOM v1 removed Shadow piercing combinators - http://hayato.io/2016/shadowdomv1/#shadow-piercing-combinators - but https://drafts.csswg.org/css-scoping/#deep-combinator still lists >>> in the static profile -- so what is it now? [10:42:02.0000] rodneyre_: I think there's an open issue on this [10:42:09.0000] rodneyre_: and some disagreement [10:42:14.0000] rodneyre_: see the one on /deep/ [10:44:35.0000] rodneyre_: The combinator is *very intentionally* still in CSS in the static profile only (which only covers things like querySelector(), *not* stylesheets). [10:45:35.0000] but it won't select into closed shadows, correct? [10:46:54.0000] Closed shadows dont' exist yet. (Except handwavey in the form of built-in elements that clearly contain internal structure.) But based on what I think is going to happen, no, it won't select in. It won't give any power that you can't get from just poking via DOM APIs. [10:47:42.0000] closed shadows exist [10:48:00.0000] Oh really? News to my ears, but I'm a bit out of the loop. [10:48:13.0000] I've stayed in touch *just* enough to figure out what needs to happen on the CSS side. [10:48:26.0000] yeah, they were necessary to get consensus back when that happened. [10:48:33.0000] I mean, don't get me wrong. I'd happily do away with that, if we get some way to disable focusable elements within a shadow [10:49:31.0000] TabAtkins: I don't think there's agreement on implementing it for querySelector() at this point [10:50:08.0000] It's the plan of record to the best of my knowledge, and no one's contradicted it yet. [10:50:22.0000] It would be pretty fucking stupid to not have it, given that you can just poke thru via the DOM api. [10:50:23.0000] TabAtkins: see https://github.com/w3c/webcomponents/issues/78 [10:51:05.0000] Requiring a .query(...).map(x=>x.shadowRoot).query(...) would be dumb as hell just to avoid .query(... >>> ...) [10:51:27.0000] It seems fine for a first iteration [10:51:34.0000] (It's actually much more difficult to faithfully implement, but even this pretend version is stupid.) [10:51:37.0000] It's not even clear you should iterate that way as rniwa points out [11:11:11.0000] Does anyone know the right contact for Gecko for BroadcastChannel? Would be good to get them to weigh in at https://github.com/whatwg/html/issues/1371 [11:11:40.0000] Baku [11:11:54.0000] bakulf iirc? [11:12:00.0000] On GH [11:13:01.0000] https://github.com/bakulf ? [11:23:58.0000] Domenic: I pinged him in IRC as well, although I think this is towards the end of the work day for him [11:43:56.0000] Domenic: yeah [13:07:29.0000] annevk: what happened to your finger? [13:09:12.0000] hmm i pictured you had it cut off entirely but i suppose that is not necessarily the case [13:25:39.0000] I suspect he just cut it, and bandaids make it hard to use touchpads. ^_^ [13:37:52.0000] just need an outer layer of bacon to fix it 👌 [13:46:14.0000] then you get a greasy screen. d- fix [14:56:25.0000] kickstarter: conductive bandaids for touchscreen use [14:58:30.0000] astearns: They already exist [14:59:12.0000] ugh, of course they do [15:00:55.0000] Your dream of being the Zuckerberg of home medicine will have to be put on hold 2016-06-07 [17:26:08.0000] Domenic: in streams section 3.9.5 (ReadableStreamDefaultControllerEnqueue), does step 5.d.ii mean to rethrow the exception? I'm not really familiar with the "abrupt cancellation" terminology [17:26:36.0000] Domenic: woops... mean step 5.b.ii.2 [17:26:45.0000] or I guess its the same usage there [17:37:35.0000] wanderview: yep, that's the idea. [17:38:00.0000] Domenic: I thought I was finally starting to understand spec language... and then I have to go learn ES spec language :-) [17:38:37.0000] wanderview: it builds character ;) [17:38:47.0000] it builds something [21:52:37.0000] what was the exact reason why Object.observe brought down? [22:11:41.0000] howdoi: https://esdiscuss.org/topic/an-update-on-object-observe [22:17:39.0000] Thanks MikeSmith [00:28:49.0000] hallvors, ping [00:29:23.0000] Ms2ger: pong [00:29:42.0000] hallvors, trying to figure out where the spec backs http://w3c-test.org/XMLHttpRequest/send-content-type-charset.htm [00:29:52.0000] Especially the "charset given but wrong, fix it" ones [00:31:36.0000] Let me investigate a bit - we may have to ping annevk too, I think several of those assertations were written by him originally [00:32:45.0000] Ms2ger: anything not backed by step 4 of https://xhr.spec.whatwg.org/#the-send()-method is likely wrong [00:33:08.0000] Oh wait [00:33:11.0000] Ms2ger: it seems to be testing that from skimming it and those requirements might well have been tweaked a little bit since I wrote that test (or part of it) [00:33:41.0000] Ah, I seem to have missed the last paragraph [00:34:02.0000] ok [00:34:51.0000] I was about to point to step 4, last para too :) [00:35:26.0000] Though I'm not sure that requires the exact string values in the test [00:35:34.0000] /me notes that even the test's meta data is correct [00:36:06.0000] for once :) (lots of meta data is outdated and I have ambitious plans for fixing that) [00:37:08.0000] Someone want to reply to https://github.com/w3c/web-platform-tests/issues/3121? [00:39:02.0000] zcorpan: about experimenting with https://github.com/whatwg/html/issues/1351 “Remove parse error for dashes in comments”, do we want to experiment with also dropping the warning “The document is not mappable to XML 1.0 due to two consecutive hyphens in a comment.”, or do you want to continue to emit that? [00:40:54.0000] annevk - I mostly agree with the 3121 issue, but I think you defended the test when I brought it up earlier ("be strict in what you send" etc). Leaving to you to reply ;) [00:41:21.0000] MikeSmith: i think we should keep that, at least for now. if the people using the validator don't care about those warnings then all of them should be turned off by default, not just for -- in comments [00:41:32.0000] ok [00:41:37.0000] imho [00:41:43.0000] yeah [00:42:06.0000] zcorpan: OK so FYI take a look at the adjustDoubleHyphenAndAppendToStrBufAndErr function at https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/Tokenizer.java#L922 [00:43:25.0000] and https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/Tokenizer.java#L476 [00:43:36.0000] I guess by default it does ALTER_INFOSET [00:44:08.0000] ah wait though, if that were true it wouldn’t be emitting the warning [00:44:56.0000] will need to look at the checker code further to see what it is setting [00:45:27.0000] maybe the validator doesn't use the parser's default [00:45:36.0000] yeah I think it must not [00:45:42.0000] anyway, the simplest change would of course be just to drop the errConsecutiveHyphens(); call at line 924 [00:45:54.0000] Ms2ger: hallvors: I left a reply [00:46:48.0000] zcorpan: but in looking at that code, I could also just move the errConsecutiveHyphens() call into the ALLOW and FATAL cases [00:47:31.0000] so that for ALTER_INFOSET case it would just silently alter the infoset, with no error and no warning [00:48:08.0000] MikeSmith: don't we still want to use ALLOW in the checker? [00:48:12.0000] I guess in the context of the checker it doesn’t really matter much since nothing actually consumes the parse tree it creates [00:48:40.0000] to get the warning if nothing else [00:48:44.0000] OK [00:49:03.0000] so that is what I will do for not [00:49:06.0000] *for now [00:49:14.0000] and push it to https://checker.html5.org/ [00:50:13.0000] MikeSmith: what about [00:51:15.0000] https://github.com/w3c/webcomponents/issues/496#issuecomment-223529711 o_O [00:56:51.0000] MikeSmith: https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/Tokenizer.java#L2602 was also moved to be an error when seeing ">" in COMMENT_END_BANG instead [00:58:43.0000] zcorpan: what about it? we want to try to dropping that error too? [00:59:33.0000] MikeSmith: it's a new error, that won't be reported otherwise [01:00:03.0000] oh [01:00:18.0000] we we want to *add* new reporting for it? [01:00:27.0000] /me looks back that the issue discussion [01:00:29.0000] MikeSmith: https://github.com/whatwg/html/pull/1356/commits/b4d672b4976740cea236f197cc340a066cf0ac6e [01:04:56.0000] zcorpan: https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/Tokenizer.java#L2602 is for --! right? [01:05:02.0000] how is that relevant? [01:06:53.0000] right. i suppose it's a separate thing but i changed it in the PR, because i didn't see any reason to disallow [01:08:31.0000] ok [01:08:53.0000] sorry this was not a one-line change :-) [01:15:06.0000] heh [01:15:28.0000] OK will need to set aside more time to write it up [01:15:56.0000] 👍 [01:26:03.0000] annevk: https://fetch.spec.whatwg.org/#cors-preflight-fetch-0 [01:26:37.0000] annevk: from what it says there, if you have a header `content-type: x-pony`, which is not in accesscontrolallowheaders, it should error, yes? [01:27:11.0000] because http://web-platform.test:8000/XMLHttpRequest/send-redirect-to-cors.htm seems to think otherwise? [01:27:54.0000] Manishearth: yeah, that's not a CORS-safelisted request-header [01:28:35.0000] so is the test wrong? O.o [01:28:44.0000] it somehow passes in firefox [01:28:45.0000] hold on [01:30:20.0000] annevk: ok, not sure what's going on, this test should fail [01:30:40.0000] (it fails in servo, but not firefox) [01:31:31.0000] Manishearth: looking at corsenabled.py I'm not sure why it should fail [01:32:03.0000] annevk: as in? [01:32:11.0000] annevk: we send a content-type: x-pony header with it [01:32:34.0000] so the preflight fetch should return a network error, since that's not an allowed header [01:32:54.0000] Oh yes, and it seems Firefox doesn't even issue a preflight here [01:33:03.0000] Unless the network console cannot be trusted [01:33:27.0000] annevk: I just assumed that the preflight isn't put in the network console [01:35:09.0000] I hope that's not true [01:35:10.0000] annevk: oh, from the wptserve log -- it doesn't [01:35:21.0000] annevk: it should be issuing a preflight, right? [01:35:43.0000] Yeah, I think so, otherwise you could use a redirect to circumvent preflights... [01:35:54.0000] Which seems to be what is happening here [01:36:13.0000] huh [01:36:21.0000] chrome fails these tests [01:36:24.0000] but not the way servo fails [01:36:34.0000] Yeah, also in a weird way [01:36:45.0000] /me curses redirects [01:36:49.0000] chrome, too, doesn't do preflights [01:37:12.0000] brb filing bug on chrome to make tons of bounty monies [01:37:52.0000] chrome doesn't preflight, but it *does* scrub the headers [01:37:57.0000] Manishearth: can you file one against Firefox too and against wpt? [01:38:06.0000] right [01:38:18.0000] Not the best way to start the day [01:38:24.0000] heh :) [01:38:34.0000] well, for once the failure isn't servo's fault :) [01:38:50.0000] annevk: chrome runs wpt too, right? [01:39:10.0000] I'm not sure at what stage they are [01:39:29.0000] annevk: given that no browser does this properly, I assume this isn't a security bug (for firefox?) [01:39:53.0000] Manishearth: it kinda is, but we just discussed it in public [01:40:06.0000] Manishearth: copy Jonas Sicking [01:40:11.0000] yeah [01:44:37.0000] annevk: https://github.com/w3c/web-platform-tests/issues/3123 [01:45:26.0000] should we mark it an easy bug? [01:47:25.0000] Manishearth: probably not, since we want to keep some variant of that test around [01:47:42.0000] Manishearth: we just need to change the pass conditions [01:47:53.0000] Manishearth: and I guess we want a new test for what the old test actually wanted to test [01:48:32.0000] annevk: right, the current test should check for a network error [01:52:37.0000] annevk: how do you recommend I write a testcase for this? [01:56:26.0000] Manishearth: the existing testcase can be changed to invoke assert_unreached() from xhr.onload and test.done() from xhr.onerror [01:56:40.0000] annevk: but that needs wpt [01:56:47.0000] I want to write one that doesn't need wpt [01:56:53.0000] trying to write a netcat test case rn [01:57:15.0000] Manishearth: what are you looking to test? [01:57:36.0000] annevk: that the preflight doesn't happen [01:57:42.0000] for the gecko/chrome bug [01:58:29.0000] Manishearth: you could test that if a preflight did happen, the server would reply something bogus [02:08:15.0000] annevk: ok, now I'm not sure what's happening [02:08:26.0000] I am getting an OPTIONS request with http://manishearth.anapnea.net/tmp/test.html [02:08:56.0000] I don't get one if there are no headers, but that's ok [02:09:06.0000] on firefox, that is [02:09:37.0000] Manishearth: what if you set Content-Type instead? [02:11:49.0000] annevk: no OPTIONS, only GET [02:12:03.0000] Manishearth: there you go [02:12:08.0000] Manishearth: and without redirect? [02:12:41.0000] Manishearth: I guess maybe the check post-redirect is not the same check as normal, which would be pretty bad architecture [02:13:47.0000] annevk: both firefox and chrome skip OPTIONS when there are no strange headers, even on a direct XHR [02:13:56.0000] and they replace POST with GET [02:14:14.0000] in both cases [02:14:37.0000] the only time I get OPTIONS is when I add a strange header [02:15:03.0000] this happens even without redirects [02:15:25.0000] cookies are scrubbed, too [02:15:30.0000] So basically Firefox does not restrict Content-Type: unknown/type? [02:15:36.0000] oh, not tried that [02:15:39.0000]