Re: Why Binding Scripting in Style Layer Conflates Semantics

Shelby Moore wrote:
> The difference is that with XAML the specialized script code for
> <mapselect> or <select type="map"> only gets invoked if those semantic
> indicators are in the markup.

Well.  I'm sure nothing prevents you attaching the specialized script code for 
just "<select>" except you choose not to do it.  Or is this assumption wrong?  I 
have to admit to not being as familiar with XAML as you seem to be...

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); }


>> The idea of XBL-like things is that given semantic markup like <select
>> type="select-a-country"> (which clearly says what we're selecting),
> 
> But binding at style layer means you can do these things even if
> type="select-a-country" is not present.

Sure, but wouldn't this be true for any technology that has this sort of 
functionality?  It's certainly true for XSLT...

> 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.  The way this functionality is 
presented to the user (via a dropdown, or a set of mutually exclusive radio 
buttons, or something else) is not part of the semantics.

> So using the correct XSLT mechanism

What would that be in this case?  Perhaps I'm not following exactly what your 
XSLT is doing?

>> one
>> can attach different presentations (a dropdown list of countries, an
>> imagemap for which clicking on a country selects it, a set of radio
>> buttons, one radio button per country, etc).
> 
> 
> Yes I am not disagreeing with the benefits of new semantic behaviors.

None of the things in that list are semantic in any way.  They're all pure 
presentation.  The semantics are the same -- "A way to choose one and only one 
country from the given list".

> XSLT gives you transformation styling.

At the cost of modifying your DOM, however...  This is the #1 benefit of the 
XBL-like proposals -- they allow complex presentation without exposing the 
details of that presentation to the DOM.  So from the DOM's point of view, there 
is just a <select type="select-a-country"> and the list of <options>, one per 
country, and the purely presentational details (buttons you can press on to drop 
down dropdowns, images that have areas mapped to particular countrys, individual 
radio buttons in a list of radio buttons, whatever) are not visible.  There is 
no way to accomplish this with XSLT.

>> Note that producing these with server-side XSLT would actually obscure
>> the semantics (those being simply "select a country").
> 
> No.  The semantics of the output would be <select type="select-a-country">.

But if the output is the following HTML (for the "select a country by clicking 
on a map" case):

<map name="foo">
   <area ...>
   ...
</map>
<img src="..." usemap="#foo">

then the semantics _is_ obscured.  The output of the XSLT transformation doesn't 
have any knowledge that there was a <select type="select-a-country"> involved -- 
it just knows that there is an image and an imagemap.

> What would be obscured is the semantic style transformation (from say
> <select> to <select type="select-a-country">)

You mean the addition of the attribute?  I'm rather assuming the attribute is 
placed on the <select> by the author of our semantically rich original markup. 
Are we starting out with different assumptions here?

> Hope you do now?

No, I still do not.

-Boris

Received on Wednesday, 23 November 2005 22:34:48 UTC