Hi Simon, Adam,
Simon Lessard wrote:
Wow, another IE nasticity...
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.
As for not generating either compressed or uncompressed version
depending on
a context parameter value, I think it's a good idea as well.
Me, too. We could tie in debug mode to automatically not compress...
something I would
like to do anyway, because right now we have this 'internal' key to
disable compression,
although it is such a useful feature for people who are creating skins.
In the case where we don't compress, then we can't combined selectors.
Well, technically we can, but I'm sure you all already know that would
be too strange to do to
the skinning person.
I would also encourage a major reduction of private selectors usage as in
real world you always have to overload them anyway.
What do you mean?
Finally, does that restriction applies to IE 7 as well?
yes, it does. I primarily use IE7 now at work. I did try this on my IE6
on my home machine, and it occurs there, too.
Regards,
~ Simon
On 1/31/07, Adam Winer <[EMAIL PROTECTED]> wrote:
Having magic insider knowledge of the scenario where this
problem occurs :), one of the major causes of it is
using different keys for the same CSS rules. For example,
we use af|selectManyShuttle and af|selectOrderShuttle,
but they're basically the same thing. Merging the
compressed versions of those keys would be a major
win.
This is tricky for classes that are used in complex
selectors, but for classes that only show up in simple
selectors, we could potentially detect the match,
-- Adam
On 1/30/07, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Well, it turns out that IE has a limit to the size of a CSS file. It's
> not the actual size of the file, but rather it is the
> # of CSS selectors. I did a test and found out that the limit is 4095
> CSS selectors.
> Firefox doesn't appear to have a limit.
>
> As you may know, the CSS file we generate contains both compressed and
> uncompressed styles, like this:
> .af_inputText_content, .x01 {background-color: blue}
>
> Our renderers render a shortened styleclass, unless
> the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml,
then it
> renders the long styleclass.
> <input class="x01...>
>
> Ok, that's the background.
>
> *The problem* is that because we have a lot of custom components that
> we've built on top of Trinidad, and our customers
> have built custom components, etc, and these all have skinning,
> we have bumped up against the 4095 selector limit in IE. All selectors
> after the 4095th one are ignored.
>
> *A quick fix*, and probably a good one for a long time, is to
render the
> styles in compressed mode when compression is on,
> or in uncompressed mode when compression if off. That will reduce our
> style selectors by 1/2, and will help performance to boot. :)
> I can also add a warning if we go past 4095 selectors for IE.
>
> Another solution is to break up the file into multiple files when I've
> reached the limit in one file, and include
> all the css files into the rendered page. I can do this in addition to
> the quick fix when I have more time.
> Or, I'll be forced to do this solution if the above solution can't be
> done for some reason.
>
> Anyway, let me know what you think about the fixes. I'll start
> investigating it to make sure it is possible and won't break
> anything. My main concern was if people were using our public style
> classes, like styleClass=".AFInstructionText", but
> it looks like we compress these when we are in compressed mode.
>
> Let me know if there are other things I should check.
>
> Thanks,
> Jeanne
>
>
