Kaleidea

Inappropriate procedure

The proposal and the discussion did not follow the proper procedure outlined in the new features guideline, yet it was accepted as the de facto solution. The following steps were skipped:

1. "Forget about the particular solution you have in mind!" - The lead editor had a specific solution in mind: "the use case for this proposal is when you don't want a " and aggressively rejected any other solution.
2. "What are the use cases?" - I had to collect these
3. "list requirements for each use case"
4. "Ask fellow web developers about their opinions" - Domenic described web developers' input as "confusion" and as ["makes no sense"]( https://twitter.com/domenic/status/1438229658

Kaleidea

This is a follow-up to a private report I've made to allow the Steering Group to resolve this issue discretely.

Summary

I've spent 2+ weeks on the research, implementation and specification of the search element. The implementation for Chrome is complete, WebKit and Firefox are in progress. However, my work has faced constant suppression by an editor who spent less than a few hours on this topic, but takes actions to undermine my work and prevent me from contributing to the HTML standard and Chromium - two projects in which he has authority.

Objective issues

1. Rude remark: "One more attempt at being crystal clear [...]", "I would also appreciate if you stopped trying to tell us how to run a standardization process."

Kaleidea

This intent message is hand-made, NOT generated by Chrome Platform Status.

Contact emails

kaleidealogy@gmail.com

Explainer

https://kaleidea.github.io/whatwg-search-proposal/

Specification

https://search-element-html-spec.netlify.app/multipage/forms.html#the-search-element

Kaleidea

Links to key thoughts in discussions about custom elements inheriting built-in elements.

Articles:

• https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements
• https://annevankesteren.nl/2015/01/dom-element-constructors
• https://annevankesteren.nl/2015/01/dom-custom-elements
• https://github.com/domenic/element-constructors

Discussion:

• WICG/webcomponents#509: The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension.

Kaleidea

This is a detailed complaint about the code of conduct violating remarks in the <search> element standardization process: previous, last (archive).

Non-technical discussion should be kept to a minimium on the issue tracker. If you wish to respond, please do so here in the comments.

Detailed and polite reasoning preceded this complaint:

• intro
• proposal
• plea
• prior complaint

Kaleidea

HTML <search> element - specification draft and implementation

The <search> element is a new semantic HTML element to mark the ARIA search landmark. It represents the common functionality of searching a website, contents on a webpage or filtering a dataset. <search> is a short form of <form role=search> or <div role=search> depending on whether form submission is enabled by setting the action attribute. The benefit of this element is making the best practice for accessibility simpler, more intuitive and semantically meaningful.

• Test page
• Implementation explanation
• Specification draft:
  • Readable form (generated)
  • Specification changes (source)

Kaleidea

Alternatives

Should the implementation of a hybrid element as defined fall through, an alternative is to define 2 elements (<search> and <searchform>) for the 2 use-cases:

• <search> === <div role=search>
• <searchform action="..."> === <form role=search action="...">

Implementing this is trivial by aliasing HTMLElement -> <search> and HTMLFormElement -> <searchform>. The specification still needs rewording to incorporate <searchform> as a <form>. The only benefit would be that the action attribute's specification is not changed.

Should 2 elements find opposition, the proposal would be to favor the best practice:

Kaleidea

This is the detailed answer to @scottaohara's 3rd response on the <search> element discussion.

Implementation cost

[nesting] is a far easier implementation lift than duplicating all the functionality of the <form> element just so that <search> can be a <form>

The implementation is 26 lines of code. The specification is also similar to the original proposal.

Only adapting the spec's "form elements" wording (mostly in "Links" and "Forms" sections) is tedious, but simple. It's understandable that this was seen as a "huge lift" that Domenic chose to avoid. It took 3 days, but to lift that barrier, I've done that update. With that out

Kaleidea

Implementation details

Implementations:

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

Kaleidea

This is a detailed response to the code of conduct violating remarks in the <search> element standardization process: previous, last (archive).

Non-technical discussion should be kept to a minimium on the issue tracker. If you wish to respond, please do so here in the comments.

Detailed and polite reasoning preceded the problematic comments:

• intro
• proposal
• plea
• prior complaint