Re: [jsr-314-open] Wrapping Text with a tag - what's the correct behavior?

I agree that we should specify this. I should probably, at this point, mention exactly what outputText is currently doing, so we can talk about how it should act. outputText is rendered in it's entirety in the encode end section of the api. This is certainly, as Dan says, a bug. It also allows children to be rendered, provided that the wrapping outputText is rendered. I'd actually argue that we should just not allow children on outputText components. Consider this contrived example: <h:outputText value="after">Count: <h:commandButton type="button" value="button"/> </h:outputText><br/> Right now, this returns: Count:<input type="button" name="form:j_id-519344002_6caa9f6" value="button" />after<br /> Adding an id, to force the span to be rendered, gets you: Count:<input type="button" name="form:j_id-519344002_6caa9f6" value="button" /><span id="form:test">after</span><br /> Removing the value, <h:outputText id="test">Count: <h:commandButton type="button" value="button"/> </h:outputText><br/> you then get: Count:<input type="button" name="form:j_id-519344002_6caa9f6" value="button" /><span id="form:test"></span><br /> Notice that the contents of the outputText are *outside* the span. This is the original bug, and not addressed by Dan's proposal. Moving them inside the span opens up other issues, since spans aren't allowed to wrap just any old tag, there are restrictions. Should we care? So, if we're going to disallow wrapped values in some cases, I'd like to propose that we simply disallow wrapped values in all cases, turning off the ability to render children. This will break some existing code - but the odds are, it wasn't working terribly well anyway. If we instead adopt Dan's proposal, only wrapping in the case that value is unspecified, we'll *still* need to spec it that the wrapping span actually starts at encode begin, not encode end. So - which of these two options do people prefer? I'd like to change the impl *now*, and then spec the behavior in 2.1. Jim On 6/19/09 10:18 AM, Dan Allen wrote: