| 00:05 | <MikeSmith> | Domenic: oof will try restarting |
| 00:11 | <MikeSmith> | Domenic: botie is alive again |
| 00:11 | <Domenic> | \o/ |
| 00:11 | <Domenic> | In the meantime I have resorted to GitHub pinging |
| 00:12 | <Domenic> | (https://github.com/whatwg/html/pull/2332 is the context for the record) |
| 00:13 | <MikeSmith> | "predecoding" really rolls off the tongue |
| 06:29 | <MikeSmith> | fucking hell the wiki is doing the “A database query error has occurred. This may indicate a bug in the software.” thing to me again |
| 06:31 | <MikeSmith> | in any browser so it’s got to be some misguided IP-blocking thing |
| 07:01 | <annevk> | MikeSmith: works here, sigh |
| 07:04 | <MikeSmith> | annevk: yeah not sure what triggers it but the only solution just seems to be to wait for it to unblock |
| 07:21 | <annevk> | MikeSmith: maybe time to move more stuff to whatwg.org and get that autopublished |
| 07:22 | <annevk> | MikeSmith: it's ready to go, just need to coordinate with Ian |
| 07:58 | <MikeSmith> | annevk: yeah thanks for getting all that prepared, I think it will work out a lot better |
| 09:04 | <annevk> | public-webappsec is slowly sliding towards not having any meaningful discourse either |
| 09:33 | <zcorpan> | annevk: http://caniuse.com/#feat=url says URL is supported since Edge 12? |
| 09:33 | <zcorpan> | re https://github.com/whatwg/url/issues/137#issuecomment-278275342 |
| 09:34 | <annevk> | Oh my |
| 09:35 | <annevk> | zcorpan: it totally is |
| 09:35 | <annevk> | zcorpan: filing a bug now |
| 09:35 | <zcorpan> | 👍 |
| 09:35 | <mkwst> | annevk: public-webappsec has plenty of meaningful discourse! For instance, just today we're discussing imaginary timelines for "completion" of documents that will likely never actually be complete. Totally useful. |
| 09:36 | <annevk> | mkwst: yes |
| 09:37 | <zcorpan> | annevk: should URLSearchParams also have toJSON? |
| 09:38 | <annevk> | zcorpan: dunno |
| 09:40 | <Ms2ger> | mkwst, that must be the only w3c list where that happens |
| 09:41 | <mkwst> | Ms2ger: It seems to only happen when groups' charter expires. We make up dates, folks tell us that our made-up dates aren't made-up enough, and we make up new dates. Very worthwhile. |
| 09:42 | <annevk> | mkwst: you might enjoy https://github.com/whatwg/url/issues/222 |
| 09:42 | <annevk> | (brought to you by Amazon's recommendations system) |
| 09:45 | <zcorpan> | can't all standards be done already? how hard can it be? |
| 10:25 | <Ms2ger> | > The @W3C Web Cryptography Working Group is closed, it produced Web Cryptography API |
| 10:26 | <Ms2ger> | zcorpan, clearly that one is done! |
| 10:26 | <zcorpan> | there we go |
| 10:27 | <annevk> | Hmm, except for the requirement about secure contexts that is being added? |
| 10:27 | <Ms2ger> | Time to set it up on whatwg.org for maintenance |
| 10:29 | <jgraham> | Seems like Multimodal Interaction's charter expired, so I guess EmotionML is done! |
| 10:45 | <annevk> | mkwst: heh, just occurred to me you could block these base elements in CSP too |
| 10:46 | <mkwst> | annevk: If you're happy with me bypassing HTML by abusing the hooks you've so generously helped me add, I can do that. ;) |
| 10:47 | <zcorpan> | mkwst: or CSP can block relative URLs :-D |
| 10:48 | <mkwst> | The web would be so much more secure (and less usable) if I had my way. |
| 10:48 | <mkwst> | Thankfully for everyone, I'm not the decider. :) |
| 10:49 | <zcorpan> | (and block http: URLs) |
| 10:51 | <mkwst> | Obviously. That's step 1. |
| 10:52 | <mkwst> | annevk: Regarding this subresources thing, would you accept a patch that changed the definition of `subresource request` and `non-subresource request` to include/exclude requests targeting nested browsing contexts? That might be simpler than burying the distinction in a substep. |
| 10:52 | <annevk> | mkwst: that would require coordination with JakeA and jungkees |
| 10:53 | <annevk> | mkwst: I think |
| 10:53 | <mkwst> | Ok. There's no rush, right? Coordination doesn't seem like a blocker. :) |
| 10:53 | <annevk> | mkwst: I would be happy with refactoring things though or introducing new terminology that helps explain this |
| 10:53 | <mkwst> | annevk: Even more terminology? Seems like we already have too much. :) |
| 10:54 | <annevk> | mkwst: yeah, if only people stopped adding little exceptions to the rules here and there |
| 10:55 | <mkwst> | Exceptions are great! They let me break things I don't like without breaking things I do like! |
| 10:55 | <mkwst> | (Also: should I reflow entire paragraphs to 100 characters if I touch them?) |
| 10:55 | <annevk> | mkwst: (yeah) |
| 10:56 | <annevk> | mkwst: you like <base>? You monster! |
| 10:57 | <mkwst> | I like developers not storming my castle with pitchforks. |
| 10:57 | <mkwst> | Also, Google Cache uses `<base>`, so killing it seems unlikely. |
| 10:57 | <mkwst> | (I looked into it) |
| 11:01 | <mkwst> | Hrm. Actually, this "subresource"/"non-subresource" distinction doesn't really match the way I think about the terms. Why are workers non-subresources? Also, why does "potential-navigation-or-subresource request" exist? |
| 11:01 | <mkwst> | I assume this is used in service workers, given your pointer to relevant folks. |
| 11:02 | <annevk> | mkwst: a worker creates its own environment |
| 11:02 | <annevk> | mkwst: the potential thing is for <object> and <embed> |
| 11:03 | <annevk> | mkwst: and yeah, service workers uses this to some extent |
| 11:19 | <annevk> | tobie: I keep accidentally writing IDL patches against master :/ |
| 11:20 | <tobie> | annevk: only heycam|away can fix this. |
| 11:20 | <annevk> | tobie: okay, did we ping him recently? |
| 11:27 | <tobie> | annevk: I check for him here daily, but he seems to be marked as away all the time. |
| 13:14 | <MikeSmith> | Can anybody please give me wording for a one-sentence definition of the concept of Service Worker scope? |
| 13:15 | <MikeSmith> | “The *scope* of a service worker is the...” |
| 13:15 | <annevk> | MikeSmith: "... set of URLs that cause the service worker to run (roughly)" |
| 13:17 | <MikeSmith> | nice |
| 13:17 | <MikeSmith> | annevk: thanks |
| 13:17 | <annevk> | MikeSmith: maybe "set of browsing context/environment URLs", to make it clear it's not subresources that matter |
| 13:17 | <MikeSmith> | OK |
| 13:18 | <MikeSmith> | but hmm in terms of how it’s declared, it’s a single URL |
| 13:19 | <MikeSmith> | “...a URL that defines a set of browsing context/environment URLs...” :/ |
| 13:19 | <annevk> | MikeSmith: maybe say something like "substring" or "URL pattern" |
| 13:19 | <annevk> | MikeSmith: there's a matching algorithm |
| 13:20 | <MikeSmith> | OK |
| 13:21 | <annevk> | So a problem I have with Fetch is that it's hard to get review |
| 13:22 | <annevk> | E.g., https://github.com/whatwg/fetch/pull/476 hasn't had much attention thus far |
| 13:22 | annevk | assigns a bunch of people in the hope that'll work |
| 13:24 | <MikeSmith> | hah that’s one way to do it |
| 13:26 | <annevk> | mkwst: when are we going to tackle https://github.com/whatwg/url/pull/72 again? |
| 13:26 | <annevk> | mkwst: what's the current feeling at Google around public suffix? |
| 13:26 | <annevk> | mkwst: it seems WebAuthn(sp?) is using it too now |
| 13:27 | <annevk> | MikeSmith: I'd appreciate your input on https://github.com/whatwg/url/pull/228 |
| 13:28 | MikeSmith | hurries to respond before annevk assigns him |
| 13:28 | <annevk> | MikeSmith: in particular since we moved from "validator" to "checker", should we also not use "valid"? |
| 13:29 | <annevk> | MikeSmith: Domenic and zcorpan are suggesting that instead of "URL string" we say "valid URL string" |
| 13:29 | <MikeSmith> | yes |
| 13:29 | <MikeSmith> | I agree |
| 13:29 | <MikeSmith> | I like "valid URL string" |
| 13:29 | <MikeSmith> | “valid” by itself does not have the baggage that “validator” does |
| 13:30 | <MikeSmith> | but I guess it could also be “conforming URL string” |
| 13:30 | <MikeSmith> | or “conformant” |
| 13:30 | <MikeSmith> | but still in this context “valid” seems fine to me |
| 13:31 | <annevk> | Okay |
| 13:31 | <nox> | wellformed vs valid? |
| 13:32 | <MikeSmith> | nox: seems like we have no wellformed-ness concept in this case |
| 13:32 | <MikeSmith> | hmm |
| 13:32 | <nox> | "Parser doesn't fail" |
| 13:32 | <nox> | vs "Parser doesn't fail and doesn't emit syntax violations" |
| 13:33 | <MikeSmith> | OK yeah |
| 13:33 | <annevk> | There's also doesn't fail, doesn't emit syntax violations, and URL makes sense |
| 13:33 | <annevk> | E.g., mailto://tralala/ |
| 13:33 | <nox> | annevk: When does it make no sense but there is no syntax violation? |
| 13:33 | <annevk> | I don't know how many types we want to distinguish |
| 13:33 | <MikeSmith> | well anyway, zcorpan point is that we are using “valid” everywhere else already, so for consistency we should use “valid” for this too |
| 13:33 | <nox> | "mailto://tralala" seems perfectly legit to me. |
| 13:34 | <annevk> | nox: it's not a valid mailto URL |
| 13:34 | <MikeSmith> | if we want to switch to using something other than “valid” then we should change it all globally |
| 13:34 | <annevk> | which is closer to the XML distinction between well-formed and valid |
| 13:35 | <annevk> | XML uses well-formed for parses into something, and valid for "makes sense per vocab" |
| 13:35 | <annevk> | But I don't really care about being analogous to that |
| 13:35 | <MikeSmith> | yeah |
| 13:37 | <zcorpan> | well-formed seems like it has mental baggage we probably want to avoid |
| 13:41 | <MikeSmith> | annevk: “The scope of a service worker is a single URL against which addresses much match in order to cause the service worker to run.”? |
| 13:42 | <annevk> | MikeSmith: s/addresses/environment URLs/? |
| 13:43 | <MikeSmith> | “environment URL” is a dfn in the spec? |
| 13:43 | MikeSmith | looks |
| 13:43 | <MikeSmith> | hmm no |
| 13:44 | <MikeSmith> | this is pulling at threads |
| 13:44 | <MikeSmith> | hard to define it conceptually without also needing to mint other definitions it can reference |
| 13:45 | <MikeSmith> | annevk: “document addresses”?... |
| 13:46 | <annevk> | https://html.spec.whatwg.org/#environment exists |
| 13:46 | <annevk> | MikeSmith: "address" is not a thing, what's wrong with URL? |
| 13:46 | <annevk> | MikeSmith: "document" doesn't capture workers |
| 13:46 | <annevk> | MikeSmith: you could do document/worker URLs maybe |
| 13:48 | <MikeSmith> | yeah |
| 13:48 | <MikeSmith> | https://html.spec.whatwg.org/#navigating-across-documents:concept-environment-creation-url-2 |
| 13:49 | <MikeSmith> | “The created environment's active service worker is set in the handle fetch algorithm during the fetch if its creation URL matches a service worker registration.” |
| 13:49 | <MikeSmith> | that is not bad wording |
| 13:49 | <MikeSmith> | “creation URL” is dfn’ed |
| 13:50 | <MikeSmith> | meaning “environment URL” |
| 13:50 | <MikeSmith> | anyway I guess I will take a break now and go to the sento and meditate on it there |
| 15:27 | <wanderview> | JakeA: I seem to recall you told me in irc that you were ok adding a "serviceworker" ClientType. Am I remembering that right? https://github.com/w3c/ServiceWorker/issues/1036 |
| 15:28 | <wanderview> | just looking for a head nod in the issue so I can add it to gecko |
| 15:28 | <JakeA> | wanderview: I'll nod |
| 15:28 | <wanderview> | thanks |
| 15:28 | <wanderview> | JakeA: the reserved client thing is trickier than I thought, btw |
| 15:29 | <JakeA> | Which bit? |
| 15:29 | <wanderview> | JakeA: getting stuff initialized before the network load just breaks existing assumptions in the code |
| 15:30 | <wanderview> | maybe it will be easier in blink |
| 15:30 | <wanderview> | I've just had to fix a bunch of stuff in our worker implementation to support doing this |
| 15:30 | <wanderview> | which is good I suppose |
| 16:18 | <tobie> | TabAtkins: any idea why the following returns 400? https://api.csswg.org/bikeshed/?force=1&url=https://raw.githubusercontent.com/tobie/sensors/fd4501a5c2bb7fb727fc2faff7f2c14f14227b74/index.bs |
| 16:38 | <TabAtkins> | Ask plinss? (Over in w3c#css) |
| 16:38 | <botie> | will do |
| 16:38 | <TabAtkins> | tobie: ^^^ |
| 16:38 | <tobie> | ty |
| 18:00 | <MikeSmith> | reading https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/ |
| 19:18 | <smaug> | annevk: why https://github.com/w3c/web-platform-tests/pull/4702 is right? |
| 19:18 | <smaug> | or I guess I should ask why the spec is right |
| 19:19 | <smaug> | per spec href getter and toJSON return the same value |
| 19:19 | <smaug> | but the test hints that value starts with " and ends with " |
| 19:23 | <annevk> | smaug: JSON.stringify adds that |
| 19:24 | <smaug> | annevk: ok, why do we have toJSON() then? |
| 19:25 | <smaug> | oh, I see |
| 19:25 | <smaug> | rather silly setup |
| 19:25 | <smaug> | but I guess that is what toJSON is |
| 19:26 | <smaug> | but url.toJSON() == url.href |
| 19:32 | <annevk> | smaug: yeah |
| 19:33 | <smaug> | I was just looking at a patch to implement that in Gecko and patch was clearly wrong since it was trying to json-stringify and return that value |
| 20:13 | <tobie> | smaug: that's the behavior toJSONString() had (back when it was the first iteration of Crockford's JS library with the funky "don't be evil" license). |