mirror of
https://github.com/danog/sass-site.git
synced 2024-12-11 08:59:51 +01:00
73 lines
3.4 KiB
Plaintext
73 lines
3.4 KiB
Plaintext
---
|
|
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.
|
|
|
|
%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.
|