DOM事件中e.preventDefault()为何设计为函数而非属性？

这个设计是DOM标准制定时经过多方面权衡的结果，不是拍脑袋决定的：

• 首先是为了保证API的可靠性，划清职责边界
  方法的语义是「执行一个明确的动作」，属性的语义是「存一个可读写的状态」。preventDefault()本质是给事件派发系统发信号：本次事件的默认行为我要拦截，别执行了，从来不是让开发者随便改个标记玩的。
  真做成e.preventDefault = true这种可写属性，最大的坑就是状态可以被随便篡改：你写个表单提交校验，刚把属性设成true拦下来做校验，后面哪个第三方脚本、或者冒泡阶段别的回调随手给你改回false，表单直接就绕校验提交了，这种跨逻辑的状态踩踏bug，排查起来能把人逼疯。
  你说的「设回false就能重置状态」看起来灵活，其实完全违背DOM事件流的设计原则：规范里本来就定了，只要事件流里有一个回调明确要求取消默认行为，这个决定就该生效，后面的回调没资格推翻——不然捕获阶段子元素拦了行为，父元素随便给你放开，整个事件逻辑就没有任何可预期性可言。现在标准里其实有对应的状态属性e.defaultPrevented，但特意做成了只读的，就是只让你查有没有被取消，不让你随便改别人的设置。
• 其次是扩展性和兼容性的考量
  W3C制定DOM2事件标准的时候，IE已经在用自己的私有实现e.returnValue = false做同样的事，标准选方法形式，一来和IE的私有API做了区分，二来留足了扩展空间：以后要是想给取消默认行为加新功能，比如传参指定只拦截某类默认行为、只在某个阶段拦截，直接给方法加参数就行，布尔值属性根本做不到这种扩展。
  而且方法形式对排错更友好：你提问里都把preventDefault拼成preventDeafult了，要是用方法，拼错了控制台直接报is not a function，一眼就能看到问题；要是用属性，拼错了只会在event对象上加个没用的新属性，代码静默失效，你找半小时都找不到哪错了。
• 最后是实现层面更高效
  如果用可写属性做，浏览器得专门给这个属性加setter拦截，每次赋值都要触发内部的状态更新，平白多了性能开销。方法是直接挂在事件对象原型上的，调用的时候直接执行内部逻辑就行，实现更简单，跑起来也更快。

要是你真的有「前面的回调拦了默认行为，我后面又想放开」的需求，别想着改状态，正确做法是把你的逻辑放到事件流更早的阶段（比如捕获阶段）做判断，本来事件流就不鼓励后面的回调推翻前面的逻辑，这属于典型的反模式。

内容的提问来源于stack exchange，提问作者LuisAFK