I was wondering why the data-abide-error has inline style display: none;? Inline styles are bad so maybe using the class .hide could be used instead?
i.e. http://foundation.zurb.com/sites/docs/abide.html#initial-state
[data-abide-error] must currently have an inline style declared because it is by this way the error is shown or hidden in the Js (see js/foundation.abide.js:331).
However, I totally agree with you that it is not a good practice at all, and we should use visibility helpers instead.
@kball I see we are always using .hide() for other component (which is the JQuery way to define display: none;). Do you think we should move to visibility classes (.hide) ? Dedicated classes inside each component (.abide-*) ? States (.is-hidden) ?
I agree that generally, inline styles must to avoided. But in this case, do we expect the [data-abide-error] invisibility to be overriden ? And more generally, is there a case when an element hidden in JS should be shown ?
I am not saying there is no case where a lower specificity would be useful/expected. But for now I do not find obvious ones.
My inclination would be to move towards a either visibility classes or state classes. Everywhere possible display/visibility/etc should be done by manipulating classes, not direct css via js.
So we would not use visibility/state class to have a lower specificity, but to make easier the control of the visibility/state of the component ?
Yeah, and for general consistency. visibility classes tend to use !important; so they're high specificity anyway.
After thinking about it a while, I would tend to use States, because it is for what it is made for. A semantical state, often controlled by JavaScript, that we do not expect to be overriden (states have a specificity of 0.2.0 in BEM).
Avoiding inline styles would be a requirement to make it work with a CSP without "unsafe-inline"
@ncoden is this something that could be done for 6.5?
Yes ;)
I'm moving this to v7 as it not only affects abide but other components as well (dropdown, reveal, etc.)
Most helpful comment
After thinking about it a while, I would tend to use States, because it is for what it is made for. A semantical state, often controlled by JavaScript, that we do not expect to be overriden (states have a specificity of 0.2.0 in BEM).