On 8/20/06, Dave Bacher <[EMAIL PROTECTED]> wrote:
Shadow2531 wrote:
> On 8/18/06, Christian Biesinger <[EMAIL PROTECTED]> 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.
<embed src="file.php"> might not do me any good if file.php doesn't
send the right content-type.
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
