Not yet, but I will.
I'm in doubt about the right moment to start. Before Martin has packed the Moodle 1.5 Beta version is not optimal, because all CSS changes will have to be worked into all 1.5 Themes. Any suggestions?
That is very generous of you.
If I understand the new scheme correctly you can start immediately. All non-standard themes inherit from the standard scheme so creating an orange variant of the standard scheme should not require a very large stylesheet.
If I understand the new scheme correctly you can start immediately. All non-standard themes inherit from the standard scheme so creating an orange variant of the standard scheme should not require a very large stylesheet.
Yeah, styles are still being added as we come across places that need them. Give it a few more days.
IMHO this is something that could use a lot of work. Both the code and the CSS would be better off with some sensible changes made. E.g., just today I changed
.headingblock and .headingblockoutline to
.headingblock and .headingblock.outline
removing all inline styles and a width argument from some function in course/lib.php. It makes sense that a .headingblock is a .headingblock no matter if it's also .outline or not, so writing it this way lets us reuse the CSS and keep it simpler.
I 'm bringing this up because every time it happens, old themes will be broken. And we 're already breaking the themes with 1.5. Modernizing the structure of the CSS (and improving the HTML) is something that will allow us to avoid breaking themes in the future (or the alternative, getting burdened with legacy stuff in the styles). So we should get in as much of this as possible before packing 1.5.
It's demanding work, though. Modernizing the calendar almost killed me; at one point I was so frustrated (due to IE mainly) that I had to let logic take over ("you are upset and no longer productive; give it up") and take a break from Moodle for several hours...
.headingblock and .headingblockoutline to
.headingblock and .headingblock.outline
removing all inline styles and a width argument from some function in course/lib.php. It makes sense that a .headingblock is a .headingblock no matter if it's also .outline or not, so writing it this way lets us reuse the CSS and keep it simpler.
I 'm bringing this up because every time it happens, old themes will be broken. And we 're already breaking the themes with 1.5. Modernizing the structure of the CSS (and improving the HTML) is something that will allow us to avoid breaking themes in the future (or the alternative, getting burdened with legacy stuff in the styles). So we should get in as much of this as possible before packing 1.5.
It's demanding work, though. Modernizing the calendar almost killed me; at one point I was so frustrated (due to IE mainly) that I had to let logic take over ("you are upset and no longer productive; give it up") and take a break from Moodle for several hours...
Absolutely, it's really hard to know when to add new classes or change old ones or just use a more complex selector. It's an iterative process and varies depending on the bit we're looking at. The more help we have the better!!
Calendar is looking great now, by the way!
I would really like this release to be the only one for a long time where themes break in a noticeable way.
Calendar is looking great now, by the way!
I would really like this release to be the only one for a long time where themes break in a noticeable way.
Jon and Martin,
if you want to enter this wide field I propose to consider the following. For all parts of a Moodle page with a somehow similar structure and task standard names can be used:
.header
.content
.leftside
.rightside
.footer
Based on that names many chunks can be named and addressed in CSS with "Contextual Selectors" like:
_ "Forumpost"
the CSS could look like:
.forumpost .picture { }
.forumpost .topic { }
.forumpost .leftside { }
.forumpost .content { }
.forumpost .footer { } /* distance
to the next post could be omited and done
by .forumpost {margin-bottom:1em;} */
_ course "Topicsoutline"
the CSS could look like:
.topicsoutline .content { }
.topicsoutline .leftside { }
.topicsoutline .rightside { }
and the informations in a list:
.topicsoutline .content .list { }
and the single info in every row:
.topicsoutline .content .list .r0/.r1 { }
_ "Sideblock"
the CSS could look like:
.sideblock .header { }
.sideblock .content { }
.sideblock .footer { }
and the informations in a list:
.sideblock .content .list { }
or shorter
.sideblock .list { }
and the single info in every row:
.sideblock .content .list .r0/.r1 { }
or shorter
.sideblock .r0/r1 { }
What do you think?
I really like this basic plan ... it looks like it will really help get a hold on the proliferation of styles.
I"m experimenting with new classes on the course page just now...
I"m experimenting with new classes on the course page just now...
Absolutely, I like this too.
Only, IMHO we should avoid writing "short" CSS selectors. For me, a good rule of thumb is: "include in the selector all the items that play an active role in structuring the page". That is:
Only, IMHO we should avoid writing "short" CSS selectors. For me, a good rule of thumb is: "include in the selector all the items that play an active role in structuring the page". That is:
- Use all items with ids and classes
- Do not use any extra wrappers (most likely divs) that are there to allow more flexibility
- Do not be anal (there's no need to say table.something tr td.one; the tr is not really doing anything helpful in that selector)
As "short as possible" should be the maxim ... bearing in mind the many poor admins who will be facing these sheets without much CSS knowledge.
On the new course topics page I worked on last night the styles now look like this:
#course-view .section td {
border-color:#DDDDDD;
vertical-align:top;
}
#course-view .section .content {
padding:5px;
border-style:solid;
border-width:1px;
border-left:0px;
border-right:0px;
}
#course-view .section .side {
padding:5px;
border-style:solid;
border-width:1px;
background: #EEEEEE;
}
#course-view .section .left {
border-right:0px;
font-style:bold;
}
#course-view .section .right {
border-left:0px;
}
#course-view .current .side{
background: #FFD991;
}
#course-view .topics {
margin-top: 9px;
}
#course-view .weeks {
margin-top: 9px;
}
#course-view .section .spacer {
height:0.5em;
}
The downside to the new short classes is that old themes will be broken even more, but if we're going to clean all this stuff up then this release is the time to do it all at once, eh?
On the new course topics page I worked on last night the styles now look like this:
#course-view .section td {
border-color:#DDDDDD;
vertical-align:top;
}
#course-view .section .content {
padding:5px;
border-style:solid;
border-width:1px;
border-left:0px;
border-right:0px;
}
#course-view .section .side {
padding:5px;
border-style:solid;
border-width:1px;
background: #EEEEEE;
}
#course-view .section .left {
border-right:0px;
font-style:bold;
}
#course-view .section .right {
border-left:0px;
}
#course-view .current .side{
background: #FFD991;
}
#course-view .topics {
margin-top: 9px;
}
#course-view .weeks {
margin-top: 9px;
}
#course-view .section .spacer {
height:0.5em;
}
The downside to the new short classes is that old themes will be broken even more, but if we're going to clean all this stuff up then this release is the time to do it all at once, eh?
I would like to update the formal_white theme in the HEAD branch according to the new CSS rules. Unsure if it is already time or it is better to wait.....
It would be a good idea to wait a bit longer since things are changing quite a lot. I really need everyone with access to be concentrating on the "standard" theme only.
I'll make an announcement when it's stabilised so other themes can be upgraded to match.
I'll make an announcement when it's stabilised so other themes can be upgraded to match.
The old themes had an easy way to change the color scheme. Is something comparable planned for the new themes?
Unfortunately this is one of the things we have lost in moving to plain CSS files, but it's not TOO hard to go through styles_colors.css.
However, I hope that eventually we can a web-based GUI that simplifies this process.
However, I hope that eventually we can a web-based GUI that simplifies this process.