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

At 05:16 AM 1/1/2003 +0000, Ian Hickson wrote:

[...]

I will respond to your the rest of your post later...

Below are a few items that stuck out for me.


>>> 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.


That imho is indicative of your ability to judge fiction from reality
("bug" from "todo").

Almost everything is a bug by your definition.  Bug then has no meaning.
Hmmm...sounds similar to our semantic debate...

Any thing you can do to discredit...

Are you really after truth?  Seems to me you don't get paid to do this,
thus there is some righteous reward?



>>>>> 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.


Er, can't you read??????????????

http://lists.w3.org/Archives/Public/www-style/2002Dec/0230.html

"You must have forgotten that Javascript does not require a function."

Are you not familiar with Javascript syntax:

{
var a =...
}

There is no function name there.  And all variables should be in block
scope.  If Javascript does not support block scoping, then it needs to be
fixed, or use a better scripting language.

How you going to wiggle out this one Ian?  Ignore it?



>>> 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.


When did compiled UA code become redefined as "scripting"?

You will do any thing to wiggle out of finding truth.


>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.

You wrote that behavior requires scripting.  I said it was False.  It is
indicate of everything you write that you prefer to invent fiction to save
yourself from admitting you are wrong.

The *FACT* is that behaviors can be implemented in the UA for standard
elements.  This is what XUL does.  That is not user/author scripting.  You
know that.  You just can't admit it in public.

Take that single point in isolation and it is a *FACT* that you made a
false statement.


-Shelby Moore

Received on Wednesday, 1 January 2003 02:23:57 UTC