This change can’t happen until version 2.0, because it will break everything
But I’d like to point out that, in CHtml, the ID attribute is calculated incorrectly - if I emit an input for the $name attribute of a Contact model, e.g. CHtml::activeTextField($contact,‘name’), this results in markup like <input id=“Contact_name”>, which is wrong.
Why? Because if you have more than one contact form on a page, you will have multiple inputs with the same ID - this not only means your document will not pass DOM validation, but your JavaScript will fail as well, if you’re trying to attach a behavior to the element with that ID.
"Contact" is a class, and the attribute "name" is part of class declaration - the combined name "Contact_name" therefore refers to a class-attribute, and per definition is not an ID.
Imagine the disaster if widgets worked the same way.
The class-attribute name should be correctly applied as class="Contact_name".
Yeah, this is a known limit of CHtml. A (ugly) workaround is to extend the model class so that it has a different name, if the same page contains two or more forms about the same model.
In fact, anything related with IDs are very hard to find a perfect solution. If you use fragment caching to cache part of the output, you will find that the IDs are no longer the same as the version without caching.
I second the class name approach. I already use classes to store all kind of information with an element. E.g. mark elements that should have a "behavoir" attached, like "button-open-login", so you can attach event handlers to multiple elements very easy. So using classnames to identify form elements would fit very well into that concept.
A good naming scheme is crucial, though, to avoid clashes with layout related (CSS) class names.
