Re: [jsr-314-open] [jsf2.next] WITHDRAWN Proposal to support newsemantic HTML5 tags

While I see the benefit of components that will provide semantical/structural information about the view, I don't think we need every HTML(5)-tag as a component but rather tags, that are able to represent the structure of a document in a more abstract way. Also I don't think renderkit authors would be thrilled to see that many new standard components they would have to support in case we add every possible HTML-tag. (But we could probably ask both ;) ) As I don't think we will be able to come up with a tagsoup that will cover 80% of the needs of users and renderkit developers, a possible way to give for example early adaptors of HTML5 a simple solution, would be to make composite-component libraries "renderkit(mode)" aware and a simple way to declare/match these modes. So a compcomp author could provide two (or more) libraries with implementations of <my:nav>, which will translate depending of the user-agent/outputtype to either <nav>, <ul class="nav"> , <pdf:toc>, ... effectively creating different view files for different presentations, agreeing on the coupling of presentation and view files with Lincoln.

>>>>> On Mon, 14 Dec 2009 13:48:18 -0500, Simon Lessard <Simon_Lessard(a)dmr.ca&gt; said: >>>>> SL> We might have agree to disagree, the "name of the tag created" does SL> make the whole difference imho, it's not just about how it look. Though I'm delighted to see all the traffic on this topic, I have to weigh in and oppose adding many more tags. The design focus of JSF views has always been to mix template text and components. In my opinion, this is widely seen as a strength for server-side UI technologies such as JSF.