| 02:39 | <MikeSmith> | https://stackoverflow.com/questions/54777993/set-cookie-from-a-server-to-an-xhr-client-in-a-different-domain-setting-the-dom |
| 07:47 | <Nepose> | Sorry for it, network problems... |
| 07:57 | <annevk> | Nepose: not sure what you’re asking |
| 07:59 | <annevk> | MikeSmith: I guess I can answer that |
| 08:06 | <Nepose> | annevk: I mean that if you now do some of Web standards like HTML or XMLHttpRequest and still W3C "do" (copy-paste your work) the same standards (like now, "developing" HTML 5.3), then why they do it and for who? |
| 08:19 | <annevk> | Nepose: I think there was a disagreement over control, but we're pretty close to a partnership of sorts, as some W3C blog posts have reported on |
| 08:55 | <Nepose> | annevk: okay, did you develop together any standard? |
| 09:00 | <annevk> | Nepose: most WHATWG standards are in some sense derived from work earlier done at the W3C and IETF and continue to get feedback from those communities |
| 12:05 | <annevk> | MikeSmith: replied |
| 12:10 | MikeSmith | looks |
| 12:15 | <MikeSmith> | annevk: thanks! |
| 12:31 | <nox> | annevk: Do you have a link to said blog posts? |
| 12:33 | <annevk> | nox: https://www.w3.org/blog/2018/06/w3c-strategic-highlights-for-spring-2018-and-advisory-committee-meeting/ and https://www.w3.org/blog/2019/02/w3c-strategic-highlights-strengthening-the-core-of-the-web-html/ |
| 12:33 | <annevk> | (awesome bar is awesome) |
| 12:34 | <ondras> | so, window.open is limited to calls from a user-interaction event handler? |
| 12:34 | <nox> | Thanks! |
| 12:35 | <annevk> | ondras: depends, I suspect |
| 12:36 | <annevk> | (I'd imagine navigating an existing browsing context to always work.) |
| 12:36 | <ondras> | annevk: I see. I was about to ask "what if the user-interaction event handler sends a message to a different context (iframe) and *that* context wants to window.open as a result" |
| 12:37 | <ondras> | so, basically, "it the user-interaction-based flag propagated far enough?" |
| 12:37 | <ondras> | *is |
| 12:37 | <annevk> | ondras: see recent HTML issue |
| 12:37 | <annevk> | ondras: that's all a bit muddy still |
| 12:37 | <ondras> | ah, my bad, should've specified that I am explicitly looking for the target=_blank scenario |
| 12:38 | <ondras> | which I would guess is more restricted with respect to the origin of the call |
| 12:45 | <annevk> | ondras: origin doesn't matter much, but that gets "new window" protection |
| 12:45 | <annevk> | ondras: or popup protection, I guess |
| 12:49 | <ondras> | "origin" as in "was it invoked from a user-interaction event handler", not "origin" in the DOM Origin sense |
| 12:49 | <ondras> | sorry, wrong terminology |
| 12:49 | <ondras> | but yeah, the newwindow/popup protection, that is what I am talking about -- would that work if the open() call came from an onmessage event? |
| 12:50 | <annevk> | CSS folks are like why does (0, 0) matter here |
| 12:50 | <ondras> | ha, *trusted* is apparently the proper name for this |
| 12:50 | <annevk> | ondras: "user activation" |
| 12:50 | <annevk> | ondras: https://github.com/whatwg/html/issues/4364 |
| 12:51 | <annevk> | (tl;dr: no) |
| 12:51 | <ondras> | a-ha! thanks |
| 12:51 | <ondras> | that is what I thought. |
| 12:55 | <domfarolino> | annevk: So in the usage of the `as` attribute here (https://html.spec.whatwg.org/multipage/semantics.html#fetching-and-processing-a-resource-from-a-link-element:attr-link-as), we check for "no state", (which I think includes missing/invalid value default), but based on your latest review, wouldn' |
| 12:56 | <domfarolino> | wouldn't that sort of break that usage? |
| 12:56 | <domfarolino> | (since missing/invalid value defaults are I guess valid states?) |
| 12:56 | <annevk> | domfarolino: I guess that's wrong |
| 12:56 | <annevk> | domfarolino: as is an enumerated attribute afaik and per the enumerated attribute definition "no state" and "valid state" are not things it knows about |
| 12:57 | <domfarolino> | Makes more sense now. That usage of `as` is sorta what I was basing mind off of. I guess I can file an issue for that |
| 12:57 | <annevk> | domfarolino: sorry, I'm wrong, "no state" is a thing |
| 12:57 | <domfarolino> | oh |
| 12:57 | <domfarolino> | np |
| 12:58 | <annevk> | domfarolino: so instead of valid state, you can assert that it has a state |
| 12:59 | <annevk> | domfarolino: or rather, that it represents a state, perhaps? |
| 12:59 | <domfarolino> | annevk: so "has a state" excludes missing/invalid value defaults then? |
| 12:59 | <annevk> | domfarolino: enumerated attribute could use some refining at some point |
| 12:59 | <annevk> | domfarolino: aye, though I think I'd go with "represents a state" given that's what the prose uses |
| 13:00 | <domfarolino> | annevk: Ok I'll do that ('tis what I was going for anyways, but ty for the clarification) |
| 13:01 | <annevk> | domfarolino: Domenic is back later this week and I'll let him do a final pass since he had at least one remaining comment too |
| 13:02 | <domfarolino> | SGTM |
| 13:15 | <domfarolino> | annevk: Ok, latest commit should address the comments, will wait for domenic's pass. thanks again |
| 13:16 | <annevk> | \o/ |
| 18:04 | <cvazac> | annevk: i believe you said (https://freenode.logbot.info/whatwg/20190216#c1999445) that cross origin IFRAME requests should not emit fetch events to the service worker in the base page. i assume that means that a fetch event *should* be emitted to a service worker installed on the other domain. which makes the offline story of the base page more complicated. i couldn't find anything in the service worker spec about IFRAMEs, do you know |
| 18:04 | <cvazac> | if this behavior is specced somewhere else? |
| 18:31 | <annevk> | cvazac: it's specified between HTML, SW, and Fetch |
| 18:31 | <annevk> | cvazac: but effectively, as with the top-level browsing context, an iframe element's nested browsing context navigates, and interception for navigation (as well as workers) works differently |
| 18:32 | <annevk> | cvazac: there's further complications here in browsers that do third-party isolation (Safari) and plan to do more third-party isolation (Firefox) |
| 18:33 | <cvazac> | annevk: thx! |
| 19:41 | <lgrahl> | o/ Hello everyone, long time no chat |
| 19:44 | <lgrahl> | Someone asked (regarding RTCDataCHannel but it's the same for WebSocket): If you create a WebSocket and then bind the open event, wouldn't there be a small time period where open could fire before it's being bound? |
| 19:46 | <lgrahl> | My thoughts: The event would have to be enqueued pm the event loop and since the task creating the WebSocket itself is already running, the bind happens before the event can fire. Is that assumption correct? |
| 19:46 | <lgrahl> | *on |
| 19:48 | <annevk> | lgrahl: aye |
| 19:48 | <lgrahl> | Cheers! |