Events guideline: Single entry for event and onXXX event handler #13595
Conversation
github-actions
bot
added
the
docs
Elchi3
force-pushed
the
events-guideline
branch
from
b3cfd16 to
670a0ad
Compare
docs/data-guidelines.md
Outdated
| @@ -56,13 +56,15 @@ For example, the feature for a `focus` event targeting the `Element` interface w | |||
| } | |||
| ``` | |||
|
|
|||
| This rule applies to the event features themselves, not the features for the event handlers. For example, `focus_event` and `onfocus` are two separate features. | |||
| The event handler `onfocus` is included in the `focus_event` entry. If an implementation doesn't support the event handler property, use `partial_implementation`. | |||
There was a problem hiding this comment.
Can you suggest what the note text should be?
Can you also say what should happen if onfocus is supported but the "focus" event cannot be fired? That can mess with feature detection, but I think we should probably still just not record it in BCD.
docs/data-guidelines.md
Outdated
| @@ -56,13 +56,16 @@ For example, the feature for a `focus` event targeting the `Element` interface w | |||
| } | |||
| ``` | |||
|
|
|||
| This rule applies to the event features themselves, not the features for the event handlers. For example, `focus_event` and `onfocus` are two separate features. | |||
| The event handler `onfocus` is included in the `focus_event` entry. If an implementation doesn't support the event handler property, use `partial_implementation` with the note `"The <code>onfocus</code> event handler property is not supported."`. If an implementation doesn't support the event name, use `partial_implementation` with the note `"The <code>focus</code> event name is not supported."`. | |||
There was a problem hiding this comment.
Two suggestions here, for clarity:
- I think it's worth including an explicit prohibition on creating
onentries (i.e., having an imperative like "Don't create features foronevent handler properties"). Perhaps saying "represented by" instead of "included in" would also help? As written, I think there's a plausible interpretation here thatonhandlers can be subfeatures of the event feature. - "If an implementation doesn't support the event name…" is slightly ambiguous. It could be read as if all events are either fully supported or partially supported and none are false. Perhaps something like "If only the handler is supported…"
There was a problem hiding this comment.
For the "If an implementation doesn't support the event name" case, I think we should treat that as not supported, meaning no "version_added": false. It is possible that on* properties exist and will mislead feature detection, but I don't think the value of trying to capture this correctly justifies the work.
Although I will say that one benefit of representing it is that if tests using the on* properties show earlier support than BCD, then such partial_implementation entries would avoid incorrectly updating BCD to claim earlier support.
There was a problem hiding this comment.
I think I addressed Daniels suggestions.
And I agree with Philip to make it "version_added": false when on* event handler exists but no event name.
Co-authored-by: Philip Jägenstedt <[email protected]>
|
@Elchi3 Hmm, should we do semver minor or major for this? Or would you like to avoid merging any of these until after tomorrow's release, to buy time to think about? |
|
The consequence of this is removals of and changes to existing (non-protected) data points. I guess I would lean towards semver minor if anything. What did we do when we last had a new data guideline or changed an existing one? |
* Bump version to v4.0.13 * Populate intial notes * Add release note (and semver minor) for #13595 * Fix heading levels * Add stats * Reduce clutter
Summary
Update the data guideline on events to require a single BCD entry for an event. (no separate data for onXXX).
Related issues
https://github.com/mdn/content/discussions/9098