David Scotson

I never managed to wrap my head around html_writer. I tried (and filed a couple of bugs, like MDL-35307) but just couldn't cope with it. The amount of extra typing involved makes it very hard for me to read code using it, and the first thing I now do when trying to figure out what a renderer is actually doing is go through and manually translate all the html_writer::tags to something that I can read and map mentally back and forth between code and the output it produces.

I'm struggling for something constructive and useful to say since this is planted fairly deep and I don't think there's much chance of change. Let me see..., okay here goes but bear in mind this is from a programmer point of view, I realise it's tricky to be everything to everyone:

1. I think it would be better if the name html_writer was as short as possible e.g. out::tag, html::tag, h::tag tag::div as it's used all over the place so like common words in languages it should be short (same for get_string, which I've seen elsewhere as a single or double underscore e.g. _("hello")). It would be fairly easy to point both at the same function for a transition period.

2. It would be better if you didn't pass the tag name as a string as it allows difficult to catch typos, like html_writer::tag('dib', $etc. If it's html_writer::div($etc. then not only do you get some extra typo checking, but you've saved yourself three characters, two apostrophes a comma and a space (at a cost of an extra function calll, which PHP developers generally seem to be allergic to).

3. You shouldn't be using such low-level tag writing most of the time. If you're outputting a cancel button you should be calling a function and giving it the unique info it needs e.g. out::cancel_button($text) and all the muddling about with HTML should be hidden within that function, that means if you need to change all the cancel_buttons to have a different tag or class or wrapper or whatever you can do it in one place. This is very related to Amy Groshek's attempt to map out the disparate HTML used in Moodle and somewhat standardise it (see https://moodle.org/mod/forum/discuss.php?d=216519 for more on that and Danny Wahl's comment in particular: https://moodle.org/mod/forum/discuss.php?d=216519#p942924 is relevant to this). That encapsulation should carry on all the way up the stack, so if you need a warning dialog you should just give it the text, and it'll take care of calling the ok and cancel buttons which will then allow all dialogs to look and act the same and be themeable.

4. I don't know if it's too late for this, but as in my bug linked above, the one thing I really couldn't cope with was the attributes going at the end. My poor little brain just couldn't manage going from <div class="first">content</div> to html_writer::tag('div', $content, array('class'=>'first')) and back, especially when the $content was another set of tags.

I had a look to see if there was a widely used PHP library for this kind of thing but the only thing I found was twig templates which seemed a bit much for my own use.

Yes, something like that. The idea is that I have one flexible theme, with a standard settings page which lets you select various options e.g. responsive or not, icon font/glyphicons/new moodle icons and then displays them to you when you save so you can test it out on a live site.

However, you don't want all that baggage in your final theme, so I'd like something automated (currently a command line script, but ideally you'd click a link in the Moodle and get a zipped theme) that takes your decisions and makes them permanent, and drops all the unnecessary stuff.

My flexible theme uses LESS, so you can choose a base color and it'll calculate different shades and gradients based on that color etc. Currently that compilation step is done in the CSS Processor and I have a separate file that calls the same function I call from the CSS Processor and returns the output CSS directly and I write it to a file as part of my theme building script. Currently I have to manually specify the various settings again in PHP, which isn't exactly a burden for me, but I'd like others to be able to use the same system and help me find bugs so if it could pick up the settings from Moodle that would be great.

Strangely that didn't happen for me when testing in Firefox's "Inspect Element" mode, but you're right. Back to the drawing board...

I also set it so that the striping only appeared when you hovered over a particular set of icons, to link it to the related activity. I found the striping too much if I left it on all the time.

This should be possible to prototype in CSS. If I get a chance I'll try it and report back.

And some CSS to take the rough edges off:

.smallicon.navicon {
    height: 16px;
    vertical-align: -2px;
    padding-right: 4px;
}
.commands img.iconsmall {
    height: 12px;
    padding: 4px;
}

li.activity img.activityicon {
    height: 16px;
}

This leaves the activity icons 24px in most places, but where size is disruptive in 2.3 I've shrunk them to 2/3 the size, they still look good (imho).

This works for me but at the moment I've deleted most of the core Moodle.css for my theme, I'll double check later if there's any further tweaks necessary for use in a standard theme.

Here's a screenshot, please ignore other brokeness you might see, this is a test site: