Hi Dainius,
first i want to say i agree with most that was said before, especially about the sheer amount of css. I think the main goal is flexibility and clarity. So to me the idea of having separate files for different elements sounds good. For example, a javascript driven Element should have its own js and also css, like the superfish menu, so if you decide to use your own solution it can easily be removed. Right now its all buried in elements.css and gui.js. Also the files should be split by groups of pages, like one for detail and one for checkout. This would make it easier to take some pages/elements and use them in a different context or different layouts, or to remove certain elements. I also like the idea of loading these files during runtime, as it would make even clearer which files are used by a certain page. About one file vs many files performance: as css-files are only requested once and then cached, it sounds good to distribute this task among pages to reduce the loading size of the start page. If files are compiled into one, this file would have to contain everything again in order to be cached. So I agree that the performance gain of not loading unnecessary elements would outweigh the loss due to having several files. Also it would be easier to deliver minimized layouts that do not make use of many of the possible elements, like a start page that only contains a menu and a single slider, and in fact only needs a few lines of css. Regards, Grüße aus München, Frank Zunderer Von: [email protected] [mailto:[email protected]] Im Auftrag von Dainius Bigelis Gesendet: Donnerstag, 16. Juni 2011 15:44 An: [email protected] Betreff: [oxid-dev-general] Split CSS files to smaller ones 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
