On 22.05.2012, at 23:29, Brian Leathem <bleathem_at_gmail.com> wrote:
> On 12-05-22 01:39 PM, Frank Caputo wrote:
>> Hi EG,
>>
>> I had similar thoughts about HTML5.
>>
>> HTML5 is DTD-less and supposed to change quickly. To allow this agility, we should have 2 things:
>>
>> 1) render through unknown attributes
>
> Agreed! This would by far provide the simplest markup, with the easiest "buy-in" from those developers familiar with HTML 5. Give it a few more years, and this means everyone.
>
>> 2) have a generic dynamic element
>>
>> Explanation:
>>
>> 1) All attributes not handled by a component should be simply rendered out as they are. Eg. h:inputText doesn't know the attribute placeholder.
>>
>> <h:inputText value="#{foo.bar}" placeholder="foo"/> would be rendered as <input type="text" value="" placeholder="foo"/>
>>
>> This way new attributes in HTML5 are no longer a problem (this would also be fine for all those data-xxx attributes ;-))
>>
>> If the value of an unknown attribute is null or "", don't render it.
>>
>> Maybe we could override attributes. Eg. h:inputText doesn't have the attribute type, but the renderer renders it.
>>
>> <h:inputText value="#{foo.bar}" type="email"/> would be rendered as <input type="email" value=""/> because the unknown attribute overrides it.
>>
>> The type attribute is just a hint for the client (eg. to change the keyboard layout) while it doesn't change anything on the server.
>>
>> UIComponentBase should provide a Map of all unknown attributes to the renderer.
>
> The problem with this being that facelet files are not DTD-less (shema-less), and so this would be a more complex solution. IMO however, it would be an effort worth pursuing, as the arbitrary attribute support would be intrinsic to JSF, and not "bolted on".
But the schema for facelets is just for documentation and to help tooling, right?
Anyway if this is a problem, we could limit this to the jsfc syntax, because it is preferred by HTML developers and modern IDEs support it well.
>
>> 2) A UIComponent which could represent any HTML tag would be very helpful, eg. if one wants to render anything else but a div or span conditionally or have it in the render list of a partial response. We should add this functionality to h:panelGroup. We could either deprecate the layout attribute and add a new one for the tag name or enhance it to simply hold the tag name.
>>
>> <h:panelGroup layout="ul" type="disc" id="foo"/> would be rendered as <ul type="disc" id="foo"></ul> if we would also have 1).
>>
>> We could also enhance the facelet parser to let us have tags like <ul type="disc" id="foo" jsfc="h:panelGroup"></ul> which handles jsfc="h:panelGroup" specially and converts it to <h:panelGroup layout="ul" type="disc" id="foo"/> using the tag name for the attribute layout.
>
> An interesting suggestion, worthy of it's own issue (it if doesn't already have one.
>
>> I think, that both features provide pretty much HTML5 functionality, because most of them are client side. The only one making my head aching is the form attribute of the input elements (http://www.html5rocks.com/en/tutorials/forms/html5forms/#toc-inputs-attributes-attributes).
>>
>> Another benefit is the ability to support browser specific tags and attributes which makes sense in intranet applications.
>>
>> It would also increase the acceptance for HTML developers, who are often unhappy with not letting them do what they want when they must use JSF.
>>
>> Frank
>
> Brian
>