Hasty Treat - Stylin the Unstylables

Monday. Monday. Monday.

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest TS, web development treats coming in hot. Here is Wes, Barracuda, Boss, and Scott, El Toro Loco, Tolinski.

Welcome to Syntax.

In this Monday, hasty treat, we're gonna be talking about Styling and the unstyllables.

And you might not think about this offhand, but there are a number of things that are insanely painful to try to CSS in HTML. HTML.

And me, I like CSS and stuff. So we're gonna be talking all about the different types of things that are difficult to style in CSS, a little bit about how you can style them, and then Some future tech around this same subject. My name is Scott Talinski. I am a developer from Denver, Colorado. And with me as always is Wes Bos coming to you from the full stack shack.

Yes. I'm out I'm out here. Internet is a little bit better today, so me and Scott are having a decent time talking. Absolutely.

I thought you I thought you had more there. So, yeah, I'll pick it right back up. Yeah. We're having a great time talking. And in Queen, this episode and the other one just dropped my, new hedge trimmer just arrived, so shout out to the hedge trimmer that I was very excited about in the last episode that we just recorded.

This episode is sponsored by 2 excellent sponsors, and I'm talking about Sanity and LogRocket.

Wes, would you like to take Sanity, and I'll take LogRocket?

Yes.

Sanity is. They I love it. They've every time I visit their home page, they've They're they're very clearly distilling down what it is they do, and now their website just says content is data. So, basically, It's a CMS where you can create your content types. You can create relationships between the 2, and then you pull that data into whatever UI you've wanted, whether that is I I've talked to them about some pretty cool use cases that they've used it for. Obviously, pull it into a mobile app or a website, site, but it could be pulled in literally anywhere.

So I really like it myself. They have this really slick thing called Sanity Studio, which is, I'm gonna say, the best Editor I have ever worked in. If you've you've been using WordPress forever, check out Sanity Studio because They have spent so much time and so much work making the editing experience just as an end user, let alone the amazing actual JavaScript that you can write to implement it and pull it in and and listen for changes, never mind all that. But, actually, the The end user editing experience is super super nice. We use it in one of my my Gatsby course specifically because I liked it so much, not because They're a sponsor of this. So check it out. Sanity dot I o forward slash syntax. That will give you double the free usage tier. We're also sponsored by LogRocket. LogRocket.

Session, video replay for errors and exceptions. Now LogRocket is a perfect place for you to see exactly how errors and exceptions happen in real time in a scribble Video replay.

One of the cool things that LogRocket does, you can go head to their website, logrocket.comforward/syntax.

Now one of the coolest things that Loud Rocket does is they make it crystal clear what their product does for you because they they show you very quickly and easily on their landing page exactly what this thing looks like. You can see all the features. So, basically, their little tagline is stop guessing why bugs happen, and that really sells it to me because You get to see the error happen in a video replay that gives you the network logs, any JavaScript errors, The stuff that you're used to when when when debugging on your own in local development, you're gonna get there for things that have happened in the past to actual users and be able to Solve those problems is very cool. You can even guide your users to a resolution with a live co browsing mode, which is, I think that's a new feature because that's not one I've seen before. It's really neat.

So check it out at logrocket.comforward/syntax.

And, again, it works with All of the types of platforms you might be using on the front end, whether that is a React, Angular, Vue, Redux, plain JavaScript, anything you want to use, this thing works with it. And there's a self hosted or an on premise version, the LogRocket cloud. There's a lot of really cool stuff here. Logrocket.comforward/ Syntax, give it a check out and see the magic.

Let's get started here. Styling the unstylable. Can it be styled? What about things, that can be difficult in styling, and how can we style them? So the 1st category we wanna talk about were things that you could just Sort of just style the defaults the best you can. So most elements in CSS, right, most things you can style.

And complex elements when you get into things like let's use a select list as an example. Select list is a complex element. Right? It's not just one thing. You have Kind of like a button interface, maybe some arrows on the side. You click it, and there's an options list. There's a whole bunch there with the select list. And, typically, If you've ever tried to CSS this, you'd know that this is not your standard type of grouping of HTML elements. And even though it is Just underneath the hood, you'll typically see if you if you pop open your browser, you inspect just about anything in HTML that is a complex element. What you'll see is a shadow, and that is the shadow DOM, which is inaccessible. This is The pieces that make up the larger element that you're using.

And this is sort of the whole basis around Custom elements in journal. What do they call those? C s or, I keep on HTML components. Is that what they're called now? Shadow DOM components. Shadow DOM. Yeah. But what do people call them call them? Oh, web components. Web components. Yeah. I couldn't think of that. I don't know why I didn't think of it. Either way, this is the this is basically everything in in your browser is made up of Smaller HTML elements, and sometimes those are obfuscated behind the shadow DOM.

The shadow DOM is not necessarily easily Stylable.

So what do we do here? What do we do with these elements that don't have things that we can access?

Yeah. You we've got a couple options, really. So we'll break it down into the kind of 4 different ways or three and a half different ways that you can style these things. And We're primarily talking about 2 things, inputs and media elements.

Those are the 2 big things in the browser, and I'm I'm not even sure if there are more. Maybe maybe the details element in HTML. But, basically, we have these defaults f. In there, and there's a little bit you can style, and there is a lot of it that you can't style. And if you want it to look a certain way or have A decent user experience, the big one being input type of number. When you use input type of number, you get these tiny little arrows like arrows for ants.

Ants. Yeah. There's nothing you can do to style those things to make them bigger or change the color, Things like that. So at the very basic, we have input and select and checkbox and radio, and they are very hard to style. Some of them, You can provide, like, accent color, I think, is one that is coming to the browser. Will you be able to at least specify what the accent color is? Woo hoo.

Yeah. Woo hoo. I wanna be able to to style everything, at the very basics. I've I've sort of rattled off a little list of CSS properties here that you could possibly style on these things. And, generally, it revolves around font size, color, padding, margin, Background, background image, outline, focus styles, and borders. And past that, there's not a whole lot you can do to actually style these things.

So past that, if you want them to look good or not the browser's default And and that you want them to do something else. And the big like, a a regular input type of text is fine, though that one you can pretty much do everything you wanna do. But if you wanna style the input type of date or you have a checkbox with a radio button that you want to look custom, There's a little bit that you can do, and we'll move on to point 2 here, which is you can start to overlap DOM elements

On top of these inputs to make it look like it's custom. Have you done that before? Yeah. There's a lot of different strategies for doing this, but, typically, I I'm using, like, before and after pseudo selectors that allow you to create content in the DOM. So in CSS, One common technique that you'll see specifically for styling checkboxes or radio or toggle buttons is through the usage of labels and input colon checked To be able to determine if the input has been checked or or or selected.

So you can do this to then have your own custom Checkboxes where you physically are styling a before and after property to maybe use maybe, like, your own custom checkbox. I've done it It's like animated a little check or you're creating these boxes, but it's all relying on kind of rip. It's kind of goofy, right, if you think about it because here we have this checkbox x. And what we're saying is, hey. How about let's not show the actual checkbox, and let's, like, create a fake one. And then we can kind of style it and Sort of fake it, essentially.

And, yeah, this is the way you gotta do it. This is how we basically do everything nowadays, unless, of course, we're rebuilding it from scratch in JavaScript.

Yeah. In the past, what I've done is either using before or after. Before and after doesn't work on every element. I think there's, like, a list of

Specifically, like yeah. Their inputs, you can't use it on because Because they are shadow DOM. Right? Well, before and after inserts into the DOM element. So if you have an element that cannot have a child property, it can't have before or after. So it has to have a child property. That's at least my understanding. Yes. That that makes a lot of sense, actually, because before and after are flex children. They are Child, so what what are other elements that can't have children? Break tag, horizontal rule.

I think I think HR can have a A before and after now that I think about it, but a lot of the input cannot. So if that's the case, just wrap it in a div or a span or or use the wrapped, labels, something like that that's wrapped around it, and then you can I've put backgrounds on specific things that look like arrows in the past.

You can overlap spans or or actual button elements that go on top and below.

You can also If you're just overlapping them, you can use pointer events none.

And what that will do is when somebody clicks on the thing, it will just Pass through the click through whatever you've put on top of it to the element that is below it, and that can be really handy. I I like those because In most cases, you're maintaining all of the accessibility benefits that come keyboard toggles, autofill.

Any special Stuff that comes along with the browser in terms of features or accessibility, those are still maintained, but you're just adding a little bit of Frills on and around it, which is it can be nice. Yeah. It's

it's it's so so annoying, some of the things that you have to do To get just, like, basic styling of things that, you know, feel like they should have been stylable from day 1, but, you know, here we are. Right? It's been this way forever and ever and ever. There there's a, you know, select list too. The select list has some things that you can style in it, and then, like, a lot of it, you can't. And, typically, you'll find people just, like, rewriting this from scratch, which is a whole another way that you could do this is to reimplement everything in JavaScript yourself To have your own list of of potential select things maybe that you're selecting from and have, like, a fake input. And, by gosh, I've done this before, and it just doesn't it's not a lot of fun to maintain. It's not a lot of fun to have, especially when there is a select list Component out there, one that is, you know, nice as it is. And, also, one reason you shouldn't do this, one reason you should just use a select list or have some better kind of fallback here is because Mobile browsers, Safari, Chrome, any of that stuff, they know how to handle these with very custom input selectors that are Tune very finally for mobile. And if you get into a mobile case and you click on a drop down and it gives you some, like, really crabby drop down selector that somebody wrote themselves in JavaScript, It's not gonna be a lot of fun for your users, and that's not super accessible typically anyway. So when I am coding up my my HTML forms, I'm always thinking native elements first. 1st and foremost and only as a, last ditch effort am I gonna be using JavaScript to do anything Fancy there. Yeah. As much as it sucks to style

native elements, I agree with you there. Try to use them as default as you can. When you get into things like autocomplete suggestion, that is actually good. There is 1 built into the browser for suggestions. Yeah. But it's it's not very good. Like, you don't have full control over over that type of thing. That's we I asked on Twitter, like, what is something that you want you

you wish was added to HTML. And a lot of the responses were basically just like good, stylable, commonly used UI widgets. Oh, yeah. Could you, like, a toggle toggle selector, like, that's on iOS? The iOS toggle selector with come on, man. I got 800 of those in my site. It's true. Also talking about,

like, video and audio is another one that is entirely built on the shadow DOM. It's kinda interesting. If you open, like an MP 4 in Firefox.

You can right click inspect element, and you can see all of the elements That make up the video player, it's just buttons and divs and and progress bars and whatnot, and we had to pre implement the entire audio player on syntax. CSF. When we built it, and then you need to make sure that that types of stuff is is accessible as well because it's very easy to make a div that you Click, but then you gotta think about keyboard access and all that. So I would say, in most cases, try to use defaults, The built in native ones or and this is the next one is just use an existing UI library because there are Many, many cases where you need a custom input. And if that's the case, you can reach for

any of the many UI libraries that are out there. What are some of the the more popular ones? Actually, before we even get to that, I I did wanna say something about the video and audio stuff. I've really gone down the rabbit hole of custom video players. I wrote 1 using React Framer Motion to do animation stuff and, CSF. A lot of, like, custom stuff for our video player, but there are so many things you have to consider when doing that. In fact, like, when you when you say, you know what? I'm gonna drop the default video player to go with something more custom, You're opening yourself up to a long time to work on that. So don't don't don't think that's it like a, you know, a a 2 hour project and you're done. That is a big, big project, and it's going to be one that will sit with you for a long time. And not only that, you'll see that there's a ton of video players out there that do different things, and None of them have, like, less than a 100 issues on GitHub because there's just so many issues. There's so many things Pop up, and I I've done I've done the tour of all of them, and I'm actually about to swap out the one that we're using in level up tutorials for another one for a handful of reasons, whether that is Chromecast support being finicky or how how they work, it is a huge, huge world. So just keep that in mind if you're like, oh, I'm gonna reimplement my own some video player from scratch. It's it's a bit of a it's a bit of a task. I just looked up some examples of, popular UI libraries.

Obviously, Bootstrap Foundation, 2 big ones. Ant Design, Carbon Design System, UI Fabric, Fast Lightning Design System, Material Components, Stardust UI. Chakra. Chakra.

I don't think Chakra does input. Maybe they do. Maybe they do. Maybe I'm wrong, but There's a whole whole bunch of UI components that are already built out there, and they have hit every little edge casey thing, every little browser bug because this stuff can be really, really finicky, every little focus

state issue. So definitely would would reach for one of those. I'm interested if web components are going to really pick up steam in this department,

like micro things rather than, like, a UI framework. Maybe that's where web components really take off. That's what I was thinking as well. I was I was like it's because it's frustrating to make a new component for every single framework out there.

And then, also, people are asking for kind of the world from these browser based components.

And I don't think that if the browser were to roll out a set of really good input elements, People would just be like, okay. But I wanna be able to do x, y, and z. Right? And I think that's where web components Come in where you could maybe set maybe even, like, a standard lib of components. And then if you don't like it, you can Extend it? I don't know if if that's a good idea, but I guess that brings us to the next point that we have here. We had Nicole Sullivan comment on, one of our tweets is that I had never seen this. Work is underway over at Open UI. Please join and contribute use cases. So what Open UI is aiming to be is allow web developers to style and extend built in web UI controls such as select. That's exactly what we just said. Style and extent. Mhmm.

Select drop downs, checkboxes, radio buttons, date color pickers. So, basically, they wanna what they're doing right now is they are documenting all of the different types of UI controls, Skeleton, slider, switch, table, tabs, all of these things that don't necessarily exist, Or they do exist like Select, and they they're awful. You mean to tell me they got a skeleton in there? I was really happy to see skeleton in there. I and I bet I bet Once they've standardized this, then they'll go to the browsers. Nicole works for Google.

They'll go to the browsers and say, hey. How about how about This is gonna be HTML seven, I bet. How about we have some really good set of UI boxes that we can Just use they work. They look really good.

They're accessible. And then if you want to be able to extend them, then you can.

I'm not sure via JavaScript API likely. I love that. I love it. How many times have you had to implement a badge, like a an like a notification Ticker badge. I had to do that a handful of times. In fact, I'm just deleting 1 today that I'm not using anymore. But that's like that's on them that you gotta do all the time. And, it's it's not necessarily PIA, but, hey, here's one that's a very common thing that we use on the web.

Make it standardized.

Yeah. Input type of file. Like, imagine there would be one where you could preview the image that you've selected like such a simple thing. Styling a tooltip.

Yeah. Tooltip would be another one that would be really nice to have built into the browser. I don't know that all of these things will make its way into the browser because I I could see an argument against all of them being like, well, it's not really the browser's

that's not really the browser's job. I don't even care if they're into the browser at this point. If this library was easy to implement, then give me this. Just give me this thing. Yeah.

I I I think I would like them in Some nice defaults in the browser because then you don't have to bring them in, especially for simple little I do lots of little simple little examples. And you don't have to do npm install. You know, give me my normal UI components. Yeah. Polyfill,

include the CSS as well. And You're gonna have to anyways for the browsers like behind. But if you're just giving a simple example, pop open Chrome or something, yeah, that'd be nice to have a main browser. Yeah. So I'm really excited about I'm surprised I had never heard about it. It's called OpenUI, available at opendashui.org.

And I am excited to follow along With what's going on, and we should also encourage anybody who, like, cares deeply about this stuff, maybe even join in. Give your 2¢ now before you It's implemented, and then you start a tweet thread about how it was not implemented the way you thought it would be.

Yeah. Get in on the ground level. Share share, Your use cases and requirements and help out because I think this is one of those projects that, has a lot of potential to change things For the for the like, there's so many little things in in web development that, like I said, how many times do you have to implement this? I don't know. I have to implement it Certain things in every project, and I'm not always looking to install, you know, an individual React component to handle this or that or whatever. So Would love to have some of this stuff in here, and Open UI is definitely a project that I will be watching extremely closely.

Alright. I think that's it. Thank you so much for tuning in, and we will catch you on Wednesday.

Peace.

Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or Drop a review if you like this show.