ConLite

  • Status Closed
  • Percent Complete
    100%
  • Task Type Feature Request
  • Category Frontend
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Low
  • Reported Version ConLite 1.0
  • Due in Version ConLite 2.0.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: ConLite
Opened by Ortwin Pinke - 08.08.2012
Last edited by Anonymous Submitter - 18.12.2012

FS#64 - CSS-Compressor

To optimize HTML-Output in frontend we will add a simple css-compressor which will put all named css-files into only one obfuscated/compressed css-file. This file will also be cached, so it will only be rebuild if one of the used css-files whave changed.

In the feature - next version of compressor - there will also be a possibility in module area of the backend to add custom css-files for modules and to set a priority of the files.

Closed by  Anonymous Submitter
18.12.2012 12:06
Reason for closing:  Implemented
Additional comments about closing:  

View the comments!

Anonymous Submitter commented on 16.12.2012 13:28

Opera says for the demo client's contenido_sample.css: without compression = 12,46 kB, with compression = 2,11 kB.
The compressor handles both css and js files and can be switched per client setting like this:

Type:    generator
Name:    output_compression
Value:   full / correct / off
         full = compress css and js files, link them in the head area (default)
         correct = move css and javascript file links to the head area
         off = no correction and compression (use for development only)

Both the full and correct setting place the links to the head section, which makes it possible to place those links in modules and module templates now.
Therefore, there is no need for special css and js areas with the modules.

Anonymous Submitter commented on 17.12.2012 18:14

Fixed a bug with CSS links in IE comment tags like <!–[if...
Switched off javascript compression in the /contenido/plugins/chains/inludes/include.chain.frontend.output_compressor.php because of problems with frameworks including files themselves (like js/scriptaculous.js?load=effects) and the swfobject class

Anonymous Submitter commented on 18.12.2012 12:02

When set to full:
- All stylesheet links not in IE conditional comments are put to the end of the head section, they are compressed to single files per media type.
- Then all stylesheets in IE conditional comments are put to the end of the head section, they are compressed to single files per media type too.
- And finally all javascript link tags (not javascript blocks) are put to the end of the head section, but they are not compressed, because this doesn't work in all browsers (Opera for example).
- The loading order stays the same, and doubles are not filtered out (caused problems in Opera).

When set to correct:
- All stylesheet links not in IE conditional comments are put to the end of the head section.
- Then all stylesheets in IE conditional comments are put to the end of the head section.
- And finally all javascript link tags (not javascript blocks) are put to the end of the head section.
- None of the files will be compressed, the loading order stays the same, and doubles are not filtered out (caused problems in Opera).

When set to off:
- All links keep their position, nothing is done. This way css and javascript links in modules and module templates stay in the body section, which isn't valid (X)HTML.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing