css minification

[Andrei Alexandrescu via Digitalmars-d]

On 1/17/15 12:00 PM, Sebastiaan Koppe wrote:
> On Saturday, 17 January 2015 at 18:23:45 UTC, Andrei Alexandrescu wrote:
>> On 1/17/15 10:01 AM, Sebastiaan Koppe wrote:
>> I'm not an expert or an ideologist in the area. It was added by others
>> who obviously have a different opinion from yours.
> Well, then they should use http://zeptojs.com/

Of course. :o)

>>> why not compress the thing? It takes around 4 lines in
>>> apache conf to accomplish this. Give me SSH access and I'll do it in
>>> under 2 min.
>>
>> I'm working with our webmaster to create accounts for a few folks. For
>> now you may want to send me what needs to be done and I'll take it
>> with him. N.B. I vaguely recall I've tried that once but it was not
>> possible for obscure reasons.
> I do not know the obscure reasons, but it should be as simple as:
>
> nano /etc/apache2/mods-enabled/deflate.conf
>
> <IfModule mod_deflate.c>
>            # these are known to be safe with MSIE 6
>            AddOutputFilterByType DEFLATE text/html text/plain text/xml
>
>            # everything else may cause problems with MSIE 6
>            AddOutputFilterByType DEFLATE text/css
>            AddOutputFilterByType DEFLATE application/x-javascript
> application/javacript application/ecmascript
>            AddOutputFilterByType DEFLATE application/rss+xml
>            AddOutputFilterByType DEFLATE application/json
> </IfModule>
>
> I know I am imposing on somebodies else's work here, but compressing
> resources should really be done.

Forwarded to our webmaster, thanks.

>>> Caching is the next trick in the list. Remember that ISP's, proxy, etc.
>>> may also cache your files, not just browsers.
>>>
>> Where should these be cached? I don't understand.
> In the browser. So that on a reload of the page, the browser, instead of
> making HTTP calls, uses it's cache.

How do we improve that on our side?

>>> Next point on the list is bundling resources. The browser can only load
>>> some much stuff async. If you have too much, part of those resource are
>>> going to be blocked. Which basically means you have another round-trip +
>>> data that you have to wait for.
>>
>> Yah, we do a bunch of that stuff on facebook.com. It's significant
>> work. Wanna have at it?
> Yes. Please. But the compression thing takes precedence.

Awesome. Don't forget you said this.

> regex to select comments: /(\/\*[^(*\/)]+\*\/)/g
> regex to select whitespace: /(\s+)/g
>
> and then delete those.

Tested PR or by the end of the day this will slide into obsolescence.

> Design is a *very* touchy issue. It is basically a matter of choice.
> Without a definite choice made, I won't waste my time improving it.

It's clear that once in a while we need to change the design just 
because it's old. Also, there are a few VERY obvious design improvements 
that need be done and would be accepted in a heartbeat, but NOBODY is 
doing them.

I'm not an expert in design but I can tell within a second whether I 
like one. Yet no PR is coming for improving the design.

> The choice is very simple:
>
> keep it like it is,
> do what everybody else is doing

False choice.


Andrei