Enhanced Elements should receive (suffixed) classes attached to original element.

[Wilto]

In any case where an enhanced element is created by wrapping the original element (selects, input buttons), there’s no way of attaching a custom class to the enhanced element. This leaves authors in a position where they can only target an element by wrapping it in another element or wandering all over the DOM with their selectors.

Classes on the original element should remain in place, but a suffixed version (“-enhanced”) should be applied to the enhanced element.

[kurteknikk]

Good idea, maybe one of the discussions should be the order of classes. Should the user defined enhanced classes be first or the jquery mobile classes first.
We can always use !important to force which rule is more important, but still maybe there's a logical reason about which classes should be first.

[gabrielschulhof]

This can be solved by properly implementing the widget() method on our widgets. The widget factory uses this method when handling the setting of the disabled option, for instance:

        if ( key === "disabled" ) {
            this.widget()
                .toggleClass( this.widgetFullName + "-disabled ui-state-disabled", !!value )
                .attr( "aria-disabled", value );

So, by implementing widget() methods for our widgets, we could give developers the div they need to style. We should do this in addition to adding the -enhanced class.

[arschmitz]

@gabrielschulhof that was my thinking exactly i'm going to move this to 1.4 as part of the widget review.

[jaspermdegroot]

We also have to look at the legend of the checkbox/radio and select controlgroups which is wrapped in a div. See #5351

[jaspermdegroot]

We made it possible to use a different icon color for buttons by just adding class ui-icon-alt to the element or a container (see e0ceaac). In case of <button> and <input type="button"> adding the class to the element won't work. In this case we will have to copy the class to the wrapper without prefix/suffix.

[jaspermdegroot]

Should we do the same with ID's?

[arschmitz]

yes ids should i think classes im less sure about i think class config
might be a better direction to go

On Wed, Feb 27, 2013 at 4:05 AM, Jasper de Groot
notifications@github.comwrote:

Should we do the same with ID's?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3577#issuecomment-14163505
.

[jaspermdegroot]

Do you mean option classes like we use for panel and table?
I think we will run into problems if you set a string with multiple classes (the default class for the wrapper and your custom class), because we have to be able to use it in selectors too.

[jaspermdegroot]

Discussed this with @arschmitz and @gabrielschulhof today and we are all in favor of introducing data-class and data-id. It will give the user full control over what classes and ID should be added to the wrapper and it's less expensive than copying classes and ID's and adding a suffix.

Have to see what to do with the "ui-btn-left" and "-right" classes.
Update: There are more classes that needs to be on the wrapper instead of the element (ui-shadow-icon, ui-icon-alt, ui-icon-nodisc). Mini and shadow are still an option at the moment, but we want to change that to "add the class" as well. So I think it's best to clearly document that you have to use data-class here and not adding code to port all those classes.

Should we use data-filter-class and data-filter-id for the search filter? #1835

[arschmitz]

this has been implemented in all reviewed widgets closing this as fixed by new data-wrapperClass option in widgets

[jaspermdegroot]

Note thate we decided to only implement this for classes, not IDs.