You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed on Slack, see https://wordpress.slack.com/archives/C02RQBWTW/p1491840082372116 we should try to establish good CSS naming conventions. Also worth considering the CSS classes used for the fields can be re-used in other contexts, for example in the future Fields API and in any other part of the admin.
keep selectors specificity as low as possible, avoid overqualified selectors
Helen Hou-Sandí suggested selectors should also provide a context:
"In an ideal world, you would have some baseline stuff for elements themselves, and then you scope upward to apply specific stuff based on context as needed".
"The goal should be for people (devs) to not have to do anything involving class names or CSS the vast majority of the time."
Helen Hou-Sandí will try to start a doc to dump thoughts on the best option we have for CSS naming
CSS classes to target stuff in JS: they should be separate from classes used for styling
CSS classes for state naming for JS (e.g. .is-active or .is-dismissible)
The text was updated successfully, but these errors were encountered:
As discussed on Slack, see https://wordpress.slack.com/archives/C02RQBWTW/p1491840082372116 we should try to establish good CSS naming conventions. Also worth considering the CSS classes used for the fields can be re-used in other contexts, for example in the future Fields API and in any other part of the admin.
Some points emerged during the discussion:
.is-active
or.is-dismissible
)The text was updated successfully, but these errors were encountered: