| 04:44 | <MikeSmith> | annevk: I’m confused how an ShadowRoot.prototype.delegatesFocus property ends up being exposed in UAs despite no such property being defined in the IDL at https://dom.spec.whatwg.org/#interface-shadowroot for ShadowRoot, nor being defined for any interface ShadowRoot inherits from |
| 04:46 | <MikeSmith> | I realize there’s an abstract “delegates focus” defined at https://dom.spec.whatwg.org/#shadowroot-delegates-focus but I don’t see how that translates into an explicit exposed property of the object |
| 04:47 | <MikeSmith> | and I realize that there is an explicit delegatesFocus member defined for the ShadowRootInit dictionary, but again I don’t see how that translates into an exposed property of the ShadowRoot object |
| 04:53 | <MikeSmith> | as far as implementations, at https://chromium.googlesource.com/chromium/src/+/refs/heads/master/third_party/blink/renderer/core/dom/shadow_root.idl#36 I see that the ShadowRoot IDL in Blink has a delegatesFocus property |
| 04:54 | <MikeSmith> | ... but I don’t understand why it’s there, since the spec doesn’t seem to define it |
| 05:31 | <annevk> | MikeSmith: in HTML? I thought that got added recently |
| 05:37 | <MikeSmith> | annevk: I am looking at the DOM spec |
| 05:38 | MikeSmith | looks in HTML |
| 05:38 | <MikeSmith> | yeah, I don’t see it HTML |
| 06:16 | <annevk> | MikeSmith: thanks, file an issue? I guess some git log grepping is in order |
| 06:17 | <MikeSmith> | annevk: OK, will raise an issue |
| 06:17 | <MikeSmith> | I did a lot of grepping already, but maybe I’m not looking in the right place |
| 06:18 | <MikeSmith> | but thing is, do we actually need an expsed delegatesFocus property? |
| 06:18 | <MikeSmith> | WebKit implements the requirements in the spec, without exposing any such property |
| 06:19 | <MikeSmith> | but instead just as internal flag, all in the C++ code, without anything in their IDL |
| 06:21 | <MikeSmith> | well they implement the IDL for the dictionary member for the constructor |
| 06:21 | <MikeSmith> | but that just has the effect of setting the internal flag, which is all that the spec requires |
| 06:22 | <MikeSmith> | so given that, I don’t understand what need there is for Blink to expose an explicit property to web content |
| 06:58 | <MikeSmith> | annevk: raised https://github.com/mdn/browser-compat-data/pull/7620 for BCD |
| 07:02 | <annevk> | MikeSmith: I mainly wonder if we discussed it when delegates focus was added |
| 07:03 | <MikeSmith> | ah OK |
| 07:03 | <MikeSmith> | Krinkle: thanks for weighing in on that sendBeacon issue |
| 07:05 | <Krinkle> | I hope I captured it more or less correctly :/ |
| 07:05 | <Krinkle> | starting to doubt myself... |
| 07:05 | <MikeSmith> | heh |
| 07:06 | <MikeSmith> | unrelated general question about the https://github.com/notifications UI: There’s no way to get a view of just the PRs/issues that have been merged or closed, right? |
| 07:07 | <MikeSmith> | I basically would most of the time just want to ignore closed/merged PRs/issues |
| 07:07 | <MikeSmith> | but the way that UI is now, they just get mixed in with everything else, and there’s no option to filter them |
| 07:08 | <MikeSmith> | I tried searching to see if somebody had come up with a browser extension or userscript to add that capability, but I find nothing |
| 07:09 | <MikeSmith> | it’s hard for me to believe there aren’t a lot of people like me who would like to filter those |
| 07:10 | <annevk> | MikeSmith: marking them read or unfollowing them is too much work you mean? |
| 07:12 | <annevk> | It doesn't seem like is:open is an available filter, which is somewhat disappointing |
| 07:22 | <annevk> | MikeSmith: as far as I can tell none of the delegates focus PRs talked about exposing a new member on ShadowRoot |
| 07:24 | <MikeSmith> | annevk: OK, thanks (about the delegates focus PRs) |
| 07:24 | <annevk> | MikeSmith: even in early drafts such as https://www.w3.org/TR/2016/WD-shadow-dom-20161128/ there's no member on ShadowRoot |
| 07:25 | <MikeSmith> | did the blink implementation precede the spec? |
| 07:25 | <MikeSmith> | is that maybe what happened? |
| 07:25 | <MikeSmith> | the spec reverse-engineered the blink implementation? |
| 07:26 | <annevk> | Even in the dglazkov-era it was not there: https://www.w3.org/TR/2015/WD-shadow-dom-20151215/#the-shadowroot-interface |
| 07:26 | <annevk> | No idea |
| 07:27 | <MikeSmith> | OK |
| 07:27 | <MikeSmith> | it needles me to not know how it appeared |
| 07:28 | <MikeSmith> | but I guess I should just let the mystery be |
| 07:28 | <MikeSmith> | ... and get back to slogging through github notifications 😱 |
| 07:28 | <MikeSmith> | and yeah as far as the github notifications thing, manually marking them all read is significant work for me after mostly being away for two weeks and ending up with a giant backlog |
| 07:30 | <annevk> | MikeSmith: I guess you can go through the commit log of Chromium |
| 07:33 | <annevk> | MikeSmith: https://github.com/whatwg/dom/issues/931 |
| 07:34 | <annevk> | (if you click that link you'll have one less notification) |
| 07:41 | <MikeSmith> | heh |
| 07:41 | <MikeSmith> | thanks |
| 07:41 | <MikeSmith> | thanks for raising that |
| 13:34 | <croraf> | I'm checking https://html.spec.whatwg.org/multipage/history.html#the-session-history-of-browsing-contexts and I think it is kind of confusing. In the 3 sentences it of gives two different definitions of the session history. First it says it is a sequence of Documents, then in the third sentence it says it is a flat list of session history entries. |
| 13:35 | <croraf> | Am I right that this should be reworded? |
| 15:24 | <annevk> | croraf: see "topic: history" issues against whatwg/html |
| 16:11 | <hsivonen> | I'm looking at the case where focus is in an iframe and the iframe is navigated. Where does focus go? Firefox says that the newly-loaded document in the iframe takes focus and experiences a `focus` event. |
| 16:11 | <hsivonen> | I don't see Chrome firing the event. Unclear to me so far where focus actually goes in Chrome. |
| 16:12 | <hsivonen> | I don't see spec text covering this. Am I missing something? Does the spec cover this case? |
| 16:13 | <annevk> | hsivonen: I don't recall reading about that case, could well be overlooked |
| 16:14 | <hsivonen> | annevk: OK. |
| 17:10 | <croraf> | annevk, I cannot find the related issue |
| 17:10 | <croraf> | There are 60 history issues |
| 17:16 | <annevk> | croraf: there's a high-level one about redesigning it |
| 17:20 | <andreubotella> | in any case, that specific difference doesn't seem like a bug |
| 17:21 | <andreubotella> | a "sequence of Documents" is the conceptual overview, but in order to formalize it you need metadata associated with the Documents, which is why you have session history entries |
| 17:21 | <croraf> | https://github.com/whatwg/html/issues/2566 this one of yours? |
| 17:21 | <croraf> | annevk, ? |
| 17:21 | <annevk> | croraf: https://github.com/whatwg/html/issues/1454 |
| 17:21 | <croraf> | andreubotella, this conceptual overview is just confusing. |
| 17:23 | <croraf> | annevk, this bug of yours that I linked can be closed I think. To me it seems clear that History is associated with the document, and window.history returns the associated History of its associated Document. |
| 17:25 | <croraf> | DIdnt read the full discussion though, but for the original question it is welldefined (a bit complicated, but I think consistent and) |
| 17:27 | <annevk> | croraf: I recommend reading the issue first then |
| 17:28 | <croraf> | andreubotella, If I go to learn and read the spec, I cannot know if the first sentence is the conceptual overview or the specification, or if the third is an overview or what. It needs to be uniquely well defined. |
| 17:31 | <andreubotella> | annevk: while I was working on the spec changes for the newline normalization in forms, I realized that things were more complicated than we thought |
| 17:32 | <annevk> | andreubotella: oh, what's the thing we forgot about? |
| 17:32 | <andreubotella> | we were assuming there was no way to serialize a FormData object into urlencoded or text/plain, but FACEs let you embed a FormData in a form's entry list as it's being constructed |
| 17:33 | <andreubotella> | and we were assuming there was no way to get a FormData object from a form's entry list in the form submission process, but the formdata event gives you one and lets you modify it |
| 17:34 | <annevk> | Ah, and so then the question is whether the normalization happens or not |
| 17:34 | <annevk> | Hmm |
| 17:36 | <annevk> | That's too much for tonight, but I'm happy to help tomorrow; I guess it might also be worth asking tkent about making changes to how this all interacts, if that would be helpful |
| 17:36 | <andreubotella> | right |
| 17:37 | <andreubotella> | I have tests for how both of those things interact with the changes to the form construction algorithm, should I push them into the wpt PR? |
| 17:38 | <andreubotella> | I assume we're not merging it until the spec changes are merged, so there's no need to mark them tentative |
| 17:44 | <annevk> | andreubotella: sounds good |