Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Standardize classnames and layout to facilitate theming: Difference between revisions

From MoodleDocs
Line 26: Line 26:
   <div class="generalbox well">
   <div class="generalbox well">
</pre>
</pre>
Also, tables should not be getting the .generalbox class, as they are tables, not boxes.


===Use .maincontent instead of .generalbox to indicate parent of all content in central column===
===Use .maincontent instead of .generalbox to indicate parent of all content in central column===

Revision as of 22:01, 21 November 2012

Working notes on standardization of classnames and layout across Moodle activity types, with the intention of making theme design faster and more foolproof.

In order to be sure all bases are covered in standardization, I began with a Survey of existing page views and markup. I'm going to exclude editing screens from this survey because it would just be too much to cover. Additionally, student views should probably be the first priority.

Recommendations

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.

Add a paragraph renderer

Add a paragraph renderer. The container() renderer encourages developers to render text that is not appropriately tagged as paragraph text. This would be a simple thing to add. Or if not, at least discourage instructions and other text within bare divs. // similar to the heading renderer heading(); // to replace container() as a default text function to print a block of text paragraph();

.generalbox for text features

Use generalbox only for a box/block of text, not for container of all content in the central column. (In following with purported original purposes of .generalbox, assuming it used to be similar to .generaltable.)

  <!-- If we aren't going to implement a framework, then this will suffice. -->
  <div class="generalbox">
  <!-- If we are going to implement a framework, then, at least with regard to Twitter Bootstrap, 
.generalbox is analogous to the .well class. 
We might implement them both. -->
  <div class="generalbox well">

Also, tables should not be getting the .generalbox class, as they are tables, not boxes.

Use .maincontent instead of .generalbox to indicate parent of all content in central column

Expand the role="main" container div with a classname so it can take the place of .generalbox as a container of all content in the central column:

  <div role="main" class="maincontent">

Eliminate span.maincontent

Do we still need the following? If not, let's get rid of it. Or if it's just a spacer or some such thing, let's give it a classname such as .maincontent-spacer-top. If it doesn't need access by JavaScript, let's eliminate the ID.

  <span id="maincontent"></span>

Standardize inheritance for tables

The .generaltable instances look nice and are commonly used. But there are some activities where tables are given their own classes entirely, and not given the .generaltable as well. This makes it hard to style all tables with general styles. It's no problem for a mod developer to add additional classnames to target with the mod's own CSS, but the parent classname should be retained.

An example of this is the forum. At present, the table of threads for a news forum has only one classname:

  <table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">

This means that anything special theme designers did with .generaltable will not apply to the forum table. A better strategy would be to include the .generaltable class, and then add additional classes for mod-specific styling.

  <table cellspacing="0" class="generaltable forumheaderlist" id="yui_3_5_1_1_1353535026017_577">

Header usage should be hierarchical within page views

  • Header usage, especially h2.main, is way higher than it should be.
    • Ideally, we use h2.main only once on a page view, for activity title or other "main" title.
    • .main is not a descriptive classname. It doesn't tell us anything we don't already know from h2 and the body tag.
    • .main also is not reliably used as the top-level header in the page-content. In many views it is applied to every header on the page.
    • On some page views, headers are used for purposes other than headings. We should move away from this. Text that is not a heading but needs emphasis should instead be given emphasis using uniformly-available classnames.

Additional classnames to allow for framework adoption