users@javaserverfaces-spec-public.java.net

[jsr344-experts mirror] Re: [jsr344-experts] HTML5 friendly markup (fix inconsistencies and documentation review)

From: <edward.burns_at_oracle.com>
Date: Tue, 15 Jul 2014 21:51:10 +0000 (UTC)

Yes this is a very late reply. This question was given additional
importance due to issue JAVASERVERFACES-3270.

On Tue, 18 Mar 2014 21:37:58, Leonardo Uribe wrote

LU> The first problem is the documentation and the purpose of
LU> <jsf:element ...> tag is not very clear for the reader.

[...]

LU> Take a look at what happened to min, max and value
LU> attributes. Applying the rule written in the spec, the attributes
LU> are copied to the component attribute map. According to the spec,
LU> the resulting output will be this:

LU> <meter id="meter2">350 degrees</meter>

LU> Where are the attributes? in the component attribute map like the
LU> spec says. The renderkit javadoc of javax.faces.passthrough.Element
LU> doesn't mention anything about process the attributes in attribute
LU> map. What the user expect is something like this:

LU> <meter id="meter2" min="1" max="400" value="350">350
degrees</meter>

LU> But trying the example with Mojarra 2.2.6 or earlier, it works as
LU> the user expect. How? I did a black box test and it seems the
LU> attributes are copied somehow into the passthrough attribute map,
so
LU> once the attributes are not rendered and the tag is closed, they
are
LU> rendered as passthrough attributes. It is clear the intention, so I
LU> just fixed it in MyFaces, but the problem is a behavior like that
LU> needs to be documented in TagDecorator.

To answer your question of "How?" we look at this text in the overview
section of the HTML_BASIC renderkit. [1]

  The ResponseWriter must ensure that any pass through attributes are
  rendered on the outer-most markup element for the component. If there
  is a pass through attribute with the same name as a renderer specific
  attribute, the pass through attribute takes precedence. Pass through
  attributes are rendered as if they were passed to
  ResponseWriter.writeURIAttribute().

I have created <
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1292 > to
address your concern:

LU> The first problem is the documentation and the purpose of
LU> <jsf:element ...> tag is not very clear for the reader.

I agree it's difficult to pull together the specification requirements
for all the different pieces of this feature, but it touches lots of
different layers of the specification.

LU> The second problem is related to the attributes declared for
LU> jsf:element. The taglib javadoc of jsf:element has these
LU> attributes:

[...]

LU> It should be something that allows you to customize this part, but
LU> at least the following attributes should be there too:

LU> * onload (supported by <body>, <frame>, <frameset>, <iframe>,
<img>,
LU> <input type="image">, <link>, <script>, <style>)
LU> * onunload (supported by <body>, <frameset>)

LU> Theoretically it doesn't matter if all valid names for html event
LU> are part of jsf:element. I have added onload/onunload in MyFaces
LU> 2.2.2, since it is quite easy to do so and it doesn't affect
LU> anything.

I have created
<https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1293> for
this.

Ed

[1]
http://jsf.java.net/docs/2.2/renderkitdocs/HTML_BASIC/renderkit-summary
.html#general_behavior_encoding