Throughout this specification method arguments are marked as non-nullable (consistently in both the parameter table and the IDL-fragments), but the 'null' value is still assumed handled in the algorithm steps.

Example:

interface MediaSource : EventTarget {
    ...
    SourceBuffer   addSourceBuffer (DOMString type);
    void           removeSourceBuffer (SourceBuffer sourceBuffer);
    ...
};

"addSourceBuffer
...
When this method is invoked, the user agent must run the following steps:

1. If type is null or an empty string then throw an INVALID_ACCESS_ERR exception and abort these steps.
...
removeSourceBuffer
...
When this method is invoked, the user agent must run the following steps:

1. If sourceBuffer is null then throw an INVALID_ACCESS_ERR exception and abort these steps."

In both of these cases the algorithmic steps assumes null is a valid value and handles it.
However, assuming WebIDL semantics [1], these methods would never be invoked with null as the value. In the case of addSourceBuffer(null), null would be converted to the string 'null' [2], and for removeSourceBuffer(null) a TypeError exception would be thrown because the null value cannot be converted to an object of interface type "SourceBuffer" [3].

Similar issues exists for other methods in the specification.

[1] The spec does not reference WebIDL AFAICS, but seems to follow notational and other conventions from it.
[2] http://heycam.github.io/webidl/#es-DOMString
[3] http://heycam.github.io/webidl/#es-interface