CSS3: Match parameter contents with the :not pseudoclass

It's possible to match parameter contents in the :not (negation) pseudoclass used in Cascading Style Sheets Level 3 —

A:not([href*="subdomain.domain.tld"]) {color:blue;}

All links are colored blue except those targeting anything that contains subdomain.domain.tld .

The asterisk * before the equals sign = means, that the match is any parameter value inside double quotes (quotes may be optional or pursuant to syntax) — in this case, links (A) that contain subdomain.domain.tld — to which a particular CSS rule is not applied using :not([]). Here, link contents can be a variation of
https://subdomain.domain.tld/directory/folder/file.html

More complex use of the :not pseudoclass:

A[TARGET="_blank"]:not([href*="subdomain.domain.tld"]) SPAN {color:yellow}

All SPAN elements inside links (A) with TARGET="_blank" (these typically open new windows) are colored yellow; except those, where link address contents match subdomain.domain.tld —

Approximation in HTML:

<A HREF="https://domain.tld" TARGET="_blank"><SPAN>Text in this link's SPAN element is colored yellow.</SPAN></A>

<A HREF="https://subdomain.domain.tld/folder/file.html" TARGET="_blank"><SPAN>Text in this link's SPAN element is not colored yellow, because it matches subdomain.domain.tld .</SPAN></A>

The W3C CSS3 spec itself is rather fuzzy about all this, but after some experimenting, I got a satisfactory result with a userstyle.

And if it works in a modern version of Firefox, it should work in other browsers, too.

Additional notes

If you want to match by the existence of a parameter inside an element, such as ENABLED inside <BUTTON>, or use a simple selector, such as a .classSelector or #idSelector — then you have to do without square brackets []:

A:not(TITLE) {}
   /* all links that do not contain TITLE
      (without tooltips on link hover) */

BUTTON:not(DISABLED) {}
   /* all buttons that are enabled */

DIV:not(.frontpage) {}
   /* all DIV elements not with class="frontpage" */

DIV:not(#articleContents) {}
   /* all DIV elements not with id="articleContents" */

...and so on.

Other selector matching rules apply, too.

Errata

Strangely enough, I found it impossible to insert or nest a negation pseudoclass into a series of combining selectors (with Firefox 39.0.3):

DIV A:not([href*="subdomain.domain"]) SPAN {parameter:value;}

— where a multi-selector involving SPAN elements inside links without subdomain.domain and inside DIV elements would not work.

So, in a ruleset, the negation pseudoclass must be listed first, and can include child selectors, but cannot be a child selector itself.

Rationale

As it was, this post was borne out of a need in a userstyle (made to improve the functionality of one website) to give all links that open in new windows using TARGET="_blank" a certain visible background, which was a yellow gradient, so that the reader could decide how they should open those links.

The exception to that rule was to avoid setting that background to weather content, as it was based on elements for which the website applied its own background images. Incidentally, these backgrounds were dynamically applied to child elements inside links with TARGET="_blank", and setting one's custom background replaced the background images, and weather information was thus lost.

As the links resolved to the website's weather subsite, then excluding those required matching the weather-themed subdomain, as in weather.website.tld and the links' SPAN, B, and other child elements that already contained backgrounds.

Of course, I could have specifically targeted several large and content-heavy parent DIV elements that did not contain weather content, but this would certainly have required involving way more than one such DIV element.

I could have also tried using a negation pseudoclass with a simple selector, as in:

DIV:not(.thisclass) A[TARGET="_blank"] {background:gradient(to left, yellow 0px...)}

... and maybe this would have worked, too. — But then I would have risked missing several non-weather links that did open in new windows, and as such, these would in turn have remained potentially invisible.

Therefore I found it more prudent to use link-based selectors.

---

Article Errata:
Corrected terminology of :not being a pseudoclass instead of a pseudoelement.

Absolute positioning of content in a containing block

A less formal alternative title would be "Placing content from the middle of a box into a sidebar to the edge of a containing block"

Context

The problem first occurred when I tried to create a user style for a login page to accomodate small screens (Yes, there are people who use small screens).

The main problem was that I could not change the structure of the not-so-well designed page, so I had to resort to some unorthodox uses of formatting in CSS. Later it turned out ot have some interesting uses in a sister blog.

The basic [formatting] concept behind this is taking content out of normal flow, placing it as a sidebar into the top right edge of the container block, and then making sure that other content (mostly visible text) will then flow around the sidebar box.

While it may sound simple just like that, then implementing a working solution for the first time proved more difficult. The solution that I found out does work, but still contains some caveats. More about it later and below.

In-depth

What does not work

First off, just floating the box to the right is pointless, because the box is positioned according to normal flow and is floated where it's structurally positioned in the page (or text). It is then adjacent to that content which only follows the box in the page structure.

Adding a negative top margin is just as impractical, because it will never be accurate relative to the sidebar's position, as the position of the sidebar still depends on how much space is taken up by preceding objects or text, since relative renderings are always different, depending on fonts, rendering engines and zoom levels.

If you're modifying your own content, then putting the box before the content that initially preceded it defeats the purpose of normal text flow (as seen in Lynx).

The solution

Mostly assuming that the containing block and inner blocks are <DIV> elements, which I so dislike, because they are severely overused.

The points are here in a hierarchically continuous order, so as to present the logic and reasons behind it.

• The containing block,
  which is to enclose the sidebar and content that should surround it:
  Set its position to relative — This will keep absolutely positioned blocks inside the containing block; otherwise all absolutely positioned blocks will be taken out of all flow and will be (absolutely) positioned relative either to any preceding relatively positioned block in the page hierarchy, or the viewport, which is the topmost block.
• The sidebar's position must be set to absolute, with most important parametres set like this:
  
  <DIV STYLE="position:absolute; top:0px; right:0px; width:234px">Textual content<DIV>
  

  ^ top:0px and right:0px will place the sidebar box to the top right (to right of main content), where position is calculated from the containing block's top and right edges; width:234px — Here you can specify your own width for the absolutely positioned box.

• And finally, the tricky part — How to make sure that content or text surrounding the sidebar will show next to the sidebar without all of parts of it staying hidden under the sidebar?
  
  Well, my solution was to place the that content (which precedes the sidebar and is innards) into a relatively positioned DIV& box, with its right margin approximately the amount of the sidebar's width. This ensures that text or content inside that DIV won't stay under the sidebar.
  
  If the sidebar is long enough to encompass much of the content that follows, then that content should also be encased in a DIV with similar parametres: relative positioning and same margins.
  
  Caveats:
  • If much of the content left of the sidebar is text, then its flow is limited to the squares of DIV boxes (there must be at least two of them). Normally flowing text could then start well after the sidebar and DIV boxes end.
    
    Mitigating effects
    One way to mitigate this without creating separate DIVs and their left (or right) margins is to create a ghost DIV with same size properties as the sidebar floated right just under the absolutely positioned sidebar. This has better chances of taking effect if the sidebar's height and width are fixed and that the content is controlled server-side.
    
    Yes, the "ghost" DIV can contain about the same text, if there's a desire for that ghost DIV to follow the size of the primary DIV (think differences in fonts and zoom levels), but this then may defeat the purpose of having that text in the ghost sidebar, because it would be duplicating. Oh well, solutions can be made both with JavaScript and CSS to make sure this text doesn't appear twice in a text-only or very plain browser (think Lynx).
    
    Otherwise I was thinking of :before and :after pseudoelements, or of a way to insert a client-side Greasemonkey script.
    
    This is now the point where one can play around with various options.
    
  • I found another problem when editing text here in Blogger, where the sidebar height was greater than text next to it, so the sidebar, given that it was absolutely positioned, overlapped past the post tools area. In that sense it's a good thing to try out the size of the sidebar in the DOM Inspector, which allows client-side visual editing of webpage elements under inspection.
    
    One way to mitigate this would be wrapping all of the affected content, including some preceding the sidebar (where it visually starts) in a DIV and specifying a height greater than the height of the sidebar. The height of the DIV should then allow for some hypothetical differences in size.
  
  

This out-of-order sidebar solution works in Firefox 1.0 (Mozilla 1.7.xx, preferably SeaMonkey 1.1.19 or K-Meleon 1.5.4) and newer. It does not work in Internet Explorer 7 (or older), so a workaround must be in place, if there's a large IE-based audience in mind. It should probably work in Internet Explorer 8 or newer.

Putting stuff before a counter with CSS and associated caveats

I thought this too important to be passed up, so here's only a very rough draft of what I discovered. And because I was only revisiting this subject right about now, I have yet to get my own head around all this, with more detailed explanations.
(Blogger had nasty issues with updating their software, so a number of blogs were in read-only mode and so instead of writing this up I was occupied with other things. The good thing is that Blogger have been very responsive in addressing the posting outage.)

When tallying personal data and opinions for what was ostensibly a list of items in a text file, I wanted to find out how in an ordered HTML list (a numbered list with <OL> tags) I'd be able to use Cascading Style Sheets (CSS) to place some special items before counters (usually numbers, but CSS 2 standard has expanded counters to be much more) as markers of some sort.

The main point was to make a more informative and interesting list... Well, yes, but this turned out to be a far more difficult exercise than I first thought.

For an intro, the following describes the differences in rendering between Mozilla Firefox 2 and Mozilla Firefox 3+. Because these browsers use the Gecko rendering engine, which is used by other browsers, then here's also a quick browser side-by-side of the rendering engine's branches:

Gecko 1.7	Gecko 1.8.1	Gecko 1.9 and newer
Mozilla Firefox 1.0	Mozilla Firefox/IceWeasel 2	Mozilla Firefox/IceWeasel 3+
Mozilla Application Suite 1.7	SeaMonkey 1.1	SeaMonkey 2+
	K-Meleon 1.5	K-Meleon 1.6+

What follows is example CSS code with some comments. I haven't yet had all the time to describe everything, but bear in mind the lede.

OL.Eurovisioon {counter-reset:item; list-style-position:outside}

OL.Eurovisioon LI {display:block;}

/* • display:block ^ loses the browser's automatic numbering;
• The items must be displayed as block, so as to make sure that the later width attribute applies. */

OL.Eurovisioon LI:before {float:left; content:'miskitekst\ ' counter(item) '.'; counter-increment:item; border:solid 1px gray; padding-right:5px; width:82px; text-align:right; line-height:1.1em; color:navy; white-space:nowrap} _{/* these work... */}

/* ^ • Floating them left makes sure that the items are displayed like in a standard ordered list;
• item must be inside counter(), item is also specified for counter-increment;
• text-align:right aligns numbered counters right and so makes it more list-like again;
• white-space:nowrap makes sure that when increasing text size, text inside blocks wouldn't wrap and add in height and take away from the structure.

Caveats:
Once the items are all displayed as text-block or inline, the width attribute does not apply anymore. Displaying as block and floating to right works in Firefox 4 (I'm also assuming 3.0+), but not in SeaMonkey 1.1 and anything with the Gecko 1.8.1 engine (see the above table) and the caveat applies to all older browsers.). Setting the display to text-block or inline fixes the issues in SeaMonkey 1.1, only that setting width attributes does not work then. */

OL.Eurovisioon > LI.plus:before {width:82px; content:'\ sisu\ ' counter(item) '.\ '; text-align:right; color:blue} _{/* somehow works */}

OL.Eurovisioon > LI.plus {list-style-position:outside}
^ Is this really necessary?

Moreover, the list already contains tabular data; including informative content with :before or :after pseudo-classes means that this data won't be indexed and may be lost to search engines. Non-graphical and older browsers won't be able to see such content.

I, of course, thought that I'd never see the day when my own fancy CSS implementation would not be visible with something like SeaMonkey 1.1.19.

The correct rendering is supported by Mozilla Firefox and IceWeasel 3 (probably since 3.0), SeaMonkey 2, Google Chrome (Version 11 does, so I'm assuming a host of earlier versions do, too), and the latest Konqueror, Apple, and Opera fare. Internet Explorer 7 does not support this. Bleh.

So here's the example list:

1. tekst
2. teine tekst
3. kolmas tekst
4. neljas tekst

with corresponding code in HTML:

<OL CLASS=Eurovisioon>
<LI>tekst</LI>
<LI CLASS=plus>teine tekst</LI>
<LI>kolmas tekst</LI>
<LI>neljas tekst</LI>
</OL>

So long I still have to use Mozilla Firefox 1.0, I must still use a simple HTML table. At least the advantage is that most browsers will be able to see the content. The table in question is here.

As the information was laid out in a text file, it nevertheless turned out to be tabular data, which was actually much simpler to organise into a table, rather than implement complex CSS for the same.

Collapsing elements in Firefox 1.0

As I was perusing Yahoo Mail Classic in Mozilla Firefox 1.0, it turned out that there was a linked block element half-blocking the sign-out link at the top of the page and in May this year, those links stopped being underlined when hovered over — this made targeting the pointer too difficult to click on the sign-out link. If I click on that block element, it will jump to a position on the page, then, somehow the block element probably moves and probably frees up the space above the sign-out link... Or whatever.

Turned out that the culprit was an invisible non-collapsed block that contained a "Skip to conent" link, which was meant for browsers like Lynx, Links, Elinks, Netscape 4.x, and other older fare (Lynx is still maintained :). This is really the fault of site coders, who instead of specifying display:none in the element's style, only specified visibility:none. The former would have collapsed the whole element, the latter only makes it invisible, but still usable and visually existent in the document structure.

If positioning is important, then one design solution is to specify a low z-index for the invisible DIV element and a correspondingly higher z-index for code that contains links (an unordered list). In CSS, z-index specifies how elements are layered with respect to each other: a higher value means that an element is above (or in front of) all other elements and a lower value (if somewhere is a higher value specified) means that the element is below, or behind higher-valued elements.

First I tried the Adblock Plus (ABP) extension, but that didn't work: ABP 0.7.0.2 is the last version for Firefox 1.0, but lacks functionality to collapse/hide elements by their id. Only the next version, 0.7.1, starts supporting this. I've written about it previously.

As I was looking for a solution, the Greasemonkey extension caught my fancy. The last to support Firefox 1.0 is 0.5.3.

Version 0.5.3 is also the last one of Greasemonkey to install on SeaMonkey 1.1, but it doesn't work.

The solution is to first install xSidebar (If the current stable versions won't want to install, then version 1.0.1 or 1.0.2 might install properly). Then on the back of xSidebar a modified Greasemonkey extension can be installed. So for SeaMonkey 1.1, Greasemonkey 0.8.2 mod is the order of the day. Note that if you have Adblock Plus 1.0.2 installed, its toolbar button will vanish. But no worries: You can turn on the Adblock Plus status bar icon from Tools > Adblock Plus Preferences...

Greasemonkey is a powerful tool to change the look and functionality of online sites and web pages client-side, but alas, it is not very easy and requires knowledge of HTML, JavaScript and CSS.

There are many instructions online on how to incorporate custom JavaScript and CSS snippets into your browser equippped with Greasemonkey and how to specify server whitelists and blacklists. I might introduce the same instructions here or put them up somewhere else.

While I thought I just had the solution, it then turned out that the block element was only equipped with a class parameter and no ID. I had also learned that only recent and modern versions of Greasemonkey now support the JavaScript getElementbyClass functionality, but I only have an outdated version.

Well, no matter: Greasemonkey 0.5.3 supports getElementbyId, but that really is not the most important thing, because Greasemonkey also allows injecting snippets of Cascading Style Sheets with JavaScript. And CSS is power.

Yes, while the DIV element did not have the ID parameter in it, it still had the CLASS parameter specified and the solution looks like this:

document.styleSheets[0].insertRule('A[class~=yucs-skipto-search] {display:none}', 0);

/* ^ • A is the linked element;
• Square brackets in the selector are used for conditional matching in the form of ELEMENT[attribute=value] — In this case, the {display:none} CSS block applies when yucs-skipto-search is found anywhere in an A tag's class attribute value (which the next point is about);
• ~= means that the pattern for the element attribute may be any matching part inside class, because when I looked at the source, the class parameter contained more than just yucs-skipto-search.
• display:none collapses the element. */

document.styleSheets[0].insertRule('A[target=_top]:hover {text-decoration:underline !important;}', 0);

/* ^ In this line, Any hovered link tag A where the target parameter exactly contains _top must be underlined when hovered over. Note that instead of ~= for any matching part inside A[TARGET ]there is a single equals sign = for an exact match. !important overrides anything provided previously and makes sure that the these links are underlined when hovered over. */

So much for now.

Adding formatting to CSS generated content

This solution (or workaround, if you like) came out of a need to write text visible only for modern browsers.

I have a case, where such text would point out a formatting feature containing further information in <ACRONYM> tags, only that severely out-of-date and text-only browsers do not support the dotted underline and border properties, so help text for these browsers was not necessary. I wouldn't use JavaScript (which uses document.write) and there are websites like WordPress (IINM) that only allow editing CSS files and may forbid JavaScript.

The CSS 2.1 specification has it that it's possible to create generated content before or after an element, using :before and :after pseudo-elements, respectively.

The best explanation about how it works is in the CSS2 technical recommendation at W3.

The difficult part is in how to format text within the content: property.

Well, there are two ways that work and a third way that is a workaround. The two ways are well-documented in the W3 technical recommendation (see above link), where it's possible to specify attributes with first-letter and first-line (for longer texts within content) pseudo-elements.

The Third Way

Specifying formatting for bits of text within the content: property is impossible, so the solution is to create one or more rulesets of :before or :after pseudo-elements with similar declaration blocks, wherein some rulesets' declarations are different.

In HTML, write the following snippets of code:

<SPAN CLASS=text></SPAN><SPAN CLASS=dotted></SPAN><SPAN CLASS=bits></SPAN> and so on...

In CSS, example code shows the following:

.text:after {content:'^ Mouse over text with\ ';}
.dotted:after {content:'dotted underlines'; border-bottom:dotted 1px; border-bottom-color:inherit;}
.bits:after {content:'\ for more infobits'}
/* ^ Use the backslash \ to escape special characters, including a space (or it won't be shown). */

The result:

Browsers, which don't support CSS :before and :after pseudo-elements, won't see this. ^

The result is used here in a previous blog post. The example text snipped was put in place of a paragraph break, but since the Lynx browser wouldn't create a paragraph break inside a list with <P></P> or <BR><BR>, or instead there was more space added in modern browsers with variants that included a non-breaking space  , then the best solution was to wrap above HTML code within <DIV> tags and add a non-breaking space —

<DIV>&nbsp;<SPAN CLASS=text></SPAN></DIV>

Characteristics

The most interesting and equally obscure characteristic with CSS generated content is, that generated text cannot be directly copied — even when selecting a normal area that wraps around generated content, then only the wraparound selection is pasted.

While this may be useful to wonks interested about protecting original content, then it's still a chore to implement, and advanced users would still be adept at copying text from near the source (unless obfuscated). The technique is similar to mechanisms that disable direct text copying in advanced document files, like PDF, but with the difference in sophistication: PDF files have encryption and other features.

The (dubious) advantage is, that direct copying is disabled; and the disadvantage is, that a number of browsers don't support these pseudo-classes. And not just older (Netscape 4) and niche browsers (Lynx, Links, Elinks), but even Internet Explorer 7 doesn't.

16.12.2015. Update:

I recently wanted to add newlines to generated content, but after several turns of trial-and-error with \A in content:, I turned to a search engine and found about the best blog post by Chee Aun that describes the issue in detail.

The solution with Firefox is to specify white-space:pre-wrap — This preserves both wrapping and newlines.

Somehow installing, configuring, and using NoScript in K-Meleon 1.5 via Wine

I am assuming that you probably already know how to use Wine and know your way around the computer.

The conditions: Knoppix 4.0.2, because it runs passably with 128 Mb of RAM, in a situation where no swap space is available. This version of Knoppix has a really outdated version of Wine, which makes it difficult to use Windows programs there. There may be people stuck with either that version of Knoppix or that old version of Wine. At least this post provides a case study, which I hope could be of some interest.

The only reasonable place I could find NoScript for K-Meleon 1.5.4 is from extensions.geckozone.org/KMES-NoScriptEn. The version is 1.7.8.0 and it's from 17.06.2008 (that's 2 and 3/4 years old as of April 2011).

First off, change installer's .exe file rights for it to be an executable. Like this from the command line:

chmod u+x "K-Ext(1.1-1.5-1.6)_NoScript(1.7.8.0).exe"
^ u = for current user; + = add/enable; x = executing;
The filename is wrapped in double quotes, because it contains parentheses "()".

In my case, the first round of installation didn't work. Later I specified this target install directory:

z:\mnt\hda1\Program Files\K-Meleon
^ can't remember if I specified an upper- or lowercase letter z

and installation worked after that.

K-Meleon should not be running during installation, so run it after installation.

27.04.2011.–: After a relatively quick-and-dirty article which turned out to be far more specific than originally anticipated and still quick-and-dirty, I've updated the following with information which will make K-Meleon slightly easier to use as it is, with what the setup is and all...

When running K-Meleon through Wine in Knoppix 4.0.2 (remember that it's from 2005 and very outdated) and when you're stuck with such a set-up:

• The NoScript button menu can be used with a mouse by right-clicking on the NoScript button and holding the pointer device button down and dragging the cursor to the necessary command (shortcut menus will otherwise turn off after right-clicking on an item and hovering a mouse cursor over its menu; I've seen this in TWM, don't know how it works in other window managers).
  Other ways:
  • Click on the NoScript button, then use menu hotkeys (underlined) to perform a function;
  • or consider dragging the pointer through the NoScript menu via the main Tools menu.
• Saving configuration changes in the NoScript Options window does not work, because it's impossible to save settings by clicking the OK button, but you can otherwise close the window (saving options may work with newer versions of Wine; haven't tried this myself).
  Workarounds:
  
  • Configuring NoScript is possible only at about:config for settings (use the noscript text pattern in the about:config search bar to get NoScript-specific settings);
  • ^ Consider removing some default domains there from the noscript.default string;
• Worse, the NoScript menu in K-Meleon (at least in the given configuration and set-up) won't show domain names in its menu (Shock! Horror!).
  • Now, the whitelist, which is not shown in about:blank, is only configurable in prefs.js at the local K-Meleon profile folder on the hard drive (from where K-Meleon is run). If you don't know what the prefs.js location of the current profile is, open Preferences, go to "Privacy & Security" preference category, click on the Cache tab and see the "Cache Folder:" entry, which shows the location of the current profile folder.
    An example location is here:
    

    "/mnt/hda1/Program Files/K-Meleon/Profiles/g1bb3r1sh.default"

    So, edit the prefs.js file with a text editor at this line:
     
    user_pref("capability.policy.maonoscript.sites","place.doma.in nam.es here.com in.alphabetic.al ord.er.com ea.ch doma.in na.me separated.wi.th a.space.com and.do not.break.the.li.ne");
     
    Make sure just in case that K-Meleon is not running when editing the file, because if you've saved the file and then exit K-Meleon, then K-Meleon is highly likely to overwrite your changes.
    13.09.2011.

    Given that I had been using K-Meleon like that for a longer while, I created a menu item in the TWM window manager, where I could directly open the prefs.js file from the menu.
  • Alternately, adding sites to whitelists works from the menu (see above), but since the above configuration does not make it possible for the K-Meleon URL bar to function and display addresses, then a user is limited to knowing the site domain and web page address in the following ways:
  • In K-Meleon, the tab bar is typically shown by default, so it should be enough to hover the mouse cursor over a page's tab button: This displays the tool tip, which then shows the site/page title and its partial address.
  • A user might know the site's domain name, if they've entered it themselves (because of limitations, entering a URL goes through editing bookmarks and accessing a bookmark set up for just that).
    A user can specify that only top-level domain names are added, by setting this in NoScript preferences through about:config, only that the whole point of NoScript to me is the fine-grained way in which some subdomains can be whitelisted, so that disruptive ones are duly excluded. Unfortunately, not directly seeing a site's domain name in the URL bar has security implications, including the fact that the non-functioning URL bar doesn't change color when visiting a secure site, though a bottom-right status bar indicator should work. Preferably, only safe sites should be visited. (Avoid clicking e-mail links, if you know they're dubious, but this requires at least some user education and this is where NoScript is useful. There is nevertheless a greater amount of security in running K-Meleon equipped with NoScript, no matter how limited it is, through Wine in Linux than in Windows 9x);
  • Some necessary domain names pulled by a page from (a) differently-named domain/s to fetch scripts and/or stylesheets across sites and subdomains are not displayed anyway (not even in the NoScript menu), so there is no direct way of learning which other domains must be allowed for scripting.
  • Consider disabling NoScript for the duration of the session, if you're using a service which requires logging in and if it's been impossible to learn what are the exact outside domains with necessary scripts.
  • The third option is to import domain names from other NoScript settings in other prefs.js files. This actually works. But what if using a new service that users a non-primary domain name for scripting? Or what if an existing service sometimes changes its subdomains?

Older Flashblock and NoScript for older Firefox and SeaMonkey versions

If you're ever stuck with an older computer and a Live CD (an older version of Knoppix) or an older computer with Windows 95/98/Me and an older version of Firefox or Mozilla or SeaMonkey, then useful extensions (add-ons, but not plugins) for these still exist and can be installed.

(If installing them from a website won't work, download an .xpi separately and install from local storage.)

The most recent version of NoScript to support —

• Mozilla Firefox 1.0.x (in my case): 1.1.4.7 (XPI)

01.02.2011.

Noscript caveat:
Version 1.1.4.7 does not block META redirects within <NOSCRIPT> elements in HTML. — I saw this with one Russian social networking site.

The noscript.forbidMetaRefresh boolean (set to true) in about:config only applies to refresh elements outside <NOSCRIPT> tags.

Turned out that the functionality blocking META-refresh-in-<NOSCRIPT>-tags was first introduced with version 1.1.4.8RC1 of NoScript, which only supports Mozilla Firefox 1.5 or newer.

02.02.2011.

Multiple Mozilla Firefox 1.0 caveats with the modern Internet:

• Firefox 1.0 is so outdated that only "Basic", "Classic" and "Lite" versions of various popular services work. Remember to place these services' old versions' addresses in the Bookmarks menu or toolbar.
• Windows Live sign-in doesn't work at all.
• Nowadays' popular Websites use scripts and AJAX so intensively that NoScript is invaluable in suppressing unnecessary scripts that may hog system resources (also applies to Firefox 2 and SeaMonkey 1.x).

Windows 95	Firefox 1.5–1.5.0.3:	NoScript 1.5.2 (XPI)
	Firefox 1.5.0.4:	NoScript 1.8.1.3
	Firefox 1.5–	NoScript 1.10	SeaMonkey 1.1.17 –1.1.19
Windows 98/Me	Firefox 2.0.0.20
28.01.2016.
Windows 2000	Firefox 12.0	NoScript 2.9.0.1rc1	SeaMonkey 2.9.1

NoScript versions page

I know I haven't posted much about Flashblock, but it can be had from flashblock.mozdev.org

The legacy options presented in this post pertain to situations where it's impossible to upgrade to SeaMonkey 1.1.19, such as an out of date Live CD (and what if someone has only that?).

Yet when it comes to a Windows 9x operating system, then it's best to install or upgrade to SeaMonkey 1.1.19. Reasons for this in one of my previous posts.