LSCSS

Hacks

Containing hacks

Hacks are sometimes necessary. The problem is not using one. The problem is pretending it is not a hack and letting it quietly become architecture with a desk and calendar invite.

Quick decision rules

TEXT code example 
Ask:
Is this temporary and urgent?
→ Hacks

Is this a real structural fix?
→ Component or layout

Is this only visual presentation?
→ Theme, not hacks

A hack should be obvious, justified, and easier to remove later than it was to add today.

Why the hacks layer exists

Production sometimes needs a fast correction before the real refactor is possible. The hacks layer gives those urgent fixes a visible quarantine zone instead of hiding them inside normal component files.

This protects the rest of the system from temporary decisions pretending to be design choices.

Visible hacks

CSS code example 
@layer hacks {
    .legacy-slider {
        inset-block-start: -1px;
    }
}

A good hack is isolated in the hacks layer, clearly named, and documented enough that nobody has to perform archaeology to remove it later.

Hidden hacks and permanent emergencies

CSS code example 
.product-card {
    margin-block-end: 12px !important;
}

.site-header {
    z-index: 999999;
}

These are not sustainable fixes. Hidden important declarations and panic z-index values create ongoing debugging overhead, not maintainable systems.

  • Do not hide hacks inside normal component files.
  • Do not use theme as a hiding place for temporary fixes.
  • Do not leave undocumented important declarations behind.
  • Do not let emergency values become permanent architecture.

Working rules

  • If it survives long enough to feel normal, review it.
  • If it needs explaining twice, it probably needs a real fix.
  • If it exists because of legacy CSS, keep it near that legacy context.
  • If it is no longer temporary, move it or remove it.
  • Hacks should be visible enough to make people slightly uncomfortable.

Next useful pages