By Any Other Descriptor

I really have not been paying attention. Apparently there are various editions of Shakespeare’s works, with vastly different text among them, with no definitive versions. In fact, the earliest versions seem to be considered the least reliable. This is the opposite of how original publications of musical works are generally treated, where urtext (original text) editions are thought of as bringing us closest to the composer’s original intentions.

I grew up thinking I knew the following lines from Romeo and Juliet:

What’s in a name? That which we call a rose
By any other name would smell as sweet.

I heard this on the radio this past weekend as:

What’s in a name? That which we call a rose
By any other word would smell as sweet.

Wanting to verify my sanity, I quickly checked my bookmarked link to the Complete Works of William Shakespeare at MIT. By any other name. Sanity confirmed? Perhaps not. Google has this to say:

By any other name would smell as sweet (about 535,000 results)

By any other word would smell as sweet (about 124,000 results)

The ratio is about 4:1, which doesn’t spell a staggering defeat of one over the other. What was driving me crazy was that I couldn’t find any mention of this disparity.

Here’s another view from Google. Both phrases have coexisted for hundreds of years, with the name form always being more popular.

Beethoven vs. Shakespeare

At least in music, disparities like this get some attention. Beethoven marked the first movement of his fourteenth piano sonata (the Moonlight Sonata) to be played senza sordino. This brings up two very nonintuitive Italian markings in piano music:

Senza sordino: don’t use (or stop using) the soft pedal. The meaning is something like without [the] mute and instructs you to not mute the sound, which nowadays means don’t use (or stop using) the una corda pedal, where the una corda pedal is also known as the soft pedal or left pedal.

Senza sordini: do use the damper pedal. The meaning is something like without mutes (or dampers) and instructs you to play without dampers on the strings, which effectively means to depress the damper pedal, which is also known as the right pedal. This term rarely occurs in music in favor of using a fancily scripted Ped. marking instead.

Note: Schubert used sordini (i.e., short for con sordini, meaning with dampers) to mean don’t use the damper pedal. All these double negatives really make you stop and think! Brahms used una corda (one string) and tre corde (three strings), which to me is shrouded in less obscurity.

Some argue that Beethoven misspelled (or perhaps miswrote) sordini as sordino (plural vs. singular). In fact, some Beethoven editions make the according “correction.” The Harvard Dictionary of Music concludes (assumes) that Beethoven misspelled the word.

These pedal markings usually apply only to a few measures at a time within a piece. Beethoven’s marking has perhaps never been used at the beginning of another piece, where it seemingly refers to the whole piece. Some argue that Beethoven meant that the damper pedal should be held throughout the entire movement and would not have used a marking such as this (misspelled or otherwise) unless he meant something special, such as holding the pedal throughout the entire movement.

There are many levels to this controversy! They will be discussed forever and never resolved.

Words and grammar don’t really matter

Trying to find more information on the Shakespeare side of things, I found this website:

The site has photocopies of various early editions, excerpted as follows:

First quarto (1597)
Second quarto (1599)
First folio (1623)
Second folio (1632)
Third folio (1664)
Fourth folio (1685)

Wow! The amount of sloppiness and bad grammar boggles the mind. The same site has the only mention of this budding rose controversy I could find so far:

This page comes out and says, simply, that the first quarto (by any other name) is bad and the second quarto (by any other word) is good. Alas, the futility.

CSS for Printing

Sometimes people are more baffling than browsers.

The goal

The goal is to create a simple web page (such as a résumé) that prints nicely, specifically at page boundaries. Being a Microsoft Word user, I think in terms of applying keep with next and keep lines together to key places. These concepts are covered nicely in the CSS specification:

  • Keep with next translates to page-break-after: avoid
  • Keep lines together translates to page-break-inside: avoid

Most browsers do not work

The spec has been regurgitated over the years in various forms, across hundreds, perhaps tens of thousands, of web sites, some claiming support exists in every major browser. Has anyone actually tried it in any browser other than IE?

  • Microsoft Edge 20 works.
  • IE9 and IE10 work.
  • IE8 works, as it says it does.
  • IE7 works, which is surprising.
  • IE6 does not work, as expected.
  • Chrome up through 25.0 does not work. page-break-inside starting working after a few years but page-break-after still does not (after three years).
  • Safari 5.1.7 for Windows does not work.
  • Firefox 4.0 through 17.0 do not work.
  • Opera 10 does not work (but fails in the weirdest way: the content that should be moved to a new page is duplicated on both pages).
    • Opera 11.5 works.

In order to help myself track this limitation, I created a test page here:


One theory as to why some people are mysteriously satisfied with something that doesn’t work is that they didn’t actually try it (i.e., print to paper) and are satisfied simply putting the CSS in place, believing that it works, and not noticing that it doesn’t. Or perhaps they tried it only in IE, which is probably more true the farther back in time you go (IE7 is just over three years old at the moment).

Maybe some people are content with trying it and seeing that it doesn’t work and moving on to bigger fish to fry. Actually, I think that for whatever reason, very few people care about and have tried this feature.

Memory Leaks in IE8 and IE9 (Fixed in IE10)

In June 2007, Microsoft famously fixed a problem with memory leaks in Internet Explorer 6 (broken URL to more information). IE8 leaks memory worse than IE6 ever did, yet I haven’t been able to find any mention of it. I say worse because:

  1. No closures or circular references are required.
  2. I cannot find a workaround. (Update: See comments from May 9, 2011 for a way to avoid the problem.)

Update: It was fixed in IE10.

Problem statement

The memory used by IE8 to create certain DOM nodes is never freed, even if those DOM nodes are removed from the document (until is unloaded). There are no closures or circular references involved.

The DOM node types that leak are form, button, input, select, textarea, a, img, and object. Most node types don’t leak, such as span, div, p, table, etc.

This problem only occurs in IE8 (and IE9 and IE10 preview). It does not occur in IE6, IE7, Firefox, or Chrome.

In case you missed it: every image element, anchor element, etc. added to a page uses memory that is not reclaimed even if the element is removed from the page.

In practical terms

Think intranet web application rather than Internet web site—that is, something that you may leave running for multiple days. If you have a web page that never reloads as a whole but pulls over many updates from the server (e.g., images and anchors are updated Ajax-style), each update will leak memory. Note that update here means existing DOM nodes are removed and new DOM nodes are created.

Depending on the size and frequency of the updates, IE8 can end up using all available virtual memory, start thrashing within itself, and eventually failures occur; see below for more details.

The user hitting F5 occasionally (if the page can handle it) will unload and free its memory, but there is no apparent programmatic workaround. If the page is in an iframe, unloading the iframe has no effect. It seems that must be unloaded.

In terms of code

First example

Here’s the basic idea of the leak, which is to repeatedly execute the following:

function leak1() {
    var node = document.getElementById("TO_AREA");
    node.innerHTML = "<img>";
    node.innerHTML = "";
    node = null;


  • You can leave off the second innerHTML assignment, as well as setting the node to null, which I put in just for clarity/emphasis.
  • There’s an initially empty div with an id of TO_AREA in the body.
  • Example innerHTML that doesn’t leak: <span></span>. See the problem statement above for a list of problematic node types.
  • As I mentioned, there are no closures or circular references involved here.

Second example

Here’s a similar piece of code that avoids innerHTML and has the same leak:

function leak2() {
    var node = document.getElementById("FROM_AREA").cloneNode(true); = "NEW_AREA";
    node = null;


  • The FROM_AREA contains HTML like in the first example. Still, there are no closures or circular references.

Third example

This is the simplest and most straightforward:

function leak4() {
    var node = document.createElement("IMG");

Replace IMG with (e.g.) SPAN, and there is no leak.

Other notes

These examples leak in IE8 but not other browsers. I’ve tried IE8 on Windows XP, Windows Vista, Windows Server 2008, Windows Server 2008 R2, and Windows 7. I’ve tried IE in IE7 backwards compatibility mode, as well as every possible variation of quirks and standards mode. Though that’s by no means every variation of everything, it makes me comfortable that it’s not a fluke.

Live example

Here’s a link to an example page that shows the problem highly amplified. What I mean by amplified is that the job of the page is to show the leak, highly exacerbated; it has no other purpose. There are start/stop links on the page, so don’t worry about the page doing something terrible on its own.

Characterizing the leak

The memory size (called private working set on Windows 7) of iexplore.exe grows steadily over time, but this doesn’t lead directly to failures. IE memory usage does seem capped, and it does seem to be trying to manage memory from a DHTML perspective within certain constraints.

After it reaches its self-imposed cap, it seems to start thrashing within itself. Operations that could be performed at maybe 100 times per second begin taking over one minute per operation. Eventually, DHTML-style out-of-memory errors can occur.

In closing

I’m very interested in hearing about workarounds to this problem. I will post any meaningful updates as they are uncovered.

Update 2010-03-26

Microsoft made an IE9 preview available on 2010-03-16. It runs my leak test and does not leak. This is very promising. Additional update on 2010-06-24: We are now up to preview #3, and still no leaks.

There is a lot of memory churn in IE9 for the elements that leak in IE8, and there’s no churn at all for elements that don’t leak in IE8. The memory usage pattern in IE9 could be characterized as following a sawtooth pattern (low amplitude, high frequency), but with no long-term growth. I ran the test for an hour with no memory growth in IE9, whereas IE8 grew by about 1 GB in the same time.

Update 2010-09-16

Microsoft released the first beta of IE9 yesterday. The leak is back, at a rate of about 1 GB an hour: the same elements are leaking as before, at about the same rate as before.

Update 2010-10-28

Microsoft released the sixth preview of IE9 today. The leak is still there, same as in the beta.

Update 2010-11-17

Microsoft released the seventh preview of IE9 today. There’s the same churn and sawtooth as in the original three previews, and likewise, there is no leak. This is turning into a nail-biter.

Update 2011-02-10

Microsoft released the IE9 RC today. The leak is back.

Update 2011-03-14

Today is π Day, and Microsoft released IE9. The leak is still there.

Update 2011-04-12

Microsoft released IE10 Platform Preview 1. In terms of leaking, this is very similar to the IE9 preview: no overall leak, but a lot of churn and the sawtooth pattern is back.

Update 2011-06-29

Microsoft released IE10 Platform Preview 2. No leak. I suppose there is no SmartScreen Filter in these preview releases, which might account for the leak being absent from them.

Update 2011-09-13

Microsoft released the IE10 Platform Preview 3 as part of the Windows 8 Developer Preview. The leak is still there if the SmartScreen Filter is off; otherwise (the default), the leak is not there.

Update 2011-11-29

Microsoft released the IE10 Platform Preview 4 for the Windows 8 Developer Preview. The leak is not there, but I suspect the SmartScreen Filter is also not there; it’s hard to tell.

Update 2012-02-29

Microsoft released the IE10 Platform Preview 5 for the Windows 8 Consumer Preview. The leak is not there, and the SmartScreen Filter definitely is. This is the best it’s looked in years.

Update 2012-05-31

Microsoft released the IE10 Platform Preview 6 for the Windows 8 Release Preview. The leak is not there, and the SmartScreen Filter definitely is. This is the best IE has looked in years. And Windows 8 is looking pretty good, too (after going to the desktop and staying there, that is).

Update 2012-11-13

Microsoft released the release preview of IE10 for Windows 7. The leak is back, just as before: with the SmartScreen Filter disabled, the leak is present; with the SmartScreen Filter enabled, the leak is not present.

Update 2013-02-26

Microsoft released IE10 on Windows 7. The leak is gone! With the SmartScreen Filter enabled, the sawtooth pattern is there. With the SmartScreen Filter disabled, it looks even better: no manic memory usage and no memory growth.

Update 2013-06-26

Microsoft released an IE11 Preview with the Windows 8.1 Preview. I haven’t had a chance to look at it.

Update 2013-07-25

Microsoft released the Developer Preview of IE11 for Windows 7. It looks fine.