Just my own current thinking, on laying out paragraph-heavy text, like
Racket documentation...
For laying out (or typesetting) paragraphs of text single-column --
whether it's in a paper book or on-screen -- note that we have a maximum
column width that the human eye can scan well, for reading paragraphs of
text at a time. Approximating roughly, let's say this ideal column
width is around 70em. (Think of "em" as very roughly the width of a
character, in whatever typeface and size is being used, though the width
can vary a lot within a typeface and font.)
Also note that Web browsers do (and have always, from the very-very
start) had a default font size for the user's preference on the device.
For layout purposes, Web designers should still treat this as the user's
preferred size for reading paragraphs of body text, which was the
original use (going back to original HTML, which was an SGML encoding of
a simplified LaTeX-like article style).
Sometimes, at the user's preferred font size, we can't show our full
70em ideal column width, and/or we can't show both the 70em and whatever
sidebar stuff we have in the layout, so we dynamically adapt our layout
gracefully ("responsively"). We keep the highest priority on the user's
preferred font size (don't make me call the accessibility cops on you),
and second-highest priority on our ideal column width. After those two
top priorities comes the various stuff we might put in any extra
horizontal space, and we have a lot of flexibility in how we use that
extra horizontal space, depending how big it is.
A public example (pardon the corny old visual design) of using CSS to
implement a variation on these priorities, although for a
not-paragraph-heavy small Web site that puts a higher priority on its
retro appearance (for no good reason), but still respecting user's font
size:
http://www.neilvandyke.org/racket/
If you view this on a desktop browser, and vary your window width, you
can see 3 layout modes:
* More width than we need, so we use our 70em-ish column, plus
sideheads, plus horizontal dead space.
* Not quite enough room for our sideheads plus our 70em-ish column, but
we still have enough room for our campy sideheads plus a good-enough
column width.
* Window is narrow enough that there's really no excuse for our cool
sideheads, so we reluctantly switch to a smartphone-like layout, with
headings as horizontal bars between paragraphs.
If the use of non-main-column space were much more complicated, we'd
have to mix in some JS with the CSS, but in this Web site's case (and
probably for most paragraph-heavy sites), we can do the layout entirely
in CSS with media queries:
http://www.neilvandyke.org/neilvandyke-blueboxes.css
The two CSS "@media" queries at the end of the file, combined with the
pretty clean earlier stuff, implement the 3 layout modes.
Now, that's a corny amateur visual design from 1999, the HTML is ancient
generated stuff, and the CSS reimplementation is mostly from 2002,
retrofitted in 2015 to implement the 3 modes... but it's holding up, and
you get the idea. "Responsive" layout implementation of paragraph-heavy
pages can be simple and maintainable, no frameworks required, and you
can always respect the user's font size.
I'm not talking here about non-paragraph-heavy pages, like many
marketing pages, or app UIs. Though some of the principles sometimes
still apply.
P.S., I just saw the new racket-lang.org Web site for the first time,
and it looks awesome! Kudos! (You might want to remove the third-party
HTTP requests, and host your nicely modest dependencies yourself, for
privacy and good-example security reasons.)
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
