A big thank you to everyone who attended either in person or remotely and a huge thank you to our scribes (Jeremy Roman, Mu-An Chiou, Joey Arhar)! You can find their excellent work below (any errors in the GDoc-to-Markdown conversion are mine).

Attendees

Panos Astithas (Google Chrome)
Dominic Farolino (Google Chrome)
Simon Pieters (Mozilla)
Peter Van der Beken (Mozilla)
Henri Sivonen (Mozilla)
Domenic Denicola (Google Chrome)
Jeremy Roman (Google Chrome)
Noam Rosenthal (Google Chrome)
Brian Kardell (Igalia)
Jonathan Kingston (Duck Duck Go)
Keith Cirkel (GitHub)
Mu-An Chiou (Ministry of Digital Affairs, Taiwan)
Kagami Rosylight (Mozilla)
Anne van Kesteren (Apple)
Joey Arhar (Google)
Chris Wilson (Google Chrome)
Adam Rice (Google Chrome)
Shunya Shishido (Google Chrome)
Jeffrey Yasskin (Google Chrome)
Nidhi Jaju (Google Chrome)
Tsuyoshi Horo (Google Chrome)
Olli Pettay (Mozilla)
Mason Freed (Google Chrome)
Hidde de vries (Invited Expert)
Theresa O'Connor (Apple, TAG, 5 > 2)
Tim Nguyen (Apple)
Nicolás Peña Moreno (Google Chrome) (HTML session)
Christian Biesinger (Google Chrome) (HTML session only)
Ryosuke Niwa (Apple)
Cathie Chen (Igalia)
Dan Clark (Microsoft)
Benjamin VanderSloot (Mozilla)
Benjamin Lesh
Thomas Steiner (Google Chrome)
Yifan Luo (Google Chrome)
Christian Liebel (Thinktecture)
Simon Pieters (Mozilla)
Matthew King (Meta)
Matthew Atkinson (TPG Interactive)
Janina Sajka (Invited Expert)
Daniel Ehrenberg (Bloomberg)
Yoav Weiss (Google Chrome)
Nic Jansma (Akamai)
Michal Mocny (Google Chrome)
Patrick Meenan (Google Chrome)
Carine Bournez
Eric Portis
Shuo Feng (Mozilla)
Westbrook Johnson (Adobe)

Thursday

Process session

Anne van Kesteren (Apple): Please review the code of conduct
Panos Astithas (Google Chrome): Topic is WHATWG processes, starting with specification acceptance stages
Chris Wilson (Google Chrome): https://github.com/whatwg/meta/issues/290
… This is the description of the spec acceptance stages
… attempting to solve a problem in a lightweight, opt-in process
… we don't have to change anything about what we're doing, but additional ways to get features through the spec acceptance process
… we will start tracking incubations earlier, and start trying to get implementer and spec editor buy-in earlier in the stages, reflecting stages used in TC39, WebAssembly, etc.
… you make a proposal (stage 0), people start looking at it and saying "we should solve that problem" (stage 1), iterate on that and at some point there's agreement that we're going to solve the problem and the solution starts looking like the right solution path (stage 2), eventually we are committed to implementing it into the specification (stage 3), shipped (stage 4)
… mostly about getting implementers to pay attention, and giving spec editors something to be pointed at prior to dropping a PR into a spec, which is difficult for larger proposals
Brian Kardell (Igalia): OpenUI is an example where such a process might have helped, we typically don't have WHATWG folks in all of those processes; how does that work?
Chris: There's some questions about how we would pragmatically track things, we don't have all the details of precisely how this would work. You would file issues, and we would have labels that track what stage a proposal is at so it can be tracked.
… either HTML triage meetings, or asynchronously, we would bring proposals before relevant implementers and spec editors
… someone from OpenUI would be responsible for coming and doing that, but it wouldn't get pulled out of OpenUI
… more a mechanism for tracking it, rather than changing for OpenUI works on ideas
Domenic Denicola (Google Chrome): OpenUI is a good case to focus on
… a lot of work has been done over there and then kind of "dumped" and rushing for stage 3
… having these explicit stages makes it clearer how to get buy-in at each stage, encourages more frequent and explicit communication from any incubation group
Chris: In the OpenUI case, part of the disconnect has been that there is acceptance between multiple stakeholders in OpenUI, but though it seems that should translate to WHATWG, we kind of reset the clock on multi-stakeholder acceptance
… want to make sure that they aren't so disconnected
Brian: it was like 1.5-2 years and it was frustrating
Domenic: was similarly frustrating for HTML working group
Chris: you might stay in earlier stages for some time
Brian: OpenUI agrees that we wish we could do it over
Chris: we want better focusing/sharing earlier on, so that they are investigated and we are looking for buy-in
… does anyone see problems with this that we haven't thought of, or anyone object to us trying this?
Joey Arhar (Google): Looking at stage 2 and stage 3, one is a "draft" spec and one is a "complete" spec, I never really had a draft spec, rather we wrote a complete spec and then iterate on it.
… is a draft or incomplete spec useful to anyone?
Domenic: If you don't want to waste time writing a complete spec that might not have multi-implementer support, you could get earlier feedback (e.g. you should share this other algorithm) to save you time.
… if you want feedback on a complete spec, that's fine too
Chris: one difference between stage 2 and 3 is how complete the spec is; you might come in with a complete proposal but you may still be designing a solution at that point
… the other difference is how much multi-implementer buy-in; you might have to build that even if you have a complete specification
… on the other hand, you might have a complete spec and interest from multiple implementers and move quickly to stage 3
Henri Sivonen (Mozilla): is there a way to uncommit from stage 3? I understand that part of the process is vetting it and then going to stage 3?
Chris: the proposal includes a section about regressing stages; you should be able to do that
… engines may commit to a feature and then back out of that commitment; shouldn't be a bad thing to have happen in terms of throwing the process out
Domenic: happens in TC39; a little traumatic for everyone involved, but needs to be something that can happen
Simon Pieters (Mozilla): I like this direction, adds clarity for bigger proposals. The advancing stages text says that advancing requires support from two implementers, which makes sense for stage 3 and stage 4. Advancing from stage 0 to stage 1 should not require so much overhead. You should be able to come in at stage 1.
Chris: part of this was an attempt to make sure we're tracking the same stage identifiers as TC39/WebAssembly
… difference between stage 0 and 1 is relatively slight because bar for stage 1 is not high
… it should be relatively rare that you shouldn't be able to go into stage 1 relatively quickly
Domenic: implementers are committing merely to what the stage signifies, not any more support than required for that stage
… if you show up and all implementers say it's a terrible idea, you probably should get that signal
Anne: should be clear about how this relates to the working mode
Chris: next step is building out how the administration of this process would work; goal is to make this as lightweight as possible, not have elaborate triage meetings to establish stages of each proposal
Noam Rosenthal (Google): we were working before on proposals that eventually got incorporated into HTML, like preload; does this replace that process?
… we didn't know it was going to eventually be in HTML, but it happened later
… unlike ECMAScript, the web platform has many different spec venues
… it's not always clear that WHATWG will ultimately be the right venue
Chris: this is the reason why this isn't a strictly required process, because some features may enter this process when they're already stage 2 but we just need to get the commitment from implementers and editors
… you don't need to enter at stage 0 level because you might have been incubated elsewhere
Domenic: you don't have to use this process at all; if your process works, you can keep doing it
… this process gives you an opportunity to get the buy-in you need
… if you have been incubating in another WG, that's fine
Mu-An Chiou (Ministry of Digital Affairs, Taiwan): what happens to existing issues?
Chris: they can opt-in if they would like, but we're not going to go review each existing issue
… this process allows features to build momentum and buy-in early, rather than waiting until you're at a PR
Mu-An: as someone who has proposed something before, if I weren't here in person, how would I know that this process exists?
Chris: once we flesh out the details, we will update our documentation
Domenic: best idea for an announcement venue is blog.whatwg.org
Anne: Twitter
Chris: contributing guide
Anne: sometimes people ask for updates on issues; could steer them toward this process
Mu-An: I might not have followed those venues, or know that I should check if the contributors guide has changed
Anne: in the current working mode, you have to proactively do things to get a change into any standard
… this gives more structure, but if you're waiting for something to happen, that might take some time
Mu-An: for some proposals, I feel like I've done all I can and not clear how to move forward; if I don't know about this process I might be stuck
Anne: Are you aware of the working mode?
Mu-An: no
Anne: It does provide some steps/requirements for getting changes in; we should be better about creating an issue.
Jeremy Roman (Google Chrome): bot or issue template?
Domenic: prefer issue template UI, new proposal template could give steps, call attention to working mode, FAQ, etc
Mu-An: could we have a bot to identify stuck proposals?
Domenic: there are 384 proposals; don't want to spam the process
Anne: don't want to be spammed with bot comments
Dominic Farolino (Google Chrome): Going from one stage to another has the same requirements the working mode already requires; it seems this encourages people to pay earlier attention to those criteria.
Anne: It's a good comment that we need to be clearer to new people coming in.
… can maybe do that as part of this
… adding an issue template to all spec repos is pretty easy
Joey: adding an issue template sounds like a good issue; the PR template is very nice
Anne: as a reviewer, it helps you evaluate whether a PR is ready
Simon: can also update READMEs
Anne: they are subtly different across the standard, so hard to put them in a central repo
… in particular, the formatting requirements tend to differ by standard
… not a feature, but hard to change
Chris: next steps: I'll work together with editors and implementer reps to figure out how the process of how we do this, and ramp up testing it out in practice
… want to acknowledge that Chris Harrelson had a lot to do with this process and deserves credit
Panos: next topic is process around triage meetings
… we were previously meeting one hour, once per month
… interval was made more frequent – thirty minutes, biweekly
… how do people feel about the current setup?
Domenic: I feel bad that not many people attend the APAC meeting
Anne: now that we are traveling more, I find I end up missing a lot of meetings, mostly because I'm not in the right time zone
… the cadence is okay
Panos: moved to accommodate more time zones about a year ago
Domenic: I can supposedly make 2/3 meetings, but if I travel I'm not always in the right TZ
… Anne and I are watching every issue asynchronously
Noam: I've only joined a few of those; it was unclear what the meeting was
… more interested in a way of synchronously discussing an issue
… need to find issues that it is important to discuss and build consensus
Anne: tend to use triage to call attention to issues that need it
… might have a short back and forth about details, but typically those are resolved offline
… for longer technical discussions, if you feel it would be useful, you can propose scheduling something ad-hoc
… most editors are happy to meet with people to discuss particular things; it just needs to be organized
… not sure a recurring call for that purpose makes sense – create an issue, and let's just do it – creating an issue allows other interested parties to participate
Panos: attendance has gone down; primarily the editors submit issues to the agenda
… meeting is not as productive if we don't have at least one editor participating
… there are exceptions when there are implementation questions to be addressed
… should we cancel meetings without at least one editor present?
Anne: people are welcome to have a discussion without us, but if it's not useful to you, you should cancel
Dominic: if implementers think it's useful without editors present, putting the question to those people might be the way to go
Anne: European summer might have significantly impacted attendance lately
Joey: I've found it useful as long as people from at least two implementers are present
… maybe triage isn't the most descriptive name for that meeting, since it's not literally triage
Noam: more like a "pulse"
Panos: what if we stopped meeting in some of the time zones? I'm not present in APAC and Europe-friendly meetings, are they useful?
Domenic: there have been good APAC meetings, though not recently
Anne: I think European meetings were okay before the summer
Domenic: worry that APAC/America meetings are just Chrome people
Joey: I had the same concern, but Olli said he would join
Simon: US time zone meeting conflicts with interop sync meeting
Anne: has anyone from Apple been attending US meeting?
Panos: Marcos has attended some meetings but hasn't been consistent
… primarily lack WebKit representation in these meetings
… those issues tend to stall for far longer than others
Domenic: current TZ rotation seems okay, but we should consider canceling if attendance seems insufficient
Panos: what about extending the meeting to an hour? Sometimes the conversation would benefit from more time.
Brian: a few times, it has felt like a half hour was too short; it's easier to block an hour and give people time back if necessary
… it felt like some discussions were rushed and could have benefited from more time
Anne: maybe if we have special guests we should have a longer meeting
Domenic: 45 minute meetings have the property that if you can make only the first half, you can just ask for your item to be discussed early
Panos: an hour?
Anne: 45 minutes still gives a sense of urgency
Panos: Google Calendar likes 50 minutes
Anne: OK
Joey: name still confusing
Anne: need another clever name like WHATUP – maybe WHATVC
Joey: should we be directing people at these meetings, or asking them to schedule ad-hoc meetings?
Panos: maybe we should document these meetings so people are aware of them
Anne: can also generalize labels across whatwg repositories, so if someone wants to flag an issue in the fetch repo for example
… or move to whatwg/meta
Domenic: whatwg/html is the focus of so much activity, don't want to add overhead
… I think the label is everywhere, and we can query across them
Anne: OK
Domenic: WHATNOT (navigating open topics) is ChatGPT's suggestion
- Also WHATEVER: engaging various emerging resolutions
- WHATCHAMACALLIT: Confronting Heterogenous Agenda Methodically, Addressing Core And LateraL Issues Together
Panos: what can we do about mostly editors proposing new issues
Anne: people can add agenda+ label and I'm comfortable with, but maybe people don't feel empowered to
Panos: or they don't know about it
[various people]: didn't know about agenda+ label
Mu-An: also wouldn't have felt comfortable joining without knowing someone already
[back and forth about the permissions required to add labels, and to give people permission to add labels]
Noam: encourage people frustrated about an issue to agenda+ meeting, join meeting
Anne: I always feel like there's an option for people to join the chat, but nobody does
Domenic: or they expect quick responses & leave quickly
Dominic: is the triage meeting documented anywhere? Should we formally describe it?
Anne: Okay. It's been successful so might be okay.
Panos: I'll take an action item to improve the docs.
Domenic: Maybe a whatwg.org page or blog post.
Panos: Anne, in a recent meeting, you asked for help with adding labels and triaging issues
Anne: for everyone who doesn't have triage permission, ask me and I can get it for you
… we get a lot of new issues across repos but mainly whatwg/html
… classified as addition/proposal, if they need implementer interest
… additional labels start with topic: that categorize issues by general area
… especially for bugs of some kind, so you can quickly find related issues to cross-link, duplicate, etc
Panos: where should we meet for CSSWG joint meeting?
Brian: their room is much larger
Panos: okay, resolved
Noam: do we find the process of community groups helpful for organizing work about a use case? For example, nobody knows which vector graphics ideas are important to the community?
Domenic: we've used WICG; I don't think you need a new CG per area
… but having a separate repository about your problem space is helpful, which isn't what you get once you're in a WHATWG spec
Noam: it would be helpful to identify a problem space that would benefit from a venue to discuss a certain use case
Anne: that seems separate – Domenic was talking about repositories for proposals, but you're talking about identifying priority problem areas within a topic
… could be useful – we have a lot of worker issues, a lot of canvas issues, not obvious which one to tackle first if you have a spare moment
Noam: could we suggest something like this to point people at when they want attention for their issues?
Anne: we have something like this for Web Components, people who try to drive work in a particular area
… groups like Color (sp?) and OpenUI are focused on new proposals, but a lot of the work we don't get help with is bugs in existing features
… e.g., <canvas> issues around interaction with CSS
Simon: we have topic labels, so people could filter for a topic of interest, but you can't subscribe to a label, just the entire repo
Noam: I don't think this is as much about repo/label/etc, as much as encouraging people to discuss as a community before going to the implementers. Similar to a product manager.
Anne: I would like it if they could identify which issues are most painful.
Brian: even if you don't intend to do that, having some breakout groups or community groups tends to find things that need to be prioritized
… when David Baron brought accordions to OpenUI, we knew about existing issues with summary details
Anne: that's a pattern I want to encourage more – pay off technical debt in an area and get enough credit to introduce something new
… also gives you the experience to avoid introducing similar bugs
Simon: should we document that as a suggestion?
Anne: more of a guideline
Domenic: wish people were more motivated by blog posts
… not everyone has full-time employer sponsorship, don't necessarily have time to work on tech debt
Brian: we have both implementers and non-implementers in OpenUI
Domenic: TC39 has something in this area, an incubation call – if you have an idea, bring it to discuss, figure out next steps, anticipate objections
… it's a lot of work, but would appreciate it
Anne: how often?
Domenic: think monthly, will add a link
- https://github.com/tc39/how-we-work/blob/main/incubator-calls.md
- https://github.com/tc39/incubator-agendas
Noam: maybe we can arrange something quarterly? Might just create work
Anne: I do a lot of active guidance on chat, works best for me.
… synchronous discussion time is trickier, due to personal and work conflicts
Domenic: agree onboarding stuff is clearly a good idea
… something more ambitious would require bandwidth that I don't have
Anne: willing to experiment, but not willing to drive it
Mu-An: as someone who would love to have that, I hope it happens
… I understand how taxing that would be
… maybe useful to say "I want to discuss this" so you can discuss with someone relevant
… chat is more intimidating than you think
Anne: I am open if someone wants to request some of my time
… when it's more structured, it feels like a recurring commitment which is intimidating to me
Mu-An: I was very excited in the beginning of this process and told my friends, but realized I have the resources and know who to talk to at implementers.
… a random person might not have that, but a sign-up sheet would be more accessible
Anne: we already have the WHATNOT call
Domenic: need to balance inclusivity & prescreening
… I typically prefer to stay silent on issues that don't seem viable
… on the other hand, the TC39 incubator call fields all comers, but I don't want to sign up for that
Noam: we could have a needs-incubation label, to mark it as not ready
… we could encourage people with such issues to ask for asynchronous help in chat
Anne: like that idea
Domenic: we have needs-concrete-proposal, but not well-documented
Anne: that feels like a later stage, this feels more like "this needs fleshing out"
Domenic: encourage people to look through all open addition/proposal issues on whatwg/html to get a sense of the range
Anne: even fairly concrete proposals can take multiple years
Domenic: who wants to drive this? Panos? Noam?
Noam: I don't want to overcommit right now
Domenic: in particular, want someone to turn these minutes into concrete action items
Anne: a new issue in whatwg/meta with a checkbox list would be great
… I think I'm willing to sign up to add an issue template to all spec repos.
… and maybe READMEs
Simon: can point people at paths to mentorship, chat
Anne: adding needs-incubation label seems like something we should just do
Noam: I can look at that
[break]

OpenUI session

Panos: three topics proposed, Selectlist element, dialog updates based on popover, invoker
Joey: dialog update may be combined with invoker
… selectlist has been incubating in the open UI group
… the existing select element is not very styleable and can't contain rich HTML
… people build their own from scratch for the above reasons
… selectlist element want to solve the above problems with support for autofill and accessibility
… there are still many open issues but we will be opening an issues in the HTML repository with the explainer
… we may want to discuss the light DOM cloning mechanism
Domenic: can we see some code examples?
Joey: Explainer. <selectlist> contains <option>s. Developers can supply their own <button type=selectlist> to be slotted in the default button location.
… use <listbox> to be used to slot content into the UA shadow root for rich content
… use <selectedvalue> in button slot to show selected value (potential rich content)
… this is where light DOM cloning or other solutions would be needed
Anne: how is this implemented today for <select>?
Joey: text content is copied from the <option>
Anne: That's simple enough.
Anne: Have you looked at duplicating through CSS?
Joey: What does that look like?
Anne: rendering element in multiple places
… There's no existing primitives.
… The alternative is cloning elements, which might be painful.
Joey: I have another issue in open UI about this with Domenic and Mason on this.
… it follows the ARIA practices for combobox.
… <select> currently have
Mu-An: how would that work? Combobox info in the ARIA specification has changed a lot over the past few years. Is it going to use one specific version?
Joey: wasn't aware that there were recent changes; we have a11y people like Scott O'Hara
Mu-An: ARIA WG was just talking about new focuses for 1.4 spec yesterday
Joey: could follow up on, see if they have any feedback
Mason Freed (Google Chrome): in particular, do you know if anything has changed (re. keyboard)?
Mu-An: don't know
Joey: ARIA practices doesn't seem to be versioned, just has an explainer
… who should I ask?
Mu-An: ARIA working group
Hidde de Vries (Invited Expert): APG and ARIA spec are two different things, APG is a "note", ARIA is a spec
Brian: APG is not an official spec document but a demonstration. So look at the ARIA specification instead.
Mu-An: happy to help out with navigating that
Brian: Currently we are only taking the text?
Joey: It used to be, but now it does clone nodes and all the rich DOM content
… it was important to copy the rich content so it appears the same
Brian: Yes. That seems to be important to developers.
Mason: Not only do you need to have rich content, you'd also need to allow people to separately style the cloned nodes as the option.
Brian: duplicating the rendering might cause a11y issues
Anne: you also have to do a clone whenever an option mutation happens
Joey: current prototype only does it when option is selected
Anne: An alternative solution is to clone the element into the UA Shadow DOM
Domenic: we would need to design a new upwards Shadow Root encapsulation for that to work
Anne: This new feature would introduce a number of new problems,
… this might be a path the shield it from the problems that comes with selectlist
Mason: would also be helpful to talk about the problems with cloning
Anne: …complexity around observers, mutations happening while inserted
… it's novel behavior to insert elements while you parse as a side effect
… it happens with custom elements from script, but not when using a built-in element
Mason: would certainly have to define the timing of that
Brain: I feel like the CSS idea can solve this better, to just paint it
Domenic: this can go on the CSS WG agenda
… but I think this would be pretty difficult.
… Tab was pretty optimistic, and assume you use SVG <use>
… but that's not the case, I am not optimistic
Anne: doesn't svg <use> clone?
Domenic: you cannot style the element differently in the two places
Brian: that can but two elements
Domenic: coming up with a model where things have two parents is tricky, not the syntax for describing it
… you can just copy pixels if it's literally the same thing, but that's not the case here
Mason: the majority use case is where the options look different in the two places
Anne: how does SVG avoid the internal shadow root being observable?
Domenic: I don't think it does
- Demo: https://jsbin.com/qavabudoke/edit?html,console,output (in Firefox which does the per-spec shadow DOM implementation of svg:use)
Mu-An: SVG <use> doesn't clone – if you use an element earlier in the DOM and it is removed, all the instances are removed
Anne: right, but as far as I know, some implementations implement it through a shadow root
… they have to clone, even if they might have listeners which clean up the shadow root afterward
… if you clone, you also clone event listeners, perhaps – might run into some fun issues
Olli Pettay (Mozilla): This is basically replacing <select> without multiple
… on mobile you kinda want to use the current mechanism because you want the native popup
Joey: There's an open issue on this. We can provide an option to the developers to opt-out UA styling
… but I also think that if you had styled <selectlist> maybe that's definitely what you want across the board?
Theresa O'Connor (Apple): when a design looks good on the devices I've tested it on, it sometimes turns out the UX is bad on other platforms
… on those platforms, you should probably get the native picker, but the developer didn't opt into that because they didn't anticipate the problem
Anne: I wonder if a way to supply the equivalent text content would enable it, e.g., on platforms like a watch where the rich content might not be suitable to display in a picker.
Joey: maybe there should be an accessible string as well
… Mason mentioned that we can have UA style on mobile to transform the style to make
… selectlist styling more usable on mobile
Mason: Yes this is an option to fix the mobile UX problem, but we are not sure how to do that yet.
Anne: By default, the experience needs to match the other controls. If you use an <input type=text> next to a select element, when it focuses, you can press to go to the next control, but if it has some weird custom experience that would be quite jarring. If the developer goes through the pain of redesigning the entire input experience, that might work, but if they only do it for some elements that might be quite bad.
Mason: in some cases, developer didn't think about mobile; in other cases, they do think about it a lot and want the control to do what they want
Joey: Do we have an open UI issue for this?
Mason: we have several, there is one about "doing all this in CSS" and another one talking about how you might opt in/out of various behaviors, like native picker and UA styles
[select] Should the inner HTML & styles of the selected option be copied into selected-value? · Issue #571 · openui/open-ui · GitHub
Joey: Anyone who has opinions on this we would greatly appreciate them on the Open UI issues.
… I don't think there's anything left we need to talk about in the explainer
… we had talked about the way to use CSS to work around cloning
… I'd like to know more about what the API shape for that would look like
… I don't know what I'd ask to the CSS WG right now
Mason: I just posted an issue in CSS WG
Anne: I don't know if I fully understand the need for users right now. (ability to handle events to give mouseover effects, etc)
Joey: I hope authors would not dig into the child nodes
Anne: That's why I hope we can go with shadow root so you can style it but not change its content
… there's a bunch of challenges, interaction and accessibility
… what are the general requirements? Is it just styling or are there other requirements?
Tim Nguyen (Apple): CSS solution on the issue of using element() doesn't seem great for a11y, because the element() would be more like an image
Anne: <selectedvalue> element would be wrapping it; it creates some kind of render box of its own
Tim: would the CSS solution look like an element with a background-image
Joey: I agree that something like background-image: element(...) would work well
Anne: wasn't suggesting copying pixels, just creating boxes in two places for one element
Domenic: he was suggesting the CSS element() mirroring(?) so there will be two boxes
Anne: was just clarifying
Tim: <selectedvalue> could be a replaced element
Joey: Like a useragent shadow root or?
Tim: up to the UA to handle the display of the element
Anne: Shadow Root can also implement CSS boxes
… if you use shadow root what happens to events
Joey: it being harder to style would also be a concern
… author would want to target the elements inside the shadow root
[Next topic: dialog/popover updates]
Add light dismiss functionality to <dialog> #9373
Mason: this and the next one are capabilities we introduced with the popover API
… people think they can also be used for dialog
… 9373 is about the light dismiss, escape, click away
… many people want this for dialog, modal dialog in particular
… this is very tricky to do
… now that there's the popover API some people also use it in place of modal dialog because these features don't exist on dialog
… so the proposal is to add another attribute to the <dialog> element, "lightdismiss" for example, to get all the popover elements niceness.
Theresa: Ideally developers would just day <dialog> and not have to add a lot of attributes to get desirable behavior; is there a way to get this without an attribute? Are we concerned with compatibility risk?
Domenic: question whether closing a dialog when clicking outside is the right default behavior
… a lot of modal dialogs benefit from being modal because they really need you to do something
Mason: agree, some dialogs really don't want this behavior, and esp. Don't want to break existing ones
Theresa: Makes sense, thanks.
Tim: I wonder if it's better to get popover "modal" functionalities?
Mason: we talked about this a lot with popover; it isn't modal
Domenic: remember popover is a non-semantic low level functionality
… most dialogs you can close out by escape but not by clicking out of the dialog
Theresa: there are two types of dismiss, heavy and light, and heavy for the dialog and light for the popovers
Keith: I have a use case where we might want non-default behavior. When you click on an option under Assignees, Labels, etc., and you click out, we're adding a Save button to each. We cannot retain the behavior where you click outside to save for a11y reasons, but we don't want to keep the behavior where ???, because users might think data has been saved when it hasn't.
Tim: What is the use case for lightdismiss dialog?
Keith: easier way to dismiss the dialog, when action is only presenting you with one forward action that's a good idea – e.g. delete repository, clicking out of the dialog might be a panic action to safely escape the dangerous popup
Tim: Do you actually want the lightdismiss to work in this case?
Keith: yes, dismissal is the "no choice" and we want that to be very easy to access. Having the no choice vs the bad choice having equal precedence in the UI is not affordant to the user.
Theresa: Another example, you might have a modal that's for ToS, any other way than clicking "accept" would be "decline" in this case.
Brian: some kind of dismiss is used in lots of UI patterns, got popular for dialogs, because "away" is a much larger click target than a close button
Keith: assignee/labels/etc are modal dialogs and do trap focus, even though they don't have a visible lightbox
Domenic: does everyone love this proposal?
Tim: my concern is between popover modal and lightdismiss attribute there's a inconsistency
Theresa: could imagine instead of a boolean, making it a DOMTokenList of what kinds of dismissal you want
… don't want to overdesign, not sure what we'll actually need
Brian: maybe someone from open UI can confirm, but there was the notion of lightdismiss early on but there was a lot of difference in how people understand them
Theresa: we can have multiple mode that is not just boolean
Domenic: for example lightdismiss="blah"
Mason: we previously had a token list with a lot of more specific behaviors and it might end up being a footgun, thinking only about clicking but not keyboard
Theresa: it makes sense to bucket the gestures to different default default behaviors
… how confident are we that there are only two?
… if we think there might be a third than we should consider different syntax
Tim: Do we ever plan to add this attribute to an element that is not a dialog?
… otherwise we will have two routes to do lightdismiss, this attribute, as well as popover=auto.
Mason: currently there is popover, dialog, and fullscreen
… dialog is currently is the only use case that has come up for lightdismiss
Anne: form controls already have lightdismiss
Mason: All the pickers are the other examples
Domenic: old browsers implement color pickers as modals
Anne: I suggest lightclose rather than lightdismiss
Mason: lightdismiss is not very well defined right now but developers know what it is but lightclose might be unfamiliar
Domenic: We can change popover specs to refer to light close
Anne: reusing words is good especially for ESL.
Hidde: can update popover spec to align with this terminology too
Theresa: I just said heavydismiss because of lightdismiss, not crazy about either name
Anne: softdismiss?
Theresa: closebehavior="?"
… light/heavy aren't great. Minimal/maximal?
Brian: I interpret them differently.
Theresa: I'm just saying people should put more thoughts into the naming.
Mason: So to conclude, people think this is a good idea? Just more bikeshed needed for the naming
Domenic: please use close.
[Invoker button]
[Proposal] Invoker Buttons - allowing popover/dialog and more to be invoked without JS · Issue #9625 · whatwg/html · GitHub
Keith: I filed 3567. To have a way to close dialog without JS. Now that this behavior exists for popover, I just want it to exist for dialogs.
… invokertarget attribute on buttons with idref.
… Opens a dialog, plays/pauses a video, displays a popover, etc
Theresa: I don't hate it. It dispatches an invoke event, if the author wants to mix other behaviors they can just listen to the invoke event… that sounds cool.
Keith: in addition to a target, there's also an action
Theresa: if the invoke event contains the button then you can just figure out the action
Domenic: better to use event.currentTarget.
Keith: the proposal also includes a hint attribute, play/pause/fullscreen, etc.
Theresa: I think doing something simpler is still fine. For example, detached media custom controls in a semi-declarative way. Probably the simplest thing is that the invoke handler dispatches based on what button you clicked on, and calls the appropriate HTMLMediaElement API.
Anne: that's no longer declarative
Theresa: This is an improvement on what we have.
Keith: one other goal is to deprecate popover target, which has similar behavior to hide/show popovers
Theresa: I want to make this simpler, because I don't like DSLs. if we can use existing platform mechanisms then that would be better than micro syntax.
Tim: micro syntax already exists for popover. Keith's proposal also includes a micro syntax to deprecate popovertargetaction as well.
Mason: several built-in things have similar need for multiple possible actions
Theresa: all these things are distinct though.
Anne: it's just a single string, not a microsyntax; the element either recognizes it or it doesn't
Theresa: Custom Elements have their own way to define this?
Anne: I don't think these are discoverable, you'd just have to write them in the documentation.
Jeremy: Does this duplicate event names?
Domenic: duplicates method names, also want to make sure it's clear that an element with invokertarget causes this thing to happen
Theresa: and the event should be cancelable.
Domenic: events are not causing anything to happen. https://dom.spec.whatwg.org/#action-versus-occurrence
Jeremy: So is this better than onclick=video.play?
Domenic: Keith convinced me that it's because it also has ARIA effects.
Jeremy: Is this going to add a hint to AT by default?
Domenic: there will be have equivalent capability to aria-controls
Mu-An: nothing supports aria-controls today
Olli: about the invoke event, if you click on invoker, then you will have both click and invoke events, you don't need to prevent both events because you can just cancel the click.
Theresa: video elements often have a default play/pause event handler anywhere on the video
Domenic: you're setting up a way to call play() etc, which don't fire click
… click is something the user does, invoke is something the invoker does
Anne: Is this about custom elements?
Olli: the only thing you need to handle is the invoke event, and you can call preventDefault() to prevent
Domenic: so you're saying video elements will invoke itself on play/pause.
Olli: yes, it's invoking itself
… right now, a click implicitly invokes it, but adding the invoke element provides you a way to cancel this
Domenic: clearly good for <input type=file>, where you only want to write one handler – for <video>, it's less obvious
Anne: because you don't know what will happen when the user click.
Olli: you know from the event
Keith: What about for dialogs?
Jeremy: Domenic, I'm not sure whether that behavior depends on controls or not
Anne: For dialog you can have it too? When you click on the backdrop the invoke event gets dispatched as well.
Keith: What if you click inside?
Anne: Nothing, because nothing gets invoked.
Domenic: as I understand Olli's proposal, elements which invoke some behavior when clicked fire invoke events at themselves, including <input type=file> and <video controls>
Brian: What if you have a close button inside of dialog?
Olli: We should have explicit invoke events.
Domenic: are you saying the proposal should be expand to more things? Whenever anything gets invoked the event gets fired?
Brian: can you end up with a cycle?
Theresa: yes, this would require cycle detection
Anne: can we do this incrementally? Handling everything up front seem like a lot.
Tim: I am against rolling this for every element, because then you can't define default action easily. In Keith's proposal, the elements all have clear default invoke actions.
Therasa: Well then those are no-ops, right? For example divs.
Mason: I am also scared of adding them to everything. That has a lot of implications, especially for accessibility.
Anne: button has the default action which is to submit. Then you will have an invoke event on the form element.
… I don't think we have to tackle all of them at once.
Keith: There's another part to this proposal- InterestedTarget attribute, for example, hover, focus, etc. The main use case is popover style tooltips.
… it dispatches an "interest" event.
Theresa: depending on the method by which the user expresses they gain or lose interest in a thing, this can have privacy concerns.
… Right now people can track mousemove events to fingerprint users.
… for transient inputs, with this you will have an explicit way to track this.
Keith: touch screen? Eye tracking?
Theresa: Yes:
Keith: For touch, you can open the popover with a long press on the button and then it would bring up a context menu or something
Mason: For the touch screen it's a long touch.
Theresa: You are using hover as an example though? Long press is an explicit activation but hover isn't.
… in Apple Vision Pro, we have a visual effect when you're gazing at something, but it's not exposed to the page, but if a page wants to have a popover tooltip, it'd want to have that information, but we can't.
Keith: I think what Apple Vision would do would be a gesture that indicates interest?
Theresa: But that'd be the equivalent of long press, pretty heavy-handed for a tooltip, no?
Mason: people build tooltips with hover today, and those tooltips are inaccessible to mobile devices and devices like Vision Pro today – this at least would allow those platforms to expose this in some way
Theresa: when mobile browsers were introduced, a hover didn't exist, and now you have the first and second click.
Keith: For example on GitHub right now the hoverable checks seem to be unusable.
Mu-An: No it works in the way Therasa suggests.
Jeremy: … if these invoker buttons allow you to invoke all the things, and they're not protected, this can expose security vulnerabilities. (bypassing CSP, attribute filtering, CSRF tokens, and other traditional protections)

CSSWG session

[At the CSSWG room: Nervion/Arenal II, Zoom link]

Notes on IRC: #css on irc.w3.org

Agenda: https://github.com/w3c/csswg-drafts/projects/39

HTML session

Panos: topic is [element.setHTMLUnsafe and document.parseHTMLUnsafe](https://github.com/whatwg/html/pull/9538)
Joey: idea is to allow you to (1) parse declarative shadow DOM without it being in the original HTML sent over the wire, (2) support new sanitization APIs that allow websites to take untrusted HTML and parse with various sanitization options
… still have some open TODOs before it's ready to be merged
… open question: does this mean that declarative shadow DOM PR is now unblocked?
Mason: one substantive question we could discuss that Domenic opposed, asking what happens on <template> elements if you use setHTMLUnsafe; does it modify contents or children
… I think it should modify content
Anne: as far as parsing APIs go, that PR is fine
… it should match innerHTML, except for declarative shadow trees
Mason: okay with these two?
[no dissent]
Panos: topic is Declarative ShadowDOM (#8759, #5465, #892)
Mason: the first is now moot
… the other two are a bit out of date, but the point is: what else is needed, besides modifications to incorporate setHTMLUnsafe/parseHTMLUnsafe?
Anne: one oddity in the API is a disparity between open and closed shadow roots for non-custom elements, because they don't have element internals but do have declarative shadow roots, which seems somewhat illogical
Joey: why?
Anne: because there is no way to get hold of shadow DOM that ends up being created
Mason: you can create shadow root and then throw it away
Anne: not the same
Mason: the parity I care about is imperative/declarative; you should be able to do the same things
… I don't want to tie shadow DOM closer to custom elements
Anne: in retrospect we should have, and ElementInternals does
Mason: it gives additional powers to custom elements
… you can create a shadow root with nice slotting behavior etc, without ever needing a reference, using declarative shadow DOM
Anne: don't want to encourage open shadow roots for this reason
Mason: I don't follow; you can do all of this with script
… I think it would be confusing if you couldn't do the same things with imperative vs declarative shadow DOM
Anne: there is no parity – you don't have a handle to it, so you can't do things to it
Mason: the parity is the resultant DOM tree structure; you're saying you can't create a tree with a shadow root on a
declaratively but can imperatively
Anne: I'm not sure we should have had shadow roots for non-custom elements
… I'd rather you use custom elements
Mason: in my personal experience with declarative shadow DOM, 95% of the time I don't need scripted access to the shadow root
… we regret many things about the web platform
Anne: we don't further build on mistakes
Joey: allowing shadow roots on non-custom elements adds complexity? What complexity?
Anne: if we were to design it today, you'd probably only create shadow roots through ElementInternals, wouldn't have a whole boolean that blocks attachShadow
… we ended up designing ElementInternals after shadow roots
Mason: if we were to allow declarative shadow root on <div>, what is the harm?
Anne: closed shadow roots might get hurt
Mason: shadow roots don't have feelings
Joey: you'd be inclined to use open shadow roots if declarative, so you can access the shadow root if needed with script later
… I also tend to prefer open shadow roots generally
Mason: no need to relitigate that disagreement
… limiting access to something that doesn't seem to cause any harm, aside from the fact that we don't like our past choices, seems unnecessary
Panos: is there a future-proof option, that won't foreclose changing our mind in the future?
Mason: I don't think this makes removing shadow roots from <div>s, etc., any harder
Anne: need Olli to weigh in; revisit tomorrow?
Mason: can you ping me when you know this will come up tomorrow?
Panos: expected to be 9:30 am CEST tomorrow; will let you know if that changes
… topic is Define mutation events · Issue #305 · whatwg/dom · GitHub (or remove them)
Mason: is this on the agenda because I have been trying to remove mutation events?
… we could either deprecate and remove them, or define them as much as possible
… the latter option seems tough; they're not interoperable, not only in terms of what events are supported but also how they behave across browsers
… the behavior of those events is also bad for performance and causes bugs, because browser implementers need to worry about mutation event listeners
… usage is high according to Chrome's counters (e.g., 1.8%) but I am willing to give it a shot and see if we can lower that usage
Anne: Have you looked at mutation events that are not interoperable as a starting point?
Mason: Sure. Some events don't exist in Firefox (in-document ones), and many have low usage. There are about three that we could probably deprecate quickly, but the problematic ones are DOMNodeRemoved, DOMNodeInserted, and DOMSubtreeModified (which has quite different behavior across browsers). We don't know which of the behaviors developers are relying on.
… There is the possibility that some can be removed, but I'm not sure that gets us much of the benefit.
Anne: If we have to define them, I'd prefer to define fewer of them.
Mason: DOMCharacterDataModified, [missed one], DOMNodeRemovedFromDocument are probably easier
… does anyone want to speak in defense of mutation events?
[crickets]
Panos: anyone want to volunteer to write the spec for them? Anne?
Anne: I filed it for tracking. We've been wanting to deprecate them since MutationObserver was added, or at least got more serious. That issue keeps track of what we have to do if we're not successful.
… I'm not actively hoping to work on them, though.
… Ryosuke had some concerns. I don't think he had concerns with deprecating them, but didn't see the point because other events fire around the same time.
… In particular, around focus behavior of frames.
Mason: recently, we've been working on a name attribute of <details> to do exclusive accordions
… mutation events were an obstacle, and we had to disable them
Domenic: If all else fails, we could say that mutation events don't fire if any new feature is used.
… This is already true for document.open. In Chrome and Safari, mutation events get permanently off. In Firefox, they are re-enabled on document.close.
Mason: Any objection to using that tool?
Joey: They aren't in the spec in the first place.
Anne: There might be precedent. Security folks have tried similar things, unsuccessfully.
Jeremy: Might we sabotage the usefulness of our new feature, because it breaks ads or some other third-party library by breaking mutation events?
Domenic: That's plausible. 🤷
Anne: The parser doesn't fire mutation events, but does fire mutation observers. In document.open, there is also a step that says "without firing".
Domenic: Can we add a flag with no defined behavior about whether mutation observers fire, without specifying what it does?
Anne: Would you object, Ryosuke, to firing mutation events less?
Ryosuke: 👍
Mason: OK
Panos: topic is [Should we deprecate dialog.show()? · Issue #9376 · whatwg/html · GitHub](https://github.com/whatwg/html/issues/9376)
Anne: you might not want a modal dialog?
Keith: popover answers that
Anne: seems ungainly, looks weird
Keith: makes sense that <dialog> is a container with the role "dialog" which happens to have an API showModal which does focus trapping, and if you don't want that, you can use <dialog popover>
Anne: if invoke triggers pan out, then you can use that to trigger "show" or "showModal"
Mason: there is a difference in behavior; I believe these are superior to dialog.show()
Domenic: I don't think anyone replied adequately to my comment: one of them is top-layer, should every non-modal dialog actually be in the top layer? If you have a modal dialog open and then you do a non-modal dialog, should that really go on top of the modal dialog?
… e.g. modal TOS, non-modal newsletter solicitation
Anne: all four of those things are being addressed already, except for top layer, which Domenic just talked about
Keith: want dialogs to display within showModal – for example, a date picker or tooltip
… a form control tooltip should have role dialog
Domenic: no, I'm saying there are cases where you want a non-modal dialog not in the top layer
Mason: why?
Domenic: sign-up-for-my-newsletter dialog pops up after an inactivity timeout while you're waiting at a modal dialog that you need to take action on
… there are modal things, and non-modal things
… modal things belong in the top layer; not convinced non-modal things do
… would appreciate a survey of how this works in other ecosystems
Mason: in native platforms, they do go under OS windows, but within one application, typically they are on top of everything else
Keith: I think that's a macOS convention; on Linux you do get dialogs over everything
Domenic: In Microsoft Visual Studio 6, the dialogs overlap each other
Keith: if you needed a non-top-layer dialog, what is wrong with display:block, if show() didn't exist?
Mason: my sense is that in almost all cases, show() is wrong and usually it causes confusion
… the cases where you want it, if they exist, are corner cases and developers should be explicit about it
Anne: two questions: (1) usage numbers, (2) what do you envision deprecation to mean here?
Mason: right now, just marking as deprecated in the spec and on MDN
… no specific goal to remove it
Anne: would want to move show() to the obsolete-but-still-required section?
Joey: Chrome use counter 0.04%
Keith: it's quite difficult to explain the nuance between <dialog>, top layer
… top layer is preferable to the nightmare that is z-index when more than one developer's code is involved
… I feel like the top layer covers most non-edge cases
… whereas z-index covers virtually nothing before you get into conflicts
… I don't think I would consider the edge case Domenic mentions if I were the site developer
Mason: I would just like to offer guidance to developers that they should look at <dialog popover>
Domenic: another example – find-and-replace dialogs
… isn't that a non-modal dialog?
Mason: but likely top-layer?
Domenic: don't want light-dismiss
Mason: <dialog popover=manual>
Domenic: OK; semantically feels like a non-modal dialog to me
Anne: feels weird to add a popover attribute to a <dialog>
Joey: the whole reason we moved popover to be an attribute, is because it's not supposed to have semantics and a11y semantics
… a dialog provides a11y semantics; combining them in this way makes sense
Anne: I thought popover would have a11y exposure?
Domenic: no
Keith: invoking button has necessary a11y info
Anne: how does AT tree know something popped up?
Keith: focus moved, invoking button would say aria-expanded=true
Joey: popovers do have an initial focus thing which is defined
Anne: need more data that this is actually what we want to do
Domenic: maybe we could find pages currently using it and figure out if they belong in the top layer or not
Ben Lesh: has anyone checked with authors of popular libraries?
… I would expect library authors to have encountered these scenarios
Mason: they usually put something at the end of the body and use z-index
Panos: topic is Selection API for Web Components (ED, explainer, getComposedRange() review w3c/selection-api#161, Selection APIs for Shadow DOM WICG/webcomponents#79)
Mason: WebKit has now implemented this and written spec; there are some disagreements
… in particular, there's a comment on selection-api#161 that identifies two
… (1) whether we should support multiple ranges for a single range; WebKit & spec support multiple but explainer says 1
… (2) what happens when mutations happen? If a selection ends in light dom content of a host element with a shadow root and that content gets removed, what happens? More precisely defining behavior wrt the endpoints of a range
Ryosuke Niwa (Apple): we went with a multiple range solution because that's how the selection API is defined
… we didn't want to limit the API to single range because in the future when we add multi-range selection, and would need to add yet another API that works with both shadow DOM and multi-range selection
Mason: got it; my pushback is that there is a ton of code on the web that does getRangeAt(0) and assumes that's the only selection, because that's what works interoperably between browser today
… I would guess that plenty of sites ignore all other ranges today; if so it seems like we shouldn't perpetuate it
Anne: both can be true
Mason: we could have getFirstRange, getRest APIs if you know what you're doing
Anne: same effect; there's no magical algorithm that can combine multiple ranges into one
… we also wouldn't redesign the current API if we added multi-range support, we would just instruct people how to use the current API correctly
Mason: we're introducing a new API that won't be interoperable on day 1
… we don't know that need will exist in the future; want to be forward-compatible
Anne: not sure that needs to be a fully interoperable feature; what the user can select and how they can select things is a UI level
Mason: if you're writing an editor component, you want to know, e.g., to implement a Bold button
Anne: should encourage people to iterate over the ranges
… otherwise the editor would already not work on Firefox today
Mason: don't feel super strongly, these bugs would be filed against engines that support multiple ranges, not ours
Ryosuke: the time span of this API getting implemented across browsers, and when multi-range selection is added to another implementation – there's no clear definitive time difference between the two
Mason: for Chromium, new selection API is coming soon, but rearchitecting our selection system for multiple ranges is a big deal and not on our radar
Anne: was selection discussed in the editing group?
Ryosuke: yes; we didn't talk about single vs multiple selection, mostly about the issue that the current spec doesn't cover what happens when DOM mutation happens across shadow boundary, and how selections that span shadow roots
… currently allow that through setBaseAndExtent and ? functions
… we thought it might make sense to define a new concept in DOM which is "cross-shadow range", "cross-shadow live range", which know how to update themselves
… and then selection API can reference that new concept in the DOM spec
Anne: range needs to have an optional pointer to a selection object
… because if you mutate the range, the selection might need to be updated
Ryosuke: a refactor across these specs might be required to reconcile that
Mason: we agree that concept should not be exposed, just internal to those new APIs?
Ryosuke: Yes.
Anne: (consulting with Peter Van der Beken, Mozilla) for WebKit it's important that it's the same as the normal selection API, for Chromium not, Gecko leaning toward it being the same
… when the user has access to multi-selection and the website doesn't support it, that's the concern
Mason: all that's left is the spec questions, otherwise sgtm
Panos: topic is [FedCM Fetch integration](https://github.com/whatwg/fetch/issues/1637)
Christian Biesinger (Google Chrome): Mozilla and others have requested that FedCM's id assertion endpoint needs to be protected by CORS, because that's what gets shared with the RP
… if you use CORS, we have to set the origin of the RP by definition
… because this is a request made by the UA, need to send first-party cookies to the IDP
… right now, Fetch has no way of expressing that; how do we proceed?
Anne: Johann and I had a session about cookie layering, and Ben VanderSloot was also there
… idea was to tackle that mess, but it hasn't been much of a priority so far
… similar fixes are needed for storage access etc
… once we have infrastructure to determine when to fetch cookies from the cookie store and put them in the request, this would just be a couple steps in that algorithm
Christian: so you're saying even if Fetch had a parameter, Fetch would have no way to do it
Anne: correct, there is no infrastructure
… linked you to relevant issues
Nicolás Peña Moreno (Google Chrome): what does this have to do with cookie layering?
Anne: infrastructure to properly describe cookies is necessary
… the layering is currently very bad
… the network layer just grabs documents and does something with them, which doesn't work
Christian: how can we deal with this in the near term?
Anne: do you have spare engineers to work on this?
Christian: not to work on the cookie spec
Anne: ask your management
Christian: right now, this is implemented in Chromium, Mozilla
Nicolás: today we use no-cors in our implementation, and it works
Ben: you specify the Origin header yourselves?
Christian: it's possible the way we specified it doesn't work either
Ben: which is why the new mode seemed like an okay idea
… but with renewed interest in a plan in the layering session, seems less like a good idea
… there was an idea to add a user-agent-no-cors mode, which is scary and a footgun, which says that you can do some no-cors things that aren't very good, but it's okay because it's the browser
[various people listing things]
Anne: and it bypasses ORB
Dominic: does it need to?
Anne: yes
… no-cors doesn't work once there's ORB
Dominic: does ORB block everything that doesn't match a certain number of destinations, or—
Anne: one of the things it does is parses the response as JavaScript, and also as JSON, and if it's JSON but not JS, it blocks
Christian: so providing a regular JSON object would parse as JavaScript?
Anne: tl;dr: JSON would be blocked
… CORS bypasses ORB
Nicolás: do we still need the mode after we add CORS?
Anne: No
Christian: we still need a way to send unpartitioned cookies
Anne: that could be a flag
Dominic: something based on the layering work
Anne: people might not expect cookies on a CORS request
Christian: these are special endpoints
Anne: I know, but these metadata handlers are often reverse proxies that block stuff
Christian: haven't tried sending a new mode through a reverse proxy in use with our partner IDP
Anne: similar with an existing mode with unusual properties
Dominic: what is the blocker here?
… if when the cookie layering work matures, we agree this should be the behavior, is that satisfying?
Ben: Yes.
Christian: if we add a boolean to the fetch spec that says "force-send-unpartitioned-cookies", …
Dominic: i.e., set the site-for-cookies to the request site?
… is Mozilla comfortable with this given the future layering improvements to cookies?
Anne: we still have to check if it's okay to send a CORS request that includes these cookies
Ben: would need to talk with Necko team about that
Dominic: i.e., whether we're comfortable with the security properties?
Anne: in particular in the same CORS mode, so server wouldn't have previously needed to handle this combination
… non-Chromium browsers don't have cross-site cookies
Dominic: presumably those servers support Chromium clients
Anne: yes, but also what it will be like afterward
… just don't know what current fetch metadata handlers care about
Christian: thoughts on this from a security perspective?
Antonio: would have to think about this; properties in this specific case seem fine
… if the alternative is doing the same thing without CORS
Anne: specifically the request mode (Sec-Fetch-Mode)
Christian: this is a blocker for Firefox shipping FedCM, IIUC; we're fine to make a change if it unblocks
Ben: can't make that call by myself
Jeffrey Yasskin (Google Chrome): requestStorageAccess does something similar
… turning on rSA sets the same sort of flag this sets
Anne: that sets it for the whole document
… we only want it for the request, not other requests from the document
Dominic: how do we determine whether we need CORS or non-CORS modes?
Anne: that's why I want Artur's opinion; he knows what servers do with these headers
… adding certain cookies to requests that otherwise wouldn't seems like a big change
… Artur and I are concerned about the future and the far future
Jeffrey: they'd also have to not be considering requestStorageAccess
Christian: so we make a relatively small PR to Fetch spec that adds the boolean?
Ben: first solve cookie layering?
Dominic: if we agree what the PR should do, we can just write it down and wait on the spec PR pending cookie layering changes
Anne: okay to do Christian's proposal
… we can add the necessary field for FedCM, with an issue marker at the point where we ought to use it
Dominic: do we also have an action item to run this by Artur et al?
Anne: yes, you should do that, Christian

Friday

HTML followup session

Panos: topic is Revisit Declarative ShadowDOM with @smaug---- (#8759, #5465, #892)
Mason: yesterday another concern with declarative shadow DOM was brought up, regarding open vs closed shadow roots – specifically, whether we should allow shadow roots on non-custom elements
… my position is that we should, as we do for attachShadow
Anne: because ElementInternals is restricted to custom elements, I think that declarative shadow DOM should be too, because otherwise, declarative closed shadow roots are at a disadvantage to declarative open shadow roots
Olli: what's wrong with having shadow DOM there?
Anne: the problem is that you can get access to the open declarative shadow root from script, but not the closed one
Olli: if you want to use shadow DOM decoratively, I don't see the problem
Anne: we've previously argued if you can't achieve the same things with open and closed, we've decided to design them differently
… since you can do things here with open you can't do with closed, the same thing seems to apply
… I can let this go if everyone else disagrees
Olli: I would expect closed shadow roots to work there
… because they work and it's not harmful
Anne: people might be incentivized to use open shadow roots instead
Domenic: you can't get access to the closed shadow root – that's the point
… the principle that you should be able to do the same things with both didn't make sense to me
Anne: my proposal is to make declarative shadow roots only work for custom elements, where we have a solution – custom elements
Mason: to me, the parity argument that you should be able to do the same things with script and HTML is more compelling
… if we wanted to go that route, we would only allow attachShadow for custom elements
Domenic: restricting to custom elements only for declarative shadow DOM feels like inconsistency in the platform, which I don't like
Mason: declarative shadow DOM doesn't require script, so it seems odd to worry about parity in script
Anne: the ability to get access to it from script is a key use case – hydration
… is this exclusively for custom elements?
Mason: the case where you need to access it via script is typically for custom elements
Olli: I think there are use cases for this without custom elements
… you can just decorate your DOM using shadow DOM, and don't need to script the shadow root
… I understand you are worried about authors choosing to use open shadow roots more
Anne: I think authors don't realize the long-term implications
… the argument would be, if you're doing it for non-custom elements, it won't be a component that will be reused and need to be refactored, which might make it somewhat reasonable
… okay, I think that resolves that question and this unblocks the issue
Mason: some updates are needed to the PR; will do that
Topic: Observables API
WICG/observable: Observable API proposal
Observable API Presentation TPAC 2023
Domfarolino: my coauthor is ben, we are talking about the observable api that we are proposing for the web platform. We are going to talk about observables and how they related to events, integration into web platform eventtarget, and some design details and semantics, then call for input
… before we had promises, the only way we could represent async stuff in the callback was inside the callback, you have to use a nesting relationship to describe the linear flow through which your async values flow through, aka callback hell, not maintainable or pretty.
… promises gave us a handle that represents an async value to be used outside the callback to create a linear flow by chaining .then handlers
… limitation of promises is that they are one shot, they only represent one value. We still have to use that nesting relationship for event listeners. In one event listener we start listening to a second one or remove an event listener etc. Here is an example where we remove event listeners inside another event listener. Very nested
… our proposal is an api called observables, promises but for multiple events. Immediately available handle that represents a stream of events that may be pushed to you asynchronously. Main thing is EventTarget, a .on method for EventTarget, represents a stream of events. What this enables you to do is use a bunch of operators to declaratively describe what you're going to do with the event. We can linearly set up a flow of what happens, and then finally subscribe to add an internal event listener.
… here's another more complicated example where we get an observable for the keydown event, then call flatMap with an inner observable. Arbitrary sequence of combinators, and at the end subscribe
… this is the general idea: declarative lazy flow which describes how events will flow instead of using nesting
… design details: observables are lazy. They don't start subscribing just by being created. When you get an observable it gives you a closure with addEventListener inside. Subscribing is what invokes this internal callback. It will not push or store anything until you tell it to.
… subscribe: when you get an observable what you want to do with it is subscribe. These things get invoked internally with the observable. These methods consume things that get pushed to you, they produce some value. You can pass in an AbortSignal to cancel your subscription to an observable. Observables are multitask, you can subscribe as many times as you want and events will be pushed to you whenever you want, the inner observable gets invoked, and your handlers get run.
… you pass in your next and complete handlers, but the observable that gets created, it is responsible for inside of its constructor taking a callback that gets run when you subscribe, and this function gets a subscriber interface and it has next, complete, error. These push the next value out to the thing you have on the left. Pushes values through the subscriber interface
Ben Lesh: when you subscribe to an observable, they can synchronously emit values. Unlike a promise that has scheduling, it's possible for an observable to sync or async emit. The only trick around that is error handling which the semantic for that is if there is an error is thrown, that can't be sync. You can't put a try catch around an observable.
Dom: the sync delivery part is important for ???. events get pushed to an observable, get invoked like a callback that allows you to cancel events if you want, doesn't provide you any async.
Ben Lesh: when you're using the observable constructor, the premier feature is deterministic memory management. This addTeardown method allows you to define teardowns that must be called if you unsubscribe. The 3 different ways about how you can terminate a subscription are the producer, and the consumer which is whoever called subscribe. The producer can tell you complete i'm not gonna send you values, or I sent an error so I'm not going to send you values. The consumer can abort or unsubscribe, i don't want you to produce values, please tear down and stop
Dom: want to open up for discussion, this proposal has been around for a while and we want to breathe some new life in this. This is the most reacted to standards issue on github based on spec reactions website. We tweeted our proposal and it got really positive developer reception. We want to get some more engagement. Right now the proposal lives in WICG. I would like to resolve some of the big issues and start landing prototype code in chrome at some point and get a pulse from other browsers and the ecosystem.
Ben Lesh: regarding developer hype: there's a group of people that like observables and a group of people who have never heard of. RxJs is what I've worked on and it has as many downloads as lodash, and it's a very similar thing, it's like lodash for events. There's a list of a dozen other libraries that are in the readme where I've linked to readmes of observable like things which take a callback and subscribe. These are big libraries that are cooking their own types and shipping them for everyone. I don't think I should be the sole arbiter of this thing and maintain 50% of all the observables in the world right now. At scale, if you could take that away from me and ship it in the browser, we would save a lot of bytes over the wire.
Dom: our proposal has a sketched Web IDL, including various operators. We can chat about anything, want to open the floor up
Keith: would you like to talk about the relationship to signals?
Ben Lesh: there's different ways to think about things: push and pull. Iteration and calling functions is pull. Observable is a straight push, you subscribe and it pushes values as you. You've got async iterable, that's push and pull. Signals are the inverse of async iterable, it pushes a notification that something has changed but you don't know what, then you have to pull. Observables are more primitive, you could build a signal from it. Their relationship is similar but different. You can't use signals to represent events because they have state. When someone gets notified that's changed there's a state that gets changed there. Observables are generally stateless and better for events
Dom: we envisioned this as a replacement for addEventListener and could be used as a replacement in any scenario you want. Right now, addEventListener dictionary could limit this to the capture parameter. This should be a fully fledged optional replacement, should be able to drop in anywhere you're doing event handling.
Keith: what combinations are you proposing?
Dom: everything has been inspired by tc39 iterator proposal: flatmap etc. etc. etc. takeUntil. These are the ones we've proposed so far, we don't want to do everything that anyone would ever want to do, but want to start with a good set
Domenic: I helped encourage this choice. The goal of being as good as EventTarget, you don't need any combinators at all and you've already done everything EventTarget can do. What do you add on top of that? Starting with iterator helpers is a good baseline. I do think over time we will find more things. RxJs has hundreds, we want to find the ones that are like this is actually something you do so often that we really need to pull those in one by one or two on top of this solid foundation. We want to do full research, is this really as common as we thought over dinner, but that feels like a gradual process.
Ben Lesh: some of these combinators return promises that can make preventdefault difficult. I have seen and implemented every shape of observable you can imagine, and I'd be very malleable to any suggestion. RxJs returns an observable and that's it. To mirror what async iterator is doing
Keith: which ones return promises?
Ben: reduce, find
Dom: equivalent to ones that use a whole iterable instead of producing a lazy observable that can pass through it, flatmap
Keith: does observable have a notion that it has no more values it can send?
Ben: yeah the complete callback is called
Jeremy: the last two for detection return promises
Keith: so they could return observables that return one value
Ben: yeah except forEach, from tc39 to have a means of subscription. forEach is a great way to do that, it takes a callback and you can give it a signal and returns a promise that resolves to void when it completes, or rejects with an error. The original vision was that people were going to use forEach, but the callback gets called synchronously so you can preventDefault
Anne: is there a way to terminate the loop?
Ben: yeah with a signal
Anne: so there's not a return value you could use in a callback?
Ben: no because it returns a promise
Domenic: there are old stackoverflow answers. How do I break out of forEach? I think its just weird
Anne: if forEach is very popular and they don't pass a signal, then they end up leaving the listener forever
Ben: yeah you need linters, but they do that with observables now
Jeffrey: why doesn't this take a type parameter for the type of event
Ben: for the observable, the on method takes a type and gives you a
Domenic: is this a Web IDL question?
Jeffrey: for typescript purposes, all of these functions are going to take a type of object that were passed in when the event fired. Its not represented in Web IDL as a type parameter unlike promises
Jeremy: so you want a type parameter
Domenic: Promise<T> in specs' Web IDL are just documentation, we don't need to add them this time around. Typescript has a good system for adding types for these, you get good type safety, if you're using a language where the type system is actually good, then this is typable
Ben: there are parts of typescript for rxjs
Jeremy: does bindings generator consume promise types?
Domenic: don't think so. we can talk about the Chromium binding generator later :)
Ben: for async types, the only one that people might have a knee jerk for is async iterable, and async iterable is not good for modeling an event target: you pull out a promise and the promise is scheduled so you can't preventDefault. There are two phases you can not iterate, or you have to do something to reject the promise in flight, so those things are deceptively complicated when they start off when they have different operators. Difficult to do at that higher level
Dom: some of the discussion about the typing stuff, I want to mention that we do have in our proposal that an observable can be constructed from another observable, iterator, or promise. Our goal is to make takeUnil take on observable, async observable, specifically with from or conversions. If you have observable in Web IDL it would be converted
Anne: reads funky: observable from observable, means you can pass anything in, but its fine
Ben: rxjs has observable and people started pulling off from and using it directly, there are portions where i "import from from from". Issues where people say why did you call it from? But i didn't name it that
Anne: we have other objects with a from thing
Dom: iterator.from wont take a promise and turn it into an array
Domenic: I thought this was weird, tc39 people say this is fine. This is the biggest from we've proposed
Ben: this is how rxjs has worked for a very long time. flatMap, in rxjs we call it concatMap, people use an async function or generator and it just works which is nice
Anne: I have a concern about the promise returning. I was thinking of service workers. You have a preventDefault like thing – respondWith. We would not be able to use those features there
Domenic: I don't think it is an issue. If you want to use it like addEventListener, just on and subscribe, already at parity. Now, let's look at the observable operators, you can use those. Let's look at every insump. Those are going to create booleans, nothing to wait until on. No problems. This is just about find and reduce, i think it's ok if those don't work. Find the install event and then prevent it. I think filter would be better for that because you're not trying to find a single one. This is a problem just for find and reduce, and having them return a single value is more important
Jeremy: you can rewrite it as filter(...).take(1) anyway
Ben: it will process just one if you filter just one
Domenic: reduce is usually to a non-event
Ben: in my experience, the ones we have there that are returning promises, in rxjs they're ??? reduce isn't very common in the rxjs world. Scan is popular and it's like reduce. It's not in here because there's nothing else like it in the platform, it just happens to be very popular
Keith: its common to debounce events, tc39 had debounce
Ben: I don't recall that being in tc39, debouncing is very common, throttling is less common. It's not in here because it could be added later and it's not an api that people are used to
Domenic: debounce has been brought up in tc39 but they have no event loop
Keith: tricky to get right, libraries exist to do debouncing, seems like a good use case
Domenic: lets to eventarget integration, but then we can do setInterval that doesn't suck
Ben: there's an open issue: debounce, scan, catch. There's a few. Rxjs literally has 100 operators, i took this over 8 years ago. I'm very excited to have an observable with a more refined set of what people should be using vs what rxjs has.
Dom: mozillas in the room. Feedback?
Olli: I'm still trying to understand the whole concept, so different from event handling has been so far. I don't like to say that it makes something. How to apply this to all Web IDL callbacks? Eventlisteners, async eventlistener ???? if there was some way to mutate an observer, it takes a callback like an event listener but its not, how to apply that to this kind of case?
Domenic: i thought we were already ambitions by adding it to all callbacks
Ben: the tc39 has symbol.observable which is weirdly popular today, the idea behind that is like iterable, you can say this has symbol observable on it. You call that and you get an observable. It can be consumed with from. Observable.from or flatmap could consume it. If you add something later, mutationobservers implement this symbol, and therefore you would be able to use it. Kind of different, you define an observer and tell it to observe which causes this subscription, will be challenging
Keith: mutationobserver: takes options. Performing options in the observable, takes a function to perform the operations, unless you pass in a noop function, alternative is to emit that, but if you pass into other call sites, it's a first class implementation so toehers can emit things, it gets very tricky then because how do I as a consumer, how do i as a consumer know if they implemented a callback, mutationobserver can throw and needs the first argument. New mutationobserver needs to change one with or without a callback. I'm defining two sets of behaviors, if i assume it does a have a callback then it throws, but it's throwing far later than where it would throw
Domenic: my instinct is that it's not going to be every callback in the platform. requestAnimationFrame. Those callbacks do not make sense, it's not a repeated sequence. The case of things that are kind of event like but don't use eventtarget like mutationobserver, maybe custom element callbacks, i don't know if were actually going to add an adapter or parallel api, but it would be worthwhile for the champions to say if we did design this from scratch this is what it would look like. Maybe if someone has time they could do mutationobserverv2, writing in the abstract and we know that observables are good fit
Anne: if you make a MutationObserver without a callback, then you could have a property that returns an observable. Like that would already be sufficient. It would get pushed to mutation recrtorks
Keith: how would I know as a consumer ???
Anne: you need an opt in or bridge
Domenic: id just call it MOv2
Ben: I've seen code that creates an observable from other things. The people who use these know really well how to use the constructor to build what they need. The libraries are very tiny. I think just getting a constructor in place would give people the tools to do what they need. What got me started on this a long time ago is websockets. What we wanted at netflix was a websocket observable that errored when it closed. The messages all come from the message handler, you gotta compose all these things into one observable. If you get an error, rxjs has a retry, it sets everything up again.
Keith: we have some complex stuff at github with exponential retry on the server side and it gets hairy without observables
Anne: is there an example of how you compose observables?
Ben: i could add it, one thing that's missing with catch. You can catch the error and returned the same observable resubscribed
Anne: multiple event listeners so multiple observables, handle them together somehow
Domenic: takeUntil takes an observable
Ben: this is really close to what I want, but there's a couple things I don't like. I'd like to have takeUntil for closes and errors to be like oh, if i get an error i want this thing to error. This is with the available tools pretty nice, imo
Anne: in this case in the map, does the close event show up?
Ben: not from takeUntil
Anne: there is a thing where you do want to add those somehow
Ben: the operator in rxjs is what you'd call merge. You'd merge the two together, and both sets of signals come out of the same observable. I did this so i could show off the operators we have, but you could just make new observable and write the same code everyones been writing
Domenic: general issue: we have a few of these message message message error close. It would be cool if we could semi generically turn that into an observable. I don't know how many there are. Websockets itself is turning into astream. Load events, really only one time. Other one is XHR, idk how valuable it is
Anne: in the future it would be stream or observable
Domenic: not clear if we want to build something in
Anne: merge seems useful, key events at the same time
Ben: XHR still beats fetch for upload and download progress, very easy with observable. Fetch version is implement a stream and etc. a lot more advanced.
Keith: message error closed patterns seems good for symbol observable. Please unpack this
Domenic: there's a lot of ways you could do it. If Anne and Olli like merge, that's good feedback. Add it to the short list v1 or v1.1
Panos: Dom you asked for implementor feedback/interest while Anne was out of the room. Anne, any feedback with your WebKit hat on?
Anne: I don't know at the moment
Dom: going back to mutation observer, how would you detect observable. Wouldn't you just check for observable returning a method?
Keith: conjecture is that it is cheap enough to translate in userland, and it gets awkward to figure out how we do this.
Ben: if you find that some huge number of websites are wrapping mutation/resize observer, then everyone could dream up a good api
Keith: i can work with you on that, nuances that need to be looked at
Jeremy: this started in tc39 and now its here. It seems like a lot of this is applicable to promises moved into ecmascript. Is this going to follow a similar path?
Dominic: no, i think this works in the dom spec. https://github.com/WICG/observable#standards-venue It works with addEventListener and AbortSignal. Primitives that all work well with each other in the platform. Shooting for WHATWG for that reason. ?? filed a bug to talk about concerns with the original proposal in tc39, those concerns are satisfied and that aiming this at the web platform. Were happy where it is and i'd like to see it continue in WHATWG
Jeremy: you're trying to match iterator helpers that ecmascript exposes, some overhead calling between c++ and js across the Blink bindings, v8 has optimized ways of doing this efficiently, for both those reasons there's some relationship to ecmascript, but ecmascript doesn't have a cancelation primitive
Anne: it doesn't depend on eventarget
Domenic: AbortSignal depends on eventtarget
Keith: upstream to tc39?
Domenic: not really
Anne: i'd love for them to maintain WebIDL but they won't do it
Domenic: what we've seen is that establishing baseline across (WinterCG)
Dom: we've gotten good feedback from people in node, this would reach the whole ecosystem
Ben: i forgot to mention is that one of the other thing sim excipet about, if we land this in the platform, debugging observables libraries is much more difficult that it would be if it was native code. Callstacks get crazy, anonymous functions. Exciting for people to see in debugging tools.
Domenic: ??? about stack concepts. Are there other dev things? For promises we built promise graph analyzers and nobody used it
Ben: benedict moore and friends built something for async task in console, and it was cool because you could say heres map and filter, but i had to add closures everywhere in the library. I was able to put it in rxjs, but being able to see those things definitively in a stack or console, heres where this thing happened would be quite good, things have fallen out of maintenance. You could visually step through what an observable is doing. Definitely room for things like that.
Domenic: integration with async task tracking would be good
Ben: that would be huge
Panos: It sounds like we have consensus that the problem is worth solving, and is within the scope of the WHATWG.
Domenic: stage process?
Dom: i want to preread the proposal, but probably
Topic is iframe reloading issues (Reparenting iframes without reloading html#5484, Proposal: New method to reorder child nodes dom#891)
Joey: we talked about this in the CSSWG joint session
… one of the requests from the React team was the ability to move things around the tree without cursor moved around, iframes reloaded, video playback stopping, etc
… talked about having a primitive DOM function to atomically move something without those effects occurring
… some feedback from Ryosuke – iframes can't just be moved around
… React said reordering within one parent would be good enough for their use case
… gave up after less than compelling supporting feedback
… order property in CSS, vs actually reordering
… someone in CSSWG did share it being important to be able to move an iframe around the document
… where we are now: open issue about insertion and side effects, which we should resolve first, before this
… there are some compat issues between browsers, spec could be improved
… possible issues with mutation events, want to avoid script running in between
… considering not firing mutation events in this case
Anne: we need to be really clear in the spec and also have shared understanding of what happens when you insert built-in elements, and what happens when you remove them
… Olli mentioned the impact it can have on session history when you insert & remove <iframe> elements, on top of the script execution issue
… once we understand what happens for built-in elements, it becomes much easier to define a move primitive that does some, but not all, of those things
Domenic: from the spec POV, none of this is very hard; there are insertion & removal steps
… but there are some unspecced insertion & removal steps, and subtleties
… if you nail those, it should be easy to spec
… from an impl POV, it might break lots of assumptions
Olli: yes, have to change browsing context tree, session history, window.frames, etc.
Domenic: from a spec POV, window.frames will fall out naturally of what's in the document
Anne: browsing context tree doesn't exist in the spec
Dominic: does any of that actually change?
Domenic: doesn't change
Olli: order changes
Anne: order matters with which iframes to fill with URLs from session history, etc
Domenic: parent.frames[0] changes with reordering etc
Olli: browsing context tree in Gecko is synced across multiple processes, need to reflect those changes everywhere
Dominic: this could be one of the "no mutation events" APIs proposed yesterday

Joint session with the accessibility group

Topic: Consider adding a headinglevelstart attribute html#5033
Slides
Mu-An: a new HTML attribute, a rework of the outline algorithm spec that Anne worked on
… Léonie Watson is looking forward to the outcome of this session
… Why: a lot of sites have UGC that can affect heading structure, which is important to assistive technologies
… [example] GitHub uses <h1> for the heading structure, but then the README on the page also has an <h1>, which disrupts the overall page's heading structure
… previous solution was the outline algorithm with <section>
… proposal was that <section> element would adjust heading level, but doesn't exist in the spec anymore
… proposing headinglevelstart attribute; <ol start> exists and works somewhat similarly
… inside a container with <div headinglevelstart=3>, <h1> turns into an <h3> heading
… right now, people can do this by changing the rendered Markdown output
… but this has a side effect that as the README author, you expect <h1> but GitHub has changed it
… Léonie also pointed out that priority of constituencies favors authors and users
… options: headinglevelstart="3" (my proposal), start="h3", start="3"
… framework authors might also need WebIDL attribute on HTMLHeadingElement to read the actual heading level as exposed to AT
… asked how hard this would be to implement; most of the work seems to be what level to communicate to AT
… looking at WebKit's impl, it doesn't seem too hard
… what happens to heading levels above 6? AT doesn't support it
… Scott O'Hara thinks AT should be updated; I think in the worst case they get aria-level but it has limitations
Anne: presumably aria-level has the same limitations – that levels beyond 6 don't have universal support?
Mu-An: correct
… looking for next steps
Keith: statement that authors can increment in their own code is not true
… we provide README contents on a variety of pages and websites, like GitHub, npm, vscode, each with different heading level structures
… at render time, we don't know what the heading level will be when it's in a document
… we could provide an API to get README at a particular level, but it's not great
Mu-An: GitHub only one heading levels which is 3 (should be 4) in the toolbar to try and limit depth in practice
… comments are also displayed on notification, dashboard, profile, and other pages, each with a different heading structure
… this attribute would fix that
Keith: Markdown is very complex and ambiguous; most sites that use UGC use off-the-shelf Markdown libraries; to my knowledge not many allow you to rewrite HTML in certain ways
… Markdown library features are focused around sanitization but not rewriting
Anne: on the WHATWG side, we replace the number of # as a preprocessing step
… it's not elegant
Keith: we prerender some Markdown because it can be expensive
Mu-An: web a11y is a tricky and neglected area
… we just want to make it easier to get right
Matt King: I chair ARIA authoring guide and agree with Léonie. I do see problems with start levels greater than 3, because you'd quickly run out of the ability to have much of a heading structure in the UGC. That might generate more problems than we're solving. I'd almost rather have a new heading level 1 than have h1 become h6.
… I can imagine scenarios where the user still needs to be able to navigate the page effectively. I don't know what the best way to resolve that would be. I can imagine a screen reader wanting to try and override this value, but I don't know if we want to do that.
… I don't know if we can fix a maximum headinglevelstart value, or provide a validator warning for values greater than 3. We should consider something like that.
Mu-An: It would be good for axe-core to include this in checks. Heading structure checks exist already, and this would be an additional thing to consider.
Domenic: Can include it in dev tools, Lighthouse, Issues panel, etc. It's interesting that you can't go beyond 9.
Matt: It's also a cognitive processing issue. When I have to learn a structure with more than four levels, it is difficult. You can't remember which level corresponds to which section of the page that you're in.
… If I put two levels of headings inside my comments, I know that those will be 4 and 5, but when they get much deeper than that, it's a real burden.
Jeffrey: It looks like this is not intended to affect styling. I just wanted to check that's correct.
Mu-An: Correct. GitHub could use the attribute selector to change styling inside the container if desired. A pseudoselector could be added, but would increase the complexity of this proposal.
Keith: Since we're putting headinglevelstart on the container, we can add suitable styles.
Henri Sivonen (Mozilla): considering that the XHTML2-inspired heading level algorithm didn't get implemented, is there analysis about what caused that not to get implemented, and how does this differ?
… it seems like this involves walking up the ancestor chain and not looking at previous siblings, so potentially simpler, but it seems that both styling and a11y reflection need to work in a performant way
… why would this succeed where the previous thing failed?
Anne: I don't know why the initial algorithm didn't get implemented. Styling was implemented because it was easy, and the ARIA one wasn't implemented because there were no tests and nobody tried.
… I made a revised algorithm that would be feasible, but WordPress and other sites had already used <section> in ways that it would have distorted their existing heading structures
… that seemed like too much of a regression, so we removed it
… styling effects are still there and probably too hard to remove at this point
… I don't think there's any particular implementation challenge with this proposal
Mu-An: theoretically the previous outline algorithm would require knowing section depth to compute heading level
… here you're just looking at the closest parent
Domenic: so if they're nested, I get the innermost start not the composition?
Mu-An: Yes, it's up to the author to adjust if needed.
Domenic: Makes sense. That's consistent with the name.
Olli: How would this work in shadow DOM? Headinglevelstart inside shadow dom, and then slot an <h1> into it?
Keith: It would be ideal if it worked.
Mu-An: Agreed, though it's out of my expertise.
… There are existing ARIA problems with shadow DOM that also need to be resolved. This might be a small addition to that.
Anne: so you potentially leak the existence of the shadow tree
Olli: That's okay
Domenic: you're intentionally giving shadow children an ability to adjust their heading levels
Joey: I'm in favor of just walking the flat tree.
Anne: no, it's not the flat tree
Keith: is it shadow-including ancestors?
Domenic: we will use the right terms when we remember them
Keith: the level isn't currently exposed, unless the WebIDL proposal is also included
… absent that it wouldn't be observable
Domenic: the level property seemed like a good idea
Anne: I don't think that should be the level exposed to AT
… the difference is that we don't want aria-level reflected here
… I'd like this and possibly also a pseudoclass
Domenic: don't be afraid of this
Anne: it should be readonly though
Joey: in chromium, the a11y code is in a separate module that works even when AT is off
Anne: we decided a long time ago that ARIA wouldn't affect HTML semantics, so this attribute should just reflect HTML semantics
Domenic: yeah, and ARIA could override it for AT, like it does for the rest
Mu-An: agreed
Keith: if authors wanted to observe ARIA level, they could just getAttribute('aria-level')
Mu-An: or element.ariaLevel
Anne: for styling, I also added a heading pseudoclass, and I still think that makes sense
… you want to be able to style elements and it would be annoying to write style rules where you have to re-adjust all of the headings
… those long selectors would probably also be less performant than a pseudoclass, and less clear
Olli: would work with shadow DOM, too – otherwise you couldn't select across the boundary
Domenic: would encourage the WG to allow them to land this sequentially
… we've failed before by being overly ambitious
Anne: I already wrote the heading pseudo spec, it's very small
Domenic: 👍
Mu-An: what are the next steps? I know how to write polyfills and WPTs, and am happy to try writing a spec
… Keith also wants to use this
… is this suitable for the incubation stage process?
Panos: it might be too early for the new process
Domenic: Chromium people are happy to implement. Writing the spec PR will be a big contribution.
… if you really want to get the process moving, getting standards positions from Mozilla and WebKit would be good
Mu-An: does this require a spec?
Anne: no
Topic: [Programmatically setting focus navigation start point? html#5326](https://github.com/whatwg/html/issues/5326)
Slides
Mu-An: when you use the mouse cursor to click on a web page, it sets SFNSP to that position
… currently reserved to the browser to do
… Rob Dodson wrote a 2016 blog post about how when the a focus start point is removed from the DOM, its parent becomes the focus start point
… that is great, but this issue has been opened by Alice Boxhall, and has supporters
… this is needed because focus management is very important to web a11y, and currently hacks exist (moving focus) as alternative to setting SFNSP, but they have drawbacks
… currently, developers have to decide where the starting point should be (already a big task, e.g. file container on GitHub)
… if you go back to a parent folder, we want to put focus there, but that is a lot of JavaScript specific to that container which cannot be reused elsewhere
… need to set tabindex, call focus, ensure focus outline doesn't apply, and then remove the tabindex when unfocused
… frameworks have similar workarounds
… proposing document.setSequentialFocusStartingPoint (name to be bikeshedded); alternative proposed by Keith is an HTML sfnsp attribute
… known issues: SFNSP is poorly supported in AT, implementation is very different across engines (Bocoup/Microsoft were saying something about selection APIs)
… Sarah Higley (Microsoft) wrote a blog post about how removed-element change was a win, only because AT technologies do not know about this
… AT not supporting things in the spec is not new
… exposing this to developers would increase the visibility of SFNSP and make focus management less of a hack that you need to paste from Stack Overflow or a blog post
… help make it more of a priority for AT vendors
… because this is polyfillable using the current hack, it would help with a11y in general because it would be easy to do the right thing
Matt: I don't understand why it wouldn't generate a focus event already supported by AT
… why does AT have to do anything special to support this?
Mu-An: it's not setting focus, it's setting where the focus should start after you tab
Anne: the way it's polyfilled does set the focus; existing users would expect focus
Matt: you wouldn't have to do anything special if you did set focus
Mu-An: original proposal from Alice was to add an option on focus function
Domenic: that was an API concern
… the Rich Harris code does set focus as part of the polyfill but then immediately blurs
… the desired user experience is that focus doesn't actually change, but instead when you start moving focus, specifying where it starts
Anne: does it influence where AT starts reading?
Mu-An: current solution does pull focus and AT reads the new focus, but there often isn't a specific thing we want to focus on
Anne: how would it change the UX for an AT user with the polyfill? How would it change with this new API?
Mu-An: when you call the API, nothing will be read to the user
Anne: how does that make the experience different from the polyfill?
… I would imagine today the temporary focus affects the user experience
… is this an improvement or a regression?
Mu-An: goal is mainly to improve the developer experience
… finding the element to focus on is the biggest challenge for developers
Domenic: because you have to pick a focusable element, not the natural starting point
Mu-An: yes, and you need to change the tabindex to make sure it's focusable
… AT experience differs on how nothing is read
Anne: we need a concrete answer about how this changes the user experience
Domenic: Anne wants to know what the user experience in each case is, and which is better
Keith: because we're lacking these devices, we try to return focus to some sensible element which is not necessarily ideal
… we need very explicit intent when we do that
… today, we have many issues where we have to, case-by-case, identify a reasonable place to land
… I don't use AT enough to know what happens, but my understanding is that the nearest interactive element is used
Domenic: it sounds like your intent as the developer is not to change the focus
… and that is not achievable right now
… but from the POV of developer intent, at least, the version with the new API is better
… landing focus on the <body> is an a11y problem, we would prefer it land the SFNSP on some reasonable place so the user doesn't have to restart their entire journey
Matt: I understand the authoring problem, but if we want to make sure developers do the most beneficial thing for the users, we should helping the developer restore the focus to the place where the user last had focus
Keith: certainly for a lot of UI elements like <dialog> then they could land back on the invoker button
… but e.g. in a file explorer, the entire old tree is gone due to the SPA navigation
… it's hard to precisely maintain the last focus point
Matt: even if you recreated the old tree, the document cannot save that state because the element doesn't exist anymore
Keith: we could try to keep some kind of reference in localStorage, I think there a lot of hacks, or we can try to find a general solution to at least keep it within a container
Simon: we want to figure out the ideal AT behavior when using this API, how it should affect AT reading
… ATs have an invisible virtual cursor, if this API gets called on another API, should the a11y cursor stay where it is, or move to the SFNSP
Mu-An: to move it
Keith: some move the cursor to where the SFNSP is, and some don't
Simon: then we bug the AT vendors about this issue
Keith: we still don't have a primitive to programmatically set the SFNSP
Simon: we should still be explicit about what the ideal behavior is, and what the current behavior is, e.g., wrt the reading position
… it sounds like this will make it less bad for AT users today
Mu-An: wrt current workaround where we use focus, in the issue there is a lot of back and forth between Alice and Maciej about that
… suggest reading issue for the reasons
… what is the next step? I could write a polyfill. I could propose this to the ARIA WG and ask what their experience is
Domenic: Chrome people think this is easy to implement; please write the spec
… exposing a primitive that the spec uses in a few places is useful and good
… yes, we should fix AT bugs and test, but it's also just good as a primitive, even though it's low-level
Olli: on API, why can't we reuse the existing focus node
Keith: when there's an SPA style navigation, container is gone
Olli: JS selection APIs expose this information, albeit not in Chrome
Topic: Symbols in web content
Matthew Atkinson: firstly, on heading levels, we've been looking at exploratory work on different ways of navigating with media IG and ePub
… that might come to WHATWG at some point
… we're happy to discuss our proposals in more detail afterward
… passing out physical fliers with symbols in the content that help you understand it
… text content on both side is the same, but symbols are different
… this is an analogy for how people use symbols to understand content
… this is the opposite of symbols for communication – symbols to understand what some content means
… there are hundreds, if not thousands, of symbols – we've used Blissymbolics, which is a language using symbols
… the other, ARASAAC, is popular in the alternative communication world and was funded by the local regional government here in Spain
… we asked for the means to bring this to HTML
… the challenge is that you can't just add images to the web page because you don't know which symbols the user understands – you need a mapping
… Bliss has the most comprehensive symbol dictionary, which we're using as the source of truth
… we propose a markup attribute to identify a content attribute, and the user agent automatically picks the symbol to display
Janina Sajka: working on getting reliable numbers – successful in communication, but not in web content
Matthew: started prototyping how this would work
… symbols appear above the words
… you might use fewer symbols, or more likely, for our core users largely accessing videos, in the chapter titles
… seeking implementations and authoring tools
Janina: registry to manage which symbol set gets displayed to a user
… we think we have the main concepts, but need a process for how these symbol sets are updated
Simon: it seems to me these are symbols as a language; have you considered proposing these to Unicode?
Matthew: I'll send a link with more detail; the Bliss symbols are expected to go into Unicode
… so why don't we just use those glyphs?
… we're not the experts, but there are technical reasons we can't just use those Unicode code points as the lookup w3c/adapt#240
… original poster was happy with the resolution, that we couldn't use Unicode
Janina: reporter was satisfied with the response about why that wouldn't be a suitable database key
… we want to provide a mapping into various symbol sets
Matthew: Unicode seems superficially the logical place to go, but the issue explains why that's not possible and I can't concisely summarize why
Anne: it doesn't seem to answer, but I should read it more
Janina: came up with Apple, media group, etc.; if the explanation there isn't clear enough, we'll continue
Jeffrey: I'm worried about the adapt symbol={number}, seems difficult to deal with in HTML source because it basically has to be tool-generated
… is there a technical reason why human-readable names aren't used?
Matthew: Bliss use those numbers and we use them in our registry; if we did use names then we might run into issues with some names being very long, or i18n issues
… we can ask Bliss if there is a different way to refer to them
Anne: I've read Russell's summary and disagree but can't reopen the issue; only repo owner can
Matthew: we welcome your input; please comment
Daniel Ehrenberg: did you get commentary from Unicode consortium?
Matthew: if you just put Unicode glyphs in there, you still need the attribute
… because you can't turn them on/off or control who sees them otherwise
Topic: Pronunciation
Matthew: Educational providers need TTS engines to pronounce content in the right way
… you might be learning, e.g., how English was spoken hundreds of years ago
… there is no different language code
… we identified seven use cases for what we need to be able to do for pronunciation
… 4/7 are critical, we've been talking to other groups like ARIA, who have slightly different lists of which they consider critical
… still in exploratory stage, currently looking at two different proposals
… we have been asking the industry and particularly AT vendors for their views
…. (1) put pronunciation information in some serialized form inside an attribute attached to an element
… (2) support SSML (speech synthesis markup language) in HTML directly, like MathML and SVG
… the first would allow passing off parsing/processing to the AT, if the TTS engine supports it
… the second might be architecturally cleaning, but means admitting SSML into HTML, which is a big ask
… have feedback from some AT vendors, still awaiting feedback from some TTS/assistant providers
… we think we might have come up with an approach that brings them on board
… we wanted to gauge the feeling in the room about whether you would object to or support either of these proposals
Janina: goal is consistent, reliable pronunciation across operating environments
… some TTS won't, but others will if we can give them consistent guidance
Simon: both of these will require new HTML attributes
Matthew: we don't know what the consensus is, looking for WHATWG's take
Janina: need it in the educational assessment environment, but useful beyond AT with the prevalence of digital assistants (curb cut)
Jeffrey: have you looked at how the <ruby> element could help, or if it's not related?
Matthew: might help with symbols stuff, but for pronunciation I don't think it's related
Domenic: it is related but I don't think it's powerful enough for your needs
Matthew: I don't think we've looked at that
Jeffrey: not a complete fix, but might be part of the solution
Henri: <ruby> is about visual presentation; if the intent is to deliberately not render the pronunciation visually, then is that essential? If so, why?
… would it be bad to have IPA in <ruby>?
… SSML seems really verbose and domain-specific; if you have a document where you have an occasional word which needs a pronunciation override, naively you would think the IPA pronunciation is sufficient (as when you look it up in a dictionary)
… why should it be SSML, which seems very verbose?
Matthew: yes it is intended to be non-visual, because it's for TTS engines to interpret
… we might not even be in a visual context, we might be in a conversational interface
… why SSML instead of IPA? IPA does not allow us to do everything that we need to, in terms of pauses and intonation; see gap analysis
Dan: SSML has a lot of capabilities; is this something that could be handled by more language subtags?
… what capabilities do you actually need?
Matthew: gap analysis documents critical use cases
… SSML does do more than what we absolutely need; on the other hand, proposals in other groups would preclude us from doing some things we think are critical e.g. pausing
… SSML exists and is well-specified
Domenic: have you considered doing this as CSS? It seems presentational, not semantic
… CSS has a speech module which is unimplemented
… feels like a better fit to the data model, where you're attaching a lot of data to spans
Matthew: talking with CSS about speech later
Domenic: if you were to make this first-class in HTML, I would take an approach that is much more minimal and does as little of SSML as you need
… you have a whole alphabet choice; can we have only IPA and not X-SAMPA
… do we really need the name and gender of the voice?
… simplifying this makes it more like a first-class part of HTML
… even emphasis level could relate to <strong> and <em>
… as a wholly separate approach, something more like ARIA – have a namespace that is not really touched by most browser user agents, passed through to other technologies
… because the HTML spec doesn't really need to get involved
Matthew: while it's cleaner than a serialized thing in one attribute, ATs did not want to have call into the a11y tree all the time to deal all of those separately
Simon: browser can expose it differently in the a11y tree
Keith: is there i18n requirements for SSML?
Matthew: refer to facilitators

Joint session with Web Performance WG

Topic: Web Perf WG/WHATWG collaboration process
Anne: WHATWG is considering adopting a "staged" incubation process, similar to TC39
… recommend looking at that and seeing if it meets your needs for things that migrate into WHATWG
… when things happen in HTML that Web Perf should be, we should notify a performance team on GitHub when there is a performance issue
… alternatively, we could have a label that you monitor, which is what i18n wg does
Yoav Weiss (Google Chrome): having a team that you @ sounds great
Domenic: on the staged process, don't see them as hoops
… you've been working well, this isn't a new requirement, just some optional structure
Anne: It seemed like Yoav wanted more indication about implementer sync points, which the staged process provides
Yoav: for moving into WHATWG, we'll have to integrate with staged mold
Anne: read it and see
Yoav: when we have a feature implemented in multiple engines and there is consensus but it makes sense to move the processing model closer to HTML, does that start at stage 1?
Anne: that's stage 3, or maybe stage 2
Domenic: maybe 2 given level of spec maturity, using example of preload
Yoav: okay, so decide which stage things should be in, no need to climb ladder
Anne: the whole process is optional; you can still send a PR under the existing working mode
Domenic: recently you've been doing a good job with HTML integration
… upstreaming monkey patches, moving things into HTML wholesale, etc
… other groups should emulate this
Anne: call the team "perf"?
Yoav: 👍
Topic: fetchLater
Yoav: this started as unload beacon, then PendingBeacon, and then feedback led to the current API shape which seems to have more consensus: fetchLater
… the API is built around Fetch primitives
… it would have been great to get that feedback earlier; what could have been different in our process to bring that feedback earlier?
… I know that review bandwidth is scarce
Alex Christensen (Apple): part of it is my fault, sorry
Yoav: is there something systemic that we can do?
Anne: originally it didn't really seem like a new Fetch feature; if it had an issue on the whatwg/fetch repository would have been natural
… still not a bad idea to talk to the fetch community when doing things related to fetch
Domenic: maybe it should be a principle that if you're doing requests, talk to Fetch
Anne: TAG isn't looping in domain experts for things like crypto and Fetch, which could be better but is hard
Olli: did PendingBeacon go through TAG review?
Domenic: TAG gave feedback after 5 months that was not addressing this sort of issue Pending Beacon API · Issue #776 · w3ctag/design-reviews · GitHub
Yoav: early review is still open about a year later
Domenic: my proposal would be if you're starting a new fetch via a web developer exposed API, especially if it's generic, probably talk to Fetch people
Yoav: private state tokens is also doing something like that
Domenic: specs do need to fetch all the time; if you're introducing an API that allows developers to send semi-arbitrary or arbitrary data, maybe that should be fetch or look more like fetch
Yoav: we can keep that in mind within Web Perf WG
… maybe it should be added as a design principle, as you suggest
Jeremy: it's more about process than design
Yoav: maybe TAG or Blink process should be telling people to do this
… spec PRs are coming along https://github.com/whatwg/fetch/pull/1647
… any other concerns/topics related to fetchLater?
Anne: I think we're in a pretty good place now.
Yoav: OT ongoing or will be soon, with good feedback on previous API shape
Anne: next time will hopefully be better
Yoav: hopefully not another iteration of this API 🙂
Topic: compression dictionaries
Compression Dictionary Transport (WebPerf WG @ TPAC 2023)
Patrick Meenan (Google Chrome): another pass at dictionary compression for content encoding, using previous versions to compress new versions, or side channel dictionaries for better compression
… previous versions existed, this version hopefully better integrates with browser privacy models
… any HTTP response can be used as a dictionary to decompress a future response
… use cases are things like JS lib updated to new version (e.g., updated YouTube JS player library 60-90% savings on the wire)
… in origin trial right now in Chrome
… any response can include a Use-As-Dictionary response header which defines what it applies to, notably including a match pattern (likely a URL pattern) because URLs are often versioned
… TTL is needed to avoid blowing up caches
… when the browser sends a request, it looks at available dictionaries for that origin in that cache partition, sees if any match patterns match the URL about to be requested
… if multiple match, it picks "best", currently longest string
… if so, it will send a Sec-Available-Dictionary header with a hash of the available dictionary and the available compression protocol, currently Brotli and Zstd
… Chrome 116 has Brotli, Chrome 118 also has Zstd
… if server has a static version delta-compressed with that dictionary or has the dictionary available and can compress dynamically, it can indicate with Content-Encoding
… client only advertises one dictionary, so server will either use that or send a full response
… some discussion about explicitly indicating what dictionary was used
… one thing likely to affect HTML is, in the case of a custom-built dictionary that has all my HTML templates etc, we need a way to trigger a load of a resource that would then have Use-As-Dictionary response
… currently considering using <link rel=dictionary> which would download the dictionary at some idle time so that the network layer sees it
… [examples on slides]
… we have had history of privacy and security issues in this space
… all partitioned and cleared with cache and cookies
… oracle attacks have been the big problem where compression dictionaries can reveal information about either the dictionary or the resource
… for this reason, dictionaries and compressed resources need to be non-opaque to the origin they're fetched from
… spec-wise, we're working on the actual headers and content encoding in the HTTP spec
… it clearly touches Fetch and HTML in some places; Fetch in particular touches CORS and [various other things]; HTML touches <link rel>
… have had internal privacy & security reviews which we've cleared, don't think we've talked to PING
… think we're in good shape, but still need to take it through the privacy team
Yoav: re. HTML integration, it doesn't seem super complex
Anne: dictionary needs to be stored somewhere, that sounds somewhat complex
… needs to be integrated with Clear-Site-Data and other things
Yoav: I believe it's tied into CSD, UI equivalents
Patrick: whenever cookies, cache or site data are cleared, it's wiped out
Anne: is it grouped under cache or under cookies?
Patrick: it's in its own partitioned storage which mirrors cached, but is also cleared and follows rules of cookies
… whichever is more restrictive at the time
… in Chrome today, dictionaries are partitioned along with cache even though cookies aren't yet
… if you CSD: cookies, cache, or *, the dictionaries are cleared in all such cases
Anne: we could spec that, though it seems a little weird
… definitely requires patches to several specs
Domenic: is there a reason not to pick one? Like cache?
Patrick: main reason is that dictionaries can be abused as an identifier, since the hash of the dictionary contents is sent and could be used to track individual people
Domenic: is that different from HTTP cache?
Yoav: you would need a timing attack for the HTTP cache; this is explicitly advertised to the server
Domenic: okay, it's more explicitly like cookies in that regard
Anne: if you cache a response and then read it from the cache, isn't that the same thing?
… don't we have only-if-cached? Or force-cache? This is also CORS?
Patrick: it's possible we were being overly cautious given the history in this space
Yoav: can hash that out over an issue
Domenic: I had concerns about navigation; have those been resolved offline?
Patrick: we did reply; there is CORS tainting for subresources if it bounces but doesn't redirect
… in the case of navigation, they are not tainted
… as you follow each redirect, the partition for which the dictionaries are stored follows the partition for the current request
… this is consistent with the cache
Anne: the concern was a confused deputy attack on the target origin
Patrick: what could be confused, since the dictionary has to be same-origin and has to be in the partition
Anne: could be confused by the referrer in some way
… same reason we have SameSite=strict cookies
Patrick: I don't follow how a referrer could impact the compression dictionary for an origin
Anne: origin creates the dictionary
Patrick: and it's on the request to that origin, independent of what referrer it came from
Yoav: final document is readable by the origin, regardless of how it got there
Anne: we have SameSite=strict cookies for a reason
… I would like someone to analyze why it's okay behaving like lax cookies for some reason
Patrick: it's more like cache
… we don't not use cache in case of a navigation redirect
Yoav: need a more explicit explanation of what the confused deputy attack here would be
Anne: some kind of query string that influences the dictionary creation in some way that the origin hadn't intended
Patrick: navigations cannot themselves be dictionaries, they can only use dictionaries
Jeremy: a document can use a dictionary but it cannot create a dictionary
Anne: then it might not apply…?
Yoav: confusion could affect content of a current navigation but not the content of the dictionary
Jeremy: you'd also need a hash collision to be able to confuse decompression, since they're keyed by a content hash
Anne: if the target content can't become a dictionary…I'd have to think about it again
… creates a murkier definition in Fetch, because we have to know what the response is going to be for
Patrick: fetch destination exists
Anne: is it just document? Document is only for top-level, so you also have to look at others
… there might be a shortcut
Tsuyoshi Horo (Google Chrome): request mode "navigate"
Patrick: either way, seems solvable
Anne: might also want to exclude WebSockets
Patrick: we've explicitly excluded them, they have their own compression issues
Anne: no-cors is not excluded necessarily, if it's same-origin and tainted, then it's fine
Simon: if it's tainted, then no-cors
Anne: tainted no-cors is not used
Patrick: previous thing fell flat for multiple reasons, but one is that at the HTTP/2 layer there was no concept of partitioning, so oracle attacks could be done across sites
… private data could end up in dictionaries, and you could see into opaque requests
… since most of the use cases we care about don't need to do delta compression for opaque requests
Yoav: at the transport layer, you could mix origins in a single HTTP connection
Anne: I don't like that feature, though CDNs probably like it
Yoav: any comments on the venue split, IETF, etc
… I know on the IETF side there is some grumpiness re. Web model, dependency on CORS
Anne: given what we just discussed, I don't see how we could avoid it
Patrick: we could keep most of the CORS stuff out of the HTTP layer, because most of it's client-side at fetch time
… the only place it is exposed is when you get a non-CORS cross-origin request where you depend on the ACAO response header – the server needs to not send a dictionary in that case, even though the client couldn't read it and would ignore it
… so we do have a requirement in the IETF draft that if the fetch origin & mode are a certain combination, don't use dictionary compression
… there is some discussion about making it advisory in HTTP
… the other main heartburn is around URLPattern for matching, they already didn't like wildcards and the more complex processing logic around URLPattern isn't going to be popular
Anne: re. URLPattern, can we restrict it to only path and query?
Domenic: discussed that; I don't think it really helps
… it just creates new variants of URLPattern, and you can get functionally equivalent results and if it's a different origin, it just won't match
Jeremy: the server just emits it
Patrick: the processing logic is all on the client, it would only affect other HTTP clients
Anne: that means the server will parse it, server-to-server communication
Patrick: if it is a client which is storing dictionaries, and wants to use this pattern, then it will have to do that
… a lot of server-to-server cases will be using hardcoded configuration and won't need to parse the pattern
Anne: IETF won't buy that you just emit this
Domenic: I really think it's okay; URLPattern is well-specified and has a JSON test suite that any client could use
… appreciate pushing through heartburn at IETF
Anne: another question about the protocol – are responses identified other than with the dictionary
Patrick: Content-Encoding
Anne: do need to handle cases where you unexpectedly get a content encoding back, or if you get it for an opaque response
Yoav: erroring seems likely the only option
Patrick: failing hard in edge cases is the plan
… will proceed with OT, file issues with Fetch and HTML
Topic: isInputPending
Yoav: WICG incubation which is part of the scheduling APIs
… probably makes sense for it to land in HTML
… at the same time, Meta folks editing that incubation are not WHATWG HTML workstream members
… we'll have to figure out how that works
Shuo Feng (Mozilla): if something is in WICG, editor can modify any time they want
Yoav: commitments were given when that spec was committed
… it's a portable license
… anyone can modify the existing spec, but open question on whether one can take those contributions and integrate them into a WHATWG workstream without original contributors
Domenic: my understanding from talking to steering group and lawyers is yes
… we've done it with other WICG specs, like web components and navigate API
… lots have had PRs from various people, and we've never tracked them down to confirm they're WHATWG members
Yoav: are there mechanics about who should move things?
Domenic: someone who is a member, typically add a reference to the previous license under Acknowledgments
Shuo: need implementer interest to modify things in WHATWG
Yoav: I'm not saying isInputPending has multiple implementer interest, so I'm not saying it will happen tomorrow
… we expect in Web Perf WG that these things that integrate into the event loop will eventually target landing in HTML
Olli: re. isInputPending itself, I wonder if WebKit has any feedback
… your process and scheduling models are still so different
… is it safely implementable in WebKit?
Anne & Alex: don't know, ask ? or Ryosuke
Yoav: in memory-constrained devices, yes, cross-origin iframes can be same-process in Chromium
Olli: you might be able to know whether someone is interacting with another page in the same process
Yoav: there was some work around mouse—
Olli: more about keyboard event handling
Anne: was this also the API that if you invoked it twice, might get different answers? Or was that different?
… I think it returned shared state
Olli: I don't think it has to be implemented that way
Anne: oh, it is a method now
Ryosuke: right now that would be hard for us to implement
… we're not looking to implement right away
… fundamental premise of checking if there is pending input seems like a good idea
… I don't think we're opposed to the idea
Olli: possible issues with cross-origin iframes when you're on a mobile device where the iframe might need to be in the same process
Ryosuke: needs to be isolated by top-level frame to avoid a side channel, but that's true regardless of site isolation
Olli: thinking about a pending keyboard event, change focus to the iframe
Domenic: in spec, it's already partitioned because it uses agents as the largest possible scope
Topic: [Form-associated custom elements: being a submit button WICG/webcomponents#814](https://github.com/WICG/webcomponents/issues/814)
Keith: web components have no semantics until you start applying them
… as we're adding more behavior to things like buttons, things like popover
… custom elements are diverging from that featureset
… have added form-associated custom elements to get some behavior back
… when new proposals add more behavior to built-in controls, component authors want to know how custom elements can participate
… no concrete proposal, but question: how can web components be like buttons, have these button attributes?
… we just had a conversation about slotted in CSSWG, where a similar topic arose
… if you want to pretend to be a list element, how do you get to the required elements?
… is there a more general solution? Do we need behavioral components?
Domenic: if only there were some way to customize built-in elements…
Anne: people also want shadow trees
Keith: if you could have a shadow tree that pretended to a button…
Anne: I made a somewhat concrete suggestion of adding something to ElementInternals
Domenic: matching :default and participating in implicit form submission came up
Form-associated custom elements: being a submit button · Issue #814 · WICG/webcomponents · GitHub
… concrete proposal to put a submitButton=true on element internals
… long discussion after that, and then Anne ended up with a similar concrete proposal, which was more extensive
… then people arguing about activation behavior
… new constraint: what about being a <button> button not a submit button
… very last suggestion is elementInternals.button = 'button'|'submit'|...
Anne: what we outlined there is a good way forward
… it's okay to offer being a button or submit button, maybe also reset button
Keith: concern from Web Components CG is that a lot of these are added imperatively but not declaratively
Anne: we haven't yet tackled declarative custom elements
… don't want stuff on <template> because that's the shadow root, similar concern with ARIA stuff
Westbrook Johnson: if we were to add a button property to element internals, by default if you set that you get tab stop, roles, etc?
… are you customizing a builtin by doing this? Are we reinventing an old idea?
… we could just create, imperatively, the most complex version of customized builtins, by forcing them to configure all the element internals to make it happen
Domenic: that is the idea of custom elements, though – you should be able to replicate built-in elements in JS
Westbrook: there are implementers against is="", but if we're going to put that same API in a different, more complex, surface, then why?
Anne: don't have the same limitations; a customized built-in can't have a shadow root, custom element name, etc
… I'm not too concerned about the builder of the custom element having to use script
… but don't want users to have something weird that doesn't look like an HTML element
Westbrook: is button the right level? Focusing deeply on button seems like a misstep if you're open to this pattern. If I have to separately say that tabindex=0 and separately role="button", are you intending that a custom element has to set all of those?
… or are you getting a different path to customized built-ins?
… it would be great for people to get the functionality that's already developed by browsers, because a11y is great
Anne: HTML already has a concept of buttons, which is how we say that attributes like popovertarget apply
… that's a state an element can have, so exposing it on ElementInternals makes sense
… maybe as we add more then there will be conflicts (e.g., you can't be a button and a label at the same time)
Keith: valid concerns about developer experience, whether <button is="..."> is natural
… we really need mix-ins
Domenic: mix-ins are a bad API shape for inheriting particular behaviors
Anne: ElementInternals already went down this path, exposing a bunch of state of form controls
… we do need to consider possible conflicts, like buttons having a restore value or whatever
… exposing fundamental states that elements have makes sense to me
Keith: could you just say a custom element can't be a button and form-associated, but has some other link to the form
Anne: submit button does have a submittable value
Keith: intricacies around form-associated custom elements, might want to just say you can't be form-associated and also have a button
Domenic: I'd go the opposite direction – allow as many things as possible, and only prevent when you have an explicit conflicts
… maybe it's a little weird to have some things, but nothing prevents many combinations
Anne: if you say something is a button—
Domenic: there should be separate composable things for role, participates in :default
… a11y, focus, buttonness, form-associatedness, etc are all separable
Keith: currently too much work to do all that stuff
… we can already do what buttons can do today
Domenic: you cannot be a submit button or match :default today
Joey: popovertarget?
Keith: you can do that via script, but it's unwieldy
… I understand that there are certain capabilities that aren't there
Domenic: the custom element approach that we originally started was to work on all the low-level tools that let developers build as flexibly at they want
… we added form-associatedness, we still haven't added focus
… maybe this approach is a dead-end, and instead we should do high-level stuff instead
… the original vision of custom elements was to expose these low-level capabilities
Anne: it would be useful if saying you're a button in ElementInternals gives you a bunch of things for free
… it seems unlikely you'd want to override them, and you can still do so explicitly
Domenic: packages of defaults seems like a separate project, "customized built-ins v2"
Keith: still means some kind of imperative API to elect to be a button
Domenic: not necessarily, if it's a whole new project it could be declarative, like <button is="..."> which was declarative
… Anne seemed okay with <my-button is="button">
Keith: users of libraries then have to opt-in to that
… are we talking about declarative custom elements?
Anne: that's something WebKit would like to see happen, too
… maybe we don't need an imperative API, but if you do, you might know roughly what the declarative APIs need to look like
Domenic: we could add new low-level capabilities, or design packages of capabilities
… in the latter case, do we do imperative or declarative first?
Keith: tandem specifications for declarative and imperative
… or some idea that they're going to happen within a meaningful time period
… right now we have many imperative APIs but not many declarative APIs
Domenic: because we have a foundation of imperative APIs, adding declarative APIs would be blocked on the existence of declarative custom elements
Anne: need more imperative things, too, to solve the ARIA problem
… don't want to block that on solving [declarative custom elements]
Keith: we saw a good amount of work on attaching shadow roots imperatively but held up on declarative things
… we still need JavaScript to be running to access imperative APIs
Westbrook: one nuance on declarative vs imperative API is, it's not always clear that they can come out at the same time
… when we're making imperative APIs, we need to be conscious of what would be necessary to make it possible to expose them declaratively, even if they don't ship at the same time
… there's no clear path about how you would make ElementInternals declarative; it's hard to see how you could do that
… doing something is definitely more important than doing nothing, but keep in mind how we could do that, so that we don't hit roadblocks if/when we want to build the declarative part of the API
Domenic: sounds like people wouldn't want this PR even if we wrote it
Keith: it feels like we're getting piecemeal APIs, which are welcome, but it seems not to be providing the bigger picture and I'm somewhat fearful that web component authors are going to end up with a huge block of code to set a large number of ElementInternals properties
Anne: it's not that easy, even these things are somewhat involved to add
Domenic: it would be a very large request of browser vendors to build a whole declarative custom element API
Anne: incremental evolution feels like how we get there, rather than designing the whole thing from scratch
Olli: we still need to anticipate what the future will look like, so we don't design bad APIs that won't work with that
Keith: today it's form-associated and button behaviors, tomorrow it will be dialog behaviors, etc
… to be clear, big fan of web components and would like to see it continue to evolve
… don't want to stall because we can't come to an ideal resolution
… as a developer, I would like to see more
Topic: scheduling APIs
Olli: would like to know: can WebKit implement these APIs, and how can we integrate these into the HTML specification?
… it doesn't have the concept of priorities, etc
Update on Scheduling APIs (TPAC 2023)
Yoav: family of APIs to improve task scheduling performance
… essentially, trying to reduce thread contention and, on the one hand, break up work and prioritize tasks that are being scheduled in ways that match what developers want
… goal overall is to improve responsiveness and user-perceived latency
… scheduler.postTask is the first – post a task with appropriate prioritization
… without this API, users use setTimeout, postMessage to self, but no way to assign priority to this queue so high-priority tasks run first
… underlying assumption is that developers will break up long tasks into smaller chunks and then prioritize those chunks appropriately
… the API returns a promise and tasks posted are cancellable using TaskController
… shipped in Chrome 94, used in up to 1.25%, polyfill using setTimeout and MessagePort
… scheduler.yield: postTask assumes developers are trying to break apart work into different tasks, but in many cases developers have existing long tasks that they would like to stop and then continue without explicitly breaking them for convenience or sense
… want to keep a continuous task if possible, but yield to browser when higher priority tasks, like user interactions or rendering opportunities, need to happen
… this makes the app more responsive to input, and allow the overall task to complete faster than occasional setTimeout
… hesitance of the part of web developers to yield because you don't know when you'll get control back
… scheduler.yield provides better guarantees for when the continuation will run, so that other scheduled tasks will not get in the way even if you're yielding to input or rendering
… inheritance: task continuation will inherit the priority of its parent task
… future work planned for scheduler.render(), scheduler.wait(), etc, which is more speculative
Domenic: can I have scheduler.wait yesterday?
Olli: missing piece from spec of scheduling API – priorities haven't been defined
… they have names, but no description of what happens
https://github.com/WICG/scheduling-apis/issues/67 https://github.com/WICG/scheduling-apis/pull/71
Domenic: PR in progress
… it was vague because of feedback from Boris Zbarsky (Mozilla)
Olli: HTML spec doesn't have a concept of priorities so need to add something there
… at least Gecko and Chromium use separate task for rendering updates
… the specification doesn't have that model, don't know about WebKit
Ryosuke: yes, rendering update is a separate task in WebKit
Olli: we should change that
Domenic: it's not observable
Olli: it might help in specifying these priorities, like the highest-priority "user-blocking"
Anne: are you saying everything that happens in "update the rendering" is a queued task?
Domenic: yes, but unobservable
Anne: what about microtasks?
Domenic: we flush them when the stack is empty, so not observable
Olli: I don't think it's observable, but in order to specify the priorities we need to understand what is being prioritized before and after that
Anne: might make that other algorithm more readable, since it's such a large step
Olli: specifying priorities is blocking us from enabling the API anywhere else
Yoav: TaskPriority enum – my imagination of integrating this into the event loop would be to add some kind of priority queue to the event loop to decide which task is being pulled next
Olli: have to determine what is compatible with all of the engines
… Chromium and Gecko seem to have similar models, but I don't know how WebKit works and what they think about the scheduling API
… you mentioned in Web Perf WG that you can't always control your tasks that well
Ryosuke: that makes implementing this API challenging
… it's not impossible, though – we can schedule the ones that we have control over to respect these priorities
… the biggest problem with this API is the lack of handling of priority inversion
… you schedule something with low priority but something high-priority depends on it
Yoav: developers already don't have that control
Ryosuke: there are cases where you schedule something, you initially thought it was low-priority, but that situation may change
… if you fetch some script asynchronously, it may not be important initially, but then later the user tries to interact with what that script provides, it is now high priority
Michal Mocny (Google Chrome): TaskSignal can adjust the priority of a previously scheduled task, though you have to do it explicitly
Ryosuke: AsyncContext seemed interesting and might address the issue
Olli: our TaskController in Gecko can express dependencies between tasks, but we use it very rarely
Michal: scheduler.yield alone has been incredibly useful; is that something that you could?
Ryosuke: we would not implement
Michal: could you run render steps and then continue, without actually yielding to the task queue?
Ryosuke: Maybe.
Michal: Key use cases for yield are for high-priority work, and then you resume immediately. In Chromium, new input events & rendering.
Olli: based on spec issue, rendering defaults to normal priority
… very high if you haven't rendered in 100 ms
Michal: in chromium, for 100 ms we keep rendering at normal priority and then boost to highest, but then after any new input it automatically goes highest
… a very common and important use case is for a long-running task in the context of an interaction to yield and be certain that rendering is a high priority
Ryosuke: so just updating rendering wouldn't work because you'd have to process input
Michal: a long blocking task might yield to input, which then yields to rendering
Ryosuke: so yielding to rendering isn't sufficient; we would need to yield to input as well
… we do some rAF aligning, but it's sent as a separate IPC so we have to yield back to the system run loop to process input
… today, there is no way to implement something like that
… it's not impossible, 5-10 years from now, but it won't happen anytime soon
Michal: API is polyfillable, but ergonomics alone are valuable even if it backs onto setTimeout(..., 0)
Yoav: but still pay the performance cost
… as I understand it, nothing prevents postTask from being implemented in WebKit, but still a question about whether you're interested in implementing, but yield would be much more complex
Ryosuke: Correct, yield would require significant work.
Olli: in Gecko, we don't have yield implemented but it should be relatively easy to implement.

HTML triage of agenda+ items

https://github.com/whatwg/html/labels/agenda%2B
Topic: Use inside settings to fetch the descendants of module worker in the worker module script graph · Issue #9571 · whatwg/html · GitHub
Domenic: I will ping Hiroshige (Google Chrome)
… Anne asked security people from Chrome to comment, and they said it wasn't security-relevant
Topic: [Add ToggleEvents to .showModal() (whatwg/html#9733)](https://github.com/whatwg/html/issues/9733)
Domenic: proposal in issue only has toggle, not beforetoggle
Keith: also asking for beforetoggle if appropriate
Domenic: probably is, just trying to remember why we have both
Keith: for animations and adjusting styles
Joey: we're already doing the same thing for popover?
Domenic: what events does <dialog> already have?
Joey: cancel, …
Domenic: lots of events on closing! Are there any events on show? It seems not on show, and I don't think on showModal either.
… but there are two events on closing: cancel and close
… cancel is only fired for close requests (Esc, Android back, etc) modulo a pending PR
… not excited about expanding the number of events firing when closing from two to four
Keith: I'm mostly interested in showing, because we could use close if we need to for closing.
… It feels weird for popovers to do beforetoggle/toggle, but to only do that on open
Domenic: trying to find out how often beforetoggle is cancelable
… it's only cancellable before opening, which is less complex though not consistent
… I now think it is good and does not significantly conflict. It will increase the number of events, but not in a problematic way.
Keith: Moz/WK?
Olli: Fine for consistency, and the beforetoggle event is useful because it's useful for popover.
… Firefox uses that to populate popups
Anne: which events do you need to listen to vs ignore?
Keith: would listen to beforetoggle to hook up animations, and kick off ? scans, and also listen to cancel to reset default contents if there's a form
Domenic: will have to work out exact details in the PR. Is close async?
Anne: yes, it queues, and so does cancel
Domenic: event sequence on open is: beforetoggle, [async], toggle; on close: cancel, beforetoggle, [async], toggle, close
Exact order of toggle/close, beforetoggle/cancel tbd
Joey: should be in same task at least
Domenic: agreed
… only beforetoggle on open and cancel on close are cancelable
Keith: seems reasonable to me
… there's a toggle event on <details> that doesn't use ToggleEvent interface
Domenic: I think Tim and Mike Smith fixed this recently (checked) yes
Anne: <details> doesn't have before
Domenic: true, it could
Keith: could also have a pseudoclass for them all
Joey: CSS spec says :open/:closed should apply to a list of elements, including <details>, <select>
Anne: I'm still stuck on whether we should add beforetoggle to <details>
Mu-An: we should
Domenic: there's some weird stuff around how <details> is opened synchronously by the parser sometimes
… there may be an existing interop bug about whether/when it fires a toggle event
Clarify that <details open> fires the toggle event even if the open attribute is set from the parser · Issue #4500 · whatwg/html · GitHub
Anne: still worried about XHR, is it still an issue with parseUnsafeHTML?
Domenic: parseUnsafeHTML does run script, and some of the other parsing things do fire events but not run script
Keith: is that an issue for <dialog>?
Domenic: no, because <dialog open> doesn't actually show it, though I would have liked to have changed that
Joey: not in Chrome
Domenic: it shows it visually, but doesn't hide popovers, run dialog opening steps, etc
… coming to a firm resolution on <details> open toggle behavior would be helpful for making a decision about adding toggle/beforetoggle to <dialog>
Anne: Henri always talked about script synchronization points and only a few elements require it, does this mean <details> is one because it doesn't queue a task?
… it's after insertion but before children, which requires a script synchronization point, which I thought we only had for custom elements and [a few other cases]
… it seems bad to introduce one for an arbitrary element, but if everyone already does it, whatever
Olli: toggle queues a task, but beforetoggle would not
Joey: you could argue it's not really toggling if it parses open
Domenic: the problematic thing is synchronous
Jeremy: you could just not fire beforetoggle, what would even happen if you canceled it?
Domenic: what happens if you add the open attribute to <details>?
… if you do setAttribute('open', …) and then get a beforetoggle event and cancel it, what happens?
Anne: the attribute also being the state is weird
Domenic: so it's not cancelable for details
Jeremy: or it could only be cancelable when it's a user click
Keith: the use case for beforetoggle is kicking off animations
Domenic: this all feels relatively workable, but still want to see if Anne is comfortable with firing queued async events for parsing <details> and the precedent that sets
Anne: what's wrong with the solution at the end?
Domenic: slight compat risk, why be inconsistent and this is the one event with a browsing context connected check?
… there are many things you can do in parsing to cause scripts to fire
… MutationObserver fires during parsing, and so does DOMContentLoaded
Anne: I see your point, but I'm not convinced we carefully considered the implications
Domenic: load, error, etc
Anne: when we specced XHR and when we parse new parser APIs, the parser has very few things to actually disable things
… when you look at how things integrate with that, they're not necessarily aware these other contexts could exist
… it seems like it's unlikely to be a problem, but it wasn't a carefully considered design
Domenic: I don't think you need to carefully consider reusing an HTML parser and script execution – it works
Anne: we had to disable scripting in the XHR parser
Domenic: sure, because of XSS risk, but here the outside context has to explicitly listen for it
Anne: we didn't consider it for any of the events you mentioned from the 2000s
Domenic: it feels like we would have considered this in XHR
Anne: didn't design XHR; I wrote it down and I'm telling you I did not consider it
Domenic: I considered it now and I think it's fine
Olli: you can't easily have event handlers there, you have to do so explicitly
Anne: I guess same argument applies to DOMParser, parseHTML, parseUnsafeHTML, …
Olli: innerHTML?
Anne: okay, we've considered it and you can merge those tests in whatwg/html#4500
Domenic: I'll take care of this, and I think that unblocks your issue
… we don't need to change current stuff, including <details>
… it seems like <dialog> is the priority
… the parser cannot show the dialog, it can just open it
… plan to add beforetoggle and toggle for <dialog> should be straightforward
… re. <details>, during parsing, if we fire beforetoggle we will need a check to prevent it during parsing or do it in the same task as toggle
Keith: during parsing, if details is opened during parsing, don't want something to animate during parse
Domenic: if you're adding beforetoggle to <details>, you have to deal with cancelability and not doing it during parsing

whatwg / meta

TPAC 2023 meeting #284

TPAC WHATUP meeting agenda

Draft agenda

Thursday

Friday

Topics for the joint session with OpenUI

Topics for the joint session with CSSWG

Topics for the HTML session

Topics for the Friday HTML session

Topics for the joint session with Web Performance

Attendees

Thursday

Process session

OpenUI session

CSSWG session

HTML session

Friday

HTML followup session

Joint session with the accessibility group

Joint session with Web Performance WG

HTML triage of agenda+ items