Implementation details

1. Implementation complexity
2. DOM building
3. ARIA
4. Disabling form submission
5. Form behavior that’s enabled even without a form element: no change
6. Form behavior that’s not disabled: no change
7. Nesting: no change
8. User-agent stylesheet
9. Shadow DOM
10. Further considerations

Implementations:

• Chromium (prototype, commits on GitHub)
• WebKit (proof-of-concept, commits on GitHub)
• Firefox in progress (commits in Mercurial)

Implementation complexity

In Chromium:

• Checks for kSearchTag when aliasing div: 5 = 2 (parser) + 1 (aria role) + 2 (<p> closing)
• Checks for kSearchTag when aliasing form: 10 = 3 (parser) + 1 (aria role) + 2 (<p> closing) + 1 (form) + 3 (collections)

DOM building

• Constraint: The HTMLFormElement class in the 3 major browsers is final for performance.
• HTMLTreeBuilder (Blink, WebKit): kSearchTag instantiates an HTMLFormElement.
• html_tag_names.json5 (Blink): name: "search", interfaceName: "HTMLFormElement" generates HTMLSearchConstructor() -> HTMLElementFactory::Create()
• HTMLTagNames.in (WebKit): search interfaceName=HTMLFormElement generates searchConstructor() -> HTMLElementFactory::createKnownElement() (WebKit)

ARIA

• role=search if the element tag is search, otherwise unchanged (role=form with an accessible name, role=none without).

Disabling form submission

• HTMLFormElement’s form submit functionality is disabled if the element tag is search and the action attribute is unspecified.
• Empty / whitespace-only action="" attribute resolves to the current page’s address.
• HTMLFormElement::ScheduleFormSubmission() method returns after handling method=dialog.

Sidenote: if <form> wouldn’t be standardized yet, I’d suggest the same functionality.

Form behavior that’s enabled even without a form element: no change

(Depending on the user agent.)

• autocomplete is on by default, defined by the individual form controls:
  • “If there is no form owner, then the value “on” is used.” (HTML spec)
  • “The missing value default and the invalid value default are the on state.” (HTML spec)
• Validation is defined by the individual form controls.

Form behavior that’s not disabled: no change

• <input type=reset> remains functional. It this features is used, this is the developer expectation.
• The search element is registered in document.forms. This is different from <div role=search>, but documented behavior for the <search> element, therefore developers would be aware. This is more intuitive, even.
• Form associated elements (form controls) associate with the closest <form> or <search> ancestor. The presence or absence of action has no effect on association.
  

Nesting: no change

• For implementation simplicity nesting of <search> and <form> elements is invalid in any order.
• <search><search> - it’s semantically not meaningful to put a search component within a search component.
  

User-agent stylesheet

• form, search { display: block; margin-top: 0; } in the user agent stylesheet (Blink: third_party/blink/renderer/core/html/resources/html.css).

Shadow DOM

• <search> cannot be a shadow root: .attachShadow() is not allowed (like <form>, but unlike <div>). (MDN)

Further considerations

• Any affected functionality missing?
• Any layout inconsistencies with <div>?