MoodleDocs - User contributions [en]

Git for developers

2017-11-20T18:52:40Z

Aegroshek: /* Keeping your public repository up-to-date */

This document is for helping you get started on Moodle development with Git. For further details of Git, see [[:Category:Git]].

== General workflow ==

'''A reasonable knowledge of the Git basics is a good idea before you start to use it for development. If you are new to Git, you are encouraged to go to 'See also' for some more general reading.'''

[[image:git-pushpull-model.png|right|thumb|400px|Moodle development workflow with Git]]
Detailed explanation of the workflow can be found in the [[Process]] page. In short, the Moodle development with Git looks like this:

* You as the contributor commit changes into your personal repository at your computer
* You push the changes into your public repository and publish links to your changes in the Moodle Tracker
* You request a peer review of your code from another developer
* When peer reviewer is happy they submit issue for integration
* Moodle integrators pull the changes from your public repository and if they like them, they put them into Moodle integration repository
* The integrated change is tested and finally pushed into Moodle production repository
* You update your local repository with all changes from the production repository and the next cycle may start again

This workflow runs in roughly weekly cycles. The integration happens on Monday and Tuesday and the testing on Wednesday. On Thursday (or Friday if testing takes too long), the production repository moodle.git is usually updated with changes from the last development week.

Most Moodle developers have their public repositories hosted at [http://github.com/ Github]. Alternatively you may want to try [http://gitorious.org Gitorious] or the legendary [http://repo.or.cz repo.or.cz]. In the examples in this guide we assume you'll set up your public repository at Github.

When you first register on tracker you can not assign issues to yourself or send them for peer review. You will be added to the developers group after your first bug fix is integrated. Before that just comment on the issue with a link to your branch and component lead or another developer will send issue for peer review for you.

== Installing Git on your computer ==

Install Git on your computer. Most Linux distributions have Git available as a package to install. On Debian/Ubuntu, type ''''sudo apt-get install git'''' on the terminal. If you are on Mac, [http://code.google.com/p/git-osx-installer/ git-osx-installer] installs it in a few clicks.

Immediately after the installation, set your name and contact e-mail. The name and e-mail will become part of your commits and they can't be changed later once your commits are accepted into the Moodle code. Therefore we ask contributors to use their real names written in capital letters, eg "John Smith" and not "john smith" or even "john5677".

git config --global user.name "Your Name"
git config --global user.email yourmail@domain.tld

Unless you are the repository maintainer, it is wise to set your Git to not push changes in file permissions:

git config --global core.filemode false

Also, it's recommended to verify that the your git installation is not performing any transformation between LFs and CRLFs. All Moodle '''uses only LFs''' and you should '''fetch/edit and push''' it that way (may need to configure your editor/IDE too). Note that having any "magic" enabled is known to cause [[Common unit test problems#The_test_file_.22evolution.test.22_should_not_contain_section_named_.22.5Blots_of_content.5D.22|problems with unit tests]] execution. So we recommend you to set:

git config --global core.autocrlf false

== Setting-up the public repository ==

1. Go to [http://github.com/ Github] and create an account.

2. Go to the [http://github.com/moodle/moodle official Moodle Github repository] and click on the Fork button. You now have your own Github Moodle repository.

3. Now you need to set up your SSH public key, so you can push to your Github Moodle repository from your local Moodle repository. On Mac you can go on this [http://help.github.com/mac-key-setup/ Github help page]. If you are on another system, go to your Github administration page, to the section SSH Public Keys, and you should see a link to a help page. Done? Good! That was the most difficult part!

== Setting-up the local repository at your computer ==

Create a local clone repository of your Github repository. In a terminal:

git clone git://github.com/YOUR_GITHUB_USERNAME/moodle.git LOCALDIR

(or: git clone git@github.com:YOUR_GITHUB_USERNAME/moodle.git LOCALDIR)

This command does several jobs for you. It creates a new folder, initializes an empty Git repository in it, sets your Github repository as the remote repository called 'origin' and makes a local checkout of the branch 'master' from it. The important point to remember now is that your Github repository is aliased as 'origin' for your local clone.

Note that the format of the URL here is important. In the first example, the URL starts "git://github.com" and this will give read-only access to the repository at github.com. If you use this URL, the "git push origin" command that appears later in this document will not work. Therefore, if you want to be able to update the "origin" repository, you should use the URL that starts "git@github.com", i.e. the second of the two "git clone" commands given above. This will give you read and write access to the repository on github.com.

== Keeping your public repository up-to-date ==

[[image:git-sync-github.png|right|thumb|400px|Fetching changes from upstream and pushing them to github]]
Your fork at Github is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git and push them to your public repository. To avoid problems with this it is strongly recommended that you never modify the standard Moodle branches. ''Remember: never commit directly into master and MOODLE_xx_STABLE branches.'' In other words, always create topic branches to work on. In Gitspeak, the master branch and MOODLE_xx_STABLE branches should be always fast-forwardable.

To keep your public repository up-to-date, we will register remote repository git://git.moodle.org/moodle.git under 'upstream' alias. Then we create a script to be run regularly that fetches changes from the upstream repository and pushes them to your public repository. Note that this procedure will not affect your local working directory.

To register the upstream remote:

cd moodle
git remote add upstream git://git.moodle.org/moodle.git

The following commands can be used to keep the standard Moodle branches at your Github repository synced with the upstream repository. You may wish to store them in a script so that you can run it every week after the upstream repository is updated.

#!/bin/bash
git fetch upstream
for BRANCH in MOODLE_{19..34}_STABLE master; do
git push origin refs/remotes/upstream/$BRANCH:refs/heads/$BRANCH
done

=== How it works ===

The git-fetch command does not modify your current working dir (your checkout). It just downloads all recent changes from a remote repository and stores them into so called remote-tracking branches. The git-push command takes these remote-tracking branches from upstream and pushes them to Github under the same name. Understanding this fully requires a bit knowledge of Git internals - see gitrevisions(7) man page.

Note there is no need to switch the local branch during this. You can even execute this via cron at your machine. Just note that the upstream repository updates typically just once a week.

=== New branches ===

Occasionally, moodle.org will create a new branch that does not exist in your public (e.g. Github.com) repository. If you try to push this new branch, you will see an error such as the following:

error: unable to push to unqualified destination: MOODLE_99_STABLE
The destination refspec neither matches an existing ref on the remote
nor begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@github.com:YOUR_GITHUB_USERNAME/moodle.git'

In the above example, "MOODLE_99_STABLE", is the name of the new branch that does not exist in your public repository. To fix the error, you need to create the new branch on your public repository, using the following commands, replacing "MOODLE_99_STABLE" with the name of the new branch you wish to create:

git checkout MOODLE_99_STABLE
git push origin MOODLE_99_STABLE:MOODLE_99_STABLE

The above code will create a new copy of the "MOODLE_99_STABLE" branch in your local repository. If you do not need to keep a local copy of the new branch - and probably you do not need it, you then can remove it from your local repository as follows:

git checkout master
git branch -D MOODLE_99_STABLE

== Preparing a patch ==

As said earlier at this page, you never work on standard Moodle branches directly. Every time you are going to edit something, switch to a local branch. Fork the local branch off the standard branch you think it should be merged to. So if you are working on a patch for 1.9 or 2.0, fork the branch off MOODLE_19_STABLE or MOODLE_20_STABLE, respectively. Patches for the next [[Moodle versions|major version]] should be based on the master branch.

git checkout -b MDL-xxxxx-short-description-of-the-bug origin/master

Note that if you forget to specify the starting point, the branch is based on the currently checked-out branch. It may not be what you want. It is recommended to always specify the starting point.

To check the current branch, run

git branch

The current branch is highlighted.

Now go and fix the issue with your favorite IDE. Check the status of the files, view the change to be committed and finally commit the change:

vim filename.php
git status
git diff
git commit -a

For the commit message, please do respect the guidelines given on in the article [[Coding style#Git_commits|Coding_style]].

Note that this is safe as the commit is recorded just locally, nothing is sent to any server yet (as it would in CVS). To see history of the commits, use

git log

Once your local branch contains the change (note that it may consists of several patches) and you are happy with it, publish the branch at your public repository:

git push origin MDL-xxxxx-short-description-of-the-bug

Now as your branch is published, you can ask Moodle core developers to review it and eventually integrate it into the standard Moodle repository.

=== Changing commit message, reordering and squashing commits ===

It often happens that you made a mistake in your patch or in the commit message and helpful CiBot pointed it out for you. You can "rewrite the history" and change the existing commits.

Option 1. Reset all the changes in the branch and commit again.

git reset --mixed origin/master

Now all your changes are still present but all commits on top of "master" branch are gone. You can create a new commit

Option 2. Discover '''git rebase --interactive''' - this is a powerful tool to change the sequence of commit, change the commit messages, squash commits, etc. We will not cover it here, there are many articles in the Internet about it, for example: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History.

Whatever option you chose, you have "rewritten the history" and you can not simply push the changes to github again because they would need to overwrite the commits that were already pushed. If you try "git push MDL-xxxxx-short-description-of-the-bug" you will get an error message suggesting you to force push.
To force push the changed commits use:

git push -f origin MDL-xxxxx-short-description-of-the-bug

If an error occurs because you are still using the git protocol (read only), use this command :

git remote set-url origin https://github.com/<user.name>/moodle.git

A prompt will ask for your credentials, if you previously setup your SSH public key you can also use this one :

git remote set-url origin git@github.com:<user.name>/moodle.git

=== Checking if a branch has already been merged ===

After some time contributing to Moodle you would have a lot of branches both in your local repository and in your public repository. To prune their list and delete those that were accepted by upstream, use the following

git fetch upstream (1)
git branch --merged upstream/master (2)
git branch --merged upstream/MOODLE_20_STABLE (3)

The command (1) fetches the changes from your upstream repository at git.moodle.org (remember that git-fetch does not modify your working dir so it is safe to run it whenever). Command (2) and (3) print all branches that are merged into the upstream master branch and MOODLE_20_STABLE branch, respectively. To delete these local branches, use

git branch -d MDL-xxxxx-accepted-branch

The similar approach can be used to check the branches published at your origin repository at github.com

git fetch origin (1)
git fetch upstream
git branch -r --merged upstream/master (2)
git branch -r --merged upstream/MOODLE_20_STABLE (3)

The command (1) makes sure that you have all your branches from github.com recorded as the remote tracking branch locally. Commands (2) and (3) work the same as in the previous example but they list remote tracking branches only ([http://www.kernel.org/pub/software/scm/git/docs/git-branch.html see -r param]). To delete a branch at github.com, use

git push origin :MDL-xxxx-branch-to-delete

This syntax may look weird to you. However it is pretty logical. The general syntax of the git-push command is

git push <repository> <source ref>:<target ref>

so deleting a remote branch can be understood as pushing an "empty (null) reference" to it.

== Peer-reviewing someone else's code ==

To review a branch that someone else pushed into their public repository, you do not need to register a new remote (unless you work with such repository frequently, of course). Let us imagine your friend Alice pushed a work-in-progress branch called 'wip-feature' into her Github repository and asked you to review it. You need to know the read-only address of the repository and the name of the branch.

git fetch git://github.com/alice/moodle.git wip-feature

This will download all required data and will keep the pointer to the tip of the wip-feature branch in a local symbolic reference FETCH_HEAD. To see what's there on that branch, use

git log -p FETCH_HEAD

To see how a particular file looks at Alice's branch

git show FETCH_HEAD:admin/blocks.php

To create a new local branch called 'alice-wip-feature' containing the work by Alice, use

git checkout -b alice-wip-feature FETCH_HEAD

To merge Alice's work into your current branch:

git merge FETCH_HEAD

To see what would be merged into the current branch without actually modifying anything:

git diff ...FETCH_HEAD

Once you are all set and reviewing code, this [[Peer_reviewing_checklist|checklist]] should prove to be useful.

== Rebasing a branch ==

Rebasing is a process when you cut off the branch from its current start point and transplant it to another point. Let us assume the following history exists:

A---B---C topic
/
D---E---F---G master

From this point, the result of the command:

git rebase master topic

would be:

A'--B'--C' topic
/
D---E---F---G master

and would end with 'topic' being your current branch.

You may be asked to rebase your branch submitted for the integration if the submitted branch was based on an outdated commit. The typical case is if you create a new branch as a fork off the upstream master branch on Tuesday. Then on Wednesday, the upstream master branch grows as all changes from the last integration cycle are merged to it. To make diff easy on Github for next weekly pull request review, you want to rebase your branch against the updated master.

git rebase master MDL-xxxxx-topic-branch

Note that rebasing effectively rewrites the history of the branch. '''Do not rebase the branch if there is a chance that somebody has already forked it and based their own branch on it.''' For this reason, many Git tutorials discourage from rebasing any branch that has been published. However in Moodle, all branches submitted for integration are potential subject of rebase (even though we try to not to do it often) and you should not base your own branches on them.

=== Conflicts during rebase ===

During the rebase procedure, conflicts may appear. git-status commands reports the conflicted files. Explore them carefully and fix them in your editor (like you would do with CVS). Then add the files with 'git add' command and continue.

vim conflicted.php
git add conflicted.php
git rebase --continue

== Applying changes from one branch to another ==

Most bugs are fixed at a stable branch (like MOODLE_20_STABLE) and the fix must be prepared for other branches, too (like MOODLE_21_STABLE and the main development branch - master). In Moodle, we do not merge stable branches into the master one. So usually the contributor prepares at least two branches - with the fix for the stable branch(es) and with the fix for the master branch.

If you have a patch prepared on a local branch (let us say MDL-xxxx-topic_20_STABLE), it is possible to re-apply it to another branch.

=== Cherry-picking a single commit ===

Let us have two local Git repositories ~/public_html/moodle21 containing local installation of Moodle 2.1 and ~/public_html/moodledev with the local installation of most recent development version of Moodle. They both use your public repository at github.com as the origin. You have a branch in moodle21 called MDL-xxxx-topic_21_STABLE that was forked off MOODLE_21_STABLE. It contains one commit. Now you want to re-apply this commit to a branch MDL-xxxx-topic in moodledev.

cd ~/public_html/moodledev
git checkout -b MDL-xxxx-topic origin/master (1)
git fetch ../moodle21 MDL-xxxx-topic_21_STABLE (2)
git cherry-pick FETCH_HEAD (3)

The command (1) creates new local branch forked off the master. The command (2) fetches all data needed to re-apply the topic branch and stores the pointer to the tip of that branch to FETCH_HEAD symbolic reference. The command (3) picks the tip of the branch (the top-most commit on it) and tries to apply it on the current branch.
There is also a variant of the cherry-pick command that supports multiple commits, shortly (see its man page for details): <code bash>$ git cherry-pick A^..B</code> if you want to include from A - see '''^''' - to B, A should be older than B. We will use another approach for cherry-picking multiple commits.

=== Applying a set of patches ===

If the branch MDL-xxxx-topic_21_STABLE from the previous example consists of several commits, it may be easier to use git-format-patch and git-am combo to re-apply the whole set of patches (aka patchset). Firstly you will export all commits from the topic branch to files.

cd ~/public_html/moodle21
mkdir .patches
git format-patch -o .patches MOODLE_21_STABLE..MDL-xxxx-topic_21_STABLE (1)

The command (1) takes all commits from the topic branch that are not in MOODLE_21_STABLE and exports them one by one to the output directory .patches. Look at the generated files. They contain the patch itself (in diff format) and additional information about the commit. You could eg send these files by email to a friend of yours for peer-review. We will use them in another repository.

cd ~/public_html/moodledev
git checkout -b MDL-xxxx-topic origin/master
git am -3 ../moodle21/.patches/* (1)

The command (1) applies all the files from the .patches directory. When a patch does not apply cleanly, the command tries fall back on 3-way merge (see the -3 parameter). If conflicts occur during the procedure, you can either deal with them and then use `git am --continue` or abort the whole procedure with `git am --abort`.

== See also ==

; Moodle forum discussions
* [http://moodle.org/mod/forum/discuss.php?d=168094 GIT help needed]
* [http://moodle.org/mod/forum/discuss.php?d=165236 Best way to manage CONTRIB code with GIT]
* [http://moodle.org/mod/forum/discuss.php?d=167063 Handy Git tip for tracking 3rd-party modules and plugins]
* [http://moodle.org/mod/forum/discuss.php?d=167730 Moodle Git repositories]
* [http://moodle.org/mod/forum/discuss.php?d=183409 Git help!! I don't understand rebase enough...]
* [http://moodle.org/mod/forum/discuss.php?d=217617 add MOODLE_24_STABLE to github.com repository]

; External resources
* [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So]
* [http://gitref.org/ Git Reference]
* [http://progit.org/book/ Pro Git book]
* [http://vimeo.com/14629850 Getting git by Scott Chacon] - an recording of an excellent 1-hour presentation that introducing git, including a simple introduction to what is going on under the hood.
* [http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html Tim Hunt's blog: Fixing a bug in Moodle core: the mechanics]

[[Category:Git]]

[[ja:開発者用Git]]

Javascript Modules

2016-07-15T14:31:56Z

Aegroshek:

{{Moodle 2.9}}

= Javascript Modules =

== What is a Javascript module and why do I care? ==

A Javascript module is nothing more than a collection of Javascript code that can be used (reliably) from other pieces of Javascript.

== Why should I package my code as a module? ==

By packaging your code as a module you break your code up into smaller reusable pieces. This is good because:

a) Each smaller piece is simpler to understand / debug

b) Each smaller piece is simpler to test

c) You can re-use common code instead of duplicating it

= How do I write a Javascript module in Moodle? =

Since version 2.9, Moodle supports Javascript modules written using the Asynchronous Module Definition ([https://github.com/amdjs/amdjs-api/wiki/AMD AMD]) API. This is a standard API for creating Javascript modules and you will find many useful third party libraries that are already using this format.

To edit or create an AMD module in Moodle you need to do a couple of things.

== Install grunt ==

The AMD modules in Moodle must be processed by some build tools before they will be visible to your web browser. We use "[http://gruntjs.com/ grunt]" as a build tool to wrap our different processes. Grunt is a build tool written in Javascript that runs in the "[http://nodejs.org/ nodejs]" environment.

This means you first have to '''install nodejs''' - and its package manager [https://www.npmjs.com/ npm]. The details of how to install those packages will vary by operating system, but on Linux it's probably similar to "sudo apt-get install nodejs npm". There are downloadable packages for other operating systems here: http://nodejs.org/download/. Moodle currently requires node "v4" and does not work with the latest node "v6".

Once this is done, you can '''run the command''':

npm install
npm install -g grunt-cli

from the top of the Moodle directory to install all of the required tools. (You may need extra permissions to use the -g option.)

== Running grunt ==

See [[Grunt#Running_grunt]] for more details of specific grunt commands which can be used.

If you get the error message

/usr/bin/env: node: No such file or directory

Then see the thread https://github.com/nodejs/node-v0.x-archive/issues/3911

On Ubuntu 14.04 this fixed it for me:

sudo ln -fs /usr/bin/nodejs /usr/local/bin/node

== "Hello World" I am a Javascript Module ==
Lets now create a simple Javascript module so we can see how to lay things out.

Each Javascript module is contained in a single source file in the <componentdir>/amd/src folder. The final name of the module is taken from the file name and the component name. E.g. block_overview/amd/src/helloworld.js would be a module named "block_overview/helloworld". the name of the module is important when you want to call it from somewhere else in the code.

After running grunt - the minified Javascript files are stored in the <componentdir>/amd/build folder. The javascript files are renamed to show that they are minified (helloworld.js becomes helloworld.min.js).

Don't forget to add the built files (the ones in amd/build) to your git commits, or in production no-one will see your changes.

Lets create a simple module now:

blocks/overview/amd/src/helloworld.js
<code javascript>
// Standard license block omitted.
/*
* @package block_overview
* @copyright 2015 Someone cool
* @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
*/

/**
* @module block_overview/helloworld
*/
define(['jquery'], function($) {

/**
* Give me blue.
* @access private
* @return {string}
*/
var makeItBlue = function() {
// We can use our jquery dependency here.
return $('.blue').show();
};

/**
* @constructor
* @alias module:block_overview/helloworld
*/
var greeting = function() {
/** @access private */
var privateThoughts = 'I like the colour blue';

/** @access public */
this.publicThoughts = 'I like the colour orange';

};

/**
* A formal greeting.
* @access public
* @return {string}
*/
greeting.prototype.formal = function() {
return 'How do you do?';
};

/**
* An informal greeting.
* @access public
* @return {string}
*/
greeting.prototype.informal = function() {
return 'Wassup!';
};
return greeting;
});
</code>

The most interesting line above is:
<code>
define(['jquery'], function($) {
</code>

All AMD modules must call "define()" as the first and only global scoped piece of code. This ensures the javascript code contains no global variables and will not conflict with any other loaded module. The name of the module does not need to be specified because it is determined from the filename and component (but it can be listed in a comment for JSDoc as shown here).

The first argument to "define" is the list of dependencies for the module. This argument must be passed as an array, even if there is only one. In this example "jquery" is a dependency. "jquery" is shipped as a core module is available to all AMD modules.

The second argument to "define" is the function that defines the module. This function will receive as arguments, each of the requested dependencies in the same order they were requested. In this example we receive JQuery as an argument and we name the variable "$" (it's a JQuery thing). We can then access JQuery normally through the $ variable which is in scope for any code in our module.

The rest of the code in this example is a standard way to define a Javascript module with public/private variables and methods. There are many ways to do this, this is only one.

It is important that we are returning 'greeting'. If there is no return then your module will be declared as undefined.

== Loading modules dynamically ==
What do you do if you don't know in advance which modules will be required? Stuffing all possible required modules in the define call is one solution, but it's ugly and it only works for code that is in an AMD module (what about inline code in the page?). AMD lets you load a dependency any time you like.
<code javascript>

// Load a new dependency.
require(['mod_wiki/timer'], function(timer) {
// timer is available to do my bidding.
});
</code>

== Including an external javascript/jquery library ==
If you want to include a javascript / jquery library downloaded from the internet you can do so as follows:

'''Warning: if the library you download, supports AMD but is already "named" you will not be able to include it directly'''
e.g.
<code javascript>
define("typeahead.js", *[ "jquery" ], function(a0) {
return factory(a0);
});
</code>
will not work, as moodle injects it's own define name when loading the library.

If the library is in AMD format and has a define:
e.g. i want to include the jquery final countdown timer on my page ( hilios.github.io/jQuery.countdown/ )
* download the module in both normal and minified versions
* place the modules in your moodle install e.g. your custom theme dir, or plugin dir
* /theme/mytheme/amd/src/jquery.countdown.js

you can now include the module and initialise it (there are multiple ways to do this)
php:
<code php>
// 1. Create your own amd module and initialise it:
$this->page->requires->js_call_amd('theme_mytheme/countdowntimer', 'initialise', $params);
</code>
javascript:
<code javascript>
//1. put this code in theme/mytheme/amd/src/countdowntimer.js
define(['jquery', 'theme_mytheme/jquery.countdown'], function($, c) {
return {
initialise: function ($params) {
$('#clock').countdown('2020/10/10', function(event) {
$(this).html(event.strftime('%D days %H:%M:%S'));
});
}
};
});
</code>

2. put the javascript into a mustache template
<code javascript>
// /theme/mytheme/templates/countdowntimer.mustache
<span id="clock"></span>
{{#js}}
require(['jquery', 'theme_mytheme/jquery.countdown'], function($) {
$('#clock').countdown('2020/10/10', function(event) {
$(this).html(event.strftime('%D days %H:%M:%S'));
});
});
{{/js}}
</code>

3. call the javascript directly from php -- although who would want to put javascript into php? ergh..
<code php>
$PAGE->requires->js_amd_inline('
require(['theme_mytheme/jquery.countdown'], function(min) {
$('#clock').countdown('2020/10/10', function(event) {
$(this).html(event.strftime('%D days %H:%M:%S'));
});
});
');
</code>

== Embedding AMD code in a page ==
So you have created lots of cool Javascript modules. Great. How do we actually call them? Any javascript code that calls an AMD module must execute AFTER the requirejs module loader has finished loading. We have provided a function "js_call_amd" that will call a single function from an AMD module with parameters.

<code php>
$PAGE->requires->js_call_amd($modulename, $functionname, $params);
</code>

that will "do the right thing" with your block of AMD code and execute it at the end of the page, after our AMD module loader has loaded.
Notes:
* the $modulename is the 'componentname/modulename' discussed above
* the $functionname is the name of a public function exposed by the amd module.
* the $params is an array of params passed as arguments to the function. These should be simple types that can be handled by json_encode (no recursive arrays, or complex classes please).
* if the size of the params array is too large (> 1Kb), this will produce a developer warning. Do not attempt to pass large amounts of data through this function, it will pollute the page size. A preferred approach is to pass css selectors for DOM elements that contain data-attributes for any required data, or fetch data via ajax in the background.

AMD / JS code can also be embedded on a page via mustache templates
see here: https://docs.moodle.org/dev/Templates#What_if_a_template_contains_javascript.3F

== But I have a mega JS file I don't want loaded on every page? ==
Loading all JS files at once and stuffing them in the browser cache is the right choice for MOST js files, there are probably some exceptions. For these files, you can rename the javascript file to end with the suffix "-lazy.js" which indicates that the module will not be loaded by default, it will be requested the first time it is used. There is no difference in usage for lazy loaded modules, the require() call looks exactly the same, it's just that the module name will also have the "-lazy" suffix.

[[Category:AJAX]]
[[Category:Javascript]]

CSS Coding Style

2013-07-11T14:49:38Z

Aegroshek: /* Properties and Values */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

or

<code css>#selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-05-17T14:06:55Z

Aegroshek: /* Progressive Enhancement */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

or

<code css>#selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and use the shorthand version where possible, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066). If you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-05-09T14:19:09Z

Aegroshek: /* LESS and Other CSS Preprocessors */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

or

<code css>#selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and use the shorthand version where possible, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066). If you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-05-09T14:18:35Z

Aegroshek: /* LESS and Other CSS Preprocessors */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

or

<code css>#selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and use the shorthand version where possible, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066). If you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks, and syntax, please attempt to follow the style guidelines above.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-05-09T14:05:37Z

Aegroshek: /* Documentation and Comments */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

or

<code css>#selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and use the shorthand version where possible, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066). If you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks, and syntax, please attempt to follow these style guides.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-05-09T13:58:26Z

Aegroshek: /* Browser Hacks */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

or

<code css>#selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and use the shorthand version where possible, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066). If you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks, and syntax, please attempt to follow these style guides.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-02-16T00:51:11Z

Aegroshek: /* Properties and Values */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and shorten values when possible. If you use HSLA or RGBA, provide a HEX fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important! If you need to use !important, something is wrong with the CSS you're trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-02-16T00:50:57Z

Aegroshek: /* Properties and Values */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and shorten values when possible. If you use HSLA or RGBA, provide a HEX fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important If you need to use !important, something is wrong with the CSS you're trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-02-16T00:50:39Z

Aegroshek: /* Properties and Values */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and shorten values when possible. If you use HSLA or RGBA, provide a HEX fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use *!important* If you need to use *!important*, something is wrong with the CSS you're trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-02-16T00:46:10Z

Aegroshek: /* Selectors */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and shorten values when possible. If you use HSLA or RGBA, provide a HEX fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important. If you need to use important, something is wrong with the CSS you're trying to override. Rather than adding more problematic CSS, submit a tracker ticket to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-02-16T00:44:46Z

Aegroshek: /* Progressive Enhancement */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a Tracker ticket to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and shorten values when possible. If you use HSLA or RGBA, provide a HEX fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important. If you need to use important, something is wrong with the CSS you're trying to override. Rather than adding more problematic CSS, submit a tracker ticket to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-02-16T00:41:46Z

Aegroshek: /* Progressive Enhancement */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a Tracker ticket to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and shorten values when possible. If you use HSLA or RGBA, provide a HEX fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important. If you need to use important, something is wrong with the CSS you're trying to override. Rather than adding more problematic CSS, submit a tracker ticket to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the [https://docs.moodle.org/dev/Moodle_2.3_release_notes#Requirements Supported browser in question] does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-02-16T00:39:37Z

Aegroshek: /* Progressive Enhancement */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a Tracker ticket to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and shorten values when possible. If you use HSLA or RGBA, provide a HEX fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important. If you need to use important, something is wrong with the CSS you're trying to override. Rather than adding more problematic CSS, submit a tracker ticket to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the browser and version in question (only those supported by Moodle) does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-02-16T00:39:18Z

Aegroshek: /* Progressive Enhancement */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
#selector_one,
#selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a Tracker ticket to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, avoid uppercase, and shorten values when possible. If you use HSLA or RGBA, provide a HEX fallback.
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important. If you need to use important, something is wrong with the CSS you're trying to override. Rather than adding more problematic CSS, submit a tracker ticket to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0,0%,100%,1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the browser and version in question (only those supported by Moodle) does not support the unprefixed property. Outdated vendor prefixes can be removed. There are [http://caniuse.com/ Can I use] or like resource to determine what's supported.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-02-16T00:35:15Z

Aegroshek: /* Properties and Values */

CSS Coding Style

2013-02-16T00:34:48Z

Aegroshek: /* Properties and Values */

CSS Coding Style

2013-02-16T00:33:55Z

Aegroshek: /* Properties and Values */

CSS Coding Style

2013-02-16T00:31:46Z

Aegroshek: /* Properties and Values */

CSS Coding Style

2013-02-16T00:29:41Z

Aegroshek: /* Progressive Enhancement */

CSS Coding Style

2013-02-16T00:27:48Z

Aegroshek: /* Progressive Enhancement */

CSS Coding Style

2013-02-16T00:26:24Z

Aegroshek: /* Selectors */

CSS Coding Style

2013-02-16T00:26:00Z

Aegroshek: /* Selectors */

Talk:CSS Coding Style

2013-01-24T20:12:14Z

Aegroshek:

A few questions about these style guidelines, as they seem a bit outdated:
# Do we need to restrict color settings to only HEX? This probably made sense when there was only HEX & RGB, but we now have really cool stuff like HSLA which is supported in all the browsers we support except IE8. It's also very easy to provide fallback to HEX:
<code>

.selector {
background-color: #hex;
background-color: hsla(170, 50%, 45%, 1);
}

</code>
# For many properties, browser prefixes are no longer needed for our supported browsers. Shouldn't we be recommending that browser prefixes be added for supported browsers which need them, only? (Also, to make sure there is a background-color fallback for things like gradients?)
# What about !important being a bad thing? If you can't override existing rules without !important, that indicates that existing selectors are too aggressive (usually using IDs rather than classes and elements).
# How about we recommend OOCSS and where you can't use it request classes added to Moodle's markup so you can?

Talk:CSS Coding Style

2013-01-24T20:11:34Z

Aegroshek: Created page with "A few questions about these style guidelines, as they seem a bit outdated: 1) Do we need to restrict color settings to only HEX? This probably made sense when there was only HEX..."

A few questions about these style guidelines, as they seem a bit outdated:
1) Do we need to restrict color settings to only HEX? This probably made sense when there was only HEX & RGB, but we now have really cool stuff like HSLA which is supported in all the browsers we support except IE8. It's also very easy to provide fallback to HEX:
<code>

.selector {
background-color: #hex;
background-color: hsla(170, 50%, 45%, 1);
}

</code>
2) For many properties, browser prefixes are no longer needed for our supported browsers. Shouldn't we be recommending that browser prefixes be added for supported browsers which need them, only? (Also, to make sure there is a background-color fallback for things like gradients?)
3) What about !important being a bad thing? If you can't override existing rules without !important, that indicates that existing selectors are too aggressive (usually using IDs rather than classes and elements).
4) How about we recommend OOCSS and where you can't use it request classes added to Moodle's markup so you can?

CSS Coding Style

2013-01-24T20:08:10Z

Aegroshek: /* Browser Hacks */

Standardize classnames and layout to facilitate theming

2012-12-20T22:49:42Z

Aegroshek: /* Revise span.maincontent */

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.
* CSS selectors should use classnames over IDs. The logic being that we build reusable classes for application in multiple contexts, with consistent markup across numerous page view and elements, rather than writing CSS to target individual 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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span#maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

<pre>
<table cellspacing="0" class="generaltable forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>
This is mentioned again in the Consolidation item below.

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate Selectors for Several Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

====Info Alert====
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>

====Form Buttons====
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>

====Table====
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T21:23:34Z

Aegroshek: /* Success Alert */

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.
* CSS selectors should use classnames over IDs. The logic being that we build reusable classes for application in multiple contexts, with consistent markup across numerous page view and elements, rather than writing CSS to target individual 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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

<pre>
<table cellspacing="0" class="generaltable forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>
This is mentioned again in the Consolidation item below.

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate Selectors for Several Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

====Info Alert====
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>

====Form Buttons====
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>

====Table====
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T21:23:12Z

Aegroshek: /* Alert */

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.
* CSS selectors should use classnames over IDs. The logic being that we build reusable classes for application in multiple contexts, with consistent markup across numerous page view and elements, rather than writing CSS to target individual 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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

<pre>
<table cellspacing="0" class="generaltable forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>
This is mentioned again in the Consolidation item below.

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate Selectors for Several Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>

====Success Alert====
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

====Info Alert====
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>

====Form Buttons====
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>

====Table====
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T21:20:42Z

Aegroshek: /* Move away from use of IDs as CSS selectors */

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.
* CSS selectors should use classnames over IDs. The logic being that we build reusable classes for application in multiple contexts, with consistent markup across numerous page view and elements, rather than writing CSS to target individual 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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

<pre>
<table cellspacing="0" class="generaltable forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>
This is mentioned again in the Consolidation item below.

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate Selectors for Several Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

====Success Alert====
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

====Info Alert====
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>

====Form Buttons====
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>

====Table====
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Talk:Standardize classnames and layout to facilitate theming

2012-12-19T21:03:39Z

Aegroshek:

I like the way this is going. Naturally I will only comment on the bits I don't completely like ;-)

I still don't get why "Eliminate span.maincontent" is a good idea, but then I already explained my reasoning in MDL-34723.

On an unrelated note, I recommend reading some articles like http://css-tricks.com/efficiently-rendering-css/ and http://boblet.tumblr.com/post/34751669/tips-for-css-performance and the classic https://developer.mozilla.org/en-US/docs/CSS/Writing_Efficient_CSS that they both link to. Hence, some parts of your recommendations worry me a bit, like the one to always prefer classes to ids.

--[[User:Tim Hunt|Tim Hunt]] 15:31, 30 November 2012 (WST)

Hi Tim. I hear you on the selectors issue. From the bottom of the CSS-Tricks post:
<blockquote>
So we know that ID's are the most efficient selectors. If you wanted to make the most efficiently rendering page possible, you would literally give every single element on the page a unique ID, then apply styling with single ID selectors. That would be super fast, and also super ridiculous. It would probably be extremely non-semantic and extremely difficult to maintain. You don't see this approach even on hardcore performance based sites. I think the lesson here is not to sacrifice semantics or maintainability for efficient CSS.</blockquote>

Standardize classnames and layout to facilitate theming

2012-12-19T19:13:02Z

Aegroshek: /* Standardize inheritance for tables */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

<pre>
<table cellspacing="0" class="generaltable forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>
This is mentioned again in the Consolidation item below.

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate Selectors for Several Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

====Success Alert====
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

====Info Alert====
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>

====Form Buttons====
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>

====Table====
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T19:09:41Z

Aegroshek: /* Consolidate a Variety of Elements to a Set Number of Content Types */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate Selectors for Several Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

====Success Alert====
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

====Info Alert====
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>

====Form Buttons====
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>

====Table====
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T19:08:26Z

Aegroshek: /* Table */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

====Success Alert====
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

====Info Alert====
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>

====Form Buttons====
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>

====Table====
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T19:08:16Z

Aegroshek: /* Form Buttons */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

====Success Alert====
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

====Info Alert====
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>

====Form Buttons====
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>

===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T19:08:08Z

Aegroshek: /* Info Alert */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

====Success Alert====
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

====Info Alert====
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>

===Form Buttons===
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>
===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T19:08:00Z

Aegroshek: /* Error Alert */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

====Success Alert====
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>

====Error Alert====
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

===Info Alert===
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>
===Form Buttons===
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>
===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T19:07:51Z

Aegroshek: /* Success Alert */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

====Success Alert====
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>

===Error Alert===
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>
===Info Alert===
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>
===Form Buttons===
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>
===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T19:07:38Z

Aegroshek: /* Alert */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

====Alert====
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

===Success Alert===
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>
===Error Alert===
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>
===Info Alert===
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>
===Form Buttons===
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>
===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T19:07:28Z

Aegroshek: /* Success Label */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

====Success Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

===Alert===
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>
===Success Alert===
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>
===Error Alert===
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>
===Info Alert===
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>
===Form Buttons===
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>
===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T19:07:08Z

Aegroshek: /* Warning Label */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

====Warning Label====
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

===Success Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

===Alert===
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>
===Success Alert===
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>
===Error Alert===
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>
===Info Alert===
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>
===Form Buttons===
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>
===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T18:57:02Z

Aegroshek: /* Consolidate a Variety of Elements to a Set Number of Content Types */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap. In each case, we should implement a single class, and if possible eliminate unnecessary extra classes and IDs.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

===Warning Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

===Success Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

===Alert===
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>
===Success Alert===
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>
===Error Alert===
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>
===Info Alert===
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>
===Form Buttons===
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>
===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T18:55:43Z

Aegroshek: /* Table */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

===Warning Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

===Success Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

===Alert===
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>
===Success Alert===
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>
===Error Alert===
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>
===Info Alert===
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>
===Form Buttons===
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>
===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#tables.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T18:55:22Z

Aegroshek: /* Error Alert */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

===Warning Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

===Success Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

===Alert===
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>
===Success Alert===
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>
===Error Alert===
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>
===Info Alert===
The following elements all present info alert-type elements. DS chose to associate them with Bootstrap's alert-info class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
body.admin div.info,
div.box.copyright,
div#helppopupbox,
div.redirectmessage,
body.pagelayout-report div.info,
div.releasenoteslink,
div.performanceinfo.pageinfo
</pre>
===Form Buttons===
The following elements all present form button elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms. DS notes that there are other form element types in need of consolidation.
<pre>
#fgroup_id_buttonar,
#fitem_id_submitbutton,
table#form td.submit,
.form-buttons
</pre>
===Table===
The following elements all present table elements. DS chose to associate them with Bootstrap's form-actions class, which can be viewed here: http://twitter.github.com/bootstrap/base-css.html#forms.
<pre>
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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T18:50:59Z

Aegroshek: /* Alert */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

===Warning Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

===Success Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

===Alert===
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>
===Success Alert===
The following elements all present success alert-type elements. DS chose to associate them with Bootstrap's alert-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
div.notifysuccess
</pre>
===Error Alert===
The following elements all present error alert-type elements. DS chose to associate them with Bootstrap's alert-error class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#page-admin-roles-assign h2 + .box.generalbox,
div.notifyproblem,
.errorbox
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T18:48:24Z

Aegroshek: /* Alert */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

===Warning Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

===Success Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

===Alert===
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>
DS also implemented the .alert .close class for the following Moodle element:
<pre>
a#closehelpbox
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T18:45:56Z

Aegroshek: /* Success Label */

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.
<code php>
// similar to the heading renderer
heading();
// to replace container() as a default text function to print a block of text
paragraph();
</code>

===.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.)
<pre>

<div class="generalbox">

<div class="generalbox well">
</pre>

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

===#intro ID a classname instead===
The #intro item is common to all activity types. It is not a target of JavaScript and in addition is not really different from any generalbox element in most cases. It could very easily just be another notification box.

Currently:
<pre>
<div id="intro" class="box generalbox"></div>
</pre>

Recommended:
<pre>
<div class="intro generalbox"></div>
</pre>

===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:
<pre>
<div role="main" class="maincontent">
</pre>
===Revise span.maincontent===
Link to main content is needed for accessibility, but do we need a special element to do it? span.maincontent is not really semantic... MDL-34723
<pre>
<span id="maincontent"></span>
</pre>

Going recommendation is
<pre>
<a id="maincontent-target" name="maincontent-target"></a>
</pre>

===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:
<pre>
<table cellspacing="0" class="forumheaderlist" id="yui_3_5_1_1_1353535026017_577">
</pre>

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.

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

===Header usage should be hierarchical within page views===
* Headers should be hierarchical, with two or more <h3> under each <h2> and so forth.
* <h2> is the top-level header of the page content/central column. There should be only one <h2>
* Headers should not be used for notification. Notification classes should be used for notification.
* We shouldn't even need the .main class. The fact that the header is located in the central column/main content area, and is a header, should be enough. The only reason we need it is because we're recruiting headers for other purposes.

Not this:
<pre>
<h2 class="main">This is the top-level header</h2>
<p>A paragraph of content.</p>
<h2 class="main">These is your score on XX activity.</h2>
<p>A paragraph of content.</p>
<h2 class="main">You must make a selection to proceed.</h2>
<input type="submit" value="Generic submit button">
</pre>

This:
<pre>
<h2>This is the top-level header</h2>
<p>This paragraph gives additional information and explains what's to come.</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<h3>Content sub-header</h3>
<p>More paragraph content content content</p>
<div class="notifyproblem">You must make a selection to proceed.</div>
</pre>

===Consolidate a Variety of Elements to a Set Number of Content Types===
These elements were identified and organized by David Scotson, and their first listing can be found here: https://moodle.org/mod/forum/discuss.php?d=216519 The content types are based on components in Twitter Bootstrap.

====Important Label====
The following elements all present an error-type element. DS chose to associate them with Bootstrap's label-important class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
div.felement.error span.error,
span.error,
span.patherror,
tr.rolecap td.risk.xss a,
div.form-warning
</pre>

===Warning Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-warning class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.warn,
p.warn,
span.editinstructions,
#page-admin-report-security-index span.statuswarning,
span.statuswarning,
tr.rolecap td.risk.spam a,
.form-overridden
</pre>

===Success Label===
The following elements all present warning-type elements. DS chose to associate them with Bootstrap's label-success class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#labels-badges
<pre>
span.ok,
span.pathok,
span.statusok,
font[color="green"],
tr.rolecap td.risk.config a
</pre>

===Alert===
The following elements all present alert-type elements. DS chose to associate them with Bootstrap's alert class, which can be viewed here: http://twitter.github.com/bootstrap/components.html#alerts
<pre>
#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
</pre>

Standardize classnames and layout to facilitate theming

2012-12-19T18:44:17Z

Aegroshek: /* Important Label */

Standardize classnames and layout to facilitate theming

2012-12-19T18:42:09Z

Aegroshek: /* Reduce Various Selectors to Specific Content Types */