Kenneth: There's a lot of meta things about this. This also ties into switch. A lot of discussion has happened already. This one was controversial not least because of the name

Dan: Yeah I don't get why it needs to be a standard component, why not just write JS to do it.

Kenneth: the explainer covers this... one reason is having multiple toast libraries on the page ... accessibility

discussion of name, inevitably

David: There is more to discuss here about how we introduce new elements to HTML. There's a lot going on with that plan that I think we should look at.

... Web components did this thing where you need a dash in the name, and now we're making the new elements have dashes in their name. What's the theory behind this, when do you use it? Why do we need to use an import? Is that syntax real TC39 Syntax?

Tess: Each of these proposals build on and depend on a bunch of other pieces that are either not there or don't have clear consensus or aren't fleshed out. It's a little hard to do specific reviews when so many underlying assumptions are not clearly going to eventuate.

... it feels a little futile to debate this one element if those things may not come to fruition.

Kenneth: Well the same UI may be surfaced a slightly different way...

Dan: What happened to incubation? This is why I want to have this discussion at TPAC. The Extensible Web Manifesto ... marketplace of ideas ... this seems to assume that that discussion doesn't need to happen in public.

Alice: There is a bit of a misunderstanding of the weight that intent to implement carries.

Tess: these elements don't strike me as a fait accompli, but the underlying assumptions do.

... Domenic asked questions about whether new elements should be fully polyfillable? The HTML community can address these issues at that issue, but I wish those issues had been filed first. I'm happy to see that he agrees that we haven't come to that conclusion either

Kenneth: I think the intent was to drive that precise discussion. I agree that this should have gone to WICG before coming to i2i and TAG review.

Sangwhan: It seems a bit dangerous that they're going straight to the standard namespace.

Tess: It's not even that, it has a js- prefix in the JS library and the element has an <std- prefix. My understanding is that Domenic intends this to be owned by HTML.

Sangwhan: If we decided on std as the new standard namespace - why are these going straight into that namespace without incubation? (e.g. why is there no TR1?)

Tess: I think there is a third question... Domenic raised an issue on whether ... DOM level stuff. My understanding is that it (?) wasn't. My understanding of the JS standard library is that it should be equally usable in non-web contexts. So it felt weird to use that mechanism for adding DOM API.

Kenneth: I think it was intended for web stuff as well, like the KV store.

Tess: That one surprised me as well.

... My impression from msaboff was that it was for things usable across all javascript contexts.

Dan: Can somebody take some time to boil down this discussion into an issue comment?

... Domenic mentioned they're hoping to bring it to WICG... extending notifications ....

... What can we do right now besides summarising our discussion here, to push this along?

Kenneth: I'm not clear on whether they are interested in review on the actual element, rather than the underlying things?

Dan: Are you interested to do that?

Kenneth: other than the name...

Alice: Name is a bikehed honeytrap. I have a11y thoughts. I think it's an antipattern; it's difficult to make accessible complete sense. I spent time working on this with a colleague (Chrome UI bookmarks page). We wished it wasn't there but did our best. You can make an accessible version of an inaccessible pattern, but the pattern is not great.

Kenneth: but people are using the pattern all over; otherwise just not accessiible by default.

Alice: so what kind of sad bargain do we need to strike there?

Kenneth: I'd love to have an a11y expert look at this.

Alice: It's not, but you can fudge it to be kind of accessible for some people.

Kenneth: ... if you give it focus ...

Tess: focus seems like an obvious case of its inaccessibility. Does it popping up change where the screenreader is focused?

Alice: screenreader isn't the worst of it; worst part is zoom.

Alice: I've been waiting for the rush of attention around process issues before getting into it.

Sangwhan: I have technical feedback on ...

Tess: Seems like it should be a mode in the notifications api; then you can rely on system a11y.

Kenneth: these notifications are much more tied to the content; when you've surfed to something else they don't matter anymore.

Dan: We're ratholing into designing the feature. I think we ought to end the timebox here.

Sangwhan: I don't think we can summarize without agreement on what we want to say.

Dan: We've brought up different issues; they can be asked.

Kenneth: I think a11y should be raised.

Alice: Issue has been snarky so far; we should try to be extra kind.

Kenneth: I can make a comment ...

Dan: I think we should continue this discussion in comments. We have 15 minutes left, I'd like a two minute discussion on each of the other agenda issues.

Alice: interested in what you all think

David: still a bunch of namespace discussion in TC39

Hadley: Am I misreading gary greene's responses? Kenneth wrote up a11y concerns. Gary came and says he sees other concerns? Oh... not part of team working on this?

Hadley: So have we seen response from people working on this?

Alice: A little overwhelmed, they have been active in their own repo; our issue thread got pretty noisy.

Kenneth: blink-dev too.

Hadley: what's the best way to get responses to the questions we asked in our issue?

Alice: raises question about our process -- sometimes it's helpful having external people comment on these issues, but sometimes gets very noisy. Becomes difficult for someone to follow the conversation. Doesn't look like we've heard back from them on this issue since we last talked over a month ago.

Alice: a11y issues are going to be difficult to overcome, I think. I'm not convinced it's not a pattern that's inaccessible by design. Do we standardize such a thing, just because we think we can do a better job of a11y than the 50 libraries doing it? Is it a net win, or does it not meet the bar?

Peter: there's the argument that we can get it in front of the right people to get an answer to the a11y argument.

David: common tradeoff with adding features - adding a feature that has negatives for the user increases the use of that feature (negative) but does it in a less bad way than how developers were doing it before (positive)

Peter: push down a week or two?

Alice: would be good to have a longer discussion; a lot to unpack.

Peter: ok, next week then.

Alice: Feels like there's a lot to unpack; not sure where to start.

Alice: For sure there's the namespace issue. There's the naming issue. There's the import thing -- importing a module in std namespace -- discussed elsewhere on builtin modules -- has that come to the TAG?

Alice: The link text says "builtin module" under proposed API.

Alice: There's pay-for-what-you-use HTML elements, related to builtin modules.

Alice: There's the question (dearest to me) about the process for adding a new HTML element with UI implications. How do we think this should work? What are the requirements?

Alice: Then you get into specifics of design of this specific element and the design pattern.

Dan: Where has the conversation gone on this specific element, since June?

Alice: There's a document -- let me check. They've been working on accessibility. Adding a type attribute to the element, implies the default style and ARIA role.

Dan: A lot of emotive language in this thread...

Dan: Can we de-link the meta issues you described, e.g., adding UI elements to HTML. We previously had discussion about badging. That's not HTML, but another rather similar (in concept) to what we're talking about here. Something that alerts the user to something that's happening. What is the difference in terms of how easily that discussion seems to be going versus the toast discussion?

Alice: Also an interesting question.

Dan: Scope of it? For badging we're talking about very specific API. Maybe has a smaller community of practice around it. Once we start talking about HTML it's the entire WHATWG community of practice. All the people who are engaged in it -- all the stakeholders. Group of stakeholders is bigger.

Tess (writing, audio problems): (trying to paraphrase something IIRC dbaron said the last time we talked about std-toast) it makes me nervous that this proposal is built on top of so many other proposals that also haven’t shipped in multiple browsers / been around for a while (JS Standard Library, Import Maps, Builtin Modules, and the open HTML issues about polyfillability & “pay for what you use”ness, etc)

Tess: like, as a general engineering principle, you’re more likely to succeed in adding a new thing if it builds on more stable underlying parts

Alice: ??? we begin addressing the various issues that this brings up?

Dan: We could assign some time at the face-to-face for a toast meta-retrospective. And try to tease out the meta-issues that have come up and discuss each as a separate thing. Could try to time-box that, to try to come to some reasonable conclusion or action on those. Make sense?

Alice: Yes.

Alice: Dan, would you like to leave feedback on issue about identifying subissues, and needing a face-to-face discussion? So that we're not leaving the issue silent.

Dan writes.

Dan: On this issue itself, what do we do?

David: Seems like some of the stuff in this issue depends on the meta-issues.

Dan: Specifically some of the dependencies that Tess brought up.

Dan: Do we need to put this on ice until face-to-face discussion?

David: Maybe worth identifying and opening issues to open before them?

Dan: schedule a breakout to do that?

Alice: I'm happy to go. Also happy to not go if it helps scheduling.

Dan: Australia+California timeslot might make sense.

Tess and David also interested. Maybe Peter, if the time works for him.