This intent message is hand-made, NOT generated by Chrome Platform Status.
https://kaleidea.github.io/whatwg-search-proposal/
https://search-element-html-spec.netlify.app/multipage/forms.html#the-search-element https://whatpr.org/whatwg-html/7382/forms.html#the-search-element PR: whatwg/html#7382
I'm looking for review/mentoring of the specification (the mentor request form is not public).
The <search>
element is a new semantic HTML element to mark the ARIA search landmark. It represents a search form: <search>
is short for <form role=search>
or <div role=search>
depending on whether the action
attribute is set (that enables form submission, including implicit form submission when pressing ENTER or equivalent). The benefit of this element is making the best practice for accessibility simpler, more intuitive and semantically meaningful.
Blink>HTML>Parser, Blink>Forms, Blink>Accessibility
Technical: https://kaleidea.github.io/whatwg-search-proposal/#motivation Personal: I was looking for this feature as it would make web development more intuitive and fun. Since it's a rather simple feature, I took the challenge to move forward its implementation as an unaffiliated individual (I'm working on the WebKit and Firefox implementations too). It's been 10 years since I last wrote C++, so be critical. The relevant code-base does not make use of "new" features (such as RTTI) anyway.
Is this feature too simple/minor for the TAG's scale?
N/A
The new element might not function as expected or the layout could be different from form
due to some logic outside Blink relying on the form
tagName.
There is small chance of implementation bugs due to the simplicity, but those would affect forms or collections in document
.
Such issues should be caught with WPT and dev/origin trials.
Third-party code, such as libraries that extend forms and rely on selectors with form
tagName or element.tagName === 'form'
would possibly not function correctly or at all for the new element, these need to be updated or their client has to provide the selector / element reference. Please link any such libraries for evaluation.
Browser support: WebKit implementation: WIP: https://github.com/Kaleidea/WebKit/commits/search-element Firefox implementation: WIP.
Can't get more ergonomic than this.
New HTML element: no special support needed. The ARIA role=search
is observable in the Accessibility pane.
WIP. Manual test: https://kaleidea.github.io/whatwg-search-proposal/testpage
HTMLSearchElement
(Note: such class does NOT exist).
False
https://bugs.chromium.org/p/chromium/issues/detail?id=1277435
https://chromium-review.googlesource.com/c/chromium/src/+/3323365 (squashed) chromium/chromium#100 (unsquashed)
?
TODO: https://chromestatus.com/feature/
- Request specification review/mentoring: need access.
- Add tests to WPT (WIP).
- Request CI (Goma) for Mac (and maybe Windows) preview build.