Re: [w3c/uievents] Consider splitting the spec into smaller specifications (Issue #369)

I think the most important goal is to migrate the spec to use properly written algorithms. That will be a significant aid to maintainability because the existing spec text (written mostly as "do something like this") has proven over the past decade or so to be far too vague to support the level of detail that we need. Regardless of where the spec ends up being hosted, this conversion needs to take place.

I wrote up some algorithms as a starting point a few years ago, and recently people have begun augmenting them because it allowed them to specify the details that they wanted. However, I know that the algorithms are inadequate and I also know that we have some browser implementation differences that will be tricky to specify correctly.

These inadequacies are why I've hesitated to propose incorporating the algorithms as they currently are into the main spec. The algorithms look more official than ad-hoc text descriptions, so errors feel more consequential.

Thus, my plan was to split the spec to remove the cruft and choose one event type (perhaps MouseEvents) as a canary to test migrating the algorithms over. That experience would inform how we move over the other events. We can't avoid having some interdependencies (e.g., PointerEvents), but I don't think the problem is unmanageable (referencing a different spec vs. referencing a distant section in the same spec).

If we don't split the spec into parts, then we need to have a plan for how to migrate to algorithms.

What do people think about the following approach:

* Remove sections that don't fit the modern specification structure: "DOM Event Architecture", "Changes", "Glossary"
* Choose one event (like MouseEvent) and update the main spec with the algorithms from the `event-algo.bs` file.
   * Iterate on the algorithms until they're "good enough" and then remove the old text.
* Rinse. Repeat.

Once (if) we have general agreement on the high-level approach, I'll create tracking issues for each task so it can be discussed in more detail. But I'm open to any suggestions.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/369#issuecomment-1933080650
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents/issues/369/1933080650@github.com>