Re: Another view (sorry) on XBL and behaviours

On Mon, 6 Jan 2003, Andrew Clover wrote:
> Hixie wrote:
>> I think you underestimate the amount of help XBL and HTCs can provide.
> No, I can see exactly how much they do.

Then you're a better man than me, because I certainly don't see exactly
how much XBL and HTC can do!

> For exactly that reason, their complexity, I feel opposed to their
> being a 'standard'. They're a great feature for Mozilla, which is
> after all more than a web browser, but not something that all UAs
> should be compelled to implement IMO.

Something being a standard does not compell anyone to implement it.

For example, CSS is purely an optional component of a Web browser.

Standardisation merely ensures that those UAs that _do_ want to support
something, can follow the same rules in order to at least attempt to be

> The ability to bind code to elements through selectors is the one
> 'capability' I see in XBL/HTC; the rest is 'architecture'.

The ability to bind code to elements through selectors isn't even
technically a part of XBL!

What about:

   anonymous content addition
   content reordering
   declarative event handler addition
   declarative method and property declaration
   scoped stylesheet linking
   image prefetching

...? Why are they architecture rather than abilities?

> > For example, a user could bind all buttons to a binding that was carefully
> > designed to provide keyboard access (or whatever the user needs), and then
> > specifically override any author bindings that try to change the behaviour
> > of buttons.
> I agree that this is desirable, but I don't think XBL as is stands is really
> capable of this. Unless I am mistaken and there is some special mechanism for
> this, the binding property is not additive [...]

That is due to a limitation of CSS, not XBL. There are already proposals
on the table for making the cascade additive.

> We see minor problems like this with CSS already, where user and author
> stylesheets clash to make some pages hard to read; the problem can only
> be amplified when scripts are involved, as interaction between programmatical
> elements is naturally more complicated than declarative ones.

Certainly this is a valid concern, however, IMHO the solution proposed
here is definitely a step up from <script> embedded in pages, where it is
either all or nothing.

> > Also, note that some aspects of XBL are distinctly non-trivial to
> > implement at the top level using script. For example, adding an <li>
> > element dynamically to an <nl> element may need quite significant code
> As far as I can see the only reason this would be difficult would be that
> a script cannot generally be told when an element matching a selector has
> entered or left the document (or has been mutated). An approach such as
> the addSelectorListener method I proposed in the previous post would make
> this reasonably easy.

No, it really wouldn't. I don't really know how to convince you of this. I
suppose I could show you some examples, but my scripting abilities aren't
good enough to write the JS equivalents of what can be done with XBL.

> I disagree with the implication, though, that behaviour is purely
> presentational. It's active, scripting content, which is something
> different. Some uses of behaviour might only be presentational, but
> not all are, just as not all <script>s are presentational.

I agree that active scripting can be both presentational and for logic.

I wouldn't classify the logic code as behaviour, though.

> > One is to suggest to the XML team that a new attribute be introduced,
> > xml:scripting or some such, which could indicate that everything from that
> > element and deeper should be unable to execute associated script.
> This is a useful idea, and one that has been suggested in a number of
> forms in www-html in the past. There are practical considerations...
> for example, an attacker could attempt to put a close-tag in the submitted
> content to end the no-scripting tag early and proceed to insert malicious
> code. It is easier to sneak tags through content filters than most
> authors think.[3]

With XHTML it's impossible (because you need the rest of the content to be
well formed or _nothing_ will work).

With HTML, you could use an <object> element.

> There are ways to stop this of course, but nothing suggested so far looks
> really elegant. I would prefer to reduce the number of in-roads for
> scripting content, by deprecation.

Deprecation won't help, since UAs will keep supporting them.

> > or including SVG as background images (SVG images can be scripted).
> Yes, however in this case the SVG script will have no access to the
> object model of the parent document. (I *hope* this is actually
> true, anyway, or users are in trouble...)

From the "window" object you can get to pretty much anything.

> > If you extend your example to what you'd have to do when binding a complex
> > one, the one line of CSS vs the dozens if not hundreds of lines of JS
> > becomes quite a convincing argument.
> I don't believe so... because J.*Script is a full scripting language
> there's nothing to stop you doing:
>   bindings= {
>     'input[type=submit]': {
>       'click': myclickfn,
>       'keypress': mykeypressfn,
>       ...
>     },
>     'select': {
>       'click': myselectclickfn,
>       ...
>     }
>     ...
>   }
> With suitable read-and-call-binding loop. Or some other less CSS-like
> strategy involving objects or whatever. This is an architectural
> decision; I prefer architecture to be left to authors.

I'd rather have one team per UA implement the code common to all bindings
rather than have hundreds of thousands of implementations all with their
own bugs.

> [4] In particular, javascript: pseudo-URLs are a disaster in every way
>     and should be deprecated *right now*.

They are, aren't they? In fact, they've never been anything other than
unofficial extensions, as far as I am aware.

Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.                         `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 7 January 2003 21:12:57 UTC