Event references should list bubbles, cancelable, and composed values

[lapcat]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/Element/click_event

What specific section or headline is this issue about?

No response

What information was incorrect, unhelpful, or incomplete?

The event reference documentation did not give the values of the bubbles, cancelable, and composed properties.

What did you expect to see?

The values of the bubbles, cancelable, and composed properties of the event.

Do you have any supporting links, references, or citations?

The old documentation used to give the values of the bubbles and cancelable properties:

https://web.archive.org/web/20220104000330/https://developer.mozilla.org/en-US/docs/Web/API/Element/click_event

Do you have anything more you want to share?

I gave an example of one event, "click", but this issue applies to every event reference.

[hamishwillee]

@queengooborg The tables showing the bubbles, cancellable, etc were removed as part of your PR here: #18226

What was the thinking?

[teoli2003]

Vinyl used the new event template for this. So she is not guilty there.

When we defined the new template, we noticed that most of the time, it was always the same values, so we decided to use prose to mark when an event was bubbling or cancelable.

I would be open to revisiting it (not reverting but finding a 3rd solution), but I would like to understand the use cases better. Note that if it bubbles, it is written.

(Overall, I'm not happy with how the bubbling chain is documented – and this was also the case when we had the table. So maybe both problems should be thought together, as a whole)

[hamishwillee]

@teoli2003 (and @queengooborg) Thanks for letting us know. Can you own this discussion - I'm not back until Friday?

I don't have much to add other than pulling information about of prose is not always easy, and I didn't assume that because there was no comment (in the case I looked at) that it meant the event did not bubble; I assumed we'd dropped the information or omitted it. In other words, having the prose works when you know the pattern.

[teoli2003]

We should launch a discussion on mdn/discussion. I'm a bit under the water now, but I will try to formulate something to launch it. If you don't see any activity from me by Monday, please ping me (nicely).

[hamishwillee]

@teoli2003 OK! Typically when I need to kick people off for more work, I like to yell "work harder, not smarter". I hope this will work on you :-)

[hamishwillee]

@teoli2003 ^^^ When you have a moment.

[T1mL3arn]

After some time googling "does %eventname% ibubbes" and don't understanding why such info is not on MDN I tried to look on webarchive and bingo - the info was finally found. Wanted to create a similar issue and I am not the first one.

@teoli2003

we noticed that most of the time, it was always the same values so we decided to use prose to mark when an event was bubbling or cancelable.

Didn't find the "prose" for change event, for click event, and I guess for many other events it is the same.

Note that if it bubbles, it is written.

At this moment - it isn't. Maybe I am missing something and there are some general info on other pages about it. For now it looks like such info is removed completely.

but I would like to understand the use cases better

The use case was simple - immediately get desired info:

• open event doc
• instantly see summary about bubbling/cancelable/etc

how it is now:

• open event doc
• see no summary about bubbling/cancelable/etc
• Ctrl+F and see nothing again
• go google or webarchive

[wbamberg]

There's more detail on this issue at #31137 (comment).

[hamishwillee]

As per that linked issues

But we're not going around this loop again ... until I run into the next case I have to update.

@teoli2003 I think you're going to have to accept that the current approach does not work.

[wbamberg]

See https://github.com/orgs/mdn/discussions/665 - let's try to get a resolution for this.

[teoli2003]

As per that linked issues

But we're not going around this loop again ... until I run into the next case I have to update.

@teoli2003 I think you're going to have to accept that the current approach does not work.

Sounds good to me. The current approach indeed doesn't work.