Redesigned, Again

It is difficult to write about your own website just like it’s difficult to design something for yourself. I’ve been working on this off and on since about the middle of September of last year, mostly for about an hour here and there when I had time. I originally was just going to redesign and not say anything because mostly the design builds upon the last one just like it did the one before it. However, there are a few changes that are worth mentioning. Here goes nothing.

CSS Grid

No. I didn’t use some sort of stupid “grid” layout with classes everywhere a la Bootstrap. I mean the actual CSS Grid. There’s been a lot of talk about it lately. All the major browsers implemented it fairly quickly starting late last year which is great because it simplifies laying out webpages immensely. I started this redesign intent on using CSS Grid. Learning to use it was the reason why I decided to redesign. I wanted to make better use of space on larger screens. I believe I’m mostly successful with that, but more on that later.

@media screen and (min-width: 71.20999rem) and (min-height: 28.94427rem) {
    @supports (display: grid) {
        body {
         display: grid;
         grid-template-columns: 16.18034rem calc(100% - 16.18034rem);
         grid-template-areas: "header main"
            "footer main";
        }

        body > header {
         grid-area: header;
        }

        main {
         grid-area: main;
        }

        body > footer {
         grid-area: footer;
        }
    }
}

This is pretty much the core of the layout of this website. When the screen is wide enough it changes from flow layout to grid layout with the header and footer in a sidebar with the rest devoted to content. If CSS Grid isn’t supported traditional flow content continues to be used, thanks to support queries.

Caveats

CSS Grid is very new. In fact it’s astounding just how fast browsers have implemented it. The specification is only a candidate recommendation, and yet it’s in every major browser.

Many people are championing the idea of using CSS Grid right now because with support queries the layout can progressively enhance — or as people are calling it today “resilient design”. Support queries aren’t the Holy Grail of CSS. You cannot support query your way around bugs. Safari and Mobile Safari 10.0 have difficulties handling nested grids and have severe redraw issues where a grid from one page will “stick” to another. Both of these issues are already fixed, so they will land in stable versions soon enough. Just be mindful of what you’re building, and as always test, test, test.

If interested in learning more about CSS Grid the best content available on that subject would be Jen Simmons’ brilliant videos. The videos will get you up to speed, and Grid by Example by Rachel Andrew will show far more.

Icons

I have for quite some time now had icons in the footer of different social media websites I am on along with email and feeds. They have been an icon font for quite a few years now, and they still are now. I decided initially with this redesign to switch to SVG sprites. SVG sprites have been typically loaded through JavaScript because why the hell not, right? The JavaScript would through an overengineered system end up pretty much injecting SVG symbols into the page, leaving the developer to just include them everywhere in the document via SVG use elements. You don’t need JavaScript to load icons. The SVG symbols can just be put into the document itself and included the same way, but the icons aren’t cached separately from the document, leaving them to be downloaded every time the document changes or its cache expires. There is, however, another way; that is by using img elements and sourcing the icons from an external document by their identifier:

<img src="/images/sprites.svg#mastodon" width="24" height="24" alt="Mastodon">

<?xml version="1.0" encoding="utf-8"?>
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="24" height="24" viewBox="0 0 24 24">
 <defs>
  <symbol id="mastodon" viewBox="0 0 24 24">
   <path fill="#2b90d9" d="M22.532,14.388c-0.323,1.693-2.896,3.546-5.852,3.905c-1.541,0.187-3.058,0.359-4.676,0.284c-2.646-0.123-4.734-0.643-4.734-0.643c0,0.262,0.016,0.512,0.048,0.745c0.344,2.657,2.589,2.816,4.716,2.89c2.147,0.075,4.058-0.539,4.058-0.539l0.088,1.975c0,0-1.501,0.82-4.176,0.971c-1.475,0.082-3.306-0.038-5.439-0.612C1.939,22.118,1.143,17.1,1.021,12.009C0.984,10.497,1.007,9.072,1.007,7.88c0-5.206,3.352-6.732,3.352-6.732C6.05,0.357,8.95,0.025,11.965,0h0.074c3.015,0.025,5.918,0.357,7.608,1.147c0,0,3.352,1.526,3.352,6.732C22.999,7.88,23.041,11.721,22.532,14.388"/>
   <path fill="#ffffff" d="M19,8.215v6.304h-2.439V8.401c0-1.29-0.53-1.944-1.59-1.944c-1.172,0-1.759,0.777-1.759,2.312v3.349h-2.424V8.769c0-1.536-0.587-2.312-1.759-2.312c-1.06,0-1.59,0.655-1.59,1.944v6.119H5V8.215c0-1.288,0.32-2.312,0.964-3.07C6.627,4.388,7.496,4,8.575,4c1.248,0,2.193,0.491,2.818,1.474L12,6.517l0.608-1.043C13.232,4.491,14.177,4,15.425,4c1.078,0,1.947,0.388,2.611,1.146C18.68,5.903,19,6.927,19,8.215"/>
  </symbol>
 </defs>
</svg>

Frankly, I’m quite shocked at how badly that works. Literally every browser has problems with it except for Firefox. If you use anything which must be internally linked such as gradients they won’t show in Edge, Safari, or Chrome. It’s as if SVG sprites linked through img elements were only tested using flat icons in those browsers. I tried looking through WebKit’s and Chromium’s bug systems, but I can’t really make heads or tails of either one. WebKit had a bug similar to this before, but it’s labeled as fixed.

Needless to say I went back to using an icon font. At least for now that means I must go back to using flat icons. The way I use them and have used them is different from what I’ve seen before, though. I’ll write something on it soon. It would be best to devote an entire post to it.

Use of Space

The previous incarnation of this website — quite frankly all of them — didn’t use the space on large screens well. I’d just center the content in the middle and keep the lines of text at an appropriate measure. I still do that today but just on blog pages. This is mostly because there is nothing that could be done and have the layout remain dynamic. I use CSS Grid in this redesign to make content on most of my pages utilize large screens, but because of the shortcomings of CSS as it is today text remains a single column resident. Print design has this solved. Magazines and newspapers have for centuries now split text up into columns. For the Web there’s CSS Columns, and… it sucks.

Why does it suck, exactly? Because it doesn’t take the behavior of the Web into account at all. The Web isn’t like print; it is not static, but CSS Columns is. I have attempted to use it on this website and elsewhere numerous times, and I have yet to find a use for it that is scalable at all without setting a media query for every single addition or removal of a column. No thanks. Typographically CSS Columns as they’re currently implemented aren’t friendly to the reader. Columns don’t easily break with the viewport without some considerable work, making the reader scroll on really long columns which defeats the entire purpose of them really. Firefox also for some odd reason refuses to implement column-span and has layout issues with CSS Columns when doing anything not absolutely basic.

CSS Columns is in stark contrast with CSS Grid. CSS Grid opens up an entire world of layouts previously impossible or difficult to do and is scalable without resorting to numerous media queries. My hope is that in a future update to CSS Grid it would allow a way for content to simply flow through columns, virtually creating the effect of CSS Columns but with the freedom CSS Grid allows. Ultimately, when laying out just about anything a designer does establish their grid and then the columns of text reside in that grid; the Web should work the same way except with the added benefit of fluid and responsive layouts. Grid and multi column text should not be entirely separate.

Feeds

I’ve long provided news feeds for my blog. In the modern world of social media feeds seem like a vestige of a bygone era on the Web. It seems that few people use them anymore. My guess is that it is mostly because good software to read them has been nonexistent especially since Google destroyed independent feed readers with Google Reader and then subsequently shut the service down. Jeff King and I are trying to mitigate the problem. Playing my part in the development of The Arsse, I decided I would work on a script to generate test feeds for our work-in-progress feed parser, Lax. The first iteration of that script became a script to generate the feeds for this website, one in Atom 1.0 and another in JSON Feed 1.0. I haven’t provided a feed in vanilla RSS in quite a long time now, and I don’t plan on ever doing so again. Atom is a vastly superior format. Both Atom and RSS can be entertwined into a Frankenstein-like feed format which gives people like us difficulties in writing a feed parser. I won’t be doing that, either.

Adding to news feeds’ feeling of being of an earlier time is the fact they’re XML. It’s neither fashionable nor economical these days to use XML for a data interchange format, so it is indeed surprising it has taken this long for a JSON-based format to surface. After writing a feed generator of my own thus far I find JSON Feed an odd format. Its specification is ambiguous in spots where it shouldn’t be¹, and it looks by the activity on its GitHub page that it’s effectively abandoned as questions haven’t been answered since August of last year. Personally if making a JSON-based feed format I would have just translated Atom to JSON along with a few of the things JSON Feed adds which are relevant to new technologies available in today’s Web. Atom has years of work put into it, and a lot of the ambiguousness of JSON Feed is solved already in Atom through iterative improvements over the years. Hopefully the current maintainers open it up to contribution by new people or someone comes by and creates an Atom to JSON Feed’s RSS.

Despite the lethargicness of the maintainers of the format I am going to keep serving the JSON Feed. If I weren’t helping write a feed parser for a feed aggregator I probably wouldn’t even bother, though. Links to both of my feeds can be found on the Feeds page.

The Road Ahead

For a post where I initially stated that it’s difficult to write about my own website I have written quite a few words. Actually, it has taken me a couple of weeks to string this together in-between life and frequent hole plugging in the dam.

I’m fairly happy with the outcome. If being self-critical of my design I’d like to work in the future on white space. My wide screen layouts mostly use the space up, but because of CSS Grid I can move things around as I like and create interesting uses of white space previously only possible in print or with JavaScript on the Web. There’s likely bugs that still remain. I’ve spent my 30 minutes to an hour of time here and there lately mostly picking nits. I can fix the rest as I go instead.

My hope here is to resume writing about the Web as I used to do. I know I’ve said that before, and it remains to be seen if I’ll keep my word this time. However, the Web is under attack by giant corporations who control vast amounts of it, by governments who have disdain for those who use it to question their authority, and by developers themselves who build garbage websites and Web apps by ignoring Web standards and then complain about it. These reasons have given me a resolve to crack open my text editor and use it from time to time for writing about Web stuff, about my artwork and projects, and perhaps a bit of coding.