forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diwaker Gupta <>
Subject view/viewHelper XHTML code generation
Date Mon, 02 May 2005 05:51:19 GMT
Hi everyone,

There are a number of small but important problems with the
view/viewHelper XHTML code generation. Actually, my guess is that this
is not really a problem of the plugin, since I believe the contract
definition delegates the actual XHTML generation to Cocoon?

Anyways, basically I took one of the generated pages and ran it
through W3's validator. Here are some of the major problems, and each
one of them should be easily fixable. I'm happy to prepare a patch,
only that I'm not very familiar with the code that does XHTML
generation. So if someone can point me to it, I'll be glad to help.

o generated XHTML starts with an <?xml tag. I'm not sure thats the
expected behavior. IIRC documents should start with the DOCTYPE tag.
In the current setup, the validator returns a "DTD did not contain
element declaration for document type name" error

o Then the root element of the XHTML seems to be a <xhtml> tag. There
is NO such tag. Documents *must* have <html> as the root element.
There are no attributes such as xmlns:forrest and xmlns:xi either. Why
do we need them in the generated XHTML anyways?

o Many of the "<a name='xxx'>" type tags generated (eg: for section
headings) contain invalid characters. At some places spaces have been
converted to "%". At other places, a long title has been shorted to 2
words joined together by a "+" sign to generate the value of the
'name' attribute -- again, XHTML strict does not allow '+' sign in
this context. Why go through all this trouble for character
substitution? Just use spaces :)

o The feedback contract generates a div tag with an attribute
xmlns:jx, which is again invalid. Why is this needed?

Finally, validation will go a lot smoother if we just use XHTML
transitional instead of XHTML strict for now. Once we validate
transitional, we can push for strict. Though I'm all for aiming for
strict from the beginning!

Diwaker Gupta

View raw message