[whatwg] The embed element

[Henri Sivonen]

The party line has been that the embed element is badly designed and  
evil and needs to be replaced with the object element.

Yet, for compatibility, tools keep generating embed as a child of  
object and practically-oriented guides suggest it. According to
http://weblogs.macromedia.com/accessibility/archives/2005/08/ 
in_search_of_a.cfm
the default embedding markup emitted by Flash is the most compatible  
across browsers and screen readers and does not require JavaScript.

(Apparently, the Gecko plug-in folks *still* insist on ignoring  
objects with MS-style classids instead of special-casing the common  
ones and mapping them to Netscape-style plug-ins or even using the  
data attribute if present. Opera at least uses the data attribute.
https://bugzilla.mozilla.org/show_bug.cgi?id=106065#c1
https://bugzilla.mozilla.org/show_bug.cgi?id=46569 )

The main arguments against the embed element have been:
  * Not expressible in a DTD. (Non-issue for HTML5.)
  * Not invented at the W3C. (Non-issue for the WHAT WG.)
  * Lacks proper design for fallback content.

I think pleasing validators or conformance checkers at the expense of  
browser compatibility is a bad idea here. Therefore, I suggest that  
the object element have an alternative content model, where the  
possible param elements are followed by one embed element and the  
embed element is optionally followed by one noembed element whose  
content model is what the content model of the object element would  
otherwise be in this context (except for params).

Conforming HTML5 browsers should display the noembed element if the  
embed element immediately before it cannot be displayed.

Whether attributes allowed on embed should be open-ended is a matter  
of taste, I guess, but at least their datatypes and IDness should not  
conflict with common attrs and they should be sufficient for the  
usual suspects (Flash, QuickTime, etc.).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/