David Scotson

• Google Site - pass the search argument to google restricting the search to your web site
• Google Internet - pass the search argument to google for a fill internet search

Both of these are relatively easy to do. Instructions are available here:

http://www.google.com/searchcode.html

Though to search within your course you'll need to allow Google to have guest access which is an option since 1.2. Note that this has privacy implications as the general public searching on Google will be able to see the content of your courses.

I would highly recommend reading the sample chapters of the book "Designing With Web Standards" by Jeffrey Zeldman available here: http://www.zeldman.com/dwws/

The two freely available chapters walk through what he refers to as a 'transitional design' i.e. something that uses a minimum number of tables for the basic structure but delegates the majority of the styling to CSS.

He also talks about why he continues to use the bgcolor attribute in XHTML transitional even though it 'could get us thrown out of the Pure Standards Academy' and drops in a variety of accessibility tips too.

The entire book is highly recommended.

The link you provide is about HTML versus XHTML in respect to accessibility (at least as far as I read), but in my reply I was referring to disagreements over sending XHTML to browsers as XML versus HTML. The best summary of this argument I've found is here: http://www.hixie.ch/advocacy/xhtml (you may have to 'view source' to see that correctly in some browsers as it's just a text document).

And while the guy who wrote that really does know what he's talking about and says (basically) not to use XHTML, I've not seen many other people (again, looking to those who know what they're talking about) follow his lead. I get the feeling he's just being pedantic.

Given that the above seems to have been decided by general acclaim in XHTML's favour I'm not sure what the benefits are to creating XHTML and then delivering HTML. But I can see that it would add a layer of complexity when debugging layout issues and possibly be a drain on server resources.

I like XHTML, particularly for generated web pages, because it gives you another level of error checking because the page should at least be valid XML. Kind of like using a compiled language, you can catch a whole range of stupid errors at an early stage. It also allows you to use a variety of clever tools e.g. easy translation from XML via XSLT and seems in general to be more 'programmer friendly'.

I favour transitional rather than strict because I don't think it is wise to do everything at once. Since Moodle is made up from many different components it will be easier to get them validating at the transitional stage and the sooner it validates the better. The jump to cleanly separated presentation and structure can wait until after the more mechanical and straightforward translation of invalid HTML -> validating XHTML.

My comments on the proposal:

* Planning to replicate current html structure in templates first is a very good idea.

* XHTML 1.0 Transitional is a good choice as it is XML and provides a stepping stone to strict.

* WAI, SENDA and Section 508 standards are all good things. It is important to remember that these standards are not met just by creating valid (X)HTML. Proper semantic use of tags and probably extensive user testing is required to fulfil the spirit and not just the letter of the law.

* You mentioned elsewhere using templates to tailor content for phones,PDA etc. I think that it is a much better idea to aim to do it all in CSS with a single properly marked up XHTML page being sufficient for all different browsers & platforms *if* it is done correctly.

* "Users choosing themes" needs to be clarified. Most user style switching I've seen is done via the javascript/cookie/CSS route. This should, I think, be separate from administrators choosing themes. To clarify my own point: choosing text size (and maybe font but less importantly) should be up to the user. Providing a hi-vis / hi-contrast / colour-blind safe alternate theme should probably be a commonly developed default part of every different 'theme'. But allowing end users to choose between a wide variety of skins (that look like Mac OS X, or match their football colours or whatever) through a PHP based mechanism seems A) somewhat frivolous and B) to impact negatively on the usability of the site (for example using coloured text in forums that might be invisible on certain backgrounds). Minor visual changes within a theme a la http://www.simplebits.com/ (has colour controls in the top right corner) seem more appropriate on a user selected basis.

* I'm struggling to express why I think multiple templates (per device, or per Moodle theme) are a bad idea. I think my main problem is that creating a proper semantically correct XHTML layout is a very difficult task. Once it is done then creating different CSS 'views' or 'themes' should be relatively easy, but it will be an iterative process with people needing things added to the XHTML in order to do interesting things in the CSS. (see http://www.csszengarden.com/). By encouraging people to fork the XHTML, you are losing focus and asking for a large number of templates/themes using traditional HTML shortcuts as it simply won't be worth the effort to get it to work 'correctly' (from a CSS/accessibility/code-sharing perspective) in a single theme utilized by only a small subset of the users.


* A web interface to colour sets (anaglogous or complementary color schemes, different shades of a single colour etc.) is something I was also thinking about. However, I was thinking that after the colours were chosen then a new .css file would be written out from a template (which should help with style caching problems too) rather than have them called each time from a .php file which is 99% CSS and changes once in a blue moon. After this file generation step they would then be totally transparent to the rest of the system, which would deal with it just like a hand generated .css theme.

* "All styles will be named with a mdl_ prefix to allow mixing with other styles." I have no idea what this means!

* Smarty seems like a good choice.

* Gradual change is good.

That's all for now, hope you find this helpful.

I see Howard has been talking me up, while I typed this reply, hopefully it won't be an anti-climax after all the hype.

I agree with Martin that XHTML transitional 1.0 is a valid and useful goal. To answer someone else's question it's main advantage over HTML 4 is that it is XML which allows it to be operated on as such with some slightly more advanced tools. It is appropriate to move to transitional for the very reason suggested in it's name, we are transitioning from having presentation in the HTML to having it purely in the CSS. It also aids backwards compatibility which might be important in many educational settings..

The debate about sending XHTML to browsers is usually focussed on whether the content is delivered to the browser to be interpreted as XML or HTML, (HTML being the smart choice) and even the XHTML spec has an appendix on how to write HTML compatible XHTML so it's not really controversial.

However, the comment about Strict not allowing tables is a touch off-base, since tables (and other tags that can be misused) are still present in XHTML 1.0 strict.

Full differences are listed here, note it's mainly about removing purely presentation based markup: http://liorean.web-graphics.com/xhtml/comparison.loose-strict.html

This brings up the issue of the difference between valid and semantically correct (X)HTML. The validator program can't tell if you're using a table for tabular data or to correctly line up some text with an image, or if you're using blockquote just to indent some text.

That is one of the reasons why the Accessibility standards checkers require human interaction to ensure that you aren't misusing tags for anything other than their correct semantic meaning.

I have various links to expand on this stuff but I wanted to throw this out before the developers meeting.