| 06:59 | <draginfable> | File an issue. (Looks like you did, https://github.com/whatwg/html/issues/9894 ) But also see https://github.com/whatwg/html/issues/9158 |
| 07:23 | <chargeitall> | You mean ones which will never match without JS doing something? There is no easy way, no. (And :fullscreen can match without JS; you can click the fullscreen button on a <video>, for instance.) |
| 10:55 | <keithamus> | annevk: I wonder if you have an opinion on whether an I have no strong opinions either way on this, other than to get it resolved ;) |
| 10:56 | <keithamus> | Based on your commentary in the above issue, I'd say that given invoke events could occur on a shadow host, then it is reasonable/desirable for them to be composed. |
| 11:00 | <smaug> | (click isn't user input) |
| 11:02 | <keithamus> | because domactivate is? Or because events aren't input? |
| 11:06 | <smaug> | Click is dispatched as a reaction to *down/*up events, or keypress or what not, or one can trigger it using click() etc. Click is quite special. |
| 11:06 | <keithamus> | right yes, makes sense, thanks |
| 11:06 | <smaug> | And in some sense invoke is similar-ish activation event |
| 11:07 | <smaug> | My main question is that if invoke isn't composed, doesn't that lead the user of the component to then usually rely on click? |
| 11:08 | <smaug> | I don't feel very strongly about this. But if it is not composed, then invokeEvent.invoker doesn't need to be retargeted, since nothing should be leaked. |
| 11:10 | <keithamus> | For manual dispatch it will leak but I suppose that's considered okay? |
| 11:11 | <smaug> | well, sure, if you explicitly dispatch composed event. It is like dispatching CustomEvent with detail pointing to something inside the shadow dom. |
| 11:13 | <keithamus> | Right. FWIW I like the idea of making it composed, I think it makes sense especially if we consider the idea of having built ins dispatch invoke events to announce their own internal behaviours (such as a summary opening the details) - it seems to explain those better. |
| 11:15 | <smaug> | Relatedly, are there use cases where one should be able to target host as invokee, and then somehow we'd retarget that invoking operation to something inside the shadow dom? I guess it would mean the component announcing their behaviors. I could imagine <video> inside shadow dom, and then action being "play" or "pause" etc |
| 11:17 | <keithamus> | I would imagine in those use cases you would use scripting to dispatch correctly to elements in the shadowdom |
| 14:24 | <TabAtkins> | The video interface currently has native support for triggering fullscreen mode, but other elements require JavaScript coding to achieve the same effect. I have observed that the :modal pseudo class does not work without JavaScript, which raises the question of which other pseudo classes also require JavaScript to function properly. |
| 14:24 | <TabAtkins> | So like I said, there is no list, and the set will change over time. |
| 18:06 | <Luke Warlow> | :modal also is getting declarative invocation behavior, via the dialog/popover stuff 😃 |
| 22:16 | <smaug> | keithamus: where is the most up-to-date custom state pseudo class spec? |
| 22:17 | <keithamus> | https://github.com/whatwg/html/pull/8467 |
| 22:17 | <annevk> | nicolo-ribaudo: do you know why WPT still has a lot of tests assuming support for import assertions rather than import attributes? That seems incorrect. |
| 22:26 | <annevk> | I filed https://github.com/web-platform-tests/wpt/issues/42875 to discuss further. |
| 22:33 | <smaug> | keithamus: thanks. I just couldn't (and still can't 🙂 ) understand what values can be passed in. |
| 22:34 | <smaug> | I'm probably missing something obvious |
| 22:34 | <keithamus> | An ident production |
| 22:34 | <keithamus> | Or a dashed ident |
| 22:35 | <smaug> | but dashed idents can't be for example --default |
| 22:35 | <smaug> | And I couldn't find in the pr any validation |
| 22:35 | <smaug> | the old spec proposal does have that |
| 22:36 | <keithamus> | I agree |
| 22:44 | <keithamus> | There’s also https://github.com/w3c/csswg-drafts/pull/8213 which says the production is the :state( function followed by a <string> followed by ) but I think that’s a mistake because every example I see discussed does not seem to use quotes and I don’t know why you would; it seems like it should be custom-ident or dashed-ident but I think that should be validated against in the html customstateset class. |
| 22:48 | <keithamus> | In my opinion it should be a production of :state( [[ident] | [dashed-ident]] ) and the spec should validate the given argument to ensure the given argument is either an ident/dashed-ident. This will ensure compatibility/migration with the older proposal which was :[dashed-ident]. |
| 23:02 | <annevk> | I don't understand why we'd validate the API input. We don't validate getElementById() either. And you can type almost anything after #. I agree that Selectors needs to define the syntax formally as an ident, but I don't think any of the other changes discussed here are needed. jarhar did the right thing, the only thing needed I suppose is some change on the Selectors side. |
| 23:23 | <smaug> | yeah, that is one option. I was just looking at a patch which did some validation and was confused. |
| 23:30 | <annevk> | I think reading the PR again an empty string check probably makes sense. We generally don't allow the empty string as identifier so that seems reasonable to follow here as well. |
| 23:35 | <smaug> | but we don't really prevent use of empty strings |
| 23:40 | <annevk> | smaug: fair, we could allow them and not match |
| 23:40 | <annevk> | let me update my comment |