Ep. 14: Does valid and semantic HTML still matter? With guest Ben Myers

Episode Guests

Ben Myers is a web developer from McKinney, Texas known for their commitment to web accessibility, intentional inclusiveness, and unforgivable puns. Follow Ben on Twitter, and subscribe on Twitch.

Transcript#

Claire:

Welcome back to Word Wrap with Claire...

Steph:

and Steph! You can find the transcript for today's show on wordwrap.dev.

Welcome back to Word Wrap. Claire and I are super excited this episode to be joined by our guest Ben Myers, and they are a front end software engineer at Microsoft. Our topic today is essentially discussion of HTML. Things like is semantic HTML still relevant, and really what we're talking about in terms of what it means to have HTML still be an important core skill, and things of that nature. So I'm going to go ahead and toss it to Ben. Can you just give us an overview of why HTML is important to you? Why you're, you know, passionate about that topic and being an educator around HTML.

Ben:

Absolutely. And thank you so much for having me on I'm super excited to be here. So for context, I feel like most people who would already know who I am would probably have been exposed to my accessibility content. I, I am a passionate advocate for accessibility in all forms. And lately that's really taken the form of learning more about web accessibility and sharing what I know with communities w with the web developer community. So I came to semantic markup through that accessibility journey.

I, when I was first learning about web accessibility, I did all the cursory Googling of please how to make site accessible. And a lot of it really came down to you should have very strong foundations, your markup needs to be semantic. And that brought me down this rabbit hole of kind of core web technologies and just really what the platform gives for us out of the box.

And so that's a lot of what I'm hoping to share with you all today is, you know, why those HTML foundations still matter. And in fact, probably matter even more than ever in this day and age.

Claire:

Yeah.

I don't think if anyone has listened to the show, I don't think anyone's probably a, a stranger to us feeling that way, but it's good to hear someone really deep dive into it, so.

Ben:

So I personally would group HTML elements into three different types. And the types that you're going to need are going to depend largely on what website or web application you're building. So I would group semantic elements into there are your interactive elements. So your buttons are linked to your form elements.

Okay. I there's there. There are landmark elements, which divvy up, you were a page into recognizable sections, and then there's your inline or text level semantics. So these are things like adding strong tags and such to further describe the text contents on your page. I bring this up because I think sometimes when we talk about semantics, we index very heavily on one type of semantic or another in a way that can sometimes make semantics not feel broadly applicable to all web developers.

So today I'm hoping to kind of give a website or product agnostic introduction or not introduction so much as like case for semantics, but grouping out into those three types is I think a helpful way to start thinking about this. And then I would argue that semantics for me at least has kind of five major benefits.

I would say that semantics improves your sites a robust functionality. It improves your site's accessibility. It improves your support for alternative browsing modes that you might not even anticipate. There is search engine optimization. And then finally, I want to argue that semantics is better for you, the developer, you're going to enjoy your product a lot more if you use semantic elements.

Claire:

Yeah. I think it's really important what you said earlier about as you were listing the three types of like seman- like three types of like buckets that elements go into. Because like you said, like, you know, a lot of things a lot of people tend to focus on like the landmarks or maybe the interactive bits.

But I find that a lot of folks don't really know why you would use a `strong` tag over a `b` tag or use, you know why you'd use a div over a span or, you know, et cetera. So do you want to go into a little bit of why semantics really helps just the robust functionality of a web app in general?

Ben:

Yeah. So every element or every tag, I guess I should say has a expected meaning associated with it. And many of them, the interactive elements in particular have like expected functionality to them. And so what I mean by this is when you're using a button tag, for instance, you are describing, Hey, this is a thing that you can click or press or interact with the keyboard, and something's going to happen. A form will get submitted or maybe a dialogue will open up. There is that meaning there of what is this thing doing here? It's a clickable thing or a pressable thing. And how do I use it? And so semantics is kind of the, the, the mission of using these tags that best express, this desired functionality and meaning.

And when you don't have that your user experience can be lacking in your user's expectations. So a while back Twitter did a redesign and I don't really want to cast dispersions on them. But one of the things I found about their redesign was that when you're in your feed, every tweet is an article tag and that article tag has a click event associated with it.

So if you wanted to open up that tweet in a more prominent view and see its replies, you could click it and it would open up. The, the trouble is they go to a lot of lengths to make you think that it's not really an article, but that it's a link. They add a hover state there's client side routing that happens, the URL bar even changes, but there's no links. There's no anchor tags associated with this.

And what that meant was back in 2019, I was really expecting to interact with this tweet as though it were a link. I middle click the tweet to open it up in a new tab and nothing happened because it wasn't an anchor tag. It didn't have that functionality built in.

Now, I don't want to say that them using an article for a tweet was the wrong thing. But I do want to suggest that because they went through a lot of effort to make me think this was a link when I attempted to interact with it as though it were a link and those expectations were not met, I was confused and frustrated.

And so this is what I mean about robust functionality. These elements all have a behavior baked into them from the browsers that your users have come to expect. And when you use these elements, you get all of that functionality out of the box. It's fantastic. And when you don't use those elements, when you instead go through hoops to make people think that you've got a different experience going on, it's easy to miss out.

One of the ways I've described this is when you reinvent the wheel it's very easy to miss a few spokes along the way that you just didn't anticipate. And for the record, Twitter has totally fixed that middle click thing now, but yeah.

So that is functionality that your users already expect just given for you out of the box. You don't have to worry about it. You don't have to predict it ahead of time. You don't have to write a feature and stick it on JIRA to support middle clicking. You don't have to worry about the bugs that ensue. You don't have to write that code, it's all there for you for free.

Claire:

I do wonder, I'm curious your thoughts on this. You know, earlier in my web dev career, I was making an accordion. And, you know, an accordion is kind of one of those weird interactive elements where we don't have something for it in HTML. I mean, I guess you could say that the details and summary elements may be it, but it's, you know, there's a whole plethora of articles about how it's not actually an accordion, et cetera.

I digress. So. I think in that instance, there was an, there was, you know kind of a debate between me and the team of like, should that be a button? Should that be a div with a click event? Should that be what cause what, what is it? Is it a button? Is it, you know? And so I kind of wonder if that same debate might've happened there where the tweet itself is a piece of information that might be, you know, semantically an article. But at the same time, there's this need and desire to make it easier for the user to make, to, you know go to the specific tweet or something.

And admittedly, I would probably make an uh, make a explicit action of like expand tweet or, you know, go to tweet or something like that instead of making the whole thing clickable. But I also understand the desire to do so. So at that point, does it become you know, an article or is it, is it still an article or is it a button?

And I think, I think what you bring up is a very good point because like you said, reinventing the wheel, you know, you miss a lot of the, you might miss a lot of the things along the way. But I also do think that's probably something that a lot of people struggle with is what is the real, and right answer.

Ben:

Absolutely. And I have no easy answer for that. All I can say is that the correct answer is whatever your user testing says. You should like, but those, those interactions are in there.

You know, the, the web is several decades old at this point. Like people have kind of gotten used to a lot of those conventions.

Even as the web becomes more and more interactive, people have gotten used to some of these conventions and. I don't know. It's like, it's so easy to miss out that I certainly wouldn't want to take on the responsibility for reimplementing a lot of the functionality that certain people, even if they're what we might consider, like power users might be expecting, I would just want something to give me this out of the box predictably in a way that behaves the same across all browsers or across all pages within the same browser.

Claire:

I think that leads us into the next topic you wanted to talk about, which is accessibility and, you know, missing those things along the way, like, accessibility, if we kind of broaden the picture, but accessibility benefits everyone. And so like I think about curved in the United States the Americans with disabilities act mandated that all sidewalks must, what is it? Ramp slope into the streets without a sharp cutoff and that benefits everyone. That benefits, you know, bikers, that benefits folks that just aren't looking or, you know, whatever the case may be. And so that's a pretty good example of how accessibility can benefit everyone. But using the right semantics seems to also benefit without maybe even someone thinking about it, someone is using or that, that is, you know an accessibility or accessible user or, you know, someone that benefits from accessibility. Or if you want to go into that a little more.

Ben:

Absolutely. So in terms of some of the functionality that disabled users might expect, when you come into your page there are things like keyboard navigability, right? All of that stuff. If you're tabbing to elements, or if you're using your arrow keys and your space keys to interact with that stuff.

When you're using semantic elements out of the box you get all of that stuff for free.

So if folks can't use a mouse perhaps because they're paralyzed or because they're blind and the idea of a cursor floating around in two dimensional space, isn't that helpful a mental model for them. They get that keyboard functionality out of the box, but then other folks will use assistive technologies.

Some of the more prominent ones that we talk about would be screen readers but there's also voice controls and alternative inputs and stuff that

The story is all pretty much the same of these different devices and softwares and inputs that disabled users use, take these semantic elements and interpret them into user experiences.

So for instance, if I'm using a screen reader, I might want to be able to skim through the page really quickly and see what the content is. If I were sighted I could scroll through, I could see the headings and get a good sense of where the content on the page is that I want. But screen readers are very, very linear software. And to compensate, they've added functionality where you can skip between different elements of the same type.

So I could skip from heading to heading. And so that means that headings are very meaningful to me or rather to screen reader users. I don't personally use them in my day to day, but headings are very meaningful for screen reader users as a way to indicate the kind of outline of the page. Another way this is that semantics benefit screen reader users is in the use of landmark elements. These are your tags, such as the header tag, the main tag, the footer tag, aside. If you're sighted, these elements, seem little more than a glorified `div`. A `div` under any other name. But if you're using assistive technology, these things are really meaningful because they break up the page in a way that makes it really easy for a screen reader user to just directly hop to.

So, you know, oh, I know that this page front loads with a whole bunch of links, I'm going to skip over those. And I want to get to the main content. I can go into my screen reader. I can hit a shortcut and hop directly there. I can do that because the developer used the main tag, which told me the, the main context. Without that tag, the screen reader user would not be able to hop directly to that, or they would have to rely on some other workarounds.

So divvying up our page with these landmark elements gives a screen reader users hotspots that they can jump directly to to get the content that they care about instead of having to chug through everything very, very linearly.

And there are other ways of which semantics can impact accessibility. I mentioned voice control earlier. I don't feel like we talk about voice control enough in accessibly spaces, but using semantic elements means it's possible for someone to say like for instance, click and then the name of a button and because the browser and the assistive technology know that this thing is a button, they know that the click command is associated with that button. So if you've got a button that says for instance "submit tweet" I could say click submit tweet. And it's because I use that button element that the assistive technology knows what it is I'm referring to and what actions can be taken on that.

So in general, using semantic elements gives our browsers and assistive technologies the best possible chance to determine how to interpret how our web content into an experience that's compatible with assistive technologies and with alternate modes of navigating the page.

Steph:

Yeah. Awesome. And, you know, speaking of voice control, I attended the virtual Access All Areas conference that took place in the recent times here.

And I don't remember the presenter, but they brought a bunch of videos showing those different ways that folks will interact and with a big emphasis on voice control such as Dragon Naturally Speaking. And one of the things that stood out to me was, I knew this as a principle, but to see somebody actually struggle with it in action was pretty powerful. But anyway, when they said, you know, click go to classes or whatever the, the website said, then the voice control prompted them. And they had to choose a number because there were multiple links that contained that sequence of whatever the sequence of words was. And so you know, that's kind of beyond the basic of choosing what HTML semantics, but it's still to be relevant to the conversation because you know, essentially all those choices you make, you kind of, it makes sense in the moment, but if you're not thinking of this grander scale of impact. You know, it can cause confusion and frustration and just getting a better awareness of that is super important.

Claire:

I wanted to add in one thing. I think it's really important that I think a lot of folks approach developing for the web as a simply visual thing. That most people will see it and they'll be like, oh, I can figure out what that is. The whole idea of using semantics and the whole idea of, of developing with accessibility in mind is not necessarily making it so that a portion of users to be able to use the site.

It shouldn't be thought about like that. It should be thought about as we're making these very visual, very, you know, if, if everyone, like, if everyone looked at it and they were sighted they were able to figure it out. You're telling a computer what this is. Because at the end of the day a, computer's not going to be able to tell what div is what div and you know, like it doesn't have that discern ability.

Maybe the AI gods will help us solve that. I don't know. I hope not. But you know, like Ben was saying. You know, with voice control or with screen readers, these are things interpreting these pages for a person. And so if you do not give the, you know, the meaning behind something, or, you know, even just using a header tag instead of a, you know. Cause at one point in time, I'm guilty of thinking the header tag was a glorified div tag. I am totally guilty of that. But that clarifies intent. It clarifies what that is for in a way that we've already programmed a computer to do X or Y based upon it. And I think back to this, this quote that I've heard a lot, which is computers only will do what we tell them to do. And so if we don't tell them what it is, they're going to just go to a default. They're just going to be like, yeah. It's like giving every link "click here". Like sure, someone might be able to figure it out, but you know, on its own, you wouldn't be able to.

Ben:

Absolutely. And I think this really gets to the heart at really, really, truly why is semantics important? Which is that any time someone accesses your web content they are doing so in a computer mediated way. We talk about our pages as though they were HTML and stuff on the page.

Okay. Users don't care about your HTML. They, they, they don't look at the source. It's not like they're looking at the source code to figure out like, oh, what is this content? Right. Instead, the consistent story of navigating the web is that I am on some device. And that device is interpreting the HTML for me to create a usable user experience as web developers.

Our mission is to make the most usable user experience. And so the way to do that, the secret sauce, is to give the device as much information as possible, to be as expressive as possible about our intent, so that the device has all the information it needs to be able to create the most usable user experience. And that is what semantics is for.

Claire:

Maybe we should start circulating the phrase of, you know, how people sometimes say pictures are worth a thousand words, maybe semantics are worth a thousand words. Because like you said, you get a lot of things for free just by utilizing a header tag instead of a div tag, you know, in the, in the appropriate place.

Ben:

So. And this actually ties in a way to the kind of the third argument I would make, which is alternative browsing modes. And there are a few that I could talk about here. And I don't think that these are going to apply to every single site. Things like functionality and accessibility. Those apply to every site.

What we're getting into here is a little more contextual. Especially it's more geared around your content based sites like news sites or blogs and technical documentation and stuff like that. But Claire, as you were saying, like, we, we, we. We have this mindset, this assumption about how folks are navigating our page or how they're experiencing it, rather, what does a very visual mindset. I wanted to call out another assumption, which is that we expect that folks are viewing our content on our site with our styles. This is just kind of an implicit assumption that developers often have. And this often isn't true, especially when you're in the content space, is very, very likely that someone could be accessing your page with reader mode. Browsers have those built in reader modes features where it blows away all the distractions, blows away all the styles. And what you're left with is more or less the sheer raw text that exists inside of your main element. And so we still want to make sure that folks who are using reader mode still have a fully featured experience. They get all the content that they need. And the way the browser decides what's important for reader mode is - you guessed it - the semantic markup that you use.

This is a similar story for anyone who's accessing your content in their favorite RSS reader. So. These are different ways folks could be accessing the content. And then they might be using devices that you haven't anticipated, devices that don't even exist yet.

One of my favorite articles about someantic markup is from Bruce Lawson, who was talking about how, you know, ages ago he wrote his personal site using semantic elements, and then Apple came out with the Apple watch. And he pulled up his page in the Apple Watch browser. And, you know, the, the smartwatch blows away all of the styles because there's no way any of that content could fit in just a smartwatch screen. It converts everything to just texts. There's adapted experiences for things like images and such. And everything worked out of the box. He didn't have to make any changes because the site had already leveraged strong strong foundation of expressive semantic elements. The smartwatch knew what to do with it even before Bruce knew that smartwatches were going to be a thing.

Claire:

Yeah. And that's, that's the key in st- sticking with standards, sticking with things that have been mutually agreed upon. Because when we build new things, hopefully we're using standards in order to, you know, create a basis.

Another alternate browsing mode that I thought of was like if I ask Google Home something. You know, I know some of those things are curated, but others, you know, will take from like the first couple sentences in a main element or something. You know, and that that's automatic. I don't plan for that, but by using semantics it kind of just comes free.

And I think that actually leads us right into the near fourth point, which was SEO. Because that, I mean, that's another, it's another computer trying to interpret what you're doing with, with your site. But this one has a lot of businessy bits to it.

Ben:

The thought about search engine optimization, that when I'd realized that it kind of, it was a mind blown kind of moment for me.

Which is that that the Google search results page is still a user experience. It's still, in fact, your user's experience. Is still a way in which your users experience that experience your page to get the information that they're looking for. And here are the devices aren't trying to figure out how to make user interface elements, work, and stuff like that. But instead, the device's goal is to find the relevant information on the page and surface it in a short enough blurb and prioritize which sites might have the most or most relevant information about whatever it is, the users' looking. So that's, that's how they're interpreting your web content to make a user experience for your users.

Even if it's not on our site, right. It's not on our.com. It's not on our domain. Search engines again, because they're their devices, they need as much help as they can get to understand the content on our page. And if it's important at all, and why it's relevant. Using semantic elements can give the search engines as much information as possible about the contents of your page and how it's structured.

One of the big ones that people talk about here is your heading tag, your `h1` through `h6` tags, which Google and other search engines use to understand effectively, how has your page laid out? Is it structured in a way that's meaningful for folks who are looking for certain kinds of information. So again, when you follow that kind of outline structure for your headings, where every level of heading describes effectively a nested section within a section within a section, Google knows: hey, this is how you're structuring your content. And this is what information is relevant. So when you do that well, when you do it appropriately, Google is going to give you a bit of extra search engine juice, because it knows that users are going to have a good experience getting the information they need if they go to your page.

Yeah, definitely search engine optimization, by the way, a favorite selling point for semantic markup, if you work in the marketing space. It's, it's definitely the most businessy of all of these reasons. I think. Gotta get that SEO.

Claire:

Yeah, no, it's true. I've used it on several accounts. If something hadn't been made with semantics or accessibility in mind, I always use SEO or something like that that has business implications, or you could argue it.

Steph:

Indeed. Yeah, it, I just, one more point on that, that I thought of was, you know, the structural elements, but also how it lends to the hierarchy and being able to just overall understand the content that's there. I know Chris Coyier brought up a few months ago how Google is actually changing the search result title.

So they're not even necessarily using what you provide. They're diving that deep into your page content to summarize essentially and surface the most relevant part. We knew they were doing that in descriptions, but they're doing in titles now too sometimes. So if you have structured your content appropriately, then, you know, although we're kind of deprioritizing it as, you know, an important thing, you know, you're going to, again, you're going to do better on the SEO. It's just, it's just all goes hand in hand at it. You know, all of these things work together to improve both user experience once they land on your site, but also in getting them there in the first place, so.

Ben:

It's worth calling out because I think sometimes some folks in the search engine optimization space can recommend kind of tricks and hacks that they tell you will totally beef up your, your rankings in the search engine of choice. Google I know is very secretive about their search engine like algorithms.

However, one of the points that they've been most consistent on is so long as you're using your semantics well and appropriately and expressively, you're gonna be fine. You're going to do fine. So that is a thing to call out is just follow the standards, focus on how can I use the elements that best express, what kind of content this is?

You'll be fine. If you find yourself feeling like you're resorting to hacks or stuffing keywords in your headings, like you're probably abusing semantics, which means you're creating a worse off experience for your users. And also it's not going to work out as well for you in Google or other search engines as you think it might.

Steph:

Yeah. All right. So that was all awesome information and excellent points to consider and take away. But as a developer, what's in it for me?

Ben:

Yeah. So first of all, I think anyone who has worked with me like at the code level before, knows that one of my favorite things is code that is very expressive.

I believe personally, that expressiveness beats out any other mantra about code cleanliness or anything like that. And writing expressive code has never led me astray.

And if you think about it, we, when we use semantic elements to express the contents of our page for our users devices, that expressiveness kind of loops back in on itself and helps us out as well. So I don't know if you've ever had the experience of opening up your pages' dev tools and having to dig through div after div to find the div that is really important, right? Like if everything is the same, if everything is a div or some other element, it makes it really hard to debug. It makes it hard to know what markup is corresponding to which piece of your code or which piece of your content.

And so by leveraging semantic elements, honestly as developers, it means that we're naming our elements better. And we, we don't even have to come up with the names. The worldwide web consortium has already done the hard part of coming up with the names for us. We get to leverage it and it makes our code readable. Heck yeah, that's a win. And this, you know, this pays dividends, tenfold in other things such as CSS.

I know that we're all big fans of CSS here on this show. I've joked on Twitter before that my favorite CSS methodology is semantic markup because being able to stick the word "nav" in my styles, instead of having to come up with a class for this particular nav is hugely expressive for me. I don't have to come up with those names. It's just there and it makes my CSS more readable as well, in my opinion. So I really like that expressiveness it, it rewards the developer. It makes things easier to debug and to select for. And when you're using the full range of semantic elements, that make sense for your page, and when you're following the standards, that also helps, I think, when it comes to your stylesheets.

And it's like, I'm a big fan of the DL element. I don't feel like it's talked about enough, which is why I wrote a blog post about it. But if you're unfamiliar with the DL element, it describes a list of key value pairs. And it can have effectively two kinds of children, the DT element, which is your terms, your, your keys, the names, in your name, value pairs. And then there's your DD element, which is like the, the details or the values in your name value pairs. And that's it. You can have some divs for wrapping inside, but that is. We have whittled down the list of available semantics once you've entered a DL, which means that you basically only have names and values. And those two elements, the DT and the DD, they can only exist within a DL element.

And this means that as you're styling, you can directly target those DTs and DDs and, you know that's not going to be impacting other stuff across the rest of your page. Because you know, you're following specs you're only using these elements as appropriate. So your code gets to be expressive about the functionality of the thing. And it's just easier to read.

Claire:

Yeah, no, I agree. Also side note, I'm so glad that they allowed divs within DLs because styling, it was kind of hard when when you have repetitive ones, I don't want to digress. Point is: cool element and it is definitely one of the better ones, although it's on the DL. Ha ha joke.

But yeah, that was great. Thank you for going through a lot of that and yeah. Semantics in general, like, you know, it's not just limited to just HTML. They still matter within any kind of framework, they still matter no matter how you're interacting with the web. You're probably going to be exporting HTML at some point. So the source also needs to utilize those semantics as well.

Ben:

And all web content is eventually HTML. All HTML is eventually interpreted by your users' devices to create the best possible user experience for them. The robust accessible experience that they're hoping for.

And, you know, the mission of semantics is to provide as much information ahead of time, to express as much of the intent ahead of time, so that your devices have what they need to be able to create that user experience.

Steph:

Yeah, absolutely. I think it's worth noting before we end the episode, too, that a lot of confusion in my experience comes from you know, going beyond the basics that are needed for content and trying to create more functionality. I don't want to deep dive into that tangent, but what I did want to mention is for those that aren't familiar, the Open UI project.

So some of the things they literally say in their charter, developers re-invent the same components for every product they build. And if those aren't in HTML currently, you know, that's where we introduce a lot of bugs and we miss a lot of things as, as Ben was talking about. So I encourage folks to check out that Open UI project, just as an example, some of the things that they are working to bring into the standards for HTML and things that would be natively available include things like tabs, which I think would be huge. I think there's a lot of momentum on that one in particular. And they've also looked at trying to improve dialog, which exists, but has some issues. Things like a way to provide functionality related to tool tips and similar features.

So in other words, the browser itself would help you have that functionality and also ideally have best practices around accessibility baked in. So just something for everyone to keep you know, keep on your radar and know that HTML is not a stagnant language either. It is also being evolved and to meet these needs and particularly improve, you know, where accessibility is concerned.

And, to help developers make these decisions more efficiently and overall produce a better outcome. So any last thoughts, Ben, before we close? That was so much to think about. This is been really great discussion and you know, just even as someone who, you know, we think that we use HTML everyday, but you know, we've, you've already given me some, a little bit different angle on some stuff to think about as I go forward.

So yeah. Any last, last comment?

Ben:

I don't know that I have any actually just, yeah, I don't think I have any,

Steph:

No problem! Claire?

Claire:

No, I just, I love that it's called the HTML living standard now, instead of having numbers, I was just reflecting on that while you were mentioning that it's living and breathing.

Ben:

The web is a far more robust platform I think then we sometimes make it out to be. And like y'all have mentioned it is getting better and better all the time by, by leveraging kind of the hard work that the specs authors and the browser developers have done for us. Like we can create these like excellently, predictable experiences.

You just, you just kind of have to put your faith in HTML, I think, and in its ability to provide.

Claire:

Yeah. And I also think, you know, that's another another good closing point is that HTML is not just something for, you know, elites or anything like that. I mean, I helped propose something in the container - CSS container query spec, for example. You know, I don't think of myself as much, but I thought that was pretty cool.

And like anyone can propose a lot of things. Just, you know, it's a community and, and, and whatnot. So anyway, thanks Ben for joining us. It's been great. Semantics are cool.

Ben:

Semantics are cool. We need, we need that on a t-shirt.

Claire:

Thanks for listening. Be sure to subscribe and keep in touch on Twitter by following us @WordWrapShow. If you're able to cover show costs, join us at Patreon.com/WordWrap. We'll see you next episode!