15:52:28 <RRSAgent> RRSAgent has joined #CSS
15:52:28 <RRSAgent> logging to http://www.w3.org/2010/05/05-CSS-irc
15:52:35 <glazou> Zakim, this will be Style
15:52:35 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 8 minutes
15:52:40 <glazou> RRSAgent, make logs public
15:56:03 <oyvind> oyvind has joined #css
15:58:05 <Zakim> Style_CSS FP()12:00PM has now started
15:58:12 <Zakim> +plinss
15:58:40 <Zakim> +[IPcaller]
15:58:40 <dbaron> dbaron has joined #css
15:58:53 <jdaggett> zakim, ipcaller is jdaggett
15:58:53 <Zakim> +jdaggett; got it
15:59:06 <Zakim> +glazou
15:59:14 <Zakim> +dsinger
15:59:43 <dsinger_> dsinger_ has joined #css
15:59:55 <dsinger_> zakim, who is on the phone?
15:59:55 <Zakim> On the phone I see plinss, jdaggett, glazou, dsinger
16:00:06 <Zakim> +bradk
16:00:07 <dsinger_> zakim, mute dsinger
16:00:07 <Zakim> dsinger should now be muted
16:00:20 <Zakim> +TabAtkins
16:00:24 <Zakim> +sylvaing
16:00:49 <bradk> good morning
16:01:00 <Zakim> +[Microsoft]
16:01:01 <szilles> szilles has joined #css
16:01:35 <arronei> zakim, Microsoft is me
16:01:35 <Zakim> +arronei; got it
16:02:06 <Zakim> +David_Baron
16:03:10 <Zakim> +??P18
16:03:24 <Zakim> +SteveZ
16:04:41 <Zakim> +smfr
16:04:45 <dbaron> Zakim, ??P18 is fantasai
16:04:45 <Zakim> +fantasai; got it
16:06:20 <tabatkins> ScribeNick: tabatkins
16:06:38 <tabatkins> plinss_: Anything on the agenda?
16:06:52 <tabatkins> plinss_: First topic: test suite status
16:06:56 <ChrisL> ChrisL has joined #css
16:07:03 <smfr> smfr has joined #css
16:07:08 <tabatkins> arronei: I've made good progress on tagging all test cases, and am still on track to have them all tagged/checked in this friday.
16:07:52 <tabatkins> fantasai: I talked with Richard about the i18n tests.  He's in India right now, and he'll get back to me next week.  For now I'm going to work on getting the reftests in, then I'll work on getting Hixie's test into a format we can use.  The conversion shouldn't take too long, but there may be some missing files somewhere.
16:07:58 <tabatkins> arronei: I may be able to find them.  We'll figure it out.
16:08:19 <tabatkins> plinss_: Sounds like progress is being made.
16:08:29 <Zakim> +ChrisL
16:08:40 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0553.html
16:08:47 <tabatkins> plinss_: Font issues.
16:08:53 <tabatkins> jdaggett: We went through a bunch of these.
16:09:03 <tabatkins> jdaggett: We got through part of Bert's comments last week, through point G.
16:09:10 <tabatkins> jdaggett: Remaining ones are h through k.
16:09:29 <tabatkins> jdaggett: H is titling-caps.  It's not really ideally specced, it's really "titling form".
16:09:45 <tabatkins> jdaggett: There was a suggestion from John Hudson about how to rewrite that.
16:10:07 <tabatkins> jdaggett: Part I, I went through and changed some of the values [didn't catch the exact values]
16:10:22 <fantasai> from e.g. lining-nums to lining-numberals
16:10:31 <tabatkins> jdaggett: ChrisL, you said you think just doing nums would be fine?
16:10:32 <fantasai> s/numberal/numeral/
16:10:35 <tabatkins> ChrisL: Yeah, I think it's fine.
16:11:13 <tabatkins> plinss_: I think in general we should spell things out.  If it's a well-known abbreviation or shortening, ok, but otherwise lets just use the longform.
16:11:42 <tabatkins> szilles: I think that "num" is an abbreviation for "number", not "numeral", and the two things are different.
16:11:55 <tabatkins> fantasai: I don't see a difference, but I'm not a typographer.
16:11:56 <bradk> lining-numes?
16:12:07 <tabatkins> jdaggett: So, steve, you'd prefer "numeral" to be spelled out?
16:13:22 <tabatkins> jdaggett: I'll leave it as "num" for now, until someone has stronger objections.
16:13:42 <tabatkins> jdaggett: Point j is wrong, the fraction is a unicode feature.
16:14:11 <tabatkins> jdaggett: Point k I put in to describe what it was, though it's really something for the webfonts group to talk about.
16:14:25 <tabatkins> jdaggett: I just didn't see why Bert thought this violated the web architecture.
16:14:51 <tabatkins> jdaggett: I don't think this is something to go into at great depth; the fonts group will talk about it, and then we can clarify it in our spec.
16:15:10 <dsinger_> zakim, who is here?
16:15:10 <Zakim> On the phone I see plinss, jdaggett, glazou, dsinger (muted), bradk, TabAtkins, sylvaing, arronei, David_Baron, fantasai, SteveZ, smfr, ChrisL
16:15:12 <Zakim> On IRC I see smfr, ChrisL, szilles, dsinger_, dbaron, oyvind, RRSAgent, Zakim, glazou, sylvaing, bradk, shepazu, miketaylr, jdaggett, krijnh, arronei, jgraham, karl, fantasai,
16:15:14 <Zakim> ... tabatkins, TabAtkins_, Hixie, plinss_, plinss, Bert, trackbot
16:15:25 <tabatkins> jdaggett: I'll leave it to bert to respond as he is so inclined. (Since he's not on the call.)
16:15:38 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Apr/0000.html
16:15:42 <tabatkins> jdaggett: Next is szilles comments on character-transform.
16:15:49 <sylvaing> thinks that CSS3 Fonts can't make same-origin normative; that's up to the Web Fonts WG. But it's relevant info for the spec so i like to have it there
16:15:57 <tabatkins> jdaggett: I think this works; I think it's probably better.
16:16:24 <tabatkins> jdaggett: Only caveat is that, the way this is worded now, if an OT font has a sub/super glyph it is used, otherwise the rendering is "as it is today".
16:16:38 <tabatkins> jdaggett: I think it would be best to specify that it falls back to an auto-generated sub/super.
16:16:48 <tabatkins> jdaggett: But that might have issues with nested elements.
16:17:12 <tabatkins> jdaggett: The tricky thing with doing OT sub/super scripts is that they can contain other elements that aren't in a typeface.
16:17:20 <tabatkins> jdaggett: They need the adjusted baseline and such, frex.
16:17:35 <tabatkins> jdaggett: I think we should come back to this after experimenting, and seeing if we need to change the fallback.
16:17:59 <tabatkins> jdaggett: Final issue is what to call the feature.  I don't see an ideal term here.
16:18:26 <tabatkins> jdaggett: I think the most accurate was "relative-script", but other people said that was awful.
16:18:46 <tabatkins> szilles: I proposed character-shift and use-font-shift.
16:19:00 <tabatkins> ChrisL: I'm not sure about the shift thing, it makes it sound like a baseline shift.
16:19:16 <tabatkins> jdaggett: If nested elements are involved, it's more like a baseline shift.
16:19:47 <tabatkins> szilles: I liked the "use-font-*", because you weren't faking it, you were using the font data.
16:20:08 <tabatkins> szilles: Or alternately, a font-variant-*?  Maybe font-variant-shift.
16:20:23 <tabatkins> jdaggett: For now I'll put in character-transform, and we can think more about the name.
16:20:35 <tabatkins> szilles: I can live with that.
16:20:49 <tabatkins> smfr: I wanted to follow up on the discussion about turning on kerning everywhere.
16:21:08 <tabatkins> smfr: In webkit if you go down the complex kerning-on path all the time, it significantly slows down our page performance.
16:21:21 <tabatkins> jdaggett: I'm not sure that should be classified as a webkit bug.  We fun on the same platform and we don't see it.
16:21:30 <tabatkins> smfr: I think david said that you only turn on kerning above a certain size.
16:21:37 <tabatkins> jdaggett: On Windows.  On Mac we run with kerning on all the time.
16:21:57 <tabatkins> smfr: Curious.  I guess we can improve it somewhat, but I'd like to wait for some data that it's okay.
16:22:06 <tabatkins> jdaggett: I think we left that the default was 'auto', which is defined by the UA.
16:22:13 <tabatkins> fantasai: I had a comment on character-transform.
16:22:34 <tabatkins> fantasai: I think, in order for nesting to work you need character-transform to not be inherited.
16:22:44 <tabatkins> fantasai: Suppose I have <sub>foo<span>bar</span></sub>.
16:22:57 <tabatkins> fantasai: If it's inherited, both sub and span have character-transform:sub.
16:23:23 <tabatkins> fantasai: I can't tell if the span is supposed to be a further sub of the foo, or if it's suppossed to be at the same level as everything else.
16:23:28 <Lachy> Lachy has joined #css
16:23:37 <tabatkins> jdaggett: That's something I should play around with.
16:26:06 <Zakim> +[Apple]
16:26:12 <Zakim> -dsinger
16:26:21 <alexmog> alexmog has joined #css
16:26:26 <tabatkins> plinss_: Next is the Selectors stuff.  Anne's not on the call.
16:26:41 <dsinger> dsinger has joined #css
16:26:47 <tabatkins> tabatkins: I had an issue that doesn't involve anne.  In Selectors, :nth-child says that the number can be omitted if a is 1 or -1.  It can't always be omitted for -1.
16:26:55 <tabatkins> dbaron: You can omit the "1", but not the "-".
16:27:04 <dbaron> fantasai, when fixing the editorial issue, the rules should end up saying that the sign cannot be omitted for -1, but the sign still can be omitted (as the previous paragraph says) for +
16:27:08 <tabatkins> tabatkins: Okay, so editorial issue then, that passage is very unclear if that's what's meant.
16:27:12 <tabatkins> fantasai: I can fix that.
16:27:22 <fantasai> I'm just going to say the <code>1</code> can be omitted
16:27:29 <dbaron> fantasai, since :nth-child(+n), :nth-child(n), and :nth-child(-n) should all be valid
16:27:43 <tabatkins> fantasai: Daniel sent me a message on an editorial note and I've replied to it, but haven't prepared a response yet.
16:27:52 <fantasai> s/prepared/gotten/
16:27:55 <dbaron> fantasai, ok, sounds good
16:28:55 <tabatkins> glazou: Since Anne's not here, I'm going to review the "serializing selectors" and post detailed comments, because otherwise it will flounder.
16:29:18 <Zakim> -jdaggett
16:29:19 <tabatkins> plinss_: Next topic, View Modes comments from WebAppsWG.
16:29:25 <tabatkins> glazou: There was confusion last week about this.
16:29:32 <tabatkins> glazou: We got two requests to review 2 documents.
16:29:34 <fantasai> fixed - http://dev.w3.org/csswg/selectors3/#nth-child-pseudo
16:29:44 <tabatkins> glazou: First was the View Mode spec, second was the View Mode Interface spec.
16:29:48 <tabatkins> glazou: This request is the first one.
16:29:58 <tabatkins> glazou: I posted comments a while ago when the first draft was released.
16:30:10 <tabatkins> glazou: I didn't have time to review it completely today, but it seems that all the changes I requested were done.
16:30:28 <tabatkins> glazou: Mainly it clarified a bit what is a "windowed"/"floating" application, and the prose is much better than it sued to be.
16:30:36 <fantasai> s/sued/used/
16:30:45 <tabatkins> glazou: Other than that I have no comments.
16:31:26 <tabatkins> plinss_: anyone else taken a look at this?
16:31:38 <tabatkins> tabatkins: I have, and I'm reasonably happy with it now that glazou's comments have been accepted.
16:31:55 <tabatkins> plinss_: So our formal response at this point is that we're happy and have no comments?
16:32:09 <tabatkins> glazou: Let me reread it again in detail, but probably yes.
16:32:24 <tabatkins> tabatkins: Deadline for comments is the 18th.
16:32:54 <tabatkins> plinss_: Next topic, empty MQ and the DOM.
16:33:02 <tabatkins> plinss_: There was some additional discussion on the list.
16:33:10 <tabatkins> plinss_: Where do we stand on that?
16:33:22 <tabatkins> glazou: david sent a message about that, and I and Sylvain posted followups.
16:33:31 <tabatkins> glazou: IMO I think that we have 2 options.
16:33:57 <tabatkins> glazou: First is to keep the syntactic rule unchanged, and change only the OM side.  But that means we have to serialize the empty list to "all".
16:34:08 <tabatkins> glazou: I don't really like the fact that you can't serialize back to what you got if you reparse.
16:34:20 <tabatkins> glazou: Second option is to change the syntax, and allow @media with no media before the {
16:34:39 <tabatkins> glazou: I spent some time thinking about it, and I think that even if it's a change, allowing @media without a media is better.
16:34:51 <fantasai> I note that we discussed this twice and both times reached the same conclusion to make @media { } invalid
16:35:03 <tabatkins> glazou: It's probably not in CSS2.1 right now, but it should be our goal.  Otherwise it's just too complex and will lead to edge cases.
16:35:16 <dbaron> I think I agree with glazou.
16:35:27 <tabatkins> tabatkins: I've no objection, and I like being able to serialize back and forth cleanly.
16:36:02 <tabatkins> smfr, sylvain: Like.
16:36:11 <tabatkins> dbaron: FF3.6 accepts @media with no media type.
16:36:16 <tabatkins> glazou: And has it mean "all"?
16:36:58 <tabatkins> glazou: We just need to make sure that @media without media is a known hack, such that we will break pages if we change this.
16:37:20 <tabatkins> dbaron: Yes, "all".
16:37:46 <tabatkins> dbaron: In 3.6, if you have a media rule that has media types, and you dynamically remove all of them, that is equivalent to "not all"
16:37:53 <tabatkins> dbaron: I suggested a possible change to MQ spec.
16:38:05 <tabatkins> glazou: That's a different issue.
16:38:15 <tabatkins> tabatkins: Yeah, but it's a confusing issue so that something needs to be resolved.
16:38:41 <tabatkins> glazou: I think a decision is needed here.  So, the proposal is to change @media in CSS3, and allow no media after the keyword, meaning "all".
16:38:54 <tabatkins> plinss_: Fine with me as long as we can reconcile it with the OM.
16:39:06 <tabatkins> glazou: There's nothing to reconcile.  We have nothing to do on the OM side.
16:39:49 <tabatkins> sylvaing: As to it being a hack, I doubt it is, since the behavior has changed for browsers across versions.  It's not stable enough to set up as a good hack.
16:40:01 <tabatkins> glazou: So no objections?
16:40:21 <tabatkins> RESOLVED: change CSS3 so @media accepts no media after the keyword.
16:40:30 <tabatkins> dbaron: Can I talk about the weird FF OM thing?
16:40:37 <tabatkins> dbaron: I think that behavior is relatively logical from the spec.
16:40:43 <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Apr/0592.html
16:40:52 <tabatkins> dbaron: In my post I pointed out 2 statements in the spec.
16:41:16 <tabatkins> If there's a query with an unknown media feature, or just a media feature value, it is ignored.
16:41:31 <tabatkins> dbaron: And then if all the media are ignored, it's equivalent to "not all".
16:41:50 <tabatkins> dbaron: So the weird thing is that you have to track what is ignored to see if what you have is an "all list" or a "not all list".
16:42:04 <tabatkins> dbaron: So if we want to make this interoperable, we have to figure out exactly what you have to track.
16:42:23 <tabatkins> dbaron: So if you have a list and you start removing a bunch of queries, what exactly happens.  And is it possible to remove the queries that are ignored.
16:42:54 <tabatkins> dbaron: Another way is to say that rather than the whole list is "not all", each individual ignored query is equivalent to "not all".  And I think that's simpler for the OM as a whole.
16:43:10 <tabatkins> ChrisL: That sounds better.  What was the whole "ignored queries" thing supposed to achieve?
16:43:29 <tabatkins> dbaron: It's supposed to match declarations, where if you dont' understand part of it you drop it all.
16:43:29 <fantasai> ChrisL, you want @media unknown-query { body { color: red; } } to not apply
16:44:16 <fantasai> Sylvain: You assume that an unknown query doesn't match.
16:44:44 <tabatkins> dbaron: I'd like to hear what Anne thinks about this.
16:44:53 <tabatkins> fantasai: I think he might have suggested it at some point.
16:45:04 <tabatkins> dbaron: I think the "not all" for the whole list came from Anne.
16:45:22 <tabatkins> sylvaing: So if you have queries that are ignored, and you serialize it, will you have "not all"s in the various places?
16:45:25 <tabatkins> dbaron: I think so, yes.
16:45:51 <tabatkins> plinss_: Do you want that, or do you want to preserve what was there when you reserialize?
16:46:14 <tabatkins> glazou: I have to think about that.
16:46:50 <tabatkins> plinss_: Otherwise you try to edit a stylesheet in an editor that happens to not understand the new declarations, you'll lose things.
16:46:55 <tabatkins> fantasai: That's how declarations work now.
16:47:00 <tabatkins> tabatkins: But we want to change that.
16:47:02 <Me> Me has joined #css
16:47:03 <fantasai> s/new declarations/new media queries/
16:47:13 <tabatkins> plinss_: Basically the difference between "treating it as not all" and "changing it to not all".
16:47:56 <tabatkins> dbaron: It's different from what we've always done for properties and rules, but I think it might make sense.
16:48:44 <tabatkins> plinss_: Don't have to make a decision on it right now; just throwing it out there.
16:48:53 <smfr> sylvaing: webkit too!
16:49:23 <tabatkins> plinss_: Get someone to ping Anne.
16:49:44 <tabatkins> ACTION Tab: ping anne about the MQ stuff re: empty media and ignore medias.
16:49:44 <trackbot> Created ACTION-227 - Ping anne about the MQ stuff re: empty media and ignore medias. [on Tab Atkins Jr. - due 2010-05-12].
16:50:19 <tabatkins> plinss_: Next topic, Tab revived a decades-old display-split issue.
16:50:23 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0023.html
16:50:29 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0022.html
16:50:36 <tabatkins> fantasai: Can we skip that for box-shadow first, since we can go to LC with them resolved?
16:51:03 <tabatkins> fantasai: If we like what the wording is in what I typed, I can add it to the spec.
16:51:08 <tabatkins> bradk: I like the new wording.
16:51:15 <tabatkins> dbaron: How does it match existing implementations?
16:51:23 <tabatkins> bradk: I don't think anyone matches the current spec fully.
16:51:37 <tabatkins> sylvaing: I like it, but I'll circle back with Brian.
16:51:56 <tabatkins> smfr: What would negative value of spread do if they would cause the height/width to go below 0?
16:52:04 <tabatkins> fantasai: I think at that point the shadow doesn't exist.
16:52:44 <tabatkins> bradk: I think still missing is a bullet point saying what the shape is if there is no spread or blur.
16:53:08 <tabatkins> fantasai: The shape should be the shape fo the border box, in the draft currently.
16:54:16 <tabatkins> bradk: [issue with some of the prose concerning shape of the shadow versus where it is drawn]
16:55:21 <smfr> ow my ears
16:55:22 <tabatkins> bradk: I was somewhat confused when it talks about altering the shape before it even says what the shape is, and then it immediately talks about drawing.
16:55:30 <tabatkins> fantasai: I can move the shape part up.
16:56:08 <tabatkins> smfr: Question about negative spread, will it transform a curved corner to sharp-edged?
16:56:12 <tabatkins> tabatkins: Yes.
16:56:40 <tabatkins> smfr: In many cases won't negative spread just make the shadow not appear?
16:56:45 <tabatkins> bradk: No, just use offset.
16:56:49 <tabatkins> tabatkins: Or an inset shadow.
16:57:06 <tabatkins> fantasai: A negative spread on an inset shadow will increase the size of the box.
16:57:33 <tabatkins> smfr: I think we might come to weird behaviors where the shadow disconnects from the edge of the box.
16:57:52 <tabatkins> fantasai: Spread changes the position of the shadow's edge.
16:57:57 <tabatkins> fantasai: It doesn't make the shadow move.
16:58:23 <tabatkins> smfr: The way shadows are implemented, you take the box, blit it to a bitmap with whatever color, then apply a gaussian blur.
16:58:47 <tabatkins> smfr: Then spread changes the shape with some not very well-defined algorithm.
16:58:57 <tabatkins> fantasai: Now the algorithm should be quite good.
16:59:06 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0022.html
16:59:11 <tabatkins> smfr: My problem is that spread isn't a transform on the box, it's some additional change on the box.
16:59:20 <tabatkins> smfr: We can't map that to an efficient hardware implementation.
16:59:35 <tabatkins> smfr: Ideally we'd want to push this to the GPU, but we can't map spread to the GPU.
16:59:44 <Zakim> -bradk
16:59:59 <tabatkins> tabatkins: Would a scale rather than a spread allow pushing to the GPU?
17:00:12 <bradk> I got dropped
17:00:15 <tabatkins> sylvaing: Yeah, a scale with the border-radius proportional allows you to easily do it in the GPU.
17:00:48 <bradk> Scaling is not spread
17:01:40 <tabatkins> tabatkins: Brad's the only one with sufficient experience in Photoshop et al, I think, so we just need to know if spread is *so useful* over a scale that it's worth the more difficult/slower implementation.
17:01:56 <tabatkins> ChrisL: Scale and spread are different in general, but for rounded boxes they're much more similar.
17:02:21 <tabatkins> sylvaing: I trust Brad to know if spread radius is more important to designers than a scale.
17:02:25 <bradk> Im not on the call any more, and can't get in again
17:02:39 <smfr> quick, let's remove spread ;)
17:02:51 <bradk> DOH!
17:03:16 <bradk> Scale would just be a completely different thing.
17:03:34 <glazou> BTW, IE9p2 has MQ ! congrats MSFT
17:03:43 <tabatkins> plinss_: So move to mailing list until next week.
17:03:53 <ChrisL> I noticed that too b ut have yet to test it
17:03:56 <tabatkins> fantasai: So is the question about whether people like/dislike spread, or if we want spread at all?
17:04:01 <bradk> What I was starting to say is that the shape with spread applied is really no different that a spape with an extra border applied
17:04:08 <tabatkins> smfr: If we have spread, we'd like it specified in a way that allows hw accelaration.
17:04:09 <bradk> or an outline
17:04:15 <tabatkins> smfr: Using scale would probably be the only one.
17:04:41 <bradk> except that the border-radius affects the inside radius of that fake border
17:04:43 <tabatkins> ChrisL: If you take the raster image, blur it, then do a threshold operation you'll get a spread.
17:05:15 <tabatkins> smfr: That's two blurs, though, which is expensive.
17:05:18 <bradk> If you want it to be a raster effect, then you don't get sharp corners
17:05:36 <tabatkins> tabatkins: Brad's pointing out that a spread is just like increasing the border.  Is that okay?
17:05:41 <fantasai> The UA may | approximate the spread shape by outsetting (insetting, for inner | shadows) the shadow's straight edges by the spread radius and | increasing (decreasing, for inner shadows) and flooring at zero | the corner radii by the same amount.
17:05:46 <bradk> In PhotoShop, there is a filter called "minimize" that has that sort of effect
17:05:58 <tabatkins> smfr: That might be okay.  Sorta confusing with inset.
17:06:11 <tabatkins> fantasai: I will draw pictures for you.
17:06:14 <smfr> :)
17:06:23 <tabatkins> fantasai: Or maybe Brad can draw pictures.
17:06:34 <bradk> For inset, it is like figuring out the shape of the content cox in the presence of padding
17:06:37 <bradk> sort of
17:06:42 <Zakim> -ChrisL
17:06:44 <Zakim> -smfr
17:06:45 <Zakim> -SteveZ
17:06:46 <Zakim> -David_Baron
17:06:48 <Zakim> -glazou
17:06:48 <bradk> I would be happy to draw pictures
17:06:49 <Zakim> -arronei
17:06:50 <Zakim> -fantasai
17:06:51 <glazou> sylvaing: bravo
17:06:51 <Zakim> -plinss
17:06:52 <Zakim> -sylvaing
17:07:05 <Zakim> -[Apple]
17:08:04 <bradk> I've been meaning to draw a diagram anyway...
17:08:13 <fantasai> bradk: We'll need two, I think.
17:08:27 <bradk> outer and inner?
17:08:28 <fantasai> bradk: One for the strict definition of spread ( perpendicularly outward)
17:08:35 <fantasai> bradk: (or inward)
17:08:41 <bradk> OK
17:08:41 <fantasai> bradk: And one for the approximation
17:08:47 <fantasai> bradk: which alters the width and the radii
17:08:54 <fantasai> bradk: they're not quite the same
17:09:26 <bradk> Im not sure I understand what approximation that's different
17:09:37 <fantasai> So, if you take an ellipse
17:09:54 <fantasai> and you stroke it with the inner edge of the stroke being the ellipse edge
17:10:00 <fantasai> the outer edge will not be an ellipse
17:10:39 <fantasai> Strictly speaking, that's what you want for spread -- an offset, perpedicular to the edge, of the spread amount
17:11:02 <fantasai> Imagine an ellipse with arrows pointing outward from the edge
17:11:08 <fantasai> like a sun, except elliptical :)
17:11:13 <bradk> OK
17:11:18 <fantasai> If the arrows are all the same length
17:11:30 <fantasai> and you draw a shape connecting their tips
17:11:35 <fantasai> you will not get an ellipse
17:11:42 <fantasai> You will get something that looks almost like an ellipse, but is not an ellipse
17:11:49 <fantasai> in the strict mathematical sense
17:12:04 <fantasai> in other words, you can't get it by defining slightly different elliptical radii
17:12:06 <Zakim> disconnecting the lone participant, TabAtkins, in Style_CSS FP()12:00PM
17:12:10 <Zakim> Style_CSS FP()12:00PM has ended
17:12:12 <Zakim> Attendees were plinss, jdaggett, glazou, dsinger, bradk, TabAtkins, sylvaing, arronei, David_Baron, SteveZ, smfr, fantasai, ChrisL
17:12:27 <smfr> smfr has left #css
17:12:28 <bradk> Umm... That is pretty much how Illustrator 88 used to do it, I think.
17:12:47 <fantasai> Strictly speaking, that outward offset of the edge is what you want for a spread
17:12:51 <bradk> sweeping a 1px line around the path to get a border
17:13:06 <fantasai> or 5px or whatever
17:13:06 <fantasai> yes
17:13:16 <fantasai> But since that's not an ellipse
17:13:19 <fantasai> it might be hard to calculate
17:13:28 <fantasai> So that's why there's an alternate definition there
17:13:40 <bradk> Do you mean because the "connect the dots" part is snot a smooth curve?
17:13:41 <fantasai> that allows you to approximate the shape by altering the radii
17:13:47 <fantasai> no, make it a smooth curve
17:14:00 <fantasai> # arrows -> infinity
17:14:09 <fantasai> It's not about the smoothness, it's about the geometry
17:14:17 <fantasai> For a circle, if you do that, you will get a bigger circle
17:14:32 <fantasai> but for an ellipse, you don't get an ellipse, you get something that looks like an ellipse but doesn't match its mathematical form
17:15:07 <bradk> OK. I think I have seen this, come to think of it. I will play around and see if I can recreate the difference.
17:16:41 <bradk> The idea of just scaling the elipse instead of offsetting the path is more palatable to the implementors?
17:18:35 <bradk> I have to go. Will try tinking with clear diagrams/illustrations of the concepts tonight or soon thereafter.
17:18:36 <tabatkins> Yeah.
17:19:41 <bradk> OK. Bye.
17:34:49 <TabAtkins_> TabAtkins_ has joined #css
17:40:00 <dbaron> dbaron has joined #css
17:44:58 <TabAtkins_> TabAtkins_ has joined #css
18:41:53 <alexmog> alexmog has left #css
19:27:17 <Zakim> Zakim has left #CSS
20:07:38 <arronei> arronei has joined #CSS