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.

Since some time in April, a bug in the software at LiveJournal.com has kept me from logging into it, and from logging into other sites using that same software, with my OpenID. To-day I received an admission that the problem hasn't been worked and is not likely to be worked any time soon. If you're an LJ friend who posts nothing but Friends-only or otherwise filtered entries, then you might as well write me off.

More generally, my experience filing bug reports has not been very happy. I've recently reported my problems with the formula editor of OpenOffice.

Rather longer ago than that, I noted how WordPress, after letting two dead-lines slip, had just un-scheduled a bug-fix by setting a milestone of Future Release. This morning, I discovered that a spurious claim that the bug was not manifest had caused the report to be closed about three weeks ago. After I was compelled to jump through some otherwise superfluous hoops, it was plainly established that WordPress indeed had exactly the bug that I'd reported (on 29 April 2008), and that, from my initial description, the point of failure could have been quickly found and fixed. A patch was filed, and I thought that the fix would be scheduled for the next bug-fixing release (3.1.4 or 3.2.0, whichever came first), but then the milestone was instead re-set for Future Release. It might still be fixed in the next release, but there is simply no assurance of that. (I can hack my own installation, of course.)

While someone somewhere has surely written a nice clean, unified explanation on associating favicons, Apple Touch icons, and site thumbnail images with WordPress 'blogs, I've not seen it; and, when it comes to supporting site thumbnail images in WordPress themes, I have seen an awful lot of discussion that is unclear, and PHP code that is inflexible, breakable, or already broken. Perhaps I'm now about to contribute to the problem, but I'm here going to make my own attempt at discussion.

[This entry was written at the suggestion of the Woman of Interest, but she's really not to blame for how it turned-out.]

FavIcons, Apple Touch Icons, and Site Thumbnail Images

First, I'll try to explain the rôles and invocations of these images without peculiar reference to WordPress or to PHP.

Working Code and How to Use It

I think that a great many people are just going to want code that they can drop into a theme, and a practical explanation of how to use that code, so I'll provide such code, with an explanation of how to use it.

PHP and WordPress Coding Issues

A few hardy or lost souls are going to want to know what motivated that code, how it actually does what it does, or what I see might be done differently. (Some of them might do a rather better job than have I.) For those readers, I have prepared a very boring discussion.

I don't much like being limited to using the characters found on my key-board or in the ASCII set.

In some contexts, the resolution is to enter an escape sequence, such as those for HTML or those for Java. In other contexts, the best that I can do is to copy-and-paste the character from somewhere.

With that in mind, I cobbled-together a utility qua webpage for my own purposes, character.php. It's a PHP page because it uses server-side code to generate a table on-the-fly of Unicode characters from U+0020 through U+07FF. (Most of these characters will not be well rendered on most systems, though.) Before that table, it has an assemblage of characters that I frequently want (or that I see as otherwise belonging amongst such characters), such as Greek characters and Latin characters with diacritical marks. And, before that assemblage, it has a couple of JavaScript applets; the first of which converts amongst hexadecimal, characters, and decimal; the second of which converts ordinary strings into strings of HTML escape sequences.

Anyway, I began creäting the page with my own use in mind, but I've extended it a bit to make it more useful to others. I might not implement suggested changes, but I'd certainly consider them.

As previously noted, back at the end of April 2008, when WordPress version 2.5.1 was the latest stable release, I reported a bug in the handling of nested q[uotation] elements by WordPress. The bug was scheduled to be fixed with version 2.7. Then, as the release of version 2.7 approached, the bug-fix was rescheduled for version 2.9. When I discovered this rescheduling, I wrote

And there seems no assurance that, about half-a-year from now, that target won’t be reset to version 3.1.

Well, that was actually more than 11 months ago, but two days ago, with version 2.9 in beta, the fix was rescheduled for Future Release, which is to say that it really isn't scheduled at all.

I don't really want to dive into the code to fix the error myself. For one thing, I've been thinking of writing an independent software package that would contain some of the same functionality as that of the package in which the bug resides, and I neither want to license the code of someone else nor face challenge as having perhaps cribbed said code. Further, I'd expect to have to invest significant effort to understand the code before I could properly patch it, and might have no use for the understanding after the patch.

WordPress version 2.7 has been released.

About eight months ago, when 2.51 was new, I reported a bug that had been giving me grief, a mishandling of the HTML <q> element. WordPress.org automatically set the target of fixing this bug by version 2.7 — which, frankly, to me seemed rather unambitious. It's one thing not to expect to fix a bug in the very next bug-fix release, quite another to put it off for two minor versions.

In any case, I've been looking forward to version 2.7. Now it's out… …and the bug is not fixed. In fact, I've learned that about two months ago, the target was changed to fixing the bug by version 2.9, another two minor versions away. And there seems no assurance that, about half-a-year from now, that target won't be reset to version 3.1.

Best practice in HTML is to put quotations into Q[uotation] elements, so that the mark-up looks like this:

Sam growled <q>I asked him, and he said <q>I swear on me mother's grave!</q></q>

rather than like this:

Sam growled “I asked him, and he said ‘I swear on me mother's grave!’”

Note that it is possible to have one Q[uotation] element inside of another — a good style-sheet will handle that.

Unfortunately, the WordPress editor seems to have been written by a programmer who believes that Q[uotation] elements must not nest, and the editor tries to fix things when it encounters nesting, by closing the outer element when it comes to the inner element. In the case of my previous entry, it then discarded the original closing </q> tag of the outer element, but (who knows why?) added an extra </div> at the end of the entry. The appearance of the whole page went to H_ll.

I fixed things by by-passing the WordPress software, and editing the 'blog's underlying dB with phpMyAdmin.

I've filed a bug report.

(I still need to arrive at a good specification of the list-bug that plagues my entry on installing Open Office.)

I was looking at the version of Installing OpenOffice 2.4 under Red Hat Enterprise Linux 5.x that is delivered for the LiveJournal feed of this 'blog, and saw that it has a bunch of unmatched closing p[aragraph] tags that simply aren't in the entry as I marked it up. Indeed, I don't think that I used p[aragraph] elements at all in that entry.

Looking at the entry that is delivered to visitors to my site, I see <p> and </p> appearing various places that I haven't put them. But they don't appear when I attempt to use the WordPress editor to remove them, nor are they in the entry as it appears in the raw dB. The problem, then, is in the preprocessing by WordPress.

I s'pose that I need to explore the problem and then file a bug report with WordPress.org.