17:06:03 <RRSAgent> RRSAgent has joined #CSS
17:06:03 <RRSAgent> logging to http://www.w3.org/2009/11/03-CSS-irc
17:06:12 <plinss> rrsagent make logs public
17:06:18 <TabAtkins> TabAtkins has joined #css
17:06:30 <plinss> zakim, this will be style
17:06:32 <Zakim> ok, plinss; I see Styl_CSS-FP(TPAC)12:00PM scheduled to start 6 minutes ago
17:07:24 <fantasai> Topic: Run-ins
17:07:33 <dbaron> Zakim, what is the number?
17:07:33 <Zakim> I don't understand your question, dbaron.
17:07:36 <dbaron> Zakim, what is the phone number?
17:07:36 <Zakim> I don't understand your question, dbaron.
17:07:40 <glazou> glazou has joined #css
17:07:41 <dbaron> Zakim, passcode?
17:07:41 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), dbaron
17:08:05 <plinss> zakim, dial salon 9
17:08:05 <Zakim> I don't understand 'dial salon 9', plinss
17:08:06 <fantasai> Zakim, dial Salon_9
17:08:06 <Zakim> ok, fantasai; the call is being made
17:08:32 <dbaron> bz, conference code is above^
17:08:56 <dbaron> Zakim, who is on the phone?
17:08:56 <Zakim> Styl_CSS-FP(TPAC)12:00PM has not yet started, dbaron
17:08:57 <Zakim> On IRC I see glazou, TabAtkins, RRSAgent, Zakim, bz, dethbakin, plinss, jdaggett, bradk, Bert_lap, dbaron, Arron, markusm, sylvaing, smfr, kohei, hamaji, dsinger, MoZ, arronei,
17:08:59 <Zakim> ... Hixie, karl, krijnh, fearphage, fantasai, trackbot, Bert
17:09:31 <Kai> Kai has joined #css
17:10:18 <dbaron> Zakim, who is on the phone?
17:10:18 <Zakim> Styl_CSS-FP(TPAC)12:00PM has not yet started, dbaron
17:10:19 <Zakim> On IRC I see Kai, glazou, TabAtkins, RRSAgent, Zakim, bz, dethbakin, plinss, jdaggett, Bert_lap, dbaron, Arron, markusm, sylvaing, smfr, kohei, hamaji, dsinger, MoZ, arronei,
17:10:21 <Zakim> ... Hixie, karl, krijnh, fearphage, fantasai, trackbot, Bert
17:10:22 <bradk> bradk has joined #css
17:10:22 <dbaron> Zakim, this is Style
17:10:22 <Zakim> ok, dbaron; that matches Styl_CSS-FP(TPAC)12:00PM
17:10:25 <dbaron> Zakim, who is on the phone?
17:10:25 <Zakim> On the phone I see SteveZ, Salon_9, +1.617.487.aaaa
17:10:31 <dbaron> Zakim, aaaa is bzbarsky
17:10:31 <Zakim> +bzbarsky; got it
17:11:08 <annevk> annevk has joined #css
17:11:54 <Lachy> Lachy has joined #css
17:12:14 <tantek> tantek has joined #css
17:12:17 <TabAtkins> Scribenick: TabAtkins 
17:12:19 <dbaron> Zakim, who is noisy?
17:12:21 <Bert> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
17:12:29 <Zakim> dbaron, listening for 10 seconds I heard sound from the following: SteveZ (37%), Salon_9 (20%)
17:12:59 <bz> how do I mute myself?
17:13:03 <bz> via the phone system?
17:13:09 <dbaron> Zakim, mute bzbarsky
17:13:09 <Zakim> bzbarsky should now be muted
17:13:11 <dbaron> Zakim, unmute bzbarsky
17:13:14 <Zakim> bzbarsky should no longer be muted
17:13:14 <TabAtkins> Bert: As a reminder, general idea of runin is a heading followed by a paragraph, and you want to display the header inline, perhaps with styles to make it stand out.
17:13:18 <bz> aha, nice
17:13:24 <bz> zakim, mute bzbarsky
17:13:24 <Zakim> bzbarsky should now be muted
17:13:30 <TabAtkins> Bert: Another application is a dl wheree the dt runs into the dd that follows rather than above it.
17:13:43 <TabAtkins> Bert: First issue: When can this happen?  When can the run-in element become inline in the next element, and when not?
17:13:51 <TabAtkins> Bert: This dpeends on the element itself, and what follows.
17:14:03 <TabAtkins> Bert: There must be a block afterward, for it to run into, and it can't contain blocks.
17:14:10 <bz> mmm
17:14:11 <TabAtkins> Bert: Original definition wasn't precise.
17:14:12 <alexmog> alexmog has joined #css
17:14:16 <dbaron> bz, can't here bert?
17:14:21 <bz> I can't make out any of it
17:14:22 <dbaron> hear
17:14:27 <bz> it's very quiet and pretty noisy
17:14:32 <TabAtkins> Bert: *points to email*
17:14:32 <bz> but only when speaker is talking
17:14:58 <bz> aha
17:15:01 <bz> this is better!
17:15:02 <bz> yes!
17:15:05 <bz> much better
17:15:21 <TabAtkins> Bert: The first link goes to pag holding conditions for element following the runin.
17:15:28 <bz> which page are these links on?
17:15:30 <TabAtkins> Bert: It must have a following sibling.
17:15:37 <TabAtkins> Bert: Ignore anything that's not in flow.
17:15:39 <bz> ah, I see, archives
17:15:40 <bz> ok
17:15:50 <TabAtkins> Bert: Such as floats, display:none elems, etc.
17:16:01 <TabAtkins> Bert: At top of the message, first point is about run-in itself.  Come back to that later.
17:16:11 <TabAtkins> Bert: Point 2!
17:16:27 <TabAtkins> Bert: You need to have an element after the run-in that is either block or list-item, or else the element displays as block.
17:16:41 <TabAtkins> Bert: Also, it clarifies that run-in comes before any pseudoelements of the following sibling, so element order is retained.
17:17:18 <TabAtkins> Bert: There was discussion about whether block+list-item was sufficient.  Frex, would run-in+run-in+block causes the two run-ins to run together, or would the first make the second a block, and then the second doesn't run in.
17:17:48 <TabAtkins> Bert: Frex, an <h2> followed by an <h3>.  Perhaps the content between the two headers is temporarily suppressed.
17:18:00 <fantasai> s/h2/h3/
17:18:15 <fantasai> fantasai: What about <h2> followed by <h3>?
17:18:21 <TabAtkins> Tantek: You can just put several run-ins in a row, right?  And they'll all run in?
17:18:35 <TabAtkins> Bert: No, not by current language.  The first would go block, the second would run-in.
17:18:57 <TabAtkins> Bert: The dt case makes a stronger example.  You may want multiple <dt>s applying to the same <dd> to run together.
17:19:15 <TabAtkins> Bert: But I think the heading case is strong enough that we don't want to make multiple consecutive run-ins go together.
17:19:26 <TabAtkins> Bert: Point 1! Conditions on the run-in, and what children it can contain.
17:19:41 <TabAtkins> Bert: You have to look not only at children, but at all in-flow descendants.
17:20:05 <shepazu> shepazu has joined #css
17:20:07 <TabAtkins> Bert: The definition is in terms of elements that are incompatible with run-in behavior; elements that inhibit run-in.
17:20:21 <TabAtkins> Bert: If one of the children inhibits run-in, the run-in must go block.
17:20:39 <TabAtkins> Bert: Again, ignore out-of-flow children.  But if one of the remaining children is block/list-item/table/run-in, the run-in cannot go inline.
17:21:16 <TabAtkins> Bert: The remaining children must be inline, so recursively descend to look for children with block/list-item/etc.  If there are no in-flow children that inhibit, the element can run-in.
17:21:35 <TabAtkins> Fantasai: You can combine a,b,d and say "all children, including :before and :after".
17:21:40 <TabAtkins> Bert: Yeah, that's already done.
17:21:59 <TabAtkins> Bert: Rewritten definition at bottom of email that has only two clauses.
17:22:14 <TabAtkins> fantasai: Can we say block-level element or display type, so we're not tying things to a specific list?
17:22:31 <TabAtkins> fantasai: The more we can do that, the better we'll be in the future when we introduce new types.
17:22:53 <TabAtkins> tantek: That's mostly good, but it might also causes problems if a future display type specially should interact with run-in.
17:23:01 <TabAtkins> fantasai: More things should prevent run-in than less.
17:23:14 <TabAtkins> plinss: It's far more likely that something new would inhibit run-in than allow it.
17:23:27 <TabAtkins> Bert: I haven't looked into that specifically, to see if the definition of "block-level" would work.
17:23:53 <TabAtkins> fantasai: Yeah, we've just had a lot of problems with inline-blocks, because a lot of specific lists didn't take it into account.
17:24:08 <TabAtkins> tantek: That's a good argument.  inline-block may act like a block *or* inline.
17:24:16 <MikeSmith> MikeSmith has joined #css
17:24:20 <TabAtkins> fantasai: What we need is the ability to say something is a block on the eoutside, or a block on the inside.
17:24:41 <TabAtkins> tantek: Yeah, but we didn't even know that until we made inline-block.  We didn't realize the abstraction was even necessary.
17:25:08 <TabAtkins> fantasai: You have the same problem with tables and table-cells.  Table cells act like a block container, but it's not like a block on the outside.
17:25:28 <TabAtkins> fantasai: I don't want to introduce a new display-type and say "Let's go audit CSS2.1 and fix all the places."
17:25:48 <TabAtkins> fantasai: But I think for the new display types, our abstractions are good enough to talk about.
17:26:04 <Lachy> Lachy has joined #css
17:26:06 <TabAtkins> plinss: If we have a new list, we're *guaranteed* to update it.  An abstraction *may* need to be updated.
17:26:17 <TabAtkins> tantek: I'd rather have things fail obviously than subtly.
17:26:32 <TabAtkins> fantasai: It's never obvious.  People look at the list of things that are allowed, and just assume that it's still correct.
17:26:55 <TabAtkins> dbaron: We do have the terms "inline-level" and "block-level" elements, which can work as the excluded/included lists.
17:27:21 <bz> That was updated
17:27:23 <TabAtkins> dbaron: I've noticed the list of Bert's seems to be wrong.  A run-in containing a run-in is inhibited.
17:27:26 <TabAtkins> Bert: That's what is says.
17:27:30 <TabAtkins> dbaron: Sorry, yeah.
17:27:32 <bz> http://lists.w3.org/Archives/Public/www-style/2009Sep/0013.html has the right text
17:27:35 <fantasai> Peter: If we had an include list and an exclude list, then people would notice "oh, it's missing". But if we have an include list and "everythingg else" is excluded, nobody notices that something's wrong.
17:27:39 <TabAtkins> tantek: How many implementors have some kind of run-in.
17:27:53 <TabAtkins> smfr: Webkit has basic run-in behavior, but sort of broken.
17:28:05 <TabAtkins> dbaron: I think everyone but Moz implements, but they all do it differently.
17:28:21 <TabAtkins> tantek: And presumably the test-cases that demonstrate lack of interop is published?
17:28:29 <TabAtkins> TabAtkins: Yeah, I think Boris published those.
17:28:36 <TabAtkins> tantek: It would be good to get a pointer for that.
17:28:39 <Bert> -> http://www.w3.org/Style/Group/css2-src/visuren.html#block-boxes Definition of "block-level elements" (9.2.1)
17:28:52 <Zakim> -SteveZ
17:28:53 <sylvaing> http://lists.w3.org/Archives/Public/www-style/2009Sep/0018.html
17:29:02 <mjs> mjs has joined #css
17:29:04 <TabAtkins> dbaron: I think Boris is waiting to publish the test-cases until he's sure that they're right.
17:29:14 <TabAtkins> tantek: It's useful to have real examples, not just specified abstractly.
17:29:23 <sylvaing> correction; a testcase from bz: http://lists.w3.org/Archives/Public/www-style/2009Sep/0017.html
17:29:25 <TabAtkins> tantek: It may turn out that once we see a real exampl of the prose text, it's not what we wanted.
17:29:50 <TabAtkins> Bert: I don't have a preference for a list or a "block-level" definition.
17:30:03 <TabAtkins> Bert: There's some subtlety in that it would refer to run-ins and say "some of the time".
17:30:35 <TabAtkins> Bert: Verdict on the definition?
17:31:55 <TabAtkins> fantasai: I think I'd prefer it to say "block-level elements", but I don't need to block this on this.  We can raise a separate issue for it.
17:32:09 <TabAtkins> Bert: So that sounds like proposal #1?
17:32:15 <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Aug/0607.html
17:32:19 <fantasai> accept text at bottom
17:32:25 <bz> http://lists.w3.org/Archives/Public/www-style/2009Aug/0594.html
17:32:28 <TabAtkins> RESOLVED accept text at bottom.
17:32:37 <TabAtkins> Bert: Next issue.  Should still be easy.
17:32:42 <TabAtkins> Bert: What do to with replaced elements?
17:32:50 <bz> I assume we decided that behavior is ok?
17:32:56 <bz> Zakim, unmute bz
17:32:56 <Zakim> bzbarsky should no longer be muted
17:32:58 <TabAtkins> Bert: Maybe a wider issue.  In my implementation replaced elements are always empty.
17:33:02 <TabAtkins> fantasai: No.
17:33:06 <TabAtkins> Bert: I know what I think.
17:33:26 <TabAtkins> fantasai: In the document tree it's not necessarily empty: textarea, object, etc.
17:33:43 <TabAtkins> Bert: That's the issue.  Do you look in the document tree, or just in the things considered for rendering?
17:33:56 <TabAtkins> Bert: In replaced elements, the children are thrown away.
17:34:04 <TabAtkins> fantasai: And form elements may or may not b replaced, depending.
17:34:15 <TabAtkins> Bert: Let's look at the proposal.  There's proposed text to clarify.
17:34:23 <TabAtkins> Bert: Section 3.1
17:34:45 <dbaron> bz, doesn't the table-cell have a block wrapping it in that case?
17:34:52 <TabAtkins> Bert: Do we consider replaced elements as empty so we never look at its children, or do we look at the children of the replaced element?
17:35:03 <bz> dbaron: it doesn't
17:35:06 <TabAtkins> fantasai: Replaced elements are defined as children being outside of the scope.  Per CSS, there aren't any children.
17:35:14 <bz> dbaron: or rather....
17:35:19 <TabAtkins> Bert: So that seems to mean that we don't have to look at them.
17:35:21 <bz> dbaron: the interaction is interesting
17:35:26 <fantasai> s/Per CSS, there aren't any children//
17:35:36 <fantasai> fantasai: Whether or not it has children doesn't matter
17:35:48 <TabAtkins> Boris: I think the behavior is well-defeined for if the runin is into a table cell or not.
17:36:12 <TabAtkins> Boris: It's a little weird because if it has a table child it can't run in, but I think it's all consistent.
17:36:18 <TabAtkins> Boris: It's something to be careful with.
17:36:21 <tantek> sylvaing thanks - http://lists.w3.org/Archives/Public/www-style/2009Sep/0017.html helps but would prefer actual live test cases we can quickly click and run across browsers/machines.
17:36:33 <TabAtkins> dbaron: I would think that if it has any table stuff in it, except inline-table, it should inhibit run-in.
17:36:49 <TabAtkins> Bert: But if you ahve a table-cell inside an inline element, it automatically generates an inline table.
17:37:03 <TabAtkins> tantek: Did we ever define pseudoelems for the generated wrappers for tables?
17:37:05 <TabAtkins> fantasai: No.
17:37:15 <TabAtkins> Boris: Anonymous blocks have to have something to do with what's going on here.
17:37:25 <fantasai> s/fantasai/?/
17:37:44 <TabAtkins> dbaron: I don't think there's an inconsistency between bori's two cases, because it only occurs into inlines and not other things.
17:37:46 <dbaron> bz, I don't think we're inconsistent between those two cases, since the recursion in Bert's proposal only recurs into inlines
17:38:01 <TabAtkins> Boris: The issue raised here was addressed in Bert's proposal, and should both result in the run-in running in.
17:38:02 <Zakim> +SteveZ
17:38:14 <tantek> anonymous table pseudoelements and anonymous table-row pseudoelements - that get auto-generated when an element is set to display:table-cell outside of any kind of table context for example
17:38:50 <TabAtkins> Bert: Back to replaced elements. Proposal is to clarify definition in section 3.1, where it says "out of scope"
17:38:59 <bz> tantek, http://lists.w3.org/Archives/Public/www-style/2009Jul/0030.html has another test
17:39:14 <bz> tantek: but yes, testcases that are clickable (or at least reftest-like) will happen
17:39:21 <TabAtkins> Bert: Definition of replaced elements in 3.1 says that content it out of scope.  I want to clarify that you don't have to look inside a replaced element to determine if it inhibits run-in.
17:39:34 <Lachy> Lachy has joined #css
17:39:35 <TabAtkins> fantasai: I disagree with what Bert hasn't said yet.
17:39:55 <bz> tantek, my current estimate is we need ~100ish tests to test all reasonably
17:39:57 <tantek> bz - thanks much - that will help a lot
17:40:01 <tantek> ouch!
17:40:10 <TabAtkins> Bert: Proposal is that document tree is empty for CSS.
17:40:13 <bz> tantek, dynamic changes make it extra fun.  ;)
17:40:20 <TabAtkins> Bert: you disagree, fantasai?
17:40:38 <bz> tantek, e.g. webkit gets confused if you change textnodes between the run-in and the block from whitespace to not or vice versa
17:40:42 <TabAtkins> fantasai: Yeah, in the document tree the elements isn't considered empty, and for selectors and such you don't *want* it to be empty.
17:40:43 <tantek> bz - even just a few live static tests to start with, even if "exploratory" in nature (i.e. not knowing exactly what *should* occur) would help answer some of the design questions.
17:40:55 <tantek> bz - agreed, things are much more difficult when dynamic.
17:41:04 <TabAtkins> fantasai: We'll be referring back to this later, and you can't screw around with the document tree for future extentions.
17:41:05 <tantek> useful to at least get the static cases figured out first though right?
17:41:08 <glazou> glazou has joined #css
17:41:19 <TabAtkins> Bert: But that's the definition of replaced.  The content that was there no longer appears.
17:41:23 <bz> yeah, no point testing dynamic much till static is defined
17:41:31 <TabAtkins> fantasai: But what about inline SVG?  There's obviously children there.
17:41:39 <TabAtkins> Bert: But it looks empty for CSS.
17:41:49 <bz> tantek, http://lists.w3.org/Archives/Public/www-style/2009Jul/0025.html has an attached testcase
17:42:04 <bz> tantek, with lots of different cases tested
17:42:14 <TabAtkins> fantasai: You're talking about the rendering tree, which is different from the document tre.
17:42:16 <tantek> http://lists.w3.org/Archives/Public/www-style/2009Jul/att-0025/test.html is a good start
17:42:19 <TabAtkins> Bert: There is no rendering tree.
17:42:19 <bz> tantek, sadly, without much description of what _should_ happen
17:42:24 <glazou> "There is no rendering tree" -- Bert 2009-11-03
17:42:31 <TabAtkins> fantasai: If we can reword it so we don't say the element is empty, I may be happy with it.
17:42:31 <tantek> bz - presumably red means wrong?
17:42:47 <TabAtkins> Bert: We may avoid 'empty', but need to say that the contents of a replaced leement is ignored for CSS.
17:42:53 <bz> tantek, sorry, no.  color is just used to tell apart the various blocks
17:42:53 <TabAtkins> Fantasai: Sure, just don't call it empty.
17:43:00 <bz> tantek, I should have used purple or blue.....
17:43:17 <TabAtkins> tantek: so it's opaque
17:43:26 <bz> tantek, all the right/wrong is in whether things run in or not.  So whether they're on one line or two lines
17:43:45 <bz> tantek, and which is contained in which border
17:44:15 <TabAtkins> fantasai: What about the parent selector?  object:has(a), should we just say this doesn't match?  Selectors should work on the actual DOM.
17:44:23 <bz> I just have nothing to say on this; the behavior we want is obvious; the only question is how to define it.
17:44:46 <fantasai> Let's say I have a <p> element with an <a> inside it
17:44:56 <fantasai> I write a selector for <p>s that have <a>s inside them using Selectors 4
17:45:06 <fantasai> then I say { content: url(image.png); }
17:45:08 <bz> so...
17:45:09 <fantasai> That makes it replaced
17:45:11 <bz> it's even simpler
17:45:13 <fantasai> which makes the selector no longer applyl
17:45:16 <bz> Say I have an HTML <img>
17:45:21 <bz> that I style with :empty
17:45:24 <fantasai> because it's replaced
17:45:27 <fantasai> and now it's empty!!
17:45:34 <tantek> fantasai - no selector feedback loops
17:45:37 <bz> img:empty { border: 10px solid purple; }
17:45:46 <ChrisL> ChrisL has joined #css
17:45:56 <TabAtkins> glazou: But why would this no longer apply?
17:46:19 <TabAtkins> fantasai: Because we say that it's a replaced element now, and thus it would be empty.  No selector can target the contents anymore.
17:47:29 <TabAtkins> dbaron: We should fix this issue in the run-in section, not by changing the definition of a replaced element.
17:48:15 <TabAtkins> TabAtkins: fantasai is saying that run-ins can ignore children of replaced, but we shouldn't just say that the children don't exist.
17:48:34 <TabAtkins> Bert: We don't care about the DOM, we care if CSS says they exist.
17:48:42 <TabAtkins> fantasai: But they do exist.  You can select on them.
17:48:57 <TabAtkins> Chris: Ignoring them and making them disappear are two different things.
17:49:16 <TabAtkins> Bert: I just want to clarify that we're using a definition is internally consistent.
17:49:27 <TabAtkins> Bert: Per CSS, whatever's inside a replaced element simply isn't there.
17:49:37 <dbaron> object:empty only matches some of the time
17:49:42 <TabAtkins> fantasai: Let's just say that you can't do anything with it, not say that it isn't there.
17:50:21 <TabAtkins> dbaron: You're saying the object:empty should match *all* of the time.
17:50:26 <TabAtkins> Bert: Yeah, it should say that.
17:50:36 <TabAtkins> glazou: When doesn't object:empty work?
17:50:47 <TabAtkins> dbaron: When <object> has fallback, frex.
17:51:13 <TabAtkins> glazou: Object has children in the DOM.
17:51:19 <TabAtkins> Bert: If it's replaced it has no children.
17:51:22 <TabAtkins> glazou: It does.
17:51:26 <TabAtkins> Bert: Does not.
17:51:34 <bz> is too, is not
17:51:47 <TabAtkins> Chris: We're going in circles.  Chairs?
17:51:56 <dbaron> dbaron has joined #css
17:52:10 <TabAtkins> tantek: How do you assign different styles to an object based on whether the object loads or not.
17:52:16 <TabAtkins> tantek: This decision is made before CSS happens.
17:52:21 <TabAtkins> tantek: How do you decide?
17:52:52 <TabAtkins> TabAtkins: :incomplete?
17:52:53 <glazou> ChrisL: rofl
17:52:57 <TabAtkins> tantek: That's an old thing, right?
17:53:15 <TabAtkins> fantasai: Nah, it's relatively recent.  But it's out of scope of the conversation.
17:53:24 <TabAtkins> Bert: Let's make it clear that you don't look at the DOM content of replaced elements.
17:53:26 <TabAtkins> fantasai: Yes.
17:53:40 <TabAtkins> Bert: We just need to exclude children from being looked at for this.
17:53:47 <TabAtkins> Bert: So how do we phrase this?
17:54:26 <fantasai> "The children of replaced elements are not considered in the CSS rendering model."
17:54:35 <fantasai> for 3.1
17:55:12 <TabAtkins> Bert: But that sounds like a contradiction.  Replaced elements don't have children.
17:55:20 <TabAtkins> glazou: Nah, everyone agrees that it does.
17:55:54 <TabAtkins> dbaron: So if a <select> is a replaced element, browsers can't render <option>s.
17:56:19 <TabAtkins> fantasai: They're not unrenderable, just CSS won't see them.  Whatever draws forms will.
17:56:32 <TabAtkins> Bert: In CSS1 form elements were defined as replaced, but we've gradually been removing that.
17:56:47 <TabAtkins> tantek: And in CSS3, <select> is appearance:popup-menu.
17:57:06 <tantek>  http://w3.org/TR/css3-ui
17:57:13 <TabAtkins> glazou: Bert, do you have a counterproposal, since you're blocking this sentence?
17:57:41 <TabAtkins> Bert: Can we say that the "content", not "children"?
17:57:43 <TabAtkins> fantasai: Okay.
17:57:47 <Zakim> -SteveZ
17:57:57 <fantasai> "The content of replaced elements is not considered in the CSS rendering model."
17:58:23 <TabAtkins> Bert: That's fine.
17:59:24 <TabAtkins> Chris: So what about <foo-img src=bar><tooltip>baz</tooltip></foo-img>.  Does this mean we can't ever style the tooltip?
17:59:49 <TabAtkins> ChrisL: I think the real answer is we *can* target and style the tooltip.  Maybe it has display:tool-tip or whatever, but it should be there.
18:00:02 <TabAtkins> Bert: How do you display that image?  Does it replace the contents?
18:00:06 <TabAtkins> ChrisL: Ys.
18:00:19 <TabAtkins> Bert: Defined by the document format?
18:00:29 <TabAtkins> ChrisL: Yes.
18:00:33 <annevk> XBL!
18:00:35 <TabAtkins> Bert: Then it has no children.
18:00:47 <TabAtkins> ChrisL: But we may want to do so.
18:00:47 <dbaron> So which case of run-in behavior are we trying to affect, anyway?
18:00:57 <TabAtkins> Bert: Then we'll need to change CSS to do so.
18:01:22 <TabAtkins> Bert: When we use CSS3 Generated Content, we'll be able to do so.
18:01:29 <dbaron> The definition for whether things run in seems fine for replaced elements already.
18:01:36 <TabAtkins> Bert: If th document language says how to display it, we can no longer say anything about it.
18:02:03 <TabAtkins> ChrisL: I was trying to get away from <object>, because the children there are clearly alternates.  I wanted an example where the children are used alongside the content.
18:02:14 <TabAtkins> glazou: What Chris is saying is that this restricts new language design.
18:02:37 <TabAtkins> fantasai: CSS2.1 model: 1) parse document, 2) I'll let fantasai reminute the list.
18:02:46 <fantasai> http://www.w3.org/TR/CSS21/intro.html#processing-model
18:02:55 <dbaron> Instead, I propose changing:
18:02:56 <dbaron> C has a computed value for 'display' of 'inline' and it has one or
18:02:57 <dbaron>       more children that inhibit run-in behavior
18:02:58 <dbaron> to:
18:03:10 <TabAtkins> ChrisL: I'm happy to say "formatting structure" rather than "rendering tree".  It's in *that* that replaced elements have no children.
18:03:12 <dbaron> C has a computed value for 'display' of 'inline', is non-replaced, and has one or
18:03:12 <dbaron>       more children that inhibit run-in behavior
18:03:28 <TabAtkins> ChrisL: The point is that it's not the source tree, so we don't have to *pretend* that the document-tree has no children.
18:03:36 <dbaron> and changing:
18:03:42 <dbaron> If A has any children
18:03:42 <dbaron> to:
18:03:44 <TabAtkins> Bert: Ok.
18:03:47 <dbaron> If A is non-replaced and has any children
18:04:04 <TabAtkins> glazou: We were at 3.  Accept the proposal with Bert's text?
18:04:30 <tantek> tantek has joined #css
18:04:42 <TabAtkins> RESOLVED Accept Bert's text for issue 3 in the run-in email
18:04:53 <Bert> http://lists.w3.org/Archives/Public/www-style/2009Sep/0126.html
18:05:06 <TabAtkins> Bert: Next issue.  What is the containing block of the run-in and children?
18:05:21 <TabAtkins> Bert: Every box needs a containing-block.  If the run-in goes inline, which box is containing it?
18:05:32 <TabAtkins> Bert: 10.1 supposedly defines the containing block for all elements.
18:05:55 <TabAtkins> Bert: In my reading, it does, and the definition there only follows the document tree.  It doesn't look at the visual place it appears, just ancestors in the document tree.
18:06:14 <TabAtkins> Bert: So the run-in will have it's normal parent as the containing block, not the sibling that it's flowing into.
18:06:29 <TabAtkins> Bert: Do we want that, or do we want the sibling to be the containing block?
18:06:33 <TabAtkins> fantasai: The second one.
18:06:35 <Lachy> Lachy has joined #css
18:06:59 <TabAtkins> fantasai: Frex, width:50% on the run-in should be taking its width from the sibling it's flowing into.
18:07:27 <TabAtkins> sylvain: So it would get its color, frex, from its parent, but other things would come from the eparent.
18:07:50 <TabAtkins> fantasai: Yeah, we do something similar with abspos.  The containing block may be an ancestor far up, even though it still inherits from its parent.
18:07:56 <fantasai> s/run-in/run-in's inline-block child/
18:08:03 <TabAtkins> Boris: To be clear, I think we want to say this...
18:08:35 <TabAtkins> Boris: The other question is if you have floating children of the run-in, then what happens with those?  Which block is the containing block for those floats?
18:08:47 <TabAtkins> Boris: And with abspos children of the run-in.
18:09:09 <TabAtkins> fantasai: For floats it should be the same - the containing sibling.
18:09:24 <TabAtkins> fantasai: For abspos children, I have no opinion.  I'm happy to go with whatever's easiest.
18:09:45 <TabAtkins> TabAtkins: For consistency, I'd prefer abspos to do the same thing.
18:10:20 <TabAtkins> Bert: It seems most are in favor of taking the sibling as the containing element for run-in and all children?
18:10:23 <bz> yay!  ;)
18:10:35 <TabAtkins> RESOLVED The sibling that the run-in runs into is the containing block for it and all children.
18:10:49 <TabAtkins> Bert: Next issue.  Boris believes 10.1 is ambiguous.  It says "ancestor box".
18:11:21 <TabAtkins> Bert: In my reading it's just the ancestor.  But Boris thinks it might refer to the formatting structure, and so it may refer to thee ancestor in the formatting structure.
18:11:40 <jdaggett> jdaggett has joined #css
18:11:57 <TabAtkins> Bert: So should we go through the spec and look for "ancestor box", "parent box", etc and replace it with something umabiguous, so we're clear if it refers to the content or the visual structure or containing block.
18:12:25 <TabAtkins> Bert: I don't personally think it's necessary.  I read "ancestor box" as referring to the document structure.
18:12:40 <TabAtkins> Bert: But if others think it's ambiguous, we have to go through the text and replace those occurences.  Thoughts?
18:12:56 <TabAtkins> fantasai, sylvain: I always interpreted that as being formatting structure.
18:13:08 <TabAtkins> plinss: Especially since it says "box", not "element".
18:13:25 <TabAtkins> ChrisL: Yeah, it's ambiguous, especiall frex for abspos.
18:13:30 <tantek> tantek has changed the topic to: display:run-in
18:13:52 <TabAtkins> dbaron: Why is "ancestor" clearly one tree and not the other?
18:14:01 <TabAtkins> dbaron: I think it's clear that it's in the formatting tree.
18:14:13 <TabAtkins> ChrisL: If you have an abspos element, is the ancestor the whole document?
18:14:20 <TabAtkins> Bert: That's the ICB, not an ancestor.
18:14:36 <TabAtkins> plinss: The fact that we're having the conversation means it's ambiguous.
18:14:42 <TabAtkins> Bert: You can say that about any line in the spec.
18:15:05 <TabAtkins> Bert: It's a bit of work to go through the spec.
18:15:20 <TabAtkins> ChrisL: I'm okay with saying it's unambiguous if someone explains it clearly.
18:15:33 <TabAtkins> plinss: If it's supposed to be the box of the ancestor, say "box of the ancestor".
18:15:51 <TabAtkins> fantasai: In run-in, we dont' want to look up the element tree.  We want to look up the formatting tree.
18:16:20 <TabAtkins> fantasai: Frex, with several runs of nested spans around an abspos, is the run-in's containing block (sibling) relpos?  That's a formatting ancestor, not a document ancestor.
18:16:40 <TabAtkins> fantasai: We don't want to make this decision unless we're careful about run-ins?
18:16:58 <TabAtkins> Bert: Are you saying that if we keep it how it is we don't need to make a change?  I think you're going opposite from me.e
18:17:08 <TabAtkins> Bert: I think we'll have to rewrite 10.1 anyway, at least an extra clause.
18:17:40 <TabAtkins> fantasai: I'm saying for children of the run-in, frex when they're looking for fixpos/relpos ancestors, they're going up the formatting tree and will find the run-in's containing block.
18:18:40 <TabAtkins> fantasai: So I guess file this as an issue and deal with it later?  Somebody has to go through and look through the whole spec and figure out what we're doing all over the place.
18:18:51 <TabAtkins> Bert: I think deciding that is progress already.  At least we know it has to be done.
18:19:52 <TabAtkins> RESOLVED File an issue to go through the spec for this.  Either Elika or Bert will take care of this.  At least clarify/define the "ancestor box".
18:20:01 <TabAtkins> Bert: Now the famous ::first-line issue.
18:20:29 <TabAtkins> Bert: Consider a run-in displayed inline in the sibling.  The sibling has a ::first-line pseudo.  Where does the first line get its properties from?
18:20:37 <fantasai> http://wiki.csswg.org/spec/css2.1#issue-142
18:20:53 <TabAtkins> Bert: Imagine the run-in is short, so half of the first line comes from th run-in, and half comes from the content.
18:21:04 <TabAtkins> Bert: There are 3 or 4 reasonable ways of creating that inheritance tree.
18:21:57 <TabAtkins> Bert: Tab's proposal was to avoid the whole issue and just create ::run-in.  Then ::first-line doesn't apply to run-in, just the content from the paragraph.
18:22:20 <TabAtkins> Bert: But we don't have that pseudo in CSS2, so it's quite a change.
18:22:31 <TabAtkins> fantasai: I proposae following the document tree.
18:22:39 <TabAtkins> plinss: I don't know if that makes stylistic sense.
18:23:06 <TabAtkins> plinss: I don't think a run-in should pick up any style from the first line of the paragraph that it's running in.
18:23:32 <TabAtkins> Bert: What about background?
18:23:48 <TabAtkins> fantasai: Run-in should be included in ::first-line, but shouldn't inherit from ::first-line.
18:26:59 <Bert> [Tab explains the issue ::run-in is trying to solve: being able to style the element differently when it run in than when it is block.]
18:27:19 <dsinger> dsinger has joined #css
18:27:51 <Bert> [Tantek says you typically use run-in when you're pretty sure the element *will* run in.]
18:28:09 <fantasai> [tantek and fantasai point out that you can't have a pseudo-element match depending on display type]
18:28:47 <fantasai> s/element/class/
18:29:00 <fantasai> Peter: but you could have a pseudo-element
18:29:11 <fantasai> Peter: that selects its contents
18:30:27 <fantasai> RESOLVED: run-ins inherit from their document tree parent
18:30:50 <fantasai> dbaron: what about the ancestor's ::first-line?
18:31:58 <fantasai> s/ancestor/common ancestor/
18:32:10 <fantasai> dbaron: I don't think we want to ignore the paragraph's ::first-line but honor the ancestor's
18:32:24 <fantasai> fantasai: Yeah, we shoudl either ignore all ::first-lines for run-in inheritance, or honor all of them
18:32:58 <fantasai> bz, can you type in your example pls? :)
18:33:09 <bz> <div style="color: blue">
18:33:20 <bz>   <div style="display: run-in">Text</div>
18:33:28 <bz>   <div style="color: yellow"></div>
18:33:30 <bz> </div>
18:33:55 <fantasai> bz: If there aer no ::first-lien styles, then we've just decided the run-in is color: blue
18:34:20 <fantasai> bz: If there is a ::first-line style on the second <div>, what happens?
18:34:37 <fantasai> bz: If that ::first-line style also sets color: orange, what happens?
18:34:45 <fantasai> (orcolor: yellow; )
18:35:57 <TabAtkins> plinss: I think the run-in should inherit from its parent always.  The remaining content of the sibling on the first-line coms from the sibling's ::first-line, the run-in doesn't care.
18:36:40 <TabAtkins> fantasai: If you have ::first-line{color:green;} on the ancestor, should it affect the run-in?
18:36:42 <TabAtkins> plinss: yes.
18:36:53 <TabAtkins> plinss: You're in effect getting two separate first-line boxes.
18:37:48 <TabAtkins> TabAtkins: Is this actually any more difficult than current ::first-line behavior?
18:38:02 <bz> of course
18:38:07 <TabAtkins> dbaron: I don't think we implement the full ::first-line behavior anyway, so we can't really say.
18:38:09 <bz> first-line + inheritance is just a bad scene, no matter what
18:38:26 <TabAtkins> fantasai: counterproposal is to ignore ::first-line for run-ins always.
18:39:56 <TabAtkins> TabAtkins: So the sibling's ::first-line never affects the run-in.  The difference is whether the ancestor's ::first-line applies to the run-in or not.
18:40:53 <TabAtkins> dbaron: I think it's more consistent to say the run-in always ignores ::first-line.
18:41:57 <Bert> [Fantasai copies bz's mark-up to the flipover and starts drawing...]
18:43:06 <bz> annevk, can we drop first-line too?  ;)
18:44:33 <annevk> I wouldn't mind :)
18:44:52 <TabAtkins> fantasai: Does ::first-line have values for properties that aren't epxlicitly set on it?
18:45:43 <TabAtkins> alex: I've ejust tried this in several browsers.
18:45:59 <alexmog> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0Adiv%3Afirst-line%20%7Bcolor%3Agreen%7D%0D%0Ap%3Afirst-line%20%7Btext-decoration%3Aunderline%7D%0D%0Ab%20%7B%20display%3Arun-in%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cdiv%3E%0D%0A%3Cb%3Erun-in%3C%2Fb%3E%0D%0A%3Cp%3E%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20paragraph%20text%20pa
18:46:06 <TabAtkins> alex: In IE8, the run-in does inherit from parent first-line, but not sibling first-line
18:46:24 <TabAtkins> alex: FF and Opera it doesn't make it a run-in.
18:46:57 <TabAtkins> alex: IN Safari, the ancestor style is ignored, and the run-in gets the sibling's ::first-line.
18:47:09 <TabAtkins> dbaron: Just punt it as undefined and move on?
18:47:43 <TabAtkins> fantasai: 2 things we can leave undefined.
18:48:07 <TabAtkins> fantasai: 1 is inheritance for run-ins in general.  2 is inheritance for run-ins just in ::first-line.
18:49:07 <TabAtkins> RESOLVED Run-ins inherit from their document parent, not their sibling.  It is explicitly undefined what happens with parent/sibling ::first-lines and run-ins.
18:49:11 <bz> mmm yummy undefined
18:49:53 <TabAtkins> RESOLVED ADDENDUM: Undefined for CSS2.1, maybe for CSS3 (Box Module may be able to take care of it.)
18:50:01 <fantasai> :)
18:50:21 <fantasai> yay!
18:50:31 <bz> well, other than the fact that I have to write the code... ;)
18:50:46 <bradk> bradk has joined #css
18:51:27 <tantek> http://wiki.csswg.org/planning/tpac-2009
18:57:33 <ChrisL> bz, yes we are on break now
18:58:06 <markusm> markusm has joined #css
18:58:27 <dbaron> bz, yep
18:58:32 <dbaron> Zakim, who is on the phone?
18:58:32 <Zakim> On the phone I see Salon_9, bzbarsky
18:58:40 <dbaron> Zakim, disconnect Salon_9
18:58:40 <Zakim> Salon_9 is being disconnected
18:58:42 <Zakim> -Salon_9
18:59:05 <bz> time for another meeting in 2 mins, yay
19:02:27 <kohei> kohei has joined #css
19:05:24 <glazou> glazou has joined #css
19:06:13 <mjs> mjs has joined #css
19:10:27 <bradk> bradk has joined #css
19:15:09 <dsinger> dsinger has joined #css
19:16:50 <plinss> plinss has joined #css
19:17:11 <dbaron> Zakim, who is on the phone?
19:17:11 <Zakim> On the phone I see bzbarsky
19:17:19 <dbaron> Zakim, disconnect bzbarsky
19:17:19 <Zakim> bzbarsky is being disconnected
19:17:21 <Zakim> Styl_CSS-FP(TPAC)12:00PM has ended
19:17:22 <Zakim> Attendees were SteveZ, Salon_9, +1.617.487.aaaa, bzbarsky
19:17:37 <dbaron> Zakim, remind us in 7 hours to go home
19:17:37 <Zakim> ok, dbaron
19:17:50 <dbaron> RRSAgent, pointer?
19:17:50 <RRSAgent> See http://www.w3.org/2009/11/03-CSS-irc#T19-17-50
19:18:03 <dbaron> RRSAgent, make logs public
19:18:22 <dbaron> RRSAgent, this meeting spans midnight
19:18:43 <TabAtkins> TabAtkins has joined #css
19:21:35 <Bert> Scribe: Bert
19:21:50 <Bert_lap> Scribe: Bert_lap
19:22:20 <Bert_lap> [Discussion about which issues need discussion]
19:24:10 <tantek> tantek has changed the topic to: selectors
19:24:10 <Bert_lap> Topic: Selectors
19:24:43 <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2009Nov/0022.html
19:24:51 <TabAtkins> Default attribute thread
19:25:02 <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/
19:25:13 <Bert_lap> http://www.w3.org/mid/4AEFE294.8070104@inkedblade.net
19:25:53 <Bert_lap> Fantasai: Default attributes, e.g., colspan is default 1. Can you match against them?
19:26:11 <Bert_lap> ... Spec leaves it open.
19:26:20 <Bert_lap> ... Should we allow both behaviors?
19:26:36 <Bert_lap> ... Most impl. don't match default attrs.
19:26:59 <Bert_lap> Tantek: Impl. shouldn't be required to read DTD, so they don't necessarily know the default.
19:27:10 <Bert_lap> ... That's the background behind the current spec.
19:27:35 <Bert_lap> Glazou: You *can* check if an attribute is absent.
19:28:00 <Bert_lap> DavidB: But need to select all unknowns, can get a long selector...
19:28:14 <Bert_lap> Fantasai: So agreed that spec allows both matching and not matching?
19:28:20 <glazou> glazou has left #css
19:28:31 <glazou> glazou has joined #css
19:28:31 <glazou> glazou has left #css
19:28:36 <Bert_lap> Arron: Are you goin gto send proposed text?
19:28:47 <Bert_lap> Fantasai: Yes, I will.
19:28:59 <glazou> glazou has joined #css
19:29:03 <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20091025/reports/
19:29:11 <Bert_lap> Fantasai: Next is impl. reports. Looks like Opera fails several. Do we have other impls.?
19:29:22 <Bert_lap> ChrisL: Webkit was not tested yet.
19:29:37 <Bert_lap> DaivdB: Webkit seems pretty good.
19:29:54 <Bert_lap> ChrisL/DavidB: 15C may not matter
19:30:13 <Bert_lap> [DavidB trying out things in webkit.]
19:30:30 <dbaron> we don't have 2 impls for 174a, 174b, and d3
19:30:43 <dbaron> also 0 impls for 15c, but I don't think that matters
19:30:55 <dbaron> Mozilla is the only impl passing 174a, 174b, and d3 that I know of
19:31:33 <Bert_lap> Glazou: I am trying to get impl. report from zoomorama(sp?}
19:31:50 <Bert_lap> Fantasai: Should we also look at Prince?
19:32:04 <Bert_lap> Glazou: Yes, Prince is interesting.
19:32:27 <Bert_lap> ... May also look at Andrew Fedoniouk's HTMLayout.
19:32:49 <Bert_lap> [Several discussions at the same time]
19:33:12 <Bert_lap> Fantasai: I'll run tests on Prince.
19:33:27 <Bert_lap> ChrisL: I can try Webkit.
19:34:09 <Bert_lap> [Discussion about most efficient way to quickly press keys.]
19:34:32 <Bert_lap> Fantasai: We need another impl. for some tests. Webkit not enough.
19:34:38 <Kai> Kai has joined #css
19:34:51 <Bert_lap> ChrisL: I talked to Opera about their failures. Maybe they can do something about it.
19:35:16 <Bert_lap> Beth: I tested the failures and they still fail in latest build.
19:35:25 <Bert_lap> Topic: Color and gamma correction
19:35:28 <tantek> tantek has changed the topic to: CSS3 Color and gamma correction
19:35:47 <Bert_lap> DavidB: Gamma may not be the right term.
19:35:57 <Bert_lap> ... Colors are in sRGB.
19:36:06 <Bert_lap> ... But nobody really impleents it.
19:36:14 <dsinger> see 3.1.1 in http://www.w3.org/TR/css3-color/
19:36:38 <Bert_lap> ... Do we relax the spec?
19:36:55 <Bert_lap> ChrisL: On many platforms sRGB is right by default.
19:37:01 <Bert_lap> Beth: Not on the mac.
19:37:25 <Bert_lap> DavidB: 2nd question is do we give authors a way to opt in?
19:37:35 <Bert_lap> ... Plugins are a known problem.
19:38:02 <Bert_lap> ... The right thing would be to treat CSS colors as well as untagged images to be in sRGB.
19:38:13 <Bert_lap> ... I don't know what Flash defines.
19:38:22 <Bert_lap> ChrisL: Nothing.
19:38:42 <Bert_lap> DavidB: Flash guys may be interested in defining something.
19:38:52 <Bert_lap> ... But we may also want to give authors a choice.
19:38:53 <ChrisL> s/Nothing/No color management, currently/
19:39:00 <fantasai> Prince passes 174a and 174b and 15c
19:39:13 <fantasai> fails d3 (since it's dynamic)
19:39:15 <Bert_lap> DavidS/Beth: A vague idea we had:
19:39:27 <Bert_lap> ... An ability to turn it on with a property.
19:39:40 <Bert_lap> ... Not crazy about the idea, but needed it for a client.
19:39:52 <Bert_lap> Tantek: So you needed it per element?
19:39:59 <fantasai> Konqueror passes d3
19:40:44 <Bert_lap> ChrisL: A need per element maybe because of video, of which there is more and more,as well as tagged images.
19:41:09 <Bert_lap> DavidS: And if you it on body, it applies to everything?
19:41:36 <Bert_lap> ... Example: a background behind a flash, and only that, should be uncorrected.
19:42:07 <Bert_lap> Beth: We don't want to override color profiles when explicit in an image.
19:42:12 <ChrisL> Need to override *tagged* immages is minimal
19:42:21 <Bert_lap> DaviDS: There are also many incorrectly tagged images.
19:42:33 <Bert_lap> DavidB: Gecko now corrects tagged images.
19:42:52 <Bert_lap> Tantek: DavidS, what do you want, more precisely?
19:43:00 <ChrisL> Not clear that there are many incorrectly tagged images
19:43:14 <Bert_lap> DavidS: You can say that the color space of this element is such and such, or is 'none'.
19:43:27 <Bert_lap> Tantek: And if the image is tagged, it will override?
19:43:51 <Bert_lap> ... So you described the 'auto' value that we had in a previous draft.
19:44:04 <Bert_lap> DavidB: But we also need our current behavior.
19:44:23 <Bert_lap> ... Which is not interoperable.
19:44:48 <Bert_lap> DavidS: But it is consistent in a single browser.
19:46:05 <Bert_lap> Beth: We want 'auto' to match whatever browser decides to do. Which may even change over time...
19:46:31 <Bert_lap> Tantek: If you use 'auto', you cannot count on any specific behavior.
19:47:02 <Bert_lap> DavidB: You can count on it being consistent with a single browser.
19:47:23 <Bert_lap> DavidS: We may want to force platform-specific colors.
19:47:32 <Bert_lap> DavidB: Not sure we want that.
19:47:55 <myakura> myakura has joined #css
19:48:14 <Bert_lap> Tantek: Would there be no standardized value in the UA style sheet?
19:48:54 <Bert_lap> ChrisL: Difference between platform color spce and platform specific behavior, which may be color managed.
19:49:20 <Bert_lap> DavidB: Mozilla changed to be compatible with Webkit and go a lot of negative feedback.
19:49:34 <Bert_lap> Tantek: 'Default' could be another keyword.
19:50:01 <Bert_lap> ... It means you cannot count on cross-platform conistency.
19:50:08 <Bert_lap> Beth: Sounds good.
19:50:32 <Bert_lap> ... It means: what UA would do if the property weren't specified at all.
19:50:38 <Bert_lap> ... That can change over time.
19:50:48 <Bert_lap> ... E.g., at the moment we don't do color managament at att.
19:50:54 <Bert_lap> ... But we may do so in the future.
19:51:00 <Bert_lap> s/att/all/
19:51:25 <Bert_lap> Tantek: So 'auto' means treat as sRGB, except for images that are tagged.
19:51:37 <Bert_lap> ... And 'sRGB' means override the image tags.
19:52:12 <ChrisL> Pointer to the relevant part of the old spec  http://www.w3.org/TR/2003/CR-css3-color-20030514/#icc-color
19:52:17 <Bert_lap> DavidS: So we have 'historical' and 'correct' (as keywords?).
19:52:59 <ChrisL> we don't want to encourage overiding of images, so the old proposal is not very good. Tantek's current wording is better
19:53:08 <Bert_lap> Tantek: Two values for reintroduced color-profile: default (as per Beth) and srgb, defined the way 'auto' used to be defined.
19:53:32 <ChrisL> "All colors are presumed to be defined in the sRGB color space unless a more precise embedded profile is specified within content data. For images that do have a profile built into their data, that profile is used. For images that do not have a profile, the sRGB profile is used so that the colors in these images can be kept "in synch" with the colors specified in CSS and HTML."
19:53:50 <Bert_lap> Tantek: a'uto' exactly as that quoted text.
19:54:04 <Bert_lap> Tantek: And just two values seems enough.
19:54:34 <Bert_lap> Brad: Wrong tags in images?
19:54:40 <dsinger> note that the correct application of color spaces in plugins is the responsibility of the plugin and not the browser
19:54:59 <ChrisL> Brad is concerned about images saves with incorrect profiles, which was not noticed because browsers only started dealing with tagged images fairly recently
19:55:00 <Bert_lap> DavidB: That will never cause probelsm on some machine but not others. You will see the problem immediately.
19:55:18 <dsinger> note that the color spaces used in video are different, and the color correction of video is handled by the video subsystem
19:55:30 <Bert_lap> Peter: Didn't you, DavidB, say there were tools that generated wrongly tagged images?
19:55:44 <Bert_lap> DavidB: I think I said there were many untagged images.
19:55:57 <Bert_lap> chrisL: Most common tag is Adobe RGB.
19:56:22 <Bert_lap> DavidS: I want authors to tag images correctly.Not provide a work-around.
19:56:47 <ChrisL> most common after untagged, or tagged as sRGB, is AdobeRGB
19:57:20 <Bert_lap> [Discussion of DavidS text above]
19:57:52 <Bert_lap> ChrisL: Untagged video is almost sRGB in practice.
19:58:17 <Bert_lap> Tantek: Can DavidS find out if it is OK to treat unagged video as sRGB?
19:58:18 <ChrisL> its the same primaries (CCIR 709 primaries) the transfer curve is slightly different
19:58:48 <tantek> re-introduce 'color-profile' property, two values. 'default' per Beth's definition, and 'sRGB' per definition of 'auto' from http://www.w3.org/TR/2003/CR-css3-color-20030514/#icc-color
19:58:50 <tantek> specifically
19:58:56 <tantek> 'sRGB'
19:59:20 <Bert_lap> ACTION on DavidS check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
19:59:20 <trackbot> Sorry, couldn't find user - on
19:59:27 <tantek> "All colors are presumed to be defined in the sRGB color space unless a more precise embedded profile is specified within content data. For images that do have a profile built into their data, that profile is used. For images that do not have a profile, the sRGB profile is used so that the colors in these images can be kept "in synch" with the colors specified in CSS and HTML."
19:59:36 <Bert_lap> ACTION on Singer check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
19:59:36 <trackbot> Sorry, couldn't find user - on
20:00:06 <ChrisL> ACTION: DavidS to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
20:00:06 <trackbot> Sorry, couldn't find user - DavidS
20:00:17 <ChrisL> trackbot, status
20:00:33 <ChrisL> ACTION: Dsinger to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
20:00:33 <trackbot> Sorry, couldn't find user - Dsinger
20:00:49 <ChrisL> ACTION: singer to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not.
20:00:49 <trackbot> Created ACTION-194 - Check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not. [on David Singer - due 2009-11-10].
20:02:49 <Bert_lap> RESOLUTION: re-add a 'color-profile'-like property with the two values 'auto' and 'srgb'
20:02:55 <smfr> s/auto/default
20:03:24 <Bert_lap> Beth: We are working on -webkit- prefixed property, May be available by end of week.
20:03:39 <ChrisL> s/color-profile/color-correction/
20:03:47 <Bert_lap> ChrisL: Name should not clash with SVG.
20:04:02 <Bert_lap> Tantek: Other name is fine.
20:04:55 <Bert_lap> Tantek: call it 'color-correction'
20:05:08 <Bert_lap> DavidB: Per element is harder than per document.
20:05:26 <Bert_lap> ChrisL: Won't be changed very often.
20:06:13 <Bert_lap> [Dicussion about allowing UA to only do per document.]
20:06:33 <Bert_lap> Tantek: So require per-element?
20:06:40 <ChrisL> please lets
20:07:11 <Bert_lap> DavidB: I don't want to have to check it for every color paint.
20:08:40 <tantek> also proposed: drop section 3.1.1 Gamma correction
20:08:45 <Bert_lap> Bert: How do you get untagged images to match CSS text?
20:08:52 <tantek> http://www.w3.org/TR/2008/WD-css3-color-20080721/#gamma
20:08:58 <Bert_lap> Tantek: You say 'color-correction: srgb'
20:10:04 <Bert_lap> ChrisL: Do we have sufficient text for this property?
20:10:15 <Bert_lap> Tantek: Yes, everything is in IRC [above]
20:10:27 <Bert_lap> DavidB: Another last call for Color?
20:10:38 <Bert_lap> Tantek: Can we not go to CR with this change?
20:10:53 <Bert_lap> ChrisL: It's a change, needs a WD.
20:11:13 <Bert_lap> ... But can go straight to PR after the LC, if we have implementation reports.
20:11:43 <Bert_lap> .. So, write the test, and make sure UAs pass them, in particular Safari and Firefox.
20:12:03 <Bert_lap> ... Opera doesn't do color management. I want to try to get them to change.
20:12:26 <tantek> write tests including vendor prefixed properties for color-correction to allow for those implementations to enable passing the tests.
20:12:28 <Bert_lap> ... Some of the platforms it runs on are hard to determine.
20:12:46 <Bert_lap> Arron: We don't do color management either.
20:12:59 <Bert_lap> DavidB: Is 'srgb' the right keyword?
20:13:11 <ChrisL> s/needs a WD/needs a Last Call/
20:13:22 <Bert_lap> Tantek: We can always add 'srgb-force-damnit'...
20:13:40 <Bert_lap> DaviDB: Also, retract that comment.
20:13:51 <Bert_lap> Glazou: Next steps?
20:14:06 <Bert_lap> ChrisL: Some editing, test cases, LC, and PR.
20:14:43 <dbaron> http://www.w3.org/Style/CSS/Test/CSS3/Color/current/
20:15:10 <ChrisL> http://www.w3.org/Style/CSS/Test/CSS3/Color/20081014/reports/
20:15:31 <Bert_lap> RESOLUTION: drop section 3.1.1 
20:17:13 <Bert_lap> Topic: Media Quries in HTML5 video
20:17:31 <Bert_lap> DavidS: Proposal is to add media query to VIDEO element.
20:17:53 <Bert_lap> ... And then also add queries for the user's special needs.
20:18:23 <Bert_lap> Glazou: Seems like a good idea. I never thought it was just the media, always the context.
20:18:50 <Bert_lap> Tantek: So DavidS want some new terms to be added to the spec.
20:18:57 <Bert_lap> ... And then a new LC.
20:19:05 <Bert_lap> Several: Or a second version.
20:19:31 <Bert_lap> General agreement to not change the current spec, but write a new one.
20:19:49 <Bert_lap> ChrisL: So just a draft for the new values, not repating the old ones?
20:19:54 <Bert_lap> Glazou: Yes.
20:20:02 <Bert_lap> Topic: ftf dates 2010
20:21:40 <Bert_lap> Old proposal was 22-24 March, but AC is 21-22 March, and in Boston, not in California.
20:22:13 <Bert_lap> DavidS: 23-25 in Boston is possible, if we have a host...
20:22:30 <Bert_lap> DavidB: Do we have the list of conflicts still from last time we discussed this?
20:23:20 <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0179.html
20:24:37 <Bert_lap> DavidB: SXSW is Mar 12-16, WWW2010 is Apr 26-30
20:24:50 <Bert_lap> ... How many people *will* be at AC?
20:25:08 <Bert_lap> DavidS: I will need to be at AC, but need not be in CSS WG.
20:25:42 <Bert_lap> Fantasai: I'd like to be on east coast around that time.
20:26:12 <Bert_lap> Bert: Organizing at W3C is likely to be possible.
20:26:32 <dsinger> http://www.w3.org/Member/Eventscal
20:27:15 <Bert_lap> ChrisL: Co-locating with WWW2010, in Raleigh, NC?
20:28:18 <Bert_lap> DavidB: How many will go there?
20:28:27 <Bert_lap> [Discussion about weather in Boston in March.]
20:29:00 <Bert_lap> Fantasai: How many would come in Calif? How many would come in Boston?
20:29:19 <Bert_lap> DavidS: 24-26 March, the rest of the week after AC.
20:29:55 <Bert_lap> [Looking for Easter dates.]
20:30:13 <Bert_lap> Glazou: And August?
20:30:30 <Bert_lap> DavidB: SteveZ had a family event conflict.
20:31:02 <Bert_lap> [Currently scheduled for Oslo, Aug 18-20]
20:31:50 <Bert_lap> DavidS: I also have a conflict for Aug.
20:32:19 <Bert_lap> Glazou: Let's keep August as it is for now. Now Håkon here anyway.
20:32:29 <glazou> s/Now/not
20:32:43 <Bert_lap> DavidS: 2 questions for W3C: host in March? and is there a TPAC end of the year?
20:33:00 <Bert_lap> LUNCH
21:02:02 <jdaggett> jdaggett has joined #css
21:10:39 <MikeSmith> MikeSmith has joined #css
21:15:12 <TabAtkins> TabAtkins has joined #css
21:15:22 <Curt`> Curt` has joined #css
21:15:45 <bradk> bradk has joined #css
21:15:52 <markusm> markusm has joined #css
21:20:34 <Kai> Kai has joined #css
21:21:40 <mjs> mjs has joined #css
21:22:29 <bradk> bradk has joined #css
21:22:45 <Arron> Arron has joined #css
21:23:48 <dbaron> dbaron has joined #css
21:27:42 <Lachy> Lachy has joined #css
21:29:28 <dethbakin> dethbakin has joined #css
21:30:43 <glazou> glazou has joined #css
21:30:50 <hamaji> hamaji has joined #css
21:32:13 <annevk> annevk has joined #css
21:32:58 <shepazu> shepazu has joined #css
21:33:13 <tantek> tantek has joined #css
21:34:35 <TabAtkins> TabAtkins has joined #css
21:34:39 <plinss> plinss has joined #css
21:35:29 <dsinger> dsinger has joined #css
21:36:29 <Bert_lap> Bert_lap has joined #css
21:36:36 <alexmog> alexmog has joined #css
21:36:59 <smfr> smfr has joined #css
21:38:30 <glazou> glazou has joined #css
21:38:44 <bradk> bradk has joined #css
21:38:46 <ChrisL> ChrisL has joined #css
21:39:04 <kohei> kohei has joined #css
21:39:19 <dsinger> followed by a break for non-persistent cookies
21:40:00 <ChrisL> ChrisL has joined #css
21:40:23 <ChrisL> Scribe: Chris
21:40:30 <ChrisL> ScribeNick: ChrisL
21:40:44 <ChrisL> Topic: Test suite status
21:43:00 <ChrisL> Aaron: What's that staus, who has reviewed their tests
21:43:14 <tantek> tantek has changed the topic to: Test suite status
21:43:17 <ChrisL> Elika: I'm doing a coverage report
21:43:38 <ChrisL> AAron: Still targetting 15 January?
21:43:42 <ChrisL> Elika: yes
21:44:08 <ChrisL> s/Aaron/Arron/
21:44:22 <bradk_> bradk_ has joined #css
21:44:22 <dbaron> s/AAron/Arron/
21:44:24 <ChrisL> action: arron to create a template fr CSS 2.1 test suite reports
21:44:24 <trackbot> Created ACTION-195 - Create a template fr CSS 2.1 test suite reports [on Arron Eicholz - due 2009-11-10].
21:44:32 <ChrisL> s/Aaron/Arron/
21:44:43 <glazou> BTW, not sure everyone in the WG got news from Robert Stevahn : http://twitpic.com/o63vs :-)
21:45:20 <ChrisL> Elika: we have implementations for all selectors tests, counting prince, webkit, opea and firefox
21:45:37 <sylvaing> sylvaing has joined #css
21:45:53 <ChrisL> ... appart from the 15c subtest which needs multiple id support, already listed as feature at risk
21:46:03 <ChrisL> glazou: champagne
21:47:03 <ChrisL> http://www.cardsunlimited.com/largeimage/Champagne.jpg
21:48:39 <ChrisL> Resolution: Advance to Proposed Recommendation for the Selectors spe
21:48:46 <ChrisL> s/spe/spec/
21:50:26 <ChrisL> Topic: Gradients and Image Sprites
21:50:55 <ChrisL> Arron: recall this had to but not sure what it is
21:51:00 <ChrisL> David: Who added it
21:51:08 <ChrisL> Tab: Not sure what it means either
21:51:15 <ChrisL> (we are all confused)
21:52:06 <ChrisL> Tab: Asked Shepazu to help with SVG equivalents of the gradient examples
21:52:19 <ChrisL> ... for sprites, its choosing between options
21:52:35 <ChrisL> Elika: No, i just liked to the various proposals
21:52:45 <ChrisL> David: We implemented moz-image-rect
21:53:14 <ChrisL> Elika: the URI based syntax has no fallback. Could addit by putting it im the image not in the URI
21:53:37 <ChrisL> Elika: no need to a separate functional notation. 
21:53:48 <dbaron> s/moz-image-rect/-moz-image-rect()/
21:53:55 <ChrisL> ... if linked to image functional notation and require both to be iplemented
21:54:05 <ChrisL> ... waiting for media fragments wg to publish a spec
21:54:29 <ChrisL> Elika: Image sprites should make it more efficient that specifying explicit coods in the stylesheet
21:54:40 <ChrisL> ... not so much to discuss therefore
21:55:17 <szilles> szilles has joined #css
21:55:19 <ChrisL> Simon: I have some feedback, will send on list
21:55:33 <ChrisL> ACTION: Simon to send gradients feedback to www-style
21:55:33 <trackbot> Created ACTION-196 - Send gradients feedback to www-style [on Simon Fraser - due 2009-11-10].
21:56:25 <bradk> http://www.bradclicks.com/cssplay/drop-shadow/Drop-Shadow.html
21:56:27 <ChrisL> Topic: Drop shadows
21:56:43 <ChrisL> (brad demonstrates)
21:59:20 <ChrisL> brad: we want something that casts a shadow under the element, casts from background and border
22:00:06 <ChrisL> ... transparecy affects the color of the shadow where it overlaps. based on alpha channel
22:00:53 <ChrisL> (brad fiddles with the drop shadow dialog in photoshop)
22:01:04 <ChrisL> Brad: shadow has translucency
22:02:09 <ChrisL> ... inner version of a shadow 
22:02:56 <ChrisL> Chris: Please define how you are using the term inner
22:03:10 <fantasai> CSS2.1 coverage report (thrown rather haphazardly together, somewhat incomplete): http://lists.w3.org/Archives/Public/www-archive/2009Nov/att-0002/index.xht
22:03:23 <ChrisL> Brad: the shape is cut out of the background  and the shadow is on that
22:04:33 <ChrisL> Chris: the shadow is in fact still on top
22:04:36 <ChrisL> Brad: yes
22:04:49 <ChrisL> (we discover the projector really needs color management)
22:05:57 <ChrisL> Brad: so this is easy with sharp edges. with soft edges people seemed to be confused
22:06:15 <ChrisL> Chris: its the same copy, remove color, add color, blur, opacity operation
22:08:28 <ChrisL> Chris: notice you are using blending modes - svg has those
22:11:22 <ChrisL> (discussion on what exactly is happening in photoshop as people get their heads around it)
22:11:35 <ChrisL> Simon: Easier to look at the actual proposal
22:14:16 <ChrisL> Tab: the shadow is cast by a negative of the alpha channel, then clipped to the actual alphs channel
22:16:36 <ChrisL> John: what is the use case for this?
22:16:58 <ChrisL> ... the photoshop is not convincing me of the utility
22:17:10 <ChrisL> Elika: We have box shadows already
22:17:37 <ChrisL> David: And we implement that, but lets decide if this part is useful before deciding exactly how it works
22:18:15 <ChrisL> (brad demonstrates inner shadow on text)
22:19:17 <ChrisL> Simon: With box and text shadow, the shadow does not depend on the transparency of the element
22:19:46 <ChrisL> ... fully transparent text still casts a shadow, with text-shadow
22:20:27 <ChrisL> Brad: suppose you want just the border, or the background, or *one* of the backgrounds shaddowed
22:20:41 <ChrisL> Simon: That seems more useful in the filters discussion
22:21:34 <bradk> apply-to(border + foreground, background-image + background-color)
22:21:35 <bradk> apply-to(border + foreground, background-image + background-color)
22:21:35 <bradk> apply-to(border + foreground, background-image + background-color)
22:21:39 <ChrisL> Brad: pluses mean the shapes composite before shadow calculation, commas mean they each have their own shadow
22:22:57 <ChrisL> David; apply-to gives the z-order?
22:23:13 <ChrisL> .. what if you apply to things that are not z-ordered together?
22:23:56 <ChrisL> Elika: you cant composite the text and the background and composite onto the border
22:24:30 <ChrisL> Simon: this is trying to get photoshop into css, i don't see the use case. Separate elements can be used to do this
22:25:04 <ChrisL> John: This sort of effect is better done in SVG, we don't need another language to do this. its a complex mechanism that duplicates something which already exists
22:25:25 <ChrisL> Elika: So SVG filters can be used but we lack the ability to select parts of the border
22:25:44 <ChrisL> John: If the goal is to do something this complex, is CSS the right language?
22:27:49 <ChrisL> Chris: We are headed for a fairly complex selector model if we do this, to get at parets of the border
22:28:39 <ChrisL> Elika: getting the whole border would be sufficient, but we need to address the different background layers
22:29:52 <bradk> ::apply-to(border + foreground, background-image + background-color)
22:30:25 <ChrisL> Chris: could imageine pseudo elements to address the border, the background(s)  and the content
22:31:15 <fantasai> Then how do you turn it off?
22:31:23 <fantasai> How many pseudo-elements do you need to write to turn it off?
22:31:34 <fantasai> dbaron: I don't think this is the right way to do it...
22:31:55 <ChrisL> Brad: just targetting the whole border would satisfy my needs
22:32:15 <fantasai> fantasai: The pieces we'd need to address, in various combinations: background layers, border (one piece), content (one piece)
22:32:54 <ChrisL> Brad: we don't want to implement all of svg in css, sure. We want to be eble to use parts of them
22:33:07 <ChrisL> David: we already do SVG filters on any element
22:33:32 <ChrisL> Brad: but only the whole parts
22:33:55 <ChrisL> David: add to source-graphic source-alpha etc to add source-border, source-background ......
22:34:17 <fantasai> dbaron attempts to summarize how svg filters work
22:34:30 <smfr> http://www.w3.org/TR/SVG/filters.html#FilterPrimitivesOverview
22:34:32 <smfr> (scroll down)
22:34:38 <ChrisL> Simon: fill-apint and stroke-paint
22:35:39 <ChrisL> David: things to address the border, background or contents
22:35:56 <ChrisL> Tab: Could we use parameters with that
22:36:01 <ChrisL> Chris: Sure
22:36:17 <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Oct/0072.html
22:36:52 <ChrisL> Elika: need a way to aprameterise that so we have a library of effects and apply them,  without writing new filters
22:37:24 <ChrisL> Simon: background image in SVG is what has already been painted by other elements
22:38:01 <ChrisL> Elika: roc has some name suggestions
22:38:26 <ChrisL> Chris: please pass those on to the SVG WG. The editor is Erik Dahlstrom from Opera. We can add them
22:38:53 <ChrisL> David: Put them in the order you want and thats how they end up
22:38:57 <shepazu> [I'd be happy to talk to the CSS about my SVG parameters specification, which could pass parameters through a CSS property]
22:39:43 <jdaggett> shepazu: cmon down dear
22:39:56 <ChrisL> Elika: does not make sense for a border to cast a shadow *under* the background
22:40:49 <fantasai> border casts a shadow immediately under the border, i.e. over the background
22:40:50 <ChrisL> Brad; we should retain the natural stacking order
22:41:04 <fantasai> if border and background ar composited, then their shadow casts underneath the composited layer
22:41:12 <fantasai> i.e. directly underneat the background
22:42:43 <ChrisL> (discussion on how to pass opacity to a filter)
22:46:43 <ChrisL> Sion: how to get the putput of the filter int he right place
22:47:24 <ChrisL> s/Sion/Simon/
22:48:05 <ChrisL> Shepazu: we are adding more canned filter effects, we could add more if you identify the. Adds a merge for the border etc
22:48:52 <ChrisL> Elika: a filter to make the border and background partly transparent
22:49:49 <ChrisL> Shepazu: filters can be computationally intensive. Though canned filters can be optimised. need to warn authors
22:49:52 <ChrisL> Tab: Yes
22:50:11 <ChrisL> ... but won't trigger unexpectedly. Its clearly an opt-in
22:50:33 <ChrisL> Shepazu: Need to make a tradeoff between power, speed and authoring ease
22:50:54 <ChrisL> Simon: want to see blur and colour manip filters
22:51:02 <ChrisL> Shepazu: sepia, b&w
22:51:21 <ChrisL> Brad: so value in having a simple drop shadow?
22:51:35 <ChrisL> http://www.bradclicks.com/cssplay/drop-shadow/Drop-Shadow.html
22:52:12 <Lachy> Lachy has joined #css
22:52:17 <ChrisL> Shepazu: need review from Erik and Anthony
22:53:07 <ChrisL> Brad: syntax there is more similar to the existing box-shadow property. Illustrations were done in photoshop
22:53:34 <ChrisL> Shepazu: Need to discuss, only now introducing canned filter effects so open to syntax that makes sense for CSS authors
22:53:50 <arronei> arronei has joined #CSS
22:56:09 <ChrisL> (we look at innter shadow on text again)
22:56:53 <ChrisL> Simon: for canned filters we would likely go to core graphics
22:57:20 <Bert_lap> s/innter/inner/
22:58:02 <ChrisL> Elika: happy to join any SVG telcons about this
22:58:49 <ChrisL> filters spec is here  http://dev.w3.org/SVG/modules/filters/publish/SVGFilter.html
22:59:19 <dbaron> http://lists.w3.org/Archives/Public/public-fx/
22:59:47 <ChrisL> Shepazu: there is a public-fx@w3.org list
22:59:53 <ChrisL> http://lists.w3.org/Archives/Public/public-fx/
23:00:57 <ChrisL> Chris: canned effecxts are great, though people should be able to use arbitrary filters as well
23:04:32 <ChrisL> Topic; F2f dates, the re-re-run
23:04:57 <ChrisL> Szilles: the proposed dates clash with the AB meeting. next week would be fine
23:06:54 <ChrisL> Now moved to Cupertino, 29-31 March 2010
23:09:13 <ChrisL> Topic: SVG Params
23:09:55 <ChrisL> (Doug walks through http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html )
23:21:00 <annevk> annevk has joined #css
23:23:23 <ChrisL> David, PLH: using ? in the URI mesans its server side, not client side
23:23:52 <ChrisL> foo.svg#param(name, value; name,value)
23:25:11 <dbaron> might you want to svg:use foo.svg#element with parameters?
23:25:44 <ChrisL> john: is there an expression language?
23:25:50 <ChrisL> shepazu: not yet
23:27:24 <MikeSmith> MikeSmith has joined #css
23:31:49 <Bert_lap> (Use an SVG file that consists of "param(x)" and nothing more, than pass <param name=x value="A bit of SVG..."> :-) )
23:34:24 <dsinger> dsinger has changed the topic to: Coming Soon to a Stop
23:34:40 <ChrisL> Peter: would be great to pass in the currently cascaded color for example
23:34:53 <dsinger> dsinger has changed the topic to: Canwe Substitute in SVG?
23:37:03 <ChrisL> adjourned!
23:37:12 <ChrisL> rrsagent, make minutes
23:37:12 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/03-CSS-minutes.html ChrisL
23:38:29 <bradk> bradk has joined #css
23:53:50 <dsinger> dsinger has joined #css
00:12:23 <Kai> Kai has joined #css
00:17:38 <tantek> tantek has joined #css
00:40:05 <Bert_lap> Bert_lap has joined #css
00:55:21 <sylvaing> sylvaing has joined #css
00:58:58 <Arron> Arron has joined #css
01:16:28 <kohei> kohei has joined #css
01:16:35 <kohei> kohei has left #css
01:16:38 <markusm> markusm has joined #css
01:39:10 <tantek> tantek has joined #css
01:45:12 <dbaron> dbaron has joined #css
01:47:57 <Bert_lap> Bert_lap has joined #css
01:49:56 <plinss> plinss has joined #css
01:50:28 <glazou> glazou has joined #css
01:50:39 <annevk> annevk has joined #css
01:51:21 <plinss> plinss has joined #css
02:08:17 <hamaji> hamaji has joined #css
02:17:38 <Zakim> dbaron, you asked to be reminded at this time to go home
02:30:53 <dbaron> Zakim, I can't, since I'm in another meeting now.
02:30:53 <Zakim> I don't understand you, dbaron
02:32:57 <Bert> :-)
02:44:39 <bz> zakim, your understanding is somewhat limited in general
02:44:39 <Zakim> I don't understand you, bz
02:58:11 <dbaron> Zakim, bye
02:58:11 <Zakim> Zakim has left #css
02:58:26 <dbaron> RRSAgent, pointer?
02:58:26 <RRSAgent> See http://www.w3.org/2009/11/03-CSS-irc#T02-58-26
02:58:29 <dbaron> RRSAgent, bye
02:58:29 <RRSAgent> I see 5 open action items saved in http://www.w3.org/2009/11/03-CSS-actions.rdf :
02:58:29 <RRSAgent> ACTION: DavidS to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not. [1]
02:58:29 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-CSS-irc#T20-00-06
02:58:29 <RRSAgent> ACTION: Dsinger to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not. [2]
02:58:29 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-CSS-irc#T20-00-33
02:58:29 <RRSAgent> ACTION: singer to check with HTML WG that untagged video can be treated as sRGB, or provide counter examples if not. [3]
02:58:29 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-CSS-irc#T20-00-49
02:58:29 <RRSAgent> ACTION: arron to create a template fr CSS 2.1 test suite reports [4]
02:58:29 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-CSS-irc#T21-44-24
02:58:29 <RRSAgent> ACTION: Simon to send gradients feedback to www-style [5]
02:58:29 <RRSAgent>   recorded in http://www.w3.org/2009/11/03-CSS-irc#T21-55-33