HTML5 support for PrimeFaces?

kiwifrog · 06 Sep 2010, 15:52

Is there any plan to implement HTML5 components?
Inputs with type = tel, email, date, time etc...

MyFaces have already started it: http://people.apache.org/~aliok/GSoC/ta ... index.html

But we would love to see it in TouchFaces and/or PrimeFaces!

christofer10169 · 22 Jul 2011, 11:05

any news about type="number" for primefaces mobile.

Thank you in advance.

22 Jul 2011, 11:08

We have HTML5 stuff although they are not advertised like myfaces, but included under the hood like;

Charts has canvas
Fileupload has xhr upload/drag drop
InputText has type option.
...

oranheim · 06 Oct 2011, 21:57

I think it would make sense to conform to the HTML5 standard. Even though PF3 make use of certain HTML5 facets, it doesn't mean it complies with HTML5.

I hope the upcoming JSF 2.2 JSR add support for dual renderkits. One for legacy and another for conforming to HTML5.

* The xmlns attribute on the html element should be removed from response

* The meta attributes should be shortened

* Script includes should support async, in which would increase performance. The browser needs to load all resources in head before its able to layout a web document

* Further reading: here's a good reference to differences between HTML4 and 5; edited by Anne van Kesteren: http://www.w3.org/TR/2011/WD-html5-diff-20110405/

ltune · 07 Oct 2011, 04:38

oranheim wrote:The browser needs to load all resources in head before its able to layout a web document/

Does it mean there would be is a problem when the widgets (like p:imageswitcher) declare their javascirpt in <body /> part?

Greets,

Adam

oranheim · 07 Oct 2011, 08:59

It means it may cause unpredicted behavior in browsers. The user-agent (FF, Opera, Chrome, Safari) etc comes in various versions ,right. Canvas is quite new, so IE7/8 wouldn't be able to support that.

A browser detects content based on two initial instructions: content-type (text/html, application/xhtml+xml) and DOCTYPE. The next thing a browser does is to find anomalies in the markup, in order to determine if the user-agent got fooled. This has an impact on the HTML-rendering engine. When the layout manager builds up your document, it will check for your mime-type.

If you provide the user-agent with XHTML, you should actually respond with application/xhtml+xml, however several user-agents would fail on that; e.g. IE. Simply because they implement HTML parsers, an HTML layout engine and an HTML execution tree. So what I'm saying here. Think of browsers are text/html compatible devices and not application/xhtml+xm compatible devices. The latter would be forced back to the first anyway; in the browser.

IMO it's a responsibility of JSF Mojarra/MyFaces and libraries such as PF to comply with browser standards and to support advertisement of correct doctype. To use application/xhtml+xml is fine on the server side. Still, you should respond with text/html. The reasoning behind this is because we use XML parsers to handle content and support AJAX. So the idea of well-formed markup is quite key here.

If you expect a user agent to treat your content right the correct content-type must be returned.

For HTML4.01 QuicksMode is set. For XHTML family user-agents switch to standards mode and for HTML5 it would also switch to standards mode.

I guess the question is. We concern ourselves with standards on the server side. Should JSF JSRs / PF care about standards for the browser side. My all means, PF is all about a delivery context of content to user-agents. Isn't it?

Btw, the term widget shouldn't be used for PF Components/Controls. A widget is better described here: http://en.wikipedia.org/wiki/Web_widget, http://www.w3.org/TR/widgets/ and http://www.wacapps.net/.

oranheim · 07 Oct 2011, 09:12

ltune wrote:
oranheim wrote:The browser needs to load all resources in head before its able to layout a web document/
Does it mean there would be is a problem when the widgets (like p:imageswitcher) declare their javascirpt in <body /> part?

Greets,

Adam

No it shouldn't be a problem if it's rendered in the body. Then the browser will load the script just in time. Scripts should preferably be put in head though, except for inline markup.

HTML5 support for PrimeFaces?

Who is online