- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Jan 2010 00:37:57 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed various problems with color correction.
- CSS3 Color is still waiting for dbaron to finish addressing all LC comments
before CR or PR publication.
- Reviewed message about selectors and security:
http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0051.html
Concluded that doing anything about it is outside the scope of CSS.
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
David Baron
Bert Bos
Beth Dakin
Elika Etemad
Simon Fraser
Daniel Glazman
Brad Kemper
Hĺkon Wium Lie
Chris Lilley
Peter Linss
David Singer
Steve Zilles
Unidentified Microsoft Representative
<RRSAgent> logging to http://www.w3.org/2009/12/09-CSS-irc
Scribe: TabAtkins
Agenda
------
plinss: Anything else on the agenda? (silence) no.
CSS3 Color
----------
plinss: First item, dbaron objected to publishing css3-color
plinss: David, can you summarize?
dbaron: The main problem is that I'm not sure which draft you want to
publish. There are still a bunch of lc comments i need to deal with.
dbaron: Beyond that, I'd like to do what we decided at the ftf and keep
color-correction in.
dbaron: But the main thing is that there's no real draft to publish, and
if we're not keeping color-correction in we need to figure out
what we're going to say
<glazou> who just joined ?
ChrisL: If there are unresolved comments, then resolving them before
publishing is prudent.
ChrisL: In terms of color-correction, there are no implementations that
use that syntax. There are impls that use color management on
tagged images, but those aren't addressed by specs right now.
dethbakin: There's an experimental impl in webkit
bert: It seems that the spec is complete and consistent right now.
It doesn't talk about images, but I don't see how that's necessary.
We can add that elsewhere to another module.
ChrisL: When earlier, when we dropped it, I said "That's a shame, all
these impls are already color-managing." They could implement
the spec, but they haven't. But now that webkit has an experimental
impl, that says we should keep it in and hope for a second impl.
<ChrisL> So if webkit has one implementation, we should keep it in
Bert: I can't remember exactly what color-correction does, but I can only
imagine one thing to do - respect colorspaces and treat untagged as
SRGB
dethbakin: It also refers to css colors, frex.
Bert: But they should be in SRGB anyway.
<ChrisL> The use case is for matching styled content with images
dethbakin: In practice that's not quite true in current browsers.
dbaron: The point of color-correction is to allow users to opt-in to
color-correction until browsers can do that automatically for
everyone.
Bert: But the default should still be srgb, as that's what it's been
for 13 years.
dethbakin: Afaik that's only in spec.
Bert: I'm getting more afraid; I think you want to change CSS 2.1 or
further back?
dethbakin: I don't want to change specs at all. I'm okay with it saying
that they should be corrected to srgb, and so i'm fine to let
authors turn that on per element.
bert: Why not just fix reality?
dethbakin: We can't fix that in Webkit, so we'd just have to go against spec.
ChrisL: It would be helpful to say why "fix reality" isn't feasible.
Is it just color maching with images?
dethbakin: There are images with video, but also images on the mac with
matching to images.
dbaron: Matching untagged images to CSS colors isn't a problem, but
matching colors in plugins are an issue.
<Zakim> +SteveZ
<Zakim> +fantasai
<dethbakin> The major issue for WebKit is performance. Enabling sRGB on
the Mac all the time was a performance regression the last
time we tested.
ChrisL: 2 issues being brought up. 1 is matching different colors together.
Images, video, and css colors. They all need to match. The issue
is that video is not color-corrected.
ChrisL: It uses platform defaults. If you want to match it, you have to
manually correct to platform defualt.
ChrisL: 2nd issue is performance. If you have to do color correction it's
slightly slower.
smfr: Actually maching plugins is a more widespread problem than matching
video.
ChrisL: Yeah, and videos are usually done with plugins, so it means
matching what flash does.
smfr: Distinction between <video> and plugins, so say "plugins" if you
mean it.
ChrisL: Frex, the adobe svg plugin does do color management. But video
gets sent straight to the video chip so there's no opportunity
for color correction.
szilles: So video and plugins are different?
ChrisL: Yes, and there are also plugins which manage and ones that don't.
ChrisL: There's a need to say on a per-element basis to say "this thing
isn't color-managed" because it's more useful to match with
something else next to it, rather than get an exact color.
smfr: You're suggesting an opt-out that says no color management explicitly.
smfr: But that's what browsers do now, and if they switched to mass-managing
to srgb there would be big problems. It should be opt-in.
Bert: The problem seems to be the mac. That's a problem that should have
been used long ago.
ChrisL: You get content that's done on a mac, but then when viewed on
other platforms there are issues with it being too dark.
smfr: I think mac does gamma the same as pcs now.
smfr: Mac doesn't use srgb by default for rendering, it matches the
display's default color space. On windows i think srgb is the
default color space for rendering
ChrisL: So, if you get 4 different macs with 4 different displays,
they'll all display differently?
smfr: They'll look the same because the mac knows the monitor's
display profile.
ChrisL: So it's doing the right thing? It's converting the colors to
the display color space.
smfr: Yeah, srgb talks about the source color space, and then maps to
the display's color space.
smfr: Kind of a historical thing that css colors aren't in srgb by default.
Bert: I think MacIE does it in srgb.
Bert: I remember that IE looked different from Safari.
smfr: We can't just throw a switch and start doing srgb for everything.
Bert: But it's apparently okay if you display colors differently between
macs and other machines. Why not just switch them?
smfr: Because if we did so Macs would suddenly have lots of color
management issues. Since there are lots of design people on Macs,
it's a problem.
ChrisL: You can change the way you display images, and you can change
the way you do css colors. plugins are still the problem;
flash just doesn't do it correctly.
Bert: So is adobe here? Maybe we can change flash?
szilles: (laughter) I will investigate what flash thinks it's doing.
smfr: I don't even think flash has an api to tell the browser what
colorspace it's in.
szilles: We know that if we *did* any change we'd need an api to know
what colorspace it needs to use.
smfr: Seems like a good idea to start that discussion.
ChrisL: And it doesn't even need to be cross-platform, because the
code that does it is platform-specific.
szilles: That only solves half the problem. If the plugin is trying
to match the video, there's still an issue because the video
is going straight through without correction.
smfr: html5 video playback is under the browser's control, and should
be able to be colormanaged if the browser can accept the perf hit.
szilles: I accept that, but what if the author doesn't ask for that?
szilles: I think we're stuck supporting the current world, which is
what Simon says.
<ChrisL> and most video uses rec.709 primaries, which are the same as
sRGB uses?
plinss: While this is useful and productive, it's not addressing the
original topic.
ChrisL: It sorta is. It's addressing what we can change, and therefore
what we can publish.
plinss: Previously we resolved to remove and publish to get it out the door.
dbaron: And before that we resolved to publish it *with* color-correction.
So we have resolutions to do both.
szilles: What's the problem with leaving out the color-correction
propertiees?
ChrisL: The problem is that we're publishing something that webkit
says they can't conform to.
dbaron: And that we have no conformant impls of.
szilles: [something about defualts being ccir601?]
<ChrisL> CCIR 601 http://en.wikipedia.org/wiki/Rec._601
<Bert> (I don't think we ever decided to publish a CR *with*
color-correction. We decided to add it to a WD, then later
decided to take it out and publish a CR.)
smfr: So email from david says srgb matches rec 709. rec 601 and 709
are equiv in transfer function and slightly different in primaries.
ChrisL: is 601 not the same as the old ntsc one that nobody uses?
smfr: Not sure. Discuss later?
szilles: It (601?) claims to be the ubiquitous standard for professional
equipment.
szilles: I find this discussion difficult to hold on the phone, but do
think we should talk about this and get it out the door.
szilles: Was one option to go back to srgb and describe what happens in
the world today?
ChrisL: Right, so 601 is ntsc and *nobody* uses that. In practice
nobody uses it.
szilles: That doesn't necessary follow. They may color-correct to
709 monitors.
<smfr> can the chair move things along?
<ChrisL> nobody uses *the NTSC primaries*. actual content is not
produced using those primaries any more
glazou: I don't think we'll reach any resolution for this right now.
We still have a resolution to release or not.
<ChrisL> http://www.efg2.com/Lab/Graphics/Colors/Chromaticity.htm
Bert: It's a completely implemented spec, but if we don't have consensus
we can't do it.
RESOLVED Don't publish Color module as CR.
fantasai: So, what do I do with the snapshot?
fantasai: Delay it, drop color, add something else?
<fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2009OctDec/0148.html
szilles: Is it clear that there's no solution to color that will prevent
it from going to CR?
dbaron: I think there's a solution to take it to *P*R. CR shouldn't be a
problem. Either way we need to address the LC comments.
szilles: We discovered we're not as far on color as we ethought, but it
still seems worthwile to tie the snapshot to color.
fantasai: So yeah, we need to address the LC comments, but how much time
will that take? less than a week, or longer?
dbaron: Dunno, but I need some time, and I won't have any this week.
fantasai: Is this color-correction thing going anywhere? I don't know
how I can go forward, and don't know how long I should wait.
ChrisL: We need to have a discussion on the list with more details.
We're spinning wheels because we have not enough detail.
<dbaron> I'm ok with publishing css3-color without 'color-correction'
szilles: I was going to suggest a subcommittee with Chris, dbaron, maybe
dsinger, and continue this discussion.
fantasai: Okay. Estimate on time? 1 month? 6 months? 2 years?
ChrisL: Probably more than a month, less than 6 months, to report back
with solid data.
fantasai: So are we holding up the snapshot for that?
dbaron: I'm okay with advancing CSS3 color without color-correction, but
we do need to address the lc comment.
fantasai: Okay.
dbaron: I think I can get to it within the next month.
fantasai: So when the LC comments are done we'll make the decision to
publish as CR/PR
glazou: Elika, your original question was about the snapshot.
fantasai: Yes. If we're going to delay color for a month, that's fine.
But if we're going to hold it up longer than that, we need to
evaluate whether we want to hold up the snapshot.
<ChrisL> SMPTE 170M reflects modern practice in the generation of NTSC
signals and, in some respects, differs from the original NTSC
specification published in 1953; notably in no longer using NTSC
primaries and Illuminant C whitepoint
CSS3 Selectors and Security
glazou: Next item is the "security of css selectors in case of injection
of a style sheet".
<glazou> http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0051.html
glazou: It's not just selectors, but also properties and values.
glazou: The thread was about the injection of external stylesheets
with seamless iframes.
glazou: So if someone could inject and use attribute selectors, they
could steal information.
glazou: Another instance is using positioning or multiple backgrounds
to phish.
glazou: I'm of the opinion that css isn't the problem here, its the
insertion of it into third-party content.
sylvaing: My reading was that the attack surface was increased by
css3-selectors.
sylvaing: All of these things are already issues, though. So where's
the extra attack surface? In html5, or some combination
with css selectors, or what?
<TabAtkins> It's only a problem with pages that are same-origin but
not under the same control.
<glazou> I said a security attribute
<glazou> making a <link> or <style> digest a stylesheet
<glazou> in conformance with a given profile
<glazou> excluding attribute selectors and "harmful" properties could
be a solution
TabAtkins: Would that be an attribute *on* the <link>/<style>?
TabAtkins: Because it's not an issue about you unwittingly using
someone's else's malicious CSS, it's about them iframing
you without your knowledge.
glazou: Yeah, on the <link>
TabAtkins: That won't help then. You don't have control over the
<link> that's causing the problems.
Bert: We should just say that CSS isn't passed through iframes.
<glazou> do we want to send an official mail from WG about it ?
<glazou> saying we're aware of issues in CSS
<glazou> but issues are caused by security model of the web itself
<glazou> and we cannot do a lot about it from our end ?
<TabAtkins> I think we should. Bandaid patching/restricting CSS
here won't fix the underlying problem, which will just
keep popping up with sites on the same origin but
different owners.
<TabAtkins> And we're not introducing any new attack scenarios
fundamentally.
<glazou> other opinions ?
<Bert> I think it's better for usability if a style sheet is blocked
completely or not at all, not individual features of it.
<glazou> even if we have a security profile ?
<TabAtkins> Agreed, Bert. We can't just identify particular bits
of CSS without causing author confusion.
<sylvaing> i hung up
<glazou> ok, I'll prepare that mail then
<glazou> I suggest to adjourn the meeting
<glazou> painful today because of phone problems
<glazou> we have only 4 minutes lefts anyway
<TabAtkins> So yeah, I'd prefer an official mail from us about the issue.
ACTION glazou: answer from CSS WG to public-web-security saying the
issues are related to security model of the web and
CSS cannot do a lot
<TabAtkins> So people don't think that it's something wrong with CSS
that can just be patched away.
<glazou> let's adjourn the meeting
<glazou> thanks guys, and sorry for the phone bridge even if that's
not our fault
Received on Thursday, 14 January 2010 08:38:36 UTC