Consider creating an HTML search element

carmacleod commented 4 years ago

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

bathos commented 4 years ago

I didn't know a specific role for this existed; it never occurred to me that there might be extra landmarks. Pretty much every app I've worked on has had a search filters bar/sidebar/panel and apparently I've never marked them up correctly. If there were an element for it, I suspect I would have discovered this sooner.

domenic commented 3 years ago

Hey @carmacleod, we discussed this in the triage meeting (https://github.com/whatwg/html/issues/6936) and there was general agreement (including from implementers in Gecko and Chromium) that this is a good idea.

However, we worried a bit about the name. <search> sounded too much like a search input, not a search landmark. I.e. it sounds like a widget that would do a search.

This isn't the biggest deal; authors can always read the docs and figure it out. But I think it would be a shame if we introduced a new feature and then immediately had to add to the docs: "You may be looking for <input type="search"> instead."

Can you (or others) help us think of ideas for alternate names that might avoid that pitfall?

scottaohara commented 3 years ago

FYI: I've discussed the following with @carmacleod

Would something like one of the following names be of help here: "searcharea", "searchform", "searchgroup" or "searchset"? (fwiw, carolyn and i prefer 'searchset')

In terms of how this might be spec'd beyond the naming of the element, some thoughts for your consideration:

Presently, depending on how a page's search functionality is setup (e.g., using an actual form submission, or using JavaScript), current use of the landmark would be expected to look like one of the two following markup patterns:

<form role=search action=... method=get aria-label="site (or some other name to describe purpose)">
  <!-- search related controls here -->
</form>

 or

<div role=search aria-labelledby=foo>
  <p id=foo>Filter results</p>
  <!-- search related controls here -->
</div>

While there is no requirement in the ARIA spec for a search landmark to have an accessible name, it can be helpful to provide one, particularly in instances where there might be two search landmarks on a page, or if the search controls have a specific function that is a variant of searching - e.g, filtering. It would be nice if the new element could be named by a native HTML feature, for instance similar to a <fieldset> via its <legend>.

domenic commented 3 years ago

Personally I like searcharea and searchgroup; either of those would be good in my book. Can you tell us more about why you like searchset? I don't normally think of a landmark or section as a "set".

For the non-naming point, it sounds like what you're suggesting is that we'd benefit from changing the accessible name computation algorithm for this element in some way, so as to give a "first-class" (i.e., non-ARIA) way of specifying accessible names.

What kind of markup pattern do you think would be best for such scnarios? It looks like other sectioning and grouping elements use title="" attributes. This seems a bit strange given how that will also create a tooltip in desktop browsers, but probably there's a good reason for the precedent... should we follow it?

scottaohara commented 3 years ago

Personally I was leaning towards searchset purely towards the relationship I see here with fieldset. And that’s because the search landmark is meant to represent a related grouping of form controls / potentially links and instructions that are related to searching. As such, it isn’t a huge leap to make, imo, that a search grouping of form controls could be named by a legend, similarly to a standard grouping of form controls.

To your point though, yes this could be done via the title attribute. It’s just unfortunate that’s the only way to name these elements using HTML at present. Just figured this would be a good opportunity to suggest such a mechanism.

So my original though was something like

< searchgroup> < legend>name< /legend> … < /searchgroup>

The mapping/behavior for legend already exists, so if it could be extended to work for this new element, as it does with fieldset, it seemed a path with lower potential for friction.

I hadn’t thought of another element, aside from legend, since I figured that’d be out of scope. Though ideally, to allow other elements that are also landmarks to be named, it’d be nice if there were either an element that could work similarly to fieldset / legend or table/caption. Or I suppose an attribute that could indicate the element’s content was to be used as the accessible name for the closest ancestor element that was an implicit landmark. Or if more direct relation was needed, it could work as an attribute (spitballing: namefor=foo) pointing to the id of the element it was to name.

I understand this is all obviously beyond what was previously discussed, so definitely do not want this to hold up the primary objective of creating the new element. But appreciate that I could talk this out a bit more. Thanks.

carmacleod commented 3 years ago

searchgroup is also ok with me (@scottaohara says he's fine with it, too).

[Edit: Although... thinking about existing elements with "group" in the element name, there's hgroup, colgroup, and optgroup. Both colgroup and optgroup feel like "sub-groups", which might be confusing. And optgroup supports a label attribute, which might be an odd precedent if the "search" element were to support a "legend" child element... so I still have a slight preference for the name searchset with optional legend child, along the same lines as fieldset with legend child.]

I'm not a fan of searcharea - I guess it feels like it could be confused with "this is the area to search within" as opposed to "this is a group of things to aid in searching the site/page/internet/whatever". :)

j9t commented 3 years ago

However, we worried a bit about the name. <search> sounded too much like a search input, not a search landmark. I.e. it sounds like a widget that would do a search.

If this element is not related to performing a search (and input for a search query), just what is this element for then? What is a “search facility for the document”?

(It seems all perfectly clear for everyone here, but it wasn’t for me when reading through the issue.)

annevk commented 3 years ago

@j9t the first paragraph of OP explains it (and has a link with further information).

annevk commented 3 years ago

"set" seems quite reasonable from the perspective of fieldset, but perhaps not from the perspective of mathematics. Another variant I thought of is searchsection, but it's quite long (not longer than foreignObject though so I think it's okay parser-wise as far as optimizations go).

j9t commented 3 years ago

However, we worried a bit about the name. <search> sounded too much like a search input, not a search landmark. I.e. it sounds like a widget that would do a search.

If this input from the side is welcome (apologies for anything I missed): Is this not the same problem the ARIA role suffers from? And would the consistency not be useful and valuable by itself, similar to what we have with main, nav[igation], or form?

Also: Would the problem of authors mistaking search just for search input (if that’s a concern, re @domenic) outweigh the problem of authors shunning searchsomething because they don’t understand it well enough?

From my (limited) vantage point, “search” looks like a name consistent with the naming of other elements, allowing for great 1:1 translation to ARIA, and coming with enough clarity for adoption. As an author, I’d prefer this element name.

domenic commented 2 years ago

To your point though, yes this could be done via the title attribute. It’s just unfortunate that’s the only way to name these elements using HTML at present. Just figured this would be a good opportunity to suggest such a mechanism.

Ah OK. Yeah, I agree that might be a reasonable thing to tackle, but I think we should do it holistically for all sectioning elements that currently use title="", and not couple it to this proposal. Then we can have discussions like <legend> vs. <summary> vs. <caption> vs. new element vs. <h1> (😉 mostly kidding on that last one).

I'm not a fan of searcharea - I guess it feels like it could be confused with "this is the area to search within" as opposed to "this is a group of things to aid in searching the site/page/internet/whatever". :)

Good call.

Another variant I thought of is searchsection

I like this one too. I think length is not a huge deal since there shouldn't be too many of these per page.

Also: Would the problem of authors mistaking search just for search input (if that’s a concern, re @domenic) outweigh the problem of authors shunning searchsomething because they don’t understand it well enough?

I don't think you should use this element if you don't understand it; my understanding is that mislabeled landmarks are worse than no landmarks at all.

So at this point I think the best candidates are searchgroup, searchsection, and search. I've posted a Twitter poll to see if we can get some web developer sentiment, but to be clear the results are not binding; it's just seeking to get more input :).

gregwhitworth commented 2 years ago

Apologies if I'm being pain here but I really don't want to see a new element added that is solely a wrapper rather than solving the other issues that Open UI is trying to tackle. As with the base attribute for example and leveraging the model. Is it possible to take this there and incubate not only the name but also the parts & associated controller code so that we don't end up with yet another new element that enables that new model?

Specific to the naming, search is by far the most used in the design system/component libs we track.

scottaohara commented 2 years ago

@gregwhitworth i'm not sure i understand the objection? per the tracking link you provided, all the instances of 'search' appear to be concerning instances of input type=search or aria's role=searchbox equivalent. The carbon design system did include their search widget within a role=search containing element. Though, I'd submit they're incorrect to assume that's always necessary. a search field doesn't always need to be within a search landmark, so i wouldn't expect an open ui control to indicate it must?

gregwhitworth commented 2 years ago

@scottaohara objection is a strong word :P

Apologies on missing the initial request here - as I missed that it was solely dedicated to a landmark and not an actual widget. Disregard my statement above.

Paul-Hebert commented 2 years ago

Hey, thanks for working on this! I'd love to have parity between HTML elements and aria roles, and it would be nice to be able to switch from a role to an element in my code.

I'm a little confused about how this would work in conjunction with forms. If I wanted to use a <form> element for native form submission would I continue to use <form role="search">? Or would I nest the new search element in a form? <form><search>...</search></form>?

Either way would work for me. I just want to make sure I'm understanding. Thanks!

domenic commented 2 years ago

This fell off my radar during vacation, but back on it now...

The Twitter poll is fairly conclusive that we should name it <search>. However a lot of people expressed confusion (similar to @Paul-Hebert's above) about when they would use this versus using <form role="search">.

The answer, I believe, is that they would use <search> in place of <div role="search">, and continue using <form role="search"> if they didn't need a wrapper element.

I wonder if we should consider solving the <form role="search"> case as well though. I.e. if our goal is to avoid people having to use ARIA for mainstream use cases (per the first rule of ARIA), then it's less of a win if we tell them to sometimes use <search> and sometimes use <form role="search">.

Ideas I can think of:

Encourage (in the spec and docs) a nested pattern, i.e. <search><form>...</form></search> for search forms. I'm not sure what impact this has on AT users, if any, versus <form role="search">.
In addition to <search> (for the <div role="search"> case), also specify a boolean attribute search which can be placed on <form>. So then you'd replace <form role="search"> with <form search>. There's not a lot of precedent for semantics/AT-only attributes as opposed to elements, perhaps because the win over ARIA attributes is so slight, but it still seems reasonable to me, and philosophically aligned with the goal of not requiring ARIA for mainstream use cases...

scottaohara commented 2 years ago

<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. I personally like the idea of using a search attribute on a <form> element as an alternative to using ARIA. While practically it wouldn't be that different than devs using role=search on a <form>, right now... it being part of HTML could at least allow for extensions of its features or functionality in the future?

jimmyfrasche commented 2 years ago

I have a lot of nav with just a ul so search with just a form seems perfectly normal

Paul-Hebert commented 2 years ago

Thanks for following up! I like the idea of having a <search> element but would probably reach for <form search> first if it were available. Though, I haven't run into a need for <div role="search"> instead of <form role="search"> so there may be a use case I'm missing!

domenic commented 2 years ago

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

Thanks, that's valuable info! In that case I lean toward just a <search> element, with no need for <form search>, i.e. the "Encourage (in the spec and docs) a nested pattern" option above. If we ever do come up with interesting ideas for extensions in the future (e.g. <form search=something>), then we can introduce search="" as a separate attribute...

I'm curious to gather other opinions, either on this thread or as part of the triage meeting (#7201).

carmacleod commented 2 years ago

Thanks, all! I agree with:

element name being <search> (that was my first choice, in the OP)
encouraging nested pattern, either <search><form>... or <form><search>... (the only caveat being that if an author gives the form a name using either aria-label, aria-labelledby or title, then the form becomes a landmark as well. Which is ok - i.e. nested landmarks are allowed - as long as it's what the author intended).
leaving <form search> for consideration sometime in the future

Kaleidea commented 2 years ago

Hello all! <form role=search> is used by MPAs and more accessible client-side apps (transitional apps if you like) that allow for a no-JS fallback to a server-side search page (defined with the form's action attribute). IMO this is a better practice and the shortest syntax <search> should support this.

Use-cases considered:

Site search - usually has an implementation as a server-side page also advertised in the OpenSearch description.
Filter dataset (eg. table, listings) - happens client-side if all data is present, client rendered from server-side data source if data is paged, server-rendered for MPAs.
Search in page (eg. editors) - client-side.

Use cases 1 and 2 would benefit from a short for <form role=search>. IMO these are the most common use-cases.

Alternatives:

The nested form <search><form> or <form><search> adds complication without benefit: Which should be the parent and the child? Where to add aria-label?

<form search> looks good, but is it necessary? Is there any use-case where <search> meaning <form role=search> would have drawbacks and <div role=search> would be used? I'm unaware of such case, maybe someone is.

<form search> also comes with a refactoring drawback when <search> is upgraded to <form search> to provide a fallback: the tag selector (if not using class selector) ... search must be changed to ... form[search] despite not making visual changes.

The latter could be answered by <search form>, which sheds some light on the double inheritance rabbit hole where these alternatives lead.

Personally I prefer the simplicity of <search> inheriting from <form>, unless there are strong technical reasons against it. It would save us difficult questions down the road and favor what I see as best practice.

domenic commented 2 years ago

Personally I prefer the simplicity of <search> inheriting from <form>, unless there are strong technical reasons against it.

There are indeed strong technical reasons against it. The form element is quite magical, and duplicating that magic into another element is a huge implementation and spec lift that isn't worth it so that people can avoid typing the extra few characters of <search><form>.

Especially since then we'd need a case for people who don't want form behavior, i.e. want the current behavior of <div role=search>.

bathos commented 2 years ago

I’d lightly advocate for there to be just one nesting pattern — either <form><search> or <search><form> — rather than both. Maybe this is just me, but when stuff like that is arbitrary it can be more confusing than helpful. (“Hm, it seems to work either way, but I don’t know for sure if there’s a subtle difference in behavior that I’m missing or if they’re really just interchangeable...”)

(Or at least maybe just one should be formally valid per the content model even if both are recognized? Clear usage guidance is really valuable especially when it comes to accessibility concerns.)

scottaohara commented 2 years ago

I only have a slight worry about making a formal declaration about nesting, as it seems like it could unnecessarily limit use.

If a <search> were to wrap an entire <form>, that would indicate that all content of the form was related to the search landmark.

However, there could be a complex form consisting of many sections / groupings of form controls. To help facilitate exposing an important search-related aspect of this form, a markup pattern such as:

<form>
  <search> <!-- controls related to searching, but specific to this overall form, go here -->
  <!-- other form controls and groupings here -->
</form>

From what I've seen, the first example, or simply just using <search>...</search> without using a <form> at all are likely to be the more common options. But, I have encountered at least 2 scenarios that fall into the latter, which are presently being solved by <div role=search>...</div> inside of a lager <form>.

While it might confuse some people that the nesting can be one way or the other, creating a restriction would also then be confusing for people who are already familiar with role=search and know that there is no restriction for nesting that role at all.

domenic commented 2 years ago

Question: should this element be display: block in the user agent stylesheet, or not? Most landmark elements, including e.g. nav, have that.

scottaohara commented 2 years ago

Yes. Display block as a default

Kaleidea commented 2 years ago

<form>
  <search> 
  
</form>
From what I've seen, the first example, or simply just using <search>...</search> without using a <form> at all are likely to be the more common options. But, I have encountered at least 2 scenarios that fall into the latter, which are presently being solved by <div role=search>...</div> inside of a lager <form>.

It's hard to find search landmark inside a form. The closest I found to the above mentioned composite form was a sole button after the search div on a 6year old archived page (outtake, source, candidates (2 false positive): <form> <... role=search></...> + <...>).

Sourcegraph indexes public projects only, including git scraping like this one, but it does not cover the World Wide Web.

It would be interesting to see those examples, maybe it could be refactored. In any case I mean to point out that such pattern is very unusual.

Kaleidea commented 2 years ago

<search> <form>...</form> </search> <form> <search>...</search> </form> <form role=search>...</form> would all be the same as far as how these patterns were exposed to AT. I personally like the idea of using a search attribute on a <form> element as an alternative to using ARIA. While practically it wouldn't be that different than devs using role=search on a <form>, right now... it being part of HTML could at least allow for extensions of its features or functionality in the future?

Currently Chrome exposes <div role=search> <form> as 2 landmarks, different from <form role=search> which is one landmark. NVDA reads it as:

search landmark
form landmark

This is confusing for screen reader users and should be avoided.

Kaleidea commented 2 years ago

Due to screen reader announcing <div role=search><form> as two landmarks (see above comment) the <search><form> nesting is not viable. The key constraints is that the <form> element has to be the search landmark. Not surprisingly the <div role=search> <form> pattern is rarely used, only 79 results. All other patterns are 500+ (no estimate, presumably orders of magnitude more).

The most common use-case for a search element is site search that typically loads the results on a new page when ENTER is pressed. The best practice to implement this is a <form> that works without JS (<form role=search>, no <div> within examples). JS is used to show suggestions while typing as progressive enhancement. This use-case either can't use the <search> element or its accessibility is negatively affected by nesting.

New features and syntactic sugars should favor best practices to nurture a better quality and more accessible internet, therefore I'll attempt to dispel the concerns about technical issues and show a solution that works for both <div role=search> (SPA use-case) and <form role=search> (MPA use-case) semantics.

Please note the problem statement "Consider creating an HTML search element" does not constrain the base element to div, nor the use case to SPA. Although the proposition chose div - an obvious choice for a basic element -, however it could have chosen form as well, which would reflect the best practice.

Please also note the repeated feedback regarding the expectation that form functionality is available in a search element, suggesting this is a common sense expectation, which - if unmet - will often cause confusion:

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 - "why would an author ever use this new element? Using a <form role="search"> gives you significant functionality beyond the ARIA semantics."
tweet - "The semantics of \<form role="search"> is more motivating."
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>?"
github - "I haven't run into a need for \<div role="search"> instead of \<form role="search">"
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 would be unlikely to employ <search> without <form>"

None of these are represented or considered in this process. This is a violation of the new features guideline: "Ask fellow web developers about their opinions. Adjust the list of use cases and requirements as appropriate."

Also, MDN and WAI-ARIA demonstrates role=search with the form element.

Kaleidea commented 2 years ago

[...] we'd need a case for people who don't want form behavior, i.e. want the current behavior of <div role=search>.

The proposed solution:

<search> inherits <form>

interface HTMLSearchElement : HTMLFormElement
the action attribute can be an empty string (note: that would be invalid on a form in HTML5)

but form submit functionality is disabled if the action attribute is unspecified.

requestSubmit() method override returns immediately
key handler (ENTER) is not registered or returns immediately
<input type=reset> remains functional
the search element is registered in document.forms even if the submit functionality is disabled
anything missing?
any layout inconsistencies with <div>?

Benefits:

Make the best practice simple: <search action="/search">
Hit two birds (div - SPA, form - MPA) with one stone.
Avoid never-ending disagreements about <search><form> vs. <form><search> vs. <form search> vs. <searchform>

Form `action` sidenote:

An empty/only whitespace form action is invalid in HTML5 to avoid clickjacking which is no longer a vulnerability. Empty action despite being invalid is still widely used (<form role=search action="">). It can be omitted, also often done (<form role=search action=undefined>). HTML4 was the opposite: empty was valid, but the attribute was required. These restrictions won't apply to the <search> element.

Extra sidenote

Exotic search landmarks - not <form>, not <div>: input, ul, li, components, aside, table, span, section??

scottaohara commented 2 years ago

@Kaleidea,

It's hard to find search landmark inside a form.

yup. it's not common, and the instances I've come across have been behind logins where the entire web page is contained within a <form>. I don't pretend that this is reflective of modern web development practices. Just indicating that there are legitimate instances of this now, and in the cases I've encountered, they have landmarks roles such as search, banner, main, inside of the containing <form>. Granted, they are not likely to be candidates for migrating to a <search> element.

Currently Chrome exposes <div role=search> <form> as 2 landmarks, different from <form role=search> which is one landmark... This is confusing for screen reader users and should be avoided.

That's a bug, a nameless form should not be exposed as a landmark by screen readers. So, that should be fixed, rather than used as a justification.

However, regarding "confusing for screen reader users", how? I agree that it's extra verbosity. But "confusing"? People encounter nested landmarks quite frequently, particularly in regards to nested navigation landmarks, and even search landmarks (e.g., within a banner, contentinfo, complementary). I don't disagree that it is preferable to only have the 'search' landmark announced, per the bug you referenced, but let's not inflate the impact this current bug would have in a way that makes the HTML spec more restrictive than necessary.

Regarding your remaining points, Domenic has already made comments that are relevant to them. I don't have anything further to add there.

domenic commented 2 years ago

To be clear, a new element "inheriting from form" is not viable and if that's the only thing that's acceptable then this feature won't get specced/implemented. It seems there's some disagreement on this which in and of itself is a bit discouraging.

scottaohara commented 2 years ago

@domenic I've been giving this more thought today, particularly in regards to element nesting and I think that if HTML wanted to make a preference for a

<search> 
  <form> <!-- search related stuff --> </form> 
  <!-- other search related stuff if need be -->
</search>

<!-- or -->
<search> <!-- search related stuff --> </search>

that would decrease the potential author confusion about which way it could/should be nested.

For the few use cases of <form> <div role=search></div> </form> I mentioned, those could just continue to use ARIA, as they are now. HTML could just be more explicit in the nesting order. As that'd likely make things a bit easier, I think that'd make sense here if you agree. I've hidden my previous comment about the nesting of the element.

Per the bug about dual landmarks that @Kaleidea mentioned, that could be further mitigated from happening again by HTML AAM specifically stating that if a <search> contains a <form> that the implicit form landmark must be suppressed, since people don't need both a search and form landmark announced for the same content.

Kaleidea commented 2 years ago

Thank you @scottaohara for describing that unusual use-case. Explains it very well, reminds me of ASP forms... :-)

Currently Chrome exposes <div role=search> <form> as 2 landmarks, different from <form role=search> which is one landmark... This is confusing for screen reader users and should be avoided.

That's a bug, a nameless form should not be exposed as a landmark by screen readers. So, that should be fixed, rather than used as a justification.

I didn't expect it to be a bug as the accessibility tree includes both, but indeed Firefox+NVDA only reads "landmark search", while both are present in the A11y tree. Could you link to the documentation of these rules affecting what screen readers read? I'm going by experience and that's not normative.

Just for clarity: both landmarks were read when focusing the input box, but the landmark list only contained the search landmark, not the form.

With this understanding, I adapt my reasoning to focus on simplicity and the benefit of supporting the best practice with the standardized element. More detail in the following comment.

However, regarding "confusing for screen reader users", how? I agree that it's extra verbosity. But "confusing"? People encounter nested landmarks quite frequently, particularly in regards to nested navigation landmarks, and even search landmarks (e.g., within a banner, contentinfo, complementary). I don't disagree that it is preferable to only have the 'search' landmark announced, per the bug you referenced, but let's not inflate the impact this current bug would have in a way that makes the HTML spec more restrictive than necessary.

AT is used by fewer people than the browser in general, thus AT bugs persist longer. With this being a bug there's still value in being able to avoid it without losing the ability to use <search>, but I agree it's not as severe as it seemed.

What "makes the HTML spec more restrictive" refers to?

Kaleidea commented 2 years ago

To be clear, a new element "inheriting from form" is not viable and if that's the only thing that's acceptable then this feature won't get specced/implemented. It seems there's some disagreement on this which in and of itself is a bit discouraging.

Inheritance is not the only solution, but the best match to the common sense mental model and the cleanest separation, therefore my first approach.

There should be no misunderstanding: the viability of inheritance was not discussed yet. It was stated, "The form element is quite magical, and duplicating that magic into another element is a huge implementation and spec lift". We agree that duplication would be terrible and I would never propose that. Inheritance is the opposite, serving to maximize code (and spec) reuse. Nonetheless, I've adjusted the proposal to avoid inheritance as well.

There are some communication difficulties that I experience, such as this mismatch, then very short answers lacking technical explanation and an unwelcoming response ("It makes no sense"), that are certainly not encouraging to put the many hours into researching the use-cases and constraints. I think we can do better than that and work together even if we disagree on some aspects due to differing perspectives. That's just the nature of technical discussions. However, this is not the topic of this issue, therefore I suggest discussing it in DMs, if you are open to it.

On topic:

With the understanding that maybe none of the solutions I'll propose would find implementer acceptance, I'm asking that we explore these options properly and make a best-effort attempt to find a solution that best serves both major use-cases.

I'd like to achieve that both the most prominent use-cases are given equal consideration: I'd expect that the standardization process includes all perspectives. To sum, these are:

<div role=search> if the results are loaded with fetch()/XHR or available client-side.
<form role=search> if page navigation is desired when pressing ENTER/search button.

Other elements used with role=search that are less prominent would be migrated to <search> as a child element.

Kaleidea commented 2 years ago

2 major use-cases

div is used by SPAs primarily, and MPAs that don't cater to low-bandwidth users where JS loading might be unreliable. form is used by MPAs primarily, and hybrid SPA-MPAs (transitional apps) that degrade gracefully on unreliable connections.

IMO the second is the best practice that gives the best accessibility. There are valid cases to use <div>, where a server-side search page does not exist or is not applicable, however, there are many cases where <div> is used, although a server-side search page is available and could be hooked up with no expense to create a more resilient product. By supporting <form role=search> too with the <search> element, developers would utilize this functionality as suggested by prior comment, thus promoting the best practice. It's worth noting that the solution I seek equally includes the <div> use-case explored deeply on this issue: if the action attribute is unspecified then the form functionality is disabled and <search> becomes a replacement for <div role=search>.

I hope this explains why I find the form use-case important: to make the accessibility best practice simpler, so it proliferates, consequently improving the quality of the internet. This is not about saving a few characters.

Imbalance

From this perspective, the form use-case seems to be ignored in this issue and unwelcome. I don't think this meets the standardization process's requirements. To improve the balance I'll propose the next solution adapted to the feedback and I'm looking forward to learning about the viability of the secondary alternative <searchform>: I have the impression that one more element would be a tough sell, your input on that would be appreciated and also about the rest of the alternatives.

Kaleidea commented 2 years ago

Proposal v2

Functionally is the same as the previous: <search action="..."> behaves as a form, <search> without action attribute disables form submit functionality. Empty action="" attribute means the current page's address.

The implementation is different: instead of a new class inheriting HTMLFormElement, <search> is implemented by HTMLFormElement, similar to the semantic elements <main>, <section>, etc. being implemented by HTMLElement.

The specialized behavior is incorporated in HTMLFormElement, branching dependent on the element tag. This avoids the efficiency constraint of final classes (no inheritance) and can be implemented with minimal, trivial changes: disable the submit functionality if the tag is search and the action attribute is unspecified. I expect this approach to be technically feasible as far as I can tell as not a Chrome developer. What opinions branching to disable form functionality would spark I cannot tell, but I can tell its performance impact will be negligible.

Disagreement

There is a disagreement regarding the viability of exposing form functionality. To resolve this I've implemented the proposed solution in 26 lines of code, proving that its implementation cost is not a concern.

I am aware that the expectation was to find a simple solution to the need for a <search> element by aliasing <div> and it was assumed that aliasing <form> has significantly higher cost. The presented implementation proves aliasing <form> is almost as simple as <div>.

A new issue makes a clear case why this solution serves better web developers' needs. The features, implementation, specification, migration path are presented in a more explorable structure.

Communication breakdown

This is the solution I've been trying to communicate, the word "duplication" is not applicable to it. I was discussing "inheritance", but the word "reuse" would have been more appropriate.

With the concept of duplication the original proposal would sound like this: "<search> duplicates the <div> element", suggesting that the code and spec of HTMLElement would be duplicated, which is obviously not the case: it's only referred to in one line: "DOM interface: Uses HTMLElement". The difference makes or breaks the reasoning.

I believe this conceptual misalignment sidetracked the discussion, despite my clarification in a previous comment that there is a mismatch in terminology used. I hope to clear up this misunderstanding.

Openness and courtesy

I respect the standardization experience of those present and I do not wish to - as alleged - tell how to do it. On the other hand I expect that respect be mutual. What I experience is different from the WHATWG's values: "openness, utility, efficiency, and freedom", "a friendly, safe, and welcoming environment for all", "Respect that people have differences of opinion". Due to the communication breakdown and a recent deleted comment it became necessary to ask the Steering Group to help establish a mutual understanding and guide this discussion towards a welcoming and courteous environment.

I know there's a lot on the editors' plate, but to bring clarity, can I ask @domenic to give a detailed, technical explanation:

Why inheritance is unviable? (Why duplication is, is obvious.) I assume due to finalization, but it seems you have more reasons?
What form functionality is unwanted (explicitly opposed) for the <search> element with div semantics?
What developer feedback led to that decision?
Developer interest was not expressed on this issue. Why was the label removed?

The explanations would help to get a better picture and bring our understanding closer.

Opposition

Since this is a low priority feature, there is no need to rush to a solution without giving due consideration for all needs and use-cases, therefore I have to oppose this proposal in this form at this time. Due to discourtesy and the rejection to discuss the alternative of aliasing <form>, I've appealed the decisions to the Steering Group. I hope their guidance will help this discussion elevate to a mutual understanding and achieve an outcome that serves more developers' needs.

domenic commented 2 years ago

Hi @Kaleidea,

I'm sorry that you feel your opinions aren't being respected, or that this community is not open in the way you'd prefer.

I'd remind you that oppenness doesn't mean everyone has to agree with you. It doesn't even mean everyone has to engage with your (ever-increasing-in-length) posts, in a point-by-point manner. Instead, it just means that we need to provide a forum for you to be heard. And you have been heard! Repeatedly. And answered, several times. By both implementers and other web developers.

I apologize for the (now-deleted) message in which I was impatient and short with you; that was indeed not good communication style.

At this point, I myself am not able to invest further time in giving you the same answers repeatedly. (I appreciate those in this thread who have taken the time to do so, often in great length.) I'm happy for you to discuss with the Steering Group (i.e., the implementers themselves) why they will not implement <search> as an alias of <form>, and for them to help facilitate further discussion on this thread or in a private thread if necessary.

However, let's please keep your discussion as such confined to your (private, I guess?) thread with the Steering Group, instead of spreading it over this issue, the pull request, and any new issues. I'll be closing or marking as off-topic any such discussions outside of this issue.

Kaleidea commented 2 years ago

It is unfortunate this discussion came to this point. I've tried to resolve the disagreement with a respectful, technical discussion, that wasn't reciprocated. Out of courtesy I'm asking @domenic if he'd like to delete his comment again, seeing that it violates multiple points of the WHATWG code of conduct. I've responded to and refuted that comment point-by-point separately. Discussion on the issue tracker should have a technical focus.

Your disagreement does not make a comment off-topic. Please see the requests at the end regarding the censorship of an unwanted viewpoint. Note: These comments are archived. Hiding, deleting or editing them - as promised - would be additional evidence of censorship.

I intend to discuss technical questions in a professional manner and I don't feel obligated to read more comments like these (first, previous, last).

For reference the lead editor has made only 2 more short, vague comments with no explanation. Since none of my questions were answered, I have to assume the answers are not known.

Kaleidea commented 2 years ago

Thank you very much @scottaohara for the links and answers, I appreciate your professionalism. The direct link to the "form without an accessible name" rule was very helpful (hard to find). I'd like to concur regarding nesting. IMO either strong author guidance to nest like <search><form> or a validation restriction should be put in place (I have no preference). If it's a restriction then role=search is still there for unusual DOM patterns.

[...] the desire for <search> to be a duplication of <form>.

This is the source of the repetitive miscommunication that I hope we can leave behind. Quite the opposite, the desire is that <search> is an alias of <form>, just like your proposal in which <search> is an alias of <div>. Or you could say <search> is a duplicate of <div>, to give a fair comparison. The implementation cost is of the same magnitude.

A parallel would be shell script aliases: the script can behave differently depending on the name it is aliased to ($0 parameter), but the script is the same. No need to duplicate it.

This is how the semantic elements like <main> are implemented in browsers, all instantiate the HTMLElement class. The proposed solution is to do the same but with HTMLFormElement. That's what takes only 21 lines, same as for aliasing div, +8 lines for disabling form submission without the action attribute.

I've used the word "inheritance" before, which is the OOP equivalent, but not exactly as the implementation details differ. The words "extend" or "reuse" are a better match and more natural.

I'll try to clarify the rest of the points where our understanding differs fundamentally in a separate thread due to length.

I've also drafted an updated specification with the parts pertaining to form functionality reworded to incorporate the <search> element. You're welcome to opine on the chosen wording and changes. This was considered to be not worth the effort. Indeed, it was tedious work for 2-3 days. Now that it is done, both concerns (implementation and spec change cost) has been addressed and those are no longer blockers to deliberate about form functionality.

Kaleidea commented 2 years ago

Why is it assumed that form functionality is "unviable"? No explanation was given so far.

The opposing comments hinge on the following vague opinions:

twitter: "It makes no sense to propose using \<form role="search"> ..."
github "The form element is quite magical, and duplicating that magic into another element is a huge implementation and spec lift".
github: "a new element "inheriting from form" is not viable"
github: "they will not implement ... as an alias"

Duplication, inheritance and aliasing are 3 fundamentally different concepts, making these arguments lack technical soundness. OTOH viability has been proven by a trivial implementation.

Obviously, there are technical difficulties with both proposals, but the discussion lacks any clear information in that regard.

What were the technical difficulties considered before this proposal? I'm asking implementers if they can give clear explanations. Hats off to those who give detailed, technical answers.

carmacleod commented 2 years ago

Hi, @Kaleidea. I'm the OP. I'm a bit confused about why it is so important to you to make the new element a subclass of form. My original intent was to make it an alias of <div role="search"> (which of course could have zero or more form children), and if the author wants to, there would always be the option to use the ARIA role directly as <form role="search">. I believe this allows for the most flexibility. 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. Also, having a simple div alias gives authors the option to create a search landmark without using a form at all, if they prefer.

Kaleidea commented 2 years ago

Hi, @Kaleidea. I'm the OP. I'm a bit confused about why it is so important to you to make the new element a subclass of form.

Thank you for your questions, Carolyn. I was hoping these would be asked. Also, thank you for starting this proposal, without that I assume there wouldn't be a <search> element in the future.

Briefly: with form functionality included the <search> element will better meet developer expectations, lead to less "surprises", a simpler learning curve and simpler migration process. I've summed up this in the Motivation section.

I'd note that this is important to many developers, but so far I'm the only one who invested more than a week to research the usage patterns, write the implementation and the specification to present a compelling case.

That initial twitter thread reached a very small portion of web developers. Based on the uncountable number of <form role="search"> usage patterns I've found I believe this to be important to as many developers as the <div role=search> usage, if not more, given that MDN teaches the <form role="search"> pattern and this is what common sense suggests: "The search element [...] contains a set of form controls." A set of form controls is a form.

Just a technical note: the proposal is not a subclass in OOP terms. That would be not acceptable for architectural reasons: the HTML*Element classes were declared final to optimize function-calls and gain some 20+% speed up IIRC.

Kaleidea commented 2 years ago

My original intent was to make it an alias of <div role="search"> (which of course could have zero or more form children), and if the author wants to, there would always be the option to use the ARIA role directly as <form role="search">. I believe this allows for the most flexibility.

I've reviewed the most common usage patterns and presented clear and simple migration patterns for each. The critical cases to the question of flexibility are the nesting of <div role=search> and <form>, in any order. Your proposal allows nesting <search><form>, mine prohibits it (as long as form nesting remains invalid).

However, in most cases form is a single descendant of <div role=search>, therefore the two are just extra levels in the DOM (usually for layout reasons), but represent the same content. The question "which one is the landmark?" is accidental complexity with no benefit. Merging the two elements (see migration), or forcing role=search to the form element nullifies this question, simplifying developers' decisions to make, leading to more consistent patterns.

For this reason, I see no practical benefit in the flexibility given by allowing <search> and <form> nesting in the original proposal, but rather an unnecessary question and a source of inconsistency.

Most usage patterns can be simply migrated to the <search> element with included form functionality. The very few cases that I've found to be unsuitable for such migration - some we discussed with Scott - were cases of very questionable designs. By disallowing those, better practices are encouraged.

As you can see quality and forward planning is of great importance to me, that's why I chose to invest this much effort into a better solution.

If the original proposal that allows nesting <form> and <search> is ratified then later nesting cannot be made invalid and the alternative proposal - when developers ask for form functionality en masse - will be many times more complicated as now form nesting has to be dealt with also. I've explored that solution: it comes with loads of corner cases that have no clear resolution. To compare, the current proposal has one single special case for the unset action attribute, no corner cases.

To sum up: For the <search> element the additional flexibility adds no value to the functionality, but increases accidental complexity.

whatwg / html