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

Re: Why Binding Scripting in Style Layer Conflates Semantics

From: Shelby Moore <shelby@coolpage.com>
Date: Sat, 26 Nov 2005 05:10:07 -0500 (EST)
Message-ID: <2694.>
To: www-style@w3.org

Matthew Raymond wrote:
> ...It sounds like you're saying that the <select>, when bound, is
> receiving "semantics" from the <option> bindings.

If the markup tells the <select> that it is operating on specific data
types, then the <select> knows (has additional semantic information) about
what it is selecting.

Your misunderstanding may be due to that I used the word "bound" meaning
"confined", not past tense of "bind".  Poor word choice on my part
(actually realized after I sent it).

> I would argue that there are no semantics in the binding,

Correct, no additional semantics in the binding for in the _first_ example
I gave.  The semantics are explicit on the contain children of <select>,
but it doesn't diminish the architecture's ability to bind semantic
changes.  I repeat the example for clarity.

<style>select { bind SmartDataSelect.xml }</style>
   <option class='city'>Shanghai</option>
   <option class='country'>China</option>
   <option class='longitude'>119.9843</option>

>    Well, ignoring the obvious pointlessness of having unrelated items
> types in the same <select>,

Not pointless.  A select could display and select from multiple data
types.  For example, a location finder could allow user to select by city,
counry, or zipcode, etc.., all from one <select>.

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

Yup.  Also it could be "enumerated processing".

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

I will try to get you to understand your error, by asking you rhetorical

What information is lost from markup if we remove the class="..."
attributes from my example above?

Look at another way.  If you present unspecified data types as "monsters"
then how did you know they were monsters?  How do you map "China" to a
monster?  How do you map "bgvh4676tvvs" to anything?  P.S. Don't confuse
this will the "mapping" I refer to in my linked post above.

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

Thus semantics of data type are important.

> or if all of the values are recognized
> country names.

Imagine all the A.I. we would need just to detect some semantics from
anonymous content, not to mention the near impossible scenarios.  Hint:
that is why we use tags and tag attributes.

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

Distinguish between rendering and semantic input.  The input knowledge is
that the data types are countries.

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

The user has no knowledge of the binding in code.  The user may also not
view the markup.  The important factor is that things that do view the
markup, e.g. search engines, can know that the data items are countries.

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

Exactly!  You have stated one of the problems with conflating style and
semantics.  Read for more:


>    The Semantic Web is for the exchange of DATA, not implementation.

Yes, for example the knowledge that the data types are countries.

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

I know.  That is the problem.

> Searching the XBL binding does not yield any new
> data, and in fact the binding can be changed, overridden and disabled.

If the XBL interprets the contained information of the affected tag in a
way that implies additional semantics, e.g. that the inputs are countries,
then indeed this is new semantic information.

> The Semantic Web can effectively ignore XBL, just as search engines can
> ignore CSS.

And thus ignore any semantic information the XBL script creates by it's
assumptions about the anonymous content of the tag (e.g. that they are
countries).  In markup, we imply semantics via tag names and attributes
(not anonymous).

> Shelby Moore wrote:
>> 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?

Because the binding is correctly in markup, not incorrectly in CSS.



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

Oh yes, selectors are really cool.  I had stated that already in this
thread.  But they come with massive interoperability problems when used
for semantic layer:


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

Whether it is one or many, they are still subclassed.

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

I mean once we stop conflating semantics and style, how do things that are
style (not semantics) get applied to arbitrary class?  For example, how
does "color" apply to sound class?  What CSS attributes apply to animal
class?  Etc.  Think more broadly than GUI please.  The Semantic Web is at
least trillion times more broad than some GUI widgets.

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

Does "block" apply to bird class?

>> How do we decide which properties are style and which are semantic?
>    You don't. They're all style.

I predicted the "Moz-tribe" would make this error!


"I hear 'Moz-tribe' thinking 'all of them!', then we are back to obscurity
of forexample treating data as 'countries' when the <select...> knows
nothing about data type it selects."

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

For example, that when an XBL script interprets data as countries, that
the Semantic Web will know also.


Kind Regards,
Shelby Moore
Received on Saturday, 26 November 2005 10:10:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:21 UTC