On Fri, 27 Jan 2006, Henri Sivonen wrote:
> >
> > That wouldn't work. You can't know whether something is well-formed or
> > not til you get to the end of it.
>
> I was not suggesting anything that needs observation to the end of the
> document. The whole point was that decisions could be made on a per
> parse event basis using the current parse event and two stacks.
In that case I don't understand your proposal.
We need something that, given this:
<em><p>X
...results in this DOM:
BODY
EM
P
...and given this:
<em><p>X</em></p>
...results in this DOM:
BODY
EM
P
EM
Given that "X" can be arbitrarily long, how do you generate the above DOMs
using your system without sacrificing incremental rendering?
I understood your system to be:
[TOKENISER] --> [PREPROCESSOR] --> [PARSER]
...where the preprocessor rearranges tokens, and the parser creates the
DOM. How does your system handle the cases above without blocking in the
preprocessor stage to wait for the end of X?
> Actually, I think what you have in the spec now is very similar to what
> I suggesting except I described the algorithm in terms of SAX events
> before the tree construction and not in terms of DOM nodes.
I don't see how we can't do it in terms of DOM nodes, since we have to be
creating the DOM incrementally.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
