We are, by default, disabling the ability for websites to use XUL and
XBL1. We are however allowing this to be overridden on a site-by-site
basis since we know there are a few websites out there that are relying
on these technologies.
We have discussed this for a while (years), and most of the code changes
have already been made which most of you have already noticed. However I
don't think the background has been fully and coherently explained which
is why I'm sending this post.
We are *not* disabling XUL or XBL1 for extensions and XULRunner
applications. They will continue to work just like they always have.
There are several reasons we are doing this:
1. We want to encourage people to move towards standardized
cross-browser technologies. It is extremely unlikely that any other
browser will implement either XUL or XBL1. And even more unlikely to
ever be specified to the level of detail needed to accomplish the level
of cross browser interoperability needed for the web. We realize that
this creates some problems for a few developers, but long term we think
this is a better thing for the web. We've listed a few alternatives
below to help people transition.
2. Over the years we have had plenty of security related issues with
both XUL and XBL1. When they were implemented, it wasn't done with web
support as a primary concern, this has lead to many edge cases behaving
poorly and causing security problems. To this day we are spending
resources finding and fixing problems in this code. So disabling this
code will both make things safer for our users as well as give us more
time to work on making the web platform more powerful.
3. Supporting XUL and XBL1 for websites adds a lot of complexity to our
code and limits what changes we can do to our code, effectively
preventing us from making performance and other improvements that would
benefit our UI.
In short, XUL and XBL1 is a lot of code, increasing our attack surface
as well as costing us engineering resources.
We'd rather take the step of removing support for these technologies
from Firefox, than foist the wrong technology onto the web. Instead we
prefer spending time on increasing functionality and performance of
cross browser technologies.
We are also not disabling most of the CSS properties related to the XUL
box model, such as "display: -moz-box". Work is underway of
standardizing these as part of CSS so we do think that these are
standing a better chance of becoming part of the web platform.
Please do let us know which features of XUL and XBL1 that you think are
good and that you'd like to see added to the web platform. We'd love to
work on getting the appropriate features added to HTML/CSS/etc and make
them available in all browsers! You can let us know in this newsgroup,
contact me through email, or contact the W3C or WhatWG standards
organizations directly.
Short FAQ:
Q: Holy macaroni! But my website uses it!
A: That's technically not a question. But ok. Ideally we encourage you
to use cross-browser technologies. However if you don't have the time,
or for any other reason don't want to stop using XUL and XBL1, we will
allow XUL and XBL1 to be enabled on a website-per-website basis.
Q: But I'm using XUL/XBL1 in my extension/XULRunner application.
A: This change does not affect extensions or XULRunner in any way! You
can still use XUL and XBL1 there the way you always have. If you are
loading XUL pages using file:, you might need to set a preference as
documented here:
https://developer.mozilla.org/en/Using_Remote_XUL
Q: How do I enable XUL/XBL1 for my website?
A: Jorge Villalobos has come through and developed an excellent
extension which makes this a breeze. It's available here:
https://addons.mozilla.org/en-US/firefox/addon/235281/
Q: What should I use instead of XUL?
A: If you can, use HTML5. You can still use "display: -moz-box" in CSS
if you need the XUL box model. However note that "display: -moz-box" is
still mozilla-only (hence the -moz- prefix) and hasn't been standardized
yet. But work is in progress within the CSS WG to standardize these!
Q: What should I use instead of XBL1?
A: There isn't any great replacements yet unfortunately. We recommend
using widget js-libraries and CSS.
Q: What exactly is disabled?
A: You will no longer be able to create elements in the XUL namespace.
You will also not be able to use the -moz-binding property (other than
in UA stylesheets). We might disable "display: -moz-deck" and "display:
-moz-popup". However all other XUL related display types, like -moz-box
and -moz-grid, will continue to work. The details around this might
still change a bit over time, watch this space for fruther updates.
Q: Why can't I create elements in the XUL namespace?
A: It would create significant complexities in our codebase to allow
this. The problem is that a lot of the XUL implementation lives outside
the XUL element class itself. Most of this code today checks if an
element is a XUL element by checking the namespace. All this code would
have to check if the element is a "real" XUL element, or just a normal
element with a XUL namespace. There are literally over a hundred such
locations today, and more are added all the time. We'd be sure to miss a
place or two which would introduce exactly the type of security bugs
we're trying to remove by disabling XUL/XBL.
We recommend that you instead use another namespace and use the same
fallback shim for Firefox as for other browsers.
Q: I'm using a XBL1/XUL to get an ellipsis effect in Firefox, what
should I do now?
A: We recommend using this jQuery plugin:
http://devongovett.wordpress.com/2009/04/06/text-overflow-ellipsis-for-firefox-via-jquery/
Q: When is this taking effect?
A: In Firefox 4. XUL and XBL1 will continue to work in releases up to
and including Firefox 3.6.x. Firefox 4 betas already have these changes
enabled (with exception of the -moz-deck and -moz-popup disabling).
We fully realize that this will be a big hassle for some of you, and we
don't take that lightly. We believe that ultimately this is the right
move for the web as it protects our users and allows us to focus on
HTML, CSS and other cross browser technologies. If there is any way we
can help you with this change please let us know. Please do feel free to
ask questions here or contact me directly through email.
Best Regards,
Jonas Sicking
IMHO, it would be really helpful to have HTML overlays in a similar
manner to XUL overlays, but as an actual cross-browser standard.
I could envision this feature resulting in almost a revolution of
website building once enough browsers can do it.
I think glazou once made a JS-scripted variant of that, so I'm surely
not the first to have that idea. ;-)
I think this might be an interesting thing to propose and/or flesh out
in the respective standards groups.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
There are several js frameworks that implement XBL like widgets. Every
now and then someone comes around and reinvents the wheel. One problem
with these is that the XBL shadow tree isn't anonymous. So yeah
implementing this in browser core code is the way to go.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Erm, why are you talking of XBL here when I was talking of overlays? Do
you see those as being the same? They look like two different things to me.