Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Start a free Basic trial
to watch this video
Custom Framework/Style Guide Panel - Part II
53:01 with John Athayde, Elyse Holladay, Rachel Ober and Pam SelleThe Custom Framework and Style Guide panels at SassConf are designed to get an array of opinions about a topic out and to get a conversation going.
Conference Slides
-
0:00
[Custom Framework/Style Guide Panel] [John Athayde, Elyse Holladay, Rachel Ober and Pam Selle]
-
0:04
[Special Guest Nathan Weizbaum]
-
0:06
Can I ask a quick—because I have the mic.
-
0:10
Are designers ever part of your teams?
-
0:12
I'm the head of the team.
-
0:16
I'm the head UX guy and the head front-end guy,
-
0:18
but I'm definitely more a UX person than a front-end person
-
0:21
as far as my life experience.
-
0:23
And then I have 1 other pure UX design person
-
0:27
and 2½ other pure front-end people.
-
0:30
But it's funny, because when you have that small of a condensed team,
-
0:33
a lot of the front-end guys are saying, "Hey, I kind of mocked this up in code,"
-
0:37
and the designer will definitely come more from the Photoshop or Balsamic approach
-
0:41
to how he mocks things up, but there's a lot less of this
-
0:44
I have made the artifact, I pinned it up on the wall,
-
0:46
and I walked away, which I think larger design organizations,
-
0:51
even in companies, will do that kind of here we are, we are done,
-
0:54
and we are handing it over, and you have people chucking bags over the transom at each other,
-
0:58
so I think the benefit for us is it's 100% integrated.
-
1:03
Yeah, at Paperless we're slowly fixing that.
-
1:08
As we were talking about throwing things over the fence,
-
1:12
and it's like we're not Waterfull, but we kind of are
-
1:16
where we have somebody who puts the UX together,
-
1:19
then after that UX is finalized somebody then does high fidelity mockups,
-
1:23
and then maybe at that point I will see it,
-
1:26
or it goes to a Rails developer, they build it out,
-
1:29
and then they're like, "Hi, Rachel, fix this."
-
1:32
Sometime with—main markup.
-
1:38
On Wednesday we are going to attempt for the first time ever
-
1:42
to have a designer sit with me
-
1:45
and other members of the front-end team
-
1:47
to do design in browser and pair design programming.
-
1:53
I'm not exactly sure what the appropriate terms are.
-
1:58
Yes, thank you.
-
2:00
I will report back, and I'm interested to see how that goes,
-
2:05
because our UX and designers I think are probably really scared of HTML and CSS.
-
2:12
They probably don't even know Sass really.
-
2:16
But it will be a learning experience for all of us,
-
2:18
and we really hope that will break that cycle.
-
2:24
I don't really have a large team at all.
-
2:27
I have me, and I hired another girl to help me,
-
2:29
and then there's a UX designer, and he's not in the code at all.
-
2:32
But we have had so much improvement
-
2:35
in the way some of our new features have been coming out
-
2:38
when him and I sit down and have this conversation.
-
2:40
We're working on some mobile stuff right now,
-
2:42
and so he was doing wires for it, because we do have to show our client and get some approval,
-
2:45
but we sat down and talked about it first,
-
2:48
and we're doing it together, and the first round of wires he did without me,
-
2:53
and then we sat down and talked about it, and the second one was miles better.
-
2:57
It was so good, so I'm sure you all will have really good luck with that.
-
3:00
I hope so.
-
3:02
[female speaker] Rachel, how did that process change?
-
3:04
How did you get to the point where this is going to happen on Wednesday, like internally?
-
3:08
Well, the starting point was attending Sass Meetup a couple weeks ago in New York City.
-
3:15
Did you know this already?>>Did I?
-
3:18
No, she had asked the question there,
-
3:21
so I was like, "Oh, my goodness, they're actually doing it,"
-
3:23
so I was thrilled to find out how you got to—
-
3:26
So I think I was originally interested
-
3:29
because the talk that night was going to be talking about maybe mobile—
-
3:32
[female speaker] Responsive web design I think was the one.
-
3:35
Yeah, and I dragged along a co-worker
-
3:39
who was also passionate about not having stuff thrown over fences,
-
3:42
and we were like, "Okay, this responsive thing is good,
-
3:46
"but how do we actually get this into our workflow,
-
3:49
"because there's no way the way it currently is
-
3:53
"that people are putting stuff in stone,
-
3:56
"and if it trickles down all the way even after development happens
-
4:02
and then I'm given this thing and saying, 'Well, it doesn't look exactly right, can you fix it?'"
-
4:06
There's no way then for me to take that
-
4:09
and actually create some type of responsive design
-
4:11
because I would have to rewind all the way back
-
4:16
to try to implement that.
-
4:18
You should have built a time machine.
-
4:20
That should have been there.>>I know, that's my problem.
-
4:22
I keep getting told the time machine.
-
4:24
But I went to the meetup, and we're so frustrated.
-
4:28
How do we start change at our organization?
-
4:33
And Sam was like, "Sit that designer next to you
-
4:36
and just do it," and that was already probably over a month ago,
-
4:41
and we're finally doing it on Wednesday.
-
4:43
It takes time, and you have to convince people,
-
4:47
and one of our biggest issues I think
-
4:51
is changing behavior of the other people there.
-
4:54
People can get really excited,
-
4:56
but there's a lot of doubt that goes into, "Oh, my gosh, now I have to sit with somebody?
-
5:00
I picked a design job so I wouldn't have to talk to anybody."
-
5:03
[female speaker] I thought that was developers.
-
5:05
Same with developers.
-
5:07
But I was actually talking to them, and it's like I don't know how I'm going to deal with working with somebody,
-
5:13
because I think some people pick certain positions
-
5:16
so they can enjoy their world,
-
5:19
and I've noticed this change where it's like you can't hand stuff off anymore
-
5:24
in the environment that we're in.
-
5:26
Yeah, I think the lines are blurring a lot.
-
5:30
Yeah, it's like I'm moving into more designy things
-
5:34
and also still on the development, and it's like we can't have silos anymore.
-
5:39
Even as a developer, if you are responsible for the logic
-
5:44
that happens behind the interaction,
-
5:46
then you also are a stakeholder in how the interaction—
-
5:49
Those are your choices. Those are choices for your users, and you have to be aware of that.
-
5:52
Exactly, so you have to be at least aware,
-
5:54
at least marginally involved, but I think there's also 2 things.
-
5:58
The caution to back up is there's the line between let's get involved
-
6:05
and let's have lots of opinions.
-
6:10
But it's about respecting other people's expertise,
-
6:13
so I think when you come to people—
-
6:16
and that's the success I've had with working with designers
-
6:18
is I start up sentences with, "Well, given your expertise,"
-
6:23
in a very "You are the most excellent designer I've ever met" sentence.
-
6:29
But that puts people into a better place
-
6:33
because it's not you telling them what to do.
-
6:35
It's you saying I understand that you understand this world,
-
6:39
and I'd really like to understand it too so I can do my job better,
-
6:42
and then we can both be better at our jobs.
-
6:44
And if you're a developer side,
-
6:47
even if you're the Hampton where I don't know art at all,
-
6:52
I love art but I can't do art kind of thing,
-
6:54
it doesn't mean you shouldn't have an eye or develop an eye
-
6:57
to be able to say, "This feels wrong."
-
6:59
Learn to speak the language.>>Yeah, learn to speak the language.
-
7:01
And design is not just about "the pretty."
-
7:05
It is about how it works, the famous Steve Jobs quote.
-
7:08
And there's accessibility.
-
7:10
There's all kinds of factors and interaction that you don't have to be a brilliant artist to understand.
-
7:15
If you say, "That's the designer's problem," you're not doing your job.
-
7:19
I'm really fascinated by this concept.
-
7:21
I've been thinking about this for a couple years.
-
7:23
What are the UX things that developers can do?
-
7:25
And not even necessarily front-end devs but back-end devs.
-
7:28
What are those choices?
-
7:30
How can you instill that way of thinking
-
7:34
into somebody who doesn't have UX experience?
-
7:37
I would love to talk about that post panel.
-
7:39
Flow, flow, flow and flow,
-
7:41
because those database decisions reflect all the way up.
-
7:43
Yes, but getting a basic reading on information design in general—
-
7:47
like so many developers are interested in this topic,
-
7:52
I know have been to the Edward Tufte course,
-
7:54
and that's the basic core of here's information design.
-
8:00
Let's talk about charts, ya'll,
-
8:03
and why we all hate PowerPoint.
-
8:05
Not why PowerPoint is bad but why people hate it.
-
8:08
There's reasons.>>And why do people abuse it.
-
8:10
Yeah, they abuse it, but there is a place for it,
-
8:13
but understanding the why and not just implementation.
-
8:17
I think there's a few audience questions hanging out.
-
8:20
[male speaker] First, to affirm that, I think no matter where we work
-
8:23
or what we do, always encourage designer-developer partnerships and relationships.
-
8:29
That's awesome, so that's something I wanted to affirm.
-
8:32
I want to go back a few about frameworks.
-
8:35
I had a quick opinion.
-
8:37
I think what you said about your team
-
8:40
making your custom framework and then you only have 1 new design a quarter,
-
8:45
that's awesome, but for people here who are new
-
8:49
or who are figuring things out, frameworks are genius,
-
8:52
because you can jump into something,
-
8:54
you can have something out in a day,
-
8:57
and you can learn a lot from the code in the framework.
-
8:59
I actually learned most of my web development
-
9:04
2½ years ago jumping into Bootstrap
-
9:06
just to see what the heck is going on.
-
9:08
I think if you're doing a hack or you're doing an internal thing
-
9:12
or your client doesn't care what it looks like, Bootstrap, boom.
-
9:15
Done. It's internal.
-
9:17
You got paid for it. You launched it.
-
9:19
It's genius.
-
9:21
But if you're going to put something out in the world
-
9:24
and you want our peers to see it and respect it
-
9:26
and you want to be respected, Bootstrap is probably not your best choice.
-
9:30
But somebody said they set a standard, which is a style guide standard almost,
-
9:36
all these little elements that you see.
-
9:39
But my continued opinion is that Foundation is so good
-
9:45
because it does allow you to roll your own in a quick way.
-
9:49
I wanted to say this: they're not always good, and they're not always bad.
-
9:53
I think it depends on your use case.
-
9:55
Yeah, when I teach at MakerSquare they're learning Rails,
-
9:59
and so they don't get a lot of front-end stuff,
-
10:01
and so when I talk to them they ask me the same question, every single class.
-
10:05
They're like, "What about Bootstrap or Foundation?
-
10:07
What's your opinion on the frameworks?"
-
10:09
Pick the right tool for the job.
-
10:12
And I think that's what you were getting at.
-
10:15
Am I a developer trying to put out a plugin,
-
10:17
or am I trying to learn, like do I want to hack on this stuff for myself?
-
10:19
Am I trying to make my mom's cousin's friend a thing that I want to learn on?
-
10:26
Or you need to pay your rent.
-
10:28
My husband got $200-$300
-
10:32
from redesigning a website for his flight instructor.
-
10:36
He's like, "Oh, my God, this is the best thing ever!"
-
10:39
It was just done in Bootstrap.
-
10:41
I looked at it, and I'm like, "It's Bootstrap."
-
10:43
But to other people that are not—
-
10:46
There's a bigger point to that of sometimes when we get very naval gazing about these things
-
10:52
we forget that for many people
-
10:56
the Internet is Google.
-
10:58
Or Facebook.
-
11:00
The page is the Internet.
-
11:02
A small percentage of people know Bootstrap.
-
11:06
And one distinction I like to make is that internal
-
11:10
doesn't necessarily mean easier.
-
11:12
It doesn't necessarily mean that you can pass it off,
-
11:14
because for Living Social, for example,
-
11:16
internal users are 4,000 people.
-
11:19
And so very small productivity gains actually affect the bottom line.
-
11:23
Now, if you have 10 people and 2 of them are actually doing your production work
-
11:28
and using your admin system, that's ludicrous.
-
11:31
Don't spend 4 weeks making a beautiful item.
-
11:33
That's what I was referring to.
-
11:35
Yeah, it depends, of course.
-
11:37
[male speaker] I think it's also important to remember with that
-
11:39
the whole issue of frameworks versus rolling your own—hi.
-
11:44
I was like where is this voice coming from?
-
11:48
[male speaker] It's not an on/off switch.
-
11:50
It's not one or the other.
-
11:53
You can use a lot of other people's code
-
11:56
rolling your own, and it's a whole continuum.
-
12:00
There's a lot of modular plugins that you can build your own framework
-
12:04
using entirely someone else's code.
-
12:07
It's not yes or no, I will either write it all internally or—
-
12:12
The most basic of frameworks is normalized.
-
12:15
When I show the students I teach at MakerSquare Sass stuff they're like,
-
12:19
"How do you learn to write all these CSS3 mix-ins with the gradient?"
-
12:24
I'm like, "I did not write that."
-
12:27
You've got to be kidding me. Nobody writes that.
-
12:29
It's already been done.
-
12:31
We just copy the same line over and over again.
-
12:33
Yeah, that guy.
-
12:36
[female speaker] That segues into a question that did come in as well.
-
12:39
Do you use many pre-made components in your own frameworks?
-
12:44
And if so, what ones do you use and like?
-
12:46
Pre-made components.
-
12:48
Like do you take Twitter, Bootstrap, JavaScript thing or do you take—
-
12:54
I'm inspired by techniques a lot.
-
12:57
If I see how—like I still remember last year Eventbrite got a new Facebook button,
-
13:03
and I was like, "Check out that button,"
-
13:06
and it was well commented.
-
13:08
It had all the fallbacks with the comments of why they were there,
-
13:12
and I copied it, and I was like, "This is how I'm going to build my next Facebook button."
-
13:16
Not the exact same thing, but learning the lesson from how they did it.
-
13:20
And I think, again, back to CSS3 mix-ins,
-
13:23
they have been done.
-
13:25
They have been done and tested.
-
13:27
You can actually literally pull those entire things,
-
13:29
and for me the grid stuff I did was some combination of Dave Rupert's Foldy960
-
13:35
and some other media query stuff,
-
13:40
and then Chris's grid for loop thing,
-
13:43
and I was sending him chats like, "Help me!
-
13:46
I don't know how this works!"
-
13:48
But it's cool. I didn't have to write that.
-
13:50
I didn't have to go figure out how to do all that.
-
13:52
It was much easier, and it did exactly what I wanted without being a whole entire framework,
-
13:56
so pulling all those little bits and pieces
-
13:58
from the places that are inspiring to you or relevant to you.
-
14:01
And you made a perfect point.
-
14:03
It's not binary.
-
14:05
I don't know what it's about, but I think it's about 20% of Wild is Bootstrap derived.
-
14:08
We actually are using the Bootstrap buttons file,
-
14:11
and then we did a whole bunch of tweaks for different kinds of buttons,
-
14:13
different sizes.
-
14:15
Wild is the internal app?>>This is the internal, yeah.
-
14:17
I'm sorry, Wild is our internal GEM that does our style guide.
-
14:19
And we use a lot of the standard jQuery, Accordion, and stuff like that,
-
14:23
and then we tweak it, so they've figured out how to make this work.
-
14:27
I'm going to pull these pieces in.
-
14:29
Don't reinvent the wheel.>>Right.
-
14:31
And for us we pulled a couple things from Bourbon, things like that,
-
14:35
and I think if you're doing this from scratch the first time
-
14:39
and you really want to roll your own,
-
14:42
pulling pieces to build it and then being able to modularly say,
-
14:46
"This doesn't work well anymore.
-
14:48
Let me now roll my own, or hey, this one over here is really cool."
-
14:51
Just as an aside, I think for the newer people
-
14:55
there is some value in learning how to write these mix-ins
-
15:00
or learning how to do this stuff.
-
15:02
But you don't necessarily have to go to the depths
-
15:07
of having it be production ready,
-
15:09
like CSS3 gradient mix-in, all by your lonesome.
-
15:12
That's already been done, but you can go in CodePen
-
15:14
and edit it and play with it and see how it works,
-
15:16
and you can go and play with extends and play with mix-ins
-
15:19
and understand how the bits and pieces that you're pulling from other places are being created,
-
15:24
even if you couldn't necessarily write all that yourself.
-
15:27
And if you're new into the Sass world,
-
15:30
one thing that's helped me a lot is taking, say,
-
15:33
a button file or one of these old CSS files
-
15:37
that is not dynamic and saying, "I'm going to port this to SCSS."
-
15:40
I want to do a little audience participation.
-
15:42
How many of you are fairly new, within the last year or so, to Sass?
-
15:48
Nice, that's awesome.
-
15:50
And you're loving it, right?
-
15:53
You're here.
-
15:56
Any haters?
-
16:01
[female speaker] Speaking about haters, here's one for each of you,
-
16:03
and then maybe the audience will also participate.
-
16:06
Speaking of haters, here's a question.
-
16:09
Sorry. We could.
-
16:11
I wanted an individual hater.
-
16:16
What are your biggest pet peeves about Sass and/or Compass?
-
16:19
Important note.
-
16:21
Who did this question come from?
-
16:23
I can't—>>It's on Twitter, come on.
-
16:26
My biggest pet peeve was the Compass grid system,
-
16:30
and that's now gone.
-
16:33
Nesting.
-
16:35
Nesting and the old syntax.
-
16:37
See, I'm going to have to disagree with you, because nesting can be awesome.
-
16:40
It's not the fault of nesting that people abuse it
-
16:45
just like it's not float's fault that we horribly screw them up and use them for layout.
-
16:49
That's fair, but then I qualified with also the old syntax
-
16:54
because the way the old syntax—being white-space dependent
-
16:57
I feel like when people wrote it in that syntax
-
17:01
it highly encouraged nesting,
-
17:03
because one of the things I told people when I was like, "Stop using the old syntax"
-
17:06
is that you're allowed to indent things because it's not white space,
-
17:11
for like an SCSS, so if you want, if you really, really desperately want
-
17:16
something to be indented beneath something else,
-
17:18
you can have it, and you don't have to generate 7 levels deep selectors because of it.
-
17:24
I'll admit I use the bad syntax, and I like it.
-
17:26
Also, it encourages descendent selectors and not first child selectors,
-
17:29
or not direct child selectors.
-
17:31
I'm like my—
-
17:35
But I think that's an evolution.
-
17:37
I think people start off with Sass—or at least when I started with Sass,
-
17:39
it was replicate the DOM, and I was using the new syntax.
-
17:42
I was like replicate the DOM, this is amazing.
-
17:44
And of course I was setting it up because I will add styles there,
-
17:48
and now it's much more of I'm only going to write the styles I need
-
17:53
and then refactor and refactor and refactor.
-
17:55
I'm with you on the indentation thing.
-
17:58
That's how I think I and probably a lot of people used to visually format
-
18:02
their CSS files to indent stuff under the parent.
-
18:05
Not nesting but indenting to visually organize.
-
18:09
But I actually like the .sass syntax.
-
18:12
I don't know, I use it.
-
18:18
I like the indent syntax.
-
18:20
They're all getting pulled from my code base.
-
18:22
I think honestly it's not really different.
-
18:26
This is one of the things when I first started that I also hate about it
-
18:29
because I feel there's also—and I JavaScript a lot,
-
18:34
and I'm not on Team CoffeeScript, because I also do think that there is a benefit that you get
-
18:39
when you're close to what you get.
-
18:41
So context switching basically.
-
18:45
Staying close to what your output is,
-
18:49
because if someone who already hated writing CSS—
-
18:52
they're like, "Awesome, I hate writing CSS.
-
18:55
Now I can write Sass, and nothing looks like CSS anymore,"
-
18:57
and then they're debugging in the browser because that's where we make things.
-
19:02
It doesn't get you out of it.
-
19:04
You still have to look at it in the browser,
-
19:06
and then you don't understand the CSS anymore because you had the context switch,
-
19:09
and you can't read it anymore.
-
19:11
The way that I use the nesting—
-
19:13
I was talking to somebody about this yesterday—
-
19:16
is name spacing modules,
-
19:18
because then we can reuse classes,
-
19:21
and we have so many different things, and so I'll have the parent module,
-
19:24
and I think John was showing this in his talk too.
-
19:27
You have the name of your module and then the sub stuff,
-
19:31
and so then you can use state classes, is active, is hidden, whatever,
-
19:35
inside of a module without them being global.
-
19:38
It's cool.
-
19:40
I thought you were talking about the left side bar
-
19:42
and the header in the left side bar and then this band inside.
-
19:45
If I was talking about that, I should be forcibly ejected from this venue.
-
19:49
No, but I think nesting, it's not evil all by itself,
-
19:54
and I think that Sass is the same way.
-
19:56
You have to be very aware of what you're writing.
-
19:58
You have to look at your output, and if you're not,
-
20:00
then you are doing it wrong, and your CSS too,
-
20:03
your output that is CSS should be close to the CSS that you would have written.
-
20:07
And I don't mind doing that extra step.
-
20:11
I think as an author I much prefer the Sass syntax.
-
20:13
I like the way it is. I like the way it looks.
-
20:15
I find it easier to read. I like to write it.
-
20:17
But I still look at my output file.
-
20:19
And that's like for me.
-
20:21
I have a friend, and I really like the way he said this.
-
20:23
He said this the other day.
-
20:25
He said, "All glory to the build system."
-
20:28
You should do whatever you want, and all glory to the build system.
-
20:33
As long as you can work that way
-
20:37
and your team works that way, awesome.
-
20:39
I have a very strong opinion in how I work that way,
-
20:42
and I was like no deal, because I really like CSS,
-
20:45
and so I'm in a CSS world, and I like staying close to that.
-
20:49
And up until 3 or 4 months ago,
-
20:53
my team was me, so that made it very, very easy to control.
-
20:57
And now you have to dictate everything to the minions.
-
21:01
One thing developers often do is they say, "Oh, I don't like the way CSS looks,
-
21:06
or ERB looks," or things like that, and instead of saying—
-
21:09
they just switch to something like Haml or Slim or LESS or Sass.
-
21:15
And instead of refactoring and learning
-
21:18
how to do good typographic refactoring and write good HTML and CSS in the first part—
-
21:22
Yeah, because you probably don't like HTML because you're writing too much of it.
-
21:25
Right, and I have this problem.
-
21:28
I don't know if he's laughing because I've ripped on Haml,
-
21:31
but I've ripped on Haml a lot in my day,
-
21:34
but it's not Haml that's the problem.
-
21:37
It's that people sit there and say, "ERB is ugly, and therefore, Haml solves that problem,"
-
21:42
and maybe ERB is not the problem.
-
21:45
You can still write terrible code with Haml.
-
21:47
You can write awful CSS or Sass or SCSS or whatever.
-
21:50
You are the author. You have the responsibility.
-
21:53
Sass is going to fix that for you.
-
21:55
And so many of these tools you see if the team is really efficient
-
21:59
you get a massive multiplier.
-
22:01
My co-author, Bruce Williams, they use a bunch of Haml
-
22:04
in the stuff they're building for the merchant side, and they're really fast with it.
-
22:07
But they know how to write good HTML in the first place,
-
22:09
so for them it's just a force multiplier.
-
22:11
It's not a, "Oh, it's not ugly anymore."
-
22:14
It's a "I can just write faster," or the great example you had in your talk yesterday
-
22:19
where you can look down it and immediately, boom, I internalize the document structure.
-
22:22
I want to go back to the original question,
-
22:24
and I talked about this a little bit earlier,
-
22:26
and this is probably a thing—>>What was the original question?
-
22:28
The haters hate.>>Haters are going to hate.
-
22:30
What are your pet peeves in Sass and/or Compass?
-
22:34
And we talked about this earlier about the theming variable thing.
-
22:37
I really, really would love to have my client variables
-
22:40
and then be like image URL, client variable,
-
22:46
and then whatever client name, and whichever client it is,
-
22:49
then it will inject that for me, and that's probably not a thing that's going to happen.
-
22:52
So maybe—>>Or maybe I don't know how to do it.
-
22:56
This has to be more complicated than I'm thinking,
-
22:58
because could you set a variable that is the asset path for whatever
-
23:02
and then at compile you change those variables?
-
23:06
We do something like that.
-
23:08
There's a paths file in Wild that basically you can set all of those things up,
-
23:11
because we have 1 instance where we're still in Rails,
-
23:15
and we're pre-asset pipeline, so we have a shell script
-
23:18
that dumps everything out into static—
-
23:20
Rails asset pipeline, the Ruby on Rails.
-
23:22
But your pre-asset pipeline?>>2.3.
-
23:24
In production, so when you have to support all things like that,
-
23:28
we dump everything out statically, but we can actually specify
-
23:30
in there all the paths, so when it prints it all out
-
23:33
it's printing out the proper location for that app.
-
23:36
There may be some things that I'm not understanding.
-
23:41
I think it would work for images, but I want to be able to do stuff like in my style sheets.
-
23:44
If it's this client, do X.
-
23:47
If it's this client, do that.
-
23:49
If it's this client, do this other thing.
-
23:51
And you can't do that dynamically, or at least I could not get any of that to work.
-
23:59
[female speaker] We're going to take 1 more question.
-
24:05
[male speaker] My question is about the frameworks and particularly custom frameworks
-
24:09
that you guys have rolled your own
-
24:11
is I guess what you're saying.
-
24:13
What are some methods of evangelizing and getting other people on your team
-
24:19
to actually use the frameworks?
-
24:21
I've done the same thing where I've developed a framework for my team,
-
24:25
and it's great for rapid prototyping for me
-
24:28
because I spent 6 months building it, so I know exactly how it works,
-
24:31
but how do you make it accessible to other people?
-
24:35
Do you guys do code reviews?
-
24:37
Do you have tutorial sessions and hacks?
-
24:40
What are some methods of getting other people on board?
-
24:43
I'm still doing all those things.
-
24:45
Another cheat is also to volunteer
-
24:48
to indoctrinate your interns whenever you have interns,
-
24:51
because your interns are often hired.
-
24:54
So if you get them first—
-
24:57
The most successful intern I worked with,
-
24:59
he started earlier than all of our other summer interns.
-
25:03
I spent half of the day—I picked a ticket from our backlog,
-
25:08
and we sat there, and none of the other interns asked questions.
-
25:15
They assumed, but he was like, "I remember this thing we talked about.
-
25:19
Can you remind me?"
-
25:21
Or "I have this opinion on this. What are your thoughts?"
-
25:23
And taking that time and saying, "I know you're new to this.
-
25:28
Let's talk about it a little bit."
-
25:30
We also have a place to talk on Fridays.
-
25:33
We have lightning talks, and you can get up there and say, "Hey, this is what I've been working on.
-
25:37
"This is really cool. You should use it.
-
25:39
If you have any questions..."
-
25:41
We also do code reviews, and that's where you say, "Hey, that, no."
-
25:44
And kind of stop it there, but often you have to be pretty vigilant about that
-
25:50
because weird style things will kind of start shipping
-
25:53
if you're not watching.
-
25:56
Just sitting here I want to create a GEM that's called Kill Switch or something
-
26:00
and monitor the CSS.
-
26:04
Maybe something already exists.
-
26:06
Like a pre-commit hook you mean.
-
26:08
And I was thinking even if it got—pre-commit or if somebody is trying to deploy it
-
26:15
to the staging environment and a new file got added into your CSS folder,
-
26:19
be like, "Nope, fails.
-
26:21
You can't deploy that."
-
26:23
It breaks the build.
-
26:25
You sit in the chair of shame.
-
26:27
Yeah, like why did you add a new file, or why did you do this?
-
26:29
You have to be really vigilant about it.
-
26:33
I think the key thing is always—the way I figure it out is I'm like how can I trick them
-
26:40
into not seeing that I might be giving them more work?
-
26:43
How can I give them less work?
-
26:46
Right, it's a little more work now to learn something new.
-
26:49
So it's like trying to make that value proposition
-
26:53
in an effective way.
-
26:55
[male speaker] You give them ownership.
-
26:57
Yes, giving ownership is a very good tip that we got from here.
-
26:59
[male speaker] There is 1 last question.
-
27:01
Can one of you complain about the verbose at include syntax in SCSS?
-
27:07
The what>>The verbose what?
-
27:09
[male speaker] At include syntax for SCSS?
-
27:11
You mean because there's quotation marks?
-
27:13
[male speaker] That's not a question.
-
27:15
That was a request.
-
27:17
Why don't you complain about it? You complain about it.
-
27:19
[male speaker] Chris, I'm complaining.
-
27:21
You're supposed to register a complaint.
-
27:23
Chris asked that question to troll me, because I'm always complaining about the at include in SCSS
-
27:29
because it's really long.
-
27:31
[female speaker] It is really long.>>[male speaker] I'm not a minimalist.
-
27:33
I know everybody thinks that, but it's a lot, this whole thing.
-
27:36
Are you just doing word include?
-
27:38
Just make an alias for at inc or something and make it happen.
-
27:40
Pull request, come on.
-
27:42
Okay, fine. I'm the only one who is annoyed by it.
-
27:47
The original syntax had the + sign, has the + sign,
-
27:53
and you can also use at include.
-
27:56
The question has long been will you bring a short-hand syntax
-
27:59
to the CSS syntax?
-
28:01
And maybe we can ask Nathan why that's hard.
-
28:04
[male speaker] That is actually a fantastic segue.
-
28:06
Into what's happening next.
-
28:09
So Nathan is coming up for question and answer.
-
28:14
[applause]
-
28:21
Is our job here done?
-
28:23
So we now have a panel with panelists plus Nathan.
-
28:26
[male speaker] Who has questions for panelists plus Nathan?
-
28:28
We could just stay.
-
28:31
Somebody get this man a chair.
-
28:33
This is rude. We're so rude right now.
-
28:36
[male speaker] Nathan, the first question is what about that verbose
-
28:40
at include syntax in SCSS?
-
28:44
Even if you take for granted—is my mic working?
-
28:49
I don't know. I don't know anything.
-
28:52
Turn it off and on. Is it plugged in?
-
29:02
Oh, there we go. Cool.
-
29:04
So even if you take for granted
-
29:09
that you want a shorter at include syntax in SCSS,
-
29:14
which there are positives and negatives of,
-
29:17
you probably want to do something that people are familiar with.
-
29:21
You want it to be similar to some degree
-
29:25
to the indented syntax plus syntax.
-
29:31
But in addition to that,
-
29:34
the people who have been most excited about this
-
29:37
have also been pushing for a way to make the shorter syntax
-
29:45
look more like a property.
-
29:48
They want to be able to do something like plus the name of the mix-in,
-
29:53
colon, the arguments, either space separated or comma separated,
-
30:00
which would look cool.
-
30:02
It's nice to have syntaxes that feel similar to other syntaxes you're used to using.
-
30:08
The biggest problem with that
-
30:11
is that it creates an edge case where there's an ambiguity.
-
30:19
As you know, in Sass you can nest selectors,
-
30:22
and also in CSS you can use plus
-
30:26
as a way to combine selectors to do adjacency relationships.
-
30:34
And also, when you have mix-ins
-
30:40
you can pass content blocks to them,
-
30:46
which you can then reference using at content.
-
30:49
What all of this means is that if you write
-
30:52
plus and then the name of the mix-in
-
30:55
and then a colon and then an argument,
-
30:59
which is also an identifier, all of this without any spaces,
-
31:02
and then an open bracket, there's no way for Sass to tell
-
31:06
if that is supposed to be a selector or an invocation of a mix-in,
-
31:12
and that sort of ambiguity is very, very bad.
-
31:17
That's the major stumbling block.
-
31:21
I have been thinking more about this lately,
-
31:23
and I don't think that's fatal.
-
31:27
I think since people are unlikely to want to
-
31:32
invoke a mix-in without putting a space after the colon
-
31:43
I think it might be good enough
-
31:47
to say you have to have a space after the colon
-
31:50
when you're invoking a mix-in in this way.
-
31:52
And if you don't, we're going to treat it as a selector.
-
31:57
That might be coming in an upcoming version.
-
32:02
I have a question for you.>>Sure.
-
32:04
What is your Sass pet peeve?
-
32:06
My Sass pet peeve.
-
32:08
The thing that you want to fix.>>In the language?
-
32:10
This is Chris's question. What's your pet peeve?
-
32:14
I get to fix a lot of the things that bug me.
-
32:18
Yeah, what's the one that is driving you crazy right now?
-
32:20
Right now the thing that bothers me the most
-
32:24
is how primitive
-
32:29
the way you include other files is,
-
32:35
like it's literally just a text include.
-
32:39
You take the other file and drop it in your file,
-
32:42
and this has several awkward consequences.
-
32:47
It means that if some Sass file
-
32:51
somewhere way off in your dependencies
-
32:53
includes something, you have everything that that file defines no matter what.
-
32:58
You have no say about it.
-
33:00
You get its mix-ins, you get its top-level variables,
-
33:02
and that's awful.
-
33:05
It also means that there's no way for you to take
-
33:13
a file that you want to include
-
33:15
and only use some of the things from it in your file.
-
33:21
One thing that we've always sort of—
-
33:25
since we added extend that we've wanted to be able to support
-
33:30
is taking a file that someone created
-
33:36
as a way to style stuff.
-
33:40
Even maybe a plain CSS file and being able to
-
33:43
extend the stuff you care about
-
33:45
but not the stuff you don't, so similar to the way placeholder selectors work
-
33:49
but using a file or a library that wasn't defined—
-
33:54
that wasn't written with placeholder selectors in mind.
-
33:57
It's almost like an inactive vaccine kind of thing.
-
34:02
Yeah, exactly, so the way include works right now
-
34:07
doesn't allow any of that.
-
34:09
It doesn't allow any sort of name spacing either,
-
34:13
and that's something that Chris and I are going to be working really hard on
-
34:17
in upcoming releases.
-
34:20
Our grand plan for Sass 4.0 is to have a completely revamped
-
34:25
module inclusion system which will have all of these features and more.
-
34:29
It also will allow you to load a .CSS file.
-
34:34
It will not be named at include,
-
34:37
so it won't have this incredibly awkward conflict
-
34:41
with an existing thing in CSS that we have to maintain compatibility with.
-
34:45
That will be great.
-
34:49
[female speaker] Questions from the audience?
-
34:52
There's a question. I think it's Mike.
-
35:02
Hi, I was curious what keeps globbing statements
-
35:07
out of import statements in standard Sass.
-
35:11
This is something we get asked about a lot.
-
35:16
The biggest concern is that the way
-
35:24
globbing works is inherently unstable
-
35:29
with respect to the order of the files that get imported.
-
35:32
It means that you can impose some stability there.
-
35:37
You can say, "All right, we're going to order them alphabetically."
-
35:40
But it's arbitrary, and what's more important is it's not based
-
35:46
on something that the user has an understanding
-
35:56
of affecting the way their CSS comes out.
-
36:00
And one thing that's a little bit awkward about CSS
-
36:04
is it's a language where order matters.
-
36:06
And often order matters in very subtle but meaningful ways,
-
36:12
so if you have 2 arbitrary CSS rules, and you flip their order,
-
36:18
it's possible that will make some part of your site
-
36:23
that rarely gets looked at completely unusable.
-
36:29
The way this relates to globbing
-
36:31
is that if we allow globbing what that means is that if someone renames their file
-
36:37
something that you should feel safe doing
-
36:45
it could change the styling of your website
-
36:49
in subtle and hard to detect ways,
-
36:52
and that's something we are extremely worried about.
-
36:56
We are professional developers. You can trust us.
-
36:59
[laughter] Just trust us, Nathan.
-
37:02
The people in this room
-
37:05
I can absolutely trust, but unfortunately,
-
37:08
I don't want the people in this room to be the only people who use Sass.
-
37:12
[male speaker] Can you put in a secret turn off the safe mode switch?
-
37:15
Yeah, there's a Sass globbing package
-
37:19
that you can get, and it's a plugin,
-
37:21
and people use that,
-
37:23
and you're welcome to do so.
-
37:27
But then I can't get into Libsass.
-
37:34
It's important—I'm a big believer in the idea of many small experiences
-
37:43
combining to give a larger impression.
-
37:45
It's important to me to minimize as much as possible
-
37:49
the number of small ways that Sass can make you feel like you're doing something
-
37:55
that might not be safe.
-
37:59
Even if only 10% of the developers
-
38:03
and each have 1 time where the ordering of the files being loaded
-
38:09
causes them confusion and pain
-
38:13
and makes their site break in a way they don't understand,
-
38:16
that adds up on top of additional confusion
-
38:21
that's built into learning a new language
-
38:23
or to ways that we have to interact with CSS
-
38:27
to make things work.
-
38:30
And eventually that can hit a critical mass
-
38:34
that causes people to become upset with the language,
-
38:37
and that is the point we don't want people to reach.
-
38:41
[applause]
-
38:48
[female speaker] In the back.
-
39:07
Just back to the question we had before about Sass and CSS, SCSS.
-
39:13
I don't know a lot of people using SCSS.
-
39:16
I love Sass for a lot of reasons.
-
39:18
I was wondering, do a quick poll, who is using Sass?
-
39:22
Raise your hands.
-
39:25
And SCSS? Okay.
-
39:27
That's very interesting, because out of all the people I know in Europe
-
39:32
mostly they are using Sass for a very long time,
-
39:35
and if you're working on a big team
-
39:38
and you're a really experienced front-end developer
-
39:41
and having no key issues with that
-
39:44
or having a standard syntax helps a lot.
-
39:49
But I know for us particularly we use SCSS only and other reasons.
-
39:55
Quite interesting. Thank you.
-
40:00
Another question?
-
40:02
I'm actually surprised by how few of us in here are using the Sass to text.
-
40:06
[male speaker] That's the beauty of it. I don't even know—
-
40:13
Oh, no. Save the laptop.
-
40:18
That is the—I want to be straight-up honest.
-
40:21
I don't even know the difference.
-
40:23
I don't know the difference.
-
40:25
[female speaker] You're about to get educated right now.
-
40:28
Dot SCSS.
-
40:30
SCSS is white space.
-
40:32
And whatever I'm using, which I guess is Sass.
-
40:34
Does it look like CSS? Does it have curly brackets?
-
40:38
Okay, yes.
-
40:40
Curly brackets. I use curly brackets.
-
40:42
The .sass is the kind that's very white space dependent.
-
40:49
It would look like Haml.
-
40:52
Where did that come from?
-
40:54
Where did the non brackets come from?
-
41:01
That was the original, no?
-
41:03
It was the only one for a very long time.
-
41:05
[male speaker] I'm late to the game but the beauty is—
-
41:08
Could I jump in here? I have an opinion on this.
-
41:14
I've been using Sass since the beginning,
-
41:18
and I was originally a very, very rabid original syntax kind of user,
-
41:23
so I can very much identify with you as well.
-
41:26
But I feel like it's important not to under emphasize the value of the SCSS syntax as well
-
41:32
from an evangelism perspective.
-
41:34
As soon as we added that,
-
41:37
there was a whole new openness in the CSS community
-
41:41
to try Sass, so I don't know if we're ever going to end up with one syntax versus the other—
-
41:49
You want to talk?
-
41:51
One syntax versus the other, but it's huge on the evangelism side.
-
41:55
The other thing that I would add—
-
42:00
I've written an article about this on The Sass Way you can check out.
-
42:06
I'm comparing the differences between the 2 syntaxes and the value there.
-
42:11
I would say the big thing for me
-
42:13
is that using a more free-form syntax like CSS,
-
42:17
particularly once you get away from the nesting,
-
42:19
is a lot more fun, expressive.
-
42:23
There's times when being forced into that rigid indentation-oriented things,
-
42:32
your CSS files span tons of lines,
-
42:36
and I find myself often really pleased
-
42:39
to collapse all the hover state of an item on 1 line
-
42:44
if it's just changing a color or something like that.
-
42:48
I don't know. There's value on both sides.
-
42:51
[female speaker] I don't mean to interrupt.
-
42:53
We don't have the auditorium for much longer,
-
42:55
and it's a very rare treat to have Nathan on stage.
-
42:58
Do we have more questions for Nathan?
-
43:01
We can continue this debate upstairs too.
-
43:10
Is it on? Yeah.
-
43:12
This is a small one, but I was wondering if you could tell us your thoughts on generating an error
-
43:17
in a style sheet in case the person is calling a mix-in or something in a way that totally won't work
-
43:22
and will not do what they want and the warning is not really enough.
-
43:26
I think we have an at error directive now.
-
43:28
Have we not added that yet?
-
43:30
No? We should add that.
-
43:34
The only thing I could think of was to call a mix-in that definitely does not exist to make the error.
-
43:40
It's one of those issues that have been filed for a while,
-
43:44
and it's one of those we definitely want to do this,
-
43:46
but there are a lot of issues we definitely want to do.
-
43:49
It's a getting around to it question.
-
43:54
Patches welcome.
-
43:58
Rob, you want to go ahead?
-
44:04
One of the big benefits of Compass
-
44:08
is that you can dip into the Ruby layer and expose new functions to Sass.
-
44:12
What are the plans for making a parallel system
-
44:17
with Libsass?
-
44:20
Is this something I should ask you or I should ask—
-
44:22
It's definitely a Hampton question.
-
44:24
That's a Hampton question. Okay, pass it on.
-
44:26
[female speaker] Scott, do you have a question?
-
44:29
I was wondering if you had any guesses as to how many jelly beans you've got?
-
44:35
[female speaker] If he guesses in a range, does he get more jelly beans?
-
44:39
Is this like Price is Right?
-
44:42
This is like high school math.
-
44:44
How many jelly beans are in the jar?
-
44:48
I'm the worst at estimating, so I'm going to say somewhere between
-
44:51
10 and a million.
-
44:54
Safe bet.>>Sounds good to me.
-
44:56
Any more hands?
-
45:00
Oh, mic. Hold on.
-
45:05
Hi, how are you doing?
-
45:07
[male speaker] Is there ever a possibility of getting dynamic imports?
-
45:13
It's pretty unlikely.
-
45:15
The way—sorry?
-
45:21
Being able to say import and then interpolating a variable into the import.
-
45:28
That would be rad, though.
-
45:30
It would be amazing.
-
45:35
It's not impossible.
-
45:37
But it would require a lot of strain on the order we do our parsing and resolution,
-
45:45
and like many instances of adding the ability to do things more dynamically,
-
45:53
it would require a pretty convincing use case
-
45:56
for us to start pushing that far.
-
46:03
Theming and IE support.
-
46:07
Say more.
-
46:09
Oh, now I'm on the spot.
-
46:11
Kind of back to the client theming stuff I was doing earlier.
-
46:15
I can see a case for that in what I do
-
46:19
where some clients only want certain parts of things,
-
46:23
and I want to import these style sheets and then also this style sheet
-
46:31
with this client variable in it.
-
46:33
I am totally on the spot right now.
-
46:35
I have to think about this a little bit in more detail.
-
46:37
I don't know, can you do this like import blank, like kind of Ruby-esque?
-
46:42
Import blah if blah or unless blah?
-
46:45
No, no.
-
46:48
Yeah, but I can see a way that I would use that.
-
46:52
Here's something that is more likely to happen
-
47:00
that gets you I think part of the way to doing what you want.
-
47:03
In our fancy new world of exceptionally powerful and awesome imports,
-
47:10
we may have the ability to do something like, say,
-
47:17
do an import but wrap it in a mix-in.
-
47:22
I think it's important for a lot of the infrastructure
-
47:27
around how Sass compilation works
-
47:30
that the set of all files that might be touched
-
47:35
when you do a compilation can be known without running the compilation itself.
-
47:39
But if you have enough information to say,
-
47:45
"Here are the files that I'm going to import,
-
47:48
but the way I use those imports may vary,"
-
47:53
and this could also potentially be done with putting them in an if,
-
47:56
but I think being able to have the single way of saying
-
48:00
wrap it in a mix-in and then be able to use the existing ways
-
48:12
of dynamically dealing with mix-ins, and we'll probably also move to being able to interpolate
-
48:19
when you do an include in the mix-in name,
-
48:22
so that will also help if you want to have a variable that's the name of your theme or something like that.
-
48:28
That would be awesome.
-
48:30
I have 1 question.
-
48:32
[female speaker] Yes, go ahead.
-
48:34
What is the best or most preferred way
-
48:36
for us as developers to contribute back to Compass and Sass?
-
48:42
Pull requests on GitHub.
-
48:44
Unfortunately, there are 6 or 7 that are sitting there
-
48:49
and have been sitting there for quite a while.
-
48:51
Chris and I both have a limited amount of time
-
48:54
that we can devote to Sass and Compass,
-
48:58
and my next priority now that we've gotten the ball rolling
-
49:05
on 3.3 in earnest, once that is out,
-
49:09
my next priority is to clear out those pull request queues and hopefully be more on top of them in the future.
-
49:16
Are you looking for other maintainers?
-
49:18
Or how would that go?
-
49:21
That's something that I would hope would evolve
-
49:25
from consistent pull requests over time
-
49:28
and becoming confident that someone making these pull requests understands the style
-
49:36
and what needs to happen with a new feature,
-
49:38
because there's this whole checklist of things that need to be done.
-
49:42
We need to add a new element of syntax.
-
49:44
You have to add it and add tests,
-
49:47
make sure that Sass convert works properly with it, etc.
-
49:51
And these are things that for individual pull requests
-
49:56
we're happy to shepherd people through that process.
-
50:00
Is there documentation on what it is that you check?
-
50:03
Documentation?
-
50:05
What's your hate of documentation?
-
50:07
I'm not hating, I'm just skeptical that it exists.
-
50:09
I think there is a contributing file, but I think it's very old.
-
50:13
But that's something I would like to exist.
-
50:18
Again, definitely want it, but haven't gotten around to it.
-
50:21
Just because my co-worker did want to contribute,
-
50:24
and if we can make it easier to get certain things fixed
-
50:28
or contributed—maybe other people out there want to help as well.
-
50:31
Having—
-
50:33
[male speaker] Compass needs more help.
-
50:35
That's actually true.
-
50:37
I think if—>>Is there a punch list somewhere of—
-
50:40
Yeah, if we can help with this is what we need to make sure—
-
50:43
I'm not an expert at this, but that's why I brought the question up.
-
50:47
[female speaker] We have time for 1 more question.
-
50:59
What's limiting current compilation speed in the Ruby version of Sass?
-
51:06
I'm not a performance expert.
-
51:09
Take what I'm saying with a grain of salt.
-
51:13
But we've at various times made pushes to make it faster,
-
51:19
and usually what that's ended up doing is running some profiling on it
-
51:25
when compiling large files and seeing what the bottlenecks are,
-
51:31
and usually there's been some major bottleneck.
-
51:36
At one point it was parsing static properties
-
51:39
that don't have any variables in them, and then we found a way to speed that up.
-
51:43
Or at one point it was reparsing files that you—
-
51:49
imported files that you'd already parsed before in a previous compile,
-
51:51
and then we added caching and sped that up.
-
51:55
For the last several versions when we've run the profiling
-
51:58
all we've seen is that the time it's taking is spread very evenly across all parts of the project,
-
52:08
which is exactly what we don't want to see,
-
52:10
because that means there's no place we can target
-
52:13
to say, "All right, if we do this one thing
-
52:15
it will get a lot faster."
-
52:17
There may be room for additional caching
-
52:21
at a further level.
-
52:23
I was talking with someone about this last night.
-
52:27
That's probably the most fruitful way to look,
-
52:29
but I think the time it takes to do a first-time compile right now
-
52:35
may be limited by the speed of Ruby and the string processing we need to do.
-
52:43
Okay, so that closes our panel
-
52:46
and the last talk of Sass comp.
-
52:49
A round of applause.
-
52:51
[applause]
You need to sign up for Treehouse in order to download course files.
Sign up