- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Wed, 08 Jun 2005 00:41:32 -0400
J. Graham wrote: > On Tue, 7 Jun 2005, Matthew Raymond wrote: [Snip!] >>| <selectgroup classname="myclass1" multiple="False" /> >>| >>| <table> >>| <tbody> >>| <tr> >>| [...header row...] >>| </tr> >>| <tr class="myclass1"> >>| [...first row of block two data...] >>| </tr> >>| <tr class="myclass1"> >>| [...second row of block two data...] >>| </tr> >>| <tr class="myclass1"> >>| [...third row of block two data...] >>| </tr> >>| </tbody> >>| </table> (Above example left for other readers to reference.) >> This seems like a good way to handle it at first, but there are several >>problems, not the least of which is the fact that you're creating a new >>element that amounts to a semantic styling tag. > > Eh? What's a semantic styling tag? Well, you use the |class| attribute for styling purposes. Therefore, assuming selection is semantic (and I feel it is, since it's already used by <select> and such), then the <selectgroup> element is effectively styling members of a class with new semantics they otherwise wouldn't have. > What I'm saying is that, if we want > things like selection to work declaratively, one possibility is to use an > element to bind certian classes to a behavior. There are, of course, other > possibilities - is a declarative solution even necessary? What could a UA > do with selection (or drag/drop) information if js is turned off? Why would we need Javascript for selection? My examples with <sl> and <switch> didn't use Javascript at all. (Of course, my examples assumed that clicking on a link to a <section> inside <switch> would make that <section> active, which isn't in the spec, as far as I know.) > Could one use a CSS/mozilla-XBL like solution instead (i.e. > .myclass {select:multiple;} ) - maybe not if we consider this to be > 'semantic' - but what does sXBL (or whatever it's called now) do? Selection is clearly not presentational. You might call it behavioral, but it's definitely not presentational, because a selection in a form control can be submitted. Therefore, selection should NEVER be defined in CSS. Also, don't forget that you break the page if you turn of CSS (like you can do in Firefox). >>Another problem is that this >>can cause serious problems if someone forgets to put the class name inside a >>template, thus making all items created by a user unselectable. Or you could >>have situations where simple misspellings make things unselectable. > > Well, er, yes. In the same way that a misspelling in any piece of > javascript can prevent that code working, a misspelling in a class > attribute can prevent the expected style selectors matching an element... > These things are typically solved by testing. Why is this suggestion any > harder to test than any other part of the language? You somewhat have a point, but points of possible failure should always be minimized whenever possible. Compare the following... Original list: | <ul> | <il>Item 1</il> | <il>Item 2</il> | <il>Item 3</il> | </ul> List with <selectgroup>: | <selectgroup classname="myclass1" multiple="false" /> | <ul> | <il class="myclass1">Item 1</il> | <il class="myclass1">Item 2</il> | <il class="myclass1">Item 3</il> | </ul> List with |selection| attribute: | <ul selection="single"> | <il>Item 1</il> | <il>Item 2</il> | <il>Item 3</il> | </ul> Not that with your system you have to add an extra element and a |class| attribute for every item. Note also that the class has virtually no value for styling, since you can use :selected in both cases: | ul > il:selected { /* Selected item styling. */ } While misspelling is a potential source of error in my system, there a small, finite set of attribute values, so unless you hand-code the HTML, your HTML editor will ensure that misspellings are not an issue. By contrast, the |class| attribute can be anything. It makes more sense to have <selectgroup> as an attribute, since you have to declare the group name for every item anyway, and even then you have the same problem: the user has to type in the |selectgroup| for every item.
Received on Tuesday, 7 June 2005 21:41:32 UTC