I'd like to raise concerns regarding my experience recently contributing to the ongoing standardization of the search element. I'm facing serious communication difficulties, misunderstandings and disrespectful comments. I'd like to ask for your attention and independent input to steer this discussion towards mutual understanding and an outcome that's inclusive to differing perspectives and practices.
There is a disagreement about the viability of extending the form element. To prove my point I've implemented the form-based search element: 29 lines changed for the key features, proving its viability and low implementation cost.
This input is not welcome, deliberations about it are not reciprocated. We are discussing incompatible concepts (reuse vs. duplication) and despite my attempts to clear up this misunderstanding, my reasoning is not heard and the discussion revels around huge implementation costs that my implementation disproves. My reasoning has no effect and the constant push-back became uncourteous.
In my opinion this misunderstanding prevents the editors to take all aspects into consideration and formalize the <search> element with the best possible semantics.
I'm aware that these reasons might have been discussed in the monthly triage meetings to which I have no access, or between the editors. If that is the case, I appologize for my lack of awareness. However, that can be easily remedied with in-depth technical explanations to the unreasoned conclusions and decisions presented on the issue.
I appreciate the editors' long-term service towards the web developer community and I respect their standardization experience. Their work is very valuable to the great progress the HTML standard makes from year to year that I am and maybe all web developers are very grateful for. I know that the editors have a lot on their plate. I understand they had a solution in mind and their expectation was it will be quick and simple to alias the <div> element, similar to other semantic elements like <main>. Investigating the use-case of aliasing <form> is more than what they allocated time for and this feature is low on priority. However, aliasing <form> is almost as simple as <div> as proven by the implementation.
I do not intend to burden the editors, therefore I've done the investigation and I'm willing to go as far as submitting implementations if implementer interest is lacking. Unfortunately, my reasoning is not considered. I went into great lengths - literally - to explain my point, but my efforts seem to be unwelcome and not reciprocated. Since this is a low priority feature, there's no need to rush, we can take our time to discuss perspectives that were missed. I believe we should aim to support best practices and developer satisfaction.
I believe the presented alternative has significant benefits worth persuing. Ignoring it would be a missed opportunity to improve the quality of the World Wide Web, therefore I'd like to ask the Steering Group's help to revisit the assumptions and decisions of this proposed standard. Please help in reaching a mutual understanding, openness towards novel ideas and a more courteous tone.
Below I'll collect key comments to demonstrate the statements above.
- The
<search>element is proposed as an alias for the<div>element. This decision is unexplained and there's no deliberation about it. - github - There was considerable feedback to make the
<search>element an alias for the<div>element / expose form functionality. This well-reasoned feedback from developers is described as confusion: - github - "However a lot of people expressed confusion [...] about when they would use this versus using
<form role="search">."- This is a misreading of the feedback and discourteous towards those people.
- github - I went to great lengths to advocate the use-case with form functionality.
- github - The implementation details were not discussed. The discussion got stuck on the misplaced concern about "duplication", which is a fundamentally different concept than what I've reasoned.
- The often repeated conclusion "makes this far more complicated than it needs to be" hinges on this conceptual misunderstanding.
- The communication broke down at this point and was shut down: "Further discussion about making
<search>into a near duplicate of<form>is going beyond the scope of what this request was asking".
Starting from the beginning it was not considered how prevalent the <form role=search> use-case is. My mentioning that it is the best practice was not followed up, as if it didn't matter.
- rude rejection: "It makes no sense to propose using when the use case for this proposal is when you don't want a
<form>"- The point was that form functionality is often needed. This message is not heard.
- Form functionality eg. reset, validation is also needed in some cases even if submission is not.
There was no response to the following:
- request: "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."
- concern: "From this perspective, the form use-case seems to be ignored in this issue and unwelcome.
- request: "I'm looking forward to learning about the viability of the secondary alternative "
Rejecting differences in opinion:
- response: "It seems there's some disagreement on this which in and of itself is a bit discouraging."
- Code of conduct: "Respect that people have differences of opinion"
-
response - "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"
-
response - "a new element "inheriting from form" is not viable"
- The answers are short, unreasoned and ignore all other topics brought up. Effective discussion cannot be conducted in this way. This creates an unwelcoming atmosphere.
- Duplication and inheritance are also conflated in this example, making the arguments harder to process.
- The non-technical verbiage does not help to clarify what form functionalities are discussed. I've found that the only form feature of concern is implicit submission.
- With the knowledge that exposing form functionality can be done with a minimal implementation, the arguments don't hold up.
-
response - "so that people can avoid typing the extra few characters of
<search><form>."- The best practice and API ergonomy brings much more benefits than a few saved characters.
- request: "Any solution that combines form functionality and the search role in one element is welcome. It would be really appreciated if that use-case would receive some love."
- rude response: "One more attempt at being crystal clear: we will add zero new elements with any form-like functionality such as action=""."
- "I would also appreciate if you stopped trying to tell us how to run a standardization process."
I have no words.
I have great respect and strong appreciation for the work done in the WHATWG group. Domenic's long-time service is of great value to web development and the relevance of this proposal is just a tiny drop in comparison. Possibly he has no time to allocate to go into technical details or consider the other use-case, I understand his situation. I can only assume if he had the time and interest, this would be a very thoughtful discussion about implementation constraints and possibilities.
This experience is not in line with the WHATWG's values. I assume Domenic has reasons to make these decisions, but those reasons are unknown and contradict my experience. The short and discouraging responses work against resolving the disagreement. It's possible that those have been discussed in WHATWG meetings unavailable to me. In the spirit of openness, Domenic could share and discuss those reasons openly to the benefit of all participants and to resolve the disagreement. By rethinking the reasons either I would learn of previously unknown constraints or he might find that I present a novel approach that is worth considering and could better serve the Web. That's how I imagined the standardization process.
Although this is my first experience communicating with Domenic, by chance about a month ago I've read a similar, technically unproven and unexplained decision on another standardization issue and sometimes impolite comments on twitter. This pattern is one of the reasons to bring this to the attention of the Steering Group. I can imagine he might be overburdened by all the exposure and it would help him to be a bit more acceptive to different ideas. That is difficult, I know from experience. I understand it can be angering to have a random person from the internet question one's work process. Having seen Domenic talk on stage I assume in a different situation he would be more courteous, communicative, and it would be a beneficial experience to interact with him. I believe some support towards this goal from WHATWG members would be helpful. Lastly, I hope we will be able to communicate politely in the future.
Thank you for having read this far and for giving your support for the standardization process.
- Please help seek implementer feedback to evaluate the proposed solution.
- Please steer the standardization process towards an open, inclusive outcome that better serves the Web.
- Please support Domenic in finding a more courteous and reasoned voice when his views disagree with others'.
With appreciation,
Kaleidea