| 10:01 | <nox> | annevk: Progress woohoo https://github.com/whatwg/html/pull/4354#issuecomment-463566900 |
| 10:12 | <annevk> | nox: \o/ |
| 10:15 | <nox> | annevk: So where am I supposed to look at in the spec for focus handling? :D |
| 10:16 | <annevk> | nox: HTML defines some of it |
| 10:16 | <annevk> | nox: search for "focusing steps" |
| 10:17 | <annevk> | nox: I guess the main question is whether blur is dispatched if you remove an element that's focused (or insert it elsewhere) |
| 10:18 | <nox> | annevk: Aren't they always invoked through a queued task? |
| 10:18 | <nox> | Ah no, ok. |
| 10:21 | <nox> | annevk: https://html.spec.whatwg.org/multipage/interaction.html#focus-processing-model:unfocusing-steps This is the important thing you want me to test right? |
| 10:24 | <annevk> | nox: <input>.focus() getting unfocused by removal and maybe <input autofocus> potentially getting focused by insertion? Though I think the latter does use a task |
| 10:25 | <annevk> | nox: I'm having a hard time coming up with other scenarios for this |
| 10:25 | <nox> | Yeah the latter definitely uses a task. |
| 14:39 | <annevk> | So nobody ever created tests for <iframe name> |
| 14:39 | <annevk> | I should not be surprised, but I am |
| 15:45 | <nox> | annevk: So what I need to try to test for is when blur/focus events are fired, is that right? |
| 16:03 | <nox> | I need to test that https://html.spec.whatwg.org/multipage/links.html#link-type-stylesheet:fetch-and-process-the-linked-resource |
| 16:08 | <nox> | When the spec says "Wait until algorithm asynchronously completes with result", that means we block, right? |
| 16:09 | <annevk> | nox: that step "blocks", yes |
| 16:10 | <annevk> | nox: such a "Wait" statement should only be found in stuff that's "in parallel", except perhaps if it's legacy |
| 16:11 | <nox> | annevk: When is link.sheet updated? |
| 16:11 | <nox> | (For <link rel=stylesheet>) |
| 16:12 | <annevk> | nox: the set of steps that dispatches load, before it's dispatched |
| 16:12 | <nox> | annevk: Do you have a spec link for that? I lost myself. |
| 16:13 | <annevk> | nox: domfarolino has been refactoring |
| 16:13 | <annevk> | and I'm not sure that was ever super well-defined |
| 16:13 | <nox> | annevk: Also not sure whether that matters or not but in https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-reactions we may understand that the callback is immediately invoked, but that's not what happens right? |
| 16:14 | <annevk> | nox: look for "process the linked resource" and how it's defined for stylesheet |
| 16:14 | <nox> | Ok thanks. |
| 16:15 | <annevk> | nox: scroll down to [CEReactions] for the exact timing on custom element reactions |
| 16:15 | <annevk> | nox: they're basically run at the point when IDL returns to JS |
| 16:16 | <nox> | Yeah that's what I gathered, so that can't interfere with the insertion algo. |
| 16:19 | <annevk> | nox: yeah, if you do insertBefore() or appendChild() it's be 1) "actual insert" 2) "this new queue you're working on " 3) "custom element reactions" |
| 16:19 | <annevk> | it'd be* |
| 16:19 | <nox> | https://twitter.com/nokusu/status/1096081486082723841 wtf |
| 16:29 | <nox> | https://github.com/whatwg/html/pull/4354#issuecomment-463693419 My brain is on fire so I'll do something else for the rest of the day. |
| 16:30 | <Ms2ger> | nox, go home, eat a baguette |
| 16:30 | <annevk> | nox: heh |
| 16:30 | <annevk> | nox: so I think most of those are not a problem |
| 16:30 | <annevk> | nox: and done at insertion time |
| 16:31 | <annevk> | nox: except for those that depend on some external resource and are therefore done async |
| 16:38 | <nox> | annevk: You mean before scripts run then, right? |
| 16:38 | <nox> | annevk: But I think Gecko uses their AddScriptRunner stuff for some of them, hence why I listed them. |
| 16:39 | <annevk> | nox: aye |
| 16:39 | <annevk> | nox: interesting |
| 16:39 | <nox> | annevk: See bz's link https://searchfox.org/mozilla-central/search?q=AddScriptRunner&case=true |
| 16:39 | <nox> | (Cursed link tbh) |
| 16:40 | <annevk> | Hmm yeah, maybe I need to reread the thread at some point |
| 16:40 | <annevk> | But I'm pretty sure I tested <iframe> at least |
| 16:41 | <nox> | annevk: At the very least, |
| 16:41 | <nox> | I'm pretty confident that the DOM part of my set of PRs is solid. |
| 16:41 | <nox> | As in, it is enough to encode whatever way Firefox uses their script runner stuff. |
| 17:07 | <Domenic> | annevk: stupid question, how can a Window not have a browsing context? |
| 17:07 | <annevk> | Domenic: see test, hold ref, remove iframe |
| 17:09 | <Domenic> | annevk: that discards the BC, but doesn't remove the reference from Window -> BC |
| 17:09 | <Domenic> | Discarding only removes the reference from UA -> BC, but if there's a JS -> Window -> BC reference, the BC still exists |
| 17:10 | <annevk> | Domenic: hmm I thought it removed all refs as we don’t really deal with such a bc |
| 17:10 | <annevk> | Domenic: so we’d need discarded checks instead? Seems worse, but maybe this is indeed not clear currently |
| 17:11 | <Domenic> | I guess per the tests UAs clear out the name, instead of keeping it? |
| 17:12 | <Domenic> | I'm just a little worried about how much else might assume that every Window has a BC. But those things might be broken in other ways, indeed. |
| 17:12 | <annevk> | Domenic: i think the tests support the notion of the bc not being there, if you look at the setter |
| 17:12 | <Domenic> | Sigh, fractal brokenness. |
| 17:12 | <annevk> | Domenic: stuff either needs to branch on it being there or it being discarded; everything that doesn’t is broken |
| 17:13 | <Domenic> | Well, "being discarded" isn't a well-defined concept (there's no discarded boolean), so removing the reference makes some sense. I'll comment and solicit bz's opinion. |
| 17:14 | <annevk> | closed branch on discarded, but I agree that nulling is our normal way |
| 17:14 | <annevk> | branches* |
| 17:14 | <annevk> | And also agree that branching on discarded is rather silly |
| 17:14 | <Domenic> | annevk: I assume the tests passed in all browsers? |
| 17:15 | <annevk> | Domenic: yeah, though initially I set name after insertion, which explains the other PR 😊 |
| 17:35 | <annevk> | Domenic: if we agree on the null model I can add that concept to the spec inc a red box and then we slowly fix it over time and rebase this PR on top of that |
| 18:36 | <annevk> | Domenic: spec has “Lose the strong reference from document's browsing context to document.” already |
| 18:36 | <annevk> | Domenic: this should all be much more explicit though |
| 18:38 | <annevk> | I might work on that a bit as it’ll prolly keep coming up and seems good to rectify as tighten other lifetime behavior too |
| 18:38 | <annevk> | as we* |
| 19:31 | <Domenic> | annevk: I agree with the null model but would feel more comfortable if jdm and bz signed off. |
| 19:31 | <Domenic> | The spec does indeed sever the BC -> document, but it doesn't say much about the Window -> BC. Even if we define Window -> BC as a macro for Window -> associated Document -> BC, severing BC -> document does not impact that. |
| 19:38 | <annevk> | Domenic: ah yes |
| 19:38 | <annevk> | I wonder if that connection was even considered |
| 19:39 | <Domenic> | This whole mess would benefit from some pictures |
| 19:39 | <Domenic> | Tangentially, it looks like from your tests <embed>s have name="" attributes!?! |
| 19:40 | <annevk> | Yeah, though poorly defined |
| 19:40 | <annevk> | Initially embed did not have nested bcs… |
| 19:40 | <annevk> | In the spec |
| 19:40 | <Domenic> | Yeah it appears to not exist in the spec at all |
| 19:40 | <Domenic> | I'll file a separate bug... |
| 19:40 | <Domenic> | I think the plan for <object> and <embed> is to wait for Flash to die then re-do everything |
| 19:41 | <annevk> | We did add support when we centralized creation of nbcs |
| 19:41 | <Domenic> | Oh |
| 19:41 | <Domenic> | I was Ctrl+Fing "name" and looking at the highlighted instances, but you're right |
| 19:45 | <Domenic> | As jdm mentions, the fact that #concept-document-bc indirects through session history, and session history is impacted by discarding, means... something is happening here. |
| 20:00 | <annevk> | Uhuh, I wonder if we’re still on track for 2022 or whatever it was |
| 20:08 | <Domenic> | Are you talking about Flash's death or REC-worthy test coverage? |
| 20:09 | <Domenic> | Oh, we got actions access somehow. I never got an email. |
| 20:30 | <annevk> | HTML5 being Hixie-perfect |
| 20:59 | <eightfold> | hi. should i put my sitewide navigation <nav> in a <section> if it containers anything more than a heading (h1) and <ul> list of links? |
| 21:04 | <annevk> | eightfold: no hard-and-fast rule, afaik |
| 21:05 | <eightfold> | thanks. as it looks now there’s only a h1 and ul, so sidewide nav should be directly below body it seems. |
| 21:06 | <annevk> | eightfold: sounds fine |
| 21:12 | <eightfold> | any wrapper divs should not affect structural outline, right? |
| 21:27 | <Domenic> | Correct |
| 21:29 | <eightfold> | and (last question i hope), body > main > article > header > 1makes sense even if there’s only one article in main? |
| 21:29 | <eightfold> | i meant: body > main > article > header > h1 |
| 21:30 | <eightfold> | just wondering if i should ditch either main or article in that outline |
| 21:30 | <eightfold> | content in article is blog posts |
| 21:30 | <eightfold> | blog post, singular :) |
| 21:33 | <annevk> | eightfold: either ok |
| 21:34 | <eightfold> | so all of these are ok: 1. main only. 2. article only. 3. article inside main |
| 21:34 | <eightfold> | for my use? |
| 22:01 | <eightfold> | shouldn’t the second example here: https://html.spec.whatwg.org/multipage/sections.html#the-header-element |
| 22:02 | <eightfold> | have a </header> directly after the </nav>? |
| 22:02 | <eightfold> | or is the </header> below ... |
| 22:02 | <eightfold> | ? |
| 22:24 | <MikeSmith> | it’s all up to you |
| 22:25 | <MikeSmith> | none of those elements have any specific presentational effects |
| 22:25 | <MikeSmith> | so you could also just as well use <div>s |