IRC log of CSS on 2009-11-03
Timestamps are in UTC.
- 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