 How's it going is everybody really awake after lunch? So I came in from the West Coast. We don't have Dunkin Donuts on the West Coast I'm really looking forward to drinking like a medium iced coffee from Dunkin Donuts later So if anybody wants to go get one and wake up, let me know Hey, what's up? My name is Pete You might be wondering why a JavaScript person is speaking at CSS conference because I'm probably the least talented CSS person in the room But just a little bit about me. I worked at Facebook for a number of years Specifically worked on the Instagram team Built out, you know the first version of everything that you see on Instagram comm this includes photo pages profile pages business tools we actually had this whole suite of like analytics and ad creation stuff and basically stuff that pays the bills we created grew that team up ended up being an engineer manager over there Probably most excited about my work on react So we wanted to build a really rich and immersive Experience in Instagram comm and we had some technical limitations that required us to render exclusively on the client You know you're scaling you don't want to burn too many CPU cycles rendering stuff on the server So we wanted to render on the client There was this kind of crazy weird technology that put your HTML and your JavaScript in inside of Facebook Called react that we we built the first single-page app with react We did the first data fetching with react it was kind of the first full on react app and then later I worked on open sourcing it and And you know since then I backed off a little bit from the project But I still I'm a huge fan and work in the community a lot Most recently I've been working on a startup called smite We try to find you know all the online harassers the spammers the the trolls all those bad guys I'm on the internet classify them and then you know take them out So if you're a social app or a marketplace and you got these problems. Let me know happy to help So I wanted to start by kind of sharing my perspective, and I've been thinking about this a lot I talk a lot of crap about CSS because I really don't like it And then you know I realize that my perspective is not the right perspective But it's also not necessarily the wrong perspective either I just come from a background of developing applications. So if you think about what Facebook is like or what Instagram is like It's not really a document, right? You've got these reusable components all over the place It's interactive you're fetching data stuff is updating all over the place And the way that you build and style and construct an application is a lot different than how you would build and construct a document the separation of content from style is Less important in an application. It's very important in a document And there's all sorts of different kind of concerns here So in this talk, I wanted to focus specifically on the concerns of app developers Rather than more content-based documents so I took a look back in into the history of CSS and CSS was kind of designed from the beginning to work with documents There's this great document right there that you can take a look at that talks about how CSS came about and Turns out in the 90s. There was a bunch of authors that were Pretty upset that they couldn't change the color of text in a reliable way in their web pages and so there were a bunch of competing style sheet proposals and CSS is obviously the one that eventually won out and It had one feature that distinguished it from all the others. It took into account that on the web The style of a document couldn't be designed by either the author or the reader On their own but their wishes had to be combined or cascaded in some way So if you guys remember how browsers used to work There was an author style sheet where you say hey This is how I want my page to look and then the user creates their own style sheet and says hey I want the font size to be a little bit bigger because I have trouble reading it or I want to So reduce the size of the images or I don't want to see these ads And you would combine those the browser would combine those two style sheets or multiple author style sheets multiple user style sheets And eventually compute the style This makes sense This is something that everybody's been doing every day since then so three years ago that feature got removed from the most popular browser on the desktop and So effectively kind of the entire reason that CSS won out was this cascading feature that was designed to support User style sheets, and we don't have user style sheets anymore So throughout this talk I'm gonna kind of make the case that CSS has a couple of vestigial tails and those when you start to develop with Components those can get in the way a little bit And so there are certain techniques that you can use to try to avoid those and some more crazy ideas When it comes to styling applications and components that we could take a look at But I've said the word component a couple times now I think everybody's got a different definition of component. I come from the react world I'm not trying to do a react talk So I'm just kind of looking at components in the context of a piece of UI That's reusable in different contexts. So rather than you know a Header that can look different based on kind of where it is a component You want to kind of behave the exact same no matter where it's placed Now somebody in this room actually pioneered the technique of developing components in CSS Maybe somebody did it earlier. I couldn't find any evidence, but Nicole Sullivan created this idea of object-oriented CSS back in 2010 and She the kind of example that she used to talk about components and reusable CSS is called the media object And the way she describes it is it's in it's a the media object is an image to the left with descriptive content to the right She has this whole blog post about it. I suggest you check it out if you haven't already. It's kind of cool So this is an example of a media object on Facebook You can see my profile photo to the left and a bunch of descriptive stuff to the right It's not just a Facebook thing though. You can see it on Twitter, too You can see it not just in terms of comments and tweets, but you can also see kind of recommended people to follow or also media objects I saw it in Gmail. I Saw it in LinkedIn as well. It's all over the place So the way that you construct a Media object in HTML and object-oriented CSS according to Nicole on her blog looks something like this So you have this top-level div that has a class of media. It's got a link inside there And then the image is embedded inside the link and then there's a separate kind of content area And you can tell that this was this article is written in 2010 because we've got some browser hacks in there to make everything work in like IE 6 but you get the idea so the whole point of Developing code in this way is you create this one style sheet and you never create any more CSS when you want to render something like this you simply Cut and paste this markup and the CSS is generic enough to render this style of component all over the place There's a lot of benefits. It's less code to maintain. Let's go to send down to the browser And there's just a lot of great benefits to building components in this way So if you're an Ashley Simpson fan it renders like this By the way, I have these JS fiddle links that you'll probably not be able to copy down But I'll put the slides up or something But you know you can believe that it renders something like that So let's build this media object this kind of canonical reusable component in react Now again, I'm not trying to to teach you react in this talk If you're using web components or some other system even templates that use partials All the the same ideas should apply So the key idea here number one Is that there's no static html all of your html is generated is generated procedurally from javascript So you're not copying pasting component code You're you're referencing a component and then the engine is rendering it for you And the second piece is that you build components out of other components And this is how you can build complicated apps You've got a high level application component that represents your whole app a profile component that represents one page in your single page app Etc etc until you go down to a primitive component which just renders a div or just renders a link or something like that So if we were to to build this in react It would look like this I'm just going to breeze through this because I'm just using react to to illustrate this But we have a component called media object Every react component has a render method that returns the description of the markup that it should render There's some weird syntax in here called jsx, which basically is a way to embed html in your javascript I'm not going to fight that battle today Sorry But uh, there's just a couple weird things about it Instead of class. There's class name Those little curly braces let you interpolate values into your markup And this dot props references the properties that are passed to a component. So a component can be reused You pass it these props which are key value pairs And then it renders some piece of DOM Is does this make sense is this? I'm seeing sufficient nods that i'm going to move on okay cool and thumbs up nice So if I wanted to use this component You would kind of call it as if it was its own tag or custom tag So you see here. I have a div which is a regular old html element But then I have this media object which then passes link and image props As well as children to that component And so I've rendered two of them In this application and then if I were to render this to the browser it would look like this And uh You can see we just can kind of reference this media object component Over and over again and render as many of these as we want in any context It should render the same whether we want to render an ad unit recommend somebody follow somebody on twitter or a comment We should be able to reuse this piece of code Um, so everything's good right we can just reuse this all over the place Is there any problems that are going to arise anyone think anything? Someone just said cascade I wonder if they're pandering to me or not well the Yeah, I do hate the cascade. Um But the first one is is definitely related to cascade. It's class name conflicts So css is this big global namespace And all of these different components could be coming from different authors Maybe you pull in one from a third party vendor You have two different teams inside your organization that are building components They don't know about each other and then you have a third product team that glues them together And none of these different um authors really know about each other And it can get even worse where the the person that glues the components together then leaves Somebody comes back upgrades the dependencies and now there's this whole other set of crap you have to deal with And a lot of this stuff comes from class name conflicts and we actually saw this a lot on instagram sadly um And i'll talk more about that in a second. So let's say that we wanted to build this seem more component What this is is a piece of text with like a little arrow at the end that says That kind of indicates to the user that they're going to go off-site You've seen this on like wikipedia and some other places Again, you know, we we have this top level class name of seem more applied to the div We render whatever children are passed in To the tag And we render a little image at the end And we have some some crappy styling that is is not according to best practices, but whatever It's like someone could reasonably write this Now if we render this in our application again, we just reference this custom component as any other tag It renders like this, you know, you got some text you got a little icon at the end Now let's say we want to combine this and our media object So we want to have one of these kind of external seem more links inside of our media object So the natural way to do that is to take our media object which we built with best practices and modular object oriented css And compose it Together with this seem more component So we built the media object just like we normally do except instead of passing text to it We pass a seem more component Now we're composing components together. This should just work, right? If you actually put this in the browser You get this And this is not what we wanted we wanted this arrow to be on the right hand side of the text not the left hand side of the text And the reason for that Is if you look at the css that we used For both the media object at the top and the see more component in the bottom We have a conflict between this dot image class name Which is a pretty generic sounding class name Now you might think that this is like somewhat of a contrived example But this is actually exactly what happened to us on instagram We had a class name called image that was used in two slightly different ways And what we had done is we had taken What used to be kind of separate Web or separate server rendered pages with css and we turned them into a single page application So what would happen is in the kind of traditionally rendered version? We had kind of tested and and we didn't know about the specificity war between the two different image rules And everything worked fine But once we started dynamically loading in components in our single page application and pulling down the css on demand as we needed it We couldn't guarantee which order those rules would would load in as So we had this phenomenon where we would go on the profile page and everything would look fine Then we would switch to the feed and everything would look fine And then the person would hit the back button and go back to the profile page And suddenly images that were supposed to have rounded corners didn't or vice versa It was actually really bad like one corner was rounded and the other one wasn't it was just like It was embarrassing And when you've kind of built without thinking about components refactoring your way out of this is really really hard Especially when you have like preprocessors in play that are generating like lots of code It's hard to keep track of all this stuff So there's a bunch of methodologies that do help you out with this one of them is called BEM But just very simply the the way to solve this is rather than use the descendant selector for namespacing You prefix every class name with kind of the name of the component or some sort of unique id That prevents those conflicts between multiple components. So you notice here, we don't have any class called image anymore We have a media image and we have a seem more image And when we make these changes Everything Renders the way that you would expect so the the overriding theme here is We took an unpredictable style sheet and it's now become much more predictable so one of my rules of thumb When developing style sheets with components is to really stick with single class name selectors only And to never use descendant selectors or really any sort of clever selectors That can interact like that A second rule Is your class name should be unambiguously namespaced now. I mentioned, you know You can just prefix the name of the component or you can use a methodology like BEM There's also this cool technology called CSS modules. It's not tied to webpack, but there's a great implementation with webpack It will take care of namespacing your CSS for you. So you don't really have to think about it as much Now it generally needs means you need to swallow kind of a bunch of build tools In order to to work with it But it is really cool technology if you're set up in that way And the third rule that I have is that class names should be referenced exactly once in your js code And they should be private to the component that that uses them So this is important here a lot of times people use CSS classes in order to reuse styles throughout their page You if you have this common, you know set of style properties that you want to apply to a DOM node You create a class for it and then you start applying that class to all these different DOM nodes My argument is that if you have a powerful component system on the client the component system is designed to reuse Different pieces of UI for you. So you don't have to actually use The style reuse capability of CSS, especially because it does have some unpredictable properties So instead you just reference your CSS class once and every time you want to reuse that You know use a new react component or a new web component or a new template or a partial template And that applies even to tiny little bits of UI like this. So rather than have You know A css class called special link just create a really lightweight component called special link and And off you go So if you take a look at how we've kind of ended up once we start following all those rules We have our names spaced CSS class names in our in our js and our css We're only referring to every CSS class once so nowhere in here will you find two references to media under under image And if you start kind of developing in this style for a while You'll realize that you'll have your js file open in your left pane of your editor your css file open in your right pane And you'll just bounce back and forth between those two files a lot And you'll start to to kind of have this like Disconnect between the two files like you see the DOM node that you want to style And then you got to go look in a css kind of find the rules that all apply to it And then edit those rules reload the browser and it does kind of slow you down And since you're only referring to a class name in one place in your code It's functionally equivalent to doing all of your styles in line because again if we're developing in components And you're trying to de-emphasize the cascade de-emphasize You know a lot of the issues where where specificity matters inline styles isn't actually that bad So if we were to write that component in all inline styles Again in react it would look a little bit ugly So we have these kind of two curly braces the first curly brace Represents hey, I'm gonna interpolate a javascript expression into this dom node And then the second one is a new javascript key value object. So we're basically passing, you know Little bits of inline style Into these these components now if you were writing regular html those would be style strings, but in react you got to be a little weird So The disadvantage here is like it is a little bit ugly The advantage is I can look at this and I can immediately say see just from looking at the component definition how it's going to render And so I started Kind of developing in this style a little bit And then started kind of moving some stuff around and writing a couple of lightweight abstractions And refactored this to look like this So a lot of times when you render a div you really just want to render some sort of block element With flexbox, you know, you can have a flex row flex column And this I think is is super easy to read I'm like, oh, okay My element renders this block. It's got 10 pixels around it I'm going to float a block to the left and put a margin right of 10 It just kind of you don't have to bounce between that top j s and the bottom css File and you don't have to parse all these extra curly braces and expressions So we've been developing Our front ends in this way for almost two years now at smite It's open source It's available at github.com slash smite slash j s x style I think that, you know, some people in the community have have really thought that it's an interesting way to develop And some people are building applications with it You know, I encourage you to check it out. Keep an open mind and see how you like it Inline styles are not perfect though I'm sure there's a million things that you guys can think of that suck about inline styles I don't think that specificity is one of them because I just don't think we should be thinking about specificity at all ever Because we should get rid of the cascade But media queries. This is a great example Um, you want to conditionally Change how some element render is based in the width of the viewport for example. There's no easy way to do that with inline styles Um, my suggestion is just write style sheets the way that you normally have That seems like a great use of style sheets and what they're designed for, you know, that's kind of like, um A little bit more true to how documents work, right? They're elastic Uh as far as kind of simpler, um, you know Like features of css like pseudo classes One thing that we're playing around with is Adding extras magic style attribute attributes to those those components So rather than saying like block color equals something you can say block color equals something hover color equals something else And that will code gen, you know, the the proper css rule to change the color When the users hovered their mouse over it You might also be thinking about accessibility Separation of you know style from content and that type of thing Um, you know, first of all, I think that this is a great way to build apps I don't claim to know the best way to develop more content heavy sites or or publications Um, I'll leave that to the experts, but in terms of accessibility applications Just because you're developing with inline styles doesn't mean that you have to use divs everywhere Um in jsx style. Anyway, there's this component prop You can say you can pass to a component and say hey, I want to render a block But I actually want the component to be article You can also pass around all the aria attributes to improve kind of accessibility And um You know another thing too is is keep in mind that just because you're developing with kind of like semantic tags and separate content from From style doesn't mean that you automatically get accessibility for free Like you always have to go through in voiceover And you always have to go through and try to navigate through your site with just the keyboard To make sure that it works So, you know this approach of kind of styling everything as quickly as we can in in a more application kind of development style And then going through and adding the accessibility stuff and the and the kind of hints to the the browser later Has worked really well for us The big one for me though and what kept me off of inline styles for a long time was performance So we um actually originally shipped our product to customers Just naively inserting inline styles into the dom now Our application it's targeted towards like desktop users with powerful computers and we render like lots of visualizations and long lists and just like shoving like a lot of data into the browser And we found that rendering inline styles was just too slow Like we were creating these giant strings and we were inserting them into the dom and it was um You know it was locking up the user experience just to like create that string and garbage collect that string uh So what we ended up doing was making a change to jsx style where you write your code In a style where you it looks like you're writing inline styles But under the hood we code gen a a style sheet and we insert that style sheet into the dom So the code that you write looks like Block margin equals five and then some content and then we insert um into the head a style tag And we auto gen a class name and we give it a margin of five And actually a display of block two which I didn't include there And then all we do is apply this this class name to the to the The actual dom note itself and what's cool about this is you can actually reuse these class names between similar looking components So if you tend to just have some divs that have five pixels of margin around them All of them will get the same class name or if you render a long list of items You'll create this style sheet once and then just reference it throughout the rest of your uh, the lifecycle of your application Uh in terms of of kind of more performance Uh The the problem with that technique is it makes server rendering substantially more difficult So if you want to render out a static webpage to serve to google or to serve to a mobile device Um, you're going to want it styled without having a bunch of inline styles in it because caching is going to be not super fun um, so there's an experimental Toolchain that we've built that will walk through all of your components and see where you're referencing constants So a good example is if you created one of those block components and you said margin equals five or margin equals some global constant We know that that's always going to be five and so we can code gen that css file ahead of time and um kind of just reference it from the webpage itself Some things you can't do that for so if we say Um, you know block color equals some variable or some expression that is not known until runtime that we can't generate ahead of time So what we found is that for you know around 80 percent of your css properties You can generate css. That's equivalent to what you would have written By hand if you follow the other kind of modular css principles that I lined up Um, but you know in the case that we can't do that, uh, you can always fall back to to hand written css There's no reason why you why you can't use any handwritten css in my opinion You try to write as much inline as you can just because it's like a really nice developer experience But if you really need to fall back to to regular css, that's totally cool um Now the the kind of crazy idea that we're trying out over the last couple weeks And i'm not sure if this is a good idea or not. I'd love for people who know css better than I do to educate me on this Um, but what I found is that inheritance in css Um has some problems when you're trying to reuse components So let's go back to that example of this media object And when I mouse over this thumbnail, I want some tooltip to appear You know in the in the browser now There's a lot of different ways to implement tooltips one common way is you surround this element with a position relative container and then you position the The tooltip You know as a child or you put that the tooltip as a child of that element and position absolute it into the right spot So while it doesn't look like it's a child element of that that container it actually is So let's say that we we've implemented this some other teams, you know pull the tooltip component off the shelf You know combine it with this media object And we render it in our app Like this so we we've added the tooltip object to the media object component And let's say in our application. We want to render the kind of caption to the right of that media object in small caps So if we add that that uh css rule here at the bottom We just say dot app, which is you know our class name right there font variant small caps We get the desired result without the tooltip But if you didn't actually mouse over Every one of these in your production application Or in your staging environment You might not have realized that you also style the text of the tooltip and if your tooltip was supposed to be using You know small caps in another way or um any one of these inherited css properties You've actually kind of accidentally styled the tooltip when you didn't mean to style the tooltip So there's um a couple ways to to deal with this The first one is you like the tooltip maybe should explicitly provide all of those Kind of base styles that it expects, but I don't think it's reasonable to expect all component authors to do that So the crazy idea is what if we applied a css reset to every component? In your hierarchy to opt out of this inheritance, which you know, it kind of makes sense right? We we apply a css reset to our entire page And if you think of your whole page as a component and each of subcomponent as like a mini application in and of itself It kind of conceptually makes sense to kind of reset to a blank slate environment but What gets a little bit weird is a lot of times you do want to actually set the font face for You know all children of some subtree of your components or you do want to set the color or the mouse pointer So my proposal is rather than just get rid of inheritance entirely. We want to make it Opt in rather than opt out So if you want to style a if you want to change the font face of something You can either say, hey, I just want to change the font face of this component Or I want to change the font face of this component and all of its children So I think that's a pretty interesting idea We're in the early days of implementing it on a pull request Again, I've never used this particular technique in a production app So I don't know if it's good or not But I just think it's an interesting thing to think about because if you look at any other ui construction toolkit on any other platform Nobody has anything like this. Um, so I think it's one of these holdovers from the days when CSS was meant only for documents And again, you know, there's a couple performance things That I think will make this difficult to push to production in all use cases, but I just think it's an interesting experiment So at the end of the day, um, you know, I think that CSS was great for documents and For people that are developing more content heavy sites. Um, I think CSS is uh, is great Um, I'm not an expert in that though. So maybe someone disagrees with me But I don't think it's particularly well suited to the needs of 2016 apps I think if you were going to sit down this year and be like, I'm going to build a way to style apps You would not come up with CSS Um, I think that rather than reusing chunks of CSS and CSS classes, you should reuse components Um inline styles, I think are really fun to develop in they've historically had a lot of problems But I think those problems can be mitigated and we have an app in production that does mitigate those problems So it's been pretty good for us And I think there's some really interesting future work around inheritance that we could explore That's all I have. Thank you guys I wish we could uh, cue print controversy here as a little like lead segue into your inside the actor studio chat Come on over this way Uh, we've got a bunch of questions Uh for you How do you feel after your controversial talk to a bunch of css people? Everyone seems really nice Everyone seems nice. You're still on stage. So Um, all right, so we've got a few talks and folks. Let's um, Let's go here. So one thing was Oh Sorry, since I just love that How can you leverage feature detection and still adhere to component based styling? um, we generally would I know this is bad, but facebook does a lot of user agent sniffing and uh, I Don't know developing in desktop apps with flexbox. I haven't had to do that much feature detection Um, because I'm only targeting every green every green browsers at this point. Um, so again, this is a little more experimental Um But yeah, if you really need to use um, like modernize or one of these things You can use your your regular css techniques. Um, you just don't need to use Style sheets for all of your layout You know, I mean like a lot of times I'm just trying to line up like two or three boxes And I just don't want to bounce between style sheet and my my js code okay, um To follow that up. What happens if Your javascript breaks and your markup isn't semantic and you're on a slow network connection Or someone's trying to use your app from a place where? Uh, 3g or 2g is the norm. Well, there's there's a couple things there First of all just because you're using this technique doesn't mean your markup's not going to be semantic um, if you think about css and the browser as a render target and you have whatever abstraction you can dream of that eventually renders down to the same result um, I think it You don't have to accept that you're not going to have semantic markup You can generate You know just as you can generate with with the right tags and with the right um the same kind of hierarchy that you otherwise would have In terms of like what happens if the javascript breaks This is a little more of a um Of a js framework question React in particular support server side rendering where you can render out a page You know from the server push it down and then you know when the javascript on the client kicks in It will like take over that markup and and attach event listeners and stuff like that so I don't know uh They're they're like it does work on the server Um, and I think that's the only answer that really so take care to make sure that you can actually render it on the server In case that that happens. So like how does facebook deal with it because I know they're You know internet for all and accessible all over the world. Is that the So I don't work at facebook anymore. I don't speak for facebook. Just everyone knows um Facebook uh renders the Um interactive parts the parts that need interaction with javascript and it still does a lot of server side rendering You know and they're exploring a bunch of different ways to to change how that server side rendering is done But when I was there it was still largely php Uh, how does something like react fit in with web components? And what are your thoughts on web components where like css is a part of it? Yeah, um I really like web components Why don't you like web components? this is I think So I think the style and encapsulation is cool Um, I think the what we've been promised from the kind of shadow DOM spec Of like being able to customize a select box Awesome, really excited about that Five years later. We still don't have that. Um I don't think the way that components communicate web components is is particularly good um I don't know Yeah, that's about it So my last question How do you see like the these sort of philosophies of react making their way into other frameworks or other Basically like not being totally married to the react system. Do you see that happening like flowing into let's say Other js frameworks or other ways that we think about the web Uh, but is it possible to do that in a way where we don't kind of give up the core? Philosophy of tim burners lee web for all like the the beauty of sort of css and html is like boom I've done it And I think you do a good job in talking about the distinction between like hey I'm making an app with like this use case. This is a totally different use case than your document um But do you see any of that? Um design philosophy percling in well, there's a lot to to dive in there Or dive into there the the the first thing is like I kind of trash on on the You know trying to shoehorn this like document this model I was developed for documents into developing apps because like I've seen what the consumer Like startup world is doing and the consumer tech world is doing and they're just like Web can't deliver the experiences that we want So we're just going to ship on proprietary platforms And now people have to download a binary before they can use the app And it's got to be signed by apple and then you got to like talk to them before pushing an update And that's that sucks and it's less democratic And it's a lot harder for some kid to just like open up web inspector and start writing code So I think that that movement's pretty bad And I think that we need to to kind of Look critically at our abstractions and say hey, you know It's 2016 the fundamental building block of like every social app is this component called UI table view on ios Where it's it's like the instagram main feed, you know where there's like these photos that scroll and there's sticky headers You can't build that on the web and it's like It's been the most important component for a long time on on native apps. So You know, I think that if we can figure out a way to to kind of give Framework developers the the abstractions that they need to build Kind of performant applications. That's that's really great. So there's the extensible web manifesto, which was popular a couple years ago Seem to be going in the right direction Like I think if we could just give everybody Web gl and shared memory parallelism And maybe like a text rendering engine We'd be We'd open the door for a lot of cool stuff I'm not I think I went off on a tangent. I don't know if I actually answered your question It works. It works. Um, I think our other speaker is gonna want to speak anyway. So that'll be a nice way to end Okay, cool. Thanks so much. Thank you guys