Skip to content

Instantly share code, notes, and snippets.

@Kaleidea

Kaleidea/search-element-request.md

Created November 10, 2021 09:53
Show Gist options
  • Save Kaleidea/3162fb8d8dc8588140e8286fd4a5b714 to your computer and use it in GitHub Desktop.
Save Kaleidea/3162fb8d8dc8588140e8286fd4a5b714 to your computer and use it in GitHub Desktop.
Download ZIP
<search> element request with <form> functionality
Raw
search-element-request.md

Consider making the HTML <search> element an alias for <form> when the action attribute is specified

This 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:

  1. Motivation
  2. Feature definition
  3. Best practice
  4. Requests for this feature
  5. Prior art

Gists:

  1. Including the original proposal: <div> functionality
  2. Alternatives
  3. Migration guide
  4. Specification draft
  5. Implementation details

Motivation

The <search> element was originally proposed as an alias for the <div> element. This request proposes <search> element as an alias for the <form> element to expose form functionality. This is

  • a popular developer request
  • the best practice as demonstrated by the MDN example and the WAI-ARIA example.
  • the common sense mental model: "The search element represents a part of a document or application that contains a set of form controls or other content related to performing a search or filtering operation."

Consider supporting this use-case with the <search> element to improve API ergonomy and to foster the best practice. In the long term this will reduce the learning curve, increase developer satisfaction, make accessibility more intuitive and consequently improve the quality of the World Wide Web. These long-term benefits are worth a little extra effort up front, which - as demonstrated - comes at little implementation cost.

Feature definition

  • <search> functions like <div role=search>
  • <search action="..."> is an alias for <form role=search action="...">

This is achieved by disabling the form submission when ENTER or a submit button is pressed if the action attribute is unspecified. Other form functionality is opt-in: if the developer makes no use of it then it does not change the application's behavior:

  • form validation
  • reset button
  • autocomplete is on by default

The wiring of <search> as a form is documented:

  • registration in document.forms
  • associating with descendant form controls

Nesting of <search> and <form> is invalid in any combination:

  • <search><search> is semantically meaningless
  • <div role=search>...<form> and <form>...<div role=search> can often be refactored to a single <search>. Researching usage patterns in the wild suggests this to be possible in most cases.

Best practice

The most common use-case for a <search> element is site search. The best practice for implementation is <form role="search" action="/search"> as demonstrated by the MDN example and the WAI-ARIA example. Exceptions to this are client-side rendered search results (use-cases without page navigation), like SPAs, in-page search and table filtering. OTOH SPA-MPA hybrids (transitional apps) use <form> to provide fallback in case JS is disabled or fails to load, improving accessibility.

Requests for this feature

  • tweet - "Using a <form role="search"> gives you significant functionality beyond the ARIA semantics."
  • tweet - "Should the <search> element be an extension of the <form> element such that it can process its own form actions without having to also be wrapped in a <form>?"
  • tweet - "<search> makes sense and would be great if [...] it could process its own form actions without a <form>. I would expect that feature would make (correct) usage of the element by devs more likely too"
  • tweet - "The semantics of <form role="search"> is more motivating."
  • tweet - "Aren't you meant to add role="search" to the <form> element rather than a separate element?"
  • tweet - "Extra attribute on a <form>?"
  • github - "I haven't run into a need for <div role="search"> instead of <form role="search">"

Prior art

This request builds upon the request for the <search> element implementing <div role=search>. The decisions made there that don't affect form functionality also apply here:

  • search { display: block } in the user agent stylesheet

This issue focuses only on the aspect of exposing form functionality, specifically: implementation details, viability and corner cases.

Gists

Due to length these are split into gists:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment