Looks very nice, and the use of a grid on the front page is an exciting step forward.
One nitpick, I think the logo is 3 or 4 pixels too high in the top bar, it doesn't look centered like the rest of the content.
David Scotson
Beiträge von David Scotson
In this, like many other things, I'd take the battle-proven techniques of Bootstrap as the gold standard and expect deviations from that to be heavily justified.
So things that Bootstrap have already thought about:
* how to avoid targetting the row that has the header cells in it
* how to target the cells within the row rather than the row itself for background color
* how to avoid targetting layout-tables that are used within a tabular table
* how to identify tables that are tabular to differentiate them for layout tables
* a system of different looks for tables that can be easily applied via combinations of classnames and require no additional CSS to be written
* and so on.
So things that Bootstrap have already thought about:
* how to avoid targetting the row that has the header cells in it
* how to target the cells within the row rather than the row itself for background color
* how to avoid targetting layout-tables that are used within a tabular table
* how to identify tables that are tabular to differentiate them for layout tables
* a system of different looks for tables that can be easily applied via combinations of classnames and require no additional CSS to be written
* and so on.
Yes, sorry I should have been more explicit about meaning "tables for layout", especially as there's at least two places in Moodle where things that are semantically tables (since they contain tabular data) have been built out of span tags and a whole bunch of unnecessary CSS to make the spans behave like the usual table tags.
Not counting themes other than Standard, I see stripes defined in about a dozen different places, and 7 or 8 different color schemes in that diff.
I think the ideal number would be 1 and 1, respectively. It would also be good if there was a recommended way for 3rd parties to pick up that same style (like using the library functions for tables).
But the only one that's not defined within the theme directories (which means I've had access to it and already fixed it in Bootstrapbase) is the mod quiz styles for the #categoryquestion table.
On the subject of which, is that change correct? They've switched .r1 for (odd), when usually r1 is the even rows. And the code doesn't seem to do anything for the even rows so it seems a bit strange that only the odd rows can be highlighted, which means switching odd for even might have more effect than it normally would.
edit: the reason it only define the highlight for r1 rows is because .highlight is already defined generally in Standard (but not Base) theme, and the r1 class overrode it, so it gets overriden again in the core quiz style, even though the original color it tries to match is in the Standard theme, and the color is defined differently in the two themes that use that class, canvas and formfactor, which inherits it from canvas but also defines it in the TinyMCE editor stylesheet.
I think the ideal number would be 1 and 1, respectively. It would also be good if there was a recommended way for 3rd parties to pick up that same style (like using the library functions for tables).
But the only one that's not defined within the theme directories (which means I've had access to it and already fixed it in Bootstrapbase) is the mod quiz styles for the #categoryquestion table.
On the subject of which, is that change correct? They've switched .r1 for (odd), when usually r1 is the even rows. And the code doesn't seem to do anything for the even rows so it seems a bit strange that only the odd rows can be highlighted, which means switching odd for even might have more effect than it normally would.
edit: the reason it only define the highlight for r1 rows is because .highlight is already defined generally in Standard (but not Base) theme, and the r1 class overrode it, so it gets overriden again in the core quiz style, even though the original color it tries to match is in the Standard theme, and the color is defined differently in the two themes that use that class, canvas and formfactor, which inherits it from canvas but also defines it in the TinyMCE editor stylesheet.
I don't want to hijack the thread too much because clearly the javascript guys want to fix what's holding them back and get on with their lives, but....
there's all sorts of theme/front-end issues that spring out of this, like why are the stripes defined in so many different places throughout Moodle instead of just once?, why are they sometimes different colors? (was it a choice?, was it a mistake? can we change it?), why do 3rd party developers feel the need to hand-write tables rather than call one of the two core Moodle libraries that'll provide a standard HTML table for them, should we really be encouraging people to call those functions in the upgrade notes, rather than invent their own HTML and CSS (and what's the difference between the two libraries anyway?), why are we still using tables for layout in this day and age? Is there any thoughts of shifting to using a grid system to allow for responsive layouts etc. and so on.
If there's any enthusiasm for fixing that kind of thing, maybe there's should be a bug for that as well and we (the themers) could vote for that one instead of the one that primarily benefits javascript coders and will be closed and marked as fixed as soon as their requirements are met?
there's all sorts of theme/front-end issues that spring out of this, like why are the stripes defined in so many different places throughout Moodle instead of just once?, why are they sometimes different colors? (was it a choice?, was it a mistake? can we change it?), why do 3rd party developers feel the need to hand-write tables rather than call one of the two core Moodle libraries that'll provide a standard HTML table for them, should we really be encouraging people to call those functions in the upgrade notes, rather than invent their own HTML and CSS (and what's the difference between the two libraries anyway?), why are we still using tables for layout in this day and age? Is there any thoughts of shifting to using a grid system to allow for responsive layouts etc. and so on.
If there's any enthusiasm for fixing that kind of thing, maybe there's should be a bug for that as well and we (the themers) could vote for that one instead of the one that primarily benefits javascript coders and will be closed and marked as fixed as soon as their requirements are met?