You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Diwaker Gupta <di...@gmail.com> on 2005/05/02 07:51:19 UTC
view/viewHelper XHTML code generation
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!
cheers,
Diwaker
--
Diwaker Gupta
http://resolute.ucsd.edu/diwaker
Re: view/viewHelper XHTML code generation
Posted by Ross Gardler <rg...@apache.org>.
Diwaker Gupta wrote:
> 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
XHTML is XML and therefore must start with the XML processig instruction.
> 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.
That is an error.
> There are no attributes such as xmlns:forrest and xmlns:xi either. Why
> do we need them in the generated XHTML anyways?
These are left in as a result of previous transformations. The xmlns:xi
is from the xinclude transformer.
> 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 "%".
Are you sure it's not %20, which is correct.
> 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.
Really, well if it's not allowed then we need to escape it or use
another symbol.
> Why go through all this trouble for character
> substitution? Just use spaces :)
Because id attriburtes cannot have spaces in them.
> o The feedback contract generates a div tag with an attribute
> xmlns:jx, which is again invalid. Why is this needed?
This appears to be coming from the files in view:
$ find . -name "*.xml" -exec grep -H xmlns:jx {} \;
./whiteboard/plugins/org.apache.forrest.plugin.internal.view/src/documentation/c
ontent/xdocs/howItWork.xml:
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
> 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!
We say we are an XML standards project, I'd prefer to go for strict from
the outset. There is a tendency to be happy with passed tests regardless
of which are being passed.
Having said that, I'm not the one doing this work, so I won't stand in
your way :-))
Ross
Re: view/viewHelper XHTML code generation
Posted by Diwaker Gupta <di...@gmail.com>.
> > 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 :)
> >
>
> That is an old problem that we need to fix as well in views.
I think this is a fairly major problem. For instance, the Gecko
rendering engine doesn't parse the currently generated XHTML (with the
above mentioned illegal characters in the <a> tag), which in turn
affects the CSS rendering.
--
Diwaker Gupta
http://resolute.ucsd.edu/diwaker
Re: view/viewHelper XHTML code generation
Posted by Thorsten Scherler <th...@apache.org>.
Just a quick reply because I am just coming from the beach and have to
tranquilize my sunburn ASAP. ;-)
All questions already answered by Ross I will not answer. ;-)
On Sun, 2005-05-01 at 22:51 -0700, Diwaker Gupta wrote:
> 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.
>
:)
It is mainly produced in the contracts which resides in
{viewHelper}/templates.
> 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?
>
I will fix that after the sunburn. ;-)
> 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 :)
>
That is an old problem that we need to fix as well in views.
> o The feedback contract generates a div tag with an attribute
> xmlns:jx, which is again invalid. Why is this needed?
>
This is from an old experiment of mine.
...anyway namespaces *are allowed* in xhtml.
http://www.w3.org/TR/xhtml1/#well-formed
> 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!
>
:) I will help you with the patch and if you want to start with
transitional that is fine with me (we just have to try going for strict
before 0.8 gets out).
> cheers,
> Diwaker
Thanks for your work.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)