passive is ambiguous

[rik]

When first being introduced to this feature, I assumed that passive events where sort of "read-only" events. Meaning they could not change the DOM. After reading a bit more, I realise it only removes the preventDefault method on events.

Because they only do one thing, I'm suggesting to rename the option : preventable. It defaults to true and you set it to false to get the performance benefits.

[annevk]

We cannot have arguments default to true. That is a bad practice.

[rik]

Why?

[annevk]

Because you have to learn the defaults otherwise.

[rik]

I'm not sure I understand. We do have to learn the defaults regardless of the meaning of the boolean. I have to learn that by default, event listeners can block scrolling.

[annevk]

If they all default to false, as they fortunately mostly do, you know whether you can omit the argument when reading code and such and whether it being specified has an effect. I can't really find a canonical reference for this, but this is the way it is. https://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/thread.html#msg302 has some debate on the subject.

[foolip]

The reason to avoid true as a default that I've found most compelling is that undefined should map to the default, which means that { passive: false } and { passive: undefined } would mean different things even though both are falsy values.

[annevk]

See w3ctag/design-principles#28 about getting this documented.

[RByers]

And pragmatically we've already bike-shedded this name to death over the path many months (eg. #13, #14, #17). Since this is now shipping in Chrome and is being actively adopted by websites, we'd need a strong justification to change the name at this point.

[rik]

Thanks for the boolean defaults pointers, it's very helpful.

[rik]

I don't think it is too late to change the name. One browser does not make a standard. Also, since it's a dictionary, it's easy for websites to add another property.

In previous bike-sheds, did you receive feedback from web authors? I only see regular web standards participants in the conversations you linked.

My preference is disableCancel, like @domenic. This change is beneficial for web authors outside of the performance benefits because it gives them a guarantee that no one (aka another person working on the same website in the future) will accidentally preventDefault that event.

[annevk]

No it doesn't. Another person could set up their own listener. The only guarantee is that the listener is passive, that's it.

[rik]

Yeah sorry, I got my terminology wrong here. But my point still stands.

[annevk]

I don't really see how it does.

[tabatkins]

disableCancel

Another boolean design practice is to always name your booleans with a positive attribute, not a negative one. Negating a negative attribute makes things harder to understand. (Follow the link above to http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html and read the "double negative" section.)

I don't think it is too late to change the name. One browser does not make a standard.

No, but gratuitous changes still shouldn't be taken lightly. It invalidates previous information spread around, and requires additional work by the implementors that have already done some work, and early-adopter authors.

It's not difficult to change names, but it's not trivial either. The new name needs to be a significant improvement (like passive was over the previous names).

Also, since it's a dictionary, it's easy for websites to add another property.

What's not easy is updating anything - as a first approximation, websites are never updated.