Intent to Prototype: Search semantic element

intent-to-prototype.md

This intent message is hand-made, NOT generated by Chrome Platform Status.

Contact emails

kaleidealogy@gmail.com

Explainer

https://kaleidea.github.io/whatwg-search-proposal/

Specification

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).

Summary

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 component

Blink>HTML>Parser, Blink>Forms, Blink>Accessibility

Motivation

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.

TAG review

Is this feature too simple/minor for the TAG's scale?

TAG review status

N/A

Risks

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.

Interoperability and Compatibility

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.

Ergonomics

Can't get more ergonomic than this.

Debuggability

New HTML element: no special support needed. The ARIA role=search is observable in the Accessibility pane.

Is this feature fully tested by web-platform-tests?

WIP. Manual test: https://kaleidea.github.io/whatwg-search-proposal/testpage

Flag name

HTMLSearchElement (Note: such class does NOT exist).

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1277435

Patch

https://chromium-review.googlesource.com/c/chromium/src/+/3323365 (squashed) chromium/chromium#100 (unsquashed)

Estimated milestones

?

Link to entry on the Chrome Platform Status

TODO: https://chromestatus.com/feature/

Next steps

1. Request specification review/mentoring: need access.
2. Add tests to WPT (WIP).
3. Request CI (Goma) for Mac (and maybe Windows) preview build.