Bug 208190 – Use 1000-based units for file sizes, per HIG

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector

[Mathias Bynens]

https://developer.apple.com/design/human-interface-guidelines/macos/system-capabilities/finder/ says:

"Report disk usage and file sizes accurately and consistently. Provide values that are consistent with values reported by the Finder and utilities like Activity Monitor. It’s confusing when an app and the system report different values for the same measurement."

Yet, Safari DevTools currently uses "1 KB" to mean 1024 bytes. This can easily be tested by creating a 1024-byte file as follows:

    python -c 'print("x"*1024)' > foo.txt

Then loading that over HTTP and using the Network panel to inspect its size.

[Mathias Bynens]

You can use these files to test:

- https://mathiasbynens.github.io/css-dbg-stories/1000.txt
- https://mathiasbynens.github.io/css-dbg-stories/1024.txt

[Paul Irish]

Would Safari DevTools be willing to make this change if you know that Chromium and Firefox are also making it?

[Nikita Vasilyev]

My understanding is that treating 1 KB as 1024 bytes was intentional decision as this what majority web developers expected. 

From a web developer perspective, first and foremost, I'd like to see the same units in all DevTools (Safari, Chrome, and Firefox).

https://docs.google.com/document/d/1TWn4kpXlN-W_LmuZGQ9Iv7pmK4R7zgmhKkZ9gF2CsrE/edit
It looks like you're going with base-1024 and KiB/MiB labels in Chrome DevTools. I personally think this is fine and Safari DevTools should do the same.

[Mathias Bynens]

> From a web developer perspective, first and foremost, I'd like to see the same units in all DevTools (Safari, Chrome, and Firefox).

Strong +1 to that!

FWIW, Chrome 81 (stable since April) uses the 1000-based SI units (which happens to match the Apple HIG), and we haven't heard any complaints. It seems like we could choose whatever option here.

[Mathias Bynens]

Chrome DevTools now consistently uses 1000-based units with the proper SI labels, matching the Apple HIG: https://bugs.chromium.org/p/chromium/issues/detail?id=1035309

It would be great if the Web Inspector did the same, especially given comment #3.

[Radar WebKit Bug Importer]

<rdar://problem/71045696>

[Nikita Vasilyev]

Created attachment 413294 [details]
Patch

[Nikita Vasilyev]

Created attachment 413316 [details]
Patch

[Blaze Burg]

(In reply to Mathias Bynens from comment #5)
> Chrome DevTools now consistently uses 1000-based units with the proper SI
> labels, matching the Apple HIG:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1035309
> 
> It would be great if the Web Inspector did the same, especially given
> comment #3.

Somehow, I don't think that section of the HIG was written for developer tools that need to examine network traffic. In fact, the section you linked is specifically about Finder, which is consumer facing.

This change makes Web Inspector report values different from many other developer tools which report bits in sizes based on powers of two. I don't think it's an improvement to what already exists.

[Mathias Bynens]

(In reply to Brian Burg from comment #9)
> (In reply to Mathias Bynens from comment #5)
> > Chrome DevTools now consistently uses 1000-based units with the proper SI
> > labels, matching the Apple HIG:
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1035309
> > 
> > It would be great if the Web Inspector did the same, especially given
> > comment #3.
> 
> Somehow, I don't think that section of the HIG was written for developer
> tools that need to examine network traffic. In fact, the section you linked
> is specifically about Finder, which is consumer facing.

The relevant text is:

> Provide values that are consistent with values reported by the Finder and
> utilities like Activity Monitor. It’s confusing when an app and the system
> report different values for the same measurement.

This is unambiguously not just about Finder. It says all apps must match how Finder reports file sizes. The HIG is clear and precise in this regard, and doesn’t include any exceptions or special cases for developer-facing apps.

> This change makes Web Inspector report values different from many other
> developer tools which report bits in sizes based on powers of two.

Which examples are you thinking of? Note that when we looked into this (https://goo.gle/devtools-si), Firefox DevTools were on board with making the change. We’ve already made the change in Chrome DevTools.

[Mathias Bynens]

(In reply to Brian Burg from comment #9)
> (In reply to Mathias Bynens from comment #5)
> > Chrome DevTools now consistently uses 1000-based units with the proper SI
> > labels, matching the Apple HIG:
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1035309
> > 
> > It would be great if the Web Inspector did the same, especially given
> > comment #3.
> 
> Somehow, I don't think that section of the HIG was written for developer
> tools that need to examine network traffic.

Note the explicit HIG mention of Activity Monitor, which specifically includes “tools to examine network traffic”. I don’t understand your interpretation.

[Blaze Burg]

We can haggle all day about the HIG, but the reality is that the rest of Apple's development toolchain still uses KB = 1024 bytes. As do most other developer tools that I'm familiar with. Your own feature document shows skepticism about this change, noting that the authoritative references are simply Wikipedia articles and the Apple HIG. Not exactly a compelling argument to me, but to each their own. Other attempts to use SI units in web standards (i.e., to add to TC39) and tooling also haven't gone anywhere. It seems like a Chrome bug about inconsistent unit labels has developed a life of its own.

I also take issue with how this was proposed in the first place. You invited one WebKit committer to the feature document some number of months ago, and made a bug in Bugzilla without providing further context (yknow, like the big feature document with alternatives spelled out). Please email webkit-dev if you'd like opinions that represent the entire WebKit community.

It would be great to bring this topic to the Browser Tools and Testing working group, which includes a wider set of perspectives than people cc'd to this bug. Perhaps a colleague could introduce and discuss a resolution regarding SI units. I'd love to see it. I'm not going to spend any more time arguing in Bugzilla about this.

[Mathias Bynens]

(In reply to Brian Burg from comment #12)
> Your own feature document shows
> skepticism about this change, noting that the authoritative references are
> simply Wikipedia articles and the Apple HIG. Not exactly a compelling
> argument to me, but to each their own.

It sounds like we’re conflating two different things here. In Chrome we wanted to unify the way we represented units, since we were mixing 1024 and 1000 with incorrect labels. The doc outlines the two ways to go about fixing this: either use 1024 consistently with correct labels, or use 1000 consistently with correct labels. The labels and their meanings are well-defined and aren’t controversial.

The controversy seems to be about the choice between 1024 vs 1000-based units, which is understandable (because of personal preferences). It’s interesting to me that one of the reasons we went with 1000-based units is Apple’s HIG, yet here we find Apple engineers arguing against the HIG — definitely not what we expected.

> Other attempts to use SI units in web
> standards (i.e., to add to TC39) and tooling also haven't gone anywhere.

Could you elaborate? The opposite is true for e.g. Intl.NumberFormat (TC39), which supports 1000-based units, but doesn’t support 1024-based units: https://github.com/tc39/ecma402/issues/449 The same is true for the Unicode CLDR where locale data for these various units is defined. Did you get that backwards or were you thinking of a different example that goes the other direction (I don’t know of any)?

[Paul Irish]

(I'm mostly uninvolved with DevTools stuff these days, but I've been involved in this discussion as Lighthouse TL)

Back in June when this conversation really started getting going, I emphasized the ecosystem impact. Because, of course, it's not desirable to make a change that creates inconsistent measurements across tools. 

There's really three options in handling this:

Option A) Use 1000 and label as KB
Option B) Use 1024 and label as KiB
Option C) Use 1024 and label as KB

I initially thought "Is Option C really that bad?" but later realized that approaches violates all relevant Standards of units (since ~1998). https://en.wikipedia.org/wiki/Binary_prefix

The general consensus is that A and B are fine, but C should be avoided.

( There's also a great document where Ubuntu did this same soul searching: https://wiki.ubuntu.com/UnitsPolicy )

[Nikita Vasilyev]

Created attachment 422852 [details]
Patch

Rebaselined.

[Nikita Vasilyev]

(In reply to Paul Irish from comment #14)
> Option A) Use 1000 and label as KB

Did you mean kB (lowercase "k")? SI Units have the lowercase k and this's what Chrome DevTools are using.

[Nikita Vasilyev]

I was reminded that macOS uses KB (uppercase K) so I'm going to use that. I know it contradicts SI Units.

[Nikita Vasilyev]

Created attachment 423543 [details]
Patch

[Blaze Burg]

Comment on attachment 423543 [details]
Patch

r=me

[EWS]

commit-queue failed to commit attachment 423543 [details] to WebKit repository. To retry, please set cq+ flag again.

[EWS]

Committed r274680: <https://commits.webkit.org/r274680>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 423543 [details].