On Tuesday 03 June 2003 09:38, Bruno Dumon wrote:
BD> TK> We have a current problem, that cocoon is not useable in many cases,
BD> TK> because it's nearly impossible to create valid (x)html.
BD> And again I'm wondering why? Of the tree reasons given earlier:
BD> AC> 1) As a fix for the "the namespace problem"
BD> AC> 2) When human-readable HTML output is needed
BD> AC> 3) To validate the output to a dtd
BD> only number 1 really causes problems, the others are merely
BD> conveniences. Those are important too, but don't make it "impossible to
BD> create valid (x)html".
The second is helpful to debug your output and the last is helpful to ensure
you output valid code. Would be nice to ensure valid output, before sending
out code which has the w3c compliance logo. I can do all this with a script
called after cocoon (which I still have to do for non-html output). But
TidySerializer is a cleaner solution.
BD> TK> There is also HTMLGenerator using jtidy and noone says, we wait for
BD> TK> the web pages to have valid (X)HTML.
BD> While I do find this a false comparison (we don't control webpages, but
BD> we do control what we generate in our pipelines), please understand that
Both is for tweaking external problems or failures. HTMLGenerator is for
webpages which haven't xhtml, TidySerializer is for HTMLSerializer's which
don't ignore, what's not interesting for them.
BD> I'm not opposed to a tidyserializer. I'm just figuring out why I would
BD> use it.
To make it affordable to have valid html output. Problem is, you can do it
actually, but it's to much work. You have to use a xml formatter, to read the
output and see whats wrong. You have to validate the output to see if it's
valid. You have to do xalan "tricks" to remove unneeded namespaces. ...
Tidy is a temporary (I hope that xalan does the job some time, because I'd
like to have it for wml and others too) "solution" for these problems.
For me it works much better than the existing HTMLSerializer, that's why I
sent it to the BTS. When you don't have these problems so far, or have
another way or a better way to solve them, you don't need it. Indeed it's
better not to use it, as it eats performance.
Regards
Torsten
--
Domain in provider transition, hope for smoothness. Planed date is 1.7.2003.
