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

[Imre Osswald]

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.

Imre Oßwald

On 14.12.2009, at 21:26, Lincoln Baxter, III wrote:

> While I think the concept of pluggable render kits is interesting, I  
> wonder if the amount of overhead required to successfully provide a  
> new render kit for a different content type, using the same facelet  
> layout, is too high, and if anyone is actually using the  
> functionality.  Is it a feature we push that nobody is going to use?
>
> Most sites host a separate domain to handle this type of  
> accessibility case, eg: .mobi, or they just use a swappable  
> stylesheet, which is a far simpler solution.
>
> Accessibility for text to speech is already provided by HTML/CSS.
>
> I think presentation is intrinsicly coupled to the view files except  
> for trivial use cases, or extremely over-complicated architectures.
>
> Lincoln Baxter III
> http://ocpsoft.com
> http://scrumshark.com
> Keep it simple.
>
>
>> On Dec 14, 2009 1:46 PM, "Simon Lessard" <Simon_Lessard at dmr.ca>  
>> wrote:
>>
>> Well, 2 reasons:
>>
>> 1. It's along the line of Dan suggestion about Facelet and not  
>> pushing direct html to the output, a different render kit might  
>> have to intercept the ResponseWriter to tranform some of those new  
>> tags to something else. New tags allow just that, giving the  
>> opportunity to encode the view in just about anything. Maybe a PADF  
>> render kit using iText (althoguh that one could deal with the  
>> HTML), or renderer generating TeX, that in turn gets turned to PDF  
>> using some of the available engines in the endDocument call.
>>
>> 2. Most importantly, semantic and accessibility. A view remains a  
>> document and providing every basic components in the HTML kit  
>> enhance that toolbox and allows developer to add whetever they want  
>> to their view, really expressing what is ment to be there. I'm  
>> prety sure this would also come (especialy?) handy in composite  
>> componnet development. As for the accessibility part, <p> != <div> ! 
>> = <fielset>  for a screenreader or any other accessibility enabled  
>> device. As for the header, we could provide auto-depth detection if  
>> not overriden using a level/depth attribute. In pretty much all  
>> project I had to work on we had to redevelop pretty much all those  
>> components because Facelets was not an option at the time (and  
>> Facelets would have been to HTML coupled anyway).
>>
>> Regards,
>>
>> ~ Simon
>>
>> ________________________________
>>
>> From: jsr-314-open-bounces at jcp.org on behalf of Lincoln Baxter, III
>> Sent: Mon 12/14/2009 1:30 PM
>> To: jsr-314-open at jcp.org Subject: Re: [jsf2.next]  
>> WITHDRAWN Proposal to support newse...
>>
>> I'm not sure I really see the need for special tags like this. What  
>> are the advantages of turning ev...
>>
>> http://ocpsoft.com <http://ocpsoft.com/>
>> http://scrumshark.com <http://scrumshark.com/>
>> Keep it simple. On Dec 14, 2009 1:12 PM, "Dan Allen" <dan.j.allen at gmail.com 
>> > wrote: > > JD> ...
>>
>