From fbbb7eb25ec5f38f378ac30c61acf2c87704bfca Mon Sep 17 00:00:00 2001 From: Natalie Weizenbaum Date: Fri, 29 May 2015 16:06:26 -0700 Subject: [PATCH] Add an Implementation Guide. This is designed to help creators of new Sass implementations know where to start and what to avoid. --- source/implementation/index.html.haml | 66 +++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 source/implementation/index.html.haml diff --git a/source/implementation/index.html.haml b/source/implementation/index.html.haml new file mode 100644 index 0000000..897f084 --- /dev/null +++ b/source/implementation/index.html.haml @@ -0,0 +1,66 @@ +--- +title: Implementation Guide +--- + +- content_for (:introduction) do + 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. + +: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. + + ## 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. + + ## 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.