Consider creating an HTML search element

[carmacleod]

All of the ARIA landmark roles (banner, complementary, contentinfo, form, main, navigation, region) have a corresponding HTML element (header, aside, footer, form, main, nav, section) whose implied role is a landmark role... except for the search role.

Consider creating an element called "search" that will have an implied search landmark role, i.e. it would have the same semantics as <div role="search">.

The intent of creating this element is to allow user agents to include <search> in landmark navigation, so that users could navigate quickly to the search facility for the document. User agents should not have to rely on the presence of ARIA role markup (such as role="search") in order to decide whether to include an element in landmark navigation.

Note that this is not the same as a search input (which has an implied role of searchbox). The search landmark can be thought of as a container for search-related controls, i.e. a search landmark could contain an input with type="search".

[Kaleidea]

Creating a landmark needs to be a conscious decision on the part of the author, and I'm a bit concerned that giving authors a <search> form element may lead to some unintended landmarks when the author just wanted a non-landmark search form.

By definition <search> is a landmark just like <form role=search> or <div role=search>. If the author wants a non-landmark search form then they are supposed to use <form>. I think your concern also applies to your proposal: what if someone wants a non-landmark search field without form submission? Using the <search> element as a wrapper might be attractive, but it's similarly wrong.

In any case, thank you for mentioning this, I'll add explicit wording to the specification draft to emphasise the <search> element should be used only when intended as a landmark. With that guidance, using <search> unknowingly when a landmark is unwanted would be akin to using <main> incorrectly, such as having multiple <main> elements, or highlighting a "main" (dominant) element in a sequence of elements that's a small part of the document. The standard can't protect from misuse, just give clear guidance.

Nevertheless, if you have a strong concern that such misapplication would happen by mistake a lot, could you present some use-cases or examples you have in mind, where this concern could apply? We (I) have discussed the 3 most common use-cases, those are landmarks and I can't recall a non-landmark search form use-case.

Also, having a simple div alias gives authors the option to create a search landmark without using a form at all, if they prefer.

There's no need to use the form functionality at all. Your original use-case is a first-class part of the alternative proposal: you would use <search> exactly how you proposed, without providing an action attribute. Form functionality is either opt-in (validation, reset, document.forms), on by default (autocomplete, whether there is a form or not), or disabled in this case (form submission). I've written about this in detail. My goal was to satisfy both usages without any extra burden for web developers.

I hope I've addressed your questions sufficiently. Probably too much detail, as I prefer to err on the side of clarity, sorry for that. If some answer is not satisfactory, feel free to make a more specific question. Particularly, it would add value to see examples of a "non-landmark search form".

[foolip]

SG hat off

@Kaleidea your suggestion is to let <search> use the HTMLFormElement interface. I don't think it would pan out, so let me try to explain why I think that.

The problem is breaking assumptions of existing code, assumptions that have always held until now. For example in JS it's been safe to assume that e instanceof HTMLFormElement would only be true for <form> elements. There are 1.6 million hits for "instanceof HTMLFormElement" in HTTP Archive. I found that https://cdn.noibu.com/collect.js includes the code if (e instanceof HTMLFormElement) return "form". I don't know what that code does, but it's a virtual certainty that some sites would stop working if a <search> element were added. And the code that broke could be ancient, making the problem hard to understand and connect to the addition of a <search> element.

This is a similar kind of problem we have to worry about when removing features, see Blink principles of web compatibility for more on that.

It's not impossible to overcome a problem like this, but there would have to be a very strong reason for trying to go down that path. For a new feature, when complications like this can be avoided, I think it's best to do so.

[foolip]

I should also say that even without those compat concerns I'd be very cautious about the suggestion simply because there is no precedent for it. There is no other element <bla> where there's an HTMLBlaElement also used by some other element. There are cases like <ins>+<del> and <audio>+<video> where there is some sharing, but not in the same way. Assumptions around how element names and interface names relate could be made in places we don't know about yet, and again it seems like a risk not worth taking.

[bathos]

@foolip this doesn’t invalidate your point at all for obvious reasons but the compulsion to share silly web detritus trivia is much stronger than i could ever hope to be. HTMLPreElement is used by listing and xmp.

[ten thousand apologies]

[Kaleidea]

Thank you @foolip for the detailed reasoning, this is very valuable feedback, the kind I was looking for. I share your concerns about such complications. If I am able to find scenarios where significant breakage would occur, my opinion about the feasibility of this solution would change.

There are 1.6 million hits for "instanceof HTMLFormElement" in HTTP Archive.

For those interested in seeing some examples, the same search in public open-source repositories: https://sourcegraph.com/search?q=context:global+instanceof%5Cs%2BHTMLFormElement&patternType=regexp

I found that cdn.noibu.com/collect.js includes the code if (e instanceof HTMLFormElement) return "form". I don't know what that code does, but it's a virtual certainty that some sites would stop working if a <search> element were added.

That's a proprietary tracker, so no unminified source 🎉:

• https://sourcegraph.com/search?q=context:global+cdn.noibu.com&patternType=literal
• https://slayterdev.github.io/tracker-radar-wiki/domains/noibu.com.html

I've debugged it on the first site (currentcatalog.com): It's an IIFE, the sole calling function gathers some attributes from the DOM. Interestingly, it does not care about forms, only links, images, scripts, styles, etc. However, if it did it would want to process <search> as a "form" element, so that logic makes the right assumption. That tracker would work as expected for <search>.

Btw, what was the bigquery that led to this? In open-source repos I've found only one similar case, even there it's inconsequential.

[Kaleidea]

The problem is breaking assumptions of existing code, assumptions that have always held until now. For example in JS it's been safe to assume that e instanceof HTMLFormElement would only be true for <form> elements.

Yes, such assumptions will be broken.

Assumptions around how element names and interface names relate could be made in places we don't know about yet, and again it seems like a risk not worth taking.

That is an assumption itself ;-) Nonetheless, it has to be investigated. The questions are: (1) how prolific such assumptions are and (2) how severe is the consequence of breaking those assumptions?

There are two cases when such assumption fails:

1. Match by interface: Treating a <search> element as a HTMLFormElement when only <form> is expected. This is unlikely as checking tagName is simpler, shorter and more efficient. Also, I fail to come up with a reasonable use-case where this would cause a problem. Say, for ex. a HTMLFormElement would be cloned using createElement('form'). That would be bad programming, but if happens the result is just the clone losing its search landmark role. Bad for a11y, but not a breaking issue.
2. Match by tagName: Treating a <search> element as not a form when it should be. This is the case that will occur most likely. The result could be a search form that cannot process and submit its data, or the popup suggestions for the search input field won't work with a selector ex. "form input[type=search]" ("form" doesn't need to be there actually).

In both cases the solution is simple: don't use the search element until your JS, libraries, and the targetted browsers support it. As long as the JS and the HTML is under the developer's control, it's their responsibility to use only features that are available.

Where the form functionality of the search element could cause problems is HTML not under the control of the developer:

• Libraries (if affected): don't use search (or the lib) until it adds support.
• Sanitizers: whitelisting solutions (any decent sanitizer) won't accept form or search, unless explicitly enabled by the developer.
• Trackers, crawlers: wouldn't affect the usability of web pages, so the impact is not breaking. The data collected would be incomplete, but if that's some crucial infrastructure (eg. google search), then it will be updated long before the search element is widely used.

So far I haven't found a case where assumptions of the relation between HTMLFormElement and form would have broken the user experience. Breakage could only occur if the developer would use the search element and rely on JS code that queries <form>s, but does not handle the <search> element. That is a very specific scenario, and the responsibility of the developer.

[Kaleidea]

This is a similar kind of problem we have to worry about when removing features, see Blink principles of web compatibility for more on that.

Adding an opt-in feature though does not break anything, while removing a used feature does.

I should also say that even without those compat concerns I'd be very cautious about the suggestion simply because there is no precedent for it. There is no other element <bla> where there's an HTMLBlaElement also used by some other element. There are cases like <ins>+<del> and <audio>+<video> where there is some sharing, but not in the same way.

• <h1>-<h6> are HTMLHeadingElements
• <q>, <blockquote> are HTMLQuoteElements
• <ins>+<del> are HTMLModElements as you said
• listing and xmp were HTMLPreElements as @bathos said
• td,th are HTMLTableCellElement
• col,colgroup are HTMLTableColElement
• tbody,thead,tfoot are HTMLTableSectionElement

Though these are not "new" elements for developers, there are quite a few.

Additionally, almost all semantic elements and many more are HTMLElements, though you might not count that. All in all - subjectively - I don't have the impression that developers could ever reliably assume a 1-to-1 tagName <-> interfaceName mapping. That however is biased by my developer practices and you might find plenty of counter-examples.

---

I hope I've given a satisfactory explanation of this viewpoint. I'd highlight this as a summary: Already existing pages won't break by the introduction of a new element that they don't use. A few libraries, etc. will need to be updated before they can be used with the new element. The update is simple and using the new element is optional.

[foolip]

@foolip this doesn’t invalidate your point at all for obvious reasons but the compulsion to share silly web detritus trivia is much stronger than i could ever hope to be. HTMLPreElement is used by listing and xmp.

[ten thousand apologies]

Nice find, and apologies accepted 😄

I've filed https://github.com/w3c/webref/issues/445 about that, since that's what I used to look for interfaces used by multiple elements. Given how listing and xmp are special cased this is probably the only such case. It's precedent, but an obsolete precedent then.

[bathos]

there are quite a few

I believe @foolip specifically describes cases where the “middle” of the name is the same as one of the specific tag names that uses the interface.

The gist, I think, was that presence of a specific tag name in the interface name leads to a reasonable developer expectation that the interface is specific to elements with that tagname precisely.

Though listing and xmp technically do that, they’re “non-conforming” and this behavior is just there for backwards compat. I meant that as a joke / interesting (well, to me...) bit of trivia rather than a serious counterexample. (It seems fair to say that deprecated elements wouldn’t make sense as useful “precedents”.) Of the others mentioned, col+colgroup arguably fits the bill given table member elements are like HTMLTable{MIDDLE}Element. The rest don’t seem to match; their names already communicate that they are “generic” pretty well.

Even if one feels col/colgroup “counts” in a technical sense, this is pretty obscure and the interface seems unlikely to get referenced nearly as much as a “powerhouse” like HTMLFormElement. The spirit of the comment was about developer expectations rather than technicalities :>

[foolip]

Btw, what was the bigquery that led to this?

@Kaleidea I used this query:

SELECT page, url
FROM `httparchive.latest.response_bodies_desktop`
WHERE STRPOS(body, 'instanceof HTMLFormElement') > 0

Already existing pages won't break by the introduction of a new element that they don't use.

The problem is that code for some completely unrelated functionality could break when a <search> element is added to the page. That code might be very old, and understanding why it suddenly doesn't work very hard.

I'm going to step away from this issue. Having <search> be an HTMLFormElement doesn't seem promising to me, and I can't justify spending time getting deep into the details.

[chrishtr]

Hi @Kaleidea, after the HTML spec triage meeting today, I went through this issue to understand it better. Hopefully what I have to say below helps.

I agree that "not viable" is not quite the right phrase. What I think Domenic meant is that the risk and complexity of the approach you're suggesting is high (because it's a new thing with a number of dependencies), and possibly not even "web compatible" (because there would be too many broken sites for all of them to be fixed). Others have already enumerated several kinds of risk on this issue.

I agree with you that it's probably simpler for a developer, to just put <seach>... in their pages instead of <search><form>.... You're also right that it's possible that the web compatibility risks and other risks are lower than have been estimated by others in this thread.

Unfortunately (or fortunately, because the web is so successful!), it is necessary to consider carefully the risk and complexity I mentioned above before choosing to move forward with a feature. In addition, we have to take into account that all of us are juggling several projects at once and many competing demands on our time. So we have to sometimes limit investigations and make educated guesses and estimations based on past experience. Some of that limiting and estimation was certainly applied in this case, and led them to conclude that a different solution has better tradeoffs.

In particular, as far as I can tell the approach in this PR from Domenic allows web developers to achieve the same use cases for the user as your PR here. The only difference for the developer is that it's a bit more work for them to put in the extra element or so, and put in the work to understand how they relate to each other semantically. For the user, the end result is the same on sites that implement this technology. And PR 7320 has, in the educated estimation of several domain experts, substantially less complexity and risk.

So I do think it makes sense to land, implement and ship in browsers the approach from 7320. We can then gather developer feedback at scale about whether this really meets their needs or falls short in some way, and address those gaps if so, perhaps even with approaches similar to the one you prefer if there is a compelling enough demand.

My personal estimation is that the solution in 7320 will be plenty good enough. There are already a number of cases where developers need to add multiple elements to achieve a use case, and others where it's substantially more complex than that, and they still do it because it's worth it to have the feature on their site.

[Kaleidea]

@foolip Thanks for the bigquery. To avoid misunderstandings, would you please acknowledge that the example you've brought works properly with the addition of form functionality?

The problem is that code for some completely unrelated functionality could break when a <search> element is added to the page. That code might be very old, and understanding why it suddenly doesn't work very hard.

This can be said about any newly added feature: it's the common fear of the unknown. To shed light on the real risks we have to do research. Since you can't justify spending time, I've done that and found that the risks are localized to the search element, predictable and preventable. We don't have to worry about functionality unexpectedly breaking.

[Kaleidea]

Hello Chris,

Thank you for your input. This discussion has grown unnecessarily long and it's easy to miss some key points. I hope it will help to clarify these:

Others have already enumerated several kinds of risk on this issue.

To clarify, 4 experts have opined on the risks: myself (software architect, implementer), Philip (editor), Domenic (editor), Scott (a11y, not editor).

I have implemented this feature both with and without form functionality in 3 browsers. I wrote 15+ page-length comments explaining the implementation and analyzing all the possible risks raised by others. Philip wrote 3 comments, Domenic 3 sentences, Scott reiterated Domenic's assumptions and discussed orthogonal questions in 3 page-length comments.

I have done the necessary research that no other participant has done and more, I've put an order of magnitude more effort into this specification than all other participants combined. This uniquely qualifies me to summarize that all the risks enumerated were technically wrong, contradictory to practical evidence and deductive reasoning about software behavior. Plainly: those risks are non-existent. You'll find a detailed enumeration of the speculated risks and their rebuttal in the next comment.

complexity of the approach you're suggesting is high

I've implemented this approach in 3 browsers with trivial complexity. I've spent weeks implementing this feature, then wrote 15+ pages and a proposal to explain it. This is the cornerstone of this discussion. Please help me understand, how does it happen that all colleagues of Domenic, who comment are unaware of this fundamental fact?

possibly not even "web compatible" (because there would be too many broken sites for all of them to be fixed)

Fortunately, there won't be broken sites. As the proposal is to add form functionality to the search element, which is not standard yet, this has no effect on valid sites that have no search element. There are very few sites that have one, those do not enable form functionality (no action attribute), so no issue there. A layout change (inline -> block) however is possible with the new element regardless of form functionality (thus affecting the original proposal).

it is necessary to consider carefully the risk and complexity I mentioned above before choosing to move forward with a feature.

This is what we've been doing for 2 months. We've evaluated the potential risks, although I took the brunt of the work upon myself. To reiterate: the complexity is trivial, the impact on the ecosystem is minimal and non-breaking, the risks well understood, localized and managable. Details in the next comment.

[Kaleidea]

The list of assumed risks and why those aren't serious:

1. Browser complexity ("Huge implementation cost" - Domenic, Scott): This is expressly false as proven by the trivial implementation, there are no complications or unexpected interactions. We've been through this many times, but despite my effort and patience, it was all ignored.

2. Huge "spec lift" (Domenic): This was correct in the sense that editorializing was a days-long, tedious, repetitive process. I wholeheartedly understand that Domenic did not want to do this, so I took that task upon myself. It is done, no longer an issue. The added meaningful content is almost the same as with the original proposal.

3. Complexity affecting the ecosystem (Kaleidea): Most notably sanitizers and routers will need to be updated to be functional for the search element. The update is trivial in most cases. This is not a risk: decent (whitelisting) sanitizers drop unknown elements and libraries not supporting the search element will only lose functionality for that specific element. This is under the developer's control: wait for the update before using search.

4. Parser change (Henri): Introducing a new element (the original proposal) changes parser behavior regardless of form functionality. This can result in changes to the parsed DOM tree (unknown elements are not paragraph-closing). In non-supporting parsers this can lead to search element within an unclosed p element, resulting in CSS selectors not matching and layout differences. Not a serious issue (verify browser compatibility).

5. Fantom risks - random, unrelated breakage (web compatibility - Philip): "code for some completely unrelated functionality could break when a <search> element is added to the page." The wildcard argument: anything could go wrong. This could be said about any new feature and that's how much it weighs. The sole example meant to demonstrate this turned out to be evidence that code assumed to break actually works as expected.

That's all. We've looked thoroughly, but no one found evidence for a single case where introducing form functionality would cause breakage.

[Kaleidea]

Summary

To summarize the above findings:

• Negligible complexity: all the features are already available, only the wiring of those features changes.
• Minimal impact on ecosystem: a handful of libraries that work with forms will need to be updated, the update is trivial in the general case.
• The effect of the search element is limited to that element. Unrelated functionality is not affected.
• Sites that don't use the search element are not affected at all.

In conclusion: there are no significant risks, Domenic's, Scott's and Philip's arguments are incorrect.

What's the source of the confusion?

A hint from annevk suggests that the search element with form functionality was compared to custom elements inheriting builtin elements, where significant complexities were encountered.

I might be at fault for unknowingly triggering this memory as I've used the word "inheritance" to describe the implementation. Well, I was wrong. The final implementation does not use inheritance, just a simple bitflag.

This also means that the complexities of potentially multi-level inheritance, async definition, etc. (the prior experiences) do not apply.

Conclusion

This discussion has become an echo chamber of speculated risks and complexities, distracting from the fact that there is evidence to prove the viability, simplicity and limited risks of form functionality.

If WHATWG principles and the code of conduct were followed, this discussion would read very differently: we would be discussing specific examples, real consequences and risks. The origin trial to acquire real-world data on the debated risks and to resolve the disagreement would be already in progress if Domenic wouldn't have revoked my access to chromestatus.com.

I hope this will change, that others are willing to cooperate, review their assumptions and support my work.

The way out of running these circles is to gather feedback from the web developer community, for ex. by running the origin trial. If you wish to, it would help to support my work for the origin trial.

[foolip]

@Kaleidea as I said, I'm going to step away from this issue. If this comes to an Intent to Ship on blink-dev I will have to expand on the compat risk that I see and the analysis that would be needed.

[Kaleidea]

@foolip I've only asked "To avoid misunderstandings, would you please acknowledge that the example you've brought works properly with the addition of form functionality?"

It would help to resolve the disagreements, if you would. I've already analyzed that to save you time and detailed how it treats the <search> element as a form, which is the expected behavior, therefore it does not break:

It's an IIFE, the sole calling function gathers some attributes from the DOM. Interestingly, it does not care about forms, only links, images, scripts, styles, etc. However, if it did it would want to process <search> as a "form" element, so that logic makes the right assumption. That tracker would work as expected for <search>.

Did I spend 2 hours debugging a minified source fruitlessly?

[Daasin]

Perhaps the discussion currently taking place at https://github.com/w3ctag/design-reviews/issues/714 aswell as https://github.com/whatwg/html/pull/7320 could be relevant?

[jcsteh]

<search>
  <form>...</form>
</search>

or

<form>
  <search>...</search>
</form>

or

<form role=search>...</form>

would all be the same as far as how these patterns were exposed to AT.

@scottaohara , I don't follow this. The user might perceive them similarly, but they're definitely different in terms of a11y tree exposure. In particular, <form role="search"> would override the form role with the search role, whereas the other two provide both roles, albeit in a different nesting order. Can you clarify your thinking here?

[scottaohara]

@jcsteh in the other two instances the from landmark is not supposed to be exposed due to no accessible name of the form element.

[jcsteh]

That's fair, but the element is still exposed with the form role , even if it's not a landmark. If an AT chooses to report the presence of forms even if they aren't landmarks, these will not be equivalent. NVDA doesn't report non-landmark forms, but I vaguely recall JAWS might; I'm not certain.

[scottaohara]

Last I had checked JAWS made no mention of a form element if it had no name.

If need be, we can clarify this further in html aam to suppress a form landmark role if it is nested with a search element.

edit: yes, testing again today with JAWS w/chrome and firefox, an unnamed form is not exposed with default settings for either of the screen readers. Neither does Narrator with Edge on Win11.

Further, only recently (last few months - much later than my original comment here) was HTML AAM updated to indicate a form element could still expose a form role (though not a landmark). Previously a nameless form was not mapped/a generic element.

ARIA 1.3 has additional updates indicating that only a named element with a form role should be exposed as a landmark form.