Looks like the correct change to solve this problem, +1 from me

Thanks sam. Submitting for integration now.

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

TIA and ciao

Rebased.

Integrated to master, 25 and 24 - thanks Tim.

In interests of getting better at good/bad CSS practice i'm starting to use csslint to check things and just noting that csslint warns about adjoining classes. (Seems to be an IE6 problem, I just a

styles.css

4: warning at line 11, col 1

Don't use adjoining classes.

.que.multichoice .answer div.r0 label,

styles.css

5: warning at line 12, col 1

Don't use adjoining classes.

.que.multichoice .answer div.r1 label,

styles.css

6: warning at line 13, col 1

Don't use adjoining classes.

.que.multichoice .answer div.r0 div.specificfeedback,

styles.css

7: warning at line 14, col 1

Don't use adjoining classes.

.que.multichoice .answer div.r1 div.specificfeedback {

Dan, those rules like .que.multichoice have been there for years (probably since long before IE6 was released) and no-one has ever reported a bug. So, I don't know what IE bug they are worried about, but it never bit us, and anyway we don't supported IE6 any more. So, quaint historical thingy, thanks for sharing, but let's move on (and perhaps reconfigure our CSSlint?).

For info, here is the link about this (google result):

https://github.com/stubbornella/csslint/wiki/Disallow-adjoining-classes

Although Tim's response may have been a bit, er, robust, I agree this doesn't seem like it should be relevant to the 21st century. (Also, from that documentation we see that the csslint maintainer somehow thinks it's better to require you to change the html to add a new class? Uhhhhhh....)

Thanks for your justifications, but as demonstrated by integrating it - I wasn't worried about it

Although you 'Uhhh' about adding the new class, i'd be interested to know what a designers POV would be, it might be one of those 'programmers point of view' situations.

Sorry for the noise in testing instructions. Just trying to make it clearer whether every part needs to be tested in every browser, or just the results (i.e. do I need to create a new question for each browser, or just preview in each browser - I'm going for the latter as it appears that it's the preview that is being tested, not the question creation)

Andrew, we are testing the preview.

Dan, think about the rule you are commenting on: .que.multichoice. According to the link Sam gave, IE6 will see that as .multichoice, which is actually not a big deal. The point is, it would be presumptuous of the question bank to think that it was the only place in Moodle that might output a <div class="multichoice">, so it outputs <div class="que multichoice">, and the style rule matches the .que too.

(Actually, the outer div gets more classes than that <div class="que multichoice adaptive correct">.)

Now, if we were starting today we might go for class="qtype_multichoice" but Gustav Delius made these choices back in 2006. (One of the commits is 1d0f9df57ea3cca9a6fd87e66c003e1027744f6e.) and, as I said before, no-one has ever reported a bug relating to this.

I'm seeing some strange issues with the .specificfeedback class not being applied correctly to some of the unusual styling I've played with - specifically tables, and <p> tags so far. Attaching a screenshot.

Passing after discussion with Tim about the background.

Raising a few new issues out of this though

Hurrah! Thanks for your contribution - this fix is part of Moodle.