Punted to F2F

Tess: it's one of the only remaning cases where there's an aria landmark role that doesn't have a corresponding html element.... that's it - search element - container for searchy things.

.. reasons why <search> may be better without forms functionality.

Tess: element not backwards compat - also more complex to specify. Goes beyond the original ask which is to make an element for each ARIA landmark role...

... WHATWG SG ruled there was no code of conduct violation ...

Dan: So from a design perspective - what is there to do? Pretty simple.

Hi folks - just FYI we've been asked to review the proposal. We're now moving forward with the review of the proposal as outlined in the initial request. Can we please limit discussion here to that context? Thanks!

Peter: call out specifically reviewing on technical merits, not process

Tess: most elements have some kind of default styling that aren't div or span. I don't remember offhand if this has any.

Dan: left comment

Lea: doesn't make sense to duplicate form element functionality. Troubles me that it's an element that doesn't do anything and its only purpose is to have role="search". I worry authors will not be motivated enough to use it if it doesn't do anything else

Tess: fair. Lets you write selectors simply, like section or article - just aria landmarks, and make landmark look cleaner.

Lea: article and section are things you use multiple times on a website, so benefit from having them multiple times is more

Tess: <nav> you have once.. next to nav, search.. kind of nice

Lea: not saying it shouldn't exist..

Tess: it's a weak argument

Lea: anything useful it could actually do?

Tess: agree. Argument is basically completionism.

Lea: where is that discussion?

Tess: aria and html people have always seen aria as a way to override semantics, not a way to set the semantics it should have had anyway. If you're using html correctly you souldn't have to decorate lots of things with aria. These days you do because people build their own custom form controls and you have to use aria on all of that stuff. But assuming you're using all of the pieces of html you shouldn't have to reach for the hacks.. aria is a hack, is the philosophy. The primary use case for aria that I find compelling is when you are a frontend developer and you come into a project afer it's been built, and someone says hey this is inaccessible please fix it. You have this refactoring challenge - do you fix all the markup to be good? you might break it. Might be complex selectors. Refactoring that kind of stuff can be risky. So the much lower risk is aria. Surgical tool for someone to make something accessible without screwing it up too much.

Lea: plans to add elements like grid cell, menu item, list box ..?

Tess: probably depends. Table is seen as the markup solution to tabular stuff. I doubt the aria stuff will get new elements as wel. But anything where there isn't any kind of equivalent, then probably. As far as I know for sectioning element stuff this is the last one. There might be some early aria design doc that talks about that philosophy that talks about it being an override and you should just use the html elements

Lea: I'm aware in general if you use html correctly you shouldn't need aria, but not about the pupsh to have html elements. Seems a cheat to invent html elements for the sole purpose of being aria roles.

Tess: sure.. one of the nice things about adding it as an element that doesn't do anything is you're not overconstraining the future. If we wanted to add an api that hangs off this in future there's nothing to stop us. If we had it inherit from html form suddenly you've got this whole can of worms in terms of the stuff that hangs off it. I feel like the argument for adding it is pretty mild. Against is mild too. It seems fine. No real red flags.

Peter: I thought in the html5 parsing algorithm unknown elements are parsed as spans not block level?

Tess: this does not require parser changes, but there was an argument about whether it should autoclose <p> and don't remember how that ended up. I think it should. But there might be good arguments against. Obvious arguemnt is please don't ever change parser again

Peter: according to explainer it does close p tags, which does require a parser change. That's frightening, older browsers will parse a different DOM.

Tess: backwards compat story isn't that bad.. delivering markup to old implementations you can close the p yourself

Peter: with well formed you can always achieved the same DOM. That's not the point. Should acehive the same DOM regardless of how clean your markup is. So concerned if this does require.. I agree it's logical ot close the p tags, but breaking parsing algo is a concern

Tess: valid concern

Dan: leave a comment?

Peter: want to confirm I'm remembering this right. Always thought it was a mistake when they refined html5 parsing algorithm they should have defined self closing tags and defined a way to say this is block level... but this is th eworld we have, I'd like to not break it.

Dan: Lea's quesiton about additional functionality was answered by Tess?

Tess: still think i'ts worth bringing up. If you're going to convince someone to use an element there has to be some benefit. I'm okay with either outcome. I want to see they thought about it. You can make an argument either way.

Dan: that's what we should be doing, prompting people to think and write it up

[various comments]

Lea: [looks up stats]

Dan: Peter left commentary on 11th April, what can we do to progress?

Peter: changing HTML parser seems like a bad thing

Dan: Anne says it's worth it...

Tess: we changed for the template elemnet - that was worth it... I'm ambivelent ... there's an ARIA role and we need to elements for ARIA roles... But are people asking for it? It would be nice if search auto-closed... but feels like a weak argunent.

Peter: agree...

Dan: maybe we'd like to see more evidence?

Peter: we're not pushing back on the entire conceopt - but rather does this merrit a parser change.

peter to write some feedback

Rossen: multi implementer?

Dan: seems like Mozilla is interested as well..

Rossen: Sounds like paper pushing... worried about stalling progress.

Peter: if i put a <p> <search> </search> then different browsers will create a different DOM. How bad is the breakage? could break CSS. Could break script?

Rossen: these risks would be assessed by implementers...

Peter: it's not an argument designed to stall - but rather to live up to promises of the parsing algo. I think it's a good change but can we change it in a way that allows us to make this declarative somehow - make a parser change once that will allow these changes to be not a big deal in the future? We've lose extensibility?

Rossen: opening a can. But I would suggest adding that to the issue.

Peter: that's my intended feedback. I think "a promise was made - we're breaking that promise"

Dan: no response to message 11 may... Satisfied with concerns?

Peter: Don't know.. Yes but the concerns aren't concerns I think we can blow off. I'd like to see those concerns addressed. Don't want to block this.

Lea: won't this issue be present every time a new block element is added to HTML? So every time we...

Peter: depends on what the closing tag rules are.

Lea: but most block elements close P tags.. Don't think we should be in a state where we can't add new block elements due to architectural concerns.

Peter I ageee - but this fundamentally breaks backwards compat promise.

Lea: we have precedent though.... Dit these cause problems?

Peter: We can get away with making breaking changes - we have done it. But everyone who breaks things needs to be aware of the consequences...

Lea: I think there's already a high bar. I'm not sure what's the alternative. We do want to be able to add new block elements...

Peter: alternative is to add a new syntax - or declarative mechanism - to indicate ...

Lea: signifigant overhead

Peter: could be a micro-syntax.. tells the parser it has this behaviour. For example we could re-introduce the self-closing tags and have that behaviour. I think these are mistakes of the HTML5 parsing algo - and we're paying the price for those mistakes.

Dan: how about close with concerns and a post about this issue? Raise awareness that way?

Lea: fine by me

Peter: we could also open another issue just to track this. But we can't file an issue on ourselves, we need to get other html people to be thinking about it and agreeing it's an issue

Dan: could also invite anne to a call in the future. When everything is in a review it limits our ability to think about big picture issues. We don't want to block this review. We have to have a mechanism where we can bring the topic up in a wider way. TPAC session?

Peter: fine closing this with concerns and doing something else to raise the issue and get traction...

Peter: similar situation - comment I left has had no response but comment is broaded scoped. Maybe we should just open an issue against HTML - need a mechanism for declaratively making elements with this type of behaviour that don't require parser changes.

Dan: I think that makes sense.

Peter: I will file the issue in their repo and close our issue.

Rossen: there will be an update soon.

Other: