Yes 100% suitable :P
It describes what the image is to those who can't see the image
perfectly well.
It magically makes the image show up in terminal browsers, as if your
terminal browser can render small images to the very pixel.
Bonus, for terminal/text-based browsers the "image" can even adapt to
your custom font! How cool is that?
Look, people, unique per-user images without cookies, without
javascript, without sessions, without CSS.
It was a very pleasant commit-message-writing experience...
Until realization hit. Why TF did you have the stupid image in the first
image when it can just be a block of text (<code>)? Oops! Let's not
celebrate my site's accessibility features too early, *cough* *cough*.
---
PS: Anyways after like almost two(?) years my site finally has a
favicon, lol, see previous commits.
I mean the pfp-text thing
For nav, same as other nav items (so it looks consistent, I guess)
For homepage, use a special new variable to let it feel more 'together'
with the icon.
Don't mind me, this is yet another bloat web-design commit.
Adding YET ANOTHER variable for something should just be left to the web
user-agent stylesheet. I'm so extra, I know.
Anyways in this commit I've adjusted the scaling for h1, h2, and h3 so
they aren't too big.
Reasoning:
Big = attention-seeking = ugly = bad = bad design
Big = wraps text on smaller screens = ugly = bad = bad design
The scale progression of headers is inherited from simple.css. In the
future I'll probably remove the font-size settings altogether and leave
it up to the user to set.
Basically all the changes involving my profile pics
- Favicon: 32x32 2-colors version
- Both SVG and PNG provided
- Nav home link: Now having the icon next to the name
- Configurable in config.toml (see its comment)
- For homepage: the home link is Site.title
- For other pages: icon next to name
- Index page h1: No more big ugly pfp, now inline
- Using shortcodes with corresponding partials ln'ed to them
- CSS for the nav thing
- Right now when user hovers on the home link, the portion has a
background color. I tried to not select it but apparently failed.
Desired behaviour: it should only have the hover effect if the home
link does not have the image (which is the case for all pages other
than index page, as described in second list item above).
Current behaviour: A useless CSS selector change that did not alter
the site's behaviour in any way whatsoever. Don't mind me, I'm
horrible at comitting things for this repo - I tend to like to make
a lot of changes in one go and commit using `git apply -p`. I also
litter a lot of comments in the CSS, which apparently increases the
size of the inline <style> in every. single. HTML file generated.
Literally.
Most likely switching back to external stylesheet in the future to
save some bytes in my overall website size.
- (Most likely the worst CSS addition I've every made): A blinking
lower-block for the h1 on index page. Seriously? CSS Animations on a
supposedly "simple" site like this??? Hopefully I would know better
and remove it soon.
- It's only animated for like 5 seconds. After that it is hidden
- For text-based browsers it willbe static and forever there. This may
be a problem because it looks like my name has a trailing
underscore 🤦
- It just looks wrong. I didn't have the typewriter animation for the
h1 text though, so ugh.
This commit should be associated with the commit previously that was about
changing layouts/partials/posts.html.
Excuse me for modifying so much stuff and then commiting them afterwards, it's
easy to lose track of those atomic changes we strive for when talking about VCS
commit best practices :/
- Previously using:
<nav><ul>
<li>first item</li>
<span class="right">
<li>second item</li>
<li>third item</li>
<li>last item</li>
</span>
</ul></nav>
This sucks, because:
1. Fails in accessibility due the the <span> - <li> should be under <ul>
directly
2. I had to hard code the opening span as pre in menu config for second item,
and closing span as post in menu config for last item.
3. Looks horrible
4. I have 4 reasons for changing it! :P
- Anyway, the structure of the nav is now:
<nav>
first item
<ul>
<li>second item</li>
<li>third item</li>
<li>last item</li>
</ul>
</nav>
beautiful!
Not quite easier to style in css, not quite nicer for text-based browsers,
but it works, that's what matters.
NOTE TO `GIT BLAME`-ERS
-----------------------
This commit should be associated with the commit(s) before this that touched
layouts/partials/header.html, which has the changes for the nav structure. May
you find what you are looking for there.
Attempted to fix ugly indentation in generated HTML:
eg
<html>
<head>
<meta>
<more meta>
<meta from head.html>
<more stuff from head.html>
</head>
<body>
<header></header>
<footer></footer>
</body>
</html>
I feel like the only fix is to put the indentation manually in
partials/head.html etc.
Because body no longer has min-width. The min-width is set in <main> so
retaining the top border is very inconsistent with the border-top in
<footer> (which is outside of <main>, unbound by min-width).
- Use <ul>
- Get rid of the ugly border-bottom
- Instead, decrease the left/right margin so it spans across the width
of the screen
- Align site index link on the left, and the other nav items on the
right
- Adjust behaviour of hover
- Reflect currently selected page in the nav bar