Re: Review of IndieUI User Context

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.

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%));
  /* 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?

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

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

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

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

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

>> 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 Wednesday, 13 November 2013 21:44:20 UTC