2017-06-01 [23:12:56.0000] https://url.spec.whatwg.org/#concept-host-parser [23:13:08.0000] Let ipv4Host be the result of IPv4 parsing asciiDomain. [23:13:08.0000] If ipv4Host is an IPv4 address or failure, return ipv4Host. [23:14:00.0000] An IPv4 address [23:14:00.0000] is a 32-bit unsigned integer that identifies a network address. [RFC791] [23:15:48.0000] is an implementation of a host parser supposed to confirm that the ipv4Host (1) is a 32-bit unsigned integer, and (2) that it identifies a network address ? [03:36:52.0000] huh. :-( https://bugs.chromium.org/p/chromium/issues/detail?id=87553#c66 [03:38:18.0000] Hello is this the official Web Hypertext Application Working Group irc channel? [03:39:50.0000] micminty: Web Hypertext Application Technology Working Group, yes :-) [03:41:45.0000] zcorpan: OK, thanks for the quick reply.. [03:43:19.0000] micminty: np [04:11:33.0000] zcorpan: What's that patch? :o [04:12:04.0000] nox: it removes implementation [04:12:34.0000] zcorpan: Is it an independent decision from them or are we all going to remove it? [04:12:49.0000] nox: independent [04:12:53.0000] :/ [06:49:57.0000] We should probably remove it from the spec... [06:53:24.0000] https://github.com/whatwg/html/issues/2730 [11:06:06.0000] Domenic: you around? I'm picking up my old attempt to fix this modules crossorigin WPT [11:07:00.0000] aklein: yep [11:07:16.0000] (https://github.com/w3c/web-platform-tests/blob/master/html/semantics/scripting-1/the-script-element/module/crossorigin.html) [11:07:33.0000] Domenic: and now I'm remembering that I can't even tell exactly what the failing test is trying to do [11:07:42.0000] To the logs!! [11:07:46.0000] it specifies a valueless "crossorigin" attribute [11:07:58.0000] I second Hixie on https://github.com/whatwg/url/issues/295 [11:08:34.0000] http://logs.glob.uno/?c=freenode%23whatwg&s=19+Apr+2017&e=19+Apr+2017#c1026373 [11:10:13.0000] http://logs.glob.uno/?c=freenode%23whatwg&s=19+Apr+2017&e=19+Apr+2017#c1026399 seems like the main outcome [11:10:19.0000] " From the spec's point of view github.com/w3c/web-platform-tests/…origin-root-missingheader.sub.html and github.com/w3c/web-platform-tests/…rossorigin-root-different.sub.html should be identical" [11:10:33.0000] my proposed PR would be to just remove tests 1 and 5 [11:11:36.0000] "aklein: I think we should change them to fail" [11:16:02.0000] Domenic: ok :) [11:18:21.0000] geez, Domenic, let me finish filing the issue first >_< [11:18:43.0000] Er, sorry, thought you did once you edited the title... [11:22:01.0000] Domenic: OK, fire away :) [11:29:26.0000] Domenic: so does the "crossorigin" attribute on the script elements have any effect in these tests? [11:29:39.0000] that's really the only difference between tests 1 and 3 [11:34:35.0000] in fact I don't see any web platform tests that set crossorigin to anything [11:48:26.0000] aklein: well the servers respond differently, right? [11:49:02.0000] aklein: nevermind, same URL [11:49:14.0000] aklein: it doesn't have any effect in this case since the server isn't allowing you to access anyway. [11:49:24.0000] But Microsoft thought it did, so it's good to keep a test showing the opposite. [11:49:58.0000] crossorigin="" for module scripts should impact whether credentials are sent or not, and how [11:50:05.0000] But yeah I don't think there are good tests for that yet [11:50:12.0000] Possibly ones are being added as part of fixing that Chrome bug [12:37:41.0000] Domenic: crossorigin="" on modules sends creds same-origin whereas ="use-credentials" sends creds cross-origin right? [14:39:56.0000] domfarolino: correct [14:40:22.0000] foolip: on https://github.com/whatwg/html/pull/2627 / the corresponding fullscreen PR, would editorial-ish review be helpful, or wait for annevk to get back, or you and upsuper can take care of it...? [14:52:24.0000] Domenic: re: https://codereview.chromium.org/2914273002/, you're not a Chromium committer? [14:53:23.0000] aklein: nope 2017-06-02 [05:08:01.0000] 0 notifications!! (down from something like 550) [12:13:18.0000] jugglinmike: where did we come to a decision on returning basic for same-origin no-cors requests? https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-worker/fetch-response-taint.https.html#L122 [12:13:24.0000] I can't find it [12:15:05.0000] wanderview: https://github.com/whatwg/fetch/issues/535 [12:15:43.0000] thanks [12:31:10.0000] no problem [13:19:34.0000] jugglinmike: does chrome actually pass this somehow? https://github.com/w3c/web-platform-tests/blame/master/service-workers/service-worker/resources/fetch-response-xhr-iframe.https.html#L43 [13:19:41.0000] seems that should throw since event doesn't exist [13:20:54.0000] jugglinmike: I'll fix it locally and get it upstreamed [13:22:25.0000] wanderview: it does pass [13:22:33.0000] but that change is definitely not intention [13:22:37.0000] intentional [13:22:44.0000] It passes because of this https://developer.mozilla.org/en-US/docs/Web/API/Window/event [13:23:01.0000] ah.... [13:23:02.0000] ok [13:23:13.0000] I didn't know that existed [13:23:31.0000] Sometimes [13:27:41.0000] jugglinmike: I guess we are thinking of implementing it in the future... but some stuff with shadow dom needs to be spec'd [13:27:48.0000] or something [13:31:36.0000] the lack of support in Firefox is a good thing. I'd like that to go away, so FF proves that interop isn't a problem [13:38:07.0000] jugglinmike: does this one pass for chrome? https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-worker/fetch-request-fallback.https.html#L96 [13:38:20.0000] AFAICT the harness does not like passing null for the exception type there [13:38:31.0000] https://github.com/w3c/web-platform-tests/blob/51a11c7f17d967633edbefff36cfb2f0ae23c074/resources/testharness.js#L1182 [13:43:14.0000] wanderview: You're right; it does not. We were only able to land it because of timing issues in the upstreaming process. Mek caught that her https://codereview.chromium.org/2858933003#msg23 [13:43:45.0000] and while I offered to "correct this in WPT directly", I failed to follow through on that offer [13:43:49.0000] I will do so presently [13:44:02.0000] jugglinmike: I can do it... but what did you end up using? [13:44:43.0000] 'NetworkError' or new TypeError()? [13:45:04.0000] Oh, hey [13:45:16.0000] Actually, I'm not as big of a screw-up as I thought [13:45:19.0000] Here's the patch https://github.com/w3c/web-platform-tests/pull/5869 [13:46:44.0000] I can't request your review on GitHub.com, though. Do you have commit rights to WPT? [13:47:39.0000] no [13:47:56.0000] I can land it locally and get it upstreamed if you want [13:48:09.0000] jugglinmike: that patch fixes the test for us [13:48:45.0000] jugglinmike: I'm doing a pass of WPT stuff and will request a sync next week sometime [13:49:16.0000] or you can land it there and we'll get it on sync [13:49:21.0000] I guess it doesn't matter [13:50:16.0000] Unfortunately, it's out of my hands now [13:50:22.0000] oh? [13:50:44.0000] It needs a review [13:51:26.0000] I'll add Matt on the Chromium team to the list of requested reviewers. He's in Japan, but he may be able to get to it before we're in on Monday morning [13:51:29.0000] jugglinmike: do you mind if I land it locally and upstream that way? [13:51:37.0000] ok, I'll just wait [13:58:04.0000] jugglinmike: can you request review from me now? [13:58:55.0000] oh, mek approved them [13:59:16.0000] hah, seems he did [13:59:21.0000] Thanks, Mek! [13:59:28.0000] will it auto-merge? [14:00:01.0000] Refresh [14:00:06.0000] It's merged now, too [14:00:15.0000] awesome, thanks [14:00:18.0000] I have trouble reading [14:03:44.0000] No worries. It's the end of the week, after all [14:17:42.0000] rniwa: webkit doesn't support HTML Imports , right? [14:17:45.0000] and doesn't plan to [14:17:59.0000] smaug: nope [14:18:14.0000] smaug: we don't support HTML imports or builtin custom elements, and we don't plan to [14:18:27.0000] wanderview: ^ [14:24:13.0000] thanks [14:24:43.0000] rniwa: do you guys have any thoughts on "html modules" approach? I've heard some rumblings about that [14:24:52.0000] Domenic: Reviewed https://github.com/whatwg/html/pull/2588 [14:25:23.0000] The CL with the tests is ready to go. Ideally we want to land both at the same time [14:25:42.0000] (and I don't have write access) [14:33:37.0000] yoav: should be good to go, except you gotta merge the preload spec change :) [14:36:08.0000] Domenic: deal! [14:37:37.0000] yoav: https://github.com/w3c/preload/issues/95 and https://github.com/w3c/preload/issues/80 now seem closable [14:37:56.0000] just closed [14:38:18.0000] :) [14:39:26.0000] Next is https://codereview.chromium.org/2903653005/. I'll change the IDL according to your comments and land [14:41:22.0000] wanderview: html modules seem more promising but we haven't really hashed out details ourselves yet [14:52:02.0000] The site `https://github.com/whatwg` says "To be invited, just ask us on IRC; all are welcome to participate." SO I am wondering if I can be added. [14:53:37.0000] Also, how do I submit a proposal for things related to V1 Web Components? [14:56:14.0000] intervalia: file an issue on https://github.com/w3c/webcomponents/, but please pay attention to https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F [14:56:32.0000] intervalia: Hm I think that means more along the lines of anyone can participate, just ask and mentorship can be provided, since there are only 39 people publically associated with the org. Could be wrong though. [14:56:45.0000] indeed, that's what it means :) [14:57:12.0000] OK. Maybe a little clarification to that message... [14:57:19.0000] Thanks for the info on Web Components. [15:05:03.0000] publicly* lol [16:59:02.0000] Domenic, i vote we make a joke about the subsubsubsubsubsubsteps littered around the spec in XHR for the next april fools 2017-06-03 [17:14:56.0000] \example\..\demo/.\ [17:15:09.0000] what is the domain supposed to be on that, according to URL? [17:15:15.0000] sorry, host [17:52:57.0000] GPHemsley: https://quuz.org/url/liveview.html#\example\..\demo/.\ [17:53:18.0000] lovely, thank you [17:54:02.0000] wait, that automatically uses the current URL as the base? [17:54:57.0000] I should have specified, I'm looking for the raw output from "basic URL parser" [17:55:39.0000] that is it [17:55:57.0000] there is no URL without a base [17:56:14.0000] there it just uses https://quuz.org as the base [17:56:24.0000] but you can replace that with whatever other base you want [17:56:30.0000] how? [17:56:57.0000] conceptually [17:57:02.0000] it is arbitrary [17:57:23.0000] the algorithm acts differently when there is no base [17:57:36.0000] yeah it fails [17:57:46.0000] because it must have a base [17:58:31.0000] anyway the only relevant information to discern from that string is what path it would produce [17:58:58.0000] I'm trying to debug my implementation [17:59:00.0000] which https://quuz.org/url/liveview.html#\example\..\demo/.\ tells you [17:59:12.0000] I see [17:59:42.0000] well I don’t see how you can implement anything without evaluating the input string against a base [17:59:54.0000] again, base can be null [18:00:02.0000] and the algorithm acts differently when it is [18:01:09.0000] but ok, I guess I understand what you're saying [18:01:40.0000] OK yeah well I don’t know any other tools that let you test what happens with some input string in the base=null case [18:01:41.0000] I think my actual problem is in "host parser" [18:02:07.0000] so I'm trying to figure out what the return value for that is expected to be [18:02:12.0000] in this case [18:05:16.0000] in order for the "basic URL parser" to know to use the base URL's host, it has to determine that the URL doesn't have a valid host [18:05:44.0000] and my implementation seems to have a problem with doing that in this case [23:26:26.0000] GPHemsley: if base is null you get failure for that input [23:26:53.0000] annevk: For which algorithm? [00:25:07.0000] GPHemsley: URL parser [03:42:05.0000] I notice that a lot of browsers skip the capture phase during event dispatching in certain specific situations. this is not specced anywhere right? [04:06:20.0000] JoWie: Do you have a sample? [04:08:03.0000] img.dispatchEvent(new Event('load')) vs img.dispatchEvent(new Event('foo')) [04:08:22.0000] the first one only seems to handle the AT phase [04:09:02.0000] in firefox and chrome [04:10:32.0000] however if the load event is triggerd by the browser isTrusted, it does enter the capture phase [04:10:47.0000] i'm just wondering if this is against the spec or that i'm missing something [04:12:07.0000] JoWie: Is your listener's capture flag set to true? [04:12:24.0000] yep [04:12:40.0000] No idea then, can't find anything in the spec. :) [04:12:42.0000] i log both with and without [04:12:52.0000] yea that's what i thought [04:13:24.0000] i've noticed a lot of spec violations with event handling before, perhaps i should add some WPT's [06:50:18.0000] JoWie: for load the Window object has a special case [06:51:22.0000] JoWie: does not explain the isTrusted thing though, so maybe file a bug against DOM [06:55:40.0000] so the process nowadays is to file a DOM bug? not at each browser vendor? [06:55:45.0000] or HTML, etc [07:15:40.0000] JoWie: depends on the bug, but this kind of mismatch prolly needs investigation [07:16:04.0000] ah sure [07:16:16.0000] JoWie: and if browsers are consistent it seems best to start with the standard [07:35:23.0000] annevk: I need to know what happens for "host parser" [07:40:23.0000] GPHemsley: would reject on the slashes iirc [07:40:42.0000] so return failure? [08:58:26.0000] GPHemsley: hai [08:58:34.0000] /me waves [10:08:35.0000] annevk: my issue indeed only occurs for when i add the listener to the window. so i guess it's in the spec after all [10:22:47.0000] the isTrusted thing was incorrect [12:09:41.0000] annevk: I assume you've figured out by now that I've spent the week creating an implementation of URL in Perl. :) [12:12:12.0000] 800/849 tests passing, so almost there [13:58:19.0000] GPHemsley: cool, I'm on vacation so haven't been keeping track of things [16:30:40.0000] annevk: When do you come back? [16:31:36.0000] (this is apparently what I do when *I'm* on vacation) 2017-06-04 [21:31:58.0000] hmm... it always help if you finish coding a particular section >_< [21:57:43.0000] GPHemsley: beginning of next month [21:57:57.0000] oh wow, you're taking the whole month? [22:01:38.0000] I hope that's for positive reasons [22:10:02.0000] Fairly normal in Europe I think [22:41:39.0000] ah, so many things normal in Europe that are unthinkable in the U.S.... :( [22:42:04.0000] like, you know, caring about people's wellbeing and such [10:57:25.0000] well well well... I actually found an implementation difference [10:57:53.0000] https://quuz.org/url/liveview.html#http://./ [10:58:06.0000] https://quuz.org/url/liveview.html#http://../ [10:58:15.0000] the platform tests don't match the spec [10:58:22.0000] so that's fun [10:59:07.0000] wait, this is a 3-way difference [10:59:20.0000] >_< [11:00:02.0000] spec says (a), WPT says (b), jsdom/whatwg-url does (c) [11:00:38.0000] Domenic, annevk: Thoughts? ^^ [11:02:12.0000] hmm, lemme dig deeper into this... this distinction hinges on whether the base URL can be a base [11:43:04.0000] hmm, might just be jsdom/whatwg-url that's wrong [11:43:28.0000] I think there's an issue in the implementation of Unicode ToASCII that is clouding my implementation 2017-06-05 [17:01:20.0000] I think the test is wrong in this case: https://quuz.org/url/liveview.html#http://4294967296 [17:01:26.0000] (says it should fail) [17:06:54.0000] unless this is another problem with ToASCII >_> [18:09:53.0000] Releasing to the world: [18:09:54.0000] https://github.com/GPHemsley/WHATWG-Infra [18:10:01.0000] https://github.com/GPHemsley/WHATWG-URL [20:16:46.0000] GPHemsley: very cool [20:36:38.0000] MikeSmith: :D [00:54:22.0000] gsnedders: how do I run tokenizer tests with html5lib? [02:24:14.0000] gsnedders: can you add inikulin as a collaborator for html5lib-tests? [06:15:13.0000] dgrogan: re https://github.com/whatwg/html/pull/2734 , If you're implementing this in chromium, adding tests to external/wpt and referencing the CL there is OK. [08:48:21.0000] igrigorik: what do you think rIC should do in this case: setInterval(f, 5); requestIdleCallback(d => console.log(d.timeRemaining())); [08:48:39.0000] igrigorik: should requestIdleCallback's deadline.timeRemaining() ever return more than 5ms? [16:27:30.0000] Domenic: do you think an implementation of Console should throw on, eg, console.log()? [16:29:23.0000] as wrritten right now `console.log("symbol: %s", Symbol.for("foo"))` should throw [16:30:06.0000] """If specifier is %s, let converted be the result of ToString(current).""" 2017-06-06 [17:30:08.0000] terinjokes: yeah, IMO conversions should throw; we've been adding a few tests for that. [17:30:29.0000] That said symbols should maybe get a special exception? [17:33:58.0000] Domenic: as a user, i would be a tad surprised by console.log throwing [17:34:49.0000] I mean, would you be surprised if the argument was { toString() { throw x; } }? [17:35:19.0000] i think this goes back to the conversations about if console logging is observable [17:35:52.0000] i don't remember the resolution to those [14:48:12.0000] How do you rename things on MDN? https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs [14:49:11.0000] Domenic: There's an "Edit Page Title" right under the page title when you're editting. [14:49:32.0000] TabAtkins: thank you.... -_- [14:49:41.0000] ^_^ [15:31:21.0000] Hello, I just noticed that some types of input elements (like `input[type=number]`) do not provide selectionStart/selectionEnd getters (and related methods/properties).) [15:33:47.0000] There's Bugzilla issue on the topic, closed as wontfix because the W3C spec doesn't mention that functionality for type=number... It would be nice to have those though, for UA whose widgets are plain text inputs that can be selected. [15:35:15.0000] Should I open an issue at https://github.com/whatwg/dom, or is it a lost cause (if so, I'd love to know why). [15:56:16.0000] They're not provided because type=number/etc don't necessarily have text-based input; there's no guarantee that a selection can even exist. [15:57:16.0000] it should be mandatory that they don't have text-based input. I hate entering dates and stuff on mobile browsers without the keypad UI :< [16:03:33.0000] TabAtkins, That was my guess, but it would be nice for UAs that do implement them as text fields to provide them (be them noops on other platforms). [16:04:48.0000] UAs shouldn't do that in the first place, and having APIs that work differently like that encourages bad design - it's easy to test on the one browser you usually use, and not realize you have a broken site for someone using another browser. [16:05:21.0000] (By "shouldn't do that", I mean "provide text-based input"; like caitp said, giving better input methods is *way* better for the user.) [16:05:52.0000] My current problem is: I have a client that wants me to emulate `maxLength` on an input[type=number] field. It can be done in JS, except for taking care of selections. [16:06:59.0000] If the field has reached the limit, you can't select some of it to type over. [16:08:16.0000] What would you suggest as a better input method for numbers on devices with a physical keyboard? [16:08:52.0000] pygy: you can do max="999" [16:09:13.0000] pygy: a better input method is e.g. a keypad (with no selection allowed) [16:09:27.0000] That won't limit the text size [16:09:30.0000] Instead of preventing typing, just show a validation message if the .valueAsNumber is too large? [16:09:31.0000] Yes it will... [16:09:36.0000] It will limit it to at most 3 [16:11:09.0000] The field will be marked as invalid, but you can type more http://jsbin.com/kalijiridi/edit?html,output [16:11:33.0000] Sure, yeah, that's what I meant [16:11:38.0000] You can never stop people from typing more, even with maxlength="" [16:12:18.0000] But maxlength doesn't work for numbers [16:12:19.0000] (Well, depends on the browser UI, but again, you're using browser UI, the browser gets to make the decisions.) [16:12:38.0000] Indeed, you're supposed to use max="" instead for numbers [16:13:03.0000] Are we going 'round in circles? [16:13:07.0000] Yeah, seems like [16:13:23.0000] maxlength="" is not a guarantee that you can't type longer. Several mobile browsers just make the field invalid, I believe [16:13:24.0000] Around a hole in the spec? [16:13:48.0000] The spec doesn't prescribe UI [16:13:54.0000] So this cannot be a problem with the spec [16:14:12.0000] It is valid per the spec for input type="number" to accept the string "nine hundred and ninety nine" [16:14:46.0000] Or perhaps more realistically, 三百五 [16:14:59.0000] The hole is the lack of support for selections in text fields [16:15:11.0000] How would you "select" a numeric keypad? [16:15:15.0000] It's not a text field [16:15:20.0000] If you want a text field, use input type="text" [16:15:27.0000] Another valid UI is a dial [16:15:31.0000] If the UA falls back on a text field, provide selction-related properties/methods. [16:15:36.0000] Noop out otherwise [16:15:46.0000] As explained above, that doesn't work because of cross-browser issues [16:16:14.0000] What wouldn't work? [16:16:23.0000] 19:04:48 UAs shouldn't do that in the first place, and having APIs that work differently like that encourages bad design - it's easy to test on the one browser you usually use, and not realize you have a broken site for someone using another browser. [16:17:06.0000] (having APIs that work differently depending on platform, like you suggest with your "if... noop out otherwise") [16:17:34.0000] It's also valid, in particular, to type "00009", which will contain the numeric value 9, and send "9" when submitted. [16:17:48.0000] There's no reason to prevent people from typing that if it's a number. [16:18:19.0000] If it's not a number, but just a string that only contains digits, then you want to use type=text and inputmode=digits, if I recall the attribute value correctly. [16:18:27.0000] And then you can just use maxlength like normal. [16:18:48.0000] Yeah, if your goal is to limit people to e.g. between 0 and 999, trying some maxlength="3" equivalent will fail badly on 三千 (=3000) [16:19:40.0000] Maybe that can be helpful in convincing your client :) [16:19:49.0000] I'll see how `inputmode` gels with the accessibility team, thanks. The site is French/English only... Arabic numbers only. [16:21:39.0000] Sure but lots of people visit French/English sites from other-language phones or computer OSs, which is what input type="number" will care about (the OS's settings) [16:22:07.0000] Positive integers... So I'm already filtering out non-digits with JS. Those are weird requirements, I agree... I'm several steps removed from the people who make those decisions, so it's not easy to argue... [16:22:17.0000] Heh, yeah, I've been there... [16:23:02.0000] All I can say is HTML designed min/max for this use case, so hopefully that'll work for those folks... if not then they probably don't want an actual number input, but a text input with some restrictions, yeah. [16:23:02.0000] It's an insurance site, to order insurance products in Canada. [16:23:17.0000] I hear Canada has a lot of Chinese expats [16:24:58.0000] What's the actual "number" you're putting in? [16:25:23.0000] Domenic, truth, i am one [16:25:28.0000] Again, is it a real number, or just a string that's limited to digits? (That is, is doing math on the value meaningful, or is it just an identifier?) [16:25:33.0000] vancouver is dubbed as little Hong Kong [16:25:45.0000] Money amounts. [16:26:53.0000] Used either to for comparison, or to be sent over the network (as floats, yuck) [16:27:22.0000] Okay, so then yeah, just use or whatever. That's literally all you need. [16:27:43.0000] (Remember that you have to do validation on the value on the server side, too - there's no way to prevent the client from sending whatever random data it wants.) [16:28:22.0000] I know, the server is none of my business. All I have is a schema, and an endpoint. [16:28:47.0000] Also: um, you might want to kick it up the chain that representing money as floats can sometimes have legal consequences when pennies are added or lost. They should be integers representing cents, or whatever fraction of cents you're legally required to work in. [16:29:20.0000] I already did [16:29:37.0000] to no avail [16:30:23.0000] I asked for amounts in cents, as integers, it fell on deaf ears. [16:31:53.0000] The server sends non-integers amounts, and I convert them immediately to integer cents amounts [16:42:32.0000] Thanks for the discussion guys :-) `input[inputmode=numeric]` is the actual value (which isn't reflected as poperty on the element) [16:45:32.0000] Well "numeric" is the value, and "inputmode" isn't reflected... the previous sentence didn't make any sense :-) [16:45:42.0000] Bye 2017-06-07 [00:58:07.0000] hsivonen: MikeSmith: checking https://drafts.fxtf.org/geometry/ with checker.html5.org or validator.nu but via file upload seems to cause a timeout (v.nu says " IO Error: java.util.concurrent.TimeoutException: Idle timeout expired: 30000/30000 ms", checker.html5.org gives a blank page after a while) [00:58:18.0000] hsivonen: MikeSmith: checking a small file works ok [03:33:59.0000] zcorpan: thanks for the heads-up [03:34:12.0000] yeah, https://checker.html5.org/#file just hangs when I try it with that file [03:34:33.0000] an no errors getting logged on the server side [03:34:52.0000] hmm ERR_SPDY_PROTOCOL_ERROR [03:34:57.0000] in Chrome [03:35:40.0000] but I guess that’s not the related really [03:37:27.0000] works fine at https://validator.w3.org/nu/#file [03:37:43.0000] i get the same result in firefox as in opera [03:37:54.0000] there is some chance the cause is in nginx [03:38:26.0000] I think hsivonen and I are using a similar setup, using nginx to do the TLS termination [03:39:09.0000] and proxying to the vnu jetty web server on port 8888 [03:39:56.0000] hmm yeah [03:40:11.0000] zcorpan: I’ll tell you a little secret [03:40:16.0000] http://w3c-test.org:8888/ [03:40:36.0000] that’s what https://checker.html5.org/ is currently proxied to [03:40:46.0000] and if you try it there it works fine [03:40:50.0000] file upload [03:41:20.0000] because that does not go through nginx but instead directly to jetty [03:41:59.0000] so I guess there is probably some nginx config setting we need to tweak [03:42:32.0000] I thought I had already, upped some file-upload size limit that nginx has a low default for [03:42:39.0000] interesting. but doesn't explain java.util.concurrent.TimeoutException in v.nu? [03:42:58.0000] yeah that I don’t know why [03:43:01.0000] /me bbiab [15:08:34.0000] tbug [15:08:56.0000] /me accidentally typed in the wrong window :( [15:26:18.0000] MikeSmith: I have a bit of free time, would you like me to help move the files around for the multipage dfn.js PRs so we can merge them? [15:31:15.0000] Domenic: yeah if you have the time now [15:31:35.0000] would appreciate it [15:31:35.0000] https://accounts.spotify.com/authorize [15:31:39.0000] oofs [15:32:11.0000] as far as the filename, html-dfn.js is fine by me [15:33:27.0000] but I can also do it myself now if you want [15:33:53.0000] I have about 30 minutes free now [15:34:08.0000] I'm happy to do it, and let you have the free time :) [15:34:16.0000] :) cheers [15:54:18.0000] Domenic: What's the most reasonable way to poke at TC39? Still es-discuss? [15:54:29.0000] TabAtkins: for new feature proposals, yeah [15:54:35.0000] kk 2017-06-08 [22:08:56.0000] Is there a benefit of using multiple link tags w/ media attributes as opposed to stuffing ALL styles into one file and using @media throughout? My guess is there will be less render blocking CSS since the parser doesn't have to actually parse ALL styles up front (and of course wait for that larger file to download) to display page...is this accurate? [23:43:31.0000] MikeSmith: hmmm. the script is loading cross-references when selecting some text. is that intentional? [23:44:45.0000] zcorpan: nope [23:44:52.0000] dunno why it would do that.. [23:45:05.0000] but will investigate and fix it [23:45:32.0000] but I guess it’s just the event listener [23:46:05.0000] I mean, it’s probably not the select but just the click event? [23:46:47.0000] which is ignore if you’re clicking on a hyperlink [23:46:58.0000] but otherwise do not ignore it seems [23:47:31.0000] so I think it will happen every time you click anywhere in a page other than a hyperlink [23:48:26.0000] MikeSmith: right [23:49:50.0000] OK I’ll figure out how to make it not do that and write a patch and PR it [23:54:36.0000] MikeSmith: i guess the listener should check if e.target or e.target.parentNode or e.target.parentNode.parentNode is a dfn, and none of those are [23:55:51.0000] (or walk up to maybe) [23:55:57.0000] zcorpan: yeah was trying to think of a more elegant way but I guress that will do [23:57:18.0000] matchesSelector could work but is likely more expensive. but maybe that doesn't matter if it happens on each click [23:59:02.0000] well I guess just iterating up to body is simple and fast [00:21:30.0000] TabAtkins: So regarding our discussion about computed values and serialisation, [00:22:00.0000] TabAtkins: Does that mean that https://drafts.csswg.org/css-shapes/#basic-shape-computed-values doesn't matter when it comes to serialising these computed values, and that parts that can be omitted should be? [02:23:52.0000] MikeSmith: i'm looking at html-dfn now [02:24:06.0000] ok thanks [02:25:01.0000] (sorry I didn’t get teh PR raised earlier; needed to pick up my little one from daycare) [06:36:35.0000] nox: Yes [06:37:54.0000] zcorpan: sorry, I don't know how to fix that with nginx [06:40:33.0000] TabAtkins: Nice! [08:37:18.0000] TabAtkins: is that Shapes section incorrect? [08:38:25.0000] or is it just that it's not applicable to serialization? [08:41:42.0000] astearns: Not applicable to serialization. [08:42:01.0000] It's just normalizing the computed value to have all the information readily available. [08:42:14.0000] And then serialization outputs the shortest form of it, which will often omit some of that information. [09:28:11.0000] is there work under way getting link preload with integrity|nonce attribs working with fetch and csp sri for script|style ? [09:55:11.0000] TabAtkins: And OTOH we serialise to the shortest form for specified basic shapes only because of the spec, right? [09:55:40.0000] Because of CSSOM [09:55:40.0000] TabAtkins: Other properties, by default, should serialise to whatever was in the property rule, just normalising whitespace and whatnot, is that correct? [09:57:01.0000] This is for computed values. Specified values should match what was input (modulo whitespace/etc) [09:57:41.0000] TabAtkins: Except in the case of basic shapes and similar cases, where the spec states how they should be serialised, right? [09:58:23.0000] No, it shouldn't be. [09:58:37.0000] (Our story isn't too straight here.) [09:59:10.0000] I would love to be able to just serialise shortest forms all the time, but I guess that's wishful thinking. [10:00:10.0000] People depend on specified values equaling what they entered, in general. [10:00:12.0000] TabAtkins: Adding that this part isn't too clear for now makes a lot of sense, I'm ok with that. [10:00:42.0000] TabAtkins: Sometimes you state things as if they are crystal clear from the prose in the various specs and it confuses the hell out of me hah. [10:00:47.0000] This is only observable by looking at a stylesheet directly or reading .style, of course. [10:00:52.0000] Hehe, sorry. [10:01:04.0000] My specs aren't golden in this regard either. [10:01:40.0000] Well, I don't blame you, given how implementing that stuff is a huge task, I don't want to even think about how to specify them. [10:02:08.0000] One of my tasks for Typed OM is too define the "shortest form serialization" for every single property. [10:02:10.0000] Joy. [10:02:38.0000] TabAtkins: In Servo we switched a lot of code to use generic types, parameterised for example by a specified or computed length, [10:02:56.0000] so simpler properties share the same code for serialisation, [10:03:12.0000] that's why I would like both of them to just serialise the same, but I guess real world won't let me have that. :) [10:03:42.0000] Understandable. [10:03:48.0000] I'd do it if I could! [10:03:55.0000] TabAtkins: And the cherry on the cake, [10:04:21.0000] TabAtkins: I recently implemented #[derive(ToCss)], so we don't even have to write serialisation code anymore for many properties. [10:05:36.0000] Rust's #[derive(...)] has been damn useful to implement many aspects of the CSS properties, whether a value contains viewport percentages, how to compute values, and serialisation. [10:06:30.0000] Interesting! 2017-06-09 [00:09:56.0000] zcorpan: I’m looking at https://github.com/whatwg/wattsi/issues/47 now [00:10:06.0000] = xrefs.json should include cross-spec definitions [00:10:18.0000] > Clicking on a definition in the Dependencies section used to bring up a panel with the references in HTML. [00:10:43.0000] can you say precisely which references you mean [00:10:52.0000] or just one of them [00:11:52.0000] ah I guess all of them [00:12:50.0000] when I look at snapshots I don’t see that popups were being generated for those [00:12:53.0000] https://html.spec.whatwg.org/commit-snapshots/79151848f8f80bb59d9e7bd469c9c1e4e2e7940a#dependencies [00:15:12.0000] at least now we are (still) generating the popops [00:15:36.0000] so I just need to figure out why it’s not able to populate them [00:18:02.0000] OK those terms are actually all in the xrefs.json file [00:18:33.0000] e.g., “strip leading and trailing ASCII whitespace” [00:20:52.0000] that is, strip-leading-and-trailing-ascii-whitespace [00:21:10.0000] and code-point is in there too [00:21:14.0000] etc etc [00:21:41.0000] so I think the problem must be in html-dfn.js? [00:54:33.0000] MikeSmith: ok. I didn't actually debug, just guessed at the cause [00:55:27.0000] yeah, glad it turns out the cause is not the wattsi code [00:55:38.0000] now looking at the JavaScript [00:58:57.0000] but I have only 2 minutes [00:59:05.0000] now 1 minute [00:59:21.0000] before I get sucked off to something less useful for at least an hour [00:59:30.0000] will get back to it after that [01:00:34.0000] zcorpan: btw thanks immensely for fixing all the stuff I regressed with move to the multipage-enabled dfn handling [01:01:37.0000] MikeSmith: thank you for enabling multipage dfn ^_^ [01:19:29.0000] hmm. wattsi does not emit a tag. so our scripts at the top in body are parsed in head [01:49:28.0000] oh [01:50:14.0000] well `source` has no tag right? [01:50:33.0000] maybe we can fix it just by adding it to `source` [01:51:44.0000] zcorpan: btw I mispoke earlier, about the cause of the Dependencies problem not being in wattsi [01:52:07.0000] MikeSmith: source has body [01:52:15.0000] I had just gotten confused about the state of my working copies [01:52:19.0000] oh [01:52:37.0000] OK well we can fix that thing in wattsi easily enough [01:52:47.0000] I've PRed already :-) [01:52:52.0000] ah cool [01:53:06.0000] so about the Depedencies thing, the wattsi fix is dead simple [01:53:13.0000] sweet [01:53:16.0000] - if ((Variant <> vDEV) and (not DFN.HasAttribute(kCrossSpecRefAttribute))) then [01:53:20.0000] + if (Variant <> vDEV) then [01:53:23.0000] will PR that right now [01:53:55.0000] I now do not remember why I put that `and (not DFN.HasAttribute(kCrossSpecRefAttribute)` in there to begin with [01:54:15.0000] i almost have re-opening panel across multipage working [01:54:33.0000] oh wow [01:54:35.0000] great [01:55:06.0000] yeah in pratice that UX regression is pretty glaring [01:55:54.0000] since when actually using the spec, you end up following many dfn links across pages [03:40:22.0000] man now i might just start to use multipage again [04:00:05.0000] do updates happen automatically now when merging changes to wattsi (for travis CI, deployment)? Domenic? [04:23:35.0000] zcorpan: for unknown reasons no, the web hook errors out. You have to ssh in. [04:26:32.0000] Domenic: ok. can you do that for https://github.com/whatwg/wattsi/pull/49 ? [04:44:29.0000] I want https://discuss.httparchive.org/t/numdomelements-data/756/2 but for
specifically (i.e. REGEXP_MATCH(LOWER(body), r')') or so) [04:45:14.0000] How do I write a query to count matches for each site? [04:45:55.0000] what I've tried I think counts number of resources that have
at all, not the total number of
s there is [04:46:56.0000] igrigorik: ^ [04:47:51.0000] (checking just where page = url is fine) [08:28:47.0000] hi there! [08:29:01.0000] Salva from Mozilla here [08:29:26.0000] good afternoon from Spain [13:51:43.0000] Domenic: Per aklein, the better way to contact tc39 is via their github or mozilla#jslang IRC. [13:51:57.0000] TabAtkins: er, or #tc39 on Freenode [13:52:02.0000] bterlson created that soon [13:52:09.0000] Yeah, I'm in that one. [13:52:19.0000] Should probably join moz's IRC. [13:54:34.0000] GitHub is only really for bug reports. [15:59:09.0000] anybody here have some experience with Yacy or Solr? [15:59:37.0000] I have a Yacy instance set up to index the multipage HTML spec [15:59:54.0000] and it successfully indexes all the pages expect just one [16:00:00.0000] https://html.spec.whatwg.org/multipage/media.html [16:00:49.0000] my Yacy admin console shows it fetched that document successfully and has the raw content [16:02:07.0000] but then it shows nothing in the Parsed Content and Parsed Sentences parts of the admin browser for that page [16:02:55.0000] whereas for all the other multipage/ documents it shows the expected results of parsing those [16:03:18.0000] .. [16:04:07.0000] so one thing I’m wondering is, what HTML parser does Yacy use and is it failing on that document for some reason [16:05:22.0000] would like to get this figured out, because otherwise we can’t get search results for searches of any text in that /multipage/media.html document [16:34:56.0000] https://github.com/yacy/yacy_search_server/blob/master/source/net/yacy/document/parser/htmlParser.java I guess 2017-06-10 [15:50:25.0000] TabAtkins: ⬇ [15:50:32.0000] curl https://api.csswg.org/bikeshed/ -F url=https://raw.githubusercontent.com/w3c/ServiceWorker/master/docs/index.bs -F output=err [15:50:54.0000] \033[1;33mLINK ERROR:\033[0m No 'dfn' refs found for 'the worker's documents'. [15:50:54.0000] <a data-link-type="dfn" data-lt="the worker’s Documents">the worker’s Documents</a> [15:50:57.0000] \033[1;33mLINK ERROR:\033[0m No 'dfn' refs found for 'unicode serialization of an origin'. [15:51:00.0000] <a data-link-type="dfn" data-lt="Unicode serialization of an origin">Unicode serialization</a> [15:51:03.0000] \033[1;33mLINK ERROR:\033[0m No 'dfn' refs found for 'unicode serialization of an origin'. [15:51:06.0000] <a data-lt="Unicode serialization of an origin" data-link-type="dfn" data-link-for-hint="ForeignFetchEvent">Unicode serialization</a> [16:16:50.0000] .. [16:16:56.0000] curl -s https://api.csswg.org/bikeshed/ -F url=https://raw.githubusercontent.com/w3c/ServiceWorker/master/docs/index.bs -F output=err | xargs -0 printf [16:17:11.0000] LINK ERROR: No 'dfn' refs found for 'the worker's documents'. [16:17:11.0000] <a data-link-type="dfn" data-lt="the worker’s Documents">the worker’s Documents</a> [16:17:14.0000] LINK ERROR: No 'dfn' refs found for 'unicode serialization of an origin'. [16:17:16.0000] <a data-link-type="dfn" data-lt="Unicode serialization of an origin">Unicode serialization</a> [16:17:19.0000] LINK ERROR: No 'dfn' refs found for 'unicode serialization of an origin'. [16:17:22.0000] <a data-lt="Unicode serialization of an origin" data-link-type="dfn" data-link-for-hint="ForeignFetchEvent">Unicode serialization</a> 2017-06-11 [20:50:54.0000] MikeSmith: "Unicode serialization of an origin" was removed [20:51:08.0000] As was the worker's documents, I believe [20:51:18.0000] I thought we fixed the latter at least in service worker [22:08:52.0000] Domenic: seems like they much still be in there somewhere [22:08:56.0000] /me looks [22:09:43.0000] oh I guess by “removed” you mean, removed from HTML [22:10:04.0000] but the references still must be in the Service Workers spec [22:10:07.0000] ya [22:10:12.0000] OK [22:10:28.0000] I’ll look and try to write up a patch fixing that [22:24:11.0000] Domenic: so yeah about “the worker's documents” I see again now the patch I wrote for changing that [22:24:16.0000] https://github.com/w3c/ServiceWorker/pull/1124 [22:24:54.0000] which has just been waiting for me to make a change that jungkee requested [22:25:04.0000] so will do that [22:25:17.0000] then I’ll do that "Unicode serialization of an origin" one [22:41:58.0000] Domenic: OK https://github.com/w3c/ServiceWorker/pull/1124 righted [22:54:44.0000] Domenic: OK raised https://github.com/w3c/ServiceWorker/pull/1160 just now [23:08:33.0000] MikeSmith: FWIW, pretty sure there are open issues on both [23:08:43.0000] MikeSmith: that I filed [00:31:32.0000] annevk: Ah ok I'll update the commit messages to reference the issues [02:07:22.0000] MikeSmith: https://github.com/w3c/web-platform-tests/pull/6167#issuecomment-307442381 also shouldn't have been merged while it has the status:needs-spec-decision label [02:19:29.0000] zcorpan: oops [06:57:45.0000] the spec PR was merged, I wonder what spec decision zcorpan thought was needed [07:28:55.0000] OK well I’ll follow up with jgraham about the other thing [16:26:08.0000] hmm... jsdom/whatwg-url has a funky bug [16:26:09.0000] https://quuz.org/url/liveview.html#http://0x100000000/test [16:26:57.0000] I'm not really sure what it's doing here [16:28:09.0000] GPHemsley: indeed weird [16:28:28.0000] wonder how it ever gets there [16:28:47.0000] yeah, I don't understand why the 16 sticks around [16:28:48.0000] I mean given there’s no hash in the URL [16:29:01.0000] https://quuz.org/url/liveview.html#http://0x123456789/test [16:29:02.0000] oh I was just thinking of the hash [16:29:14.0000] oh, I'm looking at IPv4/domain parsing [16:29:25.0000] d’oh [16:29:48.0000] Anything over 0xFFFFFFFF should be IPv4 serialized as 0.0.0.0 [16:29:51.0000] ignore everything I said :) I just noticed the actual URL being tested [16:30:00.0000] now, what other functions do with that is another story [16:31:00.0000] the spec defines an IPv4 address as 32-bit, but doesn't really enforce it anywhere [16:31:07.0000] not explicitly, anyway [16:31:45.0000] IPv4 serialize doesn't even explicitly require operating on an IPv4 address [16:31:59.0000] oh wait, yes it does [16:32:08.0000] but it doesn't check that that is the case [16:32:21.0000] it just silently discards anything above 32 bits [16:32:54.0000] but from looking at the jsdom/whatwg-url code, the problem is not in the IPv4 serialize function [16:32:59.0000] as that appears to be spec-compliant [16:33:09.0000] so somewhere down the line, that 16 sticks around [16:33:22.0000] compare: https://quuz.org/url/liveview.html#http://0x10000000/test [16:33:47.0000] which is indeed 16.0.0.0 [16:44:50.0000] it seems jsdom/whatwg-url doesn't have unit tests :/ [16:57:52.0000] GPHemsley: it imports web platform tests [16:59:29.0000] yeah, but that only tests the endpoints 2017-06-12 [22:55:07.0000] JakeA: when you are around I want to ask you about what days are best for Service Workers meeting at TPAC [22:55:23.0000] I am talking with the W3C meeting planners about the schedule [22:55:44.0000] the choice is either Monday and Tuesday or Thursday and Friday [22:57:49.0000] I think the Web Components discussions are scheduled for Monday, so that suggests we should either try to get the SW room for Thursday and Friday, or else ask that the Web Components discussions be rescheduled for Thursday and Friday so that we could do Monday and Tuesday, if that turns out to be preferable [23:08:00.0000] oh, I see what the problem is here... if jsdom/whatwg-url throws a 'TypeError: Invalid URL', the Live URL Viewer doesn't blank out the other fields from the previous run, thus resulting in weird results and a likely mismatch with the browser [23:08:49.0000] I think the real problem may be that jsdom/whatwg-url is throwing at all [23:09:12.0000] "A validation error [23:09:12.0000] indicates a mismatch between input and valid input. User agents, especially conformance checkers, are encouraged to report them somewhere. " [23:09:24.0000] "A validation error does not mean that the parser terminates. Termination of a parser is always stated explicitly, e.g., through a return statement. " [23:14:26.0000] filed https://github.com/jsdom/whatwg-url/issues/92 [23:36:41.0000] igrigorik: (I figured something out for the
thing, https://bugs.chromium.org/p/chromium/issues/detail?id=728499#c9 ) [01:37:08.0000] MikeSmith: avoiding clashing with security stuff would be great too. Other than that, I don't mind which day. [01:41:59.0000] JakeA: OK [01:42:12.0000] /me checks webappsec days [01:43:17.0000] JakeA: so yeah WebAppSec meets Monday-Tuesday https://www.w3.org/2017/11/TPAC/Overview.html#Schedule [01:43:37.0000] thus I will ask for Thursday-Friday [05:28:01.0000] Domenic: MikeSmith: sorry for confusion with . I commented in the spec PR when I meant to comment in the wpt PR, and figured we should wait with merging either PR until we have heard something from mozilla folks [05:28:59.0000] ah OK [09:32:43.0000] Oh awesome zcorpan that you got Chrome to update for the
spec change. That makes me hopeful about further UA stylesheet alignment. [10:02:05.0000] Domenic: I thought blink was implementing context menu [10:02:14.0000] perhaps plans changed [10:02:21.0000] smaug: they were, then plans changed, yeah :( [10:02:37.0000] https://bugs.chromium.org/p/chromium/issues/detail?id=87553&desc=2#c64 [10:04:45.0000] If Mozilla believes this feature is valuable, maybe the right thing to do is find someone at Mozilla to move it into some other spec repo (WICG?) and keep the code... Certainly Blink implements a lot of single-vendor features via that route... 2017-06-13 [08:22:16.0000] JakeA: ping [08:23:34.0000] JakeA: is there a reason we don't exposed the "parsed" internal state as a ServiceWorkerState enum value? [08:23:45.0000] https://w3c.github.io/ServiceWorker/#dfn-state [08:29:19.0000] JakeA: I wrote a spec issue: https://github.com/w3c/ServiceWorker/issues/1162 [09:08:25.0000] If someone wants a: fast, embedded in Python, HTML parser, what should they use? Neither Gumbo nor html5ever support character encoding stuff, so I don't know what's recommendable? [11:20:16.0000] gsnedders: No idea, but presumably servo has some encoding support somehow [11:20:43.0000] so html5ever should be able to be persuaded to do something meaningful [11:43:14.0000] jgraham: https://github.com/servo/servo/issues/6414 implies not [11:45:35.0000] Maybe not then. Looks like it might be somewhat supported at least 2017-06-14 [17:27:28.0000] wow, Blink/Chrome style guidelines recommend (prohibit in some cases?) against use of `const`? because of design limitations in V8 it seems [17:29:56.0000] https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/MJhTok8Usr8/XCrkisaBBQAJ [17:30:02.0000] > In a recent CL, I was told that the DevTools still do not use const and existing usage is being removed due to V8 deoptimization concerns. [01:57:28.0000] Is it possible to have a wiki page redirect to an external url? And how do I edit the links in the sidebar? [02:38:23.0000] zcorpan: for linking to an external URL, see https://en.wikipedia.org/wiki/Wikipedia:Tutorial/Wikipedia_links#External_links_section [02:39:05.0000] for editing the sidebar, just click the "edit" link on top of the page, and locate where the sidebar is to edit it [02:39:52.0000] strupo: ideally I want the page to redirect, not just show a link [02:40:17.0000] Well, I don't know if you can do that [02:40:25.0000] ok [02:40:43.0000] It can redirect to another wiki article, but to an external URL... I don't think so. [02:42:27.0000] clicking edit gets me to https://wiki.whatwg.org/index.php?title=Main_Page&action=edit but still don't see how to edit the "Code of Conduct" link in the left-hand sidebar [02:44:50.0000] I think that's indepedent of which article you're seeing now [02:45:33.0000] maybe I don't have editInterface permission. https://www.mediawiki.org/wiki/Manual:Interface/Sidebar [02:49:01.0000] https://wiki.whatwg.org/wiki/MediaWiki:Sidebar [02:50:03.0000] zcorpan: I've made you an admin [02:50:18.0000] GPHemsley: thanks! [02:50:54.0000] there's probably some other folks around here who should have those rights [02:51:05.0000] this list seems short: https://wiki.whatwg.org/index.php?title=Special:ListUsers&group=sysop [03:53:54.0000] https://html.spec.whatwg.org/#dom-form-elements says “The elements IDL attribute must return an HTMLFormControlsCollection rooted at the form element…”. But `elements` also includes any elements outside the form whose form owner is the form (), so “rooted at the form elements” seems wrong to me. Or am I misreading it? [07:00:26.0000] annevk, Domenic, Sebmaster: Is there a particular organization to the urltestdata.json file that PRs should maintain? [07:02:49.0000] GPHemsley: no 😟 [07:04:29.0000] cool, so I'll just go willy nilly [07:09:26.0000] annevk: How about preference for # or no # in comments? [07:17:07.0000] GPHemsley: one of those for a following block is what I do [07:18:16.0000] well I added the comment string for the blocks, sure [07:18:23.0000] but some of them use a preceding # [07:18:34.0000] I opted not to, since it seems redundant [07:44:28.0000] https://github.com/w3c/web-platform-tests/pull/6238 [07:46:49.0000] GPHemsley: Out of curiosity, what's the purpose of writing "\u003E" rather than just >? [07:47:37.0000] the spec is explicit about bytes/code points, so this make it clear that they're there [07:49:06.0000] GPHemsley: But the parser won't ever see \u003E. [07:49:20.0000] I'm aware [07:49:25.0000] that's for the humans [07:49:38.0000] As a human I would rather read > than \u003E. [07:54:12.0000] and as a human, you are able to easily identify and distinguish between >›〉⟩〉? [07:54:36.0000] https://irccloud.mozilla.com/file/HNAyCCdJ/Capture%20d%E2%80%99e%CC%81cran%202017-06-14%20a%CC%80%2016.54.27.png [08:01:44.0000] uh huh, and which one is the one relevant to the test? [08:54:07.0000] GPHemsley: The first one. I wrote it just above soit was easy to distinguish it. [08:54:44.0000] I just don't see how that is an argument against a literal >, which is the obvious one. You wouldn't argue against writing a 'a' because it could be Latin or Cyrillic, would you? [08:55:48.0000] In the end, none of the tests actually show which character it is about, so as a human I have to look up the characters somewhere to know what the test is checking for. [08:56:36.0000] none of the expectations* [09:18:17.0000] I mean, I can change it if that's the consensus [09:18:22.0000] In case hasather comes back: that gives the definition of the elements IDL attribute, so since the definition says it's rooted at the form element, then no, elements cannot contain any elements outside the form. [09:18:48.0000] but I did it deliberately to highlight what it was testing: "If byte is less than 0x21 (!), greater than 0x7E (~), or is 0x22 ("), 0x23 (#), 0x3C (<), or 0x3E (>), append byte, percent encoded, to url’s query. " [09:18:49.0000] GPHemsley: nox: my opinion is it's up to the test author; I try not to let stylistic things get in the way of making authoring tests easy. [09:19:13.0000] Would be nice to give these tests a name then. [09:19:47.0000] 'Percent-encoded query and fragment' is the name [10:57:55.0000] hsivonen: I'm willing to devote some time to helping you land WPTs for encoding (including r12a's tests) if you can provide all the domain expertise. E.g. if you want to provide diffs to r12a's pull requests I can apply them and press the merge button. [11:47:16.0000] Domenic, hsivonen: I can also spend some time reviewing them or changes to them, but last I looked I got lost in complexity [14:16:22.0000] tobie: https://github.com/heycam/webidl/pull/323 is ready to merge BTW :) [14:18:42.0000] Domenic: yeah, I got started on adding tests for it and wanted to land both together, but the testing tool a little longer than expected. [14:18:58.0000] Domenic: https://github.com/w3c/web-platform-tests/pull/6246 [16:49:22.0000] https://html.spec.whatwg.org/multipage/semantics.html#attr-link-as [16:49:32.0000] doesn't that mean that .as can be "featch" [16:55:36.0000] smaug: no. https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:enumerated-attribute [16:56:05.0000] so? [16:56:32.0000] "A potential destination is "fetch" or a destination which is not the empty string. " [16:56:42.0000] er [16:56:47.0000] fetch [16:56:57.0000] that was typo, fetch, not featch [16:57:04.0000] oh. Then yes. [16:57:31.0000] just reviewing some code and for some reason it returned "" when content attribute was "fetch" 2017-06-15 [18:46:55.0000] oy, what a bulky test suite this is [23:45:14.0000] a quick question -- how does a XHR interact with the content-disposition:attachemnt response header? [23:46:49.0000] /me XhmikosR howdy [02:45:29.0000] Any folks from React here? [02:47:01.0000] Domenic, gsnedders: https://github.com/whatwg/encoding/issues/57#issuecomment-308654813 indicates we should wait for r12a to address my claims of test suite bugs [02:47:28.0000] Domenic: I commented LGTM to merge EUC-KR, Shift_JIS and Big5 tests [02:47:32.0000] Domenic: thanks [06:04:52.0000] #join #react [06:04:57.0000] oops [09:44:45.0000] Twitter does not like square logos anymore... https://twitter.com/storagestandard [09:57:47.0000] Domenic: Hey. I saw http://logs.glob.uno/?c=freenode%23whatwg&s=14+Jun+2017&e=14+Jun+2017#c1030325 `elements` does include form controls outside of the form though, test e.g. data:text/html,
[09:58:17.0000] is the spec wrong there? (The original question was http://logs.glob.uno/?c=freenode%23whatwg&s=14+Jun+2017&e=14+Jun+2017#c1030301) [10:08:38.0000] hasather: well, it looks like it's an interop issue; Edge at least gives 0 for that test case, although FIrefox and Chrome do give 1. Would you mind opening a spec bug so we can collect opinions from implementers? [10:15:57.0000] Domenic: Edge doesn't support the 'form' attribute yet, see https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/7327649-add-support-for-the-form-attribute. I'll file a bug on the spec. Thanks. [10:16:16.0000] Domenic: Actually noticed this when implementing the 'form' attribute in jsdom. :) [10:16:45.0000] oh i see :) [10:22:53.0000] Domenic: for the big5 PR - ping me when the CI finishes if I don't notice first [10:23:40.0000] jsbell: sounds good, will do [10:32:37.0000] Domenic: https://github.com/whatwg/html/issues/2764 [10:39:45.0000] hasather: awesome, will look into it [12:53:14.0000] hsivonen: if the numbers at https://travis-ci.org/w3c/web-platform-tests/builds/243381522 are any indication, good job on encoding_rs performance, FF nightly is taking like 3/5 of the time of Safari and Chrome [12:55:34.0000] (Although using Travis for perf comparison is probably dubious, given how it's subject to fluctuating cloud resources) [13:40:56.0000] jsbell: https://github.com/w3c/web-platform-tests/pull/6254 ready for review [14:07:16.0000] Domenic: is it safe to use async functions in WPT now? [14:07:30.0000] wanderview: yes, although Servo folks might be sad. [14:07:58.0000] Domenic: if spidermonkey has async functions, won't servo have them too? [14:08:15.0000] wanderview: servo updates spidermonkey rarely, if ever... [14:08:31.0000] Domenic: well, they can remedy it if they want then [14:08:40.0000] Indeed [14:08:52.0000] They might be sad, but it's not a blocker [14:08:57.0000] Domenic: no one is going to want to run this test anyway [14:09:11.0000] /me is testing about:blank replacement interaction with service workers. [14:09:49.0000] good times [15:11:44.0000] Do folks have a favorite Jabber client? It looks like that's what the IETF uses... [15:14:13.0000] I used to use Trillian, but I can't imagine it's kept up with the times... [16:08:14.0000] Domenic: done [16:11:51.0000] Domenic: thanks for picking the tests up! [16:17:03.0000] :) they just seemed so close, and it was a shame to let them languish 2017-06-16 [17:28:11.0000] Domenic: Hey, did jsdom/whatwg-url pass all those new tests? [17:29:11.0000] GPHemsley: yep [17:29:16.0000] cool [17:29:30.0000] https://github.com/jsdom/whatwg-url/commit/e6c485ee0f516ca2467fc87e0d240d8363a2cb8a [17:31:05.0000] oh, very nice [17:32:13.0000] Domenic: I assume you are aware of this but are not using it because of the commit hash thing? http://w3c-test.org/url/urltestdata.json [17:32:22.0000] GPHemsley: yeah [17:32:27.0000] k [17:32:39.0000] I was doing it the same way you were, link-wise, and then I found that [17:42:19.0000] Yeah, seems important to check in a last-known-passing revision if I want new contributors to get a passing `npm test` on checkout [04:23:54.0000] Domenic: thanks. for Web workloads, encoding_rs decodes faster than ICU [04:24:44.0000] Domenic: I haven't had the time to extract the non-ICU UTF-8 and windows-1252 decoders from Blink or WebKit to test those in isolation [04:25:19.0000] Domenic: however, with TextDecoder, the overhead in Firefox and Chrome is pretty bad [04:25:41.0000] Domenic: in Firefox can be larger than the time spent in the decoder [04:26:03.0000] Domenic: I'd estimate that to be the case for Chrome, too [07:10:49.0000] MikeSmith: Is it possible to *not* have the TPAC service worker meeting on Monday? [07:43:54.0000] JakeA: you mean only have it one day? [07:44:17.0000] MikeSmith: Was the current plan to have it on Monday & Tuesday? [07:45:16.0000] it is now, because the W3C meeting planners have been trying to fit everything together, and that it where it ended up [07:46:00.0000] partly because the shadow DOM and custom elements meetings are now scheduled for Thursday and Friday [07:46:32.0000] and that seemed like the main thing we did not want to conflict with [07:46:56.0000] Ok, I'll check to see if we need both days & get back to you [07:47:26.0000] Our usual meetings are two days, but we only had one day at the last TPAC [07:47:38.0000] OK [08:48:23.0000] MikeSmith: Yeah, let's just do the Tuesday [08:48:33.0000] We'll ad-hoc more if we need to [09:24:40.0000] So according to the fetch spec here, for "To append:" https://fetch.spec.whatwg.org/#terminology-headers - it would seem that if header 'x-foo' already exists, and I want to append 'X-Foo': 'bar', my `header list` would end up with both, ala: { 'x-foo': 'bar', 'X-Foo': 'bar' } ... can that possibly be the spec here or am I misunderstanding? [09:25:25.0000] Nope, I realized I misread the moment after I typed that out heh... my bad, ty [10:35:11.0000] JakeA: OK [11:33:30.0000] Hmm is whatwg.org down right now? [11:51:12.0000] domfarolino: its down for me :( [12:31:49.0000] blehhhhhh [12:32:11.0000] crack team of sysadmins alerted [12:53:42.0000] Domenic: is what.org down or something ? [12:53:51.0000] Apparently, see above... [12:54:07.0000] /me looks at the logs [12:56:58.0000] Server is sshable, probably a Dreamhost problem :-/ [13:01:24.0000] Back [13:04:26.0000] :) [15:37:17.0000] Domenic: quite happy I'm actually implementing tests for [Default] toJSON() in idlharness. Helped uncover some corner cases around supplemental interfaces I wasn't aware of. [15:38:33.0000] Domenic: in you add an interface J to https://s3.amazonaws.com/pr-preview/tobie/webidl/tojson.html#example-tojson-default-inheritance-and-mixins, and have `H implements J`, then that also gets accounted for with the current algorithm. [15:39:42.0000] Domenic: I'm not too sure if that's a feature, a bug, or something we shouldn't care about until we add mixins [15:41:58.0000] Domenic: (I'm tempted to wait for mixins) [15:47:33.0000] Heh, yeah... a feature I guess, but not something to worry about [15:54:02.0000] Domenic: Think I'll be tackling mixins next, actually. [16:38:38.0000] tobie: Does WebIDL support comparing dictionaries for equivalence? [16:39:49.0000] I don't see anything to that effect in https://heycam.github.io/webidl/#idl-dictionaries , but it may be defined elsewhere [16:42:36.0000] I guess that's not hard to express in English, though. Maybe I can just write "If the value of each member of dictionary A is the same as the value of the corresponding member of dictionary B [...]" [16:42:44.0000] jugglinmike: dictionaries aren't distinguishable, see https://heycam.github.io/webidl/#dfn-distinguishable [16:43:09.0000] jugglinmike: so what's your use case? [16:45:03.0000] I'm working on a spec (Permissions) that supports "pending" operations, each associated with a dictionary. I would like to target that operation from another algorithm [16:46:13.0000] oh, you can use infra notation to help with this [16:47:00.0000] Happy to educate myself. Could you point me in the right direction? [16:49:37.0000] jugglinmike: https://infra.spec.whatwg.org/#maps (as described just below https://heycam.github.io/webidl/#ref-for-dfn-dictionary-member-default-value-2) [16:49:46.0000] (was looking for the links) [16:50:09.0000] jugglinmike: but you'll have to resort to prose [16:52:25.0000] got it [16:52:26.0000] thanks! 2017-06-17 [09:15:24.0000] so... who logged in to @mimesniff yesterday? [09:30:50.0000] GPHemsley: that was me; was testing stuff to try to fix https://github.com/whatwg/meta/issues/28 [09:31:32.0000] /me grumbles something about Twitter circular icons [13:45:46.0000] does web-platform-tests have any tests for "state override" or "encoding override"? [13:46:00.0000] (in the URL parser) [13:50:59.0000] GPHemsley: yeah, the setter tests [13:51:04.0000] for "state override" [13:51:06.0000] Not sure about encoding... [13:51:54.0000] I guess these test encoding https://github.com/w3c/web-platform-tests/blob/master/encoding/legacy-mb-japanese/shift_jis/sjis-encode-href-errors-han.html [13:52:14.0000] And https://github.com/w3c/web-platform-tests/blob/master/encoding/legacy-mb-japanese/shift_jis/sjis-encode-href.html [13:56:20.0000] hmm, ok [13:56:54.0000] any idea which parts of the HTML spec use these parameters? [13:57:10.0000] "The encoding override argument is a legacy concept only relevant for HTML. The url and state override arguments are only for use by various APIs." [13:57:37.0000] I guess that might be an easy search in HTML [13:59:48.0000] ooh, the toascii.json is gonna be important [13:59:56.0000] I'm having trouble with my UTS46 library [14:19:12.0000] Yeah we don't have that working in jsdom/whatwg-url yet either [14:19:28.0000] But someone did a massive PR that should help https://github.com/Sebmaster/tr46.js/pull/11 [16:07:41.0000] Domenic: That's cool; my problem is that the upstream Perl library hasn't been particularly respondent to my PR. I may decide to rewrite from scratch instead. :/ [16:10:43.0000] ...and now I need to figure out why I didn't get an e-mail about your comment on the related whatwg/url ticket [16:13:01.0000] hmm... I wonder if it has anything to do with the fact that it's a closed ticket [16:15:20.0000] TIL GitHub has a concept of Projects [16:15:40.0000] AKA Kanban boards [16:30:02.0000] hmm, it does appear that the notifications stopped after the ticket was closed [16:30:03.0000] odd [16:30:13.0000] that sounds like a GitHub bug [16:33:34.0000] ..took a little bit to come, so now I'm just confused 2017-06-18 [19:54:17.0000] oh, here's a question... are validation errors ever used by anybody? [19:54:43.0000] by which I mean, do they have an effect on web compatibility or anything of that nature? [20:29:12.0000] I have a question about WebIDL and constructors... does an interface not have a constructor unless you explicitly say it does? how do you initialize an interface without a constructor? [20:40:47.0000] is it a matter of `Foo()` vs. `new Foo()`? [20:41:22.0000] I see the dependence on ECMAScript gets stronger the deeper you go [03:28:33.0000] Sorry for the silly question but what's the official opinion about why WHATWG calls it "URL" and not URI? [03:43:16.0000] GPHemsley: interfaces don't have a constructor unless you specify one using the constructor extended attribute [03:43:52.0000] GPHemsley: so calling both Foo() and new Foo() will throw a TypeError in that case [03:46:05.0000] GPHemsley: see step 1.1 of the algorithm described in https://heycam.github.io/webidl/#interface-object [03:46:24.0000] profsimm: The distinction between URL/URI/IRI is not useful in practice and is confusing, and URL is the term that almost everyone in the world uses so it seemed best to standardise on that one [03:47:15.0000] Philip`: thanks [03:47:27.0000] profsimm: See e.g. https://url.spec.whatwg.org/#goals [03:47:52.0000] profsimm: (Also it's what I remember from discussions on the mailing lists like a decade ago) [03:48:00.0000] GPHemsley: Note that as per step 1.2 of the same algorithm, Foo() (without the new constructor) throws in all cases. [03:49:14.0000] GPHemsley: that is, even when a Constructor extended attribute is present. [04:14:50.0000] Philip`: is WHATWG the HTML spec which browsers follow most closely? [04:14:55.0000] Philip`: compared to W3C [04:26:00.0000] profsimm: yes [04:26:46.0000] gsnedders: aren't browser makers involved in W3C as well? [04:28:41.0000] profsimm: not with the HTML specification; it was merged into a larger WG to try and get them involved they haven't [08:07:18.0000] tobie: Thanks for clarifying. :) [08:17:38.0000] GPHemsley: np. [08:22:05.0000] tobie: Do you know where the semantics of getters and setters are defined? Is that in WebIDL or ECMAScript or somewhere else? [08:22:21.0000] DOM, maybe? [08:22:56.0000] oh wait, I think I found them [09:51:26.0000] GPHemsley: WebIDL and ES [09:51:36.0000] GPHemsley: depending on what getters and setters you're talking about [13:31:18.0000] gsnedders: Ultimately, I just wanted to know if setters return the new value of the attribute, and it seems the answer is yes. [13:37:35.0000] GPHemsley: that would be the normal ES behaviour, and I don't think it can be avoided [13:44:26.0000] gsnedders: I wasn't trying to avoid it, I was trying to replicate it. [13:46:14.0000] GPHemsley: I just mean I think it falls from the definition of the = operator in ES [13:46:38.0000] well I'm not implementing ES, and some things take ES behavior for granted [13:46:47.0000] so I was just trying to approximate 2017-06-19 [00:55:09.0000] TabAtkins: When some spec says && , unless stated otherwise the serialisation by default should be , right? [00:57:15.0000] TabAtkins: Asking because https://drafts.fxtf.org/filters/#funcdef-filter-drop-shadow says {2,3} ?, but every UA I tried serialises the colour first. [02:12:12.0000] TabAtkins: getting long delays for responses from https://drafts.csswg.org/ [02:14:09.0000] on the order of 20 seconds just to get the start of the response [02:14:45.0000] before the content even can begin loading [02:21:45.0000] wondering if maybe it has some rate limiting in place and I’m getting tarpitted [07:51:00.0000] nox: Yes to your first question. But to your second question, there's no && in there; putting a color first shouldn't even parse, per spec. [07:51:11.0000] TabAtkins: Oh right. [07:51:32.0000] MikeSmith: Hmm, dunno about that. plinss is the one to bug, tho. [07:51:40.0000] TabAtkins: What happens I think is that both UA probably just parse that stuff like box-shadow and then reject values with inset and spread. [07:51:48.0000] Probably, yeah. [07:51:57.0000] TabAtkins: But I think the spec should say '&&', because they both serialise the color first. [07:52:06.0000] TabAtkins: Should I file an issue? [07:52:11.0000] yes plz [07:52:20.0000] TabAtkins: Will do. [07:52:27.0000] TabAtkins: Another question: [07:52:41.0000] TabAtkins: with , calc(10 + 10%) should be allowed, right? [07:52:50.0000] Yup. [07:52:53.0000] Oh wait. [07:53:09.0000] As opposed to | . [07:53:20.0000] No, we just disallowed that. I need to go edit some things. [07:53:26.0000] Ok. [07:53:34.0000] TabAtkins: Are all such mixing disallowed except for , now? [07:53:35.0000] (Required to be disallowed to make calc unit algebra work sanely.) [07:53:43.0000] No, all units are fine. [07:53:50.0000] Just number+percent that's problematic. [07:53:51.0000] But no browsers care, right? [07:54:05.0000] Nobody implements a number+percent calc yet, no. [07:54:11.0000] I haven't seen anything allow calc(10s + 10%) or angles or whatever else but lengths. [07:54:32.0000] Uh, probably so. [07:54:41.0000] Don't remember any off the top of my head. [13:33:00.0000] Bikeshed question here: when I write `[=fetch/status=]`, Bikeshed complains: [13:33:01.0000] LINK ERROR: No 'dfn' refs found for 'status' with for='fetch'. [13:33:02.0000] status [13:33:47.0000] but when I run `bikeshed refs --spec fetch --text status` [13:34:02.0000] the results include: [13:34:03.0000] status: current [13:34:04.0000] for: [] [13:34:04.0000] level: 1 [13:34:04.0000] url: https://fetch.spec.whatwg.org/#concept-status [13:34:04.0000] type: dfn [13:34:04.0000] export: True [13:34:05.0000] text: status [13:34:05.0000] shortname: fetch [13:34:06.0000] normative: True [13:34:06.0000] spec: fetch [13:34:28.0000] TabAtkins: or maybe Domenic: do you know what I'm doing wrong there? ^ [13:34:56.0000] Yeah, that definition is "for" nothing. You're trying to specify the *spec* it's from, which can't be done in the shorthand. [13:35:21.0000] (In [=foo/bar=], it's equivalent to bar.) [13:36:16.0000] Does that mean this patch is incorrect? https://github.com/w3c/ServiceWorker/pull/1144/files [13:36:42.0000] I don't understand the relevance of that patch. [13:37:31.0000] Isn't status supposed to be for a response, anyway? [13:37:34.0000] Not a fetch? [13:38:10.0000] Oh, sorry. That patch is using "WorkerGlobalScope", not the name of a spec [13:38:54.0000] Domenic: Yeah, I think that definition could do with a for value in the spec. A bare "status" is kinda hard to link to. [13:39:08.0000] I think it has one in the spec [13:39:22.0000] This is the text that was confusing me: https://github.com/w3c/ServiceWorker/blob/fa1f95c41523b7cc8de65d2ec24edb43bf9f5cc3/docs/index.bs#L2009 [13:39:27.0000] Domenic: It does not. [13:39:31.0000] Oh, well, it depends on if you're linking to the status *type* or the property of a response [13:39:49.0000] https://fetch.spec.whatwg.org/#concept-status vs. https://fetch.spec.whatwg.org/#concept-response-status [13:40:07.0000] It's the latter that I want, actually [13:40:10.0000] jugglinmike: Yeah, that's linking to the "terminate a fetch" definition, which is for=fetch. Unrelated to being in the Fetch spec. [13:40:17.0000] got it [13:40:18.0000] Yeah, then just [=response/status=] [13:40:58.0000] Domenic: The other status should still have a for value. Like for=http or something? [13:41:10.0000] Perfect! Thanks to you both [13:41:13.0000] Yeah, maybe. Unsure why disambiguating by spec is insufficient though [13:41:26.0000] It's sufficient, but it's hard to do so in Bikeshed's syntax. ^_^ [13:41:51.0000] (And then you'd still need to *also* disambiguate by for value, since there are multiple "status" dfns in the spec.) [13:43:27.0000] Well, not if you use the explicit for switch ^_^ [13:43:45.0000] Okay sure, but only you two weirdos use that. ^_^ [13:54:07.0000] Hello. My script is running in context of webpage say http://xyz.com. I make an xhr request to http://media.xyz.com/a.mp4 but it fails. Why is that? [13:54:21.0000] That's a different domain. [13:54:30.0000] (And thus, CORS applies.) [13:54:41.0000] I am trying to understand why that fails and why does