Re: Why Binding Scripting in Style Layer Conflates Semantics

Thanks.  I guess I have no choice but to reply one more time, because
apparently my previous post was somewhat ambiguous.  Below...


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

Boris Zbarsky wrote:
> 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...


You are prevented in XAML.

XAML is an XML schema for declarative instantiation of .Net classes.  Thus
if markup a <select>, then you get <select> class, which is already an
(x)HTML normative standard semantic implementation.  To override that
semantic normative standard, you would create a new class <mapselect>
(perhaps inherit from <select>).  The <select type="country"> syntax
wouldn't do anything, unless the standard select class had support for
that attribute (.Net Property).

I do believe XAML concept is more general than .Net.  It is way to wire up
any code via declarative markup.  I would like to encourage W3C to explore
this concept before MSFT goes off too far on it's own.  I tried to bring
the concept to W3C style group 3 years ago, but I got ridiculed.

Also I am not claiming to be the utmost expert on XAML, especially it not
released to general public yet.  Suggest do your own research as well.


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


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


But for XSLT when we transform for example <select> to <mapselect> or
<select type="country">, then our semantic markup now contains <mapselect>
or <select type="country">.  There is no way to obscure the semantic
change from the markup, as you can with the XBL example.

Well strictly speaking, I guess you could use XSLT to embed some scripting
that accomplishes semantic change after loading, but the onload state
document will have a semantic meaning that is not obscured from it's
markup.  There is nothing we can really do about generalized client-side
scripting, except at least it is orthogonal to style layer, so user can
turn it off if they want.  This "problem" is why I really favor the XAML
(XML) method for new semantics.  It provides a semantic markup alternative
to client-side scripting hell.  XAML is really a "no brainer", and I was
trying to suggest that W3C be the leader 3 years ago.  Oh well.  MSFT beat
us because Shelby was a threat to XBL.  I've learned to respect MSFT
again.  They are doing some important things we need for rich web.


>> 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.  I was not referring to
non-semantic aspect of presentation, i.e. the choice of selection
paradigm, colors, physical orientation, etc..


>> So using the correct XSLT mechanism
>
> What would that be in this case?  Perhaps I'm not following exactly what
> your XSLT is doing?


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

My point being that we can restyle the semantics using XSLT, but the
markup transformation is not obscured.  I consider this to be good for the
semantic web, not bad as you claim about DOM below.


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


The semantic behavior was that the list contains countries.  An
unspecialized <select> does not specify what kind of data it selects. 
Thus we don't know about using a map.



>> XSLT gives you transformation styling.
>
> At the cost of modifying your DOM, however...


As stated above, this is a very important benefit for the semantic (rich)
web.


>  This is the #1 benefit of the  XBL-like proposals --
> they allow complex presentation without exposing the
> details of that presentation to the DOM.


Thats fine when the presentation changes are not semantic assumptions
without semantic markup.  For example, assuming that a markup of
"<select>" is selecting a data type of "country", thus displaying a map.

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

As I said already, we never want to bind scripting in the style layer,
because it has the potential to obscure semantic changes from the markup
layer.

It is a basic design principle of orthogonality.  When we start conflating
layers, we get into big (often unforeseen) complexity problems.



> So from the DOM's point of view, there
> is just a <select type="select-a-country"> and the


Or just a <select>!


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


Sure you can accomplish this we XSLT.  Preferably you tranform to
<mapselect> and bind the scripting using declarative binding such XAML. 
Or worse, you transform to a bunch of client-side scripting hell (which is
what XBL is as well).


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


Nice example of transformation that XSLT could do.  Thanks.

And I don't think the semantics are obscured, if transforming from
unspecialized <select> to <map> you have above.  The semantics are now a
map.  I assume the style (XSLT) coder didn't want to imply "country"
semantics, only "map" semantics.


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


If XSLT was instead used to transform a <select type="select-a-country">
into your <map> above, and if that transformation was done server-side,
then yes the style coder intended to obscure the semantic transformation. 
But that is really irrelevant.  What the coder serves, is what we consume.
 We as the semantic consumer don't care if the coder's server does a
zillion things before it.  By serving us a <map>, the coder is telling us
that his/her semantic intention is <map>.  If server wants a different
internal semantics, that is coder's internal semantics.

Whereas, XBL (binding scripting at style layer) enables the consumer, UA,
coder, etc to obscure semantics architecturally.

It all boils down to the layers.  We have othogonal layers for a reason. 
It is to maintain the concepts that the layers represent.  As soon as we
combine layers, those orthogonal concepts (e.g. semantics, style) cease to
exist.  It is Object Oriented Architecture Design 101.


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


I am just saying that any possible style transformation using XSLT can not
bypass markup in the output.  Whereas, binding scripting in style layer,
can bypass the markup layer.


>
>> Hope you do now?
>
> No, I still do not.


Thanks for illuminating where I was ambiguous.  I really need to make this
my last reply.  Hope others will pick up where I left off, if there are
still issues to be discussed.


-- 

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

Received on Thursday, 24 November 2005 03:25:33 UTC