But I have had cases where browsers (yes, IE) wouldn't accept a
hierarchical style not using style-id's. I'd have to dig deep to find
an example, but there were some. Additionally, it is against the
semantics to always use style-classes. Why would id selectors have
been invented if not for the case of styling exactly one element on
the page?
regards,
Martin
On 8/7/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
>
>
> 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.
>
> I have to disagree with that. imho, CSS file including an element id is
> worst than style classes.
>
> > 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
> > >>
> > >>
> > >>
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
