Skip to content

Commit

Permalink
[] (0) Resolve the issue markers in the <embed> section.
Browse files Browse the repository at this point in the history 
git-svn-id: http://svn.whatwg.org/webapps@1925 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information
@Hixie
Hixie committed Jul 24, 2008
1 parent 237dd87 commit 6d0c488
Show file tree
Hide file tree
Showing 2 changed files with 55 additions and 59 deletions.
56 changes: 27 additions & 29 deletions index
View file
Expand Up @@ -16422,44 +16422,37 @@ the time Marco had stuck his tongue out...&lt;/p></pre>
disabled). User agents should convey the danger of overriding the sandbox
to the user if an option to do so is provided.

<p>Otherwise, the <code title=attr-embed-src><a href="#src3">src</a></code>
attribute is present, and the element is not in a sandboxed browsing
context:

<p>When the element is created with a <code title=attr-embed-src><a
href="#src3">src</a></code> attribute, and whenever the <code
title=attr-embed-src><a href="#src3">src</a></code> attribute is
subsequently set, user agents are expected to find an appropriate <a
href="#plugin">plugin</a> for the specified resource, based on the <a
href="#type-of" title=concept-embed-type>content's type</a>, and hand that
<a href="#plugin">plugin</a> the content of the resource, fetching it if
necessary. If the <a href="#plugin">plugin</a> supports a scriptable
interface, the <code><a
href="#htmlembedelement">HTMLEmbedElement</a></code> object representing
the element should expose that interfaces.</p>
<!-- Note that this
subsequently set, if the element is not in a sandboxed browsing context,
user agents should fetch the specified resource, find an appropriate <a
href="#plugin">plugin</a> it based on the <a href="#type-of"
title=concept-embed-type>content's type</a>, and hand that <a
href="#plugin">plugin</a> the content of the resource. <!-- Note that this
doesn't happen when the base URL changes. -->
If the <a href="#plugin">plugin</a> supports a scriptable interface, the
<code><a href="#htmlembedelement">HTMLEmbedElement</a></code> object
representing the element should expose that interfaces.

<p>Fetching the resource must <a href="#delays">delay the <code
title=event-load>load</code> event</a>.

<p>The user agent should pass the names and values of all the attributes of
the <code><a href="#embed">embed</a></code> element that have no namespace
to the <a href="#plugin">plugin</a> used.

<p>Any (namespace-less) attribute may be specified on the <code><a
href="#embed">embed</a></code> element, so long as its name is <a
href="#xml-compatible">XML-compatible</a>.

<p>The <code><a href="#embed">embed</a></code> element has no <a
href="#fallback">fallback content</a>. If the user agent can't display the
specified resource, e.g. because the given type is not supported, then the
user agent must use a default plugin for the content. (This default could
be as simple as saying "Unsupported Format", of course.)
<p>The user agent should pass the names and values of all the attributes of
the <code><a href="#embed">embed</a></code> element that have no namespace
to the <a href="#plugin">plugin</a> used.

<p>The <dfn id=type4 title=attr-embed-type><code>type</code></dfn>
attribute, if present, gives the MIME type of the linked resource. The
value must be a valid MIME type, optionally with parameters. <a
value must be a valid MIME type, optionally with parameters. If the
attribute is present, its value must specify the same type as the <a
href="#content-type5" title=Content-Type>explicit Content-Type
metadata</a> of the resource given by the <code title=attr-embed-src><a
href="#src3">src</a></code> attribute. <a
href="#refsRFC2046">[RFC2046]</a>

<p>The <dfn id=type-of title=concept-embed-type>type of the content</dfn>
Expand All @@ -16479,14 +16472,19 @@ the time Marco had stuck his tongue out...&lt;/p></pre>
href="#plugin">plugin</a> for it.
</ol>

<p class=big-issue>Should we instead say that the content-sniffing used for
top-level browsing contexts should apply here?
<p>Whether the resource is fetched successfully or not must be ignored when
determining the resource's type and when handing the resource to the
plugin.

<p class=big-issue>Should we require the type attribute to match the server
information?
<p class=note>This allows servers to return data for plugins even with
error responses (e.g. HTTP 500 Internal Server Error codes can still
contain plugin data).

<p class=big-issue>We should say that 404s, etc, don't affect whether the
resource is used or not. Not sure how to say it here though.
<p>The <code><a href="#embed">embed</a></code> element has no <a
href="#fallback">fallback content</a>. If the user agent can't display the
specified resource, e.g. because the given type is not supported, then the
user agent must use a default plugin for the content. (This default could
be as simple as saying "Unsupported Format", of course.)

<p>The <code><a href="#embed">embed</a></code> element supports <a
href="#dimension0">dimension attributes</a>.
Expand Down
58 changes: 28 additions & 30 deletions source
View file
Expand Up @@ -14074,43 +14074,37 @@ the time Marco had stuck his tongue out...&lt;/p></pre>
overriding the sandbox to the user if an option to do so is
provided.</p>

<p>Otherwise, the <code title="attr-embed-src">src</code> attribute
is present, and the element is not in a sandboxed browsing
context:</p>

<p>When the element is created with a <code
title="attr-embed-src">src</code> attribute, and whenever the <code
title="attr-embed-src">src</code> attribute is subsequently set,
user agents are expected to find an appropriate <span>plugin</span>
for the specified resource, based on the <span
title="attr-embed-src">src</code> attribute is subsequently set, if
the element is not in a sandboxed browsing context, user agents
should fetch the specified resource, find an appropriate
<span>plugin</span> it based on the <span
title="concept-embed-type">content's type</span>, and hand that
<span>plugin</span> the content of the resource, fetching it if
necessary. If the <span>plugin</span> supports a scriptable
interface, the <code>HTMLEmbedElement</code> object representing the
element should expose that interfaces.</p> <!-- Note that this
doesn't happen when the base URL changes. -->
<span>plugin</span> the content of the resource. <!-- Note that this
doesn't happen when the base URL changes. --> If the
<span>plugin</span> supports a scriptable interface, the
<code>HTMLEmbedElement</code> object representing the element should
expose that interfaces.</p>

<p>Fetching the resource must <span>delay the <code
title="event-load">load</code> event</span>.</p>

<p>The user agent should pass the names and values of all the
attributes of the <code>embed</code> element that have no namespace
to the <span>plugin</span> used.</p>

<p>Any (namespace-less) attribute may be specified on the
<code>embed</code> element, so long as its name is
<span>XML-compatible</span>.</p>

<p>The <code>embed</code> element has no <span>fallback
content</span>. If the user agent can't display the specified
resource, e.g. because the given type is not supported, then the
user agent must use a default plugin for the content. (This default
could be as simple as saying "Unsupported Format", of course.)</p>
<p>The user agent should pass the names and values of all the
attributes of the <code>embed</code> element that have no namespace
to the <span>plugin</span> used.</p>

<p>The <dfn title="attr-embed-type"><code>type</code></dfn>
attribute, if present, gives the MIME type of the linked resource.
The value must be a valid MIME type, optionally with parameters. <a
href="#refsRFC2046">[RFC2046]</a></p>
The value must be a valid MIME type, optionally with parameters. If
the attribute is present, its value must specify the same type as
the <span title="Content-Type">explicit Content-Type metadata</span>
of the resource given by the <code title="attr-embed-src">src</code>
attribute. <a href="#refsRFC2046">[RFC2046]</a></p>

<p>The <dfn title="concept-embed-type">type of the content</dfn>
being embedded is defined as follows:</p>
Expand All @@ -14131,15 +14125,19 @@ the time Marco had stuck his tongue out...&lt;/p></pre>

</ol>

<p class="big-issue">Should we instead say that the content-sniffing
used for top-level browsing contexts should apply here?</p>
<p>Whether the resource is fetched successfully or not must be
ignored when determining the resource's type and when handing the
resource to the plugin.</p>

<p class="big-issue">Should we require the type attribute to match
the server information?</p>
<p class="note">This allows servers to return data for plugins even
with error responses (e.g. HTTP 500 Internal Server Error codes can
still contain plugin data).</p>

<p class="big-issue">We should say that 404s, etc, don't affect
whether the resource is used or not. Not sure how to say it here
though.</p>
<p>The <code>embed</code> element has no <span>fallback
content</span>. If the user agent can't display the specified
resource, e.g. because the given type is not supported, then the
user agent must use a default plugin for the content. (This default
could be as simple as saying "Unsupported Format", of course.)</p>

<p>The <code>embed</code> element supports <span>dimension
attributes</span>.</p>
Expand Down

0 comments on commit 6d0c488

Please sign in to comment.