A small History of browser support for CSS variables

Firefox support for CSS variables began with version 29 (with the var- prefix, released 29.04.2014) and as an option to be turned on in about:config for this to work.

Support without the custom prefix exists since version 31 (22.07.2014) and with the about:config option turned on by default.

The about:config preference to toggle CSS variables was finally removed in Gecko 55 (08.08.2017), which is the current version; it includes Firefox 55 and other browsers that use the current Gecko rendering engine.

CSS variables have been supported in Google Chrome from the outset with the -webkit-var- prefix and when 'Experimental Web Features' were turned on in chrome://flags.

Prefixed variables functionality existed in Chrome until 33.0.1750 (20.02.2014, Blink 537.36, V8 v3.23.17), and was removed in Chrome 34.0.1847 (08.04.2014, Blink 537.36, V8 v3.24.35) because of performance issues. V8, or Chrome V8, is the JavaScript engine used in Chrome.

Un-prefixed variables were implemented in Chrome 49.0.2623 (02.03.2016, Blink 537.36, V8 v4.9.385). The current Chrome version is 61.0.3163 (05.09.2017, Blink 537.36, V8 v6.1.534).

Windows Me, Netscape 4.x

This text was written as a series of replies I posted in the YouTube comments section of a promotional introduction video of Windows Me, which can be found in the said operating system.

Since the video was not uploaded from the official source, chances are that the video and the comments to it won't be available at some point of time. So I posted them here for future reference.

And since Blogspot does not have limits on the amount of text, then I have edited the replies a bit to add text.

Windows Me was really good on something like a 667 MHz CPU and 128Mb RAM at the time. If you want to run reasonably modern software without swapping much, then you need 256 Mb of RAM (factor in [modern] web browser, IM program, OpenOffice 2.4.3).

Windows Me can run on less, of course, as it was included in computers that only had 64Mb of RAM.

At one point, Windows xp ran fine with 128 Mb RAM, but nowadays it needs 512M RAM as a real-life minimum to keep the system secure & do something productive.

These specs were for a new PC from around 2000 that was first supplied with only 64 Mb RAM. I requested it have 128 Mb, since the lesser setup was slow with multimedia of the time (it had fast Internet, so I knew it was the amount of RAM). After the RAM upgrade, using the computer was a breeze.

I also took very good care of the hard drive and the OS, keeping it updated & secure, and since its users mostly used Netscape for business, then viruses and exploits never made it there.

At that time it [the popular version of Netscape] was Netscape Communciator 4.x. I think on that PC we stuck with 4.79 for a long time (the last of 4.x was 4.8, released in 2002 :-). The 4.x branch was the first to support CSS, but that was the only feature which caused crashes when turned on (especially in 4.0x), so I kept it off on all our Netscapes, which were fairly solid after that. Despite the clunky Navigator, the best part was the e-mail client, which introduced mail filters to fight spam (then seen as controversial).

We skipped Netscape 6, never considered 7.x, and in newer PC's moved instead to Mozilla, the open-source descendant of Netscape and which Netscape 6 and 7 were based on anyway.

As Mozilla Foundation started Firefox, it ceased Mozilla development, which was taken over by others, and Mozilla Application Suite became SeaMonkey.

The last version of SeaMonkey for Windows 98/Me is 1.1.19 ([from] 2010); its Gecko rendering engine is a wee bit newer than that of Firefox 2.0 (Gecko 1.8.1.20 vs 1.8.1.24).

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.

Best Gecko-based browser for Windows 9x

The latest and last versions of Gecko-based browsers to run on Vanilla Windows 98/Me (and 95, with updates and other reservations) are

• Mozilla Firefox 2.0.0.20 (Gecko 1.8.1.20, 20081217),
• K-Meleon 1.5.4 (Gecko 1.8.1.24pre, released on 05.03.2010) and
• SeaMonkey 1.1.19 (Gecko 1.8.1.24, released on 16.03.2010).

If there were a competition between the three, then the winner would be SeaMonkey.

The reasons are thus:

• Under similar limited circumstances, SeaMonkey 1.1 is more responsive than Mozilla Firefox  2.

  Here's why: SeaMonkey 1.1's XPFE/XPToolkit-based user interface (UI) technology dates back to Mozilla Application Suite (v1.0 released 05.06.2002, but pre-releases were usable since a year before), while Mozilla Firefox 2.0 (2006) is completely based on a newer toolkit (XUL).

• SeaMonkey 1.1.19 has a newer and more secure Gecko layout engine than Mozilla Firefox 2.0.0.20 and K-Meleon.
• SeaMonkey 1.1 has been supported by the two most important extensions to grace web surfing: Flashblock and NoScript.

  K-Meleon also uses the native Windows API for its UI, meaning that it can't run extensions which normally work in SeaMonkey or Mozilla Firefox.
  
  While K-Meleon comes close with its quick UI responsiveness and its rendering engine, it's only good for websites that are safe and are known to not be resource-intensive. Most of the latter still exist as they are, but the most popular sites (for webmail and news) are regularly redesigned to include more fancy features and are therefore made more demanding by way of including extensive JavaScript and AJAX technologies and often embedding multiple manifestations of the Adobe Flash plugin.

Which is why SeaMonkey 1.1.19 adorned with NoScript and Flashblock extensions is about the best Gecko-based browser solution that there is for Windows 9x, even Windows 95.

The only caveat is that SeaMonkey requires at least 64 Mb of RAM to run passably and at least a 266 MHz CPU. Well, a Navigator-only one-window/one-or-two-tab solution works in a PC with just a slightly lesser CPU.

K-Meleon is best for computers with 32–48 Mb of RAM (certainly less than 64 Mb).
Some words of caution: Java and JavaScript could only be allowed for safe and non-demanding websites. Because of a lack of NoScript or like extension for K-Meleon, JavaScript should be turned off for casual browsing (sometimes even a Google Search result may cause a hiccup). Keeping Java on is only recommended when a user consciously recognizes a real and pressing need to use that plugin (maybe a map application over the web).

On Plugins

Although Adobe Acrobat Reader 6.0.6 (released/updated last in 2003) is about the last version for Windows 98 as far as I know, it is still outdated and so more vulnerable to attacks that use the Reader.

While older computers might best handle even older versions of Acrobat Reader, it's most important to disable Acrobat (Java)Script in the Reader's preferences, no matter the version. This should somehow prevent malicious websites using the Reader as an attack vector.

A complete alternative to using Adobe Reader in old computers is muPDF: It's much less resource intensive, supports the newest PDF document display standard (PDF 1.7) and does not use AcroScript. muPDF does not support interactive PDF elements; this is both a caveat and a security/speed measure. muPDF does capture the file type association in Windows, so when using the app, then it's an either-or situation between it and Acrobat Reader. It should still be a no-brainer in old computers.

Optimize page rendering of Gecko-based browsers

Originally posted on 24.09.2008.

Tips from here.

• nglayout.initialpaint.delay — Set the integer value to 0 if the connection is too slow.
  
  E., 06.12.2010 Edit/Update: The downside is greater CPU usage, so if the computer is slow and/or if there's a slow operating system (Windows 95/98), then don't use this feature.
  
  For example, I have at my wherewithal a 900 MHz computer with 128 Mb RAM and Windows 98SE (the operating system that was supplied by the manufacturer), in which OS the latest Gecko-based browsers can be Mozilla Firefox 2.0.0.20, K-Meleon 1.5.4 and SeaMonkey 1.1.19.
  
  In late 2010 I realized how much more complex have websites become and their rendering really slowed the computer down. Messages about unresponsive scripts have also become more frequent.
  
  The only thoughtful solution to this would be changing the operating system to something lightweight, which supports SeaMonkey 2.0 (such as Linux). More about this in a future post.