Tech Debt: Clean up CSS #344

Open
opened 2019-02-11 15:59:33 +00:00 by shpuld · 5 comments
Owner

Currently our CSS is a bit all over the place, bad practices are used and some things have so many nested styles refactoring or modifying it is very hard.

My thoughts on some things that could/should be improved:

  • Clean up bad practices, like using flex over float
  • Simplify complex nesting of styles
  • Avoid inheriting too many styles from other components (Keep common sense with you: using generic styles like .panel, .panel-heading from app.scss is completely fine, but user-card-content being affected by what happens in user-card is not so fine)
  • More clear class naming (status.vue has some very bad examples of this)

OTHER DEVELOPERS: please comment your thoughts on what sort of CSS you think would be optimal for this project and why. Keeping factors in mind such as needing to support the theming engine, readability/maintainability, ease of working.

Any work for this issue should be done in reasonably sized chunks when possible, having merge requests that span the entire application is not preferable. It's also very important to keep an eye on regressions.

Currently our CSS is a bit all over the place, bad practices are used and some things have so many nested styles refactoring or modifying it is very hard. My thoughts on some things that could/should be improved: - Clean up bad practices, like using flex over float - Simplify complex nesting of styles - Avoid inheriting too many styles from other components (Keep common sense with you: using generic styles like .panel, .panel-heading from app.scss is completely fine, but user-card-content being affected by what happens in user-card is not so fine) - More clear class naming (status.vue has some very bad examples of this) OTHER DEVELOPERS: please comment your thoughts on what sort of CSS you think would be optimal for this project and why. Keeping factors in mind such as needing to support the theming engine, readability/maintainability, ease of working. Any work for this issue should be done in reasonably sized chunks when possible, having merge requests that span the entire application is not preferable. It's also very important to keep an eye on regressions.
Member

I am on it now. Will create MRs one by one.

I am on it now. Will create MRs one by one.
Owner

I want to enforce certain rules for CSS, not sure if linters for it exist or not, could be too subjective to check universally.

  1. No global styles unless it's an global HTML component styling, i.e. buttons, input fields, style normalization, in which case it should go into App.scsss
  2. Every component should have a "root" scope matching component name in certain case.
    For example style_switcher.scss must be like:
.style-switcher {
  ...
}

No rules must be defined outside "root" scope.

  1. Every element of bigger component should be referred by its class name, i.e. instead of doing
.dialog {
  button {
    ...
  }
}

it should be more like

.dialog {
  .okButton, .cancelButton {
    ...
  }
}

this is however subjective and exceptions could be made

  1. Modifiers (i.e. active, disabled, highlighted) should be defined as join-classnames, i.e.:
.dialog {
  .okButton {
    &.disabled {
      opacity: .5
    }
  }
}

the reasoning is that if we follow rule №1 we won't have problems when some stray .hidden affecting unintended element, so we can just use simple class names instead of obnoxiously long BEM notation in JS. BEM notation usually solved with JS libraries for that purposes, which isn't pretty.

@shpuld what do you think

I want to enforce certain rules for CSS, not sure if linters for it exist or not, could be too subjective to check universally. 1. No global styles unless it's an global HTML component styling, i.e. buttons, input fields, style normalization, in which case it should go into App.scsss 2. Every component should have a "root" scope matching component name in certain case. For example `style_switcher.scss` must be like: ```scss .style-switcher { ... } ``` No rules must be defined outside "root" scope. 3. Every element of bigger component should be referred by its class name, i.e. instead of doing ```scss .dialog { button { ... } } ``` it should be more like ```scss .dialog { .okButton, .cancelButton { ... } } ``` this is however subjective and exceptions could be made 4. Modifiers (i.e. active, disabled, highlighted) should be defined as join-classnames, i.e.: ```scss .dialog { .okButton { &.disabled { opacity: .5 } } } ``` the reasoning is that if we follow rule №1 we won't have problems when some stray `.hidden` affecting unintended element, so we can just use simple class names instead of obnoxiously long BEM notation in JS. BEM notation usually solved with JS libraries for that purposes, which isn't pretty. @shpuld what do you think
Author
Owner
  1. I assume this includes .panel, .panel-heading and such?

  2. should be enough to stop accidentally spreading styles to other components, good. No component should borrow styles from another component ever. (although in sub-components this might still happen with parent components)

  3. sure, would just avoid camelCase to not have mixed kebab and camel, but that's not the point I guess

  4. sure

I think these are all very reasonable and don't require a major overhaul like changing to atomic or something would

1) I assume this includes .panel, .panel-heading and such? 2) should be enough to stop accidentally spreading styles to other components, good. No component should borrow styles from another component ever. (although in sub-components this might still happen with parent components) 3) sure, would just avoid camelCase to not have mixed kebab and camel, but that's not the point I guess 4) sure I think these are all very reasonable and don't require a major overhaul like changing to atomic or something would
Owner
  1. Yea. I guess I should add pseudo-components clause, i.e. when we have stuff like .panel which isn't a component but a generic layout stuff. We could turn it into a component however, but i don't see that much of profit for it right now.
1. Yea. I guess I should add pseudo-components clause, i.e. when we have stuff like `.panel` which isn't a component but a generic layout stuff. We could turn it into a component however, but i don't see that much of profit for it right now.

Related to #857

Related to #857
Sign in to join this conversation.
No milestone
No project
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-fe#344
No description provided.