How to Use Jsf+Facelets With HTML 4/5

Is it possible to use JSF+Facelets with HTML 4/5?

Since Facelets is a XML based view technology which eats and emits in essence XML markup, you cannot use it with a HTML4 doctype. The HTML4 doctype describes several elements which cannot be self-closing, like <link>, <meta>, <br> and <hr>. However, with XML you're forced to close them like <link/>, <meta/>, etc. So using a HTML4 doctype is absolutely not an option for Facelets (that is, when you respect the standards and/or fear the w3 validator, it will however work perfectly on the most if not all webbrowsers).

HTML5, on the other hand, allows XML markup. This is specified in chapter 3.2.2 - Elements:

Example:
<link type="text/css" href="style.css"/>
Authors may optionally choose to use this same syntax for void elements in the HTML syntax as well. Some authors also choose to include whitespace before the slash, however this is not necessary. (Using whitespace in that fashion is a convention inherited from the compatibility guidelines in XHTML 1.0, Appendix C.)

I myself use <!DOCTYPE html> all the way, also with JSF/Facelets, even without a <?xml?> declaration in top of the page. It works perfectly in all browsers. With a XHTML doctype you should as per the specification be using a Content-Type of application/xhtml+xml which would only make MSIE to choke (it doesn't understand it). And since that's still one of the most widely used browsers... Replacing the XHTML content type by text/html is considered harmful, you also don't want to do this.

As per your arguments:

HTML 5 do not support namespaces.

This doesn't matter. The namespaces are only of interest for the XML based server side view technology (like as Facelets) which in turn can generate pure HTML with those tags. The following example is legitimately valid for Facelets:

<!DOCTYPE html>
<html lang="en"
    xmlns:f="http://xmlns.jcp.org/jsf/core" 
    xmlns:h="http://xmlns.jcp.org/jsf/html">
    <h:head>
        <title>Title</title>
    </h:head>
    <h:body>
        <h:outputText value="#{bean.text}" />
    </h:body>
</html>

This renders legitimately valid HTML5 (for the client side):

<!DOCTYPE html>
<html lang="en">
    <head>
        <title>Title</title>
    </head>
    <body>
        Some text
    </body>
</html>

You see, Facelets already removes the XHTML declarations since they have no meaning in the client side.

And,

Also HTML 5 has some new elements that are not available in XHTML

this make also no sense. It's all about the generated output. Which can be HTML5 as good. Your only problem may be the browser support and the availability of 3rd party JSF components which renders HTML5 specific elements. Since JSF 2.2, it's possible to use the new passthrough elements feature to turn custom elements into a JSF component. Simply give the HTML5 element a jsf:id attribute. It'll transparently internally be interpreted as a UIPanel instance in the JSF component tree (like <h:panelGroup>).

<!DOCTYPE html>
<html lang="en"
    xmlns:jsf="http://xmlns.jcp.org/jsf"
    xmlns:f="http://xmlns.jcp.org/jsf/core" 
    xmlns:h="http://xmlns.jcp.org/jsf/html"
>
    <h:head>
        <title>Title</title>
    </h:head>
    <h:body>
        <header jsf:id="header">Header</header>
        <nav jsf:id="nav">Nav</nav>
        <main jsf:id="main">Main</main>
        <footer jsf:id="footer">Footer</footer>
    </h:body>
</html>

You can even reference it from ajax as in <f:ajax render="main">.

Actually, XHTML is overhyped. Its sole intent is to ease HTML development using XML based tools which can manipulate/transform/generate HTML pages on the server side (like as Facelets). But some starters also use it without using any XML tool and output it plain as-is, because it's "so cool" -for some unclear reason.

Don't get me wrong. XHTML is great as server side view technology. But simply not as client side markup technology. It has utterly no value at the client side.

JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?

During the JSF 1.0/1.1 ages this was indeed "not a good idea", because all the HTML was not automatically taken in the JSF component tree when using JSP as view technology. All plain HTML was eagerly by JSP rendered before the JSF component tree. E.g.

<p>Lorem ipsum <h:outputText value="#{bean.value1}"> dolor sit amet<p>
<p>Consectetur adipiscing <h:inputText value="#{bean.value2}" /> elit</p>

got rendered as

<p>Lorem ipsum dolor sit amet<p>
<p>Consectetur adipiscing elit</p>

value1
<input type="text" value="value2" />

To fix this you would need to bring <f:verbatim> in.

<f:verbatim><p>Lorem ipsum </f:verbatim><h:outputText value="#{bean.value1}"><f:verbatim> dolor sit amet<p></f:verbatim>
<f:verbatim><p>Consectetur adipiscing </f:verbatim><h:inputText value="#{bean.value2}" /><f:verbatim> elit</p></f:verbatim>

This was a real maintenance pain. This was one of the major reasons why JSF 1.0/1.1 was so hated.

Since JSF 1.2, with the new view handler, the <f:verbatim> was not necessary anymore. Developers can now breathe relieved. Moreover, the new view handler allowed JSF to use a different view technology than JSP and this way Facelets was born.

How should a !DOCTYPE section look in JSF? HTML5 or XHTML?

That's the HTML5 doctype and it should work just fine in all browsers, including IE6.

JSF is officially specified to produce XHTML 1.0 compliant markup (with here and there only a few violations in the implementations which is fixed in JSF 2.2 and/or are manageable by context params). JSF can by design not produce non-XML sytnax (e.g. <br> instead of <br/>) and therefore the old HTML4 doctype is in no way compatible with JSF-produced HTML output (that is, when you respect the standards and/or fear the W3 validator; however, most if not all browsers are very forgiving on it). In contrary to the old HTML4 doctype, the HTML5 doctype allows XML syntax and is therefore compatible with XHTML doctypes. JSF pages can therefore be authored with HTML5 doctype.

The doctype is only of importance for how the webbrowser interprets and presents the HTML markup (as produced by JSF in your specific case, but the HTML does not necessarily need to be produced by JSF and thus browser's presentation is technically completely unrelated to JSF). Escpecially Microsoft IE has a major problem with certain doctypes or a complete lack of doctype. At the bottom of this page you can find a concise overview of browser behaviour in combination with certain doctypes. There are three standard behaviours:

Q - Quirksmode. You really don't want to have that. It triggers box model bug in IE. The CSS width and height then incorrectly covers the padding and border.
A - Almost standards mode. Affordable, only vertical sizing of table cells is not as per CSS2 spec. Useful if you want to avoid mysterious gaps of images in table cells.
S - Standards mode. Browser tries to be fully w3 HTML/CSS standard compliant. Preferred mode since it's the only mode you can be less or more certain that your website will look exactly the same in all browsers.

In your particular case, with the change from XHTML 1.0 transitional doctype to HTML5 doctype, Firefox, Chrome, Safari and IE>=8 will go from "A" to "S". So, you should definitely review the browser's presentation of your website as to padding of images in table cells if you intend a pixel-perfect design.

As to the importance of the doctype in IE, here's a piece of HTML which demonstrates the box model bug triggered by "Q" in IE6-9 (note that this does not manifest in IE10 anymore):

<!DOCTYPE html>
<html lang="en">
    <head>
        <title>Remove DOCTYPE to trigger quirksmode</title>
        <style>
            #box { 
                background: yellow; 
                width: 100px;
                padding: 20px; 
                border: 20px solid black; 
                margin: 20px;
            }
        </style>
    </head>
    <body>
        <div id="box">box</div>
    </body>
</html>

Copy'n'paste'n'run it. With <!DOCTYPE html> present, you'll see a rectangle. Without the doctype line you'll see a genuine square (in IE10 you need in the webdeveloper toolset (press F12) to change the "Browser mode" to e.g. IE9 in order to see it).

Sample Image

JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used

It seems that you misunderstood the purpose of XHTML like as many people during the XHTML overhype a couple of years ago. Long story short: check our XHTML wiki page. Carefully read it. In a nutshell, Facelets absolutely doesn't care about the doctype being used in the generated HTML output. You can perfectly fine declare a HTML5 doctype in a Facelets template.

It's indeed unfortunate that Netbeans by default prepares the document with XHTML doctype while HTML5 is these days the recommended doctype. I don't do Netbeans, but in Eclipse you can easily edit those templates and even create your own. You can just replace the whole XHTML doctype by a HTML5 one. You can find/create those templates via Web » HTML Files » Editor » Templates in IDE prefs.

Please note that the HTML5 support in JSF 2.2 has got nothing to do with being able to support specifically the HTML5 doctype. On the contrary, this is supported on all JSF versions, even when legacy JSP is being used. JSP and Facelets are view technologies which allows you to generate HTML output, which can perfectly fine be HTML5 as good. This is also elaborated in the following closely related answer: Is it possible to use JSF+Facelets with HTML 4/5?

Instead, the HTML5 support in JSF 2.2 covers the possibility to define custom JSF component attributes and turning custom HTML elements into JSF components. This was not possible in JSF 2.1 and before. Any custom JSF component attributes (including the HTML5-recommended data-xxx attributes) were simply ignored by the default JSF renderers. See also the following related answer: Custom HTML tag attributes are not rendered by JSF. In JSF 2.2 you can easily specify custom attributes by the new http://xmlns.jcp.org/jsf/passthrough namespace as follows:

<html ... xmlns:a="http://xmlns.jcp.org/jsf/passthrough">
...
<h:inputText ... a:autocorrect="off" />

This will end up in the by <h:inputText> unsupported attribute autocorrect to actually be included in the generated HTML output. Note that I use a XML namespace prefix of a ("attribute") instead of p as shown in the Java EE tutorial, as it would otherwise clash with default XML namespace prefix p of PrimeFaces.

Turning custom HTML elements (including HTML5 elements) into JSF components is a matter of specifying a jsf attribute such as jsf:id.

<html ... xmlns:jsf="http://xmlns.jcp.org/jsf">
...
<header jsf:id="header">...</header>
<main jsf:id="main">...</main>
<footer jsf:id="footer">...</footer>

Those will under the covers be turned into UIPanel (like as <h:panelGroup>). And yes, they are referencable in e.g. <f:ajax render>.

In other words, "HTML5 support" is just again another buzzword for "Custom attribute support".

JSF Facelets how to include external html?

The Facelets <ui:include> tag is the wrong tool for the purpose of embedding external resources in a HTML document.

Use the HTML <iframe> element instead.

<iframe src="http://mycompany.com/banner.html"></iframe>

JSF HTML5 tag tutorials / guides?

I'll bet that you're talking about this article. The h5 taglib just points to composite components which wraps some HTML5 specific elements. Composite components are just Facelet files which can be declared and used as a single JSF component in other pages. Even more, the full source code is posted in public in chapter "A JSF 2 HTML5 canvas component" of the article. You just have to copypaste it into your project to get it to run. It's not some component library like RichFaces/PrimeFaces or whatever which you have to download, install and configure first.

JSF doesn't care if the output is XHTML or HTML5. Both are equally valid as long as you adhere the XML syntax (i.e. the document must always be well-formed). You can perfectly inline HTML5 specific tags in JSF pages/components. Your only concern is the browser support.

If your concrete problem is more the lack in understanding of the purpose of composite components and how they work, then I'd suggest to get yourself through the appropriate sections of the Java EE 6 tutorial.

Java EE 6 tutorial - Chapter 5 - Facelets - Composite Components
Java EE 6 tutorial - Chapter 13 - Advanced Composite Components

JSF 2 with HTML pages instead of XHTML

However, if I change this to *.html and naming the files with a .html extension, I get 500 an error

Did you mean that you renamed the physical .xhtml files to .html? You should not have the need to do that. Rename them back to .xhtml and keep using the .html in URLs. The FacesServlet will automatically load the right XHTML file associated with the URL.

If you really need to give them the .html extension, then you'd need to change the default suffix to .html as well. Add the following entry to web.xml to achieve that:

<context-param>
    <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
    <param-value>.html</param-value>
</context-param>

How to Use Jsf+Facelets With HTML 4/5

Is it possible to use JSF+Facelets with HTML 4/5?

See also:

JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?

See also:

How should a !DOCTYPE section look in JSF? HTML5 or XHTML?

See also:

JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used

JSF Facelets how to include external html?

JSF HTML5 tag tutorials / guides?

See also:

JSF 2 with HTML pages instead of XHTML

See also:

Related Topics

Leave a reply