Skip to content

Commit

Permalink
Clean up of the unrelated text
Browse files Browse the repository at this point in the history
  • Loading branch information
bitxplora committed Jul 14, 2024
1 parent 1057f3d commit a93d1bf
Showing 1 changed file with 0 additions and 50 deletions.
50 changes: 0 additions & 50 deletions text/1037-add-glimmer-scoped-css-by-default.md
Original file line number Diff line number Diff line change
Expand Up @@ -50,54 +50,4 @@ to fight spill CSS that is affecting other components.

There is an implementation already. [glimmer scoped-css](https://github.com/cardstack/glimmer-scoped-css)

> This is the bulk of the RFC.

> Explain the design in enough detail for somebody
familiar with the framework to understand, and for somebody familiar with the
implementation to implement. This should get into specifics and corner-cases,
and include examples of how the feature is used. Any new terminology should be
defined here.

> Please keep in mind any implications within the Ember ecosystem, such as:
> - Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed
> - Features that are replaced or made obsolete by this feature and should eventually be deprecated
> - Ember Inspector and debuggability
> - Server-side Rendering
> - Ember Engines
> - The Addon Ecosystem
> - IDE Support
> - Blueprints that should be added or modified
## How we teach this

> What names and terminology work best for these concepts and why? How is this
idea best presented? As a continuation of existing Ember patterns, or as a
wholly new one?

> Would the acceptance of this proposal mean the Ember guides must be
re-organized or altered? Does it change how Ember is taught to new users
at any level?

> How should this feature be introduced and taught to existing Ember
users?

> Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc.
## Drawbacks

> Why should we *not* do this? Please consider the impact on teaching Ember,
on the integration of this feature with other existing and planned features,
on the impact of the API churn on existing apps, etc.

> There are tradeoffs to choosing any path, please attempt to identify them here.
## Alternatives

> What other designs have been considered? What is the impact of not doing this?
> This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.
## Unresolved questions

> Optional, but suggested for first drafts. What parts of the design are still
TBD?

0 comments on commit a93d1bf

Please sign in to comment.