W3C home > Mailing lists > Public > www-style@w3.org > November 2005

Re: Why Binding Scripting in Style Layer Conflates Semantics

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Wed, 23 Nov 2005 20:41:11 -0800
Message-ID: <006401c5f0b1$4bc8b6d0$3201a8c0@Terra>
To: <shelby@coolpage.com>, "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: <www-style@w3.org>



----- Original Message ----- 
From: "Shelby Moore" <shelby@coolpage.com>
To: "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: <www-style@w3.org>
Sent: Wednesday, November 23, 2005 7:25 PM
Subject: 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
>
>
>


Being almost drown in this semanticly sparkling beverage I would
like though to ask one queston:

(Indeed, XAML is simply a format to describe an object graph
thus as per its design XAML has no semantic meaning in human sense)

What will happen if UA will receive document with
unknown (to UA) classes/elements?

What I shall do if I will get <mapselect> which is
unknown to my engine, as an example?
What is the fallback schema assumed?

I can understand when XAML is used
as a compileable resource definition in Windows applications
when all classes are known and belong to the same assembly,
but seriosly looking on it as a HTML/CSS alternative... Well...

And that physiological style of argumentation... I suppose
it shall tell urbi et orbi about your level of XAML excitement or what?

Andrew Fedoniouk.
http://terrainformatica.com
Received on Thursday, 24 November 2005 04:41:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:41 GMT