| 02:24 | <MikeSmith> | so ShadowRoot.innerHTML is gone? |
| 02:24 | <MikeSmith> | I see it is still at https://w3c.github.io/webcomponents/spec/shadow/#the-shadowroot-interface but not at https://dom.spec.whatwg.org/#interface-shadowroot |
| 02:24 | <MikeSmith> | hayato: ⬆ |
| 02:27 | <hayato> | MikeSmith: Section 7 will be replaced with that of DOM Standard. I will work on it. |
| 02:30 | <hayato> | I do not remember, but I guess innerHTML is defined in DocumentFragment? |
| 02:38 | <MikeSmith> | hayato: ah OK |
| 02:39 | <MikeSmith> | I am working on a bit on the related docs at MDN |
| 02:39 | <MikeSmith> | and the MDN docs have https://developer.mozilla.org/en-US/docs/Web/API/ShadowRoot/innerHTML |
| 02:39 | <MikeSmith> | so maybe I need to move that |
| 02:42 | <Domenic> | It's not on DocumentFragment unfortunately. I wish it were. People have asked for that for a long time. |
| 02:43 | <Domenic> | Maybe rniwa and hayato can agree on adding it there and ship it? :) |
| 02:43 | <rniwa> | Domenic, MikeSmith: it's on ShadowRoot |
| 02:44 | <rniwa> | Domenic, MikeSmith: we shipped it that way, so shadowRoot.innerHTML isn't going away. Or are you talking about adding one on DocumentFragment? |
| 02:45 | <rniwa> | for DocumentFragment, there was a discussion about parsing it like template element |
| 02:45 | <rniwa> | we don't need to, really |
| 02:45 | <MikeSmith> | rniwa: OK thanks for the clarification |
| 02:46 | <MikeSmith> | thanks Domenic too |
| 02:46 | <hayato> | Ah, I have found that Blink defines innerHTML in ShadowRoot interface. :) |
| 02:46 | <MikeSmith> | OK |
| 02:46 | <MikeSmith> | so then it seems like the DOM spec needs to be updated to add it |
| 02:46 | <MikeSmith> | since it’s not at https://dom.spec.whatwg.org/#interface-shadowroot |
| 02:47 | <MikeSmith> | Domenic: should I create a PR? |
| 02:47 | <MikeSmith> | or raise an issue at least |
| 02:48 | <Domenic> | Yeah but you could move it to DocumentFragment and I and a couple other web devs would become happy :) |
| 02:48 | <MikeSmith> | heh |
| 02:49 | <Domenic> | Sorry spotty connection |
| 02:49 | <hayato> | I recalled the discussion about innerHTML. innerHTML requires a *host* element in parsing, so we can not define it DocumentFragment, as far as I remember. |
| 02:49 | <MikeSmith> | ah right |
| 02:49 | <Domenic> | Hmm I see. I guess you could use some implicit template element but yeah not as obvious as I hoped |
| 02:49 | <MikeSmith> | there is a note at https://w3c.github.io/webcomponents/spec/shadow/#the-shadowroot-interface saying pretty much exactly that |
| 02:50 | <Domenic> | And yeah MikeSmith we should raise an issue for porting |
| 02:50 | <MikeSmith> | OK |
| 02:51 | <MikeSmith> | glad I instead did not end up having to write code patches for WebKit and Blink! |
| 02:53 | <MikeSmith> | meme: bad luck brian tries to be a good guy and get MDN shadow-dom docs synced up with specs / spends the next 6 weeks writing browser patches and tests and getting them all reviewed |
| 02:59 | <rniwa> | Domenic, hayato, MikeSmith: moving it to DocumentFragment is fine but someone needs to come up with what it does |
| 03:00 | <MikeSmith> | yeah I am not signing up to do that |
| 03:00 | <MikeSmith> | not right now at least |
| 03:03 | <MikeSmith> | https://github.com/whatwg/dom/issues/393 |
| 03:06 | <Domenic> | Maybe I will open an issue :) |
| 07:38 | <annevk> | wanderview: that seems a little ugly |
| 07:39 | <annevk> | wanderview: Request and Response are ideally just data |
| 07:54 | <annevk> | Ooh Mek is back |
| 07:54 | <annevk> | Mek: please let me know when we can get back to defining the origin of blob URLs |
| 10:27 | <annevk> | Context switching between URL parsing and Fetch is not going as well as I'd hoped |
| 13:55 | <annevk> | JakeA: I hope Service Workers doesn't have much copy-and-paste algorithms |
| 13:55 | <annevk> | JakeA: https://github.com/whatwg/fetch/issues/450 is rather bad |
| 13:55 | <annevk> | (the layering there seems bad too, but I'm mostly surprised that when introducing new largely identical code it wasn't abstracted) |
| 13:56 | <JakeA> | annevk: hmm yeah. I want us to do a full review of foreign fetch in March. I don't think the API has been properly reviewed either |
| 13:57 | <annevk> | If Mek didn't change much from what we agreed on at some point I guess it's probably okayish, but yeah, probably deserves another round |
| 14:07 | <wanderview> | JakeA: annevk: fwiw, I think my opinion on foreign fetch has evolved a bit... but I wrote spec issues regarding that I think |
| 14:14 | <annevk> | wanderview: didn't I reply to those? |
| 14:15 | <wanderview> | annevk: not this one: https://github.com/w3c/ServiceWorker/issues/1024 |
| 14:16 | <annevk> | wanderview: I see |
| 14:16 | <annevk> | wanderview: I guess the big issue with foreign fetch is what we should do with third-party cookies in general |
| 14:16 | <wanderview> | annevk: at least in firefox, my position is we would implement foreign fetch event only for credentialed requests at least to start |
| 14:16 | <annevk> | wanderview: the reason web fonts are fetched without credentials is mostly because that gives you the simplest variant of CORS |
| 14:17 | <annevk> | wanderview: it didn't have much to do with third-party cookies, although I guess that's a nice side effect |
| 14:17 | <wanderview> | whatever the reasoning, I don't think we should enabled tracking where its not possible today |
| 14:17 | <wanderview> | especially since I think we can achieve the use case with a slightly different solution |
| 14:17 | <wanderview> | a different solution we want for other things as well |
| 14:17 | <annevk> | I think if we did foreign fetch the way Safari did third-party cookies it'd be okay |
| 14:18 | <wanderview> | double-keying? |
| 14:18 | <annevk> | Yeah, except for first-party visits |
| 14:18 | <wanderview> | you might as well just not intercept them... because the storage won't be shared you won't really get much benefit |
| 14:19 | <annevk> | It would be for sites visited first-party |
| 14:19 | <annevk> | So you could do the drive.google.com use cases and such |
| 14:20 | <annevk> | But yeah, part of the overall question is how much third-party tracking should be allowed anyway |
| 14:22 | <wanderview> | well, I like disabling foreign fetch event for non-credentialed requests as it automatically does the right thing if the user disables 3rd-party cookies, etc |
| 14:22 | <wanderview> | in either case, we probably won't start working on foreign fetch in firefox until Q3/Q4 2017 at the earliest |
| 14:22 | <wanderview> | we are still working on getting our multi-process house in order |
| 14:25 | <Domenic> | How's that going, by the way? |
| 14:26 | <wanderview> | Domenic: slowly |
| 14:27 | <wanderview> | Domenic: its a high priority, though, and we have more people working on SW again |
| 14:28 | <wanderview> | Domenic: and I think we have people committed to work streams, although no progress yes AFAIK |
| 14:29 | <wanderview> | unfortunately its at a difficult intersection of js engine bits and DOM binding bits... few people who know both really well |
| 14:31 | <Domenic> | Yeah till has been asking some questions, seems like he's pretty far along |
| 14:31 | <wanderview> | awesome! |
| 14:32 | <wanderview> | we have some scheduled to start working on the c++ binding part in next couple weeks as well |
| 14:33 | <wanderview> | ^some^someone |
| 14:33 | <Domenic> | \o/ |
| 14:51 | <annevk> | wanderview: I think the problem with not figuring out our final goals for third-party cookies and moving ahead with foreign fetch regardless will make it harder to switch to something better later |
| 14:52 | <annevk> | Domenic: what does "this" mean in https://github.com/whatwg/url/issues/53#issuecomment-270915763? |
| 14:52 | <annevk> | Domenic: the issue in general? |
| 14:52 | <Domenic> | annevk: oh, sorry, I meant https://github.com/whatwg/url/issues/53#issuecomment-181528158 in particular; let me edit |
| 14:55 | <wanderview> | annevk: you think all browsers will change to implement the same 3rd party cookie policies? |
| 14:55 | <annevk> | wanderview: I hope we can get closer over time, yes |
| 14:55 | <annevk> | wanderview: seems hard for web developers otherwise to make things work |
| 14:55 | <annevk> | wanderview: in particular Safari would never ship the kind of foreign fetch you would be willing to ship |
| 14:56 | <wanderview> | annevk: I don't see what they are doing as much different from firefox with "block 3rd party cookies" enabled by default |
| 14:57 | <annevk> | wanderview: it is different, because first parties won't become third parties |
| 14:57 | <annevk> | wanderview: and also, it's different by virtue of being the default, since most folks don't change settings |
| 14:59 | <wanderview> | annevk: first parties effectively become different origins when loaded as a 3rd party... creating a new fake origin for the cookie instead of just not allowing cookies both have the same effect of not using the real origin |
| 15:00 | <wanderview> | anyway... I'm just saying what I am comfortable implementing in FF given our current product features around cookies |
| 15:47 | <annevk> | igrigorik: could you comment on https://github.com/whatwg/url/issues/26 |
| 15:47 | <annevk> | wanderview: yeah, that's not how Safari works |
| 15:48 | <annevk> | wanderview: and I'm just saying that we should implement something that can work across all browsers |
| 15:56 | <wanderview> | annevk: I'm just trying to highlight a problem with the current proposal that I don't think we can implement in firefox... if apple wants to ask for further changes they can do that as well |
| 15:57 | <annevk> | You don't think a priori that we should make something that can work for Safari? |
| 16:01 | <wanderview> | annevk: I didn't say that... I'm just providing feedback from FF impl point of view... we haven't implemented anything yet so I don't know why you are picking a fight with me here |
| 16:04 | <annevk> | wanderview: I feel like you're dismissing my concern that there's a bigger issue |
| 16:04 | <annevk> | wanderview: and I don't really understand why |
| 16:05 | <wanderview> | sorry, I didn't intend to dismiss your concerns |
| 16:06 | <wanderview> | but I'm less interested in guessing what other browser vendors want than having them tell us what they want... since we're not implementing this any time soon I'm happy to wait for apple to tell us what they thing |
| 16:06 | <wanderview> | think |
| 16:06 | <annevk> | We did talk with Apple at TPAC about this, I guess you weren't there |
| 16:06 | <wanderview> | I haven't seen any foreign fetch changes since then... maybe I missed it |
| 16:07 | <annevk> | I don't think there were any changes |
| 16:07 | <annevk> | But either way the issue stands I think |
| 16:08 | <annevk> | Domenic: looking at the document it seems the validation rule is mentioned as issue A |
| 16:14 | <Domenic> | annevk: dang, I scrolled right past everything but the annevk/Simon section, nevermind |
| 16:23 | <annevk> | Domenic: so for https://github.com/whatwg/fetch/pull/449 I was indeed wondering about throwing getters, but if only Streams makes those objects, it seems like they would never be able to throw? |
| 16:23 | <annevk> | Domenic: it wasn't clear to me if those objects could ever be user-supplied |
| 16:23 | <Domenic> | annevk: oh hmm good point, this whole thing I just wrote up might be pointless... |
| 16:23 | <Domenic> | I think you're right |
| 16:23 | <Domenic> | There's no way they can be getters |
| 16:24 | <annevk> | Good, then the text in service workers isn't wrong either |
| 16:24 | <annevk> | Domenic: shall I go ahead and merge then? |
| 16:24 | <Domenic> | Let me push my style tweak |
| 16:25 | <Domenic> | annevk: pushed |
| 16:27 | <annevk> | ta |
| 16:30 | <annevk> | Domenic: I might look into IDNA tests next week |
| 16:30 | <annevk> | Domenic: I emailed some folks to see if some kind of framework was available, but no replies thus far |
| 16:31 | <annevk> | Domenic: for the host parser test, would you be okay with a dedicated hosts.json resource solely for host tests? |
| 16:31 | <annevk> | Domenic: we could also use that for host/hostname setters where there's no difference, rather than duplicating all those tests as I'm currently doing |
| 16:32 | <annevk> | Domenic: btw, that's also going to be next week, but it'd be nice to know by Monday |
| 16:42 | <annevk> | I created https://github.com/whatwg/meta |
| 16:42 | <annevk> | If something is bugging you about the WHATWG community, we now have a much better place to discuss it than the mailing list |
| 16:43 | <annevk> | (IRC is still an option of course, but only when everyone is around at the same time) |
| 17:27 | <Domenic> | annevk: yeah dedicated JSON file works great |
| 17:28 | <Domenic> | It's a little worrying that you're writing tests without being sure how domain to ASCII works? At least that's how I interpreted your reply. |
| 17:30 | <annevk> | Domenic: it didn't even occur to me ToASCII would apply and as I found out it didn't |
| 17:30 | <Domenic> | Hmm ok |
| 17:31 | <annevk> | Domenic: if a browser would have showed signs of ToASCII I would have investigated more of course |
| 17:31 | <Domenic> | I guess the bug is in tr46.js then |
| 17:31 | <annevk> | Domenic: it seems like you're using punycode.js from mathiasbynens which has known bugs |
| 17:32 | <annevk> | Domenic: but I didn't look closely |
| 17:32 | <Domenic> | I guess so, I didn't see any signs it was involved in that code path. Will dig in more later. |
| 17:33 | <annevk> | Domenic: FWIW, as I said I plan to write more IDNA tests, but those are less of a priority than the basic ASCII boundaries |
| 17:35 | <mathiasbynens> | annevk, Domenic: I’m missing some context — link? |
| 17:37 | <Domenic> | mathiasbynens: https://github.com/w3c/web-platform-tests/pull/4504#issuecomment-270771165 |
| 17:37 | <Domenic> | jsdom/whatwg-url is failing some new URL host tests. The problem appears to be in tr46.js https://github.com/Sebmaster/tr46.js which has a punycode.js dependency, not sure if the problem is in tr46.js or punycode.js yet thought |
| 17:44 | <mathiasbynens> | seems like punycode shouldn’t be hit per annevk’s analysis, so the problem is in tr46.js |
| 17:45 | <mathiasbynens> | ref. https://github.com/mathiasbynens/todo/issues/9 |
| 17:47 | <Domenic> | https://github.com/Sebmaster/tr46.js/issues/5 |
| 17:48 | <Domenic> | mathiasbynens: so the punycode spec seems pretty impenetrable, so I can't tell what the intended semantics of punycode.toASCII are. Given ASCII input, is it meant to be a no-op? Or will it always add the xn-- stuff? |
| 17:48 | <mathiasbynens> | > It at least seems people are assuming that punycode.toASCII is a no-op on ASCII input. |
| 17:49 | <mathiasbynens> | that might be my fault! I’ll fix the docs |
| 17:50 | <mathiasbynens> | https://github.com/bestiejs/punycode.js#punycodetoasciiinput says “Only the non-ASCII parts of the input will be converted, i.e. it doesn’t matter if you call it with a domain that’s already in ASCII.” That should be s/ASCII/printable ASCII/ to match the existing behavior. |
| 17:51 | <Domenic> | Is the "printable ASCII" behavior specified anywhere? |
| 17:52 | <Domenic> | I.e. is punycode.js deciding on that behavior based on a spec, or just arbitrarily? If the latter, a spec based version would be quite nice. |
| 17:52 | <mathiasbynens> | Domenic: https://tools.ietf.org/html/rfc3490#section-4.1 |
| 17:52 | <mathiasbynens> | “ToASCII never alters a sequence of code points that are all in the ASCII range to begin with (although it could fail). Applying the ToASCII operation multiple times has exactly the same effect as applying it just once.” |
| 17:53 | <mathiasbynens> | hmm, so I guess my docs are correct, and the implementation should be updated |
| 17:53 | <mathiasbynens> | if matching ToASCII is the goal, at least (`punycode.toASCII` is an abstraction) |
| 17:56 | <Domenic> | Yeah that would be quite nice |
| 17:57 | <Domenic> | Well OK but punycode is step 7 |
| 17:57 | <Domenic> | So maybe tr46 should be handling this |
| 17:59 | <Domenic> | And we should be using punycode.encode |
| 18:00 | <mathiasbynens> | step 6 |
| 18:01 | <mathiasbynens> | but yeah, that makes sense for tr46.js to do |
| 18:44 | <annevk> | mathiasbynens: is it your goal to implement ToASCII? |
| 18:45 | <Domenic> | It seems like the goal is to implement a few steps of https://tools.ietf.org/html/rfc3490#section-4.1 (but not nameprep I guess). Whereas tr46.js implements http://www.unicode.org/reports/tr46/#ToASCII |
| 18:46 | <mathiasbynens> | annevk: somewhat; RFC3490’s `ToASCII` acts on a sequence of code points + the AllowUnassigned flag + the UseSTD3ASCIIRules flag. `punycode.toASCII` just takes a string as input |
| 18:49 | <annevk> | mathiasbynens: oh, if you don't implement UTS46 I'm not sure you should advertize that API |
| 18:49 | <annevk> | mathiasbynens: the only browser-compatible API (or that comes close to it) is UTS46 ToASCII |
| 18:53 | <annevk> | Domenic: no browser fails on http://-/ |
| 18:54 | <annevk> | Domenic: aah, http://www.unicode.org/reports/tr46/#Validity_Criteria does say something here |
| 18:54 | <annevk> | Domenic: "The label must neither begin nor end with a U+002D HYPHEN-MINUS character." it seems browsers don't enforce that |
| 18:55 | <annevk> | Domenic: I guess we could try to make them |
| 18:55 | <Domenic> | Wait isn't that the problematic thing |
| 18:55 | <Domenic> | No not quite |
| 18:56 | <annevk> | Domenic: ? |
| 18:56 | <Domenic> | validity rule 3 is the known problem |
| 18:56 | <Domenic> | errr |
| 18:56 | <Domenic> | validity rule 2 is the known problem |
| 18:56 | <Domenic> | validity rule 3 is closely related though |
| 18:56 | <annevk> | Yeah |
| 18:56 | <annevk> | I guess I can add a comment to Mark's document |
| 18:56 | <Domenic> | I'll comment on the doc? |
| 18:56 | <annevk> | Please do |
| 18:56 | <annevk> | Then I'm going to take a break! |
| 18:57 | <annevk> | We'll be back Monday for more URL parsing fun |
| 18:58 | <Domenic> | \o/ |