Day 4: Box Model, Block, and Inline
A lot of this is also refresher, although I will say maybe 25%~35% are things I never read the technical aspects of so much as simply grokked (no, some moronic billionaire is not going to steal this word from me. I learned it the proper way from being raised around old gamers & devs, and I will continue to use it for its correct definition: to naturally intuit something. My culture is not Muskrat’s costume!) or built an understanding of slowly over time by getting my hands dirty on projects. Which is a good reminder that there truly are things to be gained by paying attention even to the parts that I initially want to write off as easy or below my current level. I will also say that I have always written off border-box. It doesn’t make sense to my brain, I would rather fine-tune each part of the box until I’m happy with the whole element than fight with unexpected size changes to my content level. Maybe it comes from being able to measure ems (and other such distances) pretty accurately by eye, so working out the outer parts of the box just feels more natural. Reading today’s lessons, I’ve decided it would be a good idea to step outside of that comfort zone and gain some practice with doing things the other way, at the very least to see what all the fuss is about. If the upcoming assignments don’t have me do this, and I suspect they will, then I suppose I’ll spin up a test page and give it a go myself.
As a sidenote: Outside of div and span, and ofc many of the text elements, I’ve never been very good at remembering off-hand which elements are block vs inline, and I’d like to work on that, too.
Final assingment for this section is to go back and style the recipe page using what’s been taught in the course so far. I’ve decided my challenges here are going to be 1) Use border-box 2) Use ONLY elements/attributes we’ve covered in the course so far
The idea behind the second rule is that I’m not just jumping way ahead in the styling, which would not only be too easy but also give me less to do in future assignments where we revisit the page again, making those lessons increasingly pointless because I’ve basically done everything to it by that point. Since I made the earlier assessment about my intuitive/experience-based knowledge vs my technical knowledge, it will also give the latter a chance to keep up with the code I’m using in a way that scales better as I work my way through the course.
For this purpose I’ve decided I should be keeping notes on the actual code we cover, and a wiki is the most obvious way to handle this. I searched around online for linux package based options, but that got frustrating/annoying almost immediately and also there’s the whole “no rabbit holes” rule, so I defaulted to Zim. Basic, easy to use, and offline/personal is the name of the game here after all. As a bonus, the wiki idea will also allow me to track other things, not just html. For instance the git commands I have to keep returning to the chapter for can now live in the wiki with a brief reminder of what they do, so I can easily flip to them while working on projects.
So now I’m off to quickly review the lessons and add the specific code/commands that’ve been covered so far before I crack open the recipe book repo and start editing.
Final update: Page is looking as good as I can get it with the limitations I set for myself. It was pretty tough, especially not being able to use positioning to get the index link on the right hand side and having to figure out an alternate solution to getting it to display where I wanted it without just breaking on page resize, but I’m actually really happy with how it came out. I do wish I had overflow in my toolbox though, so I could make the box scroll instead of the entire page, and text-decoration for removing the underline on the index link would also be nice.