| 04:18 | <jmdyck> | In the HTML spec, in https://html.spec.whatwg.org/#the-source-element (4.8.2 The source element), in the first Note, the phrase "react to changes in the environment" is a link to https://html.spec.whatwg.org/#img-environment-changes. However, if you follow the link and click on "react to changes in the environment", the popup doesn't list the occurrence in 4.8.2. |
| 04:19 | <jmdyck> | This is presumably because the 4.8.2 occurrence is an <a href> rather than a <span data-x>. Is that intentional? |
| 04:25 | <jmdyck> | zcorpan: You added the 4.8.2 <a href> in 9e9a6730 about 2.5 years ago. |
| 04:40 | <jmdyck> | Similarly, in 4.8.5 "The iframe element", at https://html.spec.whatwg.org/#:~:text=Furthermore%2c%20notice , "optional start and end tags" uses an <a href> to link to https://html.spec.whatwg.org/#syntax-tag-omission, whose popup doesn't link back to 4.8.5. |
| 04:41 | <jmdyck> | That one goes back to 2013, before data-x, so I think maybe it evaded conversion to <span data-x> when that came along. |
| 04:42 | <jmdyck> | I think those are the only two such cases. |
| 04:46 | <jmdyck> | Wondering if I should submit a fix for them. |
| 09:39 | <annevk> | Luke Warlow: we had agreement that form pseudo-elements would not expose underlying API details right so ::picker(select):popover-open would not work? |
| 09:39 | <annevk> | I'm seeing WPT tests for the opposite. Working on a correction now. |
| 09:40 | <Luke Warlow> | Hmm it might be worth checking GitHub for usage? But yeah :open::picker(select) does the same job so should be fine. |
| 09:42 | <Luke Warlow> | The picker stuff might have pre-dated that discussion. Also I think currently the fact it's popover is exposed in other ways? The fact it closes other popovers for example. See Keith's recent issue on that. Personally I think it's probably harmless but there's an alternative so I think it's also fine to drop it. |
| 09:44 | <annevk> | I'm pretty sure I said this from the when we proposed ::picker so I'm rather annoyed. |
| 09:47 | <annevk> | I haven't really made up my mind what would be best for Keith's issue. I do think we want consistency between native and base appearance as ultimately that should just be (mostly) appearance. |
| 09:48 | <Luke Warlow> | Isn't this (the picker being a popover) something well defined though? The implementation has to use a popover else there will be differences? It's not something that affects appearance:auto too? I can't remember the discussions when picker originally came up unfortunately. I suspect usage is low and it's changeable. Is this something specified one way or another? I guess it might just be a consequence of picker being a popover? I can't speak for whether chromium will want to change it but I'm fine with it from a css forms perspective. |
| 09:52 | <Luke Warlow> | Hmm it might be worth checking GitHub for usage? But yeah :open::picker(select) does the same job so should be fine. |
| 09:52 | <annevk> | It's a popover, but what pseudo-classes a pseudo-element exposes is a separate matter. |
| 09:53 | <annevk> | For animations maybe? I'm going to change html/semantics/forms/the-select-element/customizable-select/select-picker-animations.html and html/semantics/forms/the-select-element/customizable-select/switch-picker-appearance.html. Will put up a PR shortly. |
| 09:57 | <zcorpan> | jmdyck: I don't recall why I used <a href>, it's clearly inconsistent with the other note that has a normal xref |
| 10:11 | <annevk> | PR mentioned above: https://github.com/web-platform-tests/wpt/pull/57739 |
| 15:11 | <Dominic Farolino> | If you create a cross-origin iframe whose name=foo via the iframe attr, then window.foo should be undefined, right? That's my reading of https://html.spec.whatwg.org/#document-tree-child-navigable-target-name-property-set. I'm asking because it seems no browser follows this; all let you reference the child Window via window.foo |
| 15:35 | <Andreu Botella> | Hey, I'm not sure why the pr-preview isn't working for https://github.com/whatwg/webidl/pull/1568 |
| 15:35 | <Andreu Botella> | I thought it was because the bikeshed build was failing, but I fixed that and it's still not working |
| 15:47 | <annevk> | Dominic Farolino: I wonder if that regressed with the navigable refactor. name=foo should work. The cross-origin frame setting window.name="foo" is what should remain hidden. |
| 15:50 | <Dominic Farolino> | annevk: Just to be clear, by "name=foo should work" do you mean <iframe name=foo src=x-origin> should let the parent reference the child via window.foo? |
| 15:50 | <Dominic Farolino> | I agree we should change the spec to match browsers on this one. |
| 16:00 | <annevk> | Dominic Farolino: yup, you can always address cross-origin iframes, you should just not be able to obtain information from them (though we are bad at that too of course) |
| 16:16 | <zcorpan> | annevk: is https://github.com/whatwg/html/pull/12071 ok now? |
| 16:37 | <Dominic Farolino> | annevk: One thing I'm not clear on is: if the x-origin iframe sets window.name to something new, should window.parent.newName === window from within the iframe? This q is mostly about spec machinery... should window.parent.newName from within the frame succeed bc the targeted frame is same-origin to the one doing the accessing? Or should it fail because the targeted frame is cross-origin to the window.parent object from which the named access is done? |
| 16:38 | <Dominic Farolino> | I'm 99.9% sure it should fail, because we use the relevant settings object in https://html.spec.whatwg.org/#named-access-on-the-window-object:relevant-settings-object for the same-origin check, which disregards the fact that we're "inside the iframe" at the time of access. Sound right? |
| 16:40 | <annevk> | Dominic Farolino: yeah I don't think we could make that work because it also impacts supported property names and such. A good thing to put on the "let's make sure this is tested" list though. |
| 16:41 | <annevk> | zcorpan: shall I do a final review Monday? |
| 16:41 | <zcorpan> | annevk: sounds good, thanks |