The current post addresses what happens when such characters appear, or “dangle”, after the last rule of a rule set. All the examples shown are mistakes that should be avoided.

Table of Contents

• Grouping characters
  • Opening characters
  • Closing brace
  • Closing bracket or parenthesis
• Quoting characters and Alpha-numeric characters
  • Semi-colon
  • No semi-colon
• Across multiple stylesheets
• Closing thoughts

Grouping characters

The grouping characters, {}, [], () have surprising results and differences. The opening characters have the same disastrous effect, while the closing characters differ in their effects.

Opening characters

When an opening grouping character, (i.e., {, [, or (), is placed after the last rule, the rule is applied, but all subsequent selectors are ignored.

  [data-namespace="field:hint"] {		
		color: green

    { /* A dangling opening grouping character invalidates the rest of the entire stylesheet. */
  }

  [data-namespace="field:error"] {
    color: red; /* This is ignored. */
  }

  [data-namespace]:focus {
    background: aqua; /* This is also ignored. */
  }

Closing brace

When a closing brace, }, is placed after the last rule, the rule is applied, but the next selector is ignored, and the selector after that is applied.

  [data-namespace="field:hint"] {		
		color: green  /* This is applied... */
    
   } /* ...despite this dangling character. */
  }
  
  [data-namespace="field:error"] {
    /* Both rules below are ignored because of the previous dangling character. */

    background: white; /* This is ignored. */
    color: red; /* This is also ignored. */
  }
  
  [data-namespace]:focus {
    background: aqua; /* This is applied. */
  }

Closing bracket or parenthesis

When a closing bracket, ], or parenthesis, ), is placed after the last rule, the rule is applied, and the next selector is applied.

  [data-namespace="field:hint"] {		
		color: green  /* This is applied. */
    
    ]
  }
  
  [data-namespace="field:error"] {
    color: red; /* This is also applied. */
  }

Quoting characters and Alpha-numeric characters

The double and single quote characters as well as alpha-numeric characters affect rule processing only when the last rule does not terminate with a semi-colon.

Semi-colon

If a semi-colon appears before the quoting or alpha-numeric character, the rule applies.

  [data-namespace="field:hint"] {		
		color: green; /* This is applied. */

		" /* Dangling quote. */
  }

  [data-namespace="field:error"] {
    color: red; /* This is applied. */
  }

No semi-colon

If no semi-colon appears on the last rule, and a quoting or alpha-numeric character appears after that, the rule is ignored, while the subsequent selector is applied.

  [data-namespace="field:hint"] {		
		color: green /* No semi-colon. */

		" /* Dangling quote, terminates the rule which the parser discards as invalid. */
  }

  [data-namespace="field:error"] {
    color: red; /* This is applied. */
  }

Short explanation: Without the semi-colon, the parser includes the dangling quote or alpha-numeric character as part of the rule, and then discards it as invalid. This is explained at greater depth in the other post treating pseudo-comments as targeted malformedness.

Across multiple stylesheets

This section added on September 9, 2021.

CSS parsers in browsers process each stylesheet one at a time. As a result, a failure in one does not affect processing of any subsequent stylesheets, whether referenced by <link> elements or defined inline with <style> elements.

The following example uses three <style> elements. The second definition should fail due to the dangling open brace, {.

<!-- The following three rules run in separate stylesheets. -->

<style>
  [data-namespace="field:hint"] {		
		color: green  /* This is applied. */
    
    } /* ...despite this dangling character. */
  }
</style>

<style>
  [data-namespace="field:hint"] {
    color: red  /* This is ignored... */
    
    { /* ...because of this dangling character. */
  }
</style>

<style>
  [data-namespace="field:hint"] {
    color: aqua; /* This is applied. */
  }
</style>

Since each separate rule set only defines color, the last one, aqua, will be applied.

That will not be the case if we join the second and third rule sets into the same stylesheet, in which case only the first color, green, is applied.

<!-- The first rule runs in its own stylesheet. -->

<style>
  [data-namespace="field:hint"] {		
		color: green  /* This is applied. */
  }
</style>

<!-- The next two rules run in the same stylesheet. -->

<style>
  [data-namespace="field:hint"] {
    color: red  /* This is ignored... */
    
    { /* ...because of this dangling character. */
  }

  [data-namespace="field:hint"] {
    color: aqua; /* This is also ignored, because of the previous dangling character. */
  }
</style>

Closing thoughts

Clearly, I like exploring strange behavior around the edges.

That said, this is not a post recommending how to turn rules off with dangling characters. That is unambiguously a mistake.

Preamble

The CSS spec does not mention it, but you can mimic C-style and/or Unix-style line comments in CSS files (with some caveats). Others have written about them before (see in particular, SitePoint’s Web Foundations post covering CSS Comments). The present post examines them in further detail.

I have a follow-up post to this one that covers dangling characters.

Table of Contents

• CSS comments
• Pseudo-comments
• Semi-colons
• Inline vs. Next-line placement
• Selectors
• Pseudo-comments as targeted malformedness
  • Unknown values
  • Illegal values
  • Malformed declarations and statements
  • Quoting characters
  • Grouping characters
• At-rules
  • Pseudo-comments applied to at-rules with body blocks
  • Pseudo-comments applied to at-rules without body blocks
  • At-rules and Unknown at-keywords
• Pre-processors
  • Sass
  • Less
  • Stylus
• Best practice
  • When to use pseudo-comments
  • When to avoid pseudo-comments

CSS comments

CSS parsers, per the spec, officially bless one style for comments, the multi-line comment from C-style languages, which uses a start token, /*, and an end token, */, as follows:

/*
  Characters between, and including, the start and end tokens are ignored by the parser.
*/

And so a rule declaration in comments will be ignored:

body {
  background: red;
  /*
  background: white;
  */
}

A block declaration in comments will be ignored:

/*
body {
  background: red;
}
*/

In each of those examples, we are using the comment syntax intentionally to instruct the parser to ignore the content.

However, we can do that by accident, as with malformed declarations, such as

body {
  background: red  /* missing semi-colon */
  background: blue;      
}

In this example, neither background declaration is applied because of the missing semi-colon. The parser scans for the next semi-colon, determines the entire two-line statement is malformed, and so ignores the entire lexed content. The same thing happens if we leave out the property value altogether:

body {
  background:
  background: blue; /* this declaration is not applied */
}

And that shows that we can use malformed declarations as…

Pseudo-comments

We’ll refer to these as “pseudo-comments” because, properly speaking, these are not comments that terminate at an end-of-line character. Instead they work by malforming the input that follows them, even on subsequent lines. And this is due to the error handling process for Rule sets, declaration blocks, and selectors:

the whole statement should be ignored if there is an error anywhere in the selector, even though the rest of the selector may look reasonable in CSS 2.1.

In the following example, taken from the spec, the second rule set is ignored due to the presence of the invalid & character in the selector:

h1, h2 {color: green }
h3, h4 & h5 {color: red } /* <= ignored */
h6 {color: black }

Again, in the following, the second and third declarations are ignored due to the presence of extra characters in the background property name:

body {
  background: red;
  xbackground: white; /* property name is not recognized */
  y background: blue; /* property name is not well-formed */
}

A quick tour around the English language keyboard shows the following special characters will act as single-line declaration comments:

selector {
  ~ property-name: ignored;
  ` property-name: ignored;
  ! property-name: ignored;
  @ property-name: ignored;
  # property-name: ignored;
  $ property-name: ignored;
  % property-name: ignored;
  ^ property-name: ignored;
  & property-name: ignored;
  * property-name: ignored;
  _ property-name: ignored;
  - property-name: ignored;
  + property-name: ignored;
  = property-name: ignored;
  | property-name: ignored;
  \ property-name: ignored;
  : property-name: ignored;
  < property-name: ignored;
  . property-name: ignored;
  > property-name: ignored;
  , property-name: ignored;
  ? property-name: ignored;
  / property-name: ignored;
}

Rather than use just any character, though, stick with C and Unix convention, and use either # or //:

// background: ignored;
# background: ignored;

Semi-colons

Semi-colons are the end tokens of rule declarations. Thus, they cannot “comment” text that follows them. In spec-speak, the parser treats a dangling semi-colon as a malformed declaration (a declaration missing a name, colon, or value).

As shown earlier, when regular multi-line comments are malformed, that is, when start and end tokens are not balanced around a rule set or declaration, the subsequent declaration or rule set is ignored by the parser. The following will in effect “comment” out both background declarations because the parser will search for the next end-of-declaration token (the semi-colon) for the affected declaration:

body {
  background:
  background: blue; /* both lines ignored */
}

That’s fixed by adding a semi-colon after the comment, before the next declaration (thus the background blue declaration will be applied):

body {
background: ;     /* ignored */
background: blue; /* processed */
}

The effect is the same with a pseudo-comment on a line missing its semi-colon:

body {
  background: # red /* ignored */
  background: blue; /* also ignored */
}

and corrected by restoring the semi-colon:

body {
  background: # red;  /* ignored */
  background: blue;   /* processed */
}

One interesting thing about semi-colons is that they are optional for the last rule in a rule set. If the rule set contains only one rule, the semi-colon is optional.

Inline vs. Next-line placement

This is where the “pseudo” enters into the term “pseudo-comment.” It may be reason enough not to call these “comments” at all as they break from the end-of-line convention of C or Unix-style line comments.

A pseudo-comment placed on its own line will suppress a declaration on the next line. In the following, the background will be blue:

body { 
  //
  background: white !important; /* ignored */
  background: blue; /* processed */
}

A pseudo-comment placed after a valid declaration on the same line will suppress a declaration on the next line. In the following, the background will be white rather than blue:

body {
  background: white; // next line is ignored... 
  background: blue !important;
}

Even a “minified” version of a CSS selector with an inline pseudo-comment will behave as a single-declaration comment. In the following, the first background declaration is ignored due to the presence of the comment token, #, recognized by the parser as terminating at the next semi-colon, and the second background declaration is recognized as well-formed and therefore applied (in this case, blue will be applied to the body background):

body { // background: red !important; background: blue; }

Selectors

The same rule-based behavior applies to selectors.

An entire selector rule set is ignored when the selector is preceded by a pseudo-comment, whether inline,

/* body is ignored */
// body {
  background: white !important;
}

or next-line:

/* body is ignored */
//
body {
  background: white !important;
}

Pseudo-comments as targeted malformedness

Pseudo-comments work by taking advantage of the spec’s Rules for handling parsing errors. In effect, they work by exploiting their malformedness.

Unknown values

User agents must ignore a declaration with an unknown property.

A declaration containing an unrecognized property name will not be evaluated, as, for example, the comment property in the following body rule set:

body {
  comment: 'could be text or a value';  /* ignored */
}

Illegal values

User agents must ignore a declaration with an illegal value.

The second color property defined below is ignored because the value is a string rather than a value or color keyword, so the color applied will be gold, not red:

body {
  color: gold;
  color: "red"; /* ignored */
}

Malformed declarations and statements

User agents must handle unexpected tokens encountered while parsing a declaration [or statement] by reading until the end of the declaration [or statement], while observing the rules for matching pairs of (), [], {}, “", and ‘', and correctly handling escapes.

The second color rule that follows is malformed by the leading hyphen, -, in the property name, “color”, and so the rule is ignored, and the applied color will be green, not red:

body {
  color: green;
  -color: red;  /* ignored */
}

Declarations malformed by unmatched pairs of (), [], {}, "", and '' are more comprehensively ignored (and therefore more dangerous) than others. And the quoting characters "", and '' are processed differently than the grouping characters (), [], {}.

Quoting characters

The unpaired apostrophe in the second declaration below will prevent the subsequent declaration in the rule set from being processed (thus, the background will be red):

body {
  background: red;
  'background: white; /* ignored */
  background: blue;   /* also ignored */
}

However, a third declaration after the apostrophe will be processed (thus the background will be gold):

body {
  background: red;
  'background: white; /* ignored */
  background: blue;   /* also ignored */
  background: gold;   /* processed */
}

In sum, you can’t terminate a single quoting character on its own line.

Grouping characters

In general, grouping characters (), [], {} should be avoided as pseudo-comments because they have more drastic effects in that they interfere more extensively with the parser’s block recognition rules, and so will “comment” out more than single declarations. For the sake of completeness, we’ll examine a few of these.

For example, the appearance of unmatched starting group characters suppresses all subsequent declarations to the end of the stylesheet (not just the rule set). This is true of commas, brackets, and braces.

In the following, only the background: red; declaration is processed; all declarations and selectors after that in the entire stylesheet will be ignored:

body {
  background: red;

  /*
    Every declaration that follows will be ignored,
    including all subsequent selectors,
    to the end of the stylesheet.
   */

  {

  background: white;
  color: aqua;
  margin: 5px;
}

When grouping characters are matched, the grouped and subsequent ungrouped declarations in the rule set will be suppressed. In the following, the background will be red, not gold:

body {
  background: red;

  /*
    Every declaration that follows will be ignored
    to the end of the rule set.
   */

  (
  background: white;
  background: blue;
  background: fuchsia;
  )

  background: gold;
}

A closing comma or bracket will suppress only the next declaration that appears. In the following, the background will be gold blue :

body {
  background: red;

  ]
  background: white;  /* ignored */
  background: blue;   /* processed */
}

A closing brace, }, however, will suppress all declarations to the end of the rule set. In the following, the background will be red:

body {
  background: red;

  }
  background: white;  /* ignored */
  background: blue;   /* also ignored */
}

At-rules

At-rules (denoted by @<rulename>) have two forms:

• a body declaration denoted by braces, { ... } (such as @media),
• a rule declaration closed with a semi-colon, ; (such as @charset).

Pseudo-comments on body-block at-rules behave the same as for selectors (i.e., the entire at-rule is ignored).

Pseudo-comments applied to at-rules with body blocks

For at-rules containing body blocks, such as @keyframes, @media, @page, and @font-face, the entire at-rule rule set is ignored when the at-rule is preceded by a pseudo-comment, whether inline,

/* @media is ignored */
// @media (min-width: 0) {
  body {
    background: white !important;
  }
}

or next-line:

/* @media is ignored */
//
@media (min-width: 0) {
  body {
    background: white !important;
  }
}

Pseudo-comments applied to at-rules _without_ body blocks

At-rules without blocks, such as @charset and @import, provide a fascinating exception to inline pseudo-comment behavior.

An at-rule with a pseudo-comment after the keyword will be ignored:

/* The pseudo-comment before url() suppresses the entire @import statement. */
@import // url('libs/normalize.css');

But a pseudo-comment that precedes an at-rule suppresses both the import and the first rule or selector after the import. This is because the parser treats a pseudo-commented @import as a malformed statement, and looks for the next matching braces in order to complete the next rule set.

Thus, a pseudo-comment before one @import in a series of @import rules will suppress all subsequent @import rules and the first declaration or selector after the last import:

/*
  None of these loads because the first import is processed as a malformed statement,
  and the parser looks for the next matching pair of braces, {...}.
 */

// @import url('libs/normalize.css');
@import url('libs/normalize.css');
@import url('libs/example.css');
@import url('libs/other.css');
@import url('libs/more.css');
@import url('libs/another.css');
@import url('libs/yetmore.css');

The fix for this is surprisingly simple: just add an empty body block after the commented @import

/* Suppress loading of normalize. */
// @import url('libs/normalize.css');

/* Un-suppress any remaining imports by adding a pari of braces. */
{}

/* Now, the next import will load. */
@import url('libs/normalize.css');

This is fun for debugging, but that behavior is peculiar enough that you should avoid the pseudo-comments approach to at-rules without body blocks, and use the multi-line syntax instead.

At-rules and Unknown at-keywords

User agents must ignore an invalid at-keyword together with everything following it, up to the end of the block that contains the invalid at-keyword, or up to and including the next semicolon (;), or up to and including the next block ({…}), whichever comes first.

We can illustrate all that by using an unknown at-keyword, @comment, as a custom at-rule alternative to the multi-line syntax. For example, the following at-rule is parsed to the closing brace, }, determined to be malformed, and then ignored:

@comment { 
  I'm not processed in any way.
}

That looks harmless and readable at first, but due to the presence of the apostrophe in I'm, we’ve reintroduced the quoting character problem (i.e., you can’t terminate the single quoting character on its own line). That means, a subsequent at-rule or selector will also be ignored if our custom @comment's body is closed on its own line, because the rule’s declaration is malformed by the presence of the apostrophe in I'm:

@comment { 
  I'm not processed in any way. }

/* This whole block will not be processed either! */
body { background: blue; }

That can be rescued with outer quotes, either inside the braces,

@comment { 
  "I'm not processed in any way."  }  /* Fixed. */

body { background: blue; }   /* This block will work. */

or by leaving off the braces and instead terminating the pseudo-comment with a semi-colon, either inline,

@comment "I'm not processed in any way.";

body { background: blue; }   /* This works. */

or next-line:

@comment 
"I'm not processed in any way.";

body { background: blue; }   /* This workss */

Pre-processors

The various CSS pre-processors support similar multiline and single-line comments.

Sass

Sass supports standard multiline CSS comments with `/* */`, as well as single-line comments with `//`. The multiline comments are preserved in the CSS output where possible, while the single-line comments are removed.

— Sass-lang reference.

Compressed mode will normally strip out all comments, unless the comment is preceded by /*!.

However, you can use a single-character pseudo-comment, such as # and the output will contain the commented line.

body {
   # background: red; 
}

Less

Both block-style and inline comments may be used.

— Less.js CSS features overview.

It is not clear (to me, at least) whether Less will suppress these comments or print them to the output. From StackOverflow posts, it appears Less will aggregate line-comments at block level.

Stylus

Stylus also supports multiline /* */ and single-line comments //, but suppresses these from the output if the compress directive is enabled. If you always want multiline comments to print to the output, use Multi-line buffered comments.

Multi-line comments which are not suppressed start with `/*!`. This tells Stylus to output the comment regardless of compression.

— Stylus CSS documentation.

Hence,

/*!
 * This will appear in the output.
 */

Best practice

Readability counts.

— The Zen of Python.

Comments can make obscure code more readable, but readability depends on more than one convention. Pseudo-comments in CSS are less about readability than about playing against convention (aka, the parser).

If you find you need to use pseudo-comments,

• Stick to the C and Unix convention and use either // or # for the pseudo-comment delimiter.
• Place pseudo-comments on the same line before the item to be ignored.
• Use whitespace to separate the pseudo-comment delimiter from the intended rule, e.g., # background: ignored;.

When to use pseudo-comments

• Use pseudo-comments for debugging, notably when using an interactive CSS edit panel, such as Chris Pederick’s Web Developer extension (Chrome, Firefox, Opera).
• Use pseudo-comments to prevent individual declarations, selectors, or at-rules with bodies from being processed.

When to avoid pseudo-comments

• Avoid pseudo-comments for use with textual descriptions and at-rules without bodies (e.g., @import), and use multi-line /* ... */ comments instead.
• Avoid the quoting characters '', "" as they are hard for human eyes to scan and cannot be terminated on their own line.
• Avoid the grouping characters (), [], {} as they introduce more complicated scanning (and cannot be terminated on their own line).
• Avoid pseudo-comments in production code. Although not “harmful”, they are merely extra bytes at that point.

If you could be promoted with a raise, OR you could just get that raise without being promoted, which would you prefer?

— Jamon 🚜 (@jamonholmgren) August 11, 2021

TL;DR

Taking that promotion is your chance to make lasting improvements to anything.

Your time is limited and so is your credibility

You may not feel ready to leave your current responsibilities or focus. You may believe a that promotion means more responsibilities, less time to do what you really want, more stress and headache.

That seems logical, and I once thought so, too.

Until I was promoted and discovered the truth: With every promotion you gain credibility and more freedom to set the agenda and improve things.

That won’t always happen, but if you don’t take the chance, then it will never happen.

So take it. Use that freedom. Things may not be perfect, there may be tension or politics, but they really do want you to use that freedom.

Don’t undersell yourself

You’ve probably heard that too many times, but it’s true. If they offer you the promotion and you don’t take it, your career stalls. You may be happy doing what you do now for a long time, but the time comes when…

Your perspective will change

You’ve probably hit that moment when you had the next good idea that was vetoed for whatever reason, but you’re convinced you’re on to something. How do you convince them?

You’ll be tempted to carve out time from either more pressing tasks or your time away from work. We know where that leads: burnout. And you’re not the only one on the team who has that moment.

Taking the promotion means you can now let your teammates take the time they need to prove or falsify their ideas. You can even give them your great next idea to work out, if they are willing.

And that means you are improving things already because you are reducing Fear, Uncertainty, and Doubt, allowing everyone else to grow along with you.

You’re already growing

You’ll soon notice how some people struggle with tasks or issues that seem simple or straightforward but they can’t find their way out of the paper bag. You may have noticed that already and been called on to help out.

Guess what! You’re already performing at the next level. So take the promotion.

You can reduce stress by just listening

Everyone should feel comfortable speaking their minds (in an appropriate manner, of course), trying new things (which may or may not work), following their interests (which will change with experience).

Anything that gets in the way of that is deferred decision-making, or stress. The more acute, the worse it gets, so anything that increases stress should be addressed immediately.

If you take that promotion, you can make that effort or delegate it to the team to address however they think best, because ultimately, reducing stress is delivering.

My experiences (some details omitted)

That’s how it worked for me when I was a director of volunteers in San Francisco’s Tenderloin district (a position for which I had infinitesimal training, back in the 1990s). I asked the volunteers how they wanted to improve things, they came up with their own ideas, and we agreed to them. Things improved and they became even more engaged.

That’s how it worked for me when I became lead of a small distributed team building a JavaScript application for our clients (2018-19). I relied on the other members to work on things they preferred to work on and I took the “how do I make things safer for them so they can do their work” stuff and ran it by them and if we agreed we did it. Things improved repeatedly and we delivered.

Concluding Unscientific Summary

Ultimately, it is not your responsibilities that increase but your horizons. Your responsibilities don’t grow, they change. As your perspective increases, so will your empathy. As your empathy increases, your team will trust you. And because you understand them better, you will trust them.

Closing

Whatever your doubts or ambitions, once you gain that perspective, you can take action.

So take it. It is your best chance at improving anything.

This way…

Background

Last week (circa August 3, 2021), several people worried over the Google Chrome team’s attempt to remove the alert(), confirm(), and prompt() methods from embedded <iframe> elements. Fear, Uncertainty, and Doubt ensued.

Update: Rich Harris posted an overview of the matter as I was writing this post. Read it here.

I figured creating a polyfill couldn’t be that hard, but allowed that it might turn out to be impossible. It’s somewhere in between, depending on what you want.

First problem: Emulating synchronous blocking behavior

I tried several approaches that would block execution. What follows is the most successful approach so far.

All three native methods are synchronous, meaning they block other processing while displaying the modal dialogs. (There may an exception to this for certain methods in some browsers.)

So, after getting the dialog open-and-display logic working, I started by looking at how to make the following into a blocking call.

var answer = window.confirm("Yes?");

console.log(answer); // true or false

To do that, we have to use async/await functions that await a Promise field called “wait” in the response returned by the dialog opener (named Modal in this example).

async function prompt(title, defaultValue = "") {
  var { wait, response } = Modal({ type: "prompt", message: title, defaultValue });

  await wait;

  return response.value;
}

But to get the value from the Promise, we have to return it unfulfilled from the dialog opener (we’ll find out why in the next section), along with the response object that we update when a user’s response value is determined.

var response = { done: false };

// ... code omitted for brevity

return {
  response,
  wait: new Promise(init)
};

In the dialog opener, the wait Promise is initialized by a function that attaches a reference to the resolve function that a Promise calls on itself to finish processing.

function init(resolve, reject) {
  response.resolve = resolve;
}

var wait = new Promise(init);

Second problem: Detecting the response update

I tried two approaches to solve this problem.

First, I used polling with setTimeout() that repeated every 500ms to detect whether the response object’s done field had been set. It worked; however, I realized that could waste battery energy on long-lived (open) dialogs.

I then tried using a generator function because generators use a suspend-and-resume mechanism. When they yield, they are suspended, and so do not consume any resources, They are resumed by another caller using generator.next([value]) passing an optional value.

So, rather then checking on the state of the response, I let the dialog’s action event handler call the generator and pass the response to it when the user has decided to close the dialog.

In the following snippet, I used a co() function (not my own as you’ll read in the code comment) that accepts a generator, initializes it, advances it once with gen.next(), then returns a function send that allows the keyup and click event handler inside the dialog to update the response object, then call the resolve() function directly.

// A coroutine generator, from http://syzygy.st/javascript-coroutines/,
// which sadly no longer exists. This version is modified from Adam Boduch,
// "JavaScript Concurrency", Packt Publishing, 2015, p. 86.
function co(G, options) {
  var g = G(options);
  g.next();
  return (data) => g.next(data);
}

var send = co(function* G(response, data) {
  while (true) {
    data = yield; // This is invoked by calling g.next(data).
    Object.assign(response, data);
    if (Object(response).done) { // Make sure the response is an object.
      return response.resolve(response);
    }
  }
}, response);

Inside the dialog we listen for keyup and click events on various elements. The event handler checks whether the event type and target or key code are valid, then determines what value should be set in the response, and then removes the dialog and its event handlers from the DOM.

I’ve omitted a lot of detail in the following snippet that shows this logic.

function handler(e) {
  var config = shouldClose(e);

  if (!config.done) {
    return;
  }

  Object.assign(config, { input, prompt, confirm });

  send({ done: true, value: getValue(config) });

  remove({ dialog, underlay, ok, cancel, handler });
}

ok.addEventListener("click", handler);
cancel && (cancel.addEventListener("click", handler));
document.body.addEventListener("keyup", handler);

Results

Pretty close!

Even chained dialog calls in succesion (such as alert( await confirm("OK") );) seem to work.

To do that, you have to capture the return value.

And to do that, you have to add the await keyword in front of confirm() and prompt() calls.

var answer = await window.confirm("Yes?");

console.log(answer); // true or false

Luckily we don’t need to use await if we don’t need to capture that value, so alert() and window.alert() should just work.

And luckily, this solution is only needed in the evergreen browsers that may remove the modal methods.

However, the result is not truly blocking behavior. I used this function the console and found that while a native alert pauses the entire thread (setTimeout is not called), the polyfill does not. Try it:

setInterval(() => console.log(Date.now()), 1000);
alert("stop");

Aesthetics

Could do better.

• All the styles are defined on inline style attributes.
• Styles may be affected by (i.e., inherit from) rules in this site’s own CSS file.
• The dialog width is percentage-based, rather than fixed unit, so the dialog will expand its width as the viewport width increases.
• The JavaScript itself is a single execution that does not export anything. That could be added when the time comes for modular re-use.

Tests

In a break from habit, I did not use test-driven development for this as I:

• did not know what I did not know,
• only wanted to arrive at a working solution rather than a bullet-proof one,
• don’t intend to publish the solution to NPM.

Bugs

• A press on the Space key still scrolls the document body behind the dialog and underlay elements. 17 October 2022: This bug is fixed by adding a “focusout” event listener on the dialog adding an overflow: hidden; CSS rule to the <body> element and removing it when the dialog is closed.
• Opening a dialog from an Enter key press on a button may result in closing the dialog immediately after opening. 17 Octobeer 2022: __Suspect this is due to listening to click events rather than mouseup events and keyup events separately.

These are fixes I leave to the reader (or myself at a later time).

Accessibility

OK, but may need improvement.

• Reasonably accessible on screen readers (Navigator and Jaws) that I’ve tested so far.
• Works on Chrome, Edge, Firefox, and Falkon on a Windows 10 laptop.
• Works on iOS Safari. (Note: top-level await is not supported by iOS Safari as of 10 August 2021 ).

Try it out

There are some code samples on the demo page, where you may judge for yourself.

“Unit testers be like…”

The following joke pokes fun at developers who de-couple things arbitrarily or incoherently.

Still love this one. Unit testers be like: "Looks like it's working" pic.twitter.com/KiNT4wXP4a

— Kent C. Dodds (@kentcdodds) August 4, 2015

One of the follow-up jokes points to QA’s saving role in the process, i.e., we need integration tests.

If we take the joke’s underlying metaphor literally, we’ll see that it also confuses the practice of “unit testing” with testing only “parts” in isolation rather than their interaction.

Instead of thinking about units as parts to be fitted together, think about them as wholes that should work together. That encourages you to think from the start about how these will communicate with each other.

The following JavaScript function “works” but modifies nothing and returns nothing:

function A(a, b) {
    "secret inner workings";
}

That is an apt metaphor of the severed head in the joke animation. It can take input and hold a thought, but from just this design you cannot tell how it would work with anything else.

Once we start feeding the head some real input, what do we expect as a result? A spoken word may elicit a spoken response, in which case we need a communication strategy (vocalization, facial features, etc.). An input of food requires a different strategy (is this poison? does it taste good? what do I do with it now?).

Once it’s clear we need to support the head with other behavior, we can also see the need for the torso. However, it does not follow that we would then develop the torso independently of the head, since the torso would now depend on the head for information.

*Update, July 19, 2021 : I no longer agree with the tenor of this next paragraph.* Things that necessarily depend on each other cannot be tested in isolation without mocking those dependencies. The dependencies in this case are not the separated body parts, but several other undefined systems (the circulatory, respiratory, digestive, and nervous systems, for starters). An integration test of the head, torso and legs together is actually meaningless if those dependent systems have not been identified. When testing our programs, we are not testing the parts of the program such as variables, keywords, expressions, statements or functions independently, we are testing that they work together. Unit testing is not about making parts to be fitted together, but making wholes that work together.

Cedric’s post, Agile people still don’t get it, dates back to June 7, 2006 , and contains hard words for Agilists pushing TDD without acknowledging any associated costs.

Talbott’s comment dates to August 23, 2010 , two days after the post was picked up on reddit.com. Talbott lists some advantages and disadvantages of TDD.

Begin quote

Here are some things I like about TDD.

1. Interruptability: if you write a test first, and you get pulled away to a dreaded meeting, you can get back to work faster because you simply rebuild and run your tests to remind you of what is next and exactly what problem you were trying to solve before you were pulled away, since you wrote the code that would fail until you implemented the solution.

2. Less fragility: I’m less concerned about fixing and refactoring code when I can rerun the tests before checking in. Sometimes in large complex enterprise projects, a small change can break some distant dependency. We’ve all been there where we are afraid to make a change to someone else’s code because the app is so fragile. TDD reduces stress and makes programming more enjoyable.

3. Refactoring: a benefit from #2 is that you can keep a clean house. Nothing worse than code that “smells” and is not fun to debug or navigate. TDD allows developers to constantly refactor and delete dead code so you don’t have an increasingly growing pile of dung. It is much more fun to maintain a codebase that is 25% of the size and clean.

4. Less time wasted: when a test can pinpoint a bug in seconds that can take hours without test coverage, you realize that TDD can often reduce the time to develop software over the course of the project.

Disadvantages/Risks:

1. No buy in by developers or management: this is the biggest risk to TDD. If you don’t have people who realize the benefits, it will never work for your team.

2. Dependencies: TDD should be implemented in a way that has minimal dependencies. Depending on a database connection, network connection, web services, etc.. can lead to fragile tests. There has been a ton of work in this area, especially mocking frameworks, to get around this issue. Done right, your tests should test only your logic, not external components.

3. Hard to add TDD later: TDD is best to have in place before you start coding. It is very difficult to add TDD to an existing project. Often the application architecture will evolve in a “testable” way when you are using TDD. You will write your code and use application frameworks like ASP.NET MVC instead of ASP.NET WebForms for example to make testing easier and more natural.

End quote

We create a test function to exercise JavaScript’s Number.toFixed() method with several series to identify the pattern that results in the rounding bug. We also include a polyfill that fixes this issue.

This post first appeared in 2017 previously in a gist at https://gist.github.com/dfkaye/e977af36e668aa134c0ce55bab5bb15f and on my old wordpress blog.

This post is also a bit long. If you’re not interested in the testing approach, you may skip to the addendum with my latest thoughts.

First things first

I’m aware that this is part of the whole integer-to-binary bug set introduced in the 1960s. I am still surprised that it has been tolerated for over 50 years.

Acknowledgement

May 28, 2020 , the original polyfill created in this post was updated with a fix from reader A. Shah, to account for the padding case, so that (1.005).toFixed(4) produces “1.0050” and not “1.0051”.

Warm up

I found this version of the rounding bug in toFixed() while revising a number-formatting function that performs the same kind of thing as Intl.NumberFormat.format().

(1.015).toFixed(2)

That returns “1.01” instead of “1.02”.

The failing test is on line 42 here: https://gist.github.com/dfkaye/0d84b88a965c5fae7719d941e7b99e2e#file-number-format-js-L42.

I had missed that result until yesterday (4 Dec 2017), and that spurred me to check for other problems.

Bug reports

There is a long history of bug reports with respect to rounding errors using toFixed().

• Chrome https://forums.asp.net/t/1966237.aspx?toFixed+not+working+in+Chrome
• Firefox http://forums.mozillazine.org/viewtopic.php?f=9&t=999945
  • see also https://bugzilla.mozilla.org/show_bug.cgi?id=186563
• Internet Explorer https://stackoverflow.com/questions/10470810/javascript-tofixed-bug-in-ie6

Here is a short sample of StackOverflow questions about this problem:

• August 24, 2012 , toFixed javascript function giving strange results?
• March 11, 2011 , broken toFixed implementation.

In general, these point out a bug for a value, but none reports a range or pattern of values returning erroneous results (at least none that I have found, I may have missed something). That leaves the programmers to focus on the small without seeing a larger pattern. I don’t blame them for that.

Finding the pattern

Unexpected results based on input must arise from a shared pattern in the input. So, rather than review the specification for Number().toFixed(), I focused on testing with a series of values to determine where the bug shows up in each series.

Test function

I created the following test function to exercise toFixed() over a series of integers ranging from 1 to a maxValue, adding the fraction such as .005 to each integer. The fixed (number of digits) argument to toFixed() is calculated from the length of the fraction value.

function test({fraction, maxValue}) {
  // Happy side-effect: `toString()` removes trailing zeroes.
  fraction = fraction.toString()

// Use this in toFixed() calls in in the filter and map functions below.
  var fixLength = fraction.split('.')[1].length - 1
  
  // All this to create the expectedFraction message...
  var last = Number(fraction.charAt(fraction.length - 1))
  var fixDigit = Number(fraction.charAt(fraction.length - 2))
  last >= 5 && (fixDigit = fixDigit + 1)
  
  // Replace last two digits with single `fixDigit`
  var expectedFraction = fraction.replace(/[\d]{2,2}$/, fixDigit)
  
  return Array(maxValue).fill(0)
    .map(function(ignoreValue, index) { return index + 1 })
    .filter(function(integer) {
      // Compares 1.015 to 1.0151 b/c fixing by more than one decimal place rounds correctly.
      
      var number = integer + Number(fraction) // number 1.015
      var actual = number.toFixed(fixLength) // string "1.015"
      var expected = Number(number + '1').toFixed(fixLength) // string "1.0151"
      
      // Report failures
      return expected != actual
    })
    .map(function(integer) {
      // Format reported failures
      var number = Number(integer) + Number(fraction)
      
      return {
        given: number.toString(),
        expected: (Number(integer.toFixed(0)) + Number(expectedFraction)).toString(), actual: number.toFixed(fixLength)
      }
    })
}

Usage

The following example executes on integers 1 through 128, adding the fraction .015 to each, and returns an array of “unexpected” results. Each result contains a given, expected, and actual field. Here we consume the array and print each item.

test({ fraction: .015, maxValue: 128 })
  .forEach(function(item) {
    console.log(item)
  })

Output

For this case, there are 6 unexpected results.

{given: "1.015", expected: "1.02", actual: "1.01"}
{given: "4.015", expected: "4.02", actual: "4.01"}
{given: "5.015", expected: "5.02", actual: "5.01"}
{given: "6.015", expected: "6.02", actual: "6.01"}
{given: "7.015", expected: "7.02", actual: "7.01"}
{given: "128.015", expected: "128.02", actual: "128.01"}

Findings

I found the bug consists of three parts:

1. The last significant digit in the fraction must be 5 (.015 and .01500 produce the same result).
2. The fixing length must shorten the fraction by only one digit.
3. The bug appears inconsistently as different integer values are applied.

Inconsistently?

Yes. For example, (value).toFixed(2) with different 3-digit fractions ending in 5, for integers 1 though 128, produces these results:

• fixing numbers ending with .005 always fails (!!)
• fixing numbers ending with .015 fails for 1, then 4 through 7, then 128
• fixing numbers ending with .025 fails 1, 2, 3, then 16 through 63
• fixing numbers ending with .035 fails for 1, then 32 through 128
• fixing numbers ending with .045 fails for 1 through 15, then 128
• fixing numbers ending with .055 fails for 1, then 4 through 63
• fixing numbers ending with .065 fails for 1, 2, 3, then 8 through 15, then 32 through 128
• fixing numbers ending with .075 fails for 1, then 8 through 31, then 128
• fixing numbers ending with .085 fails for 1 through 7, then 64 through 127 (!!)
• fixing numbers ending with .095 fails for 1, then 4 through 7, then 16 through 128

Those of you with more binary and floating-point math knowledge than I have can probably reason out the underlying cause. I leave that as an exercise for the reader.

Fixing toFixed()

Fixing a value by more than one decimal place always rounds correctly.

Recall earlier that we tested various 3-digit fractions against a fixing length of 2. The rounding error disappears if we add another digit to the fraction, so that, for example, (1.0151).toFixed(2) returns “1.02” as expected. (Both the test and polyfill use that knowledge for their correctness checks.)

That means there’s a simple fix for all implementations of toFixed(): If the value contains a decimal, append “1” to the end of the string version of the value to be modified. That may not be “to spec,” but it means we will get the results we expect without having to revisit lower-level binary or floating-point operations.

Polyfill

Until all implementations are modified, you can use the following polyfill to overwrite toFixed(), if you’re comfortable doing that (not everyone is).

(1.005).toFixed(2) == "1.01" || (function (prototype) {
  var toFixed = prototype.toFixed;

  prototype.toFixed = function(fractionDigits) {
    var split = this.toString().split('.');
    var string = !split[1]
      ? split[0]
      : split[1].length >= fractionDigits
          ? split.join('.') + '1'
          : split.join('.');
    var number = Number(string);

    return toFixed.call(number, fractionDigits);
  }
}(Number.prototype));

Then run the test again and check that the length of the results is zero.

test({ fraction: .0015, maxValue: 516 }) // Array []
test({ fraction: .0015, maxValue: 516 }).length // 0

Or just run the initial conversion that started off this post.

(1.015).toFixed(2) // returns "1.02" as expected

Better solution

Meanwhile, in February 2020 on StackOverflow, I found another solution that uses the built-in Number.toLocaleString() method without string hacking.

(1.005).toFixed(2) == "1.01" || (function() {
  Number.prototype.toFixed = function(fractionDigits) {
    return this.toLocaleString(undefined, {
      minimumFractionDigits: fractionDigits,
      maximumFractionDigits: fractionDigits
    });
  };
}());

Thanks go to Christian Salvadó . That’s definitely more elegant.