Yeah, that module reached Candidate Recommendation about two weeks ago as Tantek reported (someone get him WordPress and a nice valid Atom feed). A few properties are marked as features at risk and I think that resize might not make it into the finals, although a future (let's all make ideas for CSS4) specification might include it. For some other properties, like content:icon this is exactly the same, although this property would probably be covered by the CSS3 Generated and Replaced Content Module.
One of the problems I have with the specification is that it doesn't say a thing about FIELDSET and LEGEND, see scope, this makes "bugs" like legend{display:block} unsolvable and people will actually have to use HTML hacks to create what they want, but again, a future specification will probably solve this. (Note that CSS 2.1 doesn't define everything explicit as well, which makes things harder for implementers; note also that I'm not an implementer, but I do chat/mail with them.)
Further, the specification defines an appearance property, which can be used to style an input[type=text] element as an input[type=radio]. This may not seem that interesting, but having more and more specifications, a general way of styling them is a very good solution in my opinion. This will result in smaller browsers (although they first get bigger, so actually there isn't really a difference) and a more user friendly way to style things. (Note that Mozilla already supports this in some way as -moz-appearance.)
Before people start whining that Mozilla should support it without the -moz- prefix, there are reasons for that! If Mozilla supports something with a prefix, it means that Mozilla doesn't support the real property and that developers probably don't have time to implement it correctly, since there are more important things to do. If you still want to get it implemented you should create a patch yourself.
The specification also defines some additional properties, which seem to be nice, but I would like to see an implementation before giving feedback on them (I understand that is hard, since specifications are written for implementations, so maybe I don't make sense). I also really like the informative style sheet for XHTML (HTML) aware browsers.
I know why I started following your web-log now, I don't feel like keeping track of all candidate recommendations etc. myself and this way I stay informed! (this was no spam, since it's only one message)
This may not seem that interesting, but having more and more specifications, a general way of styling them is a very good solution in my opinion. This will result in smaller browsers (although they first get bigger, so actually there isn't really a difference) and a more user friendly way to style things.
Would you mind to clarify this a bit? I'm not sure if I see how this would be a good solution and for what problem exactly...
Problem is that there are multiple specifications which use forms and some browser could support. In terms of Mozilla, think about XUL and XHTML forms (maybe even XForms (as an extension)). With CSS you can style them both (all) using just appearance instead of writing code for every single markup language.
Another advantage of the appearance property is that it "hints" rather then describes the actual "appearance" of the widget. Since widgets are mostly OS dependent this is a good thing.
Ah yes, I see now, I was thinking too limited in terms of XHTML forms. I doubt I will use it myself anytime soon though (with which I don't mean that it'll take quite some time before it's implemented and actually usable).