| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Before this commit, superscripts in print adopt the sweeping body {
font-size: 12px; } rule, making them too large and protruding.
|
|
only display author when explicitly set in Pandoc metadata.
Most if not all posts are by me, and there are plenty of occurrences of
"Zhiming Wang" on the page.
Also make authorship and date info normal instead of italic -- italic
doesn't look very nice here.
|
|
https://github.com/necolas/normalize.css/releases/tag/4.2.0.
|
|
The current behavior in Chrome and Safari is simply overflow. Not sure
which commit broke it (didn't bother to bisect and regen site multiple
times).
|
|
https://github.com/necolas/normalize.css/commit/39c21b3
|
|
Well, width restriction is still necessary...
|
|
Sometimes I have long images, e.g., in
http://zmwangx.github.io/blog/2016-04-10-emacss-got-a-redesigned-website.html,
and the image would be vertically compressed in Safari. I could switch
from width to max-width, but why restrict to screen height?
|
|
https://github.com/necolas/normalize.css/releases/tag/4.0.0
|
|
Horizontal space is valuable on mobile. Reduce formatting whitespace.
|
|
display: block spans the entire width of the parent container. Switching
to display: inline solves the problem.
Fixes #11.
|
|
Adjust to the right font size. Most of the heavylifting is avoided by
the last commit which made all printing font sizes relative (to the base
body font size).
Also add "-webkit-print-color-adjust: exact" to the pre tag to hint
WebKit based browsers to keep my code block background color. Nothing
can be done in Firefox; users need to manually check the "Print
Background Colors" advanced printing option. IE/Edge? Who knows, who
cares.
|
|
Sizes relative to the base body size are easier to update -- only need
to update the base size.
|
|
|
|
to left align numbers or bullets with standard paragraphs.
|
|
Surprisingly, a tweaked Arial isn't so bad. Saying goodbye to Open Sans,
which was tweaked to minic Helvetica Neue in the first place.
|
|
Regular text 150% => 160%, code 22px => 23px.
|
|
|
|
Use slimmed icon font packaged by http://fontello.com/. I only need two
glyphs: RSS and CC. I ended up picking the glyphs from the Entypo v2.0
family (https://github.com/danielbruce/entypo), licensed under SIL. I
actually like the Font Awesome glyphs slightly better, but fontello
currently only supports FA v4.3.0, which doesn't include the circular CC
glyph I need.
Old web fonts are kept for now. They will be removed after a while. See
\#9.
Open Sans is still in place and will be addressed later when the logo is
attacked.
The entire fontello package I downloaded, including the license, will
be added to this repo as source/fonts/fontello/ later when I have
implemented an exclude list in pyblog to prevent the directory from
being copied to the deployment tree.
|
|
Highlights:
* Change font to Times/Times New Roman + Courier;
* Text slightly darkened across the board to account for the thinner
Times;
* Eliminate line numbers;
* Use custom highlight.css (based on highlight-css supplied by Pandoc,
but hightlight more classes when Pandoc falls short, e.g., span.im for
Python from and import).
Closes #5 because we don't have line numbers anymore.
|
|
Over-long inline <code> tag or long literal link in <a> tag used to
overflow the container. This is especially bad on phones where width is
very limited. This commit hopefully solves the overflow problem. Still
no smarter word breaking, but it's probably just an unfortunate
limitation of HTML.
|
|
Droid Sans Mono doesn't stand out too well in a wall of PT
Serif. Changing to a greyish color doesn't disrupt the black-and-white
feel of the website, while giving inline code a bit more distinction.
|
|
Looks much better in desktop Safari on my non-Retina screen.
Code stolen from
http://www.intridea.com/blog/2014/5/8/better-font-smoothing-in-chrome-on-mac-os-x.
|
|
Date and author shouldn't be in the document outline.
|
|
|
|
Before: http://git.io/vGxpJ ;
After: http://git.io/vGxpk .
|
|
Sometimes (e.g., occasionally in China) Google/FontAwesome webfonts
might not be available, rendering the whole site unusable.
|
|
Just set content width to 90% instead of 80% for narrow.
|
|
Make list indices roughly align with body text.
|
|
|
|
|
|
Use web font to draw icons.
|
|
Open Sans Light 300 turns out to be too thin when antialiased (e.g., in
mobile Safari.)
|
|
Using web font Open Sans (light) instead of Helvetica Neue. Text is
thinner, but close enough and feels about right.
|
|
I forgot to update print.css to match the updated DOM last time.
|
|
To distinguish long captions from article paragraphs.
|
|
|
|
|
|
The main aim is a more logical DOM structure and more performant CSS.
|
|
Also adjusted some margins.
|
|
New:
* Greater than 1440px: load theme-wide.css, content width: 50%;
* Between 1024 and 1440px: standard theme.css, content width: 60%;
* Lower than 1024px: load theme-narrow.css, content width: 90% (and
floating nav element moves up to page top to make space).
|
|
Again using -webkit-image-set.
|
|
200x200 icon wastes too much valuable screen estate on a smart phone.
|
|
|
|
This way we can deliver the right size based on the window size (wide or
narrow), rather than deliver a universal one then scale down.
|
|
Add class and variation selector (# U+FE0E: VARIATION SELECTOR-15) to
U+21A9: LEFTWARDS ARROW WITH HOOK to fix outstanding font issue of
footnote backlinks on mobile.
Updated styles accordingly.
Trick learned from Daring Fireball.
Before: https://i.imgur.com/eUbL1k8.png
After: https://i.imgur.com/msv3INn.png
|
|
Viewport configuration per Google's mobile usability suggestions. It not
only provides a consistent experience by using device independent
pixels, but also help me get rid of theme-enlarge.css, which could
result in unexpectedly large font when one accidently resize to a
portrait window on the desktop. Thanks Google!
See https://developers.google.com/speed/docs/insights/ConfigureViewport.
|
|
The bar is the same as that for pre. Horizontal padding reduced to 1em.
|
|
Global font size in each style sheet has been tweaked very carefully so
that the precise line height is very close to a whole number of pixels,
so that precision alignment using em, which aligns something
precise (top: 13.5em) to something inprecise (line heights, with
accumulated errors due to rounding in every line), is not lost.
Note that Firefox is NOT supported, since each line seems to always
occupy one more pixel than the calculated line height.
For some reason line numbers in the print view are still rather
problematic at a page continuation. In Chrome and Safari, the first two
line numbers on a new page tend to overlap, so everything afterwards are
off (and on Firefox line numbers do not show up on the second page at
all). Anyway, printing shouldn't be a big concern.
|
|
|
|
|
