I want this yesterday. Been working on writing my own custom browser UI in a multitude of different platforms (WPF / XUL / Flex / etc. / etc.) but they were all either buggy or didn't come full featured from the start. All I really want to mess with is the UI, not the behind the scenes stuff, so this seems to be exactly what I'm looking for.

It doesn't seem like you'll be able to embed XUL elements with this form of customization. Does it mean you'll have to implement your own tree control, toolbar control, etc [1]?

Also, will this work with existing browser plugins? If users are unable to use their plugins, would they actually switch to use a customized browser with no plugin support?

Is this project intended to let developers create installable web apps (like Google Chrome's installable web apps with the manifest's "container" field set to "panel" [2])? If so, probably it'll better to just market it like so. I think people are far more interested in building monetizable web applications than customized browser layouts.

[1] XUL elements: https://developer.mozilla.org/en/XUL_Reference

[2] Chrome Web App's "panel" option: http://chromestory.com/2010/07/panel-tab-and-window-styles-c...

This is awesome. I love JavaScript and all the goodness it offers and this is one more reason to love it even more because now I can pile all my greasemonkey scripts into the UI.

This doesn't look like much now, but neither did Cello or Mosaic at first. My gut says this will be red hot.

Love it. This is the kind of open UX approach I wish more platforms had!

I'm not sure I understand the implications of this. Can it make Vimperator better? Or is it aiming at creating lots of little Vimperators i.e. various, less ambitious browser UIs?

Microsoft has exposed the webbrowser control in "classic" VB and .Net applications for some time now. Before Firefox gained traction, there were several "lightweight" web browsers that took advantage of this (early versions of Maxthon come to mind).

I've actually done this for an app at a previous company. We implemented a "CSR view" on top of the existing website so the CSR could look at the customer site right from within the app.

I understand why they've called it Chromeless, but I feel the name is jarringly similar to Google Chrome and that is a problem.

I would imagine the naming implications was given very definite thought...

Mozilla has used the term "chrome" to refer to their browser UI for many years; before Google Chrome even existed.

Once you understand what "chrome" is in this context, I don't see how it could "jar" you or possibly be considered a problem.

Is this essentially a JavaScript browser in a browser? When I worked at Netscape (1997), some developer developed one. No real use since you had to use a Nescape browser to run it but it was funny anyway...

Firefox is essentially a javascript browser in a browser to begin with, it's just that Firefox .js works on XUL instead of htlm5/css. The Chromeless project is just replacing the XUL chrome frontend with an html5/css frontend. It's kind of a misnomer because by their definition, Firefox already is chromeless, they're just adding a new API.

Firefoxes UI already runs on top of JavaScript afaik

Compelling. I've used several userstyles on Firefox's XUL interface before, such as coloring the progress bar and combining the stop and reload buttons. I welcome this latest increase in flexibility.

When I suggested the same idea to my VP in 2002 it created friction between us.