Re: Why Binding Scripting in Style Layer Conflates Semantics

Hi Boris,

I think I remember interacting with you in fair-minded/cordial
collaboration in bugzilla.mozilla.org.


Boris Zbarsky wrote:
> OK.  So say I have a <select type="map"> as a result of XSLT.  I'm still
> trying to render a map of countries (from which the user can _select_ a
> country).  Whither from now?


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.

Whereas, binding scripting in style layer, means the script could
semantically modify any tag, even a <select> which has no semantic markup
specialization.  If I remember correctly, Ian used an example in our
debate with an unspecialized markup <a> tag which reinterpreted all
contained text as dates.  In short, there is no enforceable requirement
that scripting bound at style layer can not obscure semantic changes.

Of course, non style-bound client-side scripting could potentially obscure
semantic changes as well, but only through the dynamic DOM and at least it
is orthogonal to style, and so user can turn off scripting independently
of (without turning off) style.


> 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.

Whereas, without binding at style layer, there is no way to change the
semantic presentation for <select> as it is standardized in the browser. 
So using the correct XSLT mechanism forces you to create a binding to the
code at the semantic markup layer, instead of obscured (and conflated) in
the style layer.

Not to mention other issues of complexity, infinite loops, race
conditions, etc.. that don't need to be in the style layer.


> 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.  I
am just saying we need to put the binding to the script in the semantic
markup layer, not in the style layer.  XAML does this semantic binding. 
XSLT gives you transformation styling.

In short, I am trying to enable Tim Berners-Lee's semantic (rich) web, not
give more hooks to obscure it.


> 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">.

What would be obscured is the semantic style transformation (from say
<select> to <select type="select-a-country">), but that is the benefit of
putting the style transformation on the server.  It must have been
desired.


>  Producing these
> with client-side XSLT is possible,


Yes.


> and very similar in spirit to the XBL
> approach as far as I can tell.


No, very different for the reasons stated above.


> So I don't see what the big argument is about, frankly...

Hope you do now?

After Daniel impuned me for making 130 posts the last time I debated this,
I decided I wouldn't go back and forth on this.  So I think I've made my
point now.

I will let you folks hash it out as much as you want.


-- 

Kind Regards,
Shelby Moore
http://coolpage.com

Received on Wednesday, 23 November 2005 18:03:06 UTC