814: Fundamentals: HTML

Welcome to Syntax. Today we have a fundamental show for you. Again, these are shows that we do every now and then about fundamentals, about different types of programming. We have them on TypeScript and JavaScript and CSS, and we've got quite a few of them.

And we realize we actually haven't done a full-blown HTML fundamentals episode just yet. And that is one of the very first building blocks that you learn. And having a good base to build your house upon is crucial. So here we are today.

We're going to talk to you all about why good HTML is important, good structure, what do semantic elements mean, and just basically how do you, when you're authoring a website or web app, how do you tackle that and make your HTML look like onions, which is a good thing, by the way. That saying onions is only a reference that people from the Toronto GTA area get. Maybe I should explain it because I often will say like, ooh, onions. So Chuck Sorsky, who was the commentator for the Raptors on TV, whenever a, if you just Google onions, baby onions, you'll find like all these highlight reels of like, like crazy Vince Carter doing like wild stuff back in, I don't know, when was Vince Carter?

Through the legs, underneath the leg. Yeah. And Chuck Sorsky would just go, onions, baby onions. And it's like, he can throw out.

It's so good it makes you cry? Is that? Oh, maybe. I never considered it.

I just am, I'm very, I love slang that is, like when somebody throws out a slang that I've never heard, but you kind of understand. I, like I read Urban Dictionary, like at least once a week, just to sort of get new, new one-liners and saying, it's, do you read Urban Dictionary? I almost always pull it up when my wife says something that she does not understand the meaning behind, because she works in a school, right? So she hears things.

Yeah. And she's not always up on the way to slang. So I'd say, well, maybe you might want to reconsider saying that. Yeah.

I also do it before I like say anything on this podcast, because only once did I say something on this podcast where I didn't realize the meaning behind it. And it was just like something I had heard. So I started saying it. And then now I realized I should probably check that there's no, uh, not hurting anybody.

Yeah. Yeah. But you know what is hurting people? What?

Your bad code, because you don't have visibility into the errors that you're serving people. And it's making them have a bad time. Maybe if it's raising their stress levels and actually physically hurting them. I can, you know, there's sometimes when I use a website and there are issues in it and I can't really like, gosh, if only they would have done this, I wouldn't be so angry.

Why don't you put a tie knot on this? All kinds of things, right? Yeah. And that's where we need visibility into apps.

So that way we know when people are potentially hitting issues or slow pages, right? Things that are cause turmoil in everyday usage of applications. And that's where Sentry comes in. So you'll want to check out Sentry at Sentry.io.

It's the perfect tool to get visibility. And not only just that, but make your applications better in all kinds of ways. So check it out. And this podcast is brought to you by Sentry.

So HTML, hypertext, markup, language. Wes, why is it important to understand HTML? HTML. Do you know that I thought HTML meant Hotmail when I first saw it?

Like when I was a kid, you know, you'd see it in the URL bar. Yeah, well, Hotmail was big. People who don't know, everybody had a Hotmail. But you either had Yahoo or you had Hotmail.

And I don't even know what the other ones were, because most people had Hotmail. The cool people had Hotmail. I just want to say that. Yeah.

All the parents had like a... Comcast or the ISP, you know. Yeah. It's funny because you can still tell when somebody's from the country because their email address, like written on the side of their truck, will be some obscure telecom, not like beans internet over satellites from farm to farm.

Yeah. And I often think like, those four people, what are you going to do about that email address when you switch your ISP? That's the worst example that you could do. Anyways, HTML.

Why is HTML important? A couple of reasons. It makes things easier to style. It makes things easy to compose together.

It makes things accessible. I mean, that if you use the correct HTML elements to mark up your website, a lot of your stuff will be accessible by default. There's going to be very little extra work on your end to make things accessible because simply just marking it up correctly is important. It's SEO friendly.

Having Google and other bots be able to crawl and understand your content is important. It makes things have built-in default functionality. So we're starting now to see new elements at the browser that have good default functionality, right? Scott has some really cool examples.

Let's go on the details element, right? You pop a details. What's the markup for details element? Oh gosh.

Is it details? Yeah. Yeah. Details puts it into...

Oh, summary and... Oh, you're talking about details. Sorry. I was thinking about dialogue.

So I was like thinking, is it has inset baked in or not? But yes, details. Well, dialogue too. Yes, dialogue as well.

You know, they do. They have things like baked in inset or... Popover. Yes, popover.

Even display, none display, you know, block, whatever. Those types of things can be baked in as well. And functionality and styling on all these things is... They're here for a reason, you know?

And even more important now that we're getting all of these popover and details and whatnot is that forms as well. These things are built on open standards. And when... If you build them with these standards, picking them up with JavaScript and actually building full-featured web apps is so much easier because you have started with a really standard base and you're going to be able to pull in a library that understands how forms work or how details elements work or how the popover API works.

Yeah. And I know you said this in accessibility, but interactivity as well, you know, whether or not you're writing a click event to a div or something like that. I mean, there's all kinds of things that go along with that that fall into the category of both accessibility but also just general usability. Exactly.

So this word semantic gets thrown around a lot and people always say, like, build your website with semantic elements. So what that means is that HTML elements that define the content that is inside of them will note to the browser, to default styling, to screen readers, to browsers, to search engines, what type of content is inside of them. Meaning like, oh, you're heading one through six. That denotes sort of the table of contents of your website.

You know, paragraph text goes inside of a paragraph element. And then we also have like non-semantic elements, which are more used as building blocks for your layout. The most common being span element, which is inline and div, which is block. Yeah.

I think that's an important thing to have an understanding of because as we'll see, I think the document structure in general is something that it makes a ton of sense when you have a wide view of it. And when you don't have a wide view of it or have a deep understanding about what a document structure should be like, you might just feel like you're throwing elements at the wall. So let's talk about the basic structure of an HTML page. HTML pages, or at least HTML that is designed well.

You know, you're going to see some of the same things every single time. The first one is going to be the doc type. Back in the day, we had a whole bunch of different doc types and that had to do with what were the different doc types of different versions of HTML? Yeah, HTML 4.1 strict.

There were so many of them. And they essentially noted to the browser which version of HTML to use. And that would help the browser understand how it should render out the elements on the page. Thankfully, we are mostly done that.

It's been like probably 12 years since we just got doc type HTML. And what that will do is it will force the browser into the most modern rendering engine. And if you do not put it in, a doc type in, we'll get a little message that says you're putting the browser into a quirks mode, which I don't even know if I understand what a quirks mode feature is. Do you?

Oh, gosh. Yeah, I don't know. That'd be a good one for some. Let's figure it out.

In quirks mode, the browser will attempt to render a page that will emulate the behavior of older browsers such as Netscape 4 and IE5. This can lead to inconsistent, unpredictable layout and rendering on the webpage. But like, do modern browsers still? Like, I got the quirks mode a couple months ago.

So some poor soul is still maintaining quirks mode. That's funny. Anyways, that's something you don't want. But yeah, your doc type goes in there and then you have...

And the doc type is just HTML these days. That's it. Yes. Doc type HTML.

That's the doc type that we use. And then inside of that, we have our HTML tag, which is composed of your head and your body, right? The head of your document is not visible. By default, you can do some pretty funky stuff where you can display block on the head and make it content edible.

I've done that TikTok twice now and it always does super well because it's such a funny thing. But by default, the head of your document is there to provide metadata about the document. So what types of things go into the head, right? You've got...

Often you'll have links to external resources like favicons, CSS, script tags. You'll have meta information for things like, I guess the favicon is meta, but also like graphic previews, theme color, what else goes in there? Redirect tags. That would just be a good stumped.

Name 10 things that go in the head. Let's not do it yet, but we'll wait for the next stumped. It's definitely something that you kind of experience, you pick up what goes in there at some point. But the way I like to think about it, when you're thinking about HTML in general, it's oftentimes, if you're not super experienced with HTML, it's important to think about an HTML file as a document or a file.

And like you said, the doc type first declares what type of file we're working with. The HTML tag says everything inside of here is going to be the HTML we're working with. The head is saying like, this is the metadata. This is the information about the document.

And then the body is the contents, the stuff you see, the visual thing. So after we have our head, we have our body. Our body contains any number of elements inside of the body. And the typical structure for the body inside of there, and granted, you can throw a div immediately following the body or divs left and right.

You know, div is just kind of a blank element. But inside of the body, a very common way to lay out your application is to have a header tag, and then have a main tag, and then a footer tag. Now, the difference between the three of those is kind of interesting. The header, by default, if it's in the context of the body, as in it's not inside of a section, nav, main, article, aside, if it's just inside of the body and not inside any of those, it's considered to have a landmark of banner, as in this thing is the main header that contains typically a logo and navigation and such.

And the browser will understand that if you put a header at that level, it will most likely have those things. Now, so you can use header inside of a section. You can use it inside of an article, inside a main, multiple headers per page, right? Correct.

You can have multiple headers and footers per page. But the context in which they're understood by the browser happens to do with where they exist in the context of the document flow. And so a header inside of an article would be like if you had a blog post that had a header with heading information for the blog post, that would be perfectly fine to put that inside of a header tag as well. It's just not going to be registered as the landmark of banner because it's nested within an article.

Now, main is actually, unlike header and footer, you can only have one main tag, and you should only have one main tag. The main tag specifies the main content of the website, as in this is not the header banner, this is not the footer, all that stuff in the middle goes inside of the main tag. And so if you throw one of those, everything else in there is, that is the contents of the website. Interesting.

I don't think I do that. That having a single top-level main tag, and I assume you can still throw a div around it if you want, like around the whole website for several reasons there. Okay. But I'm on the W3C ARIA documentation.

It says when only one main landmark is on a page, a label is optional, meaning that you can tap to it and the browser will understand that this is the main content for the page. However, it does say you can use multiple, but you must then label them with ARIA label by. Main text? Yeah.

I thought you said multiple. You only use one. It would make sense that you would only use one because you only have one main piece of content for the page. However, sometimes, especially with components, if you, like, let's say you have a page that is the main content, but you want to display both of them on the page for whatever reason.

You're writing a, you want to have two documents side by side. If that's the case, then you have to label them with ARIA label by, and that corresponds with the ID of a heading or something else that describes what is that content. So I guess that would be a good example is if you have two documents side by side, here are two restaurant menus that you want to view. You could say here's a restaurant menu for McDonald's and here's a restaurant for Burger King.

It's interesting because MDN says you mustn't have more than one main element that does not have a hidden attribute. Oh, interesting. Interesting. Yeah.

You know, maybe it's kind of a newer, I mean, it's definitely newer in the context of the history of HTML, but definitely it's typically just pretty much used as here's the section where all your stuff is and that's where you want to use it. Yeah. Next up, we have the nav element, and the nav element, as you can imagine, specifies that this is going to be a navigation, a grouping of links. Now, one thing I always wonder about this, and you personally, Wes, is like, when you have a nav, do you need an ordered list with list items inside of it?

And typically, you do see that anyways, right? People still define the navigation items as a list inside of the nav tag, but the nav tag is really just there to denote that this is going to be navigation for your website. Now, does that mean this is going to be the main navigation? No, not necessarily.

In fact, you know, in an example on MDN, they have a nav tag around their breadcrumbs, which is just, you know, breadcrumbs are a series of links to show you how deep you are in the nesting tree. So, a nav tag, you know, it doesn't have to be used once. This is interesting. It says, typically, the footer element often has a list of links that don't need to be in a nav element.

I find that to be curious is why that might be, but hey, that's what MDN says. Interesting. Okay, so the question of, do you need a ordered or unordered list inside of a nav tag? The answer to that is no.

You can put whatever you want. However, I don't feel good about simply just throwing anchor links inside of a nav tag because it is hard to style, and if there is a situation where there is no CSS being applied, either breaks or doesn't load or whatever, it just jams all the links together, and sometimes you even run into the thing where there's no space between each of the links and it's hard to read. So, I much prefer an unordered list of links if it is unordered. I guess you use an OL if it was like a table of contents, and then I put an LI, and then you throw whatever you want inside of there, divs and links, so that you can style it however it is that you're looking.

There can be more than one nav on a page. It says that if you, you know, you do have more than one, then ARIA labeled by can be used to promote accessibility, but yeah, you can have more than one nav per page. Typically, what you're going to see in typical websites is a header with a nav inside of it. Potentially, that nav is a mobile nav, you know, hamburger menu type of thing deal as well.

But yeah, so, nav is not a use-once-only kind of thing. Here's a question. I'm just looking at my own website, and I have a header element, and then I have a nav element, and because of styling reasons, I put my H1 tag inside the nav element. That doesn't make sense.

Is that wrong? What do you think? I don't think that necessarily matters, so to say, because heading tags kind of exist in their own hierarchy, where the heading tag is being read as like a outline, which we'll talk about in just a little bit. So, I think maybe we could use maybe a tighter expert's opinion on that in that regard, but I don't see why that would be a problem.

In fact, there's even an example here on MDN with an H2 inside of the nav, so I don't see that as being a problem. I'm fine, then. Yeah, I'm using my brain powers of deduction here. Next one is section.

Now, section is an interesting tag. Again, it was added in HTML5 days, so we used to just use divs for everything, right? You need an nav, you use a div. A section, you need a div.

Side div, article div, right? So, all of these things are block-level items, right, for wrapping content, but a section is specifically to denote a section of the document, which seems like it's self-explanatory, but typically, the way you use sections is that a section, even visually, if you're looking at a website, sometimes there's like big hard lines between color-blocked areas of a website. Those will all be sections of the website, and other times, you're just on a page, and it's just one big giant bit of information. That's one big section.

So, a section is to denote a group of related content together in one group. Yeah, I often, we should know that a section doesn't give you any special functionality or features aside from, I guess, like, what, I don't think there's any accessibility benefits to that, maybe for SEO. However, it does make things easier to architect your layouts, like Scott says, if you have big color blocks or like... On my websites, for all my courses, I'll often use sections because I have a section of what videos are in the course, what will I learn, FAQ, and I'll use those sections.

I can grab them with CSS and apply all of my styles to them. Yes, and in addition, each section should have, and this is a should, not a must, should have a heading element to denote what that section is. So that's kind of where some of the special sauce comes in. It's like if you have a section, and then you have an H1 through 6 there to denote what that section heading is, then we're saying, right, this bit of content all falls within this heading.

Likewise, we have an aside, which an aside is typically used for sidebar content. You know, back in the day, even still today, whether it was the golden layout, or we typically have a left-hand column with potentially navigations or filters or all kinds of things or either sidebar navigation, right? Often called a sidebar. An aside is for exactly that.

It's for content. That is not the main content. It is aside. You would call it a sidebar, but visually it does not always have to be a sidebar, which is why it is called an aside.

Yeah, aside can also be really handy for just little digi-nosed or little asides when you're writing an article because you say, okay, I'm writing this article, and aside, why didn't you do it this way? And then it's great. You pop a little aside in there. You can style it a little bit differently.

You can even, dare I say, float it because you can, people say, oh, floats are good. The one use case for a float right now is if you want text to wrap around an element. So if you have an aside, we're just like, did you know, the average website uses four kilowatts of energy per year, and you could just like put a little right in there, like those pop-up music videos back in the day, and then have the text wrap around it. Aside is the perfect element for that.

Yeah, totally. Likewise, article. Article is an element to denote an article. What is an article?

Well, you have a blog. What does your blog have? That's posts, also known as articles. Those are articles.

So an individual post could be seen as an article. Also, like if you have a list of things, right? Let's say you have a listing of podcast episodes on the Syntax website. There's a big old listing of podcast episodes.

Those could be considered an article themselves. So a document will have a bunch of different articles, typically, to denote like content that is grouped together, but as something like, I think the best way to describe it as like a newspaper article, a forum post, a blog entry, those types of things, that's an article. Next up, we have the span, the mighty span. The mighty span.

Let's explain real quick. Block and inline are the two sort of displays in CSS. There's obviously a lot more than that. There's probably, can we do a little trivia right now?

How many displays? Can we together come up with all the displays? There's display, none, block, inline, inline block, flex, grid, inline, contents. Sorry, what did you say?

Inline flex. Inline flex. That's the thing. Inline grid, yep.

Yep. I said contents. Display. Display contents.

So that's nine. Display table. Yes. Display, there's some weird ones like.

I know. Display, there's like unordered lists are something weird. Unordered lists? For sure.

Let's see if I can get all the properties. No, they're block by default. Unordered lists are display block. Okay, there's table row.

Oh, table, table row. There's list item, which we, yeah. Okay. I didn't know that you could do multi words.

So there's display block space flex, block space flow, block flow hyphen root. I do not know what those are. What is display flow root? Now that is not one that I know.

Flow root. Oh, interesting. Okay. So Wes, it seems like the multi word syntax is, to be sure your layouts work in older browsers, you may use the single value syntax.

For example, display inline space flex would have the following fallback of inline hyphen flex. So the inline hyphen flex is the older way to do it, and the newer way to do it is with multiple values. Inline space flex. Oh, really?

Really, yes. Did not know that. Hey, we have just learned something. So display block space grid is the same as display grid, but display inline space grid is the same thing as display inline grid?

Correct, yes. Very rarely, but every now and then I need an inline flex, and I'll just use inline dash flex. So now you can use multi keyword. Yes, and by the way, flow root, which is interesting.

I've never heard of flow root. The element generates a block box that establishes a new block formatting context, defining where the formatting root lies. I don't know. I don't know what that means.

I don't know. The element, the display flow, the element lays out its corresponding, or its contents using flow layout. If its outer display type is inline, and it's participating in a block inline formatting context, then it generates an inline box, other than it generates a block container box. Okay, those are words, right?

Those are words, right? Yeah, hey. Wow. Yeah, it's there.

Who's using that, right? Wow. If you're using display flow, let me know. I want to hear all about why you're display flow or flow root, which actually looks like they're not.

I would have figured those were old properties that we're not using anymore, but it was added to Chrome in 2017, so it's not super old. Added to Safari in 2019. Oh, here, cannot use comes in with the reason why you might use this. It provides a better solution to the most use cases of the clear fix hacks, so it's when you're using floats and things are taken out of the block.

It's a fix for clear fix that we used to have to do. Interesting. Well, I think we got them pretty close. I think the only one we didn't hit was the...

The flow root one. And then there's a couple other internal ones like display table caption and display ruby text, but that's internal. That's not something you use in CSS. Word.

What were we talking about before we started? Span. Span used a span versus div versus a paragraph tag. Why you use a span when you have a div and a paragraph tag?

Yes, because span, by default, their styling is inline, meaning that it does not break onto a new line when it creates itself. So if you want to wrap a couple words or you want to wrap something without disrupting the flow of the document, then you use a span. And also, of course, you can change those types of things in CSS, but it's really nice just to know when I see a span, I know that that is only there because it will, A, is going to not break the layout, and B, is probably being picked up in CSS to add a highlight or something like that. And even in that case, I just always throw a span around to highlight stuff until I found out about the mark tag, which is intentionally meant for highlighting elements.

Yeah, and speaking of that, if you find yourself wrapping things in a span and then immediately throwing a display block on it, chances are it should just be a div or maybe even a paragraph tag if it's paragraph or text. If you're finding yourself wrapping something in a div and immediately putting a display inline on there, you should probably be using a span. The span is the generic wrapper for inline content, as you said, by itself. You want to know a little trick I came up with the other day?

CSS, if you have a block element and you want to keep all of the blocky attributes, meaning that it breaks before and breaks after, it can take a width and a height, it can do all of that stuff, but you don't want it to span the entire width because block elements by default will go all the way across width-wise, you can put a width min content on it and it will suck to the content but not give up all of that like clear before and clear after. So grab a display block element, give it a width of min content and then pop a background on it and you'll see what I mean in that it will simply just apply the styles to how wide the content makes it but still not break before and after. Hmm, word. Hot tip right there.

And also hot tip, figure and caption. People don't use figure and caption all that often for, I don't know why, but they don't. Figure and caption are a way to do like a self-contained image illustration, diagram, code snippet, and caption. And so again, this is not necessarily that important but it gives semantic meaning to these elements and if you have something that is, let's say a picture with a caption on it, right, that seems like a perfect opportunity to use figure.

It's fig caption, which I always found to be weird. It's figure and fig caption instead of figure caption, which, or just caption. Why do they abbreviate fig? That's a great point.

I wonder why that is the case and couldn't it also be just caption? Anyway, it was too long ago that it was added. Oh, there's a caption tag. Wait, why is there a caption tag as well?

A caption tag is for a video element, is it not? Or no, that's a tag tag. It's for a title, or for a table. A caption specifies the title of a table.

So captions have already existed because it was in Chrome version one. Yes. Okay, so that's why they did fig caption. But they should still have figure caption.

I think so. Maybe too long. I'm okay with it. But I love the figure tag because it allows you just to make a nice tidy bundle.

Sometimes you throw an image and then underneath you you put a paragraph tag that describes it. Oh, I got to put those things together because I want to put a border around it. Oh, okay, throw a div around it. Oh, what do you call that thing?

You know, image container. It's called a figure. I love it. Use it a little bit more often.

Same with field set. In Formland, I know I'm going to tell myself. Field set is so good because A, you can give a field set. What's the description?

Oh, it's a legend. So you can give a little description. Almost always I don't use that and I just strip off all the field set styles and I use it because it allows you to group together a whole bunch of inputs and labels that are not necessarily grouped together and then you can disable all of them at once with a disabled attribute. Yes, I know, field set.

Super under your life and it's an ancient and it's been around forever. It's a classic HTML element right there. S-tier element. Yes, S-tier element.

Order list versus unordered list. The definition for these two is in the name of them. If you need a list of things, you wrap it in a UL or an OL. OL is for things that have an order to them.

1, 2, 3, 4, 5, 6, 7, 8, 7, 8, 8, 8, 8, 8, 8, 8, 8, 9, 8, 9, 9, 10. It has an order. They go in that order. Unordered list is typically things that are just here's some like related content like perhaps the navigation and it is in a list of things that goes in an unordered list.

So you'll often see unordered list for navigations and you'll often see ordered lists inside of content whenever something has to be sequential in any sort of way. I love just going through the list of elements on MDN because I can find all these ones that I didn't know about or maybe I learned about it. Do you know what the DFN element is for? I feel like this is one of those ones we hit and stumped at some point.

I feel like it is. My brain is not working this morning. No, tell me what DFN is. So if you have, it's a definition element.

So if you have a paragraph where you're explaining what something is, the thing that you are defining should be wrapped in a DFN tag and then you can, I think by default, it will make it italic. So if I were to say display contents is a way for you to display the element based on its content size. That's a paragraph tag. I would wrap display contents in a DFN tag because that is the definition that I am then defining.

Yes. And like there's a lot of funny weird things like there's a time element for when you have date time and then it has an attribute on it time that passes a date string so that way the browser knows that it's a date. There's so many little HTML elements and I strongly encourage you to specifically, and we'll have a link to this in the show notes, to go to the MDN page where it's HTML and then element. In fact, I'll even put it at the top of the show notes here because this is a great place to just look.

If you are looking to do something in HTML, this is a great list of really descriptive tags and what exists out there. Maybe you didn't know there was a time tag and you saw it on here and I was like, oh shoot, I have a time here. I can throw this in a time tag. Next on our list of things to talk about is form.

Form is how you add interactive controls to your website. Forms are a standard part of the web in general. Forms are how we communicate to our server or how we do all kinds of things. So like you mentioned, with the form set, a form is a big old beast.

You could probably have a whole episode on the form tag itself so we're not going to get too crazy into here. The forms typically, you know, they have an action, they do something. They have a button or an input type submit. Typically a button.

Now these days, do you ever use input type submit? Input type submit, yes. No, I don't because input type submit is very limited and I'd much rather use a button with the type of submit because anything can go inside of a button and you can style a button so much more whereas input type submit is a self-closing element and your options for styling it are a lot less. Yeah, buttons are great.

But in the same way, yeah. Buttons are, if you're wondering why they both exist then buttons are newer, right? They're newer to, I guess I haven't been around forever. Well, I don't remember a world without a button.

I'm curious, why is there an input type of submit and a button type of submit? I feel like they are newer but I don't have that actual understanding of when a button was added to CSS or HTML. Let's find out. Maybe even button type submit hasn't always been inside.

I don't know. I could be spreading incorrect things. Let's see. Oh, interesting.

Hold on. An input type of submit takes additional attributes including a form action indicating a URL for which to submit the data. This takes precedence over the action on the form element. Oh.

So input, oh, this input is also available on input type of image and button elements. Okay. And then you can do method. I knew that.

I remember because when React server components came out people were sort of up in arms because an input type of submit can be outside of a form. And you can submit a form from outside of the form by giving it a form target attribute. However, you can put a form target on a button and an input. So that's not the difference.

That's just a little fact. Interesting. Well, interesting nonetheless. And then, you know, in regards to that I mean, there's 100 HTML input types.

So just head on over to NBN and look at all those. They're changing all the time. We're getting new date types. We're getting all kinds of stuff.

Color pickers, whatever. One of the big things that people talk about in HTML is button tags and anchor tags. Typically, you're always going to use an anchor tag if it's navigating to a new page and a button if it's performing some type of action interactivity on the page. So don't use a button tag to navigate.

Don't use an anchor tag and then prevent default and have it just change something on the page. Or the worst is they use an anchor tag and I want to open it up in a new tab but it doesn't go anywhere because they're just listening with JavaScript to sort of listen for the click on that element and then submit the form. That's probably nuts. Yeah, you hold command, you click it and then it opens the page and says, oh, Gusto, come on.

Nothing. Yeah, or like, I think FreshBooks has that where I want to duplicate an invoice. It's a link, right? Click, open a new tab but it's a link with a listener on it.

So use a button in that case. And almost all the time it's just because people don't want it to look like a button so they don't use a button. You know, they just want a text link. So you have to go into your CSS and make a button with a class of naked that strips everything off of it or the opposite, make a class of button that goes on your links to make it look like a button.

Yes, I do both of those typically. Last little bit, well, not last little bit, but we also have headings which we talked a little bit about and these are the H1s or H6 tags and it seems like you can't talk about these enough because even just the other day I saw on Twitter a conversation that was like, how many H1s do you typically use? That's not the conversation you should be having. So if you want more like detailed information on this, headline number two is in fact, it's episode number 674.

We did a heading design which is not like aesthetics design but how you structure your headings. Here's how you think in a brief explanation. If you think about your website as like an article or maybe like a paper, you've been assigned to write a paper for class, right? Your teacher says, I need five pages on this.

Typically what you do is you give your paper a title and then potentially even write an outline, right? And then that outline becomes headings and you have paragraphs or maybe you just use that as an outline. You don't ever typically have more than one title of your paper, do you, right? And that never happens where you have it, here's my paper on Radiohead's today album which is a paper I wrote in high school.

My paper would not have multiple titles. You just have one title. That's your H1. You don't skip.

You don't say, all right, inside of this H2, here's an H4 just because it's smaller. No, you have an H3 and then you style it the way you want it to. So oftentimes... People get a little bit confused like that because they say, all right, I'm just going to toss this one in because it's smaller, it's bigger, it's more important, this or that.

Now, it needs to follow a very strict structure as if it were an outline of a page or a document. I got another one for you. Do you mind if I do a little more trivia because I find this really fun? Yes.

Okay, I'm going to phrase it so we can get a clip out of it. Do you know what the output tag is in HTML? I've never used this. Yes, I do know what the output tag is.

Okay. I can tell you. Tell me. Yes, hands-free.

Here's the proof I'm not looking at anything here. The output element is often used for, like, if stuff is streaming in from a server response. You can think about this as, like, let's say you have a web server, right, and you're doing a deploy, and that deploy is showing you logs. Those are logs being output from the server process.

That's when you would use the output tag. I think that's right. MDN says the HTML element is a container element for a site or app that can inject the results of a calculation or the outcome of a user action. You're right.

So you perform a user action, deploy this website, and you want to stream the results back in, or if you simply just want to, like, we built a compounding interest calculator in one of my courses. I should have used an output element in there to display the actual values at the end of the day. It's an interesting tag. It has a for attribute, and it takes multiple IDs of which inputs they are associated with.

Wild. I didn't know about that one. I knew about it, but I never use it. I'm excited because I don't do that stuff that much, but it's easy to use here to do calculations or, like, as the answer for a calculation.

That's someplace I would actually use it that I haven't thought about before, so that's really interesting. Other interesting elements, dialogue. Dialogue is a new element that gives you a modal. It has a lot of great default styling, but more importantly, it also has accessibility things baked in, like the escape key working.

So dialogue is a fantastic new element that is fully supported that you should use if you need a modal for anything. Please say tables. Really quick, Wes. Do you ever not use tables for tabular data or table data?

That's a great question because sometimes you need to display tabular data, but styling tables is such a pain in the butt. So I find myself being like, hmm, I bet I can do it with grid, and then I always regret it because I guess now that we have subgrid, it's probably a little bit easier, but still not all that useful. I do find myself using tables. However, I find myself putting a div directly inside of my table cell so that I can style a little bit differently because the actual table cell, the TD, TH, are really hard.

There's a lot of limitations. They have a funky display property on them that you can't turn off because then you break how the table works. So I find myself just throwing a div inside of the table cell and then styling that thing how I need it. Yeah, there's a lot there.

I mean, tables, for those folks who haven't existed since the dinosaurs were alive, like Wes and I have, you know, tables used to do, like, the layout for your entire website because we didn't have great layout tools. Everybody used tables to give yourself a structure for your website, but tables nowadays are still handy for tabular data. They are hard to style. Typically, when I want to figure out a more complex table styling, one of the places I go for inspiration is Stripe.

Their dashboards have the best tables. They're styled so well. It's great inspiration for understanding how to style a table and still make it look nice. So you can certainly use tables for this.

I have seen people use divs. In fact, the Drizzle Database Explorer uses divs and display grid. So if you're out there and you're like, I want to see how somebody pro does it that way, the Drizzle Studio, Drizzle Kit Studio, it does it and it works really well and it looks super nice. So you can do either, but typically you're going to reach for a table and then you're going to be Googling different table properties and CSS stuff until you get it to look nice.

We also have audio and video elements. Those are for, you guessed it, displaying audio and video. There are a bunch of tags that go along with the audio and video elements for giving multiple sources as well as for supplying caption tracks to your audio and video. They are not amazing.

By default, they work, but there's very little control over them. And almost always, if you're doing anything custom, you're going to want to reach for something that is fully customizable, like the media element. Media Chrome. Yeah, Media Chrome by the Mux, folks.

If you need video streaming or you need better support or functionality out of the box, Media Chrome is the best way to do it. And it's a web component. It works really great. It has a ton of options and let me tell you the wide world of video and audio components and elements.

Man, there are just, there's so many foot guns and complex process and bad libraries that don't work the way you want them to. So Media Chrome is the best in my mind. There's also the Canvas element, which is a drawing canvas that you can use JavaScript to draw things on. And well, it's actually, Canvas can be really super cool for all kinds of things, but it is kind of, I don't know if it's underutilized, but there's some websites.

Anytime they're doing something that you're looking at it and aesthetically, there's some crazy animations or stuff going on. It's almost always Canvas. Canvas is doing a lot of cool stuff. I've been doing a lot of shader work lately.

So I've been getting more into Canvas overall. 3D Canvas. Yeah, so there's 2D Canvas, which is simply you want to draw squares and circles and text to something. But then there's 3D Canvas, which is you can do, like, twist around and throw a model on there, do shaders.

So what have you been working on with that? Ooh, you know what, really? I ultimately, yeah, ultimately I just want to build really cool looking shit. That's really what it comes down to, is that shaders are allowed to do some crazy stuff.

And graphics programming in general is a wild world. So even just a quick statement on graphics programming, when you're programming for, you know, graphics stuff in general, you're writing code that affects an individual pixel. So the code you're writing is, hey, on this specific pixel, what's happening? But that code also needs to apply to every pixel on the Canvas.

So when you're thinking about it, you're not thinking about, all right, you start here and then you adjust all these pixels. You're thinking about all these pixels at once. The current pixel position, what should this be doing? It's crazy stuff.

So I'll talk a little bit more. We'll do an episode on shaders and I'll have a lot of cool examples. You can see what I mean. But Canvas is pretty neat.

You should check out the githubuniverse.com website. And this is a perfect example of, like, well, I'm not building a game. Why do I need to know 3D? But the tiny little subtlety that you can add with a little bit of 3D Canvas is amazing.

And I dove into it to download the models of all their 3D. And it's pretty wild. They have a whole bunch of masks. And I'm assuming it's all exported from some 3D tooling like Spline is a really sort of easy, accessible one for just regular folks like us to use.

But this is such a fun site. This is an incredible site done with shaders specifically. This Maxime Heckle site is something that's maybe my favorite website that I've been on in the past five years. I mean, it's incredible.

So if you want to see this kind of stuff you can do with Canvas, this is a great site to check out as well. There's also a search tag which you can use to wrap a form or for searching. So if you have a search bar, wrap that whole thing in a search tag, the input and everything. So that's one that a lot of people don't use that exists.

Most websites have search or at least a lot of big websites have search. And I don't know how many search tags we're seeing out there. Beautiful. So that is the fundamentals of HTML.

Obviously, there's a lot more to it, but you kind of get the point of it, right? There's a whole bunch of semantic elements. There's a whole bunch of elements that have baked-in functionality in the browser. And then there are several elements like the Canvas audio video that will allow you to display the rich media on the page.

Let us know if we missed anything you think should be added to the fundamentals. Tweet us at syntax.fm. We'd love to hear it. Yes, absolutely.

Cool. Well, let's get into the part of the show where we talk about sick pics and shameless plugs. I have a sick pic today that is an interesting cleaning brush. And this was suggested to me by a chef that I follow.

He's a chef from Detroit who uses these bamboo wok kitchen cleaning brushes. And these bamboo brushes. And the point of them is he was saying these are the single best things for cleaning your cast iron because they're not too abrasive where they're going to scratch off your seasoning or anything like that. But they're also hard.

So it's not like you're using like a scrub daddy sponge or something like that. And you take this bamboo brush and you kind of like you're using a scraper or something. And it's not going to scrape off your seasoning. It like chips up anything that's baked onto the cast iron?

Yes. And I was trying to use these on normal pans and stuff and been like, I don't know about this buy. This was kind of a weak buy because they didn't work very well. But then the very first time I used it on the cast iron, I saw the light.

These things work very well. They're super cheap. Ten bucks for two. And, you know, it's bamboo.

So it's going to like they're kind of brittle. They're going to break over time. It's not like a buy once thing forever. They're slightly disposable.

But since they're bamboo, you can feel better about that right there. There's no plastic involved here. Yes, exactly. Yeah, straight out of bamboo.

It almost looks like a great green tea whisk for anyone trying to picture it. Yeah, I know. I saw these on Instagram after the chef did it. And yeah, I've been a fan.

So check it out. Well, I've never seen these before. Abrasives. I love.

I've been using carbon steel for almost two years now. I've been using cast iron for probably 15 years. And it's so nice to be able to use abrasive cleaning things and abrasive spatulas on this type of stuff. That's so good.

I just re-seasoned my carbon steel pan the other day. And it was quite the experience, but well worth it. How do you get your seasoning off? Because I recently got a bunch of steel wool to re-season my cast iron because it had been starting to chip up.

I have never had one so bad that I had to like, I know like the pros will dip it in electrolysis. So they'll throw it in like a bath. They'll throw a little anode in there and they'll hook up 12 volts to it and leave it for a while. I've never had one that bad where I really cared about it.

I use soap on my cast iron pretty much every time I clean it, which a lot of people are scared of. And it's totally fine. My cast iron is in really good shape. I don't find I really need to strip it off.

I just need to re-season as, oh, I'm starting to see the color change. You know, it's that nice deep black. And as soon as I start seeing some like lighter ones, or if you go too far, a couple drops left on it start to rust, you know, you need to sort of re-season it. And then I go through all the steps to do that.

I was getting like flaking. Oh yeah. After a period of time, yeah. Yeah.

That's usually like just like burnt on, on the carbon from the food that's being left over. And I find that as well where I have to like super aggressively scrub it off. You can even use like a, like a chain meal. Like one of those things.

I just use hard or a steel wool to get it. Yeah, that'll work. But that's good. I am going to stick pick the Logitech MX Master 3S mouse.

So I've had the 2S for six years now. And you'll see that it is no longer a mouse because it didn't have art. So I was gone for about three, three and a half weeks. And it came back and it wasn't working.

I was like, oh, it probably died. You know, I was gone for so long and the battery died. So I plugged it in and immediately threw up low battery light on my screen. And it wasn't moving, but I could click on it.

And like I could click my volume buttons on it. And I was like, that's weird. And then it just stopped working completely. So I took it apart.

I got my whole volt meter here. I checked the batteries. I put three volts directly to it. I can't get it back.

I think something, one of the capacitors on the charging circuit, or there's a little thermometer in the battery that's a resistor. Either that is broken or something. But I've had this thing for so long. It's like falling apart, all the plastics on it.

So I was like, you know what? I don't got time for this. I'm not going to fix it. I just drove three minutes to the store and bought a new one.

And I got the 3S. And I've had the 2S forever. And this is a new one with aluminum wheels on it. And it's S, which means it's silent.

And probably Randy is going to be very happy about this because when I'm sitting here just thinking about what I'm going to say on the podcast, I'm always clicking my mouse. You know? Composably. Yeah.

And this one is silent. And I absolutely love it. It's got so many buttons on it. You can program them to do volume.

You can program gestures. I'm not big on the gestures because I'd rather use a keyboard shortcut. But I do love it for all the extra controls opening up Spotlight. Or not Spotlight.

I'm whatever. The Mac OS. Yeah. Yeah.

The thing is. Such a good mouse. I post it on Twitter and everybody's like, this is the only mouse that is good for web developers. So check it out if you need a new mouse.

The MX Master 3S from Logitech. Word. Yeah. I just can't get un-mouse usage, but they look nice and nice.

Honestly, you're on a whole nother level. You know what I would love to do is just use a trackpad like you. Yeah. But I try it so many times.

Same with the mechanical keyboards. I think I have like seven mechanical keyboards right now. I have any of them. Yeah.