- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Nov 2013 07:24:06 -0500
- 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