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

Ian,

I am very sorry but you are very wrong.  I have already stated clearly why
you are wrong.  You can twist the argument around ad nausem, and I could
continue ad nausem to refute your "tidbits" arguments which having nothing
to do with central point, but you are just obfuscating the concept of
semantic binding.  You are going to succeed in filibustering this
discussion.  I hope you are happy with that result.


At 12:18 AM 1/3/2003 +0000, Ian Hickson 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.

You keep arguing with special cases which do not address the general point.

Also specification is one form of binding, but it is not the final form.
In fact, that is the whole point of markup interpretation.  It is sort of
like a fractal.  It has infinite final forms.  That is what makes markup so
powerful and flexible.  So we have to be really careful about mixing the
non-semantic binding layers with the semantic ones.

Again I could go into great detail, but you would just find some way to
obfuscate on every little thing, such that you would avoid addressing the
main point.



> And since XBL is not the HTML specification,
>it isn't a semantic binding layer.


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

You are so far off the point, it makes want to just throw my hands in
frustration.

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.  Geez!  I am getting really tired of this nonsense debate.



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



>The XML and HTML parsers are merely processes which convert a byte
>stream to an infoset, which may then be turned into a DOM.


Think about what you wrote.


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

I want to see you write down all possible _semantic_ forms.

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.



>> So thus XSLT spec and parser is a form of semantic binding
>
>The XSLT spec defines the XSLT elements, but nothing else.


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


[...]


>> So thus CSS spec and parser is NOT a form of semantic binding
>
>Indeed, the CSS specification does not give any meanings to elements,
>only their language specification can do that.


That was not what you wrote before:


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



>> Again you never answered my assertion that the bi-directional arrow
>> much be placed between XBL and XHTML ("Semantics") in your ascii art
>> diagram of layers.
>
>No, I didn't, because I didn't think it relevant.


How convenient for you to ignore when you are wrong.  You've done that
every time you've been wrong in this thread.


[...]


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

You going to ignore this when you are finally proven wrong?


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



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


I said before you are moving the semantic parser to the implementation
layer by extracting the date using regular expressions instead of marking
up the date using a new tag.  You have undermined the ability for other
layers to know it is a date.  You can not depend they will all infer the
same as you did.   When you merge layers, then everything gets brittle
_between_ layers.   You lose the ability to swap layers independently.

How many times am I going to have to repeat myself...



>| 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.  Or perhaps I mistaken.  In any case,
one could use XBL to make a new widget call "resizeHandler" which is
semantically marked up and reused in documents.  The point of XBL is to be
able to make new widgets (new tags) using existing XUL widgets (extend them).


>The semantics of the document are not changed, only the behaviour.


Maybe in that case he was not marking up the resize handler widget.  It
doesn't change my overall point that XBL can bind to new tags that have no
specification.


[...]

>Incidentally, where would you fit XSLT in my original no-XBL diagram?
>Or would you make a totally different diagram?


I would have bi-directional line between XSLT and Semantics.  I would also
have a one-way arrow from XSLT to DOM, CSS, etc...



>> 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.  XBL has
dependencies in it's syntax.



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

I will refute and debate this only if we can agree on the other nonsense
you wrote.  This is a whole other detailed debate...



>>> (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.  Not to mention I had personal issues going in the house which
was making it very hard for me to concentrate last night.  My response was
"in process" (which I noted) attempt to advance what you had written.  All
of it was incorrect.  The correct definitions were made today by me
independently of you, because now I see you were just trying to use a
circular definition to trap me.  Very clever but I caught you.


-Shelby Moore

Received on Thursday, 2 January 2003 20:22:32 UTC