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

[CSSWG] Minutes and Resolutions 2010-02-03

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 04 Feb 2010 15:15:13 -0800
Message-ID: <4B6B5501.50902@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - CSS2.1 Test Suite Alpha 1 published last week
       http://www.w3.org/Style/CSS/Test/CSS2.1/20100127/

   - Discussed border-radius color transition issue
       http://lists.w3.org/Archives/Public/www-style/2010Jan/0530.html
     Seem to have (tentative) consensus that the gradient be recommended
     as currently, but that the location of the color stops also be defined.

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

Present:
   Tab Atkins
   David Baron
   Bert Bos
   Beth Dakin
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   David Singer
   Steve Zilles


<RRSAgent> logging to http://www.w3.org/2010/02/03-CSS-irc
ScribeNick: fantasai

Administrative
--------------

   Daniel: Extra agenda items?
   Sylvain: At some point we need to talk about the border-radius gradient
   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Jan/0530.html
   Sylvain: It's recommended in the spec, but not clearly defined
   Daniel: It's important, let's put it in the second position

CSS2.1 Test Suite
-----------------

   Daniel: Alpha version was posted last week
   Daniel: Any feedback on it?
   fantasai: build process is painful? :) build scripts have bugs. Also
             reftests need to be integrated
   <ChrisL> I have been reviewing the font tests
   Daniel: How many tests have been reviewed?
   fantasai: probably around 10%
   Daniel: Is it possible to review all tests before final release?
   fantasai: possible, but not necessarily likely. Depends on how much time
             reviewers put in
   fantasai: alpha release includes all submitted tests, including unreviewed
   fantasai: We are tracking which tests have been reviewed
   Daniel: We have two option: 1 we release without reviewing everything,
           2 we review everything
   Daniel: We probably don't want to hold up REC for getting all tests reviewed
   <ChrisL> Fantasai pointed out that each test says what its review status is
   Daniel: When can you have the reftests integrated?
   fantasai: Probably take me 4 days, so maybe in 2 weeks

border radius gradients
-----------------------

   Sylvain: When you have a border radius, two borders join
   Sylvain: If you have two colors, a sharp transition does not look that good
   Sylvain: So the spec recommends a gradient
   Sylvain: But the spec doesn't specify exactly how the gradient should work
   Sylvain: So one you get differences between browsers
   Sylvain: Second the author has no control over it
   Sylvain: The other issue is, if browsers do the gradient, can you test
            whether the transition center is where the spec says it should be?
   Sylvain: The reason it's not defined is because the spec author felt
            vendors should experiment
   Sylvain: But once browser implement without a vendor prefix the behavior
            is frozen
   Sylvain: If I'm going to do it, then if you specify border-radius you get
            the sharp transition
   Sylvain: And if you specify -ms-border-radius then you get a gradient
   Chris: Saying the browser can pick whatever it likes is a recipe for disaster.
          Can't predict what will happen, so authors will not use it
   Daniel: Leaving it unspecified is fine for small border widths
   Daniel: Issues show up in thick borders
+TabAtkins
   ...
   dbaron: Given that we don't see a lot of examples of authors doing this
           with images, I'm skeptical that we should require something that
           involves a lot of implementation work
   dbaron: The reason we have border-radius is because authors were
           synthesizing it a lot with images
   dbaron: Unless there are a lot of examples where authors are using multiple
           colors, I don't think we need to make this a requirement for UAs
   dbaron: I like the transition line approach
+Hakon_Lie
   dbaron: That nobody's implemented it doesn't mean authors can't express
           that they want it. People hack things with images if they really
           want it
   Sylvain: [missed]

   fantasai: I'm happy to remove the recommendation, as long as gradients are
             allowed.
   Chris: That doesn't help at all. You still have unreliable behavior, and
          that's not what authors want.
   Brad: I think it's good that it's recommended. As an author, I think most
         of the time if I have 2 colors meeting up in a curved corner I'd want
         a smooth blend
   Brad: But if it wasn't one, it's not something I'd spend a lot of time
         trying to get right in one browser and then be disappointed that it
         doesn't blend right in the other browser
   Brad: It's fine to me if a lightweight browser doesn't do the gradient
   Daniel: But for a thick border it's a problem
   Brad: It's more noticeable

   SteveZ: Where I come out on this is that the two effects: gradient vs line --
           are so different, that I'd like control over which of those I wanted
   Steve: Writing the spec in a way of leaving it up to the browser vendor
          seems like a bad way of writing the spec
   Steve: We should say which one it is, we should just spec it
   Steve: Based on what dbaron and Sylvain said, going with the line is the
          best approach
   Daniel: Does XSL solve this issue?
   Steve: I don't remember
   Daniel: It would be useful to know if XSL has a solution for this
   fantasai: Wrt a switch, I haven't heard that any authors care enough that
             we should a) spec it b) implement it c) add it to the stuff
             authors have to learn about. that's a lot of overhead for something
             nobody has said they want

   Daniel: when you have border-style groove with a thick border and a border
           radius, they might want a gradient
   dbaron: Do they use anything like that? I haven't seen much use of groove.
   Daniel: Yes, I've seen it
   Daniel: Our experience has shown that when we add it to the spec, authors
           use it in ways that we didn't expect.
   Sylvain: If it's important, let's specify it, and if it's not, let's take
            it out
   fantasai: What do you mean by take it out?
   Sylvain: No recommendation to do a gradient?
   fantasai: Is it allowed to do a gradient?
   Sylvain: no
   <Bert> (A gradient with a sharp corner may be allowed, but it would be have
          zero width, though. :-) )
   <dbaron> So, FWIW, http://www.twitter.com/ has a button with rounded borders
            and multiple colors
   <dbaron> (the "more" button at the bottom)
   <dbaron> (if you're logged in)
   <dbaron> Given that it's a 1px border, they probably don't care which option
            we take.
   ... lots of people said something and didn't get minuted ...
   TabAtkins: fantasai's point was important. Authors complain about ugly
              borders. If two borders are subtly different, but neither is
              ugly, I don't think anybody will mind
   Daniel: People complain
   Daniel: And they will be using this feature in ways we did not expect
   <dbaron> So should we define how dotted borders are drawn? :-)
   Chris: There's two possible ways to take it out, Sylvain. One is to remove
          the recommendation to use a gradient.
   Chris: The alternative is to require a sharp transition.
   Chris says gradients are easy to specify
   fantasai explains all the crazy cases in which they're not

   Brad: If we defined the region in which the transition happens and the
         points around which it happens, would that be ok?
   Daniel: Recommending is ok?
   Sylvain: Yes, but I want to know exactly what is recommended
   fantasai: Do you want an exact mathematical definition for the gradient
             or do you just want the stops?
   fantasai: Because the stops are easy to specify
   <TabAtkins> View in Firefox for a somewhat weird cut:
 
data:text/html;charset=utf-8,%3C%21DOCTYPE%20html%3E%3Cstyle%3Ediv%20%7Bwidth%3A%20500px%3Bheight%3A%20300px%3Bmargin%3A%20100px%3Bborder%3A%2050px%20double%20silver%3B-moz-border-radius%3A%200%20500px%200%200%20%2F%200%20300px%200%200%3Bborder-top-color%3A%20lightgreen%3Bborder-right-color%3A%20green%3B%7D%3C%2Fstyle%3E%3Cdiv%3E%3C%2Fdiv%3E
   Steve: If people aren't using gradients now, then let's not put them in.
   fantasai: ... [something about how nobody *wants* a sharp transition, so
             speccing a line is stupid] ...
   Steve: You can't define the gradient precisely enough
   Brad: As long as it's pretty, nobody's going to really care
   ...
   Daniel: We've got no consensus.
   <dbaron> Does "produces good results" include having acceptable performance
            when drawing hundreds of them at once?
   fantasai: How about this. Sylvain and I sit down and define the precise
             mathematical function that gives you pixel-perfect rendering
             on every browser that implements it. We spec that, and wait
             for implementors to complain.
   Steve: What if I don't like your gradient definition?
   ...
   Steve: Whatever we define, it should be printable.
   Daniel: We're discussing a CR. I don't want to end up with an objection
           to this CR
   Daniel: If we can reach no agreement at all on this feature, then we will
           have to remove it
   Sylvain: We don't have any consensus that it's important
   Sylvain: How can we reach consensus on how to do it?
   fantasai: we have 5 options
   1. Require the sharp transition
   2. Drop recommendation for gradient, leave transition undefined
   3. Recommend gradient, define color stops
   4. Give precise mathematical definition for a gradient that will give
      pixel-perfect copies across implementations
   5. Drop border-radius
   <ChrisL> 3
   fantasai: I'm unhappy with 1 or 5
   <bradk> 3
   Sylvain: 2 is fine
   Chris: 3
   <TabAtkins> 3 at least (4 seems like a lot of effort)
   Simon: 3
   Daniel: 3
   <ChrisL> 3 is my first choice, 4 is ok, 2 acceptable but not ideal
   Tab: agree with Chris
   Bert: Any of the first 4 is fine by me
   Peter: My concern if there's enough people that really care how it's going
          to join, we should provide a property that controls corner joins
   Tab: We can add border-radius-style if we really need to in the future
   Peter: Whatever we do should be a plausible default
   Tab: I think it's the best default to have a gradient
   Peter: other than that I abstain
   Peter: I don't care what the default is
   Sylvain: I'm ok with 2 or 3
   ACTION: fantasai post proposal for 3 to www-style

Meeting closed.
Received on Thursday, 4 February 2010 23:15:49 GMT

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