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".
> 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