XML rendering

[Zack Rusin]

Ave,

with the coming xpath and hopefully xslt, i've been looking into 
improving rendering of XML documents without stylesheets. 

Currently it's of course raw text nodes - which is also known in the 
rusin household as "this sucks" (i haven't patented this term, feel 
free to use it among yourself).

I've been experimenting with different ways of fixing that (read as: 
making khtml crash more than test dummies on Volkswagen tests) and 
essentially we have the following options:
1) Create a bogus render tree. 
	XMLTokenizer gets a new class, lets call it XMLRenderBuilder if a 
document doesn't have a stylesheet (either pending or loaded) new nodes 
are added to the XMLRenderBuilder. XMLRenderBuilder creates our Render* 
objects that match whatever look we're aiming for.

Pros:
 	- Not that hard to implement. 
	- Trivial for drawing opening tags and text nodes. 

Cons: 
	- Selection is all messed. Because Render* objects which represent 
closing tags hold the same DOM tree nodes as the Render* objects 
rendering the opening tags we get mutliple problems with duplicate 
nodes in the tree. 
	- Pretty hard to decently represent closing tags in a manner that makes 
sense. We need new anonymous RenderBlock's with RenderText's that have 
duplicate nodes.

2) Start differenting in khtml on the Document DOM and the rendering 
DOM. 
	We'd have two DOM::Document's, one with the DOM tree as parsed by our 
parser and second as created from the parsed tree to display it. 

Pros:
	- Clear seperation of what we display from what we operate on.
	- hacks to render closing nodes no longer necessary. We can keep a 
stylesheet that defines how to render raw XML in a seperate file.

<notice the seperation of this item, which implies that I like this item 
and think it's vougly important>
	- Would be pretty darn cool to have that seperation as means of 
providing hooks for outside libraries. e.g. lets say we parse math ml 
document, we parse it to the DOM, then we query to see whether we know 
what can handle the specific xml namespace. Lets say we find it, we 
pass the original tree to that library and let it render whatever it 
wants. This would of course committment to BC in the rendering lib, 
since our pluggable libs would have to inherit some Render* class, but 
just think how cool would that be. Having outside Render* objects to 
render mathml, xslt, svg. 

Cons:
	- initial phase might be tricky (meaning having two dom documents). but 
granted that in most case (e.g. html) they would be the same i think we 
(i?) could finish it in the same amount of time.
	
3) Beats me, but maybe someone else has an idea.

So, yeah, I'd appreciate if you guys could do some brainstorming as I'm 
sure I haven't thought about a lot of things. Like for example I 
completely neglected supermodels in this discussion which as we know 
are essential to create great browsers. 


Zack

-- 
People are more violently opposed to fur than leather because
its easier to harass rich women than motorcycle gangs.