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