User Queries

Orde Saunders' avatar Updated: Published: by Orde Saunders

In the CSS breakout session at Edge Conf the idea of user queries was discussed. There seemed to be a consensus that this was something that was worth progressing so here are my thoughts on the matter.

What are User Queries?

The twitter pitch for user queries is: "Like media queries but for user preferences."

With media queries we get information about the device and possibly it's immediate environment via sensors. However, it's next to impossible to infer context based on the information we have available. However, if there was a way for users to express their preferences to us then we would be able to make informed decisions rather than fuzzy inferences.

It's possible for us to implement this on a site-by-site basis, for example some sites present UI that allows users to change the font size or switch to a high contrast theme. More complex sites can have quite detailed preferences but there's no standard way of doing this so, as a user, we have to set it on every site (assuming the site even offers it and we can find out how to do it).

With user queries there would be a number of settings available in the user agent. Presented via a settings UI these would allow users to set certain preferences that were then made available in the runtime in the way media queries provide information about the user agent.

Some example preferences are:

With user queries there would be a set of standardised properties that user agents could chose to implement and developers could chose to support in their code. As, like media queries, these would be enhancements it's not essential that either user agents or developers support the full list of properties.

Suggested syntax

The initial suggestion for this is to follow the @media syntax as that's what inspired this: it's already familiar to developers and it performs a similar function.

body {
  background-color: lightgrey;
  color: darkgrey;
}
@user (contrast: high) {
  background-color: white;
  color: black;
}

It may turn out this syntax isn't practical but it seems to me like a reasonable starting point.

Reference implementation

Normally for a new feature we look for some form of reference implementation and a polyfill to demonstrate the principle. However, we already have something like this in some user agents and we've had it for a long time.

In 'desktop' browsers it's possible to change the base font size and the default font for some families (typically serif, sans-serif and monospace). If we use a relative font-size and a generic font-family in our CSS then the content will adopt the user set values.

This site is built using this principle so if you want to see it in action then - assuming you're using a user agent that supports it - go into the preferences, change the base font size and the default sans serif font and see how the site adapts to those changes.

This isn't a reference implementation of a user query per-se but, at least as far as I'm concerned, it validates the core principles and behaviour of a user query.

Concerns

This is a potential privacy leak, the settings of user preferences are an additional item that could be used to fingerprint users' browsers and possibly even target subsets of users: "If a user has a low bandwidth setting then send them an advert for Super​Mega​Fast​BroadBand(™&©)". However, there are already a lot of identifiers for fingerprinting and user preferences are - by their very nature - opt-in for users. Additionally, like screen size, they are read-only in the user agent's runtime environment which limits the potential for abuse.

User agents could start setting user properties by default and then we wouldn't know if a property was actually set by a user or not and there would no doubt be cross referencing with other user agent characteristics (like the user agent string) to see if we needed to work round a given setting in a given circumstance. Personally I don't think this is a real issue - not only would acting on user queries be opt-in for developers but also at some point we have to start accepting that browser issues aren't something we, as web developers, are responsible for fixing in our code.

There are other concerns that I haven't covered here or even thought of yet but at first pass I can't think of anything that invalidates the principle.

User Context

Update 2015-06-29: @HTeuMeuLeu pointed out there is a W3C working draft for user context that is very similar to this.

Reduced Motion Media Query

Update 2017-01-24: @StuRobson noticed that OS Safari includes a reduced motion media query that is exactly the kind of thing is discussed in this article.

Conclusion

We can't possibly know what all our users want all of the time and different users may even have conflicting needs. What if instead of making assumptions about what our users want we allow them to tell us? As an industry are we collectively mature enough to be prepared to prioritise our users' preferences over our own?