Re: Review of IndieUI User Context

On Wed, Nov 13, 2013 at 6:17 PM, James Craig <jcraig@apple.com> wrote:
> 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:
>> 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.

Read the spec. ^_^

First it determines whether black or white is more contrasty, using
the WAI definition.  This is the result for 100%.
Second it draws a line between the base color and the 100% color in
HWB space, and finds which point on that line has a minimum acceptable
contrast (ratio of 3.5).  This is the 0% color.
Values between 0% and 100% are interpolations between these two
colors, in HWB space.


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

My point was that if it's possible for the author to re-invert, then
it's possible (and more straightforward and future-compatible) for the
UA to re-invert.  Thus, I found it strange that you were using an
argument about UA difficulty to argue against putting it in the UA's
hands.


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

Okay, this makes sense.


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

Right, I read that, and it doesn't help me understand the differences
between the categories, or what they mean in terms of what I should be
doing.

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

These descriptions don't help me tell the difference between SDH and
CC.  You're forgetting that most people have very little experience in
captioning, so these words don't mean much of anything. ^_^

That note is precisely the kind of thing that's useful.  It helps
distinguish between "default" and the others, at least.

~TJ

Received on Thursday, 14 November 2013 03:54:38 UTC