Open eddow opened 7 years ago
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.
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 classActual 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:
One exemple in
alertify.css
:becomes
Possibility 2: Add a
custom
negative classOne exemple in
alertify.css
:becomes
This would already allow the programmer to use
<button class="mytheme-button custom" ...
to avoid alertify default classes