Figures will have margins on the left and right sides by default, unless
explicitly denoted "inline". The caption will also be a lighter typeface
rather than bold. When the figure caption appears at the bottom, it will
have a top border.
This increases the headings, gives them slightly larger margins, decreases
the font size for footnotes, decreases the line-height, and lightens the
weight of the font. I think this makes it easier to eyeball the different
sections (especially in the article I will be publishing shortly), and
further helps to emphasize that the footnotes are subservient to the text.
The idea here is to provide as little CSS as is sensible for the initial
page load to be styled in a layout similar to the final layout. This
initial styling may be briefly visible on a slow conection.
Slow connections can happen for a variety of reasons. For example, I'm a
Tor user, and connection speeds vary. Mobile connection speeds can also
vary wildly.
This adds a few hundred bytes, but I was able to cut it down quite a bit,
and I don't find this to be unreasonable relative to the other data on
each page.
I only noticed this issue because my work computer has IE11 installed. I will not be
supporting it. Edge works just fine and IE is just about extinct, finally.
Of couse, I recomend using a free/libre browser.
Rather than displaying the hash separately, this just makes the date a link
to the source code. Until I display a modification date, this will also
make it easy to see the history of the file.
This website honors the user's default font settings (both to be kind and
for accessibility reasons). Consequently, the responsive layout is based on
character units (ch) rather than pixels.
This goes back to Open Sans, which is what I was using previously.
I really like Source Sans Pro. Unfortunately, the font rendered far too
small relative to other sans-serif fonts, which caused an unpleasent
experience for both slow page loads (e.g. over Tor or slower
connections) and for users with web fonts disabled (e.g. via NoScript).
Further, the font is huge: the WOFF is over 100KiB per font, and I was
using regular and light versions. Open Sans, in contrast, is <20KiB per
font, allowing me to use Regular, Light, and SemiBold and still be about
half the size of the single Source Sans Pro Regular.
As a bonus, users may also already have Open Sans installed on their
system.
I settled with WOFF instead of WOFF2 for browser support.
The site now looks pretty close on fallback, which is good. For
example, I use DejaVu Sans as my default font, and it even has a Light
version that renders correctly.
As with all resources on my site, I host this from my own domain rather
than via Google's servers. That means that the font won't be cached for
users when they first visit the site, but that's okay---privacy is more
important.
I should note that, since I use NoScript, I almost never load web fonts
for other sites. But I still wanted to try to provide a consistent look
across systems for those who do wish to load fonts.
I didn't originally intend for all of this to be in a single commit. But
here we are. I don't have the time to split these up more cleanly; this
project is taking more time than I originally hoped that it would.
This is a new static site generator. More information to follow in the
near future (hopefully in the form of an article), but repo2html is now
removed. See code comments for additional information; I tried to make it
suitable as a learning resource for others. It is essentially a set of
shell scripts with a fairly robust build for incremental generation.
The site has changed drastically, reflecting that its purpose has changed
over the years: it is now intended for publishing quality works (or at least
I hope), not just a braindump.
This retains most of the text of the original pages verbatim, with the
exception of the About page. Other pages may have their text modified in
commits that follow.
Enhancements to follow in future commits.
With the CC BY-SA addition, the line of images would otherwise wrap. The font
size is adjusted slightly to be more proportional with the images.
The images dimensions are reduced by 20%.
The page is designed for modern PC resolutions---that is, 1280 or greater width.
Since it uses a 300px right-hand sidebar in conjunction with fairly generous
margins (for the index pages, at least), this causes problems with smaller
resolutions.
For the classic (but outdated) 1024px resolution, the margins will adjust to
give more viewing room. For 640px or less resolutions, which are common on some
mobile devies such as tablets, the headline that is normally displayed in the
sidebar is moved to the top and the images are significantly reduced in size,
providing 300px additional viewing width. The 42x42px images that are displayed
below the GNU logo on the upper-right are also moved to the top of the page and
to the left of the GNU logo and certain other margins (such as blockquote and
ul) are reduced.
At around 400px, the images next to the GNU logo start to become problematic and
may overlap with the title; therefore, the size of the images are halved so that
they can fit above the title. This happens to be close the resolution of certain
mobile devices, such as the iPhone (which unfortunately I see many hits from in
my sever logs) with a width of 320px, so this is the layout that will be used
for such devices.
Note that the styles for these widths are build atop of the existing rules and
essentially ``undo'' certain styles; this is to fall back to the default desktop
style in case the browser does not support such media queries.
Previously, the headline (which is essentially a sidebar) was floated to the
right; this had the benefit of allowing the content to surround it on the lower
portion of the page, though that's arguably a poor design decision. With this
change, this does not occur, but the real reason for this change was to ensure
that block elements (such as divs) do not overflow into the headline.
This uses minimalist styling---as much as possible is done using the body
element. The footer positioning was tricky with varying content length. Since
the headline currently contains only images, my decision was to just get away
with setting a min-height to something reasonable for the headline content
height.
Mike Gerwitz
Mike Gerwitz