Thank you for building Amber Console. We are using it inside a larger application rather than as the page-owning stylesheet, and the scoped-reset design has been very useful.
Current integration
The source documentation correctly explains that an embedded consumer should replace base/reset.css with base/reset-scoped.css, wrap the region in .ac-root, and rebuild. The published package exposes ./src/*, so this is possible.
In a package consumer that should not maintain a forked build, however, the practical alternative is a long source import list containing tokens, the scoped reset, selected simulations, components, and accessibility rules. That list can drift as Amber Console adds or reorders modules.
The existing layered build solves a different problem: it controls cascade authority, but still contains the page-owning reset. Some application CSS pipelines also handle @import … layer(...) inconsistently, so the layered build is not a substitute for a scoped reset.
Proposal
Would you be open to a supported package entry such as:
import "amber-console/scoped";
backed by a generated dist/amber-console.scoped.css that is identical to the default build except for using base/reset-scoped.css?
A minified variant—and perhaps a scoped layered variant—could follow the existing export pattern if you think those combinations are worth supporting. Even one canonical scoped build would:
- keep embedded consumers on the project's authoritative module order;
- prevent hand-maintained import lists from drifting;
- make the documented
.ac-root integration usable without rebuilding the dependency;
- provide a stable target for a short React/Next.js embedding recipe.
I would be glad to implement the build output, package exports, documentation, and regression coverage after you indicate the package shape you prefer.
Thank you for building Amber Console. We are using it inside a larger application rather than as the page-owning stylesheet, and the scoped-reset design has been very useful.
Current integration
The source documentation correctly explains that an embedded consumer should replace
base/reset.csswithbase/reset-scoped.css, wrap the region in.ac-root, and rebuild. The published package exposes./src/*, so this is possible.In a package consumer that should not maintain a forked build, however, the practical alternative is a long source import list containing tokens, the scoped reset, selected simulations, components, and accessibility rules. That list can drift as Amber Console adds or reorders modules.
The existing layered build solves a different problem: it controls cascade authority, but still contains the page-owning reset. Some application CSS pipelines also handle
@import … layer(...)inconsistently, so the layered build is not a substitute for a scoped reset.Proposal
Would you be open to a supported package entry such as:
backed by a generated
dist/amber-console.scoped.cssthat is identical to the default build except for usingbase/reset-scoped.css?A minified variant—and perhaps a scoped layered variant—could follow the existing export pattern if you think those combinations are worth supporting. Even one canonical scoped build would:
.ac-rootintegration usable without rebuilding the dependency;I would be glad to implement the build output, package exports, documentation, and regression coverage after you indicate the package shape you prefer.