views:

55

answers:

3

To use the W3C Validator your (i.e. beta-) website normally has to be online which I'd rather avoid. Or use the direct input method. Say hello to continuous copy & paste.

My Idea:

The "direct input methods" submits the input as a form (no surprise here). In other words: The actual validation-page receives a POST request.

So: Could I make a link (i.e. in my standard page footer) that leads to a local submitForValidation.php (rather than the regular linking to validator.w3.org)

Within that php file I shall...

  • grab the Referer-URL it just came from (yes, within PHP 'curling' the localhost server...)
  • submit that as the body of a POST request to the W3C page: http://validator.w3.org/check

Is that feasible? Someone has done this solution?

Frank

+1  A: 

I still don't clearly understand what you're trying to do. If you want to do a direct input validation by manipulating POST data, you could install w3c markup validator on localhost and then modify it as you want. refer to installation documentation here.

bangbambang
Fronker
A: 

If you want to validate an XHTML or HTML page you can use

If you want to make sure it is valid, you can also run it through the ob_tidyhandler but note that this will incur some performance penalties due to the buffer being inspected and repaired on every serving.

Gordon
Fronker
Gordon
the former I will consider, the latter I cannot do: example.com in my case is "localhost", so this is doomed.
Fronker
@Fronker well, as long as you have an internet connection you will have an IP of some sort. That's just a matter of setting up your host (and probably firewall or router accordingly). But I understand if you dont want do to that. Just saying that it's not impossible.
Gordon
A: 

If what the Web Developer Toolbar has to offer (It essentially does the same thing you are planning to do) won't work for you, what you suggest yourself sounds like the best solution to me. Use CURL to POST the contents of the current, generated PHP file to W3C's service.

You could even make use of output buffering to grab the current page's contents, run them through the validator, and if any errors occur, paste the information into a placeholder in the generated HTML. (All this in "debug mode" or if a cookie is set or a GET parameter present, or something like that.)

The tough job will be to parse the results page, though. I think a local validation package returning messages in a array or XML structure would be easier to deal with. However, DOMDocument's Validate has the downside that it doesn't give any details about problems, so it would have to be something else.

Pekka
@Gordon I stand corrected - I thought validation was a pure true/false thing here. The info is still not as fancy as the validator's output but it's there. Re the second part, the OP is referring to non-public beta sites
Pekka