Re: Review of IndieUI User Context

Thanks for the review. Responding to the individual points inline.

On Nov 11, 2013, at 10:11 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> 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.

As noted on each of the color media queries: “Need to determine how to match color hue or value ranges (potentially via HSL) so that we could expose min/max on colors. Otherwise, this may not be usable.” 

The HSL note meant I was thinking this could be achieved by adding checking “less than” or “greater than” on a particular aspect of a color. This could potentially be implemented by adding media query color suffixes, such as -hue, -saturation, and -luminosity/lightness, in the same way we add the prefixes min- and max- to numeric MQs. So the media query of this particular feature could be (using the new “greater/less than” syntax you mentioned after the meeting):

/* default to a black logo on light background colors */
.logo {
   background-image: url(./logo_black_on_light.png);
}

/* …but if the user background color is especially dark */
/* switch to a white logo that looks better on dark background colors. */
/* For reference, luminosity 0 is black, 100 is white. */
@media (user-background-color-luminosity < 40) { 
   .logo {
       background-image: url(./logo_white_on_dark.png);
   }
}


> * 'colors-inverted' should not be a MQ, as the intention of "don't
> invert this" should be addressed as a property/value in CSS.

You might be thinking of this in relation to Microsoft’s “high contrast mode” which is not the same as “display inversion.” 

A separate concept of “don’t invert this” is insufficient for a few reasons.

1. Display inversions are usually in low-level display code many steps removed from the rendering engine. If you were to suggest a CSS property for this, it would require the rendering engine to calculate and expose bitmasks of pixel data, potentially each with an algorithm of instructions detailing how to uninvert those pixels, since the rendering engine is not the process doing the inversion. 

2. Second, the colors-inverted media query would be useful for more than just double-inverting foreground content images. I added another example that more clearly illustrates this.

@media (colors-inverted) {
   .page {
       box-shadow: none;
   }
   .pagecurl {
       background-image: none;
   }
}


> (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.)

While it is true that there are other ways to modify colors, the common lexical use of “invert” means the same thing in a majority of OS and common software programs. Other types of color manipulations are possible, but they are not referred to as “inversion” in the common vernacular, and those other types of manipulation can be handled in CSS by other means, such as high contrast mode, user colors, etc.

Some justification that the terms “inverted” and “inversion” are common vernacular meaning this particular type of color modification.

	Microsoft Windows Magnifier, “Turn on color inversion” 
	http://windows7themes.net/quickly-invert-colors-on-windows-8-using-the-magnifier.html

	Apple iOS, “Invert Colors” 
	http://www.apple.com/accessibility/ios/#vision

	Mac OS X, “Invert Colors” 
	http://www.apple.com/accessibility/osx/#vision

	Android “Inverted Rendering” 
	Settings > Accessibility, and find the “Inverted Rendering” 

	Photoshop, “Image > Adjustments > Invert” (also Ctrl+I on Windows, Cmd+I on Mac)

And perhaps most importantly:

	CSS filter-effects: invert()
	http://www.w3.org/TR/filter-effects/#invertEquivalent

Note that the OS examples are straight pixel inversions, usually in low-level code, sometimes on the GPU. These are not the same as high contrast mode or “night mode” features. The original proposed name for this media feature was “display-colors-inverted” to differentiate that this was a low-level display feature, not a user agent setting.


> * 'subtitles’,

You don’t see any value in this example using custom-rendered subtitles? Note: not needed for default WebVTT rendering.

@media (subtitles) {
	video {
		margin-bottom: 3em; /* make room for the custom subtitle block */
	}
	.subtitles { 
		display: block; /* and display it */
	}
}


> '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.

That’s probably fine for subtitle-type and audio-description. 


> 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.

Okay.


> 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.

I support this suggestion, though I think it would be more understandable if they were prefixed with “user-“ such as:

	color: user-color;
	word-spacing: user-word-spacing;

Instead of the unprefixed versions, which seem confusingly vague.

	color: color;
	word-spacing: word-spacing;


> 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)

Okay, this is very similar to our previous approach (window.settings.valueForKey()), so I’ll bring some of that back where the MQs don’t make sense.

A snap shot of the old version can be viewed here:
https://dvcs.w3.org/hg/IndieUI/raw-file/6644d04a01df/src/indie-ui-context.html


> 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.

This won’t work for the reasons I listed above.


> 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.

Agreed on recommending simple user defaults.


> 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.

Okay.


On behalf of myself and the other members of the IndieUI WG, thanks for the review. It was very helpful.

James

Received on Wednesday, 13 November 2013 07:02:24 UTC