/irc-logs / w3c / #css / 2012-03-27 / end

Options:

# Session Start: Tue Mar 27 00:00:01 2012
# Session Ident: #css
# [00:21] * sylvaing is now known as sylvaing_away
# [00:26] * Joins: jet (jet@12.197.88.252)
# [00:36] * sylvaing_away is now known as sylvaing
# [00:43] * Quits: leaverou (leaverou@67.180.84.179) (Quit: ttyl laters everyone!)
# [00:59] * sylvaing is now known as sylvaing_away
# [01:08] * Joins: dbaron (dbaron@12.197.88.252)
# [01:41] * Quits: jdaggett (jdaggett@12.197.88.252) (Quit: jdaggett)
# [01:45] * Quits: arronei (arronei@131.107.0.95) (Quit: arronei)
# [01:48] * Joins: arronei (arronei@131.107.192.154)
# [02:27] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [02:54] <TabAtkins> plinss: dev.w3.org links are redirecting to w3c-test.org for some reason. I assume this is unintentional.
# [02:54] <TabAtkins> Specifically, if I go to "dev.w3.org/csswg/css3-flexbox" I get taken to http://w3c-test.org/csswg/css3-flexbox/
# [02:55] <plinss> TabAtkins: it's supposed to be a reverse proxy, are you actually getting redirects?
# [02:57] <plinss> (I'm not getting redirects with FF or Safari, FWIW)
# [02:58] <plinss> interestingly enough, if I use curl I do get a redirect… must be something with the Apache config
# [02:58] <TabAtkins> I'm actually getting a redirect in Chrome.
# [02:59] <TabAtkins> Going to dev.w3.org/csswg itself, then clicking the spec links, works.
# [02:59] <TabAtkins> It's just going to the spec directly that redirects.
# [02:59] <TabAtkins> So yeah, probably apache config.
# [03:01] * fantasai noticed that problem, too but didn't figure out how to reproduce
# [03:01] <plinss> weird, I'll look in to it
# [03:09] <plinss> TabAtkins: try http://dev.w3.org/csswg/css3-flexbox/ (with trailing slash)
# [03:11] <plinss> from what I can tell that seems to be the difference if you get a redirect or not
# [03:24] * Quits: jet (jet@12.197.88.252) (Quit: jet)
# [03:28] * Quits: dbaron (dbaron@12.197.88.252) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:42] * Quits: lgombos_ (Laszlo@192.100.104.170) (Ping timeout)
# [04:06] * Joins: lgombos_ (Laszlo@24.147.186.97)
# [04:07] * Quits: lgombos_ (Laszlo@24.147.186.97) (Quit: Leaving)
# [04:44] * Quits: miketaylr|||| (miketaylr@70.112.101.224) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
# [05:57] * Joins: dbaron (dbaron@173.228.85.36)
# [06:04] * Joins: jdaggett (jdaggett@12.197.88.10)
# [06:32] <fantasai> plinss: Sounds like we can fix that by doing the URL rewrite for that on dev.w3.org
# [06:39] * Quits: glenn (gadams@174.29.126.113) (Client exited)
# [06:41] <plinss> fantasai: yeah, all the proxy is done as rewrite rules in htaccess, I just needed to get home where I have the CVS access still set up...
# [06:41] <plinss> wifi at the hospital was dropping too many packets for vpn
# [06:42] * Joins: jdaggett_ (jdaggett@12.197.88.10)
# [06:42] * Quits: jdaggett (jdaggett@12.197.88.10) (Connection reset by peer)
# [06:42] * jdaggett_ is now known as jdaggett
# [06:46] * Joins: glenn (gadams@174.29.126.113)
# [06:50] * Quits: dbaron (dbaron@173.228.85.36) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [06:51] <plinss> TabAtkins, fantasai: I think I have it sorted, try it please and let me know if you find any issues… (ModRewrite is a black art :-)
# [06:55] <Liam> mod_rewrite is the clear and simple elegant bliss of a mountain stream (full of mountain-goat piss)
# [07:19] * Joins: leaverou (leaverou@67.180.84.179)
# [07:27] * Joins: myakura (myakura@110.233.178.43)
# [07:28] * Quits: jdaggett (jdaggett@12.197.88.10) (Quit: jdaggett)
# [07:38] * Quits: myakura (myakura@110.233.178.43) (Client exited)
# [07:39] * Joins: myakura (myakura@110.233.178.43)
# [07:39] * Quits: myakura (myakura@110.233.178.43) (Client exited)
# [07:50] <fantasai> plinss: I tweaked the rules; yours broke the links to default.css
# [07:50] * fantasai hopes everything works now
# [07:55] <plinss> fantasai: http://xkcd.com/208/
# [07:55] <plinss> looks good to me
# [08:43] * Quits: Hixie (ianh@129.241.93.37) (Quit: brb)
# [08:44] * Joins: Hixie (ianh@129.241.93.37)
# [08:50] * Joins: Ms2ger (Ms2ger@91.181.135.207)
# [08:55] * Quits: glenn (gadams@174.29.126.113) (Client exited)
# [09:16] * Quits: logbot (logbot@110.173.227.145) (Ping timeout)
# [09:19] * Joins: logbot (logbot@110.173.227.145)
# [09:33] * Joins: SimonSapin (simon@82.232.219.95)
# [09:55] * Joins: myakura (myakura@110.233.178.43)
# [09:58] * Quits: myakura (myakura@110.233.178.43) (Ping timeout)
# [10:09] * Quits: Ms2ger (Ms2ger@91.181.135.207) (Ping timeout)
# [10:29] * Quits: Bert (bbos@mcclure.w3.org) (Client exited)
# [10:39] * Joins: Bert (bbos@mcclure.w3.org)
# [11:23] * Quits: leaverou (leaverou@67.180.84.179) (Ping timeout)
# [11:24] * Joins: leaverou (leaverou@67.180.84.179)
# [11:41] * Joins: Ms2ger (Ms2ger@157.193.3.59)
# [11:43] * Quits: leaverou (leaverou@67.180.84.179) (Quit: leaverou)
# [11:55] * Quits: Ms2ger (Ms2ger@157.193.3.59) (Ping timeout)
# [12:48] * Joins: florian_ (florianr@212.213.198.101)
# [12:50] * Parts: florian_ (florianr@212.213.198.101)
# [13:01] * Joins: myakura (myakura@110.233.178.43)
# [13:45] * Joins: Ms2ger (Ms2ger@157.193.3.50)
# [14:26] * Quits: Ms2ger (Ms2ger@157.193.3.50) (Ping timeout)
# [15:50] * Joins: Ms2ger (Ms2ger@157.193.1.127)
# [15:52] * Joins: miketaylr (miketaylr@70.112.101.224)
# [16:05] * Joins: ChrisL (ChrisL@128.30.52.169)
# [16:05] * Quits: Ms2ger (Ms2ger@157.193.1.127) (Ping timeout)
# [16:10] * Joins: glenn (gadams@174.29.126.113)
# [16:15] * Joins: ksweeney (ksweeney@63.119.10.10)
# [16:49] * Joins: Ms2ger (Ms2ger@157.193.9.154)
# [17:15] * Quits: Ms2ger (Ms2ger@157.193.9.154) (Ping timeout)
# [17:26] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
# [17:48] <fantasai> Bert, if you're up for working on css3-background today, I'll be in the office in 30min
# [17:49] <Bert> Yes, lets' do that
# [17:55] * Quits: logbot (logbot@110.173.227.145) (Ping timeout)
# [17:56] * Joins: logbot (logbot@110.173.227.145)
# [17:58] * Quits: logbot (logbot@110.173.227.145) (Client exited)
# [17:59] * Joins: logbot (logbot@110.173.227.145)
# [18:02] * Quits: logbot (logbot@110.173.227.145) (Client exited)
# [18:03] * Joins: jet (jet@166.250.35.35)
# [18:03] * Joins: logbot (logbot@110.173.227.145)
# [18:03] * Quits: logbot (logbot@110.173.227.145) (Client exited)
# [18:08] * Joins: dbaron (dbaron@166.250.35.35)
# [18:08] * Joins: logbot (logbot@110.173.227.145)
# [18:16] * Quits: jet (jet@166.250.35.35) (Ping timeout)
# [18:17] * Quits: dbaron (dbaron@166.250.35.35) (Ping timeout)
# [18:23] * Joins: dbaron (dbaron@166.250.32.179)
# [18:27] <fantasai> Bert: ok, I'm here :)
# [18:27] * fantasai even had breakfast!
# [18:27] <Bert> Good. :-) This should be quick. No difficult issues, I think.
# [18:28] <fantasai> cool
# [18:28] <fantasai> Thanks for putting together the DoC, btw
# [18:28] <fantasai> :)
# [18:28] <Bert> I just finished what you started.
# [18:28] * fantasai doesn't remember starting one...
# [18:28] <fantasai> ^^
# [18:30] <fantasai> http://dev.w3.org/csswg/css3-background/issues-lc-2012
# [18:30] <fantasai> Bert: ok, for issue 2
# [18:31] <fantasai> I changed it to "two keywords, one per dimension"
# [18:31] * fantasai did that awhile ago, now trying to find email...
# [18:32] <Bert> That sounds correct.
# [18:32] <fantasai> looks like I forgot to respond. I'll do that now
# [18:37] * Quits: dbaron (dbaron@166.250.32.179) (Ping timeout)
# [18:39] * Quits: glenn (gadams@174.29.126.113) (Client exited)
# [18:40] <fantasai> Bert: k, sent
# [18:40] <fantasai> next issue
# [18:40] <Bert> So mark as "accepted" then?
# [18:40] <fantasai> yep
# [18:40] <Bert> Are you editing the file?
# [18:40] <fantasai> no, it was edited awhile ago
# [18:41] <Bert> No, I mean the issues list.
# [18:41] <fantasai> Here's the response
# [18:41] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Mar/0587.html
# [18:41] <fantasai> ah, no
# [18:41] <Bert> OK, editing...
# [18:42] <fantasai> I guess, I'll pull up the spec and apply edits, and you update the DoC? :)
# [18:43] <Bert> yes, let's do it like that.
# [18:43] * fantasai moves to issue 3
# [18:43] <Bert> Issue 3 is minor editorial. Just move the properties around in "Name" line.
# [18:44] <Bert> I'd just accept it.
# [18:44] <fantasai> yep
# [18:44] <Bert> Should still send a response, I guess.
# [18:45] * fantasai will start drafting one then -- this might take awhile since there are many issues in it
# [18:45] <Bert> Yes, 10 or so
# [18:46] <fantasai> ok, committed
# [18:46] <fantasai> next issue?
# [18:46] * Joins: jet (jet@12.197.88.252)
# [18:46] <Bert> Applies to for border radius. Commenter is right, I think.
# [18:47] <fantasai> ok
# [18:47] * fantasai copies in wording
# [18:47] <fantasai> oh, hey, we were totally inconsistent between the shorthand and longhand
# [18:48] <fantasai> next issue?
# [18:48] * fantasai checked in
# [18:49] * Joins: arno (arno@192.150.10.201)
# [18:50] <Bert> Hmm, what do I do when hg push aborts and says it would create new heads?
# [18:50] <fantasai> hg merge
# [18:50] <fantasai> hg ci -m "merge"
# [18:50] <fantasai> hg push
# [18:51] <fantasai> in general, make sure you hg pull right before you commit, and you can avoid this problem
# [18:51] <fantasai> there's a bit of race condition in there, though :)
# [18:51] <fantasai> http://wiki.csswg.org/tools/hg#submitting-your-changeshg-commit-and-hg-push
# [18:51] <Bert> Strange that I have to do a commit when I didn't change anything.
# [18:51] <fantasai> I know
# [18:51] * Joins: dbaron (dbaron@12.197.88.252)
# [18:52] <fantasai> but Mercurial did something
# [18:52] <fantasai> it merged the changes
# [18:52] <fantasai> there just happened to be no conflict, so it did it by itself
# [18:53] <dbaron> boy, dvcs.w3.org is so slow...
# [18:53] <Bert> Issue 5?
# [18:53] <fantasai> yep
# [18:53] * Bert had two time-outs in a row :-(
# [18:53] <fantasai> :(
# [18:54] <fantasai> Bert: Append "Negative values are not allowed" to the 1st para?
# [18:54] <Bert> Yes, that seems the right place.
# [18:54] <fantasai> k
# [18:55] <fantasai> next issue?
# [18:55] * Bert reading... Inner curve...
# [18:56] <Bert> Old text seems about the same as the proposed replacement.
# [18:57] <fantasai> maybe
# [18:57] <fantasai> s/adjacent corner/opposite side/
# [18:57] <fantasai> ?
# [18:57] <fantasai> would help?
# [18:57] <fantasai> Or accept his wording with that same change
# [18:58] <fantasai> how about
# [18:58] <fantasai> Note that this means that if the center of the outer curve is in
# [18:58] <Bert> I don't understand why opposite corner?
# [18:58] <fantasai> opposite side
# [18:58] <fantasai> not corner :)
# [18:58] <fantasai> hang on a sec
# [18:59] <fantasai> Note that this means that if the center of the outer curve is past
# [18:59] <fantasai> the opposite side's padding edge, the inner curve might not be a full
# [18:59] <fantasai> quarter ellipse.
# [18:59] <fantasai> ?
# [18:59] <fantasai> Maybe that's clearer?
# [19:00] * fantasai thinks it is possibly clearer
# [19:01] <Bert> Hmm, maybe then Kenny's is clearer.
# [19:02] <fantasai> So we have three variants here :)
# [19:02] <fantasai> the original
# [19:02] <fantasai> kenny's
# [19:02] <fantasai> and the one I just posted
# [19:02] <Bert> "Opposite" to me sounds like the other side of the box, which has no bearing on this corner.
# [19:02] <fantasai> it /is/ the opposite side of the box
# [19:02] <fantasai> +----+
# [19:02] <fantasai> | |
# [19:03] <fantasai> +----+
# [19:03] <fantasai> if we're talking about the top right corner
# [19:03] <fantasai> then the case is triggered when the center of that corner's outer curve
# [19:03] <fantasai> is to the left of the left padding edge
# [19:03] <fantasai> and/or below the bottom padding edge
# [19:04] <Bert> Don't you mean: "to the right of the right padding edge or above the top padding edge"?
# [19:04] <fantasai> no
# [19:04] * fantasai goes to draw you an example
# [19:06] * fantasai tries to find a browser that supports this example...
# [19:07] * fantasai needs a screenshot of IE :/
# [19:07] <dbaron> $ hg push
# [19:07] <dbaron> pushing to https://dvcs.w3.org/hg/csswg/
# [19:07] <dbaron> (crickets)
# [19:07] <fantasai> Bert: well, here's the example
# [19:07] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22height%3A%2040px%3B%20width%3A%2060px%3B%20border%3A%2040px%20solid%3B%20border-color%3A%20blue%20blue%20orange%20orange%3B%20border-top-right-radius%3A%20120px%22%3E
# [19:09] <dbaron> abort: HTTP Error 500: Internal Server Error
# [19:10] <Bert> I think I understand. The case I was looking at (and I believe Kenny, too) was the figure below the note.
# [19:10] <fantasai> ah
# [19:10] <Bert> That's not "a quarter circle" because it is a sharp corner.
# [19:10] <fantasai> that figure is illustrating the next sentence :)
# [19:10] <fantasai> Maybe we need a figure here, too.
# [19:11] <fantasai> in the note
# [19:11] <fantasai> I guess... mark an action to me to get a screenshot of IE in this case and put it in the note
# [19:12] <fantasai> Now that you understand which case it is, though
# [19:12] <Bert> OK, and in that case kenny's replacement text is not correct, and we need to keep the original or the one you just made.
# [19:12] <fantasai> which wording shoudl we go with?
# [19:13] <Bert> Trying to decide... :-)
# [19:15] <Bert> Your rewrite is better.
# [19:15] * fantasai is leaning towards just changing "adjacent corner" to "opposite side" in the existing wording
# [19:15] <fantasai> ok
# [19:15] * fantasai edits that in
# [19:15] <Bert> Yes, with an image to separate it from the existing image.
# [19:15] <fantasai> heh, ok
# [19:15] * fantasai will have to do that one later
# [19:16] * Quits: SimonSapin (simon@82.232.219.95) (Ping timeout)
# [19:16] <fantasai> checked in
# [19:19] <fantasai> next issue...
# [19:19] <fantasai> this one's tough. I don't agree with kenny's edits
# [19:20] <fantasai> Also we have WG approval on this exact text, so we shouldn't just change it
# [19:20] <fantasai> but maybe there's a way to clarify
# [19:22] <Bert> Something like "Proportional _along the curve_"?
# [19:22] <Bert> But then: what curve?
# [19:23] <Bert> The outer curve, I guess.
# [19:23] <Bert> Actually, it seems it already implies that.
# [19:24] <fantasai> so the behaviors we want to allow are
# [19:25] <fantasai> include
# [19:25] * Parts: ksweeney (ksweeney@63.119.10.10)
# [19:26] <fantasai> different interpretations of "proportional" in how it maps from a position on the outer curve
# [19:26] <fantasai> to a linear function
# [19:27] <fantasai> e.g. I could use the distance along the curve
# [19:27] <fantasai> or the angle the point on the curve to the center makes to the horizontal
# [19:27] <fantasai> or the angle of the tangent to that point on the curve
# [19:28] <fantasai> or the proportion of the x and y coordinates if the origin were the center of the curve
# [19:28] <fantasai> Does that make sense?
# [19:28] <fantasai> I don't know how better to express that idea
# [19:29] <fantasai> other than in a very rambling sort of way...
# [19:29] <Bert> Yes, that makes sense. But it is a bit long to put in the spec. :-)
# [19:31] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [19:31] <Bert> "Otherwise, the center of the color and style transitions [...] must be a point along the curve that is a continuous function of the ratio of the border widths"?
# [19:32] <Bert> (No proportional, but maybe that doesn't matter much, if we don't specify what fucntion of the position is proportiuonal.)
# [19:33] <fantasai> So
# [19:34] * fantasai splices in the edits to see
# [19:34] <Bert> Or just leave it as is and answer that we left it out on purpose what aspect of the position is proportional, exactly.
# [19:35] <fantasai> "Otherwise, the center of color and style transitions between adjoining borders must a point along the curve that is a continuous monotonic function of the ratio of the border widths. However it is not defined what these transitions look like or what function maps from this ratio to a point on the curve. "
# [19:35] <fantasai> Like that?
# [19:36] <Bert> Yes, even better.
# [19:36] <fantasai> ok :)
# [19:36] <fantasai> I think this qualifies as a better wording of what we already have in the spec
# [19:36] <fantasai> it says the same thing, except clearer afaict
# [19:37] * Joins: jdaggett (jdaggett@12.197.88.252)
# [19:38] * fantasai thinks something's grammatically odd there in the first sentence
# [19:38] <Bert> Which first sentence?
# [19:38] <fantasai> "Otherwise ... widths"
# [19:39] <fantasai> s/must/is/ + s/that is/computed from/?
# [19:39] * Joins: arno (arno@192.150.10.201)
# [19:39] <Bert> Agree with /must/is/, not sure about the 2nd...
# [19:40] <Bert> If you say computed from, it is no longer continuous and monotonic, just based on something that is.
# [19:41] <Bert> I think a point can be a function, that doesn't sound odd in my ears.
# [19:43] <fantasai> ok
# [19:45] <fantasai> committed
# [19:45] <fantasai> next issue :)
# [19:46] <Bert> Issue 8: "corresponding"
# [19:47] <fantasai> so s/sum of the radii/sum of the two corresponding radii/ ?
# [19:48] <Bert> Yes, that's what he suggests. I wonder if just adding "two" is enough.
# [19:48] <Bert> But corresponding two is fine with me.
# [19:48] * fantasai doesn't have an opinion
# [19:49] <Bert> I'd say accept.
# [19:49] <fantasai> k
# [19:51] <fantasai> issue 9?
# [19:52] <Bert> Yes, I'm trying to understand if "The rendering must be exactly the same..." is redundant or not.
# [19:52] <Bert> It seems that way, but why then did we write it?
# [19:52] <fantasai> no idea
# [19:53] * fantasai runs annotate
# [19:55] <fantasai> It was checked in with the comment Clarify that border radius reduction is performed on the used value
# [19:56] <fantasai> along with the changes that inserted the word "used"
# [19:56] <fantasai> I'm ok to remove it
# [19:57] <Bert> Yeah, can't think of any special meaning for it.
# [19:57] <fantasai> k, will remove
# [19:57] <Bert> let's remove it.
# [19:59] <fantasai> k, next issue?
# [19:59] <Bert> Issue 10: I think I made those images, but I don't remember why I made two copies of each box...
# [19:59] <fantasai> I think you did that to make them easier to compare
# [20:00] <Bert> Maybe just to show the effect side by side as well as stacked.
# [20:00] <fantasai> Maybe if we labelled the identical ones identically, that would be less confusing
# [20:00] <fantasai> exactly
# [20:00] <Bert> A A and B B
# [20:00] <Bert> That should be easy.
# [20:01] <Bert> That's an action on me, then.
# [20:01] <fantasai> k, I'll just note that you'll respond to that issue in my reply
# [20:01] <Bert> OK
# [20:03] <fantasai> next issue then
# [20:04] <Bert> Issue 11: I agree, it's not an example about tables
# [20:05] <fantasai> ah, you missed one in the email
# [20:05] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Mar/0258.html
# [20:05] <fantasai> 5.6
# [20:05] <Bert> Ah yes.
# [20:05] <fantasai> agree to move the example, though :)
# [20:06] * fantasai will do that
# [20:07] <fantasai> hmmm, should I insert it right after Figure 6, or somewhere else?
# [20:07] * Quits: dbaron (dbaron@12.197.88.252) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [20:07] * Joins: dbaron (dbaron@12.197.88.252)
# [20:08] <Bert> Just after fig 6 seems right.
# [20:08] <fantasai> k
# [20:08] <fantasai> done
# [20:10] <fantasai> for the collapsed tables issue...
# [20:10] <fantasai> we don't have a term for the middle of the collapsed border, do we?
# [20:10] <fantasai> It should be considered the border edge
# [20:10] <fantasai> otherwise lots of things are not well-defined
# [20:10] <fantasai> like background-clip
# [20:12] <fantasai> I think the correction here should be
# [20:12] <fantasai> s/boundaries/opposite border edges/
# [20:12] <fantasai> and we have a 2.1 clarification issue
# [20:12] * sylvaing_away is now known as sylvaing
# [20:12] <fantasai> sound good to you?
# [20:13] <fantasai> though that sounds a bit awkward now :/
# [20:14] <Bert> yes, on both counts (opposite and css 2.1 issue)
# [20:14] <Bert> Awkward, maybe...
# [20:15] <fantasai> k, here's what I have so far
# [20:15] <fantasai> "In this case not only must the border radii of adjacent
# [20:15] <fantasai> corners not intersect, but the horizontal and vertical radii of a single
# [20:15] <fantasai> corner may not extend past the opposite border edges of the cell at that
# [20:15] <fantasai> corner (i.e. a table corner's border-radius does not affect cells not
# [20:15] <fantasai> at that corner)."
# [20:15] <fantasai> any suggestions for improvement?
# [20:15] <Bert> ... larger than the width, resp., height of the cell...
# [20:15] <fantasai> then we get into content-box border-box issues :)
# [20:16] <Bert> True.
# [20:16] * Quits: myakura (myakura@110.233.178.43) (Client exited)
# [20:16] <fantasai> arg, forgot to file the issues in 2.1 bugzilla
# [20:17] * fantasai will do that later, too sleepy...
# [20:19] <Bert> Easiest to read would be to omit "the boundaries of," but that doesn't make is more precise.
# [20:19] <fantasai> ooh, how about s/opposite/far/?
# [20:20] <Bert> Slightly better, I think.
# [20:20] <fantasai> so we've got"In this case not only must the border radii of adjacent
# [20:20] <fantasai> corners not intersect, but the horizontal and vertical radii of a single
# [20:20] <fantasai> corner must not extend past the far border edges of the cell at that
# [20:20] <fantasai> corner (i.e. a table corner's border-radius does not affect cells not
# [20:20] <fantasai> at that corner). If the computed values of the border radii would cause
# [20:20] <fantasai> this effect, then the used values of all the border radii of the table
# [20:20] <fantasai> must be reduced by the same factor so that the radii neither intersect
# [20:20] <fantasai> nor extend past the border edges of their respective corner cells. "
# [20:21] <fantasai> I'm wondering if separated tables should also have their corners affected
# [20:22] <Bert> OK, it's still something you have to read slowly :-) but at least it now explicitly has "border edge" in it.
# [20:22] <fantasai> heh
# [20:22] <fantasai> k, I'll check it in
# [20:22] * fantasai thinks that we should also get table cells in separated borders model to do something special
# [20:22] <fantasai> it's hard to do manually
# [20:23] <fantasai> but I don't want to do that today...
# [20:23] <Bert> Yes, something similar shoul dprobably hold for separated borders, but with the border edge of the _next_ cell forming the boundary.
# [20:23] <Bert> Agreed.
# [20:24] <fantasai> well, for separated borders tables
# [20:24] <fantasai> the borders of the cells right now aren't affected by the table border-radius at all
# [20:25] <Bert> Not affected or undefined?
# [20:25] <Bert> Hmm, not affected, I guess.
# [20:26] <fantasai> no, you're right, it's undefined
# [20:26] <fantasai> given a generous interpretation of "effect on"
# [20:27] <Bert> :-)
# [20:27] <fantasai> that's fine, we can see if anyone cares enough to do something intelligent :)
# [20:30] <fantasai> Ok, I'm just going to fix 12 and 13
# [20:30] <Bert> So that makes the unnumbered issue (to become issue 26) "Accepted"?
# [20:31] <fantasai> yes
# [20:31] <Bert> OK for 12 and 13
# [20:31] <fantasai> should "see individual properties" apply to all of the fields?
# [20:31] <fantasai> or just some of them?
# [20:32] <Bert> Not sure I understand.
# [20:32] <fantasai> is "Inherited" also "see individual properties"
# [20:33] <fantasai> or stays at "no"?
# [20:33] <Bert> Oh, I see.
# [20:33] <Bert> Hmm, what do we do usually?
# [20:34] <Bert> We usually seem to say yes or no.
# [20:34] <fantasai> ok
# [20:35] <fantasai> fixed, checked in
# [20:36] <fantasai> that's it for that email then :)
# [20:36] <fantasai> on to issue 16?
# [20:36] <fantasai> oh, right 14 and 5 I agree with you :)
# [20:37] <fantasai> s/5/15/
# [20:37] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [20:37] <Bert> OK, I'll take an action to respond.
# [20:37] <fantasai> fwiw, I sketched out a feature that handles 15 in css4-background already
# [20:38] <fantasai> http://dev.w3.org/csswg/css4-background/#border-corner-shape
# [20:39] <Bert> I'm not sure we still need that, now that we have border-image.
# [20:40] <fantasai> I think it'll handle a number of common effects
# [20:40] <fantasai> particularly the bevel option
# [20:40] <fantasai> which can be used for e.g.
# [20:40] <fantasai> breadcrumbls that look liek this
# [20:40] <fantasai> >_Home_>_Sublevel_>_section_>
# [20:40] <fantasai> imagine an overline
# [20:41] <fantasai> or tabs that look like this
# [20:41] <Bert> Tantak's famous polygons :-)
# [20:41] <fantasai> /Tab\ /other\
# [20:41] <fantasai> it also makes it easier to approximate the shape of various border images
# [20:41] <fantasai> which is important for hit targets and for background painting
# [20:42] * fantasai studying grammar for issue 6
# [20:44] * fantasai wants it to be less awkward
# [20:46] <Bert> I don't think it matters much, people are going to omit the final slash by themselves if they find they have no border width to specify. I'm OK with forbidding it.
# [20:47] <fantasai> || <var><'border-image-slice'></var>
# [20:47] <fantasai> [ / <var><'border-image-width'></var> |
# [20:47] <fantasai> / <var><'border-image-width'></var> / <var><'border-image-outset'></var> ]? ]?
# [20:47] <fantasai> ?
# [20:47] <fantasai> or is there something better?
# [20:47] <fantasai> oops, too many closing brackets :)
# [20:48] * fantasai deletes one
# [20:48] <fantasai> I think it was my original intent not to allow trailing slashes :)
# [20:48] <Bert> I think that doesn't allow '/ / <outset>' (i.e., with omitted border width)
# [20:48] <fantasai> so this is an error fix to me
# [20:49] <fantasai> ah, right, there should be a ? in the second line
# [20:49] <Bert> Yes, then I think it's OK
# [20:49] <fantasai> || <var><'border-image-slice'></var>
# [20:49] <fantasai> [ / <var><'border-image-width'></var> |
# [20:49] <fantasai> / <var><'border-image-width'></var>? / <var><'border-image-outset'></var> ]?
# [20:49] <fantasai> ok, will check in
# [20:49] <fantasai> we'll run this one by the WG, but I doubt it's a problem
# [20:50] <fantasai> k, fixed
# [20:51] <fantasai> next issue...
# [20:51] <Bert> Issue 17, background shorthand doesn't reset bg-image before setting it.
# [20:52] <fantasai> bg-image is not required
# [20:52] <fantasai> so I think we do need to reset it
# [20:52] <fantasai> to handle the cases where it's not set
# [20:52] <Bert> How can it not be set?
# [20:52] <fantasai> background: repeat, blue;
# [20:53] <fantasai> is valid
# [20:55] <fantasai> so I think we need to accept this comment
# [20:55] <Bert> OK, that sets bg-image to 'none, none'. Yes, let's add bg-image to the list that is reset.
# [20:56] <Bert> (It's a strange value to set, but valid, indeed...)
# [20:57] <fantasai> k
# [20:57] <fantasai> checked in
# [20:57] <fantasai> agree that the css3-page issue is out-of-scope
# [20:57] * fantasai waits for hg to recognize the checkin
# [20:57] <fantasai> k
# [20:58] <Bert> Skipping issue 18?
# [20:58] <fantasai> oh
# [20:58] <fantasai> Um
# [20:58] <fantasai> I think all of them apply, no?
# [20:58] <Bert> We can do 19 first. I agree it's out of scope.
# [20:58] <fantasai> k, closed out-of-scope :)
# [20:59] <fantasai> So we need a statement somewhere that all properties defined in this module apply to :first-line and :first-letter
# [20:59] <fantasai> question is wher...
# [20:59] <fantasai> where
# [20:59] <Bert> Indeed...
# [21:00] <fantasai> maybe in the Module Interactions section?
# [21:00] <Bert> That's possible, or maybe in three places: under 'background', under 'border', and under 'border-radius'
# [21:01] <Bert> Under "module interactions" is shorter...
# [21:02] * Quits: danielfilho (danielfilh@187.31.77.7) (Ping timeout)
# [21:02] * fantasai doesn't have an opinion
# [21:02] * fantasai looks at 2.1
# [21:03] <fantasai> actually, probably including this as a boilerplate thing in Module Interactions would be a good idea
# [21:03] * Joins: danielfilho (danielfilh@187.31.77.7)
# [21:03] <fantasai> otherwise all our modules will forget
# [21:03] <fantasai> so let's do that
# [21:03] <Bert> Good idea.
# [21:05] * fantasai adds " All properties in this module apply to the ::first-line and
# [21:05] <fantasai> ::first-letter pseudo-elements."
# [21:06] * fantasai also adds this to the module template
# [21:07] <Bert> 'Box-decoaration-break' may apply, but never has any effect, does it?
# [21:07] <fantasai> depends if the first-letter breaks across multiple lines
# [21:07] <fantasai> is that possible?
# [21:07] <Bert> Good question.
# [21:07] <Bert> Won't look too nice...
# [21:08] <fantasai> I think we should just leave it as a blanket statement
# [21:08] <Bert> Anyway, saying that it applies won't hurt.
# [21:09] <fantasai> if :first-letter never splits, then it never is an issue :)
# [21:09] <fantasai> exactly
# [21:09] <fantasai> k, checking in
# [21:09] <fantasai> next issue?
# [21:10] <fantasai> ah, this one
# [21:10] <fantasai> I'm against changing the grammar again
# [21:10] <fantasai> But rewording the sentence ...
# [21:10] * fantasai has an idea
# [21:12] <fantasai> If two values are given, a length or percentage as the first
# [21:12] <fantasai> value represents the horizontal position (or offset) and a length or
# [21:12] <fantasai> percentage as the second value represents the vertical position (or
# [21:12] <fantasai> offset).
# [21:12] <fantasai> How's that?
# [21:13] <Bert> That sounds correct. But is that the part kenny was complaining about?
# [21:13] <fantasai> one of them :)
# [21:14] <Bert> Ah yes, I see.
# [21:14] <Bert> OK then.
# [21:15] <fantasai> Last question on this one then is whether to add that note
# [21:15] <fantasai> or maybe a different note
# [21:15] <fantasai> Maybe
# [21:16] <fantasai> "Note that a pair of keywords can be reordered while a combination of keyword and length or percentage cannot. So 'top left' is valid while 'top 0%' is not.
# [21:18] <Bert> Yes, I like your note.
# [21:19] <fantasai> k
# [21:19] <Bert> (Although 'top 0%' could also be an attempt to say "0% from the top and centered horizontally.")
# [21:19] <fantasai> got a better example? :)
# [21:20] <fantasai> oh, maybe 50% left?
# [21:20] <fantasai> vs center left?
# [21:20] <Bert> Yes, I think that is what I meant. :-)
# [21:21] <fantasai> ah -- an easier way of dealing with the two heads problem is
# [21:21] <fantasai> hg rollback # undo commit
# [21:22] <fantasai> then commit again and push
# [21:22] <fantasai> er
# [21:22] <fantasai> pull, commit, and push
# [21:22] * fantasai usually has the commit comment in the bash history, so this is easy
# [21:22] <fantasai> ok, pushed
# [21:23] <fantasai> can you reply to Kenny on this one?
# [21:23] <Bert> "hg rollback (dangerous) This command should be used with care." :-)
# [21:23] <Bert> OK, I'll reply.
# [21:23] <fantasai> we rejected his grammar changes, but accepted to clarify
# [21:25] <Bert> OK, noted, will sent e-mail later.
# [21:28] <Bert> Looking at issue 21...
# [21:29] <fantasai> to clarify the tables case, I'd say
# [21:30] <fantasai> if a border-image is applied, the used value of the border-color is transparent
# [21:30] <fantasai> that makes it clear it still takes up a width, and makes its intersection with the internal table borders predictable
# [21:31] * fantasai tries to figure out where such an edit would go
# [21:31] <Bert> I don't understand. 'Border-image' doesn't apply to internal table elements, why do we need to say anything about such elements?
# [21:32] <fantasai> we don't, but it applies to the table element
# [21:32] <fantasai> and the internal table elements' borders intersecti with the table element's border
# [21:32] <fantasai> in the case of collapsed borders
# [21:34] <Bert> That's a good issue, but it isn't what Kenny was thinking of, I believe.
# [21:35] <fantasai> yeah, he wants us to add "or border-image doesn't apply" to the list
# [21:35] <fantasai> which is fair, but seems a bit of a tautology
# [21:35] <Bert> Ah, the second half of his message. I hadn't read that far yet.
# [21:35] <fantasai> though the description of the property maybe could be clarified a bit in any case
# [21:36] <fantasai> oh, you filed them as separate issue ss :)
# [21:36] <fantasai> nm
# [21:37] * fantasai just interpolated a new issue in between the two he reported
# [21:39] <fantasai> so, here's a possible suggestion:
# [21:39] <fantasai> If the value is ‘none’ or if the image cannot be displayed (or the property doesn't apply), the border styles will be used; otherwise the used value of the element's border color is set to ''transparent'' and the border image is drawn as described in the sections below.
# [21:41] <TabAtkins> Just jumping in - note that you can't depend on whether the image is displayable until used-value time.
# [21:41] <Bert> H, I don't see
# [21:41] <fantasai> that's what I said, used value
# [21:42] <Bert> what the pb is, so also not why 'transparent' is the solution...
# [21:43] <fantasai> So, Kenny's first issue was about when the property doesn't apply, right?
# [21:43] <fantasai> I added that to the parenthetical
# [21:43] <TabAtkins> Ah, indeed. kk
# [21:43] <fantasai> "If the value is ‘none’ or if the image cannot be displayed (or the property doesn't apply), the border styles will be used"
# [21:43] <Bert> Right. If 'border-image' doesn't apply, you don't want the color to become transparent.
# [21:44] <fantasai> Setting it to transparent rather than saying the border styles 'aren't used'clarifies two things
# [21:44] <fantasai> 1. That "aren't used" means "are invisible", not "treat as border-style: none"
# [21:44] <fantasai> in the second case, we lose the border width, see
# [21:45] <fantasai> 2. Clarifies the interaction of collapsed borders when the border-image applies to a collapsed-borders table.
# [21:45] <fantasai> s/when/with the border image when/
# [21:45] <Bert> 'td {border: thin solid orange; border-image: url(foo) 15}' should be orange, shouldn't it?
# [21:46] <fantasai> yes
# [21:46] <fantasai> because it's a table cell
# [21:46] <Bert> So why do you say transparent?
# [21:46] <fantasai> border-image doesn't apply to a table cell
# [21:46] <fantasai> so we use the border styles as usual
# [21:46] <fantasai> if you do
# [21:46] <fantasai> s/td/table/
# [21:46] <fantasai> then it won't be orange
# [21:46] <fantasai> because border-image applies to tables
# [21:47] <Bert> Yes, but then there is no solid border, so who cares if it is transparent?
# [21:48] <fantasai> the layout code
# [21:48] <fantasai> that needs to know it's there and takes up space
# [21:49] <fantasai> it needs to be clear that applying border-image causes the border-style borders to be transparent, not to disappear
# [21:49] <fantasai> and if it's not transparent, but solid and colored
# [21:50] <fantasai> then you see it through the border-image
# [21:50] * Joins: arno (arno@192.150.10.201)
# [21:50] <fantasai> which you don't want!
# [21:50] <Bert> The border width is used for calculations, but neither the style nor the color have any influence. (Except possibly on collapsed borders, that is Kenny's issue.)
# [21:50] <fantasai> right
# [21:51] <fantasai> the simplest way to say that imo is to just say that they're transparent
# [21:51] <fantasai> then it's clear that they're there
# [21:51] <fantasai> and take up space
# [21:51] <fantasai> and aren't visible
# [21:52] <Bert> The spec says they aren't there ("use instead of"). We need to decide only if 'td {border-style: hidden}' hides the image at the edge of the table. Or am I overlooking something?
# [21:53] <fantasai> The spec says they aren't there, but it isn't clear on what "aren't there" means
# [21:53] <fantasai> We *also* need to say something about the border conflict resolution, but that's a separate issue
# [21:54] <fantasai> My suggestion is
# [21:54] <fantasai> If the value is ‘none’ or if the image cannot be displayed (or the property doesn't apply), the border styles will be used; otherwise the used value of the element's border color is set to ''transparent'' and the border image is drawn as described in the sections below. When applied to a border-collapsed table, all
# [21:54] <fantasai> borders drawn along the table's edge are affected.
# [21:54] <fantasai> which I think solves all issues brought up here
# [21:57] * fantasai wonders if that pasted correctly
# [21:57] <Bert> The sentence is grammatical, so I think it pasted OK, but it doesn't make sense to me :-(
# [21:58] <fantasai> lol
# [21:59] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [22:00] <fantasai> ok, let's go through it piece by piece and see where then hangup is
# [22:00] <fantasai> first piece is
# [22:00] <fantasai> "If the value is ‘none’ or if the image cannot be displayed (or the property
# [22:00] <fantasai> doesn't apply), the border styles will be used"
# [22:00] <fantasai> the change from the current text is just the parenthetica
# [22:00] <fantasai> l
# [22:00] <fantasai> That's okay?
# [22:01] <Bert> The parenthetical part seems redundant/obvious, but not wrong.
# [22:01] * fantasai agrees, but can't figure out how else to address Kenny's comment
# [22:02] <fantasai> or we could reject that comment
# [22:02] <fantasai> ?
# [22:03] <Bert> I was going to reject it, but if you think that paren remark has a chance to satisfy him, let's add it.
# [22:03] <fantasai> I think it will, and I don't feel strongly about it. *shrug*
# [22:04] <fantasai> Second part is
# [22:04] <fantasai> "otherwise the used color of
# [22:04] <fantasai> the element's borders is set to ''transparent'' and the border image is drawn
# [22:04] <fantasai> as described in the sections below"
# [22:06] <fantasai> The purpose of this is to clarify that the borders still take up room, but aren't visible. It also gives an easy way to explain the intersection of an internal table element's border with the table's border image in the case of collapsed borders
# [22:07] <fantasai> s/explain/explain and implement/
# [22:07] <fantasai> it clarifies, for example, that the internal borders are drawn all the way to the inner border edge of the table edge borders
# [22:07] <fantasai> and don't stop at, say, the border image area's inner edge
# [22:08] <fantasai> when the border-image-width doesn't match the border width
# [22:08] <Bert> First on elements other than collapsed-border tables: why should you set something to transparent that isn't drawn in the first place? On tables, all I need to know is that an image border overrides a wider border and a 'hidden' border.
# [22:10] <fantasai> So my issue is that "aren't used" isn't clear
# [22:10] <fantasai> But maybe "aren't drawn" would be clearer
# [22:10] <fantasai> so
# [22:10] <Bert> 'table {border-width 1em; border-image:...} td {border: 2em solid}' collapses to a 1em-wide image.
# [22:10] * Joins: arno (arno@192.150.10.201)
# [22:11] <fantasai> yes
# [22:11] <fantasai> but the layout is as if the 2em solid border were in effect
# [22:11] <fantasai> If the value is ‘none’ or if the image cannot be displayed (or the property
# [22:11] <fantasai> doesn't apply), the border styles will be used; otherwise the element's borders
# [22:11] <fantasai> are not drawn and the border image is drawn as described in the sections below.
# [22:11] <fantasai> When applied to a border-collapsed table, all borders drawn along the table's
# [22:11] <fantasai> edge are affected.
# [22:12] <fantasai> because border-image isn't supposed to affect layout
# [22:12] <Bert> I'm OK with s/to use instead/to draw instead/ but it seems to me to mean the same thing.
# [22:13] <fantasai> I'm fine with the first sentence as-is
# [22:14] <fantasai> my concern is that the case you give, for example, is not well-defined
# [22:15] <Bert> In my example, the border is 1em, even on the TD. That's the collapsed value and that is what the layout should be based on.
# [22:15] <Bert> It's currently not defined, indeed.
# [22:15] <Bert> And that's why I think we should say it in terms of the border conflict resolution.
# [22:15] <fantasai> So the key point here is that the layout can't depend on the loading of the border-image
# [22:16] <fantasai> So if it's 1em, it needs to be 1em regardless of whether the border-image loads
# [22:16] <fantasai> In that case, we need to define that border-image on a table causes the table's borders to unconditionally win
# [22:17] <fantasai> even if the table's borders are 'border: none'
# [22:18] <Bert> Yes, that's what I think Kenny's issue 22 is. Although unlike him I think it *does* affect border conflict resolution.
# [22:21] <Bert> I think I'm starting to see what your 'transparent' was about: you don't want border conflict resolution to change, just draw the image on top of the normal border (for collapsed-border tables only). Is that it?
# [22:21] <fantasai> yeah
# [22:21] <fantasai> although I won't object to the other way
# [22:21] <fantasai> I think it's a little more complicated to define
# [22:22] <Bert> OK, I had assumed that, if a border is not drawn for a normal element that has an image border, then it is also not drawn for a table that has an image border.
# [22:22] <fantasai> well, right
# [22:22] <fantasai> sorry
# [22:22] <fantasai> I was saying, border conflict resolution doesn't change, just draw the image as the border
# [22:22] <fantasai> and don't draw the normal border (pretend its invisible)
# [22:23] <fantasai> i.e. the normal border won't show through a transparent border-image
# [22:23] <fantasai> but otherwise it's the same as you say
# [22:23] <Bert> Except that it isn't _completely_ invisible: if it is wide, if pushes the content inwards...
# [22:24] <fantasai> it is invisible! it's just not disappeared
# [22:24] <fantasai> :P
# [22:24] <fantasai> invisible means you can't see it, not that it's not there
# [22:24] <fantasai> ...
# [22:24] <fantasai> like visibility: hidden
# [22:24] <Bert> Invisible like a black hole is invisible: It can be proven to exist indirectly. :-)
# [22:25] * fantasai is pretty sure that if you knocked into Frodo, you would realize he takes up space despite being invisible
# [22:25] <Bert> :-)
# [22:26] <Bert> OK, it's a model. I think it is a bit strange, though: the border is "sort of" collapsed.
# [22:26] <fantasai> heh
# [22:28] <fantasai> So I guess we have two potential models.
# [22:28] <fantasai> For mine, do you agree that the edits proposed are the right ones?
# [22:29] * fantasai will try to come up with edits for yours, too, and ask www-style to compare
# [22:29] <Bert> For mine: my preferred solution would be to add a rule to the border conflict resolution, a rule 0 before rule 1: Borders with a 'b-image-source' other than 'none' take precednence over all other.
# [22:29] * Bert looking again at fantasai's earlier text...
# [22:31] <fantasai> ok, to summarize, I have the following unconditional edits:
# [22:31] <fantasai> "If the value is ‘none’ or if the image cannot be displayed (or the property
# [22:31] <fantasai> doesn't apply), the border styles will be used; otherwise the element's borders
# [22:31] <fantasai> are not drawn and the border image is drawn as described in the sections below."
# [22:31] <fantasai> And then either
# [22:31] <fantasai> "When applied to a border-collapsed table, none of the borders drawn along the
# [22:31] <fantasai> table's edge are affected."
# [22:31] <fantasai> Or
# [22:31] <fantasai> "When 'border-image' is not ''none'' on a table, its borders take precedence over
# [22:31] <fantasai> all others during <a href="">border conflict resolution</a>."
# [22:31] <Bert> Hmm, no not quite: "all borders drawn along the table's edge" suggests there is more than one, but there is only one, collapsed border, isn't there?
# [22:32] <fantasai> well, there are for edges :)
# [22:32] <fantasai> and then when you draw a collapsed border, it comes out looking like patchwork
# [22:32] <fantasai> if the different rows have different styles not overridden by the table
# [22:32] <fantasai> so it looks like multiple borders to me....
# [22:32] <fantasai> s/for edges/four edges/
# [22:33] <Bert> I see: the borders of the different cells, rather than the borders of a single cell.
# [22:34] <fantasai> er, that edit is wrong actually
# [22:34] * fantasai half inverted the negatives
# [22:34] <fantasai> "When applied to a border-collapsed table, none of the borders drawn along the
# [22:34] <fantasai> table's edge are drawn."
# [22:34] <fantasai> There
# [22:34] <fantasai> :)
# [22:34] <Bert> I was just wondering :-) They *are* affected.
# [22:35] <fantasai> Sounds good?
# [22:36] <fantasai> I can check in the unconditional edits and post the table conflict alternatives to www-style
# [22:36] <Bert> I still prefer the conflict-resolution solution. But in yours, "not drawn" implies not used to calculate the width, or not?
# [22:37] <fantasai> I think drawn sounds like more of a graphical thing than a layout thing
# [22:37] <fantasai> so, I think it's fine
# [22:38] <fantasai> but I can replace with "all of the borders along the table's edge are invisible"
# [22:38] <fantasai> (and we can add a note about Frodo ;)
# [22:38] <Bert> (And the first "drawn" can be omitted: "the borders <del>drawn</del> along the table's edge")
# [22:38] <fantasai> right :)
# [22:38] <fantasai> When applied to a border-collapsed table, none of the borders along the table's edge are drawn.
# [22:38] <fantasai> or
# [22:39] <fantasai> when applied to a border-collapsed table, all of the borders along the
# [22:39] <fantasai> table's edge are invisible.
# [22:39] <Bert> OK, let's do the edit and post the proposal.
# [22:39] <fantasai> which of the last two variants should I post?
# [22:40] <Bert> You don't want to add something like: "but their width still affects the cell width"?
# [22:41] <Bert> I don't know which of the two is better. Seems pretty similar to me.
# [22:42] <fantasai> well, the same is true of other elements, right?
# [22:42] <Bert> (If you can find a good way to add Frodo, yes. :-) )
# [22:46] <Bert> Yes, but" not drawn" or "invisible" still sounds like they lost in the conflict resolution. I'm not sure it is clear that they still have an effect on a cell-by-cell basis.
# [22:47] <fantasai> fair enough
# [22:47] <fantasai> actually, on the topic of the unconditional edits
# [22:47] <fantasai> "otherwise the element's borders
# [22:47] <fantasai> are not drawn and the border image is drawn"
# [22:47] <fantasai> I'm thinking s/not drawn/invisible/ would be clearer, what do you think?
# [22:48] <fantasai> on the topic you just brought up, maybe s/borders along/collapsed borders along/ would clarify it happens after border conflict resolution?
# [22:49] <Bert> Somewhat, but it's still ambiguous, I think.
# [22:49] <fantasai> TabAtkins: Did you copy over the replaced elements definition?
# [22:49] * Bert still thinking about the not drawn/invisible...
# [22:54] <Bert> "Invisible" is easier to read than "not drawn." I see no difference in meaning.
# [22:54] <fantasai> ok, I'll switch it
# [22:54] * fantasai will draft a reply to kenny
# [22:54] <fantasai> next issue!
# [22:56] <dbaron> $ hg push
# [22:56] <dbaron> pushing to https://dvcs.w3.org/hg/csswg/
# [22:56] <dbaron> (more crickets)
# [22:57] <fantasai> that's gonna be a mid-air collision if I ever saw one
# [22:57] * fantasai hits Ctrl+C
# [22:58] <dbaron> ok, finally pushed (after rebasing against 2 new csets)
# [22:58] <Bert> Are distributed version-control systems so brittle, or have just not understood yet how to use them?
# [22:58] <Bert> s/have/have we/
# [22:59] <dbaron> well, two problems:
# [22:59] <dbaron> (1) dvcs.w3.org is ridiculously slow
# [22:59] <dbaron> (2) I'm thinking we should have gone with one repo per spec
# [23:00] <Bert> Ok, issue 23
# [23:03] <Bert> Do we need to be precise as to which elements exactly treat inset as ridge? Or will everybody understand what we mean anyway?
# [23:03] <fantasai> I like the suggestion to copy CSS2.1 and say "in the collapsing borer model"
# [23:03] <dbaron> is that a very destructive sort of insect that causes buildings to collapse?
# [23:04] <fantasai> s/borer/border/
# [23:04] <Bert> :-)
# [23:04] <Bert> No it's an "inset" not an "insect" :-)
# [23:04] <fantasai> lol
# [23:04] <Bert> Yes, copying CSS 2.1 is good.
# [23:08] <fantasai> ok, waiting for hg...
# [23:08] <fantasai> next issue...
# [23:09] <fantasai> looks like that's already fixed
# [23:09] <fantasai> and I agree with no change for 25
# [23:10] <Bert> Issue 24: "may not"
# [23:10] <fantasai> yeah, it was fixed earlier
# [23:11] <Bert> Issue 25 no change, I agree.
# [23:11] <fantasai> ok
# [23:11] <fantasai> that's it, right? :)
# [23:11] <fantasai> I guess we each have an image to make
# [23:11] <fantasai> and then you need to colorize the DoC
# [23:12] <Bert> We should maybe still say that Tab's responses to issue 25 are the official WG responses and ask Lev to agree/disagree.
# [23:12] <fantasai> ok
# [23:12] <fantasai> want to do that?
# [23:13] <Bert> Yes, I can make the HTML. And I indeed have an image to update.
# [23:13] <Bert> But not today. It's 11pm :-)
# [23:13] <fantasai> hehe
# [23:13] <fantasai> yes, not today :)
# [23:13] <fantasai> Thanks for staying up with me!
# [23:22] * sylvaing is now known as sylvaing_away
# [23:32] * fantasai notes that we need more examples in the 'border-image' shorthand section, because the syntax is hard to comprehend
# [23:38] <fantasai> Bert: looks like we introduced a conflict on ::first-line -- the spec says that 'box-shadow' does not apply
# [23:38] <fantasai> Bert: Probably because CSS2.1 doesn't list any border properties, and it's similar to a border property
# [23:39] * sylvaing_away is now known as sylvaing
# [23:46] * Joins: ksweeney (ksweeney@63.119.10.10)
# [23:47] * Parts: ksweeney (ksweeney@63.119.10.10)
# [23:49] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [23:52] * Joins: arno (arno@192.150.10.201)
# [23:56] * fantasai studies these lists
# [23:57] <fantasai> Bert: I think, to be consistent with CSS2.1, all properties that affect layout must not apply, and all properties that don't should
# Session Close: Wed Mar 28 00:00:00 2012

The end :)