This desktop- and mobile-friendly website has been live since the mid 1990s. It hosts hundreds of pages spanning software-related topics including programming, technical education, and industry trends, and all of its code and content has always been both free and advertising free. This site has also always been more about substance than style; while it does keep pace with web fashion, its main focus is on providing tech material for tech readers.
This site works as you'd expect, but here are a few quick tips. All of this site's content can be reached from its bottom-of-screen toolbar and Find
. Scroll or swipe the toolbar on smaller screens to access all its links (tap first to activate where
); its leftmost image jumps to this site's home
. Larger pages, like this one, also have floating Top
that jump to page top or content lists, and some have dynamic table-of-contents
that toggle TOCs. As of 2025, more
also now follow your device's dark-mode
.
Neither specific browsers nor JavaScript are required here, but some features work best (or only) if the latter is enabled—including
, content
, and this site's many image
(more
). Most content here renders equally well on mobile and desktop browsers, though at three decades and counting, you shouldn't be surprised if some of this site's more ancient pages are still desktop biased or otherwise
. Older content may also harbor a few grammar speed bumps; like coding, writing improves with practice and time.
This section logs changes and site-usage tips that have cropped up in recent years:
: Android Chrome overlays footers with navigation toolbar (For a visual presentation of this topic, see the images and notes in the small gallery
.) In its version 135, Android Chrome (AC) has begun adopting Android 15's edge-to-edge app-display changes. In AC, this means overlaying the Android navigation toolbar on top of content fixed to page bottom—rendering such content unusable. This includes the toolbar used at the bottom of nearly every page on this website (there's one lurking below). No other Android browser does this today, though Edge similarly but temporarily imperiled toolbars long
.
So far, the AC flavor of this breaking change applies only to:
The gesture navigation bar—not the classic and larger button navigation bar
Smaller displays—not foldables and tablets, though "smaller" is not defined
Devices running Android 15 and later—where edge-to-edge was added
Further, this change impacts only pages with:
Top-level content that scrolls down—which makes the system's navigation-bar "chin" slide up into the page and overlay content
Interactive content anchored at page bottom and no free space there—which makes the overlays destructive
The combination of these requirements makes this change's impact modest today. As an example, image galleries built by the
program are immune because their default index
have ample free space at page bottom, their custom index
are builders' responsibility, and their viewer
don't scroll (and their nested note-text widgets don't count).
Moreover, the first three requirements above narrow this change's device scope. Indeed, it's been difficult to create its effects in testing. A Fold 7's cover screen, for example, triggers overlays only sporadically, and other tested devices don't exhibit them at all. When testing is lucky enough to make them happen, here's the scene on the Fold 7
a down scroll and
.
Even when the overlay does occur, users can simply scroll up slightly to make the navigation-bar chin retract again, thereby uncovering page-bottom content. This is a minor inconvenience and no worse than jumping to a top-of-page hamburger menu (which may fall victim to edge-to-edge dogma too). Users can also simply use a different browser—and perhaps should, given the perennial breakages in AC.
Nevertheless, user upgrades to Android 15+ are inevitable, and it's reasonable to assume that this change will be expanded to both larger navigation buttons and larger devices soon. Given that this mod will break a multitude of websites, its long-term prospects may seem sketchy. Given the track records of both Android and Chrome on such things, however, it seems prudent to expect the worst.
More pressingly, Chrome has a dominant 67% market share on mobile devices today per both
and
, and most of those people aren't going to install a different browser just to visit your site. For better or worse, AC's quirks are significant.
So what to do? Short of a full website redesign to concede entire portions of web pages to browsers, AC docs propose a variety of CSS approaches for handling the overlays. One leaves content visible beneath toolbars, which is obviously subpar. Another uses iffy constants and code that attempt to pad the toolbar for the chin's slide—but failed altogether in testing. See the fails
and
.
Instead, the fix at this site uses code proposed by AC docs that's an effective opt-out for the change. Here's the required change from this site's main CSS
(only its last setting is new):
.footerdiv { position: fixed; bottom: 0; padding-bottom: env(safe-area-inset-bottom, 0px); /* effectively an opt-out */ } Per AC docs, this code is not recommended for performance reasons—and so much so that AC avoids sliding the navigation bar into content when it detects this pattern. In other words, using this "forbidden" code simply turns the edge-to-edge nonsense
altogether... which is ideal! Changes that are both breaking and mandatory are rude to both site users and site developers. In this case, at least, Chrome itself provides a loophole.
For more info, and to judge all this for yourself, you can read about the AC overlays change
and its Android 15 edge-to-edge basis
and
.
Caveats: the fix used here has not yet been applied to some program docs on this site; scroll up slightly as needed until this is globally adopted. It's also possible that this fix may either become unnecessary or have to be tweaked in the future if (well, when) AC changes yet again. Alas, chasing Android and browser churn seems a full-time job.
Related: see
for a thumbspage-galleries workaround to AC's pull-to-refresh breakage that also cropped up around the time of version 135. Engineering durable content upon a constantly thrashing base like Android Chrome is difficult to impossible. When did this field forget that?
: The Windows-Chrome scrollbar blues This site's global bottom-of-page toolbar has gone narrower, as a partial accommodation for Chrome on Windows. Unfortunately, that browser's overlay scrollbars now largely cover toolbar content like
, and it's nearly impossible to operate controls covered by the overlay. Moreover, Windows Chrome's default is still the ugly and intrusive
(overlays require an obscure chrome://flags per
). Going narrower minimizes the need for toolbar scrolls of either variety, and is a low-impact work-around for overlays. 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 chronicled
, but Google seems unlikely to provide a fix given their track record and dominance. In fact, this might be dismissed as a single-browser quirk, but for the mind-boggling hold
and
have on the PC realm (though Android rules
, and stats can be
).
At this writing, Chrome may adopt a new and less obtrusive scrollbar-overlay model pioneered by
which would make overlays safe; see the
for more info. But as is, Chrome's Windows default in late 2022 is still scrollbar
(which feels like it's 1995), and its overlay scrollbars now break
(which feels rude). Where did browsers get the idea that page space is theirs for the taking?
Going narrower involved both shorter link words and a lower min-width for the scroll cutoff. On PCs, the new min-width doesn't have any effect on typical
, and ensures that a toolbar scrollbar of any sort will be required only when windows become unusually narrow, or fonts or zoom become unusually large. That is, this makes scrollbars moot except in windows that are atypical for a PC; here's the new
on a small 13" display at 100% zoom. On mobiles, going lower simply preserves former
, despite space freed by the shorter words. Test for yourself, or find more images
.
All of which may seem a trivial mod, but the alternative is a floating-menubutton redesign, which seems overkill for what's really yet another browser bug. This bug should probably be reported, of course, but this developer has grown overly tired of seeing bug reports languish—and eventually get closed with a "by design" quip. Such is the software field in the 2020s, eh?
: after scouring the web's development forums (really, gossip mills, because that's often all there is to go on sans usable vendor documentation), it turns out that an obscure and browser-specific bit of CSS can hide the overlay-scrollbars bar in most browser/platform combinations:
.footerdiv::-webkit-scrollbar { display: none; /* Chrome, Safari, Opera, etc. */ } .footerdiv { -ms-overflow-style: none; /* IE, old Edge */ scrollbar-width: none; /* Firefox */ } With that Tower-of-Babel hack, Windows Chrome's disabling
indeed goes away in bottom-of-page toolbars, but toolbar scrolling still works when needed (per the original overflow-x: auto). Here's the
. The same thing happens in all of the seventeen desktop and mobile browsers tested across five platforms, though other browsers don't make overlaid content inoperative the way that Windows Chrome does today.
The downside—and there usually is one for ad-hoc proprietary extensions like this—is that this leaves people in the dark if they have no way to perform a left/right sideways scroll. This might arise if there is no touch screen or gesture-capable touch pad, and the pointing device is unable to issue a sideways scroll. Though likely rare today, mice with neither scroll
nor touch
would fall into this category.
To compound this, detecting such limited devices seems a pipe dream; a pointer: fine media query won't
. Perhaps worse, if overlay scrollbars are disabled (Chrome's current default), the code above prevents a scrollbar
from appearing for the toolbar. Here's the
; the same goes for macOS if scrollbars are set to Always in General Preferences. Sideways scrolls still work on the toolbar in this state where available, but this rules out disabling overlays as a solution for sideways-challenged pointers: there's nothing to grab onto!
That being said, the scope of this tradeoff may be small:
Many or most devices support sideways scrolls in some fashion today, and have for a very
Mice with vertical-only scroll wheels can still scroll sideways on Windows by pressing the Shift key while scrolling with the cursor over the toolbar
Even without a scroll wheel or surface, the toolbar can always be scrolled sideways on Windows by simply clicking it and using keyboard left/right arrow keys
And other options omitted here for space (e.g.,
and
)
Despite all this, hiding scrollbars inevitably raises accessibility
, and leaves sites affected by Chrome overlays with a dilemma: which user group should be inconvenienced? Because the audience impacted by the code above is likely smaller than that crippled by Chrome's overlays, and because toolbar scrolls are relatively rare in any event, this code has been adopted as a temporary measure for footer toolbars only, pending better overlay scrollbars in Windows Chrome. If this makes toolbars unscrollable for you, please see the list above for recourses, or simply expand the window till scrolling isn't needed—a fallback made easier by the original mod here to narrow toolbars in general.
And for now, all bets on whether a Chrome fix shows up before a site redesign are officially off...
: Security and showcode.py The script that displays code and text files nicely on this site recently required an upgrade to avoid displaying files located outside the website's content folder. This cropped up because analytics revealed that someone used an explicit URL and relative path to access the site's /etc/passwd file; the fetch was useless because the file by convention simply forwards to another that's not accessible, but it was sufficiently creepy to warrant the fix. Alas, the world wide web means everyone, for better and worse. Read the seedy details at header "DON'T DISPLAY FILES OUTSIDE THE WEBSITE FOLDER" in
, and see the new reply from
.
: Emerging dark-mode support This site has started using CSS media queries to implement a dark theme, where supported by both browsers hosting the site, and devices hosting the browsers. Initially, this is implemented only on the
—whose prior white
is now a darker grey in
, and a lighter grey
. Dark mode works on recent smartphones,
, and Linux; it's available on Windows but not (yet?) in all browsers
. More pages here may go dark over time, but there's a reasonable argument to be made that text-heavy content, like books, is better in boring but readable black on white. Update, Nov-2021: the book-links page has now gone dark too, and both that and the home page now always use the dark barkground regardless of system settings. Designing for both light and dark is complex, and dark is not that dark here. The home page now also uses rounded corners and collapses its links on narrower displays; web fashion marches on.
Update, Dec-2021: image galleries at this site, all of which are created by
, now also are darker, with a new default index-page
. It's not OLED dark, but that's easy to
.
Update, Sep-2024: a few years on, limited portions of this site now use CSS media queries for prefers-color-scheme to select a color theme based on the host device's dark-mode setting. See examples
and
. This works well today, but is a bit of a jarring contrast with all the former pages not designed for dark mode, either because it wasn't yet well supported in CSS, or simply didn't yet exist. Change convolutes things.
, Mar-2025: full dark mode is now starting to roll out to more pages on this site, including its home
, book
, other top-level
, and newer image
. The basic CSS behind this is simple:
BODY { color: black; /* light mode defaults */ background: cornsilk; } @media (prefers-color-scheme: dark) { BODY { color: #e0e0e0; background: #121212; /* text: off-white on off-black */ } IMG { filter: brightness(85%); /* darken bright elements near text */ } } But configuring pleasing color themes in both modes remains a subjective and ongoing challenge. Toggle your device's setting to change web-page appearance as desired; light mode generally renders prior color themes.
: Android Firefox—toolbar bug and work-around The latest Android Firefox has a new and nasty bug related to its dynamic toolbar, which can both leave
and make this site's own bottom-of-page toolbar slide up into
. This has been seen on Firefox versions 81 through 85; happens when its Scroll to hide toolbar is toggled on; and can be triggered by scrolling to hide the browser's toolbar and then changing device orientation. The GUI seems to believe a phantom browser toolbar is still present at page bottom (and in some cases, renders an empty strip for it). To work around, either set the toggle off, or use any other Android browser until this is fixed (which may be soon, given the flurry of reports:
,
). With the toggle-off fix, pages look like
and
, but some naturally lose space in the bargain. Update, Mar-2022: regrettably, this Android Firefox bug remains unfixed as of version 98, and its report posted by this site was
as stale without developer attention. In versions 95 through 98, the bug may have also morphed—after a scroll hides the toolbar, the bug can still be triggered by rotating orientation, but also by simply moving a stylus over widgets with hover actions. Here's the
and
of the latter. The only work-around remains toggling Scroll to hide toolbar in Customize off. Hey Firefox: your dynamic toolbar is still busted a year later; doesn't anyone care?
Update, Oct-2022: if you use the latest Firefox on Android (105.1 at this writing), you'll probably also want to turn off its Swipe toolbar sideways to switch tabs in Settings => Customize. Else, it's nearly impossible to operate this site's footer toolbar with a finger, because Firefox steals most swipes near the bottom of the screen—even if they are well above the browser's own toolbar. A stylus helps by providing more touch accuracy, but not everyone has one. Alas, this site's pages seem to keep running afoul of browser
!
Update, Oct-2022: and if you use Firefox on Linux (only), you may notice that its versions 105 and 106 cover toolbar items with URL mouse-hover popups—just like Edge once did in the now-distant
. There is no work-around for this, and a bug fix seems fanciful given all of the above; see other browsers.
: Android Opera—fullscreen, /* bug On the upside, Android Opera now has a nice multi-page fullscreen mode in landscape orientation that maximizes space for content; tap the rectangular icon on the right side of its toolbar. Here's the effect
and
the tap. Chrome badly needs something similar; its address bar won't hide on pages that don't
, and JavaScript fullscreen (e.g., thumbspage's Full) lasts for just one
. Android Opera also fixed an
reported by this site, which truncated some pages at a /* in a <pre> block (and elsewhere); it was noted in version 53, but happily fixed by 60. Things get better too. Update, Jan-2022: unfortunately, this Android Opera bug returned a few releases later, by version 65. The work-around at this site required both a custom parsing
, and manual replacement of all /* with /* in three of eleven pages having this pattern here—including
and
. Alas, Opera appears to be performing some sort of naive page parsing—and appears to have discovered it anew. One person's "agile" is another's "reckless thrashing."
: iOS tip—page zooms on small devices This site renders well in portrait (vertical) orientation on mobile-device screens as small as 4"; here's its home page on a 4"
. That said, some pages may require entire-page horizontal scrolls on smaller devices if you use the new aA menu's page-zoom option in iOS 13
. This impacts a handful of pages on this site—including its
. For such pages, the new Safari option is not a font zoom; it's really a screen zoom that works like a pinch/spread with fixed stops. Specifically, this site's home page fits well in portrait mode up to 125% page zoom on the latest iPhone SE's 4.7" display, but only up to 100% on a 4" iPod. At higher zooms, your best options are a minor scroll where required; rotating to landscape for fit-to-screen
; or simply lowering your page-zoom level. Page redesigns or browser changes may address this someday, but the work-arounds are easy, screen zooms are tough to accommodate in full, and minuscule displays will never be ideal for text-heavy websites.
It's worth adding that this issue—arguably an iOS Safari bug—does not occur in Android Chrome at any practical font or screen zoom. Here's this Chrome's
and
display; unlike Safari, fonts are increased without overflowing the viewport. Though no vendor is flux free, Apple's track record of breaking sites and programs with opinion-based morph is much too large an insert for this
.
Update, Oct-2022: this site's homepage now works without full-page horizontal scrolls on a 4" iPod up to 115% zoom in Safari, after its buttons shaved 10 pixels each for unrelated aesthetics. It's not
and 100% is still
, but this is probably a worst-case device for web views (with an audience size to match).
: iOS tip—hide Safari toolbars in iOS 13+ iOS Safari users: this site works best if you hide Safari's toolbars using the new aA menu
in iOS 13. Without this setting, this site's bottom-of-page toolbar buttons must be tapped
: once to restore Safari's toolbar, and again to activate the button. With the new setting, this site's page toolbars work
in iOS Safari, and as they do in all other browsers today. As a bonus, the new setting also fixes landscape
of thumbspage image
.
Mar-2020: Amazon Lightsail ⇒ faster site
This site is now jaw-droppingly faster, thanks to its new home on an
VPS. Its former GoDaddy
became frequently and unusably slow, plan upgrades didn't help, and tech support did little but slam the account with bogus fees. The image-size reductions of the next note are still a win; even though large images were not the culprit behind speed issues, it's still not great to push 6M images on people with limited access.
Mar-2020: Images shrunk globally
In light of recent testing on new hosting and broadband providers, the larger images in this site are being shrunk for quicker downloads, using a
. Read the story behind the script
. This change is being applied gradually, but should appear in a browser near you soon. It was long resisted for quality, but smaller images are politer to users with quotas, and demand for the web's bandwidth grows as fast as its capacity.
Nov-2019: In-page navigation controls
Many of this site's larger pages have grown floating
, and a few can now toggle their
(tap those links for demos). These tools are being rolled out to more recent and popular pages first. Both require JavaScript, but former static schemes are still used if JavaScript is disabled. The new
replace numerous static image
, but sacrifice screen space for a subjective improvement in
(the button may cover some content at page bottom); feedback on the tradeoff is
.
(See also the related and later note
)
Subtle thing: the preceding note's new Top
may slightly overlap page-bottom toolbars like
when viewed with most desktop browsers in very small and narrow PC windows, because these browsers reserve extra space for a scrollbar. This can happen on
, Linux, and macOS, though not on macOS when using a touchpad and the General preferences' automatic scrollbar-hiding default (which acts much like a mobile device).
This behavior is also intentional: it allows more space for content in this atypical and cramped context, and can be avoided by simply enlarging your PC browser window. Moreover, always moving Top up would penalize normal cases by obscuring more content; positioning Top based on screen width would require JavaScript and may be inaccurate; and portable toolbar-less designs would require JavaScript for basic site usage—an explicit anti-goal here (that is, until this rule was later relaxed in the name of
).
Update—minimizing scrollbars in Chrome: but if you really want your Top to fly free, at least for Chrome on Windows and Linux (where it's a.k.a. Chromium), it's possible to hide scrollbars and keep Top above toolbars, by setting a special flag like this:
Type chrome://flags in Chrome's top-of-window address box;
Type Overlay Scrollbars in the result page's search box;
Select Enabled in the result page's pulldown list; and
Select Relaunch to restart Chrome and apply the change.
Here's the flag
. You may also have to tweak some mouse or touchpad gestures, but the
allows scrolls with swipes in these Chromes, just like the default for all browsers on macOS, and the norm on mobiles. If there is an equivalent for Firefox or Edge today, it seems an even better kept secret. Update, Mar-2022—ditto for Firefox and Edge: with the advent of overlay scrollbars on Windows 11, both Firefox and Edge now also support minimal scrollbars, which roughly mimic macOS and mobile, don't take up as much UI space, and react to swipe gestures on touch pads and screens. Enable this in the latest versions of these browsers as follows:
Edge—type edge://flags in the URL box, search for overlay scrollbars, enable, and relaunch.
Firefox—type about:config in the URL box, search for win11.scrollbar, and enable. Confusingly, you can also set scrollbar.style of widget.non-native-theme to 1, 2, or 3 to make scrollbars narrower if desired.
The effects are the similar to that in Chrome, minimizing both full-page scrollbars, as well as scrollbars that otherwise appear on page toolbars and tables when windows are too narrow to show full content. This should probably be a platform default today, but at least it's an option. For more tips, search the web for
and
. Chrome still supports its own overlay flag and style at this writing, and may add Windows 11-style bars soon. In the plus column, this site's toolbar also shrunk recently, rendering PC scrollbars less common (and even rare) overall, and you can still simply resize your window to avoid this scrollbar circus in full.
Jun-2019: Privacy statement and changes
This site now has a
. Per that page, this site has also changed its traffic-analytics policy to anonymize IP addresses received by analytics hosts. Analytics is a useful tool that helps focus website work, but IP-address obfuscation is a crucial privacy protection; without it, analytics could be easily misused as a profiling Trojan horse—especially when run by entities that profit from your personal information (yes, that means
).
Mar-2019: Android Chrome—toolbar tip
On one of this site's test devices, Android Chrome just sprouted a bottom-of-screen toolbar which can reduce space for actual
, and make page-bottom toolbars harder to
. It's unclear if this rollout was either broad or intentional, but the effect is obviously subpar. If it ever shows up for you, you can disable the new toolbar and reclaim your phone's
: simply open Chrome, enter chrome://flags in the address bar, search for Chrome Duet in the result, select Disabled in the entry, and restart Chrome. See the Nov-2019 scrollbar tip
for a screenshot of Chrome's flags interface. This setting isn't strictly required for this site, but content should never take a back seat to browsers—as in this Chrome Duet
, where browser controls take up almost as much space as the page. Down in front, Chrome!
Aug-2018: HTTPS, mandatory and pointless
This site now grudgingly uses
, because Google's desktop Chrome browser began rudely branding every page here
. As a result, this site won't work if its SSL certificate grows unusable. This was both pointless and ironic: this site's sole user input is a search term—a datum upon which Google built its financial empire. But who could hate a company that can manage to blend monopoly and hypocrisy in a single step? It's a good thing we have Google to look out for our
. Terrific company, Google. Terrific...
Jun-2018: Edge fixes its URL overlay bug (finally!)
Microsoft's Edge has finally fixed its toolbar-overlay bug.
correctly displays URLs above hovered-over links, unlike
and earlier. Since there's not much Windows 10 users can do to avoid the update that includes the fix, Edge has joined the ranks of desktop browsers usable for this site. Read more about the 3-year
and its
.
Feb-2018: Mobile-friendly conversion
Most of this site is now explicitly
and
, thanks to HTML viewport settings; CSS magic to scale images and scroll toolbars, tables, and code; assorted page redesigns; and the copious free time of the site proprietor. The CSS tricks also provided a temporary workaround for a toolbar-overlay desktop caveat noted below.
Before all this, this website moved to its learning-python.com domain name in
ushering in its "modern" era, and it began broadcasting content in the
when the web was largely HTML text. It's been a wild ride. This site grew up with and marginally prefers to be viewed on
. It has been verified to render well on all desktop browsers in common use
—including Chrome, Firefox, Safari, Opera, Internet Explorer, and Edge. Per the updates
, a desktop-only caveat regarding toolbar overlays on URL
in Edge and Firefox was initially addressed by redesign, and later made moot by fixes in these browsers.
This site can also be read on and has been optimized specifically for
—including Chrome, Safari, Firefox, and Opera. Although nearly all content here is now
, some pages may still be best viewed in
mode, due to this site's wealth of text-oriented material (see also the Safari notes
). There's more on mobile-browser usage
.
Some of the above is orchestrated by the site's
and
files. JavaScript is also used, but is optional, and run only for anonymous
, photo viewers, and in-page navigation if enabled (to see how, view the source of this page, an image
, or a page with navigation
). Mobile-device support employs additional HTML and CSS techniques, per the next section.
This site is readable on all mobile browsers, and as of February 2018 has been heavily tuned to support smaller screens
. Mobile viewport settings alone worsened as many aspects as they improved, but usability issues were fixed with extra design changes, including:
That said, despite the redesign, a few parts of this site are still less than ideal on mobile devices, and others may never be optimized for mobile use. Code listings, for example, may require swipes to view in full; the class
is legacy desktop content generated by Word that cannot be easily changed; and the HTML user guides and screenshot galleries of desktop-only
here have been converted, but for
.
In addition, given the volume of content here—most of which is text based and some of which dates back to the
—landscape orientation may work better for some pages on smaller
. Naturally, performance and preference may vary per device, browser, and user, and some browsers have reading-mode converters and text-scaling settings that may further improve user experience.
Like them or not, smaller screens are convenient but inherently
; the goal here is to accommodate by enhanced style, not to pander by reduced substance. This site's
is currently 70–75% desktop browsers (depending on when it's checked), and its main reason for being is to support readers of books and learners of code. If you're not interested in reading words, well, how did you ever get this far?...
