- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 3 Jan 2003 16:22:37 +0000 (GMT)
- To: Shelby Moore <shelby@coolpage.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Fri, 3 Jan 2003, Shelby Moore wrote:
>>>
>>> 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.
>
> Thanks for writing that. I hope everyone reads that. New tags have
> no meaning according to Ian Hickson.
That is correct.
> XBL will add some implementation to new tags, and people will author
> pages with those new tags, but those new tags will have no meaning.
People should not be sending any elements that have no predefined
normative semantics over the network.
This is one of the fundamental cornerstones of accessible Web design.
> Need I say any more? Why would any one markup a page with tags that
> have no meaning?
That is a question very well worth asking, and one which has often
been overlooked by the XML groupies who jump on the bandwagon as it
goes past.
>> If I transmit the following XML over the network:
>>
>> <nmce xmlns="http://ns.example.com/53si8" />
>>
>> ...and assuming there is no spec for the namespace, which there
>> isn't, then that document is completely meaningless.
>
> Go on and on with your useless examples, which are not at all
> related to creating new tags with XBL, and which prove absolutely
> nothing relative to the point at hand.
With respect, my next sentence explained the relevance of that remark:
| 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.
-- http://lists.w3.org/Archives/Public/www-style/2003Jan/0045.html
You could take that one-element document and associate it with any
number of XBL bindings or XSLT transforms, using <?xml-stylesheet?>
processing instructions, HTTP Link: headers, XLink out-of-band link
bases, or even the DOM, but that wouldn't change the fact that that
document is meaningless.
> W3C is not the sole source of specifications.
That is absolutely correct. The W3C is merely one of several
consortiums of companies working together. Other groups get together
and create their own markup languages, e.g. the DVB group, the WAP
forum, even Mozilla and small groups like the blogite mailing list
have written specifications.
> Someone might need a set of tags for an intranet for example
> specific to their internal organization.
This is a very common scenario. So long as everyone involved with the
documents is aware of the semantics behind the language being used,
there is no problem.
Say I make up a new language, based on your <slideshow> example:
<slideshow>
<img src="img1.gif"/>
<img src="img2.gif"/>
<img src="img3.gif"/>
<slideshow/>
So long as there is a specification, which could be as simple as:
SlideShow Markup Language
MIME type: application/x-slideshow+xml
Root element: <slideshow>. No attributes. Represents a complete
slideshow document.
Children: <img/> with one attribute, src, pointing to a GIF image.
Represents a slide of the show, in document order.
...then that document has meaning. Note that no XBL has been involved,
no XSLT. The document now has meaning in and of itself, and a
dedicated SlideShowML renderer could be written.
>>| 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.
>
> Wrong. Adding a border is not the same as providing the meaning to a
> new tag by implementing what it does entirely.
What is the difference?
Without any CSS, an HTML document rendered in a UA that uses just CSS
to render documents would just be one long line of text.
>> XSLT and XBL don't give any new meaning. Where in those specifications
>> do you see it saying that they do?
>
> If XSLT and XBL implement a new tag, then that implementation is the
> specification for that new tag.
But where in either the XBL or XSLT specificiations does it say that
the binding or transform actually gives semantics to the document?
>>>> 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 [...].
>
> Notice that this definition of semantics is very broad.
Indeed. This is both a strength and a weakness of the HTML
specification. But that is a topic for another mailing list.
> It does not differentiate the the semantics of a header from the
> opening sentence of a paragraph. Both "briefly describes the topic
> of the section it introduces"
Well the opening sentence of a paragraph would be within the <p>
element, not within the <h1> element, so actually that isn't one of
the ambiguities.
> Some parsers might ignore the headers entirely and merge them as
> first sentence of first paragraph.
A parser would be in violation of the spec if it did so.
However, it is trivial to use CSS to obtain this rendering:
h1 { display: run-in }
h1 + p { display: block; } /* typically the default value */
Or you could turn the entire document into one visually rendered
paragraph:
* { display: inline; }
This doesn't change the semantics, only the rendering.
>> 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.
>
> I agree but those are presentation decisions. They do not
> semantically change the header into a paragraph for example.
Let's examine some of these further then:
| cropped with the rest of the text in a tooltip [...] animated such
| that it tries to follow the mouse cursor
Both of these are beyond pure CSS, and require DOM scripting to
achieve.
| even transliterated into Klingon.
How is this, which you say is just a presentation decision, any
different from transliterating into a different time zone?
| rotated pi by two radians and printed on the left of the page
I find it VERY odd that you say that this is not a semantic change
given that you said:
>>> 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 it is a semantic binding at the top of the page, but not on the
left of the page? Or is it the rotation that decides whether it is a
semantic binding?
If I put it at the top left, is it half a semantic binding?
>>> 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?
>
> I can for sure implement a new tag with XSLT. And I can for sure
> attach that new tag to some implementation which gives it meaning.
> Are you disputing that I can do that and still be within the
> specification for XSLT??
>
> If you are disputing that, then I can give an example on next reply.
> Just ask me to.
Sure, I would love an example. Please provide one.
What I would love even more though is a quote from the specification
backing your position, as I asked for above.
> I can't fathom where you get the idea that someone can or would
> author a web page without having some clue what the tag meanings
> are.
I never said they didn't -- you did.
You stated that elements could be _given_ meaning, i.e. go from no
meaning to some meaning, by being bound by XBL or transformed by XSLT.
This implies that when the document was written in the first place,
the elements had no meaning. Yet you wrote:
> How can an author use a tag for which he doesn't know the meaning??
I ask you the same thing: How can an author use a tag for which he
doesn't know the meaning?
And if the document _does_ have meaning, then how can XBL or XSLT be
_adding_ meaning to the document?
>>>> 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.
>
> You implemented the timedate using XBL in your example.
But that is the presentational layer.
What is the implementation layer?
Could you drawan equivalent of my diagram showing this layer?
> Let's just hope your regular expression doesn't fail and render a
> girl named "May who is 19 years old in 1985", as a date. Or some
> other weird content or language.
There is no need to hope -- my CMS only generates dates in ISO
standard format, and my binding only matches dates in ISO standard
format, and the binding is limited to the context of permalink
anchors, whose only content, as guaranteed by my CMS, is an ISO
standard date.
>>>>| 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.
>
> So what?
So that indicates that it is not the XBL that is conferring the
semantics onto this element.
>> 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?
>
> I am not walking into any more of your traps.
If my asking to back up your claims is a "trap", that doesn't say much
about your claims.
> I made my assertion and I stick by it. Caveat Emptor.
I _am_ being, as you say, cavere ("to beware"). That is why I asked
you to back up your claims.
> I suggest you re-read the ENTIRE thread, therein you will find some
> of my thoughts on this.
It isn't thoughts that matter, it is evidence.
>>>> 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?
>
> I suggest you re-read the ENTIRE thread, therein you will find some of my
> thoughts on this.
I re-read the thread, and as far as I can tell, you are claiming I am
wrong about XBL being usable with another DOM or style language, and
you disagree with that this is important.
Well, here is proof:
<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="demo">
<handlers>
<handler event="mouse-click" type="application/x-perlscript"> <![CDATA[
$self->attributes("open")->toggle();
]]> </handler>
</handlers>
<implementation>
<property name="open" type="application/x-perlscript">
<getter> <![CDATA[
return $self->attributes("open");
]]> </getter>
<setter> <![CDATA[
$self->attributes("open")->set($val);
]]> </setter>
</property>
</implementation>
<content xmlns:html="http://www.w3.org/1999/xhtml">
<html:span inherits="text=title"/>
<html:div>
<children/>
</html:div>
</content>
<resources>
<stylesheet src="data:text/x-en-style,hide div in element without open"/>
</resources>
</binding>
</bindings>
That binding has no dependency on the W3C DOM, no dependency on W3C
Events, no dependency on ECMAScript, no dependency on W3C CSS.
> The conceptual point is that XSLT can transform a new useful tag to
> an implementation of it's semantics.
Indeed it can, just like XBL can, but that doesn't add semantics.
> Also note that any one (author, UA, visitor, etc) can substitute a
> different XSLT transform to change this to any other way of
> implementing a slide show. An example would be to use scripting to
> change one img element's src attribute using a timer.
But this doesn't change the semantics, it only changes the
presentation and behaviour.
> Okay so we have established that XSLT can do the following things:
>
> 1. Implement the semantics of new tags by transforming a new tag
> into an implementation of supported tags. I call this transformation
> "semantic binding". Call it what you want, as long as you understand
> what it does.
Earlier you said that semantic bindings is the definition of the
meaning of an element, now you say it is the (code level)
implementation of those pre-existing semantics.
It is very hard to have a discussion when the terms change all the
time.
Yes, XSLT can "implement" an element, i.e. add event handlers,
methods, properties, and style to it. This does not _change_ the
element's semantics.
XBL can do this too, although from a technical perspective XBL does
this in a more object orientated way which makes extension easier.
(Which is to be expected, as XBL was designed for this, whereas XSLT
was designed for non-dynamic one-shot transformations and is therefore
poorly defined, if at all, in dynamic environments.)
> 3. Notice that the binding (transformation) has absolutely no
> dependence on DOM or CSS.
If the transformation includes DOM and/or CSS in itself, then the
transformation itself does have a dependency on those technologies,
which is not a problem.
The language itself, just like XBL, does not depend on any particular
DOM or CSS syntax or feature.
> Thus note that the swapping of transforms can be done without any
> changes needed to CSS stylesheets and without concern for UA's DOM.
Unfortunately the lack of concern for the UA's DOM is one of several
major downfalls of using XSLT for behavioural implemenetation.
There are several key aspects that a behavioural language must have:
The DOM must not change before and after binding.
The DOM must be dynamic, adding and removing elements to the DOM
must dynamically apply the binding.
The DOM must not be polluted at all.
XSLT doesn't define how it interacts with the DOM, so UAs differ on
the first of the above (in practice, since CSS needs a document tree
to style, what usually happens is that either the DOM is replaced, or
there are two DOMs, both of which are poor solutions). XSLT has never
been implemented dynamically to my knowledge, so it fails miserably to
achieve the second of the above. And the third can only be achieved by
using some inconvenient workarounds (like using anonymous lambdas
instead of functions).
In addition, XSLT fails to provide a way for users to selectively
override parts of the document's rendering, e.g. in the above
slideshow example, XSLT provides no way to make the first slideshow
stay on the screen for longer without change the document.
With XBL bound using CSS, users can add a single line to their user
stylesheet to override the binding with one of their own.
> [...] This means that what ever _semantic_ markup is used to
> implement the new tag <slideshow> will not appear in the DOM. Only
> <slideshow> and any exposed methods and properties will appear in
> the DOM. This is apparently by design so that the semantic markup
> data is encapsulated (similar to OO classes). That sounds like it
> should be a good thing for design.
Indeed. It is a cornerstone of the XBL design, and addresses the first
and third points given above.
> Well if you think a little deeper about it, you realize that
> _semantic_ markup is being obscured from the DOM. But the new tag is
> not part of a specification that is widely understood by UAs. It is
> a custom new tag. Thus the part of the content which _IS_ understood
> by most UAs and other layers is now obscured.
If the elements are not recognised by the UA, then it is highly
irresponsible to be sending them over the network in the first place.
Both XBL and XSLT are optional layers: they can be switched off, the
user can view the original markup instead of the transformed markup.
Therefore it is important that only content which is understood by UAs
be sent in the first place.
> This means that if we want to debug it, or do any of the other
> things we are normally used to do on supported markup tags, we can
> not.
Given that the only implementation of XBL comes with a hugely detailed
debugger specifically for this purpose, that would seem to false.
> Thus XBL:
>
> 1. Binds semantic implementation of a new tag only if DOM or CSS are
> available.
The XSLT implementation will only be able to work if DOM and CSS are
available too, since without them, there can be no styling and no
event hanlding, and thus no behaviour.
Anyway, that is not an important consideration, since even the most
minute of HTML implementations now have DOMs and CSS support. (And
certainly have them before XSLT support.)
> 2. Can only swap implementations if CSS or DOM is available. You
> have to swap the CSS style sheet to change the semantic
> implementation. Or you have to wait until document is loaded in DOM,
> then dynamically swap it with calls to the DOM.
This is a non-issue, since the same applies to any technology.
It'd be like saying "XSLT can only be swapped if you have XML
stylesheet PI support".
> 3. Other layers can not access the implementation of the new tag,
> even if that *IS* the semantic markup they will understand.
Actually, in the unlikely case that the other layers want to violate
the encapsulation layer, they _can_ access the anonymous content, as
there are special methods provided just for this purpose.
--
Ian Hickson )\._.,--....,'``. fL
"meow" /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 3 January 2003 11:22:41 UTC