Re: Review of IndieUI User Context

On Nov 13, 2013, at 1:43 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Nov 12, 2013 at 11:01 PM, James Craig <jcraig@apple.com> wrote:
>> 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);
>>   }
>> }
> 
> Exposing color lightness via a MQ makes sense.  I don't think
> saturation does, though.

I’m sure I could come up with an example, but I readily admit that -hue and -saturation wouldn’t be as commonly useful as a luminosity check.

> Note as well the automatic-contrast function newly defined in the
> Colors module: <http://dev.w3.org/csswg/css-color/#contrast-adjuster>
> This isn't a replacement for the ability to test luminosity (your
> example of background-images makes that point well), but in concert
> with the user-pref() value it can do some adjustments automatically:
> 
> .foo {
>  background-color: user-pref(background-color);
>  color: color(user-pref(background-color), contrast(100%));

Is the intention of this property to set the foreground color to the farthest away from the background color? Which value would contrast(50%) choose? Any non-zero or non-100 value seems ambiguous.

>  /* Black or white, depending on which contrasts more. */
> }
> 
>>> * '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.
> 
> I don't understand.  You seem to be arguing that it would be difficult
> for the UA to un-invert things.  If that's the case, wouldn't it be
> *even more* difficult for the author to do so?

No, I’m saying it’d be difficult to *prevent inversion* of some pixels on screen, because the process doing the inversion usually has no concept of separate layers or elements within the view. It’s trivial however, for a web author (or user agent for that matter, see below) to *double-invert* certain elements. If the UA can implement a “prevent inversion” by double-inverting, that is fine but I still see the usefulness in the “inverted” MQ.

>> 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;
>>   }
>> }
> 
> Hm, okay.  Is it common/good practice to remove excess decorations
> when a user invokes color inversion like this?

I must’ve forgotten the explanation example’s text that I added to the draft:

“In this example, the hardware display rendering is inverted, so the web app could hide elements styles that resemble "shadows" of physical light, which by default look like white glows while inverted. This media query allows authors to disable settings that don't make sense when the physical display pixels are inverted.” 

While there is not yet any “common” practice around or consensus of what is “good” to do in this situations, it does seem reasonable to disable certain elements of decoration, such as those that mimic effects that no longer make sense on an inverted display, such as drop-shadows, inset styles, etc.


>>> (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.
> 
> Inversion being handled in a common way today doesn't mean we should
> bake the assumption in forever, nor is it particularly reasonable imo
> to prefer having authors use a roundabout re-inverting solution rather
> than simply expressing the semantic of "this is a significant image
> that should stay unaltered" directly, and letting the UA take care of
> it.
> 
> In particular, note that a naive use of 'filter' to re-invert would
> wipe out any *other* filters you might be using, because that's how
> CSS works.  Having it expressed via a separate property, even if it's
> implemented by just invoking the invert filter, means that it doesn't
> interfere with other unrelated uses of 'filter’.

Okay, I can see the benefit for a separate “don’t invert this” property, but I don’t think that precludes the usefulness of the media query.

>>> * '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 */
>>        }
>> }
> 
> No, I actually think it's a bad idea, for a few reasons:
> 
> 1. You probably don't want to create the subtitle area unless the
> video is actually playing.  Your example code would add an empty
> subtitle area to every video regardless of play state, just because
> the user indicated in their preferences that they want subtitles.
> 
> 2. You can't rely on the above code to work - the user might turn on
> subtitles for a particular video without turning on a browser-wide "I
> want subtitles" pref.  You're going to want to hook the
> subtitle-area-generation to the code that actually displays the
> subtitles.
> 
> 3. Custom subtitles are going to be driven by JS anyway.  Adding a
> tiny bit more work to the JS rather than the CSS side on initial setup
> isn't significant.

Okay. I’m willing to drop this one in favor of using the JavaScript interface.


>>> '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.
> 
> Oh yeah, further feedback I forgot about: I have no idea what "sdh",
> "cc", or "default" subtitle types are, nor how I should respond to
> them.  These values (when exposed to via the JS API) should have
> better names and descriptions, and examples of what you would do
> differently based on the two values.

From the ED: “Necessary to match preference for subtitles for the deaf and hard of hearing (SDH) over default dialogue-only subtitles, but the preference for closed captions (CC) versus SDH may not be necessary. SDH appears to be generally preferred over CC when available, and a preference for SDH could indicate an implicit preference for CC over dialogue-only subtitles when CC is available but SDH is not.” 

SDH = Subtitles for the Deaf and Hard of Hearing.
CC = Closed Captions
Default = language-only subtitles. For example, watching an foreign-language movie with subtitles in your native language. 

Note: language-only subtitles do not include sound cues such as “[dog barking]” or “[gun shots fired]” that are useful to those with hearing impairments.


>>> 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.
> 
> Actually, based on discussion with the MQ editor yesterday, if it's
> possible to come up with keywords for the values, please do so
> instead.  The MQ false keyword is "none", and anything else is truthy.
> 
> In general, CSS abhors boolean values, because they never stay boolean for long.
> 
>>> 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;
> 
> Note that I was talking about a function, so you'd write something like:
> 
> color: user-pref(color);
> word-spacing: user-pref(word-spacing);

Indeed. My mistake.

>>> 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.
> 
> I don't believe this has been successfully established.
> 
>> On behalf of myself and the other members of the IndieUI WG, thanks for the review. It was very helpful.
> 
> No problem!  Thanks for coming to the WG for review early. ^_^
> 
> ~TJ
>

Received on Thursday, 14 November 2013 02:18:27 UTC