Re: Why Binding Scripting in Style Layer Conflates Semantics

An attempt to summarize my understanding of where we disagree.

Essentially it seems the XBL proponents argue that XBL enables
presentation behavior and nothing more.  I argue the XBL architecture
enables semantic extension.

First, let me support the XBL proponents' position, in that I do
understand the noble goal of XBL, which is to enable swappable behavioral
style.  For example, a <select> could be presented as a 3D "Price is
Right" spin wheel and it would not have made any semantic extension.  The
<option> data would still be of arbitrary (known) type.

But the _architecture_ of XBL enables almost any imagineable replacement
implementation for tag.  Note, this is quite in contrast to CSS, which is
very well-defined in scope of styles it can modify.  For example, in CSS
without XBL, it is quite impossible to change a <select> into a list of
<a> hyperlinks.  But this could easily be done with XBL.  I am not saying
someone should do it, but one of the important roles of a standards
organization is to play devil's advocate to explore the possible (mis)use
of the proposed architecture.  One thing is as sure as "flies to honey" is
that once you release a scripting language on to the world, you will find
it stretched and pushed to it's architectural limits.

So it is when we explore these limits of XBL, that we discover it can
indeed subclass semantics in a manner which is obscured from the XML or
SGML markup layer (the layer at which semantics are structured, expressed,
and interopt).  Then when we explore the ramifications of this, as I
pointed out in previous post, there are major interoperability blackholes.

And for what gain?  We can do behavioral styling with XSLT and avoid the
conflation, so that any semantic transformations do not escape the output
markup layer from XSLT.

The only gain I can see from putting scripting in CSS, is that we leverage
selectors and cascade.  So build a selectors and cascade syntax that
transforms and outputs the transformed markup.  I am not sure we really
need it.  I am sure we don't need the interoperability spagetti we could
get out in the world from releasing generalized scripting behind style
layer.  XAML + XSLT gives us all those cool behavioral mods, while keeping
the semantic power in the right layer.

Now I know the XBL proponents want to think that if a <select> is
implemented by XBL code as a list of <a> hyperlinks, then the semantics
haven't changed because <select> is in the markup, not <a>s.  But if I
accepted that logic, then I can put on Halloween mask and tell everyone I
am Modzilla, and that means it is true.  We don't want to create an
architecture for a "web of deception".

Now others might say I am making a big deal of out of small issue.  They
might argue that XBL can go on doing cool presentation and no one will be
bothered.  That might well be true, especially given I doubt XBL will ever
get any majority marketshare (e.g. Microsoft will probably never release
it widely).  I don't mean that as a put down.  I mean to say that when
something is used by a core group, then we often don't really get QA
feedback on full range of pitfalls.  But I am here to say that as a
standards body, we (you) hold yourselves to a higher standard of
architectural consistency (perfect right Ian?).

I posted mostly to get a feel for how capable this CSS group is to
transistioning to the new web that is coming.  I am trying to decide how
much effort to put on CSS.  CSS is an abberration in architecture.  Even
Tim Berners-Lee says that (see his "50,000ft" architecture web page).  CSS
is a cool, but it doesn't map analgously to other things XML.  CSS gets
it's own special model in any application, and it is not trivial to model
the cascade and selectors.  It gets into everything in the application and
forces complexity to carry forward through everything (even without XBL). 
If you want to pick my brains on that, email me offlist.  So one makes a
decision about it's future and whether to track it fully generalized, or
to make hueristic mappings on import and forget it on output (that is
where I am leaning based on the type of postings I have seen thus far).

I came back here to get closure from 3 years ago.  At this point, I don't
hold out much hope for CSS in future.  I came here with an open mind and I
just don't see the open minds here so far (unless they are lurking).   I
suspect Microsofts new Open Office XML format will sweep the web, or
something like it.  To date, some many years hence, we still can't do
columns in CSS.  We can't do basic things that I was doing with my WordUP
GUI publisher in 1986 on an Atari ST.  At the rate CSS is going and with
key proponents with agendas for tangents such as XBL, I just don't see the
world waiting.

Publishing is a lot more broad than HTML, the web, or even semantic web.


-- 

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

Received on Saturday, 26 November 2005 15:05:52 UTC