/irc-logs / w3c / #css / 2008-05-12 / end

Options:

# Session Start: Mon May 12 00:00:00 2008
# Session Ident: #css
# [00:26] * Quits: sharovatov (vsh@83.239.161.121) (Quit: HTTP is like vodka (colorless, tasteless, and flavorless): connectionless, stateless, and one way))
# [01:35] * Joins: jd (jdaggett@202.221.217.78)
# [03:35] * Quits: dbaron (dbaron@71.204.153.3) (Ping timeout)
# [04:51] * Joins: dbaron (dbaron@71.204.153.3)
# [05:03] * Quits: bjoern (bjoern@84.56.218.76) (Quit: Quit)
# [08:53] * Joins: sharovatov (vitaly@88.87.71.83)
# [10:08] * Quits: dbaron (dbaron@71.204.153.3) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [10:26] * Quits: sharovatov (vitaly@88.87.71.83) (Ping timeout)
# [10:31] * Joins: Bert_ (bbos@128.30.52.28)
# [10:31] * Quits: Bert_ (bbos@128.30.52.28) (Quit: leaving)
# [12:39] * Joins: myakura (myakura@125.207.238.47)
# [14:18] * Joins: bjoern (bjoern@84.57.233.109)
# [15:34] * Quits: anne (annevk@77.163.243.203) (Connection reset by peer)
# [16:19] * Joins: anne (annevk@77.163.243.203)
# [17:12] * Quits: myakura (myakura@125.207.238.47) (Quit: Leaving...)
# [18:14] <fantasai> Bert: ping
# [18:14] <Bert> Morning, Elika.
# [18:14] <fantasai> Afternoon, Bert :)
# [18:15] <Bert> Evening officially started :-) and I'm about to move from the office to my couch at home.
# [18:15] <Bert> Can we start in, say, 30 minutes?
# [18:15] <fantasai> heh
# [18:15] <fantasai> sure!
# [18:15] <fantasai> that gives me time to get breakfast :P
# [18:15] * fantasai set her alarm for an hour late by accident
# [18:16] <fantasai> ^^;
# [18:47] * Joins: sharovatov (vsh@83.239.161.121)
# [18:52] <Bert> Had a good breakfast, Elika?
# [18:53] * sharovatov always wonders how it's like to live in a GMT -something timezone :D
# [18:54] <Bert> Busy mornings, quiet afternoons. The opposite of Europe. At least when you work in an international group such s W3C.
# [18:55] <sharovatov> heh... can imagine..
# [18:57] * Bert finds he doesn't have a lot of opinions on many of the remaining open issues... other than that most seem not urgent and can be postponed to a later update (if we ever make any).
# [19:01] * Joins: peterl (peter.lins@15.243.169.72)
# [19:01] <fantasai> ok, let's mark the ones we said we were going to close as closed
# [19:02] <fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2008JanMar/0153.html
# [19:02] <fantasai> That would be .. http://www.w3.org/Style/CSS/Tracker/issues/6
# [19:03] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/7
# [19:03] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/9
# [19:04] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/12
# [19:04] <Bert> You skipped 5 on purpose?
# [19:04] <Bert> (The fallback color)
# [19:04] <fantasai> we accepted that request
# [19:04] <fantasai> didn't we?
# [19:04] <Bert> Yes, we did.
# [19:05] <fantasai> ok, I'm just going to go throught the issues we rejected for now
# [19:05] <fantasai> and then make a separate list for the ones we accepte
# [19:06] <Bert> Still not clear on how to use Tracker: shouldn't we put this list of issues to close on the WG agenda so that the WG can close them, rather than us closing them on our own?
# [19:06] <Bert> But making two lists is fine.
# [19:07] <fantasai> I think we should close the issues we posted about last time
# [19:07] <fantasai> people have had more than a month to complain
# [19:07] <fantasai> And we'll post a summary again
# [19:07] <fantasai> so they can complain at the next telecon if they want
# [19:07] <fantasai> it's why I'm making separate lists..
# [19:08] <Bert> Fine with me.
# [19:09] <fantasai> I thought we closed of ISSUE-31 awhile ago
# [19:09] <fantasai> ?
# [19:10] <Bert> At a ftf, IIRC
# [19:10] <fantasai> ok, so http://www.w3.org/Style/CSS/Tracker/issues/31
# [19:11] <fantasai> I can't find the "flipping images" issue
# [19:11] <fantasai> We rejected that one too
# [19:12] <Bert> Yes, we did.
# [19:12] <fantasai> is there an issue?
# [19:12] <fantasai> in Tracker?
# [19:12] <Bert> Can't find it either.
# [19:14] <Bert> ACTION-8 maybe?
# [19:15] <fantasai> looks like it
# [19:18] <Bert> I'd say leave it without an issue for now. We'll see if somebody raises an issue on the last call.
# [19:18] <fantasai> ok
# [19:21] <Bert> So 5 issues rejected. Still 25 to go...
# [19:21] <Bert> How many accepted?
# [19:21] <fantasai> From last time..
# [19:21] <fantasai> Three
# [19:22] <Bert> 5, 8 and ?
# [19:22] <fantasai> one feature request, two fixes
# [19:22] <fantasai> scaling the middle image
# [19:22] <fantasai> seems to have no tracker issue
# [19:22] <fantasai> (for border-image)
# [19:22] <Bert> Oh yes.
# [19:23] <Bert> And 15 (clip bg color) also, I think.
# [19:23] <Bert> Although I'm now no longer sure that the fallback color should not be clipped.
# [19:23] <fantasai> The fallback color should be clipped
# [19:24] <fantasai> It should behave exactly like a normal color
# [19:24] <fantasai> except it only shows up when the image fails to load
# [19:24] <fantasai> imho
# [19:24] <Bert> OK, tha's what I concluded this afternoon, too.
# [19:24] <fantasai> ok
# [19:25] <fantasai> RESOLVED: background color (fallback and normal) get clipped by bottommost clip value
# [19:25] <fantasai> you want to edit the issue? I'll close off these other five
# [19:25] <Bert> Will do.
# [19:32] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/8
# [19:32] <fantasai> I think we should use background-position
# [19:33] <Bert> (I added a sentence about clipping the color to the draft.)
# [19:33] <Bert> How can you use bg pos with 'space'?
# [19:34] <fantasai> for the one-tile case
# [19:34] <fantasai> that's the remaining issue there
# [19:34] <Bert> Ah, sorry.
# [19:36] <fantasai> where did you add the sentence?
# [19:36] * fantasai can't find it
# [19:36] <Bert> Hmm, somehow I find that inelegant, but I don't know if it does any harm...
# [19:37] <Bert> Not yet regenerated. Only in the .src under bg-color
# [19:37] <fantasai> ah
# [19:39] <fantasai> For background-color, Anne suggested making the first value optional
# [19:39] <fantasai> so background-color: / white; would be valid
# [19:39] <fantasai> and be equivalent to background-color: transparent / white;
# [19:39] <fantasai> I think we should accept that proposal
# [19:39] <Bert> Hmm, starting with a slash? Not very nice.
# [19:40] <Bert> What is the harm in requiring transparent?
# [19:40] <fantasai> it would be the most common case
# [19:40] <fantasai> savs typing
# [19:40] <fantasai> avoids typos
# [19:40] <fantasai> etc :)
# [19:40] * fantasai thinks the avoids typos argument is good
# [19:41] <fantasai> typos won't be noticed if they only have an effect when teh image doesn't load
# [19:42] <fantasai> we can make it valid, if authors want to be explicit they can always specify transparent explicitly
# [19:42] <Bert> The most common usage is with 'background' shorthand. How does it look there?
# [19:42] <fantasai> pretty nice
# [19:43] <fantasai> background: url(semi-transparent.png) / white;
# [19:43] <fantasai> :)
# [19:43] <fantasai> I think that's much nicer than
# [19:43] <fantasai> background: url(semi-transparent.png) transparent / white;
# [19:43] <fantasai> personally
# [19:43] <fantasai> :)
# [19:44] <Bert> background: url(foo) / 50% 50% / white
# [19:44] <Bert> I guess a color and a size cannot be confused.
# [19:44] <fantasai> right
# [19:46] <fantasai> ok, so
# [19:46] <fantasai> do we have agreement on using background-position with space?
# [19:46] <Bert> I still don't like the possibility of a slash right after a colon, but OK.
# [19:46] <fantasai> heh
# [19:47] <fantasai> RESOLVED: accept Anne's suggestion to make the first color (the non-fallback color) in background-color optional.
# [19:47] <Bert> Yes, let's use bg-pos when there is no room for two tiles in one or both directions.
# [19:47] <fantasai> RESOLVED: use bg-pos to position image when repeat is 'space' and only one tile fits
# [19:47] <Bert> Also for the case when there is no room for even one tile, I assume.
# [19:47] <fantasai> right
# [19:48] <fantasai> I think we should reject Hyatt's text clip proposal http://www.w3.org/Style/CSS/Tracker/issues/17
# [19:48] <Bert> Agreed. Hyatt himself had better ideas later on.
# [19:49] <fantasai> RESOLVED: ISSUE-17 Proposal for 'text' value for 'background-clip' rejected.
# [19:49] <fantasai> I suggest we reject ISSUE-21 http://www.w3.org/Style/CSS/Tracker/issues/21
# [19:50] <fantasai> it's just an alternate syntax for inset(), which we already rejected
# [19:50] <Bert> Yes, let's stick with background-size.
# [19:51] <Bert> It's more verbose :-) but easier to read, I think.
# [19:51] <Bert> (Not really more verbose in the shorthand, though.)
# [19:54] <fantasai> RESOLVED: 4-offset syntax for background-position rejected, duplicate of ISSUE-12
# [19:55] <fantasai> I think ISSUE-14 is closed as many, right?
# [19:55] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/14
# [19:55] <Bert> Yes, all feedback points to more than one clip value.
# [19:56] <fantasai> RESOLVED: ISSUE-14 closed background-clip has layered values
# [19:56] <Bert> (I added text to the draft for ISSUE-8.)
# [19:56] <fantasai> ok
# [19:57] * Quits: bjoern (bjoern@84.57.233.109) (Quit: Quit)
# [20:00] <fantasai> I think we should close http://www.w3.org/Style/CSS/Tracker/issues/23 as no change
# [20:00] <fantasai> imho 'each-box' is much more understandable
# [20:00] <fantasai> I also think background-break should be called background-bounds
# [20:00] <fantasai> seems to me it's much more about the bounding box than it is about how to breakt he background
# [20:01] <Bert> 'discontinuous' was a remark in the draft since a long time. It's hard to type :-) 'each-box' is fine.
# [20:01] <fantasai> RESOLVED: ISSUE-23 closed, keep 'each-box'
# [20:01] <Bert> Hmm, bg-bounds sounds like bg-clip.
# [20:03] <fantasai> sounds more like background-origin to me :)
# [20:04] <Bert> I think the word "break" is to make an association with "page break."
# [20:04] <fantasai> k
# [20:04] <fantasai> roc raised an issue
# [20:04] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Apr/0475.html
# [20:05] * Joins: bjoern (bjoern@84.57.235.233)
# [20:05] <fantasai> saying that bounding-box and continuous shouldn't be equivalent for blocks
# [20:05] <fantasai> if you think about multi-col layout, they really should be different
# [20:06] <Bert> Good point.
# [20:06] <Bert> The text wasn't written with columns in mind :-)
# [20:06] <fantasai> I know :)
# [20:07] <fantasai> I'll make that change.
# [20:07] <Bert> OK
# [20:07] <fantasai> We also should consider that in paginated modes where the "major writing direction" or whatever Paged Media calls it.. is vertical text
# [20:07] <fantasai> then the continuous boxes should be attached side to side
# [20:07] <fantasai> not top-to-bottom
# [20:08] <Bert> Really?
# [20:08] <fantasai> because you'd lay out the pages side-to-side if you wanted to turn them into a scroll
# [20:08] <fantasai> yes
# [20:09] <Bert> Same is true for horizontal text made into a scroll. But is a scroll the right metaphore?
# [20:09] <fantasai> horizontal text made into a scroll would connect down
# [20:10] <fantasai> you don't scroll horizontally, you scroll vertically
# [20:10] <fantasai> I'm not sure about paper scrolls
# [20:10] <Bert> Hebrew bible scrolls don't. Only scrolls in costume films do.
# [20:10] <fantasai> hmm
# [20:10] <fantasai> true
# [20:11] <fantasai> but on the screen
# [20:11] <fantasai> you scroll vertically for horizontal text
# [20:11] <fantasai> and horizontally for vertical text
# [20:11] <Bert> Line printers and cash register srolls are vertical, indeed.
# [20:12] <Bert> That's a question I had: are there text readers for vertical text that scroll sideways?
# [20:12] <fantasai> I'm not sure, we'd have to ask Paul
# [20:13] <fantasai> But scrolling vertically would be really really awkward
# [20:13] <Bert> You'd turn the pages into columns. The line length remains the same.
# [20:13] <fantasai> yeah, but that's really awkward with a scrolling mechanism
# [20:14] <fantasai> works fine if you're paginating
# [20:14] <fantasai> click down, next page, etc
# [20:14] <fantasai> but scrolling is awkward because you never want to be halfway between "pages"
# [20:14] <fantasai> it would be like reading multi-column text in a vertical scrolling viewer
# [20:14] <Bert> ... as happens very often when you read PDF on screen :-(
# [20:14] <fantasai> yes
# [20:14] <fantasai> not nice
# [20:15] <fantasai> found some photos of anicent chinese scrolls
# [20:15] <fantasai> they are horizontal
# [20:15] <fantasai> http://www.schoyencollection.com/china_files/ms2152n.jpg
# [20:15] <fantasai> more: http://www.schoyencollection.com/china.htm
# [20:18] <fantasai> so, I think we should connect the pages like I said
# [20:18] <fantasai> we can introduce another keyword later, if it becomes necessary, for Hebrew-style scroll attachment
# [20:18] <fantasai> which is designed for writing in columns
# [20:18] <Bert> For a repeated bg it doesn't really matter how you arrange the pages, but for 'repeat-x' or 'repeat-y' it is not clear what the author expects.
# [20:18] <fantasai> s/columns/multi-columns/
# [20:19] <fantasai> it should match the screen rendering
# [20:19] <fantasai> which is what I'm suggesting here
# [20:19] <fantasai> think about it.
# [20:20] <fantasai> If I want flowers flowing down the beginning-end of my lines of text
# [20:20] <fantasai> for English I'd use repeat-y
# [20:20] <fantasai> and expect it to continue throughout my whole document when printed
# [20:20] <fantasai> for vertical Japanese I'd use repeat-x
# [20:20] <fantasai> and expect it to continue thorughout my whole document when printed
# [20:21] <fantasai> if the pages were attached as for English with 'continuous'
# [20:21] <fantasai> then I'd only get flowers on my first page
# [20:21] <Bert> I would use 'each-box' in that case...
# [20:21] <fantasai> no, because I want the patter to not restart on each page
# [20:21] <fantasai> that's why I chose 'continuous'
# [20:22] <Bert> Can you notice that it restarts?
# [20:22] <fantasai> and again, it *wouldn't look like the screen rendering* if I chose 'continuous'
# [20:22] <fantasai> if you attach the pages vertically
# [20:22] <Bert> If you can, it might even be better to force it to restart.
# [20:22] <fantasai> but it would if you attach them horizontally
# [20:23] <fantasai> it might
# [20:23] <fantasai> but my point is again, if I want it to look like the screen rendering
# [20:23] <fantasai> the pages in vertical text must attach side to side
# [20:23] <fantasai> and looking like the screen rendering is what the author presumably expects
# [20:24] <Bert> I think the 'continuous' mode is mostly for images that are not repeated: to force that there is exactly one, even if there several pages.
# [20:24] <fantasai> Same thing!
# [20:24] <fantasai> I pick a large landscape as my image, that floats into nothingness off to the side
# [20:24] <fantasai> my text is vertical
# [20:24] <fantasai> it scrolls to the side
# [20:24] <fantasai> when I print it
# [20:24] <fantasai> I want the same effect on my pages
# [20:24] <fantasai> as if the screen rendering got cut up
# [20:25] <fantasai> not as if the text shifted to below my picture, where there is no picture!
# [20:27] <fantasai> are you seeing this, or do I need to draw a picture?
# [20:27] <Bert> I find it hard to imagine that pages scroll sideways, even if the text is vertical. But it's not my expertise. Let's put it in and see what other people say.
# [20:27] <fantasai> scrolling for vertical text is intended to work as I describe, Paul and I agree on this already
# [20:27] <fantasai> ok
# [20:28] <fantasai> RESOLVED: Make 'continuous' attach page boxes side-to-side in vertical writing modes, ask i18n for feedback
# [20:28] <fantasai> A related issue is ISSUE-222
# [20:28] <fantasai> er
# [20:28] <fantasai> A related issue is ISSUE-22
# [20:28] <Bert> :-)
# [20:28] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/22
# [20:30] <fantasai> I'm not sure what to do here...
# [20:30] <Bert> Difficult...
# [20:31] <fantasai> If there was no sizing issue
# [20:31] <fantasai> then I'd say, use the y-coords based on the page breaks
# [20:31] <fantasai> but reposition the images on the second page
# [20:31] <fantasai> that way right-aligned images stay right-aligned
# [20:31] <fantasai> and left-aligned images stay left-aligned
# [20:32] <Bert> Yes, I was thinking the same: centered images should be centered on both pages.
# [20:32] <fantasai> but then the question is, for things like 'round', what happens?
# [20:33] <fantasai> or background-size: 100%
# [20:34] <fantasai> We can define sizing and placement separately,
# [20:34] <fantasai> I think we do want to specify placement like I described above
# [20:34] <fantasai> so alignment stays true
# [20:34] <fantasai> but sizing is tricky
# [20:35] <Bert> Do it twice: position & size the image as if the second page was as wide as the first and also vice versa. Then on the first page display the part that is visible according to the first method and on the second the background as placed with the second width.
# [20:35] <fantasai> That's an interesting idea
# [20:35] <Bert> ... Assuming the left (or right?) margins are aligned.
# [20:36] <fantasai> start
# [20:36] <fantasai> but actually it doesn't matter
# [20:36] <Bert> Not for 'round' or 'space', at least.
# [20:37] <fantasai> I can't think of a case where it would matter
# [20:37] <fantasai> note, this would apply for 'continuous'
# [20:37] <fantasai> for 'bounding-box' I guess it would make sense to take the largest rectangle that can contain all the boxes
# [20:37] <fantasai> and position/place the images in there
# [20:37] <fantasai> no?
# [20:38] <Bert> Yes, that seems right.
# [20:39] * Bert goes to starts the coffee machine...
# [20:41] <fantasai> RESOLVED: pagination of bounding-box and continuous background-break modes as described above ('bounding-box' takes union of all boxes, aligned to start edge; 'continuous' resizes and repositions backgrounds using y-coords in relation to other boxes and only widht of this box)
# [20:42] <fantasai> ACTION: fantasai, edit spec for pagination-related issues above
# [20:42] * trackbot-ng noticed an ACTION. Trying to create it.
# [20:42] <trackbot-ng> Sorry, couldn't find user - fantasai,
# [20:42] <fantasai> ACTION: fantasai edit spec for pagination-related issues above
# [20:42] * trackbot-ng noticed an ACTION. Trying to create it.
# [20:42] <trackbot-ng> Created ACTION-62 - Edit spec for pagination-related issues above [on Elika Etemad - due 2008-05-19].
# [20:44] * fantasai takes a break too
# [20:47] * Bert looking for actions to create for self... Can't find any...
# [20:51] * Joins: dbaron (dbaron@63.245.220.241)
# [20:52] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/27
# [20:53] <fantasai> (if the border image is wider than the element, then the border widths should shrink proportionally until they fit.)
# [20:53] <fantasai> I think the idea makes sense, though
# [20:54] <fantasai> it solves a different problem
# [20:54] <fantasai> the existing behavior solves a different problem
# [20:56] <fantasai> this behavior lets you change the size of the border when you use an image without changing the size of the element or its content
# [20:56] <Bert> It does, but I'm not yet clear on the (dis)advantages in my mind...
# [20:56] <fantasai> the existing behavior lets you use an image border without having to worry about adjusting the padding
# [20:57] <Bert> Right, the padding gets a different function.
# [20:57] <fantasai> in the current behavior the padding stays consistent: in this proposal you might not have enough padding
# [20:58] <fantasai> note, if you're using border-box sizing, then the size of the element will be consistent
# [20:58] <fantasai> in the current proposal
# [20:58] <fantasai> only the size of the content box changes
# [20:59] <Bert> I don't see why box-sizing has an effect?
# [20:59] <fantasai> the problem with the current behavior is that if you specify the size of the box
# [21:00] <fantasai> the border-box size changes dependign on whether your UA can render border-image or not
# [21:00] <fantasai> if you use border-box sizing, that problem doesn't exist
# [21:00] <fantasai> the border-box size is constant whether or not you use border-image
# [21:01] <fantasai> the content-box size changes instead
# [21:02] <fantasai> for that reason I think I'm leaning towards keeping the spec as-is
# [21:02] <fantasai> also the behavior proposed here.. you can simulate it in most cases with multiple backgrounds
# [21:03] <fantasai> if that's what you want
# [21:03] <fantasai> what do you think?
# [21:03] <Bert> Still thinking...
# [21:05] <Bert> Seems that the current spec gives slightly more control over old vs new UAs, but I'm not sure how important that is.
# [21:05] <fantasai> it also applies for cases where images are turned off or they don't load for some reason
# [21:06] <fantasai> and I think that will be fairly important for several years, until all major UAs have border-image support
# [21:07] <Bert> Hmm, I can't decide :-(
# [21:08] <fantasai> let's keep it as is
# [21:08] <Bert> OK, doesn't seem a huge advantage either way.
# [21:09] <fantasai> RESOLVED: close ISSUE-27 (make border widths in border-image not affect width/height calculations) as no change
# [21:09] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/29
# [21:09] <fantasai> I think you have a proposal in the spec to reduce all radii proporionally, right?
# [21:10] <Bert> Yes, that seemed the best algo.
# [21:10] <fantasai> I think it's good too
# [21:10] <fantasai> let's close this :)
# [21:11] <Bert> OK.
# [21:11] <fantasai> RESOLVED: close ISSUE-29, accepted to reduce all radii proportionally until no conflict
# [21:11] <fantasai> I think ISSUE-30 should be resolved by the WG
# [21:11] <Bert> The text needs a fix, though: the algo is currently in an example instead of in normative text.
# [21:11] <fantasai> heh, ok
# [21:12] <fantasai> action you?
# [21:12] <Bert> ACTION: Bert to make algorithm 3 for ISSUE-29 normative.
# [21:12] * trackbot-ng noticed an ACTION. Trying to create it.
# [21:12] <trackbot-ng> Created ACTION-63 - Make algorithm 3 for ISSUE-29 normative. [on Bert Bos - due 2008-05-19].
# [21:13] <fantasai> I think we should close issue-28 as no change
# [21:13] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/28
# [21:13] <fantasai> I don't think anyone would bother using the keyboard
# [21:13] <fantasai> and it just complicates the syntax
# [21:13] <Bert> I agree.
# [21:13] <fantasai> RESOLVED: close ISSUE-28 ('transparent' keyword for centerless border image) as no change
# [21:14] <fantasai> Do you have an opinion on ISSUE-26?
# [21:14] * fantasai doesn't really care...
# [21:15] <Bert> I'd like to allow calc(), and that implies, I think, that percentages should be defined.
# [21:16] <fantasai> I don't think allowing calc() should necessitate allowing percentages
# [21:16] <fantasai> calc() should be defined such that it allows percentages if the property allows them, and doesn't if it doesn't
# [21:18] <Bert> That's possible, but I think of calc() as effectively a 4-tuple (a,b,c,d): a % + b em + c px + d ex
# [21:19] <fantasai> that's fine, but there are still some properties where we would want to allow calc but not percentages
# [21:19] <fantasai> so it needs to be defined in a way that honors such restrictions
# [21:20] <Bert> Percentages seem nice for consistency, too: can make a border that is as wide as the margin, even if the margin is a percentage.
# [21:21] <Bert> I haven't looked at all places where calc() might appear yet.
# [21:21] <Bert> Should do so soon...
# [21:22] <Bert> line-height: calc(50% - 2px) ?
# [21:22] <fantasai> calc should be valid anywhere that takes a length
# [21:24] <Bert> Yes, that's the principle and I believe it works. Still like to go through all properties one by one, though.
# [21:25] <Bert> I see no problems with the properties in CSS2, that's already a good sign.
# [21:26] <Bert> But let's get back to backgrounds and borders :-)
# [21:27] <fantasai> heh, yes
# [21:27] <fantasai> let's send ISSUE-26 to the WG
# [21:27] <Bert> OK. I guess I'd like for consistency's sake to allow percentages on borders. If nothing else, it avoids that we have to restrict calc().
# [21:28] <Bert> Ditto for padding (but that is a different module).
# [21:28] <fantasai> padding already takes percentages, doesn't it?
# [21:28] <Bert> Yes, it does.
# [21:29] <Bert> Wrong choice of words.
# [21:30] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/20
# [21:30] <fantasai> is that a close-no-change?
# [21:30] <Bert> I'd say so.
# [21:31] <fantasai> RESOLVED: close ISSUE-20 (scale up vs. scale down for 'round') as no change
# [21:31] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/13
# [21:32] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/24
# [21:34] <Bert> It seems there should be a way to reduce the number of properties, but I don't really know how.
# [21:34] <fantasai> adding 'border-box' and 'padding-box' and 'content-box' keywords to background-position makes sense
# [21:34] <fantasai> background-origin is also a pretty bad name
# [21:35] <fantasai> problem is how it interacts with the border shorthand
# [21:35] <fantasai> er, background shorthand
# [21:36] <fantasai> I'm in favor of ISSUE-24
# [21:36] <fantasai> if we're not merging origin with anything else, then I think it and clip should match in the shorthand
# [21:37] <fantasai> if we want to merge background-position and background-origin
# [21:37] <fantasai> then I suggest adding the box keywords before/after position's current values
# [21:37] <fantasai> and allowing clip in the shorthand preceded by the keyword 'clip'
# [21:38] <fantasai> and if 'clip' appears by itself, it clips to the origin box
# [21:39] <fantasai> background: url(...) border-box top left clip;
# [21:39] <fantasai> background: url(...) clip border-box top left; would expand to background-clip: border-box; background-position: top left;
# [21:39] <fantasai> I'm not sure how this interacts with hyatt's already-implemented stuff, though
# [21:39] * Quits: dbaron (dbaron@63.245.220.241) (Ping timeout)
# [21:40] <fantasai> we should ask for feedback
# [21:41] <Bert> Yes, but 13 and 24 together lead to many different options. We should make a list of them, otherwise the feedback risks not be very useful.
# [21:41] <fantasai> ok
# [21:42] * fantasai studies the issue more
# [21:42] <fantasai> actually..
# [21:42] <fantasai> having background-origin influence background-size, background-position, and potentially background-clip
# [21:42] <fantasai> I think it should not be merged with any of them
# [21:43] <fantasai> I do wish we had a better name :)
# [21:43] <fantasai> an origin is usually a point, not a rectangle
# [21:44] <Bert> background-calculation-base ? A bit long...
# [21:44] <fantasai> heh
# [21:44] <fantasai> yes, a bit long :)
# [21:46] <fantasai> background-box?
# [21:47] <fantasai> anyway
# [21:47] <Bert> Hmm, not immediately wrong.
# [21:48] <Bert> Although I'm hoping that there is a way to do without the property altogether without making the other syntaxes too ugly.
# [21:48] <fantasai> the problem is we have like 3 properties dependent on this thing
# [21:49] <Bert> Yes, that's why I want to get rid of it :-)
# [21:49] <fantasai> merging it with any one of them would be.. unfair isn't quite the right word
# [21:49] <Bert> It's like box-sizing: it works indirectly, and I don't like indirections in CSS.
# [21:49] <fantasai> yeah, but I can't think of any better options :(
# [21:50] <fantasai> if it didn't affect -size, I'd be in favor of merging with -position
# [21:51] <Bert> Do bg-pos and bg-size *need* to have the same "origin"?
# [21:51] <fantasai> it should be hard to make them /not/ have the same 'origin'
# [21:51] <fantasai> I can't think of any case where you'd want them to be different
# [21:51] <fantasai> and lots of ways that could happen by accident if we made it possible
# [21:52] <fantasai> I propos:
# [21:52] <fantasai> ...
# [21:52] <fantasai> I propose:
# [21:52] <fantasai> - closing ISSUE-13 no change
# [21:53] <Bert> And if bg-size depended on bg-pos?
# [21:53] <fantasai> - allowing the shorthand to take the bg-origin values
# [21:54] <fantasai> - allowing the shorthand to take the two keywords 'clip' and 'no-clip', which mean "make bg-clip match bg-origin" and "don't clip the background per ISSUE-16" respectively
# [21:54] <fantasai> if bg-size depended on bg-pos...
# [21:54] <Bert> I think that is a good solution, I just have this feeling that it is not the *best* :-(
# [21:55] <fantasai> which is?
# [21:55] <fantasai> the proposal I typed, or the proposal you typed? :)
# [21:55] <Bert> Do 'clip' and 'no-clip' apply to 'background-clip' too?
# [21:55] <fantasai> 'no-clip' should apply to background-clip
# [21:55] <fantasai> not sure about 'clip'
# [21:56] <fantasai> we might just make it a shorthand thing, and not a computed-value thing, in which case no
# [21:56] <fantasai> or we could make it a computed-value thing, in which case we'd need a keyword for bg-clip, yes
# [21:57] <fantasai> although for bg-clip, if we wanted a keyword to match the origin, we'd probably want something like "background-clip: origin", not "background-clip: clip"
# [21:57] <fantasai> :)
# [21:59] <Bert> Yes, that works, but it is getting uglier again, with too many different keywords.
# [21:59] <fantasai> I think we could just leave it as a shorthand thing
# [22:00] <fantasai> so background-clip: border-box | content-box | padding-box | no-clip
# [22:00] <fantasai> that's it
# [22:01] <fantasai> (it has to be 'no-clip', not 'none', because of the 'none' keyword in background-image.. just like no-repeat rather than repeat: none)
# [22:01] <Bert> Do you need the 'clip' keyword at all then?
# [22:01] <fantasai> yes
# [22:02] <fantasai> because the default is that clip *doesn't* match the origin :(
# [22:03] <fantasai> I warned you people in 2003!!!! but the CSSWG didn't listen to me :(
# [22:03] <fantasai> http://lists.w3.org/Archives/Public/www-style/2003Oct/0039.html
# [22:06] * Bert is trying to write a matrix of all combinations of origin and clip.
# [22:06] <fantasai> heh
# [22:09] <fantasai> Hey Bert, what does Safari do on http://fantasai.tripod.com/www-style/2003/background-attachment.html ?
# [22:09] <fantasai> For 'scroll', does the background scroll with the text or over it?
# [22:09] <fantasai> Firefox scrolls the text over it, but Konqueror scrolls the background with the text
# [22:10] <Bert> Fixed and scroll act the same: text scrolls, background is fixed.
# [22:11] <fantasai> k
# [22:11] <Bert> Difference is when I scroll the window as a whole.
# [22:11] <fantasai> right
# [22:11] * fantasai really doesn't understand what the wg was thinking when they defined this
# [22:13] <fantasai> Any thoughts on http://www.w3.org/Style/CSS/Tracker/issues/16 , then?
# [22:13] <fantasai> Can we accept?
# [22:15] <Bert> Seems well defined, if somewhat difficult to predict for authors.
# [22:15] <fantasai> they can always use position: relative; z-index: #; to control
# [22:16] <Bert> True.
# [22:17] <fantasai> so, accept?
# [22:17] <Bert> What does it do in the case you just showed, with scrollbars?
# [22:18] <fantasai> gets clipped by 'overflow' :)
# [22:18] * Joins: glazou (daniel@82.247.96.19)
# [22:18] <glazou> hi
# [22:18] <fantasai> hello
# [22:18] <glazou> plinss: peter, you're here ?
# [22:19] <Bert> OK, let's add it. If it is too expensive to implement, we're sure to hear about it.
# [22:19] <glazou> hello fantasai
# [22:19] <fantasai> yep
# [22:19] <fantasai> we can mark it at-risk
# [22:19] <fantasai> RESOLVED: add 'no-clip', mark at-risk (ISSUE-16)
# [22:19] * glazou is just back from a long week-end in france
# [22:20] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/43
# [22:20] <sharovatov> wow
# [22:21] * Joins: neanton (neanton@195.248.181.208)
# [22:22] * Joins: _LuzZza (luza@80.250.181.18)
# [22:23] <fantasai> Bert: does that make sense?
# [22:26] <Bert> Still struggling with the 'clip' keyword. It seems to make very little difference with just saying that clip is the same origin if origin is set in the shorthand.
# [22:26] <Bert> 43 makes sense.
# [22:26] <fantasai> hm
# [22:26] <Bert> Let's adopt 43.
# [22:26] <fantasai> I guess we could say that :)
# [22:27] <Bert> s/same/same as/
# [22:27] <fantasai> RESOLVED: accept ISSUE-43 -- make background-origin/background-clip keywords match box-sizing
# [22:28] <fantasai> So, the proposal is now
# [22:28] <fantasai> - allow background to take bg-origin values, if any of these are present set background-clip to the same thing
# [22:28] <fantasai> - allow no-clip as a background shorthand
# [22:28] <fantasai> keyword, it sets bg-clip only
# [22:28] <fantasai> - close ISSUE-13 no change
# [22:33] <Bert> The only difference I see is that with 'clip' you can get the combination origin=content and clip=border, while without 'clip' you can't. (Unless you use the longhand, of course.)
# [22:34] <Bert> So I'm in favour of that last proposal: no 'clip'
# [22:35] <fantasai> ok
# [22:35] <fantasai> I agree, I think it makes more sense :)
# [22:35] <fantasai> should we resolve on that?
# [22:35] <fantasai> that would also accept ISSUE-24
# [22:36] <Bert> Yes, let's do that.
# [22:36] <fantasai> RESOLVED: proposal above accepted, close ISSUE-13 no change, accept ISSUE-24
# [22:37] <fantasai> So, to fix CSS2.1's rather ridiculous set of defaults, you could add * { background: padding-box; } to your style sheet :)
# [22:37] <Bert> Though I may yet think of a way to simplify the set of properties in time for the CR...
# [22:37] <fantasai> ok
# [22:37] <Bert> Indeed.
# [22:38] <fantasai> Ok, box-shadows
# [22:38] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/40
# [22:38] <fantasai> I think that
# [22:38] <fantasai> a) The default should remain 0 0 for the offsets
# [22:39] <fantasai> b) it could be useful to allow a blur radius alone
# [22:41] * Joins: dbaron (dbaron@63.245.220.241)
# [22:41] <Bert> OK. Syntax soemthing like: x y blur? | blur
# [22:41] <fantasai> yes
# [22:42] <fantasai> quite a few of the examples I've seen show something like that
# [22:43] <fantasai> actually, we might want to consider 41 first
# [22:43] <Bert> But we should look if ISSUE-41 doesn't influence our decision.
# [22:43] <fantasai> right :)
# [22:43] <Bert> :-)
# [22:43] <fantasai> just a sec, let me split out the second part of it
# [22:44] <fantasai> ok
# [22:44] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/41
# [22:44] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/44
# [22:45] * Quits: bjoern (bjoern@84.57.235.233) (Quit: Quit)
# [22:45] <fantasai> So, I think we should accept adding a 4th value for spread
# [22:45] <fantasai> A lot of comments on the css3.info thread asked for it
# [22:45] <fantasai> and iirc several comments on webstandards.org's thread asked for it too
# [22:46] <fantasai> http://www.css3.info/css-drop-shadows/
# [22:47] <Bert> OK. It eems harmless in terms of affecting existing features and potentially useful.
# [22:48] <fantasai> RESOLVED: Add 4th length value to box-shadow for "spread" (ISSUE-41)
# [22:48] * Bert wonders where in the network is the bottleneck that keeps that page from appearing on my screen...
# [22:50] * Parts: neanton (neanton@195.248.181.208)
# [22:51] <Bert> Light source distance and spread seem equivalent. You only need one or the other. (Or spread is more powerful: it can shrink as well as grow the shadow.)
# [22:51] <fantasai> yeah, I think we don't need light source distance
# [22:51] <fantasai> spread should be enough
# [22:52] <fantasai> For issue-44, we could add an "inset" keyword
# [22:53] * Joins: bjoern (bjoern@84.56.216.45)
# [22:53] <Bert> The visual effect is nice, but aren't background and border-image enough? Another keyword complicates the syntax.
# [22:54] <fantasai> I don't know
# [22:54] <fantasai> you could ask the list
# [22:54] <fantasai> this is another request that has come up several times, mostly as a "glow" request
# [22:55] <glazou> any agenda item you want to include in next conf ?
# [22:55] <fantasai> yes
# [22:55] <fantasai> several
# [22:55] <fantasai> I will make a list
# [22:55] <glazou> can you please send them to w3c-css-wg ?
# [22:55] <fantasai> sure
# [22:55] <glazou> thank you
# [22:57] <fantasai> plinss: did you check in your changes to Selectors?
# [22:57] <fantasai> or should I just move the spec and have you merge later?
# [22:57] <glazou> plinss is idle
# [22:57] <fantasai> meh
# [22:58] <fantasai> glazou: there are open issues on the Selectors spec
# [22:58] <glazou> yes
# [22:59] <glazou> providing the preparation of my divorce happening on wednesday leaves me enough time tomorrow for that, I'll work on it
# [22:59] <Bert> The inside shadow only seems to be useful for a glow effect. Or maybe even only to make the box appear as a bubble (like 'border: outset', but more Mac than Motif-like :-) )
# [23:00] <Bert> Huh, glazou, what is that you're saying?
# [23:00] <fantasai> Bert: Brad posted some more examples, see http://bradclicks.com/cssplay/Shadows.html
# [23:00] <glazou> exactly what I said
# [23:01] <Bert> I'm sorry to hear that :-(
# [23:01] <glazou> eh
# [23:02] <glazou> me too
# [23:02] <fantasai> Bert: the layering of the letters looks terrible , but aside from that it looks reasonable
# [23:02] <Bert> Yes, I saw that page.
# [23:03] <Bert> The inside shadows with an offset look terrible.
# [23:03] <Bert> The inside shadow with only spread and no offset nor blur seem useless; they are just borders.
# [23:04] <fantasai> I think he's trying to illustrate what happense
# [23:04] <fantasai> I don't think it would be used
# [23:04] <fantasai> it looks /weird/
# [23:04] <Bert> The inside shadow with blur shows the "bubble" effect I was thinking of.
# [23:05] <fantasai> that's interesting, I didn't think of it that way :)
# [23:05] <fantasai> it seems useful, let's ask the WG (hyatt especially) what they think
# [23:07] <Bert> OK, but my opinion remains that if it can be done with border-image (which I think it can), then I'd like to avoid adding the inside/outside feature.
# [23:08] <fantasai> ok
# [23:08] <fantasai> we can leave it to CSS4 :)
# [23:08] <sharovatov> O_o CSS4
# [23:09] <Bert> I have to think about the letters, though. Is that a text-decoration or not?
# [23:09] <fantasai> text-shadow
# [23:09] <fantasai> although i think they'd look better if the shadow were applied to the text as a whole, and not to individual glyphs
# [23:10] <fantasai> sharovatov: read the CSS 2007 Snapshot
# [23:10] <sharovatov> thanks!
# [23:13] * glazou still live in european TZ and needs to sleep, bye people
# [23:13] <fantasai> bye
# [23:13] <Bert> Something like hyphenation would be much higher on my list of priorities than fonts with 3D effects. There is SVG if I need that...
# [23:13] * Quits: glazou (daniel@82.247.96.19) (Quit: zzz)
# [23:13] <fantasai> Bert: so.. issue 40?
# [23:14] <fantasai> I think we can veto changing the default offset
# [23:14] <fantasai> Several people have posted in opposition, none in favor
# [23:14] <fantasai> and I oppose that change as well :)
# [23:14] <Bert> Let's see. We can make offset optional if there is no spread. How about with a spread value...
# [23:14] <fantasai> also it would be inconsistent with text-shadow, which is already implemented
# [23:15] <fantasai> with a spread value.. you'd have to specify all four
# [23:15] <fantasai> because there's no way to distinguish..
# [23:15] <Bert> Yes, the non-zero default was more of a theoretical exercise.
# [23:15] <fantasai> RESOLVED: non-zero default offsets rejected, defaults shadow offsets remain 0 0
# [23:16] * fantasai adds a note to the issue
# [23:16] <fantasai> I'm ok with leaving the offsets required
# [23:17] <fantasai> it was just an idea, since several examples so far have been using blur without offsets..
# [23:17] <fantasai> but they would really want blur + spread with no offsets
# [23:17] <fantasai> and we can't do that
# [23:17] <Bert> It could work like this: 1 value -> blur, 2 values -> offset, 3 values -> offset + blur, 4 values -> offset + blur + spread
# [23:17] <Bert> Now, how easy to learn & remember is that syntax?
# [23:17] <fantasai> yeah, I'm just afraid it will be confusing
# [23:18] <fantasai> The advantage of requiring offsets is that you remember only that the end values are dropped
# [23:18] <fantasai> offsets, offsets+blur, offsets+blur+spread
# [23:18] <fantasai> perhaps we should close that no change, and just fix the syntax errors
# [23:18] <fantasai> ?
# [23:18] <Bert> I haven't found it hard to put two 0's in front of my blur values.
# [23:18] <Bert> Seems a very minor nuisance.
# [23:19] * trackbot-ng Cascading Style Sheets (CSS) Working Group http://www.w3.org/Style/CSS/Tracker/
# [23:19] * fantasai nods
# [23:19] <fantasai> resolve no change?
# [23:19] <Bert> OK, require the offsets and fix the grammar
# [23:20] <fantasai> RESOLVED: ISSUE-40 offsets required for shadows, grammer needs fix for errors
# [23:20] <Bert> Same grammar as for text-shadow (although there is a redundant "?" in that grammar).
# [23:21] <fantasai> where?
# [23:21] <fantasai> I think this was one of the cases where && would be useful :)
# [23:21] <Bert> <color> only needs a ? in one of the two branches.
# [23:21] <fantasai> oh
# [23:21] <fantasai> heh
# [23:21] <Bert> Yes, don't hesitate to use &&.
# [23:22] <fantasai> it's not defined anywhere!
# [23:22] <Bert> We can define it somewhere :-) But it may not be as useful as it seems.
# [23:22] <fantasai> if we could put it into the CSS2.1 intro...
# [23:22] <fantasai> it would shorten <shadow> by a half
# [23:23] <Bert> <length>{2,4} && <color>?
# [23:23] <Bert> But it still needs the ? after color.
# [23:23] <fantasai> that would work
# [23:23] <fantasai> yeah, that's fine
# [23:24] <fantasai> at least it doesn't have to be repeated
# [23:24] <fantasai> the whole pattern in reverse
# [23:25] <fantasai> For http://www.w3.org/Style/CSS/Tracker/issues/32 I think we want the cut-out effect
# [23:25] <fantasai> hyatt said that was fine
# [23:25] <Bert> Define the grammar notation in the snapshot? It should be in the CSS3 Introduction, but that is not likely to be published soon.
# [23:25] <fantasai> or ever
# [23:26] <fantasai> we could define it in the snapshot, but then things would have to depend on the snapshot
# [23:26] * Quits: sharovatov (vsh@83.239.161.121) (Quit: HTTP is like vodka (colorless, tasteless, and flavorless): connectionless, stateless, and one way))
# [23:26] <fantasai> and the snapshot is supposed to be mostly meta-information...
# [23:26] <fantasai> we could do it though
# [23:26] <Bert> Shadows outside was my original goal, indeed. That's what I found in printed material.
# [23:26] <fantasai> ok, let's do it
# [23:26] <fantasai> RESOLVED: shadows for 'box-shadow' only painted outside the border box
# [23:26] <fantasai> (ISSUE-32)
# [23:27] * fantasai goes through the list
# [23:27] <fantasai> covered ISSUE-8
# [23:27] <Bert> So that's a "no change" in fact.
# [23:27] <fantasai> ISSUE-10, ISSUE-11 deferred to WG discussion
# [23:28] <fantasai> ISSUE-13 closed no change
# [23:28] <fantasai> ISSUE-14 closed as layered
# [23:28] <fantasai> ISSUE-15 closed clip both colors
# [23:28] <fantasai> ISSUE-16 accepted no-clip
# [23:28] <fantasai> ISSUE-17 closed rejected
# [23:28] <fantasai> ISSUE-18..
# [23:29] <fantasai> shall we reject 18?
# [23:29] <Bert> None are really better than -size, are they? Yes, let's reject.
# [23:30] <fantasai> on a related note, there was a suggestion to add 'contain' and 'cover' from the 'image-fit' property
# [23:30] <fantasai> RESOLVED: ISSUE-18 closed no change
# [23:30] <Bert> Interesting.
# [23:31] * fantasai files an issue
# [23:31] <fantasai> ISSUE-19.. close no change?
# [23:32] <fantasai> or accept?
# [23:33] * fantasai isn't convinced it would be that useful
# [23:33] <fantasai> I suppose we could mark it at-risk...
# [23:33] <Bert> The contain and cover seem more useful. Yes, not convinced either.
# [23:34] <fantasai> ok, so add contain and cover, don't add scaling factors?
# [23:35] <Bert> Yes, that would be my choice.
# [23:35] <fantasai> RESOLVED: ISSUE-45 add 'contain' and 'cover' to background-size
# [23:35] <fantasai> RESOLVED: close ISSUE-19, scaling factors for bg image, as no change
# [23:35] <fantasai> ISSUE-20 closed no change
# [23:35] <fantasai> ISSUE-21 closed rejected
# [23:36] <fantasai> ISSUE-22 have proposal, need edits
# [23:36] <fantasai> ISSUE-23 closed no change
# [23:36] <fantasai> ISSUE-24 accepted as above
# [23:36] <fantasai> ISSUE-25 ...
# [23:37] <fantasai> comments on multiple borders?
# [23:37] <Bert> ISSUE-19 is rejected, rather than no change, I think. The spec currently allows scaling numbers.
# [23:37] <fantasai> ok
# [23:37] <fantasai> I think we should reject 25
# [23:38] <fantasai> but we can ask the WG in case implementors want it
# [23:38] * fantasai adds that to the WG discussion list
# [23:38] <Bert> Yes, leave something for XSLT and XBL :-)
# [23:38] <fantasai> ISSUE-26 deferred to WG
# [23:38] <fantasai> ISSUE-27 closed no change
# [23:39] <fantasai> ISSUE-28 closed no change
# [23:39] <fantasai> ISSUE-29 fixed in spec
# [23:39] <fantasai> ISSUE-30 deferred to WG (didn't we discuss this already at an F2F?)
# [23:39] <fantasai> ISSUE-32 deferred to WG
# [23:40] <fantasai> ISSUE-40 rejected feature changes, accepted grammar fix
# [23:40] <fantasai> ISSUE-41 accepted spread value
# [23:40] <fantasai> ISSUE-42 accepted
# [23:40] <fantasai> ISSUE-43 accepted
# [23:41] <fantasai> ISSUE-44 deferred to WG
# [23:41] <Bert> I don't remember a discussion on 30 (radius percentages), but it may wellbe that we did.
# [23:41] <fantasai> ISSUE-45 accepted
# [23:41] <fantasai> we definitely mentioned it in relation to not making radius affect the content box bounds
# [23:41] <fantasai> although whether we discussed adding it, I don't remember
# [23:42] <fantasai> one problem is that there are two ways to interpret %: relative to that dimension on the box, or relative to the shortest dimension of the box
# [23:43] * Bert assigns a "product" to issue-44
# [23:43] <fantasai> I just did that
# [23:43] <fantasai> :)
# [23:45] <Bert> Yes, 'border-radius: 10px' is a quarter circle, but 'border-radius: 5%' ?
# [23:48] <fantasai> let's action me to ask css3.info what they'd expect :)
# [23:48] <Bert> I think a single radius should always lead to a quarter circle, and a single percentage should be relative to the width (or line progression?), because on two siblings, the width is the same, but the height rarely is.
# [23:48] <fantasai> ACTION: fantasai ask css3.info audience what they'd expect border-radius: 50% to mean
# [23:48] * trackbot-ng noticed an ACTION. Trying to create it.
# [23:48] <trackbot-ng> Created ACTION-64 - Ask css3.info audience what they'd expect border-radius: 50% to mean [on Elika Etemad - due 2008-05-19].
# [23:48] <Bert> And www-style?
# [23:49] <fantasai> and www-style
# [23:49] <fantasai> yes
# [23:49] <Bert> Can also put it on the blog.
# [23:49] <fantasai> height is usually the same on inline elements
# [23:49] <Bert> Hmm, good point.
# [23:49] <fantasai> I'll double-post on our blog and css3.info's
# [23:49] <fantasai> and point people reading ours to comment on theirs
# [23:50] <fantasai> because we can't do comments on ours
# [23:51] <Bert> Although roudned corners on an inline element would be easy enough to specify in em. The height is rarely different from 1em.
# [23:51] <fantasai> or is related to it, yeah
# [23:51] <fantasai> but then! we're going to have flexbox
# [23:51] <fantasai> and template layout
# [23:51] <fantasai> and tables
# [23:51] <fantasai> and all kinds of fun stuff
# [23:51] <fantasai> so
# [23:51] <fantasai> not really :)
# [23:53] <Bert> Two inline blocks in a row are less likely to have the same height and thus, I think, less likely to have their corners specified as a percentage of the height.
# [23:54] <Bert> On the principle that two thing next to each other with rounded corners should normally have exactly the same corners.
# [23:54] <Bert> (Maybe unless they are circles.)
# [23:54] <fantasai> heh
# [23:56] <fantasai> Did we want to consider renaming background-origin to background-box?
# [23:56] <fantasai> ties in nicely with the keywords, actually
# [23:56] <Bert> Indeed. I hadn't noticed that yet.
# [23:57] <fantasai> accept? reject? defer?
# [23:57] <Bert> That changes my opinion from neutral to slightly in favour :-)
# [23:57] <fantasai> yeah, mine too :)
# [23:57] * fantasai just noticed this
# [23:59] <Bert> I think we can accept it tentatively, but let's make sure we get feedback on it from the people who commented on the name before.
# [23:59] <fantasai> I don't think there were that many -- most comments were on background-size, because that's what I asked
# [23:59] <fantasai> Eric Meyer commented on background-origin
# Session Close: Tue May 13 00:00:00 2008

The end :)