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, 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).
