W3C home > Mailing lists > Public > www-style@w3.org > January 2010

[CSSWG] Minutes and Resolutions 2009-12-12

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 14 Jan 2010 00:37:57 -0800
Message-ID: <4B4ED7E5.3000102@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - 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:
     Concluded that doing anything about it is outside the scope of CSS.

====== Full minutes below ======

   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


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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:42 UTC