Article Series<\/h3>\n <\/header>\n \n \n - \n Building a TODO App from Scratch \u2014 Step 1 \u2014 Planning & Design<\/a>\n <\/li>\n
- \n Building a TODO App from Scratch \u2014 Step 2 \u2014 HTML<\/a>\n <\/li>\n
- \n Building a TODO App from Scratch \u2014 Step 3 \u2014 Basic JavaScript Functionality<\/a>\n <\/li>\n
- \n Building a TODO App from Scratch \u2014 Step 4 \u2014 Styling & Interactive Choices<\/a>\n <\/li>\n
- \n Building a TODO App from Scratch \u2014 Step 5 \u2014 Extra Functionality<\/a>\n <\/li>\n <\/ol>\n <\/div>\n<\/div>\n\n\n\n
Is HTML jumping the gun?<\/h2>\n\n\n\n
Nah.<\/p>\n\n\n\n
The reason that we can jump to HTML right away is that it is common<\/em> to any other future choice we make. As I mentioned, we might just stay in entirely vanilla land, but let’s say we chose a JavaScript framework instead. Those frameworks will likely all have their own slightly special takes on HTML.<\/p>\n\n\n\n\n- If we pick Vue it might have funny attributes like
@input<\/code>, :value<\/code>, or v-for<\/code><\/li>\n\n\n\n- If we pick React we might be using JSX and have funny attributes like
className<\/code> or onClick<\/code> and we might see .map()<\/code> a lot.<\/li>\n\n\n\n- If we pick Svelte we might see stuff like
on:click<\/code> and {#if}<\/code> blocks. <\/li>\n<\/ul>\n\n\n\nEven if we go with native Web Components, we’ll see attributes you might not see every day like part<\/code> and elements like <slot \/><\/code>.<\/p>\n\n\n\nBut… it doesn’t really matter. All of them really need to start with solid semantic and accessible HTML<\/strong>, and no matter what other choices we make, we can acquiesce to their specific syntax. <\/p>\n\n\n\nThe Parts<\/h2>\n\n\n\n
We can look at our very simple design and get a sense for the main parts of the HTML:<\/p>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2024\/02\/Screenshot-2024-02-14-at-4.49.28%E2%80%AFPM.png?resize=1024%2C682&ssl=1\")
<\/figure>\n\n\n\nThe Header<\/h3>\n\n\n\n
The header is just a decorative thing. Maybe something like:<\/p>\n\n\n
<header<\/span>><\/span>\n <svg<\/span> ...<\/span> \/><\/span>\n <h1<\/span>><\/span>TODO<\/h1<\/span>><\/span>\n<\/header<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\nThe <h1><\/code> is perhaps a little controversial. I often prefer “saving” that for whatever the main focus of the page is. But in this case since the name of the app is doing that for us, it kinda works. Otherwise a <div><\/code> or whatever is fine here.<\/p>\n\n\n\nThe Form<\/h3>\n\n\n\n
The <form><\/code> feels vitally important to me. Already in poking around at other web-based to-do apps I’ve seen some inaccessible forms which feels sad to me for something so simple. <\/p>\n\n\n\nThe trick is:<\/p>\n\n\n\n
\n- Actually using a
<form><\/code>.<\/li>\n\n\n\n- Making sure the
<input><\/code> is properly <label><\/code>ed. <\/li>\n\n\n\n- Offering a submit
<button><\/code>.<\/li>\n<\/ol>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2024\/02\/Screenshot-2024-02-15-at-2.11.03%E2%80%AFPM.png?resize=1024%2C437&ssl=1\")
<\/figure>\n\n\n<form id=\"todo-form\"<\/span> class<\/span><\/span>=\"todo-form\"<\/span>>\n <label<\/span>><\/span>\n <span<\/span> class<\/span>=\"screen-reader-text\"<\/span>><\/span>New TODO<\/span<\/span>><\/span>\n <input<\/span> type<\/span>=\"text\"<\/span> name<\/span>=\"todo\"<\/span>><\/span>\n <\/label<\/span>><\/span>\n <button<\/span>><\/span>Add<\/button<\/span>><\/span>\n<\/form<\/span>><\/span><\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nI like having the id<\/code> on the form for getting our hands on it in JavaScript like we’re likely going to want to. We can make the interactive event of adding a new to-do happen on the submit<\/code> event. Plus that makes us ready for potentially adding more information into the form later if we wanted, like, say, a date picker for a deadline. The submit<\/code> event will still work great for us, instead of something more specific like watching for the enter key being pressed while any specific input is focused.<\/p>\n\n\n\nI added the class<\/code> for styling. That’s just a habit of mine, preferring to style with mostly classes for fairly flat specificity. If you have your own methods or use Tailwind or whatever, you likely already know what you’re doing and godspeed.<\/p>\n\n\n\nNotice my <label><\/code> doesn’t have a for<\/code> attribute like you normally see, and that’s because the <input><\/code> is nested<\/em> within it, which is a valid pattern. I like the pattern as it’s one less thing to screw up. <\/p>\n\n\n\nThe actual text of the label we’re hiding, as-per the design. That’s also a little controversial, but I think is generally fine. It’s fairly clear what this form does, and if you were using a screen reader, the actual label text is still there even if we do hide it visually with CSS.<\/p>\n\n\n\n
Last, the <button><\/code> is a lone wolf within the form, and that’ll make it be a submit button automatically. We could use an <input type=\"submit\" \/><\/code> as well, which is fine, but I like buttons. You can put more stuff in them and their type is implied in simple situations like this.<\/p>\n\n\n\nThe List<\/h3>\n\n\n\n
The interesting thing about the list is that it’s going to be dynamically generated. We’ll have as many to-do list items as our data tells us. We can start with just the wrapper:<\/p>\n\n\n
<ol<\/span> id<\/span>=\"todo-list\"<\/span> class<\/span>=\"todo-list\"<\/span>><\/span><\/ol<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\nAgain using the ol’ id<\/code>\/class<\/code> one two punch there. I feel like an ordered<\/em> list is appropriate somehow. Especially if we eventually add sorting of the list, then the order is very intentional and deserves that treatment. And the fact that we’re using a list at all feels right. Lists announce themselves as such in screen readers, including how many items are in the list, which may be a useful bit of information. That’s more than a bunch of <div><\/code>s would do!<\/p>\n\n\n\nThe each list item becomes a <li><\/code>, but the extra stuff in there is going to beef it up. Let’s pause on the re-ordering and edit-ability for now and just focus on the item and the ability to complete it. <\/p>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2024\/02\/Screenshot-2024-02-15-at-2.13.59%E2%80%AFPM.png?resize=1024%2C441&ssl=1\")
<\/figure>\n\n\n<li<\/span> id<\/span>=\"something-unique\"<\/span>><\/span>\n <button<\/span> aria-label<\/span>=\"Complete\"<\/span>><\/span>\n <svg<\/span> ...<\/span> \/><\/span>\n <\/button<\/span>><\/span>\n To-do text\n<\/li<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\nI figure each list item will have a unique ID on it. Actions taken on it will need to be unique to that item so that’ll be the main identifier. Maybe we don’t need it yet but we probably will. No class name here as I feel like selecting .todo-list > li<\/code> is probably fine. We could always add it. <\/p>\n\n\n\nOur design makes the interactive element to complete a to-do look like a checkbox, and we could use an <input type=\"checkbox\" \/><\/code>, but I’m kinda torn. This is where visual design and interactive design collide. <\/strong>We didn’t think out the interaction of completing a to-do all the way. What happens when you click that thing? Does it instantly<\/em> get marked as done? Then disappear? Maybe it instantly gets marked as done but doesn’t disappear from the list. Or maybe there is like a 5-second countdown before it gets removed, so you have a chance to undo it in case it was a mistake. <\/p>\n\n\n\nI kinda like the delay idea, which to me leads me more toward the path of using an <input type=\"checkbox\"><\/code> for that with the very obvious two states. We could really do it either way. If we keep the <button><\/code>, we’d just need to make sure to use an aria-pressed<\/code> role<\/a> for the two states accordingly.<\/p>\n\n\n\nLastly, the position of that interactive element I have listed first<\/em> here, before the text of the to-do, because that’s how it looks in the design. I could see the case being made though that in the HTML it should come after, just so that it reads nicer. Like as you tab through the list, you’d potentially hear the list item and then<\/em> the button text offering to complete it. I’m not 100% sure what the right answer is there, so I think we’ll leave it first, because that’s the visual<\/em> order, and I’ve heard it’s often best to match the source order and visual order.<\/p>\n\n\n\nLet’s stop there<\/h2>\n\n\n\n
With some very light wireframe-y CSS applied to those classes, we get this:<\/p>\n\n\n\n
- \n
- \n Building a TODO App from Scratch \u2014 Step 1 \u2014 Planning & Design<\/a>\n <\/li>\n
- \n Building a TODO App from Scratch \u2014 Step 2 \u2014 HTML<\/a>\n <\/li>\n
- \n Building a TODO App from Scratch \u2014 Step 3 \u2014 Basic JavaScript Functionality<\/a>\n <\/li>\n
- \n Building a TODO App from Scratch \u2014 Step 4 \u2014 Styling & Interactive Choices<\/a>\n <\/li>\n
- \n Building a TODO App from Scratch \u2014 Step 5 \u2014 Extra Functionality<\/a>\n <\/li>\n <\/ol>\n <\/div>\n<\/div>\n\n\n\n
Is HTML jumping the gun?<\/h2>\n\n\n\n
Nah.<\/p>\n\n\n\n
The reason that we can jump to HTML right away is that it is common<\/em> to any other future choice we make. As I mentioned, we might just stay in entirely vanilla land, but let’s say we chose a JavaScript framework instead. Those frameworks will likely all have their own slightly special takes on HTML.<\/p>\n\n\n\n
- \n
- If we pick Vue it might have funny attributes like
@input<\/code>,:value<\/code>, orv-for<\/code><\/li>\n\n\n\n- If we pick React we might be using JSX and have funny attributes like
className<\/code> oronClick<\/code> and we might see.map()<\/code> a lot.<\/li>\n\n\n\n- If we pick Svelte we might see stuff like
on:click<\/code> and{#if}<\/code> blocks. <\/li>\n<\/ul>\n\n\n\nEven if we go with native Web Components, we’ll see attributes you might not see every day like
part<\/code> and elements like<slot \/><\/code>.<\/p>\n\n\n\nBut… it doesn’t really matter. All of them really need to start with solid semantic and accessible HTML<\/strong>, and no matter what other choices we make, we can acquiesce to their specific syntax. <\/p>\n\n\n\n
The Parts<\/h2>\n\n\n\n
We can look at our very simple design and get a sense for the main parts of the HTML:<\/p>\n\n\n\n
<\/figure>\n\n\n\nThe Header<\/h3>\n\n\n\n
The header is just a decorative thing. Maybe something like:<\/p>\n\n\n
<header<\/span>><\/span>\n <svg<\/span> ...<\/span> \/><\/span>\n <h1<\/span>><\/span>TODO<\/h1<\/span>><\/span>\n<\/header<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\nThe
<h1><\/code> is perhaps a little controversial. I often prefer “saving” that for whatever the main focus of the page is. But in this case since the name of the app is doing that for us, it kinda works. Otherwise a<div><\/code> or whatever is fine here.<\/p>\n\n\n\nThe Form<\/h3>\n\n\n\n
The
<form><\/code> feels vitally important to me. Already in poking around at other web-based to-do apps I’ve seen some inaccessible forms which feels sad to me for something so simple. <\/p>\n\n\n\nThe trick is:<\/p>\n\n\n\n
- \n
- Actually using a
<form><\/code>.<\/li>\n\n\n\n- Making sure the
<input><\/code> is properly<label><\/code>ed. <\/li>\n\n\n\n- Offering a submit
<button><\/code>.<\/li>\n<\/ol>\n\n\n\n<\/figure>\n\n\n<form id=\"todo-form\"<\/span> class<\/span><\/span>=\"todo-form\"<\/span>>\n <label<\/span>><\/span>\n <span<\/span> class<\/span>=\"screen-reader-text\"<\/span>><\/span>New TODO<\/span<\/span>><\/span>\n <input<\/span> type<\/span>=\"text\"<\/span> name<\/span>=\"todo\"<\/span>><\/span>\n <\/label<\/span>><\/span>\n <button<\/span>><\/span>Add<\/button<\/span>><\/span>\n<\/form<\/span>><\/span><\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nI like having the
id<\/code> on the form for getting our hands on it in JavaScript like we’re likely going to want to. We can make the interactive event of adding a new to-do happen on thesubmit<\/code> event. Plus that makes us ready for potentially adding more information into the form later if we wanted, like, say, a date picker for a deadline. Thesubmit<\/code> event will still work great for us, instead of something more specific like watching for the enter key being pressed while any specific input is focused.<\/p>\n\n\n\nI added the
class<\/code> for styling. That’s just a habit of mine, preferring to style with mostly classes for fairly flat specificity. If you have your own methods or use Tailwind or whatever, you likely already know what you’re doing and godspeed.<\/p>\n\n\n\nNotice my
<label><\/code> doesn’t have afor<\/code> attribute like you normally see, and that’s because the<input><\/code> is nested<\/em> within it, which is a valid pattern. I like the pattern as it’s one less thing to screw up. <\/p>\n\n\n\nThe actual text of the label we’re hiding, as-per the design. That’s also a little controversial, but I think is generally fine. It’s fairly clear what this form does, and if you were using a screen reader, the actual label text is still there even if we do hide it visually with CSS.<\/p>\n\n\n\n
Last, the
<button><\/code> is a lone wolf within the form, and that’ll make it be a submit button automatically. We could use an<input type=\"submit\" \/><\/code> as well, which is fine, but I like buttons. You can put more stuff in them and their type is implied in simple situations like this.<\/p>\n\n\n\nThe List<\/h3>\n\n\n\n
The interesting thing about the list is that it’s going to be dynamically generated. We’ll have as many to-do list items as our data tells us. We can start with just the wrapper:<\/p>\n\n\n
<ol<\/span> id<\/span>=\"todo-list\"<\/span> class<\/span>=\"todo-list\"<\/span>><\/span><\/ol<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\nAgain using the ol’
id<\/code>\/class<\/code> one two punch there. I feel like an ordered<\/em> list is appropriate somehow. Especially if we eventually add sorting of the list, then the order is very intentional and deserves that treatment. And the fact that we’re using a list at all feels right. Lists announce themselves as such in screen readers, including how many items are in the list, which may be a useful bit of information. That’s more than a bunch of<div><\/code>s would do!<\/p>\n\n\n\nThe each list item becomes a
<li><\/code>, but the extra stuff in there is going to beef it up. Let’s pause on the re-ordering and edit-ability for now and just focus on the item and the ability to complete it. <\/p>\n\n\n\n<\/figure>\n\n\n<li<\/span> id<\/span>=\"something-unique\"<\/span>><\/span>\n <button<\/span> aria-label<\/span>=\"Complete\"<\/span>><\/span>\n <svg<\/span> ...<\/span> \/><\/span>\n <\/button<\/span>><\/span>\n To-do text\n<\/li<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\nI figure each list item will have a unique ID on it. Actions taken on it will need to be unique to that item so that’ll be the main identifier. Maybe we don’t need it yet but we probably will. No class name here as I feel like selecting
.todo-list > li<\/code> is probably fine. We could always add it. <\/p>\n\n\n\nOur design makes the interactive element to complete a to-do look like a checkbox, and we could use an
<input type=\"checkbox\" \/><\/code>, but I’m kinda torn. This is where visual design and interactive design collide. <\/strong>We didn’t think out the interaction of completing a to-do all the way. What happens when you click that thing? Does it instantly<\/em> get marked as done? Then disappear? Maybe it instantly gets marked as done but doesn’t disappear from the list. Or maybe there is like a 5-second countdown before it gets removed, so you have a chance to undo it in case it was a mistake. <\/p>\n\n\n\nI kinda like the delay idea, which to me leads me more toward the path of using an
<input type=\"checkbox\"><\/code> for that with the very obvious two states. We could really do it either way. If we keep the<button><\/code>, we’d just need to make sure to use anaria-pressed<\/code> role<\/a> for the two states accordingly.<\/p>\n\n\n\nLastly, the position of that interactive element I have listed first<\/em> here, before the text of the to-do, because that’s how it looks in the design. I could see the case being made though that in the HTML it should come after, just so that it reads nicer. Like as you tab through the list, you’d potentially hear the list item and then<\/em> the button text offering to complete it. I’m not 100% sure what the right answer is there, so I think we’ll leave it first, because that’s the visual<\/em> order, and I’ve heard it’s often best to match the source order and visual order.<\/p>\n\n\n\n
Let’s stop there<\/h2>\n\n\n\n
With some very light wireframe-y CSS applied to those classes, we get this:<\/p>\n\n\n\n
- Making sure the
- If we pick React we might be using JSX and have funny attributes like
- \n Building a TODO App from Scratch \u2014 Step 2 \u2014 HTML<\/a>\n <\/li>\n