W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: XBL2

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Fri, 3 Sep 2010 09:34:40 -0700
To: Ian Hickson <ian@hixie.ch>
Cc: hyatt@apple.com, public-webapps@w3.org
Message-ID: <OFE93F387D.0BE02705-ON88257793.0059B467-88257793.005B10B7@us.ibm.com>

It's good news that you have re-opened the XBL2 effort. We still don't have
a reasonable component model for HTML, and XBL1 has proven its value for 10
+ years in the Mozilla world.

My first question is how to deal with the chicken-and-egg problem where
developers won't touch it until 95% of deployed browser support this
feature, and browser teams won't touch it until developers show strong
interest. Is the idea that if the features goes into the HTML5 spec and one
or two browsers implement it right away, then maybe the other browsers will
follow? One other option for dealing with the chicken-and-egg problem is to
make sure that the XBL2 spec is implementable in JavaScript. If a good
JavaScript library existed and the browser teams agreed that native support
for XBL2 will be offered as a native feature for HTML5 in the future, then
developers could use XBL2 right away in current browsers and then find
improved performance in future browsers.


PS - I still have a nervous tick from our efforts on sXBL

  From:       Ian Hickson <ian@hixie.ch>                                                                          
  To:         public-webapps@w3.org                                                                               
  Cc:         hyatt@apple.com                                                                                     
  Date:       09/02/2010 06:24 PM                                                                                 
  Subject:    XBL2                                                                                                
  Sent by:    public-webapps-request@w3.org                                                                       

Since XBL2 wasn't getting much traction, I've taken an axe to the spec and
made a number of changes to the spec based on some discussions with some
browser vendors:


The main changes are simplification: I've dropped namespace support, made
it part of HTML rather than its own language, dropped <style> and <script>
in favour of HTML equivalents, dropped all the <handler> syntactic sugar
(and redirected event forwarding to internal object instead), dropped
<preload>, dropped mentions of XForms and XML Events, and so on. I've
updated all the examples to use the new syntax, so if you're curious about
the differences, comparing the examples in the spec above to those in the
TR version is probably a good way to get an idea of what I did.

If this ends up being more successful than the previous work on this
specification, I'll have to merge it with the HTML spec to more properly
define how it works. Right now it leaves a lot of the detail a bit vague
(e.g. integration with the event loop, the parser, authoring conformance
definitions, etc). If this happens, I don't yet know how much this will
lend itself to being extracted back out into a separate module (for
publication by this working group), versus being just published as a core
part of the HTML spec, but I will be happy to update the group on this
matter as it becomes clearer.

I don't think the draft above would be suitable for publication as a TR/
draft, because of the aforementioned rough edges. I mostly just wanted to
provide this for discussion, to see whether people considered this a move
in a good direction or a significant step backwards.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

(image/gif attachment: graycol.gif)

(image/gif attachment: ecblank.gif)

Received on Friday, 3 September 2010 16:35:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC