Options:
- # Session Start: Wed Apr 28 00:00:00 2010
- # Session Ident: #css
- # [00:10] * Quits: jdaggett_ (jdaggett@118.243.224.63) (Quit: jdaggett_)
- # [00:39] * Quits: divya (divya@24.22.131.46) (Quit: divya)
- # [00:48] * Joins: dbaron (dbaron@63.245.220.240)
- # [00:57] * Joins: divya (divya@24.22.131.46)
- # [01:53] * Joins: anne (annevk@111.188.6.50)
- # [01:57] <fantasai> TabAtkins: Sent April 1st
- # [01:58] * fantasai needs to put image-fit and image-position into the images draft, it would help put some of this other stuff in perspective
- # [02:43] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [03:08] * Parts: anne (annevk@111.188.6.50)
- # [03:08] * Joins: anne (annevk@111.188.6.50)
- # [03:30] * Quits: anne (annevk@111.188.6.50) (Ping timeout)
- # [03:45] * Joins: shepazu (schepers@128.30.52.169)
- # [04:39] * Joins: anne (annevk@58.1.224.28)
- # [04:51] * Quits: Curt` (DorkeyDear@75.10.138.206) (Quit: Leaving)
- # [05:32] * Joins: dbaron (dbaron@98.234.51.190)
- # [05:59] * Parts: divya (divya@24.22.131.46)
- # [07:24] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [10:13] * Joins: lstorset (lstorset@213.236.208.22)
- # [10:13] * Parts: lstorset (lstorset@213.236.208.22)
- # [10:34] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: Leaving)
- # [10:52] * Joins: Lachy (Lachlan@83.170.95.133)
- # [10:56] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: Leaving)
- # [10:57] * Joins: Lachy (Lachlan@85.196.122.246)
- # [11:23] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
- # [11:30] * Quits: anne (annevk@58.1.224.28) (Ping timeout)
- # [11:33] * Joins: Lachy (Lachlan@213.236.208.22)
- # [14:00] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
- # [14:11] * Joins: myakura (myakura@220.104.128.62)
- # [15:21] * Joins: miketaylr (miketaylr@38.117.156.163)
- # [15:49] * Joins: divya (divya@24.22.131.46)
- # [17:02] * Joins: CesarAcebal (acebal@85.152.177.64)
- # [17:34] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
- # [17:44] * Joins: glazou (glazou@85.168.30.158)
- # [17:44] * Joins: Zakim (rrs-bridgg@128.30.52.169)
- # [17:44] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
- # [17:44] <RRSAgent> logging to http://www.w3.org/2010/04/28-CSS-irc
- # [17:44] <glazou> Zakim, this will be Style
- # [17:44] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 18 minutes
- # [17:44] <glazou> RRSAgent, make logs public
- # [17:44] <RRSAgent> I have made the request, glazou
- # [17:54] <glazou> Zakim, code?
- # [17:54] <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), glazou
- # [17:55] * Joins: jdaggett (jdaggett@118.243.224.63)
- # [17:56] * Joins: Lachy (Lachlan@85.196.122.246)
- # [17:56] * Joins: bradk (bradk@67.188.133.45)
- # [17:56] <glazou> jdaggett: you're not attending the call, correct?
- # [17:57] * Quits: jdaggett (jdaggett@118.243.224.63) (Quit: jdaggett)
- # [17:58] <Zakim> Style_CSS FP()12:00PM has now started
- # [17:58] <Zakim> + +95089aaaa
- # [17:58] <glazou> Zakim, aaaa is me
- # [17:58] <Zakim> +glazou; got it
- # [17:58] * Joins: szilles (chatzilla@67.180.186.242)
- # [17:58] * Joins: arronei (arronei@131.107.0.83)
- # [17:59] * Joins: oyvind (oyvinds@213.236.208.22)
- # [18:00] <Zakim> +plinss
- # [18:01] <Zakim> +SteveZ
- # [18:01] * Joins: murakami (murakami@118.154.209.3)
- # [18:02] <Zakim> + +1.650.275.aabb
- # [18:02] <glazou> Zakim, aabb is bradk
- # [18:02] <Zakim> +bradk; got it
- # [18:02] <bradk> Zakim aabb is me
- # [18:03] <Zakim> +Bert
- # [18:04] <Zakim> +[Microsoft]
- # [18:04] <arronei> zakim, Microsoft is me
- # [18:04] <Zakim> +arronei; got it
- # [18:04] * Joins: smfr (smfr@68.183.233.103)
- # [18:04] <Zakim> +[Microsoft]
- # [18:04] * Joins: sylvaing (sylvaing@131.107.0.85)
- # [18:05] <glazou> Zakim, [Microsoft] has sylvaing
- # [18:05] <Zakim> +sylvaing; got it
- # [18:05] <Zakim> +smfr
- # [18:05] <smfr> Zakim, [Apple] has smfr
- # [18:05] <Zakim> sorry, smfr, I do not recognize a party named '[Apple]'
- # [18:06] <glazou> regrets from molly, TabAtkins, dsinger
- # [18:06] <Zakim> + +34.60.940.aacc
- # [18:06] <glazou> Zakim, aacc is CesarAcebal
- # [18:06] <Zakim> +CesarAcebal; got it
- # [18:06] * Bert to fantasai: I changed the mark-up of http://dev.w3.org/csswg/css3-text-layout/ a bit, see the CVS log
- # [18:08] <Zakim> +??P16
- # [18:08] <fantasai> Zakim, P16 is me
- # [18:08] <Zakim> sorry, fantasai, I do not recognize a party named 'P16'
- # [18:08] <Zakim> + +47.21.65.aadd
- # [18:08] <fantasai> Zakim, ??P16 is me
- # [18:08] <Zakim> +fantasai; got it
- # [18:08] <Zakim> -glazou
- # [18:08] <glazou> called dropped hold on
- # [18:08] <fantasai> Zakim +47 is howcome
- # [18:08] <Zakim> +glazou
- # [18:08] <fantasai> Zakim, +47 is howcome
- # [18:08] <Zakim> +howcome; got it
- # [18:09] <fantasai> ScribeNick: fantasai
- # [18:09] <glazou> I have major phone issues apparently
- # [18:10] <fantasai> Topic: Test Suite
- # [18:10] <fantasai> Daniel: Peter and I would like to know where we are at this point
- # [18:10] <fantasai> arron: I started work on adding the metadata
- # [18:10] <fantasai> arron: I should have half done by the end of this week, hopefully all done by end of next week
- # [18:11] <fantasai> arron: That would mean that all the cases that have not been put in due to metadata will be ready to publish in the test suite
- # [18:11] * sylvaing Tab's chinchillas ate my testcases
- # [18:12] <fantasai> fantasai: I haven't done anything, but I think two weeks time is reasonable for preparing a publication
- # [18:12] <fantasai> Topic: Template Layout
- # [18:12] <fantasai> Bert would like to publish a new working draft
- # [18:12] <fantasai> Bert: Mostly small changes, but would like to publish another draft to show it is still active
- # [18:13] <Zakim> +David_Baron
- # [18:13] <fantasai> Bert: Question of what properties should apply to ::slot()
- # [18:13] <fantasai> Bert: Tab favors all properties, I prefer limiting the properties
- # [18:13] * Joins: ChrisL (ChrisL@128.30.52.169)
- # [18:13] <fantasai> RESOLVED: Publish new WD of css3-layout
- # [18:14] <fantasai> Topic: Calc()
- # [18:14] * Joins: dbaron (dbaron@98.234.51.190)
- # [18:14] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Apr/0184.html
- # [18:14] <fantasai> howcome: It's a good question, what should be inherited from calc()
- # [18:14] <Zakim> +ChrisL
- # [18:14] <fantasai> dbaron: I had a proposal in one of the responses
- # [18:14] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Apr/0256.html
- # [18:14] <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Apr/0258.html
- # [18:15] <fantasai> dbaron: Right now, calc() is only taking lengths or percentages. It doesn't take keywords of the properties
- # [18:15] <fantasai> dbaron: We haven't figured out what to do with things that are dimensionally invalid for the property
- # [18:16] <fantasai> dbaron: I suggest percentages transformed the same way they they're handled in the property
- # [18:16] <fantasai> dbaron: And all lengths converted to an absolute length
- # [18:16] <fantasai> dbaron: If we add keywords, they would be treated similar to percentages
- # [18:16] <fantasai> dbaron: So if you say calc(50% + 2em)
- # [18:17] <fantasai> dbaron: Then the em gets converted using the element's font size
- # [18:17] <fantasai> dbaron: The percentage gets calculated according to property rules
- # [18:18] <ChrisL> so the inherited value is the "most resolved" value which might be calc() ...
- # [18:18] <fantasai> dbaron: So font-size: calc(50% + 2em) is equivalent to 250%
- # [18:18] <fantasai> dbaron: But width: calc(50% + 2em) would inherit as calc(50% + Xabsoluteunits)
- # [18:19] <fantasai> ?: It makes sense for a value to inherit the same way when it's inside calc() as when it's outside it
- # [18:19] <glazou> s/?/glazou
- # [18:19] <fantasai> ...
- # [18:19] <bradk> calc(50%) === 50%
- # [18:19] <fantasai> dbaron: We do want calc() to inherit reasonable because people might want to use it for properties that inherit by default
- # [18:20] <fantasai> Sylvain: So, people would want the formula to inherit, not the result of the calculation?
- # [18:21] <Zakim> -howcome
- # [18:21] <fantasai> fantasai: You don't want to inherit the calculation, because that would require you to do layout before inheritance.
- # [18:22] <fantasai> glazou: I'm not sure I like inheriting the formula
- # [18:22] <fantasai> fantasai: If you have width: 50%, you want width: calc(50%) to inherit the same way
- # [18:22] * dbaron is having trouble hearing sylvain
- # [18:23] <Bert> (Currently, 'width: 50%' ... 'width: inherit' also inherits the percentage, not the calculated width, so not too different from calc(50% + 1em).)
- # [18:23] <fantasai> fantasai: If you resolve the formula to an absolute length, then it won't inherit the same way
- # [18:24] * sylvaing david, i was wondering aloud if one may actually want the ability to compute 50% and inherit the result using calc(50%).
- # [18:25] <fantasai> sylvain: Why shouldn't it behave differently? It has a different syntax.
- # [18:26] * dbaron isn't sure if glazou was disagreeing with fantasai or with sylvain
- # [18:26] <glazou> dbaron: with fantasai
- # [18:27] <fantasai> <div class="a"> <div class="b"></div> </div>
- # [18:27] <glazou> Zakim, who is noisy?
- # [18:27] <fantasai> .a { padding: really big; }
- # [18:27] <Zakim> glazou, listening for 10 seconds I heard sound from the following: [Microsoft] (51%)
- # [18:27] <fantasai> Say .a { width: 50% } resolves to 100px
- # [18:28] <fantasai> .b { width: 50%; } resolves to 25px
- # [18:28] <fantasai> .b { width: inherit; } currently also resolves to 25px
- # [18:28] <fantasai> You're suggesting that
- # [18:28] <fantasai> .a { width: calc(50% + 1px) } (resolves to 101px)
- # [18:29] <fantasai> .b { width: inherit; }
- # [18:29] <fantasai> You're saying b should resolve to 101px
- # [18:29] <fantasai> rather than 26px
- # [18:29] <fantasai> you == sylvain
- # [18:30] <dbaron> Zakim, [Microsoft] has Rossen_Atanassov
- # [18:30] <Zakim> +Rossen_Atanassov; got it
- # [18:30] <fantasai> Rossen: So, the response that David actually had, the latest one, saying that you basically inherit the calc and on the way down the inheritance you have two types of inheritance
- # [18:30] <fantasai> Rossen: So ems, you resolve the ems, and then inherit the value
- # [18:31] <fantasai> Rossen: Percentage values inherit all the way down as percentages
- # [18:31] <fantasai> Rossen; so percentages are resolved in your current space
- # [18:31] <fantasai> Rossen: That makes sense to me
- # [18:31] <fantasai> Rossen: If you have calc(50%) it inherits down as 50 percent
- # [18:31] <fantasai> Rossen: But calc(1em) inherits down as whatever 1em calculates tow here it's specified
- # [18:31] <fantasai> Rossen: That's what I see in dbaron's response, and that basically confirms my understanding of how it should work
- # [18:32] <fantasai> SteveZ: So if I have an expression, it will calculate itself out unless it uses a percentage that would not be calculated out at that point if it were freestanding
- # [18:33] * Quits: myakura (myakura@220.104.128.62) (Quit: Leaving...)
- # [18:34] <fantasai> Sylvain argues that the 'calc()' syntax requests a different behavior from a user perspective.
- # [18:35] <fantasai> dbaron disagrees
- # [18:35] <fantasai> Rossen: The interesting example here, suppose we had calc(50% + 1em)
- # [18:35] <dbaron> I think calc() is about combining existing values, and those values should behave just like they do without calc().
- # [18:36] * fantasai thinks we should have used bare parentheses, then Sylvain wouldn't find this confusing
- # [18:36] <fantasai> SteveZ: The surprise doesn't come from calc, it comes from certain values not being calculated due to layout being required.
- # [18:36] <fantasai> SteveZ: This is already an issue. calc() makes it more complicated because some values computed and others don't
- # [18:36] <fantasai> SteveZ: so it emphasizes the problem
- # [18:37] <fantasai> SteveZ: To me, calc() of some value should be exactly the same as that value alone
- # [18:37] <fantasai> fantasai: Does anyone here disagree with SteveZ's last statement?
- # [18:38] <fantasai> Sylvain: I think some people will expect that calc() computes the value and then inherits down.
- # [18:39] <fantasai> Sylvain: I don't think it's crazy that an average web author considers calc(X) should behave differently than X alone
- # [18:40] <fantasai> glazou: We have two ways of saying how calc() is working.
- # [18:40] <dbaron> What's the difference between these proposals?
- # [18:40] <fantasai> glazou asserts that dbaron and fantasai and Rossen and sylvain have different proposals
- # [18:40] <fantasai> dbaron and fantasai don't understnad why
- # [18:40] <fantasai> Sylvain: I'm not proposing something different, I'm just saying it may be confusing.
- # [18:41] <fantasai> Rossen: calc() is just like parentheses. You can put parentheses around a single value in an expression; it doesn't do anything
- # [18:41] <fantasai> Rossen: I'm fine with writing up a paragraph on this
- # [18:42] <fantasai> SteveZ: I think that the teaching thing is no worse than teaching exponents, when any number to the first power is the same as that number
- # [18:42] <fantasai> Sylvain: The functional notation creates some expectations
- # [18:43] <fantasai> SteveZ: I found dbaron's description hard to read, so Rossen, if you write it up I would prefer a better explanation of why percentages behave the way they do
- # [18:43] <dbaron> I think the essence of my proposal is that each leaf value within the calc() expression gets computed as though it's a value of the property.
- # [18:43] <dbaron> Except I worded it to allow for values that aren't values of the property.
- # [18:44] <fantasai> Topic: Selectors Serialization
- # [18:44] <bradk> width: calc(100% - <padding-amount>) is something I could imagine using, and inheriting
- # [18:44] <fantasai> glazou: Is anne on the call?
- # [18:44] * fantasai can't imagine anyone inheriting width
- # [18:44] <fantasai> Topic: RFC on View Modes
- # [18:44] <smfr> url?
- # [18:44] <Bert> http://www.w3.org/TR/2010/WD-view-mode-20100420/
- # [18:45] <fantasai> SteveZ: Who wrote the comments?
- # [18:45] <fantasai> Bert: i think we developd the comments together
- # [18:45] <fantasai> Steve: But somebody sent them
- # [18:46] <fantasai> glazou: Peter and Bert and I will sort it out after the call
- # [18:46] <fantasai> Topic: Empty Media Queries
- # [18:46] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Apr/0391.html
- # [18:47] <fantasai> Sylvain: The one thing was the definitions are in two different places
- # [18:47] <fantasai> Sylvain: I understand if we don't want to move backwards to fix that
- # [18:48] <fantasai> ChrisL: In the DOM, if you remove an attribute or if it has it's default value, you can tell the difference. Is that the same as here?
- # [18:48] <fantasai> Sylvain: The implementations of @media are inconsistent, and it is more inconsistent when you consider the markup side
- # [18:49] <fantasai> Sylvain: Right now we have the OM defined somewhere else, not fully defined
- # [18:49] <fantasai> Sylvain: And then we have the spec for the static definition of media queries
- # [18:49] <fantasai> Sylvain: And because we have different specs, we won't have a full set of testcases
- # [18:49] <fantasai> ChrisL: Sounds like you're arguing to merge the two specs
- # [18:49] <fantasai> Sylvain: ... interop
- # [18:50] <fantasai> ChrisL: There is a problem with testing things between the specs
- # [18:50] <fantasai> Sylvain: I think it's worth it, but I'd like to hear what others think. Because right now there is no interop
- # [18:50] <ChrisL> ... and thus these two should be combined
- # [18:50] <fantasai> Sylvain: The results at the edges are pretty strange
- # [18:51] <fantasai> dbaron: We discussed in the past what empty media queries should mean
- # [18:51] <fantasai> dbaron: We concluded that empty media queries are equivalent to all, but other specs might not allow empty media queries.
- # [18:51] <fantasai> dbaron: So you can't write @media { } and expect that to apply to all media
- # [18:51] <ChrisL> why does that spec dissalow an empty media query?
- # [18:52] <fantasai> because it wasn't allowed in 2.1
- # [18:52] <fantasai> dbaron: The spec has changed over time, and maybe some statements that would clarify have moved around or been lost
- # [18:53] <fantasai> Sylvain: For compat with legacy, you have media='' equivalent to all, and then @media { } is invalid, and then deleting mediums from the OM gives you 'not all'
- # [18:54] <fantasai> Sylvain: I think I understand what I'm supposed to do for a static style sheet, but I'm not so sure about the OM
- # [18:54] <fantasai> glazou: Does that mean we need an extra constraint on the OM saying that the empty media list is invalid for the OM?
- # [18:55] <fantasai> Sylvain: I don't think we'll get a perfect model for compat, but, even if the attribute, OM, and style sheet behave differently at least it should be defined somewhere
- # [18:55] <fantasai> ChrisL: Why can't @media { } mean all?
- # [18:56] <fantasai> dbaron: I think it's perfectly reasonable, but every time we discuss this issue we come to a different conclusion
- # [18:56] <fantasai> dbaron: We resolved last August that it should be invalid. I went and implemented that.
- # [18:56] <ChrisL> this is why we need to get specs to rec instead of being in permanent churn
- # [18:56] <fantasai> dbaron: It's gotten to the point that when the group discusses something and resolves it, I don't consider it permanent
- # [18:57] <fantasai> Sylvain: I'm not asking for consistency among OM, attr, and CSS, I just want it clearly defined
- # [18:57] <fantasai> glazou: If I have an @media string, and from the OM I want to remove the one media attached to it and replace it with anothe
- # [18:58] <ChrisL> i agree with daniel. the intermediate state is all
- # [18:58] <fantasai> glazou: It makes sense for the intermediate state to mean all
- # [18:58] <ChrisL> that isn't a contradiction. its ok to have something reachable by dom that is not reachable by syntax
- # [18:58] <fantasai> glazou: I see the parsing and the OM being independent
- # [18:59] <fantasai> dbaron: From an implementation perspective, there's a tricky issue here. Because the way the media query spec defines invalidity
- # [18:59] <fantasai> dbaron: An invalid query doesn't invalidate the list of queries, it only invalidates that particular query
- # [18:59] <fantasai> dbaron: And invalid queries are treated as false
- # [19:00] <fantasai> dbaron: You would need to record that there was some invalid thing that's false, so that when you remove the valid attributes you get false, not all
- # [19:01] <fantasai> glazou: If we say that an empty media list attached to the OM is equivalent to 'all' ...
- # [19:01] <fantasai> dbaron: The tricky thing is what is an empty media list
- # [19:01] <fantasai> dbaron: If you have an invalid media query as part of the media list, you have to keep track of that.
- # [19:02] <fantasai> dbaron: We implemented that the media query was not empty, and that's a permanent state: you can't remove everything through the OM
- # [19:02] <fantasai> dbaron thinks maybe he needs to write something up with examples
- # [19:02] <fantasai> glazou: Does this mean the error-handling rules of media queries make it impossible to handle a few cases
- # [19:03] <ChrisL> it sounds like the rules throw up an error state for no good reason
- # [19:03] <fantasai> glazou: It seems we may need to revisit the error-handling rules
- # [19:03] <fantasai> Sylvain: all is a sensical default for empty media lists
- # [19:03] <fantasai> peter: What happens if you then serialize the OM?
- # [19:04] <fantasai> Sylvain: Then you serialize as 'all'
- # [19:04] <fantasai> Sylvain: It's an edge case, but the spec should say something about it
- # [19:04] <fantasai> Sylvain: It would be nice to have it all in the sme place and have a suite of testcases
- # [19:04] <fantasai> dbaron: I think there's a relatively straightforward solution wrt error handling, and that's to replace any invalid queries with 'not all'.
- # [19:05] <dbaron> print, screen and (nonexistent-query), projection
- # [19:05] <dbaron> turns into
- # [19:05] <dbaron> print, not all, projection
- # [19:05] <dbaron> so that if somebody then does
- # [19:05] <dbaron> media.remove("print")
- # [19:05] <dbaron> media.remove("projection")
- # [19:05] <dbaron> you have 'not all'
- # [19:05] <dbaron> rather than an empty query that evaluates to 'all'
- # [19:05] * fantasai thought this was proposed earlier
- # [19:06] * fantasai is happy with it
- # [19:06] <fantasai> Bert: Why wouldn't you just ignore it?
- # [19:06] <fantasai> fantasai and glazou try to explain
- # [19:06] <fantasai> ACTION: dbaron and glazou Write a proposal
- # [19:06] * trackbot noticed an ACTION. Trying to create it.
- # [19:06] * RRSAgent records action 1
- # [19:06] <trackbot> Created ACTION-226 - And glazou Write a proposal [on David Baron - due 2010-05-05].
- # [19:07] <Zakim> -ChrisL
- # [19:07] <Zakim> -David_Baron
- # [19:07] <fantasai> Meeting closed.
- # [19:07] <Zakim> -smfr
- # [19:07] <Zakim> -SteveZ
- # [19:07] <Zakim> -[Microsoft]
- # [19:07] <Zakim> -glazou
- # [19:07] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
- # [19:07] <Zakim> -CesarAcebal
- # [19:07] <Zakim> -plinss
- # [19:07] <Zakim> -fantasai
- # [19:07] * Quits: ChrisL (ChrisL@128.30.52.169) (Client exited)
- # [19:07] <Zakim> -arronei
- # [19:07] <Zakim> -Bert
- # [19:07] * Quits: smfr (smfr@68.183.233.103) (Quit: smfr)
- # [19:08] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [19:09] <glazou> szilles: still here ?
- # [19:10] <glazou> apparently not
- # [19:12] <Zakim> disconnecting the lone participant, bradk, in Style_CSS FP()12:00PM
- # [19:12] <Zakim> Style_CSS FP()12:00PM has ended
- # [19:12] <Zakim> Attendees were +95089aaaa, glazou, plinss, SteveZ, +1.650.275.aabb, bradk, Bert, arronei, sylvaing, smfr, +34.60.940.aacc, CesarAcebal, +47.21.65.aadd, fantasai, howcome,
- # [19:12] <Zakim> ... David_Baron, ChrisL, Rossen_Atanassov
- # [19:13] * Quits: szilles (chatzilla@67.180.186.242) (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
- # [19:17] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
- # [19:18] * Quits: glazou (glazou@85.168.30.158) (Quit: glazou)
- # [19:21] * Quits: sylvaing (sylvaing@131.107.0.85) (Ping timeout)
- # [19:22] * Quits: TabAtkins_ (tabatkins@216.239.45.4) (Ping timeout)
- # [19:24] * Joins: TabAtkins_ (tabatkins@216.239.45.4)
- # [19:28] * Quits: oyvind (oyvinds@213.236.208.22) (Quit: oyvind)
- # [19:34] * Joins: dbaron (dbaron@63.245.220.240)
- # [19:39] * Quits: CesarAcebal (acebal@85.152.177.64) (Quit: CesarAcebal)
- # [19:58] * Joins: shepazu (schepers@128.30.52.169)
- # [20:01] * Quits: divya (divya@24.22.131.46) (Quit: divya)
- # [20:02] <Bert> rrsagent, draft minutes
- # [20:02] <RRSAgent> I have made the request to generate http://www.w3.org/2010/04/28-CSS-minutes.html Bert
- # [20:02] <Bert> rrsagent, make logs public
- # [20:02] <RRSAgent> I have made the request, Bert
- # [20:03] * Joins: divya (divya@24.22.131.46)
- # [20:03] * Quits: divya (divya@24.22.131.46) (Quit: divya)
- # [20:17] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
- # [20:31] * Joins: shepazu (schepers@128.30.52.169)
- # [20:31] * Quits: shepazu (schepers@128.30.52.169) (Client exited)
- # [20:31] * Joins: shepazu (schepers@128.30.52.169)
- # [20:32] * Zakim excuses himself; his presence no longer seems to be needed
- # [20:32] * Parts: Zakim (rrs-bridgg@128.30.52.169)
- # [20:49] * Joins: sylvaing (sylvaing@131.107.0.69)
- # [21:27] * Quits: sylvaing (sylvaing@131.107.0.69) (Ping timeout)
- # [21:35] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
- # [21:45] * Joins: sylvaing (sylvaing@131.107.0.87)
- # [22:20] * Joins: shepazu (schepers@128.30.52.169)
- # [22:30] * Quits: sylvaing (sylvaing@131.107.0.87) (Connection reset by peer)
- # [23:04] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
- # [23:05] * Joins: divya (divya@24.22.131.46)
- # [23:11] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
- # [23:21] * Joins: sylvaing (sylvaing@76.104.131.10)
- # [23:32] <divya> Does anyone know how/why the CSS namespaced SVG selector seems to work on this example HTML page without specifying the namespace on the inline SVG itself? http://dl.dropbox.com/u/952/namespaces/index.html (needs minefield)
- # [23:32] <divya> (and html5.enabled = true on about:config)
- # [23:47] * Quits: sylvaing (sylvaing@76.104.131.10) (Ping timeout)
- # Session Close: Thu Apr 29 00:00:00 2010
The end :)