[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:       Frans Englich <frans.englich () telia ! com>
Date:       2005-06-07 11:55:20
Message-ID: 200506071155.21038.frans.englich () telia ! com
[Download RAW message or body]

On Tuesday 07 June 2005 01:56, Jens Herden wrote:
> > > Structure tree.
> >
> > I don't know if it would be bad. It would give a stronger indication to
> > the user to what he should fix.
>
> I know, this is very bad :-)
> If you have a error at the very beginning of the document the tree will be
> almost empty and useless. So I have to fix the errors top down to get a
> usefull tree? What a horror! Think about a document someone else created, I
> have to suffer because the other author did it wrong and I have to fix
> his/her error to get the structure tree?
> I hate it if a tool force me to work in a specific way and try to educate
> me to do it right. Where right means what the deleloper of the tool mean is
> right and not what I, as a user, think is right.
> To make it very clear here. This would be a radical change in Quanta's
> philosophy and if Quanta would choose to go this way I most likely will
> think about another tool that fits more to what I think is the right
> approach. I do not want to threat here if Quanta wants to go this way I am
> fine with it.

Yes, this is a crucial, central matter. Here's how I see it:

If Quanta reacts by throwing up a message box(or something in that direction) 
each time the user opens up a broken file, I would say it is counter 
productive. Quanta would be intrusive, not allowing the user to access the 
files.

Then the question is when, if at all, it is of interest to of some sort 
promote well-formed/valid formats.

I think there is an interest from many parties to encourage it; no one wants 
broken pages on the web; Quanta's features can work more stable if they 
operate on well-defined content; and many developers are standards aware(e.g, 
the W3C banners on page footers are quite popular). Hence, I think that good 
information, good docs & status indication, is of interest. E.g, not 
intrusive, but informative, and which makes errors visible.

A second question is how "active" Quanta should be in helping the user towards 
correct coding.

I think that if Quanta pretends it's ok, and allows operations which depends 
on a certain content to be performed, it is counter productive. For example, 
if VPL mode is allowed on a non-well-formed document, it tricks the user into 
thinking he/she has designed a good page(because it looks as intended), the 
problem is that it is rendered by KHTML's quirk mode, and quirk modes are all 
different among browsers. However, if it had been rendered in standards mode, 
it would have worked on all browsers.

Another example: there's an XPath implementation brewing in kdom; perhaps 
Quanta will allow expressions to be executed on a document, and if it's 
allowed on a non-wf doc, it produces unexpected, un-guessable results. That's 
frustrating for the user.

So, perhaps it could be like this, from a user perspective:

Broken document can be opened just fine(so to speak), and one gains a 
comfortable set of functionality; it is syntax highlighted, for example. The 
user is given strong feedback when something is wrong: what is wrong, where, 
and how to fix, combined with clear feedback. However, in order to use  
sophisticated automatic editing features, one must fixup the document, and 
there's clear info about how to do that.

This is in large parts usability questions -- the Open Usability people can 
perhaps be brought into the process(later).

How would this be implemented? Here's a sketch:

Quanta is asked to open a file(a text stream). It kicks in KHTML(2) which 
starts to build a KDOM tree with Quanta's builder that is a sub class of 
KHTMLDocumentBuilder and which does specialization[1]. KHTML's tokenizer 
handles this fine; it does doc-type sniffing, and enters quirk mode if 
necessary, etc.

After that, one have a KDOM tree(with KHTML's render tree attached), and a 
text stream in the editor.

Doing typing-parsing is a second topic, I'll follow up this mail.


Food for thought,

		Frans

1.
For example, it builds PHP processing instructions as suggested in the other 
mail. These are ignored by KHTML.
_______________________________________________
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]