Buttons

Hi, before we get started, I just want to apologize for the audio quality in this episode. We were having some issues with our connection, and because of this, our core quality isn't as great. Hopefully, this hasn't affected the episode too much, so let's get into it. Hello, welcome to Inspect, a show about web design and web development.

In today's episode, we're going to be following on from our last episode about semantics, and we're going to go into the different types of buttons that you see all over the web pages. We're probably one of the most used elements that you see on web pages in different shapes and sizes, and they all have different uses, really. I'm going to split this into sort of three main uses for buttons. The first being to submit some sort of form, whether that's a contact form, or perhaps a search bar, or it could be to submit a post to Facebook or Twitter, for example.

Another type is to perform some sort of action on a page. Whether that's in an app like Gmail, it could be to delete your emails or to make your text bold, for example, that could be a button. The third type is going to be navigational buttons, so a button which would say click here to go to another page, and that would basically take you to another page on a website, some sort of navigation. If you want to take it away and talk about the first type, then we're going to go over the different versions of submitting forms and the submit buttons.

The first part we've got is submitting forms. We've got various different types of buttons all over the web page, so one of them will be a search field, whether it's an icon in there, or a search button, which will execute a search command for a search website. Then various different types of buttons are on a contact form or inquiry form, and those buttons are most obvious buttons being submitted to submit form. Usually these forms are pretty big, they'll come with a reset button, which will allow you to just reset and clear the form.

Sometimes, maybe one of the most popular sites you see this upload button will be a recruitment website where you'll upload a CV or file or something like that. That's another type of button on the form. I think there are three buttons that I come across quite a bit on these forms. So yeah, submission kind of buttons that you find on the forms.

In terms of actual HTML elements that you see with these types of form buttons, there's two real types, there's the input, and then there's the button element. Both of those come in three different types, so you can have an input type, submit, input type, button, or an input type reset, and the same three types apply to the button element as well. And I suppose that's one of the nuances of these buttons really is knowing which one to use, when to use an input and when to use a button element. And it all depends on the actual use case, really the content of that button.

If it's just the, if it's going to be a line of text, like just a single word, and it's going to be used inside a form to submit that form, then the best one to go for is an input type, submit. Yeah, when you do put an input or about an element inside a form tag, I think by default the type is set to submit anyway, so they will, you don't need to necessarily specify that. If it's inside a form, if it's outside a form, then the action can vary based on browsers, so it's best to be a bit more specific about what you want that button to do then. And then you get, with both of those elements, you also get the type equals button as well, and essentially what that does is it turns off the submit capabilities of that button, so even if it's inside a form, it won't necessarily submit.

Again, there are some nuances with browsers, but those types of buttons, so an input type button or a just a plain button element, I tend to use those where they're going to perform some sort of action. So it could be like maybe launch a modal pop up or poggling some sort of text, perhaps, maybe showing a navigation on mobile menu. What you thought on that? Yeah, I think the last, the last that you just said were, you know, toggling modals, revealing, or toggling sections of the website on and off, things like that makes perfect sense, like the navigation toggle, which is more modal.

I think the way they rendered in bootstraps, the kind of format that I'm used to, because I'm not really coding a lot of this, you know, forms scratch. I don't find it needs to do that, so it's really interesting to pick up on this topic to, like, figure out when's the best time to use, but what are the best use cases for these buttons? So even for me, this is an eye opener with the amount of research reading that I've done into it, and kind of like trying to make sense of, you know, the input types and the use cases in, you know, is it a bad way to use it? Is it a right way to use it?

So I think just going on from, like, I'm really kind of like going along with the bootstraps of modal and how everything's rendered within this framework. So you're probably coding this stuff from scratch more so than I am. So I think you'll probably be finding, well, understanding the use cases more than I am, I think. Yeah, I think the biggest question that I always have to do is to ask myself, when I need a button on the page, is what is this button going to do?

Is the button going to be submitting a form or not? And if it's not, or if it sits outside of a form, then I'll tend to reach for the button element first. And just generally, the button element, I'll prefer it anyway because it allows you to put HTML inside of it as well. So, you know, it's very common to see these days where you've got a button with an icon inside it, or you could even have an image, act as a button as well.

So that's, although it is possible to do that with an input element, it requires a bit more CSS, and it requires a use of background images to basically get those images rendered, whereas with a button element, you can have it in your front end, in your HTML markup. You know, you can put SVG in there, you can put just images in there, you can, I think you can put almost any HTML inside of a button element, whereas an input is self-closing, so all it has is a value, and that value accepts the text string. Yes, what's your thoughts on Link's Link's style as buttons? So, for example, I'll give you an example of where this is used at the moment on a website that I'll be working on.

So, at the bottom of the website, all throughout the section of the website, there'll be a call to action, sort of like a section, and by default, a lot of the time, like a call to action widget within the page builder will display as a button, right? Whereas other times, we've got an option to style a link as a button. So, there's two different methods there, and I've found both of them working on WordPress using a page builder, using a third-party widget as part of the actual theme. There's an interesting one there, so, you know, is that right or wrong, but signing a link as a button?

I think it's not terrible to style a link as a button, but as long as that link is not trying to behave as a button, it's trying to put behaviors a link into it, and what I mean by that is that it's doing some sort of navigation, because the styling as a button is purely going to be an aesthetic thing, but the link should still behave as a link. I'll give an example for this. On my own personal website, which is ijcarbal.com, on the homepage, I've got just a little summary of what content you'll see on my website, so some blog posts a little bit about me. And then at the bottom, I've got a what looks like a button, and it just says get in touch, but it is an anchor link, styled as a button, with a class button on it, and it does just takes it to the contact page, so it's a navigation item there.

It would make sense for me to put an input button there, or even a button element, because the context isn't quite right. Whereas if I had a contact form, which I don't, but when I go to the contact form, even though the button on there may look exactly the same as the one on the homepage, I would expect to use an input or a button element instead of an anchor there, because it just goes to the context. So that's the sort of hard and fast rule of it, is if you're doing some sort of navigation, you should be using an anchor with a h-ref on it, because an input or a button element neither of them accept a h-ref as any of the attributes. So if you were to use a button, the only way to actually have some sort of navigation is to use a non-click event, and that's when you get your JavaScript involved, which you shouldn't really need to.

That's right, yeah, and you need to avoid that, yeah. Yeah, you don't need to avoid it, but you just think is it necessary? It's just a bit, you know, it's jumping through hoops for the sake of just navigating to another page. You're better off using a link style as a button if you want it to look like a button.

The bit where it gets a bit funny is when you've got a button that looks like a link. I don't know if that's necessarily a great choice, but then I guess, again, it comes down to your own design and your site design. If you have a form where the button needs to look like text, then it makes sense to use a button element or input element and you see it says to make it look like an hyperlink. Yeah, yeah.

If you look at just say iOS, for example, especially since iOS 7 when they had the massive change in design, a lot of the buttons now just look like text labels. Now, obviously they're there like native iOS controls, but if you were to mimic that style on the web, it would look like a hyperlink, but it would still make more semantic sense to use an input or a button element. Yeah, I think the design is a huge track of this as well, and the fact that your hyperlinks should stand out and not look like a button because the purpose behind hyperlink is just taking into another page. Whereas your buttons are called to action to stand out a bit more and should be a bit more obvious and giving the user a sense of, okay, this button, once you've clicked this, it's going to take you away from another regular content of the website and take you somewhere where you perform a action, whether that's a form or tapping to call, things like that.

Yeah, so it does come down to the design, whether you should install, or change the styling of a button to a link or link to a button. Yeah, in terms of just the input and the button element, applying CSS to those two, just to those two, by default, they do look fairly similar. The browser will render them almost identical. There are some slight differences, but when it comes to CSS, I think it's a lot easier to reset the styles of a button element than it is of an input.

But you know, you've got bootstrap and most of the other front end frameworks, they've all got styling in place where you know, you just take a button or a BTN class on either of those, or a hyperlink and you know, they've all been started to look and work in the exact same way. So once you've got that sort of design choice out of the way, where you can make all of those three options look exactly the same, that's where you know, you need to start thinking about, you know, the actual use case of the button now, and use the one that's most sort of semantically correct. That makes sense. Yeah.

Okay. The only thing to really watch out for is that the button element is not compatible with older versions of IE, I believe IE 6 and 7. So IE 8 onwards should be okay. And also when you're using an input element versus a button element, if it's not inside a form, then some browsers behave differently as to what happens when that button gets clicked.

Some browsers may actually just do a post back on the form, others may just completely ignore it. So best thing is to, you know, use it in the correct place. If you're trying to submit a form, use an input or a button element with type submit on it to submit the form. If you're using it outside of the form and you're just trying to do some sort of action within the page, without submitting any data, then you probably want to use type button on either of those two.

And if you're doing some sort of navigation, then stick with an anchor and start the happens button if you need to. There's another scenario that I come across using Bootstrap, and that's where your end link has a role equal to button to do with your accessibility. If you come across that, do you use that anywhere when you're working on your projects? Generally, I, especially if I'm copying, placing text from Bootstrap's documentation, I know it's on there by default.

And yeah, like you said, for accessibility, there's there to let a screen reader know that you're using an anchor that's styled to look like a button. You know, it needs to behave as a button and not necessarily just as a link. If I was just writing my own code, it's to be only system normally a bit of an afterthought. But yeah, if I was going to do an accessibility audit, I guess, or just put in some extra effort to make sure that site is accessible, then yeah, I would put role button on, especially if that button is, well, the anchor is not behaving in the most obvious way.

If it is behaving just as an anchor, then I don't think it's necessarily needed. Okay. Yeah, yeah, I don't really actively add role equals button on. Because then you start getting into the whole, you know, then there's loads of different RE attributes that you can add to buttons as well.

You can say like whether it's pressed as well, which you'll then start toggling with JavaScript to let the screen reader know exactly what the state of that button is as well. So I would, yeah, I would only really reserve that effort for if it's really needed. But I think if you just leave off role equals button, I don't think it doesn't make any difference to the way the button performs. So it's just purely accessibility.

Yeah, I think it's, you know, I think it's taking the case by case, you know, scenario where, you know, if you've got a project which requires that, you know, the user base or the audience are using tools like screen, things like that. I think that's what it's going to be a bit more, you know, as we think about it a little bit more beforehand. Yeah, because I come across that and all of a sudden, is there really necessary for this point I'm working with, but it's there and I just leave it there, especially for working with bootstrap. Yeah, I think the bootstrap recommendation for the buttons is a pretty good place to start to find out what the different types of button usage and which elements to use and they do explain a little bit about, you know, why a button is used over an input.

So I will put links to the bootstrap documentation in the show notes. There's also a couple of good stack overflow questions and answer threads which explain the different uses and essentially explain like where the button element is not compatible with all the buttons. And some of the gotchas that you need to watch out for. So I'll put a few more links in the show notes so check those out and yeah, just be careful about what type of buttons using and we're using them and always remember to use them in the right context and then think about styling as a bit of an afterthought don't let the styling of the element be your driving factor.

Let the actual context be defined first. Yeah, all right, and on that note, that's probably everything we've got on buttons for this semantic episode. Maybe we should do a little series of these where we do a little deep dive into certain elements, you know, maybe the different types of inputs. Yeah, because there's so much, there's loads that we can go into.

Yeah, definitely I think needs to be touched on a bit more than more detail. Yeah, things like, you know, whether it's got text inside the div or whether it should be inside a paragraph inside the div should text always be in a in a container that is intended for text, for example. So yeah, there's some different options that we think about before we go. You got any recommendations or anything cool that you've seen this week that you want to share?

It's just something that I came across, but I was actually subscribed to it. I think last year before it's called Blinkist. I think it's Blinkist.com. What they do is they basically just get people that have it reading a bit more and they kind of like, it's all nonfiction, short fact based articles and what they do is a kind of condensed, larger reading into sort of segments.

It helps you to get that out of reading and I'm just kind of like picking up again, resurcribe that side reading. So that's one for you guys that are Blinkist. Blinkist.com. Cool.

I'm going to recommend an app this week. I've been using this one for a while. It's a photo editing app called Darkroom. I believe it's iOS only.

It's not free. It's a good $9.99, but it's definitely worth it. It's got really granular controls over photo editing. It's got loads of preset filters and allows you to create your own filters as well.

Once you're happy with the look and feel of a photo, it allows you to edit this or histogram curves. It's just a brilliant photo editing app. It's on par with, I would say, Lightroom, but obviously this one's called Darkroom. Although it's a paid app, at least you don't need a subscription to the Creative Cloud to use this one.

I'll put a link to that in the show notes as well. It allows you to, it's just a really good app. One thing I do like about it is it lets you quickly change the dimensions of an image to, well, not so not the dimensions. Change the canvas of an image.

Suppose you've got a rectangular image and you're trying to set it as your profile, your avatar profile photo, which normally needs to be a square image. You can hit a couple of buttons and what it does is the app adds padding to your image to put you onto a square canvas. Then you can set the background color of that canvas as well to match the image as well. So you can make your photos ideal, canvas size for different social networks and stuff like that.

That's a really good feature. Just the actual controls, the editing controls, this just got so many. It's a really good app, probably the best photo editing app I've used. Get on it, check it out.

Alright, nice one. If you like this episode, do hit subscribe in your podcast player and consider leaving us a review or rating on Apple Podcasts or wherever you can. You can follow our Twitter account at InspectorFemm and you can check out the show notes for this episode and all the archive of previous episodes on our website, Inspect.Femm, where you can also find links to our personal Twitter accounts and so forth. We've also got a Discord setup and also a Slack community.

Details of those are on the website. So yeah, it will be great if you could join those and get into some more conversations and discuss in future episodes and build a bit of a community. I'll catch you later. See you later.