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

[CSSWG] Minutes and Resolutions 2009-12-02

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 02 Dec 2009 12:03:21 -0800
Message-ID: <4B16C809.5020903@inkedblade.net>
To: www-style@w3.org
Summary:

   - Mozilla and WebKit have both implemented pointer-events applied to HTML (not just SVG).
     Only two values are supported: auto and none.

   - fantasai sent and Tab will send comments on Doug's Spec Conventions proposal.
       http://lists.w3.org/Archives/Public/www-archive/2009Nov/0027.html
     There were no other comments.

   - RESOLVED: Publish css3-color as CR or PR without proposed 'color-correction' addition.

   - Reviewed implementation status for CSS Namespaces based on Chris's report:
       http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/reports/implement-report
     Only http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/syntax-013.xml does
     not have two passes.

   - RESOLVED: Add 'start' and 'end' values to 'float' (CSS3 Box Model)

   - RESOLVED: Publish Snapshot as CR along with css3-color CR or PR
   - RESOLVED: Snapshot will replace /TR/css3-roadmap, and will also be the target
               of /TR/CSS3 and /TR/CSS, pending the Director's approval.

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

Present:
   Tab Atkins
   Bert Bos
   Elika Etemad
   Simon Fraser
   Sylvaing Galineau
   Daniel Glazman
   Brad Kemper
   Peter Linss
   David Singer
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2009/12/02-CSS-irc
Scribe: fantasai

Pointer Events
==============

   glazou: Mozilla has implemented pointer-events property
   glazou: And extended it to HTML
   smfr: WebKit does that too
   only 2 values are implemented
   glazou: The two values are auto and none


glazou: First item is percentage height calculations
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0286.html
glazou: dbaron is not on the call, so we may want to defer

Feedback on Spec Conventions
============================

   <glazou>
   glazou: Discussed that last week, feedback from group is welcome
   Tab: I went through thread and agree with everything fantasai said
   Tab: Also, Schepers is using <em> in some cases for no other reason
        except to get italics
   Tab: He's using it for italics, not for emphasis
   Tab: He should be using <i>
   Tab: That's the only comment I have; the rest seems acceptable
   glazou: Do you want to send that yourself?
   Tab: I can send it myself
   glazou: Please also say that the group has no other comments

2007 Snapshot
=============

   <glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2009OctDec/0148.html
   fantasai wrote:
     I propose the 2007 Snapshot as a topic for this week's telecon
        http://www.w3.org/TR/css-beijing/
     Originally, I was going to request publication of the snapshot
     as CR when Selectors went to CR or PR, but we're talking about
     adding new features to css3-color that will not qualify for
     the snapshot until css3-color hits PR. (CR will be insufficient
     because the snapshot assumes implementation experience even if
     the spec itself is not totally stable.)
     The question is, what should we do here?
        - Delay the snapshot until color-correction is adequately
          specced, implemented, and tested?
        - Push color-correction into a css4-color spec or a
          css3-color-profiles spec and take css3-color to the
          nearest of CR or PR?
        - Drop css3-color from the snapshot?
        - Something else?
     It's clear to me from the number of questions that the snapshot
     answers that it's important for us to take it to CR and thereby
     post it as a replacement for the outdated /TR/css3-roadmap and
     as a target for /TR/CSS3. I was expecting that with Selectors
     finally out of Last Call, this would be possible by the end of
     the year. Since that is no longer the situation, I would like
     us to come up with Plan B.

   fantasai summarizes the options here
   Tab: Were there other features we could include in the module with
        color-correction?
   fantasai: There were some color profile related features that were
             dropped earlier in the cycle for css3-color
   Tab: Then I'm mildly in favor of doing that
   sylvaing: From the options you presented, I would be more inclined
             to leave color-correction for later
   sylvaing: and just complete css3-color as-is
   sylvaing: I don't think it's that interesting of a feature to hold
             up the snapshot
   glazou: I agree
   brad: You're talking about dropping color-correction, not css3-color?
   sylvaing: Right.
   brad: Then I agree with that. Seems like the best option to me too
   Bert: Sounds good to me too. I'm in the mood for finishing specs,
         so let's finish some specs
   fantasai: do we have implementation reports for the rest of css3-color?
   Bert: We have tests, but test reports..
<ChrisL> sorry to be late - got a storming headache today :(
<Zakim> +ChrisL
   <dsinger> are we saying that css color would be silent on correction,
             or require none, or...?
   fantasai: If we don't have implementations, then I propose we publish
             css-color as CR
   fantasai: and the snapshot as CR along with it
   http://www.w3.org/Style/CSS/Test/CSS3/Color/current/reports/
   dsinger: What would the css3-color spec say about color correction
            then? Nothing?
   glazou: correct
   dsinger: If css3-color is specified in srgb, then it's implied you
            should color correct
   dsinger: but doesn't say anything about how
   dsinger: I'm fine with that
   <fantasai> Opera passes system colors, but nobody else does
   glazou: so we can aim for CR only at this time
   RESOLVED: Publish css3-color as CR
   <ChrisL> opera10 passes 
http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/xhtml1/t0302-opacity-offscreen-with-alpha-c.xht
   <szilles> fantasai, if you are removing color correction do you not
             have to do another last call?
   <fantasai> szilles, we never published color correction
   <szilles> Ok

   <post-meeting>
   dbaron believes we have implementations for PR
   dbaron updates some tests to make pass criteria clearer
   dbaron notes that the last call comments have not all been addressed yet
     so we should hold off and publish PR when those are cleared
   </post-meeting>

Namespaces
==========

   <glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2009OctDec/0149.html
   chrisl: I sent an email with a link to an implementation report
   <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/reports/implement-report
   chris: which has passes for every test except one
   chris: I thought the test was wrong, but then bzbarsky pointed out the
          part of 2.1 that makes it correct
   chris: this was news to Safari, which is why they failed it
   chris: I believe the test is actually correct, just a bit underdocumented
   chris: It still means we have one test where we only have one pass
   chris: I just wanted to know what the situation was, wasn't proposing
          any action
   Peter: I ran that test in FF3.5 and it didn't pass
   chris: Oh. I might've been using 3.6 then. I'll check it
   test in question - http://www.w3.org/Style/CSS/Test/CSS3/Namespace/20090210/syntax-013.xml
   glazou: That test is fully green in Firefox 3.7
   chris: But the CSSWG doesn't accept nightly builds
   fantasai: We do, under certain conditions
   Peter: It has to be not an experimental implementation, and publicly available
   Peter: basically not something someone wrote to pass a test
   * oyvind checks opera mini
   <sylvaing> cool. is that criteria written down and documented anywhere ?
   <fantasai> sylvaing, http://www.w3.org/blog/CSS/2008/04/04/resolutions_17
   glazou: Did we need a clarification?
   chris: I guess it's clear enough, just requires reading through it carefully

glazou: other topics were messages from dbaron, so deferring for now...
<dsinger> I think we can handle the comments, actually
glazou: Next one is about CSSOM, but anne sent regrets

Float values
============
   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0336.html
   glazou: Last item is about float values, some discussion on www-style
   glazou: Peter noticed a subthread about the behavior of overflow
           regarding floats in ltr vs rtl
   peter: I think dbaron was actually bringing that one up
   <ChrisL> (Opera10 has a bunch of extra passes for color, i will send in a test report)
   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0343.html
   <plinss> http://lists.w3.org/Archives/Public/www-style/2009Dec/0009.html
   <TabAtkins> http://css-class.com/test/css/bidi/float-left-right-edge-rtl.htm
   <TabAtkins> http://css-class.com/test/css/bidi/float-right-left-edge-rtl.htm
   Tab: the original part, ignoring the overflow business, was just
        about float direction based on text direction
   Tab: Instead of being absolute left or right
   glazou: So 'start' and 'end'?
   Tab: Yes. I think that's a fine idea
   glazou: I think it's useful for bidi
   fantasai: I agree.
   glazou: I think we should add it
   <szilles> i agree also
   glazou: Other opinions?
   Bert: I have no problem with adding it, not so sure it's useful
   glazou: If you want to build web apps using floats in the bidi world,
           then you need it
   glazou: It's useful, because you have to reverse everything.
   Bert: That's the problem, you don't have to reverse everything, only
         some things
   Tab+Chris: Right, so you use start and end when you need them to reverse,
              and left and right when you don't
   Brad: This would be useful for drop-caps
   Bert: So we're editing the Box Model, my spec
   RESOLVED: Add start and end values to float
   ACTION Bert edit box model to add start and end to float

CSSAnonRule
===========

   glazou: Got an email from several people about dropping anonrules
   glazou: because they want to implement an html editor
   glazou: same problem I mentioned a long long time ago
   Chris: This is what happens when stuff doesn't display
   Chris: We could have rules that display in the dom, but have an ignore
          property which says the property is currently ignored
   glazou: It's not only that, chris
   glazou: When the processor sees a style rule it cannot parse, it
           drops the rule
   glazou: It doesn't appear in the dom at all
   fantasai: You also have the case that in some implementations, if
             the same property appears more than once in a declaration
             block, the earlier ones get dropped at parse time (rather
             than stored and ignored during the cascade)
   ...
   chris: Get a property value as a string
   Tab: Right now the way you do this you have to parse the style sheet
        yourself with JS
   glazou: The WG discussed that question a very long time ago and the
           answer from the vendors was we don't want to preserve style
           rules that we are not using because it impacts the footprint
   glazou: I hope the vendors are going to change their view on this
           point, otherwise its pointless to discuss it
   glazou: I'm seeing more and more requests on this topic
   glazou: If we really want to have cross-browser applications ...
           it's a point we need to solve
   sylvaing: The reason this whole thing came up is the whole marking
             things obsolete at DOM2
   sylvaing: ... defining it as obsolete, or hold off on that until we
             have a resolution
   glazou: Given the way CSS parsing works, it is unusued
   ...
   sylvaing: Just want to know, is what we're implementing in the
             future going to be like anonrule, or something else is
             going to replace it?
   glazou: It is not useful as defined.
   glazou: It's only for at-rules and style-rules that are dropped
   glazou: You can only use it in some cases, not in all
   Tab: It's used for at-rules
   glazou: yes, it's too limited
   glazou: it doesn't help with declarations that are dropped
   sylvaing: Ok, so it's good to drop

Snapshot (cont.)
================

   fantasai: Do we want a resolution to publish the Snapshot as CR, or
             wait until css3-color is CR?
   Bert: maybe we can decide to do them together, at the same time?
   glazou: That would be cool
   RESOLVED: Publish Snapshot as CR along with css3-color CR or PR
   Proposed: Use it to replace /TR/css3-roadmap, also have /TR/CSS3
             and /TR/CSS point to it
   Bert: /TR/CSS3 will require the director's approval, the rest
         should be easy
   Chris: /TR/CSS currently points to 2.1, you intend to replace that?
   fantasai: yes
   fantasai: /TR/CSS2 points to 2.1
   <szilles> +1 for Snapshot CR and roadmap replacement
   RESOLVED: Proposal accepted, pending director's approval
   <fantasai> I note that /TR/CSS should probably be a redirect,
              not an alias...
   ACTION fantasai make Disposition of Comments for Snapshot (even
          if it's empty)

Meeting closed.

More on css3-color:

   <smfr> fantasai: how do the color tests work?
   <smfr> specifically, what makes 
http://www.w3.org/Style/CSS/Test/CSS3/Color/20080721/xhtml1/t040501-system-colors-a.xht fail in webkit?
   <fantasai> smfr: I have no idea, ask dbaron. Maybe it passes now;
              those reports are not the latest latest
   <smfr> the test says "there should be no red", and that's true in our result
   <dbaron> css3-color is fine for pr if we don't worryr about color-correction
   <dbaron> the system colors thing is just hard to test
   <ChrisL> dbaron - yes, its hard to test. or rather, its hard to write a
            test that its possible to fail
   <dbaron> sorry, couldn't dial in
   <dbaron> can we un-resolve to publish css3-color as CR?
   <smfr> we kinda hate system colors anyway, since they are too closely
          tied to Windows
   <fantasai> dbaron: I'm pretty sure we can
   <fantasai> dbaron: if you say we're ready for PR and we have the
              implementation reports for it
   <dbaron> except for the sRGB issue, yes, I think we are
   <dbaron> it needs a little arguing about system colors
   <dbaron> which are pretty broken to begin with, and the reason I judged
            the implementation reports as "failing" is because colors
            aren't good enough to represent the system appearance
   <dbaron> which is why they're deprecated
   <dbaron> however, we also don't have a draft to publish
   <dbaron> there's a whole bunch of comments that I need to address
            before we publish
   <dbaron> even without color-correction
   <fantasai> ah, ok
   <dbaron> (it just cuts the number of comments that need to be addressed
            from 26 to 25
   <fantasai> when do you think you'll have that done by?
   <dbaron> I probably won't have time this week or next.
   <fantasai>how about mon/tues the week after?
   <dbaron> I can try...
   <fantasai> dbaron, that'd be great

   <ChrisL> smfr, could you mail a screenie of what webkit does on that test?
   <smfr> ChrisL: sure
   <smfr> ChrisL: sent
   <ChrisL> simon, i don't see anyting there that would indicate a fail
   <dbaron> I probably won't have time this week or next.
   <dbaron> smfr, what makes it fail is that it doesn't actually "look
            like a raised button... in the operating environment"
   <ChrisL> david, in that case the test is badly phrased. it would fail
            on anything that uses non-rectangular buttons for example
   <smfr> dbaron: ok
   <dbaron> ChrisL, well, it's the *spec* that's badly phrased, really,
            since the features presume that...
   <dbaron> I suppose maybe the test should say "look like the closest
            thing to a raised button in the operating environment that
            can be represented by ..."
   <smfr> dbaron: seems like the worse issue is that ActiveCaption and
          CaptionText are both black, resulting in unreadable text
   <ChrisL> david - yes, that would be better wording

   <dbaron> ok, I checked in new wording for the system colors test
   ...
   <fantasai>  dbaron: let me know when you want a new copy published on w3.org

   <smfr> the other two webkit failures are related to line height,
          not rgba colors
   <fantasai> maybe you can patch the tests to not rely on that
   <dbaron> probably the easiest patch for that is to make them use
            the Ahem font
   <dbaron> though, actually, I think the thing to do just mark WebKit
            as passing those tests, since it's passing the relevant
            parts of them
   <dbaron> and it just doesn't do 'line-height: 0' correctly
   <dbaron> I really don't know any other way in CSS 2.1 + css3-color
            to make two boxes of the same element overlap each other
   <dbaron> which is what that needs to test
   <fantasai> That seems reasonable to me. So WebKit and Firefox will
              get us to PR
   * fantasai likes ChrisL's Namespaces implementation report, it makes
       this kind of comparison really easy :)

More on publications:
   <dbaron> Also, was the publication of css3-transitions, css3-2d-transforms,
            and css3-3d-transforms permanently cancelled or just delayed?
   <fantasai> dbaron, delayed, I believe
   <myakura> 2d-transforms and transitions were published yesterday.
   <dbaron> myakura, ah, ok, good
   <myakura> not sure about 3d-transforms, though.
   <fantasai> I don't think we had a resolution to publish 3d-transforms
   <dbaron> I still have a bunch more transitions issues, but we can
            publish again in a few months...
   <fantasai> :)
   <smfr> right, we have not
   <fantasai> smfr, anyone on your side interested in writing a blog post
              to announce the drafts?
   <fantasai> smfr, or should I just say that we published new WDs and
              leave it at that?
   <smfr> i think that's fine
Received on Wednesday, 2 December 2009 20:04:05 GMT

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