[Feature request] Custom theming

[eddow]

I would have wished to implement the Semantic UI theme and therefore add semantic classes to the buttons and inputs. I was planning to implement it in a project as a "custom theme" but couldn't as alertify classes are defined negatively ( :not())

I give here an exemple about semantic but, indeed, it could be done "in general" I think.

Note: the first point is of course think it without having to attack alertify._$$alertify

Expected behavior

The button.mytheme-button css-class should be used as the generated button's class

Actual behavior

.alertify .dialog nav button:not(.btn):not(.pure-button):not(.md-button):not(.mdl-button) class is too strong and are used instead of my custom classes - also, all the themings are copy/pasted in each single class of buttons, inputs, etc. as negative classes.

Proposition

Possibility 1: Define classes positively

If the default dialog items (buttons, inputs, etc.) have a specific "default" class, this would be overridden as soon as the template is overridden.

In the template:

this.defaultDialogs = {
    buttons: {
        holder: "<nav class="alertify">{{buttons}}</nav>",
        ok: "<button class='alertify ok' tabindex='1'>{{ok}}</button>",
        cancel: "<button class='alertify cancel' tabindex='2'>{{cancel}}</button>",
    },
    input: "<input class="alertify" type='text'>",
    message: "<p class='alertify msg'>{{message}}</p>",
    log: "<div class='alertify {{class}}'>{{message}}</div>",
};

One exemple in alertify.css:

.alertify .dialog nav button:not(.btn):not(.pure-button):not(.md-button):not(.mdl-button), .alertify .alert nav button:not(.btn):not(.pure-button):not(.md-button):not(.mdl-button) {
  ...
}

becomes

button.alertify {
  ...
}

Possibility 2: Add a custom negative class

One exemple in alertify.css:

.alertify .dialog nav button:not(.btn):not(.pure-button):not(.md-button):not(.mdl-button)

becomes

.alertify .dialog nav button:not(.btn):not(.pure-button):not(.md-button):not(.mdl-button):not(.custom)

This would already allow the programmer to use <button class="mytheme-button custom" ... to avoid alertify default classes

[ChunkRadius]

Agreed! Is it correct to think that for backwards compatibility that the second option would be better? The first option seems cleaner and perhaps more ideal, but we don't want to break anything unexpectedly.

Would you be in a position to submit a PR? It's unlikely that I can get to it in the near future. I'll merge as soon as it's ready.