How to let JSF render conform XHTML 1.0 strict?

3
votes

I need to develop a web application which has to be compliant with "Stanca act" (Legge Stanca). I've used jsf2.0 (Mojarra ) + primefaces 3.2 so far but I have validation problems when I use 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

In particular for an empty form page the following generated html code:

<form id="j_idt16" name="j_idt16" method="post" action="/econsob/faces/prova_stanca.xhtml" enctype="application/x-www-form-urlencoded">
    <input type="hidden" name="j_idt16" value="j_idt16" />
    <input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="-8952155502993391596:-7459269746161777412" autocomplete="off" />
</form>

does not pass validation because:

  • attribute name in form tag is not supported by the doctype required by Stanca act
  • document type does not allow element "input" here (just below the form)
  • attribute autocomplete is not supported by the doctype

Is there a way to solve this issue? Is it possible that a jsf generated page does not validate using Strict?

1
jsfjsf-2doctypexhtml-1.0-strict

1 Answers

4
votes

The standard JSF HTML renderer is designed according XHTML 1.0 Transitional.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

You can however always use the HTML5 doctype.

<!DOCTYPE html>

It's more flexible than the XHTML 1.0 Strict doctype and still forces the browser in standards mode.

If you really intend to use XHTML 1.0 Strict, then you'd need to set the following context parameters (Mojarra only):

<context-param>
    <param-name>com.sun.faces.autoCompleteOffOnViewState</param-name>
    <param-value>false</param-value>
</context-param>
<context-param>
    <param-name>com.sun.faces.enableViewStateIdRendering</param-name>
    <param-value>false</param-value>
</context-param>

And/or to modify the renderers of the appropriate components. You'll only risk ViewExpiredExceptions whenever some overzealous browser modifies the view state value by some autocomplete means.