On Sun, 21 Oct 2001, Jon Smirl wrote: > So the SVG people are just wasting their time? A full SVG implementation > (based on the size of the Adobe one) could add another megabyte each to > gkcontent and gklayout. XUL should be it's own component too. The new XPCOM > interface would allow SVG, MathML and XUL to be dynamically loaded based on > the namespace of the incoming page. > > The longer this gets deferred the worse it is going to get.
Allowing SVG and MathML to be drop-in components requires much more that just changing some interfaces. It requires redesigning the content sink and frame construction code, and probably also significant changes to the way reflow works (and probably making so many functions virtual that our speed would cut perceptibly). What's the big advantage of drop-in components anyway? What's wrong with allowing people to redistribute a new layout dll that has mathml built in? (Yes, drop-in components would be nicer, but are the worth a significant performance cost for the cost of an installation that only happens once?) That said, people are thinking about how to make layout extensible. However, the solution is not sprinkling |virtual| all over the code in the hopes that the layout engine will eventually be slow enough that it's extensible. :-) It should be neither necessary nor sufficient. -David -- L. David Baron <URL: http://www.people.fas.harvard.edu/~dbaron/ >
