Experimenting with HTML

The past couple of weeks, and especially the past two days, have been filled with a lot of HTML and CSS work. I’ve been working on both the Verification Quest and another project that I chose to use HTML for. The learning difficulty referenced in the LoFi Manifesto is certainly rearing its head, although more in CSS than in HTML.

I’ve done each project two different ways. For the Verification Quest, all of the HTML is in one document. The CSS is embedded as a link but figuring out why the first attempt at this wouldn’t work was a whole adventure.

For the other project, I had to set up about 11 pages of content. I made one style sheet that has all the CSS and one sheet for a JavaScript function. This other project involves me rewriting a paper from a prior class, so all the content had to be reworded. Even though I’m having to change the audience quite drastically, I still spent about 3 times as long on the HTML alone. For example, I spent about 5 hours trying to figure out how to get text in a side menu to scale with the changing value of the side menu itself instead of the viewport size.

In total, I’ve probably spent about 30-40 hours across both projects. A lot of that was experimentation and trying to make things I really had no idea how to construct. It takes time, but a lot of the more complex stuff can really start to click after failing to make it work 15 times (literally). Since we are all learning HTML/CSS about to learn it for the final project, I figured I’d point out some things that I’ve noticed so far.

• Make notes on everything.

It looks messy, sure. But it helps immensely. Especially when you’re planning on using a lot of specific CSS commands, having notes about why you’re using a certain command or unit of measurement, as well as what other commands are related in some way makes it easier to figure things out when something breaks. I’d imagine that you need notes a bit less as time goes on, but making as many notes as I can has helped me.

• Break stuff!

Seriously, break stuff. You’re going to break stuff on accident but try to take some time and break stuff on purpose. If you suddenly get the urge to turn an entire page pink, let the intrusive thoughts win. Definitely keep track of what you’re doing but just trying to see what changing something does is helpful and fun.

• Find your settings

At least in VS Code, there are tons of themes in ‘extensions’ that you can try out. Sorting themes by the most downloaded usually brings up some interesting themes. This can seem like a waste of time, but when you’re staring at a programming/markup environment for 5 hours straight, you may as well like what you’re looking at. I’ve also noticed that some themes change the colors on tags and elements. For whatever reason, some of those changes make more sense to read than others for me. It’s worth checking out.

I’d also recommend looking into some of the other settings. Text wrapping settings are really helpful. Sometimes, you may want the text to wrap earlier or extend to the end of the window. For some of the stuff I did, having the text wrap closer to the middle of the window would be nice, but I hadn’t seen the option until all the content was written.

• Always have the W3 website open

I learned very quickly that it’s better to just have this open all the time. After the 900th time looking for an answer to a problem, opening up a tab for the website became the first thing I do after opening VS Code.

One other thing I’ve been doing that I never really used before is creating a new desktop. Especially when I’m using my laptop, having multiple desktops makes switching between things like my browser and VS Code a lot easier.

I know that we all went through the same fundamentals courses on LinkedIn, but I figured I might have some workflow ideas that may help someone.