[whatwg] WhatWG and <embed>

[Dave Bacher]

Shadow2531 wrote:
> On 8/18/06, Christian Biesinger <cbiesinger at web.de> wrote:
>> Hi,
>>
>> I got a question about <embed>. Firstly, does WhatWG intend to document
>> that element and how it works?
>>
>> Secondly, if so:
>> Consider an <embed src="testmovie.wmv">. Consider that said system has a
>> plugin installed that can show movies in that format (that is,
>> video/x-ms-wmv). The plugin can also handle "*.wmv" movies.
>>
>> Now, imagine that the server sends a type of text/plain for this file.
>>
>> What should happen?
>
> If text/plain is sent, I expect it to fail unless you have a
> text/plain plug-in installed. Even then though, the video wouldn't
> play because it'd be a text/plain plug-in, not a video plug-in..
> However, if no type at all is sent ( like if you're loading a local
> page that embeds a local wmv file), then I'd say use the extension as
> a backup.
This is inconsistent with how the object tag in HTML 4.01 interprets the
attribute.  In HTML 4.01, the object tag only receives a content type in
three cases:
1.  The content type cannot be determined based on the classid attribute
2.  The content type is not provided by the transport mechanism at all
(note: HTML cannot assume HTTP transport -- it is also transported by
FTP, SMTP, POP3, IMAP, WebDav and other mechanisms -- content type is a
concept not supported by some of these, notably FTP).
3.  The content type provided by the transport mechanism is incorrect

My opinion is since the embed tag is a non-standard precursor to the
HTML 4.01 object tag, that if it is supported at all (and it really
shouldn't be -- object provides the same functionality and is widely
supported now), that it should follow the exact same rules as the HTML
4.01 standard places on the object tag.

First, HTML is transport independent.  If an HTML file is viewed via
FTP, for example, there won't be a content-type at all.  You cannot
assume HTTP + HTML, you have to assume that other newer or older
protocols could be used to provide the HTML content.

Second, many applications and sites are hosted on providers such as
GoDaddy, Earthlink, GeoCities, AngelFire, AT&T Global Services, etc.
where the page author has extremely limited control over the server
configuration, if any control at all.  As a result, the HTML standard
supports HTTP-EQUIV as a meta tag for overriding or flat out providing
information that should be in HTTP headers.  This kludge is because of
these kind of providers.

My argument is this:
1.  The embed tag is redundant with the object element, and the object
element is now widely supported.  New pages should not use embed, they
should use object.

2.  If you want to add the embed element to an HTML 4.01 standard, then
its handling of content type should in every way match the handling of
the content type by the object tag, because there is no reason why it
should apply different (more or less) restrictive rules than a directly
equivalent tag.

3.  It should always be assumed that the web server and its
configuration are outside the page author's control.  HTML standards,
which are not tied to any specific transport mechanism, should be built
around that concept.  There should be no differences in behavior because
of content type, aside from potentially using a XML parser in place of
the HTML parser by default for an XML data type.  Even in that case, the
browser should fall back on the HTML parser if it fails (because the
user isn't the one who made the mistake, and you are penalizing the user
for using an up-level client -- the user will soon learn to install and
stick with a down-level client, so that you don't interfere with their
browsing).