[whatwg] WhatWG and <embed>

Mon Aug 21 12:42:18 PDT 2006

On 8/20/06, Dave Bacher <davebacher at hotmail.com> wrote:
> 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.

Making embed do as object ( minus the alternate content of course
since embed is an empty element  and noembed isn't the same) would be
a good idea. I think some things with the object element need to be
sorted out as well though.

> 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.

Point taken. If those cases, use extension or other means to determine
the action.

> 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.

True.  The type attribute could be used as a backup in these cases. (
But see my reply to Boris Zbarsky)

> 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.

I like this idea, but I don't deal with netscape 4.8 etc. I suppose
many still do.

> 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.

O.K. Syncing object and embed handling sounds good to me. Currently,
they are not handled exactly the same.

> 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).

This is where I myself would like to invoke strict handling ( via some
attribute ) as I might want things to fail if the proper content-type
is not sent.

I can see something like this:

<embed strict="true" type="audio/x-ms-wax" src="file.php">

where that would fail if file.php isn't sent as audio/x-ms-wax.

To stress again, I know we don't want to break current handling, but
we definitely need to straighten some things out.

Thanks

-- 
burnout426