Made additional optimizations to the Inter subsetting. The original Inter files are over 100kB each, which usually translates to long loading times; not long enough that it would delay the page on desktops with decent connection, but long enough that user would see the fallback font flash, which can be a little jarring.
What I realized today was that reducing the main font file to all of the subset symbols combined (all the Latin letters and numbers and all the extra punctuation) still provides files of acceptable size, between 20kB and 25kB. I wanted to find out the final size because the font flash still occurred with secondary subset fonts, such is when entering the Contact page which contains an
@ symbol. Loading a single foundational font file, with all the common and uncommon (but not rare) characters included, still causes a delay, but not nearly as significant as previously.
This does, of course, mean that I'm going to update the font (or load a separate one) for non-Latin scripts, as well as for some parts of Latin script that I didn't include.
I've also tried a different way of rendering the arrow decorations.
Previously, shortly before the log started, I'd already tried to move to relative-only positioning for the arrow pseudo-elements. While it could've been fine-tuned to work as currently, it would make for a system that's far too brittle and requires too many calculations compared to the current setup.
The reason I wanted to work on it was because of the fact that it seemed a little excessive to me to have that one CSS declaration for
.arrow elements which only states one thing:
position: relative. Not a bad thing in itself, but it does feel as if it doesn't have enough of a weight to exist in the code; like it could be done better.
This time, I tried using floats as an alternative to current absolute positioning, in two different ways.
Initially I tried to accomplish the same result using floats only, discarding non-static positioning completely. It worked just fine for "after" arrows (the ones that succeed the text they're attached to), but moved contents of "before" arrows-containing elements (such as the one front-page paragraph) too much without really giving me the capacity to adjust its spacing.
The only problem there, really, was the fact that I couldn't adjust its padding in a way that would let me overlap the arrow's effective cursor area (the area that would still activate the hover effect, even though it's ostensibly empty space with no content) with the container's content. Overlapping the padding would mean you can hover over the area you would expect to be active (such as the space between the arrow and the content once the arrow does move) without experiencing the hover flicker. Hover flicker is when you hover over an element and it moves in such a way that it no longer registers the hovering (such as when the element is no longer under the cursor), so it tries to move back, then registers the hover again... ad infinitum.
(Now that I think of it, I could've fixed it by extending the padding. While it does appear to be a sound solution on paper, in reality the related CSS would have to be extended by something like a third to accomodate for this behavior.)
The second solution – something I've only considered as I wrote these words – was to combine floats and relative positioning. This worked surprisingly well: with a little adjustment I could make it work site-wide and get rid of the excessive one-liner declaration.
The problem with that approach turned out to be in the way I handle diagonal arrows.
The travel distance for all arrows is relative to their static offset, the latter being what determines how far arrows stand away from their associated content. The distance adjustment is done with an independent factor by which the offset is multiplied to produce travel distance. For diagonal arrows – which move in two directions – two "separate" movements combined appear excessive, even though they're computationally correct (i.e. adhere to the values exactly). As such, they're given a lower adjustment factor, which results in less overall movement to the point where diagonal movement appears roughly equivalent to orthogonal.
Long story short, these reduced values are stored in variables of their own, and I need to use them for proper float-plus-relative positioning. Given that these variables are further modified by the reduced factor on diagonal arrows, the overall result is a sudden jump in diagonal arrows' distance from content. This cannot be fixed without rewriting the rather complex system of computations arrows use.
That said, if I ever do solve it, it may well be a viable solution to the "excessive declaration" problem. It adds more lines to the code, but my neat-freak mind makes it appear justified. The way I'm currently doing it – with absolute positioning – is clearly simpler and more effective, and I can live with that one line of CSS standing out. Perhaps I can come up with a system more refined than this, and reduce the necessary code even further, which would be the better solution still.
One other thing I did today was streamline some of the content block styles. The idea initially was to use blocks – based on HTML5 sectioning elements, such as
<footer>, among others – partially for semanticity's sake, and partially in hopes of eventually coming up with a way to automatically generate a table of contents for any given page or a project. (That's the idea behind sectioning elements to begin with. Their aim, as described in the HTML5 reference, is generic for all documents: blog posts, news articles, content aggregators... My goal is to latch off the generic structure and be able to produce anchors and reference points that are specific to my website's structure.)
An unexpected obstacle presented itself in the form of browser defaults. Chromium-based browsers, for example, significantly reduce the size of heading elements (
<h6>) within sectioning elements. This is surmountable, but is an unexpected hinderance all the same.
For now, I've reduced the sectioning elements' styling to any element following a
<header>, any two
<footer> when following any other element. The styling itself remains about spacing. Whether these will be extended into something more meaningful remains to be seen.