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

[CSSWG] Minutes and Resolutions TPAC F2F 2009-11-03: Selectors, CSS3 Color

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 17 Nov 2009 15:33:26 -0800
Message-ID: <4B0332C6.5070805@inkedblade.net>
To: www-style@w3.org
Selectors
---------

   - Reviewed intention of default attribute wording so that it can be clarified.
   - Reviewed implementation reports and checked a few more implementations
   - RESOLVED: Advance to Proposed Recommendation for Selectors Level 3
       Disposition of Comments <http://dev.w3.org/csswg/selectors3/issues-lc-2009>
       Implementation Reports <http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/>

CSS3 Color
----------

   - RESOLVED: Drop section 3.1.1 css3-color
   - RESOLVED: add 'color-correction' property with values 'default' and 'srgb'
               where default is UA-defined and 'srgb' corrects untagged images
               to sRGB
   - See also: http://lists.w3.org/Archives/Public/www-style/2009Nov/0226.html

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

http://www.w3.org/2009/11/03-CSS-minutes.html
http://krijnhoetmer.nl/irc-logs/css/20091103#l-973

<RRSAgent> See http://www.w3.org/2009/11/03-CSS-irc#T19-17-50
Scribe: Bert

Selectors
---------

   <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2009Nov/0022.html
   <TabAtkins> Default attribute thread
   <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/
   http://www.w3.org/mid/4AEFE294.8070104@inkedblade.net
   fantasai: Default attributes, e.g., colspan is default 1. Can you
             match against them?
   fantasai: Spec is not clear.
   fantasai: Should we allow both behaviors?
   fantasai: Most impl. don't match default attrs.
   Tantek: Impl. shouldn't be required to read DTD, so they don't necessarily
           know the default.
   Tantek That's the background behind the current spec.
   Glazou: You *can* check if an attribute is absent.
   dbaron: But need to select all unknowns, can get a long selector...
   fantasai: So agreed that spec allows both matching and not matching?
   Arron: Are you going to send proposed text?
   fantasai: Yes, I will.

   <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/
   fantasai: Next is impl. reports. Looks like Opera fails several. Do we
             have other impls.?
   ChrisL: Webkit was not tested yet.
   dbaron: Webkit seems pretty good.
   ChrisL/dbaron: 15C may not matter
   [DavidB trying out things in webkit.]
   <dbaron> we don't have 2 impls for 174a, 174b, and d3
   <dbaron> also 0 impls for 15c, but I don't think that matters
   <dbaron> Mozilla is the only impl passing 174a, 174b, and d3 that I know of
   Glazou: I am trying to get impl. report from zoomorama(sp?}
   Fantasai: Should we also look at Prince?
   Glazou: Yes, Prince is interesting.
   ... May also look at Andrew Fedoniouk's HTMLayout.
   [Several discussions at the same time]
   Fantasai: I'll run tests on Prince.
   ChrisL: I can try Webkit.
   [Discussion about most efficient way to quickly press keys.]
   Fantasai: We need another impl. for some tests. Webkit not enough.
   ChrisL: I talked to Opera about their failures. Maybe they can do
           something about it.
   Beth: I tested the failures and they still fail in latest build.

   <fantasai> Konqueror passes d3
   <fantasai> Prince passes 174a and 174b and 15c
   <fantasai> fails d3 (since it's dynamic)

   later (copied from afternoon minutes):
     fantasai: we have implementations for all selectors tests, counting
               prince, webkit, opea and firefox
     ... apart from the 15c subtest which needs multiple id support, already
	listed as feature at risk
     glazou: champagne
     <ChrisL> http://www.cardsunlimited.com/largeimage/Champagne.jpg
     * dbaron thought the resolution was 1400x1050 :-)
     RESOLVED: Advance to Proposed Recommendation for the Selectors spec

copied from after-hours:
   <fantasai> Bert: http://dev.w3.org/csswg/selectors3/issues-lc-2009
   <fantasai> Bert: http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/

CSS3 color and gamma correction
-------------------------------

   DavidB: Gamma may not be the right term.
   ... Colors are in sRGB.
   ... But nobody really implements it.
   <dsinger> see 3.1.1 in http://www.w3.org/TR/css3-color/
   ... Do we relax the spec?
   ChrisL: On many platforms sRGB is right by default.
   Beth: Not on the mac.
   DavidB: 2nd question is do we give authors a way to opt in?
   ... Plugins are a known problem.
   ... The right thing would be to treat CSS colors as well as untagged
       images to be in sRGB.
   ... I don't know what Flash defines.
   ChrisL: No color management, currently.
   DavidB: Flash guys may be interested in defining something.
   ... But we may also want to give authors a choice.
   dsinger/Beth: A vague idea we had:
   ... An ability to turn it on with a property.
   ... Not crazy about the idea, but needed it for a client.
   Tantek: So you needed it per element?
   ChrisL: A need per element maybe because of video, of which there is
           more and more,as well as tagged images.
   dsinger: And if you it on body, it applies to everything?
   dsinger: Example: a background behind a flash, and only that, should
            be uncorrected.
   Beth: We don't want to override color profiles when explicit in an image.
   <ChrisL> Need to override *tagged* images is minimal
   dsinger: There are also many incorrectly tagged images.
   dbaron: Gecko now corrects tagged images.
   Tantek: DavidS, what do you want, more precisely?
   <ChrisL> Not clear that there are many incorrectly tagged images
   dsinger: You can say that the color space of this element is such and
           such, or is 'none'.
   Tantek: And if the image is tagged, it will override?
   Tantek: So you described the 'auto' value that we had in a previous draft.
   dbaron: But we also need our current behavior.
   dbaron: Which is not interoperable.
   dsinger: But it is consistent in a single browser.
   * dsinger does anyone have a pointer to the previous version that had
             this feature?
   Beth: We want 'auto' to match whatever browser decides to do. Which may
         even change over time...
   Tantek: If you use 'auto', you cannot count on any specific behavior.
   dbaron: You can count on it being consistent with a single browser.
   dsinger: We may want to force platform-specific colors.
   dbaron: Not sure we want that.
   Tantek: Would there be no standardized value in the UA style sheet?
   ChrisL: Difference between platform color space and platform specific
           behavior, which may be color managed.
   dbaron: Mozilla changed to be compatible with Webkit and go a lot of
           negative feedback.
   Tantek: 'Default' could be another keyword.
   Tantek: It means you cannot count on cross-platform conistency.
   Beth: Sounds good.
   ... It means: what UA would do if the property weren't specified at all.
   ... That can change over time.
   ... E.g., at the moment we don't do color management at all.
   ... But we may do so in the future.
   Tantek: So 'auto' means treat as sRGB, except for images that are tagged.
   Tantek: And 'sRGB' means override the image tags.
   <ChrisL> Pointer to the relevant part of the old spec
            http://www.w3.org/TR/2003/CR-css3-color-20030514/#icc-color
   DavidS: So we have 'historical' and 'correct' (as keywords?).
   <ChrisL> we don't want to encourage overiding of images, so the old
            proposal is not very good. Tantek's current wording is better
   Tantek: Two values for reintroduced color-profile: default (as per Beth)
           and srgb, defined the way 'auto' used to be defined.
   <ChrisL> "All colors are presumed to be defined in the sRGB color space
            unless a more precise embedded profile is specified within
            content data. For images that do have a profile built into
            their data, that profile is used. For images that do not have
            a profile, the sRGB profile is used so that the colors in
            these images can be kept "in synch" with the colors specified
            in CSS and HTML."
   Tantek: 'auto' exactly as that quoted text.
   Tantek: And just two values seems enough.
   Brad: Wrong tags in images?
   <dsinger> note that the correct application of color spaces in plugins
             is the responsibility of the plugin and not the browser
   <ChrisL> Brad is concerned about images saves with incorrect profiles,
            which was not noticed because browsers only started dealing
            with tagged images fairly recently
   dbaron: That will never cause problems on some machine but not others.
           You will see the problem immediately.
   <dsinger> note that the color spaces used in video are different, and
            the color correction of video is handled by the video subsystem
   Peter: Didn't you, dbaron, say there were tools that generated wrongly
          tagged images?
   dbaron: I think I said there were many untagged images.
   chrisL: Most common tag is Adobe RGB.
   dsinger: I want authors to tag images correctly. Not provide a work-around.
   <ChrisL> most common after untagged, or tagged as sRGB, is AdobeRGB
   [Discussion of dsinger text above]
   ChrisL: Untagged video is almost sRGB in practice.
   Tantek: Can dsinger find out if it is OK to treat untagged video as sRGB?
   <ChrisL> its the same primaries (CCIR 709 primaries) the transfer curve
            is slightly different
   <tantek> re-introduce 'color-profile' property, two values. 'default'
            per Beth's definition, and 'sRGB' per definition of 'auto'
            from http://www.w3.org/TR/2003/CR-css3-color-20030514/#icc-color
   <tantek> specifically
   <tantek> 'sRGB'
   ACTION on dsinger check with HTML WG that untagged video can be treated
          as sRGB, or provide counter examples if not.
   <tantek> "All colors are presumed to be defined in the sRGB color space
            unless a more precise embedded profile is specified within
            content data. For images that do have a profile built into their
            data, that profile is used. For images that do not have a profile,
            the sRGB profile is used so that the colors in these images can
            be kept "in synch" with the colors specified in CSS and HTML."
   RESOLUTION: re-add a 'color-profile'-like property with the two values
               'default' and 'srgb'
   Beth: We are working on -webkit- prefixed property, May be available by
         end of week.
   <ChrisL> s/color-profile/color-correction/
   ChrisL: Name should not clash with SVG.
   Tantek: Other name is fine.
   Tantek: call it 'color-correction'
   dbaron: Per element is harder than per document.
   ChrisL: Won't be changed very often.
   [Dicussion about allowing UA to only do per document.]
   Tantek: So require per-element?
   <ChrisL> please lets
   dbaron: I don't want to have to check it for every color paint.
   <tantek> also proposed: drop section 3.1.1 Gamma correction
   Bert: How do you get untagged images to match CSS text?
   <tantek> http://www.w3.org/TR/2008/WD-css3-color-20080721/#gamma
   Tantek: You say 'color-correction: srgb'
   ChrisL: Do we have sufficient text for this property?
   Tantek: Yes, everything is in IRC [above]
   dbaron: Another last call for Color?
   Tantek: Can we not go to CR with this change?
   ChrisL: It's a change, needs a WD.
   ChrisL: But can go straight to PR after the LC, if we have implementation
           reports.
   ChrisL: So, write the test, and make sure UAs pass them, in particular
           Safari and Firefox.
   ChrisL: Opera doesn't do color management. I want to try to get them to change.
   <tantek> write tests including vendor prefixed properties for color-correction
            to allow for those implementations to enable passing the tests.
   ChrisL: Some of the platforms it runs on are hard to determine.
   Arron: We don't do color management either.
   dbaron: Is 'srgb' the right keyword?
   <ChrisL> s/needs a WD/needs a Last Call/
   Tantek: We can always add 'srgb-force-damnit'...
   dbaron: Also, retract that comment.
   Glazou: Next steps?
   ChrisL: Some editing, test cases, LC, and PR.
   <dbaron> http://www.w3.org/Style/CSS/Test/CSS3/Color/current/
   <ChrisL> http://www.w3.org/Style/CSS/Test/CSS3/Color/20081014/reports/
   RESOLUTION: drop section 3.1.1

copied from after-hours:
   <dbaron> ok, I updated the issues list and http://wiki.csswg.org/spec/css3-color
            should now be current
   <dbaron> I think it has almost exactly the same number of issues as the
            last draft
   <dbaron> although a decent number of them are repeats
Received on Tuesday, 17 November 2009 23:34:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:22 GMT