- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Wed, 22 Nov 2006 22:43:38 -0500
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.
Received on Wednesday, 22 November 2006 19:43:38 UTC