| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Common elements in <article> usually have their own margin settings. In
a previous CSS rule we make sure to set 'margin-top' for the first
element in <article> to a lower value such that we have a consistent
margin between the article header and the content itself.
However, if the first element is not a <p>, no such margin change will
take effect for the first <p> element. For example, if the first element
is a floating <figure>, the <figure> element will have its margin
modified, whilst the <p> will keep its usual settings, resulting in a
very inconsistent layout.
We assume that the first <p> element is at the top of the article in
almost all cases, and include a new rule in this commit that applies the
margin settings correctly.
|
| |
|
|
|
|
| |
Instead of just indenting the pre block, it is more visually pleasing
and clear to draw a border around it. That way, code blocks are clearly
delineated from text.
|
| |
|
|
|
|
|
|
| |
We may want a post to contain references to a whole number of previous
posts. The styling for external links will then clash, especially if
there are a lot of them. Make sure to make it possible to highlight
internal links differently and more subtly by adding an "internal" class
for <a>.
|
| |
|
|
|
|
|
|
|
| |
An upcoming post will (finally) make use of the "mentions" feature.
Whilst working on that post we noticed that the header indicating
mentioned posts is a big too big and clashes even with the site title.
h3 should be better suited for this purpose. Since the default margins
are slightly different from h2, make sure to tweak the stylesheet too.
|
| |
|
|
|
| |
This further increases the space available for text and makes the logo a
lot less dominant.
|
| |
|
|
|
|
|
| |
This reverts commit f99133842b48dc7d99e577df37e34ea143f1eeaf. We have
found this solution to introduce other (worse) problems because the
padding is unconditional. For now do not apply any special style to
<code>.
|
| |
|
|
|
| |
These elements overflow on smaller screens, so make sure that they're
getting scrollbars.
|
| | |
|
| |
|
|
|
|
| |
This removes a branch from the template and also makes sure that screen
readers and similar software still get access to the post title even if
we want to hide it on the presentational layer.
|
| |
|
|
| |
This improves the readability and consistency of the CSS.
|
| |
|
|
|
|
| |
Users with narrow displays currently have to deal with post banners that
do not collapse nicely. This commit adds some padding to the tag list
and hides the post time on smaller resolutions.
|
| |
|
|
| |
This feature was only used once for testing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we pad certain elements with manual interpunct spacers that
are defined in the templates themselves. This is suboptimal for a number
of reasons. Templates should be used for textual or semantic data, not
presentation. Additionally, we have no good control over how whitespace
characters will end up being rendered. Adding or deleting spacers is a
nightmare.
To fix this, use CSS to render spacers instead. To that end, introduce a
couple of HTML elements in the top banner and keep supplementary links
in a list inside a <nav> element. Add a spacer mixin that can be applied
to any element that needs it.
|
| |
|
|
|
|
| |
Currently, --font-mono is only applied to <pre> blocks, leaving <code>
unstyled. Since <pre> blocks will end up containing <code>, set the font
family on <code> instead.
|
| |
|
|
|
| |
Due to the density of the fonts used, <code> blocks tend to be too close
to the normal text. Add some padding to mitigate.
|
| | |
|
| |
|
|
| |
This way we do not have to specify the color in its selector.
|
| |
|
|
|
|
|
|
|
|
|
| |
Post titles are currently only visible in the feed, or on the post page
itself. Since people may remember posts by their titles rather than
their number, display the titles on each post's banner as well for
easier searching. This means we can now get rid of the extra item in the
post page's description.
A neat side effect is that we now have a header element for each
<article>, making W3C a bit happier.
|
| |
|
