 Hello, Arcade again. My name's Wei. I am a React web developer. You can find me with this unsyllable handle everywhere. In my spare time, I enjoy spamming this world with many, many websites. And what this talk come about, I'm going to talk about styling today. And what this talk come about was a workshop I did last Saturday on styling a Gatsby site. And to prepare for the workshop, that made me put in a lot of thoughts and research into how we style a content-centric React site. So how many of us build your own blog? OK, a lot of us. Do you use Gatsby Starter, or do you build your site's own styling? Own Starter, OK, from a starter. I wonder what's OK. So whenever I build my site, so in the beginning, I also use a Gatsby Starter. Then I realize I have more customization needs. Then I started to build my own styling. And I become very opinionated about styling my own site, which I'll show you in just a bit. But maybe without us even noticing it, React is changing the way we write styles. And what do I mean by that? So with writing code we React, we're changing from the page-based or template-based mindset on the left towards component-based mindset. And how specifically does that change the way we think about React? So first of all, we're thinking more in terms of contexts and components rather than in terms of the whole page, a flat-out page. So specifically, a context must preserve the need for different components to live in. And then correspondingly, the components must be adaptable to different contexts. We're building the component with the assumption that it lives in multiple places. And we're putting in a lot of props to describe what kind of components they are. And there are a lot of opinions set about it. So when I just started doing React, my team lead did not allow me to put a default width to the buttons because the component container will decide how wide that is. So those block-level buttons, they look like insane to me. There are no buttons. But this is something that appears after we build things we React because we want the component to not be aware of or to pick up certain styling or layouts from the context. When and why did we start to have the needs of namespace CSS? Has anybody ever thought about this? It seems to me that it's because we're writing way more components than pages. So when we're writing, and the components that we write are not supposed to know about each other, we're writing a button and we're not going to name the class name button because we don't know whether somewhere else is going to use the button or not. So that is pushing us to namespace our CSS over the place. And then nowadays, Bill Step is writing our CSS. I don't know if you notice this, but it's messing with our thought process with CSS selectors. So initially, when we write vanilla CSS, our whole CSS file was flattened out. There is no nesting. And we had to use only CSS cascading rules and combination of selectors to try to match the CSS objects with the HTML DOM elements that we wanted to style. And apparently, some of us cannot resist the temptation to nest selectors, while some other of us just keep seeing the evils in it and attempting to prevent us from nesting those things. And I think even till today, I still don't think we have a unanimous conclusion on whether we should nest selectors or not. And I think what can be even more confusing is that the build time tooling is non-trivially writing our selectors during build time now. So CSS selectors are now harder to reason about. Sometimes, if we use some CSS and JS libraries, maybe that takes away some needs of even writing a selector. You're matching your logic, your data directly to the styles. But that doesn't take away everything. And so that is making the whole thought process a lot more complex than previously. So sometimes, we're going very scoped into component styling. And that feels like a color book game and not real drawing. So that feels a lot more definite than expressive. So I read this article, as I prepare for my workshop, and where he talked about these things. He talked about more things. But he talked about two things that rings a bell in me. He talks about spectrum and responsibility. So what does he mean by spectrum? Can I put this in one? OK. So there is a spectrum of globalness and component. Vanilla CSS is very global, whereas CSS modules can move slightly towards component. And then CSS and JS libraries, they're only ways to write CSS. There are libraries that deal with very global objects. But I think most of the CSS and JS libraries are built to foster styling the component. So it can go even very extreme to the end where you can actually write your style plus your component in one single file. So I would not say that the whole CSS and JS world is towards a component-based mindset. That is not true. But a lot of CSS and JS allow me to go further away towards that spectrum. And then he talks about responsibility. So theme objects such as typography information and those more foundational styling information now becomes the responsibility of a global object. And then dynamic information goes into components. And I think so a refreshed understanding about components is that it doesn't necessarily mean a smaller area of the screen. But a component can be responsible for a very big area on the screen such as a layout. But it can have a very thin layer of responsibility that it only deals with how the page layouts everything. It adapts to viewports and these type of things. But they nowadays go into the responsibilities of components and they're very dynamic. So are these the only ways to think about styling? I don't think so. So does everybody know what universal CSS is? So traditionally, we write CSS object and we have a bunch of CSS values. We call them border top 1.04 em dotted light gray. And how about we turn each of the CSS values into a class? So border top 1.04 em dotted light gray becomes border top with 1.04 em. And then the dotted light gray, these are shorthand properties. So these are separated border tops dotted and so on and so forth. Is this a joke? Of course it's a joke. Use semantic CSS class names. But just to have fun, I built my whole site using universal CSS. So the styling of this whole site, you can inspect later on. The styling of this whole site lives in one single CSS file. And then when I need some specific styling, like when I have to do styling for this thing, I use CSS ingress to inject the styles. So oops. Go back to A. Oh, really, it's a bug. OK. I have something to do tonight. Then really, it's bugged. Oh my god. All right. OK. So the final thing I wanted to talk about is that the fact that there is no unanimous conclusion on how we start a site for me is something that's really interesting about this whole topic. Because you can try out everything that you find interesting. And in the same time, generating your own thoughts or your own attitudes on how you style your site. So I hope we'll all put down the color book and go back to drawing again. All right. Thank you. So I can take this off now. And then now I'm no longer a speaker or a button.