- From: Shelby Moore <shelby@coolpage.com>
- Date: Fri, 03 Jan 2003 00:33:49 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-style@w3.org
At 04:36 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.
>
>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.
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.
Need I say any more? Why would any one markup a page with tags that have
no meaning?
LOL ! :-)
>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.
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.
Well actually, these silly examples do prove that you will do anything to
obfuscate rather than admit you are wrong.
[...]
>> 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.
XBL binds new tags to some thing. That *IS* creating meaning (semantics ==
meaning).
We can't write specifications for every kind of extensible tag that people
need. The world is infinitely complex. Developers are free to create new
specifications and use XBL to implement them. Preferably use XSLT per my
points here in this thread.
W3C is not the sole source of specifications. Someone might need a set of
tags for an intranet for example specific to their internal organization.
Someone might create a new set of widgets and make the specification
public. Etc...
>> 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.
Wrong. Adding a border is not the same as providing the meaning to a new
tag by implementing what it does entirely.
>> 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?
If XSLT and XBL implement a new tag, then that implementation is the
specification for that new tag. Or the creator may release a written
specification.
W3C is not the only source of specification. Authors need to be able to
create extensions quickly without waiting for W3C to address their infinite
needs. The best the W3C can do is make sure it doesn't muck up the style
layer by merging it with the semantic binding layer.
>>>> 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.
The parser's conversion of markup to DOM HTML is supposed to follow the
semantics of the HTML specification. Like all transformations, semantics
will change some what during a transformation which has no inverse. It is
a mathematical fact that can't be avoided. Either you have an inverse or
you don't.
Thus your assertion that HTML spec is final form of semantics is impossible
or impractical in the real world.
HTML spec is only final form in it's written form. When implemented then
the things that are not written have to be intrepreted. Since HTML spec is
not an infinite document it is impossible for it to qualify all aspects of
semantic variance.
>>> 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. 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"
Thus some of the important semantics of header, as different from first
sentence of paragraph, are open to interpretation.
Some parsers might ignore the headers entirely and merge them as first
sentence of first paragraph.
That is totally different than changing the rendering such as font of a
header. One is semantically significant, and the other is merely
presentation property. This is a grey area, and especially the header is a
poor example to analyze because it is so broad.
None of this changes my argument that if XBL implements new tags, then it
is providing new meaning.
>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.
>In all of those renderings and any others, it is still a heading.
I agree with that because they are just rendering transformations, not
semantic ones.
>> 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.
Header popularly implies one header in section, or at least we can say the
specification is ambiguous on that point. Creating multiple copies of
header from one markup instance is imho very close to (if not a) semantic
interpretation as compared to what header is defined by the specification.
Nevertheless, I agree this was a weak example on my part.
A stronger example of parser semantics is when parser allows XBL to define
a new tag.
None of this changes my argument that if XBL implements new tags, then it
is providing new meaning.
>> 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.
>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.
If you have a new tag (not specified by W3C) and XSLT binds that tag to
some new implementation, then it most certainly is attaching semantics to
that new tag.
>>>> 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.
False. Font can be set on a paragraph and font has nothing to do with the
semantics of paragraph. This is 3rd time I have mentioned that font is not
semantically related to paragraph.
John Lewis has written in this thread "CSS doesn't need to know the markup
languages it's applied to, or any markup language at all; that's the beauty
of it. Knowledge of the markup language's elements is contained in the CSS
author, where it belongs.".
John Lewis also restated in another way, "CSS selectors match elements
without regard to the elements' semantics"
[...]
>>>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.
Wrong. See my discussion above.
>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.
How can an author use a tag for which he doesn't know the meaning??
That is the most ridiculous assertion you've made yet. 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.
>>> 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.
Maybe not W3C specification, but they have some specification, even if only
in the mind of the author.
>Absolutely, just as CSS can style tags [sic] that have no specification.
>That doesn't mean those elements suddenly gain some sort of meaning.
CSS is not and should not be involved in providing meaning. That is my point.
XBL provides meaning to new tags and thus should not be intimating tied to
CSS and DOM in its syntax. XSLT can bind new tags without those weaknesses.
>>> 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.
>> 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.
You extract the date from the content using regular expressions.
Other layers which use the same document, will not know that you
interpreted the content semantically as a date.
That is what we have markup tags for.
>Even if it did, all that is happening is that the rendering is changing.
Wrong. Other layers which use the same document, will not know that you
interpreted the content semantically as a date.
That is what we have markup tags for.
>Should I mark up every initial letter of an element's content before I
>apply 'text-transform: capitalize'?
"::first-letter" is an inferred pseudo-element semantic of CSS. It does
not belong in the markup layer because it is impractical. Thus some very
low level semantics are defined at the CSS layer. However, those semantics
are ALSO entirely _CONTAINED_ within the CSS layer. If another layer wants
to interpret the document semantically regarding pseudo-elements, then it
can refer to the CSS specification.
Also the ::first-letter is much closer to presentation semantically then
interpreting arbitrary content as a date. Also ::first-letter is
well-behaved and predictable in all languages. Whereas your regular
expressions will likely fail on some formats of date. In fact, this
reminds me of when you argued against ::sentence, because you argued that
it can not be reliably parsed.
>> 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 we do that every new data type of content in the document we create??
>Should I mark up every verb on the off chance that some layer will care?
Being ridiculous doesn't help your argument.
>> 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.
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.
And it is the conceptual point that matters. Maybe date is not important
enough to care whether it renders correctly. But conceptually there will
be cases that are important.
::first-letter is predicably inferred without markup
Inferring more complex structures from content is to be avoided as it is
very dangerous. There may be cases where markup is impractical (such as
::first-letter, proposed ::sentence, etc) , but certainly date is not one
of them. That is used very rarely and would be useful markup for search
engines, etc.
>>>| 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?
That doesn't address any of the points of my thread.
You are trying to argue that binding a new tag (a semantic markup) to
implementation is not involved in semantics.
Remember that specifications do not implement. And remember that having
XBL implementing semantics while also being intimate to CSS and DOM thru
syntax is in practical terms merging layers. That will cause same kind of
problems, that would be caused by adding to CSS the semantics properties of
markup.
Your date example is just the tip of iceberg of how brittle and "spagetti"
every thing will end up. I'll be back here in 2 - 3 years saying "I told
you so!" :-)
>> 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.
If you say so then it MUST be true, but it doesn't change the fact that XBL
can "make new widgets (new tags) using existing XUL widgets (extend them)".
>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++.
That has nothing to do with point I was making.
The limit of new tags is infinite. You will never make all of them in C++,
nor would you want to.
>It doesn't matter what language is used to specify the event handlers,
>the semantics of the elements don't change.
I do not see what event handlers have to do with my points about semantic
binding. I have not mentioned events regarding semantic binding. I only
mentioned that combining the events layer syntactically with the semantic
binding layer, makes the 2 layers non-orthogonal.
[...]
>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.
Perhaps that would that be Daniel Glazman (my other antagonist in this
thread) or his cohorts.
>>>> 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.
That is a far cry from being a normaltive part of specification or syntax,
as is case for XBL.
Besides those references do not imply it must be used that way.
>> 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?
I am not walking into any more of your traps.
I made my assertion and I stick by it. Caveat Emptor.
I suggest you re-read the ENTIRE thread, therein you will find some of my
thoughts on this.
>>> 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.
It is my way of saying I am tired of debating you. I already covered these
details. Next time please try harder to reach understanding earlier, if
you are really after truth.
>>>>> (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.
No it was written by you and I added one word.
You took things I had written out of different contexts, merged them, and
asked me agree. You inserted the statement that "essential nature is tag
name".
Ian you are ________NEVER__________ wrong. End of debate.
All future replies from you on this topic will be blackholed. Thanks for
discussion but I have no more time.
-Shelby Moore
Received on Friday, 3 January 2003 01:32:53 UTC