06:57
<sideshowbarker>
I guess https://developer.mozilla.org/en-US/docs/Web/API/Window/frameElement ?
so I’m now realizing that while that seems to work in some cases of cross-origin iframes, it returns null in others
06:57
<Noam Rosenthal>
so I’m now realizing that while that seems to work in some cases of cross-origin iframes, it returns null in others
yea this is not for cross-origin
06:58
<sideshowbarker>
yeah I thought it never worked cross-origin — but then I found for the case of the iframe at the end of https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API/Using_the_Notifications_API#replacing_existing_notifications it did actually seem to work
06:59
<sideshowbarker>
but maybe I was just testing it wrong
06:59
<sideshowbarker>
anyway, reverting to just the usual window.self !== window.top
07:01
<sideshowbarker>
oh, cool to see there’s a .top TLD now — recursively appropriate…
07:01
<sideshowbarker>
makes for some good fun and confusion for any technical writer who has to document it
07:02
<sideshowbarker>
kind of a “Who’s on first?” thing
07:02
<sideshowbarker>
“the top top-level domain“
07:02
<sideshowbarker>
or “top top” for short
08:07
<annevk>
frameElement can only work cross-origin when document.domain is involved and the documents are same-site. If you find it does something in other cases I'd love to see a testcase.
08:21
<sideshowbarker>
frameElement can only work cross-origin when document.domain is involved and the documents are same-site. If you find it does something in other cases I'd love to see a testcase.
probably I just made a mistake, when I thought I had it working with the one case
08:21
<sideshowbarker>
I will re-try it and see
08:45
<annevk>
Domenic: Yoav Weiss: shouldn't the introduction of new browsing contexts be done in a bit more coordinated manner? Re: https://groups.google.com/a/chromium.org/g/blink-dev/c/jr2fQUh6xEI/m/Oqge6pPtAAAJ
09:03
<Yoav Weiss>
annevk: Potentially... This effort is still in very early stages AFAIK. I think it'd be helpful for the team if you chimed in on that thread to say what you'd like to see defined for this to be interoperable.
09:14
<sideshowbarker>
frameElement can only work cross-origin when document.domain is involved and the documents are same-site. If you find it does something in other cases I'd love to see a testcase.
so yeah, for the record here, I was mistaken — it wasn’t working cross-origin (I just thought it was) Noam Rosenthal
11:25
<Luca Casonato>
Jake Archibald: I don't want to be a bother, but have you been able to take a look at this? Trying to judge if Chrome would be opposed to this in any way.
12:44
<Ms2ger 💉💉>
Yoav Weiss: hey, do you know if you'll have time soonish to review https://github.com/w3c/resource-timing/pull/302 https://github.com/w3c/server-timing/pull/84 ?
12:46
<Yoav Weiss>
Apologies for my slowness and thank for pinging! I'll review today
12:47
<Ms2ger 💉💉>
Thanks!
15:50
<Domenic>
Domenic: Yoav Weiss: shouldn't the introduction of new browsing contexts be done in a bit more coordinated manner? Re: https://groups.google.com/a/chromium.org/g/blink-dev/c/jr2fQUh6xEI/m/Oqge6pPtAAAJ
Yes, I'm keeping a close eye on that. It seems so far it'll just be an auxiliary BC with some flag on it... not as intrusive on other parts of the stack like browsing context groups / navigation. Although, like prerendering, they will need a lot of API restrictions. (Unlike prerendering, theirs will be simpler as they can just deny stuff, there's no transition-to-a-real-BC phase.) https://github.com/steimelchrome/document-pip-explainer/issues/1
15:53
<architect88>

Hello everyone. I'm working on my first template and can't figure out the nuances of semantic markup (in automatic key).
I apologize if some of the questions are inappropriate.

The first question is about the <aside> tag. How correct is it to place the all sidebar zone in it? because the content of the sidebar can contain a variety of elements, such as widgets, navigation elements, search filters, ad units, etc.

The second question is about the <header> tag.
Here is an example, how correct is it?

<header>logotype \ navigation</header>
<nav>breadcrumbs</nav>
<main>
<article>
<header> <h1>Article title</h1></header>
article content
</article>
</main>

maybe it's better to move the <h1> from the <article> or from the <artcile> and <main>, like this?

<header>logotype \ navigation</header>
<nav>breadcrumbs</nav>
<header> <h1>Article title</h1></header>
<main>
<article>
article content
</article>
</main>

which design is more correct or is it better to do it in a completely different way?

15:57
<annevk>
Domenic: there's another question as to whether it should count as auxiliary or nested from a privacy perspective
15:58
<annevk>
Domenic: depends a bit on whether it can show UI and what that UI would end up blaming as the responsible party, too
16:54
<Domenic>
Well I think the idea is for it to not show any UI (like other PiP windows). Which is pretty scary, so, I'm curious what the security folks say...
17:19
<annevk>
Domenic: so all APIs that could/would trigger some kind of user agent dialog would have to be disabled?
17:20
<Domenic>
annevk: yes, I think so. I don't think the team has done the audit to make sure that lines up well with their plans but I filed the issue to tell them such an audit is necessary.
17:20
<npd>
does "PIP" stand for "next generation of annoying pop-up ads that are hard to close"? ;)
17:20
<annevk>
If there's no UI indicating the origin of the PiP I'd think it would have to be fully partitioned
17:21
<annevk>
npd: I had a similar thought
17:21
<npd>
more seriously, I did find the picture-in-picture explainer. and I am scared about abuse
17:21
<Domenic>
does "PIP" stand for "next generation of annoying pop-up ads that are hard to close"? ;)
I don't think so, unless you can trick a user into pressing play on a video, then pressing the video's PiP button.
17:22
<npd>
well, this isn't just videos any more, it sounds like, and any user gesture can trigger it?
17:22
<Domenic>
Hmm yeah I was under the impression there were more restrictions but maybe that's the case...
17:23
<Domenic>
I guess it closes when the opener closes automatically, that's some slight mitigation...
17:23
<npd>
I guess it closes when the opener closes automatically, that's some slight mitigation...
for sure, although the lack of UI maybe makes it harder to see which pip came from where and how to make it go away
17:25
<Domenic>
npd: annevk: if you were able to file these issues on the repo I think they'd be much appreciated, especially the privacy/partitioning/user prompts one as the full constraints there aren't obvious to me.
17:25
<Domenic>
I can give it a shot otherwise.
17:27
<annevk>
Filed https://github.com/steimelchrome/document-pip-explainer/issues/9
19:05
<completesagalego>
is anyone there
19:07
<completesagalego>
completesagalego:
19:09
<completesagalego>
i go for dinner
19:18
<npd>
https://github.com/steimelchrome/document-pip-explainer/issues/10
19:32
<completesagalego>
what
19:47
<completesagalego>
is anyone there
19:50
<npd>
is anyone there
welcome to the WHATWG chat room. more info here: https://whatwg.org/chat
is this the group you were looking for?
19:57
<completesagalego>
yes it was
20:13
<completesagalego>
ooh cool
20:14
<completesagalego>
angry video game nerd
22:46
<smaug>
Ms2ger 💉💉: what is a Shadow realm?
22:48
<smaug>
aha, /me finds https://github.com/tc39/proposal-shadowrealm/issues/331
22:48
<smaug>
Still don't know what it is , and whether it is related to shadow dom 🙂
22:51
<smaug>
aha, perhaps https://github.com/tc39/proposal-shadowrealm
22:51
<smaug>
confusing name