/irc-logs / w3c / #css / 2008-08-22 / end

Options:

# Session Start: Fri Aug 22 00:00:00 2008
# Session Ident: #css
# [00:21] * Joins: dbaron (dbaron@131.111.225.1)
# [00:37] * Quits: dbaron (dbaron@131.111.225.1) (Connection timed out)
# [00:38] * Joins: dbaron (dbaron@131.111.225.1)
# [00:42] * Quits: dbaron (dbaron@131.111.225.1) (Ping timeout)
# [00:47] <fantasai> molly: I got a question for you
# [00:47] <fantasai> there's a CSS property that changes the direction of block flow
# [00:47] <fantasai> For horizontal text it takes the value 'tb' (for top-to-bottom flow)
# [00:47] <fantasai> For vertical text it takes the values 'rl' and 'lr'.
# [00:47] <fantasai> Question is, what's a good name for it?
# [00:47] <fantasai> It's currently called 'block-progression'
# [00:48] <fantasai> other suggestions include 'block-direction'
# [00:48] <fantasai> what do you think?
# [01:27] <molly> sorry, I'm back now.
# [01:28] <molly> and for the record I want to be you when I grow up, Elika
# [01:28] <molly> my goodness, you're a powerhouse, woman!
# [01:29] <molly> so the actual normal flow changes within the block?
# [01:29] <fantasai> yeah
# [01:29] <fantasai> it changes direction
# [01:29] <molly> block-flow
# [01:30] <fantasai> sure?
# [01:30] <fantasai> I will bring that up tomorrow :)
# [01:30] <molly> well, I think it's the most clear.
# [01:30] <fantasai> cool
# [01:30] <fantasai> so
# [01:30] <molly> if the whole point is to change the flow of the block
# [01:30] <fantasai> block-flow: tb | lr | rl
# [01:30] <fantasai> ?
# [01:30] <molly> I think that makes sense
# [01:30] <fantasai> ok
# [01:30] <molly> what do you think?
# [01:31] <fantasai> Makes sense to me :)
# [01:31] <molly> hehe
# [01:31] <molly> isn't it the middle of the night there?
# [01:31] <molly> go to bed!
# [01:31] <fantasai> yep
# [01:31] <fantasai> hehehe
# [01:32] * fantasai updates a few more issues and then obeys molly :)
# [01:33] <molly> I wish I could be there with
# [01:33] <fantasai> I wish you could too
# [01:33] <fantasai> we have no web-designers present this meeting ;(
# [01:33] <molly> alas, not this trip, I just couldn't physically do it
# [01:33] <fantasai> I'm sure you'd be bored out of your mind half the time
# [01:33] <molly> Well, I'll stick around online as close to things as possible.
# [01:33] <fantasai> but it's really helpful to be able to ask "what makes sense here from your perspective?"
# [01:34] <fantasai> yay~
# [01:34] <molly> absolutely, and it always makes me feel good to contribute *something* of value
# [01:34] <fantasai> :)
# [01:34] <molly> I am planning to be at TPAC so that'll be good
# [01:34] <fantasai> awesome
# [01:34] <fantasai> another question
# [01:34] <fantasai> relates to font-weights
# [01:34] <fantasai> if you have three nested spans
# [01:34] <molly> okay, I was around for part of that discussion earlier g/a
# [01:34] <fantasai> with the font weights 'bolder', 'bolder', and 'lighter'
# [01:35] <fantasai> but you only have two weights, normal and bold
# [01:35] <fantasai> is the innermost span bold or normal?
# [01:35] <molly> what's the rule look like?
# [01:36] <fantasai> (A related question: if given two nested spans 'bolder' and 'lighter', should the inner span always be the same weight as outside the spans?)
# [01:36] <fantasai> the rule looks like
# [01:36] <fantasai> Am I normal or bold?
# [01:38] <molly> well, I might argue that the only span of relevance is that directly spanning the content, and therefore, in this case, "lighter"
# [01:38] <molly> all of the other spans are empty
# [01:38] <fantasai> oh, well they could have text in them :)
# [01:38] <fantasai> or they could be <div>s
# [01:38] <molly> also, what's the parent? It seems that in part this would be inheritance no?
# [01:38] <fantasai> the behavior would have to be the same
# [01:39] <fantasai> no, there's no inheritance
# [01:39] <fantasai> it's just "bolder" is a relative term
# [01:39] <fantasai> if you have a font with three weights
# [01:39] <fantasai> then the innermost span would be the same weight as the outermost span, bolder than the text outside the spans
# [01:39] <fantasai> but lighter than the text inside the middle span
# [01:40] <fantasai> normal weight bold weight extra-bold weight bold weight
# [01:40] <molly> so it's relative to the immediate parent span?
# [01:40] <fantasai> like that
# [01:40] <fantasai> yep
# [01:40] <molly> urgh
# [01:40] <fantasai> the question is, what happens if you only have two weights
# [01:40] <molly> I say it goes to normal
# [01:40] <molly> in some ways it feels like as the designer
# [01:41] <molly> I'd need a "clue" to say, okay, there's a breakdown in the relation here
# [01:41] <molly> if the author is intending to have a lighter color
# [01:41] <fantasai> right, well
# [01:41] <molly> that should be explicit (I hate hate hate relative values btw)
# [01:41] <molly> for this very reason
# [01:41] <fantasai> it's defined as lighter than the parent
# [01:42] <fantasai> but the designer might be trying to get back to the middle value here
# [01:42] <fantasai> if there were multiple weights (like 3 or 5) that's what happens
# [01:42] <fantasai> I don't know
# [01:42] <molly> it's confusing.
# [01:42] <molly> I don't know either. Definitely a question to ask Jason
# [01:42] <fantasai> we've got both kinds of implementations
# [01:42] <fantasai> k
# [01:42] <molly> that's of course what I figured :)
# [01:42] <fantasai> I think I did ask him
# [01:43] <fantasai> and he said it was a hard question :)
# [01:43] <molly> any relative value questions are hard
# [01:43] <molly> to me, anyway
# [01:43] <molly> relational math? Designers don't think that way, they just don't for the vast majority anyway
# [01:43] <fantasai> heh
# [01:43] <molly> designers say "I want it THIS dark"
# [01:43] <molly> and give it a specific value
# [01:44] <molly> seriously.
# [01:44] <fantasai> we have keywords for that
# [01:44] <fantasai> seriously.
# [01:44] <fantasai> :)
# [01:44] * Joins: alexmog (alexmog@78.25.227.22)
# [01:44] <fantasai> hey alexmog
# [01:44] * fantasai is pretty tired
# [01:44] <fantasai> seriously.
# [01:44] <fantasai> I should go to bed now I think
# [01:44] <molly> I know, which is why the entire bold/bolder situation is a strange one. Most designers are not gonna use relative weights
# [01:44] <molly> seriously.
# [01:44] <molly> LOL
# [01:44] <fantasai> :D
# [01:45] <molly> go to bed, Elika!!!! sweetest of dreams :)
# [01:45] <molly> Hi Alex
# [01:45] <fantasai> 'night molly :)
# [01:45] <molly> 'night fantasai
# [03:18] * Quits: alexmog (alexmog@78.25.227.22) (Ping timeout)
# [04:58] * Parts: molly (mollyholzs@70.171.237.207)
# [08:09] * Joins: dsinger (dsinger@90.52.84.233)
# [08:12] * Joins: alexmog (alexmog@78.25.227.23)
# [08:21] * Quits: dsinger (dsinger@90.52.84.233) (Quit: dsinger)
# [08:46] * Joins: dsinger (dsinger@217.167.116.128)
# [08:55] * Joins: dbaron (dbaron@131.111.225.1)
# [08:57] * Quits: alexmog (alexmog@78.25.227.23) (Ping timeout)
# [09:11] * Quits: dbaron (dbaron@131.111.225.1) (Connection timed out)
# [09:12] * Joins: dbaron (dbaron@131.111.225.1)
# [09:23] * Quits: arronei (arronei@131.107.0.104) (Ping timeout)
# [09:23] * Joins: shepazu (schepers@128.30.52.30)
# [09:28] * Quits: dbaron (dbaron@131.111.225.1) (Connection timed out)
# [09:29] * Joins: arronei (arronei@131.107.0.72)
# [09:29] * Joins: dbaron (dbaron@131.111.225.1)
# [09:46] * Quits: dbaron (dbaron@131.111.225.1) (Connection timed out)
# [09:46] * Joins: dbaron (dbaron@131.111.225.1)
# [09:55] * Quits: dbaron (dbaron@131.111.225.1) (Ping timeout)
# [10:11] * Joins: plinss_ (plinss_uk@213.199.146.138)
# [10:14] * Joins: SaloniR (d5c7809c@128.30.52.43)
# [10:16] <fantasai> Good Morning, everyone!
# [10:16] * Joins: anne (annevk@213.199.146.138)
# [10:17] * Joins: alexmog (alexmog@131.107.0.105)
# [10:18] <alexmog> scribenick: alexmog
# [10:18] * Quits: plinss_ (plinss_uk@213.199.146.138) (Quit: plinss_)
# [10:19] * Joins: r12a (ishida@128.30.52.30)
# [10:20] * Joins: dbaron (dbaron@213.199.146.138)
# [10:20] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
# [10:20] <RRSAgent> logging to http://www.w3.org/2008/08/22-css-irc
# [10:20] <dbaron> RRSAgent, make logs public
# [10:20] <RRSAgent> I have made the request, dbaron
# [10:21] <alexmog> on agenda:
# [10:22] <alexmog> -- styling for implicit video controls (discussing who added it to the agenda and if there is a proposal)
# [10:23] <fantasai> Philippe: There are two kinds of controls for the HTML5 video element. There's the default controls, then you can make controls with JS
# [10:24] <alexmog> elika: is there a proposal?
# [10:24] <alexmog> elika: suggest we skip the topic
# [10:24] * Joins: glazou (daniel@213.199.146.138)
# [10:26] <alexmog> (further discussion on why implicit video controls are on the agenda and if it needs an action item to follow up)
# [10:30] * Joins: plinss_ (peter.lins@15.243.169.72)
# [10:31] <alexmog> discussion: video control buttons need to be styled. Define pseudo elements for it?
# [10:31] <alexmog> bert: if we don't provide style, the only solution is script
# [10:32] <alexmog> daniel: suggest a proposal comes from implementers
# [10:32] <alexmog> peter: if this is something we want to address, we should at least discuss if this something we need to tackle
# [10:33] <alexmog> steve: we don't need to solicit a proposal, it will happen or not happen
# [10:34] <dsinger> I think we should have a discussion of styling of multimedia, including but not limited to controls, 'stylable aspects' (volume, brightness, contrast, perhaps) and control of optional aspects of the content, particularly accessibility
# [10:34] <dsinger> but I agree the discussion should be anchored by proposals...
# [10:34] <dsinger> and that today may not be the best use of time
# [10:35] <alexmog> bert: if we do something we should do it soon or it will fall off the table
# [10:35] <dsinger> the video-on-the-web group seems to be a good place to discuss cross-group aspects such as CSS implications of media elements, right?
# [10:35] <alexmog> david: looking at what mozilla is doing now
# [10:36] <alexmog> david: controls with SVG, not seeing anything with custom controls
# [10:36] <dsinger> (I am in another stds meeting and cannot call in, only IRC when I am not paying attention here!)
# [10:36] <fantasai> anne: We already have problems styling form controls
# [10:36] <alexmog> (it is noted that David Singer is interested in the topic)
# [10:37] <fantasai> anne: The appearance property is way underspecified
# [10:37] <fantasai> anne: people are implementing form controls in JS, makes it unusable for mobile phones
# [10:38] <alexmog> peter: propose action dsinger and bert to contact someone in mozilla and come up with a proposal
# [10:38] <fantasai> Philippe: someone being Chris Double
# [10:39] <dsinger> I'm happy to work with Bert on "CSS aspects of HTML5 media elements", yes
# [10:39] <alexmog> action bert: come up with a proposal for implicit video controls
# [10:39] * trackbot noticed an ACTION. Trying to create it.
# [10:39] * RRSAgent records action 1
# [10:39] <trackbot> Created ACTION-97 - Come up with a proposal for implicit video controls [on Bert Bos - due 2008-08-29].
# [10:40] * Joins: plh (plh@128.30.52.28)
# [10:40] <fantasai> Topic: block flow
# [10:40] <dbaron> And for what it's worth, I think what we're doing with the controls attribute is pretty much what HTML5 says to do.
# [10:40] <alexmog> elika: molly proposed syntax for block-progression
# [10:41] <alexmog> elika: block-flow: tb | rl | lr | bt (bt is optional)
# [10:41] <alexmog> elika: richard, what do you think
# [10:42] <alexmog> richark: reasonable
# [10:42] <alexmog> david: "flow" could be one of multiple things...
# [10:42] <alexmog> richard: when do we want to talka about case A (on the whiteboard - tbrl flow)
# [10:43] <alexmog> richar: should it be called "block-flow-direction" ?
# [10:43] <alexmog> s/richar/richard/
# [10:44] <alexmog> elika: when we talk about vertical, we'll say "in left-to-right block flow"
# [10:44] <fantasai> RESOLVED: Molly's proposal accepted
# [10:44] <alexmog> steve: when this replaces property name, do we still say "block flow direction"?
# [10:44] <alexmog> elika: yes
# [10:47] <alexmog> elika: we have a concept of "normal flow" as opposed to out of flow
# [10:48] <alexmog> elika: ... and inline flow direction...
# [10:48] <alexmog> elika: tblr, tbrl = "horizontal block flow"
# [10:48] <alexmog> elika: lrtb, lrbt = "vertical block flow"
# [10:49] <alexmog> steve: bad idea for general terminology
# [10:49] <alexmog> peter: we should always qualify with "inline" or "block" flow
# [10:50] <alexmog> peter: terminology is fine when talking of block flow, not for general discussion where "vertical" means "vertical text"
# [10:50] <alexmog> steve: same objection
# [10:53] * anne notes http://www.w3.org/QA/2008/08/css-wg-give-me-a-break.html
# [10:54] <alexmog> elika claims it is a bad idea to use "direction" property in CSS. it should be in html "dir" property because content knows more about its direction
# [10:54] <alexmog> alex is surprised and doesn't yet agree with it
# [10:55] <alexmog> richard: I would use "vertical text mode" even if it isn't text
# [10:55] <alexmog> steve: agree, that is the most common usage
# [10:56] <alexmog> richard: do we need "mode"
# [10:57] <alexmog> alex: in a sentence "in vertical text mode table rows are vertical" - is "mode" necessary?
# [10:58] <alexmog> richard: with "mode" it sounds more specific in terminology
# [10:58] <alexmog> elika: works for me
# [10:58] <alexmog> RESOLVED: "vertical text mode", "horizontal text mode"
# [10:59] <fantasai> richard: So for Mongolian you'd say "left to right vertical text mode"
# [10:59] <fantasai> Bert: I've been using adjective terms mostly
# [10:59] <alexmog> mongolian = "vertical text mode with left-to-right block flow direction"
# [11:00] <alexmog> elika: could say "vertical mode containing block"
# [11:01] <alexmog> elika: ok to use shortened form "vertical block"
# [11:02] <alexmog> alex: define once "vertical block" = "block with vertical text flow direction"
# [11:03] * Joins: jdaggett (jdaggett@213.199.146.138)
# [11:03] <alexmog> daniel: list style "tree"
# [11:04] <alexmog> peter: arron wanted to be on call for that
# [11:04] <glazou> next topic is CSS Backgrounds and Border
# [11:04] <fantasai> http://dev.w3.org/csswg/css3-background/
# [11:05] <alexmog> may or may not talk about variables today. it would be good to have apple people for that one.
# [11:06] <alexmog> elika: couple of open issues
# [11:07] <alexmog> -- issue 11: specify which corner offsets are from
# [11:08] <dsinger> (I'm in europe but don't know about variables, I'll ping the other apple folks, but it'll be late in the day if you catch them (for you, that is))
# [11:08] <alexmog> elika: "background-position: bottom 10px right 25%"
# [11:09] <alexmog> david: what happens when keywords and values are rearranged?
# [11:10] <alexmog> peter: "left 15px" means "0px, 15px" - why?
# [11:10] <fantasai> david: the problem with "bottom right 10px 25%" is, does it mean 10px horiz 25% vert or 10px vert 25% horiz? because currently with coordinates the horiz is always first
# [11:10] <alexmog> david: another way to solve same problem is calc()
# [11:12] <alexmog> alex would find it more intuitive to have a separate property that defines alignment direction
# [11:13] <alexmog> davie would rather leave it to calc() at this point
# [11:13] <alexmog> hakon: can we write an example using calc()?
# [11:13] <alexmog> elika: "background-position: 75% calc(100% - 10px)"
# [11:14] <alexmog> hakon: good case for adding calc
# [11:14] <fantasai> background-position: 75% calc(100% - 10px);
# [11:14] <dbaron> I don't see any reason background-position: 75% calc(bottom - 10px) shouldn't work either
# [11:15] <alexmog> hakon: want inside/outside too
# [11:15] <dbaron> calc(0.25 * start + 0.75 * end)
# [11:16] <alexmog> peter: calc is designed to solve odd cases
# [11:16] <alexmog> peter: you can't build something that depends on direction
# [11:18] * plh background-position: gps(N42°21.69348, W071°5.4957);
# [11:18] <alexmog> saloni: "start + 5px" makes sense
# [11:18] <alexmog> peter: you can't substitute "start" with 0 or 100...
# [11:19] <alexmog> elika: I don't think we should allow keywords in calc
# [11:19] <alexmog> hakon: agree
# [11:19] <alexmog> discussion on difference of start/end and left/right
# [11:25] <alexmog> steve: how do we represent start + 5px?
# [11:25] <alexmog> elika: calc(start + 5px)
# [11:27] <fantasai> background-position: 75% calc(100% - 10px);
# [11:27] <fantasai> background-position: bottom 5px left 45px;
# [11:27] <fantasai> background-position: start 5px top 45px;
# [11:27] <fantasai> background-position: calc(start + 5px) top;
# [11:27] <fantasai> background-position: calc(5px + start) top;
# [11:27] <fantasai> background-position: calc(start + end) top;
# [11:27] <fantasai> background-position: calc(start + bottom) top;
# [11:27] <fantasai> You're going to make Molly cry if you make her do this much math. :(
# [11:27] <fantasai> just to put something in the bottom right corner
# [11:27] * Quits: plinss_ (peter.lins@15.243.169.72) (Ping timeout)
# [11:27] <fantasai> (we are looking at examples in http://dev.w3.org/csswg/css3-background/#the-background-position )
# [11:28] <fantasai> Elika is against putting keywords in calc()
# [11:28] <dbaron> calc(25% + 10px) means you position the 25% point in the image at the 25% + 10px point in the container
# [11:28] * alexmog is not excited in parsing calc(100% + 5x) separately to determine anchor point in the image, then again to get the number
# [11:28] <dbaron> The current definition of calc() doesn't allow keywords, so I'm ok with not allowing keywords too.
# [11:28] * Joins: plinss_ (peter.lins@15.243.169.72)
# [11:30] <fantasai> discussion of implementing calc()
# [11:31] <dbaron> background-position: 15px 20% (left top);
# [11:31] <Bert> (calc() is a fancy notation for a triple (p, q, r) where p is the number of percentages, q the number of ems and r the number of px.)
# [11:31] <dbaron> background-position: 15px 20% (start after);
# [11:32] * Joins: SteveZ (d5c7928a@128.30.52.43)
# [11:32] <alexmog> background-position: 0 15px; background-flow: rl-tb;
# [11:33] <fantasai> background-position: [ <length> | <percentage> ]{2} [ keywords ] {2}
# [11:36] <fantasai> Steve attempting to paraphrase Alex: for writing-mode relative positioning, just add one keyword to make it writing-mode relative
# [11:36] <dbaron> background-position: 15px 20% from-top-left;
# [11:36] <fantasai> RESOLVED: No keywords in calc()
# [11:37] <fantasai> for background-position
# [11:37] <dbaron> background-position: 15px 20% from-before-start;
# [11:37] <alexmog> david: I no longer propose calc() as a solution for RTL background
# [11:37] * alexmog is happy to hear that
# [11:37] <fantasai> Richard Ishida draws two images
# [11:38] <fantasai> [ W3C ::: :: : : : ]
# [11:38] <fantasai> [ : : : :: ::: W3C ]
# [11:38] * glazou notes that fantasai is excellent at asciifying graphics :-)
# [11:39] <dbaron> background-position: 15px 20% logical;
# [11:40] <alexmog> it is noted that right-aligned background is possible in CSS2 - "background-position:100%"
# [11:41] <dbaron> ... and then calc(100% - 10px) can handle the right-relative use case
# [11:43] <dbaron> ... to solve vertical, you'd also need background-repeat: repeat-block-progression | repeat-inline-progression
# [11:43] <alexmog> alex: if there is a keyword "logical" it picks one of 4 corners for origin, then tiles normally...
# [11:43] <dbaron> ... and you'd need to make 'logical' on background-position flip the x and y for the vertical case
# [11:44] <dbaron> Elika: ... and you'd also need mirroring / rotating of the image
# [11:46] <Bert> Corners NW, NE, SE and SW?
# [11:47] <alexmog> background-position: 15px 20% tb-lr;
# [11:50] <alexmog> peter: we don't want to use "top-right" combinations will explode ... "start-right", etc.
# [11:52] <alexmog> hakon supports an additional property that defines origin
# [11:54] <alexmog> david: if there are 8 writing modes, do we need all 8 for background position?
# [11:54] <alexmog> alex: yes, if rotate and mirror are included
# [11:55] <dbaron> Elika: background-remap: absolute | reposition | [ mirror || rotate ]
# [11:56] <dbaron> Håkon: can't live with this
# [11:57] <alexmog> steve: whatever we do should work if image is designed for arabic, then mirrored to english version
# [11:59] <alexmog> steve: the real requirement is for semitic pages to have the same capabilities as western pages
# [12:00] <alexmog> backround-position-mode
# [12:00] <alexmog> background-mode
# [12:02] <alexmog> hakon: why not have a background-offset property?
# [12:02] <alexmog> elika proposes dropping the functionality from CSS3 and taking CSS3 to CR?
# [12:04] <fantasai> fantasai: New proposal: drop background positioning from other corners, push that and border-length to CSS4 BB, publish this draft as WD, then LC/CR around Dec/Jan.
# [12:07] <fantasai> Steve: do we have consensus on using a separate property for defining origin corner?
# [12:08] <fantasai> fantasai: No, because whether I agree with having a separate property depends on what it's defining
# [12:08] <fantasai> fantasai: if we're defining which corner the origin is separate from the offsets, then I don't agree
# [12:09] <fantasai> dbaron: I agree with Elika
# [12:11] <fantasai> Peter: So proposal on the table is to use calc() for positioning from bottom right, and moving on with this draft
# [12:13] <fantasai> Alex: I like Elika's original proposal with bottom and left keywords better than calc()
# [12:14] <fantasai> David: I think I agree with what Alex is saying
# [12:14] <fantasai> David: Take the current set of values, those are still valid
# [12:14] <fantasai> David: Then add to that a syntax for four values
# [12:16] <fantasai> Alex: And it's not allowed to mix logical and physical
# [12:16] <fantasai> Alex: can't mix start and top
# [12:16] <fantasai> Peter: My concern is that it makes the background remap unlikely to work later
# [12:17] <fantasai> Alex: I think this is preferable to dropping values from CSS3
# [12:17] <fantasai> Peter: Are you going to implement this in IE8?
# [12:17] <fantasai> Alex: Unlikely
# [12:17] <fantasai> Alex: If we choose to add something from CSS3 BB in IE8, multiple backgrounds would come much sooner than this
# [12:17] * plh notes http://www.w3.org/QA/2008/08/css-wg-give-me-a-break.html
# [12:19] * anne notes http://krijnhoetmer.nl/irc-logs/css/20080822#l-207
# [12:19] * anne ;)
# [12:22] * plh is waking up slowly :)
# [12:23] <alexmog> proposal: elika's original version, with restrictions that remove ambiguity
# [12:23] <alexmog> no start/end/before/after in CSS3
# [12:24] <Bert> (background-position: right 1em 1px bottom 1.4em -1px)
# [12:24] <alexmog> elika shows examples
# [12:24] <fantasai> background-position: left top 10px;
# [12:24] <fantasai> background-position: left 10px top;
# [12:24] <fantasai> background-position: 10px 10px; /* CSS1 */
# [12:24] <fantasai> background-position: top 10px left 10px;
# [12:24] <fantasai> background-position: left 10px 10px; /* INVALID */
# [12:26] <alexmog> hakon: what will dom return here?
# [12:27] <alexmog> elika: 4 values
# [12:27] <fantasai> fallback behavior:
# [12:27] <fantasai> background-position: bottom right;
# [12:27] <fantasai> background-position: bottom 10px right 10px;
# [12:28] <fantasai> background-position: bottom right; /* CSS1/2 clients */
# [12:28] <fantasai> background-position: bottom 10px right 10px; /* CSS3 clients */
# [12:28] <fantasai> Bert: I want to wait for calc
# [12:28] * Quits: plinss_ (peter.lins@15.243.169.72) (Ping timeout)
# [12:29] <fantasai> Daniel: I disagree, I think web authors will not understand calc()
# [12:29] * Joins: plinss_ (peter.lins@15.243.169.69)
# [12:36] <alexmog> resolved: 4-value syntax, two keywords must be present, zero values can be skipped (examples above)
# [12:36] <alexmog> saloni: how about start/end/before/after
# [12:36] <Bert> I don't think we resolved anything, I think we decided it was unresolved.
# [12:38] <alexmog> no consensus at this point on when start/end are introduced
# [12:38] <fantasai> RESOLVED: new background-position syntax in the draft is ok
# [12:38] <SaloniR> I accept the syntax but I want the discussion on start/end to happen soon.
# [12:41] <alexmog> break
# [12:41] <Bert> Not resolved. Objection from me.
# [12:42] <Bert> calc() will happen anyway, so don't add redundant syntax.
# [13:12] <alexmog> more BB
# [13:12] <alexmog> elika: there is a proposal to add 'transparent' keyword to border-image property
# [13:12] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/28
# [13:13] <alexmog> elika: it would complicate the syntax, the image can be made transparent too
# [13:13] <alexmog> david: we can skip it, syntax is complicated enough
# [13:14] <alexmog> peter: it seems a misnomer that border-image includes background, although i see use cases
# [13:14] <alexmog> consensus: no change
# [13:14] <alexmog> RESOLVED: proposal to add "transparent" to border-image is rejected
# [13:15] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/46
# [13:15] <fantasai> Steve: Why not call it background-position-area
# [13:16] <alexmog> issue 46 -- rename background-origin to background-box
# [13:16] <alexmog> elika: thre is background-clip with same values
# [13:16] <alexmog> peter: sounds consistent
# [13:17] <alexmog> elika: there is background-break property (for page boundaries)...
# [13:19] <alexmog> peter: would expect background-clip to take a rect. should it be background-clip-box?
# [13:19] <alexmog> peter: and background-box
# [13:19] <alexmog> david: don't like bacground-box since there is also two; this is origin for positioning
# [13:19] <alexmog> anne: let's keep it stable
# [13:20] <alexmog> (no strong arguments to making the change)
# [13:21] <alexmog> peter: concern about background-clip - will it interfere with adding a rect clip in the future?
# [13:21] <alexmog> elika: will allow rect in background-clip
# [13:21] <alexmog> steve: background-position-box?
# [13:22] * Quits: dsinger (dsinger@217.167.116.128) (Quit: dsinger)
# [13:22] <alexmog> anne prefers to not change; there are implementations already
# [13:22] <fantasai> elika: That's clearer, but my concern is that it breaks the pattern that given properties foo and foo-bar, foo is a shorthand that sets foo-bar
# [13:23] <Bert> ('background-origin: NE content-corner')
# [13:23] <alexmog> david: ok with changin background-origin; background-clip is fine
# [13:23] <anne> ('background-origin' has remained the same since 2002; nobody has suggested something substantially better it seems, otherwise it would've been changed)
# [13:24] <dbaron> s/is fine/is a good name/
# [13:24] <alexmog> RESOLVED: no change to background-origin/background-clip naming
# [13:25] <Bert> (Or combine bg-origin and bg-clip into one property?)
# [13:25] <alexmog> elika: added no-clip to background-clip property. marked at-risk.
# [13:25] <alexmog> david: painful to implement... an odd overflow case
# [13:26] <alexmog> elika: no-clip with a no-repeat image overflows the box to however big the image is
# [13:26] <alexmog> steve: what does it do for scrolling
# [13:26] <alexmog> peter: probably should not trigger overflow
# [13:27] <alexmog> alex: if it looks like overflow it should behave like overflow
# [13:27] <alexmog> elika: shadows currently don't trigger overflow
# [13:27] <alexmog> elika: we currently don't define anywhere what triggers overflow
# [13:28] <alexmog> elika: if your element has srollbar and background is scrolled you are allowed to clip to padding edge
# [13:29] <alexmog> saloni: how does overflow background affects other elements?
# [13:29] <alexmog> elika: same stacking order as normal backgrounds
# [13:30] <alexmog> peter: does it belong to the same property?
# [13:31] <fantasai> border-clip: padding-box no-clip
# [13:32] <Bert> (background-repeat: repeat | no-repeat | repeat-x | repeat-y | no-clip ? Or background-image: url(foo) no-clip ?)
# [13:32] <fantasai> elika notes that no-clip would be marked at-risk
# [13:32] <alexmog> peter: not convinced it is a good idea but if we have to have it I'd prefer a separate keyword
# [13:32] <alexmog> elika: box-shadow property
# [13:33] <alexmog> elika: adding inner shadow -- inset keyword
# [13:33] <alexmog> elika: brad kemper have images for that
# [13:34] <alexmog> david: is the spread feature still in? I know we implement that
# [13:35] <alexmog> elika: want to publish a working draft
# [13:36] <alexmog> david: plan to last call reasonably soon
# [13:36] <alexmog> anne: is border-radius stable?
# [13:36] <alexmog> elika: yes, and we have accepted your proposal
# [13:37] <alexmog> RESOLVED: publish WD
# [13:41] * Joins: myakura (myakura@118.8.102.216)
# [14:43] <fantasai> Bert: Can we publish a new working draft of Template Layout that consists of the first section with Template Layout
# [14:43] <fantasai> Bert: with the second and third parts removed?
# [14:43] * dbaron notes Trains from Cambridge to London: http://www.firstcapitalconnect.co.uk/Main.php?sEvent=HomePage
# [14:43] <fantasai> Bert: Nobody seems interested in the tabbed layout or row-based layout
# [14:44] <fantasai> http://www.w3.org/Style/Group/css3-src/css3-layout/
# [14:45] <fantasai> Bert: old version http://www.w3.org/TR/2007/WD-css3-layout-20070809/
# [14:48] <fantasai> Elika: I had a comment that you should be able to assign min/max widths/heights to rows and columns
# [14:48] <fantasai> Bert: there is syntax there for doing that
# [14:50] <fantasai> Daniel: Are implementors interested in this?
# [14:51] <fantasai> Anne, David: we are more interested in flexbox
# [14:51] <fantasai> Howcome, Bert: This has useful things, especially the ability to reorder content
# [14:51] <fantasai> Saloni: How does this fit with the grid proposal?
# [14:51] <fantasai> Bert: they are complementary, they work together
# [14:52] <fantasai> Bert: With the grid module, you establish a grid, but then you need to use top/left etc to position things
# [14:52] <fantasai> Bert: With this you establish the grid and create slots at the same time
# [14:53] <fantasai> ...
# [14:54] <fantasai> Elika: I think Grid is very useful for snap-to-grid
# [14:54] <fantasai> Elika: I think using positioning with grid is not likely to be as robust
# [14:55] <fantasai> Elika: but being able to snap widths/heights to grid
# [14:55] <fantasai> Bert: or float to grid, or space out N items
# [14:55] <fantasai> would be useful for those
# [14:55] <fantasai> ACTION: Bert update CR Exit criteria to latest wording for CSS3 Template module
# [14:55] * trackbot noticed an ACTION. Trying to create it.
# [14:55] * RRSAgent records action 2
# [14:55] <trackbot> Created ACTION-98 - Update CR Exit criteria to latest wording for CSS3 Template module [on Bert Bos - due 2008-08-29].
# [14:56] <fantasai> Topic: Update on changes made by David Hyatt to CSS3 Variables
# [14:56] <plinss_> Latest version of the text: http://www.w3.org/Style/CSS/Tracker/actions/44
# [14:56] <fantasai> Topic: Revisit Issue 14 in CSS2.1
# [14:58] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Aug/0154.html
# [14:58] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Aug/0164.html
# [15:00] <fantasai> # The bottom margin of an in-flow block-level element is adjoining
# [15:00] <fantasai> # to its last in-flow block-level child's bottom margin when:
# [15:00] <fantasai> # * the element's specified 'height' is 'auto',
# [15:00] <fantasai> # * the element's used height is the same as it would have
# [15:00] <fantasai> # been if the specified values of 'min-height' and 'max-height'
# [15:01] <fantasai> # were their initial values
# [15:01] <fantasai> # * the element has no bottom padding or border.
# [15:06] <fantasai> Alex: Maybe the bullet about 'overflow' not 'visible' should be generalized to block formatting contexts
# [15:08] <dbaron> Elika adds that as issue 70.
# [15:10] <fantasai> RESOLVED: proposal accepted for Issue 14
# [15:10] <fantasai> Change Vertical margins of elements with 'overflow' other than 'visible'
# [15:10] <fantasai> to Vertical margins of block formatting contexts (such as floats and elements with 'overflow' other than 'visible')
# [15:11] <fantasai> for Issue 70
# [15:11] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-70
# [15:14] <fantasai> RESOLVED: proposal accepted for Issue 70
# [15:15] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-46
# [15:15] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Jun/0106.html
# [15:17] <fantasai> David: The issue is that we don't really say how media restrictions work
# [15:17] <fantasai> David: We say that if the @media rule matches, then all the rules inside it apply
# [15:17] <fantasai> David: But we don't say what happens with nesting
# [15:18] <fantasai> David: if you get to a style sheet by multiple links, you don't want to check only the restrictions on the parent link
# [15:18] <fantasai> David: You want to match the media restrictions on all the links
# [15:18] <fantasai> David: Also you want this to work right if you link to the style sheet in multiple places.
# [15:20] <fantasai> Daniel: The last sentence in this proposal doesn't handle media queries
# [15:21] <fantasai> David: This is for 2.1, not CSS3
# [15:25] <fantasai> "The import only takes effect if the target medium matches the media list." <- prepend to last para in 6.3
# [15:26] <fantasai> RESOLVED: Accept dbaron's proposal plus the change above (from plinss). Bert to figure out exact placement etc.
# [15:27] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [15:27] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-49
# [15:27] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Aug/0167.html accepted with s/will more/will be more/
# [15:29] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-62
# [15:29] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Aug/0168.html
# [15:29] * Joins: shepazu (schepers@128.30.52.30)
# [15:30] <fantasai> RESOLVED: Proposal accepted for Issu 62/51
# [15:33] <fantasai> Peter: Melinda raised an issue with the grammar
# [15:34] <fantasai> Peter: rule sets can't contain other blocks
# [15:35] <fantasai> discussion of what 'any' means and whether it is permissive enough
# [15:38] <fantasai> inconclusive
# [15:38] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-32
# [15:39] <fantasai> Daniel: I hit exactly the same problem in my source code editor.
# [15:40] <fantasai> Daniel: @ followed by an unrecognized ident will not be recognized as an at-keyword by the parser
# [15:40] <fantasai> David: You shouldn't use Appendix Gs' grammar for parsing
# [15:41] <fantasai> Daniel: If you follow Appendix G you will not recognize @foo as an at-rule.
# [15:44] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Aug/0165.html
# [15:45] * Joins: jason_cranfordtea (jason_cran@64.236.128.12)
# [15:48] <fantasai> RESOLVED: Proposal by dbaron+fantasai accepted for ISSUE 32
# [15:50] <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-35
# [15:53] <fantasai> Issue described by
# [15:53] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Jan/0432.html
# [15:53] <fantasai> and
# [15:53] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Mar/0026.html
# [15:53] <fantasai> Daniel: I see your point, David, but I think if web authors specify all four offsets they will expect the replaced element to stretch to fit
# [15:55] <dbaron> David: I think this would become the only case where a replaced element with width and height auto would behave differently from a non-replaced element with explicit width and height.
# [15:56] <dbaron> ...and I'm also unsure whether we should be changing the spec at this point because we don't like what it says.
# [15:59] <fantasai> Elika: I think we should make this change for replaced elements without an intrinsic size
# [15:59] <dbaron> David: I don't want to half-make this change. I'd rather either make it or not.
# [15:59] <jason_cranfordtea> yt?
# [15:59] <fantasai> Elika: The results for http://fantasai.inkedblade.net/style/tests/issues/abspos-replaced-intrinsic-unsized -- using 300px by 150px
# [15:59] <fantasai> Elika: really don't make any sense at all
# [16:03] <fantasai> Seem to agree that this change would make sense for authors, other questions remain
# [16:03] <fantasai> Peter: Would this break existing content?
# [16:03] <fantasai> Peter: IIRC WebKit tried to match the spec here and ran into broken content
# [16:07] <fantasai> discussion between Bert and Peter
# [16:10] <fantasai> everyone tries to convince Bert that flexing auto makes more sense than ignoring a specified offset
# [16:14] <fantasai> Bert is not convinced
# [16:15] <fantasai> Straw Poll: Do we make an absolutely-positioned replaced element with intrinsic size stretch/shrink to fit if all four offsets are specified
# [16:15] <fantasai> ?
# [16:16] <fantasai> Discussion about interoperability
# [16:18] <fantasai> Howcome: It's not worth it to fix it. You can fix this today by setting the width. But we already have interoperability on the currently-specified behavior
# [16:18] <fantasai> Alex: If we change this in the spec, would FF3 fix it?
# [16:18] <fantasai> David: Not for 3.0, but perhaps for 3.1
# [16:19] <fantasai> David: Not saying that we'd necessarily have time to change it, but that we'd be willing to
# [16:20] <fantasai> Howcome: I'm not really convinced that this is worth changing from being interoperable to perhaps years of not being interoperable
# [16:20] <fantasai> Howcome: I think we're taking a risk there.
# [16:20] <fantasai> Howcome: I'm a skeptic
# [16:21] <fantasai> David: Abstain
# [16:21] <fantasai> Daniel: In favor
# [16:21] <fantasai> Saloni: Change
# [16:21] <fantasai> Richard: abstain
# [16:21] <fantasai> Steve: abstain
# [16:21] <fantasai> Peter: in favor
# [16:21] <fantasai> Alex: mixed feelings. I see perfect interop here
# [16:21] <fantasai> Alex: We can improve it, but why
# [16:21] <fantasai> Alex: No change
# [16:21] <fantasai> Bert: No change
# [16:22] <fantasai> Elika: no strong opinion, change iframe not image
# [16:22] <fantasai> Anne: seems there are enough other ways to get this effect that we can address this case using other means
# [16:22] <fantasai> Anne: So I would say no change
# [16:22] <arronei> From what I have just read I would say no change
# [16:24] <fantasai> Daniel: No consensus at all.
# [16:24] <fantasai> Daniel: So we'll have to say no change.
# [16:25] <fantasai> Elika: Can we undefine the behavior for iframes?
# [16:30] <plinss_>
# [16:34] <glazou>
# [16:37] * glazou has to leave in 45 minutes from now
# [16:40] <fantasai> Daniel: I want to discuss the charter and also to report on Variables
# [16:40] <fantasai> Topic: Charter
# [16:40] <fantasai> Philippe: I looked into the charter
# [16:40] <fantasai> Philippe: Listent to you for past three days
# [16:40] <fantasai> Philippe: Don't have any significant changes to suggest.
# [16:40] <plh> http://www.w3.org/Style/Group/2008/draft-charter2.html
# [16:41] <fantasai> philippe: I changed the online version of it this afternoon, some minor changes but perhaps they are major for some people
# [16:41] <fantasai> Philippe: We changed success criteria
# [16:42] <fantasai> Philippe: to be relative to each feature instead of each deliverable
# [16:43] <fantasai> Bert: In some cases you might want per-feature, in some cases per-deliverable
# [16:43] <fantasai> Bert: For example with a profile you don't want each feature you want the whole thing
# [16:45] <fantasai> Philippe: My intention was to make it less restrictive.
# [16:45] <fantasai> Philippe: So that you can choose to target the whole deliverable, but in other case you can also target each feature
# [16:46] <fantasai> Philippe: I didn't see any need to call out the W3C RECs for QA Framework, Charmod, Web Architecture
# [16:46] <fantasai> Philippe: We just expect everyone to follow the RECs
# [16:47] <fantasai> Philippe: Removed sentence about minutes being public because that is redundant with the top part of the charter, which says proceedings will be public
# [16:48] <fantasai> Philippe: Removed paragraph saying that we follow Section 3.4 Votes because the previous sentence adds extra restrictions
# [16:50] <fantasai> Philippe: Some concerns about your process.
# [16:50] <fantasai> Philippe: Your Decision Policy requires making decisions only during group meetings
# [16:52] <fantasai> Philippe: And the quorum requirement ...
# [16:52] <dbaron> "When deciding a substantive technical issue" should have "by formal vote" at the end.
# [16:52] <fantasai> Elika: The Decision Policy paragraph seems to impose the 2/3 quorum requirement on allt echnical decisions
# [16:52] <fantasai> Elika: Not just for formal votes.
# [16:52] <fantasai> Elika: And we almost never have 2/3 of Members in attendance
# [16:53] <fantasai> See dbaron's comment in IRC -- we should make that change.
# [16:53] <fantasai> Philippe: Deliverables section
# [16:53] <fantasai> Philippe: I want to be clear that anything not under this section is not under the patent policy
# [16:54] <fantasai> Philippe: Any contributions made to these drafts will not be under the patent policy
# [16:55] <fantasai> Philippe: If you want any working drafts to be in REC track they must be in the Deliverables section.
# [16:56] <fantasai> Steve: The other items are in scope, they're just not expected to be delivered in this charter
# [16:57] <fantasai> This section seems to need clarification about the other items in the module list being on the REC track
# [16:58] <fantasai> Philippe: Just add a pointer back into the Scope section from here to make it clear that those items are in the REC track
# [16:59] <fantasai> Daniel: Steve, when we had these items under the REC track list you objected that it was way too many items under patent disclosure and Adobe lawyers would object
# [17:00] * glazou alexmog: (re: now it is your turn to join facebook :) no I'm not going to join FB again
# [17:01] <fantasai> Steve does not remember this
# [17:02] <fantasai> ...
# [17:02] <fantasai> Daniel: I think if we put everything back under the REC track then W3C will not accept the charter because they want us to prioritize more heavily
# [17:03] <fantasai> Philippe: You need to say that these Deliverables are the items that the WG will deliver, but that the other items in the Scope section are also on the REC track
# [17:03] <fantasai> Daniel: This is the opposite of what Chris Lilley said
# [17:04] <fantasai> Daniel: I suggest you talk with Chris Lilley before we make any changes here
# [17:04] <glazou> s/said/wanted
# [17:04] <fantasai> Philippe: THe IP policy would reject publishing any item not on this deliverable list
# [17:05] <fantasai> Steve: Right, the agreement was that if we wanted to publish something as a WD we would amend the charter to include it
# [17:06] <fantasai> discussion about being on REC track, covered under IP policy etc
# [17:08] <fantasai> Steve: What surprised me is that the patent policy would not apply to the items in scope but not deliverable
# [17:09] <fantasai> Daniel: Any other feedback on wg?
# [17:09] <fantasai> Philippe: The WG seems to be working well. Have a resources problem, that is not uncommon.
# [17:09] <fantasai> Philippe: It would be nice to have CSS2.1 as a REC asap
# [17:09] <fantasai> Daniel: That's the goal
# [17:09] <fantasai> Daniel: Ok, thank you Philippe
# [17:09] <Bert> (I think the easiest change is to change the title from "Rec-track deliverables" to "milestones" to remove the impression that the other drafts are excluded from the Rec-track.)
# [17:09] <fantasai> Topic: CSS Variables
# [17:10] <fantasai> Daniel: Dave and I made some changes from the original spec we released back in April
# [17:10] <fantasai> Daniel: The first change is in the keywords themselves
# [17:10] <fantasai> Daniel: Based on a suggestion it changed @variables into @define
# [17:10] <fantasai> Daniel: In the current nightly builds we can use both of them
# [17:10] <fantasai> Daniel: And we add a media type
# [17:10] <arronei> Is there a link to the updated document?
# [17:11] <plh> Bert, I'm fine with that change, but the charter needs to indicate which deliverables are on the rec track, so you need a statement somewhere that says that all modules are on the rec track.
# [17:11] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Jul/0545.html
# [17:11] <fantasai> Daniel: Note that for the time being it's vendor-prefixed
# [17:11] <fantasai> Daniel: He added two things I thought were incredibly ugly
# [17:11] <fantasai> Daniel: =foo= and $foo
# [17:11] <Bert> Plh, I'm fine with saying that explicitly, but I'm sure it's redundant.
# [17:11] <fantasai> Danie: It really looks like a programming language now?
# [17:12] <fantasai> John: Doesn't that cause problems in templated situations?
# [17:12] <fantasai> Daniel: In a more recent email, Hyatt added the ability for variable to be a block of CSS declarations
# [17:12] <plh> Bert, not in what I've seen unfortunately
# [17:12] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Jul/0571.html
# [17:13] <fantasai> David: Are variables variable or are they constant?
# [17:13] <fantasai> Daniel: The syntax for calling this breaks the forwards-compatible grammar
# [17:13] <fantasai> Daniel: It's something web authors have wanted for years, but it breaks CSS as it is
# [17:13] <fantasai> Daniel: I personally like the feature, I don't like the design
# [17:14] <fantasai> Daniel: If you have comments yourself about this, please jump on thread and make a comment
# [17:14] <fantasai> John: So why is the functional notation a good thing?
# [17:15] <fantasai> Elika: I don't like the functional notation because I don't want nested parentheses e.g. inside calc()
# [17:15] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Jul/0571.html
# [17:16] <fantasai> Steve: What if I created a new property that took the variable substitutions?
# [17:17] <fantasai> Elika: That's a hack. It's not really a property-value combination, it's meant to be replaced by a set of property-value combinations
# [17:17] <fantasai> David: The current CSSOM only supports one value per property per declaration
# [17:18] <fantasai> David: You can't do that and get the cascading order right
# [17:18] <fantasai> David: And change the variables after the fact
# [17:18] <fantasai> Daniel: Then these need to be constants
# [17:18] <fantasai> Steve: Also I could have recursive variable calls
# [17:19] * Quits: glazou (daniel@213.199.146.138) (Quit: glazou)
# [17:19] <fantasai> Anne: was there a lot of positive feedback of them being mutable through the DOM?
# [17:20] <fantasai> Howcome: I don't think that's a very good idea
# [17:20] <anne> (I would like to see pointers fwiw.)
# [17:20] <fantasai> Howcome: A syntactic macro function seems reasonable
# [17:20] <fantasai> Howcome: but manipulating them through the DOM, I don't think so
# [17:20] <fantasai> I still prefer http://lists.w3.org/Archives/Public/www-style/2008Jul/0031.html
# [17:20] <fantasai> personally
# [17:20] <fantasai> for syntax
# [17:22] <fantasai> Several conversations at once
# [17:22] * fantasai doesn't want to format the minutes...
# [17:23] <plh> fantasai, I changed the draft charter to reflect your comment on quorum requirements
# [17:23] <fantasai> Saloni: font-size: calc( var(black) + 1em); ?
# [17:24] <Bert> (These variables do so little and cost so much :-( Why not design a *real* macro language, with parametrized macros, conditional macros and all. It can be much more powerful and at the same time much easier to spec and use...)
# [17:25] <fantasai> fantasai: I don't particularly like their proposal. I'd prefer something like macros
# [17:25] <fantasai> Anne: constants would make things easier for the CSSOM
# [17:26] <fantasai> David: It's not that clear whether their proposal is variables or constants
# [17:27] <fantasai> Steve: macros just save typing, they're not that important to have
# [17:28] <fantasai> Elika: maintenance
# [17:29] <fantasai> Elika: Can we make a counter-proposal?
# [17:31] <dbaron> (unminuted discussion with people talking very fast and simultaneously)
# [17:38] <Bert> (... discussion continues about... scope (from definition forwards only?)... textual replacement or typed/pre-parsed replacement...)
# [18:00] <anne> Test: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A...%3Cstyle%3Ebody%20%7B%20background%3Ared%3B%20test(test)%3B%20background%3Alime%20%7D%3C%2Fstyle%3E
# [18:01] <fantasai> ACTION: fantasai draw up parse-time constants counter-proposal
# [18:01] * trackbot noticed an ACTION. Trying to create it.
# [18:01] * RRSAgent records action 3
# [18:01] <trackbot> Created ACTION-99 - Draw up parse-time constants counter-proposal [on Elika Etemad - due 2008-08-29].
# [18:01] <fantasai> ACTION: peter draw up parse-time constants counter-proposal
# [18:01] * trackbot noticed an ACTION. Trying to create it.
# [18:01] * RRSAgent records action 4
# [18:01] <trackbot> Created ACTION-100 - Draw up parse-time constants counter-proposal [on Peter Linss - due 2008-08-29].
# [18:02] <fantasai> Meeting closed.
# [18:02] * Quits: plinss_ (peter.lins@15.243.169.69) (Quit: plinss_)
# [18:04] * Quits: SaloniR (d5c7809c@128.30.52.43) (Quit: CGI:IRC (EOF))
# [18:05] * Quits: jdaggett (jdaggett@213.199.146.138) (Quit: jdaggett)
# [18:10] * Quits: alexmog (alexmog@131.107.0.105) (Ping timeout)
# [18:20] * Parts: jason_cranfordtea (jason_cran@64.236.128.12)
# [18:24] * Quits: myakura (myakura@118.8.102.216) (Quit: Leaving...)
# [19:00] * Quits: plh (plh@128.30.52.28) (Quit: Ex-Chat)
# [19:20] * Quits: r12a (ishida@128.30.52.30) (Ping timeout)
# [19:22] * Parts: anne (annevk@213.199.146.138)
# [19:22] * Quits: dbaron (dbaron@213.199.146.138) (Ping timeout)
# [19:22] <fantasai> -> dinner
# [19:23] * Quits: SteveZ (d5c7928a@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
# [20:24] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
# [20:34] * Joins: melinda (melinda.gr@67.142.45.126)
# [21:18] * Joins: hyatt (hyatt@98.200.231.139)
# [22:54] * Joins: shepazu (schepers@128.30.52.30)
# [23:00] * Joins: dbaron (dbaron@131.111.225.1)
# [23:02] * Joins: hyatt_ (hyatt@17.116.199.127)
# [23:03] * Quits: hyatt (hyatt@98.200.231.139) (Ping timeout)
# [23:09] * Quits: dbaron (dbaron@131.111.225.1) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [23:26] * Quits: shepazu (schepers@128.30.52.30) (Dead Socket)
# [23:26] * Joins: shepazu (schepers@128.30.52.30)
# Session Close: Sat Aug 23 00:00:00 2008

The end :)