You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Renzo Tomaselli <re...@tecnotp.it> on 2007/11/14 09:55:03 UTC
[Trinidad] avoiding style class aliasing
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
Re: [Trinidad] avoiding style class aliasing
Posted by Andrew Robinson <an...@gmail.com>.
Perhaps there can be a change to allow exceptions to the compression.
Something like a prefix or postfix that prevents specific class names
from being compressed.
I am not a big fan of JavaScript using style classes to affect
behavior, but I don't see a good reason to not help support it if that
is something someone wants.
On 11/15/07, Simon Lessard <si...@gmail.com> wrote:
> Hi Renzo,
>
> The optimization is not mainly for the CSS size, but for the generated page
> markup. Trinidad set a styleClass on almost every single HTML element, so
> the content-size is not much bigger without compression, but noticeably
> bigger enough to worth it.
>
>
> On Nov 15, 2007 3:27 AM, Renzo Tomaselli <re...@tecnotp.it> wrote:
> >
> > 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 <je...@oracle.com> 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 < renzo.tomaselli@tecnotp.it
> > >
> > >
> > > >> <ma...@tecnotp.it>> 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
> > > >>
> > > >>
> > > >>
> > >
> >
> >
>
>
Re: [Trinidad] avoiding style class aliasing
Posted by Simon Lessard <si...@gmail.com>.
Hi Renzo,
The optimization is not mainly for the CSS size, but for the generated page
markup. Trinidad set a styleClass on almost every single HTML element, so
the content-size is not much bigger without compression, but noticeably
bigger enough to worth it.
On Nov 15, 2007 3:27 AM, Renzo Tomaselli <re...@tecnotp.it> wrote:
> 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 <je...@oracle.com> 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 < renzo.tomaselli@tecnotp.it
> >
> > >> <ma...@tecnotp.it>> 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
> > >>
> > >>
> > >>
> >
>
>
Re: [Trinidad] avoiding style class aliasing
Posted by Simon Lessard <si...@gmail.com>.
On Nov 14, 2007 2:19 PM, Jeanne Waldman <je...@oracle.com> 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 < renzo.tomaselli@tecnotp.it
> >> <ma...@tecnotp.it>> 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
> >>
> >>
> >>
>
Re: [Trinidad] avoiding style class aliasing
Posted by Jeanne Waldman <je...@oracle.com>.
The fact that it generates both compressed and uncompressed in this test
case is not a bug, but as designed.
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 < renzo.tomaselli@tecnotp.it
>> <ma...@tecnotp.it>> 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
>>
>>
>>
Re: [Trinidad] avoiding style class aliasing
Posted by Simon Lessard <si...@gmail.com>.
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 <re...@tecnotp.it> 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
>
>
>