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

John,

BTW, the "emphatic" portion of my reply was targetted more towards Ian and
Tantek (and any others who plan to obfuscate the useful debate).  I have very
much appreciated the open mindedness of your debate.  The Axiomatic Proof was
merely factual response to you.

Now I will convince you... :-)


At 05:26 AM 1/5/2003 -0600, John Lewis wrote:
>
>Shelby, you didn't respond to the meat of the argument: You're talking
>about HTML's semantics as defined by humans and I'm talking about
>HTML's semantics as defined by the HTML specification.


But I did.  Non-conforming implementations are still implementations.  In fact,
_all_ implementations are not perfect and thus are to some small degree
non-conforming[1] [2].

Of course the conforming meaning has not changed.  But the implemented meaning
has changed.  We see this all the time in the real world.

You need to differentiate between "define" and "control" of meaning. 
Specifications "define", but they do not "control".  They do not "control"
because they do not "implement".

It is a very difficult concept to agree with, because we all want to believe
that making specifications will make all use of those specifications have
consistent meaning (myself included).  But laws of nature will always dictate
otherwise.  And in fact, Darwinism proved that superiority is only attained
thru competitive mutation.   There isn't one source deciding what mutation is
superior.  The nature we live in is a chaotic system.

We can ignore the laws of nature and then fail.  Or we can embrace the laws of
nature and understand how to best organize our specifications to optimize.



[...]
>The ability of CSS to change the meaning of a document to a human is
>unrelated to the ability to change the meaning of a document as
>defined by HTML.


I agree.  The former is conforming.  The latter is non-comforming.


> CSS can do the first, but it cannot do the second.


Wrong.  CSS can do non-conforming per an exact quote from CSS spec!!

http://www.w3.org/TR/REC-CSS2/visuren.html#display-prop

"Conforming HTML user agents may ignore the 'display' property."

Thus CSS "display" controls semantics because it admits it is not conforming
(in this case). 

See [3] for more discussion on this point.




>Until you provide an example proving otherwise, I don't believe CSS or
>XBL is harmful for the first ability; in fact, the ability to augment
>the meaning of a document to a human is part of the reason CSS and (I
>assume) XBL exist.


No implementation can change the conforming meaning.  Of course I agree with
that!!  If any one ever felt I did not agree with that, then they merely
misunderstand me.

However implementations can make non-conforming semantics.  When they do, they
are non-conforming implementations.  That is what my Axiomatic Proof stated.

Are non-conforming implementations bad?  Well yes and no.  That is a longer
discussion.  If you accept my Axiomatic Proof (which essentially just defines
what is conforming and what is non-conforming), then I am willing to move to
next level and discuss when non-conforming is good and when it is bad, and
optimal organization of layers to deal with needs for non-conforming
implementations.

It sure has taken a long time to get to this point, as that was the original
discussion I wanted to have:

Subject == "CSS is wrong W3C layer for semantic...".


> Likewise, you haven't proven that CSS or XBL has
>the second ability, so I cannot condemn them for that.


I have proved it with quote above.



[...]
>> Axiomatic Proof:
>
>> 1. Specification defines the meaning of HTML,
>
>True.


Note the word "define".  Not the word "control". [2]

Please make sure you read the cited references.



>> 2. Thus any deviations which are not allowed by the specification,
>> would be changing the semantics as defined by the specification.
>
>No, deviations not allowed by the specification make the document
>*invalid* or the UA *in error*.


Non-conforming and CSS also allows non-conforming per the CSS spec as quoted
above.



> HTML remains constant. I agree it
>could well change the semantics of HTML to authors (see below for an
>example), but not the semantics of HTML as defined by HTML.


You are just relating the difference between conforming and non-conforming
meanings.

The whole point of the Axiomatic Proof is to define the two kinds of meanings. 
So in essense I agree with your point that one meaning is for the specification
and the other is for humans (or apes or who ever the implementation is
targetted to).



>> 3. XBL can most certainly change the implementation of HTML tags to
>> some thing which disagrees with specification
>
>Assuming for a minute this is true, which no one has proved:


See [3] for the beginning of this discussion.  We can carry on from there, if
we can first agree to [2].

So please reply first to [2] (agree or disagree), then if agree we can move to
replies to [3]


[...]
>By your definition, Internet Explorer for Windows has changed the HTML
>specification.


Microsoft understands very well that implementation controls non-conforming
means, and that is IMHO why they aren't too worried about W3C.

They will pick and choose what they support.  Since they control 95+% of
browser implementations, then they will in effect control meaning.  It will be
some times non-conforming, but nevertheless that is what some (or most) authors
will use.

BTW, Mozilla also has same problem.  For example their support for XSLT is
non-conforming.  Mozilla is apparently more focused on its non-standard XBL.


> I agree that IE/Win does things wrong,


So does Mozilla.  Every implementation does things "wrong".


> but we call
>those "bugs" or "errors"--


Remember I got offended when Ian used this word so loosely.  If you say that
any implementation that doesn't agree with your specification has a "bug", then
the word "bug" loses it useful meaning.  Because there are infinite
specifications in this world.  Microsoft has it's own specifications.

The only correct way to say this, is that the implementation would be "not W3C
conforming".  That is a very big difference from "bug".  Now if the
implementation claims to be 100% W3C conforming, then of course it would be a
"bug".

I'd really have a much easier time respecting people who do not get too overly
righteous with the word "bug".  I am one of the best debuggers at every company
I ever worked for, and so I know very well that a bug is when the program does
not behave as specified.  But you have to honor the specification claimed by
the programmer, not your own specification.


>we don't say that HTML has changed. Even if,
>for example, everyone starts using acronym elements instead of abbr
>elements, that doesn't change the meaning of acronym as defined by
>HTML.


I agree that implementation can not change conforming meaning.  But
implementation can control and change non-conforming meaning.  Two different
meaning spaces, as I am sure you agree.

We agree.  Just different ways of stating the same concept.

[...]


[1] http://lists.w3.org/Archives/Public/www-style/2003Jan/0087.html
(follow all cited references within link above also)

[2] http://lists.w3.org/Archives/Public/www-style/2003Jan/0092.html

[3] http://lists.w3.org/Archives/Public/www-style/2003Jan/0094.html


-Shelby Moore

Received on Sunday, 5 January 2003 12:54:51 UTC