Fire a load event for network errors in <embed>

Fixes whatwg#4024. Fixes whatwg#1461.

Tests: web-platform-tests/wpt#24518

source

@@ -30757,6 +30757,10 @@ interface <dfn>HTMLEmbedElement</dfn> : <span>HTMLElement</span> {
        <span>the <code>embed</code> element setup steps</span> for <var>element</var>, then
        return.</p></li>
 
+       <li><p>If <var>response</var> is a <span>network error</span>, then <span
+       data-x="concept-event-fire">fire an event</span> named <code
+       data-x="event-load">load</code> at <var>element</var>, and return.</p></li>
+
        <li><p>Let <var>type</var> be the result of determining the <span
        data-x="concept-embed-type">type of content</span> given <var>element</var> and
        <var>response</var>.</p></li>
@@ -30862,10 +30866,9 @@ interface <dfn>HTMLEmbedElement</dfn> : <span>HTMLElement</span> {
   </ol>
   <!-- This algorithm is a monument to bad design. Go legacy! -->
 
-  <p class="note">It is intentional that the above algorithm allows <var>response</var> to be a
-  <span>network error</span> or to have a non-<span>ok status</span>. This allows servers to return
-  data for plugins even with error responses (e.g., HTTP 500 Internal Server Error codes can still
-  contain plugin data).</p>
+  <p class="note">It is intentional that the above algorithm allows <var>response</var> to have a
+  non-<span>ok status</span>. This allows servers to return data for plugins even with error
+  responses (e.g., HTTP 500 Internal Server Error codes can still contain plugin data).</p>
 
   <p>To <dfn>display a plugin</dfn> for an <code>embed</code> element <var>element</var>, given a
   string <var>type</var> and optionally  a <span data-x="concept-response">response</span>