Re: Why Binding Scripting in Style Layer Conflates Semantics

Shelby Moore wrote:
> Boris Zbarsky wrote:
>> With XBL bound via CSS, you can (and probably should, for the use case 
>> we're discussing) do:
>>
>>    select[type="select-a-country"] { binding: url(map.xml); }
> 
> Yes, but nothing stopping the coder from doing:
> 
>     select { binding: url(map.xml); }

What's the problem with that?  That doesn't alter the semantics of the 
select element in any way whatsoever, and (assuming this is an (X)HTML 
select element) it still semantically represents a form control for the 
user to select 1 or more items (depending on the multiple attribute). 
The presentation of the control, whether it is presented as a drop down 
list, a set of radio buttons, check boxes, a world map or anything else 
you can possibly imagine for the user to interact with, has absolutely 
no affect upon the *semantics* of the element.

If it did, then, would you say this is wrong:

h1 { color: green; }

By your logic, it would be, because the h1 element is not marked up as 
being a *green* heading, in which case we may as well go back to using 
<font> elements.  My point is, again, that a select element presented as 
a drop down list has no semantic difference from the same element 
presented in another way.

>>> Whereas, without binding at style layer, there is no way to change the 
>>> semantic presentation for <select> as it is standardized in the browser.
>> 
>> The presentation of <select> is by definition not semantic.  The semantic 
>> thing is that the user should be able to select from a list of mutually 
>> exclusive (unless the "multiple" attribute is set) options.
> 
> That is what I mean by "semantic presentation".  It is the semantic aspect 
> of the presentation-- that is must do selection.

That's it's functionality, not its presentation.

> XSLT can be used to transformation some markup (e.g. unspecialized 
> <select>) to some other semantics, e.g. <mapselect> or <selecttype 
> type="country>, etc..

But in that case you are actually changing the semantics of the 
document, whereas CSS and XBL does not do that, and as a result...

> We don't want to force search engines to parse CSS and script code just to 
> understand what the semantics are.

...by putting the semantics of the final document into the XSLT, you'd 
be forcing the search engines to do exactly that with the XSLT in order 
to understand the document at all.  Search engines do not have to parse 
CSS and script in order to understand the semantics, as they do not 
alter the semantics at all!

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Thursday, 24 November 2005 09:39:51 UTC