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:
- "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.
- "What are the use cases?" - I had to collect these
- "list requirements for each use case"
- "Ask fellow web developers about their opinions" - Domenic described web developers' input as "confusion" and as "makes no sense". Incorrect and very disrespectful.
- "Research existing solutions." - Not even the best practice was considered.
- "Come up with new solutions." - The only new solution was immediately rejected without consideration.
- "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.
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 revoked my access to chromestatus.com, preventing me from filing the Intent to prototype and progressing the implementation that I've worked on for months.
By doing so he also prevented the involvement of the chromium developer community, who might have views different from his.
The editor refused to answer the following questions fundamental to his decisions:
- Why inheritance is unviable? (Why duplication is, is obvious.)
- What form functionality is unwanted (explicitly opposed) for the
<search>element withdivsemantics? - What developer feedback led to that decision?
Related, but different:
- 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:
- Have you discussed with the chromium team the proposal with form functionality before rejecting it in November? Link to public records.
- Who discussed it from the chromium team at that time?
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.
The editor based its decisions on the following flawed assumptions and misunderstandings:
- 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.
- 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.
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.