Item2530: wiki pages have errors; don't validate

Problem

Wiki pages have many errors and don't validate. I've tried to clean up my wiki, but virtually all the errors come from the base code. Although the details vary, I've seen this on all versions of *wiki. This needs to be cleaned up - we need to generate clean pages!

foswiki.org

A couple of examples using foswiki.org:

Using firefox, display the error console. open http://foswiki.org. Loading the page yields a bunch of errors:

Warning: Expected declaration but found '*'.  Skipped to next declaration.
Source File: http://yui.yahooapis.com/2.7.0/build/reset-fonts-grids/reset-fonts-grids.css
Line: 7
...repeated many, many times.

Warning: Unknown property 'zoom'.  Declaration dropped.
Source File: http://yui.yahooapis.com/2.7.0/build/reset-fonts-grids/reset-fonts-grids.css
Line: 7

Warning: Unexpected end of file while searching for ';' or '}' to end declaration.  Unexpected end of file while searching for closing } of declaration block.
Source File: http://foswiki.org/
Line: 142

JS Error clicking document whitespace

Click anywere on the screen that isn't a hotspot (e.g. not a link, button, etc).

Get one error for each click:
Warning: Empty string passed to getElementById().

I see this on all my wiki pages as well.

Try the w3c validator: Click on this link: http://validator.w3.org/check?verbose=1&uri=http%3a%2f%2ffoswiki.org%2f

The page has 33 reported errors.

I'm currently typing this using IE 8 with the developer tools window. The console reports one "Object expected line 149 character 1" error for each keystroke.

I'm sure that there are many reasons for this. But it would be good to have a plan to get it under control - and regression tests to keep it that way. I suspect this is rather a large effort...but it should pay back in better browser compatibility and fewer mysterious odd behaviors.

-- TimotheLitt - 28 Dec 2009

I agree, absolutely. Last I looked in to the problems with those warnings on every keypress in the editor, it was a foswiki.org specific thing - the skin adds an onkeydown="" event attribute to the textarea, but for some reason the corresponding handler is in a js file that isn't loaded. Its purpose was to intercept the escape key and ask "do you really want to leave this page, you should save first".

It would be nice if we had a link crawler that built a validation report against each link generated by interesting skins (Eg. pattern).

It would also be nice if we had perlcritic and jslint reports that were autogenerated and easily accessible from each plugin's ThePlugin topic.

Apart from anything else, SafeWikiPlugin uses a cpan lib for parsing the XHTML that dies in horrible ways on some of these validation issues.

-- PaulHarvey - 28 Dec 2009

Part of the issue is that Yahoo Grids code, used on the homepage, does not validate. This lies outside of our influence.

-- ArthurClemens - 28 Dec 2009

We need to identify the templates that have errors. Generally the PatternSkin validates quite well for view, but the oops/edit/etc. templates do not.

I also try to help NatSkin validate too, although there are some benign errors that are more effort than it's worth for me.

PatternSkin edit template

• Apparently h3 cannot be contained in its span
  • That must be the twisty link label. -- ArthurClemens - 28 Dec 2009
• Inline style elements missing type attribute
• Same id used more than once for a couple of divs

-- PaulHarvey - 28 Dec 2009

Glad to see the interest. Most pages also have <p /> -- self-closing paragraphs aren't legal. This isn't from templates, it's from the core.

If Yahoo! grids isn't validating, the person who added it to our website should file a bug report with Yahoo!. We have that much influence Really. Our website is what our prospective users see first; it should be representative of the best that our technology can deliver. If I were shopping for a new web tool for commercial use & the tool's site didn't validate (including for accessibility), I'd mark it down severely. After all the reasoning goes, if the tool developer can't make it validate, a new user sees work.

The problem with "benign" errors is that there are something like 10,000 browers (and screen readers) out there (and even the dozen major ones) that have different ideas of what "benign" is. They also clutter the error and validation reports, making it harder to distinguish Foswiki errors from those introduced by users. And enterprise users tend to have standards like "zero errors". So while it's probably necessary to prioritize, our end goal should be zero errors from what we distribute, and zero errors from our public website.

-- TimotheLitt - 28 Dec 2009

On Yahoo Grids, it is full of conditional code for Firefox 2 and IE versions. But instead of fixing the released version, Yahoo devs have been focusing on YUI 3. Now Grids have been moved out of YUI 3: http://tech.groups.yahoo.com/group/yui3/message/726

The 'fixer' of Bug ticket "Syntax error - validation does fail" has this recommendation: Users who value validation over single-file ease of maintenance for central resources may shield other browsers from those rules by removing them from the main file and serving them to IE6/7 only via a conditional comment or other means.

If we want to have it fixed, we are kindly urged to do it ourselves. Which may not harm because it will not be updated.

-- ArthurClemens - 28 Dec 2009

Started Item2535, which should help our skin developers and somewhat automate the discovery of validation problems.

-- PaulHarvey - 29 Dec 2009

A huge amount has been done since this report to improve validation. We have reached the stage where a validation test infrastructure is in place. Validation errors now need to be reported individually and in sufficient detail to make reproducing them possible. So I'm marking this closed.

-- CrawfordCurrie - 29 Jun 2010