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