This document summarizes a talk given about the history and development of Sass. It discusses how Sass started with a vision to make CSS more enjoyable to write. Over time, the Sass team listened to feedback to improve features and address issues. They take a thoughtful approach to evaluating new features and ensuring stability. Community involvement is important for testing, providing feedback, and helping with issues. The talk aims to provide insight into managing open source projects.

1. Camp Sass
April 19, 2014
Thank Hampton and Michael

2. Who am I?
Creator of Compass
Sass Developer
Family man
Engineer at LinkedIn
* New Baby in November
* LinkedIn pays me to work on Open Source Software

3. I don’t think that Sass is good
because it’s an abstraction; I
think that Sass is good because
it’s a we!-designed abstraction.
Crucia!y, it’s also easy to learn
…just like CSS.
– Jeremy Keith

4. What makes Sass so
Syntactically Awesome?
A story of taste, co!aboration, and responsiveness.

5. “It's a new syntax that I don't want to learn or support.”
“It's a terrible idea for a CSS preprocessor
to be whitespace sensitive.”
“Good luck supporting two syntaxes.”
“Why the $ak do I need control directives in CSS?”
–Nathan Borror circa 2009

6. Sass 2.0 Source
* I thought this kinda sucked but not for any of the reasons it does.
* good things: left-side-scannable, merge conflicts, I like white-space
* Bad things: repetition -- sass 2.2 fixed this.

7. Sass 3.3 Source

8. Sass 2.0 Output

9. Sass 3.3 Output
Same input API, more configurable/flexible, equivalent to hand-crafted output.

10. How did we get here?

11. Sass’s Vision
Make CSS syntactica!y similar to Ruby and Haml.

12. Sass’s Vision
Make the experience of authoring stylesheets truly enjoyable
Chris Wright’s talk: “joy & excitement”. Every day I see a tweet where someone thanks the internet that Sass exists.

13. What Makes Writing Sass Enjoyable?
Creative Expression.
Remove Drudgery.
Clear understanding of how Sass works.
Straightforward debu%ing.
Trust.

14. A Problem
No one on the Sass core team
writes stylesheets for a living.
My life has taken me down a path that doesn’t involve as much front-end code.
I don’t think this is a big problem with the right process and approach.
Not a hero -> a servant.

15. We Listen
Features are added to
solve the needs
of CSS authors.

16. We Listen
I find myself o!en doing X,
if Sass did Y,
then X would be simpler & more maintainable.
Even if you don’t know what Y is, once you’ve discovered a pattern, I guarantee you we want to solve it.

17. We Listen

18. We Listen... to the trolls.
Be careful who you ca! a tro!.
Most tro!s are speaking to some
form of the truth.
People who speak out against are
o&en tech promoters too.
Public critique != trolling
Real trolls are trying to make you angry. Genuine engagement is often not expected and is disarming.

19. Personal Pride
We never ship anything we don’t love.

20. Minutia Matters
Naming.
Edge cases.
Aesthetics.
Error messages.

21. Not a Democracy
Consensus breeds mediocrity.
Great projects require great leaders. The quality of the Sass language is thanks to Nathan’s unwavering commitment
to perfection (or as close as we can approximate our understanding of perfection)

22. New Feature Evaluation
What other ways are there to accomplish the same feature in Sass or CSS.
How does the feature interact with the other Sass features?
Is it intuitive?
Does it make things harder to maintain?
Potential for misuse?

23. Import globbing
strip-­‐unit function
@include
foo
!important
Properties that are mixins.
@extend
within
@media.
We (Kind-of) Listen
Give users what they need, not what they ask for.

24. @extend within @media
Sometimes the request, as made, cannot be fulfilled.
We would love to allow user to write this.

25. @extend within @media
Users wanted Sass to move the selectors involved in the @extend query to the media query.
Moving selectors is a very dangerous operation and can break expectations based on source order.
Furthermore, the act of moving selectors is more like @include another break of expectation

26. @extend within @media
After approximately 1000 requests for this feature it occurred to us that there was another possible output, that
while bloated, didn’t behave unpredictably.

27. We Listen
“In preparation for its release, we've
put out a couple of release candidates
to be sure that everything was set and
ready to go. Unfortunately, it wasn't.”
Usually, it falls on Nathan and me to tell other people why their features do not cut the mustard. But in this case, the
community told us. & in SassScript failed to be intuitive for the use case of handling multiple parent selectors. Full
write up: https://gist.github.com/nex3/8050187

28. Patience
AVirtue it is

29. Understanding cannot be rushed.
When we don’t know, we wait.
We trust our instincts that something is not right.

30. Long Release Cycles
Let the community adjust
Provide stability
Fewer features, more thought

31. This Was Amazing to 2008 Me

32. “It's a new syntax that I don't want to learn or support.”
“It's a terrible idea for a CSS preprocessor
to be whitespace sensitive.”
“Good luck supporting two syntaxes.”
“Why the $ak do I need control directives in CSS?”
–Nathan Borror circa 2009
We were pretty sure control directives did make sense. and it was thanks to the weird syntax...

33. We Need You!
Subscribe to the issue tracker &
watch issues that look interesting to
you.
Help triage common issues
Confirm bug reports and improve the
information about them.
Identify the commit that caused a
regression (git bisect!)
Provide a workaround for the user
Leave us useful issue comments ~
Disagree with us!
Te! us when we’re on the right track

34. Community Interaction Guidelines
Not everyone is going to be as tapped
into Sass development as you.
Educate, don't chastise.
The correct response to someone who
is being an entitled jerk is to
disengage.

35. We Need You!
Test new features in alpha releases.
Blog about your experiences. Think
out loud.
Speak at local meet-ups.
Make feature su%estions
Polish patches - Documentation
improvement
Sass-lang.com documentation.

36. Thank You!
I hope this talk has helped you understand how Sass works
& more genera!y, a way of running and working with open source projects.