JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

042

042 JSJ CSS and CSS Superset Languages


Panel

Discussion

02:11 – CSS Gripes

16:32 – Preprocessors/Compilers

20:34 – Basic Features of CSS Preprocessors

23:02 – Usefulness 27:15 – Mathematics w/ Variables

28:54 – Animation

31:12 – Nesting 35:40 – Build Processes

42:20 – Distinction

  • Prefixing

47:35 – Tightly Coupled

Picks

Book Club

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

MERRICK:  You have more technical problems than any other nerd I know. [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK:  Hey everybody and welcome to Episode 42 of the JavaScript Jabber show. This week on our panel, we have Joe Eames. MERRICK:  He’s out to a phone call, terrible timing. CHUCK:  We also have Merrick Christensen. MERRICK:  That’s me. CHUCK:  AJ O’Neal. AJ:  Yo! Yo! Yo! Coming at you live from the snow sphere of Provo, Utah. CHUCK:  And we have a guest, that’s Brian Turley. BRIAN:  That’s right. I’m a designer friend of AJ’s. CHUCK:  We’re talking about CSS today so we brought in a designer to set us all straight. And I’m Charles Max Wood from devchat.tv. And like I said, we’re talking about CSS today. One of the things I think that’s interesting about CSS is that it converges with JavaScript. Well, there are a couple of things but one is systems like LESS, that kind of compile, they give you some sane options for dealing with some of the dumb stuff that CSS doesn’t include. Then the other one is, I’ve also wound up fighting designers for selectors in the HTML. And so, I thought we could talk through that a little bit as well. BRIAN:  Hey, Chuck? CHUCK:  Yes? BRIAN:  I think those are two like really good points but I think there’s even more areas we can discuss in terms of how JavaScript and CSS are coupled. Like computed styles from JavaScript and also all the CSS methods from JavaScript. And the fact that your JavaScript sometimes doesn’t work, your UI doesn’t work unless the CSS is set up. I think the two tend to be a lot more coupled than people like to think. CHUCK:  I agree. That’s fair. So, which avenue or which aspect do you want to tackle first? Should we talk about just CSS and where it kind of doesn’t give us what we want? BRIAN:  I would love to complain about CSS. I got some bitterness in that sphere. CHUCK:  I know some people consider it programming but it doesn’t have any of the things that classic programming has like variables and functions or methods or anything like that. And I think that’s where a lot of us get frustrated is that we’re used to being able to reuse things, we’re used to being able to set things up that will define the behavior that we want. And in CSS, you really don’t have that. It’s really just simple markup. JOE:  So, do we consider the CSS languages, like Sass and LESS and all those to be part of CSS because then we talk about actually having those things. CHUCK:  Yes. I don’t know if you can call them CSS. I tend to think of them more as frameworks. JOE:  They compile to CSS, and they’re still not programming languages. MERRICK:  That is not true. AJ:  They become programming languages in some sense. Sass for example has functions, mix engines, if else logic, mathematics. It’s very much I would consider, a domain specific language, sure. But it’s definitely a programming language. JOE:  I guess it depends on your definition of language because HTML is a HyperText Markup Language. If it’s not a programming language, then it’s certainly not a speaking language. BRIAN:  But before we move on to like actually saner implementations of CSS, could we gripe about regular CSS for a second? CHUCK:  Yeah, let’s do it. MERRICK:  I think we have to. BRIAN:  One of the things that I’ve struggled with CSS versus JavaScript and maybe you guys haven’t experienced this as much, maybe I’m just a newb. But with CSS, I find that it is completely under featured for the things that we’re trying to do with it these days like in terms of building really rich clients to a point where you have to be incredibly disciplined with things like object-oriented CSS, and like what else? Like SMACSS. These things all help. But really, it all comes down to the fact that CSS is kind of an under featured language where discipline is your only defense in terms of maintainability. And that’s true of JavaScript except for JavaScript is at least flexible enough that we can mandate it to be something that is more scalable towards what we need to do with it these days. Whereas CSS is just rigid, you have to use a preprocessor. JOE: Yeah, it’s harder to be disciplined in CSS than it is to be disciplined in PHP. That says a lot. BRIAN:  That’s a good point. Yeah, except for I don’t have a PHP rage that you guys do. [Laughter] AJ:  So, CSS has absolutely no errors whatsoever. CSS is completely just a text format that may or may not turn into anything useful. It’s even worse than PHP because PHP, when you put it through — because you run it because it’s a template language. And you get sometimes very, very, very rarely but in the worst of cases, you get an error. Where with CSS, you can just type garbage and you never get an error. [Crosstalk] CHUCK:  Well, you don’t get an error. The problem is if you mess up the syntax, for example, if you leave off a closing curly brace, you just lose everything else. AJ:  Yeah, but without warning. CHUCK:  Yeah, and with the compilers. JOE:  It’s pretty easy to find where you broke the CSS. Whereas with JavaScript, there’s a lot of variables you can edit and mess up because it’s more complex syntax. [Crosstalk] MERRICK:  That’s fair. It is relative because if you’re kind of new to CSS and you haven’t learned the tricks about figuring things out then… BRIAN:  The other thing I’ve seen a lot of people struggle with, like my career as a programmer actually came more from the design into the development and not the development forced to be a designer. So, most of my experience with CSS has been building out sort of basic websites. And I found as I met more and more developers that came from more Java or sort of backend programming, or programming backgrounds in general, they really struggle with some of the CSS that is less obvious. Like the fact that margins collapse or different things that are not so like. For example, when you float two elements, you need to query your floats because essentially lose your box model. Things like that just tend to boggle developers’ minds because it’s a declarative language but you’re not necessarily declaring what the heck a clear bolt does or what overflow hidden does to break your query floats. I think that’s one of the more insane driving things for a lot of developers. CHUCK:  Yeah, I mean as you do it you get used to doing those kinds of things if you learn those tricks. One other thing that blows my mind sometimes is the way that the CSS will cascade. So, you have an outer element then you have a mid level element, and then another mid level element, and then another midlevel and then you have the bottom element. And so if you’ve got selectors that selected the bottom element and you’ve got other selectors that select things in between, and sometimes you’ll select the completely outer element, and then you’ll say, “Any of the inner type that do things.” And so which ones win? And it’s not always obvious. It’s not always the last one. And so, you’re always trying to figure that out. Thankfully, you have tools like the Chrome web developer tools that will show you which ones are winning and help you figure out how to get it. BRIAN:  Oh, no kidding! And speaking of the cascade thing, now don’t get me wrong, I’m really grateful for CSS and the fact that we’re not using font tags and tables anymore with these sort of images. Do you remember those spacer dot gifs? That was ugh. And at the time, it was so awesome, like doing table layouts was the ‘chizz’. CHUCK:  Oh, yeah! Now, it’s such a kludge, man! BRIAN:  Oh, yeah! I was hustling tables. [Laughter] BRIAN:  But my point is that the problem with a big team, and this is why I say CSS is completely under featured for where we are today in development, is people are trying to build like desktop class applications in the browser. And when you do that, you tend to require a bigger team to build these kinds of really rich components. And I’m super stoked for the web component API, by the way, because of this. But it’s really hard in the browser particularly to encapsulate people. In JavaScript, we’re given Closures to do that essentially like we have functions or Closures. But in CSS, you have a team like anyone making CSS selectors is essentially affecting everybody else in the global scope. And so, they come up with these really awkward unique class names but then you don’t have the shared code anymore because you can’t import somebody else’s styles or extend other styles. I love Sass, particularly because they offer an add extend which is completely useful. But the problem is, is because it’s not in the language, you tend to bloat your style sheets when you use extend. So, I think the CSS working group needs to take a look at extend. MERRICK:  And as you said, the only defense is discipline. BRIAN:  Yeah, with CSS and that’s what kills me. CHUCK:  One other thing that I want to bring up and this is something that I’ve been fighting more recently is that we’re using XJS for my current client and it generates its own styles. It uses its own styles and it generates its own styles inline. It’ll just add them to the tag in the style tag. And so, in order to override those, a lot of time you wind up using ‘!important’ (bang important). ALL:  No! CHUCK:  The real problem is, is that they use ‘!important’. So, if you want to override what they did, you can’t just add a style that overrides it. You actually have to tell it it’s important. I want to take ‘!important’ and I want to stab him in the eye with it BRIAN:  Yeah, just take the ‘!’. That’s funny. You know, something that I’ve seen is, I call it Z Index Warfare. And it’s developers making up a higher Z index than whatever else is on the page. And eventually, you get up and you’re like 9,000,001 Z indexes. It’s like, “Top that, suckers!” It’s just because it’s really hard to know the scope of your development environment when it’s completely something you’re going to have to research. What classes you’re going to reuse? So, you end up needing to do a ton of work on a style guide or something, which really, we just need some sort of like better encapsulation and better sharing with encapsulation, whatever. CHUCK:  So, one other question I have about this before we move onto some of the solutions is CSS3. Does it make it any better? JOE:  No! BRIAN:  It does in some sense. Do you remember having to create fetching shadow corners and then repeating images on the sides of your internal div just to make a div with a box shadow grow to the content? Because I remember that and those were tearful days, man. Rounded corners. The amount of work that went into some of the simplest UI components, that for the most part, you don’t have to deal with. CHUCK:  Or the gradients. BRIAN:  Oh, my gosh! The gradients, which wasn’t possible before, right? Before, you had to hack it by making some hugely long gradient image. CHUCK:  Yeah, and then you would make it stretch when you want to change the sizes. BRIAN:  Yeah. You’d make it stretch, or you’d pick a background color. CHUCK:  Yeah, it’s gradient to the height of the image and then background color from there. BRIAN:  So CSS3, and also arguably, I don’t think it’s part of the specification. But I know there are variables with WebKit prefixes. It’s an awful syntax and it’s really upsetting that they didn’t use any familiar syntax. But you can do like WebKit, something variable and you can actually make variables. But I don’t think that’s part of the CSS spec. But maybe it is. We’ll have to look that up. CHUCK:  Yeah. But one other thing with CSS3 that is worse that drives me crazy, is some of them will honor like the actual CSS. So, if you put ‘border-radius’ in, it will give a border radius to it. But half of the browsers out there, you still have to put like ‘-webkit-border-radius’. [Crosstalk] CHUCK:  Yeah. So, it’s like, “Okay. Well, I’ve only declared it like six times now.” BRIAN:  That’s a good point. I think I’ve been using preprocessors for too long because I haven’t experienced that. CHUCK:  Yeah. The preprocessors are nice because they’ll just insert that for you. They’ll put all of them in and you don’t have to think about it. MERRICK:  It’s really funny when the browser makers start supporting each others’ prefix tags. AJ:  Firefox is like, “Hey, guys! What about us?” [Laughter] CHUCK:  Yeah. AJ:  Want any of those [inaudible] prefixes? [Laughter] AJ:  So, the thing that just drives me nuts though, is with all of the web standards, like anybody that’s under that umbrella, it’s like they lock them in separate rooms and say, “Please don’t ever work with someone who will ever develop with this technology and come up with the API based on looking at your foot.” JOE:  Yeah. AJ:  Like, if anyone who had ever used JavaScript in their life had been present in the room when they were going through the CSS3 stuff, they would have been like, “Oh, wait! Don’t you mean to make it so that’s actually useable? [Laughter] CHUCK:  I hate my life. Could you make me hate it less? I forgot one more thing that I have to throw in there. And I don’t know how common this is anymore because I usually just ignore Internet Explorer. But do you remember adding those comments in there that are like, “If IE > 7, then use this style sheet.” And it overrides half of your styles, so it will look right in the other browser? AJ:  You mean, “If IE, include Chrome frame.” CHUCK:  [Laughs] BRIAN:  You see the star hack a lot too, right? Like, “This will apply specifically to IE, so we’ll put an asterisk before it.” CHUCK:  I haven’t seen that one. MERRICK:  I’ve seen it, but I’ve never understood it. BRIAN:  Or like, another thing that I’m grateful is like going the way of the dinosaurs. I don’t know if you guys ever had transparent pings back in the day, because you couldn’t get a GIF to map just right. So, if you wanted to get the transparency to carry over in IE, you had to like include some corresponding, either HTC file to get the Microsoft browsers to respect the transparency, to like redraw the images. It was such a tearful road, man! [Laughter] AJ:  I remember there was a JavaScript library for it. It was like PNG.js or something. BRIAN:  There you go. It’s like, “Are you kidding me?” CHUCK:  Alright. So, are there any other gripes that we have about CSS that we want to air before we start talking about some of the solutions? MERRICK:  Yeah, the inability to know if a class is used. CHUCK:  Oh, yes. MERRICK:  And so, that’s why my style sheets download 40K extra worth of styles that probably are never used but I can’t delete them because they might be used. BRIAN:  And if you do delete them, they might potentially break behavior and not just look. So, it’s risky to delete things. CHUCK:  Yeah. And another headache is the absolute positioning or relative positioning or whatever positioning. [expression] AJ:  No, no, no. You got to put an absolute inside of a relative. CHUCK:  Yes. BRIAN:  I don’t know. That’s less insane like Fixed not working sanely across the older browsers. That’s more disappointing. JOE:  Well, they fixed “Fixed” in IOS6. BRIAN:  Oh, that’s nice. Because there are plenty of libraries to doc navigation at that point. CHUCK:  Alright. Well, let’s talk about some of these — what are they? Preprocessors? Compilers? BRIAN:  Oh, man! I don’t know what you’d call them. Preprocessors seem like a good one. Transpilers, I don’t know. They’re kind of compilers, I suppose. CHUCK:   It’s like a meat grinder, right? You put Sass or whatever in one end and you get CSS out the other. AJ:  Yeah. It’s the Coffee Scripts of CSS. BRIAN:  Yeah, it is. Except for the unfortunate limitations that Coffee Script doesn’t as much because JavaScript is so flexibly — you can do some pretty crazy things with it. CHUCK:  Yep. So which ones have you guys used? BRIAN:  I’ve used LESS, Stylus, and Compass/Sass. JOE:  Isn’t that all of them? BRIAN:  There’s more than that. There’s one from some agency, can’t even think of the name. But I have used quite a few of them because CSS is such a tearful road. CHUCK:  Stylus. MERRICK:  I just use LESS. I’m open to using something else. They all kind of seem the same to me. So, I picked LESS because at the time, it was — like you didn’t have to do anything to your CSS to start using it. You just rename the file from .CSS to .LESS and bam! Now, you’ve at least got Lintor. BRIAN:  So, I’ll point out that that is also true of SCSS which is compiled by the Sass Compiler. So, that’s not exclusive to LESS. CHUCK:  Yeah. I’ve used Sass and I’ve used Compass which is built on Sass. BRIAN:  Which is so sexy. CHUCK:  Yeah, I’m in love with Compass. BRIAN:  When I consider my sort of CSS heroes and people that I think are like changing the landscape for CSS, Chris Eppstein is up there. He’s the guy that’s, I think, he’s on the Sass Core Team. But I know he’s the lead for Compass and Compass is just amazing. Not only does it abstract away a lot of these odd sort of browser things, like inline block not working in certain versions of IE and giving you mix-ins to basically mitigate some of those. So it kind of has, to liken it to the jQuery library, or I’m sorry the JavaScript library, you have jQuery so you can sort of mitigate the differences across browsers. So, Compass has sort of a jQuery aspect to it. So, that way you have sort of these shared mix-ins that mitigate differences across browsers. And as browsers evolve, so does your compiled CSS which is really cool. So, if a certain prefix gets deprecated, then it will get deprecated out of your CSS the next time you compile. But then, it also has an Agile file JS component where you can compile production level CSS versus targeted CSS for different types of browsers. CHUCK:  What do you mean by production level versus targeted? What’s the difference there? BRIAN:  They have different styles that you can output. You can do like development output. And by the way, Chrome has source maps for Sass which is really dope. So, where your actual CSS or SCSS is and knowing where that’s reflected in your browser, is actually in Chrome now. They have source maps that you can go to the line number within where it is actually in your Sass or your LESS. CHUCK:  That’s sick. BRIAN:  It’s super sick, particularly because now — I wrote this library one time to load CSS onto a page with a component using AMD. So a lot of times, your JavaScript needs the CSS to function, like they’re not as different as you think. And so, I wrote something to let you basically require and interact with your CSS on the page, called Style Manager. And the only problem with that was I made style tags rather than links because the browser actually stops you from creating link tags at a very short number of links. It’s like 30-something or maybe even less than that. But when you create style tags, then you no longer know where the heck your CSS is coming from. But source maps help mitigate that issue. CHUCK:  Right. So, do we want to talk about just some of the basic features of the LESS or Sass or whatever type of — let’s call them your CSS preprocessors? Just some of the features that make your life simpler. It seems like the kind of the biggest one that’s the most useful, at least for me initially, is variables. BRIAN:  Yeah, for sure. And I think mix-ins are probably where my heart is the most. And that’s why I like Compass to append the Sass because — or for Stylus, it’s called Nib. I don’t know if LESS has something. I’m sure it does because it’s crazy if they don’t. Well, Nib is for Stylus what Compass is, in a sense, to Sass and they give you like, known mix-ins. Like, “I want to make this horizontal list.” Or, “I want to make this inline block.” CHUCK:  Yeah. It looks like it does have mix-ins. BRIAN:  And they do the vendor prefixing as well, which is just — those are pre-built mix-ins. But for those of you that don’t know what mix-ins are in this context, they’re almost like Includes, I would suppose. They’re sort of like little functions that evaluate to — because they can usually take arguments and they can evaluate to output of CSS. JOE:  Syntax checking, that’s a huge one. CHUCK:  Well, that’s because all of these preprocessors are syntax reliant or they rely on the syntax. And so, if the syntax doesn’t line up, it’ll barf. AJ:  Thank goodness. Yuck! CHUCK:  And so, the whole point is you get the syntax checking for free with all of them because they have to have the correct syntax or they won’t work. So, it’s kind of a bonus there. The mix-ins for me, you can kind of think of them as really dumb templates. BRIAN:  That’s a fair point. They’re almost like thresholds. MERRICK:  It’s a macro. CHUCK:  Yeah, it’s a macro. That’s a good way of thinking about them. So effectively, you just say, “Okay, here’s what you need to know to put it together.” And then, it just compiles a set of CSS for you and they’re extremely powerful. And you can mix them together. So, if you want rounded corners and you want a certain gradient in the background and you want these other things, you just mix in a couple of these and it does all the work for you. BRIAN:  Yeah. CHUCK:  I’m kind of curious, Brian. From a designer’s point of view, do you find the same usefulness out of these or are there other things that really kind of pay off for you? BRIAN:  I’ve only used LESS up to this point and then standard CSS. And it’s been nice to be able to do queries and kind of mix-ins but other than that, I haven’t gone really deeply into the programming features of these preprocessors. CHUCK:  Okay. MERRICK:  You know what else is cool, Chuck, is — Brian, maybe you know this. Do you know if LESS has color manipulation stuff because that’s something that I’ve really — as a guy who’s not necessarily a designer. Actually, I’m just straight up not a designer. I really like the ability to lighten this gray by 30%. So that way, when I have a variable that represents — or let’s do blue because that makes a little bit more sense. I want to lighten the blue by 30% to create this variable, and I want to darken the blue by 20%, and I want to do some de-saturation on the blue for this variable. And so, you can create like themes from a single hex value because you’re able to essentially get color manipulation or mathematics on the hex to generate different color schemes or different colors. That’s one of the things that I really think is cool about these particular things too. Can you do that in LESS? Do you know? BRIAN:  I’m not sure. I haven’t tried to do that. AJ:  I think you can. [Crosstalk] CHUCK:  LESSCSS.org, I’m browsing all of these. It does have that. It has some function stuff that you can do. And specifically in the footer, it says, “Color, base color, blah…blah.” And it adds some green to it. And then, the next one is border color and it de-saturates the red by 10%. JOE:  That’s great. BRIAN:  That’s awesome. I think one of the things I really like about LESS is — this is a JavaScript podcast and I’m trying to avoid the hipster thing of being like, “Well, it’s written in JavaScript, so therefore…” But the fact that it is written in JavaScript is really nice because now, you don’t have to run a build step during development still. You can just do it on the fly. And that’s why I think designers are drawn to LESS because it’s like, “Add this to your page.” And you’re done. It’s not like, “Go and install Ruby. Go and get Gems updated. Now, install Sass link.” It’s like, “No, you just grab this JavaScript file,” which they are probably used to doing from jQuery and things like that. And then suddenly, you can support these new features in your browser. So, I think LESS has a great level of adoption because of the fact that it was built in a way that it could be run in the browser. JOE:  So you, instead of compiling it to CSS as a preprocessor step, you actually load it? MERRICK:  Just attach it as a file. CHUCK:  Yeah. All you do is you install or you use a script tag to get LESS.js. And then from there, all of your CSS link tags can be [inaudible] style sheets/LESS. Then, you just pull in your .LESS files and it will, on the fly, set up your CSS for you. BRIAN:  And I would be shocked if they tell you to do that in production. CHUCK:  I was going to say, “I wouldn’t do this in production.” MERRICK:  I’ve always pre-compiled it. I mean, the first reason I started using it, like I said, is because it provided a Lintor. So, if there was a semicolon in this thing, it would catch it. BRIAN:  Yeah. And speaking of Lintors, since this is a CSS broadcast, there is a CSS Lint, in terms of just the syntax piece. And CSS Lint is kind of like the JS Lint of the CSS world and it also happens to be incredible harsh. I’m also kind of waiting for CSS Hint to come out. [Laughter] [Crosstalk] CHUCK:  Why don’t you go write it? JOE:  I think it’s from Stubbornella who kind of came up with the object-oriented CSS mentality and evangelized it so much which is awesome, by the way. It goes miles and miles in terms of maintaining CSS across a big team. CHUCK:  Yeah. So, we’ve talked about mix-ins. One of the things I want to talk about with the variable, besides just the fact that you have them, is that in a lot of cases, you can do mathematics with them. For example, if you have a color and it’s really a hex number and most of these preprocessors know that. So, if you want it to darken, you just multiply by two. You can also use some of the other saturation, lighten, darken, whatever functions that are built into these. But the other thing is that if you want one thing twice as wide as the other, you have a width variable for the one, you just times two for the other one. And so, a lot of that is really, really handy. BRIAN:  Yeah, it’s amazing. Some of the grid frameworks like Susy, have you seen Susy? It’s amazing. But some of these frameworks for grids written in these languages are so remarkably flexible and robust because they just use MAC to generate the grids. Rather than like the old day when you downloaded — I shouldn’t call it ‘the old days’ because people probably still use them quite frequently — but like the 960 grid system, you download it and then you have like a chizz ton of classes that you just use. Whereas with this, you essentially get this awesome level of grids that you can compile and customize. And they’re responsive too. Susy is awesome because their grids are done with M’s and they include breakpoints, which is another area that Sass is awesome. They’re already helping you with responsive stuff. CHUCK:  That is cool. I’m looking at it right now. BRIAN:  Isn’t that sweet? CHUCK:  Yeah, it’s all managed through mix-ins. BRIAN:  Yep, it’s all managed through mix-ins. And that guy, I think the guy that does that also did — hopefully I’m not mis-crediting people — but he also did this animation plug-in for CSS3 animations which is eventually going to be bundled up in to Compass. But it abstracts away a lot of the CSS syntax for doing the hardware-accelerated or hopefully hardware-accelerated CSS3 animations and transforms them. AJ:  So, jumping off of the animation thing real quick. I just briefly looked at — there’s like a document, .addEventListener animation done or like WebKit animation done or something like that, so you know that when you’re doing a CSS straight transition that some transition somewhere on the page is finished. Is that right? BRIAN:  You know, I wish I knew. That’s actually been something I’ve always struggled with, is not knowing when those things are going to be completed. CHUCK:  You almost have to set it off and then set a JavaScript type, so you can react when it’s done. AJ:  You can add an event listener for it but I think the event listener is really stupid if I understood the example I was looking at correctly. And that, it’s an event listener that fires anytime any animation is complete. So, if you add two classes with animations, then you are going to get two animation events or something. BRIAN:  Some polling on the DOM? See, I got to give those guys more credit. Like, I would be shocked if there were really one event listener. And I’ve been shocked before in this kind of stuff. But if you think about images, like you listen to Load on a document but you can also listen to Load on other elements as well. AJ:  So, I would just be amazed if that was the way you had to do it. JOE:  I’m going to Google it real quick. CHUCK:  Yeah. BRIAN:  You know, most of the CSS animation and transition stuff that I’ve done, because it’s not very well supported yet, has been in just little pet projects and little experiments to do with 3D transforms and stuff, because it’s kind of hard to use them in production today because most people can’t support it anyhow. CHUCK:  Yeah. BRIAN:  So, I haven’t really experienced much what the interaction with JavaScript would be like except for adding the classes. CHUCK:  So, one other thing I want to talk about with some of these. In fact, all of the ones that I’ve looked at, Sass, LESS, whatever, is nesting. It’s simple but it’s really nice. BRIAN:  It is. CHUCK:  So, if you have a div and you know you’re going to have another div of another class inside of that, you can just define it inside of the CSS definition for the outer div. And then, it will properly compile it down so that you have outer div, inner div, and then the style in the CSS. BRIAN:  Which is wonderful because you’re not retyping that earlier selector over and over, but it’s also a vice. And I’ll give you a word of warning because when I first started using SCSS, I basically mashed my HTML structure because that’s what made sense to me at the time for whatever reason. And I basically was like, “Oh, yeah. Screw CSS and all of those things that I learned about maintaining CSS. I’m going to just basically mash this up.” So, you basically throw away all the reusability of your CSS when you create over specified selectors. And it’s really tempting to do that when you get the nesting because it feels like you’re just replicating almost your markup. CHUCK:  Well, the thing that I really like about it is that it’s like let’s say, in general, that I have a widget that’s going to be on my thing on my page. And so, I can do widget and then I can do all the special styling for a widget. So, all the buttons that are going to be in the widget, all of the links that are going to be in a widget, all of that stuff and then, I can declare another one that’s a specialized widget and then, I can just tweak what I want in that and have that as a separate selector that’s got all the nested stuff in it. BRIAN:  Totally. CHUCK:  So, it keeps all of the stuff that belongs together, together because it’s nested and it’s convenient to put it there. BRIAN:  Oh, that’s a brilliant way to use it. It took me a little bit of pain to realize that you shouldn’t over specify just because you can, just because it feels so natural too. But that’s an awesome way to do it. And if you’ve used Sass, they offer an ‘add extend’. So, you can be like, “My specialized widget actually extends this other widget.” So, they give you a way to pull in those attributes but it tends to blow your style sheets. So again, I want to call on the CSS working group to review ‘extends’. CHUCK:  Yeah. I generally don’t use the ‘extend’ because of exactly what you said. Yeah, it pulls all of the styles from the original into the compiled version of the copy. BRIAN:  What it does is it takes your selectors and then it adds them to whatever you’re extending as well. CHUCK:  Oh, there you go! BRIAN:  So, your selectors tend to be exceptionally bloated when they don’t need to be. But ‘extend’ in theory would go a really long way towards making CSS more maintainable. So, that’s why I really hope they review that. CHUCK:  Yeah. I really like the — I usually don’t use ‘extend’. I just set it up so that the one is up above the other. And so then, my specializations get loaded last and they win. Then, they kind of take control that way. BRIAN:  One other thing. I don’t know if Stylus or LESS has this. But it’s another thing that I really love about Compass is they actually compile sprites to CSS. So, you can give it a folder of images and you can import it into your style sheets. And it will export a compressed image of all those images as well as CSS to basically reference those images. JOE:  Wow! BRIAN:  So like, I look at Compass and Sass. And I honestly just feel like they’re way advanced. But that’s honestly because I haven’t ever felt the need to look at the other ones as much. I looked at LESS and Stylus and I’ve used them both but I’ve never been quite as impressed as I am with Compass and Sass. JOE:  To jump back for a second, I did just find a better tutorial on the MDN, the Mozilla Developer Network. And it does show that you can listen to the animation, start animation, end an animation, editable frame or something like that on individual elements. The previous tutorial I looked at was doing it the dumb way where it made it seem like you had to listen on the window. MERRICK:  You don’t care about event delegation? CHUCK:  [Laughs] JOE: What? MERRICK:  [Inaudible] dude. CHUCK:  Yeah. So, let’s talk about the build processes a little bit. With Sass, it’s Ruby; with LESS, it’s JavaScript. BRIAN:  Stylus is JavaScript’s. CHUCK:  Stylus is JavaScript’s? BRIAN:  Yeah. CHUCK:  Do they depend on Node? Or can you use some of the other JavaScript engines? AJ:  Like Firefox, for example? BRIAN:  No, Rhino? Come on! CHUCK:  Yeah, Rhino or yeah, whatever. BRIAN:  For us kids in the Java world, I don’t know. Anytime I’ve ever used — the instance I’m thinking of right now is JSDoc. When I switched from the Rhino engine to Node for running our JS documentation, we cut the time by almost like 2,000%. It was insane, the speed improvement. So, I haven’t even tried to run things through Rhino anymore even though we have a very heavy Java backend here. CHUCK:  The reason that I ask is because a lot of times, what you wind up doing is you set up a CI machine, or some other build machine. And so, when you check in and you’re ready to deploy or even before you’re ready to deploy, if you have some staging environment or something. When it’s getting ready to push that out, you have to have, in Sass’s case, you have to have Ruby installed, and you have to have the Sass gem, and probably the Compass gem if you’re using any of their mix-ins, on the machine in order to do the build. The same with LESS or whatever if you’re going to use it, you’re typically using Node or some other execution environment to build that out. And so a lot of times, it basically comes down to, “Well, what do I already have there? What am I going to need in place anyway? What are the trade-offs between the features I’m getting versus the technology I have to install?” And, “How long is it going to take my build cycle to run if I’m using these different tools?” JOE:  That’s what dev ops engineers are for. [Laughter] BRIAN:  Well, that’s actually a beautiful point, particularly when you complicate your build that you to build it to develop, when you need to run your build to develop. Because then suddenly, your development time start to dwindle as your build starts to take two or three seconds. That’s an optimistic case for a lot of people. CHUCK:  Yep. As far as build steps go, it is something to consider, and there are trade-offs. I think for the most part though, it doesn’t really matter if it takes you three seconds or four seconds to deploy, as long as you’re not creating downtime on the other end. JOE:  So, if you’re talking about build steps from a designer’s point of view, since we’re usually less familiar with programming languages, it is best if you set up your styles. So that they can compile in a really quick set of steps or very simply, maybe one step; as easy as you can make it for the designer, the better. AJ:  Well, that’s better for developers too, man. I’m with you. CHUCK:  Yeah always, almost always. Yeah, there’s definitely something to that. JOE:  Well, I think Grunt kind of gets in a space where it can solve that problem too with doing the watches. The build system that I currently have that I reuse a lot, I kind of would like to convert to using Grunt after seeing Merrick’s excitement about it. MERRICK:  Yes! CHUCK:  So, that’s another thing that I was going to talk about a little bit is that some of these frameworks, I know that Sass has one. It looks like LESS has one as well. They basically have something that you can start up, if it’s a daemon or something. It’s basically a watcher. So, it watches that section of the file system and then basically says, “Oh, something changed here.” And it will compile on its own. Have you had any problems with that? Do you generally like that kind of thing? BRIAN:  I’ve found in my case, you run into browser limitations before you run into your operating systems limitations, depending on what you’re building. I’ve seen, for example, the link task. You get a big enough task that you need to watch and your file system suddenly can’t open and watch that many files. Your operating system can’t because of the file access limitations. And you can adjust those. But because the browser only allows like a certain amount of CSS selectors or a certain amount of link tags as it is, you typically don’t run into those as much with the CSS problem because you have less files in general. JOE:  Fewer files. BRIAN:  Yeah. Fewer files, I should say. And also, the one area that I have had a problem – and I’m not aiming to bash Ruby at all because I love Compass – but because of the spy compilation that we’re doing, that can be the slowest part of our build because they’re doing this awesome basically image compression and compiling really sophisticated style sheets from it. So, that can take longer than you’d hope when you start to use some of those more extensive features. JOE:  And it kind of makes you wonder like, how did we go backwards from the 1970’s when make files made sure that your spites didn’t get compiled when they didn’t need to? BRIAN:   You know, I actually wondered that. Like particularly with Node.js, I keep waiting for when we’re not going to have to close Node and reopen it every time we make a change. CHUCK:  One other thing that is interesting that I run into with some of these is I’ll set it up so that it will compile whenever I change something on my development machine. And then, when I try and merge with something somebody else was working on who was doing the same thing, I run into merge conflicts. BRIAN:  Yeah, check in those compiled files. CHUCK:  Yeah, it’s easy to solve. You just run the build again after you’ve merged all of the source files. And then it just — you don’t have the merged conflict on the compiled file anymore because it doesn’t matter. BRIAN:  It’s easier just to not version control them, I think. CHUCK:  Yeah, I agree. Just put it into your build and deploy steps. And that way, you get them out where you want them. BRIAN:  Exactly. CHUCK:  And Rails, I use Ruby on Rails for a lot of the development I do and it has its own asset pipeline. And you run into that with some of the others, as well – the JavaScript files and stuff. Anyway, I agree. You generally would want to keep them out of your build or out of your development process. Don’t check them in. BRIAN:  Yeah. JOE:  So, there were a couple issues that we mentioned at the beginning but didn’t actually get into. Well, one in particular and it’s something else that I was going to bring up. So when it comes to CSS, it’s got the JavaScript part, the DOM part and the style part which are separate. Because JavaScript is one thing, HTML DOM is another thing, style and prettified things. And so with — I think I’ve actually said this before in a different podcast we had. But the way I handle that distinction between what means what, is if it’s something the designer’s going to use, then it’s prefixed with CSS, if it’s something that the JavaScript needs, it’s prefixed with JS. And I think if you’re looking at maybe that animation type stuff where it’s got more hooks into the DOM or something, you can prefix that maybe with ANI or whatever. Because at least, I’ve heard people complain about having CSS in front of every single class name is kind of dumb because you just have to type more and, blah…blah, whine…whine…whine. But I’ve noticed that at least, I think it was Github or some super, super, super popular sites. If you look at their styles, they have JS in front of every single thing that they use to select on or attempt to do the DOM which I think is a really good way to do it. BRIAN:  I think that’s more sensible though than prefixing everything because if you’re prefixing the exceptional stuff then your default could be to noprefix and assume that that’s style. JOE:  Well, the problem that you run into is that people forget or they get lazy. So like, if you see it where it doesn’t have a prefix, then you know that someone forgot to decide what they meant to do with it. MERRICK:  Dude, developers are perfectly disciplined. They’ll never do that. [Laughing] CHUCK:  I do want to also point out that in a lot of cases, the development, like the development teams that I’ve been working with recently, we don’t do any of that. And it really hasn’t been a problem for us since we’re usually building both the CSS. We’re doing the layout and we’re doing the development. And so, we have some regression tests that make sure that the site works. And so, it’s like, “Click here. Do this. Do this other thing.” And so, it will fall apart if it doesn’t work. And it kind of feels like a little bit extra overhead just in the process of building stuff to remember to do that. And so, if it pays off for you, then go for it. If it doesn’t, then… BRIAN:  At what costm Chuck? At what cost? Your users got to download all those CSS prefixes? CHUCK:  No, it’s more just mental context that I have to keep in mind. That’s the cost to me. JOE:  It depends on your team. Since I work often with people who don’t do programming, I’ve found that that’s taking my merge conflicts and my, “Why doesn’t my event attach on the DOM element,” that I think it should be attaching to from every single time someone commits, to almost never. CHUCK:  Yeah. And if that’s the price you’re paying for not doing that kind of thing, then by all means, go for it. JOE:  And then, if there’s ever a conflict between an ID needing to be used by both, I’d say just hand it off to JavaScript unless you find out that building the widgets over and over again, that doesn’t apply to a style. So yeah, just let the ID go to the JavaScript and not to the CSS. CHUCK:  That is a generally good rule that I found anyway, is that you just assume that the JavaScript is probably going to need the ID’s. It’s real easy. I guess it goes both ways but it’s real easy to create just another class. And you can have as many classes as you want on an element. So, the ID’s can really be your unique selectors when you need them. And typically, you don’t need them as much in the CSS because you can just add a class to it as opposed to the JavaScript where you may just want the one element. BRIAN:  Yeah, the ID’s have a higher level of specificity too. So, they’re sometimes less useful in CSS than one might think. JOE:  I was just going to say one more thing is I’ve seen a lot of people when they’re starting out, they do ID’s. And then they do this dumb thing where they do like, “Table Row, Zero, Table Row, One,” because they’re dynamically generating ID’s. And if you ever scrape sites, I scrape sites all the time like when I get on something and they’ve got a bunch of songs on a demo album, I’ll just jQuery in there and select them and build the Wget script kind of thing. MERRICK:  You steal their music, for sure. JOE:  Well, you know, if it’s free… MERRICK:  I’m just kidding dude. CHUCK:  Yeah. So Merrick, you were talking about how tightly coupled sometimes your CSS and your JavaScript can be. And we’ve kind of talked around some of the issues. But I’m still not completely catching the vision of where they’re tightly coupled. Are you just talking about like the page layout and what you can see and what you can’t? Or is there more to it than that? MERRICK:  So, in a lot of ways, if your component doesn’t look right, it simply doesn’t work right. So say, you have a pop over component that is directly related to a link. If you don’t have the CSS necessary to say, “Hey, this is going to be positioned absolute.” So when the JavaScript figures out where to place it and it goes over the link, then suddenly, it shows up in the top left up of the corner or it’s positioned pertaining to the window. And then suddenly, that pop over component doesn’t work anymore because it’s not relative to the ancillary content that it’s trying to represent. So that’s one case. The other case is when you actually use classes in your JavaScript for example, to hide elements, to show elements, things like that, that if you don’t have those in, your page simply doesn’t work. There’s so many behavioral styles that when you’re interacting with your element with JavaScript that the behavior isn’t — without that behavior, your component is no longer functioning. So there’s some coupling there that people tend to discredit, I think. There’s a reason that when you download jQuery UI, for example, you have to download a corresponding CSS style sheet even if you don’t specify a theme. And that’s because there are these behavioral or coupled styles that I’m talking about. CHUCK:  That makes sense. That makes a lot more sense than what I was trying to figure out because there are styles that actually affect the behavior they’re not just… MERRICK:  Exactly, yeah. CHUCK:  It’s not just layout, it’s actually how it interacts with the rest of the page. MERRICK:  Exactly. And how it interacts with the user too, right? CHUCK:  So, I like it. Are there any other aspects of CSS or these preprocessors or pre-compilers that we want to talk about before we get into the picks? AJ:  As much as I complain, I’m really grateful for the work done on it because it’s a lot better than it used to be. CHUCK:  Yeah. I think that’s really the case. We just wish that it had some of these other features that make it much more pleasant to deal with. AJ:  Exactly. CHUCK:  And it’s funny that we’ve actually built these shims on top of it. MERRICK:  Transpile to it. CHUCK:  Yeah, to do all the stuff that we wish it had. So, alright. Well, let’s get into the picks. AJ:  Really quick. I remember what my thought was. Instead of like table row, zero, one, two, three, whatever, use a class and then use the data attribute to put like the ID number, whatever. But one thing about CSS is there’s little weird things where you can have say, one style inside of another style. And it makes your rendering or your DOM events extremely slow versus if you put it on a parent element or versus its absolute. Have any of you guys ever encountered stuff like that? JOE:  Nothing comes to mind. CHUCK:  I like that elements on the page inherit from each other. AJ:  There was this one case where, when I was building my Dropshare and I wanted to have an element move with the mouse. I switched the class I think from being, even though the element could move outside of its parent, I switched the class to being inside instead of outside and it made it be able to re-render a hundred times faster. Ah, never mind. CHUCK:  Yeah, I don’t know. I’d be interested if you could put like the code in a Gist on Github or something. And then, we could look at it and you could say this one was faster and this one was slower and then we could kind of figure out what the difference was. Anyway, let’s get into the picks. Joe, what are your picks? JOE:  Alright. I’m going to have two picks today. The first one is the book ‘Old Man’s War’. I’m about half way through that book. Freaking awesome, excellent book. My other pick is, I’ve actually picked this before when it first came out. But I got a copy of it for Christmas and it’s the X-Wing Miniatures game. I got the basic starter set for Christmas and that’s really cool, really fun game. So, I’m going to pick that one as well. CHUCK:  Awesome. Merrick, what are your picks? MERRICK:  Dave Crowe, he’s a beat boxer. He’s absolutely amazing. And it was pretty dang cool. The other thing is, as per the New Year, encourage people to live in the present, not in the past and not in the future. It’s a good time to just try and recollect, be happy. CHUCK:  Yeah, the world could end a couple of weeks ago. MERRICK:  You never know. CHUCK:  Yeah. Alright. AJ, what are your picks? AJ:  Okay. So, I went to Utah Software Craftsmanship Group last night. And it was a different format than most of the groups I go to. It was more discussion based. Joe, is that generally how it goes? JOE:  Yeah, that’s pretty much it. One hour of discussion on the book reading and then an hour of some kind of a coding exercise. AJ:  Yeah. So, I really liked the way that that was done. It was very interesting. So, if you’re around Salt Lake and you want to come to it, there will be a link in the show notes to that group. It was a really cool experience. JOE:  If you’re interested in starting up your own local Software Craftsmanship User Group and want some ideas on how to format it, then contact us. CHUCK:  Yeah. It sounds like a really cool group. Unfortunately, I was fixing a toilet last night and I couldn’t go. JOE:  It’s really good to have a group that’s all about just writing software well and not about the tech. CHUCK:  Yeah. There’s definitely that component to things, because I think a lot of times, we do get caught up in what JavaScript can do rather than how the programming could really make our lives better. AJ:  Yeah, like how to code well even though it’s JavaScript. The other thing I’d like to pick is the Effective JS book. And I guess we’re going to talk about that next week. So, I’ll save my comments. CHUCK:  Two weeks, we’re talking about it in two weeks. AJ:  Oh, in two weeks? JOE:  That’s great though because then people will have a chance to read it before we talk about it. CHUCK:  Yep. AJ:  So the two things I want to say about it, is I don’t necessarily think it’s a book for absolute beginners. And it does not dive into the specifics of the browser or of Node.js. It is about JavaScript, the language. It’s not about the environments that you use JavaScript in, but it’s very well written. CHUCK:  Yep. Well, we’ll have read it and we’ll be talking about it in two weeks with the author, David Herman. I guess I’m going to go next. So one thing that I realize, these used to be a lot more expensive but it’s something that I’ve recently purchased. It’s just a 32G SD card. I usually try and pick things that are much more like, “Here’s the general applicability of whatever it is.” But this cost me like $15. I was actually pretty happy about it. And it goes into my Canon Zi8 camera. It also will fit into my [inaudible] or Roland digital audio recorders. And so, I’m going to put a link to the one I got on Amazon, but just super happy with that. It’s nice because then, I can record a whole bunch of stuff before I have to sync it up to my computer and pull it off. The other thing that I want to pick and this is just what I’m going to be doing next week is I’m heading out to New Media Expo. I’m actually speaking on podcasting, specifically on syndication. Anyway, so I’m really excited about that. It’s going to be, well when you listen to this, it’s going to be over but I’m really excited about that. JOE:  Is that Alt Summit or something else? CHUCK:  New Media Expo. JOE:  New Media Expo. CHUCK:  Yes. And it’s in Vegas which is like a five or six hour drive from here. A little less when I drive it, a little more than less if I see police cars. But anyway, I’m super excited. And then, I’m also going to the Consumer Electronics Show. And I’m hoping that while I’m down there at the Consumer Electronics Show that I’ll see some devices that open up APIs. A lot of times, they open up APIs to some of the more ubiquitous languages like C++ or Java. Or in some cases, even JavaScript. So, I’m kind of curious to see if we might run into some devices somewhere that allow us, JavaScript developers, to really get in and do cool things with them. And my last pick, and this is again something else that I’m working on, is I am on the verge of starting an IOS Development show that’s formatted like this and the other shows that I do. If you know somebody who is an IOS developer that is kind of one of those genius people that you would like to hear talk about it every week, then shoot me an Email, chuck@devchat.tv or you can tweet me, CMaxW and just let me know who they are. I’m going to start inviting people to join the panel and we’ll probably kick things off here in about a month. So anyway, I’m also working on a show name. I bought a domain but I’m not sold on the name. So anyway, those are my picks. And we’ll throw it over to Brian. Brian, what are your picks? BRIAN:  Thanks! So my picks are more design picks, obviously. But one of them is a book called ‘Grid Systems’ By Josef Muller-Brockmann. And it’s not really specific to HTML or CSS or any web platform. It’s really just grid systems in general and I think it was written in the 60’s. Anyway, it’s been a really helpful book for me in learning grid systems and just how they’re applied. It’s definitely been helpful as I’ve done web design as well. Then the other thing that’s been interesting to me lately, it’s this website called IFTTT.com. You guys might have already seen it but it’s basically just a way to hook up different platforms online and make them connect and talk with each other and be able to do some programming like features. So it’s pretty cool. So, those are my two picks for this week. CHUCK:  Awesome. One other thing that I want to mention real quickly is that I’m doing Rails Ramp Up. So if you want to learn Ruby on Rails go to railsrampup.com and check that out. Well, thanks for coming to the show. I really appreciate all of your input. And we’ll catch you all in a week or two.

x