Published on March 01, 2014.
There comes a time where I get just bored enough that I’m restless and not so bored that I’m lazy. During these times, I code myself a website, usually from scratch. The last time was around finals season of last year, and it resulted in the first iteration of my personal website (which despite my best intentions was bloated and ugly). Anyway, it’s happened again, and so now I have a new website. Hope you enjoy it!
I had a pretty simple concept for this new site and it didn’t take all that long to roll out, but along the way I ran into some pretty funky bugs, many of which almost brought me to tears.
The Rotating Tagline
Challenges here start with
After some creative Googling, I found and adapted a function that calculates text width by creating an invisible text element on the page with the same styling as the text in question. Take a look:
Fairly straightforward, but definitely non-obvious. The element is created, given all the classes passed in, and then given the testDimensionCalculation class, which makes it invisible and absolutely positioned (as to not interfere with any elements the user can see):
After the width of the
<div> is calculated, it is destroyed.
With the width of the text determined, the next step would be to implement the word replacement. The markup, it turns out, was more challenging than I would have expected. My first instinct was to wrap each word in a
Consider animating from the word “preposition” to the word “about”, however. When the width of the
<span> is animated, the text starts to break up into multiple lines , and the height of the
<span> increases randomly. This causes spastic jumping of different words during the animation. In order to smoothly animate words, I put each
<span> in a container, and added another
<span> to control the actual width of the container. Both
<span> elements contain the same text, but one has an invisible class, and the other has a visible class.
The way this works is that the container doesn’t ever have a width applied to it, rather the invisible
<span> expands and shrinks. The visible
<span> has absolute positioning, so it has no influence on the size of its container. Then, in order to change between to words, I fade out the visible
<span>, animate theinvisible
<span> to the new width, and then fade in the visible
For alignment reasons, and because
<div>s around all the words removes whitespace, I actually had to add
<div class=”word”> elements containing just
<div> tags as well.
I had never heard of this being a problem before, but I actually ran into whitespace issues between the <div> elements that are
display: inline-block;, which was solved most simply by removing any space after the closing tag of the
</div><div class=...). It was a massive pain across different browsers. Some browsers would display the sentence just as I expected, others would cut off part of the words, others would have an unnatural amount of spacing, etc. The whitespace logic of HTML still deceives me, and because it’s so loosely defined, there’s no way to understand whether or not you’re being compliant.
Animated Name Abbreviation
When I was designing my blog, I wanted a fairly chromeless interface. I don’t need any fancy widgets, menus, other links, or pages. My website is really just the splash page and my blog, so there really isn’t anywhere else to go. I did want a link back to the splash page from the blog though, so without any navigation bar there wasn’t really any place to put it.
In order to achieve this, I calculate the percentage left in the animation as the (positive) percent of the total distance between the title and the top of the page that the user has scrolled:
So if the Title is 200px from the top of the screen, and the window has been scrolled 100px, then the animation will be 50% complete.
Now what is being animated? I separate all the parts of my name into fragments, and animate each one appropriately. This way, I can animate the lowercase letters and the spaces between my first, middle, and last name to zero, leaving my initials untouched.
I used the same
calculateWordWidth() function to find the starting and ending widths of all of the name-fragment
<div>s, and then I animated each of them incrementally from the starting to ending width based on percentageLeft.
That process is pretty simple: figure out what stage of animation each piece should be in based on the distance scrolled from the top of the page, and then animate each element’s width appropriately. Where things get complicated is making this process responsive to screen size changes and compatible with multiple browsers.
Making it all Cross-Browser Compatible
I knew I wanted my name to stay at the top of the page on mobile, but that brought up the problem of what if a desktop user was part of the way down the page and then resized from full width to tablet width or vice versa. I already had my animation function
updateTitle() bound to the window scroll event, but then I realized that I also needed to bind it to window resize:
updateTitle() I either update the animation if the screen is desktop width, or set the title to be at the top of the page on tablets and mobile.
Seems right, but I had forgotten something: orientation changes on mobile. Because when you rotate the screen neither the page scroll event or the window resize event are called,
updateTitle() is never called despite the fact that the window size is different, and therefore all the elements are lined up improperly.
The fix is easy, but I’m lucky I caught this, it’s not often that I rotate my device in the middle of browsing a web page.
I didn’t know about this until it started causing me trouble, but apparently, scrolling with a scroll wheel on a mouse is actually different from the browser’s perspective than scrolling on a trackpad. As a result, when I used a traditional mouse to scroll on my site, sometimes the
updateTitle() function would not be called, or would be called unpredictably.
The fix should have been easy: bind
I thought this would be good enough, I was wrong. It turns out that both thescroll and wheel events will get called when you scroll down the page; it doesn’t matter what actual device is being used to do the scrolling. As result, sometimes I would scroll down the page just fast enough and my code would
callupdateTitle() twice, and the result would be a miscalculation of where the title belonged on the page. This is because sometimes an event would be triggered when the user was near the top, but only resolve when they had scrolled down a ways, causing the title to float somewhere in the middle of a blog post — very annoying. To solve this problem, I had to make clever use of
setTimeout() is a function that takes a function and an amount of time, and will execute that function in that amount of time. The original call returns the id of the timeout, so it can be referenced later.
clearTimeout() takes a timeout id and will clear it, so the function call will never happen.
Because I only want one call to
updateTitle() when the user scrolls, but I want them to be able to scroll on a touch screen, trackpad, arrow keys, or mouse, I have to cancel any other call to
updateTitle() when I create a new one. Check out the before / after, it’s pretty ugly but it works:
I only set the timeout to 1 millisecond, but this ensure that multiple calls to
updateTitle() don’t stack up on each other.
Even simple variable declarations started causing me trouble. Did you notice in my
doMobile() code that the value I’m setting “width” to is actually the result of a function call? At first, I just had variables for the original widths of the elements:
But this actually caused some problems.
When I move from mobile to tablet to desktop screen sizes, I change the font size on most of the elements on the page to make them fit better. This is a problem for my animation variables however, because if the page is loaded as in desktop width and then resized to a smaller screen size, the original and final widths of the elements are with respect to the original screen size, not the new one.
This was a massive pain, because after resizing the screen a few times, random text elements would be a few pixels to small, and my name would show up as “Da R Schlosse” (which, if pronounced as two words in a pirate accent is actually not all that bad). What makes this worse, is that if I reloaded the page, it would be fixed (because the original and final width variables would be recaclulated.) My solution was to make these variables into functions, so the values would be computed in real time with respect to the window width.
You Won’t Believe This Bug
As a grand finale, I bring to you the most mind-boggling bug I experienced while making my website, and probably is the craziest bug I’ve ever had the pleasure of fixing. I’ll start with the symptoms:
I would load the front page of my website, and everything looks good. I click the pencil icon, navigating to the blog page, and everything looks good. Then, I reload the page and my name gets cut off (the return of “Da R Schlosse”). I inspected element, and I saw that the
<span>s that wrap the lowercase parts of my name were a few pixels too small. Very weird. I need to specifically define the width of these elements, so that I can animate them later, and now apparently when I refresh the page they are sized differently.
calculateWordWidth() function, which creates an invisible element on the page, applies classes that you pass it to the element, puts the string you want the width of into the element, finds it’s width, and deletes the element. To figure out why this wasn’t working on refresh, I removed the line of code that removes the element from the document, and used the chrome inspector to make these elements visible (they were a bunch of
<div>s at the bottom of the page).
calculateWordWidth() function again, and saw it happen live. Everything worked as expected, and my name was not cut off. This was infuriating. Whatever was causing the
<span>s around my name to be mis-sized was also covering its own tracks!
<div> I was creating had the fallback font, which has a different character width. By the time I could inspect the
<div>, the font had loaded however, so it appeared to be the right size.
So how do I fix this bug? Closer inspection of the
The problem with this is that this doesn’t wait for CSS and images to load, and so my font was not yet loaded. I discovered that there was another function similar to
.ready() that would wait for all assets to be loaded, and I replaced
.ready() with that:
And it worked! It might have taken me hours and hours to finally figure it out, but I fixed it, and as result I don’t have any problems, no matter how many times I reload the page.
You might think that I’m a little crazy for investing this much energy into what could have been a really simple website, and on some levels you might be right. Personal pages are meant to be simple, and there are a lot of tools to make a simple, attractive web page. But because I didn’t have any references for how to implement some of the visual tricks that I did, I found myself thinking about the knitty gritty of web development in new ways. I think that it’s an important learning process. Plus, where’s the fun in having a WordPress?