Add 'mobile' client hint to explainer and spec

[amtunlimited]

Add a boolean "mobile" client hint to the explainer and spec, which should cover a very large use case while revealing less entropy and acknowledging user preferences on the matter.

Possible questions include:

• is this the right name for the header?
• is a boolean the right call?
• should there be a more rigid or specific definition of "mobile"?
• does anything else need to be edited other than the specific values (and the FAQ)?

[miketaylr]

Browsers distinguish between more than just Mobile or not Mobile -- there are also VR (and sometimes Mobile VR (some oculus and samsung devices) and TV <devicecompat> tokens (my phrase, I think Samsung calls it "UX RECOMMEND") in user agent strings, depending on form factor. Rather than a new boolean for each of those, it's probably better to abstract over that, if this extension seems useful.

[mikewest]

Framing it in terms of UX recommendations might make sense. I like that semantic more than "This is mobile."

I wonder what granularity we could reasonably provide by default, though. This hint only makes sense if we're sending it by default, as developers can of course request actual viewport information directly. I worry that too many buckets will add enough entropy to make it unlikely we'd benefit users by shipping this without an opt-in.

[amtunlimited]

I was considering this too; making an enum or list of values as opposed to just a boolean. I liked that it was just one bit of information, but it may not be useful.

I do agree with @mikewest that if we make it an enum or even just a string, the balance of of entropy to usability will be rough. I also worry that feature creep might turn it into a mess of different values, way too specific values, and general compat mess.

There's also the issue that if someone decides to make a new value, no one else will use it and the default might be more or less useful than another more popular option (like if you're on a TV and the "mobile" version might be more useful the "desktop" version).

We could set up a preference order (like font-families in CSS), although that might make for more fingerprinting (?) it would make graceful failing of unknown values better.

[yoavweiss]

@amtunlimited - Can you join the WICG and link your GH account with your W3C one to appease the IPR bots?

[amtunlimited]

@amtunlimited - Can you join the WICG and link your GH account with your W3C one to appease the IPR bots?

Done

[amtunlimited]

@yoavweiss I appeased the bots. Sorry it took so long, I didn't realize you had to manually re-validate (and log in to do so)

[mikewest]

Would you mind reformulating this PR against https://github.com/WICG/ua-client-hints/blob/master/index.bs? We're moving out of IETF and into Bikeshed... should be simple to pull it across, but apologies for the inconvenience!

[amtunlimited]

No worries. It seems to be just markdown with some sugar on it, yes?

[mikewest]

Yup. Just a different kind of markdown than before. You should be able to copy and paste the sugary bits from the other header definitions. Thanks! Sorry!

[amtunlimited]

That ought to do it? Had a weird merge conflict, I think it didn't like that I rebased in a weird way? IDK, but we're good now. Check my bikeshed though, I'm just going by example.

[mikewest]

There does seem to be some merging weirdness. The diff looks very strange... I'll see what I can do about cleaning it up.

[yoavweiss]

I pushed some small changes directly this morning, just to test the travis auto-publish setup (spoiler: it is not working). If that's the source of weirdness, feel free to nuke them

[mikewest]

I noticed. :)

I merged this manually. Hopefully we didn't lose anything interesting along the way...