mirror of
https://github.com/danog/sass-site.git
synced 2024-11-27 04:24:50 +01:00
72 lines
3.4 KiB
Plaintext
72 lines
3.4 KiB
Plaintext
---
|
|
title: Implementation Guide
|
|
introduction: >
|
|
Sass has a thriving community of implementations, with more being produced all
|
|
the time. The core team loves to see new implementations thrive and mature,
|
|
and they want to help out in any way they can.
|
|
---
|
|
|
|
%ul.list-tiled
|
|
%li
|
|
:markdown
|
|
## Resources
|
|
|
|
* [`sass-spec`](https://github.com/sass/sass-spec) is a suite of
|
|
implementation-agnostic test cases for verifying that a Sass
|
|
implementation behaves correctly. It's the best way to track your
|
|
implementation's compatibility with the Sass reference implementation.
|
|
|
|
* [How `@extend` Works](https://gist.github.com/nex3/7609394) is a fairly
|
|
comprehensive run-down of the algorithm used by Sass's trickiest
|
|
feature. Natalie still says that the implementation of `@extend` is the
|
|
hardest code she's ever had to write, but luckily you don't have to
|
|
figure it out from scratch.
|
|
|
|
* **Reach out!** If you're working on a new implementation, we want to
|
|
hear about it. Send an email to [Natalie](mailto:nex342@gmail.com) and
|
|
[Chris](mailto:chris@eppsteins.net), tell us about the cool work you're
|
|
doing, and ask about any corners of the language that don't quite make
|
|
sense.
|
|
|
|
%li
|
|
:markdown
|
|
## Requirements
|
|
|
|
We whole-heartedly love new implementations of Sass, but we do have a few
|
|
restrictions that we ask those implementations to follow in order to call
|
|
themselves "Sass", "Sass implementations", or the like. Sass is a
|
|
community as much as it is a language, and it's important that all
|
|
implementations are willing to work for the good of the community.
|
|
|
|
First, we ask that every implementation adopt the [Sass community
|
|
guidelines](/community-guidelines) for their own implementation-specific
|
|
communities. Much of what makes the Sass community strong is a culture of
|
|
kindness and respect, and having clear and explicit guidelines helps
|
|
produce that culture.
|
|
|
|
Second, we ask that implementations not extend the language without
|
|
agreement from the other major implementations and from the language
|
|
designers, Natalie and Chris. The only reason a Sass community exists at
|
|
all is because the language enables styles and frameworks to be shared
|
|
among designers, and it's crucial for sharing that Sass code that works
|
|
for one implementation works the same for all of them. In addition, it's
|
|
important that there be a unified vision for the language design.
|
|
|
|
%li
|
|
:markdown
|
|
## Making Language Changes
|
|
|
|
Sass can still evolve as a language, of course. We're working on putting
|
|
together a more explicit process for proposing and iterating on new
|
|
language features, but for now all discussion of changes happens on [the
|
|
Sass issue tracker](https://github.com/sass/sass/issues). Language changes
|
|
are considered final when they're part of a stable release of the Ruby
|
|
reference implementation.
|
|
|
|
Language changes are discussed collaboratively, with particular weight
|
|
given to the maintainers of mature Sass implementations. Attempts will be
|
|
made to reach consensus with all stakeholders. However, this may be
|
|
impossible in some circumstances, and the ultimate say lies with the lead
|
|
designer of Sass, Natalie. Chris, the other core designer, also has veto
|
|
power over any language change.
|