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

At 04:16 PM 12/27/2002 -0600, Jeremy Dunck wrote:


>And on that note, one -could- argue that the DOM is redundant with XSLT.

In what way?

DOM core is the Document Object Model.  It only models the document
objects.  XHTML DOM models the types of objects in XHTML.

XSLT is an XML application for transforming XML documents.

One thing models objects.  The other models transformations.  How can you
say objects are redundant with transformations?

>  Or 
>that XSL:FO is redundant with CSS.  Or that XHTML is redundant with HTML.  
>And so on.  And they'd be somewhat right.

Yes these are *partially* redundant because we have legacy standards which
do not have compelling functionality we need, so we create new ones.  In
the cases above, the compelling functionality is first to support XML.
Remember in my opening post, I said the question was whether there are
compelling applications of XBL which existing W3C standards can not do?

>I know you, Shelby, interpreted Daniel's remark "Hammers are too heavy to 
>efficiently smash flies." as being snide, and I certainly think it could 
>have been put less abrasively--  but the point is valid.

He wasn't referring to XBL.  He was referring to the W3C's proposed DOM
ViewsAndFormatting.  I responded that even his XBL example is using
proprietary (Netscape and IE's) presentation layer properties (such as
event.ClientX).  In fact, if you read the thread at bugzilla, you see that
on his todo list for that XBL example is scrolling.  There is no W3C
standard for the scrolling model of a View.  That is why that W3C proposal

So if any thing, he was criticizing his own code with that snide remark.

>The fact is that there's more than one way to skin any particular cat, and 
>the varying ways to do it are better than others in certain situations.

If you want to use XBL then no skin off my back.  But the W3C has finite
resources.  XBL is not supported in 99% of clients.  It will be a very
brittle way, because is not well designed to be orthogonal and swappable
across different layers of W3C standards.

And if you decide later to reskin your cat, you will be stuck because of
both the lack of orthogonal separation and because of lack of client
support (XBL is not orthogonal to the browser like XSLT is).  Like I said,
any one who wants to follow Daniel to "Bataan", then by all means follow
while the "Red Sea is parted"...just do not try to go back...

>I happen to believe it would have been better to make XBL bindings using 
>CSS-like selectors (and the cascade?) in separate instances, rather than 
>mingling them in where they could be mistaken as CSS properties.

I still do not see how that makes XBL orthogonal to the browser and thus
useable today on 99% of clients.

And I still do not see the other criticisms I made addressed by this change.

>I also believe that at some point, there must be glue to make all these 
>orthogonal layers work.

The glue is already there.  XSLT tranforms XHTML to XHTML.  XSLT is the glue.

>Witness the inclusion of an [stylesheet in XML].

Not following your point on that.

>  Witness the dodged bullet 
>of providing the [DOMImplementation] instance for client-side DOM usage.

This exposing the DOM on the client.  I do not see what this has to do with
the discussion of INTRA-layer orthogonality or "glue".

>Yes, I do believe that W3C standards could be used to accomplish what XBL is 
>doing-- but perhaps not so well.

Factual reason why??

>I am not knowledgable about XSLT, XBL, or DOM implementations to comment on 
>that.  I am not knowledgable on XEvents and XForms to comment on that.  But 
>I am also willing to believe that a group other than the W3C had a good 
>idea.  (That's not intended to be inflammatory...)

I have no problem with other people having good ideas. XSLT and XML weren't
my ideas and I avoided them for a long time.  Let's have a factual
discussion.  Opinions without factual basis just obfuscate the facts.

>Thanks for the constructive feedback, David.
>Shelby, you may not have fired the first shot, but humility in the face of 
>arrogance is quite disarming.

Trust me I have been humble.  There are other things I may have wanted to
say when someone insults me, but would not be appropriate here.  I am
trying to stick with the facts, but so far most of the discussion is just
opinions based on some stereotypical jusdgments (such as "all generality is
slow", or "orthogonality will not work in real world", or "XBL is great
because I work for Mozilla").

>Daniel, I think you've provided some great insight into XBL.

Yes.  For one thing, the example was very useful in illustrating weaknesses
of XBL.  You may not agree.  You may look at the XBL code and say, "wow
this is neat".  Every person is free to ignore the issues of good design.
That is why there are so many late, buggy, slow, and crappy software
products.  But not all.  Not all of us ignore good design principles.

>  Before this 
>thread, I knew of XBL, but but had never looked into it.  While I may 
>disagree with some of the specific implementation choices made, I think that 
>XBL does provide a great value-- Standards are good, but there's a lot to be 
>said for working code.

What is that value?  That you can make something which runs on 1% of the
browser clients?  Or that you can bundle the Mozilla runtime with every
copy of your application?  What you going to do when there is a bug, and
you go report it at bugzilla to find that there is no resources to work on it?

Personally I'd rather use widely implemented standards, because because of
law of supply and demand, there is much better chance I don't get stuck on
the wrong side of the Red Sea.

-Shelby Moore

Received on Saturday, 28 December 2002 23:36:14 UTC