Closed Bug 533868 Opened 15 years ago Closed 13 years ago

Investigate using XBL with HTML instead of XUL

Categories

(Core :: XBL, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: taras.mozilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ts])

Jonas says it should already be possible to make use of XBL1 to build application UI on top of HTML.

My guess is that this should startup and render faster than xul-based UIs due to the higher amount of developer attention that our html render gets.
Whiteboard: [ts]
We've actually put in a fair amount of attention into the XUL DOM in the past, and in particular into the XUL prototype setup.  HTML may or may not actually be faster.  Should measure.
OS: Linux → All
Hardware: x86 → All
Summary: Investigate using XBL with html instead of XUL → Investigate using XBL with HTML instead of XUL
(In reply to comment #1)
> We've actually put in a fair amount of attention into the XUL DOM in the past,
> and in particular into the XUL prototype setup.  HTML may or may not actually
> be faster.  Should measure.

That is the point of this bug.
Using HTML for chrome UI would use HTML Content sink and that would perhaps
lead to few unwanted behaviors, like incremental rendering or whatever it is 
called. XUL Document/Content sink waits until everything is "ready" before it
initializes presentation, so when opening a window everything is rendered in the right place when the window becomes visible (or something like that).
(In reply to comment #3)
> XUL Document/Content sink waits until everything is "ready" before it
> initializes presentation

We can get this behavior by making the root display:none and flipping that at end of document load.

> so when opening a window everything is rendered in
> the right place when the window becomes visible (or something like that).

That's orthogonal to the above; it happens just because we wait for onload to show the window.
Blocks: 447581
Whiteboard: [ts] → [ts][Snappy]
We are not pursuing this atm.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Whiteboard: [ts][Snappy] → [ts]
I think this is a great idea, we should be practicing what we preach. If HTML isn't fast enough for Firefox then we need to make it fast enough. We should re-open this and get to work.
In general, yes, we should be able to build Firefox and similar applications with HTML, with or without a component layer like XBL1, although the question of whether or not to rewrite Firefox's existing UI in HTML is more complex and would require careful analysis and investigation.

Regarding XBL1 specifically, the energy these days seems focused on Web Components:

http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
(In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> In general, yes, we should be able to build Firefox and similar applications
> with HTML, with or without a component layer like XBL1, although the
> question of whether or not to rewrite Firefox's existing UI in HTML is more
> complex and would require careful analysis and investigation.

I don't think the question of whether or not we should work towards replacing XUL with HTML in Firefox should really hinge on technical analysis and investigation. It's a question of our goals for HTML as a platform (and resources, of course). If we don't want to limit the HTML platform to apps that are less complicated than Firefox (I sure don't!) then we need to make HTML good enough for Firefox. And if HTML was good enough for Firefox, then why wouldn't we want to write it in HTML?

We need to let people build applications that are as complex as Firefox sooner or later, and sooner is better. I'm sure there are some tough problems to solve, but not succeeding shouldn't be an option. I think we should figure out what the problems are, solve them, and prove that we've solved them by converting Firefox itself. This will take a while. Lets get started.
Josh, I responded to your comment from the perspective of someone deciding how to allocate scarce resources to multiple valuable projects, which is how Taras made the decision on this bug, if I understand it correctly.

But don't get me wrong, yours is a great vision, and I encourage your pursuit of it!  It does seem broader in scope than this particular bug, though, and thus best pursued in a more general forum.
FWIW, we *are* very actively working on enhacing the web platform to be able to support applications as complex as Firefox. Note that all of FirefoxOS has been written in HTML.

However it's no small task. We have a very high bar for quality of APIs that we're adding to the web. The Web Components/XBL2 work is one of the pieces and it's been ongoing for a very long time. Likewise features like context menus, toolbars, tree views etc is work that people are looking at, but it takes a long time to get it right.

I don't think that trying to rewrite all of firefox in HTML is going to be a successful project. Changing individual parts over to HTML is much more likely to succeed.

It's unclear to me that further discussions in this bug is useful, since practically speaking I don't think there's anything that we're going to do in a bug that is as broad as this one (and that is labeled "investigate doing X").

More fruitful I think would be to get a general agreement that "it would be nice if more of Firefox was written in HTML" in the newsgroups and then start filing bugs and patches for changing individual pieces as soon as the web platform supports it.
You need to log in before you can comment on or make changes to this bug.