This seemed like a cool idea at first glance, but it's actually quite useless.
I ran it on one of my projects, which I've already tested for standards and accessibility compliance, and it highlighted everything on the page. There's no messages explaining what is failing and where. A traditional validator would be more helpful here.
I think it would be a huge improvement to implement tooltips when mousing over an outline that brings up a note saying WHY something was flagged. Otherwise, I think it's an interesting idea.
If you are a web designer you can just inspect each element in firebug. It will give you a list of the currently applied styles to that element and the top one is something of the form:
It would be nice if the documentation described or at least linked to explanations of why all the things it highlights are bad. It's relatively obvious why deprecated elements are bad, but what's wrong with links to "#" or links without a title? If you have time, don't just reply to my comment with the answer; Fork and Edit the docs on GitHub (https://github.com/redroot/holmes/blob/master/README.markdow...) so everyone can learn.
The Browser Support section wonders if Holmes.css works on IE9. I tried the bookmarklet on this very Hacker News page, and the only colored borders I see are grey, whereas in Firefox 4 I see all three colors of border - so, it seems IE9 only partially supports Holmes.css.
I have forked the project and added a pop-over description of the error when the user mouses-over the 'diagnosed' element (not supported on all elements)
Great idea. Even better that it's on GitHub (1). That way it can improve quickly and have community discussions on some of the more subjective markup guidelines.
I think this can be especially helpful on local dev servers (turned on when a DEBUG flag is set, for example) while building a fresh site.
This looks awesome and very useful. How do you envision the use case for Holmes to be? Would I always include it in my site, and just switch on the 'holmes-debug' class when testing? Or would I only include the .css file during development?
I would think conditionally linking to it, that's what immediately came to mind while reading this. Within your HTML template and preferably using a built-in variable that indicates you're running in DEBUG or DEV mode.
[+] [-] akamaka|15 years ago|reply
I ran it on one of my projects, which I've already tested for standards and accessibility compliance, and it highlighted everything on the page. There's no messages explaining what is failing and where. A traditional validator would be more helpful here.
[+] [-] bcrescimanno|15 years ago|reply
[+] [-] weaksauce|15 years ago|reply
.holmes-debug div:empty, .holmes-debug span:empty, .holmes-debug li:empty, .holmes-debug p:empty, .holmes-debug td:empty, .holmes-debug th:empty
If you are on a div and it's empty then that's why, etc....
It would be a lot easier if there was a popup explaining but as a first pass it's pretty useful and not all that hard to get at the info you want.
[+] [-] roryokane|15 years ago|reply
The Browser Support section wonders if Holmes.css works on IE9. I tried the bookmarklet on this very Hacker News page, and the only colored borders I see are grey, whereas in Firefox 4 I see all three colors of border - so, it seems IE9 only partially supports Holmes.css.
[+] [-] MrNibbles|15 years ago|reply
I have forked the project and added a pop-over description of the error when the user mouses-over the 'diagnosed' element (not supported on all elements)
- https://github.com/MrNibbles/holmes
[+] [-] joeyespo|15 years ago|reply
I think this can be especially helpful on local dev servers (turned on when a DEBUG flag is set, for example) while building a fresh site.
[1]: https://github.com/redroot/holmes
[+] [-] JakeSc|15 years ago|reply
[+] [-] joeyespo|15 years ago|reply
[+] [-] ndunn2|15 years ago|reply
accessility -> accessibility maet -> met
[+] [-] ggoodale|15 years ago|reply
[+] [-] sv123|15 years ago|reply
[+] [-] david_a_r_kemp|15 years ago|reply