Why this matters
Consistent scoping ensures that styles only apply to the intended components, preventing unintended side effects and making styles easier to manage, especially in large projects or when using third-party components.
For applications, styles in a top-level `App` component and in layout components may be global, but all other components should always be scoped. This can be achieved through CSS modules, class-based strategies like BEM, or the `scoped` attribute in Single-File Components.
Consistent scoping ensures that styles only apply to the intended components, preventing unintended side effects and making styles easier to manage, especially in large projects or when using third-party components.
Side-by-side examples engineers can pattern-match during review.
<template>
<button class="btn btn-close">×</button>
</template>
<style>
.btn-close {
background-color: red;
}
</style><template>
<button class="button button-close">×</button>
</template>
<style scoped>
.button {
border: none;
border-radius: 2px;
}
.button-close {
background-color: red;
}
</style>
<template>
<button :class="[$style.button, $style.buttonClose]">×</button>
</template>
<style module>
.button {
border: none;
border-radius: 2px;
}
.buttonClose {
background-color: red;
}
</style>
<template>
<button class="c-Button c-Button--close">×</button>
</template>
<style>
.c-Button {
border: none;
border-radius: 2px;
}
.c-Button--close {
background-color: red;
}
</style>From the same buckets as this rule.
For changes that affect architecture, data models, external APIs, security posture, deployment topology, or cost (>10%), create an ADR in docs/adr/ using the standard template (Context, Decision, Consequences) and link the PR and issue IDs.