The HTML ‘change event’ Element: #JavaScript30 — Day 3
In order to practice vanilla JavaScript and help land my first job as a software engineer, I am undertaking Wes Bos’ #JavaScript30 challenge. To view Day 1 and my overview of how and what #JavaScript30 is, go to my Practice Makes Permanent: #JavaScript30 — Day 1 post.
Day 3 of #JavaScript30: today we learned about CSS custom variables. This course is introducing me to so much CSS! I am such a magpie sometimes, show me pretty changing colors and I’ll be happy as I work. Today’s mission was to make the Spacing, Blur, and Base Color sliders adjust the HTML elements using vanilla JavaScript and CSS variables.
This activity was a bit of a challenge. Rather than watching much of Wes’ prompt video, we saw the aim and started to go right at it. We looked into a fair bit of documentation and made a good amount of progress before the productive struggle started to ebb. We then returned to the video to help outline the CSS properties and shut it off again before Wes started to discuss the script. I am glad we did that struggle first, because we were on a pretty-close-but-not-quite-there-track and now I feel like I actually grasp how the CSS custom properties work, rather than just follow it.
One take-away was the :root CSS pseudo-class. The :root selector represents the <html> element and is the same as the html selector, except its specificity is higher. This, in essence, declares global CSS variables. This is where we set the default values that the script section will update.
The second item of note for today, was our use of the ‘input’ event, seen below in line 67. If you note in the video demo above, when I drag the slider, it updates as I slide, not just on a ‘click’ or ‘mouseup’ event. We tried quite a few event types before finding ‘input’. And it works great given our html structure! The solution given for this challenge actually overlapped two different event types to create the desired effect, so through our productive struggle and research, we were able to actually create cleaner and simpler code. It is worth looking up different events based on your needs, there are so many more options than I have memorized for sure.
That said, that was probably the only upgrade we found ourselves. As you can see below, our first solution was on the left. After we finished, we went and watched the rest of the day’s video instruction and there was more to learn! So we went back and refactored, learned about datasets and cut our code in half. I think it was a good process, to go from what felt like a more accessible thought process to a more streamlined one. We were able to digest concepts a bit more thoroughly, and then continue to introduce new ones after having already processed the first aim of the challenge.
Day 3, was a doozy for only 6 lines of script and a few lines of CSS. But that goes to show how much can be done in a few lines of code, and how much a brute solution can be optimized. If you want to check out the code, here’s my repo: 27 challenges left!
