Themes

Move away from use of IDs as CSS selectors

• IDs are needed for elements which need identification for JavaScript. Elements which do not need to be accessed or manipulated by JavaScript can be identified by classnames.

• Wherever possible, CSS selectors should use classnames over IDs.

I'm not too keen on OO-CSS because it doesn't accomplish the stated goal of "making theming faster and more reliable".  For example:

#footer {} - obviously the page footer
.footer {} - could be a forum post? blog? gotta use body > .footer or #region_main + footer or something...

This isn't to say there's not room for improvement, why are there selectors like #page-content #region-main {} when you can use #region-main {} ? or why add class .course-content when that's the only div that uses it (should be ID?) and then have a selector #region-main .course-content {}

I think we should stick with the common CSS practices and work on making it more readable.  For example:

.path-calendar .maincalendar,
.path-calendar .sidecalendar,
.path-calendar td.sidecalendar .block,
.loginbox,
.userinfobox,
.groupinfobox,
.forumpost,
.block .content,
.glossarycomment {   border-bottom-left-radius: 10px;   border-bottom-right-radius: 10px; }

Can we split that out into a couple of rules to make it a little more understandable? (or maybe a .border-round class?) Another example:

.sitetopic .section .activity .commands img,

.course-content .section .activity .commands img {}

WOW! Oh and not to mention it's different than the block selector...

.block .header .commands .icon img {}

which basically output the same thing with two separate sets of rules...

I hope I'm not sounding too complainy I'm really excited for this and would love to contribute in any way possible!

2nd reply, about renderers.  If renderers need to be updated and possibly rewritten (for revisioning support...) can we please make sure that they conform to the coding style - or modify the coding style to unify the writing methods?  I can't speak for other theme developers but I'm not much of an actual programmer so when I see these different methods to accomplish the same thing it really throws me for a loop (no pun intended) to figure it out:

concatenation
$output = html_writer::start_tag('div', array('class'=>'generalbox'));
$output .= html_writer::tag('a', get_string('purgecaches', 'admin'), array('href'=>$CFG->wwwroot.'/'.$CFG->admin.'/purgecaches.php));
$output .= html_writer::end_tag('div');
return $output;

"stuffing" (probably a real name for this...)
$output = html_writer::tag('a', get_string('purgecaches', 'admin'), array('href'=>$CFG->wwwroot.'/'.$CFG->admin.'/purgecaches.php));
$output = html_writer::tag('div', $output, array('class'=>'generalbox'));
return $output;

nesting
$output = html_writer::tag('div',

 html_writer::tag('a', get_string('purgecaches', 'admin'), array('href'=>$CFG->wwwroot.'/'.$CFG->admin.'/purgecaches.php)), array('class'=>'generalbox);
return $output;

mixing (can be any of the 3 above w/ raw HTML)
$output = html_writer::start_tag('div', array('class'=>'generalbox'));
$output .= '<a href="' . $CFG->wwwroot . '/' . $CFG->admin . '/purgecaches.php' . '">' . get_string('purgecaches', admin') . '</a>';
$output .= html_writer::end_tag('div');

there's more variation out there, and I realize that in certain situations some are better than others (like building a list vs a div w/ a link) but it largely seems to be guided by personal preference.

So I went back and checked my CSS for places where I'd had to "harmonise" a bunch of different classes, the big ones seem to be marking text as error/warning/success (i.e. red/yellow/green), various types of alert boxes, form layouts and tables.

Note this isn't CSS, it's LESS, basically saying apply the Bootstrap CSS inside the { } to all the classes named before it.

You can see the full file here: https://github.com/ds125v/gumoodle/blob/master/theme/bootstrap/less/moodle/patch.less

Currently I'm trying to fix the problem at the root by rewriting renderers so this HTML doesn't get written out in the first place, but particularly in forms that's not possible so once I've convinced myself I can't fix it in a renderer I'm patching it in a similar manner here:

https://github.com/ds125v/moodle-theme_bootstrap_renderers/tree/master/style/moodle

div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning {
  .label-important
}
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden {
  .label-warning
}
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a {
  .label-success
}

#page-admin-roles-assign h2 + .box.generalbox,
div.notifysuccess,
div.notifyproblem,
body.admin div.info,
div.box.copyright,
body.pagelayout-report div.info,
div.redirectmessage,
div.adminwarning,
div.forumnodiscuss,
div#notice p,
div.performanceinfo.pageinfo,
div.noticebox,
div#helppopupbox,
div.releasenoteslink,
.errorbox {
  .alert
}
a#closehelpbox {
  .alert .close
}

div.notifysuccess {
  .alert-success
}

#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox {
  .alert-error
}

body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo {
  .alert-info
}

/* just one example for forms */
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons {
  .form-actions
}

table#explaincaps,
table#defineroletable,
table.grading-report,
table#listdirectories,
table.rolecaps,
table.userenrolment,
table#form,
form#movecourses table,
form#movecourses table,
#page-report-log-user .generaltable,
#page-admin-course-index .editcourse,
.forumheaderlist,
.userprofilebox table.list,
.generaltable {
    .table
}