Hello,
you could also turn off generation of component client IDs included in a
form and "hardcode" them. Change the value of the prependId attribute on
the UIForm component from the default of true to false to indicate that
the form ID should not be a prefix of the component ID. Note that this
is a feature that has been included in the JSF 1.2 release [1].
///
<h:form prependId="false">
<h:inputText id="x_name" ... />
</h:form>
...
input#x_name { /* style configuration */}
\\\
regards,
Bernhard
[1]:
http://java.sun.com/developer/technicalArticles/J2EE/jsf_12/#clientID
On 8/7/07, Bryan Basham <[EMAIL PROTECTED]> wrote:
> Thanks for the responses, Andrew and Simon.
>
> Yes, we are aware that *some* browsers are able to handle
> colon-escaped IDs, but the reality is that our product must support
> IE (6 and 7) which does not allow this. And, yes, we are also
> aware of the suggestion that you can use class-based styles rather
> than ID-based styles, but this is not an elegant solution.
>
> So, back to my original question: If we were to override the
> Renderer.convertClientId() method to replace colons with (say)
> an underscore character, would that break anything else in JSF?
> And is underscore a reasonable replacement for colon or would
> you suggest a different character?
>
> Thanks,
> Bryan
>
> Andrew Robinson wrote:
> > Actually colon's are legal in CSS, just not supported by Microsoft (go
> > figure), they just need to be escaped for the "real" browsers.
> >
> > I would suggest using style classes instead of IDs and just give
> > components unique style classes. I know it isn't the same, but it is
> > much less risky than changing the naming separator.
> >
> > Also, if you change your layout (id of a naming container), you would
> > have to change a large amount of CSS code if you were using client
> > IDs.
> >
> > Almost all components support styleClass, so that shouldn't be an issue at
> > all
> >
> > -Andrew
> >
> > On 8/7/07, Bryan Basham <[EMAIL PROTECTED]> wrote:
> >
> >> Hello,
> >>
> >> There is a well-known problem with JSF's choice of using a colon
> >> as the NAMING_SEPARATOR character: The CSS standard does
> >> not work well with HTML IDs that include a colon in the name.
> >> So for example, if you try to style a specific input element...
> >> <h:form id='x'>
> >> <h:inputText id='name' ... />
> >> </h:form>
> >>
> >> ...with a CSS file entry...
> >> input#x:name { /* style configuration */}
> >>
> >> This is illegal in CSS. As I said, this is well known. Here are a few
> >> links that a co-worker discovered in his investigation:
> >>
> >> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=161
> >> http://www.nabble.com/Colons-in-component-ids-tf1476983.html#a4015739
> >> http://wiki.apache.org/myfaces/css_component_ids
> >>
> >> My team is investigating a work-around for this. I read through
> >> the UIComponentBase.getClientId() code and it is clear that we
> >> cannot alter the NAMING_SEPARATOR character. However,
> >> I did notice the component's renderer is given the opportunity to
> >> convert the name before it is stored (and returned from the getClientId
> >> method). The base Renderer.convertClientId method simply returns
> >> the passed in string; no conversion.
> >>
> >> Has anyone tried to override this convertClientId method to change the
> >> colon to some other, CSS-compatible character? If so, which character
> >> did you use to replace the colon? And did this conversion cause other
> >> problems within the JSF framework itself?
> >>
> >> The PROs are clear: enables component-specific styling. The CONs are
> >> not so obvious, but the biggest "gotcha" I have found is that if you use
> >> standard JSF components, you must override their renderers to support
> >> the conversion. Can anyone think of other gotchas?
> >>
> >> Regards,
> >> Bryan
> >>
> >>
> >>
>
