[Custom Framework/Style Guide Panel] [John Athayde, Elyse Holladay, Rachel Ober and Pam Selle]

[Special Guest Nathan Weizbaum]

Can I ask a quick—because I have the mic.

Are designers ever part of your teams?

I'm the head of the team.

I'm the head UX guy and the head front-end guy,

but I'm definitely more a UX person than a front-end person

as far as my life experience.

And then I have 1 other pure UX design person

and 2½ other pure front-end people.

But it's funny, because when you have that small of a condensed team,

a lot of the front-end guys are saying, "Hey, I kind of mocked this up in code,"

and the designer will definitely come more from the Photoshop or Balsamic approach

to how he mocks things up, but there's a lot less of this

I have made the artifact, I pinned it up on the wall,

and I walked away, which I think larger design organizations,

even in companies, will do that kind of here we are, we are done,

and we are handing it over, and you have people chucking bags over the transom at each other,

so I think the benefit for us is it's 100% integrated.

Yeah, at Paperless we're slowly fixing that.

As we were talking about throwing things over the fence,

and it's like we're not Waterfull, but we kind of are

where we have somebody who puts the UX together,

then after that UX is finalized somebody then does high fidelity mockups,

and then maybe at that point I will see it,

or it goes to a Rails developer, they build it out,

and then they're like, "Hi, Rachel, fix this."

Sometime with—main markup.

On Wednesday we are going to attempt for the first time ever

to have a designer sit with me

and other members of the front-end team

to do design in browser and pair design programming.

I'm not exactly sure what the appropriate terms are.

Yes, thank you.

I will report back, and I'm interested to see how that goes,

because our UX and designers I think are probably really scared of HTML and CSS.

They probably don't even know Sass really.

But it will be a learning experience for all of us,

and we really hope that will break that cycle.

I don't really have a large team at all.

I have me, and I hired another girl to help me,

and then there's a UX designer, and he's not in the code at all.

But we have had so much improvement

in the way some of our new features have been coming out

when him and I sit down and have this conversation.

We're working on some mobile stuff right now,

and so he was doing wires for it, because we do have to show our client and get some approval,

but we sat down and talked about it first,

and we're doing it together, and the first round of wires he did without me,

and then we sat down and talked about it, and the second one was miles better.

It was so good, so I'm sure you all will have really good luck with that.

I hope so.

[female speaker] Rachel, how did that process change?

How did you get to the point where this is going to happen on Wednesday, like internally?

Well, the starting point was attending Sass Meetup a couple weeks ago in New York City.

Did you know this already?>>Did I?

No, she had asked the question there,

so I was like, "Oh, my goodness, they're actually doing it,"

so I was thrilled to find out how you got to—

So I think I was originally interested

because the talk that night was going to be talking about maybe mobile—

[female speaker] Responsive web design I think was the one.

Yeah, and I dragged along a co-worker

who was also passionate about not having stuff thrown over fences,

and we were like, "Okay, this responsive thing is good,

"but how do we actually get this into our workflow,

"because there's no way the way it currently is

"that people are putting stuff in stone,

"and if it trickles down all the way even after development happens

and then I'm given this thing and saying, 'Well, it doesn't look exactly right, can you fix it?'"

There's no way then for me to take that

and actually create some type of responsive design

because I would have to rewind all the way back

to try to implement that.

You should have built a time machine.

That should have been there.>>I know, that's my problem.

I keep getting told the time machine.

But I went to the meetup, and we're so frustrated.

How do we start change at our organization?

And Sam was like, "Sit that designer next to you

and just do it," and that was already probably over a month ago,

and we're finally doing it on Wednesday.

It takes time, and you have to convince people,

and one of our biggest issues I think

is changing behavior of the other people there.

People can get really excited,

but there's a lot of doubt that goes into, "Oh, my gosh, now I have to sit with somebody?

I picked a design job so I wouldn't have to talk to anybody."

[female speaker] I thought that was developers.

Same with developers.

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,

because I think some people pick certain positions

so they can enjoy their world,

and I've noticed this change where it's like you can't hand stuff off anymore

in the environment that we're in.

Yeah, I think the lines are blurring a lot.

Yeah, it's like I'm moving into more designy things

and also still on the development, and it's like we can't have silos anymore.

Even as a developer, if you are responsible for the logic

that happens behind the interaction,

then you also are a stakeholder in how the interaction—

Those are your choices. Those are choices for your users, and you have to be aware of that.

Exactly, so you have to be at least aware,

at least marginally involved, but I think there's also 2 things.

The caution to back up is there's the line between let's get involved

and let's have lots of opinions.

But it's about respecting other people's expertise,

so I think when you come to people—

and that's the success I've had with working with designers

is I start up sentences with, "Well, given your expertise,"

in a very "You are the most excellent designer I've ever met" sentence.

But that puts people into a better place

because it's not you telling them what to do.

It's you saying I understand that you understand this world,

and I'd really like to understand it too so I can do my job better,

and then we can both be better at our jobs.

And if you're a developer side,

even if you're the Hampton where I don't know art at all,

I love art but I can't do art kind of thing,

it doesn't mean you shouldn't have an eye or develop an eye

to be able to say, "This feels wrong."

Learn to speak the language.>>Yeah, learn to speak the language.

And design is not just about "the pretty."

It is about how it works, the famous Steve Jobs quote.

And there's accessibility.

There's all kinds of factors and interaction that you don't have to be a brilliant artist to understand.

If you say, "That's the designer's problem," you're not doing your job.

I'm really fascinated by this concept.

I've been thinking about this for a couple years.

What are the UX things that developers can do?

And not even necessarily front-end devs but back-end devs.

What are those choices?

How can you instill that way of thinking

into somebody who doesn't have UX experience?

I would love to talk about that post panel.

Flow, flow, flow and flow,

because those database decisions reflect all the way up.

Yes, but getting a basic reading on information design in general—

like so many developers are interested in this topic,

I know have been to the Edward Tufte course,

and that's the basic core of here's information design.

Let's talk about charts, ya'll,

and why we all hate PowerPoint.

Not why PowerPoint is bad but why people hate it.

There's reasons.>>And why do people abuse it.

Yeah, they abuse it, but there is a place for it,

but understanding the why and not just implementation.

I think there's a few audience questions hanging out.

[male speaker] First, to affirm that, I think no matter where we work

or what we do, always encourage designer-developer partnerships and relationships.

That's awesome, so that's something I wanted to affirm.

I want to go back a few about frameworks.

I had a quick opinion.

I think what you said about your team

making your custom framework and then you only have 1 new design a quarter,

that's awesome, but for people here who are new

or who are figuring things out, frameworks are genius,

because you can jump into something,

you can have something out in a day,

and you can learn a lot from the code in the framework.

I actually learned most of my web development

2½ years ago jumping into Bootstrap

just to see what the heck is going on.

I think if you're doing a hack or you're doing an internal thing

or your client doesn't care what it looks like, Bootstrap, boom.

Done. It's internal.

You got paid for it. You launched it.

It's genius.

But if you're going to put something out in the world

and you want our peers to see it and respect it

and you want to be respected, Bootstrap is probably not your best choice.

But somebody said they set a standard, which is a style guide standard almost,

all these little elements that you see.

But my continued opinion is that Foundation is so good

because it does allow you to roll your own in a quick way.

I wanted to say this: they're not always good, and they're not always bad.

I think it depends on your use case.

Yeah, when I teach at MakerSquare they're learning Rails,

and so they don't get a lot of front-end stuff,

and so when I talk to them they ask me the same question, every single class.

They're like, "What about Bootstrap or Foundation?

What's your opinion on the frameworks?"

Pick the right tool for the job.

And I think that's what you were getting at.

Am I a developer trying to put out a plugin,

or am I trying to learn, like do I want to hack on this stuff for myself?

Am I trying to make my mom's cousin's friend a thing that I want to learn on?

Or you need to pay your rent.

My husband got $200-$300

from redesigning a website for his flight instructor.

He's like, "Oh, my God, this is the best thing ever!"

It was just done in Bootstrap.

I looked at it, and I'm like, "It's Bootstrap."

But to other people that are not—

There's a bigger point to that of sometimes when we get very naval gazing about these things

we forget that for many people

the Internet is Google.

Or Facebook.

The page is the Internet.

A small percentage of people know Bootstrap.

And one distinction I like to make is that internal

doesn't necessarily mean easier.

It doesn't necessarily mean that you can pass it off,

because for Living Social, for example,

internal users are 4,000 people.

And so very small productivity gains actually affect the bottom line.

Now, if you have 10 people and 2 of them are actually doing your production work

and using your admin system, that's ludicrous.

Don't spend 4 weeks making a beautiful item.

That's what I was referring to.

Yeah, it depends, of course.

[male speaker] I think it's also important to remember with that

the whole issue of frameworks versus rolling your own—hi.

I was like where is this voice coming from?

[male speaker] It's not an on/off switch.

It's not one or the other.

You can use a lot of other people's code

rolling your own, and it's a whole continuum.

There's a lot of modular plugins that you can build your own framework

using entirely someone else's code.

It's not yes or no, I will either write it all internally or—

The most basic of frameworks is normalized.

When I show the students I teach at MakerSquare Sass stuff they're like,

"How do you learn to write all these CSS3 mix-ins with the gradient?"

I'm like, "I did not write that."

You've got to be kidding me. Nobody writes that.

It's already been done.

We just copy the same line over and over again.

Yeah, that guy.

[female speaker] That segues into a question that did come in as well.

Do you use many pre-made components in your own frameworks?

And if so, what ones do you use and like?

Pre-made components.

Like do you take Twitter, Bootstrap, JavaScript thing or do you take—

I'm inspired by techniques a lot.

If I see how—like I still remember last year Eventbrite got a new Facebook button,

and I was like, "Check out that button,"

and it was well commented.

It had all the fallbacks with the comments of why they were there,

and I copied it, and I was like, "This is how I'm going to build my next Facebook button."

Not the exact same thing, but learning the lesson from how they did it.

And I think, again, back to CSS3 mix-ins,

they have been done.

They have been done and tested.

You can actually literally pull those entire things,

and for me the grid stuff I did was some combination of Dave Rupert's Foldy960

and some other media query stuff,

and then Chris's grid for loop thing,

and I was sending him chats like, "Help me!

I don't know how this works!"

But it's cool. I didn't have to write that.

I didn't have to go figure out how to do all that.

It was much easier, and it did exactly what I wanted without being a whole entire framework,

so pulling all those little bits and pieces

from the places that are inspiring to you or relevant to you.

And you made a perfect point.

It's not binary.

I don't know what it's about, but I think it's about 20% of Wild is Bootstrap derived.

We actually are using the Bootstrap buttons file,

and then we did a whole bunch of tweaks for different kinds of buttons,

different sizes.

Wild is the internal app?>>This is the internal, yeah.

I'm sorry, Wild is our internal GEM that does our style guide.

And we use a lot of the standard jQuery, Accordion, and stuff like that,

and then we tweak it, so they've figured out how to make this work.

I'm going to pull these pieces in.

Don't reinvent the wheel.>>Right.

And for us we pulled a couple things from Bourbon, things like that,

and I think if you're doing this from scratch the first time

and you really want to roll your own,

pulling pieces to build it and then being able to modularly say,

"This doesn't work well anymore.

Let me now roll my own, or hey, this one over here is really cool."

Just as an aside, I think for the newer people

there is some value in learning how to write these mix-ins

or learning how to do this stuff.

But you don't necessarily have to go to the depths

of having it be production ready,

like CSS3 gradient mix-in, all by your lonesome.

That's already been done, but you can go in CodePen

and edit it and play with it and see how it works,

and you can go and play with extends and play with mix-ins

and understand how the bits and pieces that you're pulling from other places are being created,

even if you couldn't necessarily write all that yourself.

And if you're new into the Sass world,

one thing that's helped me a lot is taking, say,

a button file or one of these old CSS files

that is not dynamic and saying, "I'm going to port this to SCSS."

I want to do a little audience participation.

How many of you are fairly new, within the last year or so, to Sass?

Nice, that's awesome.

And you're loving it, right?

You're here.

Any haters?

[female speaker] Speaking about haters, here's one for each of you,

and then maybe the audience will also participate.

Speaking of haters, here's a question.

Sorry. We could.

I wanted an individual hater.

What are your biggest pet peeves about Sass and/or Compass?

Important note.

Who did this question come from?

I can't—>>It's on Twitter, come on.

My biggest pet peeve was the Compass grid system,

and that's now gone.

Nesting.

Nesting and the old syntax.

See, I'm going to have to disagree with you, because nesting can be awesome.

It's not the fault of nesting that people abuse it

just like it's not float's fault that we horribly screw them up and use them for layout.

That's fair, but then I qualified with also the old syntax

because the way the old syntax—being white-space dependent

I feel like when people wrote it in that syntax

it highly encouraged nesting,

because one of the things I told people when I was like, "Stop using the old syntax"

is that you're allowed to indent things because it's not white space,

for like an SCSS, so if you want, if you really, really desperately want

something to be indented beneath something else,

you can have it, and you don't have to generate 7 levels deep selectors because of it.

I'll admit I use the bad syntax, and I like it.

Also, it encourages descendent selectors and not first child selectors,

or not direct child selectors.

I'm like my—

But I think that's an evolution.

I think people start off with Sass—or at least when I started with Sass,

it was replicate the DOM, and I was using the new syntax.

I was like replicate the DOM, this is amazing.

And of course I was setting it up because I will add styles there,

and now it's much more of I'm only going to write the styles I need

and then refactor and refactor and refactor.

I'm with you on the indentation thing.

That's how I think I and probably a lot of people used to visually format

their CSS files to indent stuff under the parent.

Not nesting but indenting to visually organize.

But I actually like the .sass syntax.

I don't know, I use it.

I like the indent syntax.

They're all getting pulled from my code base.

I think honestly it's not really different.

This is one of the things when I first started that I also hate about it

because I feel there's also—and I JavaScript a lot,

and I'm not on Team CoffeeScript, because I also do think that there is a benefit that you get

when you're close to what you get.

So context switching basically.

Staying close to what your output is,

because if someone who already hated writing CSS—

they're like, "Awesome, I hate writing CSS.

Now I can write Sass, and nothing looks like CSS anymore,"

and then they're debugging in the browser because that's where we make things.

It doesn't get you out of it.

You still have to look at it in the browser,

and then you don't understand the CSS anymore because you had the context switch,

and you can't read it anymore.

The way that I use the nesting—

I was talking to somebody about this yesterday—

is name spacing modules,

because then we can reuse classes,

and we have so many different things, and so I'll have the parent module,

and I think John was showing this in his talk too.

You have the name of your module and then the sub stuff,

and so then you can use state classes, is active, is hidden, whatever,

inside of a module without them being global.

It's cool.

I thought you were talking about the left side bar

and the header in the left side bar and then this band inside.

If I was talking about that, I should be forcibly ejected from this venue.

No, but I think nesting, it's not evil all by itself,

and I think that Sass is the same way.

You have to be very aware of what you're writing.

You have to look at your output, and if you're not,

then you are doing it wrong, and your CSS too,

your output that is CSS should be close to the CSS that you would have written.

And I don't mind doing that extra step.

I think as an author I much prefer the Sass syntax.

I like the way it is. I like the way it looks.

I find it easier to read. I like to write it.

But I still look at my output file.

And that's like for me.

I have a friend, and I really like the way he said this.

He said this the other day.

He said, "All glory to the build system."

You should do whatever you want, and all glory to the build system.

As long as you can work that way

and your team works that way, awesome.

I have a very strong opinion in how I work that way,

and I was like no deal, because I really like CSS,

and so I'm in a CSS world, and I like staying close to that.

And up until 3 or 4 months ago,

my team was me, so that made it very, very easy to control.

And now you have to dictate everything to the minions.

One thing developers often do is they say, "Oh, I don't like the way CSS looks,

or ERB looks," or things like that, and instead of saying—

they just switch to something like Haml or Slim or LESS or Sass.

And instead of refactoring and learning

how to do good typographic refactoring and write good HTML and CSS in the first part—

Yeah, because you probably don't like HTML because you're writing too much of it.

Right, and I have this problem.

I don't know if he's laughing because I've ripped on Haml,

but I've ripped on Haml a lot in my day,

but it's not Haml that's the problem.

It's that people sit there and say, "ERB is ugly, and therefore, Haml solves that problem,"

and maybe ERB is not the problem.

You can still write terrible code with Haml.

You can write awful CSS or Sass or SCSS or whatever.

You are the author. You have the responsibility.

Sass is going to fix that for you.

And so many of these tools you see if the team is really efficient

you get a massive multiplier.

My co-author, Bruce Williams, they use a bunch of Haml

in the stuff they're building for the merchant side, and they're really fast with it.

But they know how to write good HTML in the first place,

so for them it's just a force multiplier.

It's not a, "Oh, it's not ugly anymore."

It's a "I can just write faster," or the great example you had in your talk yesterday

where you can look down it and immediately, boom, I internalize the document structure.

I want to go back to the original question,

and I talked about this a little bit earlier,

and this is probably a thing—>>What was the original question?

The haters hate.>>Haters are going to hate.

What are your pet peeves in Sass and/or Compass?

And we talked about this earlier about the theming variable thing.

I really, really would love to have my client variables

and then be like image URL, client variable,

and then whatever client name, and whichever client it is,

then it will inject that for me, and that's probably not a thing that's going to happen.

So maybe—>>Or maybe I don't know how to do it.

This has to be more complicated than I'm thinking,

because could you set a variable that is the asset path for whatever

and then at compile you change those variables?

We do something like that.

There's a paths file in Wild that basically you can set all of those things up,

because we have 1 instance where we're still in Rails,

and we're pre-asset pipeline, so we have a shell script

that dumps everything out into static—

Rails asset pipeline, the Ruby on Rails.

But your pre-asset pipeline?>>2.3.

In production, so when you have to support all things like that,

we dump everything out statically, but we can actually specify

in there all the paths, so when it prints it all out

it's printing out the proper location for that app.

There may be some things that I'm not understanding.

I think it would work for images, but I want to be able to do stuff like in my style sheets.

If it's this client, do X.

If it's this client, do that.

If it's this client, do this other thing.

And you can't do that dynamically, or at least I could not get any of that to work.

[female speaker] We're going to take 1 more question.

[male speaker] My question is about the frameworks and particularly custom frameworks

that you guys have rolled your own

is I guess what you're saying.

What are some methods of evangelizing and getting other people on your team

to actually use the frameworks?

I've done the same thing where I've developed a framework for my team,

and it's great for rapid prototyping for me

because I spent 6 months building it, so I know exactly how it works,

but how do you make it accessible to other people?

Do you guys do code reviews?

Do you have tutorial sessions and hacks?

What are some methods of getting other people on board?

I'm still doing all those things.

Another cheat is also to volunteer

to indoctrinate your interns whenever you have interns,

because your interns are often hired.

So if you get them first—

The most successful intern I worked with,

he started earlier than all of our other summer interns.

I spent half of the day—I picked a ticket from our backlog,

and we sat there, and none of the other interns asked questions.

They assumed, but he was like, "I remember this thing we talked about.

Can you remind me?"

Or "I have this opinion on this. What are your thoughts?"

And taking that time and saying, "I know you're new to this.

Let's talk about it a little bit."

We also have a place to talk on Fridays.

We have lightning talks, and you can get up there and say, "Hey, this is what I've been working on.

"This is really cool. You should use it.

If you have any questions..."

We also do code reviews, and that's where you say, "Hey, that, no."

And kind of stop it there, but often you have to be pretty vigilant about that

because weird style things will kind of start shipping

if you're not watching.

Just sitting here I want to create a GEM that's called Kill Switch or something

and monitor the CSS.

Maybe something already exists.

Like a pre-commit hook you mean.

And I was thinking even if it got—pre-commit or if somebody is trying to deploy it

to the staging environment and a new file got added into your CSS folder,

be like, "Nope, fails.

You can't deploy that."

It breaks the build.

You sit in the chair of shame.

Yeah, like why did you add a new file, or why did you do this?

You have to be really vigilant about it.

I think the key thing is always—the way I figure it out is I'm like how can I trick them

into not seeing that I might be giving them more work?

How can I give them less work?

Right, it's a little more work now to learn something new.

So it's like trying to make that value proposition

in an effective way.

[male speaker] You give them ownership.

Yes, giving ownership is a very good tip that we got from here.

[male speaker] There is 1 last question.

Can one of you complain about the verbose at include syntax in SCSS?

The what>>The verbose what?

[male speaker] At include syntax for SCSS?

You mean because there's quotation marks?

[male speaker] That's not a question.

That was a request.

Why don't you complain about it? You complain about it.

[male speaker] Chris, I'm complaining.

You're supposed to register a complaint.

Chris asked that question to troll me, because I'm always complaining about the at include in SCSS

because it's really long.

[female speaker] It is really long.>>[male speaker] I'm not a minimalist.

I know everybody thinks that, but it's a lot, this whole thing.

Are you just doing word include?

Just make an alias for at inc or something and make it happen.

Pull request, come on.

Okay, fine. I'm the only one who is annoyed by it.

The original syntax had the + sign, has the + sign,

and you can also use at include.

The question has long been will you bring a short-hand syntax

to the CSS syntax?

And maybe we can ask Nathan why that's hard.

[male speaker] That is actually a fantastic segue.

Into what's happening next.

So Nathan is coming up for question and answer.

[applause]

Is our job here done?

So we now have a panel with panelists plus Nathan.

[male speaker] Who has questions for panelists plus Nathan?

We could just stay.

Somebody get this man a chair.

This is rude. We're so rude right now.

[male speaker] Nathan, the first question is what about that verbose

at include syntax in SCSS?

Even if you take for granted—is my mic working?

I don't know. I don't know anything.

Turn it off and on. Is it plugged in?

Oh, there we go. Cool.

So even if you take for granted

that you want a shorter at include syntax in SCSS,

which there are positives and negatives of,

you probably want to do something that people are familiar with.

You want it to be similar to some degree

to the indented syntax plus syntax.

But in addition to that,

the people who have been most excited about this

have also been pushing for a way to make the shorter syntax

look more like a property.

They want to be able to do something like plus the name of the mix-in,

colon, the arguments, either space separated or comma separated,

which would look cool.

It's nice to have syntaxes that feel similar to other syntaxes you're used to using.

The biggest problem with that

is that it creates an edge case where there's an ambiguity.

As you know, in Sass you can nest selectors,

and also in CSS you can use plus

as a way to combine selectors to do adjacency relationships.

And also, when you have mix-ins

you can pass content blocks to them,

which you can then reference using at content.

What all of this means is that if you write

plus and then the name of the mix-in

and then a colon and then an argument,

which is also an identifier, all of this without any spaces,

and then an open bracket, there's no way for Sass to tell

if that is supposed to be a selector or an invocation of a mix-in,

and that sort of ambiguity is very, very bad.

That's the major stumbling block.

I have been thinking more about this lately,

and I don't think that's fatal.

I think since people are unlikely to want to

invoke a mix-in without putting a space after the colon

I think it might be good enough

to say you have to have a space after the colon

when you're invoking a mix-in in this way.

And if you don't, we're going to treat it as a selector.

That might be coming in an upcoming version.

I have a question for you.>>Sure.

What is your Sass pet peeve?

My Sass pet peeve.

The thing that you want to fix.>>In the language?

This is Chris's question. What's your pet peeve?

I get to fix a lot of the things that bug me.

Yeah, what's the one that is driving you crazy right now?

Right now the thing that bothers me the most

is how primitive

the way you include other files is,

like it's literally just a text include.

You take the other file and drop it in your file,

and this has several awkward consequences.

It means that if some Sass file

somewhere way off in your dependencies

includes something, you have everything that that file defines no matter what.

You have no say about it.

You get its mix-ins, you get its top-level variables,

and that's awful.

It also means that there's no way for you to take

a file that you want to include

and only use some of the things from it in your file.

One thing that we've always sort of—

since we added extend that we've wanted to be able to support

is taking a file that someone created

as a way to style stuff.

Even maybe a plain CSS file and being able to

extend the stuff you care about

but not the stuff you don't, so similar to the way placeholder selectors work

but using a file or a library that wasn't defined—

that wasn't written with placeholder selectors in mind.

It's almost like an inactive vaccine kind of thing.

Yeah, exactly, so the way include works right now

doesn't allow any of that.

It doesn't allow any sort of name spacing either,

and that's something that Chris and I are going to be working really hard on

in upcoming releases.

Our grand plan for Sass 4.0 is to have a completely revamped

module inclusion system which will have all of these features and more.

It also will allow you to load a .CSS file.

It will not be named at include,

so it won't have this incredibly awkward conflict

with an existing thing in CSS that we have to maintain compatibility with.

That will be great.

[female speaker] Questions from the audience?

There's a question. I think it's Mike.

Hi, I was curious what keeps globbing statements

out of import statements in standard Sass.

This is something we get asked about a lot.

The biggest concern is that the way

globbing works is inherently unstable

with respect to the order of the files that get imported.

It means that you can impose some stability there.

You can say, "All right, we're going to order them alphabetically."

But it's arbitrary, and what's more important is it's not based

on something that the user has an understanding

of affecting the way their CSS comes out.

And one thing that's a little bit awkward about CSS

is it's a language where order matters.

And often order matters in very subtle but meaningful ways,

so if you have 2 arbitrary CSS rules, and you flip their order,

it's possible that will make some part of your site

that rarely gets looked at completely unusable.

The way this relates to globbing

is that if we allow globbing what that means is that if someone renames their file

something that you should feel safe doing

it could change the styling of your website

in subtle and hard to detect ways,

and that's something we are extremely worried about.

We are professional developers. You can trust us.

[laughter] Just trust us, Nathan.

The people in this room

I can absolutely trust, but unfortunately,

I don't want the people in this room to be the only people who use Sass.

[male speaker] Can you put in a secret turn off the safe mode switch?

Yeah, there's a Sass globbing package

that you can get, and it's a plugin,

and people use that,

and you're welcome to do so.

But then I can't get into Libsass.

It's important—I'm a big believer in the idea of many small experiences

combining to give a larger impression.

It's important to me to minimize as much as possible

the number of small ways that Sass can make you feel like you're doing something

that might not be safe.

Even if only 10% of the developers

and each have 1 time where the ordering of the files being loaded

causes them confusion and pain

and makes their site break in a way they don't understand,

that adds up on top of additional confusion

that's built into learning a new language

or to ways that we have to interact with CSS

to make things work.

And eventually that can hit a critical mass

that causes people to become upset with the language,

and that is the point we don't want people to reach.

[applause]

[female speaker] In the back.

Just back to the question we had before about Sass and CSS, SCSS.

I don't know a lot of people using SCSS.

I love Sass for a lot of reasons.

I was wondering, do a quick poll, who is using Sass?

Raise your hands.

And SCSS? Okay.

That's very interesting, because out of all the people I know in Europe

mostly they are using Sass for a very long time,

and if you're working on a big team

and you're a really experienced front-end developer

and having no key issues with that

or having a standard syntax helps a lot.

But I know for us particularly we use SCSS only and other reasons.

Quite interesting. Thank you.

Another question?

I'm actually surprised by how few of us in here are using the Sass to text.

[male speaker] That's the beauty of it. I don't even know—

Oh, no. Save the laptop.

That is the—I want to be straight-up honest.

I don't even know the difference.

I don't know the difference.

[female speaker] You're about to get educated right now.

Dot SCSS.

SCSS is white space.

And whatever I'm using, which I guess is Sass.

Does it look like CSS? Does it have curly brackets?

Okay, yes.

Curly brackets. I use curly brackets.

The .sass is the kind that's very white space dependent.

It would look like Haml.

Where did that come from?

Where did the non brackets come from?

That was the original, no?

It was the only one for a very long time.

[male speaker] I'm late to the game but the beauty is—

Could I jump in here? I have an opinion on this.

I've been using Sass since the beginning,

and I was originally a very, very rabid original syntax kind of user,

so I can very much identify with you as well.

But I feel like it's important not to under emphasize the value of the SCSS syntax as well

from an evangelism perspective.

As soon as we added that,

there was a whole new openness in the CSS community

to try Sass, so I don't know if we're ever going to end up with one syntax versus the other—

You want to talk?

One syntax versus the other, but it's huge on the evangelism side.

The other thing that I would add—

I've written an article about this on The Sass Way you can check out.

I'm comparing the differences between the 2 syntaxes and the value there.

I would say the big thing for me

is that using a more free-form syntax like CSS,

particularly once you get away from the nesting,

is a lot more fun, expressive.

There's times when being forced into that rigid indentation-oriented things,

your CSS files span tons of lines,

and I find myself often really pleased

to collapse all the hover state of an item on 1 line

if it's just changing a color or something like that.

I don't know. There's value on both sides.

[female speaker] I don't mean to interrupt.

We don't have the auditorium for much longer,

and it's a very rare treat to have Nathan on stage.

Do we have more questions for Nathan?

We can continue this debate upstairs too.

Is it on? Yeah.

This is a small one, but I was wondering if you could tell us your thoughts on generating an error

in a style sheet in case the person is calling a mix-in or something in a way that totally won't work

and will not do what they want and the warning is not really enough.

I think we have an at error directive now.

Have we not added that yet?

No? We should add that.

The only thing I could think of was to call a mix-in that definitely does not exist to make the error.

It's one of those issues that have been filed for a while,

and it's one of those we definitely want to do this,

but there are a lot of issues we definitely want to do.

It's a getting around to it question.

Patches welcome.

Rob, you want to go ahead?

One of the big benefits of Compass

is that you can dip into the Ruby layer and expose new functions to Sass.

What are the plans for making a parallel system

with Libsass?

Is this something I should ask you or I should ask—

It's definitely a Hampton question.

That's a Hampton question. Okay, pass it on.

[female speaker] Scott, do you have a question?

I was wondering if you had any guesses as to how many jelly beans you've got?

[female speaker] If he guesses in a range, does he get more jelly beans?

Is this like Price is Right?

This is like high school math.

How many jelly beans are in the jar?

I'm the worst at estimating, so I'm going to say somewhere between

10 and a million.

Safe bet.>>Sounds good to me.

Any more hands?

Oh, mic. Hold on.

Hi, how are you doing?

[male speaker] Is there ever a possibility of getting dynamic imports?

It's pretty unlikely.

The way—sorry?

Being able to say import and then interpolating a variable into the import.

That would be rad, though.

It would be amazing.

It's not impossible.

But it would require a lot of strain on the order we do our parsing and resolution,

and like many instances of adding the ability to do things more dynamically,

it would require a pretty convincing use case

for us to start pushing that far.

Theming and IE support.

Say more.

Oh, now I'm on the spot.

Kind of back to the client theming stuff I was doing earlier.

I can see a case for that in what I do

where some clients only want certain parts of things,

and I want to import these style sheets and then also this style sheet

with this client variable in it.

I am totally on the spot right now.

I have to think about this a little bit in more detail.

I don't know, can you do this like import blank, like kind of Ruby-esque?

Import blah if blah or unless blah?

No, no.

Yeah, but I can see a way that I would use that.

Here's something that is more likely to happen

that gets you I think part of the way to doing what you want.

In our fancy new world of exceptionally powerful and awesome imports,

we may have the ability to do something like, say,

do an import but wrap it in a mix-in.

I think it's important for a lot of the infrastructure

around how Sass compilation works

that the set of all files that might be touched

when you do a compilation can be known without running the compilation itself.

But if you have enough information to say,

"Here are the files that I'm going to import,

but the way I use those imports may vary,"

and this could also potentially be done with putting them in an if,

but I think being able to have the single way of saying

wrap it in a mix-in and then be able to use the existing ways

of dynamically dealing with mix-ins, and we'll probably also move to being able to interpolate

when you do an include in the mix-in name,

so that will also help if you want to have a variable that's the name of your theme or something like that.

That would be awesome.

I have 1 question.

[female speaker] Yes, go ahead.

What is the best or most preferred way

for us as developers to contribute back to Compass and Sass?

Pull requests on GitHub.

Unfortunately, there are 6 or 7 that are sitting there

and have been sitting there for quite a while.

Chris and I both have a limited amount of time

that we can devote to Sass and Compass,

and my next priority now that we've gotten the ball rolling

on 3.3 in earnest, once that is out,

my next priority is to clear out those pull request queues and hopefully be more on top of them in the future.

Are you looking for other maintainers?

Or how would that go?

That's something that I would hope would evolve

from consistent pull requests over time

and becoming confident that someone making these pull requests understands the style

and what needs to happen with a new feature,

because there's this whole checklist of things that need to be done.

We need to add a new element of syntax.

You have to add it and add tests,

make sure that Sass convert works properly with it, etc.

And these are things that for individual pull requests

we're happy to shepherd people through that process.

Is there documentation on what it is that you check?

Documentation?

What's your hate of documentation?

I'm not hating, I'm just skeptical that it exists.

I think there is a contributing file, but I think it's very old.

But that's something I would like to exist.

Again, definitely want it, but haven't gotten around to it.

Just because my co-worker did want to contribute,

and if we can make it easier to get certain things fixed

or contributed—maybe other people out there want to help as well.

Having—

[male speaker] Compass needs more help.

That's actually true.

I think if—>>Is there a punch list somewhere of—

Yeah, if we can help with this is what we need to make sure—

I'm not an expert at this, but that's why I brought the question up.

[female speaker] We have time for 1 more question.

What's limiting current compilation speed in the Ruby version of Sass?

I'm not a performance expert.

Take what I'm saying with a grain of salt.

But we've at various times made pushes to make it faster,

and usually what that's ended up doing is running some profiling on it

when compiling large files and seeing what the bottlenecks are,

and usually there's been some major bottleneck.

At one point it was parsing static properties

that don't have any variables in them, and then we found a way to speed that up.

Or at one point it was reparsing files that you—

imported files that you'd already parsed before in a previous compile,

and then we added caching and sped that up.

For the last several versions when we've run the profiling

all we've seen is that the time it's taking is spread very evenly across all parts of the project,

which is exactly what we don't want to see,

because that means there's no place we can target

to say, "All right, if we do this one thing

it will get a lot faster."

There may be room for additional caching

at a further level.

I was talking with someone about this last night.

That's probably the most fruitful way to look,

but I think the time it takes to do a first-time compile right now

may be limited by the speed of Ruby and the string processing we need to do.

Okay, so that closes our panel

and the last talk of Sass comp.

A round of applause.

[applause]