add saveData attribute to NetworkInformation

[igrigorik]

Attribute reflects value advertised by Save-Data header defined by Clients Hints specification.

Open questions to address:

• Should saveData attribute be mapped 1:1 to the value advertised by the Save-Data HTTP header?
  • Keeping them in sync is nice, but on the other hand, may not map to the nicest JS API.. Right now you'd have to do "on" string comparisons.
  • Currently, Save-Data only registers a single token ("on"), but we wanted to reserve the option of extending this in the future, so reducing this to a boolean value is probably unwise.. Then again, if we don't map header value and JS APIs directly, we could expose different attributes in JS-land for each header value.
• Should changes in saveData value fire onchange event?

As an aside, it may also make sense to migrate Save-Data definition into this spec, instead of defining it in CH; that way we can spell out the processing and interop between them more cleanly.

Closes #42.

/cc @tarunban @jeffposnick @marcoscaceres @bengreenstein

---

Preview | Diff

[bengreenstein]

While I think "if (saveData === 'on')" is a little less elegant than "if (saveData) {...}, " I don't want to paint ourselves into a corner. I can easily imagine adding the value 'extreme' in the future.

I think a change in the saveData value should fire an onchange event, as some people do toggle the Data Saver setting in Chrome a fair bit.

[igrigorik]

While I think "if (saveData === 'on')" is a little less elegant than "if (saveData) {...}, " I don't want to paint ourselves into a corner. I can easily imagine adding the value 'extreme' in the future.

Technically, it doesn't have to. We can easily expose different JS-land attributes for each enum value, instead of asking developers to compare strings. Also, stepping back, do you envision more values in the header, and what would they be?

I think a change in the saveData value should fire an onchange event, as some people do toggle the Data Saver setting in Chrome a fair bit.

sgtm.

[bengreenstein]

So you're saying do something like "if (saveData) { if (saveDataExtreme) { ... }}" ? That seems fine to me.

[bengreenstein]

The only additional value we've considered is something along the lines of "extreme" to indicate that data is extremely expensive (e.g., when roaming) and so the absolute minimal page should be served. This is in contrast to "on," which indicates that the user is still interested in an almost full fidelity page, but would appreciate data reductions that don't interfere too much with the experience.

[igrigorik]

Interesting. What's the current thinking for where and how we'll obtain the "extreme" signal? User setting, platform / OS signals, other means? I see a few options for how we can interpret them:

1. We can keep ~saveData and ~expensiveData as separate attributes.
   • Q: would we ever have the case where expensiveData=true but saveData=false? E.g. what if I'm roaming but really want the super high-fidelity photo download?
2. Or, is ~expensiveData=true implicitly means that saveData=true?
   • If that's the case, then perhaps an enum does make more sense.

[bengreenstein]

I was thinking that the browser would convey how much data savings is desired, not how expensive the data is. So if saveAsMuchDataAsPossible is true, saveData should also be true. I also think we should not all saveAsMuchDataAsPossible=true, saveData=false, because many sites will only have one data saving implementation. If that implementation isn't extreme, the site could just check saveData. If it is extreme, it could check saveAsMuchDataAsPossible.

We could instead attempt to surface how expensive the data is, but I'm afraid the best we can do now is to use heuristics or classified a user's historical data use, which would be extremely coarse.

[igrigorik]

Hmm ok. Sounds like we want saveData as a boolean then, not an enum, plus an additional property communicate the "severity"...? In theory, doesn't effectiveType hint at this already?

if (navigator.connection.saveData) {
  if (navigator.connection.effectiveType == "slow-2g") { 
     // super duper compression 
  } else { 
    // ...
  } 
}

Translating above to headers, we might have:

Save-Data: on;slow-2g

Given that we already expose ECT, do we need any additional signals?

[bengreenstein]

An effectiveType slower than 3g indicates a need for super duper compression, as does an actual connection type of 2g, but there are likely many other signals that could contribute to a need for it, e.g., a user setting. All that said, I think a boolean is fine for now and we can invent an additional property to communicate severity if we eventually need it.

[igrigorik]

@bengreenstein updated, ptal.
@mnot per discussion earlier, also moving Save-Data definition into NetInfo -- ptal.

[mnot]

lgtm

[igrigorik]

Thanks Mark! @bengreenstein @tarunban any feedback on your end?

[bengreenstein]

lgtm

[tarunban]

'on`: Should not the attribute value be true/false (same as in the request header)?

[igrigorik]

No, these are distinct. "on" value in the header is mapped to saveData == true, and all other values to "false".

[igrigorik]

Thanks everyone for reviews and feedback, merging.

[tarunban]

Comment below.

[tarunban]

lgtm