CSS WG telcon -- 07 Oct 2009

Woo frist!

<dbaron> I'm getting "this passcode is not valid"

<dbaron> but I have te right one

<ChrisL> i'm not getting any response at all

<plinss_> I didn't get a ring signal when I called, and no response at all until I called back...

<plinss_> If you're having problems dialing in, just keep trying

<ChrisL> aha

<ChrisL> seventh time lucky, it seems

<glazou> hi ChrisL

<ChrisL> hi glazou

<bradk> Ah, well

<sylvaing> scribenick:TabAtkins

<bradk> Merci, Tab

<glazou> lot of noise in my bg sorry

fantasai: I want to discuss CSS3 backgrounds early in the agenda.

<dsinger> ow

<glazou> uuuurgh

<glazou> people, let me give you a few news from a former CSS WG Member, Robert Stevahn from HP : http://pikchur.com/hHt :-)

plinss: Elika, I presume you want to discuss border images?

fantasai: No, that's CSS3 images. The only issue I know of is to round up or down, or having a "round" keyword.
... Rather, the action of 'round' keyword.

Chrisl: The issue is round up or down, right? and it's only relevant at .5 of an imageChrisL

<glazou> TabAtkins: that was chrisL

<ChrisL> always round to the nearest, in my opinion

fantasai: no, argument is whether we shoudl round up/down, or always down. Round up/down is nicer, but always down may be better in raster images.
... I'm convinced by Brad's argument that rounding up/down is okay.

<bradk> arrggghhh

<bradk> phone dropped

ChrisL: Choice between round and truncate.

<dsinger> ? huh?

<fantasai> ceil() vs. round() in the formula

Chrisl: If you get, say, 3.95 images to fit, rounding down means dropping to 3 images, right?

Bleh, that's ChrisL at that point.

ChrisL: 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

fantasai: We definitely want to be scaling to closest number.
... With always rounding down, we get *shape* distortion, while a high-enough resolution makes the stretching-up not bad.
... 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.
... Also, we'll later be able to specify how many device px go into a CSS px.

Chrisl: The problem is that that's assumign the author knows the width, but what if they don'tplinss

fantasai: You'll often know, 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.
... The author at least should have a good idea of whther it's 3-4 tiles or 30-40 tiles.
... And if they're really fussy, they can just provide a higher-resolution image every time.

plinss_: 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 higher-resolution.

Chrisl: 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.)

ChrisL: 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 this.

<dsinger> sure, scaled down looks better as nothing is invented; but something is lost

<dsinger> oh, we're talking non-proportional scaling

<dsinger> ?

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.

Chrisl: 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.

?: If the image is vector, not raster, does it get resampledSylvain

chrisl: Well, with vector images the size will be telling you how large to draw it straight off. You're not ever resampling.

<glazou> CSS WG delirium tremens

straw poll! Who can't live with round()?

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.

?: But does detail matter that muchSylvain

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.

plinss_: My objection is that you rejected round-up and round-down for complexity, but your workaround is a lot more complex than a keyword.
... 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?

plinss_: 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.

fantasai: The tests I had used rounding for vector images.

<fantasai> s/text/

chrisl: 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> 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> fantasai: we could go back to that

Bert: Okay, I think we should add text for the dividing by zero case.

fantasai: Yeah, that's easy to fix.
... Bert, you're concerned about the quality of the images being scaled up.
... 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.
... 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.
... I'd prefer keywords to doing that auto-detection.

Bert: Elika, 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?

?: You can scale up as long as you don't scale upchrisl

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.

me: I prefer the keyword approach.

<bradk> Yes it was

szilles: I prefer seeing more experience with how it's used rather than using a fairly complex algorithm that wont' be obvious.

dsinger: 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.

plinss_: That's probably not the author's intent.

fantasai: They can list it twice, without the new keyword and then with; that will work.

plinss_: 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."
... We're not publishing CR here, we can have comments. People can give feedback.

plinss_: That works for me. We can let people comment and see what comes out.

ChrisL: So go with round for now?

fantasai: Yes.

<bradk> no that works me

plinss_ Not hearing any objections?

Bert: Works for me.

<fantasai> ACTION: fantasai mark this as an issue [recorded in http://www.w3.org/2009/10/07-CSS-minutes.html#action01]

<trackbot> Created ACTION-180 - Mark this as an issue [on Elika Etemad - due 2009-10-14].

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

BradK: Is there a use for border-image-size?
... 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 devicepx equals 1 CSS px.

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.

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.
... 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.

Me: I like howcome's approach.

?: 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.

BradK: I think it shoudl be the same in border-radius and border-image, so peopl don't get confused about how it works.

plinss_: 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.
... One of the most common effects is doing a percentage on one side and keeping it square.
... And making it so there's no straight part. 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> 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.

<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 diamong 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.
... 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?

plinss_: I think people will want a corner that is round but not 50%.

TabAtkins: Usually that's okay with a fixed size.

plinss_: 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.
... Objections, or are we good for last call?

<sylvaing> LC! LC! LC!

everyone: *silence*

<ChrisL> Go CSS!

plinss_: Okay, go to last call.

<fantasai> 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.

<fantasai> RESOLUTION: Publish css3-background as LC

plinss: five minutes left. anything that can be handled?

fantasai: Ian Jacobs? is having a talk at TPAC on developers day. If anyone would like to help me, have 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?

howcome?: LC period for multicol has ended. Not too many comments, so I've prepared some notes.

plinss_: You think you'll have that for next week?

howcome?: Yeah.

plinss_: Okay, still have five minutes.
... Have a proposal for text-overflow shrink.

fantasai: We discussed that a while ago, decided to drop it.
... 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.
... 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 deifnitely the same line length as the previous.

howcome: One wayof 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.
... 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.

plinss_: Out of time, we'll take this up later.

Okay, can someone get me the link to the records?

Excellent. I'll have minutes later today.

At least I'm getting decent at picking out Bert. Dunno why his accent sounds french to me.

I've still got a handful of unresolved ? speakers right at the end. Can anyone help?

- DRAFT -

CSS WG telcon

07 Oct 2009

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output