15:48:03 <RRSAgent> RRSAgent has joined #CSS
15:48:03 <RRSAgent> logging to http://www.w3.org/2009/10/07-CSS-irc
15:48:10 <glazou> Zakim, this will be Style
15:48:10 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 12 minutes
15:50:55 <arronei> arronei has joined #CSS
15:55:32 <dsinger> dsinger has joined #css
15:56:54 <Zakim> Style_CSS FP()12:00PM has now started
15:57:03 <Zakim> +TabAtkins
15:57:05 <TabAtkins> Woo frist!
15:57:20 <Zakim> +sylvaing
15:57:27 <dbaron> dbaron has joined #css
15:57:34 <Zakim> +[Apple]
15:57:40 <dsinger> zakim, [apple] has dsinger
15:57:40 <Zakim> +dsinger; got it
15:57:51 <Zakim> +plinss
15:58:00 <oyvind> oyvind has joined #css
15:58:16 <sylvaing> sylvaing has joined #css
15:58:18 <Zakim> +glazou
15:58:42 <plinss_> plinss_ has joined #css
15:59:45 <Zakim> +??P18
16:00:25 <plinss_> zakim, ??P18 is fantasai
16:00:27 <Zakim> +fantasai; got it
16:00:47 <bradk> bradk has joined #css
16:00:48 <Zakim> +CesarAcebal
16:01:03 <Zakim> +Bert
16:01:18 <ChrisL> ChrisL has joined #css
16:01:39 <ChrisL> rrsagent, here
16:01:39 <RRSAgent> See http://www.w3.org/2009/10/07-CSS-irc#T16-01-39
16:01:56 <ChrisL> rrsagent, make logs public
16:02:14 <Zakim> +bradk
16:04:21 <ChrisL> zakim, call chris-work
16:04:21 <Zakim> ok, ChrisL; the call is being made
16:04:22 <Zakim> +Chris
16:04:31 <dbaron> I'm getting "this passcode is not valid"
16:04:35 <dbaron> Zakim, passcode?
16:04:35 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), dbaron
16:04:40 <dbaron> but I have te right one
16:04:46 <ChrisL> i'm not getting any response at all
16:05:20 <ChrisL> zakim, call chris-work
16:05:20 <Zakim> ok, ChrisL; the call is being made
16:05:22 <Zakim> +David_Baron
16:05:22 <Zakim> +Chris.a
16:05:26 <plinss_> I didn't get a ring signal when I called, and no response at all until I called back...
16:05:30 <dbaron> Zakim, mute Baron
16:05:33 <Zakim> sorry, dbaron, I do not know which phone connection belongs to Baron
16:05:35 <plinss_> If you're having problems dialing in, just keep trying
16:05:37 <dbaron> Zakim, mute David_Baron
16:05:37 <Zakim> David_Baron should now be muted
16:05:47 <Zakim> -Chris
16:06:04 <ChrisL> aha
16:06:04 <dbaron> Zakim, who is on the phone?
16:06:04 <Zakim> On the phone I see TabAtkins, sylvaing, [Apple], plinss, glazou, fantasai, CesarAcebal, Bert, bradk, David_Baron (muted), Chris.a (muted)
16:06:07 <Zakim> [Apple] has dsinger
16:06:17 <Zakim> + +1.617.588.aaaa - is perhaps Simon
16:06:21 <Zakim> +ChrisL
16:06:27 <ChrisL> seventh time lucky, it seems
16:06:32 <glazou> hi ChrisL 
16:06:38 <ChrisL> hi glazou
16:06:46 <Zakim> -Chris.a
16:07:08 <howcome> howcome has joined #CSS
16:07:15 <bradk> Zakim, please transcribe
16:07:15 <Zakim> I don't understand 'please transcribe', bradk
16:07:21 <bradk> Ah, well
16:07:34 <szilles> szilles has joined #css
16:08:07 <sylvaing> scribenick:TabAtkins
16:08:08 <bradk> Merci, Tab
16:08:16 <dbaron> Zakim, who is noisy?
16:08:19 <TabAtkins> Zakim, scribenick: TabAtkins
16:08:19 <Zakim> I don't understand 'scribenick: TabAtkins', TabAtkins
16:08:23 <Zakim> +SteveZ
16:08:26 <Zakim> dbaron, listening for 10 seconds I heard sound from the following: glazou (22%)
16:08:36 <glazou> lot of noise in my bg sorry
16:08:39 <glazou> Zakim, mute me
16:08:39 <Zakim> glazou should now be muted
16:09:08 <TabAtkins> fantasai: I want to discuss CSS3 backgrounds early in the agenda.
16:09:09 <dsinger> ow
16:09:13 <glazou> uuuurgh
16:09:38 <TabAtkins> RRSAgent, scribenick TabAtkins
16:09:38 <RRSAgent> I'm logging. I don't understand 'scribenick TabAtkins', TabAtkins.  Try /msg RRSAgent help
16:09:49 <glazou> people, let me give you a few news from a former CSS WG Member, Robert Stevahn from HP : http://pikchur.com/hHt :-)
16:10:28 <TabAtkins> ChrisL: Elika, I presume you want to discuss border images?
16:10:42 <plinss_> s/ChrisL/plinss/
16:10:47 <TabAtkins> fantasai: No, that's CSS3 images.  The only issue I know of is to round up or down, or having a "round" keyword.
16:11:06 <TabAtkins> fantasai: Rather, the action of 'round' keyword.
16:11:27 <TabAtkins> ?: The issue is round up or down, right?  and it's only relevant at .5 of an image?
16:11:40 <glazou> TabAtkins: that was chrisL
16:11:54 <ChrisL> always round to the nearest, in my opinion
16:12:01 <glazou> Zakim, unmute me
16:12:01 <Zakim> glazou should no longer be muted
16:12:03 <TabAtkins> 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.
16:12:04 <ChrisL> s/?/ChrisL/
16:12:07 <Zakim> -bradk
16:12:20 <TabAtkins> fantasai: I'm convinced by Brad's argument that rounding up/down is okay.
16:12:21 <bradk> arrggghhh
16:12:30 <bradk> phone dropped
16:12:35 <Zakim> +[Microsoft]
16:12:43 <Zakim> +bradk
16:12:44 <TabAtkins> ?: Choice between round and truncate.
16:12:53 <dbaron> s/?:/ChrisL:/
16:12:53 <dsinger> ? huh?
16:13:05 <fantasai> ceil() vs. round() in the formula
16:13:11 <TabAtkins> ?: If you get, say, 3.95 images to fit, rounding down means dropping to 3 images, right?
16:13:18 <TabAtkins> Bleh, that's ChrisL at that point.
16:13:20 <arronei> zakim, Microsoft is arronei
16:13:20 <Zakim> +arronei; got it
16:13:48 <TabAtkins> ?: What we want isn't floor or ceiling, but windowsill!  Halfway up!
16:14:01 <dbaron> s/?:/ChrisL:/
16:14:15 <TabAtkins> ?: So, when discussing 3.95 images, should we go to 3 or 4?
16:14:19 <ChrisL> 4
16:14:38 <TabAtkins> fantasai: We definitely want to be scaling to closest number.
16:14:50 <glazou> Zakim, mute me
16:14:50 <Zakim> glazou should now be muted
16:15:04 <TabAtkins> fantasai: With always rounding down, we get *shape* distortion, while a high-enough resolution makes the stretching-up not bad.
16:15:30 <TabAtkins> 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.
16:15:55 <TabAtkins> fantasai: Also, we'll later be able to specify how many device px go into a CSS px.
16:16:12 <TabAtkins> ?: The problem is that that's assumign the author knows the width, but what if they don't?
16:16:41 <TabAtkins> 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.
16:16:53 <plinss_> s/?/plinss/
16:16:54 <TabAtkins> fantasai: The author at least should have a good idea of whther it's 3-4 tiles or 30-40 tiles.
16:17:12 <TabAtkins> fantasai: And if they're really fussy, they can just provide a higher-resolution image every time.
16:17:46 <TabAtkins> 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'?
16:18:12 <TabAtkins> 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.
16:18:26 <TabAtkins> ?: If the author doesn't need to decide, then we don't need to discuss this.  We can just decide.
16:18:27 <Bert> (In my experience, scaling images down never looks bad, while scaling up often does. More so with JPEG, but even with PNG.)
16:18:44 <TabAtkins> ?: But this really isn't an implementation cost.  Two more keywords is just like 4 lines of code.
16:18:50 <dsinger> but scaling down loses detail, whereas scaling up does not
16:18:59 <plinss_> s/?/ChrisL/
16:18:59 <TabAtkins> fantasai: I don't think people are asking for this.
16:19:05 <dsinger> sure, scaled down looks better as nothing is invented;  but something is lost
16:19:27 <dsinger> oh, we're talking non-propoertional scaling
16:19:30 <dsinger> ?
16:19:32 <TabAtkins> 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.
16:19:43 <dsinger> s/propoertional/proportional/
16:20:01 <TabAtkins> ?: 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.
16:20:11 <ChrisL> s/?:/Chrisl:/g
16:20:13 <TabAtkins> ?: I think we can always add ceil and floor later.
16:20:32 <plinss_> s/?/szilles/
16:20:38 <TabAtkins> fantasai: And you can always provide an image with twice the resolution.  It will always scale down.
16:21:04 <TabAtkins> 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.
16:21:13 <TabAtkins> fantasai: Agreed.  We can add it later if there is demand for it.
16:21:34 <TabAtkins> ?: If the image is vector, not raster, does it get resampled?
16:21:41 <fantasai> s/?/Sylvain/
16:22:05 <TabAtkins> ?: Well, with vector images the size will be telling you how large to draw it straight off.  You're not ever resampling.
16:22:20 <plinss_> s/?/chrisl/
16:22:50 <glazou> Zakim, unmute me
16:22:50 <Zakim> glazou should no longer be muted
16:23:30 <Bert> Future extension (but not really what I hope for...): 'background-repeat: repeat | space | round | ... | round-up | round-down'
16:23:32 <glazou> CSS WG delirium tremens 
16:23:52 <TabAtkins> straw poll!  Who can't live with round()?
16:24:02 <TabAtkins> I'm okay with it.
16:24:11 <glazou> I should have bet !!!!!
16:24:31 <glazou> glazou has left #css
16:24:39 <glazou> glazou has joined #css
16:24:40 <glazou> glazou has left #css
16:24:44 <TabAtkins> Bert: I don't like it.  I was doing some experiments, and scaling down always looked okay, while scaling up often looked bad.
16:24:57 <ChrisL> interpolation with nearest-neighbor will usually look like crap
16:25:00 <glazou> glazou has joined #css
16:25:04 <TabAtkins> Bert: Depends on the image, but you'll lose detail when getting small anyway.
16:25:19 <ChrisL> also attempting to scale in an indexed color space. Promote to 24bit first
16:25:36 <TabAtkins> 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.
16:25:43 <TabAtkins> ?: But does detail matter that much?
16:25:51 <TabAtkins> Bert: For backgrounds, no, but for borders it does.
16:25:51 <howcome> howcome has joined #CSS
16:26:00 <Bert> s/?/Sylvain/
16:26:28 <TabAtkins> szilles: It seems unusual to round in this situation.
16:26:56 <TabAtkins> 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.
16:27:33 <TabAtkins> 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.
16:28:01 <TabAtkins> plinss_: Bert, I heard that you're not opposed to round, but concerned that it won't give enough control?
16:28:12 <fantasai> He's concerned about quality, not about control.
16:28:29 <TabAtkins> 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.
16:28:49 <TabAtkins> ?: Pete, do you have an actual objection, or just a concern?
16:29:17 <TabAtkins> 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?
16:29:23 <TabAtkins> ?: I'm not against this.
16:29:40 <TabAtkins> fantasai: The tests I had used rounding for vector images.
16:29:46 <fantasai> s/text/
16:29:49 <plinss_> s/?/BradK/
16:30:32 <TabAtkins> ?: 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.
16:30:44 <plinss_> s/?/chrisl/
16:30:48 <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)
16:30:51 <fantasai> fantasai: we could go back to that
16:31:01 <TabAtkins> Bert: Okay, I think we should add text for the dividing by zero case.
16:31:06 <TabAtkins> fantasai: Yeah, that's easy to fix.
16:31:15 <TabAtkins> fantasai: Bert, you're concerned about the quality of the images being scaled up.
16:31:37 <TabAtkins> 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.
16:31:51 <TabAtkins> fantasai: But only have scaling-down-always if you would have to interpolate pixels.
16:32:15 <TabAtkins> 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.
16:32:50 <TabAtkins> BradK: I'd prefer keywords to doing that auto-detection.
16:33:10 <TabAtkins> Bert: Elika, you were saying you wanted a distincction between raster and vector image?
16:33:30 <TabAtkins> fantasai: No, distinction between when you have to interpolate pixels.  Low-res raster vs (high-res raster + vector).
16:33:42 <TabAtkins> Bert: So you can scale up as long as you don't exceed the original resolution?
16:34:03 <TabAtkins> ?: You can scale up as long as you don't scale up?
16:34:14 <plinss_> s/?/chrisl/
16:34:16 <TabAtkins> Bert: No, two-step process.  First scale by background-size, then apply rounding.
16:34:48 <TabAtkins> 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.
16:35:36 <TabAtkins> plinss_: Consensus?
16:35:42 <TabAtkins> BradK: I prefer less distortion.
16:35:55 <TabAtkins> me: I prefer the keyword approach.
16:36:35 <bradk> Yes it was
16:36:37 <TabAtkins> szilles: I prefer seeing more experience with how it's used rather than using a fairly complex algorithm that wont' be obvious.
16:36:56 <TabAtkins> ?: You have to think about what to do with browsers that don't recognize those new keywords.
16:37:01 <TabAtkins> szilles: They round.
16:37:10 <plinss_> s/?/dsinger/
16:37:33 <TabAtkins> fantasai: That won't be a problem.  There's not any deployed unprefixed versions yet.
16:37:46 <TabAtkins> szilles: They'd end up ignoring what they didn't understand, which means they'd go with the default.
16:38:03 <TabAtkins> plinss_: That's probably not the author's intent.
16:38:17 <TabAtkins> fantasai: They can list it twice, without the new keyword and then with; that will work.
16:38:37 <TabAtkins> plinss_: I'm hearing two different dissenting opinions.
16:38:38 <dsinger> I'm only asking questions, not dissenting
16:38:56 <TabAtkins> szillees: I say pick the simple solution now, see how people use it, and extend it later if necessary.
16:39:19 <TabAtkins> fantasai: I want no extra keywords unless people say "I'm unhappy with this pixelation."
16:39:31 <TabAtkins> fantasai: We're not publishing CR here, we can have comments.  People can give feedback.
16:39:58 <TabAtkins> plinss_: That works for me.  We can let people comment and see what comes out.
16:40:11 <TabAtkins> ChrisL: So go with round for now?
16:40:13 <TabAtkins> fantasai: Yes.
16:40:26 <bradk> no that was me
16:40:37 <TabAtkins> plinss_ Not hearing any objections?
16:40:41 <TabAtkins> Bert: Works for me.
16:40:44 <dsinger> s/was/works/
16:40:44 <fantasai> ACTION: fantasai mark this as an issue
16:40:44 <trackbot> Created ACTION-180 - Mark this as an issue [on Elika Etemad - due 2009-10-14].
16:41:04 <TabAtkins> fantasai: Can we publish last call, or are there more comments?
16:41:10 <TabAtkins> many: general agreement
16:41:15 <sylvaing> LC! LC! LC!
16:41:15 <TabAtkins> fantasai: Objections?
16:41:18 <TabAtkins> voice of the people: no
16:41:47 <TabAtkins> BradK: Is there a use for border-image-size?
16:42:16 <TabAtkins> BradK: You can't do the background-size with border-image, so I don't think that's a good idea.
16:42:33 <TabAtkins> fantasai: So you want to take an image and treat it as 2 devicepx equals 1 CSS px.
16:42:56 <TabAtkins> BradK: I can't do percentages in border-radius, but I can simulate this with border-image.
16:43:04 <TabAtkins> fantasai: I was thinking about dropping percentags from border-image.
16:43:16 <TabAtkins> BradK: I think you should do so, or else add it to border-image.
16:43:26 <TabAtkins> ?: Do we have % on border-radius now?
16:43:28 <TabAtkins> fantasai: no.
16:43:31 <TabAtkins> ?: we should add it.
16:43:34 <plinss_> s/?/howcome/
16:43:39 <TabAtkins> fantasai: Did we figure out what it means?
16:43:45 <dbaron> s/?:/howcome/
16:43:50 <TabAtkins> howcome: I have one suggestion.  I can send an email, though.
16:44:09 <TabAtkins> fantasai: That's the confusing thing.  We have impl that support % on border-radius, but they do different things.
16:44:21 <TabAtkins> fantasai: Some scale border-radius separately, some do them together.
16:44:33 <TabAtkins> howcome: I agree, but I think it's so useful that the spec should have it.
16:44:39 <TabAtkins> ?: Is it mainly useful for ovals?
16:44:40 <glazou> sorry guys I have to leave the call, bye
16:44:41 <TabAtkins> howcome: Yes.
16:45:02 <ChrisL> so 50% 50% gives you ovals
16:45:08 <TabAtkins> ChrisL: In other words, 50% 50% gives you ovals.
16:45:09 <Zakim> -glazou
16:45:14 <TabAtkins> Me: I like howcome's approach.
16:45:23 <TabAtkins> ?: I don't think that's what you want.
16:45:28 <TabAtkins> howcome: No, that's exactly what I want.
16:45:38 <TabAtkins> fantasai: If there's consensus we can put it in.
16:45:53 <TabAtkins> BradK: I think it shoudl be the same in border-radius and border-image, so peopl don't get confused about how it works.
16:46:04 <TabAtkins> plinss_: I'm not sure if % scaling on the side it's from will give people what they want.
16:46:12 <TabAtkins> fantasai: It's hard to switch between them.
16:46:28 <TabAtkins> fantasai: One of the most common effects is doing a percentage on one side and keeping it square.
16:46:58 <dbaron> Zakim, unmute David_Baron
16:46:58 <Zakim> David_Baron should no longer be muted
16:47:01 <TabAtkins> fantasai: And making it so there's no straight part.  You can rely on making a huge radius and allowing it to scale down proportionately.
16:47:19 <TabAtkins> Bert: Yeah, it scales down, but equally.  If the box is taller than wide, it'll leave you straight sides.
16:47:24 <dbaron> Zakim, mute David_Baron
16:47:24 <Zakim> David_Baron should now be muted
16:47:27 <TabAtkins> ?: It scales with the aspect ratio.
16:47:41 <dbaron> dbaron: It only works if you know the aspect ratio of the box.
16:47:43 <TabAtkins> ChrisL: Two use-cases.  One is a button, one is an oval.
16:48:09 <Bert> lozenge
16:48:12 <TabAtkins> howcome: But you can hack buttons without %-per-side, but you can't do ovals with %-is-width.
16:48:35 <TabAtkins> Bert: You can create lozenges by specifying "25in" for border-radius or someething, that will never be that big, so it will scale down.
16:48:45 <TabAtkins> ?: But when you scale it down you're not going to get a straight line.
16:48:51 <TabAtkins> howcome: are you talking about diamong shaped?
16:49:08 <TabAtkins> bradk: for the lozenge shape, it would scale down until the two corners met and you'd have a lozenge shape.
16:49:23 <TabAtkins> howcome: So it's a button you want?  A button you can specify today, currently.  You shouldn't have to rely on scaling down.
16:49:37 <TabAtkins> howcome: Just set the border-radius and do whatever you want.
16:49:46 <TabAtkins> ChrisL: YOu have to know the height.
16:49:57 <TabAtkins> howcome: Okay, if you don't know the height, you set it to big and it rounds down.
16:50:23 <TabAtkins> fantasai: typically you have only one line of text in which case you can use ems.  Not perfect, but a good approximation.
16:50:41 <TabAtkins> plinss_: There are other options, like a %height or %width unit.
16:50:49 <TabAtkins> fantasai: Yeah, but it's not important enough to add right now.
16:51:04 <TabAtkins> howcome: I agree.  Of course, I want the percentage to be of whatever I want.  ^_^
16:51:19 <TabAtkins> BradK: So %-per-side allows ovals, but you can get lozenges if you want.
16:51:25 <Bert> Does 'border-radius: 50%' give you a quarter circle, or does it mean '50% / 50&'?
16:51:28 <TabAtkins> howcome: yes.
16:51:39 <TabAtkins> fantasai: So publish this as LC?
16:52:11 <TabAtkins> plinss_: I think people will want a corner that is round but not 50%.
16:52:24 <TabAtkins> TabAtkins: Usually that's okay with a fixed size.
16:52:33 <TabAtkins> plinss_: I'm okay with leaving it for public feedback.
16:52:54 <TabAtkins> plinss: People will use different sizes for corners with different types of boxes.  We can wait for public feedback.
16:53:12 <TabAtkins> plinss: Objections, or are we good for last call?
16:53:20 <sylvaing> LC! LC! LC!
16:53:28 <TabAtkins> everyone: *silence*
16:53:30 <ChrisL> Go CSS!
16:53:46 <TabAtkins> plinss_: Okay, go to last call.
16:53:53 <fantasai> RESOLUTION: Add %ages to border-radius, scaled indep to each side
16:53:57 <TabAtkins> fantasai: so add % to border-radius, scaling per side.
16:54:05 <TabAtkins> bradk: And use the same language in border-image.
16:54:07 <TabAtkins> fantasai: yeah.
16:54:51 <fantasai> RESOLUTION: Publish css3-background as LC
16:55:03 <TabAtkins> plinss: five minutes left.  anything that can be handled?
16:55:24 <TabAtkins> 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.
16:55:58 <TabAtkins> 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?
16:56:21 <TabAtkins> howcome?: LC period for multicol has ended.  Not too many comments, so I've prepared some notes.
16:56:28 <TabAtkins> plinss_: You think you'll have that for next week?
16:56:35 <TabAtkins> howcome?: Yeah.
16:56:48 <TabAtkins> plinss_: Okay, still have five minutes.
16:57:00 <TabAtkins> plinss_: Have a proposal for text-overflow shrink.
16:57:09 <TabAtkins> fantasai: We discussed that a while ago, decided to drop it.
16:57:21 <TabAtkins> fantasai: Looks weird for last line, but I'm not actively editting CSS3 Text.
16:57:47 <Zakim> -SteveZ
16:57:50 <fantasai> I'd probably drop features rather than add them at this point, to try to stabilize what's there
16:57:54 <TabAtkins> Bert: We do need to get the vertical text out, but stretching the last line of the block is very common.
16:58:05 <TabAtkins> Bert: I was at a book fair and all the high-end printing used that.
16:58:12 <TabAtkins> fantasai: Last line of the block?  Or all lines?
16:58:34 <TabAtkins> 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.
16:58:58 <TabAtkins> ?: One way of doing that is adjusting the spaces.  Another way that is useful for headers is to increase the font size.
16:59:16 <TabAtkins> Bert: It's very common to see either spacing out or changing the size.
16:59:36 <TabAtkins> ?: I think we tried to do this, but a certain implementor reacted negatively, saying it would bring us into unspecified situations.
16:59:59 <TabAtkins> BradK: When I was doing print, i would often use horizontal scaling to squeeze things onto one line.
17:00:17 <TabAtkins> BradK: I found that less objectionable than changing the whole height.
17:00:40 <TabAtkins> 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.
17:01:02 <TabAtkins> ?: I agree.  For headings it makees sense where you stretch it out, and the second line is a different size.
17:01:05 <TabAtkins> fantasai: Yeah.
17:01:14 <Zakim> -[Apple]
17:01:15 <TabAtkins> plinss_: Out of time, we'll take this up later.
17:01:16 <Zakim> -sylvaing
17:01:17 <Zakim> -ChrisL
17:01:17 <Zakim> -Simon
17:01:18 <Zakim> -CesarAcebal
17:01:18 <Zakim> -bradk
17:01:18 <Zakim> -fantasai
17:01:18 <Zakim> -arronei
17:01:21 <Zakim> -plinss
17:01:23 <Zakim> -TabAtkins
17:01:25 <Zakim> -David_Baron
17:01:27 <Zakim> -Bert
17:01:29 <Zakim> Style_CSS FP()12:00PM has ended
17:01:31 <Zakim> Attendees were TabAtkins, sylvaing, dsinger, plinss, glazou, fantasai, CesarAcebal, Bert, bradk, Chris, David_Baron, Chris.a, +1.617.588.aaaa, ChrisL, SteveZ, arronei
17:03:26 <TabAtkins> Okay, can someone get me the link to the records?
17:03:41 <Bert> rrsagent, pointer?
17:03:41 <RRSAgent> See http://www.w3.org/2009/10/07-CSS-irc#T17-03-41
17:03:55 <Bert> rrsagent, make minutes
17:03:55 <RRSAgent> I have made the request to generate http://www.w3.org/2009/10/07-CSS-minutes.html Bert
17:04:06 <Bert> rrsagent, make logs public
17:04:43 <TabAtkins> Excellent.  I'll have minutes later today.
17:09:22 <TabAtkins> At least I'm getting decent at picking out Bert.  Dunno why his accent sounds french to me.
17:10:36 <plinss_> plinss_ has joined #css
17:25:38 <TabAtkins> I've still got a handful of unresolved ? speakers right at the end.  Can anyone help?
17:43:36 <ChrisL> Meeting: CSS WG telcon
17:44:12 <ChrisL> s/?: I think we tried/howcome: I think we tried
17:44:53 <ChrisL> s/?: One way /howcome: One way 
17:45:15 <ChrisL> rrsagent, make minutes
17:45:15 <RRSAgent> I have made the request to generate http://www.w3.org/2009/10/07-CSS-minutes.html ChrisL
17:48:20 <CesarAcebal> CesarAcebal has joined #css
19:04:58 <Zakim> Zakim has left #CSS
20:29:05 <dbaron> dbaron has joined #css
20:56:47 <howcome> howcome has joined #CSS
22:03:00 <fantasai> Bert: http://dev.w3.org/csswg/css3-background/#the-border-radius
22:06:59 <Bert> It doesn't answer the question I asked on IRC during the telcon: does 'border-radius: 40%' create a quarter circle or is it the same as 'border-radius: 40% / 40%'? :-)
22:07:51 <TabAtkins> Ah, you mean "If there is no slash, then the values set both radii equally." is ambiguous?
22:08:20 <Bert> Minor: the word "length" should be removed from a few occurrences in the the first para. It is not necerrily a length any more.
22:08:34 <Bert> Yes, equal percentage? or equal value?
22:10:07 <Bert> Also: computed value is probably "absolute length or specified percentage"
22:11:06 <Bert> Hmm, not literally that, but something like it, in plural.
22:13:00 <Bert> I think I prefer to make a single percentage make a quarter circle (and the percentage is a percentage of the width). You can always add a second percentage to refer to the height, but you cannot otherwise get a quarter circle.
22:16:29 <TabAtkins> That's really confusing, imo.
22:18:41 <Bert> What's more confusing: that 'border-radius: 1em' makes a circular arc and 'border-radius: 5%' does not? or that 'border-radius: 1em' is the same as '1em/1em', and '5%' is not the same as '5%/5%'?
22:19:28 <Bert> I think it makes little difference, but the latter is more powerful.
22:20:56 <Bert> (On the other hand, why anybody would use percentages, apart from 50%, I can't imagine. It makes the corner unpredictable and different for each box and/or each window size.)
22:20:59 <TabAtkins> The latter is more confusing to me.  The former seems sensical; all the border-radius components are 1em, or 5%.
22:21:38 <TabAtkins> You thinking what I'm thinking, Bert?
22:21:39 <Bert> Non-circular corners are very rare.
22:22:27 <Bert> Eh, not sure. What are you thinking?
22:22:30 <TabAtkins> % always refers to width, but border-radius can take a keyword value instead of its list of numbers, with only one current keyword - 'oval'.
22:23:42 <Bert> I had that thought, yes. It's simple. But are we sure that's really the only case Håkon needs?
22:24:08 <TabAtkins> I'm not sure.  I know it's by far the most *common* case in what Hakon needs.
22:24:16 <TabAtkins> We'd have to ask him if that's sufficient.
22:24:48 <TabAtkins> Of course, we also have to make sure it works for border-image.
22:27:17 <Bert> You mean: Brad may have a different case in mind where he needs percentages?
22:27:36 <TabAtkins> Yeah, and I agree with him that the two cases should work the same.
22:27:44 <TabAtkins> So lock Hakon and Brad in a room and let them hash it out.
22:29:34 <Bert> Well, in that case it's easier to just keep the percentages. :-)
22:30:13 <Bert> (After we remove the ambiguity of a single percentage.)
22:30:16 <TabAtkins> Bah.  Surely international travel costs can be justified!  This is SCIENCE we're talking about here!
22:34:22 <szilles> szilles has joined #css
22:43:00 <fantasai> TabAtkins: Actually, it's ENGINEERING
22:43:19 <TabAtkins> Still a discipline of SCIENCE.
22:43:22 <fantasai> Nope
22:43:37 <TabAtkins> http://wearscience.com/
22:43:47 <fantasai> Engineering uses knowledge to pursue design. Science uses design to pursue knowledge.
22:44:43 <TabAtkins> These pitiful details interest me not.  I'm off to SCIENCE something!
22:45:00 <fantasai> heh
22:49:35 <fantasai> Bert: ok, fixed the length->value thing
22:49:50 <fantasai> Bert: also tried clarifying that the second percentage is copied form the first
22:54:56 <Bert> So no way to make a circular arc with percentages then?
22:55:17 <fantasai> as the spec currently stands, no
22:55:40 <TabAtkins> Well, is there a use for that outside of lozenges? (Boxes with half-circles)
22:56:00 <TabAtkins> Because lozenges can be done no problem with the giant length hack.
22:57:43 <Bert> The word lozenge is ambiguous. Like Håkon, I interpreted it at first as diamond, not as pill-shaped.
22:58:04 <TabAtkins> Mac-style buttons, then.  ^_^
23:01:08 <Bert> The question can be reversed: is there a use for corners whose shape varies with the height of the box, but are not quarter circles?
23:01:23 <TabAtkins> You mean beyond ovals?
23:02:33 <Bert> Yes, I mean that the x radius stays constant while the y radius varies with the height of a box. (Because boxes vary much more often in height than in width.)
23:02:58 <fantasai> I can imagine wanting percentages against the height for things like buttons
23:03:01 <fantasai> that tend to vary more by width
23:03:16 <TabAtkins> Nod.
23:03:19 <fantasai> or tabs
23:03:33 <TabAtkins> Buttons tend to be squat and vary in width, as opposed to the average CSS box.
23:03:37 <fantasai> In that case you'd put a percentage agains the height and a fixed length against the width
23:03:51 <fantasai> I think we'll see that a lot for tabs, actually, now that I think about it
23:05:40 <Bert> But other than what may be common or not, my main argument is that taking a single percentage to mean equal radiuses gives more funcionality. You can always write two perentages, but you cannot otherwise get circular arcs.
23:06:19 <TabAtkins> I agree that it offers more functionality; that can't be argued.  I'm arguing that that's confusing, and think that the extra power granted by it isn't enough to offset this confusion.
23:07:01 <TabAtkins> (And, just for clarification, you can't get circular arcs *that are based on a percentage other than 50% of min(width,height)*.)
23:07:20 <TabAtkins> (As the giant-length hack can give you the 50% case.)
23:07:39 <Bert> My first thought was that it was confusing that a single value did *not* give me equal radii on all sides. By now I don't know what's confusing anymore. It's all equally non-memorable. :-(
23:08:05 <TabAtkins> Yeah, possibly.  Push to %h and %w units, and we'll be dandy.
23:08:11 <TabAtkins> s/to/for/
23:08:56 <fantasai> we don't need  %h and %w units
23:09:01 <fantasai> we just need some keywords
23:09:14 <fantasai> border-radius: 50% width
23:09:50 <TabAtkins> And the lack of a keyword indicates that the % refers to the correct side in context?
23:09:58 <fantasai> right
23:10:00 <Bert> Why do you say that you can't get circular except with 50%? In my interpretation of single percentages, *every* single percentage gives circular arcs.
23:10:12 <TabAtkins> (Yeah, %h and %w are a horrible idea anyway, as they'd make circular dependencies ridiculously easy.)
23:10:15 <fantasai> you have to pick something to reference
23:10:22 <fantasai> either width or height
23:10:37 <TabAtkins> Bert: I mean in my/Hakon's proposal, you can't get circular % arcs besides 50%.
23:15:45 <Bert> Fantasai, will you fix the computed value row as well?
23:16:23 <Bert> Anyway, it's well past bedtime for me. I'll check the damage tomorrow. :-)
23:16:31 <TabAtkins> Night, Bert.
23:36:34 <Curt`> Curt` has joined #css
23:40:03 <fantasai> ok
23:40:05 <fantasai> Thanks Bert :)