David Scotson

I don't know what the official stance is/was (can you point me to it if you know where it is?), but I've long thought the combination of writing low-level HTML and using html_writer to be a very bad idea indeed.

It seems strange for the FRONTEND team to be investigating/suggesting the use of template engines in renderers, presumably so that they are easier to write for people who know HTML, while also having a policy that recommends using such an obtuse, verbose and unfriendly API for simple HTML. It's as if we're officially pretending that Moodle is written in Java rather than PHP. After all, PHP itself is one of the "template engines" the front end team is considering since it's had this ability to blend code and HTML built into the language from day one.

Note I'm aware that html_writer is useful in situations where you're passing variables about and changing them before rendering something at the end, similar to your example. I wrote something very similar myself, except that it produce more idiomatic HTML5, and I believe this is the task that html_writer was originally created for. But for writing out what would otherwise be a mostly static bit of HTML it's just silly how much extra typing is involved and how unreadable the result is.

I thought (hoped?) there was a move away from using html_writer where it mostly served to complicate and confuse the intent of the renderer. Because Gareth's version is a bit more "programmery" there's more need for html_writer but I preferred Mary's original despite/because of the duplication which makes the intent and HTML clear:

if ($this->page->user_is_editing()) {
  $url->param('edit', 'off');
  $text = '<a href="'.$url.'" class="btn btn-danger" title="'.get_string('turneditingoff').'"><i class="icon-off icon-white"></i></a>';
} else {
  $url-&gt;param('edit', 'on');
  $text = '<a href="'.$url.'" class="btn btn-success" title="'.get_string('turneditingon').'"><i class="icon-edit icon-white"></i></a>';
}

My own actual personal preference would be a function/renderer that just did buttons e.g. something like:

return button_link_with_icon($url, "success", get_string("turneditingon", "edit");

but that's even more programmery, so simple straightforward presentational PHP seems like the next best thing, though Mary's version could be improved just by seperating the logic of deciding which button to use and the presentation of that button into separate functions so that people could tweak the HTML without worrying about the surrounding code.

Did you try it with btn-small? Because of the prominence of position I think you can get away with the smaller button size. Which would save you having to change the breadcrumb too much (though that's another option too).

I was thinking more of a bit of automation to generate multiple themes each with a unique look created from bootswatches rather than a single theme with multiple looks but the most general thing would be to fork the Bootswatch repository and then add any Moodle specific tweaks to the bootswach.less file for each different swatch.

People could then use these slightly modified swatches for various purposes. And people could use the inspiration to get ideas on how to customise their own themes.

Using % shouldn't be any different from using px *unless* the the body size itself (which the other fonts are the scaled from) is changing based on screen size.

If I visit http://www.rjerz.com/feedback/feedback.html and resize my browser window then the h2 text doesn't change size, so I'm not sure what it is you're intending to happen.

My personal approach to the "big headings" problem is that if it looks like http://twitter.github.io/bootstrap/base-css.html#typography then it's not a bug. That doesn't mean people aren't free to change it, Bootstrap provides tools for doing exactly that, but if you claim to have a Bootstrap theme and when people compare it with Bootstrap all the headings are different sizes (or other abitrary differences from the source) they are likely to assume *that* is a bug.

This is complicated by the fact that there are almost certainly places in Moodle that need the headings resized in Clean even if you intend it too look like Bootsrap, but the people who don't want it to look like Bootstrap confused matters because it's difficult to tell one "the heading is too big" from another "the heading is too big" even if the underlying complaint has a radically different cause, particularly when the comments are made in general and without accompanying screenshots.