This 'blog has yet to fully accommodate mobile computing. Images in entries have usually had an absolute width of 450 pixels, which made sense when displays were 640 pixels or more wide (and seldom more than 1920 pixels wide), but is now too wide for some devices.

I've been occasionally patching old entries to fix this problem. With IMG and IFRAME elements, the trick is to add

to the string-value of the style attribute, where R is the ratio of the height divided by the width, multiplied by 100. For example, if the image is 450 pixels wide and 900 pixels tall, then

Just what happens when R is not an integer seems to be browser-dependent.

An example of an IMG element could be

<img src="wp-content/uploads/2020/11/A6_corrected.png" alt="[image of formula]" width="449" height="92" style="display: block ; margin-left: auto ; margin-right: auto ; margin-top: 1em ; margin-bottom: 1em ; border: none ; width: 26.4em ; height: 5.4em ; max-width: 100% ; max-height: 20.5vw ;" />

When BitChute gives code to embed a video, it looks something like this:

<iframe width="640" height="360" scrolling="no" frameborder="0" style="border: none;" src="https://www.bitchute.com/embed/QKOTRHgzsuQE/"></iframe>

It should look something like this:

<iframe width="640" height="360" scrolling="no" frameborder="0" style="border: none ; max-width: 100% ; max-height: 56.25vw ;" src="https://www.bitchute.com/embed/QKOTRHgzsuQE/"></iframe>

I've made some changes to the code that determines the presentation of this 'blog, in order to make it more useable with devices such as cellular phone sets and tablets. Some visitors will observe substantial improvement.

There will probably be more changes to come, and during my attempts to effect such changes, the 'blog may occasionally behave dysfunctionally. If you observe a persistent problem in presentation, even if one long-standing, then please contact me, being as precise as you can about which device, operating system. and browser you use.

I frequently run across the problem of websites whose coders silently presume that all their visitors of interest have Javascript enabled on their browsers. Yester-day, I found this presumption affecting a page of someone whom I know (at least in passing), which prompts me to write this entry. (The person in question did not generate the code, but could suffer economic damage from its flaw.)

The reason that one should not presume that Javascript is enabled on the browsers of all visitors is that Javascript is itself a recurring source of security problems. Careful users therefore enable Javascript only for sites that they trust; very careful users enable Javascript only for sites that they trust and even then only on an as-needed basis; and paranoid users just won't enable Javascript ever. Now, in theory, the only visitors who might interest some site designers would be careless users, but we should look askance at those designers and at their sites.

(And trusting a site shouldn't be merely a matter of trusting the competence and good will of the owner of the domain. Unless that owner is also owner of the server that hosts the domain, one is also trusting the party from whom the site owner leases hosting. In the past, some of my sites have been cracked by way of vulnerabilities of my host.)

A designer cannot infer that, if-and-when his or her site doesn't work because Javascript is not enabled, the visitor will reälize that Javascript needs to be enabled; many problems can produce the same symptoms. Most of the time that sites don't work with Javascript disabled, they still don't work with it enabled. Further, the party disabling Javascript on a browser might be different from the present user; the present user might have only vague ideas about how web pages work. (An IT technician might disable Javascript for most browsers of users at some corporate site. Some of those users, perhaps very proficient in some areas but not with IT, may be tasked with finding products for the corporation.)

The working assumption should typically be that Javascript is not enabled, as this assumption will not be actively hurtful when Javascript is enabled, whereäs the opposite assumption will be actively hurtful when Javascript is not enabled.

The noscript element of HTML contains elements or content to be used exactly and only if scripting has been disabled. That makes it well suited to for announcements that a page will work better if Javascript is enabled

<noscript><p class="alert">This page will provide greater functionality if Javascript is enabled!</p></noscript>

or not at all if it is not enabled.

<noscript><p class="alert">This page requires Javascript!</p></noscript>

(It is possible to put the noscript element to other uses.) So a presumption that Javascript is enabled certainly need not be silent.

However, in many cases, the effect got with Javascript isn't worth badgering the visitor to enable Javascript, and the page could be coded (with or without use of the noscript element) so that it still worked well without Javascript. In other cases, the same effects or very nearly the same effects could be got without any use of Javascript; a great deal that is done with Javascript could instead be done with CSS.