- From: Shelby Moore <shelby@coolpage.com>
- Date: Wed, 01 Jan 2003 03:02:12 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-style@w3.org
At 05:16 AM 1/1/2003 +0000, Ian Hickson wrote:
[...]
This will be my last attempt to explain it to you...
>> Fundamentally, CSS is the wrong layer to take something that is
>> *semantically* defined (i.e. markup) and map it to implementation
>> which is not *semantically* related.
>
>I completely disagree.
>
>CSS is _exactly_ the right layer.
I totally disagree.
Let me try to deduce and explain what YOUR missunderstanding is:
1. If you read carefully what I wrote, I also implied that CSS is the
_correct_ layer to map markup to implementation which is not *semantically*
related
2. I also implied that mapping semantic markup to implementation is a
_correct_ activity
I did not exclude the above two things. I think your logic did not realize
that.
3. What wrote is that CSS is _not_ correct place to remap semantics which
have been selected non-semantically using CSS selectors. In other words,
if you bind <A> tag (a semantic binding), then you want all <A> tags to
inherit that same semantic swap (or addition/extension). You don't want to
use CSS selectors to change some <A> semantics but not all. If you want to
have optional implemention passed down from semantic layer, then use
attributes on the <A> tag, which is somethign XSLT can do without involving
CSS unnecessarily.
If you add functionality which is semantic in nature to some <A> tags and
not others, then you will have made some <A> tags mean one thing, and other
<A> tags mean something else. For example, embedding class selectors in
markup (a feature of CSS) as a way to switch ___semantic___ extensions is
ludicrous. It so violates the separation between semantic markup and
implementation.
I realize you will respond and try to shift the debate. You will try to
make the point that implementaton extensions are not semantic. That is not
the point. Let me try to explain it to you again. CSS is just supposed to
be hints on implementation. The purpose of XBL is to provide entire
semantic implementation. For example, changing the font on a paragraph,
does not change the semantics of a parapgraph <P> tag. However, making new
widgets from existing XUL widgets (the main original purpose of XBL) is
indeed declaring entirely new semantics. I am sure you will find some way
to shift the debate away from orthogonal questions of semantic binding.
But nevertheless it will just mean you don't understand.
You keep missing the fundamental point, which is that XBL provides a way to
attach new implementation to semantic markup. You in fact argue that
ability to change or add implementation is the important function of XBL.
That is semantic binding. That in itself is okay. But XBL _also_ provides
a way to select which elements are mapped, using CSS selection, which is
non-semantically selected.
You fundamentally do not understand that once you flatten the semantic
abstraction into the implementation abstraction, then all sorts of bad
things happen. I realize you don't understand this, and thus you will
continue to argue about things that have no relevance to the fundamental
problem that I raised in this thread. So it is pointless for me to
continue to debate you on tidbit points which have no relevance to this
fundamental questions of orthogonality and redundance (of compelling use).
I refuse to go off on more tangents which have nothing to do with the
fundamental problem.
>> CSS selectors allows one to select elements of markup based on
>> attributes which are not related to *semantics*.
>
>As an editor of the W3C Selectors Specification, I assure you, that is
>most definitely not the intention of CSS selectors.
Of course it is.
CSS selectors would allow me to change the font on any element of the page,
and group those elements in ways that have nothing to do with their semantics.
You don't understand that CSS is supposed to be hints *ONLY*??? It is not
implementations strongly typed to semantics. CSS selectors precisely allow
you avoid semantic considerations. I can apply a font globally to whole
page if I want.
XBL is getting closer to implementations that are to be relied upon,
complete semantic layers such as new widgets by extending existing XUL
widgets. This is totally different level of semantic involvement than CSS
hints.
Any way, it is not my problem what you do in CSS3. XSLT does what we need
and it is a standard. I know you disagree and I think you are very wrong.
>Furthermore, XPath (of XSLT) allows you to select every element that
>CSS allows you to select, so I am not sure what your point is.
I agreed XSLT has power to do bad design, but it not sitting at same layer
as DOM CSS and DOM XHTML.
I know you think that ability to be closer to DOM extensions is a good
feature. I understand that it creates orthogonality nightmares.
We disagree.
And XSLT runs today everywhere. See my previous posts for proof. If yuo
can't find it, then it means you haven't read carefully again.
>> Whereas XBL binds (replaces) the implementation of semantic markup.
>
>Binding and replacing are most defintely not the same thing. This may
>be where you are getting confused.
Play with the english language, it is not an exact science. Nevertheless
your statement has nothing to do with my points.
>XBL does not replace _anything_. It _only_ augments. It _adds_
>anonymous content, without affecting the actual DOM, it _adds_ event
>handlers, without removing existing ones, it _adds_ style, without
>removing exsting style rules, it _adds_ to an element's interface,
>without removing existing ones.
>
>It does not _replace_ anything.
Of for sure it can replace. It can augment. So can XSLT do both.
>> What XBL does is provide both the power for semantic implementation
>> and also the ability to select non-semantically related sets of
>> elements.
>
>I have no idea what "semantic implementation" is, but the ability to
>"select non-semantically related sets of elements" is more a
>description of XPath (and thus XSLT) than it is XBL (or CSS).
CSS DOM layer (and other layers that XBL merges) are not the same layer as
XHTML which is the layer that XSLT binds at. If you don't understand that
basic point and it ramifications, then it is hopeless to discuss it with you.
>> The key difference is that I propose that CSS selectors for XEvents
>> be a separate layer from the *SEMANTIC* binding. Do not skip this
>> point. It is crucial.
>
>What "semantic binding". XBL isn't about "semantic binding". I do not
>understand why you think XBL is anything to do with "semantic
>binding".
I explained it above.
>XBL allows you to augment an element in the DOM with further event
>handlers, styles, and decorative elements in the DOM, but it does not
>"map" anything to anything any more than CSS "maps" an element to a
>presentation.
>
>XBL does not _remove_ any of the semantics from the original document.
Sure it can. Any way, so what?
That has nothing to do with the orthogonal design issues.
>> It is mapping the entire semantic implementation. That is what I
>> mean by *SEMANTIC* binding.
>
>I don't understand what "mapping the entire semantic implementation"
>means either. :-(
Significant semantic implementation changes/extensions to the point that
the document no longer means the same thing.
If you create a new widget in XBL such as Daniel Glazman's resizeHandler
example in this thread, then you have indeed done semantic binding. No one
in their right mind could argue that is not the case.
There is no such thing in XUL or HTML for resize handles. That was
entirely new semantic abstraction. Just think about which layer you should
be doing semantic abstractions. DOM - CSS or XHTML? XHTML sits on top of
DOM - XHTML. (I noticed you ignored that debate (XSLT is related to DOM)
in this response without kindly acknowledging your mistake.)
>> Your date and time was an excellent example of this failure, because
>> you were able to remap a single <A> to mean date
>
>I do not change the semantics of the element.
Oh really?
> The semantics of the
>element are "bookmark link" (now known as a "permalink"). All I do is
>use CSS to change the rendering of the element.
Er, how did you know the date was supposed go there and not a horse?
BTW, I am only using "Er" because it annoys the hell out of me when you do
that to me and others, so I figured I let you know what it feels like.
>In CSS1, you can, for example, to this:
>
> h1 { text-transform: lowercase; }
>
>This changes the rendering of all <h1> elements, so that for instance:
>
> <h1>W3C</h1>
>
>...is rendered as:
>
> w3c
>
>It doesn't change the _semantics_ of anything, it only changes the
>rendering.
Correct. That is totally different than reinterpreting the contents of
link to be a linked date. One is semantics and the other is presentation.
>> You changed the semantic meaning of one <A> tag and not the rest of
>> them in the document.
>
>Not that it matters, but the binding is applied to all elements with a
>rel attribute of value "bookmark".
Okay I must agree and admit that point was not really relevant to the issue
of semantic binding.
My point was corrrect design would be making a new semantic tag instead of
changing semantics of <A>. Again see the point above, "Correct. That is
totally different than reinterpreting the contents of link to be a linked
date. One is semantics and the other is presentation."
>> Until you grasp and agree with the importance of keeping the
>> semantic binding layer orthogonal
>
>I don't think there _is_ a semantic binding layer, as noted in my
>diagram above. (And if there is, XBL is not in it.)
Any one can make diagrams to show any FUD.
The point is "Correct. That is totally different than reinterpreting the
contents of link to be a linked date. One is semantics and the other is
presentation."
>>> the document should not lose meaning when stylesheets are disabled.
>>> This means that it should not change the DOM of the document, as
>>> seen by other documents.
>>
>> You are trying solve the problem of semantic standards
>
>No, I have absolutely no intention of touching the problem of semantic
>standards.
Thank GOD!! Then why are you fooling with XBL?
Again I repeat "Correct. That is totally different than reinterpreting the
contents of link to be a linked date. One is semantics and the other is
presentation."
> This is why I am a member of the CSS working group, and not
>a member of the HTML, MathML, or RDF working groups.
You are sliding on a slippery slope if you contine pushing XBL at the CSS
layer.
>>> It is not a "semantic binding" language.
>>
>> False. It is ALSO semantic binding
>
>XBL was never designed, and is not positioned as, and is not intended
>to be useful as, and is not specified as, and is not supposed to be, a
>semantic binding language.
Again I repeat, "Correct. That is totally different than reinterpreting
the contents of link to be a linked date. One is semantics and the other
is presentation."
>Why do you think it is a semantic binding language?
Again I repeat, "Correct. That is totally different than reinterpreting
the contents of link to be a linked date. One is semantics and the other
is presentation."
Also see my mention above about new widgets such as the resizeHandler
example from Daniel Glazman (the co-editor of XBL spec).
>> Also I sort of disagree with your statement that is doesn't depend
>> on DOM and CSS. I think it is highly integrated with those. The
>> "black box" separation is not there.
>
>There is no more dependence between XBL, DOM, and CSS, as there is
>between XSLT, DOM, and CSS.
Are you really serious??
Do you not understand that XSLT has nothing to with DOM??
>>> One of XBL's other strengths is that it can be introduced at the
>>> user stylesheet level, where it affects every document the user
>>> reads.
>>
>> XSLT can also be swappable if UAs chose to.
>
>I didn't say swappable. I said introduced at the user stylesheet level.
Same conceptual paradigm at a more appropriate layer.
[...]
>That is, the same document can simultaneously be bound to bindings
>from different sources: author, and user.
Sure the author, user, UA, etc could substitute new XSLT transformations.
In fact, the bigger win of using XSLT is that the CSS substitution can be
orthogonal, as it should be. I realize "orthogonal" isn't in your design
vocabulary, so I do not expect for you to entire visualize the
ramifications of that advantage.
>> You deleted my main point. You were saying that my <select> example
>> did not implement swappable behavior. You said it changed the
>> semantics. And I responded that radio buttons are another way to
>> implement selection from lists. My simple example was canonical.
>
>But that example is irrelevant, because it doesn't address XBL's
>problem space, namely the styling and behaviour aspects of a form
>control.
I proposed to come back and provide more complex examples with user scripting.
And you were the one arguing that UA C++ code is also a form of scripting.
>I couldn't care less about converting a <select> into an <input
>type="radio">; in the real world, people would just use the form
>control they wanted in the first place.
The <select> form of markup is more elegant than radiobutton form. It is a
5 line example that is pretty darn eye popping if you consider it conceptually.
I agree I can do more impressive things with more than 5 lines.
> The problem is how do you then
>take the semantics of <select>, or <input type="radio">, or whatever,
>and _render_ them in a way that the user can interact with them.
You mean using user scripting and events etc. I promised to come here and
show that. Precisely what I want to do with XSLT is create a library of
reuseable widgets for writing cross platform applications. And unlike XBL,
it will run every where in 2003. And it will be orthogonal to adapt to new
technologies rapidly and incrementally.
By the end of 2003, I hope to have a collection that pretty much wipes out
the need for XBL.
>>> [snip an explanation of why changing JavaScript objects is not a
>>> solution when the question is how to extend a DOM interface]
Your summary is slanderous and *****FALSE******. If you are going to
delete something, then just put [...]. Don't try to win the debate by
writing fiction, else I will hold you in contempt!!!!
Let the reader go back and make their own interpretation of what was
written. You know better than that Ian.
>> That is a problem of JavaScript.
>
>No, it really isn't. It has nothing to do with the scripting language
>used. That, in fact, is the whole point.
I personally thinking runtime extension of the DOM is a bad idea. The
first thing you need is to get W3C to agree on allowing such runtime
extensions. Then it would be a problem of Javascript (and other scripting
languages) to support it.
My point was that *IF* it was desired, then it would be best in orthogonal
layer that does not require all the other things in XBL. Remember we don't
sew our pants to our shirts, because mix and match is more useful.
>> SOAP [...] might solve in future.
>
>SOAP is an RPC language. Why on earth would SOAP be used to solve a
>DOM interface extension proble,.
If you wanted wide interoperability of an runtime interface extension, then
RPC might be a way... but I was not asserting authority... it was just an
"off the cuff" idea on how one might do it for widest interopt.
>> [...] other technologies might solve in future.
>
>Or, we could take an existing language, like, say, XBL, or HTCs, and
>use that, since that is exactly the problem they set out to solve, and
>experience shows that these are solutions that work fine.
Ian afaik there is no widespread use of these technologies commercially. I
will be the first with XSLT in 2003.
You will say that is besides the point, and I will counter that it is the
point. Maybe we should both sit on a needle. :-)
>> You are trying to create extensible *standard* DOM interfaces
>> without those interfaces being *standards*.
>
>A good example would be the HTMLSelectElement interface, which an XBL
>implementation of a <select> element would have to implement.
>
>This is a standard interface.
Good point. What is the DOM standard interface for Daniel Glazman's
resizeHandler? There is not one. XBL could iinvent one out of thin air,
but this would not have any utility over functions and methods in an
expanded document of XSLT.
I know you will argue that other scripts could then use them thru the DOM.
And I will respond that such runtime DOM extensions should be an orthogonal
layer to XBL and then are equally useable in any layer, which includes the
XHMTL output by XSLT.
>(Imagine you had two bindings: a UA default binding for <select> that
>rendered like a combo box, and an author custom binding for <select>
>that rendered like a map. No semantic difference: this is purely a
>presentational thing.
Above you said that radiobuttons were semantic switch, now you say map is a
presentation switch. Would you please make up your mind which is it?
> Both would implement the HTMLSelectElement
>interface, so that DOM code could interact with this element without
>having any idea which binding was active.)
Works great for predefined standards, but doesn't help you much for XBL's
main purpose which is new widgets and new custom tags. Ask Daniel Glazman,
the co-editor of the spec.
>>> [snip explanation of why dynamic DOM changes need to be reflected
>>> in whatever binding system is used for the presentation layer]
Please stop proganda what is written by someone else. That is very
contemptious. Either delete my stuff and leave only [...], or do not
delete it.
>> This is a reasonable point. I did consider this in very beginning
>> and my observation is that the adding of content post markup
>> (generated content) is implementation dependent
>
>With XBL, it isn't.
I am not going to even touch that one because it is a ludicrous assertion.
It is contrary to other things you have written.
>> In other words, you can write an XSLT transformation that has
>> behavior to add content within the implementation methaphor.
>
>With XBL, you don't have to do any work at all, you get this for free.
Sorry, but nothing in life is free.
>> XBL merges the DOM implementation specifics such as DOM HTML and the
>> semantic binding.
>
>XBL doesn't touch any DOM implementations specifics such as DOM HTML,
>and is not involved in semantic binding.
Blah, blah...
See above...
>I personally have spent about as much time replying to your e-mails,
>as I have in total learning and using XBL throughout my life.
Agreed. The debate is ridiculous.
>>> I am indeed one of its more vocal proponents in the CSS working
>>> group.
>>
>> And that is why it is important that I try my best to convince you
>> about the problem with merging the semantic binding layer and the
>> implementation layers.
>
>Since I don't think that XBL has anything to do with Semantic Binding,
See above...
>I don't think it is important for you to convince me that merging the
>semantic binding layer and the implementation layer (neither of which
>figure in my diagram, oddly enough) is a bad thing.
oddly any one can draw misleading graphs.
BTW, Happy New Year!!!!
-Shelby Moore
Received on Wednesday, 1 January 2003 04:01:19 UTC