HTML Body in kolab.xml?

[Georg C. F. Greve]

On Tuesday 23 November 2010 11.22:56 Jeroen van Meeuwen (Kolab Systems) wrote:
> Not necessarily; Updating the HTML formatted body may not necessarily
> require the formatted body be updated in HTML... it might be updated in
> plaintext, partially negating the purpose of storing HTML in the first
> place.

But how would a client update something it cannot parse in the first place? How 
would it know what to modify, and in which way?

So it would always need to be able to parse HTML fully, and either offer 
editing in HTML, so it can then translate to plaintext to overwrite both, or 
know which part of the plain text that was edited corresponds to which part of 
the HTML and modify it accordingly. That's not so trivial.

It is not clear what the advantage would be of being able to parse HTML fully 
and have life matching of plain to HTML, but then only modify in plain text.

That's why this seemed to imply a de-facto "HTML only" policy.


> The real problem arises with non-readable content like PDF... there's no
> way  one can replace those contents with plaintext... and still have it be
> a PDF.

True. But PDFs are attachments, and those are possible in any format, 
including web pages & HTML information, and clients are free to ignore them if 
they do not understand them.

Shawn's proposal - as I understood it - was to allow HTML markup in the 
regular body fields, with all the obvious advantages that would bring. The 
question is therefore whether a way can be found to deal with the 
disadvantages it would bring.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101123/9a89ec3e/attachment.sig>