[whatwg] The IMG element, proposing a CAPTION attribute

[Matthew Raymond]

Andrew Fedoniouk wrote:
> From: "Lachlan Hunt" <lachlan.hunt at lachy.id.au>
>> Andrew Fedoniouk wrote:
>>> E.g. the engine allows to define following:
>>> <select id="color-selector">
>>>   <popup>
>>>      <table>
>>>         <tr>
>>>             <td role="option" value="#00FF00">...
>>>             <td role="option" value="#0000FF">...
>>>         </tr>
>>>      </table>
>>>  </popup>
>>> </select>
>>>
>>> to be able to define something like this:
>>> http://www.terrainformatica.com/sciter/screenshots/color-chooser.png
>>> http://www.terrainformatica.com/htmlayout/images/selects3.jpg
>> A better way to implement that without embedding presentational markup in 
>> the HTML would be to use an XBL template, bound to  an ordinary select 
>> element.  You could write all the markup you need to render the colour 
>> chooser or periodic table in the XBL <template>, which is populated by the 
>> values from the <option> elements.  That has the advantage of providing 
>> better fallback in legacy UAs.
> 
> 1) About that "presentational markup" sentence....
> Semanticly speaking color table is a <table> and
> periodic table is a <table> too.
> This is exactly the case for what <table> was designed.
> Think about accessibility and you will get an idea why <table> is better
> in this case.

   They're a list of colors, not a color table. If you wanted a table,
you could just create a <table> with <input type="radio"> elements.
However, this is probably an example of a situation where a color picker
control would be better:

| <input type="color" name="foreground" value="red">

   Both your use of <select> (for its popup behavior on most browsers")
and your use of <table> (to organize the colors into rows and columns)
are presentational, because what you're really doing is building the UI
for a color picker. The user can just as easily select a properly styled
radio button from a table, and with a little scripting it would look
like a color picker and still degrade gracefully on user agents that
don't even support Javascript or CSS, let alone your legacy-intolerant
nested markup.

   (A better approach for using <select> to pick colors may be to allow
the user of CSS table layout within the <select> element. You could
style the <optgroup> elements as table rows and the <option> elements as
table cells. Is there anything in the specs that says user agents can't
already do this?)

> 2) XBL is useless if your engine is not capable to do <popup>s in principle.
> it is simply nothing to bind with for your data.

   Actually, XBL 2.0 (and the original XBL, for that matter) can bind to
anything that CSS can select, so that would be more a lack of support by
the user agent than a shortcoming of XBL.

   However, even if it did fail, the user hasn't lost the ability to use
the <select> control, so the fallback is acceptable.

> 3) Lifecycle of popup element can be complex - XBL is not the best
> thing to deal with this.

   While popups would be a nice addition, they are behavioral and
presentational, not semantic. It would be better to provide proper
styling and scripting mechanisms to deal with this instead of forcing
people to use non-semantic markup. Then those mechanisms could be bound
to proper fallback markup using XBL.

> 4) XBL is "the ability to map elements to script". Just add attribute 
> "prototype"
> or "behavior" to the CSS and you will get almost perfect binding of
> class of DOM elements to the class in script or code in other place.

   I'm not sure what you mean, but XBL 2.0 is already defined as using a
CSS property to bind a behavior to an element. However, instead of
providing a hard-coded behavior, XBL allows an implementation of that
behavior based on existing web standards.