[10:46:24] <shaver> it would be a week's work, tops, to make mathML and SVG pluggable, I think [10:46:37] <shaver> (transformiix already is, I think) [10:47:06] <shaver> hyatt, waterson, brendan, blizzard, me -- we all know how to do it [10:47:10] <shaver> it's not rocket science [10:47:19] <dawn> i thought the layout engine needed redesigning to allow plugability [10:47:30] <shaver> depends how loose you want the coupling [10:47:49] <shaver> there would still be some binary dependencies [10:48:04] <shaver> (on a common library, which contained the base frame stuff)[10:48:25] <shaver> but it would mean that people would at least have the _choice_ to build plugins that might break with the next release [10:48:46] <shaver> and we could build and ship svg.xpi, mathml.xpi, etc. [10:48:56] <shaver> (which would be guaranteed to match, binary-wise0 [10:49:50] <dawn> that would be a lot better than building xpi's that completely replace the layout libs [10:50:09] <shaver> yes [10:50:15] <shaver> because we could mix and match [10:50:28] <shaver> I should write up a bug, with our combined knowledge of how to attack the problem [10:50:31] <dawn> combining mathml and svg would rock so much [10:52:21] <shaver> dawn: could you file a bug, against me, cc:ing hyatt and waterson and brendan and blizzard? [10:52:41] <shaver> "Layout should permit pluggable support for new frame/content types" [10:52:56] <shaver> mention that I should dump my brain there [10:53:41] <dawn> shaver: if you dump your brain there can i copy and sell it? [10:54:09] <shaver> dawn: we'll need to figure out the royalty terms, but I'm a reasonable man

So here's how I'd do it: - Move all the core frame and content stuff into libgeckobase.so, which would be a library and not a component (like libxpcom). We could even move all of the current non-XUL/MathML/SVG/XBL stuff into the library, since we're not doing this to reduce binary dependence. - Teach nsCSSFrameConstructor to dispatch to a frame factory based on the namespace of the element - Make frame factories for XUL, HTML (a thin layer around the library), XBL, SVG, etc. that register in the frame-factory category for their namespaces This wouldn't really reduce binary dependencies at all -- if someone makes a change to nsFrame, the previous day's XUL plugin will crash all over -- but it would at least allow us to be modular. And if someone wanted to trade space for binary independence, they could pull all the frame goop into libxulbulletproof.so.

Adjusting summary. Layout does permit support for pluggable content types.

adding helpwanted keyword

Adding that this bug blocks bug 33339 - HTML <RUBY> support

We all know what a joke it is, but I'll accept this to keep terry's bot from spamming me.

Who's a lazy quitter? _I_'m a lazy quitter. (We all knew that waterson was going to end up doing the heavy lifting here, didn't we?)

See also bug 51684

Who am I kidding.

Build reassigning Buster's bugs to Marc.

Pluggable frame/content types are important for using the Mozilla architecture in independent projects. Thus one could write new objects for custom functionality, and wrap them in XUL for the UI. I am fairly new to the project, but I would be willing to code some of this, given the proper guidance. What do you think of having namespaces register some sort of nsIFrameFactory, just as we currently have nsIElementFactory? I think this should have 'embed' keyword, but I don't have privs for that.

This came up again in bug 184746

Now formats like XForms can be implemented as extension, what is the status of this bug?

I don't think this bug is relevant anymore. It seems the project has moved in the opposite direction by making most features non-optional. Removing --disable-mathml in bug 660762 as an example.