General developer forum

Suggestions for the guidelines (some of the things I say may be already stated in the XHTML specs; I don't know if they are should-do or must-do, I just do ):

• Never use <b> and <i>, use <strong> and <em> instead
• Include at least a <tbody> tag in each table
• If you 're going to be putting header columns in tables, also use a <thead> tag
• Always use alt="" in <img /> tags
• Don't forget to properly slash-terminate tags like <br />, <hr />, <input ... />
• Always put attributes in quotes (id="someid", not id=someid)

Jon

How about removing all the font tags? They are quite "in the way" when building custom themes. At least I don't know a way to override them from CSS.

I can volunteer to do some of this kind of clean up, but as removing the font tags changes the look of the sites, should some, if all, of those tags be replaced with css styles/classes? If so, then maybe there should be some discussion of what and where?

It would be good to try to follow the guidelines for HTML compatible XHTML given here:

http://www.w3.org/TR/2000/REC-xhtml1-20000126/#guidelines

I think they are given roughly in order of importance, though C.12 (unencoded ampersands) always seems to trip people up.

Martin, you suggest: "Please work on one file at a time to minimise conflicts". That appears to be a very inefficient way of getting rid of the glaring problems like upper case tag names which occur in almost 2300 files! Working on 2300 files individually is going to take ages!

Wow. That's painful.

I think I beat 'course/category.php' (and all asociated lib functions) to death. The only elements that weren't coming up compliant were user entered elements (course summaries, etc.).

mike

A related task that could be usefully carried out at the same time is to set all the colors in config.php to 'green'. All the areas that aren't overridden in the CSS file will show through as deep forest green and can easily be spotted.

I've done this before and many of the green areas can be easily fixed by specifying the color in the CSS with the appropriate class selector, as CSS will trump the HTML written out based on the config file. However, there are some areas that don't have a suitable id or class, and one would need to be added to allow CSS to target them. If these were fixed then it would be possible to entirely switch themes via CSS and use config.php only to support older browsers.

This will A) allow for making the themes better and more accessible and B) also allow user selectable themes.

I've just put an xhtml version of the dialogue module in CVS. Well, actually my first stab at it . I'm using the (wonderful) Web Developer Toolbar in Firefox. The option I'm using is Validation|Validate Local HTML. (I'm running a development system on localhost using the xhtml theme.) This works well and comes back really quickly.

(I started with Dialogue as it's small and written fairly recently when xhtml was in the wind.)

However, I'm just getting loads of moans from the standard moodle calls which makes spotting the moans about my code kinda hard. I'm not moaning but perhaps suggesting which bits of code need to be xhtml'ed first .

Hi All,

Am I right in assuming that the following:
<FORM TYPE=""....>
is incorrect XHTML, and in fact XHTML is all in lower case?