This is a draft implementation made in a rush in a few hours without prior knowledge of the codebase.
There was no time to build it. I heard I might need a buildfarm... Consequently it might not compile.
It is only meant to demonstrate the basic changes needed to implement the form-based search element.
github: commit 9fe3d39c16095b022be2c72aefd6095d3565d3d2 (origin/main)
Should the implementation of a hybrid element as defined above fall through, an alternative is to define 2 elements (<search> and <searchform>) for the 2 use-cases:
<search> === <div role=search><searchform action="..."> === <form role=search action="...">Implementing this is trivial by aliasing HTMLElement -> <search> and <form> -> <searchform>. Corner cases of nesting need no consideration, and the specification is a trivial "Uses HTMLFormElement, as defined for form elements". The trade-off is that two instead of one element specifications are added.
Should 2 elements find opposition, the proposal would be to favor the best practice:
This solution satisfies the original use-case defined as "people who don't want form behavior": <search> without the action attribute behaves as <div role=search>, the same as the original proposal.
Breakdown of individual form features:
action attribute is unspecified.<input type=search>).document.forms, this has no effect unless the developer iterates `forms`, in which case this is expected.
I'd like to raise concerns regarding my experience recently contributing to the ongoing standardization of the search element. I'm facing serious communication difficulties, misunderstandings and disrespectful comments. I'd like to ask for your attention and independent input to steer this discussion towards mutual understanding and an outcome that's inclusive to differing perspectives and practices.
There is a disagreement about the viability of extending the form element. To prove my point I've implemented the form-based search element: 29 lines changed for the key features, proving its viability and low implementation cost.
This input is not welcome, deliberations about it are not reciprocated. We are discussing incompatible concepts (reuse vs. duplication) and despite my attempts to clear up this misunderstanding, my reasoning is not
<search> element an alias for <form> when the action attribute is specifiedThis proposal presents a novel approach to implementing the <search> element with improved API ergonomy and featuring the best practice usage for the little cost of 29 lines of code changed in Chromium Blink (draft, without tests).
This implementation disproves the prior assumption that aliasing the <form> element raises huge implementation costs, which assumption was the reason to oppose this feature.
Contents:
Please confirm whether this and the previous complaint was received upon receiving this email.
The previously reported pattern of policy and code of conduct violations has continued, despite a complaint to the person at fault. This is very unfortunate and I deeply regret that a prominent member of the WHATWG has to be reported. Please take immediate action to restore a safe environment and to prevent damage to the WHATWG's image as an open, safe, welcoming and professional environment.
"Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back."
This is a detailed response to the code of conduct violating remarks in the <search> element standardization process: previous, last (archive).
Non-technical discussion should be kept to a minimium on the issue tracker. If you wish to respond, please do so here in the comments.
Detailed and polite reasoning preceded the problematic comments: