Review of IndieUI User Context

This is a personal review. It has not been reviewed by the CSSWG.

Overall, I approve of and support the intentions and direction of this
draft.  I have significant technical comments, however.

1. Several of the items should not be Media Queries.  Specifically:
  *  'user-color', 'user-background-color', 'user-subtitle-color', and
'user-subtitle-background-color' do not have any reasonable method of
being used as MQs, as there's no reasonable notion of "less than" or
"greater than" with colors.
  * 'colors-inverted' should not be a MQ, as the intention of "don't
invert this" should be addressed as a property/value in CSS.  (Note
that there are several reasonable ways to "invert" a page, such as RGB
inverting, or lightness inverting. It's not reasonable to assume that
there is only one, author-invertible, way of doing so.)
  * 'subtitles', 'subtitle-type', and 'audio-description' should not
be MQs.  They should instead be exposed by a direct JS query interface
(described later in this email).  You can't do much of anything useful
with them in CSS directly, and when you query for them in JS, you can
do all the necessary alternate styling at that point manually.

The remaining MQs of 'user-font-size', 'user-line-height',
'user-letter-spacing', 'user-word-spacing', and 'screenreader' are
fine.

2. The 'screenreader' media query should match the syntax of other
boolean MQs.  MQ4 now defines a specialized <mq-boolean> type, which
is defined as the numbers 0 or 1.

3. Several of the values should be exposed as CSS values directly. I
suggest a user() or user-pref() value which takes an ident, like
"user-pref(color)" for their preferred color (the thing that the
spec's user-color MQ was intended to address).  The function resolves
to its associated value at computed-value time.  I suggest the
following values:

  * color
  * background-color
  * subtitle-color
  * subtitle-background-color
  * font-size
  * line-height
  * letter-spacing
  * word-spacing

I don't think any of these are sensitive information.

4. Rather than shoehorning several things into MQ that aren't useful
for styling just to get matchMedia().addEventListener, we should add a
JS API specifically for the purpose of requesting user preferences.
We could possibly put this under the CSS object, but it's probably
more appropriate standalone.

partial interface Document {
  void getUserPref(DOMString prefName, Function cb)
}

The callback is called immediately with a value; either a UA default
value or, if the user has already consented to share the given piece
of information, the user's preferred value.  It may be called multiple
times with new values at any point.  If it's a sensitive piece of
currently-unshared information, it should ask the user to share.

I suggest the following values for prefName:

  * color
  * background-color
  * subtitle-color
  * subtitle-background-color
  * font-size
  * line-height
  * letter-spacing
  * word-spacing
  * subtitles
  * subtitle-type
  * audio-description
  * screenreader
  * (more as we come up with them)

5. The colors-inverted use case should be handled by a property/value
pair.  We should first have a property which applies to content
elements (<img>, <video>, etc.) and which controls whether the given
element is inverted or not when the user asks for the page to be
inverted.  I don't know what name to use for the property or values
yet, though. :/

Similarly, for CSS images, add a new <image-tags> keyword to the
image() function <http://dev.w3.org/csswg/css-images/#image-notation>
which expresses the same thing.  Again, I don't know what name to use
for it yet, but it'll probably be similar to the property name or
value.

6. The Security section notes that the Color and Type settings
probably aren't sensitive, and thus don't need to be gated by a
security dialog. I agree.  For the remainder, I strongly suggest that
it recommend only a single security dialog to release all of the user
preferences; while a browser can certainly expose more granular
release preferences in a settings page, trying to be granular in a
security dialog tends to achieve the opposite - people get annoyed,
click things away, and end up over-sharing.

7. I don't believe the additions to MediaQueryList are necessary. The
spec already notes that "restriction" is probably not necessary.
What's the use-case for "category"?  I suggest dropping them.

~TJ

Received on Tuesday, 12 November 2013 06:12:02 UTC