[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] Re: Using KDOM in Quanta
From:       Paulo Moura Guedes <moura () kdewebdev ! org>
Date:       2005-06-07 4:04:49
Message-ID: 200506070504.49305.moura () kdewebdev ! org
[Download RAW message or body]

On Tuesday 07 June 2005 04:08, Jens Herden wrote:
> > > > > And VPL should also display a broken page.
> > > >
> > > > It already does, because it's rendered by KHTML.
> > >
> > > So are we talking about the future or about what we have now? We came
> > > to the point where we agreed about having only _one_ tree is the way to
> > > go. Where is KHTML then?
> >
> > I don't understand the question. Are you suggesting we should change our
> > rendering engine?
>
> I think so, yes, if we change to the new KDOM and we want to have only one
> tree we have to use the upcoming KHTML2, right?

Yes, but I don't see how KHTML2 is different from KHTML in this matter. Do you 
mean that, as we build a correct node tree from a bad doc it will display 
good? I don't know exactly why but this is not how it work right now...

> > > So I agree that reusing an existing parser can
> > > be a good choice and it is also smart to untie XML and script parsing.
> > > But detecting the script areas when you are parsing XML is also smart
> > > because it prevents another parsing just for area detection.
> >
> > But you don't parse the script areas in detail twice so I doubt it would
> > turn out to be a performance bottleneck. We could also have a lazy
> > approach for parsing XML. IMHO this performance issues are premature and
> > we should focus on choosing the right way of doing things.
>
> Yes, performance is important here and for me the right way is the fast way
> here. Because of this I want the first parse do the XML parsing and the
> detection of the special areas. Later we only parse the already detected
> areas instead of the whole document.

That was my first thought. Even KDOM backend parser are aware of the script 
nodes so it would be a question of processing them later.
Do you already have an opinion if we should reuse some existing parser for 
HTML/XML?

-- 
Paulo Moura Guedes

http://caixamagica.org
http://kdewebdev.org
_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel
[prev in list] [next in list] [prev in thread] [next in thread]