It is acceptable to me. Perhaps you can create a JIRA for these kinds of
cleanups (and/or add a TODO to the code). This Skinning code has been
around and added to for many years, and could use a cleanup. I
definitely agree with the StyleContext and StyleProvider being linked.
That is really confusing.
Jeanne
Simon Lessard (JIRA) wrote, On 8/27/2008 1:17 PM PT:
[ 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.
