freenode :: #whatwg

6 Jan 2017
02:24MikeSmithso ShadowRoot.innerHTML is gone?
02:24MikeSmithI see it is still at but not at
02:27hayatoMikeSmith: Section 7 will be replaced with that of DOM Standard. I will work on it.
02:30hayatoI do not remember, but I guess innerHTML is defined in DocumentFragment?
02:38MikeSmithhayato: ah OK
02:39MikeSmithI am working on a bit on the related docs at MDN
02:39MikeSmithand the MDN docs have
02:39MikeSmithso maybe I need to move that
02:42DomenicIt's not on DocumentFragment unfortunately. I wish it were. People have asked for that for a long time.
02:43DomenicMaybe rniwa and hayato can agree on adding it there and ship it? :)
02:43rniwaDomenic, MikeSmith: it's on ShadowRoot
02:44rniwaDomenic, MikeSmith: we shipped it that way, so shadowRoot.innerHTML isn't going away. Or are you talking about adding one on DocumentFragment?
02:45rniwafor DocumentFragment, there was a discussion about parsing it like template element
02:45rniwawe don't need to, really
02:45MikeSmithrniwa: OK thanks for the clarification
02:46MikeSmiththanks Domenic too
02:46hayatoAh, I have found that Blink defines innerHTML in ShadowRoot interface. :)
02:46MikeSmithso then it seems like the DOM spec needs to be updated to add it
02:46MikeSmithsince its not at
02:47MikeSmithDomenic: should I create a PR?
02:47MikeSmithor raise an issue at least
02:48DomenicYeah but you could move it to DocumentFragment and I and a couple other web devs would become happy :)
02:49DomenicSorry spotty connection
02:49hayatoI 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:49MikeSmithah right
02:49DomenicHmm I see. I guess you could use some implicit template element but yeah not as obvious as I hoped
02:49MikeSmiththere is a note at saying pretty much exactly that
02:50DomenicAnd yeah MikeSmith we should raise an issue for porting
02:51MikeSmithglad I instead did not end up having to write code patches for WebKit and Blink!
02:53MikeSmithmeme: 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:59rniwaDomenic, hayato, MikeSmith: moving it to DocumentFragment is fine but someone needs to come up with what it does
03:00MikeSmithyeah I am not signing up to do that
03:00MikeSmithnot right now at least
03:06DomenicMaybe I will open an issue :)
07:38annevkwanderview: that seems a little ugly
07:39annevkwanderview: Request and Response are ideally just data
07:54annevkOoh Mek is back
07:54annevkMek: please let me know when we can get back to defining the origin of blob URLs
10:27annevkContext switching between URL parsing and Fetch is not going as well as I'd hoped
13:55annevkJakeA: I hope Service Workers doesn't have much copy-and-paste algorithms
13:55annevkJakeA: is rather bad
13:55annevk(the layering there seems bad too, but I'm mostly surprised that when introducing new largely identical code it wasn't abstracted)
13:56JakeAannevk: 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:57annevkIf 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:07wanderviewJakeA: annevk: fwiw, I think my opinion on foreign fetch has evolved a bit... but I wrote spec issues regarding that I think
14:14annevkwanderview: didn't I reply to those?
14:15wanderviewannevk: not this one:
14:16annevkwanderview: I see
14:16annevkwanderview: I guess the big issue with foreign fetch is what we should do with third-party cookies in general
14:16wanderviewannevk: at least in firefox, my position is we would implement foreign fetch event only for credentialed requests at least to start
14:16annevkwanderview: the reason web fonts are fetched without credentials is mostly because that gives you the simplest variant of CORS
14:17annevkwanderview: it didn't have much to do with third-party cookies, although I guess that's a nice side effect
14:17wanderviewwhatever the reasoning, I don't think we should enabled tracking where its not possible today
14:17wanderviewespecially since I think we can achieve the use case with a slightly different solution
14:17wanderviewa different solution we want for other things as well
14:17annevkI think if we did foreign fetch the way Safari did third-party cookies it'd be okay
14:18annevkYeah, except for first-party visits
14:18wanderviewyou might as well just not intercept them... because the storage won't be shared you won't really get much benefit
14:19annevkIt would be for sites visited first-party
14:19annevkSo you could do the use cases and such
14:20annevkBut yeah, part of the overall question is how much third-party tracking should be allowed anyway
14:22wanderviewwell, 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:22wanderviewin either case, we probably won't start working on foreign fetch in firefox until Q3/Q4 2017 at the earliest
14:22wanderviewwe are still working on getting our multi-process house in order
14:25DomenicHow's that going, by the way?
14:26wanderviewDomenic: slowly
14:27wanderviewDomenic: its a high priority, though, and we have more people working on SW again
14:28wanderviewDomenic: and I think we have people committed to work streams, although no progress yes AFAIK
14:29wanderviewunfortunately its at a difficult intersection of js engine bits and DOM binding bits... few people who know both really well
14:31DomenicYeah till has been asking some questions, seems like he's pretty far along
14:32wanderviewwe have some scheduled to start working on the c++ binding part in next couple weeks as well
14:51annevkwanderview: 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:52annevkDomenic: what does "this" mean in
14:52annevkDomenic: the issue in general?
14:52Domenicannevk: oh, sorry, I meant in particular; let me edit
14:55wanderviewannevk: you think all browsers will change to implement the same 3rd party cookie policies?
14:55annevkwanderview: I hope we can get closer over time, yes
14:55annevkwanderview: seems hard for web developers otherwise to make things work
14:55annevkwanderview: in particular Safari would never ship the kind of foreign fetch you would be willing to ship
14:56wanderviewannevk: I don't see what they are doing as much different from firefox with "block 3rd party cookies" enabled by default
14:57annevkwanderview: it is different, because first parties won't become third parties
14:57annevkwanderview: and also, it's different by virtue of being the default, since most folks don't change settings
14:59wanderviewannevk: 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:00wanderviewanyway... I'm just saying what I am comfortable implementing in FF given our current product features around cookies
15:47annevkigrigorik: could you comment on
15:47annevkwanderview: yeah, that's not how Safari works
15:48annevkwanderview: and I'm just saying that we should implement something that can work across all browsers
15:56wanderviewannevk: 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:57annevkYou don't think a priori that we should make something that can work for Safari?
16:01wanderviewannevk: 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:04annevkwanderview: I feel like you're dismissing my concern that there's a bigger issue
16:04annevkwanderview: and I don't really understand why
16:05wanderviewsorry, I didn't intend to dismiss your concerns
16:06wanderviewbut 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:06annevkWe did talk with Apple at TPAC about this, I guess you weren't there
16:06wanderviewI haven't seen any foreign fetch changes since then... maybe I missed it
16:07annevkI don't think there were any changes
16:07annevkBut either way the issue stands I think
16:08annevkDomenic: looking at the document it seems the validation rule is mentioned as issue A
16:14Domenicannevk: dang, I scrolled right past everything but the annevk/Simon section, nevermind
16:23annevkDomenic: so for 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:23annevkDomenic: it wasn't clear to me if those objects could ever be user-supplied
16:23Domenicannevk: oh hmm good point, this whole thing I just wrote up might be pointless...
16:23DomenicI think you're right
16:23DomenicThere's no way they can be getters
16:24annevkGood, then the text in service workers isn't wrong either
16:24annevkDomenic: shall I go ahead and merge then?
16:24DomenicLet me push my style tweak
16:25Domenicannevk: pushed
16:30annevkDomenic: I might look into IDNA tests next week
16:30annevkDomenic: I emailed some folks to see if some kind of framework was available, but no replies thus far
16:31annevkDomenic: for the host parser test, would you be okay with a dedicated hosts.json resource solely for host tests?
16:31annevkDomenic: 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:32annevkDomenic: btw, that's also going to be next week, but it'd be nice to know by Monday
16:42annevkI created
16:42annevkIf something is bugging you about the WHATWG community, we now have a much better place to discuss it than the mailing list
16:43annevk(IRC is still an option of course, but only when everyone is around at the same time)
17:27Domenicannevk: yeah dedicated JSON file works great
17:28DomenicIt'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:30annevkDomenic: it didn't even occur to me ToASCII would apply and as I found out it didn't
17:30DomenicHmm ok
17:31annevkDomenic: if a browser would have showed signs of ToASCII I would have investigated more of course
17:31DomenicI guess the bug is in tr46.js then
17:31annevkDomenic: it seems like you're using punycode.js from mathiasbynens which has known bugs
17:32annevkDomenic: but I didn't look closely
17:32DomenicI guess so, I didn't see any signs it was involved in that code path. Will dig in more later.
17:33annevkDomenic: FWIW, as I said I plan to write more IDNA tests, but those are less of a priority than the basic ASCII boundaries
17:35mathiasbynensannevk, Domenic: Im missing some context link?
17:37Domenicjsdom/whatwg-url is failing some new URL host tests. The problem appears to be in tr46.js which has a punycode.js dependency, not sure if the problem is in tr46.js or punycode.js yet thought
17:44mathiasbynensseems like punycode shouldnt be hit per annevks analysis, so the problem is in tr46.js
17:48Domenicmathiasbynens: 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:48mathiasbynens> It at least seems people are assuming that punycode.toASCII is a no-op on ASCII input.
17:49mathiasbynensthat might be my fault! Ill fix the docs
17:50mathiasbynens says Only the non-ASCII parts of the input will be converted, i.e. it doesnt matter if you call it with a domain thats already in ASCII. That should be s/ASCII/printable ASCII/ to match the existing behavior.
17:51DomenicIs the "printable ASCII" behavior specified anywhere?
17:52DomenicI.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:52mathiasbynensToASCII 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:53mathiasbynenshmm, so I guess my docs are correct, and the implementation should be updated
17:53mathiasbynensif matching ToASCII is the goal, at least (`punycode.toASCII` is an abstraction)
17:56DomenicYeah that would be quite nice
17:57DomenicWell OK but punycode is step 7
17:57DomenicSo maybe tr46 should be handling this
17:59DomenicAnd we should be using punycode.encode
18:00mathiasbynensstep 6
18:01mathiasbynensbut yeah, that makes sense for tr46.js to do
18:44annevkmathiasbynens: is it your goal to implement ToASCII?
18:45DomenicIt seems like the goal is to implement a few steps of (but not nameprep I guess). Whereas tr46.js implements
18:46mathiasbynensannevk: somewhat; RFC3490s `ToASCII` acts on a sequence of code points + the AllowUnassigned flag + the UseSTD3ASCIIRules flag. `punycode.toASCII` just takes a string as input
18:49annevkmathiasbynens: oh, if you don't implement UTS46 I'm not sure you should advertize that API
18:49annevkmathiasbynens: the only browser-compatible API (or that comes close to it) is UTS46 ToASCII
18:53annevkDomenic: no browser fails on http://-/
18:54annevkDomenic: aah, does say something here
18:54annevkDomenic: "The label must neither begin nor end with a U+002D HYPHEN-MINUS character." it seems browsers don't enforce that
18:55annevkDomenic: I guess we could try to make them
18:55DomenicWait isn't that the problematic thing
18:55DomenicNo not quite
18:56annevkDomenic: ?
18:56Domenicvalidity rule 3 is the known problem
18:56Domenicvalidity rule 2 is the known problem
18:56Domenicvalidity rule 3 is closely related though
18:56annevkI guess I can add a comment to Mark's document
18:56DomenicI'll comment on the doc?
18:56annevkPlease do
18:56annevkThen I'm going to take a break!
18:57annevkWe'll be back Monday for more URL parsing fun
7 Jan 2017
No messages
Last message: 229 days and 14 hours ago