W3C home > Mailing lists > Public > public-html-comments@w3.org > July 2010

[HTML5] Missing content model category for the 'param' element

From: Philippe Verdy <verdy_p@wanadoo.fr>
Date: Sun, 11 Jul 2010 13:34:15 +0200
Message-ID: <AANLkTikXEIvpld_Oq0pJlUozC5Tr6H37EqSwS8sVY7IS@mail.gmail.com>
To: public-html-comments@w3.org
The content model for the 'param' element in HTML5 should be specified
: it was forgotten and I think this is an error:

It is used within an 'object' element, to specify additional metadata
for the parent object that contains it.

But as it is part, of its content, and this content is to be displayed
as an alternative when the object itself cannot be rendered, it will
fall within this content where it should NOT be rendered at all.

As such, it should be listed (just like the 'command' element which
behaves the same way within a 'menu' element) within the list of
elements with category "Metadata content" , at

http://www.w3.org/TR/html5/content-models.html#metadata-content-0

As well as on the diagram at:

http://www.w3.org/TR/html5/content-models.html#kinds-of-content

----

I also suggest, for better accessibility of this documentation page,
that this diagram of content models stops using mouse hovering, and
instead just uses a click to keep the displayed selection on screen,
and to allow clicking on the links displayed on right.

And below the diagram, there should be a notice saying "Click on a set
to display the elements in each category", because I did not even
notice that this diagram was active.

This help notice should just appear on a visual display media, where
the various lists of elements will not be displayed before a user
selection is made with this diagram. For the print media, or if
javascript is not enabled, the right-side column normally used to
display the selection will remain invisible, but instead the full list
 of categories will be displayed/printed below the diagram.

Yes I know that these lists are in fact displayed as 'foreignObject'
elements within an embedded SVG, but they will also not appear at all
when viewing the document with a browser that does not have support
for embedded SVG.

----

Note also that the same embedded SVG displaying the diagram is also
within an 'object' element, but as it just specified its data source
within its 'data=' attribute, and did not even specify its intended
MIME type, there's clearly ABSOLUTELY NO chance that this 'object'
parent will ever be rendered because data sources in an object are not
intended to be rendered as is, if not specifically instructed, as it
may be used to feed the data to be used by the object, but ONLY when
an actual renderer or plugin for that object has been selected (using
'classid=' or 'type=' attributes) and loaded. For various security
reasons, having to download the data source (when there's no specified
classid), in order to determine its MIME type (from HTTP headers or
from magic guesses), is unreliable (even if this is the way that
images are loaded and rendered by 'img' elements (but with
restrictions applied in all browsers for the suitable MIME types).

In other words, almost all browsers will have to display its internal
alternate content, here the embedded 'svg' element, and see what to do
with it, and an external plugin for SVG renderers will not be used,
even if it's available. Then, if embedded SVGs are not supported
natively by the browser itself, it will then display the internal
HTML-compatible contents that are specified here within all the
'foreignObject' elements of the embedded SVG.

This parent 'object' should then really specify type="image/svg" which
is missing in the HTML page, instead of relying on restricted guesses
by browsers on the data source.

---

Finally a note about the logical HTML structure of the content these
'foreignObject' elements in the embedded EVG: they contain a 'div'
elements containing a 'h1' title before a 'ul' list and additional
paragraphs. This is illogical because the actual content is logically
within a 'h5' section, part of its introduction, and before its other
'h6' subsections. The 'h1' elements in those foreign object should
then preferably become a 'dt' (defined term) within a definition list,
with the text below it part of its 'dd' definition.

Also the 'h1' elements, after they have been replaced by 'dt', should
have their text linked to the appropriate 'h6' subsection where it is
described more completely.

Additionally, all these 'foreignObject' elements should be grouped
together in the SVG, and referenced by id using SVG's standard 'use'
element, because the SVG itself contains plain '#text' elements that
will be rendered literally if embedded SVG's are not supported by
browsers. Otherwise, the content of the 'text' elements that should be
rendered in the SVG image will appear intermixed with the HTML block
of their description within 'foreignObject' elements.

By moving these descriptions at end, there will just remain the #text
elements (that should have been positioned and drawn by the SVG
engine), and they will be displayed by a non-SVG compatible browser as
sucessive, space-separated spans of text. Adding another foreignObject
on top of that will present this small list of text spans, before the
definition lists placed at end of the SVG.

For example:

<foreignObject id="content-venn-intro" class="overall" x="250"
y="-150" width="500" height="288">
   <div xmlns="http://www.w3.org/1999/xhtml">
   Venn diagram representing the various content model categories
within ellipses.
   Each ellipse is associated with a description text listing elements
that are categorized in this content model.
   </div>
</foreignObject>
<g class="a" transform="translate(2, -3)">
   <ellipse rx="244" ry="132"><use xlink:href="#venn-flow-content"
transform="translate(-2, 3)" /></ellipse>
   <text>Flow</text>
</g>
<!-- ...code snipped here for brievity... -->
<g class="g" transform="translate(-42, -7)">
   <ellipse rx="68" ry="22.5"><use xlink:href="#venn-embedded-content"
 transform="translate(42, 7)" /></ellipse>
   <text>Embedded</text>
</g>
<define>
   <foreignObject id="venn-flow-content" x="250" y="-150" width="500"
height="288">
      <dl xmlns="http://www.w3.org/1999/xhtml" class="venn-content-description">
         <dt><a href="#flow-content-0">Flow content</a></dt>
         <dd>
            <ul>
            <li><code>a</code></li>
            <li><code>abbr</code></li>
            <!-- ...code snipped here for brievity... -->
            <li><code>wbr</code></li>
            <li><span>Text*</span></li>
            </ul>
            <p>* Under certain circumstances (see prose).</p>
         </dd>
      </dl>
   </foreignObject>
   <!-- ...code snipped here for brievity... -->
   <foreignObject id="venn-embedded-content" x="250" y="-150"
width="500" height="288">
      <dl xmlns="http://www.w3.org/1999/xhtml" class="venn-content-description">
         <dt><a href="#embedded-content-0">Embedded content</a></dt>
         <dd>
            <ul>
            <li><code>audio</code></li>
            <li><code>canvas</code></li>
            <!-- ...code snipped here for brievity... -->
            <li><code>svg</code></li>
            <li><span>video</span></li>
            </ul>
            <p>* Under certain circumstances (see prose).</p>
         </dd>
      </dl>
   </foreignObject>
</define>

Philippe.
Received on Monday, 12 July 2010 10:41:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:04 GMT