The XHTML compliance has been going pretty well and is mostly done, thanks largely to Shane Elliott who has been slaving away over a hot computer beside me here at Casa Moodle.
The CSS is looming on the horizon as something that needs a good looking at. Some of it is currently a bit random, bitsy and hard to get into.
What can we do about making the CSS structure and naming easier to understand, more powerful and truly cascading? Personally I don't mind if pre-1.5 themes are broken in this upgrade - I would rather have a strong long-lasting design here that we can stick to as we expand in future.
Your ideas will be most helpful (particularly if you've implemented a large CSS design before).
It's hard to know what we're talking about without being able to see the XHTML that's being generated? Can we get Shane's work from CVS?
If the default template is going to be a header/3 column/footer based layout, Alex Robinson has a well-tested model that AlistApart have used with their Rounded Corners tutorial to produce a nice looking result (with some limitations)
As for naming and organising of CSS, there's heaps to be said... there was a pretty full-on discussion about this (separating formatting vs. layout in different files, order of style rules being alphabetical vs functional etc.) on the Web Standards Group email list a few weeks (months?) ago... is this the sort of info you are after (if so, i'll find it and post some of the worthwhile stuff).
I reckon as long as the classes and id's have meaningful names (such as class="block" and id="block_calendar"), it should be possible to organise (and order) all the style rules systematically so that they are easy to find and understand (or maybe I'm just not understanding the scope of the job!!)
If the default template is going to be a header/3 column/footer based layout, Alex Robinson has a well-tested model that AlistApart have used with their Rounded Corners tutorial to produce a nice looking result (with some limitations)
As for naming and organising of CSS, there's heaps to be said... there was a pretty full-on discussion about this (separating formatting vs. layout in different files, order of style rules being alphabetical vs functional etc.) on the Web Standards Group email list a few weeks (months?) ago... is this the sort of info you are after (if so, i'll find it and post some of the worthwhile stuff).
I reckon as long as the classes and id's have meaningful names (such as class="block" and id="block_calendar"), it should be possible to organise (and order) all the style rules systematically so that they are easy to find and understand (or maybe I'm just not understanding the scope of the job!!)
There will still be some basic tables for the basic page layout, so we won't have to break our heads and browsers on doing all that with CSS just yet.
All the code is currently in CVS HEAD, but there is almost nothing in the way of new styles yet - it all uses existing styles.
Yes, info about arranging style sheets and naming is exactly what I mean - that discussion would be helpful.
All the code is currently in CVS HEAD, but there is almost nothing in the way of new styles yet - it all uses existing styles.
Yes, info about arranging style sheets and naming is exactly what I mean - that discussion would be helpful.
Strange, I updated to CVS HEAD last night, and when I view the source of each page it still has:
Anyway, as for ordering/arrangement of CSS selectors in a CSS file, here's what Andy Budd had to say on the WebStandardsGroup list (hope it's helpful! took a lot of searching through the archives!):
Re: commonly used order of styles within a css class
By Andy Budd
Fri 03 Sep 2004 at 10:33 AM Sean wrote:
> Does anyone know if there is a common way of listing styles in CSS? I
> don't mean the order of a:hover a: visited, or the order of
> specification. I am thinking more of some logical order that would be
> helpful to anyone else working on stylesheets I have created.
Are you meaning in a micro or macro sense. i.e. how to structure sets of statement within a stylesheet or how to structure a set of declarations within a statement?
If it's the former there tend to be a couple of main ways. One is to group statements into logical types, such as all layout goes in one place, all text stuff in another. However I personally break this info into separate stylesheets as I find it easier to manage.
Another popular way is to structure stylesheets based on selector type, so you may have all element selectors first, then all id's and lastly all classes. I can see the logic behind this but it's not something I favour.
The way I tend to arrange statements is by position in the flow of the document. So I'll have all universal statements at the top, then statements relating to the header, nav, content and finally footer statements at the bottom. This works well for me, but I do often find that I'll need to add a new statement later that's the same of similar to one I already have. Rather than taking the original statement out and putting it up top with the universal statements, I tend just to tack a new selector on. This means that sometimes statements aren't always exactly matching the flow of the document. This is fine if you've only got one person working on the CSS, but would get confusing if you've got multiple people using the same file.
As for arranging declarations within a statement, because statements don't tend to be so long, I generally don't have a format. I simply put them in the order I write them in.
Andy Budd http://www.message.uk.com/
<html dir="ltr">without any doctype or character encoding etc. Is there something I need to do to switch it on? (Sorry for my ignorance! I should go and look through the files!
<head>
Anyway, as for ordering/arrangement of CSS selectors in a CSS file, here's what Andy Budd had to say on the WebStandardsGroup list (hope it's helpful! took a lot of searching through the archives!):
Re: commonly used order of styles within a css class
By Andy Budd
Fri 03 Sep 2004 at 10:33 AM Sean wrote:
> Does anyone know if there is a common way of listing styles in CSS? I
> don't mean the order of a:hover a: visited, or the order of
> specification. I am thinking more of some logical order that would be
> helpful to anyone else working on stylesheets I have created.
Are you meaning in a micro or macro sense. i.e. how to structure sets of statement within a stylesheet or how to structure a set of declarations within a statement?
If it's the former there tend to be a couple of main ways. One is to group statements into logical types, such as all layout goes in one place, all text stuff in another. However I personally break this info into separate stylesheets as I find it easier to manage.
Another popular way is to structure stylesheets based on selector type, so you may have all element selectors first, then all id's and lastly all classes. I can see the logic behind this but it's not something I favour.
The way I tend to arrange statements is by position in the flow of the document. So I'll have all universal statements at the top, then statements relating to the header, nav, content and finally footer statements at the bottom. This works well for me, but I do often find that I'll need to add a new statement later that's the same of similar to one I already have. Rather than taking the original statement out and putting it up top with the universal statements, I tend just to tack a new selector on. This means that sometimes statements aren't always exactly matching the flow of the document. This is fine if you've only got one person working on the CSS, but would get confusing if you've got multiple people using the same file.
As for arranging declarations within a statement, because statements don't tend to be so long, I generally don't have a format. I simply put them in the order I write them in.
Andy Budd http://www.message.uk.com/
Just a quick answer (I'm packing for Singapore) but you should switch your theme to "standardxhtml".
See also http://test.moodle.com which is running the same thing.
What was mentioned here about tacking statements on to the end is what I do too - it makes upgrades a lot easier but it also messes up any organisation.
See also http://test.moodle.com which is running the same thing.
What was mentioned here about tacking statements on to the end is what I do too - it makes upgrades a lot easier but it also messes up any organisation.
We could very easily keep the organization standard ignored during development and then reorder the CSS files once before each new Moodle version goes public. It wouldn't be too much work.
Not much work for you, maybe but I have 65-odd sites to upgrade every time there's a release, and most of them have custom themes.
I am using Matias_Lautaro flash theme at http://elearning.bangkaew.com/
From your discussion, I am not sure it will not have any effects when I upgrade to Moodle 1.5 , if so, I will wait until there are more themes for Moodle 1.5
I thought CVS update would take care of that...
Weeeee!!!! Now this is a subject dear to my heart!
About the tables: mainly the problems I have come accross with table-less CSS designs I have implemented start when you want to have a 3-column layout, but want to be able to "drop" one or both side columns when they don't have any content. This is easily done with JS, but to do it without JS requires a display logic that Moodle doesn't currently have.
However, I 'm not familiar with the specific technique Michael mentions above. I do believe that if it can display correctly when you just omit part of the HTML (one or both of the side block containing DIVs) then it would be good to use it.
About the tables: mainly the problems I have come accross with table-less CSS designs I have implemented start when you want to have a 3-column layout, but want to be able to "drop" one or both side columns when they don't have any content. This is easily done with JS, but to do it without JS requires a display logic that Moodle doesn't currently have.
However, I 'm not familiar with the specific technique Michael mentions above. I do believe that if it can display correctly when you just omit part of the HTML (one or both of the side block containing DIVs) then it would be good to use it.
Whilst CSS2 is capable of some really nice effects like Rounded Corners, Sliding Doors and Drop Shadows, templates that use any of these concepts will be difficult to alter without breaking the layout due to the fragility of floated elements and other cross-browser hacks. I think its easier to start people off with simple CSS concepts e.g. a very basic 3-column CSS template without to many graphical elements. This will ensure graceful degradation in problematic browsers like NS4 or IE5.
Since the majority of developers have only have a basic idea of the power of CSS it will be a steep learning curve if the default CSS template breaks as soon as you add an extra pixel of padding to a layout element.
I also agree that the main layout should be controlled by a flat table structure. This will prevent painful problems like content jumping around, unwrapped lines overflowing divs and 100% width tables breaking the layout. However all presentation from the layout table onwards should be handled by the CSS.
Since the majority of developers have only have a basic idea of the power of CSS it will be a steep learning curve if the default CSS template breaks as soon as you add an extra pixel of padding to a layout element.
I also agree that the main layout should be controlled by a flat table structure. This will prevent painful problems like content jumping around, unwrapped lines overflowing divs and 100% width tables breaking the layout. However all presentation from the layout table onwards should be handled by the CSS.
With the caveat that I've not looked at the latest 1.5 code yet, here are a few relatively simple things that I think could and should be done for 1.5:
use .css rather than .php files for stylesheets
The stylesheets are 99% straight CSS and so having them as .php may scare off designers and definitely does confuse many tools designed for pure .css files. The embedded php is used for only 2 things as far as I am aware:
- adding the server root to create absolute URLs
- importing colours from config.php
CSS can use relative links (with due respect to a very rare bug in a very rarely used older browser) so the first point is unnecessary. The second point leads me straight into my next recommendation:
we should remove config.php entirely
config.php supplies colour values that are inserted into the HTML (and also, semi-redundantly, included into the .CSS). While there is a sliver of a valid reason for keeping this for extreme backwards compatibility I think it would be better to junk it completely. It also sets a value concerning custom images. If these were set in CSS then they could be overridden by a theme's CSS too without troubling the PHP engine.
Note that I've tried to create themes that don't rely on config.php but as of 1.4 there are sections of the HTML that don't have the required id and class 'hooks' to attach styles to them, so you can't override or replace colours specified in the config.php file. Which brings me to:
add more style hooks in the form of class and id attributes
Even without changing the substance of the current HTML, the addition of semantically chosen id and class attributes would open up a world of styling opportunities. An example that I filed as a bug (which might be fixed already) is to id the three main columns so that blocks on the left and right hand side of the screen can adopt mirrored (or simply different) styles. Another that I keep tripping over is the desire to target styles at the content of text resources.
swap tables for lists
There are a lot of tables in Moodle's layout. I have no real problem with the larger layout tables, though they could be trimmed to their bare minimum. On the other hand, many of the smaller tables could be replaced with unordered lists which can be styled with much greater ease. Basically the more tables replaced the better, but I think if we start with the smallest and work our way up we'll get the biggest bang for buck.
no inline styles
Inline styles in attributes are the modern equivalent of font tags and should be removed, without exception, in favour of semantic classes or ids and the relevant CSS style moved to the stylesheet.
Hi!
I just installed moodle on a server and tried to make some design changes.
I did a lot of css web sites in the past and just hope that moodle will completely use
I just installed moodle on a server and tried to make some design changes.
I did a lot of css web sites in the past and just hope that moodle will completely use
-tags instead of the table layout in the future.
It also would be cool as a first step if all the inline formatting (e.g.: table cell-spacing, padding, text formatting, ...) would be inside the css file.
It is actually not too hard to change that. I started doing those changes in the variuos php files. It is just about defining some basic classes for text and table elements and deleting all the tags in the php code. That would help a lot. I don't care much about rounded corners and other complicated css tricks - I would be glad if I could make some global design changes in order to create a stringent design.
The basis for that work should be a style guide that defines all the elements that appear (Headlines, Labels, Copy, Buttons, Images, ...), this could also help creating a css files that user understand.
Right now even the hard-coded style stuff is not the same on all pages, tables have different attributes.
I am happy to doing some of the work and really would love to see the next version of Moodle.
best regards from Germany
Sebastian
It also would be cool as a first step if all the inline formatting (e.g.: table cell-spacing, padding, text formatting, ...) would be inside the css file.
It is actually not too hard to change that. I started doing those changes in the variuos php files. It is just about defining some basic classes for text and table elements and deleting all the tags in the php code. That would help a lot. I don't care much about rounded corners and other complicated css tricks - I would be glad if I could make some global design changes in order to create a stringent design.
The basis for that work should be a style guide that defines all the elements that appear (Headlines, Labels, Copy, Buttons, Images, ...), this could also help creating a css files that user understand.
Right now even the hard-coded style stuff is not the same on all pages, tables have different attributes.
I am happy to doing some of the work and really would love to see the next version of Moodle.
best regards from Germany
Sebastian
I agree with almost all of this 
, but the problem I'm having is coming up with a consistent extensible way of naming and storing all these hundreds of new styles.
Sometimes it difficult to know when to use the same class and when not to. For example, many of these boxes around Moodle currently use generalbox, which means changing that one style changes things consistently all over (which is good), but I guess we need a nice way of overriding individual instances via id or something.
We need a small set of simple rules that all coders can keep in their head when writing CSS hooks into new (and existing) XHTML code so that it stays consistent.
Sometimes it difficult to know when to use the same class and when not to. For example, many of these boxes around Moodle currently use generalbox, which means changing that one style changes things consistently all over (which is good), but I guess we need a nice way of overriding individual instances via id or something.
We need a small set of simple rules that all coders can keep in their head when writing CSS hooks into new (and existing) XHTML code so that it stays consistent.
It's quite legal to write class="generalbox alertbox" so that you can create an "alert" box without having to manually keep the CSS for generalbox and alertbox synchronized at source level.
So for example, the theme can specify that all boxes have borders and rounded corners, but that alert boxes have red background and really big titles (".alertbox .title { ... }") while keeping the CSS for those two independent. Use of classes can be quite enabling in this way, but we must take care not to overdo it.
IDs should be used even less than classes, but we should keep in mind that IDs provide nice hooks for all sorts of things in JS too. Thus, attaching an ID to anything that, well, can be easily identified
(like "Course section 0"). There could well be some items which have IDs defined but no specific CSS.
Also, CSS should not be seen as completely detached from HTML which I think is happening here. There are lots of selectors beside ID and class, but to use them effectively requires semantically correct markup (in addition to syntactically correct, of course). Example:
Suppose we want to have a form (that would be a table) with one field per row, two colums: field name and field value (some kind of edit box in here). To make the names left aligned and bold (sounds quite plausible, I do it all the time):
<table class="inputform">
<tr><th>Name of field:</th><td>Edit box here</td></tr>
</table>
You can then set ".inputform th {text-align: right; font-weight: bold;}" to achieve the desired effect. Unfortunately, this wouldn't be extremely farsighted. Even better would be:
<table class="inputform"><tbody>
<tr><th>Name of field:</th><td>Edit box here</td></tr>
</tbody></table>
so we now use the selector ".inputform tbody th { ... }" but also have the option to put a <thead><tr><th>Some Input Form</th></tr></thead> in there without trouble.
My point is, ANYTHING that can be used in CSS selectors (tag names, classes, IDs, even the structure of the tag hierarchy in the HTML) should be considered when we are discussing CSS.
So for example, the theme can specify that all boxes have borders and rounded corners, but that alert boxes have red background and really big titles (".alertbox .title { ... }") while keeping the CSS for those two independent. Use of classes can be quite enabling in this way, but we must take care not to overdo it.
IDs should be used even less than classes, but we should keep in mind that IDs provide nice hooks for all sorts of things in JS too. Thus, attaching an ID to anything that, well, can be easily identified
(like "Course section 0"). There could well be some items which have IDs defined but no specific CSS.Also, CSS should not be seen as completely detached from HTML which I think is happening here. There are lots of selectors beside ID and class, but to use them effectively requires semantically correct markup (in addition to syntactically correct, of course). Example:
Suppose we want to have a form (that would be a table) with one field per row, two colums: field name and field value (some kind of edit box in here). To make the names left aligned and bold (sounds quite plausible, I do it all the time):
<table class="inputform">
<tr><th>Name of field:</th><td>Edit box here</td></tr>
</table>
You can then set ".inputform th {text-align: right; font-weight: bold;}" to achieve the desired effect. Unfortunately, this wouldn't be extremely farsighted. Even better would be:
<table class="inputform"><tbody>
<tr><th>Name of field:</th><td>Edit box here</td></tr>
</tbody></table>
so we now use the selector ".inputform tbody th { ... }" but also have the option to put a <thead><tr><th>Some Input Form</th></tr></thead> in there without trouble.
My point is, ANYTHING that can be used in CSS selectors (tag names, classes, IDs, even the structure of the tag hierarchy in the HTML) should be considered when we are discussing CSS.
I agree it would be nice to remove theme/config.php, but you have to admit it's very powerful to be able to change a few values in a file and get the whole site to change in appearance.
I want Moodle 1.5 to allow users to define color sets for themselves for greater contrast or effect etc without needing to edit enormous stylesheets with hundreds of references to the same colours over and over.
Is there any trick to create named variables in CSS? That would be ideal!
Maybe we need a wizard script that takes basic colour parameters and dumps straight CSS for each user?
I want Moodle 1.5 to allow users to define color sets for themselves for greater contrast or effect etc without needing to edit enormous stylesheets with hundreds of references to the same colours over and over.
Is there any trick to create named variables in CSS? That would be ideal!
Maybe we need a wizard script that takes basic colour parameters and dumps straight CSS for each user?
Config.php caused me A LOT of problems. First of all, because the various categories were named inaccurately. Secondly, because it is not at all easy to see what they effect until you actually change them and poke around in Moodle. Personally, I would prefer to see this file done away with and everything be in individual classes that are appropriately named. Even if it means changing a lot more things, it gives one a better idea what one is changing.
And Martin, I'm with you about sticking with tables. I've seen so many snooty posts all over the internet about how tables are old school and one should "get with the program" and do layout in CSS. Out with the old, and in with the new is the theory. And then I see a lot of sites where they use CSS and the layout looks awful because things don't get placed as they are supposed to and you can't even read things properly because text is overlapping or background colors are in the wrong place. And I've seen this on big, well-funded commercial sites that should do better. Tables do the trick well. Purists say that tables weren't originally intended for layout, but hey, Viagra was originally a heart drug and look what it is used for now!
And Martin, I'm with you about sticking with tables. I've seen so many snooty posts all over the internet about how tables are old school and one should "get with the program" and do layout in CSS. Out with the old, and in with the new is the theory. And then I see a lot of sites where they use CSS and the layout looks awful because things don't get placed as they are supposed to and you can't even read things properly because text is overlapping or background colors are in the wrong place. And I've seen this on big, well-funded commercial sites that should do better. Tables do the trick well. Purists say that tables weren't originally intended for layout, but hey, Viagra was originally a heart drug and look what it is used for now!
I think the php referring back to colours in config.php has actually made the CSS more complicated because it makes it too easy to repeat the same value in many places. In CSS you should only have to define a colour once per 'design decision'. I'm not sure it's obvious what I mean by that, I'll try to demonstrate:
Currently (as of the last time I looked at styles.php) each 'thing' defines it's styles separately e.g.
.thing1 {
color: pink;
}
.thing2 {
color: pink;
}
If, and only if, these are both pink for the same reason, and it would make sense to change one when you change the other then this is more appropriate:
.thing1, .thing2 {
color: pink;
}
Obviously this expands so that every item that is pink (for the same reason) is set together in a single style declaration. Therefore there is a single place to change each decision about color, font, border etc. I went through and redid one of the standard themes in this way. I'll see if I can find the file and you can compare them.
I can't seem to locate that file but compare these snippets, noting the repetition of the first and how the second gives a better idea of the theme design by making the shared styles explicit:
.sideblockmain {
background-color: #FEF9F6;
-moz-border-radius-bottomleft: 20px;
-moz-border-radius-bottomright: 20px;
}
.sideblocklinks {
background-color: #FEF9F6;
}
.sideblocklatestnews {
background-color: #FEF9F6;
-moz-border-radius-bottomleft: 20px;
-moz-border-radius-bottomright: 20px;
}
.sideblockrecentactivity {
background-color: #FEF9F6;
-moz-border-radius-bottomleft: 20px;
-moz-border-radius-bottomright: 20px;
}
with
.headingblock, .generalbox,
.sideblock, .outlineheadingblock,
.forumpost, .siteinfo,
.generalbox, .noticebox
{
border-width: thin;
border-color: #eef;
border-style: solid;
}
.headingblock,
.navbar,
.generaltableheader,
.sideblockheading,
.outlineheadingblock
{
background-color: #eef;
}
.topicsoutlineside
{
background-color: #a0a0ff;
}
.topicsoutlinecontent
{
border: 3px solid #a0a0ff;
background-color: #e6e6ff;
}
Very very nice proposal, I second that motion!
Note that we could simplify the above by using multiple classes per item as I mention somewhere above, class="generalbox forumpostbox" would both allow more fine grained control and allow us to remove the ".forumpost" selector here.
To borrow a page from Sebastian below: since we can also split properties for the same selectors across different CSS files, themes can be split to:
Note that we could simplify the above by using multiple classes per item as I mention somewhere above, class="generalbox forumpostbox" would both allow more fine grained control and allow us to remove the ".forumpost" selector here.
To borrow a page from Sebastian below: since we can also split properties for the same selectors across different CSS files, themes can be split to:
- Allow Martin's "Color Schemes" (include one CSS file for the layout, and another for the colors; changing just the second and voila, there's your new color scheme)
- Allow novice CSS users to edit basic stuff without going into deep waters (everyone should be able to figure out how the "color scheme CSS" works to change the colors in their site; more advanced formatting can be in the "theme CSS" and warnings given)
I would hope we'd be using multiple style sheets. At a minimum having one for print media and import one for the targeted browsers.
But it would be really grand if we had a "layout stylesheet" we could customize, plus "appearance stylesheets" that could be customized by a script wizard, and the ability to join specific course id's with specific stylesheets.
Maybe it's wishful thinking, but it would let us get rid of config.php (or let us use it for other purposes).
But it would be really grand if we had a "layout stylesheet" we could customize, plus "appearance stylesheets" that could be customized by a script wizard, and the ability to join specific course id's with specific stylesheets.
Maybe it's wishful thinking, but it would let us get rid of config.php (or let us use it for other purposes).
Agree on most parts. Disagree on:
- No inline styles
Putting everything in the css will definitely be overkill. There are lots of places where inline styles are OK IMHO, such as configuration screens where you want to achieve a specific layout etc. They should be reduced, definitely, but not banned.
Martin, I think you r idea about reforming CSS is very good, and many others have already posted interesting considerations.
There is one I would add: in my opinion currently Moodle's css suffers of too many style definitions keeping it difficult to deal with, and, of course this situation may lead to contrast one of the "rule" of graphic layout: Repetition.
While an extensive css style definition allow for a extreme customization, it also may lead to inconsistent layout, thus weakening the whole interface.
Would it be a bad idea to heavely shrink the css rules identifing only those really necessary, starting from a interface layout point of view?
How would having an inconsistent layout weaken the Moodle interface? One of the big drawbacks of Moodle (for some institutions anyway) is the difficulty in integrating the look and feel of it into their existing web presence. The flexibility gained by having more css id's and classes addresses this issue and moves Moodle that much further ahead of any other LMS.
The downside to having more css is that it takes more competency with stylesheets to manage a lot of definitions. However, users need not be forced to customize their sites with css. One can always use the default styles and just change a few properties at a time. They can even use a previous template based on a table layout if they want.
To my thinking (and I realize it is just an opinion) using a smaller set of css rules limits the flexability for those wanting more customization, and it adds unnecessary coding for those who'd prefer to stick to the default table layout.
My 2¢
The downside to having more css is that it takes more competency with stylesheets to manage a lot of definitions. However, users need not be forced to customize their sites with css. One can always use the default styles and just change a few properties at a time. They can even use a previous template based on a table layout if they want.
To my thinking (and I realize it is just an opinion) using a smaller set of css rules limits the flexability for those wanting more customization, and it adds unnecessary coding for those who'd prefer to stick to the default table layout.
My 2¢
There could actually be two CSS files. One with basic adjustments and one for advanced users.
Dennis, I agree with you about the diffculty to make heavy change on Moodle layout.
When I talk about "inconsistency" I does not mean that Moodle loose its layout: what I would mean is allow Moodle use the same CSS definitions for the very same interface elements across all Moodle pages.
In this way the interface could look more "consistent" since everywhere a header looks like a header, a subheader looks like a subheader and so on. To do this I think, (but this is a opinion, maybe I can be wrong) there could be no need for huge CSS definitions and in this way "Repetition" could be more easely obtained. Of course the idea of two CSS, one basic and one advanced, could be good for those who want extreme customizations.
Another opinion I would add, is to create CSS rules to better satisfy another graphic layout rule: "Alignment". Currently Moodle uses good alignment, but this "design decision" is not "consistent" over all the pages and current theme/css system does not allow to change this since there are <center> tags embedded in the code.
Just my two cents from a design point of view.
I think Andrea makes a good point. Consistency and legibility is hard to achieve with the current system. Part of the problem is the inability to get a good preview of everything. I keep coming across bad color combinations because the classes are combined in such a way (and probably combined with config.php settings) as to make bad combinations. For instance, text that doesn't have enough contrast with the color behind it. And I can't tell you how many times in my Moodle there is text that isn't appearing at all-it's white, and unless I put my mouse over it to highlight it-the text isn't visible at all. Then I have to make some hack somewhere to correct this.
That's relatively straightforward to fix. If we get rid of the colours in config.php (and those that are hard-coded in the HTML) then all the colours will be defined in the CSS. If you then run the CSS through a basic accessibility checker it will warn you if you define a text colour without an accompanying background colour.
hello all,
when martin started this discussion here i collected my snippets and links and made the graphics for my proposal of a possible moodle page layout. i have been working on it for my own moodle design and was looking foreward to the chance to enhance the usability of the moodle css. please have a look at the moodle wiki pages http://moodle.org/mod/wiki/view.php?id=2935&userid=0&groupid=0&wikipage=CSS_Statements_uHunkler
I started a wiki branche [Reforming the CSS] in the developer wiki, because I think we should collect the results of the discussion here in the wiki. in the wiki they can be structured and can still be edited. I have good experriences working with wikis.
what do you think abot my proposal?
urs
when martin started this discussion here i collected my snippets and links and made the graphics for my proposal of a possible moodle page layout. i have been working on it for my own moodle design and was looking foreward to the chance to enhance the usability of the moodle css. please have a look at the moodle wiki pages http://moodle.org/mod/wiki/view.php?id=2935&userid=0&groupid=0&wikipage=CSS_Statements_uHunkler
I started a wiki branche [Reforming the CSS] in the developer wiki, because I think we should collect the results of the discussion here in the wiki. in the wiki they can be structured and can still be edited. I have good experriences working with wikis.
what do you think abot my proposal?
urs
Wiki: good
CSS: good
Using CSS wisely: Very Good
Personally, I would love it if we ended up with a lot of flexibility and simplicity. I guess finding the right balance to suit most users' needs is the tricky part.
I think it's also important to get the selectors, naming convention, and guidelines all established first and then apply them to a default layout for Moodle - rather than designing a new default layout first and basing the guidelines and conventions on what was used to create that one.
My most favored example of this is the CssZenGarden pages. (Who says the navigation should be on the left anyway?)
I'll be watchin' for the wiki
CSS: good
Using CSS wisely: Very Good
Personally, I would love it if we ended up with a lot of flexibility and simplicity. I guess finding the right balance to suit most users' needs is the tricky part.
I think it's also important to get the selectors, naming convention, and guidelines all established first and then apply them to a default layout for Moodle - rather than designing a new default layout first and basing the guidelines and conventions on what was used to create that one.
My most favored example of this is the CssZenGarden pages. (Who says the navigation should be on the left anyway?)
I'll be watchin' for the wiki
hello all,
in the developer wiki I started two new pages for the dicussion on "Module and block collection for naming" (just two lists) and "Structure of the CSS File(s)" for the very important aspects of the way how the CSS files are build and the CSS is coded.
In this forum you have already written many thoughts, aspects, proposals. For further discussion and decisions we could collect them in the wiki with the advantage to build up a working base for the implementation of the template and CSS files. And a base for the documentation for later easyer handling of the moodle layout.
It's wiki style to just work into the existing pages - to add, to supplement, to change - if necessary everything. Perhaps you know, every page version is stored in a database, so every step is documented, every mistake can easily be undone.
Can you envision the wiki way to be the way for the development of the CSS for moodle 1.5?
I'm very intrestet in your opinions
urs
in the developer wiki I started two new pages for the dicussion on "Module and block collection for naming" (just two lists) and "Structure of the CSS File(s)" for the very important aspects of the way how the CSS files are build and the CSS is coded.
In this forum you have already written many thoughts, aspects, proposals. For further discussion and decisions we could collect them in the wiki with the advantage to build up a working base for the implementation of the template and CSS files. And a base for the documentation for later easyer handling of the moodle layout.
It's wiki style to just work into the existing pages - to add, to supplement, to change - if necessary everything. Perhaps you know, every page version is stored in a database, so every step is documented, every mistake can easily be undone.
Can you envision the wiki way to be the way for the development of the CSS for moodle 1.5?
I'm very intrestet in your opinions
urs
I've attached a zipped up copy of a slight modification of the standardxhtml theme.
This modified theme:
- uses styles.css rather than styles.php (converting styles.php to functionally equivalent .css was a relatively simple step involving some find and replace in vim)
- moves all Mozalla specific moz- styles (e.g. rounded corners) to moz.css since these won't validate
- adds a link to validate all linked styles (inc. HTMLArea and moz.css) and one to validate just styles.css
- has some minor fixes to the CSS so that it validates
That's all fairly self-explanatory. The theme also sets all the colors in config.php to #ff00ff (a bright purple). This shows where colors are defined in config.php rather than in the CSS. Wherever this purple colour shows through, the CSS should be extended to fix it. In some cases this just involves changes to the CSS but some of the places do not have sufficient semantic style hooks in the HTML.
Don't be confused by the patches of purple. This is purely because of the settings in config.php and has nothing to do with any of the other changes. Before I changed config.php, the new theme looked identical to the standardxhtml theme.
I haven't yet reorganized the CSS as shown in my previous post but I intend to do so.
potential future plans, apart from the above:
- split style.css into moodle.css (basic structure, overwritten on upgrade maybe?) and theme.css (simple user customisation).
- transfer a small number of different looking themes to use the same basic structure
Two other issues/bugs:
how do you go about validating pages that need a login? All I get is the redirection page as the validator tries to access a page it isn't allowed to see without an account.
The doctype declaration is in header.html, some of the error messages are outputted before the doctype, which should be the first thing on any page.
Hi guys,
I have a couple of problems, but before I get to that, let me explain my situation:
I have been evaluating Moodle as a solution for the online courses at the School of Computer Science at Florida International Univeristy.
As mentioned before in this thread, we want to create a look and feel that would make our users identify better with the system.
I have had success so far in changing the config.php and styles.php to create a new theme. The problem I'm having is that in some cases, there is no class associated with the content displayed, which requires me to change the css for general html tags such as "a" or "td". That causes the whole site to change, and I am forced to come out with a color that will suit both places.
Is there any way to solve this without modifying base code?
Take for example the login box or the file browser. they all display a standard table, with the gradient.jpg on top but no css class associated with it. The font color is not appropriate in our case because our gradient.jpg is dark. So it's kind of Black-on-Black. If we change the font color to a lighter color, it does not display properly against the white background of the content boxes.
get the Idea?
It just goes around and around... Looks good here, Looks bad somewhere else deep inside the system.
Any pointers are greatly appreciated
I have a couple of problems, but before I get to that, let me explain my situation:
I have been evaluating Moodle as a solution for the online courses at the School of Computer Science at Florida International Univeristy.
As mentioned before in this thread, we want to create a look and feel that would make our users identify better with the system.
I have had success so far in changing the config.php and styles.php to create a new theme. The problem I'm having is that in some cases, there is no class associated with the content displayed, which requires me to change the css for general html tags such as "a" or "td". That causes the whole site to change, and I am forced to come out with a color that will suit both places.
Is there any way to solve this without modifying base code?
Take for example the login box or the file browser. they all display a standard table, with the gradient.jpg on top but no css class associated with it. The font color is not appropriate in our case because our gradient.jpg is dark. So it's kind of Black-on-Black. If we change the font color to a lighter color, it does not display properly against the white background of the content boxes.
get the Idea?
It just goes around and around... Looks good here, Looks bad somewhere else deep inside the system.
Any pointers are greatly appreciated
Basically you can't do that everywhere yet as several design decisions are hard-coded into the HTML and can't be overwritten in CSS. This will hopefully change in the next version.
However, it should be possible to change the text color for most headers without effecting the text color of the content. Could you post the CSS or styles.php changes you've made to give a better idea of what you're trying to do?
You can change the links with more precision than just "all a tags" even without individual class definitions for the a tag. Say you want to have a dark top bar, for example, then you could have blue links on the body and white links on the top bar like so:
<style>
a { color: blue; }
.topbar a {color: white; }
</style>
You can change a:hover and so on similarly.
<style>
a { color: blue; }
.topbar a {color: white; }
</style>
You can change a:hover and so on similarly.
I've been having a look at the more recent CVS code and update my list of possible and desirable changes that I'd like to see for 1.5
remove all font tags
I was kind of surprised to see these still here. They don't really affect the XHTML-ness of the code, but they generally send the wrong signal and are an accessibility problem. They fall into three broad categories, hard coded colors (e.g. red for error), hard coded text sizes, or hard coded fonts. It's a relatively simple mechanical task to get rid of them e.g. red color -> <em class="error">
remove all inline CSS using style="" attributes
I think someone objected to this when I mentioned it earlier. I really can't think of one good reason for doing this and the examples seen when running grep -R "style=" . should almost certainly all be rationalised and moved to the CSS.
remove reliance on config.php for defining colors
This needs only a few changes to the code here and there. The theme I've attached outlines these in bright purple. The main code is okay in this regard, it's just bits and bobs within the activities. To fix this more semantic HTML and id and class hooks for CSS need to be added to the unstylable sections.
remove all th, thead, tbody etc. tags that are not used for tabular data
This appears to have been done for the right reasons, but isn't really appropriate. See Joe Clark's Building Accessible Websites Chapter 10: Tables and Frames, "what not to do" for more.
minimise the number of tables used for positioning
The theme I've attached also attempts to eliminate tables from the header (untested with Internet Explorer as yet, so it probably breaks horribly).
Hi David,
Thanks for the reply, I found the cause of my problems. I was mistakenly overriding every font in the system because I was setting it in the general "font" class in styles.php.
So that problem is solved. BTW: if any of you guys want to take a look at the site just go to www.cs.fiu.edu/online/courses . it is still in very early experimental stage, we're working on the theme and trying to achieve some of the look and feel of our home site www.fiu.edu . if everything goes well we should have it running soon.
I totally agree with your suggestions and by what I have been reading, we should have some great surprises by the time 2.0 comes around. Until then, we can use some of our own "constructivism" and hack it ourselves.
Thanks again,
Eduardo
hello david,
i agree in all points.
but you cannot start removing parts in the templates without adding the style definitions to the css.
the steps - as i see them - are:
1| set up a naming scheme and achieve agreement with the developers
2| define the framework of the pages to get the necessary styling hooks (tables and divs with ids and classes determined in 1|)
3| decide about the strukture of the css files (1 css file + config.php, 2 css files, 2 css files + non standard css, etc.)
4| rework the css files to meet the decided structure
5| remove the formating (font tags, inline styles) in the templates (php and html) and add the formating as css definitions to the css files
6| build new themes to reflect the extended possibilities
7| write a documentation with two levels: a) all the basics needed to adjust the styling for simple changes b) detailed descriptions for advanced design changes
8| create a moodle course about styling moodle???
urs
i agree in all points.
but you cannot start removing parts in the templates without adding the style definitions to the css.
the steps - as i see them - are:
1| set up a naming scheme and achieve agreement with the developers
2| define the framework of the pages to get the necessary styling hooks (tables and divs with ids and classes determined in 1|)
3| decide about the strukture of the css files (1 css file + config.php, 2 css files, 2 css files + non standard css, etc.)
4| rework the css files to meet the decided structure
5| remove the formating (font tags, inline styles) in the templates (php and html) and add the formating as css definitions to the css files
6| build new themes to reflect the extended possibilities
7| write a documentation with two levels: a) all the basics needed to adjust the styling for simple changes b) detailed descriptions for advanced design changes
8| create a moodle course about styling moodle???
urs
to point 1|
in the desveloper wiki i started to collect the necessary informations to be able to build up a naming scheme.
who are the persons to decide about it - it's martin. And other developers?
_ who are they?
_ how are such decisions made in the moodle developer community?
urs
in the desveloper wiki i started to collect the necessary informations to be able to build up a naming scheme.
who are the persons to decide about it - it's martin. And other developers?
_ who are they?
_ how are such decisions made in the moodle developer community?
urs
to point 2|
david and i discussed the framework of the pages in the wiki. i've got the impression, that we agree in most points. so i'll draw new diagramms, to show the actual state. on that basis we, martin and the responsible persons can decide about them.
is that ok for everyone?
urs
david and i discussed the framework of the pages in the wiki. i've got the impression, that we agree in most points. so i'll draw new diagramms, to show the actual state. on that basis we, martin and the responsible persons can decide about them.
is that ok for everyone?
urs
to point 3|
discussion needed.
i think it would be very helpfull to collect the possible versions and describe the individual advantages and disadvantages. possibly in a table in the wiki, so everybody can contribute directly with his version and arguments? on this base we can more easyly and faster come to a decision.
urs
discussion needed.
i think it would be very helpfull to collect the possible versions and describe the individual advantages and disadvantages. possibly in a table in the wiki, so everybody can contribute directly with his version and arguments? on this base we can more easyly and faster come to a decision.
urs
to points 4 and 5
as i see it for the work on point 4 and 5 the decisions of point 1 to 3 have to be made. in the meantime we can collect ideas and code snippets.
_ after point 1 to 3 are decided, point 4 and 5 can be worked off
do you agree?
urs
as i see it for the work on point 4 and 5 the decisions of point 1 to 3 have to be made. in the meantime we can collect ideas and code snippets.
_ after point 1 to 3 are decided, point 4 and 5 can be worked off
do you agree?
urs
to point 6 to 8
these point i see as "nice to have" and future musik
urs
these point i see as "nice to have" and future musik
urs
Well, since there is no doubt that CSS will get a major overhaul, I would like to suggest something:
How about a simple web-based config, just like in the other modules, that would edit that(those) very powerful css file(s) and make it simple for the regular user. Developers could dig straight into the file(s) and make the changes right there.
This way, it would address both sides, CSS and non-CSS people.
(cling, cling) <-- my 2 cents
hello eduardo,
great idea. if i get it right you propose to bring the functionality of the config.php to a web interface. the php-engine would handle all the replacments in some standard themes (which must not be changed by hand).
with this approach the easy configurable css file would be unnecessary.
urs
great idea. if i get it right you propose to bring the functionality of the config.php to a web interface. the php-engine would handle all the replacments in some standard themes (which must not be changed by hand).
with this approach the easy configurable css file would be unnecessary.
urs
Yes, Urs.
You see, right now you can select which theme you want to use, from a handful of pre-made themes, but you can't really change anything unless you physically edit some files. What I'm suggesting is a web-based configuration page that would allow you to change some basic values like colors, fonts and maybe upload a new gradient.jpg.
That would allow for some very powerful changes, and still be very accessible for those not familiar with CSS.
Now, that doesn't mean you can't go to the file itself and make changes. In fact, the css file would have many other classes that would not show on the config page and would be used for fine tuning your theme. Of course, that would be targeted at developers and those more familiar with the syntax.
For example:
The web based config would allow you to change standard tags such as font,td,th,a, and maybe a few others. just modifying those values should show significant changes to the site.
But if you wanted to change something more specific, like the the headermenu class, then you would go to the file and make those changes.
I hope I'm being clear enough...
This is actually really easy to implement, and there's a few variations published freely, including a pure javascript one, so it's rather a shame that someone is charging for this feature.
I've added this to some of my own themes for Moodle, however, unless the colours and styles are generated purely by CSS (and not by a combination of CSS and config.php) then it only works to a certain degree.
Two relavent A List Apart articles: