Detailed answer to @scottaohara's 3rd response

search-element-thread-3.md

This is the detailed answer to @scottaohara's 3rd response on the <search> element discussion.

Implementation cost

[nesting] is a far easier implementation lift than duplicating all the functionality of the <form> element just so that <search> can be a <form>

The implementation is 26 lines of code. The specification is also similar to the original proposal.

Only adapting the spec's "form elements" wording (mostly in "Links" and "Forms" sections) is tedious, but simple. It's understandable that this was seen as a "huge lift" that Domenic chose to avoid. It took 3 days, but to lift that barrier, I've done that update. With that out of the way there is no reason to oppose aliasing the form element.

ARIA

Again per the ARIA specification, role=search is not defined as a synonym for a form, but rather it is noted as related to form and searchbox - this distinction is important, and it's quite apparent that many authors do not understand this, [...]

We know. The feedback that requests form functionality comes from people who are aware of the <div role=search> usage, but need or prefer to use <form role=search> (example). Since this is the best practice and also suggested by MDN, that's not surprising at all. It is incorrect and discourteous to assume they are in a misunderstanding.

I read this feedback more along the lines: "Yes, using <div role=search> is an option, and the best in some cases, but why wouldn't I use <form role=search>, since that gives me features I need and that's the most natural mental model?"

From our perspective the question is: "Why would even div be chosen as the duplicated element?" The question is hypothetical, I understand the views on that, but I find that the choice was rushed due to the faulty assumption that exposing form functionality has significant costs. Knowing that aliasing form is viable, it seems unreasonable to use div.

a11y

This is a misnomer, as without JavaScript a <search> or <div role=search> without a descendant <form> is not just broken for people with disabilities.

I've used accessibility with a wider meaning than just "for people with disabilities", also meaning "is the functionality accessible for people with unreliable internet connection".

anti-patterns

Finally, please also note that in regards to the other elements used with role=search link you provided – in reviewing these, many of them are instances of authors misusing the role, placing it on text fields or buttons.

Demonstrating that was my intent. Most of these can be "migrated to <search> as a child element". It's useful to know the anti-patterns and I also find these usages curious. The HTML spec for the <search> element will be restrictive in the sense of not supporting these. Looking at the examples I believe that's a good thing.

native HTML element

making <search> into a near duplicate of <form> is going beyond the scope of what this request was asking, allowing for a native HTML element to expose a search landmark

form is a native HTML element and an alias is not a duplicate. As I've written before the title "Consider creating an HTML search element" does not constrain the base element to div, or any other tag.

It's helpful to be aware that the source of our disagreement is that we understand the title differently.

Note that the explanatory sentence "i.e. it would have the same semantics as <div role="search">." is not binding. It's a first idea how to do it. Researching developer practices and deciding what base element to choose should have been a process of deliberation after that. It would be an error to standardize <search> as an alias of <div>, that cannot be remedied later, when web developers start complaining.