Matthew & Christian added.

Christian: Proposal to bring traditional desktop-app-style menus to the web. You can do some of this with HTML but it's super complicated. I think it's appealing because it's a real problem that developers need to solve. The explainer has many open questions that need to be resolved, so I'm not exactly sure what the review request is. I wantt to ask that, so we can carry on. First impression is the use case is valid.

Matthew: What's the web compat story about re-using <menu> (noting their reasoning on this). +1 to Christian asking what the bounds of the review are.

Luke: Sometimes there are questions in the OpenUI explainers that aren't questions that need to be answered. The framing can be: here's the thought process that lead to these answers. If TAG has feedback on some of the open questions that'd be valuable. There are some genuinely still open questions. If WHATWG like a certain approach then it'll be considered, but they're open to suggestions.

Luke: I suspect the webcompat situation is more serious than it may seem. Develoeprs may've been using it quite a bit. Maybe TAG could write something about using elements not for the semantic purpose they were intended? I think <menubar> is good.

Marcos: Agree with Matthew in case that sites can benefit from any existing semantics... worth investigating re-using/fixing the existing one if possible. Was surprsied to see new elements.

Luke: I think the existing semantics are quite different as is the CSS. So you'd need an attribute opt-in.

Lola: Sounds like Christian and Matthew doing more investigation, and we have surfaced some questions about why not use the current <menu> - can you draft an intiial comment?

Christian: Yes. Good use case, why don't you use <menu>, and what's the scope of the review.

Lola: Can definitely see the need and benefit of this process.

Luke: Earlier, there was talk about the concept of a navigation menu, with links as opposed to menu items. This was not looked upon favourably. Keyboard focus management, popovers, etc. issues. There's a separate proposal for site navigation 'menus' that may involve the <nav> element with an attribute - we should bear things in mind when considering this one.

Matthew: I'm just seeing this now: they answered our questions about the existing review. It links back to previous discussions and Scott O'Hara's blog post. I am not an expert, but given the discussion that we had last week in TAG, and to my mind, yes it has been part of the platform for 30 years, but it has completely come full-circle in terms of how it's used. It's basically the <ul> element. I've never come across it being used anywhere at all, and I've audited quite a lot of websites. I'd be interested in what other people think, though, because it does seem like it would be neat if we could use it. If we look at the data and learn that we cannot, then that's fine. It links to a few different things about the scope of the review, so I'll need to think about that. (Scott's blog post was great, by the way, and I appreciate that they don't want to break things.)

Luke: One thing that might be worth asking them for is if there's a Chrome use counter for <menu>. I have a suspicion that this will have high usage. Some devs seem to really want to use it. I think if this change were to be made it would have to be opt-in via an attribute. But then maybe the benfits aren't as strong. I think it's worth pushing on this a little more, to get enough data to make the decision.

Dan: There's a parallel to the customizable <select> where we ended up using the old element, and a CSS opt-in to the new features.

Luke: I think it's similar, but the opposite decision is correct, as in the case of <select> it has the right semantics to start with.

Lola: Matthew, you will respond.

Matthew: Sure. I'll check out the bit about the scope of review, as well.

Sarven: Is the proposal attempting to put something in place that works similar to <dialog> - it would have some affordances that come with being a menu. Dialog allows you to interact with it in different ways, e.g. instead of the alert thing popping up, you are able to put HTML content in there. It's clear that there is a plethora of examples of things having a menu. Being able to escape, or use keyboard to navigate, is important. The interaction pattern is often re-invented.

Matthew: I have not made progress on this, yet. Sorry!

matthew: i need to ask them about the usage counter in chrome and the parallels with a customisable select an old element that's reused and we provide an optim. And then there was the scope issue from last time.

Christian: Yes, let's ask the questions for now, and continue the review.

Christian: I'm satisfied with this. It's a low risk proposal, about declarative UI. there si one concrete question here: why are we not reusing a specific HTML element menu that has been used before? They said ti might be problemantic for assistive technology. I'm satisfied. Matthew?

Matthew: I'd like to look at it. I saw the answer and thought it was thoughtful. I feel like it should be possible... but Luke suggested things we could find in the archive to see how widely used it is. It would be interesting to do that, see how breakign this would be if you use the original one, If you read Scott O'Hara's article aobut it, it does come full circle.

Christian: the question is: do we have to perform that analysis, or can we ask the proponents to do that for us? I'm not sure we have the capacity

Hadley: we can do either. I don't think it's our responsibility to, we can just ask the question,. but if we're curious...?

Luke: I think the Chrome use counter could be helpful here. It may be enough for us to say "we understand the web compat perspective. do you think this is actually a prolbem in practice? Do you have the data to say that it is?"

That question on whether to use a new element or reuse the menu element will probably come up in WHATWG as well.

Christian: then I was suggest to close this review as satisfied, and ask them to clarify the compatibility story down the road.

Also it doesn't have multistakeholder support right now. There is no security and privacy self-review. Could go in the closing comment.

Hadley: If the issue is fundamentally if it should reuse an existing element, I’m sure we have design principles that are relevant. Given this is an early review, we could point to them. Who writes the closing comment?

Christian: I will do that.

Hadley: Not sure if we should do satisfied, or satisfied with concerns.

Christian: Let’s go with "with concerns," with the concern being the element reuse uncertainty.

Matthew: +1

Christian: I have a draft comment (posting after this); Matthew, please review.

Matthew: will do

Christian: Have a draft comment that Matthew +1'ed. I'll post that.