[
https://issues.apache.org/jira/browse/TRINIDAD-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626305#action_12626305
]
Simon Lessard commented on TRINIDAD-205:
----------------------------------------
It's true that an interface would be cleaner, but I don't know if such a
refactoring worth it at this time. I think the whole skin context / provider
API should be refactored as it contains some quite major irregularities. I
would gladly make it cleaner later and handle the selector count limitation in
a better way then.
Among other things, I see the following for issues:
1. The only way to access the current StyleProvider is to ask the StyleContext,
as if both where linked. However, the provider is close to stateless as all its
methods require a StyleContext instance to get the contextual information.
Personally, I think having the provider methods require the context is quite
nicely designed as it allow provider caching. However, I don't think the
StyleProvider instance should be accessible through the StyleContext, some
other third party class should handle that, maybe the render kit or the
rendering context?
2. Along the same line, I don't think getStyleMap belongs to StyleContext,
especially since it's more there as a facility method and I don't think those
should find their way in interfaces.
For those reasons, if the patch doesn't seem to break anything, I would prefer
commit it as it, saving me some time for now. Furthermore, since all those
classes are private, there's no backward API compatibility issues. Do you think
it's acceptable?
Regards,
~ Simon
> Need to avoid IE's number of CSS selectors limitation
> -----------------------------------------------------
>
> Key: TRINIDAD-205
> URL: https://issues.apache.org/jira/browse/TRINIDAD-205
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.0.1-incubating-core-SNAPSHOT
> Reporter: Jeanne Waldman
> Assignee: Simon Lessard
> Attachments: TRINIDAD-205.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
