- 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>
Ian, 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. Jon 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: http://dev.w3.org/2006/xbl2/Overview.html 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. `._.-(,_..'--(,_..'`-.;.'
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: ecblank.gif
Received on Friday, 3 September 2010 16:35:26 UTC