- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 1 Jan 2003 05:16:38 +0000 (GMT)
- To: Shelby Moore <shelby@coolpage.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Tue, 31 Dec 2002, Shelby Moore wrote:
>
> 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.
In fact, if I were to draw a diagram of the Web standards model, it
would look like this:
_ The User
/| \
/ \
/ _\|
User Agent: Output Devices Input Devices
(Rendering) (Events)
/|\ |
| \|/
Presentation: CSS DOM
\ /
`-------. ,-------'
|
Semantics: MathML, XHTML
|
Syntax: XML
|
Transport: HTTP, URI
|
Network: TCP/IP
XBL fits right into the Presentation layer:
_ The User
/| \
/ \
/ _\|
User Agent: Output Devices Input Devices
(Rendering) (Events)
/|\ |
| \|/
Presentation: CSS <----> XBL <----> DOM
\ /
`-------. ,-------'
|
Semantics: MathML, XHTML
|
Syntax: XML
|
Transport: HTTP, URI
|
Network: TCP/IP
It is the glue that binds CSS and the DOM.
> 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.
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.
> 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.
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.
> 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).
> 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".
> In XBL, afaik you can map semantics (the markup) to other content,
> implementation, behavior, events, style, DOM, etc.
I am not sure what "implementation" means in this context.
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.
> 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. :-(
> 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. 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.
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.
> 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".
> 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.)
>> 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. This is why I am a member of the CSS working group, and not
a member of the HTML, MathML, or RDF working groups.
>> 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.
Why do you think it is a semantic binding language?
> 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.
>> 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.
As in, the Cascade part of Cascading Stylesheets.
That is, the same document can simultaneously be bound to bindings
from different sources: author, and user.
> 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 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 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.
>> [snip an explanation of why changing JavaScript objects is not a
>> solution when the question is how to extend a DOM interface]
>
> 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.
> SOAP [...] might solve in future.
SOAP is an RPC language. Why on earth would SOAP be used to solve a
DOM interface extension proble,.
> [...] 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.
> 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.
(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. Both would implement the HTMLSelectElement
interface, so that DOM code could interact with this element without
having any idea which binding was active.)
>> [snip explanation of why dynamic DOM changes need to be reflected
>> in whatever binding system is used for the presentation layer]
>
> 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.
> 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.
> 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.
>>> The examples I am being asked to rewrite in XSLT have some years
>>> of development behind them.
>>
>> I came up with the "simple" demo in 30 minutes. The others did not
>> take more than an hour or two each.
>
> I meant the time you have spent learning and working with XBL and
> ditto for the people who created the complex examples that Baron had
> asked me to reproduce in XSLT.
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.
>> 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,
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.
>>>>>> I made a test driver app in HTML to test it:
>>>>>>
>>>>>> HTML: http://www.hixie.ch/tests/adhoc/xbl/demos/simple-driver.html
>>>>>
>>>>> I get an error when running Internet Explorer. Unable to test.
>>>>> Line13: "undefined" is null or not an object
>>>>
>>>> Ironically, that error message is unrelated to XBL -- it is a bug
>>>> in IE's XML DOM. That is to say, a bug with its W3C standards
>>>> support.
>>>
>>> How about not using propoganda.
>>
>> This isn't propaganda. You said it did not work in IE, I explained
>> why. It _is_ a bug, and not a lack of support, for what it's worth.
>
> Netscape and Mozilla doesn't fully support XSLT. Should I call that a
> "bug" or a lack of full support.
A bug.
>>>> nor can [XSLT] extend the interface of individual DOM nodes without
>>>> polluting the window's namespace.
>>>
>>> I refuted that already. See replies to Baron.
>>
>> Actually, you didn't. You simply said that a little pollution was ok:
>>
>> http://lists.w3.org/Archives/Public/www-style/2002Dec/0230.html
>>
>> ...(search for "collision").
>
> That reduced to one name only for the entire document without using XEvents.
>
> You apparently missed the part about XEvents completely removes the issue.
It doesn't, because you still need somewhere to place functions.
>> Of course to make it _do_ anything, just as with HTML, then you'll
>> need to script the document (using the DOM), or else it will just
>> be a non-interactive static document (like most HTML documents).
>
> False. <select> is interactive without any scripting.
No, it's not. The scripting might be implemented in C++, within the
core of the UA implementation, but it is still there.
If you want to do anything which the UA doesn't support, e.g.
rendering a <select> as a map instead of a combo box, then you need
scripting.
--
Ian Hickson )\._.,--....,'``. fL
"meow" /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 1 January 2003 00:16:40 UTC