/irc-logs / w3c / #css / 2012-02-07 / end

Options:

# Session Start: Tue Feb 07 00:00:00 2012
# Session Ident: #css
# [00:03] * Quits: jdaggett (jdaggett@81.56.65.178) (Quit: jdaggett)
# [00:06] * Quits: tantek (tantek@90.46.85.61) (Quit: tantek)
# [00:13] * Quits: nimbu (Adium@24.18.47.160) (Quit: Leaving.)
# [00:55] * Quits: TabAtkins_ (tabatkins@90.46.85.61) (Ping timeout)
# [00:58] * Quits: kojiishi (kojiishi@90.46.85.61) (Ping timeout)
# [01:03] * RRSAgent excuses himself; his presence no longer seems to be needed
# [01:03] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
# [02:30] * plinss is now known as plinss_away
# [02:41] * plinss_away is now known as plinss
# [02:47] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [03:01] * Joins: karl (karlcow@128.30.54.58)
# [03:24] * Joins: arron (Arron@24.17.123.244)
# [03:31] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [05:18] * Joins: jdaggett (jdaggett@81.56.65.178)
# [06:11] * Quits: ed (ed@88.131.66.80) (Ping timeout)
# [06:23] * Joins: ed (ed@88.131.66.80)
# [06:43] * plinss is now known as plinss_away
# [07:28] * Joins: arron (Arron@24.17.123.244)
# [07:34] * shans is now known as shans_away
# [07:43] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [08:02] * Joins: TabAtkins_ (tabatkins@90.46.85.61)
# [08:05] * Joins: tantek (tantek@90.46.85.61)
# [08:29] * Quits: jdaggett (jdaggett@81.56.65.178) (Quit: jdaggett)
# [08:30] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [08:30] <RRSAgent> logging to http://www.w3.org/2012/02/07-css-irc
# [08:33] * Joins: dbaron (dbaron@89.80.183.188)
# [08:33] * dbaron RRSAgent, pointer?
# [08:33] * RRSAgent See http://www.w3.org/2012/02/07-css-irc#T07-26-04
# [08:34] * dbaron RRSAgent, make logs public
# [08:34] * RRSAgent I have made the request, dbaron
# [08:34] * Quits: dbaron (dbaron@89.80.183.188) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [08:43] * Quits: TabAtkins_ (tabatkins@90.46.85.61) (Ping timeout)
# [08:45] * Quits: tantek (tantek@90.46.85.61) (Quit: tantek)
# [08:46] * Joins: glazou (glazou@128.93.135.193)
# [08:50] <glazou> test
# [08:50] <glazou> RRSAgent, make logs public
# [08:50] <RRSAgent> I have made the request, glazou
# [08:50] * plinss_away is now known as plinss
# [09:00] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
# [09:01] * plinss is now known as plinss_away
# [09:14] * Joins: glazou (glazou@128.93.135.193)
# [09:16] * plinss_away is now known as plinss
# [09:23] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [09:24] * Joins: kojiishi (kojiishi@128.93.135.158)
# [09:25] * Joins: dbaron (dbaron@128.93.135.77)
# [09:26] * Joins: jdaggett (jdaggett@128.93.135.115)
# [09:26] * jdaggett tries to wake up...
# [09:30] * Joins: TabAtkins_ (tabatkins@74.125.122.49)
# [09:32] * sylvaing_away is now known as sylvaing
# [09:33] <sylvaing> scribenick: sylvaing
# [09:33] * Joins: howcome (howcome@128.93.135.80)
# [09:33] * Joins: smfr (smfr@128.93.134.211)
# [09:33] <sylvaing> howcome: I think we agreed we want to achieve modern magazine designs
# [09:33] * Joins: vhardy_ (qw3birc@128.30.52.28)
# [09:33] <sylvaing> howcome: we disagree how to reach that goal
# [09:34] <sylvaing> howcome: I prefer a declarative approach
# [09:34] <sylvaing> howcome: others prefer a hybrid approach that involves script
# [09:34] * Joins: florian (florianr@128.93.135.177)
# [09:34] * Joins: tantek (tantek@128.93.135.10)
# [09:34] * Quits: dglazkov (u4270@88.198.6.68) (Ping timeout)
# [09:34] <sylvaing> steve: I thought we came out of the discussion thinking that we needed declarative as well as scripting
# [09:35] <TabAtkins_> q+
# [09:35] * Zakim sees TabAtkins_ on the speaker queue
# [09:35] * Joins: Rossen (Rossen@128.93.134.230)
# [09:35] * fantasai agrees 100% with howcome and Bert on this topic and has nothing more to say.
# [09:36] * Joins: antonp (805d8798@207.192.75.252)
# [09:36] * Joins: dglazkov (u4270@88.198.6.68)
# [09:37] <sylvaing> <successful re-enactment of yesterday's discussion>
# [09:37] * Quits: florian (florianr@128.93.135.177) (Quit: florian)
# [09:37] <sylvaing> tab: allowing the last region be auto-sized would help a lot
# [09:38] * Joins: alexmog_ (qw3birc@128.30.52.28)
# [09:38] <sylvaing> tab: being able to flow a region into a grid cell (which used to exist with ::slot) would also help
# [09:38] * Joins: florian (florianr@128.93.135.177)
# [09:38] <sylvaing> tab: with those two combined, a large number of these layouts would be possible
# [09:38] <alexmog_> q+
# [09:38] * Zakim sees TabAtkins_, alexmog_ on the speaker queue
# [09:38] <TabAtkins_> ack
# [09:38] <TabAtkins_> zakim, ack
# [09:39] <Zakim> I don't understand 'ack', TabAtkins_
# [09:39] <TabAtkins_> q-
# [09:39] * Zakim sees alexmog_ on the speaker queue
# [09:39] <sylvaing> vincent: the first one is something we have as an issue.
# [09:39] <sylvaing> vincent: we also talked about making multicol a region; in particular make the last region a multicol
# [09:39] <sylvaing> vincent: we'd also like to make a proposal for page templating
# [09:40] * Joins: jet (jet@128.93.134.233)
# [09:40] <sylvaing> rossen: our goal is to present a page template at the next f2f which would address basic region auto-generation needs
# [09:40] <sylvaing> rossen: so this would allow us to go back to the regions spec now and work on known issues
# [09:41] <sylvaing> alexmog: I think we generally disagree on the order of implementation
# [09:41] * Joins: tantek_ (tantek@128.93.135.73)
# [09:42] <sylvaing> howcome: my concern is that the first implementations coming out will force the creation of dummy divs through script
# [09:42] <sylvaing> alexmog: we only aim to enable implementation in this space and gather feedback
# [09:43] * Joins: ChrisL (ChrisL@128.30.52.169)
# [09:43] <sylvaing> alexmog: I'd like to discuss issues in the regions spec.
# [09:43] <tantek> the Microsoft implementation of regions is -ms- prefixed right?
# [09:43] * ChrisL maybe we should all implement the microsoft solution, but all with the -ms- prefix
# [09:43] <sylvaing> tantek, yes
# [09:44] <sylvaing> howcome: i think a page template spec is necessary
# [09:44] <sylvaing> howcome: regions and page templates should come together is necessary
# [09:44] <vhardy_> q+
# [09:44] * Zakim sees alexmog_, vhardy_ on the speaker queue
# [09:45] <plinss> ack
# [09:45] <alexmog_> q-
# [09:45] * Zakim sees vhardy_ on the speaker queue
# [09:46] <sylvaing> vincent: I see it as a two step process. if we do allow regions to be multicol elements I think it mixes well with your solution
# [09:46] <sylvaing> vincent: this provides a progression that doesn't require scripting
# [09:46] <plinss> ack vhardy_
# [09:46] * Zakim sees no one on the speaker queue
# [09:46] <sylvaing> tab: is there any reason why all regions couldn't be multicols?
# [09:46] <sylvaing> vincent: no
# [09:47] <sylvaing> alexmog: can we put region issues on the agenda?
# [09:48] <sylvaing> howcome: sure, i just don't want to make a general decision on whethe this is the right way forward until we have visibility into your general model
# [09:49] <sylvaing> vincent: as a way forward we'll submit a page template, add support for multicols and paged overflow
# [09:50] <sylvaing> vincent: at the f2f we can show something that's much more complete
# [09:50] <sylvaing> florian: that way we'll be able to compare complete solutions based on use-cases
# [09:51] <sylvaing> howcome: we should also look at Bert's proposal
# [09:51] <sylvaing> s/proposal/use-cases
# [09:52] <sylvaing> howcome: we need a set of use-cases to evaluate the various proposals
# [09:53] <sylvaing> jdaggett: I think it would also be useful to share presentation material like this on www-style in advance so as to gather feedback from a wider group
# [09:53] <Bert> q+ to give example of what looking at a complete example can give
# [09:53] * Zakim sees Bert on the speaker queue
# [09:54] <sylvaing> rossen: valid feedback, thank you
# [09:55] <sylvaing> ACTION: vhardy Draft a page template proposal for the May f2f
# [09:55] * trackbot noticed an ACTION. Trying to create it.
# [09:55] * RRSAgent records action 1
# [09:55] <trackbot> Created ACTION-422 - Draft a page template proposal for the May f2f [on Vincent Hardy - due 2012-02-14].
# [09:56] <sylvaing> TOPIC: Regions issues
# [09:58] <dbaron> vhardy: Should I put it on dev.w3.org?
# [09:58] <sylvaing> Bert: region styling using @-rule is different from pseudo-element styling and creates inconsistencies
# [09:58] <dbaron> daniel: of course; we have things there that aren't even in the charter; I won't entertain objections to that
# [09:59] * Joins: astearns (qw3birc@128.30.52.28)
# [09:59] <sylvaing> vincent: there was feedback at the last meeting on the way we presented issues and I wanted to start by showing how we dealt with that
# [09:59] <sylvaing> vincent projects css3-regions ED
# [09:59] <sylvaing> vincent: we're filing all the spec issues in Bugzilla
# [10:00] <sylvaing> vincent: before then we only had issue markers in the spec
# [10:00] <sylvaing> vincent: now all the issues in the spec link back to bugzilla, and the short description is shown in the margin
# [10:02] <sylvaing> vincent: this is done in a scripted manner and matches them with the spec and appends them a report at the end of the spec. it lets you know whether new issues are not marked in the spec. this helps editing.
# [10:05] <sylvaing> vincent: let me know how to make it more useful
# [10:05] <dbaron> I didn't follow what the buttons at the bottom were supposed to do.
# [10:05] <ChrisL> inline bug links in the spec are very useful
# [10:05] <ChrisL> tools better in a subdirectory instead of littering the root
# [10:05] <sylvaing> ACTION: vhardy Create a shared directory to post the bug helper script and document it on the wiki
# [10:05] * RRSAgent records action 2
# [10:05] * trackbot noticed an ACTION. Trying to create it.
# [10:05] <trackbot> Created ACTION-423 - Create a shared directory to post the bug helper script and document it on the wiki [on Vincent Hardy - due 2012-02-14].
# [10:07] <sylvaing> first bug was https://www.w3.org/Bugs/Public/show_bug.cgi?id=15159 to add use-cases
# [10:07] <sylvaing> we've done that
# [10:07] <sylvaing> http://wiki.csswg.org/spec/css3-regions/regions-use-cases
# [10:08] <sylvaing> howcome: in addition to the CSS and HTML, it'd be useful to see any script that is needed to flow in more content
# [10:09] <sylvaing> howcome: do you encourage others to add more to the wiki page?
# [10:09] <sylvaing> vincent: yes
# [10:10] <sylvaing> ACTION: vhardy make a generic use-case page linking to proposed markup solutions
# [10:10] * RRSAgent records action 3
# [10:10] * trackbot noticed an ACTION. Trying to create it.
# [10:10] <trackbot> Created ACTION-424 - Make a generic use-case page linking to proposed markup solutions [on Vincent Hardy - due 2012-02-14].
# [10:10] <sylvaing> RESOLVED bug 15159 is closed
# [10:11] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15733
# [10:11] * Joins: szilles (chatzilla@128.93.134.251)
# [10:11] <sylvaing> vincent: this is about creating regions declaratively
# [10:11] <sylvaing> howcome: let's close it once there is a proposal
# [10:12] <sylvaing> vincent: this will be solved in the template proposal
# [10:12] <sylvaing> vincent: we'll update the bug to reference the pending action
# [10:13] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15131
# [10:14] <sylvaing> vincent: originally the spec had a section on how regions integrated with different layout systems since regions don't create layout. this was taken out
# [10:14] <sylvaing> vincent: then we explained how a region could be selected or created but this was not to be covered in the spec
# [10:15] <sylvaing> vincent: but we were left with this example and we were asked to update it
# [10:16] <sylvaing> vincent: the goal should be to indicate there is an overflow area and that should be item 4 in Figure 1
# [10:17] <sylvaing> vincent: the point of the example is to show there is a catch-all area
# [10:17] <sylvaing> ACTION: vhardy Make item 4 a multicolumn overflow
# [10:17] * RRSAgent records action 4
# [10:17] * trackbot noticed an ACTION. Trying to create it.
# [10:17] <trackbot> Created ACTION-425 - Make item 4 a multicolumn overflow [on Vincent Hardy - due 2012-02-14].
# [10:18] <sylvaing> howcome: <creep-laugh type="evil">
# [10:20] <sylvaing> vincent: Bug 15186 is about auto-generation and is to be revisited with future proposals. Same for 15187.
# [10:21] <Bert> (The example of 15131 doesn't really add a layout-based solution, does it? I still see empty HTML elements...)
# [10:21] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15811
# [10:21] <sylvaing> alexmog: we are not proposing to flow content from external resources at the moment
# [10:22] <ChrisL> q+
# [10:22] * Zakim sees Bert, ChrisL on the speaker queue
# [10:22] <Bert> q-
# [10:22] * Zakim sees ChrisL on the speaker queue
# [10:22] <sylvaing> alexmog: providing flow from external resources could be out of scope, or the Regions spec shouldn't restrict the origin of a resource
# [10:23] <sylvaing> ChrisL: I don't think it should be out of scope since the alternative would be to write script to pull in content
# [10:23] <sylvaing> alexmog: out of scope may be the wrong term
# [10:24] <dbaron> q+
# [10:24] * Zakim sees ChrisL, dbaron on the speaker queue
# [10:24] <sylvaing> alexmog: can regions assume that every element or node comes from the same origin?
# [10:24] <plinss> ack next
# [10:24] * Zakim sees ChrisL at the head of the speaker queue
# [10:24] * Zakim sees dbaron on the speaker queue
# [10:24] <sylvaing> alexmog: I think it's useful to assume it but it is limiting
# [10:25] * Bert thinks flowing <iframe seamless data="foo.html"> into a chain of regions would be cool...
# [10:25] <sylvaing> dbaron: given the seamless iframes feature of HTLM5, I'm not sure how much this matters
# [10:25] <plinss> ack next
# [10:25] * Zakim sees dbaron at the head of the speaker queue
# [10:25] * Zakim sees no one on the speaker queue
# [10:25] <sylvaing> dbaron: if you assume you have seamless iframes then you don't need features in CSS
# [10:25] <ChrisL> is there a benefit to assuming that all the nodes are in the same document?
# [10:25] * Bert put suspects that <iframe> will be a rectangle, like other replaced elts.
# [10:25] <ChrisL> alex: yes, you can determine element order
# [10:26] <dbaron> ack dbaron
# [10:26] * Zakim sees no one on the speaker queue
# [10:26] <sylvaing> alexmog: but we want to allow indirection into a different document without changing the style of this document
# [10:26] <sylvaing> alexmog: seamless iframes does not have that option
# [10:26] <sylvaing> alexmog: I have a options on the wiki but I am not yet ready to commit to any of them
# [10:27] * Parts: florian (florianr@128.93.135.177)
# [10:27] <sylvaing> http://wiki.csswg.org/spec/css3-regions#issue-24creating-a-named-flow-from-external-resource
# [10:27] <dbaron> TabAtkins: there are security concerns with integrating iframes and, e.g., determining the height of the contents, without using the mechanisms in seamless iframes
# [10:27] <vhardy_> http://wiki.csswg.org/spec/css3-regions#issue-24creating-a-named-flow-from-external-resource
# [10:28] * Joins: florian (florianr@128.93.135.177)
# [10:29] <sylvaing> alexmog: one option involves using an iframe element; another uses a separate property; a third uses a flow rule. we can discuss these but work remains to evaluate the solutions as well as understand seamless iframes
# [10:29] <sylvaing> tabatkins: this should be discussed on www-style as there are issues with it
# [10:29] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
# [10:29] <sylvaing> alexmog: the Regions spec should note that the content of a named flow may come from another document
# [10:29] <sylvaing> vincent: should we retitle the bug?
# [10:30] <glazou> break time at 10:45am
# [10:30] <sylvaing> vincent: we can note in the spec that the current version assumes the content comes from the same document pointing to an issue to resolve it later
# [10:31] <glazou> TabAtkins_: selectors 4 after the break ?
# [10:31] <TabAtkins_> glazou: I'm okay with that. Check with fantasai, since I think it's generally her topic.
# [10:32] <sylvaing> Bert: this is not really a Regions issue but a general question of whether we can have replaced elements that are reflowing
# [10:32] <sylvaing> vincent: how do we deal with this issue?
# [10:33] <sylvaing> bert: put it on the agenda
# [10:33] <glazou> fantasai: ok with that ?
# [10:34] <sylvaing> ACTION: alexmog to rework 15811 as a general issue of replaced content and flow
# [10:34] * trackbot noticed an ACTION. Trying to create it.
# [10:34] <trackbot> Sorry, couldn't find user - alexmog
# [10:34] * RRSAgent records action 5
# [10:35] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15858
# [10:36] <sylvaing> vincent: the spec identifies the ICB for elements in regions
# [10:36] <sylvaing> vincent: the defintiion was modeled on the page spec which uses the first page
# [10:36] <sylvaing> vincent: based on use-cases involving a page preview we thought of using the first region as the ICB for the flowed content
# [10:37] <sylvaing> vincent: feedback has been that this may not be always useful, and that the normal ICB should be used
# [10:37] <sylvaing> vincent: we can also keep what we have
# [10:37] <sylvaing> vincent: or we can provide a switch
# [10:38] <sylvaing> alexmog: this is also relates to regions' interaction with stacking contexts
# [10:38] <plinss> q?
# [10:38] * Zakim sees no one on the speaker queue
# [10:39] <sylvaing> alexmog: if you model regions based on columns then they're not containing blocks for absolutely positoned elements
# [10:39] <Bert> q+ to mention that the 'gr' units seems enough in my experiments.
# [10:39] * Zakim sees Bert on the speaker queue
# [10:39] <sylvaing> anton: it's difficult to understand when you'll want to position within a region or within the wider document. a switch may be too hard to understand
# [10:40] <sylvaing> plinss: from past feedback, we may want to be able to declare something to be a containing block
# [10:41] <sylvaing> plinss: i like having a switch to control whether an element positions relative to the ICB but it shouldn't be region-specific. It should be in css3-break and apply to pages and maybe columns
# [10:41] <sylvaing> vincent: so regions should not discuss this at all
# [10:42] <sylvaing> ACTION: vhardy to move the issue to css3-break and remove the text from Regions
# [10:42] * trackbot noticed an ACTION. Trying to create it.
# [10:42] * RRSAgent records action 6
# [10:42] <trackbot> Created ACTION-426 - Move the issue to css3-break and remove the text from Regions [on Vincent Hardy - due 2012-02-14].
# [10:42] <sylvaing> Bert: I've found tha the gr unit should be enough to position objects independently of their containing block
# [10:43] <sylvaing> steve: if you're simulating multicolumns or something like it, you need a different mechanism
# [10:44] <sylvaing> alexmog: you may want positioned elements in your flow to start in a region and cover the next one, you don't want to be constrained by your container or its stacking context.
# [10:46] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15116
# [10:46] <sylvaing> vincent: I don't have a proposal yet.
# [10:46] <sylvaing> ACTION: vhardy to update region styling
# [10:46] * trackbot noticed an ACTION. Trying to create it.
# [10:46] * RRSAgent records action 7
# [10:46] <trackbot> Created ACTION-427 - Update region styling [on Vincent Hardy - due 2012-02-14].
# [10:48] <sylvaing> bert: there might potential confusion between styling the region itself and styling on the elements that end up in a region.
# [10:50] <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15828
# [10:50] <fantasai> glazou: would prefer css3-background / css3-text, save selectors 4 for tomorrow. Or later. I think I need more time to collect my thoughts and dig up examples from www-style
# [10:51] <sylvaing> we were missing properties in the CSSOM
# [10:51] <Bert> (If the div defines a grid and has a child p, then 'div::slot(a) {background: red}' sets a bg on the region, while 'p::slot(a) {background: yellow}' sets a bg only on the part of the p that ends up inside that region.)
# [10:51] <sylvaing> we added a way to retrive flows by name and return a collection of existing named flows
# [10:51] <sylvaing> (previous two comments by vincent)
# [10:51] <glazou> fantasai: I want to have a chance to give my opinion on Tab's Hierarchies during this ftf
# [10:52] <sylvaing> tabatkins: I'll suggest a different interface
# [10:52] <sylvaing> glazou: <break>
# [10:52] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
# [11:05] * Joins: glazou (glazou@128.93.135.193)
# [11:05] * sylvaing is now known as sylvaing_away
# [11:09] * sylvaing_away is now known as sylvaing
# [11:12] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
# [11:12] * Quits: jet (jet@128.93.134.233) (Ping timeout)
# [11:15] <fantasai> Scribe: fantasai
# [11:15] <vhardy_> ScribeNick: vhardy
# [11:15] <fantasai> Topic: Nesting Style Rules
# [11:15] <TabAtkins_> http://dev.w3.org/csswg/css3-hierarchies/
# [11:15] <glazou> http://dev.w3.org/csswg/css3-hierarchies/
# [11:16] * Joins: Rossen (Rossen@128.93.134.230)
# [11:16] <vhardy_> daniel: i want to discuss this because people discovered the document and started to discuss it as if it was a wg draft. I modified it.
# [11:16] <vhardy_> ... it is a modification of the grammar. Technically, it is not in the charter.
# [11:16] <vhardy_> ... it is about nesting rules and reconstructing the selector based on the parent rule.
# [11:16] <vhardy_> ... the goal is to simplify the selector of the children rules. This has been requested for a long time.
# [11:17] <vhardy_> ... I have a lot of issues and questions.
# [11:17] <vhardy_> ... first the OM. Not enough. Selector text on the style rule is not enough.
# [11:18] <vhardy_> ... selector text is not meaningful, you need to reconstruct looking at the parent style rules.
# [11:18] <vhardy_> tab: right now, there is only the nested selector. WOuld be more useful if we provided the expanded the selector, including the parent selectors.
# [11:18] <vhardy_> peter: if you are going to change that, add an attribute to only get the local selector text.
# [11:19] <vhardy_> daniel: there is a way to navigate the children rules from the parent rule, but not from the children rules to the parent rules.
# [11:19] <vhardy_> tab: we are following media queries.
# [11:19] <vhardy_> daniel: you do not say so.
# [11:19] * Quits: howcome (howcome@128.93.135.80) (Ping timeout)
# [11:19] <vhardy_> tab: we are going to say we follow the structure of the @media rules. If something is missing, we will fix both of them.
# [11:19] <vhardy_> daniel: I have a problem with example #5.
# [11:20] <vhardy_> .... the third nested 'thing' have a rule followed by a declaration followed by a rule. This is an issue in the OM, becaues the declaration is stored in one 'thing' and nested rules are in another. Order cannot be maintained.
# [11:20] <vhardy_> tab: I agree you should put your properties first.
# [11:20] <vhardy_> daniel: the order should be mandatory.
# [11:21] <vhardy_> tab: seems fine.
# [11:21] <vhardy_> florian: I noted that the nested things last rather than first works better. That is where they should be if mandatory.
# [11:22] <vhardy_> daniel: you are using the &. That could be an issue for embeded stylesheets because of encoding rules.
# [11:22] <vhardy_> tab: not a problem in HTML.
# [11:22] <vhardy_> daniel: I do not like the & because there are people will forget to use &
# [11:22] <vhardy_> ... I think we should discourage that. I think this is a problem.
# [11:22] <vhardy_> tab: Ok, I'll look for a replacement.
# [11:23] <vhardy_> daniel: editability is a problem. When an editor needs to add a stylerule, you can look for a stylerule with the same selector. With nesting, it is way more complicated. You need to look for a nested style rules as well. It complexifies.
# [11:23] <vhardy_> tab: if you have the full selector, does that simplify your work?
# [11:24] * Joins: jet (jet@128.93.134.233)
# [11:24] <vhardy_> daniel: when you insert a rule, you have to look for all the rules that have an effect in the cascade and modify them.
# [11:24] <vhardy_> ... I understand this is an important request from the user community, but I would like a clear issue created about editability.
# [11:24] <vhardy_> .... for example, what will happen to legacy browsers.
# [11:25] <vhardy_> tab: they will ignore the nested selectors.
# [11:25] <vhardy_> daniel: will that be used?
# [11:25] <vhardy_> tab: people love that feature.
# [11:26] <vhardy_> jdagget: for things where we have not really taken on a module, could we have a clear marker, something that says this is a 'proposal', not an editor draft.
# [11:26] <vhardy_> tab: yes, that is fine.
# [11:26] <vhardy_> jdagget: the word 'proposal would be ok.
# [11:26] <vhardy_> tab, others: ok.
# [11:26] <vhardy_> steve: moving from proposal to ED is an action of the wg.
# [11:26] <vhardy_> all: yes.
# [11:26] <vhardy_> jdagget: I think this is better to have it here than on someone's blog.
# [11:27] <vhardy_> ... should be a proposal until the group takes it on.
# [11:27] <vhardy_> chris: I did not quite understand the 'expand' the selector thing.
# [11:27] <glazou> http://dev.w3.org/csswg/css3-hierarchies/#nesting-selector
# [11:28] <vhardy_> tab: yes, you have the entire selector.
# [11:28] <vhardy_> chris: then it is duplicated.
# [11:29] <vhardy_> tab: we are talking about selector text in the OM, not in the stylesheet. What is editable is still the short form.
# [11:29] * Joins: alexmog__ (qw3birc@128.30.52.28)
# [11:29] <ChrisL> example 4
# [11:29] <ChrisL> div, p {
# [11:29] <ChrisL> & .keyword, & .constant {color: red;}
# [11:29] <ChrisL> }
# [11:30] <ChrisL> is same as
# [11:30] <ChrisL> div .keyword {color:red;}
# [11:30] <ChrisL> div .constant {color:red;}
# [11:30] <ChrisL> p .keyword {color:red;}
# [11:30] <ChrisL> p .constant {color:red;}
# [11:30] <vhardy_> daniel: In example 4, I would like a change. The parent rule has a group of selectors. The nested rule has a group of selector, if one of the selectors is invalid, the whole is invalid. So use groups in the expanded version of the example.
# [11:30] * Quits: tantek (tantek@128.93.135.10) (Ping timeout)
# [11:30] <vhardy_> tab: changing the example right now.
# [11:30] * Quits: tantek_ (tantek@128.93.135.73) (Ping timeout)
# [11:30] <vhardy_> daniel: I have a suggestion for editability.
# [11:31] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
# [11:34] <vhardy_> ... if you set the selector text, the implementation will need to match with as many parent selectors as possible to compute part of the selector only, and set that part of not. If it fails to compute the parent selector, it will throw an error. This is required, because the selector text is writable.
# [11:35] <vhardy_> jdaggett: one way to implement it, then we could do it a parse time only thing.
# [11:35] <vhardy_> (discussion about how this would be the same as the current server side solutions).
# [11:35] <vhardy_> jdaggett: but it would make it easier to manipulate.
# [11:35] <vhardy_> daniel: I do not think this is something we can _not_ do.
# [11:36] <vhardy_> dbaron: I am not happy about the selector text expansion.
# [11:36] <vhardy_> ... it seems a bit lossy in that you might want the thing with the &, it will be hard to get that.
# [11:36] <vhardy_> daniel: the part with the & is the selector text of the parent rule.
# [11:36] <vhardy_> dbaron: no, the local part.
# [11:36] <vhardy_> (all) we are introducing a way to get the local part.
# [11:37] <vhardy_> dbaron: one advantage of making the new one expanded is that we can make it read-only.
# [11:37] <vhardy_> daniel: I do not have a strong opinion, either way.
# [11:37] <vhardy_> ... I just need both for reading and oupting.
# [11:38] <vhardy_> ... to compute the style, I need both.
# [11:38] <vhardy_> ... for writing I only need the local part.
# [11:38] <vhardy_> ... with that, I think editors can work with such a specification, it is doable.
# [11:38] <vhardy_> ... this said, the question is, do we want to work on this?
# [11:38] <vhardy_> ... do we have CSS grammar in the charter for the next 3 years.
# [11:39] <vhardy_> tab: we have other specs, that will modify the grammar or tweak it.
# [11:39] <vhardy_> ... CSS conditionals will do that for example.
# [11:39] <vhardy_> daniel: section 2 of the charter says that CSS syntax is discontinued.
# [11:39] <vhardy_> chris: this just means that draft is not further developed.
# [11:40] <vhardy_> daniel: if we want to work on that, we have to find a landing spot in the existing charter deliverables or extand the charter.
# [11:40] <vhardy_> chris: or we can fit in the existing charter.
# [11:40] <vhardy_> ... syntax is in the scope section, so we are fine.
# [11:40] <vhardy_> daniel: I needed to check that.
# [11:40] <vhardy_> jdagget: the bigger question is the priority.
# [11:41] <vhardy_> ... it is possibly disruptive. There are a lot of things to work out.
# [11:41] <vhardy_> daniel: this is the kind of item that the author community is looking for.
# [11:41] <vhardy_> tab: error recovery rules are working nicely here.
# [11:41] <vhardy_> jdagget: this has a non trivial cost. We already have a lot that we need to get done.
# [11:42] <vhardy_> chris: yes, we have a priority list already.
# [11:42] <vhardy_> ... the important question is the relative priority.
# [11:42] <vhardy_> peter: is there interest from implementors to implement this.
# [11:42] <vhardy_> ... if there is only one implementor, then we will not get to REC.
# [11:43] <vhardy_> florian: from an Opera point of view, I can easily see how people want that, but it is not at the top of our priority list.
# [11:43] <vhardy_> vhardy: we think this is an important feature for web authors.
# [11:44] <vhardy_> sylvain: no plans right now.
# [11:44] <vhardy_> dbaron: there is a bunch of other things that are higher priorities.
# [11:44] <vhardy_> sylvain: selector 4 is more important.
# [11:46] <vhardy_> daniel: I think it is clear there will not be commitment from the wg members to work on this right now.
# [11:46] <vhardy_> peter: do we want to keep this on the shelve as a proposal or do we take it as a WD?
# [11:46] <vhardy_> jdagget: I think we should keep it as a proposal and ask Tab to mark it as a proposal.
# [11:47] * jdaggett vhardy_: two t's please… jdaggett
# [11:47] <vhardy_> vhardy: what are the more important things?
# [11:47] <vhardy_> ACTION: Tab to mark the nested selector spec. as a proposal.
# [11:47] * trackbot noticed an ACTION. Trying to create it.
# [11:47] * RRSAgent records action 8
# [11:47] <trackbot> Created ACTION-428 - Mark the nested selector spec. as a proposal. [on Tab Atkins Jr. - due 2012-02-14].
# [11:48] * Joins: tantek (tantek@128.93.135.73)
# [11:49] <vhardy_> vhardy: from the feedback we get, nested selectors, mixins and variables are really important.
# [11:52] * Joins: tantek_ (tantek@128.93.135.10)
# [11:52] * Quits: tantek_ (tantek@128.93.135.10) (Quit: tantek_)
# [11:54] * Joins: tantek_ (tantek@128.93.135.10)
# [11:54] * Joins: howcome (howcome@128.93.135.80)
# [11:54] <fantasai> http://dev.w3.org/csswg/css-line-grid/
# [12:00] <vhardy_> Topic: Fullscreen
# [12:01] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2012Feb/0004.html
# [12:02] <vhardy_> daniel: Art is asking if we have comments / objections to Web apps working on this.
# [12:02] <vhardy_> chris: I think it should be in web apps.
# [12:02] <vhardy_> tantek: there are presentation aspects, right?
# [12:02] <vhardy_> daniel: yes, there are presentation side effects.
# [12:02] <vhardy_> ... but it is mainly an API.
# [12:03] <vhardy_> tantek: this is already in our charter. Art is asking to propose it for their Web apps charter. Why the extra work to put it in the web apps group.
# [12:03] <vhardy_> chris: Anne is willing to do it in the web apps group and he is a member there.
# [12:03] <vhardy_> daniel: there is, in our charter, to do full screen only for CSS, not in general.
# [12:03] <vhardy_> ... it is not limited to css.
# [12:03] <vhardy_> fantasai: then it should be a joined effort.
# [12:04] <vhardy_> daniel: yes, the css part we do, the api they do.
# [12:04] <fantasai> s/joined/joint/
# [12:04] <vhardy_> chris: while we are talking about this type of cooperation, it strikes me that the CSS OM is that something that should be done as a joint effort between the two groups.
# [12:04] * Joins: CGI232 (805d87e1@128.30.52.43)
# [12:05] <vhardy_> tantek: I think we have broader dissipation in this group from different companies. From an early exposure to commit patent ip, this group is better than the Web apps group, seeing what happened with touch events.
# [12:05] * sylvaing is now known as sylvaing_away
# [12:05] <vhardy_> ... css wg is better than web apps in that way.
# [12:05] <vhardy_> ... so the work should be done here.
# [12:06] <vhardy_> tantek: the web apps wg does not have as many companies, so if the work is done in the CSS wg, we stand a better chance to get disclosures/exclusions sooner than later.
# [12:06] <vhardy_> ... touch events has been blocked by a patent from Apple.
# [12:06] <vhardy_> ... since they are not in the web apps working group, they could do that.
# [12:06] <vhardy_> tantek: so it is better to do this work, from an IP point of view, in the CSSWG.
# [12:07] <vhardy_> florian: what are the implications of joint work?
# [12:07] <vhardy_> chris: the union of the membership of both groups has the same disclosure obligations over the entire spec.
# [12:07] <vhardy_> tantek: I have not problem co-editing with Anne.
# [12:08] <vhardy_> s/not/no
# [12:08] <vhardy_> daniel: my next question: does the group feel taht the argument tantek give about size and IPr rule are the arguments I should present to Art?
# [12:08] <vhardy_> florian: working jointly is the option we should present.
# [12:09] <vhardy_> bert: the argument about members is not strong, because they have Apple and they have companies that we do not have.
# [12:10] <vhardy_> tantek: for example, Flash has a fullscreen API and Adobe is not a member of the Web Apps wg.
# [12:10] <vhardy_> peter: I agree with you, but if you are trying to bring everybody under the tent, then you may force someone out of the tent. This is a risk.
# [12:11] <vhardy_> florian: however, full screen is already in the charter.
# [12:11] <vhardy_> tantek: but hte disclosure requirements happen at FPWD time.
# [12:11] <vhardy_> daniel: so we will propose for a joint effort?
# [12:12] <vhardy_> ACTION: daniel to answer Art about joint work between CSS and Web Apps WG on fullscreen CSS and APIs.
# [12:12] * trackbot noticed an ACTION. Trying to create it.
# [12:12] <trackbot> Sorry, amibiguous username (more than one match) - daniel
# [12:12] <trackbot> Try using a different identifier, such as family name or username (eg. dglazman, dweck2)
# [12:12] * RRSAgent records action 9
# [12:13] <vhardy_> Topic: Schedule for Snapshot 2012: end or start of the year?
# [12:13] <vhardy_> peter: last time we discussed it, we said we would do a snapshot every year.
# [12:14] <vhardy_> bert: is that what worked before 2012 or starting 2012?
# [12:14] <vhardy_> chris: if you publish at the end of 2012, then people think they are dealing with an old spec.
# [12:14] <vhardy_> fantasai: we can publish at any point, but the question, is, do we expect to add things to the snapshot (and have test suite).
# [12:15] <vhardy_> .. I thinjk we are just going to republish with a new date.
# [12:15] <vhardy_> s/thinjk/think
# [12:15] <vhardy_> dbaron: 2d transform could be there.
# [12:15] <vhardy_> peter: media queries.
# [12:15] <vhardy_> tab: images will have a test suite.
# [12:16] <vhardy_> fantasai: we also need at least an implementation that passes most of the testsuite and failures understood.
# [12:16] <vhardy_> chris: this is still a prediction: we expect things to get out of CR soon.
# [12:16] <vhardy_> fantasai: yes, e.g., MQ made it because we understood the failures and there was a test suite and implementation.
# [12:16] <vhardy_> chris: if the point is to publish one every year, then we would sometimes republish the same thing.
# [12:17] <vhardy_> peter: we should publish at least once a year. We may publish several times a year.
# [12:17] <vhardy_> ... it is just a note about the current state of the world and we update as necessary but at least once a yaer.
# [12:18] <vhardy_> steve: we need to indicate some level of stability, but publishing a new number if there is no changes is not useful.
# [12:18] <vhardy_> peter: i think there is a benefit.
# [12:18] <vhardy_> ... if there isn't one that is current, which one do you look at?
# [12:18] <vhardy_> steve: the most recent one.
# [12:19] <vhardy_> peter: this is the problem with open type projects. If something is not updated, you do not know if this is because people did not publish the update or because nothing is happening. This has value.
# [12:19] <vhardy_> steve: ok, understood.
# [12:19] <vhardy_> peter: so I would like to publish snapshot 2012 asap and we will republish immediately if new things are eligible.
# [12:19] <vhardy_> bert: I think that is too often.
# [12:20] <vhardy_> ... publishing often seems unstable.
# [12:20] <vhardy_> chris: we need to communicate that the stability state has changed.
# [12:20] <vhardy_> bert: ... people can wait 6 months.
# [12:21] <vhardy_> chris: we give people a short spec. that says what is stable.
# [12:21] <vhardy_> peter: the snapshot is a note, it is easy to publish. It is for communication.
# [12:21] <vhardy_> tantek: I think we should update the snapshot everytime a spec. goes to CR.
# [12:22] <vhardy_> several: that is not the criteria, the criteria is that the spec. is almost ready to exit CR.
# [12:22] <vhardy_> steve: once a year is fine.
# [12:22] <vhardy_> tantek: I propose to publish at the begining of the year.
# [12:22] <vhardy_> several: yes.
# [12:24] <vhardy_> RESOLUTION: the CSS snapshot will be published once a year, at the begining of the year, and every time a new specification meets the criteria for being listed in the snapshot note.
# [12:24] <vhardy_> ACTION: Fantasai to publish snapshot 2012 ASAP>
# [12:24] * RRSAgent records action 10
# [12:24] * trackbot noticed an ACTION. Trying to create it.
# [12:24] <trackbot> Created ACTION-429 - Publish snapshot 2012 ASAP> [on Elika Etemad - due 2012-02-14].
# [12:25] <vhardy_> Topic: Media Queries REC http://lists.w3.org/Archives/Public/public-css-testsuite/2012Jan/0001.html
# [12:27] <vhardy_> fantasai: we need an implementation report.
# [12:27] <vhardy_> florian: what is the status of the test suite?
# [12:27] <vhardy_> peter: it was being reworked.
# [12:27] <vhardy_> fantasai: that does not make the tests invalid.
# [12:27] <vhardy_> chris: this is a case of what you use for generating the report.
# [12:27] <vhardy_> (history of the test suite and who contributed).
# [12:28] <vhardy_> peter: the test suite has sufficient coverage of the spec?
# [12:28] <dbaron> http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/
# [12:29] <ChrisL> http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/
# [12:29] <vhardy_> dbaron: I think we need to publish a new snapshot of the test suite.
# [12:29] <vhardy_> ACTION: fantasai to publish a new snapshot of the MQ test suite.
# [12:29] * trackbot noticed an ACTION. Trying to create it.
# [12:29] * RRSAgent records action 11
# [12:29] <trackbot> Created ACTION-430 - Publish a new snapshot of the MQ test suite. [on Elika Etemad - due 2012-02-14].
# [12:30] <plinss> MQ test suite source: http://hg.csswg.org/test/file/tip/contributors/anne/submitted/mediaqueries
# [12:31] <vhardy_> daniel: implementation reports by?
# [12:31] <vhardy_> Mozilla, Opera
# [12:32] <vhardy_> ACTION: dbaron to provide an implementation report for the MQ test suite.
# [12:32] * RRSAgent records action 12
# [12:32] * trackbot noticed an ACTION. Trying to create it.
# [12:32] <trackbot> Created ACTION-431 - Provide an implementation report for the MQ test suite. [on David Baron - due 2012-02-14].
# [12:32] <vhardy_> ACTION: florian to provide an implementation report for the MQ test suite.
# [12:32] * trackbot noticed an ACTION. Trying to create it.
# [12:32] * RRSAgent records action 13
# [12:32] <trackbot> Created ACTION-432 - Provide an implementation report for the MQ test suite. [on Florian Rivoal - due 2012-02-14].
# [12:33] <ChrisL> testing Opera.next Version
# [12:33] <ChrisL> 12.00 alpha
# [12:33] <ChrisL> Build
# [12:33] <ChrisL> 1272
# [12:34] <ChrisL> Passed: 254
# [12:34] <ChrisL> Failed: 107
# [12:35] <vhardy_> ACTION: smfr to provide an implementation report for the MQ test suite.
# [12:35] * RRSAgent records action 14
# [12:35] * trackbot noticed an ACTION. Trying to create it.
# [12:35] <trackbot> Created ACTION-433 - Provide an implementation report for the MQ test suite. [on Simon Fraser - due 2012-02-14].
# [12:37] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
# [12:37] <vhardy_> ===== LUNCH BREAK ======
# [12:37] * Quits: jdaggett (jdaggett@128.93.135.115) (Quit: jdaggett)
# [12:37] * Quits: jet (jet@128.93.134.233) (Quit: jet)
# [12:40] * Quits: vhardy_ (qw3birc@128.30.52.28) (Ping timeout)
# [12:40] * Quits: szilles (chatzilla@128.93.134.251) (Ping timeout)
# [12:40] * Quits: smfr (smfr@128.93.134.211) (Quit: smfr)
# [12:41] * Joins: Ms2ger (Ms2ger@94.224.25.87)
# [12:42] * plinss is now known as plinss_away
# [12:42] * Quits: tantek_ (tantek@128.93.135.10) (Quit: tantek_)
# [12:42] * Joins: lhnz (lhnz@188.223.83.48)
# [12:43] * Quits: tantek (tantek@128.93.135.73) (Quit: tantek)
# [12:43] * Quits: howcome (howcome@128.93.135.80) (Ping timeout)
# [12:43] * Quits: TabAtkins_ (tabatkins@74.125.122.49) (Ping timeout)
# [12:43] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
# [12:44] * Quits: dbaron (dbaron@128.93.135.77) (Ping timeout)
# [12:45] * Quits: lhnz (lhnz@188.223.83.48) (Quit: Leaving)
# [13:09] * Quits: Ms2ger (Ms2ger@94.224.25.87) (Ping timeout)
# [13:15] * Joins: Ms2ger (Ms2ger@94.224.25.87)
# [13:21] * sylvaing_away is now known as sylvaing
# [13:23] * Quits: Ms2ger (Ms2ger@94.224.25.87) (Ping timeout)
# [13:24] * Joins: Ms2ger (Ms2ger@94.224.25.87)
# [13:24] * Zakim excuses himself; his presence no longer seems to be needed
# [13:24] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [13:28] * Quits: Ms2ger (Ms2ger@94.224.25.87) (Quit: Leaving)
# [13:44] * Joins: jdaggett (jdaggett@128.93.135.115)
# [14:11] * Joins: smfr (smfr@128.93.134.211)
# [14:14] * Joins: tantek (tantek@128.93.135.10)
# [14:15] * plinss_away is now known as plinss
# [14:17] <smfr> http://wiki.csswg.org/planning/paris-2012
# [14:17] * Joins: tantek_ (tantek@128.93.135.73)
# [14:17] * Joins: glazou (glazou@128.93.135.193)
# [14:17] * Joins: dbaron (dbaron@128.93.135.77)
# [14:17] <fantasai> Scribe: fantasai
# [14:17] <fantasai> Topic: WebKit Prefix Conversations
# [14:17] <fantasai> plinss: Had various offline conversations.
# [14:18] <fantasai> plinss: Tantek / roc talking about creating this list of properties they're considering for webkit prefixing
# [14:18] <fantasai> plinss: Would like that list given to WG ASAP
# [14:18] * Joins: kojiishi (kojiishi@128.93.135.158)
# [14:18] <fantasai> plinss: Rather than vendors making blog posts saying "this is what we're going to do", would rather vendors brought these lists to us so we can reset our priorities
# [14:19] <fantasai> plinss: There is market interest in these properties. They are ready to be implemented, or already implemented, interoperably by multiple vendors. Therefore they meet the criteria to be standardized
# [14:19] <fantasai> plinss: No reason they shouldn't be standardized immediately.
# [14:20] <fantasai> plinss: If vendors feel there is sufficient market pressure tha it's rucial to their business, that should be our highest priority.
# [14:20] <fantasai> plinss: So I would like to get buy-in from the group that this is the right approach.
# [14:20] <fantasai> plinss: Would like commitment from vendors considering this to talk to us, let us address this as quickly as possible.
# [14:20] * Joins: jet (jet@128.93.134.233)
# [14:20] <fantasai> Florian: I'm convinced this is a good idea. Concerned it's not sufficient, but regardless we need to do it.
# [14:21] <fantasai> plinss: I accept it may not be sufficient. I hope it is. But we should as a WG do what we can to alleviate this market pressure.
# [14:21] <fantasai> plinss: Asking for commitment to get this list from vendors asap, and bring it first to WG not to vendor blogs
# [14:22] <fantasai> glazou: .... expand the evangelism commmunity.
# [14:22] <fantasai> glazou: let's try everything before going to the last resort
# [14:22] <fantasai> glazou: I have two options for the article. Can call community at large.
# [14:23] <fantasai> Florian: Idea is a call to the community at large to be responsible for how they use prefixes.
# [14:23] <fantasai> Florian: vendors have tried that on their own, he's suggesting to do it together.
# [14:23] <fantasai> plinss: I think if we have 2-3 vendors effectively agree on an implementation, whether it's because they like it or they're locked into it, that's sufficient for us to declare that it's enough for us to drop prefixes.
# [14:23] <fantasai> plinss: Then we can call on all sites to drop prefixes.
# [14:24] <fantasai> glazou: Want to move from de facto to de jure standards.
# [14:24] <fantasai> tantek: Daniel, such an article might help. Need to point out 2 things.
# [14:24] <fantasai> tantek: First, point out that -webkit- is hurting the web.
# [14:24] <fantasai> tantek: 2 problems. First is UA-sniffing, only providing modern web content to webkit
# [14:24] <fantasai> tantek: 2nd problem is that there are numerous features that work effectively interoperably across browsers
# [14:25] <fantasai> tantek: That if those sites put multiple prefixes today, without any change from this group, they would work.
# [14:25] <fantasai> glazou: Even if we're not sure that it will work, I think it is worht trying. I don't want us to take last resort option without trying.
# [14:26] <fantasai> tantek: We'd rather sites provided full content to Mozilla and have it break, than provide dumb content to us. I think we're fixing things fast enough that we can respond to that. But it's the webkit-only coding that is harmful.
# [14:26] <fantasai> glazou: Let's suppose it works a bit, and you see a trend of websites adding properties and not sniffing. Will that be sufficient for you to decide to wait?
# [14:26] <fantasai> tantek: Will look at data on a case-by-case basis. If data changes, conclusions may change.
# [14:26] <fantasai> plinss: Need to tackle this on all fronts.
# [14:27] <fantasai> plinss: Need to evaluate list of properties, resolve to drop prefixes for those that are ready.
# [14:27] <fantasai> tantek: I don't want to provide a list of properties, because I don't want anything that developers can depend on.
# [14:28] <fantasai> fantasai: What about providing a list to the CSSWG list?
# [14:28] <fantasai> tantek: Might change over time.
# [14:28] <fantasai> Florian: Peter asked for the list to set priorities.
# [14:28] <fantasai> Alan: Should emphasize that can use all prefixed versions right now, and without any changes by us, will work today.
# [14:28] <fantasai> Alan: And we should be trying to drop prefixes on the things that work in that way.
# [14:29] <fantasai> Tantek: We already have that focus in the WG. But things that are outstanding measures in the WG.
# [14:29] <fantasai> ...
# [14:29] <fantasai> plinss: The moment you have sufficient data about one property. If nothing else, send it to Daniel and I, so that we can make it #1 priority on the next telecon.
# [14:30] <fantasai> plinss: My assertion is, just like we were driving 2.1 to REC, that was highest priority. I'm offering you and Opera and MS, that level of priority if you get to that point on any property.
# [14:30] <fantasai> plinss: That will be the #1 focus of the group to drop that prefix.
# [14:30] <fantasai> tantek: Ok. I'm willing to put that on css-wg list. Don't want to kick of some kind of flamewar on www-style. Minutes of discussion will of course be public.
# [14:31] <fantasai> tantek: We may wind up posting list to wiki page, but we have better things to do than write blog posts aobut it.
# [14:31] <fantasai> plinss: If we can help the situation by dropping the prefix, we will drop the prefix.
# [14:32] <ChrisL> pointer to prefixing policy doc?
# [14:33] * Joins: TabAtkins_ (tabatkins@74.125.122.49)
# [14:33] <smfr> http://www.w3.org/TR/CSS/#experimental
# [14:34] <fantasai> fantasai: Note that we do have a loophole in the vendor-prefixing policy that the WG can declare an experimental property to be implemented prefixless *for legacy reasons*. This was originally for things like text-overflow, but existing webkit-only content on the web also qualifies as a legacy reason.
# [14:34] <fantasai> fantasai: So if we have a spec that we cannot move fast enough to CR, we can use that loophole to drop prefixes immediately.
# [14:36] <fantasai> fantasai: [says stuff]
# [14:36] <fantasai> smfr: [1-3 months]
# [14:36] <fantasai> fantasai: Will that happen?
# [14:37] <fantasai> smfr: We can make that happen.
# [14:37] <fantasai> Tantek: How about we go to CR with open issues?
# [14:38] <fantasai> fantasai: What's the point of that? The CR transition requires no open issues. If your problem is you want to drop prefixes with open issues, then drop prefixes before CR.
# [14:38] * Joins: szilles (chatzilla@128.93.134.251)
# [14:38] <fantasai> jdaggett: You can defer issues, e.g. mark things undefined.
# [14:39] <fantasai> Tantek:
# [14:40] <fantasai> Tantek: You'll get issues faster than you can evaluate them, just like 2.1
# [14:40] <fantasai> fantasai: We haven't had that problem to the extent we had it with 2.1 with our CSS3 modules
# [14:40] <fantasai> fantasai: What do you want out of moving to CR?
# [14:40] <fantasai> Tantek: Dropping prefixes
# [14:40] <fantasai> fantasai: So let's drop prefixes and not change the definition of CR, what's the problem?
# [14:40] <fantasai> Tantek: ...
# [14:41] <fantasai> Tantek: I think it's more important to use CR as a marker for dropping prefixes than a marker for closing issues.
# [14:41] <fantasai> Tantek: ...
# [14:42] <fantasai> plinss: To make progress faster, as a group, we can drop prefixes before CR. And if there's a singificant portion that is stable and has no issues, is ready to go to CR, we split the spec.
# [14:42] <fantasai> plinss: And we are also willing to run through issues and solve or defer them quickly.
# [14:42] <fantasai> plinss: We have three different avenues and we're willing to use them all as needed.
# [14:42] <fantasai> Tantek: Sounds good.
# [14:43] <fantasai> Topic: Backgrounds and Borders
# [14:43] <TabAtkins_> ScribeNick: TabAtkins_
# [14:43] <fantasai> http://www.w3.org/Style/CSS/Tracker/products/11
# [14:43] <TabAtkins_> fantasai: Bert and I have been going through the B&B issues.
# [14:43] <TabAtkins_> fantasai: There are a couple open ones, with proposed reoslutions, but we need the WG to evaluate them.
# [14:44] <TabAtkins_> fantasai: First is bidi reordering and the application of box-decoration:break
# [14:44] <fantasai> http://dev.w3.org/csswg/css3-background/#the-box-decoration-break
# [14:44] * Joins: vhardy_ (qw3birc@128.30.52.28)
# [14:44] <TabAtkins_> fantasai: After the discussion with dbaron, I edited in text that says UAs *may* apply box-decoration to control rendering at bidi-imposed breaks.
# [14:44] <fantasai> "UAs may also apply ‘box-decoration-break’ to control rendering at bidi-imposed breaks, i.e. when bidi reordering causes an inline to split into non-contiguous fragments. Otherwise such breaks are always handled as ‘slice’. "
# [14:44] <TabAtkins_> fantasai: Otherwise, such breaks are handled as slice.
# [14:44] <TabAtkins_> fantasai: Are people happy with this?
# [14:45] <TabAtkins_> TabAtkins_: Is there a particular reason to keep it optional right now?
# [14:45] * Joins: glenn (gadams@174.29.105.126)
# [14:45] <TabAtkins_> dbaron: We don't have a strict definition of where bidi breaks happen.
# [14:45] <TabAtkins_> dbaron: And we probably, in reality, want to split breaks into two groups, one of which pays attention ot the property, and the other which always slices.
# [14:45] <TabAtkins_> fantasai: This is a weird edge case, so this lets the UA do whatever makes sense right now.
# [14:46] <TabAtkins_> fantasai: The default behavior is 'slice' (the easy case), so the suggested solution is to optionally apply 'break' when specified if the UA has a good way to do it.
# [14:47] <TabAtkins_> dbaron: Is it conformant to do a split between the two?
# [14:47] <TabAtkins_> fantasai: I don't think it's conformant with this wording.
# [14:47] <TabAtkins_> dbaron: I think it's the most sensible behavior, at least given by the way we consider these breaks to exist.
# [14:47] <TabAtkins_> fantasai: That's why we have the term "contiguous".
# [14:48] <TabAtkins_> dbaron: I want tests in the test suite for this.
# [14:48] <TabAtkins_> fantasai: Ok.
# [14:48] <TabAtkins_> [no further objections]
# [14:48] <TabAtkins_> fantasai: Next issue is the corner transitions in border-radius
# [14:48] <fantasai> http://dev.w3.org/csswg/css3-background/#corner-transitions
# [14:49] <TabAtkins_> fantasai: The spec as I brought up before is *completely* wrong. But we don't have a good definition for the right behavior, so the idea right now is to make it officially undefined for now.
# [14:49] <fantasai> Color and style transitions must be contained within the segment of the border that intersects the smallest rectangle that contains both border radii as well as the center of the inner curve (which may be a point representing the corner of the padding edge, if the border radii are smaller than the border-width).
# [14:49] <fantasai> If one of these borders is zero-width, then the other border takes up the entire transitional area. Otherwise, the center of color and style transitions between adjoining borders must be proportional to the ratio of the border widths such that a function of its location is continuous with respect to this ratio. However it is not defined what these transitions look like or how “proportional” maps to a point on the curve.
# [14:49] <TabAtkins_> fantasai: This way, the spec is at least not *wrong*, and we can figure out the correct behavior in level 4.
# [14:50] <TabAtkins_> fantasai: [explains the above text]
# [14:51] <TabAtkins_> plinss: Didn't we discuss this at TPAC?
# [14:51] <TabAtkins_> fantasai: We did, and concluded we needed to investigate a lot more before we could correctly specify it.
# [14:51] <TabAtkins_> fantasai: This way, we're defining the important bits that people rely on.
# [14:52] <TabAtkins_> fantasai: Like that a zero-width border won't contribute any visible color.
# [14:53] <TabAtkins_> fantasai: And that larger borders are proportional in some way.
# [14:53] <TabAtkins_> sylvaing: What's the important bit, precisely, and who depends on it?
# [14:54] <TabAtkins_> fantasai: One example is a box with only a border on top that curves around. The sides will usually just be currentColor, and authors don't expect that to show up.
# [14:54] * Joins: drublic (drublic@77.2.157.148)
# [14:55] <TabAtkins_> tantek_: I think we could instead hook that to border-style. If the side is border-style:none, don't show any of the dest color. But if it's solid, even if it's 0px, when you do a gradient it should fade to that.
# [14:55] * Joins: howcome (howcome@128.93.135.80)
# [14:55] * Joins: Rossen (Rossen@128.93.134.230)
# [14:56] <TabAtkins_> Bert: I think that's what Konqueror does.
# [14:56] <fantasai> fantasai: So you want to replace 'zero-width' with 'none or hidden'.
# [14:56] <TabAtkins_> dbaron: I think that removes the continuity argument.
# [14:56] <TabAtkins_> Bert: Not sure. We need more research, or to leave it open.
# [14:57] <TabAtkins_> tantek_: I'm okay with leaving it open, I just wanted to present it as a use-case.
# [14:57] <TabAtkins_> fantasai: So if you wanted to use a double or dashed border...
# [14:57] <TabAtkins_> tantek_: Borders historically have been places where we allow impls to give better results, rather than locking them into an LCD.
# [14:58] <TabAtkins_> fantasai: So we still want to define, at least in the 'none' case, that the entire visible border is the color of the non-'none' border.
# [14:58] <TabAtkins_> fantasai: But that makes dbaron unhappy.
# [14:59] <TabAtkins_> dbaron: I don't think the color at the corner is ever what's desirable.
# [14:59] <TabAtkins_> fantasai: So how should we resolve this?
# [15:00] <TabAtkins_> dbaron, smfr: I'm happy leaving it as it is.
# [15:01] <TabAtkins_> plinss: Can we resolve to accept the text in the editor's draft?
# [15:01] <TabAtkins_> [no objection]
# [15:01] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/214
# [15:01] <TabAtkins_> fantasai: Next issue, define the default shadow color.
# [15:01] <TabAtkins_> RESOLVED: Accept the ED text for border-transitions.
# [15:02] <TabAtkins_> RESOLVED: Accept the proposed resolution for bidi splits and box-break
# [15:02] <fantasai> Options mentioned so far:
# [15:02] <fantasai> - black
# [15:02] <fantasai> - rgba(0,0,0,0.5)
# [15:02] <fantasai> - currentColor
# [15:02] <fantasai> - currentColor except it doesn't compute until after inheritance
# [15:02] <fantasai> - make <color> required
# [15:02] <TabAtkins_> fantasai: There's a bunch of options: 'black', 'rgba(0,0,0,.5)', 'currentColor', 'currentColor, but used-value time', or require it be defined.
# [15:03] <TabAtkins_> dbaron: Are we discussing box-shadow, or text-shadow as well? And what do the specs currently say?
# [15:03] <TabAtkins_> fantasai: Both, and they shoudl be consistent. They both say "UA defined" right now.
# [15:05] <TabAtkins_> dbaron: Gecko seems to use currentColor for both shadows, almost.
# [15:05] <TabAtkins_> dbaron: I think, though, that on text-shadow, if the text decorations are a different color form the text, the default shadow *on the decorations* will match the decoration color.
# [15:06] <fantasai> fantasai: Ok, so 6 options (for text-shadow; doesn't make a difference for box-shadow)
# [15:06] <TabAtkins_> plinss: Any opinions?
# [15:08] <dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"color%3A orange%3B text-shadow%3A 20px 20px">hello<%2Fspan><%2Fspan>
# [15:08] <TabAtkins_> dbaron: Above data url confirms Gecko's text-shadow handling.
# [15:09] <TabAtkins_> smfr: I think WebKit defaults to transparent.
# [15:11] <TabAtkins_> fantasai: We could still make it required.
# [15:11] <TabAtkins_> dbaron: I'm not comfortabl ewith a syntax change at this point.
# [15:11] <TabAtkins_> dbaron: Opera doesn't shadow decorations at all.
# [15:11] <fantasai> Tab: When we do equivalent of fill on text, filling text with images, what will text-shadow do then?
# [15:12] <fantasai> Florian: Will it behave like stained glass or not?
# [15:12] <fantasai> smfr: I think black as a default color would be easier to understand.
# [15:12] <fantasai> Tab: Given we have random answers right now, we could pick anything.
# [15:13] <dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B text-shadow%3A 20px 20px">hello<%2Fspan><%2Fspan>
# [15:14] <fantasai> [people run tests on various UAs]
# [15:15] <TabAtkins_> sylvaing: IE10 shadows text and decorations both with the currentColor.
# [15:18] <fantasai> [discussing defaulting to black]
# [15:18] <fantasai> Bert: we have an implementation: Konqueror defaults to black
# [15:18] <dbaron> http://www.w3.org/TR/1998/REC-CSS2-19980512/text.html#text-shadow-props says to use the current color
# [15:19] <TabAtkins_> [everyone checks what the default for box-shadow is in UAs]
# [15:20] <dbaron> data:text/html;charset=utf-8,<!DOCTYPE html><span style%3D"text-decoration%3A underline%3B color%3A blue"><span style%3D"text-decoration%3A overline%3B color%3A fuchsia%3B"><span style%3D"text-decoration:line-through;color%3A orange%3B text-shadow%3A 20px 20px;box-shadow: 40px 40px">hello<%2Fspan><%2Fspan>
# [15:23] <fantasai> Proposed to make box-shadow default to the value of the 'color' property on the element being shadowed. computed value doesn't have a color if it's not specified.
# [15:23] <fantasai> RESOLVED: box-shadow as above
# [15:23] <TabAtkins_> fantasai: We fixed some definitions surrounding border-image and SVG. We need review to ensure they're correct.
# [15:24] * Quits: glenn (gadams@174.29.105.126) (Ping timeout)
# [15:24] <TabAtkins_> fantasai: [explains the text in the spec]
# [15:24] <fantasai> http://dev.w3.org/csswg/css3-background/#the-border-image-source
# [15:24] <fantasai> If the image must be sized to determine the slices (for example, for SVG images with no intrinsic size), then it is sized as for an auto-sized background, using the border image area as the default object size in place of the background positioning area.
# [15:26] <TabAtkins_> fantasai: If the image has an intrinsic size, you don't need to size it to cut it.
# [15:28] <TabAtkins_> ChrisL: It won't tile in the sense tha tyou have only one copy of the image.
# [15:29] <karl> RRSagent, pointer?
# [15:29] <RRSAgent> See http://www.w3.org/2012/02/07-css-irc#T14-21-48
# [15:29] <TabAtkins_> dbaron: It seems there may be a solution wher eyou just end up with one copy of the imgae.
# [15:29] <TabAtkins_> dbaron: Except you're doing sizing before doing slicing to fill the border.
# [15:29] <karl> RRSAgent, make logs public
# [15:29] <RRSAgent> I have made the request, karl
# [15:29] <karl> RRSAgent, draft minutes
# [15:29] <RRSAgent> I have made the request to generate http://www.w3.org/2012/02/07-css-minutes.html karl
# [15:30] <TabAtkins_> [some discussion]
# [15:30] <TabAtkins_> dbaron: I guess it's fine.
# [15:30] <dbaron> (I still don't really know what it means, but I don't think it matters.)
# [15:30] * Joins: glenn (gadams@174.29.118.145)
# [15:31] <TabAtkins_> RESOLVED: Accept the ED text for border-image-slice.
# [15:32] <TabAtkins_> fantasai: next issue is animations.
# [15:32] <Bert> ISSUE-215?
# [15:32] * trackbot getting information on ISSUE-215
# [15:32] <trackbot> ISSUE-215 -- Animatability of box-shadow: none to box-shadow: <shadow> -- raised
# [15:32] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/215
# [15:32] <TabAtkins_> fantasai: We added the animatable field to the spec.
# [15:32] <TabAtkins_> fantasai: It should match transitions in general.
# [15:32] <TabAtkins_> fantasai: One different area is the box-shadow property.
# [15:33] <TabAtkins_> fantasai: We currently say "animatable: yes, but not between inset and outset". We'll deal with that kind later.
# [15:33] <ChrisL> specifying animatability on all properties is good
# [15:33] <TabAtkins_> fantasai: And we say that transition to/from an absent shadow is between "0 0 transparent".
# [15:33] <TabAtkins_> fantasai: So you can transition between box-shadow:none and box-shadow:<something>
# [15:34] <TabAtkins_> tantek_: Is there a reference to what we mean by "animatable"?
# [15:34] * Quits: glenn (gadams@174.29.118.145) (Ping timeout)
# [15:34] <TabAtkins_> fantasai: yeah, the transitions spec.
# [15:34] <TabAtkins_> tantek_: So that's a normative dependency?
# [15:35] <TabAtkins_> Bert: Not quite.
# [15:35] <TabAtkins_> dbaron: The idea is that specs that happen before Transitions, Transitions defines how they work. Ones published afterwards, the spec defines how they work.
# [15:35] <TabAtkins_> dbaron: We're maybe racing with Transitions with this spec, but it's not a big deal.
# [15:36] <TabAtkins_> ChrisL: But every spec will end up with animation information?
# [15:36] <TabAtkins_> dbaron: Yes, when they next update.
# [15:36] <ChrisL> ok, good
# [15:36] <TabAtkins_> tantek_: For specs that are ahead in progress of Transitions, we should have Transitions contain that information.
# [15:37] <TabAtkins_> dbaron: I don't agree.
# [15:38] <TabAtkins_> fantasai: Unless someone has a *really good reason* why this is a process problem, we shouldn't worry about it. It's better to be consistent and have all the specs work the same way.
# [15:38] <TabAtkins_> plinss: At TPAC we discussed transitioning between inset/outset shadows.
# [15:38] <TabAtkins_> TabAtkins_: I don't think we have a good answer for it yet.
# [15:38] <TabAtkins_> fantasai: We'll address it in level 4.
# [15:38] <TabAtkins_> plinss: Okay.
# [15:39] <TabAtkins_> fantasai: That's all the issues, so Bert and I need to compile the list of changes.
# [15:40] <fantasai> ACTION fantasai: if animating from none to inset shadow, need none to behave as '0 0 transparent inset'
# [15:40] * RRSAgent records action 15
# [15:40] * trackbot noticed an ACTION. Trying to create it.
# [15:40] <trackbot> Created ACTION-434 - If animating from none to inset shadow, need none to behave as '0 0 transparent inset' [on Elika Etemad - due 2012-02-14].
# [15:40] <TabAtkins_> smfr: Issue - If going from 'none' to an inset shadow, need to support the 'none' being treated as "0 0 transparent inset".
# [15:40] <dbaron> (or for a list being shorter)
# [15:40] <dbaron> (and none really gets treated as a 0-length list)
# [15:40] <TabAtkins_> RESOLVED: Accept ED text for all animatable properties.
# [15:40] * Joins: glenn (gadams@174.29.122.52)
# [15:41] <TabAtkins_> fantasai: So Bert and I will make the edits and compile the list of changes, then present beofr eth enext telcon.
# [15:41] <TabAtkins_> fantasai: So question, can we republish CR with the changes, or do we need to go back to LC.
# [15:42] <TabAtkins_> szilles: Did you do anything that would invalidate an existing impl?
# [15:43] <TabAtkins_> fantasai: Yes, we made the default shadow color more precise.
# [15:43] <TabAtkins_> ChrisL: You can do the minimum 3-week LC, and say you're not accepting any new features, but are only looking for feedback on the list of recent changes.
# [15:44] * Quits: glenn (gadams@174.29.122.52) (Ping timeout)
# [15:44] <TabAtkins_> tantek_: Can we just go to LC directly?
# [15:44] <TabAtkins_> tantek_: Or CR directly?
# [15:45] <TabAtkins_> [process discussion]
# [15:46] <TabAtkins_> plinss: We could potentially do a testsuite and go from LC straight to PR.
# [15:47] <TabAtkins_> fantasai: Last time we tried that with Selectors, it sat in LC for several years.
# [15:47] * Quits: smfr (smfr@128.93.134.211) (Quit: smfr)
# [15:47] <TabAtkins_> tantek_: I think that sending it back to LC ocmmunicates that it's unstable, which is wrong. That part of W3C process is broken.
# [15:48] <TabAtkins_> fantasai: I agree with Tantek that the process is broken, and we need a way to errata a CR in-place.
# [15:49] <TabAtkins_> fantasai: We have two options. Go through LC, make it quick, and get back to CR. Second is to make box-shadow default color undefined and stay in CR.
# [15:51] * Joins: glenn (gadams@174.29.108.64)
# [15:52] <TabAtkins_> [angry discussion about process]
# [15:54] <fantasai> RESOLVED: Republish Backgrounds and Borders as LC in order to errata it as CR. Include an explanation of why we're publishing a LC -- that it's still a CR-level draft, we just need to make errata 'cuz the process doesn't allow for errata in CR.
# [15:55] * Quits: glenn (gadams@174.29.108.64) (Ping timeout)
# [15:55] <astearns> the errata list should probably highlight the single issue that made LC required
# [15:55] <TabAtkins_> Topic: Image Values
# [15:56] <TabAtkins_> fantasai: If anyone has any issues about LC, please raise them.
# [15:56] <TabAtkins_> sylvaing: I have a question about gradients. Does anyone know how long they'll keep their prefixes around?
# [15:56] <TabAtkins_> sylvaing: It looks like FF has changed to accept the new grammar.
# [15:56] <TabAtkins_> dbaron: We attempted to make an additive change so we would support more of th enew syntax values, but not remove support for anything yet.
# [15:57] * Joins: smfr (smfr@128.93.134.211)
# [15:57] * Joins: miketaylr (miketaylr@187.105.255.109)
# [15:57] <TabAtkins_> dbaron: I don't plan to remove things fro mthe -moz-gradient; I plan to remove that stuff when we unprefix.
# [15:57] <TabAtkins_> dbaron: We'll probably keep the prefix around for a bit, considering how used it is.
# [15:57] <TabAtkins_> florian: We'll probably drop our prefix the moment we go to unprefixed.
# [15:58] <TabAtkins_> smfr: We implemented gradients before the angle change, which means we can't update without breaking stuff.
# [15:58] <TabAtkins_> smfr: So we probably won't be able to drop prefixes for a long time.
# [15:58] <TabAtkins_> smfr: We can definitely do unprefixed correctly, though.
# [15:59] <fantasai> Tab: smfr suggests moving element() to L4
# [15:59] <fantasai> Tab: right now only Mozilla implements. If nobody else has plans, perhaps better to shift to L4?
# [15:59] <fantasai> dbaron: How many implementations do we have of the other stuff?
# [16:00] <fantasai> Tab: The other stuff is relatively simple
# [16:00] <TabAtkins_> dbaron: Why are we removing the hard-but-popular instead of the simple-but-nobody-cares?
# [16:00] <fantasai> fantasai: If the spec is stable, then we should take it to CR and mark it at-risk.
# [16:00] <fantasai> fantasai: If the spec is unstable, then we should hold it back.
# [16:01] <TabAtkins_> TabAtkins_: Simon, would you be okay if we kept element() as at-risk as we go into CR?
# [16:01] <TabAtkins_> smfr: Yes.
# [16:01] * Joins: glenn (gadams@71.218.123.58)
# [16:02] <TabAtkins_> dbaron: Are enough things marked as at-risk?
# [16:02] <TabAtkins_> dbaron: Do we have two impls of objec-tposition and image-resolution? And the rest of object-fit?
# [16:02] <TabAtkins_> fantasai: We have two impls of image-resolution.
# [16:03] <TabAtkins_> florian: We have some code for object-*, but I don't know the status.
# [16:03] <TabAtkins_> plinss: What about a testsuite?
# [16:03] <TabAtkins_> sylvaing: We have some gradients test. We'll contribute them.
# [16:03] <TabAtkins_> TabAtkins_: I plan to make testsuite my next priority.
# [16:04] <TabAtkins_> fantasai: There's an issue from the community about the gradient syntax.
# [16:05] * Quits: glenn (gadams@71.218.123.58) (Ping timeout)
# [16:06] <dbaron> Florian: We've debated this to death already. What we have is a compromise, and it satisfies more people than any other compromise we've had.
# [16:06] <fantasai> fantasai: It was a coin toss.
# [16:07] <TabAtkins_> dbaron: I suggest we mark everything but gradients as at-risk. I don't want any of the other features to hold up gradients.
# [16:07] <TabAtkins_> [several]: That's fine.
# [16:08] <TabAtkins_> RESOLVED: Mark everything in Images 3 as at-risk except gradients.
# [16:08] <TabAtkins_> RESOLVED: Move Images 3 to CR after the above change.
# [16:08] <fantasai> fantasai^: and it made the updated syntax less compatible with what's out there already
# [16:13] * Joins: ksweeney (ksweeney@63.119.10.10)
# [16:13] * Joins: arron (Arron@24.17.123.244)
# [16:13] * Joins: glenn (gadams@174.29.101.38)
# [16:20] * Quits: glenn (gadams@174.29.101.38) (Ping timeout)
# [16:24] * Parts: arron (Arron@24.17.123.244)
# [16:24] * Joins: arron (Arron@24.17.123.244)
# [16:27] * Joins: glenn (gadams@174.29.119.75)
# [16:30] <TabAtkins_> Topic: 2.1 errata
# [16:30] <TabAtkins_> antonp: We've got about 88 issues on the bug tracker, with about 20 more I'm tracking and need to carry over.
# [16:30] <TabAtkins_> antonp: The remaining will need a lot of work to decide what's even wrong.
# [16:30] <TabAtkins_> antonp: The majority of the stuff on the list is not hard, and I think just needs to be approved.
# [16:30] <smfr> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=CSS%20Level%202&;resolution=---
# [16:31] <TabAtkins_> antonp: So, we're not going to do 88 bugs in the next hour. What's our strategy, and our timeline?
# [16:31] * Quits: glazou (glazou@128.93.135.193) (Client exited)
# [16:31] <TabAtkins_> antonp: There are a few that I think could benefit form a discussion now, 6 in particular.
# [16:31] <TabAtkins_> antonp: Which we could do easiest first, or hardest first.
# [16:31] * Joins: glazou (glazou@128.93.135.193)
# [16:31] * Quits: glenn (gadams@174.29.119.75) (Ping timeout)
# [16:31] <TabAtkins_> antonp: So, first, general strategy to get them fixed, then we can discuss some specific ones.
# [16:32] * Quits: szilles (chatzilla@128.93.134.251) (Ping timeout)
# [16:32] <TabAtkins_> fantasai: I think a good strategy would be to put a couple on each telcon, so we burn them down eventually, and for each, put a proposal on it.
# [16:32] <TabAtkins_> fantasai: So each weak, we have one or two CSS 2.1 issues to look at that the WG can discuss.
# [16:32] <fantasai> s/weak/week/
# [16:32] <TabAtkins_> dbaron: I find it easier to think about a bunch at once, rather than switching regularly.
# [16:32] <TabAtkins_> antonp: Is that because of topic? The topics divide up well.
# [16:33] <TabAtkins_> antonp: And then there are many easy editorial-like ones that can push through fairly easily.
# [16:33] <TabAtkins_> dbaron: Okay. And I think it's good to come up with a proposal.
# [16:33] <TabAtkins_> fantasai: And if there isn't one, we should be discussing who's writing a proposal.
# [16:33] <TabAtkins_> antonp: Another question, what's our timeline for all of this?
# [16:33] <TabAtkins_> antonp: What are the reqs for an errata document?
# [16:34] <TabAtkins_> fantasai: It's continuously maintained. As soon as we resolve, it goes on Bert's list to write the errata.
# [16:34] <TabAtkins_> fantasai: We'd like to publish an updated 2.1 Rec sometime this year.
# [16:34] <TabAtkins_> fantasai: Ideally around June, but we can push it to August or whatever if necessary, if we have a few more bugs to handle.
# [16:34] <TabAtkins_> florian: I think most important is to resolve them faster than reported.
# [16:35] <TabAtkins_> florian: i don't think it's quite necessary to have them all resolved at the same time.
# [16:35] <TabAtkins_> antonp: Sounds reasonable.
# [16:35] <TabAtkins_> antonp: Most of these are small, editorial tweaks. Only a small number require real thinking.
# [16:35] <TabAtkins_> antonp: So, do we now want to actually look at some of these beasts?
# [16:36] <TabAtkins_> antonp: We have two on margin-collapsing, one is kinda hard as it contradicts an old resolution.
# [16:36] * sylvaing has a nagging suspicion Anton considered issue 60 as easy
# [16:38] * Parts: ksweeney (ksweeney@63.119.10.10)
# [16:38] * Joins: glenn (gadams@71.218.123.30)
# [16:39] <dbaron> http://www.w3.org/TR/CSS21/box.html#collapsing-margins
# [16:40] <fantasai> ScribeNick: fantasai
# [16:40] <fantasai> Anton draws on the board
# [16:40] <fantasai> Anton: Partial margin collapsing could have been the perfect solution, but also kindof hard.
# [16:40] <fantasai> Anton: This is the rewrite of the old margin collapsing stuff
# [16:40] <fantasai> (points to screen)
# [16:40] <tantek_> note: for ASCII art, here is a handy web-based visual editor: http://www.asciiflow.com/
# [16:41] <fantasai> Anton: I'm using this wording b/c far better than the old wording, and forpurposes I'm discussing is exactly the same.
# [16:41] <fantasai> Anton: This is the situation wh have. We have a box with a min-height. And it has one child, and the child is self-collapsing.
# [16:41] <fantasai> Anton: The result of collapsing the child is this here (points at dotted rectangle inside solid rectangle). It is about to collapse with the parent's top margin.
# [16:42] <fantasai> Anton: Problem is it also wants to collapse with the bottom margin.
# [16:42] <fantasai> Anton: Not defined what happens there. Does this collapsed margin collapse with the bottom or the top or what?
# [16:42] <fantasai> Anton: There was a discussion of min-height and max-height and their effect on collapsing.
# [16:42] <fantasai> dbaron: At one point a distinction between whether min-height prevented collapsing through or collapsing the last child's bottom margin with the parent's margin when the margin was not collapsed with the parent's top margin
# [16:43] <fantasai> Steve: Sounds like you aid the case is already complete.
# [16:43] <fantasai> dbaron: It's a hard compromise we ended up with
# [16:43] <fantasai> Anton: There are one or two tiny things that need to be rethought, but not relevant to this case.
# [16:44] <fantasai> dbaron: There was one issue I object to in the rewrite, because it made a case where the spec was self-contradictory be defined here.
# [16:44] <fantasai> Anton: I believe it exists as a contradiction here.
# [16:44] <fantasai> Anton: This is the contradiction.
# [16:44] <fantasai> dbaron: I agree there's a contradiction in what to do here.
# [16:44] <fantasai> dbaron: Last time we discussed it, didn't think about that.
# [16:44] <fantasai> dbaorn: old spec contradicted itself with what collapsed with what.
# [16:45] <fantasai> Anton: Think that transferred across. No difference, except this spec there's a slight.. it uses adjoining when it means collapsing and vice versa.
# [16:45] <arron> do we have a test page that shows what anton drew on the board?
# [16:45] <fantasai> Anton: Adjoining is now a non-transitive issue. Collapsing is a transitive issue.
# [16:45] <fantasai> Anton: Collapsing is transitive because a collapsed margin ... Oh, hang on, maybe it's not an issue.
# [16:45] <fantasai> dbaron: I thought we wanted adjoining to be transitive?
# [16:46] <fantasai> fantasai: I tried. I couldn't do it.
# [16:46] <fantasai> dbaron: The old contradiction was that there awas a statement that these 2 things collapse, and these two things don't.
# [16:46] <fantasai> fantasai: I think most of the old text is in that note.
# [16:46] * Joins: alexmog_ (alexmog@128.93.135.194)
# [16:46] <fantasai> Anton: To approach this problem, worth pointing out what discussions were had in the past.
# [16:46] <fantasai> Anton: Was a very important case in the past where you've got your box here, you've actually got a genuine child non-collapsing child
# [16:47] <fantasai> Anton: And the non-collapsing child has a margin which is really long... *draws margin that flows out of the box*
# [16:47] <fantasai> Anton: and parent has a bottom margin.
# [16:47] <fantasai> Anton: This child with the bottom margin, the height of that margin is bigger than the min-height of the box.
# [16:47] <fantasai> Anton:What happens here? Does this force the parent to become bigger?
# [16:48] <fantasai> Anton: Doing something differnet with min-height and max-height causes discontinuities.
# [16:48] <fantasai> dbaron: They were dropped because something we really wanted to do and couldn't get two implementations passing the test suite, but what we decided to do didn't make sense.
# [16:48] <fantasai> Alex: We have resisted conditional margin collapsing that depends on content actually hitting min-height or not. min-height has an effect or doesn't have an effect.
# [16:49] <fantasai> Alex: All other aspects of margin collapsing can be calculated before layout starts.
# [16:49] <fantasai> Alex: ....
# [16:49] <fantasai> Anton: The reason then that we have ourselves in a weird situation because of that.
# [16:49] <fantasai> Anton: Now, because there's no instructions about min-height in the spec anymore, we have a strange situation where this was a self-collapsing element *points at first drawing*
# [16:49] <fantasai> Anton: Another interesting issue, now, *draws solid box inside bigger solid box*
# [16:50] <fantasai> Anton: Spec says that the bottom margin of this small child collapses with the margin on the parent, even though the box is plenty big enough to contain the child and its margin
# [16:50] * arron appreciates fantasia's descriptions of what is drawn on the board.
# [16:51] <fantasai> Anton: From what I can tell from the minutes and resolutions, it was recognized that the resolution didn't solve all the problems, and it was recognized that it wasn't solved, would have to be solved later
# [16:51] <fantasai> Anton: Seems to me fundamental problem, should this margin collapse with the one down there?
# [16:51] <alexmog_> +---------------+
# [16:51] <alexmog_> | |
# [16:51] <alexmog_> +-|---------------|--+ +
# [16:51] <alexmog_> | | | | |
# [16:51] <alexmog_> | +---------------+ | |
# [16:51] <alexmog_> | margin 1 | |
# [16:51] <alexmog_> | | | min-height
# [16:51] * Joins: glenn_ (gadams@174.29.125.223)
# [16:51] <fantasai> Anton: Here you can do something sensible.
# [16:51] <alexmog_> | | |
# [16:51] <alexmog_> | | |
# [16:51] <alexmog_> | | |
# [16:51] <alexmog_> | | |
# [16:51] <alexmog_> +--------------------+ v
# [16:51] <alexmog_> margin 2
# [16:51] * Quits: glenn (gadams@71.218.123.30) (Ping timeout)
# [16:51] <fantasai> Anton: In the case where you've got a non-self-collapsing child, as the last child
# [16:52] <fantasai> Anton: You can do something sensible to collapse its bottom margin with the paretn's bottom margin.
# [16:52] <fantasai> Anton: You have to choose, but you can spec somehting sensible.
# [16:52] <fantasai> Anton: But in the case wher eyou have self-collapsing margin, you can't
# [16:52] <fantasai> Anton: How does this margin manifest itself? You have a positive-height box, but it's supposed to be self-collapsing.
# [16:52] <fantasai> dbaron: See 2 posslbe changes to spec to fix this.
# [16:53] <fantasai> dbaron: Minimal one is to change the third bullet under the third bullet in definition of adjoining.
# [16:53] <fantasai> "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height"
# [16:53] <fantasai> dbaron: To add the condition that either the parent has zero computed min-height, or the bottom margin of the last in-flow child does not collapse with the top margin of the parent.
# [16:53] <fantasai> dbaron: Thought we had a condition like that in the spec.
# [16:54] <fantasai> dbaron: And this condition with an either-or: either parent has zero computed-min-height, or, bottom margin of the last child doesn't collapse with the top margin of the parent.
# [16:55] <fantasai> dbaron: What I'd really prefer is to reduce the condition by saying it's just "and the parent has a computed zero min-height"
# [16:55] <dbaron> change from: "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height"
# [16:56] <dbaron> change to option 1 (minimal): "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height and (the parent has a zero computed min-height or the bottom margin of the last in-flow child does not collapse with the top margin of the parent)"
# [16:56] <fantasai> Alex: I think reason min-height is not mentioned there is that we don't want to prevent margin collapsing when min-height didn't take effect.
# [16:56] <dbaron> change to option 1 (preferred, but I don't remember why we didn't do it before): "bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height and the parent has a zero computed min-height"
# [16:56] <fantasai> Alex: If you have min-height of 1px, min-height will not make a difference, but will prevent margin collapsing.
# [16:56] <fantasai> Anton: exactly
# [16:57] <fantasai> Anton: Seem to be definitely in past resolutions to not distinguish cases of whether min-height takes effect or not.
# [16:57] <fantasai> Anton: But I think you can't have continuity if you think to that.
# [16:57] <fantasai> dbaron: ...
# [16:57] <fantasai> Alex: min-height has an effect, and bottom margin doesn't collapse with top margin, your position will change ....
# [16:58] <fantasai> Anton: reoslution in the past ...
# [16:58] <fantasai> Anton: we have to say that those can collapse
# [16:58] <fantasai> Anton: Brings us back to this case (points at solid solid boxes)
# [16:58] <fantasai> Alex: .. is pretty rare, and making that work, with all of the complications that we have
# [16:58] <fantasai> Alex: If we make it work, will be pretty complicated, but we're not sure how much we really need it.
# [16:59] <fantasai> Anton: Confirming that we don't exclude min-height in general that would be collapsing here.
# [16:59] <fantasai> Alex: One case you've shown doesn't make any sense, but keep severything predictable
# [16:59] <fantasai> Anton: Important to decide what we want in this case, b/c will help us understand the contradictory case.
# [16:59] <fantasai> Anton: David your solution is then appropriate for this (middl picture of collapsed margin isnide min-height box)
# [16:59] <fantasai> Anton: Self-collapsing sits at the top, doesn't make sens to collapse to the bottom.
# [17:00] <fantasai> Anton: In this case you need to break collapsing with the bottom.
# [17:00] <fantasai> fantasai: I think we discussed this situation wrt defining the position of the self-collapsed element, not here for how to collapse it.
# [17:01] <fantasai> Anton: Yeah, the border position is well-defined. Just not defined how it collapses.
# [17:01] <fantasai> Anton: The border position sets up a hypothetical situation where you don't have these collapsing.
# [17:01] <fantasai> Anton: There is an issue where if you've got a min-height, you begin by doing the calculation based on the normal height, and you do the CH 10 calculations to determine your height.
# [17:02] <fantasai> Anton: If that's less than the min-height, then you do your calculations again.
# [17:02] <fantasai> Anton: assuming that the height is then set to the specifie dmin-height.
# [17:02] <fantasai> Anton: In all of these cases, incidentally, height is assumed to be 'auto'.
# [17:02] <fantasai> Anton: There's a note in Ch 10.7, that tries to explain something about margin collapsing. But I can't understand what that note is saying in relation to this.
# [17:03] <fantasai> Anton: If you're recalculating b/c you're assuming auto height, then assuming ehgiht = min-height, you run into differnet rules in marign collapsing.
# [17:03] <fantasai> Anton: Confusing note in 10.7, doj't know whether it's trying to address this situation or not.
# [17:03] <dbaron> These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing except as specifically required by rules for 'min-height' or 'max-height' in "Collapsing margins" (8.3.1).
# [17:03] <dbaron> (note in 10.7)
# [17:04] <fantasai> dbaron: I think what the second sentence means is that the change of used height has no effect on margin collapsing, period. however min-height or max-height might have an effect as defined in 8.3.1
# [17:04] <fantasai> Anton: So, you do all your calculations with height, but not big enough b/c have min-height, and have to redo the calculations
# [17:04] <fantasai> dbaron: Note says that you don't recompute anything wrt margin collapsing. it stays the way it was.
# [17:05] <fantasai> Anton: As in, all relationships of what collapses with what stays the same
# [17:05] <fantasai> dbaron: yes
# [17:05] <fantasai> Bert: Your rewrite of that sentence into the two parts is what I understand, yes.
# [17:05] <fantasai> fantasai also agrees
# [17:05] <dbaron> Possible rewrite of note: These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing. 'min-height' and 'max-height' only affect margin collapsing as specified by the rules in in "Collapsing margins" (8.3.1).
# [17:06] <fantasai> Anton: Ok, with that interpretation of the note... I think that doesn't add anything new to this.
# [17:06] <fantasai> Anton: Think suggestion of preventing margin-collapsing in this case is enough to solve the problem, and doesn't contradict what's intended by the other rules
# [17:07] * miketaylr is now known as miketaylr|
# [17:07] * Joins: nimbu (Adium@24.18.47.160)
# [17:07] <fantasai> Anton points at child inside larger box case
# [17:07] <fantasai> Anton: I don't think there's anything that says if this margin collapses with the other margin, which border it sticks to.
# [17:08] <fantasai> Anton: You'll get strange behavior either way, but not defined where the collapsed margin resides
# [17:08] <fantasai> Florian: If you say they dont' collapse... but that brings up other problems.
# [17:08] <fantasai> dbaron: Where do we define where the position of the next block is?
# [17:09] <fantasai> Anton: There is a whole issue on where is actually the top content edge
# [17:09] <fantasai> dbaron: We do actually define ... in [really convoluted case]
# [17:09] <fantasai> Anton: You might be right, there might be a loophole in a special case. But in the general case not defined.
# [17:09] <fantasai> ...
# [17:10] <fantasai> Anton: If we're going to collapse these two things, then it shoudl go to the parent. Otherwise it's really odd.
# [17:10] <fantasai> dbaron: 9.4.1 says the vertical distance between 2 sibling blocks is determined by the margin properties
# [17:10] <fantasai> Anton: With a big leap of faith you can make that work.
# [17:10] <fantasai> Bert: I know I tried to rewrite that in the Box Module...
# [17:11] <fantasai> fantasai: I think for things that are a bit handwavy and need a leap of faith.. well, it's an old spec. We need to rewrite all this, and shouldn't do that rewrite as 2.1
# [17:11] <fantasai> fantasai: Should just fix errors in it.
# [17:12] <fantasai> fantasai: So I believe there are two issues here.
# [17:12] <fantasai> fantasai: One is that if you have a self-collapsing only child and a min-height, don't collapse the child with the bottom parent margin
# [17:13] <fantasai> fantasai: Other one is, if a parent and child margins collapse, the collapsed margin is attached to the border edge of the parent.
# [17:13] * Quits: alexmog_ (alexmog@128.93.135.194) (Quit: alexmog_)
# [17:13] * Joins: alexmog_ (alexmog@128.93.135.194)
# [17:13] <fantasai> dbaron: I think we should say where the top of a block goes. Which right now we dont'
# [17:14] <fantasai> Anton: So we note this down as something that needs to be turned into proposed text, discuss that text on the telecon.
# [17:14] <fantasai> ACTION Anton: Record these two issues and the conclusion, point to these minutes, write a next-action to propose text.
# [17:14] * trackbot noticed an ACTION. Trying to create it.
# [17:14] * RRSAgent records action 16
# [17:14] <trackbot> Created ACTION-435 - Record these two issues and the conclusion, point to these minutes, write a next-action to propose text. [on Anton Prowse - due 2012-02-14].
# [17:15] <fantasai> Anton: Absolute positioning is defined in terms of the top margin edge of something.
# [17:15] <fantasai> Anton points us to definition of static position
# [17:15] <fantasai> dbaron: static position doesn't really matter, because UAs may approximate.
# [17:15] <fantasai> dbaron: I'd try 10.1 or 10.6.4 (?)
# [17:15] * Quits: alexmog_ (alexmog@128.93.135.194) (Quit: alexmog_)
# [17:15] <Rossen> http://www.w3.org/TR/CSS21/visudet.html#static-position
# [17:16] * Quits: miketaylr| (miketaylr@187.105.255.109) (Quit: Leaving...)
# [17:16] <fantasai> dbaron quotes from the spec the part about "... would have been the first box of the element ... specified clear had been none ..."
# [17:16] <dbaron> More precisely, the static position for 'top' is the distance from the top edge of the containing block to the top margin edge of a hypothetical box that would have been the first box of the element if its specified 'position' value had been 'static' and its specified 'float' had been 'none' and its specified 'clear' had been 'none'. (Note that due to the rules in section 9.7 this might require also assuming a different computed value for 'display'.)
# [17:17] <dbaron> (from 10.6.4)
# [17:17] <fantasai> Anton: Issue is that it says that the static position for top is from the top edge of the containing block.. to the top margin edge of the hypothetical position
# [17:18] <fantasai> Anton: So you need to know the top margin edge, which is not well-defined in most cases.
# [17:18] <fantasai> s/most/some/
# [17:18] <fantasai> Anton: If margins don't collapse, it's obvious where it is.
# [17:18] <fantasai> Anton: But when you have margin collapsing in general... you have this blob in the middle. can you really say where the top margin edge is?
# [17:18] <fantasai> Alex: top of the collapsed margin
# [17:19] <fantasai> dbaron: Does anyone know why we say top margin edge of the first child box rather than top content edge of the box itself?
# [17:19] <fantasai> dbaron: That might solve the problem. Or may be different and not what we mean.
# [17:20] <fantasai> Bert: ...
# [17:20] <fantasai> dbaron: nevermind that question
# [17:20] <fantasai> Anton: Top margin edge is not a wel-defined concept, except in exceptional cases
# [17:20] <fantasai> dbaron: I'm going to suggest this issue lead to someone writing test csaes to find out what implementations actually do
# [17:21] <fantasai> Anton: I think this was discussed by Oyvind from Opera, who wrote testcases, found there isn't an issue in practice, but spec doesn't reflect the practice.
# [17:21] <fantasai> Anton: Don't think we should define a top margin edge.
# [17:21] <fantasai> Anton: Example is, in the bug tracker somehwere.
# [17:21] <fantasai> Anton: There's very weird kind of things when you've got self-collapsing elements trapped in the middle of a collapsed margin
# [17:22] <fantasai> anton: Where the self-collapsing element has a 20px top margin, but when you calculate it's border position doesn't allow for a top margin of 20px
# [17:22] <fantasai> anton: There aren't enough pixels above the top border edge
# [17:22] <fantasai> Anton: B/c of this don't think we should define where the top margin edge.
# [17:22] <fantasai> Anton: Instead I think where it relies on the top marign edge, seems to be a consesnus that we should define it relation to the border edge, which is well-defined
# [17:23] <fantasai> Anton: We define static position in terms of the border edge, and then add the top margin edge onto it
# [17:23] <fantasai> Anton: as a correction
# [17:23] <fantasai> Steve: That seems to have the effect that in the collapsed margin case, ...
# [17:24] <fantasai> Anton: It would be this height above its border edge...
# [17:24] <fantasai> Anton: defining the top margin edge to be up here *points above the collapsed margin* doesn't make sense to me, so would rather not do that
# [17:25] <fantasai> Anton: [my suggestion] seems to match implementations
# [17:26] <fantasai> Alex: Example of what's defined as margin edge?
# [17:26] <fantasai> Anton: It's not defined. The text defines static position (10.6.4) in terms of the top margin edge, which is not defined.
# [17:26] <smfr> http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-height
# [17:27] <tantek> (ASIDE: regarding using -webkit- prefix, clarification re: Lea Verou - she's advocated using *both* vendor prefixed properties (multiple vendors) and the unprefixed version after them. See her talk http://www.slideshare.net/LeaVerou/css3-a-practical-introduction-ft2010-talk from Front-Trends 2010 for example. An actual example of -webkit- *only* prefix examples (thus implied advocacy) is Google's http://slides.html5rocks.com/ , e.g.
# [17:27] <tantek> http://slides.html5rocks.com/#css-columns has three -webkit- property declarations starting with -webkit-column-count )
# [17:27] <fantasai> dbaron: So, I'm ok with whatever bzbarsky is ok with, because I defer everything about static position to him.
# [17:27] <fantasai> dbaron: I also don't especially care. i think it's a horrible concept.
# [17:28] <Bert> (Something like: "More precisely, the static position for 'top' is a length A - B, where A is the distance from the top edge of the containing block to the top border edge of a hypothetical box that would have been the first box of the element if its specified 'position' value had been 'static' and its specified 'float' had been 'none' and its specified 'clear' had been 'none'; and B is the top margin of the element.")
# [17:28] <fantasai> Anton: b/c spec doesn't make sense as it is, important to make testcases, and check that proposed wording doesn't change the behavior of those test cases.
# [17:29] <fantasai> [Alex and Anton discuss the issue]
# [17:31] <fantasai> Alex: top: auto means it won't move in reasonable cases
# [17:31] <fantasai> Anton: ...
# [17:32] <fantasai> Alex: I'm not proposing recollapsing. Saying that for purposes of that position, margin is used [...]
# [17:34] <fantasai> Anton: The way i understand there's inline and block. Inline, no margins. If you make inline abspos, it will be shifted down by its margin.
# [17:34] <fantasai> fantasai disagrees
# [17:34] <fantasai> fantasai: Inline has a margin, it just doesn't affect line height
# [17:34] <fantasai> Alex: for block, we know very well ...
# [17:34] <fantasai> Alex: It's top margin, which we don't have to collapse with anything b/c it's positioned.
# [17:35] <fantasai> Alex: It's inline, it's out of flow.
# [17:35] <fantasai> Alex: To determine the static, all you do is look at the bottom of this line, and it's ... in the current flow and that's it
# [17:35] <fantasai> Alex: The top margin used for static calculation has now been collapsed
# [17:35] <fantasai> Alex: It's not even a block for purposes of static layout
# [17:35] <fantasai> Alex: it's a hypothetical situation
# [17:35] <fantasai> Alex: For hypothetical situation, nothing to collapse
# [17:35] <fantasai> Anton: Doesn't explain final result
# [17:36] * Joins: leaverou (leaverou@80.187.200.37)
# [17:36] <fantasai> Alex: Does. because abpsos elements are out-of-flow that have in-flow static position, determined by anonymous line
# [17:36] <fantasai> Anton: You're saying that abspos elements leave an inline-level placeholder
# [17:36] <fantasai> Anton: Even if they're blocks.
# [17:37] <fantasai> Anton: The spec definitely doesn't say that at the moment.
# [17:37] <fantasai> Anton: In tables it does.
# [17:37] <fantasai> Alex: Having something abspolutely positioned... a line.
# [17:37] <fantasai> Alex: element has no right ot colalpse with anything else because it has never been a block.
# [17:37] <fantasai> Alex: only hypotehtical
# [17:38] <fantasai> Alex: it's happening relative to that imaginary line, as if that was a line with some kind of content
# [17:38] <fantasai> Alex: With that no collapsing would happen
# [17:38] <fantasai> Anton: Where is the position of that line?
# [17:38] <fantasai> Anton: I see, would be anonymous self-collapsing block.
# [17:38] <fantasai> Anton: I'm fairly certain it doesn't leave behind a placeholder currently in the spec
# [17:38] <fantasai> Alex: ...
# [17:39] <fantasai> Alex: Abspos element is inline content
# [17:39] <fantasai> Alex: That for all other purposes is empty, but it has very well defined position
# [17:39] <fantasai> Anton: I understand the argument you're making, but I don't think the spec there.
# [17:40] <fantasai> Anton: Spec says to treat it as non-abspos to find its position, and if it's a physical inline-level box. You're redoing layout with a different assumption.
# [17:40] * tantek notes that this one issue has now taken 1 hr of f2f time.
# [17:40] <fantasai> Anton: But your'e saying when i's abpsos, it leaves behind a placeholder that affects layout.
# [17:40] * fantasai is not the chair
# [17:40] <fantasai> Alex: ...
# [17:40] <fantasai> Alex: That defines inline position of abspos
# [17:41] <fantasai> Alex: our implementation also has a line which might be empty which has a.. ok Rossen disagrees.
# [17:41] <fantasai> Anton: I honestly don't think that's what the spec says.
# [17:42] * Joins: lar_zzz (Adium@79.226.88.78)
# [17:42] <fantasai> Alex: I think it's good idea to define hypothetical position precisely.
# [17:42] <fantasai> Alex: Rossen do you disagree with anything I said?
# [17:42] <fantasai> Rossen: abspos elements that are blocks, ... we do not collapse margins
# [17:42] <fantasai> Rossen: So, we will not use the collapsed position for abspos elements.
# [17:42] <fantasai> Rossen: This is what everyone currently does
# [17:42] <fantasai> Rossen: I agree with Alex on something he said in the beginning.
# [17:43] * Joins: Ms2ger (Ms2ger@91.181.83.228)
# [17:43] <fantasai> Rossen: which is, if we insist to keep this top margin position, then we also need to specify it if the margin didn't collapse
# [17:43] <fantasai> Rossen: When it said you must treat it as if it's positoin static, and float is what it was, et.c etc. You'd add another one that says "And margins of this element did not collapse"
# [17:43] <fantasai> s/rossen/Anton/
# [17:43] <fantasai> Rossen: But that to me seems to open a can of worms.
# [17:44] <fantasai> Anton: Your'e saying if it was a static block, imagine you had a static block, and its' float was not reset to none, and clear really ahd an effect, and imagine that it didn't collapse any margins...
# [17:44] <fantasai> Anton: But you have to be more specific: not collapse which margins?
# [17:44] <fantasai> Alex: ...
# [17:44] <fantasai> Anton: Part of ccalculating stitc position is you ignore margins..?
# [17:45] <fantasai> Anton: b/c what happens with its children and their marigns, which used to collapse/not collapse
# [17:45] <fantasai> Anton; i think testcases are the way to go here.
# [17:45] <fantasai> s/;/:/
# [17:45] <fantasai> Anton: Don't think it's as simple as saying "don't collapse margins"
# [17:45] <fantasai> Anton: Of course won't collapse it's margins when its positioned anyway
# [17:45] <fantasai> Anton: b/c won't collapse once it's been abspos
# [17:46] <fantasai> Alex: ... a lot of simplifications to not overcomplicate the positioning
# [17:46] <fantasai> Alex: A lot of ... are not going to happen the same way as in normal layout
# [17:46] <fantasai> Anton: I don't have an opinion on this, just as the moment it's not currently well-defined.
# [17:46] <fantasai> Anton: Need a way to define it. Which *might* be placeholders, or [...]
# [17:46] <fantasai> Rossen: Asked for action item to have a section on that in css3-positioning
# [17:47] <fantasai> Anton: We still need to do something for CSS2.1, because the text doesn't make sense atm because it relies on an undefined concept.
# [17:47] * Parts: smfr (smfr@128.93.134.211)
# [17:47] <fantasai> Anton: The proposal on the list was to do it in terms of border position, then tweak it to account for the margin.
# [17:47] <fantasai> Alex: UAs are free to make a guess, so that makes it completely free.
# [17:48] * Joins: smfr (smfr@128.93.134.211)
# [17:49] <fantasai> fantasai: So, we've been discussing this for awhile. How about you write proposed text in terms of the border edge, since it seems that's a good way to go. And if Alex wants to implement that in terms of a placeholder in a line box in a self-collapsing anonymous block, that's fine.
# [17:49] * Quits: antonp (805d8798@207.192.75.252) (Quit: http://www.mibbit.com ajax IRC Client)
# [17:50] <fantasai> fantasai: Just make sure there's testcases and the spec *results* match implementation *results*
# [17:50] <fantasai> ACTION Anton: write proposed text and testcases
# [17:50] * RRSAgent records action 17
# [17:50] * trackbot noticed an ACTION. Trying to create it.
# [17:50] <trackbot> Created ACTION-436 - Write proposed text and testcases [on Anton Prowse - due 2012-02-14].
# [17:50] <fantasai> Anton: Does the root element establish a BFC root
# [17:50] <fantasai> ?
# [17:51] * Joins: arno (arno@192.150.10.200)
# [17:51] <fantasai> dbaron: I think it's established by the ICB, not the root element
# [17:52] <fantasai> Rossen: If you want to model the browser window, how would you do it? you would create a <div> with fixed size, and make it overflow: auto so you get scrollbars. That's your viewport
# [17:52] <fantasai> Rossen: This is what we do in IE.
# [17:52] <fantasai> Rossen: ICB is not exception to anything
# [17:52] <fantasai> Rossen: It's just an element, just not accessible to OM
# [17:53] <fantasai> Rossen: If this is what you mean, then I agree it should be a BFC.
# [17:53] <fantasai> Rossen: If you mean the root element, then should be driven by properties.
# [17:53] <fantasai> Florian: I believe in Opera we treat the root element as an abspos.
# [17:54] <fantasai> Rossen: Up to impleemnter, but if you model this as an element, but needs to have auto scrollbars, so needs to be a BFC.
# [17:54] <fantasai> fantasai: Root element is not the ICB
# [17:55] <fantasai> Anton: I'm talking about the document root element
# [17:56] <dbaron> https://www.w3.org/Bugs/Public/
# [17:56] <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15702
# [17:57] <dbaron> https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
# [17:57] <fantasai> dbaron suggests people to run this testcase
# [17:57] <fantasai> dbaron: Question is, where is the orange bar?
# [17:58] <fantasai> dbaron: chrome has changed to match Gecko since this was written
# [17:59] <fantasai> deferred to tomorrow
# [17:59] <TabAtkins_> http://wiki.csswg.org/spec/process
# [17:59] <fantasai> Topic: Spec Process
# [18:00] <fantasai> Tantek: Started to try document our spec development process, and how we try to move faster within W3C process
# [18:00] <fantasai> Tantek: Top is complaints we have
# [18:00] <fantasai> Tantek: Trying to look at positive side here, how to improve in the future
# [18:00] <fantasai> tantek: Have some principles
# [18:00] <fantasai> Tantek: Publish early and often to show interest/activity
# [18:00] <fantasai> Tantek: Transparently note objections/issues
# [18:01] <fantasai> Tantek: Advance as rapidly impelmentations and tests show interop
# [18:01] <fantasai> Tantek: Drop /postpone features lacking implementations rather than trying to keep things togethers.
# [18:01] * Joins: antonp (805d8798@78.129.202.38)
# [18:01] <fantasai> Tantek: In short, I think any editor, anyone in CSSWG shoudl be able to check in editor's draft that agrees with the charter.
# [18:01] <fantasai> Tantek: When objections are noted, editor's responsiblity to include in the draft.
# [18:02] <fantasai> glazou: ... No, not possible. Would break discusison of [...]
# [18:02] <fantasai> glazou: Any idea must be proposable to the WG, and our role afterwards to decide whther to inlcude charter
# [18:02] <fantasai> plinss: Stike requirement that it be in the Chater
# [18:02] <fantasai> ChrisL: That first point is about transition *to* editor's draft
# [18:02] <fantasai> plinss: For example Tab's hierarchies thing. He's not creating an editor's draft, he's creating a proposal.
# [18:03] <fantasai> plinss: From idea to proposal document, anyone can chekc anything in, doesn't have to match our charter
# [18:03] <fantasai> plinss: To move from proposal to ED, need to have a charter discussion
# [18:03] <fantasai> Tantek: Next one is important. Sometiems takes way too long for EDs to bpulsiehd as FPWD. We need to be much be more active about this.
# [18:03] <fantasai> Tantek: Suggest that as soon as something is implemented, we push it to FPWD.
# [18:04] <fantasai> ChrisL: Why wait that long? Does that mean without implementation, you can't publish FPWD?
# [18:04] <fantasai> Tantek: No, this is saying to treat it as a forcing function.
# [18:05] * Quits: leaverou (leaverou@80.187.200.37) (Ping timeout)
# [18:05] <fantasai> glazou: I have one big concern with this step. if the implementation impelments something that is not stabilized, and even under strong scrutiny and criticism, the implementation won't reflect the discussion and the fact that it's not stabilized
# [18:05] <fantasai> q+
# [18:05] <fantasai> glazou: This is WHATWG approach that specs do not matter, only implementers do
# [18:05] <dbaron> q+
# [18:05] <fantasai> zakim, q+
# [18:05] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [18:05] <fantasai> q+
# [18:05] * Zakim sees fantasai on the speaker queue
# [18:06] <fantasai> ChrisL: earlier is better b/c of IP timer
# [18:06] <fantasai> ChrisL: As soon as there's a list of features, even not clear what they are, that's when you want to push for FPWD
# [18:06] <glazou> Zakim, ack dbaron
# [18:06] <Zakim> I see fantasai on the speaker queue
# [18:06] <fantasai> dbaron: So, what it looks to me,
# [18:07] <fantasai> dbaron: If someone believes there is something in a draft they believe should not be in CSS, the first point to object is the PR boat.
# [18:07] <ChrisL> because there is a 150 day exclusion period. and any feature not in that fpwd can still be excluded following last call
# [18:07] <fantasai> Tantek: No, edit'rs draft. Has to be documented in the editor's draft.
# [18:07] <fantasai> dbaron: But what does that note lead to? Does the note end up in a PR?
# [18:07] <fantasai> Tantek: Point of note is to list it as there being contention.
# [18:08] <fantasai> glazou: Note that editor's draft can be modified without WG approval.
# [18:08] <plinss> ack fantasai
# [18:08] * Zakim sees no one on the speaker queue
# [18:08] <dbaron> fantasai: I think one of dbaron's points -- that the current policy of the WG that we go to FPWD when there's agreement that we want to work on it.
# [18:08] <dbaron> fantasai: And if we don't get to that agreement we don't publish as FPWD.
# [18:08] <dbaron> fantasai: We have to get consensus in the WG that we want to work on it before we go to FPWD, and that's not reflected here.
# [18:09] <dbaron> Tantek: That's part of the goal is to prevent somebody to stop something from being published just by objecting.
# [18:09] <dbaron> q+
# [18:09] * Zakim sees dbaron on the speaker queue
# [18:09] <dbaron> plinss: She's talking about whether there's even consensus to work on the draft.
# [18:09] <dbaron> sylvain: Take the hierarchies example earlier today.
# [18:09] <fantasai> plinss: I don't think it makes sense to publish FPWD of something where there's no consensus to work on it.
# [18:10] <fantasai> fantasai^: [something about ijppementation plus draft menas I have a standard to put on /tr as representing WG consensus\
# [18:10] <fantasai> ]
# [18:10] <fantasai> Steve: But you don't get ED without a consensus
# [18:10] <fantasai> Tantek: if you have a shipping implementation, you should get FPWD
# [18:10] <fantasai> glazou: I strongly object to that.
# [18:10] <fantasai> plinss: We have things we've publishe dand then lost interest in.
# [18:10] <fantasai> plinss: Don't think we need a forcing function here.
# [18:11] <dbaron> So I think a problem with this model is that these transitions lead to implementations as well.
# [18:12] <fantasai> fantasai: Why are we distinguishing Proposal vs. Editor's Draft Without FPWD? If we have agrement to work on something, it should go to PFWD. Why not have it on /TR?
# [18:12] <fantasai> dbaron: I think the underlying issue that this idea doesn't consider is that all of these transitions themselves cause implementations.
# [18:12] <fantasai> dbaron: The act of putting something on dev.w3.org increases the possibility of implementation.
# [18:12] <fantasai> dbaron: Pushing to FPWD makes it more likely.
# [18:12] <fantasai> dbaron: We have the power to influence what gets implemented. And we should consider how we use it.
# [18:13] <fantasai> Tantek: Problem is we are being behind. Editor's drafts are being published an dimplemented. W3C Process is being circumvented, and nobody's talking about it.
# [18:13] <fantasai> Tantek: Stuff is happening, let's move forward.
# [18:13] <fantasai> glazou: An editor's draft can be modified without WG approval.
# [18:13] <dbaron> s/to FPWD/to FPWD maybe/
# [18:13] <fantasai> glazou: Which means a member of this WG can edit a draft, and the draft gos to FPWD without approval of the WG. I don't want that.
# [18:14] * Joins: leaverou (leaverou@80.187.200.37)
# [18:14] <fantasai> Florian: Your model assumes any proposal is a positive one.Which is not necessarily true.
# [18:14] <plinss> ack dbaron
# [18:14] * Zakim sees no one on the speaker queue
# [18:14] <fantasai> Florian: I think if something ships and we don't have a WD, we should be considering it. But we shouldn't automatically go to draft. It should be a trigger to consider it.
# [18:14] <fantasai> glazou: It should go on the radar of WG. But that's already the case.
# [18:15] <fantasai> plinss: If these are phrased as these force us to discuss it, that's fine.
# [18:15] <fantasai> glazou: A WD is published automatically? *shakes head*
# [18:15] <fantasai> plinss: We can't publish a transition without a group resolution.
# [18:15] <fantasai> Steve: I was just going to say, W3C took action to change submissions from TRs to put them in a different place b/c they found the system was being gamed by ppl writing things and submitting them and saying they're now a W3C spec, 'cuz now on the W3C site.
# [18:16] <fantasai> Steve: So there is reason for what Florian and Daniel said. Need consideration to keep people gaming the system.
# [18:16] <fantasai> Tantek: It's worse now. /TR doesn't matter anymore. Editor's drafts are being implemented.
# [18:16] <fantasai> Steve: Saying that you're shipping a W3C standard...
# [18:16] <fantasai> Tantek: They say they're implementing a W3C standard and link to editor's draft
# [18:16] <fantasai> jdaggett: That's a little bit of a separate issue.
# [18:16] <fantasai> Steve: I don't believe we're contributing to that piece of it.
# [18:17] <fantasai> jdaggett: I think you're tyring to accelerate things base d on impelemtations bieng available.
# [18:17] <fantasai> jdaggett: Problem is you start spitting out specs in chunks. deifnitely be more confusing.
# [18:17] <fantasai> smfr: We just did that with css3-images
# [18:17] <fantasai> Steve: We're collecting implementation reality. That's a good thing.
# [18:17] <fantasai> plinss: As long as you have interoperable implementations, then ..
# [18:17] <fantasai> jdaggett: You realize this means this is beginning of every spec is one property. Every property has one spec.
# [18:18] <fantasai> Florian: Not necessarily. Did for gradients because there is urgency on gradients themselves.
# [18:18] <fantasai> glazou: Don't make it one implementation. Make it two. Then you don't have a working draft, you have a CR. You can even ahve impleementation reports and move fast.
# [18:18] <fantasai> glazou: Have browser vendors propose things that are more stable.
# [18:19] <fantasai> Tantek: Let me finish summarizing.
# [18:19] <fantasai> Tantek: From WD to LC, as soon as any feature has two itneroperable implementations, according to test suites etc,
# [18:19] <fantasai> Tantek: The draft goes to Last Call. Any features that are not implemented at all get listed as at-risk.
# [18:19] <fantasai> Tantke: Next step is CR.
# [18:19] <fantasai> glazou: For step 2 have a problem.
# [18:20] <fantasai> glazou: In history of WG, we have never made test suites before CR. Not sure that members have showed enough commitment to require test suites before CR.
# [18:20] <fantasai> glazou: We've tried.
# [18:20] <fantasai> glazou: Unless we move to CR, no point.
# [18:20] <fantasai> ChrisL: But we can encourage that. And often people post samples.
# [18:20] <fantasai> ChrisL: Just collect examples in your spec and you have some tests.
# [18:20] <fantasai> glazou: I can live with it, we can try.
# [18:20] <fantasai> plinss: Reality is as soon as someone writes impelmetnation, they are writing their own tests. They just need to write them in W3C format.
# [18:21] <fantasai> Tantek: Anyone can show a test that disproves your interop.
# [18:21] <fantasai> Tantek: During LC period.
# [18:21] <fantasai> Tantek: That resets 6-week LC period.
# [18:21] <fantasai> Tantek: At the end of that LC period, it goes to CR. Then everything with no implementations get dropped. Everything with only one implementation gets at-risk.
# [18:21] <fantasai> Tantek: During CR period, eidtor can iterate based on implementation experience.
# [18:21] <fantasai> glazou: I think this part of automati cprocess I agree more.
# [18:22] <dbaron> I've sent the whiteboard photos from the 2.1 discussion to www-style, but they haven't gotten through yet.
# [18:22] <dbaron> er, to www-archive
# [18:22] <fantasai> glazou: At the end of LC review period, shift to CR *unless* LC period has shown blockers.
# [18:22] <fantasai> glazou: Can have interoperably implemented with design issues that may harm the Web in the future
# [18:22] <fantasai> Steve: non-internationalizable, etc.
# [18:22] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2012Feb/0011.html
# [18:22] <dbaron> http://lists.w3.org/Archives/Public/www-archive/2012Feb/0010.html
# [18:22] <fantasai> Florian: We can set these as expectations, but not automatic. Look at them one by one.
# [18:23] <dbaron> with timestamps in CET
# [18:23] <dbaron> (in the message body)
# [18:23] <fantasai> Tantek: At the end of 6mo CR period
# [18:23] <arron> dbaron, thanks for doing that I will hopefully be able to understand the 2.1 conversation better now.
# [18:23] <dbaron> and metadata in UTC
# [18:23] * Quits: ChrisL (ChrisL@128.30.52.169) (Client exited)
# [18:23] <fantasai> Tantek: Then it "automatically" goes to PR, and any feature not interop by test suite gets dropped.
# [18:23] <fantasai> Tantek: When I say dropped, I mean postponed.
# [18:23] <fantasai> Tantek: You just missed the train.
# [18:24] <dbaron> fantasai: Maintaining multiple versions of the same draft is annoying; don't want to do that just so we can do CR->REC every 6 months.
# [18:24] * Quits: glenn_ (gadams@174.29.125.223) (Ping timeout)
# [18:24] <fantasai> Tantek: Trying to provide path for editor's accelerating their wok.
# [18:24] <fantasai> work
# [18:24] * Quits: jdaggett (jdaggett@128.93.135.115) (Quit: jdaggett)
# [18:25] * Quits: smfr (smfr@128.93.134.211) (Quit: smfr)
# [18:25] <fantasai> Florian: As long as these are expectations, not automatic triggers, it's okay.
# [18:26] * Quits: glazou (glazou@128.93.135.193) (Quit: glazou)
# [18:26] <fantasai> Meeting closed.
# [18:26] * Quits: jet (jet@128.93.134.233) (Quit: jet)
# [18:26] * Quits: astearns (qw3birc@128.30.52.28) (Ping timeout)
# [18:27] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [18:27] * Quits: alexmog__ (qw3birc@128.30.52.28) (Ping timeout)
# [18:27] * Quits: florian (florianr@128.93.135.177) (Ping timeout)
# [18:27] * Quits: vhardy_ (qw3birc@128.30.52.28) (Ping timeout)
# [18:27] * Quits: Rossen (Rossen@128.93.134.230) (Ping timeout)
# [18:27] * Quits: CGI232 (805d87e1@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
# [18:28] * plinss is now known as plinss_away
# [18:28] * Parts: antonp (805d8798@78.129.202.38)
# [18:28] * Quits: TabAtkins_ (tabatkins@74.125.122.49) (Ping timeout)
# [18:29] * Joins: ksweeney (ksweeney@63.119.10.10)
# [18:30] * Quits: dbaron (dbaron@128.93.135.77) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:31] * Joins: glenn (gadams@174.29.100.187)
# [18:31] * Quits: glenn (gadams@174.29.100.187) (Client exited)
# [18:34] * Quits: kojiishi (kojiishi@128.93.135.158) (Ping timeout)
# [18:35] * Quits: tantek_ (tantek@128.93.135.73) (Quit: tantek_)
# [18:35] * Quits: tantek (tantek@128.93.135.10) (Quit: tantek)
# [18:36] * sylvaing is now known as sylvaing_away
# [18:36] * plinss_away is now known as plinss
# [18:37] * Quits: howcome (howcome@128.93.135.80) (Ping timeout)
# [18:46] * Quits: leaverou (leaverou@80.187.200.37) (Ping timeout)
# [18:47] * plinss is now known as plinss_away
# [18:50] * Joins: leaverou (leaverou@80.187.200.37)
# [18:55] * Parts: lar_zzz (Adium@79.226.88.78)
# [18:57] * Quits: leaverou (leaverou@80.187.200.37) (Ping timeout)
# [19:00] * Joins: leaverou (leaverou@80.187.200.37)
# [19:13] * Joins: miketaylr (miketaylr@187.105.255.109)
# [19:17] * Quits: leaverou (leaverou@80.187.200.37) (Quit: leaverou)
# [19:35] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [19:37] * Joins: arno (arno@192.150.10.200)
# [19:39] * Quits: drublic (drublic@77.2.157.148) (Ping timeout)
# [20:07] * Parts: ksweeney (ksweeney@63.119.10.10)
# [20:11] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [20:16] * Quits: karl (karlcow@128.30.54.58) (Quit: :tiuQ tiuq sah woclrak)
# [20:36] * Zakim excuses himself; his presence no longer seems to be needed
# [20:36] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [20:38] * Joins: arronei (arronei@131.107.0.118)
# [20:39] * Quits: arronei_ (arronei@131.107.0.112) (Ping timeout)
# [20:41] * Joins: glenn (gadams@192.160.73.102)
# [21:17] * Joins: arno (arno@192.150.10.200)
# [22:03] <Ms2ger> vhardy, hope you don't mind the bugspam :)
# [22:03] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [22:05] * Joins: arno (arno@192.150.10.200)
# [22:11] * Joins: lar_zzz (Adium@79.226.88.78)
# [22:11] * Joins: drublic (drublic@77.2.136.131)
# [22:24] * plinss_away is now known as plinss
# [22:26] * Quits: Ms2ger (Ms2ger@91.181.83.228) (Quit: nn)
# [22:37] * Quits: lar_zzz (Adium@79.226.88.78) (Quit: Leaving.)
# [22:47] * Joins: jdaggett (jdaggett@81.56.65.178)
# [22:55] * Quits: jdaggett (jdaggett@81.56.65.178) (Quit: jdaggett)
# [23:09] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [23:09] * Joins: arno (arno@192.150.10.200)
# [23:31] * Quits: miketaylr (miketaylr@187.105.255.109) (Quit: Leaving...)
# [23:36] * Joins: TabAtkins_ (tabatkins@90.46.85.61)
# Session Close: Wed Feb 08 00:00:00 2012

The end :)