Text Formatting (Feature suggestion) about d3-format

[mbostock]

Interesting suggestions. Both are possible. I’m unsure how useful those features would be; I’d have to see some examples. For decimal place alignment, I’d probably be inclined to just use the f type. But… it would be possible to have a variant of formatDefault’s trimming of insignificant zeros and instead replace them with spaces.

[cool-Blue]

Thinking about it I probably only yearn for text formatting when I'm echoing to the console for debugging and don't want to get car sick trying to understand it, but if you want to output a list of mixed values to a div - a data table or a legend for example - then it would be nice to have a standard service in the API without having to do something like this...

var w = 8, span = new Array(w).join(" ");
(x + span).slice(0, w)

Mainly though, it's just my theory that symmetry delivers benefits: it would be nice if format didn't return NaN if you try to format a string. Bear in mind that Leo Fender had no idea that if you took a right-handed stratocaster, strung it upside down and played it left handed, that something magical would happen! But it did. My point being, that if you leave symmetrical functionality laying around, people will find ways to use it that you never dreamed of. Mainly because they are comfortable.

This is just brainstorming by the way so please don't take it literally but...

Another suggestion which is based on excel custom formatting is this...

d3.format( p, [ n, [ z, [ @]]])

where p is positive or general formatting, n is for negative numbers, z is for zero and @ for string.
It's nice to have the option for a blank or a "-" for zero values and a blank for negative (or positive) values if you want to focus on one quadrant in axis labeling for example.
But, anyway this would give a lot of flexibility and it only re-tasks existing functionality...

A more succinct approach may be like this...

The sign can be:

• plus ("+") - a sign should be used for both positive and negative numbers.
• minus ("-") - a sign should be used only for negative numbers. (This is the default.)
• space (" ") - a leading space should be used on positive numbers, and a minus sign on negative numbers.
• parenthesis ("(") - negative numbers should be enclosed in parenthesis and positive numbers have a leading and trailing space.

Like I said... just a few random suggestions designed to stimulate ideas.

[mbostock]

Sure, I’m onboard supporting the s type for string. If it’s s, we coerce the input value to a string, and otherwise we coerce it to a number. I have to think a bit about exactly how this interacts with the other functionality (like I think sign-aware zero-padding only applies to numeric types, but fill should apply to strings) but it seems possible.

I’m less excited about having separate formats for negative, zero and strings. I don’t like functions with lots of unnamed arguments; it diverges substantially from Python; and it competes with the existing format specification mini-language which already has branching behavior (at least as far as the sign).

The parenthesis sign idea is attractive though. That seems easily expressible. It complicates the formatting logic a bit since now a sign can introduce a character after the value as well as before. But probably doable.

Also, I don’t think d3-format has to be the be-all, end-all way of formatting numbers. Like, we might consider doing something modeled after Java’s DecimalFormat and see how expressive that is.

[cool-Blue]

Sticking with the Python mini-language spec and extending it to include the s type is a strong, compact principle that neatly addresses my main concern which is to include basic text formatting.

The parenthesis sign is standard for financial applications so, if it's doable without clutter, would indeed be a nice addition.

Then you have a solid building block that can be deployed on the user side in more complicated applications like different formatting positive, negative, zero etc. if needed.

Sounds pretty solid to me.

[mbostock]

Argh, I forgot that s is already being used for the SI-prefix notation. (We define several new types: p, r and s. The first two are for rounding to significant digits and formatting with fixed-point.) I suppose we could redefine s to be string, but that seems quite poor in terms of backwards-compatibility. I’m not sure whether backwards-compatibility or mimicry of Python is more important, especially since we’re not trying to reproduce the Python behave exactly. In any case, boo.

The negative parentheses seems pretty easy, though.

[cool-Blue]

In that case I would suggest forgetting about the s type, but instead of returning NaN when the input is a string, simply apply any formatting that makes sense (justification, width...) and return the formatted string.

[mbostock]

It might be okay to co-opt the c type and change the behavior. That format type seems pretty useless in JavaScript and likely an artifact of Python’s type system (which, unlike JavaScript, doesn’t favor type coercion). I don’t have any empirical evidence but I doubt that anyone, or at least very few, use that format type currently. And plus, once we have the ability to format strings, it’s trivial to use that formatter to format individual characters. Before:

format("c")(9731); // "☃"

After:

format("c")(String.fromCharCode(9731)); // "☃"

Or, more likely:

format("c")("☃");

Alternatively, we could just pick a new letter… like t (for “text”)? But again, I really doubt there’s much value to keeping the existing c type.

I do feel pretty strongly about keeping the existing behavior of coercing input values to numbers when a number format type is being used. That’s the JavaScript Way.™ If you try to format the string "42" with type f, it should be equivalent to formatting the number 42.

[cool-Blue]

Ah, yes: of course, I see what you mean. Ok. Excel uses @ to denote text in custom formatting, perhaps that is another possibility.

[cool-Blue]

As a final thought, perhaps the default behaviour, if coercion to a number fails (NaN), then return sensibly formatted string (justification, width...). Leave NaN-ness for the consumer to decide.

[mbostock]

Added support for character data in e247671, using the format type c as described above.