Re: Another view (sorry) on XBL and behaviours

Thanks.

This entirely supports my subject of the thread I created, "XBL is (mostly)
redundant and CSS is wrong layer for..."

And I hope you have read my Shelby's Final Position Paper on XBL, as
hopefully it is more concise and convincing than that thread.  I agree the
thread degenerated.

Lastly, I completely agree with your assertions of redundance and is
another reason why I feel XSLT is a more transparent mechanism for using
the technologies you mention (scripting, etc).

Best Regards,
Shelby



At 07:43 AM 1/6/2003 -0500, Andrew Clover wrote:
>
>
>
>I've quite given up trying to follow the main thread on XBL, which seems to
>have descended into meta-argument, recrimination and irrelevance. However,
>I would nonetheless like to air my opinions on XBL and the idea of behaviours
>in general, if anyone is still listening.
>
>XBL files (as HTCs in IE) provide a layer of encapsulation that may be
>useful to some programmers. However, they do not themselves provide any
>real extra functionality; everything that can be done with them could be
>done with a little extra inconvenience using plain [Java|J|ECMA]Script,
>coupled with DOM Level 2 Events.
>
>In my opinion, this sort of architectural helping hand does not need to be
>a web standard. Requiring added complexity of all WWW user agents in order
>to make authors' lives slightly easier does not make sense. I'm not
>criticising Mozilla here: XBL is a fine feature for a browser to have,
>and a great way to implement internal browser features. But does that mean
>the W3C should call it a standard and ask other implementors to support it?
>I don't believe so.
>
>There is one other facet to behaviours which is actually a bit of a
>separate issue, but tends to be taken as read when discussing them: the
>binding of XBL (or HTC) files to elements using CSS selectors. This is the
>one feature of the XBL and BeCSS standards that can't be done using standard
>scripting and event handling methods, and it's very useful.
>
>However, the current way CSS selectors are leveraged is through adding an
>extra property to standard CSS stylesheets (-moz-binding in Mozilla,
>behavior in IE). This is very easy, very practical, and architecturally
>absolutely terrible. Behavioural/scripting information is about much more
>than style, and should not be mixed with styling.
>
>>From a security point of view, allowing links to active content in styles is 
>dangerous. Stylesheets are expected by many to be free of active content,
>and are allowed in places such as user-submitted content, HTML e-mail etc.
>where active content is unacceptable. Many applications may wish to allow
>styling through, but not scripting; expecting them to include a full CSS
>parser, as well as understand the browser quirks in CSS parsing, to be
>able to filter out the scripting information, is unrealistic.
>
>IE's dreadful "property: expression(alert('scripting!'));" extension to CSS
>has already caused hundreds of cross-site scripting bugs in real web
>applications; the 'behavior' and 'binding' properties threaten to create
>even more. Please do not provide more new places to hide scripting in
>non-script content.
>
>So what is the alternative? Simple, just provide a way CSS selectors (or
>similar - XPath selectors would be just as good) to be leveraged from script,
>that does not involve actual CSS stylesheets. An example way this could be
>done:
>
>  function myclick(e) {
>    alert('You clicked on a <div class="foo">!');
>  }
>
>  function binder(e) {
>    if (e.type=='bind')
>      e.target.addEventListener('click', myclick, false);
>    if (e.type=='unbind')
>      e.target.removeEventListener('click', myclick);
>  }
>
>  document.addSelectorListener('div.foo', binder);
>
>In this example, the function binder would be called every time an element
>matches the selector 'div.foo'. So on calling addSelectorListener, binder
>will be called once for each existing <div> element with class="foo", and
>it'll be called again if a new <div class="foo"> is loaded, or a <div> has
>its class changed to include "foo", and so on.
>
>Using a method something like this, multiple behaviours could be bound to
>elements easily by encapsulated scripts, with no need for further formats or
>encroachment onto styling.
>
>-- 
>Andrew Clover
>mailto:and@doxdesk.com
>http://www.doxdesk.com/

Received on Monday, 6 January 2003 09:31:35 UTC