- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 04 Feb 2010 15:15:13 -0800
- 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 UTC