Hiya folks. I am not sure if I am maybe looking in the wrong places, but am I right in thinking that there is no major overhaul of the Moodle templating system planned for version 2.0?
It may well be that I have not yet found the right documentation, but compared with Joomla 1.5 templates, the Moodle templating system feels very limited and rather difficult to work with. If I understand things correctly, the only parts of a template I can control are the header and footer files as well as the css for the whole site. I don't seem to be able to do anything much about what is happening on centre stage without hacking the core code - am I right?
As an example, look at what ends up in my browser for the site admin block:
<div class="admintree">
<div class="depth0"><a class="link" href="http://10.75.48.218/admin/index.php"><img src="http://10.75.48.218/pix/i/item.gif" alt="" />Notifications</a></div>
<div class="depth0"><a href="#" Xonclick="menu_toggle('1');return false"><span id="vh_div1indicator"><img src="http://10.75.48.218/pix/i/open.gif" alt="Opened folder" /></span> Users</a></div>
...etc...
I mean even if I ignore the copious doses of javascript above the menu that seem to get sent down by default (this is from a blank install of the standard template) I find things like:
<a href="#" Xonclick="menu_toggle('1');return false">
to be a very poor way of going about things. And as far as I can see, this doesn't even seem to be using a standard unordered list to build the menu structure.
Surely it would be better to do what joomla does and have some xml tags that you can embed wherever you like in the template that call the core modules - and to make those modules pretty plain xhtml. The template designer can then call in whatever javascript they like to make things fancy - IF they want to.
Please do let me know if I am going wrong here, but I have been working with moodle for a few months now in a new job and I am looking to improve the accessibility / usability for our pupils and am stunned at how limited and stifling the templating system _appears_ to be.
Looks like I might have to hack yet further into the moodle core to achieve my school's requirements.
Hoping for solutions !
dan
I'm not aware of any plans to change the overall situation in Moodle 2, however there are plans to improve certain areas of HTML. (Not sure if admin menu is one of them.)
Personally I think it would be infeasible to try and turn Moodle into a 'proper' system with intermediate XML output format as described. Basically, if you want a system like that, don't use Moodle.
A better project aim would be to clean up and improve the HTML - remove the remaining layout tables, for instance, and the swathes of inline JavaScript. Some of this is happening for Moodle 2, and I'm sure more is likely to happen for future versions.
So no you won't be able to customise HTML without hacking the code. However, Moodle is supposed to be accessible - you should report any areas that cause genuine accessibility problems (i.e. a user with screenreader, or who is colour-blind, etc. has trouble using the site) as bugs in the Moodle tracker. Moodle is also XHTML-compliant.
There was a round of accessibility improvements some time ago (including the standardised Moodle form system, for instance); it was an awful lot worse before...
--sam
Also, I share your feelings of horror at the way JavaScript is included in Moodle at the moment. See this thread: http://moodle.org/mod/forum/discuss.php?d=106312 (The admin tree JavaScript is already cleaned up in 2.0 dev version, although I must admit I was lazy and stopped short of making the HTML semantic at the same time.)
But, to get back to the main topic you posted about.
I have never used Joomla, but as I understand it, it is a fairly generic content management system. It tracks your content, and then gives you quite a lot of control over how it is displayed. In contrast, Moodle is a learning management system, and enables you to create fairly specific learning activites (like forums, wikis and quizzes) available to your students. Of course, Moodle also does some more content-management-y things, like resources linked from the course page, and the contents of the course page itself.
So, anyway that is one question to you: how does a general templating system help theme a quiz? can you give some specific examples?
Now, some ideas about what you can do in Moodle:
1. You can do a lot by putting right HTML content into labels.
2. You can make custom blocks that display whatever you like on the sides of the course page or front page.
3. You can make custom course formats that control what appears in the middle column of a course. You might like to have a look at the flex page plugin. http://moodle.org/mod/data/view.php?d=13&rid=1080
4. You can make custom filters. Filters can basically do arbitrary search-and-replace type operations on user-entered content before it is displayed. So, for example, you could make a filter that recognises certain xml-like tags and replace them with whatever you like.
This is a Moodle module, but you can also use filters to display content from external systems (we've done this with some external CMS systems as well).
Bascially we do want to do something in Moodle 2.0
In Moodle, a lot of output goes through print_XXX functions in web lib. For example print_box, print_container, print_heading, print_table, .... One basic idea that will probably happen is to move all these functions to be methods in a class, and with a default implementation in weblib.php. Then give the theme the opportunity to subclass the default implementation if it wishes. There are some other ideas too, however the information currently in the roadmap (Roadmap#Improvements_to_the_organisation_of_courses) is pretty limited. That is mainly becuase we are still thinking this through, so it is a good time to get involved.
At this stage, a really helpful contribution to the debate would be some use cases from themers. Statements like "In my theme, I want to be able to control ...". Make the examples as specific as possible, and try to phrase them in terms of actual educational situations, where what you are asking to be able to do clearly makes a positive impact on the educational experience. That is the way to make your request most convincing.
@ Statements like "In my theme, I want to be able to control ...". Make the examples as specific as possible, and try to phrase them in terms of actual educational situations, where what you are asking to be able to do clearly makes a positive impact on the educational experience.
Tim, your question makes a real problem clear in the discussion about Moodle templates.
Nobody can seriously answer this kind of question. One major design task is to create the best possible positive impact within a certain task and context. There can't be a positive impact in general. And the solution must be different from task to task. If not design fails.
And "educational experience" does not demand a certain and specific look and feel. But the look and feel of the environment into which Moodle is integrated may demand a specific look and feel. And the presentation and form needs to be different for young learners and for adult learners.
A real life work example
Working on the moodle2 theme design I thought about how the forums may be presented to support the experience of one real discussion where people discuss together one topic. The research on forum types and looks showed up hundreds of different ways to present forum threads. For example a forum thread may be a collection of several individual expressions of personal opinions clearly separated. Or the look and organisation of the thread supports the experience of the thread as one discussion with different opinions from different persons belonging together. Two nearly opposite approaches.
I was able to realise some of the goals but I failed to implement the approach consequently. Why? The reason is that I was not able to change the content order of the relative huge personal information and repeating topic part of every posting. It separates every posting too much. If I would have access to the XHTML page structure I could have changed the content order and solve the issue.
This example shows that one can do a lot by changing the CSS. But for several essential tasks the XHTML structure needs to be changed.
Moodle theme changes with CSS are mostly like changing the wallpapers in a building. When you need a different experience you need to change the walls of the building. Multi functional buildings therefor offer "movable" walls.
Moodle is Open Source - just change core
Somebody may propose: change the Moodle forum thread content order in core when this order is better = hack Moodle core. If someone would do that the forum presentation is right for this one task but may be wrong within another context - for example when the individual posting plays the dominant role over the thread concept. So this hacking approach does not work.
Better use templates
Here templates come in handy. The program offers the content (the posting with the elements user, userimg, thread title, text etc.) in a structured way. This content is then placed into a XHTML page structure = the template. I as the web designer can rearrange the XHTML in the template and place the delivered content in the way needed for the given task. I don't hack Moodle and I don't touch content - I only arrange it to get the best user experience for the given task.
Separate content and form
The clue is to separate content and form. The program delivers structured content, the web designer delivers the XHTML form as a template and both are put together to produce the web page. It's work in two steps: First collect all content and then place it within the page. That's dead easy, isn't it?
Within Moodle the content collection and placement within the page structure is done in one go. Database calls, content preparation calculations and "echos" change evermore. Here we have the problem. Every time you want to change the form you need to change the programming too.
Separating content and form also supports two professions: (web) developers being best in handling and collecting content and (web) designers being best in creating functioning, usable and appealing web pages. Every profession can concentrate on what they can do best and co-operate in a superior user/learning experience.
In Moodle (web) developers need to deliver for both professions with very different success.
Is there any reason that CMSs and Moodle have different visualisation needs?
What I don't understand is your approach to declare information delivered with CMS systems is different in their presentation needs from information delivered by Moodle?
As you may see from my forum example above also forums and quizzes etc. never should be fixed in their visual form. You always need to see the context. And in my example the design needs to follow function and is not a candy visual effect.
The fixed form Moodle approach in the opposite is contra productive because it reduces the "positive impact on the educational experience" by reducing the impression of one closed discussion. Do you get the point?
And an important fact is, that no programmer ever will be able to create a page which fits every context. As you mentioned CMS developers solve this task by offering templates.
About templates
When I talk about templates I don't talk about template systems like for example "Smarty". I talk about XHTML include files with <?php echo $variable ?> and <?php foreach($group as $element) : ?> statements to place content within the page XHTML.
Figure out the following scenario:
In Moodle content is collected into an associative array
Import variables into the current symbol table from this array with "extract()"
Include the XHTML template saved as a separate template file "templates/forum-thread-view.inc.php"
"Echo" the variables in the symbol table within the XHTML page structure
Flush the complete page to the browser
Designers write templates to realise the needed look and feel
How may this work?
Moodle collects all template files in an array "$templates" (as a lookup table) during the setup process in "setup.php". Like Moodle collects the several CSS files now it can search the relevant places and build the table.
Every template has a unique name like "forum-thread-view.inc.php", "sideblock-list.inc.php" or "header-home-inc.php" etc. Template files are placed within "templates" directories within the blocks, modules etc. directories.
Designers can copy the template files they need to change into the "templates" directory in the "themes" directory and modify/rewrite them as needed.
Moodle reads the "templates" in the theme directory last and therefore overwrites the existing "template" entries from core in the lookup table with the new "template" link with an identical name.
Every page calls the needed "template" with for example
include($templates['forum-thread-view'])and will get either the core template or the overwrite "template" written by the designer.
That's the basic templating principle many blog or CMS systems work with. I learned how those "pure PHP templating systems" work looking at Habari and Drupal.
Templates in Moodle 2.0
I will use such PHP templates in my Moodle design work in the future to provide a better positive impact on the educational experience and better integration in the visual needs for my clients.
It would be marvellous when such a simple templating system would be integrated into Moodle 2.0. Many more designers would be able to create a better learning experience with Moodle.
It is to early to argue about whether templates are the right solution for Moodle, we don't know what the problem is yet. The best way I know to set the scope of a software engineering design problem is to get a good list of use cases. To see what I mean, here is my attempt to do it for enrolments Development:Enrolment_plugins_2.0
Only after we know what problem we are trying to solve, can we discuss the merits of potential solutions.
Your forum example is the kind of thing I wanted, although I am sceptical how many people who are creating a Moodle theme want to be able to change the layout of a particular activity that much. And if there is a different way of laying out discussion thread for educational discussions, why should that better way only be available to users of a particular theme? Why not add it to core so that everyone benefits?
I know two major reasons for templates:
Flexibility for the visual presentation
Much cleaner code which is easier to maintain
The first reason I am remembered on during my daily work. It always hurts when I need to explain a customer that I can't realize their need for a specific look coming from their corporate design or an individual learning situation because Moodle is not flexible enough.
About the second reason I learned reading the book PHP in Action. On the book's website they write: "This book takes on the most important challenges of web programming in PHP 5 using state-of-the art programming and software design techniques including unit testing, refactoring and design patterns. It provides the essential skills you need for developing or maintaining complex to moderately complex PHP web applications."
The authors show in several examples how to make code clearer and easier to understand by separating program logic from presentation with templates. This way code can be better maintained.
Equipped with the knowledge from the book, looking at Habari and Drupal and the urgent need to be able to work more flexible with Moodle I implemented a theme class in Moodle 1.9. The theme class is the adapter object for any theme engine. To check the functionality I implemented "pure PHP" templates and PHPTAL templates. About PHPTAL I learned in the book. This template engine convinced me that it's better to implement an adapter to be able to use any template engine.
The outcome you can see on my Lab site. You may log in as "student" with "stud123".
With templates I am for example able to change the XHMTL structure to create an accessible Accordion course format. Or I can create an accessibility friendly 2-1-3 column layout.
And with templates there is no need to wade through a mix of PHP and XHTML. With PHPTAL I am even able to create the page in a XHTML editor with good page preview functionality with XHTML and the PHPTAL tags. This means I can work as a designer to get a good layout and can preview the page in a browser with placeholder information and optimize it until all details are right. These pages I can then directly use as templates for Moodle without changes. Marvelous.
There is just going on a discussion about Moodle on the touch devices Iphone/iPod Touch app idea. The discussion is about creating special apps or how to optimize Moodle to get it working on the devices.
With templates anybody can change the page layout to make Moodle work on any device without hacking the code.
The layout "Flexible" on my Lab site is one approach to react flexible on different screen width. You may play with the width of the browser window to see the behavior. The content box is 480 px wide and fits on the touch screen without scaling when you hold the device in landscape orientation. Moodle with "Flexible" can be viewed on big screens and on small screens without much changes. No need for extra design work or development.
To implement the 2-1-3 column layout and the "Flexible" layout in Moodle core at the same time is impossible. They are too different. Every task needs it's special solution.
And when you want to visually integrate Mahara (which uses Smarty templates) and Moodle we add Smarty to the template engines and build the Smarty templates to use them in Mahara and in Moodle. You design once and use several times.
Drupal and Typo3 for example can also work with PHPTAL or with Smarty templates. Moodle could be much easier visually integrated into a wider software landscape with less work.
Moodle needs templates to become modular in it's visualization possibilities and to be more easily maintained.
I had a look at your Lab site. It looks great!
I heartily agree that Moodle would benefit from a template system for presentation. Presentation of information is not a matter of good looks but of usability.
I come from a Drupal background where things are done pretty well IMHO.
For example the Zen theme (http://drupal.org/project/zen, inspired by the famous http://www.csszengarden.com) is a very flexible theme you can customize only using CSS.
And Drupal also has a very clean way of using JavaScript (http://drupal.org/node/304258), mainly relying on the power of jQuery (http://jquery.com).
I hope to see some of your work find its way into Moodle core. Perhaps you should make it an "official" feature request in the Moodle Tracker.
Kind regards,
Frank
Hi Frank,
yep, another mayor argument for separating program logic and page view and then using templates is the opportunity to enhance usability.
Moodle with it's "One size fits all" approach offers all options the developers can think about to present and/or handle pages in the form the Moodle developers have decided. With templates in opposite usability experts and visual designers can decide how to present content and which parts of the given functionality users need in a certain context without hacking core code.
In the Moodle forums usability is definitely a topic. Discussions about usability solutions are seldom. Why not hand usability decisions over to communication and usability experts?
A well organized page with not more than the needed buttons can easily be presented to users with templates. Page content and button/links are all generated - in the template only the useful elements are freely arranged.
- Study what your users need and what confuses them in your learning environment
- Arrange the content as needed on the page
- Display only those buttons/links users need - leave out the not needed and then confusing elements
In short - be able to use learning material/quizzes etc. in ways the Moodle developers never could think about. Not "One size fits all" but individually optimized pages for a superior user experience can be the result.
Did I mention that Moodle will benefit from templates in many ways?
I am not trying to imply that the fix-the-PHP approach is necessarily better either. I am just saying that as far as I can see, fixing usability problems and deciding whether to use templates in Moodle, are two separate issues. Improving usability is obviously something we should be doing (and we are). The templates issue still needs more discussion.
By the way, while the Usability forum has been very quite, that is because usability discussions have been taking place in more specific forums like the
http://moodle.org/mod/forum/discuss.php?d=109291 Roles and capabilities forum
http://moodle.org/mod/forum/discuss.php?d=109444 Gradebook forum
http://moodle.org/mod/forum/discuss.php?d=103869 and Quiz forum.
That last one is a particularly good example, because that work was a summer of code project by Olli, who certainly is a usability expert.
Since one of the key rules of usability is to involve actual users, I think it is probably quite natural that these discussions took place where they did, and not in the usability forum.
Oh, and the other day I did end up doing some hacking on a highly templated system. I thought it would be helpful if pages like http://cvs.moodle.org/moodle/user/selector/lib.php?r1=1.15&r2=1.16 displayed the commit comment on the top right (just under "revision 1.16 ..."). View VC does all the UI in templates, so to do that, I of course had to edit the template; but then I also had to hack the PHP code, in order to make that information available to the template. So, in that one example, templates did not help at all.
Look, the point is that switching the Moodle user interface to use templates would be a very big change, both conceptually and in terms of the amount of work that someone would have to do to implement it. And it would not just just require work on the core Moodle code, it would also require changes in every third-party plugin. And at the moment, Moodle works very well, for a lot of people.
So, if you want to propose a change of this magnitude in Moodle, it is inevitable that proposal is going to be subject to intense scrutiny. And the burden of proof is always going to be on the people proposing the change. You have to convince the rest of us that your proposal is worthwhile. Please do. If templates, are the right solution for Moodle, then I want to be convinced. But I will only be convinced by sound technical arguments that a particular detailed plan for implementing templates is right for Moodle.
At the moment, and without re-reading them all again, I would summarise the arguments given so far in favour of templates as: "Templates are a good solution for a large class of systems. For example they work well in Drupal." I agree that both those statements are true, but they do not say much about Moodle.
What do I mean by a convincing argument? Well, I hope that Development:Changing_the_Moodle_Question_Engine is (or will become) a convincing argument for changing the Moodle question engine.
You could also try showing us how the templates for some common parts of Moodle might look. Some (quite challenging) examples would be course/view.php, mod/quiz/view.php, mod/quiz/attempt.php and mod/quiz/edit.php. The last three are naturally quite close to my heart.
Tim, thank you for your long answer.
I'll split my answers into several posting - with one aspect each.
@ I am struggling to see the connection between usability and templates.
Usability is much about functionality presented on the page and the place where a certain link/button or similar is presented on the page. To change these aspects you need to change the XHTML structure of the page - and that is the template when you have a template system.
@ View VC does all the UI in templates, so to do that, I of course had to edit the template; but then I also had to hack the PHP code, in order to make that information available to the template. So, in that one example, templates did not help at all.
Right, you only can change the presentation of existing elements or leave those elements out not needed in the specific use case. Most template engines offer the ability to add content when needed. So you should be able to add the content without hacking core functions.
@ every aspect of the interface is controllable by the templates in the theme
The templates in the theme override the core templates. Only changes go into the theme templates. When you want core changes you change the core templates.
@ someone expending a lot of effort could make a theme that didn't suffer from usability problems. However, that is only one theme.
Often you don't need a lot of effort to solve usability issues in certain use scenarios. In my daily work I don't need to solve basic Moodle usability issues. I need to solve some usability issues related to certain tasks in the very specific learning environment. If I would propose this special fix you would ask what the general use for Moodle might be. Here we are stuck. The client can't solve her special usability issue because Moodle is not flexible enough.
@ the alternative approach is for developers to fix the usability problems by fixing the PHP code.
In your argumentation you sketch an ideal world. When you check the Moodle tracker you will find many proposals I have made to fix interface issues - many have never been solved. Or you will find issues where I wanted to optimize Moodle code and I asked for help because I was stuck. Many have never been answered. Moodle core developers have restricted resources and interface design and usability are not in the focus.
So your scenario that core developers are the only ones who can make Moodle work better is an illusion. Moodle needs to offer more flexibility that people working with Moodle can solve their issues themselves. And not by hacking PHP code with the implication to take care with every update.
That is one mayor reason why I argue for templates. When I am able to change the XHTML in the template without hacking core PHP code I can solve many issues within specific use scenarios easily.
There is no reason why these changes should not go back to Moodle core when they are of general interest. Your implication that the possibility to change the specific learning environment hinders Moodle from evolving in general I need to reject.. I suspect the opposite will be the case.
For example: When I propose templates you ask for examples. When someone optimized Moodle in a certain use case you have the example. But to be able to create working examples Moodle needs to be more flexible. Looks like a vicious circle.
I looked at your Unodo site, and I think I have a hunch of what you mean. Your template - it's a shame I couldn't access any course inside - does look like a work in the art of simplicity.
But with Moodle, this being my two cents worth, I am not sure if major customization to make Moodle suit absolutely perfectly very specific situations can be part of our scope. I know you are suggesting a generic solution to solve many specific situations - the question is then, whether these situations bring sufficient worth to the bigger Moodle community.
The reason I doubt this that the reason I admire your site is because such examples are rare. The usual case is, it seems, that nor school/uni IT admins nor the teachers have sufficient usability/information architecture knowledge to put up a decently organized course where students would not get lost. Of course this is partially also a problem of Moodle navigation.
As an example, in the university I was working on Moodle a year back - although the same university has great courses on usability - I was hard pressed to find anyone with constructive views on the subject in the IT administration where management and custom development was made.
Olli
Olli, thanks for your nice words.
When you have looked at lab.unodo-design.com you find the login data on the start page. I have intentionally not presented it more obvious.
I agree that in the academic field flexibility is not that important because few people there may want to handle it.
When you work with companies flexibility is a must. They spend big amounts of money for corporate design. Learning environments must fit into the company appearance.
And all design oriented users will benefit too.
Another aspect is that with templates it would be much easier to enhance usability. You wouldn't be forced to change core files in many situations but rearrange page elements via templates. Many more people could experiment with what fits for their special needs and could contribute real working examples to the UX discussion.
@ You could also try showing us how the templates for some common parts of Moodle might look. Some (quite challenging) examples would be course/view.php, mod/quiz/view.php, mod/quiz/attempt.php and mod/quiz/edit.php. The last three are naturally quite close to my heart.
Ask Martin D. I had sent him a rewritten course. By the way - he never answered
In the area of the quiz, where I am responsible, I hate it when people send suggestions to me personally. I would much rather that they go into a public forum, so that everyone can comment, and I can base my final decision on a group consensus, rather that having to analyse everything myself.
(I will reply to some of your other posts tomorrow. For now, I must say good night.)
Tim, I had sent Martin the example he had asked for.
@ Look, the point is that switching the Moodle user interface to use templates would be a very big change, both conceptually and in terms of the amount of work that someone would have to do to implement it.
Whom do you tell? I did this work for the unodo lab site. And I know about the huge benefit - also from practice.
@ And it would not just just require work on the core Moodle code, it would also require changes in every third-party plugin.
With a clever refactoring strategy this change can be done in small steps. Only the parts that must work with templates need to be changed. On the unodo lab site template built pages work together with "old-fashioned" pages. On that site you see that in the "Basic round" design template built and "old-fashioned" pages coexist nicely - users wont notice any difference. Only in the "Flexible" design several pages look odd. The refactoring process can take as much time as needed and can be done in small steps.
@ And at the moment, Moodle works very well, for a lot of people.
I would rewrite this sentence: And in the moment, Moodle works good enough for a lot of people. For many people it doesn't.
And I don't talk about theory - it's daily work reality.
1) Moodle quickforms are basically a templated approach. I think they're a good one, although they haven't been universally popular.
2) Changing all of Moodle into a completely separated presentation layer (back-end -> XML data -> presentation), while certainly a tempting prospect if doing it properly [ie not 'oh let's use smarty'], seems unlikely to ever happen. At least, it might as well happen at the same time as we rewrite Moodle in Java...
3) Main thing that really needs to be done is to improve separation between back- and front-end code. (Easier said than done, but still...) Needs doing regardless of templating or not.
4) Another possibility would be to work out more classes of rich presentation object that can be reused (and easily restyled by themes) - PHP is already a templating language, let's take advantage of that. For example, tabs work pretty well. Anything else in that category we could have? Something you could draw with a simple function or object call that would do useful stuff in a standard way.
5) If we just want to replace core code from themes, that's easy now as far as I can see. Here's how:
a) Theme includes a file like (theme) php/course/view.php
b) near the start of config.php, get current theme, and look for (theme)/php/WHATEVER.php where WHATEVER is the path relative to moodleroot of current script. Obviously skip this step if we're already in a theme php file, also handle parent theme, etc.
c) If such a file is found, require it and exit (without running the original file)
I.e. just give themes a chance to replace any php script they like. PHP's a templating language, why not use it for templates.
At the moment there are few Moodle files this is likely to work well for - i.e. the replaced files would have a good chance of containing much back-end code and not working following a version upgrade. But there's no reason I can think of that it shouldn't work when scripts properly separate front- and back-end code: a requirement for using a templating system anyhow.
I admit it's a bit low-level and drastic, but it would work for existing code...
6) Another minimalist PHP approach (but that only works for new code) would be to just make a nice Moodle API for requiring a template PHP file instead of require('whatever.php/html') that uses theme to switch in files if needed. Eh, don't know about that...
--sam
Colour me scared.
--sam
Sam,
2) is not necessary at all. Refactoring to separate program logic and view and use templates in the form of PHP includes for the view is perfect.
3) is exactly the point to enhance code quality and maintainability. Great that you see the need to investigate in this area. And from there it's only a small step to templates.
4) is marvelous for programmers but is difficult because web designers gain less influence on the visual aspects of the learning environment. Designers are the visual experts.
6) is the approach I am working with in the moment
And another one
@ At the moment, and without re-reading them all again, I would summarise the arguments given so far in favour of templates as: "Templates are a good solution for a large class of systems. For example they work well in Drupal." I agree that both those statements are true, but they do not say much about Moodle.
That is one aspect. Another very important aspect is flexibility. When I need to react on certain project specific demands Moodle needs to offer the flexibility to solve the task. If it doesn't I need to implement a minor solution. Or I need to hack Moodle core with all implications on updates.
That's inconvenient for customers concerning updates or inconvenient for the learners when the specific needs are not fulfilled.
I heavily argue against the "One size fits all" approach. Reality has often enough proven that the flexible approach helps much better. For the learners benefit.
@ What do I mean by a convincing argument? Well, I hope that Development:Changing_the_Moodle_Question_Engine is (or will become) a convincing argument for changing the Moodle question engine.
Do you want to say that only arguments certainly formated and presented may have a chance to be considered? (Like a state office only accepting special forms
When I proposed a solution how to add CSS hooks for Moodle 1.5 no form was needed. The huge work was just done. Acceptance is also a matter of focus.
My proposals derive from my work and my experiences as the Moodle "theme manager" and actually my work on the new Moodle2 theme you see here. No theory, no woolgathering.
And I will continue my work adding templates to Moodle - Moodle needs templates
No, formatting and presentation is irrelevant. The substance is the important thing. I try to explain clearly exactly what I propose to change; I justify the need for that change by making it clear what I think the goals are, and by listing existing bugs from the tracker that will be resolved; and I try to quantify the costs.
Adding more CSS hooks did not require much justification because it was obviously a good idea with nothing to loose. It did not break backwards compatibility, and could be done a bit at a time. There was lots of obvious benefits, it was clear exactly what you were proposing, and the costs were minimal.
Here, the detail of what you are proposing is not clear, and cost, in terms of amount of work required is much higher. Also, it will break backwards compatibility. Therefore, you will have to work much harder to convince us it is a worthwhile change.
@ In your Use of JavaScript in Moodle reply you wrote: "At the moment, if anything, the Moodle code has too many inconsistencies. For example, the library that builds the admin tree is completely separate from the forms library, even though they do a similar job."
That's not only the case with core code but even more with the user interface. To build a Moodle theme takes a certain amount of time. And then you need to investigate a huge amount of additional work and time to finetune the theme for many inconsistencies for several core and third party pages.
With templates I could fix for example the module templates once and save a lot of work for future themes. And when customers accept giving back work payed by them I could commit the template changes back to Moodle. And all Moodle themers would benefit.
No, I am not going to try to understand how all the PHP - XHTML mixes work in several Moodle modules. It takes much much more time to understand program logic and presentation parts mixed together than to understand the clearly separated presentation part. Templates would help to build better readable and maintainable code (That is common developer knowledge and experience).
And when third party developers could focus on writing code to handle content and use standard templates to output their content the Moodle user interface would be much more consistent than now. Now many developers try to do web designer work and create huge inconsistencies - not willingly but just by lack of knowledge and experience.
Tim, thank you for investigating in this discussion. Your answers/remarks help a lot to collect and work out the arguments.
After so much theory I have written an article Moodle :: Solving Issues with Page Templates about my work on the "image slideshow" module. You may read it in my unodo-design journal and check the examples.
I could not only solve several issues but the templates even offer new opportunities.
At first glance there are some promising signs. The template syntax is nice (simple example right at the top of http://phptal.motion-twin.com/), and they claim that compiled templates are fast (obviously we need to check that claim out).
The syntax is a port from a similar project in Zope, and so has been knocking around for several years. Hopefully that means it is stable.
There seems to be a reasonably good manual.
Their core code is only about 230k when checked out of SVN.
From their news feed the project seems to be actively maintained.
Some questions:
- does anyone else know who else is using this?
- has anyone used this in anger? how was it for you? (We already know that Urs likes it.)
Some questions I intend to try to answer while looking at the code:
- They have support for internationalisation in templates, which is nice, but using gettext. How much would we have to hack it to use our get_string?
- Could we make an HTMLQuickForms renderer so that we can render all our existing forms using PHPTAL without having to rewrite them?
- Could we make backwards compatible print_box_start/end functions, etc, that call into PHPTAL templates, so we can maintiain backwards compatibility with existing code for a few releases while making the transition to templates?
- Does this templating system answer the concerns of large reports, where you want to use recordsets and render the page progressively, rather than loading all the data into memory, and then rendering all at once (if your server has not crashed)?
- What happens to our existing reports, where we use the same code to output XHTML, as well as CSV, Excel and OpenOffice format? Would be silly to clean up the HTML output, but only at the expense of having to duplicate code for the other fomats.
A question about templates in general: How do you use templates when you have a configurable interface. I am thinking of Moodle settings like 'Enable groupings', 'Show user idnumber in gradebook reports', configurable sort order on tables, configuration of which users can see which user profile fields, ...?
Do you just end up with templates with millions of if-statements in them? If so, is that really an improvement. If not, what is the nice way to do it.
Here's my two cents from a Drupal standpoint:
1) Drupal uses its own PHPTemplate theme engine as a default:
"Drupal's default template renderer is a simple PHP parsing engine that includes the template and stores the output. Drupal's theme engines can provide alternate template engines, such as XTemplate, Smarty and PHPTal. The most common template engine is PHPTemplate (included with Drupal and implemented in phptemplate.engine, which uses Drupal's default template renderer."
(from http://api.drupal.org/api/group/themeable/6)
"PHPTemplate theme engine"
http://drupal.org/project/phptemplate
An extensive rationale can be found here:
"Open discussion on Drupal's themeing capabilities and templating engines"
http://drupal.org/node/7133
2) You can plug-in other engines as well, e.g. PHP TAL: http://drupal.org/project/phptal. The example code given there shows that PHP TAL looks much cleaner than PHPTemplate, no ifs etc. needed.
3) Quotation regarding PHP TAL by the developer of PHPTemplate Adrian Rossouw (from the above mentioned http://drupal.org/node/7133).
"Other than pure PHP, PHPTal is the only templating engine I would actively recommend to anyone."
Kind regards,
Frank
I've been thinking about this, and switching Moodle to a templating language like PHPTAL still looks like a huge job to me (huge, as in, "please can we leave this until Moodle 3.0?"). Templates can undoubtedly be used to make very nicely architected software, but Moodle is currently a long way from having that sort of architecture.
It is much more realistic, as a first step, to find a compromise solution to the requirement "Let someone who doesn't know PHP have more control over the HTML that Moodle outputs." And continue to gradually try to separate presentation logic from back-end logic withing the current code base. That is is what everyone says the architectural benefit of templates is - it forces that separation. (As opposed to the practical benefit of letting non-PHP programmers change the HTML).
And actually, 'separte presentation logic from back-end logic' sounds easy until you try to distiguish the two. Would someone who thinks they understand these things like to look at http://cvs.moodle.org/moodle/mod/quiz/view.php?revision=1.157&view=markup, particularly the second half, from the comment '/// Print table with existing attempts', and tell me which bits of that are presention, and which are back-end, because I am not sure where the right place to draw the line is.
Another thing that I don't understand is how do you combine templates and Ajax?
Ajax, used properly, can greatly enhance usability. We are gradually adding more of it to Moodle, and hopefully everyone agrees that is a good thing. (It goes without saying that this is all progressive enhancement, and that Moodle will continue to work without JavaScript for accessibility and other reasons.)
Now, Ajax often involves JavaScript code creating and updating HTML. If the HTML can be varied using templates, how do you ensure that the JavaScript continues to work, and generate the same HTML as the server-side code?
If you want a specific example, look at http://cvs.moodle.org/moodle/user/selector/lib.php?view=markup and http://cvs.moodle.org/moodle/user/selector/script.js?view=markup. That is all code that I wrote recenly for Moodle 2.0 and I am quite proud of it. It does a lot of things right from a developers perspective. The inner workings are nicely encapsulated. It is easy to subclass to change the business logic of how it searches for users. The display logic is separate from the search logic. The HTML output is clean and uses nice progressive enhancement JavaScript. (A design patterns purist would probably split it into three classes following the MVC pattern, which would be perfactly easy to do, but wasn't necesary, so I didn't bother.)
However, the JavaScript methods user_selector.prototype.output_options and user_selector.prototype.output_group dupicate the HTML generation in the PHP code in output_options and output_optgroup; and I could not think of any way to avoid that (because of the bit about not loosing which options you currently have selected when the search results change).
I expect that people who are familiar with templating systems have an answer to this. I just don't know what it is, and would like to know.
"Let someone who doesn't know PHP have more control over the HTML that Moodle outputs."
This part I always find silly. PHP is a templating language. All the templating languages force the user to learn a few bits of syntax for
- variable interpolation
- conditionals & flow control (for/while/switch)
PHP has all of that, and more. If you have to teach them something... teach them PHP
All the PHP-based templating schemes I've seen are horribly slow because they are implemented in PHP... instead of C.
We have a fast templating lang written in C, with precompilers, caches, the works!
'separte presentation logic from back-end logic' sounds easy until you try to distiguish the two.
Completely agreed. For any reasonably sophisticated UI, it's nearly impossible.
I also itch when people talk about "programming without programming", a.k.a. "lego brick programming". We can have things like custom reports on some data, but they are usually just simple 2d tables with no built-in UI like the ajax mentioned here. Sometimes even rules like "sums over 100 in bold, negatives in red" start to give trouble.
Loops and conditional logic requires the unambiguous grammar that will inevitably transform into a programming language once it's past the "simple 2d tables" state.
Maybe refactoring some insides of conditionals and loops (as in Tim's example) to separate functions that can be overridden by some local scripts sounds more sensible to me than to throw all the dice again and paint templates over everything.
CSS is already capable enough to move things around and ti hide unnecessary stuff. Anything beyond that requires something that will be awfully similar to any simple scripting language anyway, say, like PHP
The appoach of building a really good XHTML output in core code and leaving all design to CSS was the one we've been taking, but I do really understand Urs' frustration that it's very hard to make the XHTML really good this way.
Right now I'm thinking this: don't plan 100% conversion to templates and get caught up on the edge cases, but just replace the generic things (similar to what weblib provides) with more templates, and take the opportunity to clean up what we have there at the same time (for example header.html and footer.html have way too much logic in them and could be broken up). It would also be pretty easy to put weblib in a class at the same time and allow themes to override some of those functions with full PHP if they want to.
This would allow someone like Urs to easily control, say, 75% of what they are looking at by simply editing templates and CSS, while the rest of the tricky content will have to continue relying on developers to put CSS ids and classes throughout (as they do now).
And it has the benefit that themes won't be too radically different to now.
And it will allow Moodle 2.0 to come out this year
If we put all the print_XXX methods from weblib.php into a class (moodle_renderer) and let themes override this, then we could make a subclass for themes that want to use templatse (moodle_templated_renderer). In that class, print_box, print_box_start and print_box_end would all be implemented by looking for a file called theme/mytheme/templates/box.html that would contain something like
<div id=%%ID%% class="%%CLASS%%">%%CONTENT%%</div>well, that would do for simple themes, for something like the custom corners theme, you could make it do more.
At the same time, we need to improve the coding guidelines, so that developers start writing code with more separated presentation, and good consistent use of ids and class names etc.
@ <div id=%%ID%% class="%%CLASS%%">%%CONTENT%%</div>
Tim, do you want to replace the %%ID%%with the real data? This looks like an example of slow templates.
Why not use
<div id="<?php echo $id ?>" class="<?php echo $class ?>"><?php echo $content ?></div>
Habari for example uses objects for posts. In the template you even call methods like
<div class="posting"><?php echo $post->content_out ?></div>
Templates offer the advantage to understand the XHTML structure without guessing. The mix of PHP logic and XHTML echos is often nearly unreadable and working on the output means time consuming trail and error.
Yes, when you need to integrate many options you need to work with a lot of conditional statements. PHPTAL offers the most elegant solution for this issue as far as I know. But nevertheless you keep a page with a clear XHTML structure. PHP XHTML echo mixes seldom offer a XHTML page structure at all.
And procedural programming suffers often from sometimes unreadable cascades of conditionals.
I don't think you have answered my question about the separation of Presentation and back-end logic. I agree "when you need to integrate many options you need to work with a lot of conditional statements". Now presumably some of those conditions are back-end logic, and others are just presentational issues, and so with templates, some belong in the template, and some in the PHP. I just don't know how you reliably tell the difference, and I asked you to explain, preferably by way of a specific example (mod/quiz/view.php).
You may have a look how I refactored the slideshow. (slideshowtwo.tar.gz)
Although, based on the list at Tuesday's dev meeting, I think an awful lot of other things probably need to happen (by which I mean, planned features need to be postponed) in order for 'Moodle 2.0 to come out this year'
Martin D, nice to read your posting
And probably there may also be the option to hook a template engine in in some way.
Another aspect: Let's talk about time and money.
I don't get payed for my work on templates. My motivation to investigate is the need to help to create a Moodle 2.0 where it is more easy for me as a web designer to build Moodle layouts which fit customer needs.
In the moment I need to correct too many inconsistency issues in Moodle and tell clients too often that their needs can't be fulfilled with Moodle. Or that it will be so expensive that they can't/don't want to pay. The design work with Moodle is much more expensive than it should be. The outcome is that it's harder for me to earn the money I need for living than it should be when I work with Moodle.
And that is the situation with every visual designer working with Moodle who tries to earn her living with this work.
How people react in this discussion: Martin D. has shown a possible way to proceed. Martin L. argues categorically against changes. Tim asks me to solve some sophisticated tasks. Only to give some examples.
I am sorry but I don't have the time now to investigate so deeply in the very moment. To those who are interested in possible ways to evolve complex and rich applications like Moodle I recommend the book "PHP in action" I had mentioned in a previous post. The authors don't mention Moodle but they write about complex web applications, about readable and maintainable code, the work with SimpleTest for test driven development and HTML_QuickForms for form handling. All aspects apply quite well to Moodle
And they show the advantages in the work with templates.
Web applications based on templates are often easier to handle for a bit more sophisticated visual needs than changing colours or the logo. We can create visually richer outcome in less time (for less money).
Or, is this already happening?
mike
Samuli,
@ "CSS is already capable enough to move things around and ti hide unnecessary stuff"
That's a wide spread myth. Working on the Moodle2 theme we had several issues where Martin D. needed to change the PHP code to get the desired outcome. With templates I could have changed the XHTML myself. The workflow would have been much more effective. And when you think in economic dimensions it would have been much cheeper.
You are right, http://www.csszengarden.com proves how much you can twist and tweak a layout just using CSS.
The prerequisite is an extensive and deliberate use of CSS IDs and Classes so you can access all elements.
(That would also provide hooks for AJAX implementations, e.g. with jQuery, but that's a different story... http://moodle.org/mod/forum/discuss.php?d=106312)
I have already mentioned above that Drupal provides such an extremely flexible theme (http://drupal.org/project/zen).
Therefore I agree with Martin's proposal. We should see how far we can come with CSS (and provide some tutorials for using CSS, see http://docs.moodle.org/en/CSS_FAQ) and leave switching to a template system to a later release of Moodle.
Kind regards,
Frank
CSS Zen Garden is nice - and it's one reason why the myth keeps alive.
CSS Zen Garden is a visual experiment initiated to prove the power of CSS in a time where all the world worked with tables and presentational markup. The page/content has a simple structure and only some text is used.
When you have to deal with table-less accessibility and SEO friendly 2-1-3 three-column layouts as they are needed for Moodle you will very fast notice the limitations. Sounds complex and is complex. The CSS Zen Garden is a Kinder Garden and a Web design student playground compared to real world tasks.
The important message is: use clear XHTML structures without presentational markup. Use CSS for the design. Use unobtrusive JavaScript for a behavior. The message is not - You can change anything with CSS. All three aspects play their important roles and you get well working pages only when all three aspects work together nicely.
In Moodle we deal with complex structure and content.
Someone who knows a bit about CSS, but who has not been doing in-depth for years like you, posts saying 'you can solve any layout problem with CSS, look at CSSZenGarden'. And you, with your greater knowledge and experience, have to patiently point out that it is not that simple in the real world, particularly not when you are dealing with the HTML that Moodle currently generates.
You suggest we use templates to generate all the HTML in Moodle, because of one section of a book you have read, and because it works in Drupal. And we, with our greater knowledge and experience of software architecture, patiently (or impatiently in my case) point out that it is not that simple in the real world, particularly not with the way Moodle code is currently structured.
I went on a little hunt for PHP in Action in Perth's book shops today, but failed. I wanted to see what it had to say about templates, but having looked at the description and (excellent) reviews on Amazon, I am not tempted to buy it for myself. Of the 5 bullet points listed under Product Description on the Amazon page, I have already read other more in-depth books about four of them, and it feels a bit wasteful to buy the whole book just for the one chapter. Hence my evil plan to find it in a book shop and sit there and skim-read the templates chapter.
Ah, now I see which way the wind is blowing. You simply deny me (the designer) the competence to talk seriously about development. That's easy and very successful.
Let's go back to business as usual.
PS. May be you change your mind a bit when you have seen in the book that the authors write about separating page logic and presentation with templates throughout the whole book.
I interpreted Tim more as "the examples of separation in the books are a kindergarten version of what we are doing
One advantage of using templates is that it enforces this separation. But then again the downside of that is that if in some case no such clear separation exists, then some odd compromises might have to be done.
I'm advocating "view layers" classes, but I understand that in some places I might have to "put my money where my mouth is" and code an example of what a view layer of /course/mod.php might look like, for example.
Or a template of Course front page. Let's imagine that we allow people to place blocks in a dynamic amount of places. How would a template accommodate that?
For those who have not been reading other threads in this forum. Or Recent Changes on Moodle Docs. I have started trying to write down ideas in Development:Navigation/Pagelib/Blocks_2.0_design, based on Martin's outline of what we are trying to achieve in Development:Navigation_2.0. There still seems to be a lot to work out before I can start coding. (Looking at what is left on the roadmap, it is likely to fall to me).
I suppose this might be one of the rare occasions where it is OK to cross-post to a few forums. I guess Blocks and Themes are the ones. I'll do that at some point.
Martin L, sorry, what do you want to tell us?
@ "All the PHP-based templating schemes I've seen ..."
How many have you seen and which ones are that? We talk here about "Raw PHP" templates or PHPTAL and Smarty. "Raw PHP" is pure PHP. PHPTAL and Smarty compile the templates to pure PHP and cache them. So there are only marginal speed issues. Bad written PHP pages are much slower than good written pages using templates.
And in PHP XHTML mixes you get much easier validating issues because you don't get an overview of the XHTML structure. Page validating is a real issue in Moodle.
@ "Completely agreed. For any reasonably sophisticated UI, it's nearly impossible."
How do you mean that? Can you give some examples? My experience with "Raw PHP" or PHPTAL are that you only get in trouble when you have basic logical or structural issues in your code. When you hack around you get problems. When you work clearly structured and organized you will find the right way to generate the content and then output it with templates.
I hope that you don't want to tell me that I am stupid arguing for templates and that only you know how it goes.
I have seen several, not PHPTAL but I've done quite a bit with Smarty. Last time I looked, the costs of Smarty were very significant in performance and complexity.
And complexity is a very big issue. When everything goes well and your abstractions don't leak, fantastic. But as soon as your abstractions leak (see http://www.joelonsoftware.com/articles/LeakyAbstractions.html ) you have to get in there and understand what is going on.
Can you give some examples?
Tim provided one but I'll give you another -- non-moodle related though.
A lot of times I've seen templating technologies that argued that it was possible to abstract the UI from the display. Case in point: "deliver your app (actually, your data entry forms) to WAP, HTML and native desktop apps from one source". There's about a dozen tools that want to do that.
And they are all broken, even when they work. Why?
Because the medium is completely different. That big form doesn't fit in the WAP phone, and wants to be broken down into pages and turned "resumable". On the html page it's huge but you can scroll down, on the desktop app you can use advanced UI elements not available on WAP or HTML.
I'll say to somewhat controversial things...
1 Any interesting "template" change has to deal with the code logic. Imagine taking a forum page that doesn't do threaded, and adding 'threaded view' support.
2 90% of the non-interesting template change (non interesting as in: it really doesn't change how the UI works) can be done with CSS, or we can improve the XHTML/CSS so that it becomes possible. It's amazing, people have 1 gripe with a specific page where the CSS hooks aren't good enough... and want to rewrite 80% of moodle instead of fixing that page
3 Yes. There is a 10% of changes that seem like they should be trivial but are very hard or not doable with CSS without changing the code. All technologies end up having corners that for good or bad reasons are not really easy to hack. In the short term, patch it locally and get on with life. Long term, try to figure out if an improvement under 2 is possible.
And what is most funny to me is that IMHE all systems have some 10% that is not really easy to tweak. So if we take on a big re-implementation of how we do templating, we'll work a ton, and if we're exhaustive we'll go from 10% to 9.4%. And the 9.4% will actually move around -- some things that were templatable before may not be any more.
My belief is that we can chip away at that 10% doing what I propose in #2 and #3... and educate people about recognising when the change they want falls under #1 --that is: learning to realise that the change you are after also affects codeflow, so it cannot be done with pure template changes.
Couple of additional comments
I hope that you don't want to tell me that I am stupid arguing for templates and that only you know how it goes.
Oh no no no! I think everyone here is fairly well informed and knowledgeable, and you specially about templates. We do have different perspectives and experiences though. And mine is that some things that seem possible to fix with templating are actually... almost impossible for something of the richness and complexity of moodle (tiny projects sometimes can)
Also wanted to say: MartinD's approach seems sensible. But where Tim talks about templating with custom interpolation, I'll say... how about a cup of supporting PHP syntax?
Martin,
thank you for your long answer.
@ We do have different perspectives and experiences though. And mine is that some things that seem possible to fix with templating are actually... almost impossible for something of the richness and complexity of moodle (tiny projects sometimes can)
The authors of "PHP in Action" tell the opposite and help to understand and implement. I trust them.
I mentioned the book in a previous posting.
Tim, @ "Now, Ajax often involves JavaScript code creating and updating HTML. If the HTML can be varied using templates, how do you ensure that the JavaScript continues to work, and generate the same HTML as the server-side code?"
Mostly when working with Ajax you use a DOM element like a DIV with an ID as a container for your Ajax output. One must not change that container - but you can move it in the XHTML structure as needed. Working with templates gives more freedom - and as always with more freedom more responsibility: you need to be careful not to break the page.
(Have you looked at the user selector widget in Moodle 2.0, with JavaScript on and off?)
As a fanatic user of Zope/Plone for ages I was delighted to discover the port of TAL, METAL language to php and decided to give it a go few months ago.
For somebody familiar with the original python based version, the learning curve was smooth, no problems but quite a lot of adaptation have to be done :
- converting my many Plone templates to PHPTAL was quite difficult, especially due to the fact that the usual path syntax "here/somepath/somefile" is not supported ; here must be removed .
- The same goes for the pseudo keyword macros that must be removed " <div metal:use-macro="./global_siteactions/macros/site_actions" /> must be changed to < div metal:use-macro="./global_siteactions/site_actions" />
- the parser is not as robust as the Zope parser and some strange syntax errors were fixed by removing/adding blank lines or carriage return.
- to my knowledge, it is quite easy to "include" HTML chunks generated by other templates engines into phptal using <tal:block tal:content="structure ${my_sub_template_output}" /> but not the other way around ; so phptal must be the "main template provider" , so migration is difficult.
- security issues were also reported due to the fact that an hacker can easily overwrite the cached "pre-compiled" templates that are world writable.
- finally I have noticed that some quite big other projects such as MediaWiki or ccHost have dropped PHPTAL in their most recent versions ... I wonder why ?
My two cents .
I'm not a fan of templates, I just don't see the point when what IMHO you are really doing is just trying to promote good practice which can be done just as easily in PHP code.
But, anyway, my main point. A templating engine adds additional complexity to a fundamental part of Moodle and hence is another barrier to understanding it. Please let's not forget "KISS". There's already quite a few examples of hard-to-get-to-grips-with APIs (e.g. I wasted days recently being actively obstructed by Formslib). If this is going to happen (because, presumably, it has real advantages rather than just because somebody thinks it would be cool to have) it has to be sane and somebody has to write proper documentation. Probably the other way around actually
It doesn't matter a stuff if Moodle has templates or not. In the most part the code in most of Moodle does not have the (excuse the Java-ism) business logic separated from the view logic. There's a whole raft of refactoring to do to "fix" that first. THEN we can have the discussion about having templates or not. Of course, by then the code will be all nice and we probably won't want to bother
However, I am prepared for the fact that I might be wrong, and so am happy to go on discussing this with people who wish to persuade me otherwise. I am trying to keep an open mind.
To which end I would like to flag a parallel thread in the Themes forum, to which I hope http://moodle.org/mod/forum/discuss.php?d=116398#p512326 is a useful contribution.
Then again, I may not, so please read and criticise.
First, we really should be talking about validating xhtml at all times imho, not html.
Secondly, when people are talking about cleaning up the markup, does that include the tables currently being used for layout? If a lot of markup is going to continue to be provided by Moodle core, then we really need to get that markup up to standard. If people are still to be required to do a lot with the css alone, then the markup needs to be free from table-based layout imho.
I'd also like to give an example of where css alone cannot deliver the modern designs that users expect. Very often you need to hang slices of an image at various points on an element. You might need a slice of texture repeated by x or y plus two or more corner elements. The standard way to achieve these designs as markup (as opposed to just dropping large jpegs in that google cannot parse) is to wrap elements in additional divs and build your design elements as background images attached to these wrappers. Each element can only have one background image so there are often times where you need to add a wrapper div in order to build the kind of funky designs that designers create in their adobe suites. Although wrapper divs and the like do not meet the strictest standards of semantic markup (which remains for me an ideal) they are often a necessary evil in order to achieve the design that some adobe guru has passed to you.
Imho we cannot really talk about css alone, we are always talking about a css/xhtml interaction, and when you have no control over the xhtml, your design options can get pretty limited.
Unfortunately, I have been forced to accept that 'eye candy' rules in the modern world. If an application does not look right to a user, many (but not all) are unlikely to engage with the application and they will perceive it to be 'not very good'. They won't know exactly why, but they just won't like it. If the design 'pings' and it has the right 'whizzy bits' then, sadly enough, they will probably consider it to be 'quite good' and begin to engage with the application. If we really want Moodle to reach the masses we have to get it looking cool and unique for each site that runs it.
Looking forward to working with you guys over the weeks and months ahead,
dan
ps please let me know where I can help best!
Also, in developer debug mode, you get a row of validate links in the footer that are also there for a reason.
However, in a big complex application like Moodle, occasional problems will slip in. They are bugs, and if you find a specific instance, you should report it in the tracker.
Yes, I plan to kill tables for layout as part of the Moodle 2.0 theme changes.
Extra divs in some places are available is you use the custom corners theme as a parent theme.
Even more control over the HTML will be available in Moodle 2.0. The system I designed a while ago is now definitely going to be implemented. See Development:Theme engines for Moodle? for details.
"Semantic DIV IDs?"
http://moodle.org/mod/forum/discuss.php?d=121398
Any input appreciated!
Cheers,
Frank