Scrollbar Blues

By | April 24, 2020

I majored in computer science when I first went to university, many years ago. The primary purpose of a computer science education, as far as I can remember, is to make you feel constantly insecure about your coding abilities. Because no matter what kind of programming solution you come up with to solve a particular issue, it would seem, there’s always a more elegant, and in theory more efficient, way to do the same thing. So as I code, and especially as I edit my code, I’m always mindful of the fact that whatever approach I’m taking is almost certainly misguided in some respect. Plus I never have enough comments. And my variable names are too vague or generic. There’s always something.

I was reminded of all this today as I worked on a new GUI element for Digero: a scrolling panel. The exercise vividly made clear both the elegance of Javascript/HTML, and the reasons why it can be so painful (and why I’m developing Digero in the first place). Anyway, this kind of element is highly useful whenever you need to show a lot of information in a small space. You make a little window, put all the information behind it, and add scroll bars so people can navigate through everything that’s there. Now, in a lot of pure programming languages, this sort of thing would be kind of tricky to pull off. But since we can take advantage of the powerful functionality inherent in a web browser (NW.js uses a Chrome backend), it’s just a matter of putting one div inside another div, and turning on the necessary scrollbars in the outer div.

Hey, that was easy!

But here’s the problem: since Digero lets you add elements inside other elements, you are allowed to scroll the inner div up and down, and stick things on top of it. But if you’ve ever worked with Web technologies, you’ll know that elements become hopelessly confused as to where they’re located when you scroll them. When you scroll a div, it technically doesn’t move at all, at least relative to the div it is inside of. But of course it does actually move on the screen, in that you can see it scrolling.

So where is it? Well, that depends on who you ask, in the sense that querying different parts of the CSS scheme will give you different answers. The inner div hasn’t moved at all, at least not according to its parameters. But if you ask the outer div to return a CSS style value called “scroll-top” (or “scroll-left” if you’re going left and right), if will tell you how far the inner div has moved relative to its own position. So depending on your needs, you have to forge an alchemic mix of different values from different elements in order to know specifically where anything is.

Anyway, long story short, it was very difficult to enable the user to drop new elements inside of the inner div, and have those elements actually appear where the user specified. To make matters worse, when I did devise a solution, I needed to edit the necessary code in multiple places within the program. Each element type has its own construction code for whenever you draw it on the screen. The code blocks are very similar to each other, but there are enough differences that I had to write them out separately. But the code edit I needed to make appeared in every single instance, which meant that they had to all be edited by hand, one at a time.

This is where the insecurity creeps in. Because even though I said I had to create similar but different code blocks for each element, there is clearly a way I could have rearranged things so that I could have written out the code each block has in common one time, and then pointed each separate instance to that code when it needed it. Have the common code as a root, metaphorically speaking, and the unique code for each element as a separate branch underneath that root. I would have recognized that, more than likely, if I had actually planned out how my code was going to be structured in advance. But I’m terrible at planning. I tend to just dive into these project with little forethought. Even though I can code, in other words, I would make a lousy software engineer.

In the end, I made all the changes I had to, and it was a relatively painless procedure. But the whole exercise served as a reminder that, if other bugs reveal themselves down the road, I might have to go through the whole inefficient process all over again, and be reminded once more about how lousy my code is. But at least, for now, everything is working, and I can pretend that it always will be.

This article was published on: 04/24/20 3:17 PM