- From: Gary Kacmarcik <notifications@github.com>
- Date: Mon, 29 Jan 2024 15:06:46 -0800
- To: w3c/uievents <uievents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/uievents/issues/369@github.com>
To make managing the UI Events specification a bit easier, and to facilitate the transition to a more algorithmic format for the spec, we're considering splitting the spec into a set of smaller (and more manageable) specifications. This is also an opportunity to remove sections that should not be present in the spec, usually because they cover topics already (and more properly) defined elsewhere. As such, I've done a "test split" of the spec to give people an idea of how it would look so that we can agree that this is a reasonable path forward. Note that this split was done with a slightly out-of-date version (December 2023) of the spec as a test just to see how it would look. If we agree to move forward with this, then the split will need to be re-done after we pause edits and flush the queue of pending pull requests. As a high-level summary, we're considering splitting the monolithic UI Events spec into: * UI Events (core) * Define the core UIEvent * Composition * Could be merged with Keyboard, but probably best to keep separate. * Focus * Input * Define core "input" event functionality. Discuss with the editing group about possibly merging this with the editing work (which describes a lot of specific input event stuff). But this would occur after the split so that we can ensure the correct hooks are in place. * Keyboard * Mouse * Need to coordinate with PointerEvents spec * Wheel Some of these specs are currently small, but I imagine that they will grow once we start adding proper algorithms to the documents. ## Proposal for each section: * **Abstract** - Needs to be updated to be specific to each spec once they're split. * **Status of this document** - boilerplate * 1 **Introduction** * 1.1 Overview - needs update * 1.2 Conformance - boilerplate * 2 **Stylistic Conventions** - mostly standard, with extra info mostly for key events * 3 **DOM Event Architecture** - delete, except as noted below * 3.1 Event dispatch and DOM event flow - delete, this is defined elsewhere * 3.2 Default actions and cancelable events - delete, "default actions" should be part of the algo * 3.3 Synchronous and asynchronous events - delete, the algo for each event will define this * 3.4 Trusted events - verify that this is defined elsewhere * 3.5 Activation triggers and behavior - delete, covered by the algo for each event * 3.6 Constructing Mouse and Keyboard Events - move into Mouse and Keyboard specs * 4 **Basic Event Interfaces** - first section is defined elsewhere and can be removed * 4.1 List of Event Types - Not needed, but maybe it's useful to have a list of all the events in the split specs? * 5 **Event Types** * 5.1 User Interface Events * Keep UIEvent definition in core UIEvent spec * Should load, unload, abort, error, select be removed? Are they defined elsewhere? * 5.2 Focus Events - move to Focus Events spec * 5.3 Mouse Events - move to Mouse Events spec * 5.4 Wheel Events - move to Wheel Events spec * 5.5 Input Events - move to Input Events spec * 5.6 Keyboard Events - move to Keyboard Events spec * 5.7 Composition Events - move to Composition Events spec * 6 **Keyboard events and key values** - move to Keyboard Events spec * 7 **Legacy Event Initializers** - re-evaluate if any of these can be removed * 7.1 Legacy Event Initializer Interfaces * 7.1.1 Initializers for interface UIEvent - keep in core UIEvent spec * 7.1.2 Initializers for interface MouseEvent - move to Mouse Events spec * 7.1.3 Initializers for interface KeyboardEvent - move to Keyboard Events spec * 7.1.4 Initializers for interface CompositionEvent - move to Composition Events spec * 8 **Legacy Key & Mouse Event Attributes** - re-evaluate if any of these can be removed * 8.1 Legacy UIEvent supplemental interface - keep in core, or delete? * 8.2 Legacy KeyboardEvent supplemental interface - move to Keyboard Event spec, or delete? * 8.3 Legacy key models - move to Keyboard Event spec, or delete? * 9 *Legacy Event Types* * 9.1 Legacy UIEvent events - DOMActivate: move to core UI Event spec, or delete? * 9.2 Legacy FocusEvent events - DOMFocusIn, DOMFocusOut: move to Focus spec, or delete? * 9.3 Legacy KeyboardEvent events - move to Keyboard Event spec as deprecated * 9.4 Legacy MutationEvent events - move to UI core, or delete?: * DOMAttrModified, DOMCharacterDataModified, DOMNodeInserted, DOMNodeInsertedIntoDocument, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMSubtreeModified * 10 **Extending Events** - non-normative, keep in UIEvents core, move somewhere else or remove? * 10.1 Introduction * 10.2 Custom Events * 10.3 Implementation-Specific Extensions * 11 **Security Considerations** - adjust for each new spec * 12 **Changes** - remove this section * 12.1 Changes between DOM Level 2 Events and UI Events * 12.2 Changes between different drafts of UI Events * 13 **Acknowledgements** - dup into each spec? not sure how we would split this up. * 14 **Glossary** - delete. most of these terms are defined properly elsewhere, and if they need to be defined in this spec then they should be defined inline * **Conformance et al** - all boilerplate or auto-generated -- Reply to this email directly or view it on GitHub: https://github.com/w3c/uievents/issues/369 You are receiving this because you are subscribed to this thread. Message ID: <w3c/uievents/issues/369@github.com>
Received on Monday, 29 January 2024 23:06:53 UTC