Damyon Wiese (talk | contribs) |
Damyon Wiese (talk | contribs) |
||
| Line 25: | Line 25: | ||
The problem with this approach IMO is that adding specific classes to the HTML prevents themers from changing the presentation. It also combines logic about the presentation with the content (which CSS is supposed to avoid). | The problem with this approach IMO is that adding specific classes to the HTML prevents themers from changing the presentation. It also combines logic about the presentation with the content (which CSS is supposed to avoid). | ||
== Potential Solutions == | |||
I don't know exact what the best solution to this problem is yet but here are some early thoughts: | |||
CSS for a theme can be broken down: | |||
* Styling page elements (lists, forms, menus, headings, notices etc) | |||
* Layout (including responsiveness) | |||
* More...? | |||
How to proceed? (Braindump follows...) | |||
Start work on 2 new themes. Make each theme completely devoid of styles. Include the CSS for bootstrap in one theme and include the CSS for YUI Pure in another. | |||
For each page element, see if the HTML structure needs changing to work well with either CSS framework (an example here would be a label for a checkbox). Change the default renderer to do it the new way, add a legacy renderer to the base theme that does it the old way. Add a generic moodle prefix to each element. Maintain a master list of the moodle-prefixed elements (remove any other classes from the html). moodle prefixed class names should be generic, reusable, non-visual (e.g. moodle-notice, moodle-error). Use only one class for one purpose and elements can have multiple classes when appropriate. Build a list of page elements and the HTML they generate (either a wiki or a local module like totara). | |||
Use less to apply the CSS from the framework to the moodle classes via mixins (see if this works). | |||
For layouts - we need to provide a standard set of X responsive layout templates and change all pages in Moodle to use one of these layouts. The simplest would be one content region filling all the available space. This could be the default for all existing pages until they get updated. The naming for the layouts needs to be standardized. This would allow theme designers to meticulously design a fixed number of layouts and be sure that they have covered 100% of the pages in Moodle. A layout should define the number of content-regions, the relative sizes of each region and which regions are hidden/converted to menus/popups on smaller screen sizes. | |||
== Backwards Compatibility == | |||
Backwards compatibility is a must have requirement for themes in Moodle. Many people have spent a lot of money paying for custom themes and do not want to have to rewrite their themes on upgrade (Some small changes are acceptable if they are documented). To me this implies that we need to have a set of legacy renderers that renders HTML elements using the current structure/class names. This could be a setting in the theme. | |||
== Relevant Links == | == Relevant Links == | ||
Revision as of 02:34, 30 May 2013
Random Thoughts on a CSS framework in Moodle
Problem
Our CSS is huge, this makes it slow to download and hard to maintain. It makes it hard for themers to write nice themes and makes it hard to implement responsive designs.
Current approach to CSS
Plugin/Page author manually attaches classes to HTML elements. Some classes are added to base theme and expected to be used by all themes e.g. r0, r1. Some classes are defined in the modules style.css. Themers are then expected to add a more specific CSS rule to override the style. In addition, tweaks are applied to individual pages through the use of #pageid, but the CSS for these tweaks is included in every page. There is also some CSS buried in YUI modules for things like popup windows. And there is the CSS required for standard YUI Modules (upstream).
Whats wrong with this approach?
The total CSS required for each page is: TOTALSTYLESFORALLFORMELEMENTSINBASE+TOTALSTYLESFORCUSTOMTWEAKSFOREVERYPAGEINMOODLE+ORPHANEDSTYLESTHATNOONEKNOWSIFTHEYAREINUSE+MODULESTYLES+YUISTYLES+CUSTOMYUISTYLES (It looks worse if I write it like that)
Also - when working with CSS in Moodle it is impossible to know what is in all that CSS on any one page and the approach to working with the CSS resorts to:
- Load the page
- Inspect the element you want to change
- Craft a new very specific CSS rule and add it to the bloat
- Expect themers to find this new rule and add further tweaks
CSS Frameworks
There are several CSS frameworks available that aim to help with the above problems. The ones mentioned/used at Moodle so far are: Bootstrap and Pure (from YUI).
The approach of a framework is to have an optimised small set of CSS that provides enough features that responsive, attractive designs can be achieved directly in the html by using standardized html with specific classes.
The problem with this approach IMO is that adding specific classes to the HTML prevents themers from changing the presentation. It also combines logic about the presentation with the content (which CSS is supposed to avoid).
Potential Solutions
I don't know exact what the best solution to this problem is yet but here are some early thoughts:
CSS for a theme can be broken down:
- Styling page elements (lists, forms, menus, headings, notices etc)
- Layout (including responsiveness)
- More...?
How to proceed? (Braindump follows...) Start work on 2 new themes. Make each theme completely devoid of styles. Include the CSS for bootstrap in one theme and include the CSS for YUI Pure in another.
For each page element, see if the HTML structure needs changing to work well with either CSS framework (an example here would be a label for a checkbox). Change the default renderer to do it the new way, add a legacy renderer to the base theme that does it the old way. Add a generic moodle prefix to each element. Maintain a master list of the moodle-prefixed elements (remove any other classes from the html). moodle prefixed class names should be generic, reusable, non-visual (e.g. moodle-notice, moodle-error). Use only one class for one purpose and elements can have multiple classes when appropriate. Build a list of page elements and the HTML they generate (either a wiki or a local module like totara).
Use less to apply the CSS from the framework to the moodle classes via mixins (see if this works).
For layouts - we need to provide a standard set of X responsive layout templates and change all pages in Moodle to use one of these layouts. The simplest would be one content region filling all the available space. This could be the default for all existing pages until they get updated. The naming for the layouts needs to be standardized. This would allow theme designers to meticulously design a fixed number of layouts and be sure that they have covered 100% of the pages in Moodle. A layout should define the number of content-regions, the relative sizes of each region and which regions are hidden/converted to menus/popups on smaller screen sizes.
Backwards Compatibility
Backwards compatibility is a must have requirement for themes in Moodle. Many people have spent a lot of money paying for custom themes and do not want to have to rewrite their themes on upgrade (Some small changes are acceptable if they are documented). To me this implies that we need to have a set of legacy renderers that renders HTML elements using the current structure/class names. This could be a setting in the theme.
