HTML Validator extension for Safari
A couple of days ago, Apple announced support for developing extensions, so I felt obliged to implement my HTML Validator extension for Safari too. 🙂
The HTML validator extension for Safari
The extension basically offers three options:
- Validate URL
- Takes the URL of the current tab and opens a new tab with the W3C validator and its validation results for it.
- Validate local
- Takes the generated HTML of the current web page (especially good for local content) and posts it to the W3C validator. Note: Currently opens the W3C validator in the same tab, since the extension model doesn’t support posting forms/content to new tabs.
- If you enable Autorun (on by default) it automatically validates the URL of the current page and displays number of validation errors in the HTML Validator bar.
You can enable extensions and adjust their settings in the extensions view:
Bear in mind that this is a first version and can be a little rough around the edges. However, if you want to try it out, download HTML Validator for Safari from GitHub. Note: it only works in Safari 5.
The Safari extension model
So, it’s interesting to see Safari bet on extensions as well, to be able to compete with other web browser. I’m glad they did, but being Apple, of course they have to do it their way.
You build/create extensions with the Extension Builder, which I hated at first (since I want a master file I can edit, not a form to fill out), but over time, it is actually quite easy to use instead of over-typing in a pkist file.
Another web browser, another extension model. It is quite similar to the one find in Chrome, but still different. If all web browsers are to start supporting extensions, as developers we must get the same means of developing them. It’s not ok with a different approach for each web browser. And, since Safari are the last ones out (well, ok, not Opera yet), they really should have matched an already existing extension model, for instance, the one found in Google Chrome.
Also, in the Apple spirit, you need to sign up for the Safari Developer program (free) just to be able to develop an extension, and also create certificates with which you sign your extension. Basically, just a lot of hassle. Sure signing is necessary, but there are other ways (see below).
What you can do in the web browser is pretty limited and some obvious features seem to be missing so far (for instance, an event when a tab gains focus).
Also, I can’t believe they start offering extensions without a proper extension web site where people can easily share them. I know such a web site is in the works, and when it’s released it will be much nicer. Also, there you can have automatic extension signing so developers don’t have to care?
And, please, skip the Apple Developer Program bit…
Autorun is on by default? That seems wrong to me for all the obvious reasons (performance, privacy etc.).
Anyway, good job 🙂
If there was an ongoing standardization effort for browser extensions, maybe some people involved may have been asked not to announce anything yet. Maybe. Even so Apple may not have bought in yet. Donno.
Regarding the extension website: rumor has it that they're working on one. And you will notice that, as an end user, enabling extensions is not easy. My guess is that they consider the whole extension system to be beta, and want it to be in the wild for developer feedback, fixing bugs and security issues, etc. They don't need an extension website until the support is final, and enabled by default (or at least enabled in one click in the main preferences).
I don't know if this is 100 per cent on purpose or if they were too short on time to have a fully-fledged and completely tested extension system for WWDC 2010. The result is the same anyway: it's beta, aimed at developers and advanced users only, and will probably graduate in a future release.
Well, I though aout what was easiest for users, and that it's not that easy to find the preferences section. 🙂
Yeah, maybe – one can only hope. Not sure why it would be a big secret, though.
Excellent comment, and something I pondered myself. And that's fine, I guess, but I still wish they really didn't require being part of the Safari Developer program.
[…] HTML Validator – Zeigt eine Infoleiste mit der Anzahl der Fehler an. […]
Could you implement a way for us to use our own validator URL please? W3C allow you to install a local version of the validator. Currently, the W3C version appears to block you for several hours if you use it too much; a locally installed one doesn't do that. It's also good if you're developing sites which can't be made public for whatever reason.
Cheers, and great work!
Offering an option to specify a URL of your own wouldn't be hard, but then (especially if you use another validator than W3C:s), it needs to return those values.
I have no plan to implement it just right now, but it's a good idea for the future.
Sorry Robert, that wasn't quite what I was meaning. The W3C website makes it possible to have an exact local version of their validator. You can download everything you need from their website. It gives the exact same output, the only thing which is different is the URL used to access it.
I've expanded your extension, changed every instance of the validator url up to the '/check' and packaged it up again. It works just the same…including the bugs 😉
Talking of which, when clicking the 'validate local' button, something weird is going on with tags which are closed the old way. In pages which include something like <meta content="text/html; charset=utf-8" http-equiv="content-type"></meta> , the closing meta tag gets left off and understandably causes the validator to get very upset. The auto-validate doesn't have this issue, and clicking 'Validate URL' also tells me the page is valid – which is correct – it's just the 'validate local' button which has the problem.
Right, but then in that case it would be nice with an option to choose between the W3C validator on the web, or point to a local URL.
Validate local is validate generated, meaning that it takes the actual generated HTML of the web page the way the web browser has rendered it. That means that Safari omits those closing tags then. So, it's not a bug, it's a feature. 🙂
Personally, I wouldn't refrain from such usage of closing elements, it would be the same as having closing img elements or something. Either quick-close it or don't close it at all. 🙂
[…] automatisch überprüft; das Ergebnis prominent aber nicht störend in der Toolbar angezeigt. Website des Entwickler var flattr_wp_ver = '0.9.11'; var flattr_uid = '16311'; var flattr_url = […]
[…] HTML Validator: http://robertnyman.com/2010/06/09/html-validator-extension-for-safari/ […]
[…] ????????? ??? Safari HTML5-????????? ??? Safari 5 […]
[…] HTML Validator | Safari PageRank […]
[…] HTML Validator | Safari PageRank […]
I love the goal of this, but sorry to say it’s not working for me.
I want to validate a page that’s local, not accessible to the outside world. I click on “Validated local” and I get a page (url=http://validator.w3.org/check) that says:
Can’t use an undefined value as an ARRAY reference at /usr/local/validator/httpd/cgi-bin/check line 564.
For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error.
Also, “Validate URL” creates a new tab, which is good, but “Validate local” replaces the current page, not good.
This was more of an experiment before Apple released it more officially, and I believe support has changed. Please look around in Safari Extensions Gallery for a better option.