For example
<div><div>Some Header</div>
<ul>
<li><h:outputText value="list item 1">
</h:outputText></li><li><h:outputText value="list item 2">
</h:outputText></li></ul>
will actually render as
list item 1list item 2
Some Header
<ul><li>
</li><li>
</li></ul>
Alright now the problem is that the HTML is written out right away and the JSF components are rendered at a different time.
Another situation is when you have HTML before or after a JSF Component.
<h:panelGroup>
<p>some markup</p>
<h:outputText value="some text"/>
<p>some more markup</p>
</h:panelGroup>
will render as
some text
some markup
some more markup
Now if you ask me since the default view is JSP for JSF they should have taken this into account.
They should key off the include of JSF tags in a page to parse the JSP differently.
Instead of rendering it like they do they should gather the HTML and attach it to the view in a verbatim component or some other kind of ui output component in the appropriate place in the JSF component tree. This should be possible because everything should be enclosed in a <f:view> tag.
Either that or you have the custom jsf tags be body aware which I assume they are and output the html prior to rendering their component/child component and then render html after the component.
I'm not sure which way is best or where this would take place but it seems very doable.
Now some people say Facelets is the answer and dump JSP all together.
I agree this is a way to fix it but this doesn't let you reuse any JSP tags that are non-JSF.
In the real world there are lots of JSP tags that are not JSF that still need to be reusable.
Also there was a reason for JSP pages in the first place and I'm not sure facelets fully fills that gap.
The real answer should be to fix JSP complation, JSP Rendering, or JSF tags where ever this should take place.
Whoever was responsible for the JSF spec should have seen to this in the first 1.0 release.
