Re: Why Binding Scripting in Style Layer Conflates Semantics

Shelby Moore wrote:
> I still didn't cover the entire essense of Mark Birbeck's posts.  I want
> to argue against my own logic to see if it will hold up.
> 
> I believe that Mark Birbeck is also implying that if we subclass markup
> semantics at the contained children, then the styling of the parent markup
> is not semantically bound to the semantics of the parent, but to the
> subclassed semantics of the contained children:

   That makes absolutely no sense whatsoever. It sounds like you're
saying that the <select>, when bound, is receiving "semantics" from the
<option> bindings.

   I would argue that there are no semantics in the binding, save the
semantics of (X)HTML or other semantic languages that might be used in
the binding, and those semantics only apply to the immediate elements
used, not the bound element as a whole. What you are binding to is a
user interface implementation that provides supplemental behavior and
presentation, not semantics.

> <select>
>    <option class='city'>Shanghai</option>
>    <option class='country'>China</option>
>    <option class='longitude'>119.9843</option>
> </select>
> 
> So then why not do from CSS?
> 
> select { bind SmartDataSelect.xml }

   Well, ignoring the obvious pointlessness of having unrelated items
types in the same <select>, there isn't a reason not to, if you have a
binding that can actually do something with the assorted <option> classes.

> The above style layer binding would _hopefully_ bind to code
> (SmartDataSelect.xml), which detects the semantics of the contained
> children when doing the presentation.

   If you mean that the bound code can perform "general processing" on
the |class| values, then yes. Furthermore, if there is no binding, you
have a nice <select> to fall back on.

> But for example if the code (SmartDataSelect.xml), implements (subclassed)
> semantics other than that implied by the semantics of an unspecialized
> <select> coupled with specialized contained children, then we will have
> obscured semantics from the markup layer.  Oh sure, the CSS could be
> parsed to see what semantics we are applying, e.g. SmartDataSelect.xml,

   Setting aside this "semantic" nonsense, you've pretty much stated
that the code/markup/styling is, in fact, not obscured. Rather, it is
simple a little harder to process.

   You have the whole concept of semantic markup backwards, though.
Semantics are what the element mean in a general sense, while the
possible implementations of the element can be infinite so long as they
don't violate the general meaning of the element. For example, a user
agent could present a <select> as a 3D first person shooter, where the
<option> elements are rendered as monsters trying to kill you. Every
time you shoot one of the monsters, another is resurrected, unless it's
a <select multiple>, in which case you can kill or resurrect the
monsters at will.

   Another user agent implementation could be to intelligently display
the <select> as a map of the world if the |class| attributes for all the
<option> elements is "country", or if all of the values are recognized
country names. Now suppose I create a binding that will do the exact
same thing. On our theoretical user agent, the behavior and presentation
of the <select> is identical. Yet we can't say that the user agent
changed the semantics of <select>, because if you do then every user
agent assigns a different semantic value to <select> simply by having
default rendering and behavior for the element.

   Yet, there is no difference from a user perspective between our
theoretical binding and our theoretical implementation of the element.
If the binding altered the semantics, how is this possible? The answer
is simple: It isn't.

   This is made more clear when you consider that the bindings may be
different based on the stylesheet selected. If you have alternate
stylesheets, which one contains the "semantics" you speak of? Does the
meaning of the document then change based on the stylesheet selected?

   Furthermore, I can already edit my user stylesheet to override the
styles of any webpage I view with my browser. Therefore, the CSS
property applied may not even be under the web author's control.

> but this architecture of embedding markup semantics in style would not
> interopt well, specifically with the other description languages of
> Semantic Web (RDF, etc) which are necessary to give ontology to semantics.
>  Not to mention the complexity it adds to both style and markup by
> conflating the two.

   The Semantic Web is for the exchange of DATA, not implementation. The
purpose of XBL is not to give user agents additional information about
the markup, but to add author-defined features on top of those provided
by the user agent. Searching the XBL binding does not yield any new
data, and in fact the binding can be changed, overridden and disabled.
The Semantic Web can effectively ignore XBL, just as search engines can
ignore CSS.

> Whereas, we can accomplish the same effect with XSLT, and avoid the
> problems mentioned in previous paragraph.  The output of an XSLT
> transformation could be:
> 
> <select x:Class="SmartDataSelect">
>    <option class='city'>Shanghai</option>
>    <option class='country'>China</option>
>    <option class='longitude'>119.9843</option>
> </select>
> 
> Thus via XSLT, we get the rich styling via subclassing, without the
> obscuring markup semantics.

   Huh? From what I can gather, "x:Class" is nothing more than a binding
to a class in a "code-behind" file. How is this any different from
binding the same code using XBL?

HTML:
| <select class="SmartDataSelect">...</select>

CSS:
| select.SmartDataSelect { bind: url(SmartDataSelect.xbl); }

   Actually, there's a big difference, but it's not obvious in the
example. With a selector system, we can apply the bindings over a broad
range of markup rather than a single element. If we want to apply a
binding to all elements of a given class, regardless of the kind of
element, we can do this:

| .SmartElement { bind: url(SmartElement.xbl); }

   If we want to bind to all of a given kind of element, we do this:

| select { bind: url(SmartDataSelect.xbl); }

   As you can see, the whole idea of the bindings being "subclassing" is
false. In theory, a binding could be applied to an indefinite set of
elements, not just one.

> So how does CSS style arbitrary subclasses?

   If by that you mean "How does CSS style elements in the shadow
tree?", I believe that's defined in the XBL 2.0 spec:

   http://www.mozilla.org/projects/xbl/xbl2.html

> [Do] CSS properties only apply to normative type and those that inherit
> from them?

   I'm not clear as to what you mean by that.

> How do we decide which properties are style and which are semantic?

   You don't. They're all style.

> That is what I am hoping to see in "Future of CSS in Semantic Web?" thread.

   What is it about presentation and presentation-specific UI and
behaviors that you think is necessary for the proper function of the
Semantic Web?

Received on Saturday, 26 November 2005 07:47:02 UTC