CSS + JS Hacks We’re Fine With

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

key.

Welcome to Syntax in this Monday hasty treat. I should say Monday hacky treat. We're gonna be talking about CSS, JavaScript, and HTML hacks we're both fine with and not fine with to some degree.

send in a question to our potluck being like, maybe I should just read it really quickly before we get into sponsors because I think it gives some context.

What are things in web dev that you feel are wrong or hacky when starting out, but are actually totally accepted to do? I negative margins in CSS, and I'm sure there are better samples. So, Toby from Switzerland sent that one in. I thought that would be a fun episode because there certainly are, as I become a better developer and as you see other devs, become more comfortable in their skill set, there's a lot of times you you see whether it's ESLint rules or just like like, sort of this gospel that you used to believe.

You get a better you're like, it's fine.

It's fine. Yeah. I know there's definitely some of these things. Like I said, I'm okay with them to some degree and to to not degree others, but, there's a lot of these things that maybe we we can have several episodes where we're talking about many of these different types of hacks because you'll see many of them in many different code bases all of the time.

In fact, I can it's funny because we we spend so much time on these notes, and we're, like, thinking of all these ones, and I just, like, thought of 2 now. It's like, well, there's no room in for them this.

Put them in the next one. So yeah. Right. Totally.

So this episode is sponsored by 2 amazing companies, Sentry and FreshBooks.

Sentry is the perfect place for you to see all of your errors and exceptions in a, just an awesome service that allows you to Visualize all of the errors and exceptions. See them as they're happening.

See how many people they're affecting. Right? You get a little little, this is affecting x, y, and z amount of users for each of these things. You can also see which release. It was introduced if you've tagged that. You can even get performance metrics for your site. You and just about just a ton of amazing tools. If you're a application developer of any type of application website, anything that people are using, And you want people to have a good experience with this thing. You really need a tool just like Sentry to be able to tell you, is this thing slow? Is this thing buggy? Who who who's having issues with this, and Sentry is the perfect tool for that job. So head on over to century. Io. Use the coupon code tasty treat. That's sentry.i0.

Tasty treat, all lowercase, all one word, and you'll get 2 months for free. We are also sponsored by FreshBooks. You've heard me talk about them a lot. They are the cloud accounting solution. I specifically wanna dial in on one thing that saves me a lot of time, and that is the physical receipt process as a business owner. So this still happens. You you go out for lunch with a client. You buy a box of pens at the store, and you have a physical receipt that you then need to log.

It's annoying. I hate receipts. They fade.

So what I do with those is often when I'm out, I'll just open the FreshBooks app right on my phone. I'll snap a pick. I'll log how much it was, right away. And then, as logged as an expense, I'll throw the receipt in the garbage Or I'll recycle it. Excuse me. And that's the best workflow for, doing those actual physical receipts. Luckily, a lot Those are are sort of going away even now. Like, a lot of these, self checkout places, at least in Canada, are starting to now email you the receipt instead, which I absolutely love, but physical receipt is on point with the FreshBooks app. Check it out. Freshbooks.comforward/ syntax. Make sure you use syntax. And the how did you hear about a section when signing up? You're gonna get a 30 day free trial. No credit card required. Thank you FreshBooks for sponsoring.

I hate receipts.

Yeah. They're crinkly.

They fade. They get everywhere. The fading kills me because, like, I used to I used to especially with, like, conferences, I used to Have like a box of receipts on the way home and Oh, yeah. Luckily, that's it's becoming less and less of a thing. I can't wait until there's no more

Paper. My my least favorite thing was, like, working at a company and having, like, a per diem with it was having to, like, collect all the receipts. Oh, yeah. I was just like, you know what? Fine. I'll just pay for it myself.

I'm not I'm not actually that lazy about it, but I'm I'm definitely that that unorganized, though. Yeah. Alright. Well, let's get into some hacky stuff here. Again, there this it's funny that you said that this would make a great episode because when I read this question and we are picking out our potluck For the last potluck we were we recorded, I pretty much thought to myself, there's no way that this could be a potluck episode. This is too too deep, too good.

So I'm glad you picked up on that too. So I'm gonna start with I think maybe we can go back and forth on these. How does that work for you? Yeah. Let's just peel them off as as the ones that we feel passionate about. I'm gonna start with negative margins in CSS, because negative margins are one one of the things that was mentioned in the initial question. But negative margins can get some people a little I'm not a little annoyed. And, if you've never seen them before, a negative margin is a margin, like margin top.

And then you instead of giving it a positive value, you say something like negative 2 REMS or something.

And this one, I had encountered in the wild because I I mean, I've been using negative margins myself in my own programming language, my own code for a while. And the 1st time I encountered some pushback was when I tried to have some code in a public project with our team. I can't remember. 1 of my jobs and one of the developers had a big problem with it and was like, this is Wrong. Why are you doing this? Why aren't you using negative positioning? Right? Position relative negative. And the answer is really that they're not the same thing because A negative margin is adjusting essentially the entire flow of the doc document. So when you have something and you give it a negative margin, everything underneath it also scoots up.

And then with a position relative, negative position, or even a translate, It's just taking that object, and it's moving it out of the flow and moving it up, and nothing below it is being affected.

So That is the big difference, and it's a totally valid technique, especially nowadays where you see a lot of things overlapping.

On level up tutorials, we do a number of things where we overlap things to give it more of a layered effect. Something sitting on top of something else.

And oftentimes, you don't need a position absolute to move some things like that. Maybe you just have a a one div that's been pushed down and other things that's been slid up, and the whole thing is meant to just give it a more layered effect. Negative margins. Super duper valid. Yeah. I I use negative margins all over the place on my course websites because I do all these twisted turned titles that overlap different

and, there's a reason why we have negative margins and they work. And there's a reason why we don't have negative padding and it doesn't work.

It's because it's totally valid technique. So it may seem weird, but totally fine. I agree with Scott there.

Next one we have here is, not passing your radix value to parse int. This one might seem a little bit complicated.

So parse int Takes a string and turns it into an integer and turns it into a number.

One of the ways to represent numbers in JavaScript is with with, like, a full numbers. And another way is with, like, hex values. And you if you need to convert those to a proper number in JavaScript, That's what parseInt does. And the 2nd argument of parsing is what base it is. Is it base 8 or base 10? Like, base 10 is what you're used to in normal math, but If you're doing hex based numbers, it's gonna be base 8 or base 16. There's all kinds of different things out there.

And there was this mantra for a long time and still is with a lot of ESLint rules. Mhmm. You have to pass your your your radix, that second argument. And, I was just thinking the other day, and I went into my ESLint rules to see, like, what have I turned off that's annoying? And I turned that off. I was like, never in my career if I actually had an issue with that. Oh, yeah. And I I actually went into the docs to say, like, is this actually an issue? Does this ever pop up? And if your if your string that you're parsing starts with 0 x, it will assume it's base 8. And if it starts with anything else. I will assume it's base 10. So it's pretty smart about detecting if it's 1 or the other. And almost always, it's gonna be that. I could see it being issue if somebody you're taking a input from somebody,

like, you alert or you prompt somebody for an actual value. But, like, again, Have have you ever had that be an issue for you, Scott? The only issue I've I've ever had with it is the ESLintroll complaining or my linter complaining. That's it. That's the only and it it it drives me nuts because it's like really? Do I need this? Is this is this just another red line underline in my code? Is this actually doing anything for me? Yeah. I should also say a lot of these things that I'm saying, it's probably not a big deal. It's probably because I haven't been bit by it hard enough.

Probably somebody who's, like, lost $1,000,000,000 for a bank is listening right now. I mean, like, well, actually, we had a customer whose name was 0 x 100.

When you're working with a financial institution or, you know, something with secure data, I think your your standards of everything need to be a bit different. Building a tutorial website isn't exactly the exact same thing there. Alright. The next one for me is gonna be another CSS one. And I don't know if this is early seen as a hack, but it it kind of feels like a hack. And this is if you have a position fixed or position absolute element that you want centered in the screen. You can do a position left 50% and then a translate negative 50% in the other direction on the x axis, and that will put it in the center. And for a long time, this was like the way to center things in, position absolute.

Now there's a lot of other ways to do this now. I think maybe some better options out there. Could be, like, Flexbox has you could just have the container be 100 v h, 100 v VW, And then flexbox it into the center or you could potentially use the new inset property that allows you to inset things. But There are still opportunities and use cases where you might not have access to the HTML to structure this the correct way. Maybe you don't need you can't have a wrapper div or something, and you just have a thing, and you want it to center, and it needs to be positioned absolute. This one can save your butt occasionally even if it feels weird or hacky.

I don't mind this. Next one we have here is, overriding arguments in a function. So, another ESLint rule that's very popular is don't Overwrite arguments that come into a function. So I have a function called send an email or send a product. And and the actual Argument to that function is email.

And what I do a lot in my course platform is I just take in the email, and I say email equals email that to lowercase.

And I just lowercase it. And I have ESLint rules that yell at me all the time. It says you can't overwrite an argument, make a new variable. And then I have to, like, think, like, okay, a lowercase email. Like, you have to think about, like, what is it called? And I and I get that. In a lot of cases, you shouldn't be overriding arguments of a function because you might need those original arguments at some point. You might need the untouched value.

But in many other cases, You just need to, like, quickly massage an argument and put it in, like, lower casing the actual email argument. So In that case, I'm like, it's fine. I still do. I I haven't turned that rule off. I still rewrite it to to make a new variable. But I I always think to myself, is this really an issue? Yeah. I don't know. This one

like, I understand your position on this, And by all practical accounts, it makes sense to me. But it still feels wrong. This one feels wrong to me, and I don't I can't put my finger on it. It's the immutability

aspect of functions where you shouldn't be overwriting it. If you're changing it, you should make a copy. And I get it. I I think I get it, but I still some some part of me is just

I know. There I never do this. And I and I I never hit this error in my code because I just literally don't mind. My body won't let me do it, but I understand what you're saying. I I agree with you, but, yeah, this one's hard for me. Now this one's an interesting one, and this one might blow some people's minds if you haven't heard of this before in the past. In fact, Admittedly, this is not something I was super well versed on until I got a PR, from one of our developers who had used these all over some components.

This is the nonstandard HTML elements.

Now I'm going to preface this all with by saying that I'm not okay with it, but it's it's actually something that's fine. And I I'll tell you why I'm not okay with it after I explain it a little bit more, but This is really interesting. So did you know, Wes, that you can name an HTML element whatever the heck you want, and it's functionally the same as div with the class of that same thing. So if you had a a an element that was named Wes and this was just a Wes tag, It's functionally essentially the same as a div with the class of wes.

That's how the browser reads it, But more importantly, that's how HTML was designed was to be able to support that. Anything up that you want. You could just make it up. And so I didn't really know this, but it turns out after a lot of reading about it, it it turns out it's totally fine. In fact, the what w g. How do you say that word? Do you say what wig? What wig? Yeah. What working group? What is the what for? I don't know.

The Let's find this out. Yeah. Let's find this out. The w g is web hypertext

application technology working group. Interesting. I never knew that. The web hypertext

something technology working group, they they say that The analysis of custom tags concludes that they are acceptable, standard compliant since the handling of unrecognized tags as well defined and more acceptable than, for instance, styling a generic div.

X Accordion is no worse than div class accordion.

In every mechanical sense, in the absence of definition for x accordion or component model support. Both mean the same thing. Both can be styled in the same way, and one is HTML unknown element And the other is HTML div element, and their API surface is identical.

So they're saying it's totally fine just to make it up? Yep.

And and so I don't know.

When I got this PR, I was like, what is this? I don't I don't like this. And, developer I I don't wanna call him out by name because I thought that was a really great ID. He was like, oh, yeah. This is Let's drag him some. Don't because it is totally fine, and he backed it up. He sent me all these links, and I was like, It's fine, man. And I was just like, you're right.

It's fine. Why does this feel so wrong? Isn't that what, like, Shadow DOM and and custom components are for. I guess you're allowed. The the reason why I decided to to To give this the, you know, the, the emperor thumbs down Yeah. Even though we actually have some of these in our code base. Because at the time I approved it because I was like, you're right. It's fine. What? Like, I have no argument there. The reason why I have since chosen to say, I don't know about this is not because it's functionally wrong. It's functionally it's fine. Is is is more based on like a just a, a feeling internal style feeling where I wanna say, hey, if this is a nonstandard element, make it a component and then it should be capitalized.

So If you wanna have a nonstandard element, just make it into a component, capitalize it, whatever.

But it's fine. This one blew my mind when I when I really dug into it. I had no idea this was valid. So, yeah. So this is an thing thing to to spend some time into if you want to dig into more about custom tags. Interesting. I I even find

let me ask you a follow-up question about this is what about nonstandard attributes on an element. I've always said no. If you're use if you're making one up, make it a data attribute. Anything. Yeah. Yeah. That's what I do. Yeah. Alright. Alright. Yeah. I always data data everything. Yeah.

Next 1, button must have a type.

So if you This one always gets me where you have a button and you just want to be a regular buttons. They hit the by say button type equals button. And the reason behind this is because if you put a button without a type inside a form element And somebody clicks on that, that will automatically default to a submit.

And people say, oh, you might accidentally have a submit when you don't want it.

And my answer to that is, usually, when I'm using a button that does not have a type on it, I'm outside of a form, and I just need a button to to do something and listen to it. So, I don't like having to say button type equals button. It seems a bit silly.

I know that. And if it if the button is outside of a form and you click it, it's not gonna do anything. So it's fine. I know how it works. I know that if you're inside of form, you have to make sure you don't have them. But, there are rules out there that say you must have a type all the time and you must have a button type equals button on of it. And come on. Come on. Scott Scott is type of Scott.

Yeah.

What do you think about that one?

I you know what? Honestly, I I I add type equals button whenever my linter complains and then I still do it too, but I'm just I kind of grumble about it, but then, yes. I mean, I do it. Yeah. I I it's not it's not like I'm, like, fighting the, the man here or something. It just says, okay, whatever. Whatever. Fine. Okay. You win.

Here's one that's not, like, super hacky, but it's definitely something that you will see.

For a long time, the only way to do triangles in CSS and HTML was to do them out of borders. And effectively, what you're doing is you're setting 4 borders. You're setting 3 borders To be transparent in one border, to not be transparent.

And sometimes, you just need a little triangle, And this little hack to create a triangle has been used and accepted for a long time, and, honestly, I have no real issues with it. It it it can have some trouble with box shadow. There's definitely some things to be aware of there, but just creating a little triangle, doing whatever you want there, that's fine. I, You know, I don't need it to be an SVG or a clip path or anything like that. Sometimes you just need a tiny little triangle, and, doing the border trick is is an easy one. And and for those of you who've never done this before, the reason why this makes a triangle, if you're thinking about borders, if you have a square, think about it like this. If you have a square that's a 10 pixel by 10 pixel square, and then you tell each of the borders to be essentially inset by 5 pixels each. The way that those borders end up becoming inset is they need to have a a corner like a picture frame Where the the they come together. So it ends up creating essentially 4 triangles That come together. And by setting 3 of them to be transparent and one of them to be a color or a bit any sort of opaque anything, It effectively creates a triangle, not a rectangle like you might expect when you're initially thinking of this. So this is a trick that's been around since the dawn of time, and, it's it's just it's fine. I got no issues with it. It's funny. 1 from the days past, Wes, might be, overflow hidden to clear a float. Oh, yeah. Some people some people had, like, beef with that. Nowadays, if you were to say, yeah, that's That's a hack I'm fine with. People would be like, what are you talking about? Clearing

a clearing a float? What? Next 1 we have here is, on HTML, always pass, no opener On your target equals blank links.

So this was this was one that people always preach if anytime I would, Post any sort of code with a target equals underscore blank on it. People will be like, oh, it's a security issue with, rel equals no opener. You have to put that on there. And Reason why is because, previously in older browsers, if you had a target equals underscore blank, there would be a window dot opener value on the opened website, and that would allow the person to know which website you came from, and potentially even have there was some some edge case issue where you could have access to the document of the other website that you came from.

That is no longer the case. All modern browsers now, scrub that information and do not allow access to it, so that you don't have to put those on yours anymore. And those are probably ESLint rules you could turn off as well.

I I knew that there was a security concern there. I knew kind of what it did and perhaps, like, the the general outline of it, but I had no idea, like, the browser specific thing of it of that it was older browsers or anything like that. I just thought it was It's been fixed. This is just something you gotta think about. Interesting.

Here's one that's fun is the inline styles.

Now, inline styles have long been since a conversation has been like.

For older developers, inline styles will feel definitely more painful than newer developers because newer developers are probably a little bit more used to tossing some h t or some CSS on their React components via the style tag or anything like that. But older developers were told from day 1, inline styles are bad. They're bad, bad, bad, bad, bad. And that was largely because we had a lot of code duplication. We were writing a lot of, like, classes in in HTML, and there wasn't component based workflows in straight up HTML the same way there is now. And so while I don't write inline styles, sometimes there is a point where it's like, this thing exists in one spot.

It, would be exceedingly easy for me to just add this inline style here and not have to worry about it. And since this is a component, on it. It's going to remain dry. The main concern about inline styles is that they have, excessive scoping and that they're not dry. But This could be dry. And if it needs to be excessively scoped or or tightly scoped, then, hey, is it really that a problem other than it's clouding up your HTML? Now the only thing the only reason why I wouldn't do an HTML or inline style today in very specific use cases is just because, And I kid you not, Svelte makes it that I I found some way to bring Svelte into this. Svelte makes it that easy to have, like, tightly scoped CSS Onto a file where you just have a style tag. You say, oh, let me just reference this pair paragraph tag. I don't even need to give it a class. The only paragraph tag in this file. Let me just say this paragraph should be blue. Okay? And so the only reason why I wouldn't do it today is because Svelte makes it too easy. That's pretty much it. I think that's it for our hacks. We have a couple more. Maybe we'll save for a next episode, but I thought that was kinda

Interesting. I think for maybe for beginners listening, you can know that, anytime you hear somebody, saying something as if it were gospel or anytime you see a rule. It's not necessarily bad practice. There likely is some motivation behind why they say these types of things.

But you almost always, you can find somebody on the flip side of saying, like, No. It's it's fine. I understand how this works, sir.

I'm I'm totally okay with it. I think, yeah, I think you made a a good point about understanding why they work though. Because, like, totally, don't just go do these things willy nilly if you don't essentially know what they're doing or why they're doing what they're doing Because then you could get into trouble. But if you hit something and somebody's like, hey, maybe you shouldn't do that,

dive into it. Again, I think that that That example about the non standard HTML elements. At first, I was like, no. No. No. And then I was like, wait, you got a point, man. This actually is this seems kind of interesting. Yeah. I don't I actually have any valid reasoning behind it aside from I don't like it. Yeah. Totally. Right? Yeah. It's it's a good a good point. It's same with a lot of the ESLint rules as well as it's I think it's almost better to go very aggressive with your rules, turn everything on.

And as you hit stuff. You can read us to, oh, why do why do why would somebody even want this rule on? Like, why does this rule exist? And you can sort of peer into other people's experiences and see why they might have that. And you can say, okay.

I can see that. And then you can turn it on, leave it off, or turn it off, get bit by it in 6 months, and then turn it back on.

Yeah. Right.

Alright. I think that's it. Anything else to add? Nothing.

Not a single thing. Yep. Thank you for tuning in. 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.