[Manishearth]

It would certainly help us port Firefox to Servo. But that's never really been a part of the plan.

Gecko and Firefox are quite intertwined. Even if we ignore XUL/XBL, there are things like XPCOM which are still deep-rooted. While this brings us a step closer to making Servo a drop-in for Gecko, this is not a step in a direction we're particularly interested in. At least not now, not that I know of (I'm a volunteer on the Servo team, as such there may be internal plans I'm not aware of).

For Servo one potential way ahead is bringing browser.html up to Firefox's level. Not the other way around :)

[dherman]

I agree it doesn't make sense for Servo to be a drop-in replacement for Gecko, but that doesn't mean we shouldn't bend Firefox towards compatibility with Servo. A future Servo-based Firefox is far enough off that it's impossible to predict every step from here to there, but if you ask me, dcamp's email is on the right track: we should evolve Firefox away from dependence on non-standard tech like XUL, XBL, and XPCOM and towards self-hosting on standard web technology and taking full advantage of everything Servo has to offer. What that looks like in practice remains to be seen.

[fabrice_d]

I agree. A key point to achieve that is to define what the embedding api looks like. Right now on FirefoxOS it's partly the mozbrowser api for iframe-centric features, and partly custom events that are dispatched on the top level "chrome" iframe. There's still some cleanup to do there ;)

[Manishearth]

Of course. I'm just saying that from the point of view of Servo, drop-in Gecko isn't really the focus. Making Gecko more HTML-y is a great step for Gecko, but from a purely Servo point of view at the moment it's not really something tangible. Though you're right, it may mean something for Servo a couple of years from now.