Re: XBL is (mostly) W3C redundant, and CSS is wrong W3C layer for semantic behavior *markup*

On Thu, 2 Jan 2003, Shelby Moore wrote:
>>>
>>> Semantic Binding = the mechanism of associating (intepretation of)
>>> markup with it's meaning
>>
>> In that case, there is only one semantic binding for HTML elements:
>> the HTML specification.
>
> First, we are not only talking about HTML elements. XBL has the
> ability to bind semantics to new tags. There is no specification for
> those new tags.

And therefore those new tags have no semantics, no meaning.

If I transmit the following XML over the network:

   <nmce xmlns="http://ns.example.com/53si8" />

...and assuming there is no spec for the "http://ns.example.com/53si8"
namespace, which there isn't, then that document is completely meaningless.

No amount of layers of XBL, DOM, CSS, or XSLT can do anything to give
that document meaning, because none of those technologies can change
the document, and none of those technologies represent any sort of
semantic meaning.

(RDF might be able to, theoretically, give a processor enough
knowledge to assign semantics to that document, but RDF is out of
scope of this discussion.)


> Also specification is one form of binding, but it is not the final form.

IMHO, it is the _only_ form, and I see no normative text anywhere that
claims otherwise. The XBL specification does not mention the word
"semantic" anywhere, and the only parts of the XSLT specification that
mention semantics are referring to XSLT semantics and not the
semantics of the elements being transformed.


> I notice how you ignored my previous post where I said the XBL
> semantic binding is via CSS -moz-dev and where I stated that XBL can
> even bind new tags which do not even EXIST in HTML!

I didn't ignore it, I just felt that I had already answered it in
previous points. But, for completeness, you wrote [1]:

| First, XBL has facility for defining and implementing entirely new
| tags and it's bind thru CSS with -moz-dev.

...and my reply is: XBL doesn't "define" anything. XBL can add style,
event handlers, and other script to arbitrary elements, but that
doesn't add semantics, it doesn't define those elements, any more than
CSS adding a border to arbitrary elements is defining those elements.


> The fact that new tags can be created and semantically bound (via
> XSLT or XBL) indicates that HTML is not the only specification of
> markup semantic binding.

XSLT and XBL don't give any new meaning. Where in those specifications
do you see it saying that they do?


>>> So thus HTML spec and parser is a form of semantic binding
>> The HTML spec is, the HTML parser is not.
> 
> You would also be asserting that DOM HTML is equivalent and
> invertible to HTML specification. Of course that would be a
> ridiculously false assertion.

Of course it would be ridiculously false. The HTML DOM is merely a set
of interfaces for scripting a document model representation of a
document. The DOM has nothing to do with semantics, in fact the only
cases where the DOM HTML spec mentions semantics, it specifically
refers to the HTML specification for their definitions.


>> They don't say what an <h1> element is, only the specification can
>> say that.
> 
> So what is a header exactly and in all possible _semantic_ forms???

An <h1> element has only one meaning:

   A heading element briefly describes the topic of the section it
   introduces. [...] There are six levels of headings in HTML with H1
   as the most important [...].

It may have any of an infinite number of different renderings: In a
loud voice, in a big font, bold, with its first line in blue text, in
capital letters, hidden altogether, cropped with the rest of the text
in a tooltip, rotated pi by two radians and printed on the left of the
page, animated such that it tries to follow the mouse cursor, or even
transliterated into Klingon.

In all of those renderings and any others, it is still a heading.


> For example a UA may decide to put the header at top of each "page".
> That is semantic binding thru _inference_ mechanism in the UA, i.e.
> another interpretation of the specification, i.e. another form.

No, that is just another rendering. It is quite likely to have been
based on the semantics ("heading") of the element, but its position
has nothing to do with the semantics -- the _meaning_, as you rightly
said -- of the element.


> Now you are arguing that XSLT can not create new tags and attach
> them to semantics. Nonsense!

The XSLT specification doesn't say that it can create new tags, and it
definitely doesn't say that it can attach any semantics to anything.
Where are you reading that it can?

All an XSLT transform does is create a new document from the semantics
of an existing document. It doesn't change the meaning of the existing
document.


>>> Shelby Moore wrote:
>>> CSS selectors allows one to select elements of markup based on 
>>> attributes which are not related to *semantics*.
>>
>> Ian Hickson responded:
>> As an editor of the W3C Selectors Specification, I assure you,
>> that is most definitely not the intention of CSS selectors. 
>  
> Ian's "assurance" was false.

There are no attributes that are not related to semantics, since
attributes are part of an element's meaning.

For example,

   <a href=""> ... </a>

...is a link source, but:

   <a id=""> ... </a>

...is a link target.

I stand by my statement.


>>Your statement [2]:
>>
>>| The missing link in your diagram is that XBL should have a
>>| bi-drectional line to "MathML, XHTML" ("Semantics"). Per your <A>
>>| date example, XBL has power to modify the meaning of semantic
>>| layer (and cause the content markup in between <a> and </a> to be
>>| ignored). Thus the arrow to "Semantics".
>>
>> My binding [3] doesn't change any semantics. All it does is change
>> the rendering of the contents of an element so that the time (if
>> there is one) is in another time zone.
> 
> WRONG. WRONG. WRONG.
> 
> XBL can bind new tags which do not exist in HTML.

Indeed it can.

But that doesn't change any semantics.

Those new tags are as meaningless after being bound as they are before
being bound. All the binding does is change the rendering of the
element.


>> It doesn't change the underlying document. It reads from and writes to
>> the DOM, which is why there is an arrow from XBL to DOM.
> 
> It binds new tags which do not even have any specification.

Absolutely, just as CSS can style tags [sic] that have no specification.
That doesn't mean those elements suddenly gain some sort of meaning.


>> If CSS had a value "display-times-in-local-time-zone" for the "text-
>> transform" property then my binding could be replaced with:
>>
>>    text-transform: display-times-in-local-time-zone;
>>
>> The binding doesn't change the meaning of the element, which is "link
>> to bookmark".
> 
> You are moving the semantic parser to the implementation layer

There was no "implementation layer" in my diagram, and I have not seen
you draw what you think the diagram should look like, so I really have
no idea what you mean by this.


> by extracting the date using regular expressions instead of marking up
> the date using a new tag.

My document is written in HTML, which has no date-specific element.

Even if it did, all that is happening is that the rendering is changing.

Should I mark up every initial letter of an element's content before I
apply 'text-transform: capitalize'?


> You have undermined the ability for other layers to know it is a date.

The other layers do not need to know, and if they do, then they can use
regular expressions just like the binding.

Should I mark up every verb on the off chance that some layer will care?


> You can not depend they will all infer the same as you did.

It's not critical semantic information, so who cares? The binding is
purely a presentational tweak.


>>| And XBL has the power to bind to new semantics (per Daniel's
>>| resizeHandler example in beginning of thread), thus the arrow from
>>| "Semantics" to XBL.
>>
>> Daniel's example doesn't add any semantics. An <img> element has one
>> semantic: "embedded image". Daniel's example only adds some event
>> handlers and some CSS, hence the lines from XBL to CSS and DOM.
> 
> He defines a new tag resizeHandler.

If that really is the case, then it is not his XBL that is adding the
semantics, it is his specification, or documentation, or e-mail,
wherever he describes the element normatively. A <resizeHandler> element
in his namespace means the same thing _wherever_ you meet it, whether it
be in an aural context, in Mozilla, in IE without any XBL, or whatever.


> The point of XBL is to be able to make new widgets (new tags) using
> existing XUL widgets (extend them).

You already claimed this falsehood once, I corrected you then and I'll
correct you again:

The original purpose of XBL was not to make new widgets out of other
widgets. The original purpose of XBL was to take elements with special
semantics ("checkbox", "button", "listbox", etc) and give them
renderings and behaviour.

In Mozilla, the UA default rendering of these widgets is implemented
using XBL, but that need not be the case: any scripting or programming
language could be used. For example, Mozilla currently implements the
HTML form controls using C++.

It doesn't matter what language is used to specify the event handlers,
the semantics of the elements don't change.

Quoted from:
   http://lists.w3.org/Archives/Public/www-style/2003Jan/0010.html

For what it's worth, I was originally told this by XBL's inventor and
sole editor of the W3C Note, so I am pretty sure I am right about this.


>>> The mechanism of association in XBL is combined with features at the
>>> DOM and CSS layer. Whereas the mechanism of association in XSLT is
>>> orthogonal to the XHTML, DOM, CSS, everything except XML.
>>
>> This is misleading.
>>
>> XSLT requires you to use DOM and CSS just as much as XBL does. XBL
>> does not have any direct dependencies on either DOM or CSS.
> 
> XSLT doesn't even mention DOM and CSS in specification.

CSS2 is one of XSLT's informative references. The DOM is twice mentioned
as a possible input or output format for XSLT.


> XBL has dependencies in it's synta.x

XBL is certainly designed so as to very easily mesh with both the DOM
and CSS, but I am not aware of any dependencies in its syntax.

Could you give us some examples to illustrate your claim?


>> You do not need to update XBL to use newer DOM or CSS features.
>>
>> You could quite easily use another DOM (e.g. the MSIE DOM) or another
>> style language (e.g. JSSS) with XBL.
>>
>> This is also important, because as far as I can tell, this is your
>> second objection to XBL: that it is somehow dependent on DOM and CSS.
> 
> Wrong.  And I disagree.

Which part do you think is wrong and what are you disagreeing about?


>>>> (Not to mention that your statement is an oxymoron -- something's
>>>> essential nature is orthogonal to its various interpretations.)
>>> 
>>> You say about "your" statement. It is "our" statement.
>>
>> I was referring specifically to your statement:
>>
>>   "The essential nature is the _interpretation_ of the tag name."
>>
>> ...which I still maintain is an oxymoron (just look up the words
>> "essential", "nature", and "interpretation" in any English
>> dictionary...).
> 
> We were in the process of writing some definitions, which you wrote
> and asked me to edit. Thus any thing I write will be dependent on any
> thing you wrote.

The statement that I said was an oxymoron was written entirely by you,
and was not a part of the definitions we were coediting.


-- References --
[1] http://lists.w3.org/Archives/Public/www-style/2003Jan/0034.html

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 2 January 2003 23:37:00 UTC