Re: [Trinidad] avoiding style class aliasing

[Renzo Tomaselli]

The picture is almost clear now - although class alteration by js is exactly what I'm doing. Unfortunately it's based on element recognition by class name, which cannot work unless compression is fully disabled. I will investigate about Jeanne's trick on using multiple token selectors, looks funny. Btw, I wonder about the real optimization extents that compression is presumed to achieve, also considering that browsers do cache css. -- Renzo Simon Lessard wrote: On Nov 14, 2007 2:19 PM, Jeanne Waldman <[EMAIL PROTECTED]> wrote: The fact that it generates both compressed and uncompressed in this test case is not a bug, but as designed. Oh true, my bad, else doing some styleClass alteration at runtime using _javascript_  would become impossible since the style class wouldn't be in the final CSS. In selectors without a namespace, like af|, I output both compressed and uncompressed since these could be a user's styleclass that they are using in a way that doesn't get compressed, like through their own html tags. I don't think this is the reason for Renzo's problem, but instead it is because he wasn't turning compression off. The problem must be that he sets styleClass="invisible" and this gets compressed because the renderer calls renderStyleClass which compresses it if compression is enabled. Another workaround might be to try adding to the styleClass attribute another styleclass name that is not written in the skin css file. Then it won't compress. The reason is that when we process the skin css file, we get the selector and put it in a map of selector->compressed selector. If it isn't in the skin css file, it won't get in this map, thus it won't get compressed, even when renderStyleClass is called. This is a kludge, no doubt about it. But it will keep you from having to uncompress everything. - Jeanne Renzo Tomaselli wrote: > Thanks, Simon. Disabling compression makes things working like they did > previously. > Btw, the reason why it used to work with previous versions was that > until some versions ago (1.0.1) we could disable compression on: > > org.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION > > while now it's org.apache.myfaces.trinidad. > Moreover, the best solution would be to compress only Trinidad classes - > leaving custom classes as they are, but I gues this is impossible if > translation occurs after css merging. > > -- Renzo > > Simon Lessard wrote: >> Hmmm, sounds like a bug. In compression mode, only .xe0 should be >> generated. You can try to disable content compression for now using >> >>  <context-param> >>   <param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION >> </param-name> >>   <param-value>true</param-value> >> </context-param> >> >> Regards, >> >> ~ Simon >> >> On Nov 14, 2007 3:55 AM, Renzo Tomaselli < [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >>     Hi, I noticed an unpleasant effect due to Trinidad class >>     compression/aliasing. If I define my own class such as: >> >>     .invisible { >>        display: none; >>        visibility: hidden; >>     } >> >>     then the generated css contains: >> >>     .invisible,.xe0 {display:none;visibility:hidden} >> >>     The rendered html page contains always *both* classes, even in places >>     where xhtml source specified just .invisible. >>     The final result is that any js code looking for .invisible fails. >>     I'm using Trinidad 1.0.3. Till 1.0.1 these things were running >>     properly. >>     Even adding dummy attributes to my classes seems not working: an alias >>     is generated anyway, and used in html (in place of original class >>     name). >>     Should I disable alisasing - leaving original class names ? Is that >>     possible at all ? >> >>     -- Renzo >> >> >>