Adam,
Thanks for the cleanup, it was on my list, but I wanted feedback before
progressing.
I've pulled down the sandbox containing the changes, but it fails to build.
The plugins are OK, but main trinidad tree fails. Suggestions welcome.
[INFO] Failed to configure plugin parameters for:
Folks,
Matthias and I are looking at this offline.
My faces-config.xml in $TRIN_HOME/trinidad-impl/target/classes/META-INF
is fine.
I even tested this jar and saw that my generated css file no longer has
unknown-version in it.
We are both on maven 2.0.4.
- Jeanne
Matthias Wessendorf 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
One more thing: what I really like about having
both the compressed and uncompressed style
classes is that when I see a class in the source,
I can figure out what the real .css style is.
Is there any way we could - at least in debug mode -
leave behind a .css comment with the original
class
I just commented out the offending entries in my pom.xml files and all seems
well now.
On 1/31/07, Danny Robinson [EMAIL PROTECTED] wrote:
Adam,
Thanks for the cleanup, it was on my list, but I wanted feedback before
progressing.
I've pulled down the sandbox containing the changes, but it
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.
As for not generating either compressed or uncompressed version depending on
a context parameter
I agree that the uncompressed version is useful to debug with Firebug, but
you can achieve just the same by setting compression to false, so I don't
see the need for a new debug option.
On 1/31/07, Adam Winer [EMAIL PROTECTED] wrote:
One more thing: what I really like about having
both the
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] 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
Hello Jeanne,
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
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%
On 1/31/07, Matt Cooper [EMAIL PROTECTED] wrote:
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] 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,
Simon Lessard wrote:
On 1/31/07, Matt Cooper [EMAIL PROTECTED] wrote:
On 1/31/07, Jeanne Waldman [EMAIL PROTECTED] 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
11 matches
Mail list logo
