Why Binding Scripting in Style Layer Conflates Semantics

I have stated that style and semantics should remain orthogonal:

http://lists.w3.org/Archives/Public/www-style/2005Nov/0095.html

...without explaining how binding scripting in style layer conflates
semantics.

Ian Hickson gave an example of rendering the text within an <a>text</a>
hyperlink tag as a date, and then in later post he suggested the ability
to render a <select> as a map of countries:

http://lists.w3.org/Archives/Public/www-style/2002Dec/0235.html

So when did <a> imply semantics of date or <select> imply semantics of
countries??

Ian I guess didn't realize (or didn't care? or didn't tell truth? or
wasn't consistent?) that his rendering suggestions require making
assumptions about the semantics, which are not implied by the tags being
rendered.

Binding scripting at the style layer totally obscures semantic behavioral
modification from the semantic markup.  This is why it should never be
allowed.

As I said 3 years ago, one possible correct way to do such semantic
behavioral style changes, is to transform the document using XSLT to
transform the semantic markup into semantic markup.  For example,
transform <a> into <adate> or <a type="date>, and <select> into
<mapselect> or <select type="map">.

How XAML relates to this, is that we can create a new script class called
"mapselect" and then it implements the desired behavior.

Why is this important?  Because for example, search engines can know we
have a map of countries, not just a selection.  And so that we don't build
hidden complexity into style layer.  You can imagine style sheet bugs,
such as infinite loops, race conditions, etc..  This is all avoided by
keeping semantic markup in the semantic markup layer.

I hope I understand that Ian and Daniel wanted cool things, such as the
user ability to tweak <select> in customized "skins".  And this could be 
done using XSLT method above.  Granted you don't get the exact same
cascade and selector complexity options.  But these come at a complexity
cost any ways, which is probably not desireable for semantically capable
"styling":

http://lists.w3.org/Archives/Public/www-style/2005Nov/0072.html

Ian argued such transformations wouldn't be persistant in the DOM (for
scripting, etc).  This really isn't relevant if you think about it.  For
example, a <mapselect> will have certain interfaces, some normative 
(standardized, centralized specification), and others customized ones that
follow each instance of mapselect, because mapselect is a scripted class
in XAML.

And folks, this is what I was saying 3 years ago.


With this post, I get to test Ian's "never lie" creed, to see if he
updates his blog post from yesterday to reflect my rebuttal above:

http://ln.hixie.ch/?start=1132620717&count=1

In my opinion, it was underhanded for him to rebutt my latest post by
linking off-list to an old post which I had never replied to specifically.
 I guess using personal blogs for propoganda is not strictly lying or
untruth is it?

And explain his "no inconsistency" creed, in light of the above logic
which proves that "it is semantic binding" (from his linked post above).

http://ian.hixie.ch/bible/policies

"...it is impossible to back someone into a corner if
they do not keep to a single opinion..."

What a nice goal in life to "back someone into a corner".  I regret you
forced me to give you a taste of your own medicine.  It could have been
cordial from the beginning.

Sorry but I guess I really hate most a hipprocrit, especially when they
take the "high ground" attitude while impuning me.  Just put on the
record, sometimes I lie, sometimes I am inconsistent, sometimes I cheat,
always I am human, and I am confortable with trying to do my best.

Hopefully this is my last post on the matter forever.


-- 

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

Received on Wednesday, 23 November 2005 16:33:27 UTC