 and training shop called Prototypal, you may have heard of me. So I'm giving a talk that's kind of generically titled right now, Taming CSS and number JS apps. I'm curious, how many of you have already seen this talk? So I've been refining it and so it's not really the same talk if you've seen it already. So there's some, I've added a bunch of stuff to it and you'll hopefully appreciate that. So anyways, I do training stuff, check it out, Prototypal.io, that's my plug. All right, so show of hands, who likes CSS in the room? All right, who does not like CSS? Raise your hand. All right, so it's about 50-50 from what I can tell. But right, CSS is awesome. I don't typically, I'm really lucky, I don't typically have to write a lot of CSS because I work with teams and usually there's some really great CSS guru on the team that deals with most of the problems for me. Just makes things look beautiful. So I would say that I am a practitioner of the trying stuff until it works model of CSS development. And it's kind of this weird phenomenon for me because I go work with a great team and I've worked with a lot of great teams over the years doing Ember Consulting and when I'm by myself, I feel somewhat crippled. I can't actually deliver the same quality of work visually that I can when I have a great CSS guru on the team and obviously having great designers is important too. And so CSS frustrates me. I feel like sometimes I'm still doing web development with assembly. And every time we build a new application, there's like lots of problems to solve even building on top with Ember and sometimes I just want a button that has all the appropriate states that a button should have that works on desktop and mobile and all these things and wouldn't that be nice? And I think, you know, from that desire, it has led me to focus a lot of my attention on CSS over the last couple of years and so I think CSS is actually great. But why do I care about CSS and why do I think you should as well? So well, I got started by kind of giving a lightning talk at EmberConf a couple of years ago in 2015 and I wrote an ad on like in a couple of hours before EmberConf called Ember Components CSS because I had like been feeling this problem for a long time. I work with a lot of different teams. I see like all the different kinds of weird problems that different teams run into and it felt like nobody had good patterns for organizing CSS. So I wanted, at the time we were thinking pods was a good idea in its current form and I was like oh well we have these directories for components, why don't we put a CSS file in it? It seems obvious. Nobody seemed to have done that yet and so I wrote this ad on to do that and then I like actually started thinking harder about the problem of component-based CSS. The other thing that's kind of made me care about this problem is that new pods are coming. I like to call them. There's an RFC called module, is it module unification this thing? Okay. Module unification RFC which is basically new pods so if you've used pods you should look at the module unification RFC if you haven't yet. We're going to be having a new file system structure, it's an evolution of pods and at some point it's likely going to be turned on as the default in new EmberSea liabs. The old style will still work but we're going to have a new default and when we do, there certainly is going to be still that desire for having some kind of styles.css file inside of your directory. If you don't know anything about module unification RFC you should watch Robert's talk to member NYC. There's going to be this need for Ember having some kind of story for how CSS gets organized in your app and it's actually a complicated problem. I don't think we just want to concatenate all these files into one big file. I think we want to do something a little better than that. I also want to just make writing CSS as enjoyable and mechanical and predictable as I feel like writing Ember apps are. I've talked to a lot of people about this, once you get up the learning curve and you're building a big Ember app it feels like it's a bit boring after a while because it's just like, oh, the same thing, repeat the same pattern here or the same pattern here or just a little bit different. That's nice. That helps your velocities. I want to feel that way about CSS and not feel like, oh, I made some small mistake and now it has had widespread problems in my code base. I think it's important as a framework for us to help people fall into the pit of success continually in every regard that involves our programming model. I feel like CSS is one of these places where we don't have any good story. There are add-ons that have stories that are pretty good, but we don't, as a framework, have a story which means that the knowledge of an Ember developer might not, regarding CSS, might not be portable across teams like the general knowledge about Ember is. It'd be nice for Ember to have a story for this and for somebody who's new to web programming to not have to know all the different CSS methodologies to avoid the common pitfalls that you're likely going to run into and you probably won't realize you've ran into them until it's too late and you've written a ton of CSS that now you have to refactor to perhaps be a bit more friendly to your app at scale. I also think, and this is actually like I'm burying the lead here, I think this is actually the most important reason that Ember needs to have a CSS story, which is that if you ask, there's probably a lot of add-on authors in the room. Raise your hand if you have an add-on that includes, that should include CSS to some degree or does already. If I asked all these people individually right now and said, what's the story for you including CSS in your add-on and making it accessible or customizable to your add-on users, I would probably get at least three different answers. There's actually not a great story in the Ember add-on ecosystem right now for styling extensibility, even just how to include CSS so that it's ordered properly in the build output, it can be a problem. I think right now the best solution is basically your add-on needs to give SAS to the user and then the user has to manually import the SAS file somewhere in their file and that's not a great story. It's fine for importing, but now I want to customize the way it looks. How do I do that? There's not really a story for that and that's unfortunate, I think. Speaking more generally, there are some problems with CSS that I want to just point out so that, my slide blank, what happened? How long? What slide did that stop at? Anyways, we want to make everybody fall in the pit of success. We want to have best practices for our add-on ecosystem. Here are the problems with CSS in brief. CSS is kind of a weird, global-based programming model. I'll talk more about that. Lack of modularity, encapsulation, and isolation primitives are pretty flat. It's very difficult to refactor and remove dead CSS code or even know that CSS code is dead. It's not used anymore. A lot of my early thoughts were based off of a great talk by a member of the React Core team. You should check out this talk, although I don't think that CSS in JavaScript is actually the best answer for this. I think one of the things that we've tried to do in Ember has always made the framework, we've learned a lot of lessons from our parent project. We came from Sprout Core and Sprout Core had a very tough learning curve. We thought Ember was hard. You should have tried to use Sprout Core and extend its built-in UI components, much, much harder. And so we believe that if you understand HTML, CSS, and some basic JavaScript, you should be able to be proficient writing an Ember app. You shouldn't have to learn anything super, super custom. HTML and CSS are very powerful. We should embrace them, perhaps augment them. And so I've tried to formulate a lot of my thoughts on CSS and my solution exploration to constrain us to actually still use CSS. I think it's a little easy to just quickly be like, you know what, it's easier to just solve these problems in JavaScript, so I'm just going to run and use JavaScript instead. I think that's fine. But I do think for widespread adoption, it makes sense to still keep CSS and CSS. So let's talk a little bit about globals. So what do I mean by globals? Well, every rule you define in a style sheet is now effectively a global variable in your application. So the good news is that there are approaches that have been created in the CSS communities, things like BEM, SMAC, SUIT, et cetera, their methodologies for how you write CSS and organize it. They've come up with some good solutions to these problems that are not super sophisticated, but they're basically naming conventions. So if you have a nice naming convention, you can basically avoid some amount of pitfall of potentially globally leaking unintentionally across styles for one component to another, something like that. There is somewhat good news as well, which is that Shadow DOM is coming. So Shadow DOM is a nice primitive that gives us style encapsulation. I don't know that it's going to be a total solution to all of the problems that exist in this space. I don't really think it is. I think it's a nice primitive. I would like to see something a little more primitive from it. But it's important to think about that and plan for it in the future. So I've been trying to think about that as well. So just an important thing that I would challenge you to do is when you're writing CSS or thinking about problems in CSS, I would ask that you actually try to convert them, take the problem, and say, if this was JavaScript, what would I do? And that I think it's actually a little hard to do that to some degree, especially if you're a CSS expert and you have a lot of dogma around the way that you write CSS already. It can be a little challenging. But CSS is really unlike any other programming language where this kind of global-based programming model and the best practices that we've all been indoctrinated with, to some extent, really force us into a way of thinking that I think can be, unfortunately, dangerous for building large applications at scale. So the good news is, though, with preprocessors like SAS, we can kind of have something mixed, module-esque. We can have separate files. Without a preprocessor, there's no way to actually have separate CSS files that don't end up being separate HTTP requests. It's like with JavaScript modules, we want to take a bunch of individual files, squash them into one, and send them down. We can do that with a preprocessor. So at least part of this problem is somewhat solved. But when we kind of think about the talking points around refactoring or being able to delete CSS, it's actually pretty tricky to do these things. And I believe that part of the problem here is a lack of encapsulation. And the patterns that we use to do composition with CSS are a bit broken. And they make refactoring very difficult because they intermix concerns from the provider of the base styling and the consumer of it who might be overriding things. So I think this is best demonstrated by the idea of being able to use something like Bootstrap. Let's say you started using Bootstrap in version 2. And maybe you did some amount of custom overrides using sass or less variables to change the colors. And then you did some amount of overrides that were runtime class augmentations. So you had like BTN My Theme or BTN My App that you added on top of a BTN. And it made it look the way you wanted. Well, now when BTN, when the button in Bootstrap changes, you have made a bunch of overrides. But the way in which you overrode was coupled to the implementation at that exact point in time. So if Bootstrap wants to change the way that its classes are defined, like if it wanted to start using a different CSS property or something, well, your override was written to assume that it used certain properties previously. And since you've coupled like that, there's no encapsulation. There's no actual public API between these two things. And it becomes this ball of mud, which makes it very hard to upgrade things like Bootstrap certainly within point releases. But I'm sure they put a lot of effort into not having breaking changes in minor point releases. But certainly Bootstrap 2 to Bootstrap 3, I'm wondering, has anybody been able to successfully do an upgrade like that before? Has anybody, like usually what I've heard people say is we just give up and rewrite a lot of markup, basically, or we'll rebuild our components to be Bootstrap 3 things instead of Bootstrap 2 things or whatever. It's very, very difficult, and I don't think it should be. So I think the main takeaway, my main insight here is that I think we actually need explicit public APIs for styling. And so I think, like I said, this is the big point. We need an actual API between our implementing component and our extension on top of it. And components already have public APIs. We use this kind of stuff all the time. Why don't our styles? And I think functions are a good metaphor to kind of think about this problem. So functions take arguments and they return values, and in components, they do the same thing. Components are like functions that render a template and return DOM. And so we give arguments to our function, and its return value is dependent upon those arguments. They tend to be pure a good amount of the time. And the issue is, I think, at the crux of the problems in CSS is that CSS doesn't have functions. And so there's no actual way of having some kind of indirection or some kind of local scope that you can work within and that doesn't leak out to the world around it. And so the good news is that SAS kind of has a function primitive that makes sense, I think, for usage. And that is mixins. So SAS has mixins, and they're like functions that take arguments, and they return CSS rules that have had those arguments interpolated into them. So you could imagine having a pattern where you write a SAS mixin for your component, and then you can import, you can actually use that mixin to define rules that are scoped to some particular class name. And if you had nested rules in here, you can use like ampersand to have them concatenate against the main selector here. But these functions are these primitive units of work, and you can't really have composition without functions. And so it's hard to imagine building ambitious applications like the ones that we're all building without a composition story. And I think we've been kind of for too long accepting of the status quo for styling. Just like a lot of developers don't have to deal with it, so they just don't worry about it. But I think it's actually a limiting factor to our ecosystem being able to grow and flourish. And so I have some ideas on how we can solve this. I think it's not super controversial at all. I don't think that the idea that we should be able to organize our CSS around the components who have templates that use that CSS. And ideally, when you define CSS in a component CSS file, that CSS should only be used by the template for that component. And if you had shared CSS, that wasn't just another component that you called from more than one place, you could imagine having doing what you would do in JavaScript where you would create some module where that was shared across multiple components and just import them and reuse the same things. So you can imagine this model working. And number component CSS has a story for that today to some extent. I think the other solution that we kind of need is actually a mechanism for actually name spacing our styles to be globally unique per component. And I've taken just, I've borrowed the syntax of BEM. If you're not familiar with it, it's very, very simple. It's BEM stands for block element modifier. And basically block is always a component in number. So the idea is have a naming system that's prefixed with the component name. And then it does like a double dash or a double underscore and it either you have like the element name, which could be like some sub part of the DOM inside of your component. Or you can have a modifiers which are like disabled, loading, whatever that reflects states of particular pieces of your component DOM. So really I'm just borrowing the double dash naming from BEM and you'll see this here. So this is the kind of style sheet and template we would like to be able to write. The annoying thing about BEM is that it's a lot of manual labor. And every time I go around and I talk to people all these problems they're like, yeah, you know, we want to do something about it but we don't wanna manually write out all these long prefixes to our class names and it's really annoying to do that repetitively. And so it would be ideal to just be able to use CSS kind of naively the way that we would expect to. Like the first time we looked at W3 schools and learned about CSS or whatever, we learned how to write it like this probably. And it would be nice if that actually scaled up. So what could we do? Well, we could auto-bem it for you using build tools. So it's pretty trivial in Ember CLI to do something like this right now where basically what was a foo class name in your My Component CSS file, we could actually rewrite that to be BEM for you and then also when it's referred to in your components template we could also auto-bem it there. And so you get to kind of be naive and enjoy the non-verbosity of BEM but get the benefits of it, right? So that's cool but really there's still a problem here which is that somebody on your team who doesn't quite understand what might be going on, they might look at the element inspector and see like, oh this thing looks the way that I want it to and they're going to want to grab that CSS class and then use it in another place, right? The proper way of doing that would be to hoist out the shared CSS into a mixin that can be invoked by both components or whatever per se but I think it's important to actually kind of be a little defensive about this and potentially have some kind of hashing mechanism where basically we can generate something that's a little ugly, perhaps in dev mode to prevent people from making these kinds of mistakes. So you could also imagine by the way in like production mode we could actually minify the selectors which would be interesting, it would reduce our CSS payloads. So the problem right here though is that like this is a cool system for auto-bemming basically which is neat but it doesn't add anything really to the composability and extensibility story to make us move towards a path of having an actual public API for our components styles and when we might want to override them and so I think we need functions to pull that off and so like I mentioned, mixins are a good technique for doing this and so you could imagine being able to write this so we're writing a my button component and this button let's say has a public API it only expects you, obviously there will probably be more than more variables here but basically it only expects its border color to be changed and simply by having this argument available for usage from other consumers potentially want to create a primary button that has a different border color we could actually create a primary button component that changed the border color but didn't actually change it in a way that meant that its implementation was locked in so that it was locked into the implementation of my button at any point in time so we've added this kind of function barrier here which lets us have some amount of interaction so in this case it might seem silly but if we attributed the border color if we added the border color to the element in some other technique I think a good example for this is if you have gradient borders if you want to do gradient borders it's actually you have to add some markup do a gradient background and then inset another element one pixel around it or however many pixels your border color is or your border width is and so basically different markup hierarchies and different CSS styling techniques could actually break your overrides but with a system like this we actually can choose where to apply this variable, this local argument so this is kind of very verbose I don't want you to have to write this in every single for every single component so I thought that Ember component CSS could give us some sugar which would be at component and at component basically is just expanding you could imagine it as string replace in a build tool that's like at component replace with at mix in whatever the name of the CSS file is so in our case here this is akin to writing at mix in my button but we don't have to repeat the component name that's also nice if we rename files or if this is a pod and we rename the pods directory all these names will be appropriately synced up we won't be repeating them so the other cool thing here is that Ember component CSS actually includes it by default there's basically a naming convention right the mixing gets named the same thing as the component we invoke the mix in automatically for you all right so cool story Eric here's basically the primary button example so if you wanted to create a primary button component all you would have to do is simply pass in a different color into the mix in provided by my button and you can imagine this working pretty nicely so with a simple mechanism like this you actually end up encapsulating the styling of the underlying component that you might be extending and so this might not seem all that useful for the kinds of components that you're building in your app but it's actually pretty important to solving some of the bigger problems at large with doing styling overrides and styling in a large ecosystem so I really think encapsulation is like the crux of the problem in CSS and having some kind of primitive for encapsulating helps solve a good number of those issues that I identified before obviously the BEM style rewriting and stuff those two so let's talk a bit actionable here what's the plan forward so I want to ship an Ember component CSS 1.0 that does a bunch of stuff for you so first of which it would auto BEM so if you had that CSS file defined it would automatically rewrite your classes to be globally unique I also want it to do some linting so there's some obvious bad patterns that you should not be doing inside of a component CSS file that will cause styles to leak outside of it ideally you want the styles like I said earlier you want the styles you define in your component CSS file to only apply to the template of that CSS file and so we're gonna need some good linting tools to help you avoid shooting yourself in the foot incidentally I think it's also very important to have a purview for the future and I really think about Ember component CSS as kind of like building a bridge to Shadow DOM potentially because a lot of this build rewriting stuff could potentially just get turned off once every browser you support supports Shadow DOM and the build system could actually generate you CSS files for each shadow root automatically or something and so I wanted to have a story for onboarding the Shadow DOM so maybe there's even like in one I wanted to at least have a story like I want to make sure that it's compatible forward compatible with Shadow DOM but it would be cool if in 1.0 we could also actually have a switch like if you only cared about supporting mobile like specific modern browsers that had Shadow DOM support you could actually turn off some of the build rewriting stuff and just use Shadow DOM instead should be kind of cool there's also the idea of having JavaScript module API to actually being able to import your CSS files from JavaScript because sometimes there are variables or values that you don't want to repeat twice you don't want to have the value be in your style sheet and in your JavaScript code ideally you could have those variables or those values from a class definition be accessible from both places and so I think that would be a cool thing to explore as well so my intent is to ship a 1.0 of Ember Components CSS and then soon after submit a CSS RFC to Ember because I would like to make Ember Components CSS the default in Ember CLI so when you install Ember CLI you create a new app you're gonna get Ember Components CSS built into it but there is a blocking problem here basically the new pods RFC I think it doesn't really make sense to make Ember Components CSS a default until we switch we start using new pods and so once new pods gets implemented that would be the time to start talking about it I think it also might be blocking it's not strictly blocking the release of an Ember Components CSS 1.0 but I think it would be kind of weird to ship it without making sure that it was compatible with new pods but that might be possible without it being a hard blocker so when can we have it I hear this question all the time there's a lot of people that wanna use this now I don't you know I wanna ship it my intent is when new pods ships I want this to ship alongside of it because there's gonna be some class of new Ember user perhaps that's going to or existing Ember users that switch to new pods or are using something and they want to have a story for the CSS files and I don't want there to be any gap in having a story for CSS in the new pod format so that's my intent but it's going to definitely take longer to like get it through the RFC process and all the bike shedding that involves to become the actual default inside of an Ember app or something and I don't know that's kind of my ambitious goal but it may never, I may not survive the bike shedding so that could be it but it's not so I am very frustrated with the way that we build Ember apps today primarily I think we are all actually still in reinventing a wheel we have all bought into the promise of Ember and not building our own frameworks but if you are a large company or even small companies as well what is probably one of the first things you do when you start building a new Ember app you're probably going to have to build or find a bunch of components to implement your app with and there's no actual like standard library of components Ember has some components it's actually shed its standard library there was a select component that was not very good that got removed for good reason but it doesn't actually have a good standard library of components so what do we end up doing we end up either assembling our standard library in our apps by building them ourselves or using add-ons from the ecosystem but what can that mean well that could mean like I am installing a bunch of Ember add-ons but the way that I have to style each individual one is completely different than the other and there's no actual guarantees that you don't install Ember add-ons that have conflicting CSS with other Ember add-ons I've heard recently a story of somebody installing like a tooltip library and the add-on expected to be able to use a class name that was used somewhere else in their app I think Bootstrap was using it or something and so they actually had an experience which I don't think is acceptable in the Ember ecosystem of Ember installing an add-on and it not just working it should just work and so I think that's why Ember Components CSS is important for the add-on ecosystem but I also don't think we should all be styling things or overriding styles in many different ways we should have conventions for doing that and so the reason that I've actually cared about this CSS work so much is that I think we can build higher and we can build cooler things on top of these primitives and so I really think there's a huge potential to unlock new abilities and new abstractions with if we shore up the styling story in our ecosystem and so one of those things is theming I really would like a story where you can basically, you know, Ember install a theme and all of the components in your app get auto-styled based off of some consistent theming format I think that it's just a matter of building up conventions it's obviously a very hard problem theming is not just CSS theming also involves potentially being able to override JavaScript and HTML markup to achieve the desired result that you might be wanting to have in your app or your theme I think another thing that would be awesome would be automatic style guides like why do we all build style guides manually if there was a conventional way of defining some demos for our components in add-ons then every time you ember installed the component you just installed could automatically show up in your style guide that would be pretty cool and if you imagine having both an automatic style guide and a theming system that would be that automatic style guide would be a pretty cool place to play with customizing your theming because you'd be able to see all of the components that you have installed in one place so I've been feeling like maybe we should build a standard UI library for ember that has theming support and then we can start on level five instead of level three of building our apps right now ember gets us it's better than compiling our own going out finding the right kind of boilerplate that we're gonna need to do our build tools and all this stuff we get to start on a nice stable ground a nice foundation but we then end up and every company I work with has their own versions of different kinds of components I've probably seen 15 autocompletes and they all have problems every different company's UI library has some different variations some are good at something some are bad at others almost nobody does fully baked accessible UI components and if we actually rallied around building a single good standard UI library we could actually have amazing accessibility automatically in every single app we could have good keyboard for focusing like an actual modal that worked for every use case and so I've built some prototypes of these features already I've been working on this stuff for a while and I want to show you a little bit of a demo of what I think is possible so let's see if this is gonna be I have pre-recorded some gifts here so let's see if they work okay so this is an example of a style guide that's getting automatically generated and it has a little theme editor on the sidebar and as you modify properties here in the theme editor it's actually hot reloading the CSS and you can actually see as I change certain properties like the default color, the font, the background color, and the border radius in these cases the components are auto styling themselves and all these components are built in a standard way that assumes certain styling abilities and so you can have the concept of a global theme or even some sub contextual theme and be able to just change a few variables like you probably already have if you're using Bootstrap or if you've built your own system you probably have some form of variables but the cool thing about this is that this isn't just limited to CSS so let's look at this next demo here so this is an inspector so sometimes you have global things but you also have component-specific styleable properties so what if you could actually like in the elements tab of DevTools click on a little magnifying glass click on any component in your app whether it was in your actual app or in the style guide and immediately see what the styleable properties were for that component that would be very, very cool so if you wanted to start with global kinds of overrides you could do that pretty easily but you're always going to potentially have some edge case where like maybe on this maybe on my buttons I don't want border radius so I want to be able to choose the button in overrides border radius specifically and then of course you could also imagine being able to swap themes in an actual app so here's what we call our base theme here and we've been playing with writing different themes and so we've got like an alternative theme here that just renders with vibrant colors you'll notice the theme editor and the style guide UI here which I'll demo in a second is actually written using the component library so as we change the themes its buttons are changing and here's a material theme so you could imagine not needing to have specific component implementations for every specific kind of look and feel you could imagine potentially being able to write some kind of theme now the cool thing is that themes are not just CSS in this system they're actually uses a form of component delegation so we have common UI components that you'll use like the buttons and the text fields and everything that you use in your app aren't actually tied to a specific theme but based on what the current active theme is they delegate to a different component that's responsible for rendering them and those components can be implemented by themes and they can choose to just write CSS or they could choose to write handlebars and JavaScript as well to change their behavior so we can implement a very sophisticated kind of system like material design is a pretty sophisticated visual theme because it has many different behavioral changes it does nice little ripples and stuff and that is fully possible with this architecture right now so these are the pre-recorded demos let me just show you briefly how am I doing on time here it is an action now something that I didn't have a pre-recorded demo of which I think is pretty cool is that part of the style guide is toggling between different forms of the same component so like we have a default button style but we also have I don't know how to I don't know what to call these yet I'm calling them kinds currently or traits so there's like a primary button just a variant of default and so in the style guide you can actually see and this is automatically generated we can like we can read we can see what components exist in the component library or what components have been installed that are third party that's subscribed to the contracts of this system and we can automatically populate the style guide with the appropriate buttons and stuff here so there's default and primary now the other cool thing we're doing is we have a standard way of defining states of a component and states in this case is a pretty generic concept I would say the idea to think about is that you know buttons are in active states focus states, disabled states so that's the kind of but you could actually create arbitrary states as well so the style guide also supports automatically letting you see and interact with all these components in their different possible states so here's the button in its active state and I can toggle that off and just choose to disable it as well or I can focus it see what it looks like when it's focused and also look at it in its loading state which is not like a CSS typical state it's something that I augmented it with and so these buttons have a loading state as well and this is all well formed there's a conventional way for building these things and defining these states so that the style guides can also automatically display them for you and these are not mutually exclusive either so you can actually if you wanted to if it was possible for a button to be active and disabled this is what it would look like so these aren't just always mutually exclusive states they can be concurrent currently so let's see I don't know how much there really is all that interesting to show here but you can kind of see we've been playing with a bunch of different components to play with the different kinds of styling APIs I think one of the things that's pretty interesting here and I don't know that this is the best page to demo it on let's see so we've been working on a nice responsive table that has a very nice API that allows you to basically define the table's layout as different breakpoints so you can imagine at certain screen resolutions it switches to being a list instead of being more of a great kind of table and this kind of stuff is pretty neat and we've been trying to exercise out this kind of theme these theming primitives to build some fairly complicated things but all that said let's go back to our slides here so that's a little bit of demo of what I've been doing behind the scenes playing with these CSS primitives that I want us to have in the Ember ecosystem we've been kind of promoting the idea that Ember is the SDK for the web but we're only really starting to scratch the surface I think of what's actually possible I think we can really build higher and I really want to build a lot of these things because I go around to many different companies do consulting and training and stuff and everybody ends up kind of doing the same thing and we should just share ideally have a standard component UI layer that we can all share and we can custom it should be customizable enough for us to get the right look and feel that we want in our apps but without having to write all of that code and maintain it ourselves and so I need your help I'm giving this talk as a pitch to help me because there's a lot of work to be done here and so if you're interested in this kind of stuff please reach out to me and let's build higher together so that's all thank you