| 02:17 | <sefeng> | Domenic: should https://github.com/web-platform-tests/wpt/blob/628af0fd55db95d785a63484882998343e3a069e/html/semantics/interactive-elements/the-dialog-element/dialog-focus-shadow.html#L40-L47 focus an element inside the shadow dom? |
| 02:18 | <sefeng> | because the shadow dom is before the focus-me? |
| 02:19 | <Domenic> | sefeng: Yes I think you are right |
| 02:20 | <Domenic> | focus-me should be moved to the very first button |
| 02:21 | <sefeng> | Domenic: we don't need to move this one, because the one before this template does that already, I think? |
| 02:22 | <Domenic> | Not sure what you mean? I think the test would still be valuable since it shows that autofocus="" is ignored |
| 02:22 | <sefeng> | yeah, sorry, I misunderstood |
| 02:22 | <sefeng> | I'll fix it and ping you for review |
| 02:23 | <Domenic> | Great, thank you for spotting! |
| 02:37 | <sefeng> | Domenic: so before all these generic focus delegates algorithm, when there's a nested shadow dom host with no delegates focus, we don't delegate the focus to this shadow dom. |
| 02:38 | <sefeng> | but now it seems that we can delegate the focus to this shadow dom |
| 02:48 | <sefeng> | I am looking at these two tests https://github.com/web-platform-tests/wpt/blob/628af0fd55db95d785a63484882998343e3a069e/shadow-dom/focus/focus-method-delegatesFocus.html#L271-L284 and wondering which step makes the behaviour different |
| 09:28 | <rdeltour> | Hi. I have a couple questions on how to integrate the URL standard in a specification (ping annevk I guess 😊) |
| 09:32 | <rdeltour> | In EPUB, we now refer to the URL standard. EPUB is basically a collection of web resources in an container (called "Abstract OCF Container"); practically, it's a ZIP. In this container, files refer to each other using relative URL strings (with optional fragments) |
| 09:34 | <rdeltour> | What we'd like to do, is normatively disallow relative URL strings that "leak" outside the container. For instance "../../../../secret" |
| 09:36 | <rdeltour> | So we're trying to define what is a valid relative URL string in the context of EPUB. |
| 09:40 | <rdeltour> | My question is: is it OK to say something along the lines of "in an EPUB container, a relative-URL string MUST be a container-relative URL string", and then define what we mean by container-relative URL string. In other words, we're trying to override the definition of "relative-URL string" of the URL standard by:
|
| 09:42 | <rdeltour> | In some way it has a smell of monkey patching, but I can't see how to do otherwise. That's why I'm asking for advice to y'all 😊 |
| 09:44 | <rdeltour> | see also https://github.com/w3c/epub-specs/issues/1912 |
| 09:50 | <annevk> | rdeltour: have you checked what implementations do? If there is some kind of base URL in play I'd expect it to work similarly to https://example.com/../ |
| 09:51 | <annevk> | I suppose you could still have a desire to say that's invalid, but it isn't invalid for similar URLs in other contexts (if I remember correctly) |
| 09:52 | <rdeltour> | so, implementations vary (EPUB is old and this was largely unspecified so far). We added a UA conformance criteria to specify how the implementation-specific base URL must be. But here we're trying to define authoring requirements (what string is conforming or not, before parsing) |
| 09:54 | <rdeltour> | a conforming UA will parse '../../secret' to the same URL record as 'secret', but we'd still like to disallow the former, for better interop with legacy or non-conforming UAs. |
| 09:56 | <annevk> | It seems somewhat reasonable to write such a requirement the way you proposed above. The one quibble is that URL validity is also part of the URL parser and you wouldn't really be able to change that. (It's written in two different ways for different audiences.) |
| 09:57 | <annevk> | It also seems that long term the requirement would be moot, so maybe it's easier to just explain the situation in a note and strongly encourage folks not to create such URL strings. |
| 10:03 | <rdeltour> | OK good. Yeah, we're only talking of subsetting valid URL strings, so the URL parser would still return an expected result. That it doesn't produce a validation error on some of EPUB-non-conforming strings is acceptable. As for explaining all that in a note: that's what we do in the current WD; but that requirement was normative before, and EPUB is a slow world so I believe a normative definition makes more sense. |
| 10:07 | <rdeltour> | I have another question if I may.
|
| 10:08 | <rdeltour> | the use of test URLs is somewhat inelegant, but is simpler than redefining a custom parsing algo for counting that dot-dot path segments are balanced by other segments. |
| 10:09 | <rdeltour> | any advice or comment ? |
| 10:18 | <annevk> | That seems okay, perhaps with a comment explaining the setup. You'll need to do more serializing if you want to compare strings, but you did say it was simplified. |
| 10:19 | <rdeltour> | OK thanks! (and yes the non-simplified version does serialization) |
| 10:20 | <rdeltour> | Well, thank you annevk for the help. Much appreciated! |
| 14:59 | <zcorpan> | Domenic: apologies for becoming a grumpy old man yesterday, I'll blame lack of sleep and the fact that this has been grinding for a long time lol |
| 16:20 | <Domenic> | I am looking at these two tests https://github.com/web-platform-tests/wpt/blob/628af0fd55db95d785a63484882998343e3a069e/shadow-dom/focus/focus-method-delegatesFocus.html#L271-L284 and wondering which step makes the behaviour different |
| 16:20 | <sefeng> | yeah I see the same thing |
| 16:22 | <sefeng> | ping emilio ^ |
| 16:27 | <emilio> | sefeng: Domenic: Hmm, so per spec I believe you're right (https://html.spec.whatwg.org/#focus-delegate is the relevant section, and it is determining the target area without looking at nested shadow tree's delegateFocus). However I believe we should probably behave like the test? It feels weird that delegatesFocus allows to cross arbitrary shadow boundaries |
| 16:28 | <emilio> | In Gecko what makes it behave differently is this check |
| 16:28 | <Domenic> | I am not sure... can we find an analogy with <input type=date> to help guide the intuition? |
| 16:29 | <emilio> | well we can't because conceptually <input type=date> delegates focus |
| 16:29 | <Domenic> | Or just any semi-realistic example, would help me figure out which direction feels more right. |
| 16:29 | <emilio> | But imagine we have a component that doesn't delegate focus. calling myComponent.focus() won't focus any descendant in the component |
| 16:30 | <Domenic> | Right, that's why it's helpful as an intuition pump... something like <div><#shadowroot delegatesfocus=true><input type=date"></input>.focus(), should focus the inner date textbox, right? |
| 16:30 | <Domenic> | Hmm yeah I think my example is wrong and yours is the relevant one... |
| 16:30 | <emilio> | Yeah, but that's not the difference in those two tests |
| 16:30 | <emilio> | right |
| 16:31 | <emilio> | The test-case would be <div id=outer><#shadowroot delegatesfocus=true><div id=inner><#shadowroot><input></#shadowroot></div></#shadowroot></div> |
| 16:31 | <emilio> | It feels weird that inner.focus() wouldn't focus the <input>, but outer.focus() would |
| 16:32 | <Domenic> | Yeah, that is weird. |
| 16:32 | <Domenic> | OK so we don't want flat tree... we don't want shadow-including descendants... do we want something like shadow-including direct children? |
| 16:32 | <emilio> | We want shadow-including descendants as long as the path to the ancestor delegates focus |
| 16:32 | <emilio> | As in, shadow-including descendants, but without recursing into shadow trees without delegatesFocus |
| 16:33 | <Domenic> | So inelegantly bespoke :P |
| 16:33 | <Domenic> | The spec text will basically need to do a custom tree-walk I guess? |
| 16:34 | <emilio> | Perhaps? You can also do a filter instead looking at containing shadow trees |
| 16:35 | <Domenic> | Hmm yeah I'll play around |
| 16:39 | <Noam Rosenthal> | Domenic: re https://github.com/whatwg/html/pull/7260/files#r755314056, I actually thought as an alternative to do a completely custom fetch, but take out "prepare request from link element" to a separate function... this way we won't have ephemeral state associated with the element. WDYT? |
| 16:41 | <Domenic> | Noam Rosenthal: yeah I thought of that too. I kinda like the ephemeral state bit slightly more, since it makes it more clear this is a special case. But I could go either way. |
| 16:42 | <Noam Rosenthal> | Domenic: OK, yea, I was going backwards and forwards with this but I think it's better to have it in a closure (completely custom fetch, with reusing of prepare-request) as it eliminates weird edge cases of what happens if the element changes and re-fetches before the response returns. |
| 16:43 | <Domenic> | Fair point! |
| 17:11 | <Noam Rosenthal> | Domenic: revised in that spirit (+ fixed/responded to other comments). |
| 19:33 | <Domenic> | emilio: sefeng: so if we stick with our plan of <dialog> using the same focus-delegation logic as delegatesFocus, that means most of the tests in https://github.com/web-platform-tests/wpt/blob/master/html/semantics/interactive-elements/the-dialog-element/dialog-focus-shadow.html change result, since we won't traverse into non-delegatesFocus shadow trees. That seem OK? |
| 19:43 | <emilio> | Unclear if they should use exactly the same steps... But probably? |
| 19:57 | <sefeng> | seems okay to me |