Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
CSS Markup Detective (red-root.com)
65 points by franze on April 27, 2011 | hide | past | favorite | 14 comments


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:

.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.


Good tip. I went back and took a look at while my previously validated page was failing so badly.

It turns out this test suite is really poorly designed! For example, it can't identify implicitly associated labels, so the whole concept behind this tool is quite flawed.


Yeah there is only so much that you can do solely with css but I prefer explicit labels anyway.


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.


Neat idea, but it lacked feedback for the user.

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


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.

[1]: https://github.com/redroot/holmes


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.


Looks very cool. There are a few typos littered throughout the page that the author should fix:

accessility -> accessibility maet -> met


Could this be made into a bookmarklet? I could see using this to diagnose issues on 3rd party sites where source access isn't available.


There is a bookmarklet in the yellow download box on the page.


Wow: Chrome supports marquee tags




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: