You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Jeanne Waldman <je...@oracle.com> on 2007/02/01 01:44:38 UTC
Re: [Skinning] CSS selector limit hit in IE
Simon Lessard wrote:
> On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>>
>> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >
>> > > As Adam suggest, we could do some runtime evaluation during CSS
>> > > generation
>> > > and have many selector uses the same compressed selector, this would
>> be
>> > a
>> > > 50% gain or so.
>> > I can do this, too, if we feel we have to. The logic flow will have to
>> > change, of course.
>> > Right now we build the shortened style class map, then we generate the
>> > css file.
>> > I'd have to either change the shortened style class map as I merge
>> > styles, or create it a bit later.
>> > It's no big deal, just more overhead when we create the file.
>>
>>
>> Maybe this goes without saying but we have to be careful when doing this
>> so
>> that we only use the same selector when the containment definitions are
>> also
>> the same.
>>
>> If we just have:
>>
>> .Foo,
>> .Bar {
>> color: red;
>> }
>>
>> then this could be compressed down to:
>>
>> .x1 {
>> color: red;
>> }
>>
>> But if we have:
>>
>> .Foo,
>> .Bar {
>> color: red;
>> }
>>
>> .Foo .Joe {
>> color: green;
>> }
>>
>> .Bar .Joe {
>> color: blue;
>> }
>>
>> then we cannot use the same compressed name for Foo and Bar, we'd
>> compress
>> to:
>>
>> .x1,
>> .x2 {
>> color: red;
>> }
>>
>> .x1 .x3 {
>> color: green;
>> }
>>
>> .x2 .x3 {
>> color: blue;
>> }
>>
>> If we had:
>>
>> .Foo,
>> .Bar {
>> color: red;
>> }
>>
>> .Foo .Joe,
>> .Bar .Joe {
>> color: green;
>> }
>>
>> then we could compress down to:
>>
>> .x1 {
>> color: red;
>> }
>>
>> .x1 .x2 {
>> color: green;
>> }
>
>
> Yeah that would require quite a lot of evaluation after parsing, if
> that's
> done maybe we should consider generating the CSS files at app. startup
> rather than at first request because that kind of processing would
> most like
> be O(n!) or O(x^n).
I was thinking if a style is used anywhere else, period, we do not merge
that with another style. That is less processing, at least.
Personally, I think doing the only-generated-compressed-styles solution
or (only-non-uncompressed) is enough to solve this problem for a while.
I think this merging solution is lower priority, and more of a
nice-to-have. What does everyone else think?
If there is another reason to do this, like performance, and we know the
impact, then that's another thing, but I'd like
to focus on this issue and the solution right now -- especially since
we've hit this limit.
- Jeanne
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
Hi there,
I've changed my mind and instead added this to FileSystemStyleCache. It
is cleaner. I didn't do this in the first place
because I needed the RenderingContext, and I didn't think I had it. But
then I noticed that I have it with the getCurrentInstance method.
Map skinsStyleClassMap = context.getSkin().getStyleClassMap(
RenderingContext.getCurrentInstance());
String disableContentCompression =
FacesContext.getCurrentInstance().getExternalContext().
getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION);
boolean compressStyles = (skinsStyleClassMap == shortStyleClassMap) &&
!"true".equals(disableContentCompression);
Jeanne Waldman wrote:
> This is what I've done:
> Added a getSkin() on the StyleContext object which I think is a fine
> thing to do, since the StyleContext
> gives us information we need to be able to output the stylesheet.
>
> Then I can do this to see if I need to output the compressed
> styleclasses or the uncompressed styleclasses:
> String disableContentCompression =
> FacesContext.getCurrentInstance().getExternalContext().
> getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION);
> // we do not compress if it is a portlet skin
> boolean isPortletSkin =
>
> CoreRenderKit.OUTPUT_MODE_PORTLET.equals(context.getSkin().getRenderKitId());
>
>
> boolean compressStyles =
> (!"true".equals(disableContentCompression)) &&
> !isPortletSkin;
>
> Simon Lessard wrote:
>> That works, true.
>>
>> On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>>>
>>>
>>>
>>>
>>> Simon Lessard wrote:
>>> > Hello Jeanne,
>>> >
>>> > I thought about skinning and portlet before and I came upon pretty
>>> > much the
>>> > same conclusion. However in my idea it was more like a predefined
>>> skin
>>> > family, like "containerProvided" maybe. Then renderer would always
>>> uses
>>> > uncompressed selectors and would leave <style/> tag generation to the
>>> > container. Then again the container would need a way to produce the
>>> > CSS, but
>>> > I was not yet to that point.
>>> >
>>> > I guess a flag in the skin definition works as well, but it seems
>>> a bit
>>> > strange to have a skin specific for a portlet environment, I would
>>> have
>>> > preferred to be able to use any skin.
>>> Like we have desktop skins,
>>> pda skins, we can now also have portlet skins.
>>> This way we don't change the skin-family.
>>> We we have a SimpleDesktop skin, a SimplePda skin, we
>>> now also have a SimplePortlet skin.
>>> >
>>> >
>>> > Regards,
>>> >
>>> > ~ Simon
>>> >
>>> > On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>>> >>
>>> >> I just thought of a reason why I can't simply compress or uncompress
>>> >> based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
>>> >> portal skin we've introduced in the portal branch. We don't compress
>>> our
>>> >> styleclasses when using the portal skin.
>>> >>
>>> >> The way the skinning works now in the portal branch is:
>>> >> 1. It assumes we write out both full and compressed styleclasses
>>> in our
>>> >> generated css file.
>>> >> 2. The Skin has a getStyleClassMap method. For all skins except
>>> portal
>>> >> skins, it returns our styleclass compression map if we aren't
>>> disabling
>>> >> content compression, else null; for portal skins it returns a
>>> Trinidad
>>> >> styleclass to portal styleclass map.
>>> >>
>>> >> I can see upon writing out the css file I look to see if it is a
>>> portal,
>>> >> etc.
>>> >> Or what do people think about a flag in the Skin that tells me if
>>> the
>>> >> StyleClassMap is the compression map that we use to generate the
>>> css?
>>> >> Or maybe in our css generation code we can look at the skin's
>>> styleclass
>>> >> map and glean information from it? Maybe see if it is the same
>>> >> compression map that we are using to generate the css file and if
>>> so,
>>> >> then it's ok to just write out compression, and if not, then we
>>> don't???
>>> >>
>>> >> I'll see what I can do, but I'll want a code review to make sure
>>> it is
>>> >> the best solution.
>>> >>
>>> >> Thanks,
>>> >> Jeanne
>>> >>
>>> >> Matt Cooper wrote:
>>> >> > That sounds like a reasonable first step to me since that would
>>> reduce
>>> >> > the
>>> >> > size the most.
>>> >> >
>>> >> > Thanks
>>> >> >
>>> >> > On 1/31/07, Simon Lessard <si...@gmail.com> wrote:
>>> >> >>
>>> >> >> I agree, only one version compressed or uncompressed should be
>>> enough
>>> >> >> for
>>> >> >> a
>>> >> >> while.
>>> >> >>
>>> >> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > Simon Lessard wrote:
>>> >> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>>> >> >> > >>
>>> >> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com>
>>> wrote:
>>> >> >> > >> >
>>> >> >> > >> > > As Adam suggest, we could do some runtime evaluation
>>> during
>>> >> CSS
>>> >> >> > >> > > generation
>>> >> >> > >> > > and have many selector uses the same compressed
>>> selector,
>>> >> this
>>> >> >> > would
>>> >> >> > >> be
>>> >> >> > >> > a
>>> >> >> > >> > > 50% gain or so.
>>> >> >> > >> > I can do this, too, if we feel we have to. The logic flow
>>> will
>>> >> >> have
>>> >> >> > to
>>> >> >> > >> > change, of course.
>>> >> >> > >> > Right now we build the shortened style class map, then we
>>> >> >> generate
>>> >> >> > the
>>> >> >> > >> > css file.
>>> >> >> > >> > I'd have to either change the shortened style class map
>>> as I
>>> >> >> merge
>>> >> >> > >> > styles, or create it a bit later.
>>> >> >> > >> > It's no big deal, just more overhead when we create the
>>> file.
>>> >> >> > >>
>>> >> >> > >>
>>> >> >> > >> Maybe this goes without saying but we have to be careful
>>> when
>>> >> doing
>>> >> >> > this
>>> >> >> > >> so
>>> >> >> > >> that we only use the same selector when the containment
>>> >> definitions
>>> >> >> are
>>> >> >> > >> also
>>> >> >> > >> the same.
>>> >> >> > >>
>>> >> >> > >> If we just have:
>>> >> >> > >>
>>> >> >> > >> .Foo,
>>> >> >> > >> .Bar {
>>> >> >> > >> color: red;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> then this could be compressed down to:
>>> >> >> > >>
>>> >> >> > >> .x1 {
>>> >> >> > >> color: red;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> But if we have:
>>> >> >> > >>
>>> >> >> > >> .Foo,
>>> >> >> > >> .Bar {
>>> >> >> > >> color: red;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> .Foo .Joe {
>>> >> >> > >> color: green;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> .Bar .Joe {
>>> >> >> > >> color: blue;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> then we cannot use the same compressed name for Foo and Bar,
>>> >> we'd
>>> >> >> > >> compress
>>> >> >> > >> to:
>>> >> >> > >>
>>> >> >> > >> .x1,
>>> >> >> > >> .x2 {
>>> >> >> > >> color: red;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> .x1 .x3 {
>>> >> >> > >> color: green;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> .x2 .x3 {
>>> >> >> > >> color: blue;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> If we had:
>>> >> >> > >>
>>> >> >> > >> .Foo,
>>> >> >> > >> .Bar {
>>> >> >> > >> color: red;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> .Foo .Joe,
>>> >> >> > >> .Bar .Joe {
>>> >> >> > >> color: green;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> then we could compress down to:
>>> >> >> > >>
>>> >> >> > >> .x1 {
>>> >> >> > >> color: red;
>>> >> >> > >> }
>>> >> >> > >>
>>> >> >> > >> .x1 .x2 {
>>> >> >> > >> color: green;
>>> >> >> > >> }
>>> >> >> > >
>>> >> >> > >
>>> >> >> > > Yeah that would require quite a lot of evaluation after
>>> >> parsing, if
>>> >> >> > > that's
>>> >> >> > > done maybe we should consider generating the CSS files at
>>> app.
>>> >> >> startup
>>> >> >> > > rather than at first request because that kind of processing
>>> >> would
>>> >> >> > > most like
>>> >> >> > > be O(n!) or O(x^n).
>>> >> >> > I was thinking if a style is used anywhere else, period, we
>>> do not
>>> >> >> merge
>>> >> >> > that with another style. That is less processing, at least.
>>> >> >> > Personally, I think doing the only-generated-compressed-styles
>>> >> >> solution
>>> >> >> > or (only-non-uncompressed) is enough to solve this problem
>>> for a
>>> >> >> while.
>>> >> >> > I think this merging solution is lower priority, and more of a
>>> >> >> > nice-to-have. What does everyone else think?
>>> >> >> > If there is another reason to do this, like performance, and we
>>> >> >> know the
>>> >> >> > impact, then that's another thing, but I'd like
>>> >> >> > to focus on this issue and the solution right now -- especially
>>> >> since
>>> >> >> > we've hit this limit.
>>> >> >> > - Jeanne
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
This is what I've done:
Added a getSkin() on the StyleContext object which I think is a fine
thing to do, since the StyleContext
gives us information we need to be able to output the stylesheet.
Then I can do this to see if I need to output the compressed
styleclasses or the uncompressed styleclasses:
String disableContentCompression =
FacesContext.getCurrentInstance().getExternalContext().
getInitParameter(StyleSheetRenderer.DISABLE_CONTENT_COMPRESSION);
// we do not compress if it is a portlet skin
boolean isPortletSkin =
CoreRenderKit.OUTPUT_MODE_PORTLET.equals(context.getSkin().getRenderKitId());
boolean compressStyles = (!"true".equals(disableContentCompression)) &&
!isPortletSkin;
Simon Lessard wrote:
> That works, true.
>
> On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>>
>>
>>
>>
>> Simon Lessard wrote:
>> > Hello Jeanne,
>> >
>> > I thought about skinning and portlet before and I came upon pretty
>> > much the
>> > same conclusion. However in my idea it was more like a predefined skin
>> > family, like "containerProvided" maybe. Then renderer would always
>> uses
>> > uncompressed selectors and would leave <style/> tag generation to the
>> > container. Then again the container would need a way to produce the
>> > CSS, but
>> > I was not yet to that point.
>> >
>> > I guess a flag in the skin definition works as well, but it seems a
>> bit
>> > strange to have a skin specific for a portlet environment, I would
>> have
>> > preferred to be able to use any skin.
>> Like we have desktop skins,
>> pda skins, we can now also have portlet skins.
>> This way we don't change the skin-family.
>> We we have a SimpleDesktop skin, a SimplePda skin, we
>> now also have a SimplePortlet skin.
>> >
>> >
>> > Regards,
>> >
>> > ~ Simon
>> >
>> > On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >>
>> >> I just thought of a reason why I can't simply compress or uncompress
>> >> based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
>> >> portal skin we've introduced in the portal branch. We don't compress
>> our
>> >> styleclasses when using the portal skin.
>> >>
>> >> The way the skinning works now in the portal branch is:
>> >> 1. It assumes we write out both full and compressed styleclasses
>> in our
>> >> generated css file.
>> >> 2. The Skin has a getStyleClassMap method. For all skins except
>> portal
>> >> skins, it returns our styleclass compression map if we aren't
>> disabling
>> >> content compression, else null; for portal skins it returns a
>> Trinidad
>> >> styleclass to portal styleclass map.
>> >>
>> >> I can see upon writing out the css file I look to see if it is a
>> portal,
>> >> etc.
>> >> Or what do people think about a flag in the Skin that tells me if the
>> >> StyleClassMap is the compression map that we use to generate the css?
>> >> Or maybe in our css generation code we can look at the skin's
>> styleclass
>> >> map and glean information from it? Maybe see if it is the same
>> >> compression map that we are using to generate the css file and if so,
>> >> then it's ok to just write out compression, and if not, then we
>> don't???
>> >>
>> >> I'll see what I can do, but I'll want a code review to make sure
>> it is
>> >> the best solution.
>> >>
>> >> Thanks,
>> >> Jeanne
>> >>
>> >> Matt Cooper wrote:
>> >> > That sounds like a reasonable first step to me since that would
>> reduce
>> >> > the
>> >> > size the most.
>> >> >
>> >> > Thanks
>> >> >
>> >> > On 1/31/07, Simon Lessard <si...@gmail.com> wrote:
>> >> >>
>> >> >> I agree, only one version compressed or uncompressed should be
>> enough
>> >> >> for
>> >> >> a
>> >> >> while.
>> >> >>
>> >> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Simon Lessard wrote:
>> >> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>> >> >> > >>
>> >> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >> >> > >> >
>> >> >> > >> > > As Adam suggest, we could do some runtime evaluation
>> during
>> >> CSS
>> >> >> > >> > > generation
>> >> >> > >> > > and have many selector uses the same compressed selector,
>> >> this
>> >> >> > would
>> >> >> > >> be
>> >> >> > >> > a
>> >> >> > >> > > 50% gain or so.
>> >> >> > >> > I can do this, too, if we feel we have to. The logic flow
>> will
>> >> >> have
>> >> >> > to
>> >> >> > >> > change, of course.
>> >> >> > >> > Right now we build the shortened style class map, then we
>> >> >> generate
>> >> >> > the
>> >> >> > >> > css file.
>> >> >> > >> > I'd have to either change the shortened style class map
>> as I
>> >> >> merge
>> >> >> > >> > styles, or create it a bit later.
>> >> >> > >> > It's no big deal, just more overhead when we create the
>> file.
>> >> >> > >>
>> >> >> > >>
>> >> >> > >> Maybe this goes without saying but we have to be careful when
>> >> doing
>> >> >> > this
>> >> >> > >> so
>> >> >> > >> that we only use the same selector when the containment
>> >> definitions
>> >> >> are
>> >> >> > >> also
>> >> >> > >> the same.
>> >> >> > >>
>> >> >> > >> If we just have:
>> >> >> > >>
>> >> >> > >> .Foo,
>> >> >> > >> .Bar {
>> >> >> > >> color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> then this could be compressed down to:
>> >> >> > >>
>> >> >> > >> .x1 {
>> >> >> > >> color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> But if we have:
>> >> >> > >>
>> >> >> > >> .Foo,
>> >> >> > >> .Bar {
>> >> >> > >> color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .Foo .Joe {
>> >> >> > >> color: green;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .Bar .Joe {
>> >> >> > >> color: blue;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> then we cannot use the same compressed name for Foo and Bar,
>> >> we'd
>> >> >> > >> compress
>> >> >> > >> to:
>> >> >> > >>
>> >> >> > >> .x1,
>> >> >> > >> .x2 {
>> >> >> > >> color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .x1 .x3 {
>> >> >> > >> color: green;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .x2 .x3 {
>> >> >> > >> color: blue;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> If we had:
>> >> >> > >>
>> >> >> > >> .Foo,
>> >> >> > >> .Bar {
>> >> >> > >> color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .Foo .Joe,
>> >> >> > >> .Bar .Joe {
>> >> >> > >> color: green;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> then we could compress down to:
>> >> >> > >>
>> >> >> > >> .x1 {
>> >> >> > >> color: red;
>> >> >> > >> }
>> >> >> > >>
>> >> >> > >> .x1 .x2 {
>> >> >> > >> color: green;
>> >> >> > >> }
>> >> >> > >
>> >> >> > >
>> >> >> > > Yeah that would require quite a lot of evaluation after
>> >> parsing, if
>> >> >> > > that's
>> >> >> > > done maybe we should consider generating the CSS files at app.
>> >> >> startup
>> >> >> > > rather than at first request because that kind of processing
>> >> would
>> >> >> > > most like
>> >> >> > > be O(n!) or O(x^n).
>> >> >> > I was thinking if a style is used anywhere else, period, we
>> do not
>> >> >> merge
>> >> >> > that with another style. That is less processing, at least.
>> >> >> > Personally, I think doing the only-generated-compressed-styles
>> >> >> solution
>> >> >> > or (only-non-uncompressed) is enough to solve this problem for a
>> >> >> while.
>> >> >> > I think this merging solution is lower priority, and more of a
>> >> >> > nice-to-have. What does everyone else think?
>> >> >> > If there is another reason to do this, like performance, and we
>> >> >> know the
>> >> >> > impact, then that's another thing, but I'd like
>> >> >> > to focus on this issue and the solution right now -- especially
>> >> since
>> >> >> > we've hit this limit.
>> >> >> > - Jeanne
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
That works, true.
On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>
>
>
>
> Simon Lessard wrote:
> > Hello Jeanne,
> >
> > I thought about skinning and portlet before and I came upon pretty
> > much the
> > same conclusion. However in my idea it was more like a predefined skin
> > family, like "containerProvided" maybe. Then renderer would always uses
> > uncompressed selectors and would leave <style/> tag generation to the
> > container. Then again the container would need a way to produce the
> > CSS, but
> > I was not yet to that point.
> >
> > I guess a flag in the skin definition works as well, but it seems a bit
> > strange to have a skin specific for a portlet environment, I would have
> > preferred to be able to use any skin.
> Like we have desktop skins,
> pda skins, we can now also have portlet skins.
> This way we don't change the skin-family.
> We we have a SimpleDesktop skin, a SimplePda skin, we
> now also have a SimplePortlet skin.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
> >>
> >> I just thought of a reason why I can't simply compress or uncompress
> >> based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
> >> portal skin we've introduced in the portal branch. We don't compress
> our
> >> styleclasses when using the portal skin.
> >>
> >> The way the skinning works now in the portal branch is:
> >> 1. It assumes we write out both full and compressed styleclasses in our
> >> generated css file.
> >> 2. The Skin has a getStyleClassMap method. For all skins except portal
> >> skins, it returns our styleclass compression map if we aren't disabling
> >> content compression, else null; for portal skins it returns a Trinidad
> >> styleclass to portal styleclass map.
> >>
> >> I can see upon writing out the css file I look to see if it is a
> portal,
> >> etc.
> >> Or what do people think about a flag in the Skin that tells me if the
> >> StyleClassMap is the compression map that we use to generate the css?
> >> Or maybe in our css generation code we can look at the skin's
> styleclass
> >> map and glean information from it? Maybe see if it is the same
> >> compression map that we are using to generate the css file and if so,
> >> then it's ok to just write out compression, and if not, then we
> don't???
> >>
> >> I'll see what I can do, but I'll want a code review to make sure it is
> >> the best solution.
> >>
> >> Thanks,
> >> Jeanne
> >>
> >> Matt Cooper wrote:
> >> > That sounds like a reasonable first step to me since that would
> reduce
> >> > the
> >> > size the most.
> >> >
> >> > Thanks
> >> >
> >> > On 1/31/07, Simon Lessard <si...@gmail.com> wrote:
> >> >>
> >> >> I agree, only one version compressed or uncompressed should be
> enough
> >> >> for
> >> >> a
> >> >> while.
> >> >>
> >> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> > Simon Lessard wrote:
> >> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
> >> >> > >>
> >> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> >> >> > >> >
> >> >> > >> > > As Adam suggest, we could do some runtime evaluation during
> >> CSS
> >> >> > >> > > generation
> >> >> > >> > > and have many selector uses the same compressed selector,
> >> this
> >> >> > would
> >> >> > >> be
> >> >> > >> > a
> >> >> > >> > > 50% gain or so.
> >> >> > >> > I can do this, too, if we feel we have to. The logic flow
> will
> >> >> have
> >> >> > to
> >> >> > >> > change, of course.
> >> >> > >> > Right now we build the shortened style class map, then we
> >> >> generate
> >> >> > the
> >> >> > >> > css file.
> >> >> > >> > I'd have to either change the shortened style class map as I
> >> >> merge
> >> >> > >> > styles, or create it a bit later.
> >> >> > >> > It's no big deal, just more overhead when we create the file.
> >> >> > >>
> >> >> > >>
> >> >> > >> Maybe this goes without saying but we have to be careful when
> >> doing
> >> >> > this
> >> >> > >> so
> >> >> > >> that we only use the same selector when the containment
> >> definitions
> >> >> are
> >> >> > >> also
> >> >> > >> the same.
> >> >> > >>
> >> >> > >> If we just have:
> >> >> > >>
> >> >> > >> .Foo,
> >> >> > >> .Bar {
> >> >> > >> color: red;
> >> >> > >> }
> >> >> > >>
> >> >> > >> then this could be compressed down to:
> >> >> > >>
> >> >> > >> .x1 {
> >> >> > >> color: red;
> >> >> > >> }
> >> >> > >>
> >> >> > >> But if we have:
> >> >> > >>
> >> >> > >> .Foo,
> >> >> > >> .Bar {
> >> >> > >> color: red;
> >> >> > >> }
> >> >> > >>
> >> >> > >> .Foo .Joe {
> >> >> > >> color: green;
> >> >> > >> }
> >> >> > >>
> >> >> > >> .Bar .Joe {
> >> >> > >> color: blue;
> >> >> > >> }
> >> >> > >>
> >> >> > >> then we cannot use the same compressed name for Foo and Bar,
> >> we'd
> >> >> > >> compress
> >> >> > >> to:
> >> >> > >>
> >> >> > >> .x1,
> >> >> > >> .x2 {
> >> >> > >> color: red;
> >> >> > >> }
> >> >> > >>
> >> >> > >> .x1 .x3 {
> >> >> > >> color: green;
> >> >> > >> }
> >> >> > >>
> >> >> > >> .x2 .x3 {
> >> >> > >> color: blue;
> >> >> > >> }
> >> >> > >>
> >> >> > >> If we had:
> >> >> > >>
> >> >> > >> .Foo,
> >> >> > >> .Bar {
> >> >> > >> color: red;
> >> >> > >> }
> >> >> > >>
> >> >> > >> .Foo .Joe,
> >> >> > >> .Bar .Joe {
> >> >> > >> color: green;
> >> >> > >> }
> >> >> > >>
> >> >> > >> then we could compress down to:
> >> >> > >>
> >> >> > >> .x1 {
> >> >> > >> color: red;
> >> >> > >> }
> >> >> > >>
> >> >> > >> .x1 .x2 {
> >> >> > >> color: green;
> >> >> > >> }
> >> >> > >
> >> >> > >
> >> >> > > Yeah that would require quite a lot of evaluation after
> >> parsing, if
> >> >> > > that's
> >> >> > > done maybe we should consider generating the CSS files at app.
> >> >> startup
> >> >> > > rather than at first request because that kind of processing
> >> would
> >> >> > > most like
> >> >> > > be O(n!) or O(x^n).
> >> >> > I was thinking if a style is used anywhere else, period, we do not
> >> >> merge
> >> >> > that with another style. That is less processing, at least.
> >> >> > Personally, I think doing the only-generated-compressed-styles
> >> >> solution
> >> >> > or (only-non-uncompressed) is enough to solve this problem for a
> >> >> while.
> >> >> > I think this merging solution is lower priority, and more of a
> >> >> > nice-to-have. What does everyone else think?
> >> >> > If there is another reason to do this, like performance, and we
> >> >> know the
> >> >> > impact, then that's another thing, but I'd like
> >> >> > to focus on this issue and the solution right now -- especially
> >> since
> >> >> > we've hit this limit.
> >> >> > - Jeanne
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
Simon Lessard wrote:
> Hello Jeanne,
>
> I thought about skinning and portlet before and I came upon pretty
> much the
> same conclusion. However in my idea it was more like a predefined skin
> family, like "containerProvided" maybe. Then renderer would always uses
> uncompressed selectors and would leave <style/> tag generation to the
> container. Then again the container would need a way to produce the
> CSS, but
> I was not yet to that point.
>
> I guess a flag in the skin definition works as well, but it seems a bit
> strange to have a skin specific for a portlet environment, I would have
> preferred to be able to use any skin.
Like we have desktop skins,
pda skins, we can now also have portlet skins.
This way we don't change the skin-family.
We we have a SimpleDesktop skin, a SimplePda skin, we
now also have a SimplePortlet skin.
>
>
> Regards,
>
> ~ Simon
>
> On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>>
>> I just thought of a reason why I can't simply compress or uncompress
>> based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
>> portal skin we've introduced in the portal branch. We don't compress our
>> styleclasses when using the portal skin.
>>
>> The way the skinning works now in the portal branch is:
>> 1. It assumes we write out both full and compressed styleclasses in our
>> generated css file.
>> 2. The Skin has a getStyleClassMap method. For all skins except portal
>> skins, it returns our styleclass compression map if we aren't disabling
>> content compression, else null; for portal skins it returns a Trinidad
>> styleclass to portal styleclass map.
>>
>> I can see upon writing out the css file I look to see if it is a portal,
>> etc.
>> Or what do people think about a flag in the Skin that tells me if the
>> StyleClassMap is the compression map that we use to generate the css?
>> Or maybe in our css generation code we can look at the skin's styleclass
>> map and glean information from it? Maybe see if it is the same
>> compression map that we are using to generate the css file and if so,
>> then it's ok to just write out compression, and if not, then we don't???
>>
>> I'll see what I can do, but I'll want a code review to make sure it is
>> the best solution.
>>
>> Thanks,
>> Jeanne
>>
>> Matt Cooper wrote:
>> > That sounds like a reasonable first step to me since that would reduce
>> > the
>> > size the most.
>> >
>> > Thanks
>> >
>> > On 1/31/07, Simon Lessard <si...@gmail.com> wrote:
>> >>
>> >> I agree, only one version compressed or uncompressed should be enough
>> >> for
>> >> a
>> >> while.
>> >>
>> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >> >
>> >> >
>> >> >
>> >> > Simon Lessard wrote:
>> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>> >> > >>
>> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >> > >> >
>> >> > >> > > As Adam suggest, we could do some runtime evaluation during
>> CSS
>> >> > >> > > generation
>> >> > >> > > and have many selector uses the same compressed selector,
>> this
>> >> > would
>> >> > >> be
>> >> > >> > a
>> >> > >> > > 50% gain or so.
>> >> > >> > I can do this, too, if we feel we have to. The logic flow will
>> >> have
>> >> > to
>> >> > >> > change, of course.
>> >> > >> > Right now we build the shortened style class map, then we
>> >> generate
>> >> > the
>> >> > >> > css file.
>> >> > >> > I'd have to either change the shortened style class map as I
>> >> merge
>> >> > >> > styles, or create it a bit later.
>> >> > >> > It's no big deal, just more overhead when we create the file.
>> >> > >>
>> >> > >>
>> >> > >> Maybe this goes without saying but we have to be careful when
>> doing
>> >> > this
>> >> > >> so
>> >> > >> that we only use the same selector when the containment
>> definitions
>> >> are
>> >> > >> also
>> >> > >> the same.
>> >> > >>
>> >> > >> If we just have:
>> >> > >>
>> >> > >> .Foo,
>> >> > >> .Bar {
>> >> > >> color: red;
>> >> > >> }
>> >> > >>
>> >> > >> then this could be compressed down to:
>> >> > >>
>> >> > >> .x1 {
>> >> > >> color: red;
>> >> > >> }
>> >> > >>
>> >> > >> But if we have:
>> >> > >>
>> >> > >> .Foo,
>> >> > >> .Bar {
>> >> > >> color: red;
>> >> > >> }
>> >> > >>
>> >> > >> .Foo .Joe {
>> >> > >> color: green;
>> >> > >> }
>> >> > >>
>> >> > >> .Bar .Joe {
>> >> > >> color: blue;
>> >> > >> }
>> >> > >>
>> >> > >> then we cannot use the same compressed name for Foo and Bar,
>> we'd
>> >> > >> compress
>> >> > >> to:
>> >> > >>
>> >> > >> .x1,
>> >> > >> .x2 {
>> >> > >> color: red;
>> >> > >> }
>> >> > >>
>> >> > >> .x1 .x3 {
>> >> > >> color: green;
>> >> > >> }
>> >> > >>
>> >> > >> .x2 .x3 {
>> >> > >> color: blue;
>> >> > >> }
>> >> > >>
>> >> > >> If we had:
>> >> > >>
>> >> > >> .Foo,
>> >> > >> .Bar {
>> >> > >> color: red;
>> >> > >> }
>> >> > >>
>> >> > >> .Foo .Joe,
>> >> > >> .Bar .Joe {
>> >> > >> color: green;
>> >> > >> }
>> >> > >>
>> >> > >> then we could compress down to:
>> >> > >>
>> >> > >> .x1 {
>> >> > >> color: red;
>> >> > >> }
>> >> > >>
>> >> > >> .x1 .x2 {
>> >> > >> color: green;
>> >> > >> }
>> >> > >
>> >> > >
>> >> > > Yeah that would require quite a lot of evaluation after
>> parsing, if
>> >> > > that's
>> >> > > done maybe we should consider generating the CSS files at app.
>> >> startup
>> >> > > rather than at first request because that kind of processing
>> would
>> >> > > most like
>> >> > > be O(n!) or O(x^n).
>> >> > I was thinking if a style is used anywhere else, period, we do not
>> >> merge
>> >> > that with another style. That is less processing, at least.
>> >> > Personally, I think doing the only-generated-compressed-styles
>> >> solution
>> >> > or (only-non-uncompressed) is enough to solve this problem for a
>> >> while.
>> >> > I think this merging solution is lower priority, and more of a
>> >> > nice-to-have. What does everyone else think?
>> >> > If there is another reason to do this, like performance, and we
>> >> know the
>> >> > impact, then that's another thing, but I'd like
>> >> > to focus on this issue and the solution right now -- especially
>> since
>> >> > we've hit this limit.
>> >> > - Jeanne
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
Hello Jeanne,
I thought about skinning and portlet before and I came upon pretty much the
same conclusion. However in my idea it was more like a predefined skin
family, like "containerProvided" maybe. Then renderer would always uses
uncompressed selectors and would leave <style/> tag generation to the
container. Then again the container would need a way to produce the CSS, but
I was not yet to that point.
I guess a flag in the skin definition works as well, but it seems a bit
strange to have a skin specific for a portlet environment, I would have
preferred to be able to use any skin.
Regards,
~ Simon
On 2/1/07, Jeanne Waldman <je...@oracle.com> wrote:
>
> I just thought of a reason why I can't simply compress or uncompress
> based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
> portal skin we've introduced in the portal branch. We don't compress our
> styleclasses when using the portal skin.
>
> The way the skinning works now in the portal branch is:
> 1. It assumes we write out both full and compressed styleclasses in our
> generated css file.
> 2. The Skin has a getStyleClassMap method. For all skins except portal
> skins, it returns our styleclass compression map if we aren't disabling
> content compression, else null; for portal skins it returns a Trinidad
> styleclass to portal styleclass map.
>
> I can see upon writing out the css file I look to see if it is a portal,
> etc.
> Or what do people think about a flag in the Skin that tells me if the
> StyleClassMap is the compression map that we use to generate the css?
> Or maybe in our css generation code we can look at the skin's styleclass
> map and glean information from it? Maybe see if it is the same
> compression map that we are using to generate the css file and if so,
> then it's ok to just write out compression, and if not, then we don't???
>
> I'll see what I can do, but I'll want a code review to make sure it is
> the best solution.
>
> Thanks,
> Jeanne
>
> Matt Cooper wrote:
> > That sounds like a reasonable first step to me since that would reduce
> > the
> > size the most.
> >
> > Thanks
> >
> > On 1/31/07, Simon Lessard <si...@gmail.com> wrote:
> >>
> >> I agree, only one version compressed or uncompressed should be enough
> >> for
> >> a
> >> while.
> >>
> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> >> >
> >> >
> >> >
> >> > Simon Lessard wrote:
> >> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
> >> > >>
> >> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> >> > >> >
> >> > >> > > As Adam suggest, we could do some runtime evaluation during
> CSS
> >> > >> > > generation
> >> > >> > > and have many selector uses the same compressed selector, this
> >> > would
> >> > >> be
> >> > >> > a
> >> > >> > > 50% gain or so.
> >> > >> > I can do this, too, if we feel we have to. The logic flow will
> >> have
> >> > to
> >> > >> > change, of course.
> >> > >> > Right now we build the shortened style class map, then we
> >> generate
> >> > the
> >> > >> > css file.
> >> > >> > I'd have to either change the shortened style class map as I
> >> merge
> >> > >> > styles, or create it a bit later.
> >> > >> > It's no big deal, just more overhead when we create the file.
> >> > >>
> >> > >>
> >> > >> Maybe this goes without saying but we have to be careful when
> doing
> >> > this
> >> > >> so
> >> > >> that we only use the same selector when the containment
> definitions
> >> are
> >> > >> also
> >> > >> the same.
> >> > >>
> >> > >> If we just have:
> >> > >>
> >> > >> .Foo,
> >> > >> .Bar {
> >> > >> color: red;
> >> > >> }
> >> > >>
> >> > >> then this could be compressed down to:
> >> > >>
> >> > >> .x1 {
> >> > >> color: red;
> >> > >> }
> >> > >>
> >> > >> But if we have:
> >> > >>
> >> > >> .Foo,
> >> > >> .Bar {
> >> > >> color: red;
> >> > >> }
> >> > >>
> >> > >> .Foo .Joe {
> >> > >> color: green;
> >> > >> }
> >> > >>
> >> > >> .Bar .Joe {
> >> > >> color: blue;
> >> > >> }
> >> > >>
> >> > >> then we cannot use the same compressed name for Foo and Bar, we'd
> >> > >> compress
> >> > >> to:
> >> > >>
> >> > >> .x1,
> >> > >> .x2 {
> >> > >> color: red;
> >> > >> }
> >> > >>
> >> > >> .x1 .x3 {
> >> > >> color: green;
> >> > >> }
> >> > >>
> >> > >> .x2 .x3 {
> >> > >> color: blue;
> >> > >> }
> >> > >>
> >> > >> If we had:
> >> > >>
> >> > >> .Foo,
> >> > >> .Bar {
> >> > >> color: red;
> >> > >> }
> >> > >>
> >> > >> .Foo .Joe,
> >> > >> .Bar .Joe {
> >> > >> color: green;
> >> > >> }
> >> > >>
> >> > >> then we could compress down to:
> >> > >>
> >> > >> .x1 {
> >> > >> color: red;
> >> > >> }
> >> > >>
> >> > >> .x1 .x2 {
> >> > >> color: green;
> >> > >> }
> >> > >
> >> > >
> >> > > Yeah that would require quite a lot of evaluation after parsing, if
> >> > > that's
> >> > > done maybe we should consider generating the CSS files at app.
> >> startup
> >> > > rather than at first request because that kind of processing would
> >> > > most like
> >> > > be O(n!) or O(x^n).
> >> > I was thinking if a style is used anywhere else, period, we do not
> >> merge
> >> > that with another style. That is less processing, at least.
> >> > Personally, I think doing the only-generated-compressed-styles
> >> solution
> >> > or (only-non-uncompressed) is enough to solve this problem for a
> >> while.
> >> > I think this merging solution is lower priority, and more of a
> >> > nice-to-have. What does everyone else think?
> >> > If there is another reason to do this, like performance, and we
> >> know the
> >> > impact, then that's another thing, but I'd like
> >> > to focus on this issue and the solution right now -- especially since
> >> > we've hit this limit.
> >> > - Jeanne
> >> >
> >> >
> >>
> >>
> >
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Jeanne Waldman <je...@oracle.com>.
I just thought of a reason why I can't simply compress or uncompress
based on the DISABLE_CONTENT_COMPRESSION flag, and that is the new
portal skin we've introduced in the portal branch. We don't compress our
styleclasses when using the portal skin.
The way the skinning works now in the portal branch is:
1. It assumes we write out both full and compressed styleclasses in our
generated css file.
2. The Skin has a getStyleClassMap method. For all skins except portal
skins, it returns our styleclass compression map if we aren't disabling
content compression, else null; for portal skins it returns a Trinidad
styleclass to portal styleclass map.
I can see upon writing out the css file I look to see if it is a portal,
etc.
Or what do people think about a flag in the Skin that tells me if the
StyleClassMap is the compression map that we use to generate the css?
Or maybe in our css generation code we can look at the skin's styleclass
map and glean information from it? Maybe see if it is the same
compression map that we are using to generate the css file and if so,
then it's ok to just write out compression, and if not, then we don't???
I'll see what I can do, but I'll want a code review to make sure it is
the best solution.
Thanks,
Jeanne
Matt Cooper wrote:
> That sounds like a reasonable first step to me since that would reduce
> the
> size the most.
>
> Thanks
>
> On 1/31/07, Simon Lessard <si...@gmail.com> wrote:
>>
>> I agree, only one version compressed or uncompressed should be enough
>> for
>> a
>> while.
>>
>> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> >
>> >
>> >
>> > Simon Lessard wrote:
>> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
>> > >>
>> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>> > >> >
>> > >> > > As Adam suggest, we could do some runtime evaluation during CSS
>> > >> > > generation
>> > >> > > and have many selector uses the same compressed selector, this
>> > would
>> > >> be
>> > >> > a
>> > >> > > 50% gain or so.
>> > >> > I can do this, too, if we feel we have to. The logic flow will
>> have
>> > to
>> > >> > change, of course.
>> > >> > Right now we build the shortened style class map, then we
>> generate
>> > the
>> > >> > css file.
>> > >> > I'd have to either change the shortened style class map as I
>> merge
>> > >> > styles, or create it a bit later.
>> > >> > It's no big deal, just more overhead when we create the file.
>> > >>
>> > >>
>> > >> Maybe this goes without saying but we have to be careful when doing
>> > this
>> > >> so
>> > >> that we only use the same selector when the containment definitions
>> are
>> > >> also
>> > >> the same.
>> > >>
>> > >> If we just have:
>> > >>
>> > >> .Foo,
>> > >> .Bar {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> then this could be compressed down to:
>> > >>
>> > >> .x1 {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> But if we have:
>> > >>
>> > >> .Foo,
>> > >> .Bar {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> .Foo .Joe {
>> > >> color: green;
>> > >> }
>> > >>
>> > >> .Bar .Joe {
>> > >> color: blue;
>> > >> }
>> > >>
>> > >> then we cannot use the same compressed name for Foo and Bar, we'd
>> > >> compress
>> > >> to:
>> > >>
>> > >> .x1,
>> > >> .x2 {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> .x1 .x3 {
>> > >> color: green;
>> > >> }
>> > >>
>> > >> .x2 .x3 {
>> > >> color: blue;
>> > >> }
>> > >>
>> > >> If we had:
>> > >>
>> > >> .Foo,
>> > >> .Bar {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> .Foo .Joe,
>> > >> .Bar .Joe {
>> > >> color: green;
>> > >> }
>> > >>
>> > >> then we could compress down to:
>> > >>
>> > >> .x1 {
>> > >> color: red;
>> > >> }
>> > >>
>> > >> .x1 .x2 {
>> > >> color: green;
>> > >> }
>> > >
>> > >
>> > > Yeah that would require quite a lot of evaluation after parsing, if
>> > > that's
>> > > done maybe we should consider generating the CSS files at app.
>> startup
>> > > rather than at first request because that kind of processing would
>> > > most like
>> > > be O(n!) or O(x^n).
>> > I was thinking if a style is used anywhere else, period, we do not
>> merge
>> > that with another style. That is less processing, at least.
>> > Personally, I think doing the only-generated-compressed-styles
>> solution
>> > or (only-non-uncompressed) is enough to solve this problem for a
>> while.
>> > I think this merging solution is lower priority, and more of a
>> > nice-to-have. What does everyone else think?
>> > If there is another reason to do this, like performance, and we
>> know the
>> > impact, then that's another thing, but I'd like
>> > to focus on this issue and the solution right now -- especially since
>> > we've hit this limit.
>> > - Jeanne
>> >
>> >
>>
>>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Matt Cooper <ma...@gmail.com>.
That sounds like a reasonable first step to me since that would reduce the
size the most.
Thanks
On 1/31/07, Simon Lessard <si...@gmail.com> wrote:
>
> I agree, only one version compressed or uncompressed should be enough for
> a
> while.
>
> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> >
> >
> >
> > Simon Lessard wrote:
> > > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
> > >>
> > >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> > >> >
> > >> > > As Adam suggest, we could do some runtime evaluation during CSS
> > >> > > generation
> > >> > > and have many selector uses the same compressed selector, this
> > would
> > >> be
> > >> > a
> > >> > > 50% gain or so.
> > >> > I can do this, too, if we feel we have to. The logic flow will have
> > to
> > >> > change, of course.
> > >> > Right now we build the shortened style class map, then we generate
> > the
> > >> > css file.
> > >> > I'd have to either change the shortened style class map as I merge
> > >> > styles, or create it a bit later.
> > >> > It's no big deal, just more overhead when we create the file.
> > >>
> > >>
> > >> Maybe this goes without saying but we have to be careful when doing
> > this
> > >> so
> > >> that we only use the same selector when the containment definitions
> are
> > >> also
> > >> the same.
> > >>
> > >> If we just have:
> > >>
> > >> .Foo,
> > >> .Bar {
> > >> color: red;
> > >> }
> > >>
> > >> then this could be compressed down to:
> > >>
> > >> .x1 {
> > >> color: red;
> > >> }
> > >>
> > >> But if we have:
> > >>
> > >> .Foo,
> > >> .Bar {
> > >> color: red;
> > >> }
> > >>
> > >> .Foo .Joe {
> > >> color: green;
> > >> }
> > >>
> > >> .Bar .Joe {
> > >> color: blue;
> > >> }
> > >>
> > >> then we cannot use the same compressed name for Foo and Bar, we'd
> > >> compress
> > >> to:
> > >>
> > >> .x1,
> > >> .x2 {
> > >> color: red;
> > >> }
> > >>
> > >> .x1 .x3 {
> > >> color: green;
> > >> }
> > >>
> > >> .x2 .x3 {
> > >> color: blue;
> > >> }
> > >>
> > >> If we had:
> > >>
> > >> .Foo,
> > >> .Bar {
> > >> color: red;
> > >> }
> > >>
> > >> .Foo .Joe,
> > >> .Bar .Joe {
> > >> color: green;
> > >> }
> > >>
> > >> then we could compress down to:
> > >>
> > >> .x1 {
> > >> color: red;
> > >> }
> > >>
> > >> .x1 .x2 {
> > >> color: green;
> > >> }
> > >
> > >
> > > Yeah that would require quite a lot of evaluation after parsing, if
> > > that's
> > > done maybe we should consider generating the CSS files at app. startup
> > > rather than at first request because that kind of processing would
> > > most like
> > > be O(n!) or O(x^n).
> > I was thinking if a style is used anywhere else, period, we do not merge
> > that with another style. That is less processing, at least.
> > Personally, I think doing the only-generated-compressed-styles solution
> > or (only-non-uncompressed) is enough to solve this problem for a while.
> > I think this merging solution is lower priority, and more of a
> > nice-to-have. What does everyone else think?
> > If there is another reason to do this, like performance, and we know the
> > impact, then that's another thing, but I'd like
> > to focus on this issue and the solution right now -- especially since
> > we've hit this limit.
> > - Jeanne
> >
> >
>
>
Re: [Skinning] CSS selector limit hit in IE
Posted by Simon Lessard <si...@gmail.com>.
I agree, only one version compressed or uncompressed should be enough for a
while.
On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
>
>
>
> Simon Lessard wrote:
> > On 1/31/07, Matt Cooper <ma...@gmail.com> wrote:
> >>
> >> On 1/31/07, Jeanne Waldman <je...@oracle.com> wrote:
> >> >
> >> > > As Adam suggest, we could do some runtime evaluation during CSS
> >> > > generation
> >> > > and have many selector uses the same compressed selector, this
> would
> >> be
> >> > a
> >> > > 50% gain or so.
> >> > I can do this, too, if we feel we have to. The logic flow will have
> to
> >> > change, of course.
> >> > Right now we build the shortened style class map, then we generate
> the
> >> > css file.
> >> > I'd have to either change the shortened style class map as I merge
> >> > styles, or create it a bit later.
> >> > It's no big deal, just more overhead when we create the file.
> >>
> >>
> >> Maybe this goes without saying but we have to be careful when doing
> this
> >> so
> >> that we only use the same selector when the containment definitions are
> >> also
> >> the same.
> >>
> >> If we just have:
> >>
> >> .Foo,
> >> .Bar {
> >> color: red;
> >> }
> >>
> >> then this could be compressed down to:
> >>
> >> .x1 {
> >> color: red;
> >> }
> >>
> >> But if we have:
> >>
> >> .Foo,
> >> .Bar {
> >> color: red;
> >> }
> >>
> >> .Foo .Joe {
> >> color: green;
> >> }
> >>
> >> .Bar .Joe {
> >> color: blue;
> >> }
> >>
> >> then we cannot use the same compressed name for Foo and Bar, we'd
> >> compress
> >> to:
> >>
> >> .x1,
> >> .x2 {
> >> color: red;
> >> }
> >>
> >> .x1 .x3 {
> >> color: green;
> >> }
> >>
> >> .x2 .x3 {
> >> color: blue;
> >> }
> >>
> >> If we had:
> >>
> >> .Foo,
> >> .Bar {
> >> color: red;
> >> }
> >>
> >> .Foo .Joe,
> >> .Bar .Joe {
> >> color: green;
> >> }
> >>
> >> then we could compress down to:
> >>
> >> .x1 {
> >> color: red;
> >> }
> >>
> >> .x1 .x2 {
> >> color: green;
> >> }
> >
> >
> > Yeah that would require quite a lot of evaluation after parsing, if
> > that's
> > done maybe we should consider generating the CSS files at app. startup
> > rather than at first request because that kind of processing would
> > most like
> > be O(n!) or O(x^n).
> I was thinking if a style is used anywhere else, period, we do not merge
> that with another style. That is less processing, at least.
> Personally, I think doing the only-generated-compressed-styles solution
> or (only-non-uncompressed) is enough to solve this problem for a while.
> I think this merging solution is lower priority, and more of a
> nice-to-have. What does everyone else think?
> If there is another reason to do this, like performance, and we know the
> impact, then that's another thing, but I'd like
> to focus on this issue and the solution right now -- especially since
> we've hit this limit.
> - Jeanne
>
>