Hello, I'm Kaleidea, seasoned software architect, volunteer contributor (individual workstream participant).

I've researched and implemented the <search> element in the 3 main browsers with and without form functionality. I've been waiting for the search element for some time. I give great importance to developer experience and API ergonomy, and I saw this proposal needs some support in that direction.

As a software architect I see efficient solutions where hundreds do not. I saw how much people have misjudged the complexity of adding form functionality. I expected a better solution, so I was happy to invest my free time for about 2 months to help progress this feature. The Chromium implementation got close to prototype stage.

That's an order of magnitude more effort than all other participants combined, yet I have to oppose this proposal due to various violations of design principles, WHATWG principles and policies. The list of issues has unfortunately grown very long since November 2021.

• THE FULL REPORT includes detailed evidence and references.
• There is also an appeal outlined in the WHATWG workstream policy that poses questions for Domenic.
• The appeal was closed without response in violation of the WHATWG workstream policy. This is a serious governance issue that hopefully will be corrected.
• In December 2021 I had to file a code of conduct complaint due to rude and demeaning remarks, and Domenic preventing me from contributing 2 months' work to Chromium. Unfortunately, the Steering Group was unable to provide remedy due to conflict of interest and lack of established procedures. I have worked patiently for 2 months in a hostile environment, closed to alternative thoughts.

Cause of the contention

Domenic wrongly assumed that form functionality would have significant complexities and risks, thus he excluded that option even before standardization began. If an implementer would have evaluated the possible solutions, it would be clear the complexity is minimal. To this day I'm the only implementer to have done that evaluation. Unfortunately, Domenic didn't want to hear the research results.

I hope we can avoid burdening W3C with further fruitless debate that's been going on for 3 months, so these are the reasons why the discussion failed:

• A few coworkers of Domenic have repeated these assumptions with different wording and perspective.
• Nobody has presented any supporting evidence. Nobody has done the necessary research to verify the claims.
• The arguments against form functionality are unexplained "complexities" and generic statements ("code for some completely unrelated functionality could break").
• That can happen to any new feature. These arguments are the manifestation of the fear of the unknown in various forms, that could be lifted by research, which wasn't done.
• I have presented very detailed evidence and reasoning in 15+ page-length comments and the implementation to prove that the complexity and the consequences are minimal and predictable. All this was ignored.

Since November 2021 I've tried many approaches to get the message through. It was ignored. I've also raised a number of complaints that were ignored too. All attempts at resolution failed, making the current opposition necessary.

After all that happened, it is pointless to debate the form functionality in any other form but to present verifiable examples (SourceGraph, HTTPArchive) to support any claim. That should happen on the WHATWG discussion to keep this place focused.

Outline of issues

1. The WHATWG's new feature guideline was not followed.
2. There was no research done prior to the proposal. The solution was predetermined, alternatives were not evaluated.
3. Developers' feedback was ignored.
4. Implementers (besides myself) haven't evaluated the complexity of the possible solutions. This led to the wrong belief that adding form functionality has "huge implementation costs" and complexity. This assumption couldn't be more wrong: the added complexity is trivial in fact as I've proven with the implementation.
5. The discussion became an echo chamber of speculative "risks and complexities". No one could present any evidence supporting those claims, but there is evidence to the contrary.
6. All the contrary evidence proving the viability of form functionality was ignored.
7. The proposal violates the first web platform design principle (Priority of Constituencies) as it was more important to make specification and implementation easy than to address developer needs: "huge implementation and spec lift that isn't worth it" (Fact correction: the implementation is trivial, the spec requires 3 days' worth of editorializing that I've already done).
8. Those who dismiss form functionality have failed to present any verifiable evidence to justify that position for months. There is no valid technical reason to dismiss form functionality.

Issues of professional conduct

The following information is not a complaint, but necessary to understand the context.

I've intended to fill the gaps in the standardization process with an alternative proposal, where I've summarized the research results. Stunningly, Domenic has immediately closed it, labeling it as "off-topic".

In December I've prepared the implementation for an origin trial to acquire real-world data on the debated risks and resolve the disagreement. As soon as Domenic was informed about my intent, within 3 minutes he instructed the chromestatus.com admin to revoke my access, thus preventing the path to a resolution. This is in stark contrast with the WHATWG's working mode. By this time the origin trial might be in progress, but 2 months were lost due to animus.

These and other counterproductive actions necessitated a code of conduct complaint.

Continuing this pattern, the implementations and the 2 months' work I've done isn't even mentioned in this description. It is clear that the intent is to make my work disappear.

It is very difficult to "collaborate" in this manner, yet it should be noted that despite all the negatives I've experienced, I have great respect for Domenic's expertise in standardization. We don't have to be always right to be valued.

What's wrong with this proposal?

1. The intent was to make specification and implementation easy, not the developer experience good.
2. The proposal ignores developers' requests (which came later, to be fair).
3. It ignores the best practice and contradicts common sense, causing a steeper learning curve and more mistakes: a worse developer experience.
4. It focuses on JS-dependent solutions (client-side rendering). Use-cases of MPA, no-JS (a11y on slow networks) were just after-thought. As the current trend is to move back from SPAs to MPAs, these use-cases become more important once again.

There is an even more concerning pattern underlying the issue:

Imperative bias in HTML standardization

HTML was created as a declarative language. JS was meant to be an enhancement to add affordances, polish and complex features. Yet, what we consider fundamental features today (eg. components, dialog) aren't designed to be effectively usable in a declarative fashion. These features are designed from the start with JS dependence.

This has caused developer dissatisfaction on a large scale, for a long time. 4 years ago: "One of the promises of early Shadow DOM ... was that while we would build the first version as an imperative (JS-based) API ..., we'd come in later and backfill a declarative version that made it very easy to use for common cases." The only such effort is now championed by a non-WHATWG member.

The WHATWG, while contributing immense value to the web platform, seems to be distant from HTML's core tenets. More problematically, the community's input to bring it back was largely ineffective, often because WHATWG members did not show interest, like in the case of the <search> element. In my opinion.

Fact-checking the description

[form submission functionality] was not palatable to implementers, other web developers, or the accessibility community.

"Palate" is the gauge of the master chef, not the master engineer, but it sums up the reasoning against form functionality well: dislike, not technical reasons.

• Only one web developer opposed form functionality (Scott, who wrote the specification): he has repeated Domenic's mistaken assumption about duplication and huge implementation costs. An unsound argument.
• From the accessibility community only one person commented (Carolyn, who made the proposal).
• A few of his colleagues at Google nodded in the previous triage meeting in support. The meeting was running long with no agreement in sight, so people just wanted to be over with it.
• No implementers have shared their evaluation of the implementation with form functionality. Despite this, Domenic has falsely claimed that "both implementers" (who?) have "answered, several times".

Only 2 "primary contacts" and recently a colleague of Domenic commented in opposition of form functionality. The 8 developers who explicitly requested form functionality are not even mentioned. The bias is apparent. Domenic has consistently overstated support for his preferred outcome, amplifying opinions that support it and suppressing contradictory information.

I'm not sure if this counts as "unresolved", since we've resolved to move ahead with the current approach

In fact, we couldn't come to a conclusion as time was running out. This cannot be resolved until the real risks and complexities are understood by participants.

Conclusion

I ask the W3C to reject this proposal at this time in this form due to inappropriate procedure, the lack of research, and policy violations.

Domenic's work is of great value and often great quality, but there are exceptions, such as this low-priority feature. It would be beneficial if Domenic could be more open and inclusive to help and able to let go of overbearing control for features that are less important to him.

How to resolve

The path forward is proper user research and an origin trial with form functionality. With that feedback a more informed discussion can take place and the final proposal can be selected based on whether form functionality was accepted by the developer community.

To avoid undue influence it is best if Domenic focuses on higher priority features where his expertise is more needed (the specification was written by Scott and myself).

The best progress with this feature will be made if my implementation work is supported (eg. my access to chromestatus.com is restored) and I can continue prototyping.

Request to participants

To avoid this discussion becoming another echo chamber, please limit discussion of risks and complexities to the WHATWG issue. Please present verifiable evidence (SourceGraph, HTTPArchive), no more speculations.

Seeing that I've put the most effort into this feature (months), @domenic I kindly ask you to mention my efforts in the description:

• link to the implementations with form functionality
• list me as the first contact. Thank you.

The report and the discussions are long, I don't expect every part of it will be read. If somebody needs a tl;dr of some part, feel free to ask.

I would like to address one point, as I am called out directly:

Only one web developer opposed form functionality (Scott, who wrote the specification): he has repeated Domenic's mistaken assumption about duplication and huge implementation costs. An unsound argument.

This is not accurate.

I am not opposed to form functionality for a "search", but rather I am opposed to the direction the alternate proposal has taken. It was mentioned early on in the <search> element request issue that HTML could consider adding a search or type=search attribute to the <form> element. This attribute could then be used to change the implicit ARIA mapping of a <form> to a role=search.

Effectively, the alternate proposal presented for a <search> element with form functionality has taken the most controversial path to achieve what an attribute on the <form> element could have accomplished.

Presently, the proposal which HTML has requested the TAG review for can also achieve the exact same functionality as the alternate "form functionality" proposal, but for the fact that web authors would be required to nest a <form> within a <search>. This is a minor ask for authors, as well as being a smaller request and lower level of risk for browser implementation.

I still believe having a <search> element without any of the functionality of a <form> is also beneficial in that it allows an alternative for web authors who want to natively specify a section of a web page as a search landmark, but they do not require any of the functionality of a <form>, as they have implemented their own functionality via JavaScript.

Thank you, @scottaohara for the correction and once again I appreciate your professionalism. I apologize for the careless wording. What I've meant is what you've said. I've reworded to: "opposed to adding form functionality to the search element", does that work for you?

And I'm also sorry for being so critical, but saying the same more politely was just ignored...

You've summarized your POV very succinctly. I'd like to put the alternative POV besides it for a whole picture:

[the OG proposal] can also achieve the exact same functionality

Same, but not exactly: there are subtle, hard to notice differences in features, such as the long-dormant bug of two landmarks announced. These are unexpected, frustrating and hard to get fixed due to relatively low attention to these areas. The "completely unrelated functionality could break" sentiment applies here equally: "understanding why it suddenly doesn't work [might be] very hard." The alternative solution avoids these pitfalls.

But the developer experience is different. This is very nuanced and its importance depends on personal values and biases. It is noted that the original proposal does not give any importance to this, not even mentioning these developer needs, which I believe does not meet the new features guideline.

Adding an extra element adds unnecessary topological complexity that increases the possibility of developer mistakes and might break selectors. As such the OG proposal will only serve SPA developers, others will be divided about using it.

The OG proposal focuses on meeting one notional goal - mapping an ARIA role to an HTML element - and ignores what would give meaningful functionality to authors. As one developer expressed: "why would an author ever use this new element? Using a <form role="search"> gives you significant functionality beyond the ARIA semantics."

Although very little user research was done, it suggests this is a common sentiment.

authors who want to natively specify a section of a web page as a search landmark, but they do not require any of the functionality of a <form>, as they have implemented their own functionality via JavaScript.

The rest of "form functionality" is either optional or available even without a form. The feature that's not disabled is associating form controls, which 1) does not affect developers who don't need it and 2) it's a benefit as authors now can add a reset button that works natively. There is no known use-case that would conflict with this solution. Although, if you know one, feel free to share.

I'll note that we have discussed this since November 4+ times: 1, 2, 3, January triage meeting. The "form submit functionality is disabled if the action attribute is unspecified".

This is a good example of how facts that don't agree with others' preconceived notions are ignored, but there are countless more examples. This is the underlying issue in the standardization process.

I'm requesting a TAG review of the <search> HTML element.

This new element allows authors to express the semantics of "a set of form controls or other content related to performing a search or filtering operation".

This is an especially desired semantic because it is something that an ARIA landmark role exists for (role="search"), but today can only be expressed with ARIA. Adding a dedicated element allows authors to follow the first rule of ARIA (~ "don't use ARIA if you can avoid it") and is part of the co-evolution process between ARIA and HTML.

Explainer¹ (minimally containing user needs and example code): inline in https://github.com/whatwg/html/pull/7320 Specification URL: draft at https://whatpr.org/html/7320/grouping-content.html#the-search-element

https://github.com/whatwg/html/issues/5811 - Fwiw, and if setting the other stuff aside, I would also agree with the functional benefits being worth it for a Semantic Markup/HTML <_search_> element. Even if compromises on the direction for implementing this would need to be found. :3

_Many apologies if this response is expressed incorrectly or otherwise against any established SoP guidelines, but felt it'd be important to atleast voice it ☺️_

Hi @domenic we're going to be taking a look at this at our upcoming virtual f2f (in 2 weeks). Can you please put the documented user need at the beginning of the explainer?

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 on its technical merits and not on WHATWG process issues. Can we please limit discussion here to that context? Thanks!

It seems obvious to me that the added complexity of making this inherit from HTMLFormElement is not worth the tiny benefit of saving one HTML element.

However, it does trouble me a little that the entire reason this element exists is to have role="search". This makes it less attractive for authors, and makes it less likely to be used. That said, <nav> which also only exists to have role="navbar", is used in almost 2 out of 3 pages, so perhaps that won't be an issue. However, if there's anything useful this element could do, it would certainly be better for adoption.

The explainer mentions that this element closes <p> tags. Doesn't this require a parser change? It seems problematic if an older UA doesn't produce the same DOM from <search>...<p>...</search> as a newer one would.

Wasn't there another comment about set <fieldset> & <searchsection> (which isnt longer than <foreignobject> ) being other options which could be okay parserwise?

but also that

“search” looks like a name consistent with the naming of other elements, allowing for potentially better (or even aid in 1:1) translation to ARIA and coming with enough clarity for adoption. As an author, I’d prefer this element name. #5811

Similar to <nav> although... I am aware that discussions are more fragmented now, and that it could impact how many people's points are discussed. :/

@plinss yeah, we'd change the parser. While in the short-to-medium term this might create minor issues, long term it's what web developers would expect and not having that behavior would result in confusion/disappointment.

We have concerns about the parser change. We understand (and don't disagree with) the reasoning, but feel that parser changes need to be a 'big deal' and question if the benefits really outweigh the cost. We are breaking a promise here and that should only be done when there's a significant benefit. It's not clear the benefit is here. We're not saying no, but more of 'tread carefully'.

In the longer term, we'd like to see a declarative mechanism that allows this kind of parsing behavior change to be added to HTML in a forward-compatible way. (e.g. a meta tag that defines behavior changes, or a micro-syntax in the open tag, or ??). We can foresee wanting this kind of behavior in other yet to be defined tags and if we're going to change the algorithm, better to do it once rather than over and over. (It would also be nice to support new self-closing tags.)

Aside from the parser issue, we're satisfied with this proposal. I've filed an issue against HTML and we're closing this. Thanks for flying TAG.

Hmmm. Late in the discussion, but... any chance that a new form-submission element (this is what it is, right?) might relax the set of available HTTP methods? (cc @mnot)

This is not related to form submission.