| 00:34 | <MikeSmith> | annevk: about hyphenated adjectives, I found a good example of a case where it makes a big difference |
| 00:34 | <MikeSmith> | https://japantoday.com/category/entertainment/japan%E2%80%99s-anti-piracy-ads-are-back-with-reboot-after-six-year-break headline |
| 00:34 | <MikeSmith> | “Japan’s anti-movie piracy ads are back with reboot after six-year break” |
| 00:36 | <MikeSmith> | while a muliply-hyphenated adjective as in “Japan’s anti-movie-piracy ads” would look a bit awkward, “Japan’s anti-movie piracy ads” is a lot more awkward |
| 00:39 | <MikeSmith> | ...because it sounds like it’s referring to ads promoting piracy, and that are also “anti-movie” (rather anti-piracy) |
| 07:23 | <annevk> | MikeSmith: or stolen ads 😊 |
| 07:24 | <annevk> | I guess it still works because there's only one "logical" explanation (absent this channel's rules) |
| 07:28 | <annevk> | Domenic: I don't really see how that would work in a multi-process architecture. Could you walk me through it? |
| 11:43 | <ondras> | so uhm, firefox seem to be really eager to render <summary> |
| 11:43 | <ondras> | https://jsfiddle.net/8dvht9wz/ |
| 11:43 | <ondras> | (my firefox shows that even before the ::before pseudo-element) |
| 11:43 | <ondras> | shall I file a bug here? |
| 12:40 | <annevk> | ondras: Firefox seems more correct |
| 12:41 | <ondras> | @annevk: interesting.. is this specced somewhere? I would expect ::before to appear before *any* markup-specified content... |
| 12:44 | <annevk> | Oh wait, this is https://github.com/whatwg/html/issues/3805 and per the last comment there I guess it is a Firefox bug (which is reported and has an unreviewed patch from ecobos) |
| 12:57 | <ondras> | @annevk: I see, thanks for the link! |
| 14:40 | <annevk> | MikeSmith: almost wrote "first party trackers" just now |
| 15:20 | <Domenic> | annevk: well, so in a multi-process architecture, container document is nonsense, since you cannot access `Document` objects in another process. Instead, the relevant information (in this case origin) is synced to every process in the frame tree every time it changes. |
| 15:22 | <Domenic> | i.e. every time we cross process boundaries in "synchronous" "browser" spec-code (not posting a task to the appropriate event loop), such as when we access container document, we're effectively saying that browsers need to proactively sync whatever data we access. |
| 15:22 | <annevk> | Domenic: the idea behind container document is that it's some abstract representation of your embedding parent |
| 15:23 | <Domenic> | annevk: sure. So is parent browsing context's active document. |
| 15:23 | <annevk> | Domenic: whereas if you go to the parent browsing context and then the active document it could be anything |
| 15:23 | <Domenic> | I don't see the difference. Both are documents. |
| 15:23 | <annevk> | Yes, but a browsing context could have been navigated |
| 15:23 | <Domenic> | Sure, you need to sync relevant data on navigation. |
| 15:24 | <Domenic> | Every process knows the active document('s origin, etc.) just like they know their container document('s origin, etc.) |
| 15:25 | <annevk> | I don't see how that helps |
| 15:25 | <Domenic> | The dangerous thing is when active document can *change* between steps, e.g. in navigation |
| 15:25 | <annevk> | Active document can change while you ask what it is |
| 15:25 | <Domenic> | But if you have a single synchronous loop (like the XFO spec) then all the data is available and won't change because it's been synced last time there was a navigation |
| 15:25 | <Domenic> | It cannot change during the steps of a synchronous algorithm |
| 15:27 | <annevk> | Fair, but I think where we want to end up is closer to container document |
| 15:28 | <annevk> | Probably more like container document abstraction or some such, but still |
| 15:30 | <annevk> | I guess you're also assuming that the document in which something is being processed is itself fully active or active? |
| 15:33 | <Domenic> | I'm not sure... it's being navigated, but I think you can navigate non-active documents. |
| 15:34 | <Domenic> | annevk: I guess we should also update https://w3c.github.io/webappsec-csp/#frame-ancestors-navigation-response which uses the old "nested through"... |
| 15:36 | <annevk> | Domenic: that was also a concern with source browsing context I think, because if it was ever by a non-active document a lot of the browsing context checks don't add up |
| 15:36 | <Domenic> | That seems like an argument for container document now that I think about it. |
| 15:38 | <annevk> | It generally seems preferable to have a single source of authority rather than a container for sources of authority 😊 |
| 15:38 | <Domenic> | I mean there are cases where checking the active chain is better than checking the creator chain |
| 15:38 | <Domenic> | But they probably don't make sense for inactive documents |
| 15:39 | <annevk> | Can they be different for active documents? |
| 15:39 | annevk | hopes not |
| 15:42 | <Domenic> | They can be different for active documents but not for fully-active ones, I think |
| 15:42 | <annevk> | I think we also have some issues about that distinction |
| 15:42 | <annevk> | Maybe this revived interest in bfcache will help clean some of that up |