| 02:07 | <Domenic> | TabAtkins: I think Bikeshed updates have broken things |
| 02:08 | <Domenic> | CI is failing for infra and console with 400 bad request |
| 03:10 | <TabAtkins> | Weird! Will check as soon as I get in tomorrow, sorry for the inconvenience. |
| 08:53 | <kochi> | I'm trying to run bikeshed locally on Linux, against whatwg dom spec: |
| 08:53 | <kochi> | FATAL ERROR: IDL SYNTAX ERROR LINE: 3 - skipped: "attribute [TreatNullAs=EmptyString] DOMString data" |
| 08:54 | <Ms2ger> | Have you tried updating? |
| 08:55 | <kochi> | This seems to be for CharacterData.data |
| 08:55 | <kochi> | Ms2ger: do you mean "bikeshed update" |
| 08:55 | <kochi> | ? |
| 08:55 | <Ms2ger> | I think so |
| 08:55 | <kochi> | trying... |
| 08:55 | Ms2ger | hasn't used bikeshed for a while |
| 08:56 | <kochi> | I once used, but me neither |
| 08:56 | <kochi> | "bikeshed update" doesn't help :( |
| 09:05 | <sangwhan> | If you pip install -e'ed it, think git pull in the local bikeshed checkout should do |
| 09:05 | <sangwhan> | Oh right, that won't fix the references, only the source.. |
| 10:11 | <annevk> | Redesign of whatwg.org home page, if you care comment here: https://github.com/whatwg/whatwg.org/pull/90 |
| 10:13 | <jgraham> | Is emailing Hixie really still a thing? |
| 10:13 | <jgraham> | I should comment on the bug… |
| 10:14 | <annevk> | jgraham: yeah it is, but I don't think he gets many media requests if at all |
| 10:24 | <kochi> | will retry if bikeshed is not up-to-date. |
| 10:25 | <kochi> | ^^ will retry fresh reinstall bikeshed, and do all over again. |
| 10:55 | <kochi> | hmm, got another python error - which might be python version thing. I'll try on Mac next... |
| 14:15 | <annevk> | kochi: FWIW, for delegatesFocus wouldn't we want to define that in HTML as an extension of sorts? |
| 14:15 | <annevk> | kochi: I guess it doesn't matter much, but DOM wouldn't really define behavior for it, seems weird to just define the API |
| 14:15 | <annevk> | kochi: as for bikeshed errors, you can just create a PR |
| 14:16 | <annevk> | kochi: that should create a preview for you (will be added as a link in the first comment of the PR after some time) |
| 14:17 | <deyomax> | Can I read someone why the WHATWG URL API chose terms like "url.search" "url.hash" instead of "url.query" and "url.fragment"? |
| 14:18 | <kochi> | annevk: I thought I would add a "delegatesFocus" in ShadowRootInit IDL (in DOM), and refer to it in HTML - but defining it as "partial interface ShadowRootInit { ... }" in HTML also work? |
| 14:21 | <kochi> | annevk: as to "FATAL ERROR: IDL SYNTAX ERROR ..." I might have used bikeshed that I installed long time ago, and I'm not able to reproduce so I'll retry in fresh environment. |
| 14:30 | <annevk> | deyomax: seemed better to stick with terms that were already used for Location and <a>/<area> |
| 14:30 | <annevk> | kochi: yeah, partial should work |
| 14:30 | <deyomax> | annevk: I see. But it's a bit odd when the spec seemingly has two minds about it "the url.hash contains the URL fragment" |
| 14:31 | <deyomax> | annevk: it's referred to as a fragment :) |
| 14:31 | <annevk> | deyomax: that's true, I wasn't really brave enough to deviate from the RFC terminology for the underlying concepts |
| 14:32 | <annevk> | deyomax: but they're also subtly different so it seems okay |
| 14:32 | <annevk> | deyomax: protocol always has a ":" for instance, but scheme doesn't |
| 14:38 | <deyomax> | annevk: interesting |
| 14:39 | <deyomax> | annevk: thank you |
| 14:39 | <deyomax> | annevk: btw does WHATWG see the "everything is URL" as a purely WHATWG internal terminology, or as something they wish the world used at large? |
| 14:42 | <annevk> | deyomax: the latter |
| 14:42 | <gsnedders> | (though it's largely just reflecting current usage, so not so much a wish) |
| 14:44 | <deyomax> | Thanks folks! |
| 15:05 | <annevk> | JakeA: should I look at the Fetch patch again tomorrow or are you waiting for Domenic? |
| 15:19 | <deyomax> | annevk: there's something that's bothered me a little about URL, it parses "data:text/plain,foo?bar#baz" as path "text/plain,foo" search "?bar" and hash "#baz" but then when data URL is decoded the entirety of this content is taken into account "foo?bar#baz". IETF says this with non-hierarchical URLs, the path is the entire thing without the scheme, ie. "text/plain,foo?bar#baz". |
| 15:20 | <deyomax> | annevk: now one might think "easy, just recombine the parts before you parse" but that also doesn't work because in the following data URL: "data:,x?#" the search and hash fields are empty, so the reconstructed content would be ",x" instead of ",x?#" |
| 15:20 | <deyomax> | I'm curious what you think :) |
| 15:26 | <JakeA> | annevk: it's ready for anyone to review afaik. Sorry it's gotten to vast & tough to go through |
| 17:37 | <TabAtkins> | Domenic: Fix applied to stop DOM/etc from dying. (All the WHATWG specs, because they all use the Complain About metadata, which is what was breaking. I'm adding tests for that now.) |
| 18:05 | <annevk> | deyomax: https://github.com/whatwg/fetch/pull/579 |
| 18:06 | <annevk> | deyomax: in particular fragments are not part of the content, not even in the IETF RFCs |
| 18:06 | <deyomax> | annevk: this doesn't match real-world behavior in any browser though |
| 18:06 | <annevk> | deyomax: and although hard to reproduce with the API other than looking at the serialization, the internal representation does store the nuance of ? being present or not |
| 18:06 | <annevk> | deyomax: sounds like you didn't test in all browsers |
| 18:07 | <annevk> | deyomax: and same for #; there was some hasSearch/hasHash idea, but it hasn't happened yet, I still think it might be worthwhile to add at some point |
| 18:08 | <annevk> | JakeA: okay, will go through again tomorrow (and yeah, the patch is a little daunting at this point, but not sure what can be done about that) |
| 18:10 | <deyomax> | annevk: well storing it internally is not helpful when it's not exposed :P |
| 18:13 | <deyomax> | annevk: well I'm not even more confused. Firefox ignores the fragment, Chrome doesn't. In Edge it's hard to test. And MDN says "nothing interrupts the data stream" implying also fragment |
| 18:13 | <deyomax> | now* |
| 18:20 | <deyomax> | annevk: the IETF RFC doesn't seem clear what happens with # in the data segment. It says "data is urlchar from RFC 2396" and that RFC has no such term anywhere |
| 18:21 | <deyomax> | Ah it's called "uric", ok. |
| 18:21 | <annevk> | Hopefully someone else can help, back tomorrow |
| 18:21 | <deyomax> | Doesn't include ? and #, but also that's not an up-to-date RFC for URIs |
| 18:22 | <deyomax> | :( |
| 18:22 | <deyomax> | Goodbye |
| 18:32 | <deyomax> | So now I don't even know if "data:" URL must respect the fragment or not. |
| 21:07 | <MikeSmith> | beverloo: about the behavior at https://stackoverflow.com/questions/37991514/notification-api-always-returnning-denied-chrome/37991695#37991695, is that documented anywhere? |
| 21:10 | <MikeSmith> | beverloo: I mean specifically, “Notification permission is silently denied from file:// URLs. |
| 21:12 | <MikeSmith> | beverloo: that assertion seems to be true, in that I find I can observe the same behavior with any simple notifications case I try to load as file:// locaally |
| 21:13 | <MikeSmith> | but I can’t find anywhere this is documented for Chrome, nor can I understand what the rationale might be for not logging some error to the console in that case, and instead just “silently” failing it |
| 21:30 | <deyomax> | MikeSmith: one thing I've learned about browsers and the web is that not even half of what we use every day is standardized and documented |
| 21:34 | <MikeSmith> | deyomax: see the last part of the channel topic :) |
| 21:34 | <MikeSmith> | if you want logic and consistency, you won’t get that from the web runtime |
| 21:37 | <deyomax> | MikeSmith: it's quite fascinating it still works though |
| 21:42 | <MikeSmith> | deyomax: indeed |
| 21:42 | <MikeSmith> | kind of amazing |
| 21:42 | <MikeSmith> | anyway, I think the Servo project is proof that we are getting better |
| 21:42 | <MikeSmith> | as far as having more of it standardized and documented |
| 21:44 | <MikeSmith> | because 10 years writing a new browser engine would not have been possible without reverse-engineering all over the place |
| 21:45 | <MikeSmith> | because back then, entire giant swathes of what browser engines were doing was still completely undocumented, unspecified |
| 21:45 | <deyomax> | MikeSmith: isn't Servo written by people who are quite familiar with browser engines? |
| 21:45 | <MikeSmith> | sure |
| 21:45 | <MikeSmith> | but they are working from specs |
| 21:45 | <deyomax> | Are they :)? |
| 21:45 | <MikeSmith> | hah |
| 21:45 | <MikeSmith> | good quesiton |
| 21:45 | <deyomax> | Maybe to some degree, but... |
| 21:45 | <MikeSmith> | well you can ask nox to how much degree |
| 21:46 | <deyomax> | There are so many things undocumented. Say it's not documented ANYWHERE I could find, how does a server determine if a form field is a file or not a file. And especially if it's a file field... but left empty |
| 21:46 | <MikeSmith> | but I know their M.O. is to work from specs |
| 21:46 | <MikeSmith> | dunno about that particular one |
| 21:46 | <nox> | We are. |
| 21:47 | <gsnedders> | there's also plenty of people around Servo with no background in browsers |
| 21:47 | <MikeSmith> | deyomax: there you go. from god’s lips to your ears |
| 21:47 | <MikeSmith> | that’s both jesus and the holy ghost speaking to you |
| 21:47 | <deyomax> | And what I kept finding is browser bugs being filed when a given engine accidentally has a regression bug related to file fields. Where the browser would change something, follow spec, but break half the servers out there. |
| 21:48 | <deyomax> | Say Firefox for the last 12 or so years keeps regressing the file upload functionality every 4-5 years, releases a broken build and then they fix it |
| 21:48 | <deyomax> | Because it's not documented anywhere. |
| 21:48 | <deyomax> | It's kind of funny :) |
| 21:49 | <MikeSmith> | yeah, laugh to keep from crying |
| 21:49 | <MikeSmith> | deyomax: anyway about specific question like, “how does a server determine if a form field is a file or not a file?”, please raise spec issues at https://github.com/whatwg/html/ |
| 21:49 | <MikeSmith> | best case by doing that, you find out you are wrong |
| 21:50 | <MikeSmith> | I mean, somebody replies to put out that in fact it is documented |
| 21:50 | <MikeSmith> | specified |
| 21:50 | <MikeSmith> | even though often the spec for it may be arcane and hard to follow unless you are actually implementing it |
| 21:50 | <MikeSmith> | and worst case, somebody replies to say, you’re right, we need to document that |
| 21:51 | <MikeSmith> | so it is win-win |
| 21:51 | <MikeSmith> | *we need to specify that |
| 21:51 | <MikeSmith> | well you know what I mean in this context, as far a *documenting* vs *specifying* |
| 21:52 | <MikeSmith> | I mean because for features that are already implemented, those two words amount to the same thing |
| 21:53 | <MikeSmith> | anyway, on today’s good-news report, about my notifications question, I did find where it’s “documented” |
| 21:53 | <MikeSmith> | for a different definition of that word |
| 21:53 | <MikeSmith> | https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/modules/notifications/Notification.cpp#378 |
| 21:53 | <MikeSmith> | String Notification::permission(ExecutionContext* context) { |
| 21:53 | <MikeSmith> | // Permission is always denied for insecure contexts. Skip the sync IPC call. |
| 21:53 | <MikeSmith> | if (!context->IsSecureContext()) |
| 21:53 | <MikeSmith> | return PermissionString(mojom::blink::PermissionStatus::DENIED); |
| 22:08 | <deyomax> | MikeSmith: filed an issue https://github.com/whatwg/html/issues/3040 |
| 22:09 | <deyomax> | MikeSmith: ah yeah, documented in source :P the most reliable documentation |
| 22:09 | <MikeSmith> | deyomax: thanks for raising that issue |
| 22:09 | <MikeSmith> | you’re a good citizen |
| 22:09 | <deyomax> | As the old joke goes "the software works as d̶o̶c̶u̶m̶e̶n̶t̶e̶d̶ implemented" |
| 22:10 | <MikeSmith> | heh |
| 22:17 | <nox> | deyomax: Yeah never worked on a browser before working on Servo. |
| 22:17 | <deyomax> | nox: how easy to you find it to understand the specs and then understand the *exceptions* to the specs after some real website testing ;-)? |
| 22:18 | <nox> | deyomax: We file issues and let specs people sort it out with other UA makers, and often participate to the discussions ourselves. |
| 22:19 | <nox> | deyomax: AFAIK we are in a way better place than years ago. |
| 22:19 | <deyomax> | You know, I don't understand why W3C couldn't achieve what WHATWG is achieving. I thought the major UA makers participate in W3C - it's the same people no? Mostly? |
| 22:20 | <deyomax> | Is it just the reduced formality of it? The GitHub environment? |
| 22:21 | <nox> | I don't know and to be honest, I don't really care, as long as what we are doing now is working. |
| 22:27 | <jyasskin> | MikeSmith: Your Notifications/file: thing is probably https://github.com/whatwg/notifications/issues/93 then. |
| 22:27 | <MikeSmith> | jyasskin: looking now |
| 22:27 | <MikeSmith> | so yeah I think so at first too |
| 22:28 | <MikeSmith> | but the thing is, this has been the behavior since before beverloo made the change about |
| 22:28 | <MikeSmith> | I misspoke a bit here earler |
| 22:28 | <MikeSmith> | *earlier |
| 22:29 | <MikeSmith> | that code I cited is the current code in the trunk |
| 22:29 | <MikeSmith> | but this behavior was happening before beverloo added that code |
| 22:29 | <MikeSmith> | like, in Chrome 60 and before |
| 22:29 | <jyasskin> | Mm, so it was blocked on files (maybe all unique origins?) before the secure-context restriction was added. |
| 22:29 | <MikeSmith> | right |
| 22:29 | <MikeSmith> | yup |
| 22:30 | <MikeSmith> | as far as I can see |
| 22:31 | <MikeSmith> | but am still investigating and testing |
| 22:32 | <jyasskin> | Still, restricting to secure contexts is probably the right spec fix to cover that, even if the sin was older. |
| 22:53 | <MikeSmith> | jyasskin: yes |
| 22:56 | <MikeSmith> | but as far as the behavior I’m seeing for this file:// case, I actually get back the permission string "granted" from Notification.requestPermission() |
| 22:57 | <MikeSmith> | and then if I call new Notification(), I do get a Notification object back without Chrome throwing |
| 22:57 | <MikeSmith> | but the actual notification is never shown |
| 23:40 | <gsnedders> | deyomax: politics. some of it politics 13 years ago. |
| 23:47 | <deyomax> | MikeSmith: remember you said "either you'll learn it's in the spec, or help improve the spec" |
| 23:47 | <deyomax> | MikeSmith: unfortunately there's a third option "WHATWG worker will point to an irrelevant part of the spec, and say it's covered by the spec" :P |
| 23:50 | <Domenic> | Gee, thanks |
| 23:50 | <Domenic> | Probably I should have just ignored the issue |
| 23:51 | <Domenic> | Instead of trying to help you |
| 23:59 | <deyomax> | Domenic: you're not helping me, you're preventing me from helping improve the WHATWG spec :P |