[whatwg] The embed element

[Peter Hall]

> the default embedding markup emitted by Flash is the most compatible
> across browsers and screen readers and does not require JavaScript.

Adobe FlexBuilder 2 (beta2) generates html and Javascript, which writes out
both <object> and <embed> dynamically. I'd assume Flash 9 will do the same.

Practically, you need JavaScript to support IE7 without prompting users to
launch each plugin instance. In the case of Flash, at least, it's possible
to get good browser coverage, while avoiding using the <embed> tag
altogether (http://www.alistapart.com/articles/flashsatay/), but I'm unsure
of the value of doing that, compared with the "weirdness" of it.

Peter


On 4/25/06, Henri Sivonen <hsivonen at iki.fi> wrote:
>
> 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/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20060504/cedaac57/attachment.htm>