Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Add the <search> element#7320

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
domenic merged 2 commits intomainfromsearch-element
Mar 24, 2023
Merged

Add the <search> element#7320

domenic merged 2 commits intomainfromsearch-element
Mar 24, 2023

Conversation

@domenic
Copy link
Member

@domenicdomenic commentedNov 8, 2021•
edited
Loading

Closes#5811.

Mini-explainer

This new element allows authors to express the semantics of "a set of form controls or other content related to performing a search or filtering operation".

This is an especially desired semantic because it is something that an ARIA landmark role exists for (role="search"), but today can only be expressed with ARIA. Adding a dedicated element allows authors to follow thefirst rule of ARIA (~ "don't use ARIA if you can avoid it") and is part of theco-evolution process between ARIA and HTML.

Please seethe pull request preview for web-developer focused details on usage and examples.

Some notable design choices:

  • The name. We were initially a bit concerned that developers would think that this was a type of search input, not a search container. Although we briefly discussed alternative names to combat this like<searcharea>,<searchform>,<searchgroup>,<searchset>, they each had problems, and a quickTwitter poll helped seal the deal that developers would expect and prefer the name<search>. (In addition to other developers chiming in with reasoning on the thread.) See the comments starting atConsider creating an HTML search element #5811 (comment) for more details.

  • Like other "block-level" elements,<search> closes any open<p> tags. This ensures an easy transition path from<div role="search"> to<search> and maintains platform consistency.

  • Like other "block-level" elements, the user-agent stylesheet for<search> makes itdisplay: block andunicode-bidi: isolate.

  • For conformance-checker purposes, the element is categorized as flow content and palpable content, but not sectioning content. (In this respect, it is categorized similarly to<main>, but not like<nav> or<aside>.) We are not sure whether this is ideal, partly because due toSuggest adding a warning about outline algorithm #83 sectioning content is a tricky category. But we believe that the main effect of sectioning content is to encourage authors to add headings inside the sections, which is perhaps not the right default here?

  • This element is a straightforward replacement for<div role="search">, and does not come with any additional functionality (such as having form-submission capabilities). Instead it can be combined with other primitives such as<form>, or JavaScript, etc. You can see extensive discussion of this inConsider creating an HTML search element #5811. The reasons for disfavoring more complex solutions areimplementer-expressed considerations about complexity and compat risk, as well asweb-developer and accessibility community preferences.

Credits

The element description and examples is almost entirely written by@scottaohara, although I made a few edits and rearrangements.

PR merge checklist

(SeeWHATWG Working Mode: Changes for more details.)

/dom.html (diff )
/grouping-content.html (diff )
/index.html (diff )
/indices.html (diff )
/parsing.html (diff )
/rendering.html (diff )
/syntax.html (diff )

Malvoz, KittyGiraudel, scottaohara, lyublueberry, what1s1ove, yurifyodorov, shamilfrontend, sglazov, j9t, okmttdhr, and 4 more reacted with thumbs up emojiKaleidea reacted with thumbs down emojiUnused-Account and Genbuchan reacted with heart emoji
@domenicdomenic added addition/proposalNew features or enhancements do not merge yetPull request must not be merged per rationale in comment impacts documentationUsed by documentation communities, such as MDN, to track changes that impact documentation labelsNov 8, 2021
@KittyGiraudel
Copy link

KittyGiraudel commentedNov 9, 2021•
edited
Loading

Hiiii! ✨ That’s pretty neat—I had no idea this was in the work.

I have a couple questions/comments if that’s okay?

  • Is the use of<search> limited to one per page, or can it be used multiple times? The document doesn’t appear to explicitly clarify this.
  • In the case it can in fact be used several times on a page, how would a given occurrence be differentiated from another for assistive technologies (e.g. landmark listing)?

I guess where I’m coming at is that if it isnot unique per page (unlike<main>), maybe it should be a sectioning element so that it can essentially be labelled? That’s generally what’s recommended for<nav> elements, where we’d encourage authors to label them properly so multiple navigations can be differentiated from one another.

Unless I’m missing something? :)

scottaohara, Gotterbild, and Chudesnov reacted with thumbs up emoji

@scottaohara
Copy link
Collaborator

thanks for the comment,@KittyGiraudel. There is definitely guidance that can be added to flesh that out some more.

to quickly answer your questions though:

  1. this element is different than<main>, as there can be more than one per document - though as with any landmark that exposes a landmark role, they should be used with purpose. Will draft up some guidance for this.
  2. With native HTML alone, thetitle attribute would be used to name the element, as there is no other mechanism available at this time without using ARIA.
KittyGiraudel reacted with thumbs up emoji

@domenic
Copy link
MemberAuthor

I do think the comparison with<nav> is worth digging into though. I guess you can have multiple of each per page, and the question is whether we want to encourage<hN> children inside of them.

IIUC, for both<nav> and<search>, perhttps://w3c.github.io/html-aam/#section-elements-and-grouping-content-elements-not-listed-elsewhere you can only usetitle="" or ARIA. Using a<hN> will not suffice to give an accessible name.

Not sure where that leaves us...

scottaohara and Unused-Account reacted with thumbs up emoji

@scottaohara
Copy link
Collaborator

have some additional content to add. my initial PR got messed up though, so will give it a shot again later.

Copy link

@KaleideaKaleidea left a comment•
edited by domenic
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

(edited by@domenic) Off-topic: see discussion in#5811 (comment)I'd like to thank the editors' work on this proposal and their long-term service towards the web developer community. However, [there is a viable alternative](https://github.com//issues/7323) with improved API ergonomy that better serves developer needs, but wasn't considered.In my opinion ignoring that alternative would be a missed opportunity to improve developer satisfaction and the quality of the World Wide Web.

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, thereforeI have to oppose this proposal in this form at this time. Due to discourtesy and therejection to discuss the alternative of aliasing<form>, I'veappealed the decisions to the Steering Group. I hope their guidance will help achieve an outcome that serves more developers' needs.

@domenicdomenic added the agenda+To be discussed at a triage meeting labelNov 15, 2021
@zcorpan
Copy link
Member

cc @whatwg/html-parser for

Does not close<p> elements, i.e. does not require any parser changes. (Note: this is unlike<main>.) Implementers are generally not excited about parser changes and I don't think auto-closing<p> elements is a big enough win.

Is it OK for new "block" elements to not close<p>?

If it is, maybe we need to reconsider if</p> should be optional, since it will be very confusing to not be able to omit it inside or before<search>.

hober reacted with thumbs up emoji

@artalar
Copy link

It would be nice to havemain property for this element, which indicate to browser that it should be used as a main search for site when user clickctrl(command)+F. It may dramatically improve user search experience for sites with virtual lists.

@Kaleidea
Copy link

Kaleidea commentedNov 25, 2021•
edited
Loading

It would be nice to have main property for this element, which indicate to browser that it should be used as a main search for site when user click ctrl(command)+F. It may dramatically improve user search experience for sites with virtual lists.

@artalar I think that would be a separate proposal to hook and redirect the browser'sCtrlCmd-F search functionality to the marked search element on the page, it's more than what this proposal aims for. CurrentlyCtrlCmd-F search can be hooked with JS.

@Kaleidea
Copy link

cc @whatwg/html-parser for

Does not close<p> elements, i.e. does not require any parser changes. (Note: this is unlike<main>.) Implementers are generally not excited about parser changes and I don't think auto-closing<p> elements is a big enough win.

Is it OK for new "block" elements to not close<p>?

@zcorpan Adding the element requires 2 changes to the WebKit & Blink parsers in the HTMLTreeBuilder class:
commit.

Making it a paragraph closing element requires 2 more trivial changes:
commit.

OTOH if<search> is not closing paragraphs then the trivial transformation from<div role=search> -><search> will break in cases like:
<p> Paragraph ends here. <div role=search> ... </div>
will not be equivalent to:
<p> Paragraph ends here. <search> ... </search>
Such inconsistency can be a difficulty for dev tool developers (eg. automated migration to<search>) and a footgun for web developers.

Note: I don't like the optional</p> either, but changing it would break the web.

@zcorpan
Copy link
Member

OTOH if<search> is not closing paragraphs then the trivial transformation from<div role=search> -><search> will break in cases like:<p> Paragraph ends here. <div role=search> ... </div> will not be equivalent to:<p> Paragraph ends here. <search> ... </search> Such inconsistency can be a difficulty for dev tool developers (eg. automated migration to<search>) and a footgun for web developers.

I agree, and it will be a persistent footgun. I think it's probably better in the long run to change the parser when adding a new block element.

scottaohara reacted with thumbs up emoji

@domenic
Copy link
MemberAuthor

@hsivonen any updates on your thoughts about whether it's OK to have<search> close<p> tags?

@hsivonen
Copy link
Member

If a<search> element is added, making it close<p> is probably the right thing to do. I'm not convinced that adding the<search> element is worthwhile, since it doesn't add expressiveness but mainly addresses a principled concern that all of ARIA should be ported to HTML in non-ARIA form, but I don't know enough about the use cases to argue strongly in favor or agains..

zcorpan reacted with thumbs up emoji

@zcorpan
Copy link
Member

Also rendering tests.

web-platform-tests/wpt#39163

@zcorpan
Copy link
Member

OK I think this is ready now, modulo review of the rendering tests.

@annevkannevk added the do not merge yetPull request must not be merged per rationale in comment labelMar 23, 2023
@annevk
Copy link
Member

I suggest we let@domenic do the honors since it's been well over a year since we started all this and he might well have some other relevant insights.

@domenic
Copy link
MemberAuthor

Thank you all for helping push this over the finish line!! I think it's ready to merge. I'll also file an MDN bug.

j9t reacted with hooray emoji

@domenicdomenic removed the do not merge yetPull request must not be merged per rationale in comment labelMar 24, 2023
@domenicdomenic merged commitc598ff0 intomainMar 24, 2023
@domenicdomenic deleted the search-element branchMarch 24, 2023 01:54
domenic pushed a commit to web-platform-tests/wpt that referenced this pull requestMar 24, 2023
wooorm added a commit to wooorm/commonmark-spec that referenced this pull requestMar 24, 2023
jgm pushed a commit to commonmark/commonmark-spec that referenced this pull requestMar 25, 2023
marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this pull requestMar 28, 2023
cookiecrook pushed a commit to cookiecrook/wpt that referenced this pull requestMar 29, 2023
cookiecrook pushed a commit to cookiecrook/wpt that referenced this pull requestApr 8, 2023
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull requestApr 13, 2023
…ment, a=testonlyAutomatic update from web-platform-testsAdd rendering tests for the <search> elementSeewhatwg/html#7320--wpt-commits: c49cf0a72fd7278b6f6da0fd19ed37a3d9262becwpt-pr: 39163
webkit-commit-queue pushed a commit to annevk/WebKit that referenced this pull requestMay 16, 2023
https://bugs.webkit.org/show_bug.cgi?id=254327rdar://107175819Reviewed by Tim Nguyen.Adds the new HTML search element as specified inwhatwg/html#7320. Given the code changes areminimal there is no preferences guard.It doesn't address the unicode-bidi rendering requirements as they arenot addressed for many elements in WebKit:https://bugs.webkit.org/show_bug.cgi?id=256829This change also syncs most of WPT html/syntax/parsing and addsaccessibility test coverage for the main element.* LayoutTests/accessibility/roles-exposed.html:* LayoutTests/imported/w3c/web-platform-tests/html/rendering/non-replaced-elements/flow-content-0/search-styles-expected.txt: Added.* LayoutTests/imported/w3c/web-platform-tests/html/rendering/non-replaced-elements/flow-content-0/search-styles-iso-8859-8-expected.txt: Added.* LayoutTests/imported/w3c/web-platform-tests/html/rendering/non-replaced-elements/flow-content-0/search-styles-iso-8859-8.html: Added.* LayoutTests/imported/w3c/web-platform-tests/html/rendering/non-replaced-elements/flow-content-0/search-styles.html: Added.* LayoutTests/imported/w3c/web-platform-tests/html/rendering/non-replaced-elements/flow-content-0/w3c-import.log:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/Element.getElementsByTagName-foreign-02.html:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/README:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html-integration-point.html:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_innerHTML_template-expected.txt: Added.* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_innerHTML_template.html: Added.* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_innerHTML_webkit02-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_innerHTML_webkit02.html:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_search-element.html: Added.* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_search-element_run_type=uri-expected.txt: Added.* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_search-element_run_type=write-expected.txt: Added.* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_search-element_run_type=write_single-expected.txt: Added.* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_tables01.html:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_tables01_run_type=uri-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_tables01_run_type=write-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_tables01_run_type=write_single-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_template.html:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_template_run_type=uri-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_template_run_type=write-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_template_run_type=write_single-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_tests20.html:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_tests20_run_type=uri-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_tests20_run_type=write-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_tests20_run_type=write_single-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_webkit01.html:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_webkit01_run_type=uri-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_webkit01_run_type=write-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_webkit01_run_type=write_single-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_webkit02.html:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_webkit02_run_type=uri-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_webkit02_run_type=write-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/html5lib_webkit02_run_type=write_single-expected.txt:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/math-parse03.html:* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/test.js:(test_fragment):(convert_innerHTML):* LayoutTests/imported/w3c/web-platform-tests/html/syntax/parsing/w3c-import.log:* LayoutTests/inspector/css/shadow-scoped-style-expected.txt:* LayoutTests/platform/mac-wk1/accessibility/roles-exposed-expected.txt:* LayoutTests/platform/mac-wk2/accessibility/roles-exposed-expected.txt:* LayoutTests/tests-options.json:* Source/WebCore/accessibility/AccessibilityNodeObject.cpp:(WebCore::AccessibilityNodeObject::determineAccessibilityRoleFromNode const):* Source/WebCore/css/html.css:(address, article, aside, div, footer, header, hgroup, main, nav, search, section):(address, article, aside, div, footer, header, hgroup, main, nav, section): Deleted.* Source/WebCore/html/HTMLTagNames.in:* Source/WebCore/html/parser/HTMLTreeBuilder.cpp:(WebCore::HTMLTreeBuilder::processStartTagForInBody):(WebCore::HTMLTreeBuilder::processEndTagForInBody):Canonical link:https://commits.webkit.org/264110@main
aarongable pushed a commit to chromium/chromium that referenced this pull requestAug 16, 2023
This was added to the HTML spec here:whatwg/html#7320I mostly based on this on the webkit patch:WebKit/WebKit#13887Bug: 1294294Change-Id: Ia34836f7e5172d862a3a1f24f1e5cbcbb10e6a55Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/4767222Reviewed-by: Mason Freed <masonf@chromium.org>Commit-Queue: Joey Arhar <jarhar@chromium.org>Cr-Commit-Position: refs/heads/main@{#1184358}
txgk added a commit to gumbo-parser/gumbo-parser that referenced this pull requestAug 26, 2025
jwidar pushed a commit to jwidar/LatencyZeroGithub that referenced this pull requestSep 16, 2025
…ment, a=testonlyAutomatic update from web-platform-testsAdd rendering tests for the <search> elementSeewhatwg/html#7320--wpt-commits: c49cf0a72fd7278b6f6da0fd19ed37a3d9262becwpt-pr: 39163
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@annevkannevkannevk approved these changes

+1 more reviewer

@KaleideaKaleideaKaleidea requested changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

addition/proposalNew features or enhancementsimpacts documentationUsed by documentation communities, such as MDN, to track changes that impact documentationtopic: parser

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Consider creating an HTML search element

10 participants

@domenic@KittyGiraudel@scottaohara@zcorpan@artalar@Kaleidea@hsivonen@annevk@past
[8]ページ先頭
©2009-2025 Movatter.jp