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 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).
I was thinking if a style is used anywhere else, period, we do not merge that with another style. That is less processing, at least. Personally, I think doing the only-generated-compressed-styles solution or (only-non-uncompressed) is enough to solve this problem for a while. I think this merging solution is lower priority, and more of a nice-to-have. What does everyone else think? If there is another reason to do this, like performance, and we know the impact, then that's another thing, but I'd like to focus on this issue and the solution right now -- especially since we've hit this limit.
- Jeanne

Reply via email to