Hello Dainius,

1st, sorry for rusty english.

To be honest ...

I think the main problem [1] is not the number of CSS or JS files, it is the structure inside these files.

A lot of classes and ids are mixed up. Repeated attributes [2] the whole file along. The other problem i could think about is that everyone of the developer who knows a little about CSS is allowed to change the files and submit them to the core. The main task is to use "Cascade"-SS the right way, for example like [3].

There is a lot of potential in the current solution to (micro-)optimize the CSS.

For example a TOC like this one (e.g. like i do it - it maybe not the best solution but it helps a lot) ... and get rid of the messed up CSS. Use CSS the way it was designed for ...

/**
 * TABLE OF CONTENTS [TOC]
 *
 * =RESET / html5doctor.com Reset Stylesheet
 * =HTML5
 * =FONTS / YUI 3: CSS Fonts
 * =960GS / 960 Grid System
 * =BLOCK ELEMENTS / XHTML Block Elements
 * =BODY STYLES
 * =FONT SIZES / YUI 3: CSS Fonts
 * =TABLE ELEMENTS / XHTML Tables Module
 * =INLINE ELEMENTS / XHTML Inline Text Module
 * =LIST ELEMENTS
 * =HEADINGS / XHTML Headings
 * =LINKS / =ANCHORS
 * =FLOATS
 * =HEADER
 * =PAGE STRUCTURE
 * =TEXT STYLES / =TYPOGRAPHY
 * =NAVIGATION
 * =SKIPLINKS
 * =FORMS
 * =FOOTER
 * =IMAGES
 * =HELPER / =EXTRAS / =MISCELLANEOUS
 * =PRINT STYLES / @media print
 */

I'm sure there will be only 1000 lines left for the whole azure template.

But to get it right ... To change the number of files is just a step to the side and not one forward. To move forward the whole oxid CSS must be redesigned from scratch - and this step would implement the change of the whole HTML structure of the shop. Pure headaches :)

Problems with the look and feel editor (if i remember right) and so on ...

Best regards,
Eduard Seifert

[1] http://demoshop.oxid-esales.com/revamped-edition/community-edition/
[2] http://demoshop.oxid-esales.com/revamped-edition/community-edition/out/azure/src/css/elements.css
[3] http://www.slideshare.net/stubbornella/object-oriented-css


schrieb Dainius Bigelis:

Hi,

 

Currently we are working to improve the code and structure of CSS files.

Just we are not sure about one idea, that we want to implement, so we would like to ask you about your opinion regarding that.

 

Currently (in eShop 4.5.0 verson) we have ~10 css files, where one of these (elements) have ~4000 lines of code.

Making any change in that and maintain it became really difficult for developers.

 

So we thought that would be good to split this file to the smaller ones (according the type of elements) and change the structure of other files.

 

As a result of that would be 3-5 files according to the type of page (details page, list, checkout, main page…). These files would do nothing, just include the smaller css files for elements, which are really used used in this particular page.

The advantage of such structure:

-          Much more easy development/changes and maintenance;

-          Scalability of pages, as elements which are not needed in this page would not be loaded (i.e. elements used only in checkout would not be loaded in details page).

 

Disadvantage:

-          There are some ideas, that loading more files may reduce the performance. But we think that such effect may be noticed only during the first load of the page and then it is cached. But considering what we have now – it parses all the long (4k lines) file even of some big part of this is not needed in the page.

 

Also, one of solutions to work with smaller files and deliver one file as result – is to use the dedicated tools for compiling the css files into one during deployment.

 

So – please tell your ideas about this concept or any arguments for one or other solution.

 

Best regards,

Dainius Bigelis

 

 

_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general


_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general

Reply via email to