What is the issue with the HTML Standard?

Today we held our weekly triage call (#10941) and I will post the meeting notes there in a bit. The next one is scheduled for February 6, 3pm PST. Note that this is 1 week later in an Americas + APAC friendly time.

People interested in attending the next call please respond here or reach out privately to @past, @cwilso, or the editors. We will be tagging issues for the next call again using agenda+ in all WHATWG repositories across issues and pull requests and we would like to invite anyone that can contribute to join us.

Hi @whatwg/triage, there are no agenda items for this instance. If there are not enough topics by EOD tomorrow, I'll cancel the meeting.

I see 3 new topics were added to the agenda, so the meeting tomorrow is on.

I added a couple topics as well. One that is not in the HTML repo is whatwg/webidl#1465.

Thank you all for attending the meeting yesterday and a special thank you to Joey for taking meeting notes! Here are the notes from this meeting (the next one is at #11010):

Agenda

Attendees: Luke Warlow, Joey Arhar, Stephen Chenney, Mason Freed, Olli Pettay, Chris Wilson, Domenic Denicola
Scribe: Joey

1. Review past action items
   1. Noam to open an issue for the existing blocking styles interop issue.
      1. Noam not here, carry over
   2. Keith to make a big table of loading vs. autoplay vs. preload as the next step for loading=lazy.
      1. Keith not here, carry over
2. Carryovers from last time
   1. [Stephen] Brief update on Canvas text features.
      1. Lang PR Add a lang IDL Attribute to CanvasTextDrawingStyles, and clarify "direction" on same #10873
      2. Extended Text Metrics PR Extend Canvas TextMetrics for editing and text styling #11000
3. New topics
   1. [Mason] The interesttarget attribute/proposal (early draft PR, presentation)
      1. Agreement we should try to move to stage 1, looking for objections in the next week. Explicit ask for Apple/Anne to weigh back in if this problem is worth solving (Chris to poke Anne).
   2. [Luke] Missing attribute changed steps for dialog can cause assertions to be hit (Spec PR)
      1. Mason is generally supportive, will take a look at PRs. Olli also to take a look.
   3. [Luke] Initially open dialog with closedby can be broken (Partial Fix PR)
      1. General support, but prefer the establish close watcher path
         https://issues.chromium.org/u/1/issues/393883102
         https://issues.chromium.org/u/1/issues/393879748
         https://issues.chromium.org/u/1/issues/393834331
   4. [Domenic] Assertion in "hide all popovers until" will fail when changing a showing "hint" popover to "auto"
      1. Discussion will continue on the issue.
   5. [Domenic] A new API for work during unload
      1. Domenic will take the feedback back to the team.
   6. [Domenic] Upgrade QuotaExceededError to a DOMException derived interface
      1. Discussion will continue on the issue.
   7. [Mason] The interactivity property
      1. Carryover.

Action Items

1. @noamr to open an issue for the existing blocking styles interop issue.
2. @keithamus to make a big table of loading vs. autoplay vs. preload as the next step for loading=lazy.
3. @cwilso to poke @annevk on whether the interesttarget attribute/proposal is a problem worth solving.
4. @mfreed7 and @smaug---- to look at Missing attribute changed steps for dialog can cause assertions to be hit (Spec PR).

Minutes

canvas text features:
stephen: The lang pr seems ready to land, final review would be great. have a cl ready to go. apple and mozilla folks could fill in their position so we know that should happen. another pr for extended text metrics ready for folks to start to look at. i'm waiting on metrics related to direction inherit behavior to make sure it's safe to change that in chrome and webkit without destroying the world
domenic: is the direction change in the lang pr?
stephen: The spec already said that it should return the actual value, but chromium and webkit never did. I just have to make sure that there aren't sites out there already relying on this.
lang PR: #10873

interesttarget attribute
mason: issue has been open for some time, recently putting more effort on it. I think it's ready for stage 1. It has an explainer and I've been prototyping it. There's a draft spec pr as well. The main request is to take a look and I would like support for stage 1. I gave a presentation this morning to the joint task force, i can share that if people are interested.
olli: I think it's an interesting proposal. Mobile is weird, that might require more thinking.
mason: requirement for stage 1 is that its an ok problem to try to solve, right?
domenic: yes, the problem is worth solving is the thing we need consensus on. Apple has been skeptical, I don't know if we should wait for them but it sounds like everyone here is pro stage 1.
mason: i've been trying to understand their objection, i changed the solution in hopes they will like it more
domenic: we should ask them for an objection for stage 1 and give them a week
chris: yes. there hasn't been any weigh in from apple since may, right?
olli: I think that's fine. it's possible that if we can't handle the touch handling problem then maybe we shouldn't do it.
chris: as was stated, stage 1 doesn't mean we're committing to a particular solution, just that we're interested in looking at the problem. ill poke anne to get feedback
domenic: we should relay that we're going to stage 1

missing attribute change steps for dialog
luke: light dismiss and request close behavior was added recently. long standing problem where dialogs and the open attribute is a one way data binding. it reflects its state, but if you remove the open attribute it can get it into a weird state. while implementing this in webkit i found that there's spec oddity not just ux oddity. The first one is if you remove the open attribute, it can lead to a crash. chrome avoids this by having steps not in the spec. I think we should add these to the spec. add a minimal set of change steps to the attribute. Joey had a pr that is in some form of progress that did a more complete fix and that should be the end goal, but in the meantime I think these change steps are the minimum we need to get non-breaking behavior. just wanted implementors to look and see if you're ok with that change.
mason: in principle yes. I haven't looked at the PRs. i worked around these cases while implementing
olli: I'll try to take a look tomorrow. chromium bug with same attribute node with multiple ???
luke: it's in my webkit implementation too, but that ones not shipped yet

initially open dialog …
luke: more of an issue because it's the initially open dialog step. there's 3 separate problems. one of them is if you have closedby on an initially open dialog, i think it crashes. that's in chrome but i dont think its in the spec because there's a difference with closewatchers. I think spec wise that bit is fine. The spec problem is if you call requestclose, you end up in a situation where it thinks a closewatcher has to exist but a closewatcher isn't created, so that is a spec problem. I have a pr to fix that. my proposal is just to fall through and call the close dialog algorithm and skip the closewatcher bit - if closewatcher is null then just call close. seems like an ok solution
mason: would it be better to create the closewatcher when its open by default?
luke: yes. i did that requestclose pr as a way to make the spec not broken, but yeah ideally we solve that use case. that might require us to add change steps when the open attribute is added. it may be that when its added we should create a closewatcher if it doesn't exist. i think that solves both the bugs i can think of
mason: did you create wpts for these cases?
luke: the crashes have wpts, the other things ???
mason: I just want to look at the fix in code to see which one looks better. I'm sad that i missed these and mad that i missed these. i will take a look at this hopefully tomorrow
domenic: i support the establishing a closewatcher approach. also i'll say in the past, it does sound like at the end of this process that we end up toggling stuff enough that the boolean is simpler anyway.
mason: chromium has a stored bit
domenic: it was nice and clean before reality happened
luke: there was a separate thing in chromium where the state doesn't update when it should. I have a bug raised but no fix yet. you can wpt the difference.
mason: i may reach out to you separately
luke: one thing i tried to implement it and it crashed
domenic: i wonder if we could have a dialog fuzz tester
Joey: on changed steps for dialog, what's the difference with the PR you made in closing steps?
Luke: my PR destroys the close watcher and removes it from the dialogs list. That's a subset of the closing steps. E.g. it doesn't change the modal bit, it doesn't remove it from the top layer, it doesn't do the focusing steps. My PR matches what's implemented in stable Chromium. But yeah, probably your PR is the end goal.
mason: keeps in the top layer?! sounds scary.
mason: the only reason we're not doing Joey's original full step is fear of compat problems?
joey: spec PR got feedback from Olli that focusing during attribute was bad. I revised to post a task but Olli never got back to us.
Olli: focus needs to be somewhere…
Domenic: related to focus fixup steps, which have some animation frame timing?
mason: if we can do anything, even not moving focus, that's better than the current situation
Domenic: how node removal currently works is https://html.spec.whatwg.org/#node-remove-focus-fixup : no events, just synchronously focus the body. We could do that.
Joey: Sounds good?
Olli: I'm still curious what the a11y people wanted.
Domenic: I think they are mostly concerned with focus location, not the events.
[confusion about what Joey was proposing: focus the body or focus the previously-focused element]
Olli: it's weird to focus the previously-focused element with no events
Joey: Now we have synchronous beforetoggle events. Does that change anything?
Luke: we should check what popover does when you remove the popover="" attribute
Joey + Mason will try to figure out the best solution
Mason: We should go with Luke's suggestion for now.

hide all popovers until
domenic: ladybird implementor ran into assertions
Here's all the open bugs affecting my implementation in Ladybird:
#11007
#10996
#10988
#9457
domenic: maybe we've already discussed these. they would be good to fix.
mason: these are complicated algorithms, there may be corner cases to add
domenic: i just wanted to represent and get it on yall's plate. we've had good success with some things today, and then we're blocked on is this a bug fix, it would be good to get mozilla and webkit to chime in. it would be good to get them to chime in and ratify the fixes we're making
luke: joey worked on a fix for one of them a long time ago
domenic: i don't know if the igalia person is still working on it
luke: I think he worked on the firefox implementation of popover. i don't think he's looking into that at the moment
domenic: i don't know if there's much more to do here besides editor review
mason: 9457 is related to what we're talking about.
domenic: i will turn it over to you to check, unless it's up to me to review
mason: assume nothing yet

new api for work during unload
domenic: this is a common problem, people like putting stuff in unload handlers. currently the best solution is fetch later or beacon api. if you want to do async work before the fetch, like compress something, use webcrypto, you can't do it. The hack people are using is serviceworker because it's allowed to run for 30 seconds after the page unloads, so on unload they postmessage to the service worker, but the service worker is otherwise doing nothing and taking up resources. there must be a better way to do this. we could let shared workers take on this role. The spec says that shared workers can stay alive but it's really short for same origin navigations. we could add a flag to keep it alive for as long as is reasonable. That would be pretty nice and solve this use case. people could spin up the shared worker in the unload handler. I think sharedworkers are more lightweight than service workers.
olli: if the other option is to use some sort of worker that seems ?? This seems very vague how this setup would actually work, but yeah interesting. it overlaps the fetch later and everything, so kind of need to figure out the bigger story
domenic: the bigger story is that it's useful. fetchlater is good if you know ahead of time, but if you have to capture stuff and do async work. Why are you against worklets?
olli: I haven't seen any good use cases for worklets besides audio worklets. very different use case
domenic: we thought worklet could be interesting because it could be a smaller scope than a whole shared worker.
olli: i don't think there's much difference
domenic: i will take this feedback back to the team. might stage 1 it, but no webkit
olli: i need to ask folks at mozilla what they think of this

quotaexceedederror
domenic: this is small but compat affecting. we want to add properties to figure out what the quota is and how much you exceeded it by. we should upgrade quotaexceedederror to a subclass of domexception. This has compat issues but I think they're mostly small. chromium would be willing to try this and see how it works. take the potential compat hit first. but we don't want to do so if other browsers think its bad
olli: there was an internal thread about this, and Yoav said it sounds like a good idea. a bit worried about compat, but if chromium is willing to try it
domenic: no webkit, but we will try to catch them another time