- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 07 Oct 2009 13:58:42 -0700
- To: www-style@w3.org
Summary:
- RESOLVED: 'round' keyword for 'background-repeat' and 'border-image-repeat'
scales to the nearest whole number of tiles. Will mark as an issue
for feedback in case people prefer different behavior or would like
additional control (e.g. 'round-down' or 'round-up' keywords)
- RESOLVED: Add percentages to 'border-radius'. They refer to a percentage of
the corresponding dimension of the box (so border-radius: 50% gives
you an oval).
- RESOLVED: Publish css3-background as Last Call Working Draft.
- fantasai was asked to present on CSS at TPAC's developer meeting, and welcomes
any suggestions for topics to cover
- Last Call period has ended for css3-multicol, howcome will be compiling comments
- Briefly discussed text-overflow: shrink
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
David Baron
Bert Bos
Arron Eicholz
Elika Etemad
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/2009/10/07-CSS-irc
Scribe: TabAtkins
CSS3 Backgrounds and Borders: round() vs. ceil() for 'round' keyword
--------------------------------------------------------------------
fantasai: I want to discuss CSS3 backgrounds early in the agenda.
Peter: Elika, I presume you want to discuss border images?
fantasai: No, that issue is solved in CSS3 Images. The only issue I know of
is whether to scale up or down for the "round" keyword.
fantasai: Rather, the action of 'round' keyword.
Chris: The issue is round up or down, right? and it's only relevant at
.5 of an image?
<ChrisL> always round to the nearest, in my opinion
fantasai: no, argument is whether we should round up/down, or always down.
Round up/down is preserves the shape better, but always down may
be better in raster images.
fantasai: I'm convinced by Brad's argument that rounding up/down is okay.
Chris: Choice between round and truncate.
* dbaron notes ChrisL means numeric truncation rather than image truncation
<fantasai> ceil() vs. round() in the formula
Chris: If you get, say, 3.95 images to fit, rounding down means dropping
to 3 images, right?
fantasai: No, up to 4 images -- so that you *scale* down.
* dbaron thinks it's floor() vs. round()
Chris: What we want isn't floor or ceiling, but windowsill! Halfway up!
?: So, when discussing 3.95 images, should we go to 3 or 4?
<ChrisL> 4
?: We definitely want to be scaling to closest number.
fantasai: With always rounding down, we get more *shape* distortion, while a
high-enough resolution makes the stretching-up not bad.
fantasai: You'll usually only be stretching up just a little bit. And when
the author still isn't happy with the effect, they can give a
higher-resolution image and sizing it down in CSS.
fantasai: Also, we'll later be able to specify how many image px go into
a CSS px.
Peter: The problem is that that's assuming the author knows the width, but
what if they don't?
fantasai: You'll often know approximately, but if you don't, just provide a
higher-resolution image, especially if you think you'll have few
tiles. More tiles means less percentage scaling.
fantasai: The author at least should have a good idea of whther it's 3-4
tiles or 30-40 tiles.
fantasai: And if they're really fussy, they can just provide a
higher-resolution image every time.
Peter: My concern is, the decision to scale up/down or always in one
direction, kinda depends on the content of the image. Why not give
the author control of this - augment 'round' with 'floor' and 'ceil'?
fantasai: I think that's too much. I can't see any real justification for
wanting to floor or ceil that can't be solved with vector images
or higher-resolution.
Chris: If the author doesn't need to decide, then we don't need to discuss
this. We can just decide.
<Bert> In my experience, scaling images down never looks bad, while scaling
up often does. More so with JPEG, but even with PNG.
Chris: But this really isn't an implementation cost. Two more keywords is just
like 4 lines of code.
<dsinger> but scaling down loses detail, whereas scaling up does not
fantasai: I don't think people are asking for multiple options here.
<dsinger> sure, scaled down looks better as nothing is invented; but
something is lost
<dsinger> oh, we're talking non-proportional scaling?
fantasai: In border-image, the height is fixed. If you scale the image it
changes dimensions - circle will become ovallike. Using round()
will produce less distortion.
Chris: I don't think anybody is saying round() shouldn't be the default.
We're saying that floor/ceil might be useful as an option when you
need it.
szilles: I think we can always add ceil and floor later.
fantasai: And you can always provide an image with twice the resolution.
It will always scale down.
szilles: There may be times you don't want to go with higher resolution.
But my point is we can add ceil and floor keywords later, so we
don't have to decide yet.
fantasai: Agreed. We can add it later if there is demand for it.
Sylvain: If the image is vector, not raster, does it get resampled?
Chris: Well, with vector images the size will be telling you how large to
draw it straight off. You're not ever resampling.
<Bert> Future extension (but not really what I hope for...):
'background-repeat: repeat | space | round | ... | round-up | round-down'
<glazou> CSS WG delirium tremens
straw poll! Who can't live with round()?
* dbaron prefers hexagonal :-)
<TabAtkins> I'm okay with it.
<glazou> I should have bet !!!!!
Bert: I don't like it. I was doing some experiments, and scaling down always
looked okay, while scaling up often looked bad.
<ChrisL> interpolation with nearest-neighbor will usually look like crap
Bert: Depends on the image, but you'll lose detail when getting small anyway.
<ChrisL> also attempting to scale in an indexed color space. Promote to
24bit first
Bert: If you have a 1px line somewhere, it will become gray. this is better
than scaling up, where things that were gray will become blocks.
Sylvain: But does detail matter that much?
Bert: For backgrounds, no, but for borders it does.
szilles: It seems unusual to round in this situation.
fantasai: If you have just a few tiles, you can use background-size with
border-image to effectively increase the resolution. So when
scaling 'up', you'll still be scaling down from the original.
* sylvaing finds the background property set to be complex enough as it is
* ChrisL would like to continue with the straw poll
Peter: My objection is that you rejected round-up and round-down for
complexity, but your workaround is a lot more complex than a keyword.
Peter: Bert, I heard that you're not opposed to round, but concerned that
it won't give enough control?
<fantasai> He's concerned about quality, not about control.
Bert: I know that scaling down is always okay, but am concerned that scaling
up won't always look good. I'm surprised that designers on the list
are okay with this.
?: Pete, do you have an actual objection, or just a concern?
Peter: Just a concern. I don't think adding the keywords adds much
complexity, and I think arguments about "this will look good" will
depend on intent, which we can't predict. Why not give control to
the author?
BradK: I'm not against this.
Chris: I could live with rounding. I also like the extra keywords, since
they're not much of an implementor burden, but can live without
them, since we can add them later.
fantasai: I had text that required rounding for vector images and high-res
images, but required scaling down for low-res images (where you
would have to interpolate)
fantasai: we could go back to that
Bert: I think we should add text for the dividing by zero case.
fantasai: Yeah, that's easy to fix.
* ChrisL "implementations SHOULD avoid dividing by zero, but MAY do so
within a try ... catch"
fantasai: Bert, you're concerned about the quality of the images being
scaled up.
fantasai: We could go back to the text from a few revisions ago where you
round with vector images or images that are high-enough resolution.
fantasai: But only have scaling-down-always if you would have to interpolate
pixels.
BradK: But that seems a little worse than the extra keyword. I *have* to
provide a higher-resolution image to keep it from always rounding down.
BradK: I'd prefer keywords to doing that auto-detection.
Bert: fantasai, you were saying you wanted a distincction between raster and
vector image?
fantasai: No, distinction between when you have to interpolate pixels.
Low-res raster vs (high-res raster + vector).
Bert: So you can scale up as long as you don't exceed the original resolution?
Chris: You can scale up as long as you don't scale up?
Bert: No, two-step process. First scale by background-size, then apply
rounding.
ChrisL: That's okay as long as it's clear you don't scale the image multiple
times. Need to make that clear to prevent implementors from thinking
multiple-scaling is required.
plinss_: Consensus?
BradK: I prefer less distortion.
Tab: I prefer the keyword approach.
* bradk prefers less distortion, doesn't mind an extra keyword
szilles: I prefer seeing more experience with how it's used rather than
using a fairly complex algorithm that won't be obvious.
?: You have to think about what to do with browsers that don't recognize
those new keywords.
szilles: They round.
fantasai: That won't be a problem. There's not any deployed unprefixed
versions yet.
szilles: They'd end up ignoring what they didn't understand, which means
they'd go with the default.
fantasai: Which is 'stretch'.
Peter: That's probably not the author's intent.
fantasai: They can list it twice, without the new keyword and then with;
that will work.
Peter: I'm hearing two different dissenting opinions.
<dsinger> I'm only asking questions, not dissenting
szillees: I say pick the simple solution now, see how people use it, and
extend it later if necessary.
fantasai: I want no extra keywords unless people say "I'm unhappy with
this pixelation."
fantasai: We're not publishing CR here, we can have comments. People
can give feedback.
Peter: That works for me. We can let people comment and see what comes out.
ChrisL: So go with round for now?
fantasai: Yes.
Peter: Not hearing any objections?
Bert: Works for me.
<fantasai> ACTION: fantasai mark this as an issue
fantasai: Can we publish last call, or are there more comments?
many: general agreement
<sylvaing> LC! LC! LC!
fantasai: Objections?
voice of the people: no
* glazou imagines sylvaing in a monty python film, with a beard, shouting
spam! spam! spam! :-)
BradK: Is there a use for border-image-size?
BradK: You can't do the background-size with border-image, so I don't think
that's a good idea.
fantasai: So you want to take an image and treat it as 2 device px equals
1 CSS px. We can do that in css3-images.
CSS3 Backgrounds and Borders: Percentage border-radius
------------------------------------------------------
BradK: I can't do percentages in border-radius, but I can simulate this
with border-image.
fantasai: I was thinking about dropping percentags from border-image.
BradK: I think you should do so, or else add it to border-image.
howcome: Do we have % on border-radius now?
fantasai: no.
howcome: we should add it.
<plinss_> s/?/howcome/
fantasai: Did we figure out what it means?
howcome: I have one suggestion. I can send an email, though.
fantasai: That's the confusing thing. We have impl that support % on
border-radius, but they do different things.
fantasai: Some scale border-radius separately, some do them together.
howcome: I agree, but I think it's so useful that the spec should have it.
?: Is it mainly useful for ovals?
<glazou> sorry guys I have to leave the call, bye
howcome: Yes.
<ChrisL> so 50% 50% gives you ovals
ChrisL: In other words, 50% 50% gives you ovals.
Tab: I like howcome's approach.
Peter (to howcome): I don't think that's what you want.
howcome: No, that's exactly what I want.
fantasai: If there's consensus we can put it in.
* sylvaing predicts those ovals will look perfectly square in IE6
BradK: I think it should be the same in border-radius and border-image,
so people don't get confused about how it works.
Peter: I'm not sure if % scaling on the side it's from will give people
what they want.
fantasai: It's hard to switch between them.
fantasai: One of the most common effects for wanting percentages is to make
one side circular and longer sides flat.
fantasai: For this you can rely on making a huge radius and allowing it
to scale down proportionately.
Bert: Yeah, it scales down, but equally. If the box is taller than wide,
it'll leave you straight sides.
?: It scales with the aspect ratio.
dbaron: It only works if you know the aspect ratio of the box.
ChrisL: Two use-cases. One is a button, one is an oval.
* dsinger lissajous figures
<Bert> lozenge
howcome: But you can hack buttons without %-per-side, but you can't do
ovals with %-is-width.
Bert: You can create lozenges by specifying "25in" for border-radius or
someething, that will never be that big, so it will scale down.
?: But when you scale it down you're not going to get a straight line.
howcome: are you talking about diamond shaped?
bradk: for the lozenge shape, it would scale down until the two corners
met and you'd have a lozenge shape.
howcome: So it's a button you want? A button you can specify today,
currently. You shouldn't have to rely on scaling down.
howcome: Just set the border-radius and do whatever you want.
ChrisL: You have to know the height.
howcome: Okay, if you don't know the height, you set it to big and it
rounds down.
fantasai: typically you have only one line of text in which case you can
use ems. Not perfect, but a good approximation.
plinss_: There are other options, like a %height or %width unit.
fantasai: Yeah, but it's not important enough to add right now.
howcome: I agree. Of course, I want the percentage to be of whatever
I want. ^_^
BradK: So %-per-side allows ovals, but you can get lozenges if you want.
<Bert> Does 'border-radius: 50%' give you a quarter circle, or does it
mean '50% / 50&'?
howcome: yes.
fantasai: So publish this as LC?
Peter: I think people will want a corner that is round but not 50%.
TabAtkins: Usually that's okay with a fixed size.
Peter: I'm okay with leaving it for public feedback.
plinss: People will use different sizes for corners with different types
of boxes. We can wait for public feedback.
plinss: Objections, or are we good for last call?
<sylvaing> LC! LC! LC!
everyone: *silence*
<ChrisL> Go CSS!
Peter: Okay, go to last call.
* ChrisL channels "We CAN" speech
RESOLUTION: Add %ages to border-radius, scaled indep to each side
fantasai: so add % to border-radius, scaling per side.
bradk: And use the same language in border-image.
fantasai: yeah.
RESOLUTION: Publish css3-background as LC
plinss: five minutes left. anything that can be handled?
TPAC Developer Meeting
----------------------
fantasai: Ian Jacobs asked me to give a talk at TPAC on developers day.
If anyone would like to co-present, or has suggestions to talk
about, let me know.
ChrisL: Maybe a talk about some fairly new stuff, but that's implemented
in at least one browser, maybe two, just to show progress being made?
* sylvaing finds himself immediately off the hook every time people say
'implemented in at least one browser'. And does not like it.
* ChrisL thinks sylvaing could fix that by, well, implementing more stuff :)
MultiCol
--------
howcome: LC period for multicol has ended. Not too many comments, so
I've prepared some notes.
Peter: You think you'll have that for next week?
howcome: Yeah.
Peter: Okay, still have five minutes.
text-overflow: shrink
---------------------
Peter: Have a proposal for text-overflow shrink.
fantasai: We discussed that a while ago, decided to drop it.
fantasai: Looks weird for last line, but I'm not actively editting CSS3 Text.
<fantasai> I'd probably drop features rather than add them at this point,
to try to stabilize what's there
Bert: We do need to get the vertical text out, but stretching the last
line of the block is very common.
Bert: I was at a book fair and all the high-end printing used that.
fantasai: Last line of the block? Or all lines?
Bert: Last Line? I can't tell - it was printed on paper, so I can't see
the specs. But the last line is definitely the same line length
as the previous.
howcome: One way of doing that is adjusting the spaces. Another way that
is useful for headers is to increase the font size.
Bert: It's very common to see either spacing out or changing the size.
howcome: I think we tried to do this, but a certain implementor reacted
negatively, saying it would bring us into unspecified situations.
BradK: When I was doing print, i would often use horizontal scaling to
squeeze things onto one line.
BradK: I found that less objectionable than changing the whole height.
fantasai: I can see it making sense for *one* line, or for *all* lines,
but it seems strange for the paragraph to be one size and the
last line being differenet.
?: I agree. For headings it makees sense where you stretch it out, and
the second line is a different size.
fantasai: Yeah.
Peter: Out of time, we'll take this up later.
Meeting closed.
<RRSAgent> http://www.w3.org/2009/10/07-CSS-minutes.html
Received on Wednesday, 7 October 2009 20:59:22 UTC