Formal complaint: search element standardization

[Kaleidea]

This is a formal complaint to @domenic about editor decisions according to the procedure described in workstream policy appeals, step 1: "raise an issue formally for review by the Editor".

Highlighting that Domenic is expected to answer the questions in section "Accountability".
If you wish to debate the claims made here, please do so in a separate comment, after answering the questions.

The reason

Why is this important?

DX. Developers wish that native HTML-JS solutions would be on par with the ease of use and efficiency provided by frameworks.
In this standardization process developers' requests were ignored and inappropriately described as "confusion".

Why do I disagree with multiple participants?

EDIT: As a seasoned software architect I outrank other participants in the $topic domain of software design. I see the solutions where many others see unmanagable complexity.

No other participant has done the necessary research to prepare this standard. I have spent about 2 months researching and implementing this feature in all 3 main browsers. With that knowledge, as a seasoned software architect, I have much deeper understanding of the implementation details and risks. As a comparison, I estimate other participants spent a few hours (few comments), Scott a few days (specification + examples).

I have found that the claims of the other participants (Domenic and Scott) are technically wrong assumptions that have no evidence. They did not provide evidence for their claims when asked to do so. The request was simply ignored.

I have documented the research and evidence in 15+ page-length comments and a proposal. They have repeatedly rejected and ignored the documentation and evidence that I've presented, for ex.

• Domenic has immediately closed the issue I've filed.
• Scott has repeated in the January triage meeting the first fundamental question ("people who don't want form behavior") that has been answered repeatedly, months ago: 1, 2, 3.

Professional collaboration cannot be conducted in this manner. If other participants would have done the necessary research or just respected the enormous effort I did, they would understand their concerns are non-existent risks.

[Kaleidea]

The issues

Many polite attempts were made to resolve the disagreements with reasoning, most of them were ignored. This complaint abandons that approach to describe the severity of the issues with clarity.

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". Incorrect and very disrespectful.
5. "Research existing solutions." - Not even the best practice was considered.
6. "Come up with new solutions." - The only new solution was immediately rejected without consideration.
7. "Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements." - Domenic left the discussion after the new solution was proposed, his last comment was personal and inappropriate.

Inconsistency with the WHATWG principles: openness, efficiency

I've worked weeks to research this problem domain, compared to the few hours demonstrated by the editor. Instead of appreciating my hard work, he immediately closed, censored and rejected it: "I'll be closing or marking as off-topic any such discussions outside of this issue."

Recently the editor prevented me from contributing 2 months' work to Chromium by revoking access to chromestatus.com, when I asked to file an Intent to prototype. Progress has been stalled since then. By doing so he also prevented the involvement of the chromium developer community, who might have views different from his.

[Kaleidea]

Accountability

The editor refused to answer the following questions fundamental to his decisions:

1. Why inheritance is unviable? (Why duplication is, is obvious.)
2. What form functionality is unwanted (explicitly opposed) for the <search> element with div semantics?
3. What developer feedback led to that decision?

Related, but different:

4. Why do you assume that form functionality is "unviable"?

All these assumptions were proven wrong. The editor is expected to answer these questions and present verifiable (reproducible) evidence to justify his decisions.

Further questions:

5. Have you discussed with the chromium team the proposal with form functionality before rejecting it in November? Link to public records.
6. Who discussed it from the chromium team at that time?

[Kaleidea]

Working mode violation

Working mode:

In case of a conflict among the community of contributors, the editor is expected to go to significant length to resolve disagreements.

The editor made no attempt to resolve the disagreement, instead made a number of attempts to suppress this POV, to prevent me from contributing and getting in contact with chromium developers who might have different thoughts.

Bad decisions

The editor based its decisions on the following flawed assumptions and misunderstandings:

1. comment: "The form element is quite magical, and duplicating that magic into another element is a huge implementation and spec lift"
   • Nobody proposed duplication. Reuse is key to efficient and maintainable software.
2. comment: 'a new element "inheriting from form" is not viable'
   • The rejected solution is trivially implemented without inheritance in all 3 main browsers. Its impact on the ecosystem is similarly trivial.

These claims were repeated multiple times after being disproven, creating counterproductive noise and misleading other participants.

[Kaleidea]

Recommended solution

I offer a mutually beneficial solution to the editor: there are many features in progress that are more relevant, impactful, and important for the editor. This, however, is a simple, low-priority feature that received only a few hours of attention from the editor and none in the last months. The editor's extensive standardization experience creates more value applied to those more important features.

I wrote the specification and implemented the search element in 3 browsers. I've invested more effort into it than all other participants combined. I offer to take on the responsibility of being the editor for this topic, so Domenic can focus on more valuable topics and both our work benefits the HTML standard. This is a very generous offer in the current context.

To address the concerns of other participants about the assumed risks I propose to run the origin trial with form functionality and evaluate the feedback from web developers. In case the risks are proven to be substantial the chosen solution will be without form functionality and I will submit the appropriate implementations.

I'm taking the brunt of the work upon myself to minimize the time investment needed from other participants. I hope this solution is an acceptable middle ground and the attitude towards my work will change for the better.

[bathos]

"Ask fellow web developers about their opinions" - Domenic described web developers' input as #5811 (comment) and as "makes no sense". Incorrect and very disrespectful.

People very literally expressed confusion. That is not a disrespectful description.

Gonna go ahead and say what I don't think folks in the org will be able to: you've worn out all good will and everything about this is ridiculous.

[sideshowbarker]

@Kaleidea I’ve blocked you for two weeks from any interactions with https://github.com/whatwg/ repos, based on assessing that your use of the issue tracker here has reached the point of being in violation of the GitHub Community Guidelines — in particular, https://docs.github.com/en/github/site-policy/github-community-guidelines#disrupting-the-experience-of-other-users “Disrupting the experience of other users”. There are 631 people watching this repo, and they have a reasonable expectation that moderation will be applied when necessary to ensure their time and attention is not negatively affected.