![[Home page]](../PythonPowered.gif "Home page"){kind=small}
| Books | Code | Blog | Python | Author | Train | Find | ©M.Lutz |
File: _main.css
/*
====================================================================================
External CSS sheet, adopted Nov 2015 (code last substantially revised August 2020).
Styles for fonts, nav bars, images, code, and more; supports future expansion.
Used site-side, except old training pages (own CSS) and app user guides (inline).
Caveat: some older pages here still use tables and in-line HTML tags for formatting;
this is being phased out rapidly, especially during 2018 mobile-friendly conversion.
====================================================================================
CSS CHEAT SHEET (because bandwidth is now cheap (and caching is now common)):
Use this external sheet via this in <HEAD> of HTML file:
<link rel="stylesheet" type="text/css" href="_main.css"> <!--relative url-->
Syntax:
selector {property: value; property: value}
Where common selectors =
HTML tag type: p {} for all <p> only (any element type)
Id name: #intro {} for <... id="intro">, page-unique id, <div>?
Class name: .nftable {} for <... class="nftable">, not page-unique
Events: a:hover {} for all <a> on hover event (whether href= or name=)
Tag + class: pre.fancy {} for <pre class="fancy">, some tag only
Multiples: p, dt, dt {} for <p> and <dt> and <dd>
Direct child: tr.space>td {} for all <td> immed in <tr class=space>...</tr> (only)
Direct child: h3>a:hover {} for all <a> in <h3>...</h3>, on hover event (e.g., name=x)
Descendant: .booktab th {} for all <th> descendants of <table class=booktab>
Combos: .c th, .c td {} for all <th> and <td> descendants of <? class=c>
Wildcards: * {}, td * {} for all, or all within any <td> (or html, body)
Negations: a:not(.c):hover for all <a> without class="c", on hover
a:not(.c1):not(.c2):link double :not() means neither, when unfollowed link
Precedence, from lowest to highest:
Properties are applied in order read/loaded, which generally means:
1) Browser defaults, which unfortunately may vary
2) External and internal sheets in <head>, by coding order: first to last (low..high)
3) Inline styles within HTML tags, outside/after <head>
For #2, there may be any number of <link> refs and <style> blocks in <head>
CSS property overrides same-type HTML attribute, in CSS-capable browsers (but test!)
Nested elements/classes may override attrs of their containers (e.g., <code> in <pre>)
Update: <style> blocks can appear anyhere in HTML5 standard, read when reached
Subtle bits:
Class redefinitions with disjoint properties simply extend the property set
Using <tag class="c1 c2"> combines the properties of both classes
Display may be "block" (stack vert.), "inline-block" (stack horiz.), or "inline"
A "!important" at a property def overrides standard precedence (ad hoc -- avoid!)
Properties are also applied by a selector specificity ranking (complex -- avoid!)
<tag id=X> defines an element object's ID often used in JavaScript; != #X in CSS
Coding notes:
Comments: CSS format parsed in <link> files and <style> blocks (/star star/)
Comments: else Javascript form in <script> blocks (/star star/, //)
Comments: else HTML form everywhere else in page (<!-- -->)
CSS does not do nested comments - edit closing / if present in disabled block
Errors are _not_ reported: add color/etc to verify class correctness and use
Some errors may be reported in browser's web- or javascript-console displays
<noscript> wraps HTML code to be used when JavaScipt disabled
Media queries:
"@media" appear in CSS and have and nested/conditional CSS: code within enclosing {}
Screen size: @media screen and (max-device-width: 640px) {...some CSS settings...}
Dark mode: @media (prefers-color-scheme: dark) {body {background-color: #808080;}}
Can only query browser state, cannot handle user interactions (requires JavaScript)
Where to code CSS:
An external CSS page like this, loaded with a <link> in <head>, makes it easier
to change formatting in the future without having to edit each page (or worse,
each tag within each page). Alternatives, and their downsides:
0) External sheets in <HEAD>, like this one: the best option
<link ...see above... >
1) HTML in-page style sheet(s) in <HEAD> (or not): must edit every page to change
<style>
body {
font-family: Arial, Helvetica, sans-serif;
}
</style>
2) HTML inline (in-tag) CSS styles: must edit every tag to change
<p style="font-family: Arial, Helvetica, sans-serif;">
3) HTML original font tag, anywhere: deprecated but widespread, many page changes
<font face="Arial, Helvetica, sans-serif">
4) JavaScript object-based: requires users to enable JavaScript
object.style.fontFamily="Arial,sans-serif"
5) HTML original formatting: must edit every tag in every page on changes
<td bgcolor=tan> <!-- was the web ever this young? -->
For more tips, view the source code of pages on this site.
====================================================================================
*/
/*
====================================================================================
GENERAL FONTS [site-wide]
Banish the default former Times New Roman default (a.k.a. serif).
====================================================================================
*/
/*
------------------------------------------------------------------------------------
For the entire body, except <pre> used for code/text (alt: *).
See also code and header font scaling options later in this file.
------------------------------------------------------------------------------------
*/
body {
font-family: Arial, Helvetica, sans-serif; /* precedence list (Verdana, Tahoma?) */
} /* double quote if name embeds spaces */
/*
------------------------------------------------------------------------------------
Jul18 hack: do not scale up text fonts in landscape mode on iOS Safari
(else no more text can be seen), but still allow user zooms. Limit to
smaller screens only, and assume no other consequences (a nonstandard
attribute). Uses CSS device-width to target physically small devices.
Also used redundantly in training-main.css and all apps' user guides.
Updates and findings:
- Using "none" instead of "100%" does _not_ appear to disable user zooms
today, even without the media query code - has this story evolved?
- The "100%" does _not_ appear to impact 'font boosting' text upscaling
in Android Chrome. Despite initial suspicions, uneven text sizing
appears related only to user font settings - see more below.
- Adding a "maximum-scale=1.0" to <meta name="viewport"> content today
does _not_ prevent Safari iOS landscape upscaling, and really _does_
disable user zooms in Android Chrome - more browser-specific quirks?
- device-width targets screen size instead of window size to avoid
firing for shrunken windows, but is not handled the same way across
all browsers - see the related notes at code and toolbar fonts ahead.
Caveat - more on Android Chrome font boosting:
Upscaling appears wholly related to user font settings - both global
Settings, and Android's own Text Scaling in Accessibility. For both,
large font settings may result in some text being oddly larger than
other text. This is an issue in Android Chrome only; Firefox has a
similar model, but it does not seem to yield such irregular scaling.
Font boosting is based on a heuristic analysis of content: larger
text sections are chosen for upscaling, to make desktop-focused pages
easier to view. The unfortunate consequence is that text selected
for upscaling can be much larger when users select larger font sizes.
Conversely, all text is sized the same for lower size settings.
There seems no good - and polite - way to disable upscaling via CSS
(a former "max-width: 99999px;" scheme proved futile today). Moreover,
the "-webkit" setting below has no impact on upscaling on any devices
tested, regardless of its setting or presence. Switching to and from
landscape mode can alter Chrome's rendering too, but only trivially.
Automatically scaling a page's text to differing sizes seems dubious
at best. Indeed, font boosting was filed as a bug, but dismissed as
"won't fix" - a regrettable outcome for a most-used mobile browser.
For now, users can avoid uneven scaling but still enlarge text with the
global Screen Zoom in Settings, instead of Font Size or Text Scaling.
At least until browser makers again change the rules arbitrarily...
------------------------------------------------------------------------------------
*/
@media screen and (max-device-width: 640px) { /* on 0..640 pixel screens only */
html { /* from the wildly ad hoc department! */
-webkit-text-size-adjust: 100%; /* not 'none': prevents zoom in/out? */
}
}
/*
------------------------------------------------------------------------------------
[Nov23] Disable now-broken font size boosting on Android Chrome.
On websites with text, Android Chrome (AChrome) now regularly opens
pages with some text initially scaled up to larger system or browser
font-size settings... and then abruptly scales the very same text
down to a smaller default size after initial user scrolls. A reload
after scrolls restores the botched larger sizes--until more scrolls.
This bug cropped up somewhere between versions 111 and 118, and may
be temporary. It also appears to happen only on foldables (and
tablets, presumably), not on slab phones, and hence is related to
screen size. For example, it occurs on the main (unfolded) screen of
a Fold5, but not on its smaller cover screen, and not on an S23 Ultra.
Where it happens, though, it's comically bad. Sans the CSS workaround
below, users must either not set system or browser font size past its
default, or enable the magic flag of the next paragraph. Else, text
size shifts jarringly after scrolls and reloads.
This is caused by AChrome text scaling (a.k.a. font boost), which also
makes for irregular text sizing in general. Text scaling is supposed
to be superseded by a new Accessibility Page Zoom in Settings, but the
new zoom is currently (as of version 119) behind a browser flag and
disabled by default. See in AChrome:
chrome://flags/#enable-accessibility-page-zoom
The best theory is that this change is partially disabled by the flag's
off default, but some of it leaks through anyhow and botches font zooms
on larger Android displays. If so, the bug may simply go away in a
future AChrome that enables the flag by default.
On the other hand, AChrome's track record doesn't exactly inspire
confidence in a fix. Its font zoom is arguably a bug branded as a
feature; Firefox's font boost has no such issues; and Chrome in general
has a legacy of breaking pages (see this site's recent toolbar breakage
on Windows Chrome; why do so many users put up with this?).
The CSS below makes all this moot, by disabling AChrome text scaling
enough to avoid the new and bogus initial resizes. Other notes:
- This workaround also overrides and subsumes the iOS Safari hack
above, which avoids page zoom in landscape via a 100% limit. A
bug that broke desktop Safari zoom for none has now been long
fixed, and none is supposed to be the same as 100% in Apple land
(where the -webkit prefix is still oddly used).
- Firefox on Android still requires the -moz prefix too, despite a
5-year-old bug post to remove it.
- The widely suggested [max-height: 999999px;] alternative seems
a perilous hack, and may or may not disable font zooms today.
- There are no known negative side effects of the CSS below, and
it does not preclude accessibility zooms. Some text's size is
naturally different than before, and the results are subjective,
but its enhanced uniformity would generally qualify as a win.
- Editorial: AChrome's font boost still just plain sucks in general.
It poorly renders same-page text in wildly different sizes on
mobile-friendly pages that don't need this, and is not fully
neutered by this CSS: it still makes some arbitrary choices that
are subpar. Are sites really supposed to leave font size up to
users, given the penalties in Android's market-leading browser?
Refs:
https://caniuse.com/text-size-adjust
https://duckduckgo.com/?q=android+chrome+accessibility+page+zoom
https://stackoverflow.com/questions/59095113/
font-size-display-issue-on-google-chrome-for-android
https://stackoverflow.com/questions/74029786/font-boosting-in-android-chrome
https://gs.statcounter.com/browser-market-share/mobile/worldwide
------------------------------------------------------------------------------------
*/
HTML { /* html and body work same (h contains b) */
text-size-adjust: none; /* chrome (all), edge, samsung, opera, etc */
-webkit-text-size-adjust: none; /* safari (ios, ipad default none, macos) */
-moz-text-size-adjust: none; /* firefox (not desktop) */
}
/*
====================================================================================
CODE/TEXT BLOCK LISTINGS AND INLINE CODE [site-wide]
This has evolved (old items kept for ref); auto-scroll and mono-font are crucial.
====================================================================================
*/
/*
------------------------------------------------------------------------------------
CODE/TEXT BLOCKS (some use <code> too)
Code sections that are not manually indented (an older formatting style).
Feb18: now used SITE-WIDE for *all* <pre>, and dedent any old-style code.
Jul18: other rules below add or replace font-family/font-size settings.
Note that this is for code _blocks_, not inline text: <pre> styling is
not applied to <code> text unless the <code> is nested in a <pre> block.
Moreover, nested <code> may overide some <pre> styling, even via defaults
(it generally renders in browsers' "monospace" defaults unless restyled).
HTML's <pre> and <code> roughly correspond to CSS's "block" and "inline"
display attribute values ("inline-block" arranges elements horizontally).
For more on inline <code> usage, see its styling ahead in this section.
------------------------------------------------------------------------------------
*/
PRE, pre.fancy {
/* feb18: mobile resesign (can override) */
overflow-x: auto; /* scroll if needed for mobile and shrunken windows */
white-space: pre; /* just to be sure? */
font-family: Courier, monospace, sans-serif; /* better: else some mobiles aren't mono? */
background-color: ivory; /* color, okay iff scrolled to window size (else truncated) */
outline: black solid 1px; /* border, okay if scrolled (else bisects code in most wb) */
padding: 5px; /* space around code within pre block, one=all 4 sides*/
margin: 20px; /* space around pre block itself, just one = all 4 sides */
}
/* original settings */
/* margin: 20px; /* don't indent in the text itself */
/* font-family: Consolas, "Courier New", Courier; */ /* override default, use bolder consolas */
/* outline: green solid 1px; */ /* size = max(screen size, text size) (but no-op on IE!) */
/* border: 1px solid blue; */ /* size = screen size, even if text longer (but not on IE!) */
/* feb18 experiments */
/* border-right: hidden; */ /* feb-18: else rb bisects code on small screens */
/* background-color: ivory; */ /* feb-18: this still cuts off on screen, not code */
/* display: inline-block; */ /* feb18: this makes border fit content, no bisect */
/* border: 1px solid blue; */ /* bit it looks a bit odd for narrow listings */
/* white-space: pre; */ /* and requires <p> immediately after </pre> */
/* the following traces an incremental voyage into the heart of font darkness... */
/*
------------------------------------------------------------------------------------
TAKE 1 of 3, Jul-2018: scale code down just a bit versus surrounding narrative;
but don't use html <code>: its [font-family: monospace] default is too small;
and don't do this on smaller screens, where text is already small as it is.
------------------------------------------------------------------------------------
*/
/*
* @media screen and (min-width: 641px) {
* PRE, pre.fancy {
* font-size: 95%; /* 641+ displays only (not for 640 or less) *
* }
* }
*/
/*
------------------------------------------------------------------------------------
TAKE 2 of 3, Jul-2018: try other code fonts - much of this site's content is code.
This rule's settings replace same settings (but not all) in those above it.
To try fonts: https://developer.mozilla.org/en-US/docs/Web/CSS/font-family.
Notes:
- must use "monospace" all by itself in rule's attribute, else it's
not mono on Android Chrome (oddly - but see Take 3 ahead)
- Courier == monospace on Mac Chrome; "Courier New" == Courier on
Android and Windows Chrome
- Courier is much duller on Windows, Android Chrome, and iOS Safari;
- the generic monospace (alone) is generally sharper, but small
on most browsers by default: scale it up to make code more readable
------------------------------------------------------------------------------------
CAVEAT: code fonts vary maddeningly per browser/version/platform (e.g.,
monospace default is subpar on some Firefox, courier is dull on Android
Chrome, and consolas looks much nicer than either courier or the monospace
default on some Windows browsers). Because browser/platform detection
requires JavaScript, this is mostly a "punt" here, but focus efforts on
this tech-oriented website's half1 2018 browser audience:
Desktop = 67%/18%/5% for Chrome/Firefox/Safari
Mobile = 56%/24%/3% for Chrome/Safari/Firefox
Platforms and device categories overall were:
Platform = 61%/15%/13%/7%/4% for Windows/Mac/Linux/Android/iOS
Device = 87%/9%/3% for desktop/mobile/tablet
Top browsers across all device categories broke down as:
60% Chrome desktop
16% Firefox desktop
5% Chrome mobile
4% Safari desktop
3% Edge desktop
3% IE desktop
2% Safari mobile (non-tablet)
And most relevant, top browsers across all platforms broke down as:
43% Chrome Windows
9% Chrome Mac
9% Firefox Windows
7% Chrome Linux
6% Firefox Linux
5% Chrome Android
4% Safari Mac
3% each for Edge Windows, IE Windows, Safari iOS
A limited-resource site probably stops caring near the end of this.
Also note that many browsers allow users to set mono/fixed font
defaults, though these only apply if use "monospace" in CSS here,
and users can't be expected or required to change this in any event.
For more analytics: learning-python.com/site-traffic-half1-2018.txt.
------------------------------------------------------------------------------------
*/
/*
* PRE, pre.fancy {
* font-family: monospace; /* just this, else Android Chrome is not mono *
* font-size: 110%; /* scale up, else reduced in some browsers; or 1em; *
* }
*
* @media screen and (min-width: 641px) {
* PRE, pre.fancy {
* font-size: 117%; /* scale up more on larger displays - 641+ pixels; *
* }
* }
*/
/*
------------------------------------------------------------------------------------
TAKE 3 (final?), Jul-2018: use a precedence list (as before), but with better
fonts and ordering that try to balance the needs of multiple platforms and
browsers. Also fix Safari iOS landscape upscaling (now above). This prefers
Consolas on Windows, and monospace works for Chrome on Android if coded with
others this way (for reasons unknown). In more detail:
monospace
is required for mobile browsers like Chrome and Safari: Courier is badly
washed out on these platforms, while monospace is crisp and well-sized.
Conversely, monospace's default may be unusually small, large, or dull on
some other platforms, making it poor for portability. monospace is a CSS
keyword best listed last; because it's universal, it hides anything listed
after it. On most desktop browsers, monospace's font can be set by users.
Consolas
is better for Windows, where Courier - the usual monospace default - is dull
at most zoom levels. This depends on browsers and user settings, but listing
Consolas first ensures its usage. The downside is that another user-selected
font for monospace won't apply to this site's formatted code, though most
Windows users probably never change their browser's mono-font settings anyhow.
Ubuntu mono
is the same story, for Linux (only): the default monospace seems too large,
fonts cannot be scaled on a per-family basis in CSS, and listing it here means
systems that have it won't allow code fonts to be changed by users - a less
trivial tradeoff on Linux where custom seems the norm, but trade off we must.
Courier
is the typical monospace default on Macs, and looks great (as usual on Macs).
Listing it last here makes it the general fallback option everywhere, though
monospace probably makes this moot - and uses Courier on Macs anyhow.
Menlo
is very nice on Macs, and would be okay to add to the front list below, but
it's large by default, and there's again no way to scale down by family.
Note that a user's monospace font setting will still be used on systems with a
Consolas or Ubuntu mono, for the native text display produced by a showcode.py
page's raw-text "view" link. User settings won't apply to either formatted
files (showcode.py) or code sections nested in other pages (<pre> or <code>).
Also note that, as coded, <pre> fonts are scaled down slightly for _both_ small
devices, and small windows on larger devices. Using 'device-width' instead of
'width' may avoid the latter, but even on the same device 'device-width' can
vary per browser, and the font reduction means more text is shown (a feature?).
In the end, fonts are a risky business, because they may vary per platform.
Unfortunately, monospace also varies too widely to make it a sole solution.
------------------------------------------------------------------------------------
*/
PRE, pre.fancy {
font-family: Consolas, "Ubuntu mono", monospace, Courier;
font-size: 95%;
}
@media screen and (max-width: 640px) {
PRE, pre.fancy {
font-size: 89%; /* scale down more on small views (~640 pixels): show more text */
}
}
/* the -webkit safari iOS hack was added at this time too: moved above */
/* note that this had no effect on <pre> text: code was luckily immune */
/*
------------------------------------------------------------------------------------
INLINE CODE (not blocks), July 2018
This site has not historically used <code> tags (except in a copied and
reconstructed article), because they are tedious to insert in hand-edited
HTML files. Some are being added gradually to a few popular tech pages as
time allows. strings30.html, for example, is a top search target and a
top-5 traffic page, and warranted 318 <code> inserts for literals. Other
pages get fewer hits (10%?), but may be significant enough to merit edits.
When used, apply the same font formatting as <pre> code/text blocks above,
but add color shading to make literals stand out better (on some platforms,
the font difference is negligible, and not enough by itself).
TBD: scale up to 100% everywhere to make it the same size as the text in which
<code> is embedded? Else it's smaller than surrounding text by default,
and this may look odd in embedded mode (unlike <pre> blocks). Alas, this
is too variable across platforms/devices for objective consensus.
Also removed the <pre><code> nesting in a copied article: use just <pre>
for code listing blocks, else <code> settings here can override <pre>'s.
------------------------------------------------------------------------------------
*/
CODE {
font-family: Consolas, "Ubuntu mono", monospace, Courier;
font-size: 95%;
background-color: #eeeeee; /* very-light grey bg to accentuate; same as #eee */
/*background-color: #f2f2f2;*/ /* sep18: lighter? screens vary, dingy vs washed out */
}
@media screen and (max-width: 640px) {
CODE {
font-size: 89%; /* scale down more on small views (~640 pixels): show more text */
}
}
/*
Aug-2021: Caution - do NOT go smaller for CODE everywhere blindly: Windows CODE font
is already smaller than narrative, and this would make CODE code differ from PRE code.
Really, font size depends on font family, but the latter varies across plaforms (yuck).
*/
/*
====================================================================================
HEADER (AND OTHER) BACKGROUNDS
An alternative to former table-based colorization.
====================================================================================
*/
/*
------------------------------------------------------------------------------------
Dec18 retrospect: it would be nice to add a "padding-left: 2px;" for extra
space on the left of text in titles, but the banner/colorized headers here
are not used everywhere, and are used just for the color in some contexts
where the added space wouldn't make sense (e.g., titles with images too).
Space to the left of text is being added on a case-by-case basis instead.
------------------------------------------------------------------------------------
*/
.tanheader { /* for any header level, or <P> etc. */
background-color: tan;
}
.lighttanheader {
background-color: wheat; /* wheat, or cornsilk: too light? */
}
.lightesttanheader {
background-color: cornsilk; /* too light for headers, ok for areas */
}
.darktanheader {
background-color: #A28264; /* it's dark brown... */
}
.leftspace { /* dec18: mix into header, where it helps */
padding-left: 2px; /* but most pages use more custom schemes */
}
/* other pages: for variety (and not yet used?) */
.lightbluebg {
background-color: #DFF0FF;
}
.darkerluebg {
background-color: #A2CDF3;
}
.lightgreybg {
background-color: #E9E9E9;
}
.darkergreybg {
background-color: #C1C1C1;
}
/*
====================================================================================
HOMEPAGE: BUTTON TABLE (mostly, its link cells)
An exercise in trying to forge a real GUI in a webpage using ad hoc css...
====================================================================================
*/
/*
DEFUNCT, NOV21: the former resized table has been replaced with nested
divs which show 2 columns on larger displays, and collapse into 1 column
on smaller displays. All the redesign's CSS is in-page in index.html.
*/
/*
------------------------------------------------------------------------------------
Jan16: drop html nowrap for this, but increase css's fixed size to 170px.
Fixed-width columns seem problematic: old firefox 28 on linux line-breaks
content if smaller, and nowrap+smaller makes content cross columns boundaries.
Feb18: make index table responsive for mobile via media query for small screens.
The alternative is to make images % proportional, but there's more to shrink here.
Sep18: change the 2nd click's cutoff from 480px to 360px so stretches into
more empty space on medium-width devices (e.g., Galaxy S8); else too small.
The 1st click still apples to small devices, like iPhone 4/5/se, Lumia 520).
Also, don't repeat unchanged properties in redefs: uses union of all parsed.
------------------------------------------------------------------------------------
*/
.blocklink { /* 0..359: smaller for smaller mobiles and shrunken windows */
display: block; /* hrefs that look like buttons */
width: 4.5em; /* was 170px: bad for mobile; was 145px, but causes lined-breaks in older firefox */
text-decoration: none; /* no underline for the link: forge a true gui's button */
}
@media screen and (min-width: 360px) {
.blocklink { /* 360..549: else medium for larger devices and windows */
width: 5em; /* was 480px, but wasted empty space on some devices */
}
}
@media screen and (min-width: 550px) {
.blocklink { /* 550..639: else in-between medium so not as large a jump */
width: 125px; /* alt: make table size a % of screen size (see bookimg) */
}
}
@media screen and (min-width: 640px) {
.blocklink { /* 640+: else larger for largest devices and windows */
width: 170px; /* 4th click; this was the prior desktop size (now a max) */
}
}
.blocklink:hover {
text-decoration: underline; /* underline only when cursor hovers over link */
font-style: italic; /* feb18: and go italic for consistency with footer */
}
/*
------------------------------------------------------------------------------------
Sep18: move the table itself left on small devices (e.g., 5" iPhone/Pad).
Else has body/page border on left but none on right. Could drop the border
altogether on this page (only) to save pixels, but inconsistent with site.
------------------------------------------------------------------------------------
*/
.linkstable {
margin-left: 1em; /* prior setting, 321+ */
}
@media screen and (max-width: 320px) {
.linkstable {
margin-left: 4px; /* go small, 0..320 */
} /* bit not max-device-width, else also for landscape */
}
/*
------------------------------------------------------------------------------------
Sep18: NOT USED, but retained as a tbd option - make the table a % proportional
to container, up to a max. The following (with all other settings above) scales
the table smoothly with the window, makes use of more empty space at some sizes,
and nearly works the same, but may yield some border cases of text and/or table
overflow on some devices. Punt for now; the clicks model above works (jumpily),
and this is tricky without a huge arsenal of test devices (or reliable emulators).
------------------------------------------------------------------------------------
*/
/*++++++++++++++++++++++++
.blocklink {
width: 100%;
}
.linkstable {
table-layout: fixed;
width: 95%;
max-width: 385px;
}
.linkstable td {
width: 50%;
}
++++++++++++++++++++++++*/
/*
====================================================================================
HOMEPAGE + BOOK INDEX: LEFT PANEL TABLE
Feb18: make slightly smaller on smaller displays to save pixels for other parts.
====================================================================================
*/
/*----------------------------------------------------------------------------------
SYNOPSIS: iOS-13 Safari's aA page zoom can break viewports and make some pages
require horizontal scrolls on small devices. Given that this is really a screen
zoom akin to pinch/spread for such pages, it can't be fixed - and recodings to
avoid table layouts didn't look the same, and required scolls too. As a result
of this thread, book-icon images now scale down via media queries on smaller
devices, to lessen the issue. For a user-level write-up with screenshots:
https://learning-python.com/about-this-site.html#safariios13pagezoom
DETAILS:
Aug-2020: try adding a smallest device viewport-size 'click' to shrink images.
On the smallest device tested, a 4" iPod using iOS/Safari, the existing code
rendered fine at the usual 100% font size, but spanned off screen and required
horizontal scrolls at > 100% font. Larger iOS devices, including a 4.7" iPhone
SE fit fine up to 125% zoom but scrolled theerafter. A noble attempt, but...
CAVEATS:
- The new .bookicons click doesn't seem to have any effect, because this
sizes the _table_ on the left, not the _images_ inside the table...
which define their own width and height in HTML attributes, and probably
shouldn't - this clashes with the parent table sizes here. REWRITE ME!
- This layout should be continuous responsive with % sizing to better handle
very large fonts on very small screens. 'Clicks' based on device size don't
do the job in this use case, but a brief % recode failed to retain the design.
- The overall layout of the scrolling pages uses <table>s instead of <div>s.
A recoding to use the latter didn't look the same (the left panel didn't
span), and still required scrolls for right-panel content at zoomed views
anyhow; alas, small devices just don't work well for text-heavy content.
Scope: this issue doesn't occur on Android - its Chrome renders the home page
properly at very large font and screen zooms, so this seems an iOS/Safari-only
issue (bug). Work-around: Safari page zooms work well if rotated to landscape;
this seems reasonable on rare devices of a platform that's just 4% share here.
UPDATE: recoded to downscale images on smaller viewports with the .bookiconimg
media queries below, used in the home and book-index pages. This may not be
as nice as % continuous/responsive, but it's a much easier fix. Note: on a
4" iPod, viewport size dynamically _decreases_ when font size is increased
(at 100%=>115%); this can trigger the smallest click used for images here.
Android Chrome doesn't do this on global or in-browwer font|screen resizes.
UPDATE: at least for the pages impacted (index, index-book-links), the new
aA page zoom is really a _screen_ zoom with fixed stops, not a font zoom:
the entire page expands just like a pinch/spread zoom, and nothing can be
done to address this. A radically different layout may help to a point,
but will still fail to fit at high zooms. Hence, PUNT; it sucks that Apple
breaks sites this way, but chasing artificially introduced bugs with very
low audience impact is pointless - and just no fun. Keep image clicks
anyhow, because they lessen the impact, and make sense.
UPDATE: a recoding to use <div>s instead of <table>s for layouts was close,
but couldn't quite match visually, and required the same scrolling of text
at page-zoomed views anyhow. PUNT; 4.X" devices just aren't good for text.
----------------------------------------------------------------------------------*/
/*----------------------------------------------
Caveat: width here harmless, but has no effect!
See the notes above, and the work-around below.
------------------------------------------------*/
.bookicons { /* aug20: smallest 'click' for rare cases? (see above) */
width: 20px; /* 0..320 - fits ipad touch 4" at larger font sizes */
padding: 0px;
}
@media screen and (min-width: 321px) {
.bookicons { /* feb18: leftside panel: smaller on smaller displays */
width: 40px; /* 300..479 - fits smaller devices */
padding: 1px;
}
}
@media screen and (min-width: 480px) {
.bookicons { /* 480..639 - fits galaxy j7 5.5" */
width: 40px; /* now has 4th click here (like actions table above */
padding: 2px;
}
}
@media screen and (min-width: 640px) {
.bookicons { /* 640+: original desktop size */
width: 50px;
padding: 5px;
}
}
/*------------------------------------------------------------
Aug-2020: apply viewport clicks to _image_, not table cell.
Should ideally use % continuous to a minimum/maximum (and
the layout should use float <div>s instead of <table>s), but
recreating the original layout with that scheme didn't quite
match, and still required scrolling on small iOS devices.
NOTE: this code is copied to index.html + index-book-links.html
manually and temporarily, to avoid issues with browsers caching
the prior version of _main.css - in which the lack of this code
renders images huge! DELETE the temp copies after a reasonable
time to allow caches to catch up with this file's new version.
Alt: append a query arg to file URL, but this disables caching.
UPDATE: finally deleted from index pages nov21.
----
UPDATE, JUL-2023: added the .bookiconimgsquare to publicize the
PC-Phone USB Sync app (it's not fully open source or free, but
it's Py code, and uses Mergeall). This icon originally used:
class="borderedimg bookiconimg" style="height: 95%; width: 95%;"
But that resulted in comical vertical stretching on older Chrome,
Opera, and Safari on both PCs and mobile. Older Firefox and
updated C/O/S were all okay, so this was probably a webkit bug
which was only noticeable on browsers not updated in the last
~3-ish years - if any be. But it's worth the simple fix here.
NOTE: also copied to index.html to subvert caching that leaves
new class undefined and renders huge (stupidly!): cut there soon.
--------------------------------------------------------------*/
.bookiconimg { /* 0..319: watches, 4" ipod @ large font */
width: 54px; /* 75% original */
height: 71px;
}
.bookiconimgtall {
width: 34px;
height: 55px;
}
.bookiconimgsquare { /* jul23: for p-p-u-s non-book icon */
width: 54px; /* failed: style="height: 95%; width: 95%;" */
height: 54px;
}
@media screen and (min-width: 320px) { /* 320..359, 4" ipod touch, 4" se/5, 4.X" lumia */
.bookiconimg { /* 85% oiginal */
width: 61px;
height: 81px;
}
.bookiconimgtall {
width: 38px;
height: 63px;
}
.bookiconimgsquare { /* jul23: for p-p-u-s non-book icon */
width: 61px;
height: 61px;
}
}
@media screen and (min-width: 360px) { /* 360+: 4.7" 2020 se; s8/9, note 10/20, fold */
.bookiconimg { /* also for tablets, typical desktop windows */
width: 72px; /* originally used for all devices/windows */
height: 95px;
}
.bookiconimgtall {
width: 45px;
height: 74px;
}
.bookiconimgsquare { /* jul23: for p-p-u-s non-book icon */
width: 72px;
height: 72px;
}
}
/*
====================================================================================
FOOTER TOOLBAR TABLE [site-wide]
Navigation bar at window bottom (makes homepage a bit superfluous - as it should).
====================================================================================
*/
/*
------------------------------------------------------------------------------------
Feb18: massive redesign to make toolbar scrollable at a minimum width for mobile.
Moves most markup to <div> instead of table, but retains fixed positioning.
Also works around left-corner URL popups on mouse-over on Edge (and now Firefox).
The toolbar's html itself is generated by genhtml, from html templates and inserts.
------------------------------------------------------------------------------------
May18: kill the scrollbar space below the toolbar on desktop browsers, by using
"autoscroll-x: auto" (not scroll). See also the apr18 tbd below for background.
The space was forced formerly to accommodate mouse-over URL popup overlays on
recent Firefox and all Edge. But Firefox 59 fixed this issue; the space really
didn't help Edge anyhow; and Mac OS users might never see the space on Chrome,
Safari, or Firefox if their scroll-bar General preference was set to scrolling
or automatic. Keeping the space just Edge isn't justified: it's just a 2%-3%
share browser here, and the scroll space isn't enough to fix its overlay issue.
This change is irrelevant on all mobile browsers (they never added scroll space,
and use swipes), and was propagated to training-main.css all apps' UserGuide.html.
On Mac OS, user scrollbar settings still impact all browsers for "overflow-x:auto":
when-scrolling is like mobiles (never show space, but overlay during scroll and
use swipe gestures); always-show posts a clickable scrollbar when needed only;
and automatic chooses between the two for mouse (pointers) or trackpad (gestures).
------------------------------------------------------------------------------------
*/
/* FOOTER TOOLBAR TABLE */
/* Jul18: settings here are extended or replaced by other rules below. */
.footerdiv {
position: fixed; /* anchor to bottom of display */
bottom: 0; /* position:fixed + scroll doesn't work for <table> */
overflow-x: auto; /* scroll, scrollbar iff needed (see URL hover popups) */
width: 100%; /* overflow-x:auto adds scrollbar space iff needed */
left: 0px; /* no space on left for <body> indent */
}
/* cruft */
/* margin-top: 30px; */ /* doesn't work here: use <br>s */
/* overflow-x: scroll; */ /* no: hide scrollbar till needed, mobiles never show */
.footertable { /* common browser-neutral formatting for footer button bar */
border-collapse: collapse; /* collapse border into single line */
border: 1px solid black; /* use border because color may be same as some content */
left: 0px; /* get rid of small blank space on the left side */
min-width: 650px; /* too crammed to see below this; else scrolbars don't appear */
width: 100%; /* span full screen horizontally */
height: 1em; /* 3 = alt for url popup overlays in dumb browsers (but too big) */
table-layout: auto; /* mar22: "fixed" is same as width:11%, for 9 items */
}
/* mar22 norrower: min-width 700 ~ 650: "Programs"=>"Code", drop "Email" */
/* cruft/original */
/* border: 0px; */ /* if on table only, 2px renders as outside-only border */
/* dec-15 */
/* right: 0px; */ /* but not this, or margin-left; css seems very redundant and ad hoc */
/* table-layout: fixed; */ /* alt: small words isolated, not as good when window is shrunk (+) */
/** position: fixed; */ /* fix position always at window bottom regrdless of size, position in doc */
/** bottom: 0; */ /* versus only at end of doc (must scroll to find, but less distracting? */
/** overflow-x: scroll; */ /* show scrollbar for items clipped - supposedly (no-op if pos:fixed) */
/* feb-18 */
/* max-width: 100%; */ /* seems useless here */
/* top: 0; */ /* top of screen alt */
/* margin-top: 30px; */ /* doesn't work here either if in <div>: use <br>s */
/*
* (+) Caution: "table-layout: fixed;" may cause rightmost item to be clipped when
* window shrunk, if padding on both left and right of table td items; don't use
*/
/* FOOTER TOOLBAR LINKS */
/* Jul18: settings here are extended or replaced by other rules below. */
.blocklinkbar {
display: block; /* hrefs that look like buttons */
width: 100%;
text-decoration: none; /* no underline for the link: forge a true gui's button */
color: black; /* dec-15 */
/*font-weight: bold;*/ /* too distracting? */
}
.blocklinkbar:hover {
text-decoration: underline; /* underline to designate link */
font-style: italic; /* feb18: and go italic if url popup */
}
.blocklinkbar:active { /* dec-15 */
font-style: italic; /* not retained in tables */
/*font-weight: bold;*/ /* too distracting? */
}
/*
------------------------------------------------------------------------------------
Jul18: scale up toolbar links for smaller mobile devices, else can be hard
to scroll/activate with swipe/touch. Keep the former size on larger/desktop
devices: generally mouse-based or movable windows not constrained to bottom
of the device. Uses CSS device-width, not width, to avoid larger toolbars
when windows shrunk on larger devices.
Caveat: this relies on browser-specific behavior. Toolbars may not upscale in
landscape mode on some high-res mobiles (e.g., Galaxy S8+/9+), but the screen
edge is more usable in this mode. Conversely, toolbars may upscale on some
tablets in portrait mode (e.g., older Firefoxes on Windows 8 tablets), but this
is an acceptable tradeoff. Also used in training-main.css, apps' user guides.
Oct18: tried scaling up everywhere instead of only small devices, because it
may be more usable on Android landscape (and mobiles with a stylus like the
Note 9 have a hover to italicize). The result is gross on desktops: punt!
Nov19: this avoids ":hover" on small devices assumed to be mobiles, because
hover effects can otherwise get 'stuck on' on these (though they effect is
minor if a click loads a new page). Really, ":hover" probably shouldn't be
used at all for sites that support mobile; there's no universal way to detect
non-hoverable devices, and ":hover" can also require two taps instead of one
to activate widgets on iOS Safari; see strings30.html and the head/body genhtml
insert code for floating 'top' buttons in python-changes-2014.html for more.
Alas, iOS Safari use is subpar as is, but this is 1%-2% of this site's traffic.
------------------------------------------------------------------------------------
*/
@media screen and (max-device-width: 640px) {
.footertable {
min-width: 760px; /* need more whitespace for larger font; mar22 was 800 */
height: 1.25em;
}
.blocklinkbar {
font-size: 1.25em; /* go large, for touch */
}
.blocklinkbar:hover {
text-decoration: none; /* else underline/italic may get stuck on scroll */
font-style: normal;
}
}
/*
------------------------------------------------------------------------------------
Jul18: add some left/right (only) padding around toolbar table items, so they
don't run together in Android Firefox when set to use a huge system-global font.
This hasn't been seen in other contexts (but...). This change has virtually no
impact on layout in any other browsers, because the cell <td>s are center-aligned.
------------------------------------------------------------------------------------
*/
.footertable td { /* for all <td> nested in a class=footertable */
padding-left: 5px; /* limit the damage of large-font crunch */
padding-right: 5px; /* using both may clip rightmost if table-layout:fixed */
text-align: center; /* mar22: and drop all the html align=center, finally! */
white-space: nowrap; /* mar22: don't wrap on '-' for large fonts/zooms */
/* width: 11%; */ /* mar22: this is the same as table-layout: fixed */
}
/*
------------------------------------------------------------------------------------
Oct22 - more toolbar shrinkage
Lower min-widths here from 650=>500 (after 560) and 760=>700, and change link
words in HTML+templates fom Training=>Train in toolbar+homepage and Search=>Find
in toolbar. After Mar22's 700=>650 and 800=>760, Programs=>Code and drop Email.
In Chrome on Windows, overlay scrollbars now partly cover toolbar content (blah),
and the default is still the ugly gutters (overlays require a chrome://flags).
Go narrower to minimize the need for toolbar scrolls altogether--shows scrollbar
iff window is atypically small or fonts/zoom are atypically large. Else a full
menubutton redesign may be next...
This is a Windows+Chrome issue only; macOS, Linux, and Android and iOS mobiles
do scrollbars better, and Firefox and Edge do them better on Windows. This
also smacks of the old Edge URL overlay bug (see edge-links-bug.html here),
but Google seems less likely to provide a fix given their dominance, and
Windows and Chrome largely own the PC realm (mind-bogglingly).
Chrome _may_ adopt a new-and-less-obtrusive scrollbar overlay model added to
Chrome's code base by Edge. But as is, the Chrome's Windows default in 2022
is still 90s-style scrollbar gutters, and its overlay scrollbars break content.
Where did broswers get the idea that page space is theirs for the taking?
A lower min-width doesn't have any effect on PCs until window becomes narrower;
on mobiles, going lower preserves layout after space freed by shorter words.
Note: got rid of align=center in all toolbar <TD>s earlier; see mar22 here.
Also: added google analytics 4 tag, <tr> in toolbar to silence ffox warning.
CAUTION: the old training site's pages use their own 50px+ larger versions of
this (training_main.css), and docs for program packages may be using anything.
UPDATE: it's possible to hide the overlay's bar in CSS, but it comes with
accessibility/usability tradeoffs that make it unusable here; see code+info:
https://learning-python.com/about-this-site.html#winchromescrolls
It's best to minimize scrolling potential and wait for a Windows Chrome fix.
------------------------------------------------------------------------------------
*/
.footertable {
min-width: 500px; /* was 650 oct22, 700 earlier; Train+Find frees space */
} /* and table-layout: auto still beats fixed */
@media screen and (max-device-width: 640px) {
.footertable {
min-width: 700px; /* was 760 oct22, 800 mar22 */
} /* need more whitespace for larger font on mobiles */
}
/*
------------------------------------------------------------------------------------
Oct22 - hide scrollbar for toolbar (added after narrowing)
This is a temporary measure for Windows Chrome, and a complex tradeoff covered here:
https://learning-python.com/about-this-site.html#winchromescrolls-Hide
Narrowing (earlier and above) is still useful to avoid the issue in general.
CAUTION: old training site's .css and off-line docs in some packages copy this code.
------------------------------------------------------------------------------------
*/
.footerdiv::-webkit-scrollbar {
display: none; /* Chrome, Safari, Opera, etc. */
}
.footerdiv {
-ms-overflow-style: none; /* IE, old Edge */
scrollbar-width: none; /* Firefox */
}
/*
------------------------------------------------------------------------------------
Apr18: TBD - kill space reserved for scroll below the toolbar?
--DEFUNCT: SEE May18 resolution above--
The scroll space appears on desktop browsers only, but seems a waste.
It's required for recent Firefox, else url-hover popup covers links.
Without the space, Firefox is usable but just barely - must move cursor.
Edge is beyond help either way - its popup is rude (and its traffic is ~3%).
Chrome, Safari, and IE don't need the space, but Firefox is 17% of traffic.
JavaScript tricks to disable popup or detect Firefox are non-starters.
PUNT for now, and add space to program user guide docs for consistency.
.footerdiv {
overflow-x: auto; /* show scroll iff needed *
}
.footertable {
height: 1em; /* 3 also helps, but it's chunky *
}
------------------------------------------------------------------------------------
*/
/* Not used: Npx + collapse can be variable-width on some browsers (firefox, etc), and distracting */
.footercell { /* 1px can be variable-width on firefox */
border: medium solid black; /* 2px seems distracting but browser-neutral and concise */
}
/*
====================================================================================
BOOK-TITLE PAGES EDITION TABLES
Used for all 3 title pages' editions tables, but not for top of page layout (divs).
====================================================================================
*/
/* EDITIONS LINKS */
/* caution/caveat: these are used in purchase-pointers.html too */
.booktablelink {
font-weight: bold; /* same as <B><I>...</I></B> */
font-style: italic; /* when used, <td> uses "nowrap"; css "white-space: nowrap" in IE8+ only */
text-decoration: none;
}
.booktablelink:hover {
text-decoration: underline; /* active feedback */
}
/* EDITIONS TABLE */
/*
------------------------------------------------------------------------------------
Apr18: restyle the book index-page edition tables, such that the top and bottom
rows aren't "short-changed" on whitespace. This is almost like a simple html
table's "cellpadding=4 cellspacing=2" but the top row gets more space above
it, and the bottom row gets more space below it, yielding a more uniform look.
Otherwise, the rows in the middle seem to be further apart (picky, but true...).
Html cellspacing is space between cell borders
in css, <table style="border-spacing: 5px; border-collapse: separate;">
Html cellpadding is space inside cells, to the border
in css, <th style="padding: 3px;">, for all <th> in a table/class
Though css spacing may not be portable to IE < 7 (see HTML IE comments form).
------------------------------------------------------------------------------------
*/
.edstable th { /* for all <th> within <table class=edstab> */
padding-top: 3px;
padding-bottom: 3px;
}
.edstable td, .edstable th { /* ditto, but for both all <th> and all <td> */
padding-left: 4px;
padding-right: 4px;
}
.edstable td { /* for all <td> only (data rows) */
padding-top: 6px;
}
.edstablelastrow td { /* for all <td> within <tr class=edstablastrow> */
padding-bottom: 6px;
}
/*
====================================================================================
NOT CURRENTLY USED
====================================================================================
*/
#pagenavtan, #pagenavblue, #pagenavgrey { /* and use id=name, not class=name */
background-color: cornsilk;
float: left;
padding: 5px;
padding-bottom: 10px;
border-width: 10px;
}
/* other ideas */
/* line-height: 30px; */
/* height: 300px; */
/* width: 100px; */
/* font-size: 9px;*/
#pagenavblue {
background-color:cornsilk; /* override prior settings */
}
#pagenavgrey {
background-color:cornsilk;
}
/*
====================================================================================
NON-FORMATTING TABLES
Use <TABLE class=nftable> (or id=xxx for #xxx) to activate.
====================================================================================
*/
.plaintable {
text-align: center;
/*border-collapse: collapse;*/ /* kill double lines */
border: 1px solid black; /* firefox draws single lines badly */
}
.plaincell {
padding: 3px;
text-align: right;
}
.nftable {
border-collapse: collapse; /* kill double lines */
}
.nftable, .nftd, .nfth {
border: 2px solid black; /* standard borders */
}
.nftd, .nfth {
padding: 5px; /* standard cellpading */
}
/*
====================================================================================
BOOK-PAGE IMAGES
Feb18: need to scale down for mobile, else long words split wrap-around text.
====================================================================================
*/
/*
------------------------------------------------------------------------------------
Same for all screen sizes: continuous responsive.
Max-sizes avoid bleed over; alt: set on <div> container?
Also use higher-resolution images so sharper when larger.
------------------------------------------------------------------------------------
*/
.bookimg {
width: 30%;
height: auto;
max-height: 250px;
max-width: 200px;
margin-right: 20px;
margin-bottom: 10px;
}
.bookimgtall { /* override for pyref class="x y" */
max-height: 250px;
max-width: 150px;
}
/*
------------------------------------------------------------------------------------
Alternative...
@media screen and (orientation: portrait) {
img { max-width: 90%; }
}
@media screen and (orientation: landscape) {
img { max-height: 90%; }
}
------------------------------------------------------------------------------------
*/
/*
------------------------------------------------------------------------------------
Alternative...
.bookimg { /* 0.479 *
width: 50%;
height: auto;
}
@media screen and (min-width: 480px) {
.bookimg { /* 480..639 *
width: 33%;
height: auto;
}
}
@media screen and (min-width: 640px) {
.bookimg { /* 640+ *
width: 25%;
height: auto;
}
}
------------------------------------------------------------------------------------
*/
/*
====================================================================================
LISTS
Add space between bullet and number item lines for usability/readability.
====================================================================================
*/
/*
------------------------------------------------------------------------------------
NOT USED: this might be VERY good site-wide too (like PRE), but there are
too many old special-cases, and some merit more whitespace than others.
Changing pages as they are worked on to use this in-page, and drop all
<br><br>s (see also later alternative below).
LI { /* feb18 mobile: redesign lists for small screens *
margin-bottom: 10px; /* all double-space, else hard to read or tap *
}
------------------------------------------------------------------------------------
*/
/*
------------------------------------------------------------------------------------
Apr18: use <ul|ol class=spaced> to space lists' <li> only. A tactical
alternative to the preceding strategic option, and minimizes edits.
Note - some pages use more/less pixels via in-page or in-tag styles.
------------------------------------------------------------------------------------
*/
.spaced LI {
margin-bottom: 7px;
}
.spacednested LI {
margin-top: 7px; /* better for nested lists */
}
/*
====================================================================================
GENERIC WHITE TABLES
====================================================================================
*/
/*
------------------------------------------------------------------------------------
Feb18: white tables in latest-edition and purchase-pointers pages.
These don't break Chrome toolbar when shrunk: breaks iff nowrap?
------------------------------------------------------------------------------------
*/
/*
------------------------------------------------------------------------------------
MORE ON TABLES (per much blood, sweat, and tears...):
For tables, either don't use nowrap, or use "overflow-x: auto" to scroll.
The latter is best if wrapped text too weird or table too wide in general.
Otherwise, the table overflows window, causing 2 scrolls (with the toolbar).
Note that the overflow-x must be coded in a <div> surrounding the <table>.
Also note that wrapping is probably preferred for mobile in most contexts;
nowrap sometimes works anyhow, for very narrow columns (post-release-updates).
Minor update: ALSO may need scroll if table content is unbreakable and long
(e.g., urls, paths), and may need to allow that content to be broken too
if it exceeds the size of its container (e.g., text > viewport=devicesize).
------------------------------------------------------------------------------------
*/
.bktable { /* better tables through nasty css */
border-collapse: collapse;
background-color: white;
/* border: 1px solid grey; */
/* padding: 8px; */
}
.bktable th, .bktable td { /* for all <th>+<td> descendants of <table class=bktable> */
border: 1px solid grey;
}
@media screen and (min-width: 480px) {
.bktable { /* 480+: indent table on larger screens/windows */
margin-left: 30px;
}
}
/*
====================================================================================
ETC
====================================================================================
*/
/*
------------------------------------------------------------------------------------
Aug18: notebox is no longer repeated in multiple pages (an artifact of
its gradual adoption). It's still customized in some pages for color
differences (and copied and possibly tailored in all app user guides).
------------------------------------------------------------------------------------
*/
.notebox { /* a simple box for text */
margin-left: 40px; /* now common across site */
margin-right: 40px; /* use in <p> (with <br>s) or <div> (with <p>s) */
margin-top: 45px;
margin-bottom: 20px;
border-style: solid;
border-width: 1px; /* was "1" which = "1px" in quirks mode (only) */
padding: 5px;
background-color: ivory; /* was too saturated: cornsilk; */
}
.notebox-slim { /* use class="a B" mix to mod common version */
margin-top: 30px; /* css has no direct class inheritance/overrides */
margin-bottom: 30px; /* another .notebox {} mods props in same classname */
}
/*
------------------------------------------------------------------------------------
Added Feb-2018: for rare lesser stuff, don't distract with link
------------------------------------------------------------------------------------
*/
.subtlelink {
font-weight: bold; /* 'normal;' is a bit too subtle, really... */
font-style: normal; /* especially on touchscreens */
text-decoration: none; /* initially: "site" link on homepage */
color: black
}
.subtlelink:hover {
font-style: italic; /* caveat: hover won't work on touchscreens */
text-decoration: underline; /* for consistency woth new footer style */
}
/*
------------------------------------------------------------------------------------
Apr18: use class=this in an enclosing <div> to prevent following content from
bleeding into components of the <div> when the screen is big or fonts are small.
This is an alternative to making the section a <table> with margins below it,
which can wreak havoc with the placement of nested tables (e.g., about-lp.html).
Sep20 notes:
1) Also used by strings30 for image, but some pages (about-{lp, pp, pyrf}) use
this idea, but not this class - grep for overflow: auto to find the offenders.
2) Elements following this class (or idea) may warrant custom margin-top css
settings to work with or drop the blank space added at the end of a display=block
<div> - see thumbspage.html for an example. "block" alone won't prevent bleedin.
------------------------------------------------------------------------------------
*/
.nobleedin {
overflow: auto;
}
/*
------------------------------------------------------------------------------------
Apr18: use class=this in a <span> around text to prevent it from being split
for line wraps (e.g., toc dates in python-changes page). This prevents all
splitting, dashes included - why is this part of "white-space" in css?...
------------------------------------------------------------------------------------
*/
.nolinewrap {
white-space: nowrap; /* IE 8+ only? */
}
/*
====================================================================================
DESKTOP CHROME WORKAROUNDS [site-wide]
Dec18: fix <IMG> borders and <HR> lines at low zooms in desktop Chrome.
====================================================================================
*/
/*
------------------------------------------------------------------------------------
Desktop Chrome (only) has a nasty habit of shrinking or completely dropping
just some of the borders around an <IMG> image at lower zoom level settings
(anything < 100%). This makes borders unevenly sized, and noticeably odd.
The only known solution for this is to use CSS borders, not HTML borders
(e.g., border=2), *AND* mnemonic border widths (e.g., 'thin' or 'medium'),
not absolute pixels (e.g., '2px'); pixels apparently trigger fractional math
that breaks Chrome. 'thin' and 'medium' are the same as '1px' and '3px',
respectively, but are not clipped at lower zooms (alas, 2px borders are right
out if you want to support the world's most-used browser and younger eyes).
".borderedimg" below adds the required CSS styling. This is used for <IMG>s
on the main index page, the books index page, all book title pages, all book
edition pages, and more than can be listed here - essentially every page with
an intentionally bordered image (and not border=0 to omit on IE). Luckily, a
'1px' border around the global nav toolbar works okay everywhere at all zooms.
Related issue: desktop Chrome (again, only) also botches <HR> lines at lower
zoom levels (again, anything < 100%). The lines are rendered so faintly as
to be almost absent at some zooms. ".hrbelow" solves this by replacing <HR>s
with borders: apply it to <Hn> headers, <P>s and <DIVs> to add an <HR>-like
horizontal rule line that is immune to Chrome idiosyncrasy. This is also
widely used at this site, though some <HR>s still await future edit cycles.
Update: the related ".formorereading" is now applied to <H2> lines of the
other-articles sections at the end of articles, to simulate <HR> dividers.
These sometimes work best as top borders instead of bottom borders.
Note that style 'ridge' is the same as 'solid' at the 'thin'-size level,
and borders don't change size on zoom-in/out (unlike <HRs>: another plus).
See also thumbspage, where the <IMG> and <HR> issues were first addressed.
------------------------------------------------------------------------------------
*/
.borderedimg { /* don't botch <IMG> borders at low zooms */
border: thin solid; /* just for you, Chrome... */
}
.hrbelow { /* don't botch <HR> lines at low zooms */
padding-bottom: 18px; /* more Chrome pandering... */
border-bottom: thin solid black;
}
.formorereading { /* article links at end of articles: no hr */
margin-top: 35px; /* some work better with top border on <h2> */
padding-top: 8px;
border-top: thin solid black;
font-style: italic;
}
/*
====================================================================================
MARGINS [site-wide]
Apr18: add a small bit of space on the left and right of the entire body, all pages.
====================================================================================
*/
/*
------------------------------------------------------------------------------------
Initially to address distortion at the edges of curved screens on Galaxy 7/8/9,
but the extra whitespace makes text in general marginally more inviting (yes, pun).
Downsides: (1) on Android Chrome it also shrinks the text font (a font-boosting
algorithm issue?), and (2) on very small 4" screens like iPod touch, pixels are
already a precious asset. This required restyling purchase-pointers.html to be
more flexible/responsive, and is copied in training-main.css (like much else here).
------------------------------------------------------------------------------------
*/
BODY {
margin-left: 13px; /* or padding: inside a border (margin outside) */
margin-right: 13px;
/* margin-top: auto; */ /* better to accept brower's default (4..7-ish) */
/* margin-bottom: auto; */
}
/*
====================================================================================
HEADER FONTS - NOT USED (commented-out)
Apr18: scale header fonts down on smaller screens? - smaller is not always better,
and reduces whitespace; done in training page's css only, for title text crunch;
see the end of learning-python.com/cgi/showcode.py?name=training-main.css.
====================================================================================
H1 {
font-size: 150%; /* 0..479; alt: vw size specs, but not in all wb *
}
H2 {
font-size: 125%;
}
@media screen and (min-width: 480px) {
H1 {
font-size: 200%; /* 480+, go large=default *
}
H2 {
font-size: 150%;
}
}
------------------------------------------------------------------------------------
*/
/*
====================================================================================
SEE ALSO: in-page CSS with media queries and other magic in other pages:
purchase-pointers, sitesearch, python-activities-history, programs, bullets, ...
====================================================================================
*/