Read Zeldman's "Designing w/ Web Standards, 3rd Edition". That book will give you direction and save you a lot of time.
The problem with HTML is that it is a pretty loose language and you can do a lot with it without getting your syntax right. On top of that you have a lot of confusion because of HTML 4.01, HTML5 and XHTML 1.0.
Because of all that you will find tons of HTML resources all over the web that may appear decent, but actually teach you bad habits and old hacks that are no longer best practice. Zeldman's book will give you some direction so you don't waste too much time and develop good habits from the beginning. If it's not the first book you read, it should at least be the second book you read.
I haven't read them yet, but Zeldman recommends the following JS books:
For CSS, the best resources are Eric Meyer's "CSS: The Definitive Guide" and "CSS: Pocket Reference"
The current edition of The Definitive Guide is a 2006 edition. I asked Eric about a new edition and although there isn't a date set, he expects a new edition covering CSS3 sometime in 2011.
You'll enjoy it. It may be over 400 pages long but it's a really quick read. You should be able to read it all in 1-3 days.
Zeldman makes tons of link references throughout to a bunch of excellent resources, oftentimes the original sources explaining a new idea in web design. Make sure to check those links out, they add a lot of value and context, especially the A List Apart references.
The last chapter in the book ties everything together and walks you through building the Agenda from NY Mag in HTML and CSS first and then using JQuery to add behavior:
There's no better ones, it's a matter of preference, I personally currently use JQuery but for some projects I used Mootools (great piece of code) and Prototype/scriptaculous. I heard a lot of goods for YUI also.
The MDC guides are much, much better. And Crockford's book is best.
There are also fantastic explanations of the Event model at PPK's Quirksmode site. Start here and read through all of his Event articles:
It's true that it can be simpler to directly begin with a framework. I actually began with Prototype.
If you want to build plugins for your Framework of choice (JQuery in your case), then it is also a good idea to understand what is happening behind the scenes.
There are many situations where using a Framework is not really suited. Do you really need to embed your framework of choice (JQuery in your case) if the only thing you need is show or hide a single element of your page ?
I think "begin with a framework or not ?" is a long debate (whatever the language is).
I don't have a good answer to this but in the long run knowing the language you use is recommended.
The Mozilla HTML reference is very good: https://developer.mozilla.org/en/HTML/Element and between it and just viewing the source on decent websites you can learn a lot - coming from Java, you must know XML pretty well already :)
As for CSS, I've always just used the W3's reference: http://www.w3.org/TR/CSS21/ which is a little dense but followable. (The W3 for HTML isn't bad either, but they will use the schema definitions for everything, which are slightly opaque.)
Finally, http://www.alistapart.com/ is a great reference for the pragmatic state of web design. Lots of great articles, especially going back a bit.
I'd suggest approaching this from a slightly different perspective.
Find a simple problem - say and ajax driven to do list for instance - and mock up a simple HTML front end preferably from scratch, hand-coding the HTML. Reference sites abound but I keep finding myself at w3schools.com which was previously mentioned. As you solve individual UX problems you'll quickly get the hang of how HTML does its thing. Pay attention to standards and validate you code using the W3 validator. A good HTML editor like Dreamweaver (free trial available from Adobe) will do you wonders.
Then on the server end a web dev framework (Django if you love Python...) will get you done. Again, try solving the problem without the framework and then phase it in.
A couple of weekends later you can add "Web Developer" to you resume : )
HTML will you understand relatively easily as well. You might need to pick up some CSS layout techniques which I sometimes finds a bit baffling from time to time.
CSS is actually the tweakiest part of the frontend triumvirate. The syntax isn't hard (selector + bag of key/value pairs) but putting it together so it reliably renders on all browsers takes weeks/months.
I'd recommend doing sass/compass instead which both provides an abstraction layer and a library of working code. If you're starting from nothing, the SASS syntax will probably be easier to work with than the default SCSS syntax. You can dig into the libraries if you really care about how things work, but it's always easier to start from something that works than to try to figure out stuff from scratch.
These are easily the two most important pages of the spec. If you understand these, you'll be able to take away 90% of the mystery and guesswork that can go into laying out a page. Nearly every time I've seen a developer struggling with CSS issues, it's turned out that they've had an imperfect understanding of the basic concepts that are spelled out here.
And for a technical spec, these pages are amazingly readable and understandable.
There are actually a number of server side JS runtimes, but node.js (or nodejs or NodeJS, the naming is semi-inconsistent) has the most buzz/momentum.
I'm confident that you'll see a number of frameworks/libraries that can take advantage of JS running both client and server sdie in time for JSConf in April. The most public has been Yahoo's YUI team, with Dav Glass putting the effort into getting yui3 running in node.
He also provides examples of various yahoo widgets getting rendered as static html, which I think is also in that github repo, but I can't find his demo online.
I'm also working on putting a bunch of pieces together that would allow an app to be client/server agnostic but I've been "working on it" for months now in the background and I'm not finished so I'll just wait until I'm done to talk about it.
Given that the author is interested in HTML as well, I imagine that he probably is more interested in JS resources that focus on the DOM and not on using JS as a general purpose programming language. However, I may be wrong about this.
Given the state of things today, I would definite focus on web standards and semantic HTML. The reason being that any front end HTML you write today is likely to be used both on the desktop and via mobile devices.
Writing good clean semantic HTML will help ensure that you need only write one HTML document that is then styled by one CSS document for the desktop and one for mobile devices. Plus writing semantic HTML will give you basic SEO for free.
As a more concrete example, I'm using python as the backe end to my current side project. So in the centre of the page is a bubble for python. Off that I have different things I want to explore, so there is a bubble for Security, WSGI, templating engines, and SQLAlchemy. Off of security, there are bubbles for server hardening, XSS, etc..
Best of luck, there's lots of confussing technologies and non-sensical gotchas, but eventually it does start to make sense.
I've had serious reservations about content from w3schools, to the point where I now skip them entirely when they come up in a Google search. They seem like a collection of all the bathroom-wall code ever: MySQL or SQLServer specific code presented as "SQL", things that only work in one browser or another presented as the best way to do things, etc. I usually know enough to know that their approaches are misleading, and I shudder to think how many devs take them at face value.