Refactoring SCSS Base and (Variable) Abstracts for Simplicity

[ByteB4rb1e]

Recently, I've been working on refactoring my base and abstracts layers, and I’ve realized that the key to a maintainable and straightforward structure lies in avoiding unnecessary abstractions. By focusing on plain element grouping instead of over-complicating things with broad or vague categorizations, I've found a cleaner, more intuitive approach.

Starting Point: Rethinking base ⚾🧢

Initially, the base/ directory contained stylesheets like base/typography and base/animations. Within base/typography, I styled headers, paragraphs, and other common text elements, effectively merging reset styles with basic typographic rules. However, as I re-evaluated its purpose, a few things became clear:

• Having a single, generic typography file felt redundant and overly broad, especially since it included more than just text styles (e.g., margins, paddings for resets).
• Splitting the content into granular, element-specific stylesheets would make it easier to see at a glance what’s included and where specific styles reside.

The Move to Plain Element Grouping

To simplify and clarify, I decided to organize base by grouping styles by element or thematic focus, rather than trying to bundle everything into generic categories. Here’s what my updated base looks like:

• base/headings.scss: For all <h1>-<h6> styles.
• base/paragraphs.scss: For <p> styles, including spacing rules.
• base/lists.scss: For ordered and unordered list resets and styles.
• base/animations.scss: Kept as-is for keyframe definitions and animation-related styles.
• base/resets.scss: For universal reset styles like box-sizing, removing default margins, etc.

This shift to plain element grouping eliminates unnecessary abstraction (e.g., no more vague foundation, or typography stylesheets) and makes the organization self-explanatory. If I’m looking for heading-specific rules, I know exactly where to go.

The Problem with Over-Abstraction

Previously, I toyed with naming conventions like foundation or core to house resets and typography. However:

• These abstractions often create more confusion than clarity. When the name doesn’t immediately describe the stylesheet’s purpose, it becomes harder to navigate and maintain.
• Abstract groupings risk becoming dumping grounds for miscellaneous styles, leading to bloated and unmanageable files.

By sticking to clear, element-based groupings, I avoid these pitfalls altogether.

Advantages of This Approach

• Clarity at a Glance: The structure is immediately understandable - headings styles are in base/headings.scss, list styles in base/lists.scss, and so on.
• Flexibility: If the scope of an element grows (e.g., adding more complex heading variants), I can scale the individual file without affecting the rest.
• Maintainability: Removing unnecessary abstraction reduces mental overhead and simplifies onboarding for collaborators.

Conclusion

Refactoring base into plain, element-grouped stylesheets is a step toward a leaner and more intuitive codebase. By resisting the urge to over-abstract with concepts like foundation, I’m able to keep things simple and focused. This approach emphasizes clarity and scalability, making it easier to maintain and extend the structure as the project evolves.

[ByteB4rb1e]

I have to say this really is a tough call. On one hand, I'd appreciate the verbosity of seeing through @use when SCSS abstracts are included in some stylesheet, assuming I at least @forward variables that I'd originally would have defined inside a dedicated abstracts stylesheet. On the other hand I see the problem of this getting out of hand quite quickly... Headings are easy, because they already have a logical grouping, but what about article, p? Intuitively they could be grouped as content, but that still begs the question what to do about pre, textarea, etc? I don't want to define a new convention for this, but I also can't just cram everything into a generic typography stylesheet... We're talking about a document... Most things are typographical... Will look out if there's some generally accepted convention for logically grouping HTML elements.

[ByteB4rb1e]

The easiest way sometimes is to just read the official specification... The HTML5 specification defines semantic groups. This is great, since this adheres to this reference implementation's principle of strictly following guidelines and specifications.

The potential semantic stylesheets would be:

• base/_edits.scss
• base/_embedded.scss
• base/_forms.scss
• base/_grouping.scss
• base/_links.scss
• base/_interactive.scss
• base/_scripting.scss
• base/_sections.scss
• base/_tabular.scss
• base_text-level-semantics.scss

I think this aligns quite nicely with SMACSS convention and it can also be used to define custom abstractions under this semantic grouping.

For completeness, this is an overview of how the HTML elements are grouped:

• document metadata (irrelevant for styling)
• sections -> base/_sections.scss
  • body
  • article
  • section
  • nav
  • aside
  • h1,h2,h3,h4,h5,h6
  • hgroup
  • header
  • footer
  • address
• grouping content -> base/_grouping.scss
  • p
  • hr
  • pre
  • blockquote
  • ol
  • ul
  • menu
  • li
  • dl
  • dt
  • dd
  • figure
  • figcaption
  • main
  • search
  • div
  • a
  • em
  • strong
  • small
  • s
  • cite
  • q
  • dfn
  • abbr
  • ruby
  • rt
  • rp
  • data
  • time
  • code
  • var
  • samp
  • kbd
  • sub
  • sup
  • i
  • b
  • u
  • mark
  • bdi
  • bdo
  • span
  • br
  • wbr
• links -> base/_links.scss
  • link
• edits -> base/_edits.scss
• embedded content -> base/_embedded.scss
  • picture
  • source
  • img
  • iframe
  • embed
  • object
  • video
  • audio
  • track
  • map
  • area
• tabular data -> base/_tabular.scss
  • table
  • caption
  • colgroup
  • col
  • tbody
  • thead
  • tfoot
  • tr
  • td
  • th
• forms -> base/_forms.scss
  • form
  • label
  • input
  • button
  • select
  • datalist
  • optgroup
  • option
  • textarea
  • output
  • progress
  • meter
  • fieldset
  • legend
• interactive elements -> base/_interactive.scss
  • details
  • summary
• scripting -> base/_scripting.scss
  • script
  • noscript
  • template
  • slot
  • canvas