Do you think there are major pitfalls I’m going to walk into with this?

Depends. Here’s what I’ve found, and what I’ve learned from developers with way more experience than I have:

1. If your implementation details are complicated enough to need comments, then they may need to be better abstracted.
2. If the implementation details change (which is the norm) then the comments usually don’t, which leads to comments that lie.

Better to over-comment than under-comment, especially when you’re dealing with the often-hostile world of web development. But comments should always be more-or-less unchanging, and reflect the “why” rather than the “what.” Of course, a valid “why” might be something like Need to set zoom:1 here to make IE 6 stop being an idiot; while technically that’s an implementation choice, it’s also a description of the landscape and the reasoning behind the choice, which is unlikely to change any time soon.

If there’s a particularly tricky implementation, and no way to abstract it out, which is common, since CSS has a seriously flawed abstraction model, then you’re kind of screwed. You can reduce the impact by writing a blog post about the issue and include the URL in the comments. (This also adds to community knowledge, which is good for everyone in the long run.)

Like I said, I write a lot of implementation details in my comments while I’m writing code, to the point of writing mostly-complete pseudocode for each method as I’m stubbing them out. But that stuff turns into clutter as soon as the method is working, and it’s a lot easier to manage when the scaffolding is removed.