W3C home > Mailing lists > Public > www-style@w3.org > November 2013

[CSSWG] Minutes TPAC F2F 2013-11-11 Mon II: IndieUI Presentation

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 20 Nov 2013 07:24:06 -0500
Message-ID: <CADhPm3vk_ueOp=_n0xfBBamYK21B_-qjFZ9j8E_W4B+qJ-ndcg@mail.gmail.com>
To: www-style@w3.org
IndieUI Presentation
--------------------

  - IndieUI joined the meeting to present on some of their work on the
         User Context model and how they want to use Media Queries in
         their work.
  - The main case discussed was inversion and double-inversion of
         images, especially for a11y preferences.
  - Privacy concerns were also raised and a desire was expressed to keep
         the user's data secure from applications that didn't need
         preference information.  It was suggested that European privacy
         standards should be followed as they're the most comprehensive.
  - The working group will come up with a complete response in the next
         two months-ish.

=====FULL MINUTES BELOW======

IndieUI Presentation
--------------------
  ScribeNick: fantasai

  plinss: IndieUI is joining us for a presentation.

  Janina: Thanks for allowing us time.
  Janina: We have been working on 2 modules. We want to talk about today
          the User Context model, which will allow applications to
          convey key things based on user prefs.
  Janina: Recently Apple came up with a suggestion that we really liked
          to use Media Queries.
  * fantasai notes that this was suggested several TPACs ago
  Janina: We like it for many reasons.
  Janina: And James Craig has been redrafting our document, and will
          provide examples.
  Janina: Once phone the starts working, we will ask James to present on
          how we propose to use Media Queries.
  Janina: We want your reactions to this.

  Janina: We're fine if we maintain the spec or if migrate to another
          spec.
  * sgalineau IE10 uses media queries to detect high-contrast user
              prefs...

  * TabAtkins F--k it, let's either do IRC or reschedule.
  * TabAtkins Not worth trying any more.

  [discussion of phone problems]

  <richardschwerdtfeger> ok. moving to the PF room

  <jcraig> Clarifying, this was a joint WG agreement to switch to media
           queries. Ted and I (Apple) came up with a restrictions/
           privacy/anti-fingerprinting proposed extension to
           MediaQueryList and @media.
  <jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#colors-inverted

  hober: I can pretend to be James for a minute.
  hober: One concrete example from user Context spec that makes more
         sense as MQ is display-colors-inverted.
  hober: To handle the case where for a11y reasons, you have system-wide
         color inversion,
  hober: Most of the time it should be invisible to page.
  hober: It breaks down for content images and some background images,
  hober: So that people look in normal colors, not like aliens.
  hober: Double-inverted MQ allows author to double-invert images so
         they come out right.

  <TabAtkins> I talked to our own a11y people about
              display-colors-inverted, and support it.
  <TabAtkins> I thought we could just auto-invert pictures/videos, but
              apparently a bunch of "little" images, like icons and
              such, should stay inverted like the text they're next to.
  <TabAtkins> Only significant/"content" images and videos need to be
              re-inverted back to normal.

  <dbaron___> Though Ted's use case sort of depends on knowing the exact
              inversion in order to re-invert.
  * sgalineau if I recall the IE model, high-contrast disables
              background images and such by default but you can use an
              MQ to specify them, or use images better suited to the
              context...

  fantasai: I would prefer we could tag images as not to be inverted,
            and the UA should handle it.

  hober: Using CSS filters to undo inversion seems natural
  hober: Authors are in the best position to know whether an image
         should be re-inverted.
  hober: MQ just has two keywords, inverted and none,
  hober: But if you wanted to cover different forms of inverted, you
         would need more keywords.
  hober: MQ should then only match systems that have form of inversion.
  plinss: That seems fragile for me, if there are different types of
          inversions.

  <dino> It's not clear to me that system-inversion is the same as CSS
         filter invert()
  <TabAtkins> I like fantasai's suggestion of tagging elements as not
              invertible.

  <jcraig> Before we get into specific discussion of individual MQ
           features, I would like to summarize the approach if
           rescheduling to a working phone bridge is not an option.
  <jcraig> Let's don't get hung up on inversion algorithms yet.
  <jcraig> First of all, from the intro: "The specification below adds
           several new "Media Features" to detect user settings, using
           existing syntax defined in the CSS3 Media Queries
           specification, and provides an access control extension to
           the MediaQueryList interface defined in the CSSOM View
           Model."
  <jcraig> "Because this approach relies so heavily on features that
           overlap with work maintained by the CSS Working Group and Web
           Applications Working Group, it is likely that portions or all
           of this specification may move under the purview these other
           groups. At a minimum, the IndieUI Working Group requests
           guidance and a collaborative working relationship with CSS
           and WebApps."
  <jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#intro

 <dbaron> for alternative color inversion, see
          http://dbaron.org/mozilla/invert-colors#http://www.w3.org/ in
          Firefox.

  fantasai: While I support MQ for a11y preferences in general, I don't
            think this particular case is best handled by MQ. I would
            rather enable tagging images that shouldn't be inverted and
            let the UA handle that as appropriate.
  hober: Would you allow tagging background images?
  fantasai: Think it should be general to all images.
  fantasai: Yes.

  [dbaron reads jcraig's comments aloud]

  krit: One point, double-inversion can be done with filter function,
        but I agree with fantasai that shouldn't do the double-inversion
        for the browser, but have the browser do it.
  hober: ...
  krit: There shouldn't be content images in style.

  fantasai: It's not so much content vs not content in this case, but
            maybe photographic vs not photographic, etc.
  janina: Bar chart might want inverted, but not ...
  fantasai: Also might want to invert luminosity but not hue in the bar
            chart, if talking about colors in the paragraph text nearby.
  janina: The ability to control that definitely a plus.
  <dbaron> Though inverting luminosity but not hue is actually kind of
           hard -- if you want to preserve hue you need to either
           sacrifice accurate luminosity or accurate saturation.
  <ChrisL> in fact, dbaron inverting lightness is relatively easy.

  fantasai: We have a need to tag images for bidi already, so whatever
           syntax we use for that can be used with this (with additional
           appropriate keywords)
  jcraig: Want to discuss general idea of ? MQ

  <dsinger> This general idea was first floated around 2007 (oof), on
            the WhatWG list and socialized some time around then with
            CSS
<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-June/011709.html>


  <jcraig> The general idea is that sometimes user-specific settings are
           needed by web apps. Large document suites like Google Docs
           and iWork for iCloud are examples of this, where they can
           improve the experience for all users if the app is provided
           with specific user settings, allowed by the users.
  <jcraig> But there are real privacy and fingerprinting implications to
           this.
  <jcraig> For example, not all web pages should know if a screenreader
           is running, just like not all pages should need to know your
           location.
  <jcraig> So the general concept is that there are media feature groups
           that can be restricted (some specific to accessibility, some
           not).
  <jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#example-restricted-call-to-matchmedia
  <jcraig> If someone in the room could read my IRC comments out loud?
  <jcraig> In this example:
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#example-restricted-call-to-matchmedia
  * dsinger to James, yes, we can read for you

  [fantasai reads James's comments from irc]

  <TabAtkins> I'm supportive of the general approach, but unsure about
              the precise mechanics. Several of these appear to be best
              done as special values, etc.

  <jcraig> If a site author requests access to a "restricted" media
           feature, matchMedia and @media alway return the default value
           immediately (don't expose user prefs or privacy),
  <jcraig> But then the user is prompted, and the web app can get an
           asynchronous callback when the setting becomes allowed via
           addListener or a subsequent call to matchMedia.
  <jcraig> The specifics of the proposal are rough, but we think the
           general idea of the privacy model is sound.

  <TabAtkins> Privacy model seems interesting. So, how do you get
              permission to access this stuff? On first use, pop a
              request bar? Explicit JS request? Only explicit user
              action?
  <jcraig> TabAtkins, on first request to mql.matches... or first time
           @media block (and a rule inside it match)
  <TabAtkins> Okay.

  <jcraig> Todo from the spec: Explain how the privacy model works: when
           user prompted, matchMedia returns false immediately, and only
           provides the updated match asynchronously through
           matchMedia().addEventListener or subsequent requests to
           matchMedia().matches (e.g. on page reload) so there is never
           any detectable difference between "No" and "You don't need to
           know." A restricted @media block never prompts unless both
           the @media block and an included selector matches.

  [During the IRC conversation above, a phone solution was developed]

  jcraig: Before specifics of individual media features, general idea is
          web app [echo]
  jcraig: Specific media feature, idea is that there are,
  jcraig: Categories of features that user may not want everybody to
          know about,
  jcraig: Such as things such as disabilities,
  jcraig: Or specific media features.
  jcraig: But there are also some that are less strict,
  jcraig: Which can be currently determined by creatively using CSS and
          JS.
  jcraig: But we thought to make those as media feature as well.

  jcraig: If you have an @media block with a particular rule, e.g.
          @media (subtitle)
  jcraig: It would match whether you have specific setting on.
  jcraig: If you got @media block and rule inside of that,
  jcraig: If the page matched that user setting, and had matching
          selector, then you would get a user prompt at that time.
  jcraig: The web page would return default value until user accepted to
          reveal actual prefs.
  jcraig: The user could set prefs for specific rules,
  jcraig: E.g. any feature related to audio/video, or related to
          screenreader, or related to color settings.
  jcraig: These could potentially expose user to fingerprinting /
          privacy concerns.
  jcraig: We would like CSS and WebApps to allow these queries, but in
          ways that don't expose undue privacy leaks.

  <TabAtkins> The @media "only request if there's an matched element"
              isn't a significant restriction. @media (foo) { * {} } is
              easy.
  <TabAtkins> I could see the prompt saying "This page wants to know
              about your accessibility preferences. Allow/Deny?".
  <dsinger> Being asked on every page that contains media that can adapt
            would (I hope, since all media pages should be accessible)
            quickly get annoying.
  <TabAtkins> dsinger: If you want to allow it for all pages, you should
              be able to set it to always yes.
  <jcraig> Re: annoyance. If a user did not care whether every site knew
           they wanted captions, they could allow that feature category
           to all websites.
  <TabAtkins> jcraig: Being specific is fine within the context of a
              settings page, but not within the context of a permissions
              grant. You want a minimum of permission requests, worded
              for maximum clarity.
  <dsinger> If the natural result that all users set it to say "yes,
            always" we're not exactly mitigating fingerprinting risk,
            alas.

  fantasai: I think this seems reasonable to me, as long as the spec is
            flexible enough to allow UI innovation.
  <TabAtkins> The spec needs significant review for idiom use, and
              several of these MQs should instead be values or otherwise
              handled within normal CSS (such as the color prefs), but
              otherwise it seems broadly okay.
  <jcraig> Thinks it should be more specific than just general
           "accessibility" settings. There are categories that a user
           could choose to expose.

  jet: So, authors for many years have sucked at writing accessibility
       features, and people who need those features pick specific UAs
       that will give them consistent presentation from site to site.
  jet: Allowing author to implement those seems antagonistic to users
       who need those features the most.

  jcraig: If someone wanted to share, you should be able to do that from
          browsers.
  jcraig: "allow all"
  jcraig: The flip side is location sharing, where prompt for location
          settings is not needed on most sites, but it's needed for
          specific sites like maps.
  janina: You might want to define it once and use it in various
          different UAs.
  Jason: Presumably the proposal would have common formats for storing
         it and so that UAs can then retrieve that info on behalf of
         user as required. That would extend the work somewhat.
  Jason: MQ syntax for expressing user's individual prefs, secondly
         existing APIs for interrogating that info, then potentially a
         format for storing and enabling UAs to retrieve it.
  Jason: The could be a layer on top of that.

  <TabAtkins> That sounds far beyond the concerns of CSS. We should just
              be worrying about the stuff themselves.
  <TabAtkins> Hahaha, the actual features.
  fantasai: I agree with Tab, that seems like an OS-level feature,
  fantasai: Not something to standardize here.
  <jcraig> what seems like an OS feature?
  <TabAtkins> jcraig: The specification of preferencess in a
              browser-agnostic way.
  <TabAtkins> jcraig: /sharing of prefs across browsers.

  fantasai: So what I've heard so far is that jcraig wants to make sure
            that an MQ approach is in general OK.
  fantasai: And we have some concerns about individual features being
            better handled in other ways than MQ, but others are OK
  Bert: Approach is good, but we haven't looked at individual properties
        yet.

  <jcraig> As an example, -ms-high-contrast proposal is clearly within
           the scope of CSS MF, but it potentially exposes users to
           privacy/fingerprinting. So I think the privacy model goes
           hand-in-hand with the CSS features.
  <TabAtkins> Several of these are best as values, perhaps a
              user-pref(<ident>) function.
  <jcraig> It should be part of CSSOM.
  <TabAtkins> And we can hang an API off of window.CSS for querying them
              directly (triggering the permissions grant - this needs
              some more thought).
  <TabAtkins> user-pref(foreground-color), etc.

  fantasai: Think we agree with the general approach, but want to review
            more closely individual features to make sure they are best
            handled as MQ, or should be handled otherwise.

  Rich: How do people feel about named groups?
  Bert: Can you explain what that is?
  <jcraig> Example:
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html#userMediaSettings

  <TabAtkins> I think the named groups are more of a "browser/OS
              categorization suggestion" thing.
  <TabAtkins> Like I said, I think that the permissions prompt should be
              a once-and-done thing.
  <TabAtkins> While permissions might be perma-granted in a granular
              fashion in the settings page, a request for currently-
              ungranted prefs should grant everything.
  <TabAtkins> This kind of info *should* be specified in the spec, but
              it's less of a concern for the CSS things themselves,
              except insofar as we need to make sure there is *a* sane
              way to request permission for these.
  <TabAtkins> Anything else is user-hostile, though I recognize the
              potential weaknesses.

  ?: Media features are grouped, and if any one of those features are
     prompted for, the user will get one prompt, otherwise different
     prompts.
  fantasai: I think how the prompts are categorized should be up to the
            UA
  jcraig: ...

  jcraig: The specifics of proposal are rough, but general model is
          sound.
  Katie Haritos-Shea: Whatever is decided we should follow European
                      privacy model.
  Katie Haritos-Shea: European privacy and APEC model works for ... US
                       model ...
  rich: do you have a link to these models?
  Katie Haritos-Shea: iapp.org
  <ChrisL> http://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications

  fantasai: Any further comments?
  <jcraig> I think it can work within the existing API for matchMedia
  <TabAtkins> I'm willing to do a spot review of the spec and present
              conclusions to the WG.
  <jcraig> We meet with WebApps about the same topic later today.

  [discussion of timelines]

  fantasai: When would you like to assign an action to the CSSWG to
            review your draft?
  <jcraig> Tab has agreed to review the draft.

  janina: Probably before FPWD, maybe Jan/Feb? James?

  * TabAtkins If I review, what a11y mailing list should I send comments
              to? There are too many a11y lists. >_<
  <jcraig> public-indie-ui

  ACTION csswg to review User Context Module

  <jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html

  <trackbot> Created ACTION-593 - And csswg to review user context
             module
https://dvcs.w3.org/hg/indieui/raw-file/default/src/indie-ui-context.html
[on Tab Atkins Jr. - due 2013-11-18].
  plinss: Timeframe on feedback?
  fantasai: next 2 months, I heard
  janina: Sounds fine. We're loose on timeframe, since working to finish
          events thing.

  <jcraig> thanks for your time, everyone.
  rich: Thank you.
  plinss: That brings us to lunch, then DigiPub joint meeting.

[Lunch Break]
Received on Wednesday, 20 November 2013 12:24:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 20 November 2013 12:24:34 UTC