/irc-logs / w3c / #css / 2010-08-24 / end

Options:

# Session Start: Tue Aug 24 00:00:00 2010
# Session Ident: #css
# [00:03] * Joins: tantek (tantek@84.208.66.187)
# [00:07] * Joins: dstorey (dstorey@213.236.208.22)
# [00:07] * Quits: tantek (tantek@84.208.66.187) (Quit: tantek)
# [00:08] * Joins: dsinger (dsinger@84.208.65.171)
# [00:08] * Parts: dsinger (dsinger@84.208.65.171)
# [00:21] * Quits: Arron (arronei@84.208.66.187) (Ping timeout)
# [00:33] * Quits: dstorey (dstorey@213.236.208.22) (Quit: dstorey)
# [00:44] * Joins: Arron (arronei@84.208.66.187)
# [00:55] * Joins: alexmog (alexmog@77.88.66.165)
# [01:46] * Quits: alexmog (alexmog@77.88.66.165) (Quit: alexmog)
# [02:32] * Quits: Arron (arronei@84.208.66.187) (Ping timeout)
# [02:45] * Joins: Arron (arronei@84.208.66.187)
# [02:55] * Quits: Curt` (DorkeyDear@75.10.129.150) (Ping timeout)
# [03:25] * Quits: Arron (arronei@84.208.66.187) (Ping timeout)
# [04:49] * Joins: Curt` (DorkeyDear@75.10.129.150)
# [06:25] * Quits: Curt` (DorkeyDear@75.10.129.150) (Quit: Leaving)
# [06:31] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [06:41] * Joins: nimbupani (nimbupani@24.22.131.46)
# [07:43] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [07:46] * Joins: dsinger (dsinger@84.208.66.187)
# [07:47] * Quits: dsinger (dsinger@84.208.66.187) (Connection reset by peer)
# [07:48] * Joins: dsinger (dsinger@84.208.66.187)
# [08:23] * Quits: dsinger (dsinger@84.208.66.187) (Quit: dsinger)
# [08:45] * Joins: glazou (glazou@213.236.208.247)
# [08:45] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [08:45] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [08:45] <RRSAgent> logging to http://www.w3.org/2010/08/24-CSS-irc
# [08:46] <glazou> RRSAgent, make logs public
# [08:46] <RRSAgent> I have made the request, glazou
# [08:57] * Quits: davve (davve@83.218.67.122) (Client exited)
# [09:05] * Joins: oyvind (oyvinds@213.236.208.22)
# [09:06] * Joins: dstorey (dstorey@193.213.156.111)
# [09:06] * Joins: dsinger (dsinger@213.236.208.247)
# [09:07] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [09:07] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [09:07] * Joins: dsinger (dsinger@213.236.208.247)
# [09:07] * Joins: anne5 (annevk@213.236.208.247)
# [09:08] * Joins: JohnJansen (qw3birc@128.30.52.28)
# [09:09] * Joins: jdaggett (jdaggett@213.236.208.247)
# [09:10] * Joins: mollydotcom (mollyh@213.236.208.247)
# [09:10] <Bert> scribenick: bert
# [09:10] * Joins: Arron (arronei@213.236.208.247)
# [09:10] <Bert> Tantek: Add UI to end of extra topics list?
# [09:11] <Bert> Glazou: OK
# [09:11] * Joins: dbaron (dbaron@213.236.208.247)
# [09:12] <Bert> Topic: GCPM
# [09:12] <Bert> Hakon introduces Leif, from Opera
# [09:12] <anne5> dsinger, http://dev.w3.org/csswg/cssom/ is the draft
# [09:13] * Joins: davve (davve@83.218.67.122)
# [09:13] <anne5> dsinger, last updated a couple of days ago; CSS Value API is the thing that I want to work out next
# [09:13] * Joins: dsinger_ (dsinger@213.236.208.247)
# [09:13] <Bert> Leif introduces himself. Worked on microformats, among other things.
# [09:13] * Joins: jdaggett_ (jdaggett@213.236.208.247)
# [09:13] <Bert> Interested in hit testing.
# [09:13] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [09:13] * dsinger_ is now known as dsinger
# [09:13] * Quits: jdaggett (jdaggett@213.236.208.247) (Connection reset by peer)
# [09:13] * jdaggett_ is now known as jdaggett
# [09:14] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (Connection reset by peer)
# [09:14] <Bert> Hakon: GCPM is [not] the garbage collection module. :-)
# [09:14] <Bert> ... We have two impls of most of the features.
# [09:15] <Bert> ... Prince and AntennaHouse.
# [09:15] * Quits: glazou (glazou@213.236.208.247) (Connection reset by peer)
# [09:15] * Joins: glazou (glazou@213.236.208.247)
# [09:15] <Bert> ... Last time we cut out the mst experimental stuff.
# [09:15] <Bert> .. What's left is ready for CR this year.
# [09:15] <Bert> ... (First LC, of course.)
# [09:15] * Joins: CesarAcebal (acebal@213.236.208.247)
# [09:15] <Bert> s/.. Wha/... Wha/
# [09:16] <Bert> John: Hyphenation is more useful than just print, should move to othe rmodule.
# [09:16] <glazou> +1
# [09:16] <Bert> Hakon: Several things are not just for print.
# [09:16] <Bert> ... I *do* like hyphenation to move fast.
# [09:16] * Joins: szilles (chatzilla@213.236.208.247)
# [09:16] <Bert> ... Not sure Text module will move faster.
# [09:17] <Bert> Glazou: But the title of the module is "Print."
# [09:17] <glazou> s/Print/Paged
# [09:17] <Bert> s/Print/Paged/
# [09:17] * Joins: alexmog (alexmog@213.236.208.247)
# [09:17] <Bert> Hakon: A question about hyphen was how to do hyphenation dictionaries.
# [09:18] <Bert> ... Could be a separate module,
# [09:18] <Bert> Dave: As a naive user, I'd look for hyphenationin Text module
# [09:18] <Bert> Hakon: And how about a separate module?
# [09:18] <Bert> Dave: That works, too.
# [09:18] <Bert> John Related to justification.
# [09:19] <Bert> s/John/John:/
# [09:19] <Bert> Tantek: What languages do the impls. hyphenate?
# [09:19] <Bert> Hakon: Whatever they have dictionaries for. Prince uses TeX hyphenation algo and dicts,
# [09:20] <Bert> ... The 'hyphenate-resource' points to the dict.
# [09:20] <Bert> John: Format of those files defined?
# [09:20] <Bert> Hakon: No, like 'icon', it is not defined what the reosurce format is.
# [09:21] <Bert> ... TeX is well-defined.
# [09:21] <Bert> Fantasai: Fonts have a way to specify format.
# [09:21] <Bert> John: It's not more than a hint, still need to ask server.
# [09:22] <Bert> Hakon: Should it be the same as in fonts, then?
# [09:22] <Bert> John: One reason fonts is the way it is is that there was no font mime type.
# [09:22] <Bert> Hakon: OpenOffice uses a different format, derived from TeX but not the same.
# [09:23] <Bert> ... So there is indeed a problem.
# [09:23] <Bert> ... But the impls. expect to ship with their own resources.
# [09:24] <Bert> John: Sometimes want to use system resource insyead of the url of the 'hyp-resource'property
# [09:25] <Bert> fantasai: Use a 'local' value to allow local resources.
# [09:25] <Bert> Glazou: The proeprty is currently meant for exteranl (additional) resulrces only.
# [09:25] <Bert> Dave: So you can get control by putting a 'local' value somewhere in the list.
# [09:26] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [09:26] <Bert> fantasai: Mentionsomewhere that UA doesn't *have* to parse and use the external resources,
# [09:26] <Bert> John: Is that handled as a synatx error?
# [09:26] <Bert> fantasai: No, just not a supported value.
# [09:27] <Bert> Steve: How does it show up? Do you need to parse the property?
# [09:27] * Joins: lstorset (lstorset@213.236.208.247)
# [09:27] <Bert> glazou: From a pov of testing, failing the test is still succes.
# [09:27] <Bert> ... DOM doesn't matter for that.
# [09:28] <Bert> Hakon: A more experimental, but very useful feature is 'hyphens: all'
# [09:28] <Bert> ... It puts a marker in the text at *all* possible hyphenation points.
# [09:29] <Bert> John: Limit to certain number of lines?
# [09:29] <Bert> Hakon: See 'hyphenate-lines'
# [09:29] <Bert> [Discussion about the keyword 'no-limit']
# [09:30] <Bert> John: Can you hyphenate arabic?
# [09:30] <Bert> fantasai: Yes, I think so.
# [09:30] <Bert> Hakon: Justification can be used with or without hyphenation.
# [09:30] <Bert> Fantasai: Typical impl. is to hyphanate first, then justify the resulting lines.
# [09:31] <Bert> glazou: Hyphenate character: in some languages, you use a symbold both before and after the break. Is it always the same character?
# [09:32] <Bert> ... That has to be checked.
# [09:32] <Bert> Hakon: Do we need to go as far as support a pair of characters?
# [09:32] * Joins: dstorey_ (dstorey@213.236.208.247)
# [09:32] <Bert> Steve: Ask the i18n WG...
# [09:32] <Bert> glazou: If you have hyphenation, you need to do this as well.
# [09:33] <Bert> [Dave gives example of old italian.]
# [09:33] <Bert> glazou: May need a separate property.
# [09:34] <Bert> Hakon: Chris drew hanging hyphen. How do you do that?
# [09:34] <Bert> fantasai: That is in Tetx module.
# [09:34] * glazou there's another _current_ european language using char before AND after the hyphenation break
# [09:34] * Quits: dstorey (dstorey@193.213.156.111) (Ping timeout)
# [09:35] <Bert> JohnJ: Could you find that in the dict?
# [09:35] <Bert> fantasai: Don't know.
# [09:35] <dsinger> s/Tetx/Text/
# [09:35] <Bert> Hakon:Does anybody volunteer to do the research?
# [09:36] <Bert> glazou: We originally thought for list module to only have something simple. We were very wrong. Still not have all cases.
# [09:37] <Bert> Hakon: I'd say reasonable approach is to provide what TeX provides.
# [09:37] <Bert> glazou: We have an I18N group, let's ask them.
# [09:37] <Bert> ... When they don't repsond, we can go ahead ourselves.
# [09:38] <Bert> Chris: Could make 'hyp-char' a shorthand.
# [09:38] <Bert> fantasai: Not really ncessary to make separate proeprties if they don't cacade independently.
# [09:39] <Bert> Hakon: One common knob is to not allow hyphen on last line. No property for that currently.
# [09:40] <Bert> fantasai: Can suggest in the spec that UA *should* not hyphenate the last line of the page.
# [09:40] <Bert> glazou: It is not a "should."
# [09:40] <Bert> fantasai: Ask for it in LC.
# [09:41] <fantasai> People can ask for it in LC
# [09:41] <fantasai> if they really feel it's needed
# [09:41] <Bert> glazou: 'hyphenate: auto avoid'?
# [09:41] <Bert> John: Need a way to indicate languages?
# [09:42] <Bert> fantasai: The lang= attribute.
# [09:42] <Bert> John: But then need language selector. Can also mark the hyphenate resource with a language.
# [09:42] <Bert> fantasai: If the doc doesn't indicate language, it will not be hyphenated.
# [09:43] <Bert> glazou: Why is the resource a proeprty and not an at-rule?
# [09:43] <Bert> Hakon: Possibly use different dicts for diff elements.
# [09:43] <Bert> Dave: Could be a technical dict for special terms.
# [09:44] <Bert> fantasai: But glazou was asking if that can eb a global resource.
# [09:44] <Bert> Steve: But if there are two languages?
# [09:44] <Bert> fantasai: Need to set a global resource *per language*
# [09:45] <Bert> Dave: Still need to suppress hyphens for certain elements.
# [09:45] <fantasai> glazou's point is that there doesn't seem to be a need for setting dictionary resources per element, only per language per document
# [09:45] <Bert> glazou: Can still turn it off per elt.
# [09:46] * Joins: dsinger_ (dsinger@213.236.208.247)
# [09:46] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [09:46] * Quits: jdaggett (jdaggett@213.236.208.247) (Connection reset by peer)
# [09:46] * Quits: CesarAcebal (acebal@213.236.208.247) (Connection reset by peer)
# [09:46] * Quits: dstorey_ (dstorey@213.236.208.247) (Connection reset by peer)
# [09:46] * Quits: glazou (glazou@213.236.208.247) (Connection reset by peer)
# [09:46] <Bert> Steve: Say I want math and chemistry, would need two dicst.
# [09:46] * dsinger_ is now known as dsinger
# [09:46] * Joins: CesarAcebal (acebal@213.236.208.247)
# [09:46] * Joins: jdaggett (jdaggett@213.236.208.247)
# [09:46] * Joins: dstorey (dstorey@213.236.208.247)
# [09:46] * Joins: glazou (glazou@213.236.208.247)
# [09:46] <Bert> [Discussion about wording: "try resources *in turn*, *in order*...]
# [09:47] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (Ping timeout)
# [09:47] <Bert> fantasai: Compares more to 'font' or to @font-face'?
# [09:48] <Bert> Dave: But the math/chem example is only a pb if there is a word that it is hyphenated differently in them.
# [09:49] <Bert> Chris: LANG= allows extensiona fter the dash: en-chemical, etc,
# [09:49] <Bert> Steve: But then you ened to change your mark-up.
# [09:49] <Bert> Chris: But it probably belongs in the mark-up.
# [09:50] <Bert> glazou and fantasai draw on the board: @htphen-doc { en-us: url(en.hy); ... }
# [09:51] <Bert> Hakon: What is the reason for at-rule over prop?
# [09:51] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [09:51] <Bert> glazou: Performance (only one, and fewer props) and conceptual.
# [09:52] <Bert> ... Performance is even a pb for batch processors, if style and doc grows.
# [09:52] <dsinger> if you need to differentiate your danish-mathematics from your danish-chemistry because (for example) there is a word that is hyphenated differently in the two, I *think* you would be able to use a BCP 47 private use subtag, and still associate hyphenation rules and dictionaries 'globally' with a BCP 47 language tag
# [09:52] <Bert> glazou: Would you wait for a download of a dict when rendering an element?
# [09:53] <Bert> glazou: I want the at-rule to come before any other rules.
# [09:53] <Bert> [several: seems not important]
# [09:54] <fantasai> [to enforce putting it first]
# [09:54] <Bert> Alex: I like the at-rule.
# [09:54] <Bert> Tantek: Seems indeed analogous to @font-face.
# [09:54] <Bert> Hakon: How do you reference them in the style rules?
# [09:55] <Bert> Glazou: The 'hyphens' property can refer to the resource.
# [09:55] <Bert> glazou: Let's talk about other topics, time is limited.
# [09:56] <Bert> Hakon: 'super-decimal' is a new keyword for list-style.
# [09:56] <Bert> [several: already added to list module at last ftf.]
# [09:57] * Quits: dstorey (dstorey@213.236.208.247) (Quit: dstorey)
# [09:57] <Bert> Chris: Refer to value of counter of a list item?
# [09:57] <Bert> Hakon: Yes, target-counter()
# [09:57] <Bert> Hakon: image-resolution...
# [09:58] <Bert> fantasai: Will move that to image module.
# [09:59] <Bert> Tab: I've been working on defining coutner styles with at-rules. So far works for nearly all. No need for many predefined keyword anymore.
# [09:59] <Bert> ... Two or three are not regular and remain as keyword.
# [09:59] <Bert> glazou: So GCPM should refer to that and allow at-rule-defined list numbers.
# [10:00] <Bert> Hakon: But shouldn't make GCPM depend on something that has no clear time line.
# [10:01] <Bert> [General discussion about moving forward and dependencies...]
# [10:02] <Bert> [Hakon explains 'bookmarks']
# [10:02] <Bert> Tab: HTML5 has an outline algorithm. Does that interact?
# [10:03] <Bert> Steve: Independent.
# [10:03] * Joins: lstorset1 (lstorset@213.236.208.247)
# [10:03] * Quits: lstorset (lstorset@213.236.208.247) (Quit: Leaving.)
# [10:04] <Bert> ... In PDF, anything can be put in a bookmark, it's not necessarily an outline. Could make a list of figures, for example.
# [10:04] <Bert> Tantek: That example should be in the spec, to make clear what bookmarks mean.
# [10:04] * glazou likes the @counter-style at-rule *a lot*
# [10:05] * TabAtkins_ My first draft at a UA stylesheet for all the list-styles: http://www.xanthir.com/etc/css3-lists-ua-stylesheet.txt
# [10:05] <Bert> Hakon: Also, document not necessarily HTML, so not always defined how to make a toc from it.
# [10:06] <Bert> Chris: Yes, example of table of figures is good to add.
# [10:06] <Bert> Hakon: The spec should not become an introduction to publishing, but some examples can be added.
# [10:07] <Bert> ... Bookmarks are not restricted to those examples.
# [10:07] <Bert> Molly: Show it with pictures.
# [10:07] <Bert> hakon: But careful that rendering is not necesarily the same everywhere.
# [10:07] <Bert> Hakon: CMYK...
# [10:08] <Bert> fantasai: Didn't we decide to rename it to 'device-cmyk'? To stress that it is device-dependent.
# [10:08] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jun/0186.html
# [10:08] <Bert> Steve: There are various specs, but different in several countries.
# [10:08] <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0343.html
# [10:09] <Bert> Dave: Can't you add a way to specify the desired color space?
# [10:09] <Bert> Chris: We had that discussion last time. Hakon didn't want that at this point.
# [10:10] <Bert> Hakon: I'd rather not change the notation. It's implemented and the spec is clear that it is device-depnedent.
# [10:10] <Bert> Chris: SVG has 'device-cmyk()'
# [10:10] <Bert> Hakon: OK, then I will change it here, too.
# [10:11] <Bert> [David remarks that "this page intentionally left blank" should really be ... *nearly* blank. :-) ]
# [10:11] <Bert> Hakon: Aligning baselines...
# [10:11] <Bert> Chris: Is this diff. from multicol?
# [10:12] <Bert> Hakon: Yes, more advanced control over lines when there are images somewhere in the text, e.g.
# [10:12] <Bert> Steve: Also need that for page spreads. (Similar to columns.)
# [10:13] <Bert> Hakon: Proposal here is to use 'line-box-contain' property from line box module (which is currently not being worked on).
# [10:14] <Bert> glazou: From the example, I can't understand what the property does...
# [10:14] <Bert> Steve: Easy enough to fix. Take Japanese, e.g., they need some sort of "snap to grid."
# [10:15] <Bert> ... So you need a way to define what the grid is and then say when you to snap to it.
# [10:15] <Bert> John: But nobody knows what a "line box" is.
# [10:15] <Bert> glazou: Is this baseline aligning only for multicol?
# [10:16] <Bert> Hakon: Yes, although page spreads would be another application.
# [10:17] <Bert> Steve: It really only matters for the body font. HEaders rarely need to be aligned.
# [10:17] <Bert> Hakon: Another proposal than 'line-box-contain' was 'line-stacking-strategy'.
# [10:17] <Bert> Steve: XSL has that.
# [10:18] <Bert> Hakon: Yes, but XSL doens't have the 'grid-height' value that we need here.
# [10:18] <Bert> glazou: Would aligning baselines be the default behavior for columns?
# [10:18] <Bert> Steve: No, I don't think so.
# [10:19] <Bert> [Glazou draws on white board...]
# [10:19] <Bert> [Two columns, 2nd column has a big header in the middle.]
# [10:19] * Joins: tantek (tantek@213.236.208.247)
# [10:20] <Bert> Hakon: You want to be able to force the lines after that heading to snap.]
# [10:20] <Bert> [Result shows last lines in both columns on shared baselines]
# [10:21] <Bert> glazou: That could also be done by setting some special kind of height/snap on that big element, rather than on the multi-column element as a whole.
# [10:22] <Bert> [Hakon/Steve talk about other cases, Japanese, e.g., where that is not enough.]
# [10:23] <Bert> David: I wrote 'line-box-contain' some years ago, there were reasons why it worked better than 'line-stacking-strategy', but I would need to study it again...
# [10:23] <Bert> ... The former allowed, e.g., to choose explicitly what is currently quirks-mode behavior.
# [10:24] <Bert> Steve: I will need to ask in Adobe if this is too limited.
# [10:24] * Joins: Doofl (mstensho@213.236.208.247)
# [10:25] <Bert> ACTION steve: examine stack stacking, line box contain, and suggest a way out of the problem.
# [10:25] * trackbot noticed an ACTION. Trying to create it.
# [10:25] * RRSAgent records action 1
# [10:25] <trackbot> Created ACTION-257 - Examine stack stacking, line box contain, and suggest a way out of the problem. [on Steve Zilles - due 2010-08-31].
# [10:26] <Bert> Bert: 'line-box-contain' also need a way to fix the pb of fallback fonts chaning the line box height, i.e., a way to specificy that only the first available font influences the line box height.
# [10:27] <Bert> ... FF seems to do that currently, but it's not per CSS2.
# [10:27] <Bert> [10 min break]
# [10:31] <tantek> Peanuts + Joy Division = http://blip.tv/file/4037922
# [10:39] <Bert> Topic: Hit testing
# [10:40] <Bert> [Leif introduces the topic, writes on whiteboard...]
# [10:41] <Bert> Leif: Elements can overlap without one being descendant of another.
# [10:41] <Bert> ... Imagine that one has transparent background and below is one that expects click events.
# [10:42] <Bert> ... Depending on where you click and on the browser, you get different results.
# [10:42] <Bert> ... In some browsers, the transparent bg blocks events, in others not.
# [10:43] <fantasai> isn't pointer-events supposed to address this?
# [10:43] <Bert> ... So we'd like to see a standard for it.
# [10:43] <Bert> ... Gecko & Webkit have a proeprty to specify behavior.
# [10:43] <Bert> ... Can even be more detailed.
# [10:43] <dbaron> http://webkit.org/specs/PointerEventsProperty.html
# [10:43] * Joins: ChrisL (ChrisL@128.30.52.169)
# [10:44] <Bert> ... But important is that there is a common default behavior, less important *which* behavior it is.
# [10:44] <Bert> Chris: SVG has 'pointer-events' property.
# [10:45] <ChrisL> pointer-events in SVG http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty
# [10:45] <Bert> David: Yes, but it talks about things like 'stroke' and 'fill'. So we need a way to extend it to talk about backgrounds.
# [10:45] <Bert> ... Dean had a proposal for hwo to do that.
# [10:45] <Bert> Tantek: I plan to work on that. Auto and none values seem interoperable, at least.
# [10:46] <ChrisL> �pointer-events�
# [10:46] <ChrisL> Value: visiblePainted | visibleFill | visibleStroke | visible |
# [10:46] <ChrisL> painted | fill | stroke | all | none | inherit
# [10:46] <ChrisL> Initial: visiblePainted
# [10:46] <Bert> ... 'Auto' needs more specification.
# [10:46] <Bert> ... I just wanted to have 'auto' and 'none' for now.
# [10:46] <Bert> Anne: But there is hardly interoperablilty.
# [10:47] <Bert> Tantek: Two impls of those that do the same thing.
# [10:47] <anne5> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
# [10:47] <Bert> David: Gecko/Webkit behavior is easy enough to specify.
# [10:47] <Bert> Tantek: 'auto' means the front element gets the event.
# [10:48] <Bert> Leif: Opera/IE close to SVG's 'painted' value, Gecko/Webkit close to 'visible'
# [10:49] <Bert> David: IE/Opera isn't really like 'painted'. They actually look at the shape of the painted text.
# [10:49] <Bert> ... But not clear what the exact behavior is.
# [10:50] <Bert> Tantek: So what does Opera do?
# [10:50] <Bert> ... Events include selecting text.
# [10:50] <Bert> Leif: Not sure what we do with that.
# [10:51] <Bert> Tantek: Current draft has basically the 'visible' behavior as default.
# [10:51] <anne5> Hixie's draft: http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
# [10:51] <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
# [10:51] <Bert> Leif: Hixie analyzed IE behavior a few years back. Opera used that as base for its behavior.
# [10:52] <Bert> ... Can IE switch? Sicne we have IE people here...
# [10:52] <Bert> Alex: I would need to look at what is happening now. I think we implement the property in some way, not sure what it does. It has the SVG values.
# [10:53] <Bert> JohnJ: Arron is testing right now...
# [10:53] <Bert> ACTION Arron: make a test for the pointer events behavior.
# [10:53] * trackbot noticed an ACTION. Trying to create it.
# [10:53] * RRSAgent records action 2
# [10:53] <trackbot> Could not create new action (unparseable data in server response: No child element named 'id') - please contact sysreq with the details of what happened.
# [10:54] <Bert> Leif: I sent a text last Friday to www-style. Look for my name or for hit testing.
# [10:54] <glazou> http://www.w3.org/mid/op.vhqsajuxtmo5g6@nynorsk
# [10:54] <tantek> http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
# [10:55] <Bert> Leif: I used Dean Jackson's spec. Mine has more comments.
# [10:55] <tantek> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
# [10:56] <Bert> Bert: Would all kinds of pointer event be handled the same, or is there different behavior for e.g., left click and right click?
# [10:56] <Bert> Tantek: No, all the same way.
# [10:57] <Bert> Tantek: I was planning to put 'pointer-events' in UI module and make it LC.
# [10:57] <Bert> Leif: Yes, that wa smy idea as well.
# [10:58] <Bert> Tantek: I want to make that module smaller, with only what has two impls.
# [10:58] <Bert> Anne: It is not currently in that module.
# [10:58] <Bert> Tantek: Right, I want to add it.
# [10:59] <Bert> Leif: Is that too quick? There is no good draft yet. Main interest for us is to have the same default behavior, less to have a property.
# [10:59] <Bert> Tantek: Would Opera be able to change its behavior.
# [10:59] <Bert> Leif: Yes, we would like to simplify.
# [11:00] <Bert> Anne: Some east-asian sites especially seem to rely heavily on IE's behavior.
# [11:00] <Bert> Anne: Gecko seems to have bug as well.
# [11:00] <Bert> David: Yes, a known bug. No fix planned right now.
# [11:01] <Bert> ... If there were a spec, we might be more willing to change behavior.
# [11:01] <anne5> https://bugzilla.mozilla.org/show_bug.cgi?id=102695
# [11:02] <Bert> Tantek: So my new p[roposal is to put it in UI module, marked as "at risk" so that we can pull it easily before CR.
# [11:02] <Bert> David: I want to get Robert O'callahan's opinion.
# [11:03] <Bert> Anne: Need to define what element corresponds to (x,y) on the screen.
# [11:04] <Bert> David: The Firefox bug doesn't seem to get a lot of duplicates, so not a big problem at the moment.
# [11:05] <Bert> Tantek: I'll put in some simple prose absed on Dean's draft then. Until I hear more from you or from Arron's test.
# [11:05] <Bert> glazou: UI is not in our *current* charter. Can we publish an update nevertheless?
# [11:07] <Bert> Fantasai: A charter revision is possible, but since we're rechartering in a few months...
# [11:08] <Bert> Tantek: OK, I'll just work on the editor's draft and prepare it for LC.
# [11:08] <Bert> ... Can still receive comments on it.
# [11:09] <Bert> [Discussion about speeding up the rechartering. Could recharter earlier, but thend we can't put CSS in it as "finished"...]
# [11:10] <Bert> Chris: We'd need good text about CSS2 if we recharter early.
# [11:10] <Bert> glazou: That's doable.
# [11:11] * Zakim excuses himself; his presence no longer seems to be needed
# [11:11] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [11:11] <Bert> ... We already said Chris, Bert, Peter and me would work on charter in next three weeks.
# [11:11] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [11:12] <Bert> RESOLUTION: try and move AC review of charter forward, to get UI module in it and publish a LC asap.
# [11:13] <tantek> send new charter to AC by the end of September, with 4 weeks review, should be complete by end of October (in time for TPAC)
# [11:14] <Bert> Chris: We should inform SVG of the planned work.
# [11:14] * Quits: arronei (arronei@131.107.0.106) (Ping timeout)
# [11:14] <Bert> ACTION chris: tell SVG about planned work on pointer-events in CSS WG.
# [11:14] * trackbot noticed an ACTION. Trying to create it.
# [11:14] * RRSAgent records action 3
# [11:14] <trackbot> Sorry, amibiguous username (more than one match) - chris
# [11:14] <trackbot> Try using a different identifier, such as family name or username (eg. ChrisWilson, clilley)
# [11:14] <Bert> ACTION chris lilley: tell SVG about planned work on pointer-events in CSS WG.
# [11:14] * trackbot noticed an ACTION. Trying to create it.
# [11:14] <trackbot> Sorry, amibiguous username (more than one match) - chris
# [11:14] <trackbot> Try using a different identifier, such as family name or username (eg. ChrisWilson, clilley)
# [11:14] <Bert> ACTION chrisl: tell SVG about planned work on pointer-events in CSS WG.
# [11:14] * RRSAgent records action 4
# [11:14] * trackbot noticed an ACTION. Trying to create it.
# [11:14] <trackbot> Created ACTION-258 - Tell SVG about planned work on pointer-events in CSS WG. [on Chris Lilley - due 2010-08-31].
# [11:14] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [11:14] * anne5 can someone put a pointer to the agenda in the channel topic?
# [11:15] <Bert> Topic: Publish style attribute as PR?
# [11:15] <Bert> s/PR/CR/
# [11:15] <tantek> http://dev.w3.org/csswg/css-style-attr/
# [11:16] * Joins: ChrisL (ChrisL@128.30.52.169)
# [11:16] <Bert> [Some problem getting the doc from the server]
# [11:16] <Bert> Tantek: What did the exponent issue have to do with this draft?
# [11:17] <Bert> Chris: CSS2 doesn't have scientific notation, so style attribute doesn't have it either. So SVG asked about that.
# [11:17] <Bert> fantasai: But is that an issue with this draft?
# [11:18] <Bert> Anne: Style attrib draft can refer to CSS latest state, not necessarily CSS 2.1.
# [11:18] * Joins: howcome (howcome@213.236.208.247)
# [11:19] <Bert> fantasai: Draft links to core grammar, which doesn't change anyway.
# [11:19] * howcome font-size: 2.6e-4em
# [11:20] * Joins: arronei (arronei@131.107.0.69)
# [11:20] * dsinger the really really fine print
# [11:20] <Bert> Tantek: Where in the style draft is the restriction?
# [11:20] <TabAtkins_> font-size: .00026em
# [11:21] <TabAtkins_> What's the difference?
# [11:21] <Bert> [Old discussion about scientific notation not needed.]
# [11:21] * Quits: lstorset1 (lstorset@213.236.208.247) (Ping timeout)
# [11:22] * Joins: lstorset (lstorset@213.236.208.247)
# [11:22] <Bert> David: style attr should not have a different grammar than full CSS.
# [11:23] * Quits: anne5 (annevk@213.236.208.247) (Client exited)
# [11:23] <Bert> Chris: If you rewrite a stylistic attribute to a style attribute, you need to be able to allow everything.
# [11:23] * dsinger viewport-width 1.27e11 cm
# [11:23] * Joins: anne5 (annevk@213.236.208.247)
# [11:24] <Bert> David: This draft is not the place to change CSS.
# [11:24] <Bert> Fantasai: The draft carefully points to just the core grammar, nothing that restricts the attribuet value to CSS2
# [11:25] <Bert> glazou: Draft cannot refer to documents that aren't CR, if it is to become CR or better itself.
# [11:26] <Bert> Tantek: Can Chris show the specific text to change?
# [11:27] <Bert> ... This can go to CR as is.
# [11:27] <Bert> ... If CSS's core grammar is revised, we can just make a quick revsion of the style attribute spec.
# [11:27] <Bert> fantasai: Changing the core grammar isn't going to be soon anyway. Time enough to uodate the style attr spec.
# [11:28] <Bert> glazou: Objections to CR?
# [11:28] <Bert> RESOLUTION: publish style attr as CR.
# [11:28] <Bert> ACTION fantasai: send response to SVG comments about exponential notation.
# [11:28] * trackbot noticed an ACTION. Trying to create it.
# [11:28] * RRSAgent records action 5
# [11:28] <trackbot> Created ACTION-259 - Send response to SVG comments about exponential notation. [on Elika Etemad - due 2010-08-31].
# [11:29] <glazou> <br type="lunch" />
# [11:29] * Quits: glazou (glazou@213.236.208.247) (Quit: glazou)
# [11:30] * Quits: dbaron (dbaron@213.236.208.247) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [11:31] * Quits: lstorset (lstorset@213.236.208.247) (Ping timeout)
# [11:31] * Quits: jdaggett (jdaggett@213.236.208.247) (Quit: jdaggett)
# [11:32] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [11:33] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [11:34] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [13:35] * Disconnected
# [13:36] * Attempting to rejoin channel #css
# [13:36] * Rejoined channel #css
# [13:36] * Topic is 'CSS Working Group discussion'
# [13:36] * Set by fantasai on Mon Aug 02 00:49:50
# [13:37] <fantasai> Tab: Could probably get a test impl in Webkit
# [13:37] <fantasai> dbaron: One other thought about the units is maybe we want some other type of value within the property that's not a unit
# [13:37] <fantasai> dbaron points to his proposal in IRC
# [13:38] <fantasai> Alex: I would prefer that slightly over a general unit
# [13:38] <fantasai> Alex: It's obviously not a length
# [13:38] <fantasai> Alex: It's something specific
# [13:39] * Zakim excuses himself; his presence no longer seems to be needed
# [13:39] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [13:40] <fantasai> Alex suggests adding an additional set of margin properties for flexible margins
# [13:41] <fantasai> fantasai points out that this is a cascading nightmare, and would be confusing to authors because they would think they're resetting margins (e.g. to zero) when they've only reset one set of margin properties, the other set of which still has some other values
# [13:41] <TabAtkins_> http://www.w3.org/Style/CSS/Tracker/issues/open
# [13:41] * fantasai is strongly against a new set of properties for margin therefore
# [13:42] <fantasai> Tab: Is this similar to the way abspos inside tables is handled?
# [13:42] <fantasai> Alex explains the proposal
# [13:43] <fantasai> fantasai: yeah, that's just like tables
# [13:43] <fantasai> dbaron: We've institutionalized placeholders now.
# [13:43] <fantasai> Tab: It makes me sad, but yeah.
# [13:44] <fantasai> Alex: Next issue is what reversing pack: start does
# [13:44] <fantasai> dbaron: The whole pack-align-direction stuff is probably one of the more confusing things in the current spec
# [13:45] <fantasai> dbaron: The current proposal still has box-direction?
# [13:45] <fantasai> Tab: It does have display: flex
# [13:45] <fantasai> Tab: and it does have direction. It takes two directions, one for the main flow
# [13:45] <fantasai> Tab: Another for which side they're placed on
# [13:45] <fantasai> fantasai: So you have like an inline-progression-direction and a block-progression-direction
# [13:46] <fantasai> dbaron: how do you justify the boxes in the transverse direction?
# [13:47] <fantasai> Tab: You give all the boxes a flex of one
# [13:47] <fantasai> Tab: auto heights and widths evaluate to one flex on flexbox
# [13:47] <fantasai> dbaron: In transverse direction?
# [13:47] <fantasai> Tab: yes
# [13:48] * Joins: dstorey_ (dstorey@213.236.208.247)
# [13:48] <dbaron> dbaron: ok, that solves it
# [13:50] * Quits: dstorey (dstorey@193.213.156.111) (Ping timeout)
# [13:50] <fantasai> dbaron: min/max widths assign intrinsic widths, rather than assigning constraints
# [13:50] <fantasai> dbaron: in Mozilla's implementation
# [13:51] <fantasai> Alex: At which point do you apply min/max height?
# [13:51] <fantasai> Alex: in the primary direction, I thin it should have its normal meaning
# [13:51] <fantasai> Alex: So we've run all of the normal algorithms
# [13:51] <fantasai> Alex: And then max it with max-width and height, redistributing available space if necessary
# [13:51] <fantasai> dbaron: Which is the same problem you'd have with height in a fixed-height environment
# [13:52] <fantasai> Tab: Horizontal flexbox, max-height on one of the flexbox children, and box-align: stretch.
# [13:52] <fantasai> dbaron: Ah, the table problem
# [13:52] <fantasai> Tab: And one of the children is taller than the max-heights
# [13:52] <fantasai> Tab: Everyone wants to stretch to the height of that child
# [13:53] <fantasai> Tab: Do we honor the max-height, or do we ignore it
# [13:53] <fantasai> dbaron: Or shorten the parent
# [13:53] <fantasai> Alex: I think shrinking the parent is the worst option
# [13:53] <fantasai> dbaron: I think it's the best option
# [13:53] <fantasai> Tab: You wouldn't want to do that if box-align is start.
# [13:54] <fantasai> Tab: So it's really weird if we apply max-height to the flexbox
# [13:54] <fantasai> parent
# [13:54] <fantasai> Alex: I prefer an approach where everything is normal, and whoever chooses to have a max-height just becomes smaller
# [13:55] <fantasai> Alex: I don't think it matters where it aligns
# [13:55] <fantasai> Tab: It has to be defined
# [13:55] <fantasai> Tab: And I would like to control that
# [13:56] <fantasai> fantasai: So allow stretch + a direction
# [13:56] <fantasai> Alex: I prefer start being the default alignment
# [13:56] <fantasai> Tab talks about vertical alignment within the box
# [13:56] <fantasai> Bert suggests using 'vertical-align' just like in tables
# [13:56] <fantasai> fantasai: or flex the padding
# [13:57] <fantasai> fantasai: I'd suggest centering by default
# [13:58] <fantasai> discussion of directional terms
# [13:58] <fantasai> transverse direction and progression direction?
# [13:58] <Bert> (Tab's gestures suggest "wavelength" and "amplitude" :-) )
# [13:59] <fantasai> dbaron: I lean towards centering as well
# [13:59] <fantasai> JohnJansen: me too
# [14:00] <fantasai> Alex: But the contents align to the top by default
# [14:00] <fantasai> Alex: It looks odd to center the box, but top-align its content
# [14:00] <fantasai> Tab: Yeah, that makes sense
# [14:01] <fantasai> Tab: to keep those two consistent
# [14:03] <fantasai> Alex: Need to define the baseline of the flexbox
# [14:03] <fantasai> inline-blocks it's the bottom line
# [14:03] <fantasai> inline-table it's the first line of the first row
# [14:04] <fantasai> Alex: Should aligning contents of flexbox to the baseline align the same way as table cells, or something different?
# [14:04] <fantasai> dbaron has a preference for copying inline-block
# [14:05] <fantasai> dbaron: Part of the reason inline-table works the way it does is because vertical-align: baseline on table cells uses the first line
# [14:05] <fantasai> dbaron: and given you're using the first line, you might as well use the first row
# [14:05] * Quits: lstorset (lstorset@213.236.208.247) (Quit: Leaving.)
# [14:05] * Joins: lstorset (lstorset@213.236.208.247)
# [14:06] <fantasai> Alex: The most common case for flexbox would be form controls
# [14:06] <Bert> (http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#inline-box-align allows to select which line is the line that determines the baseline.)
# [14:06] <fantasai> Alex: They will usually be only one line of flexboxes
# [14:06] <fantasai> Alex: but you do want baseline alignment
# [14:07] <fantasai> dbaron: You first line when you have a flexbox with a checkbox and a multiline label fo rit
# [14:07] <dbaron> (or center, in which case you're not doing baseline alignment at all)
# [14:07] <fantasai> Tab: So let's go with inline-table model
# [14:08] <fantasai> Alex: My implementation uses the first line of the first item
# [14:08] <fantasai> Alex: It's super simplistic, but I'm still looking for a case where it wouldn't be a good choice
# [14:09] <fantasai> dbaron: the one case it might not be reasonable is if you have a bunch of flexboxes that are baseline-aligned to each other, but the first item isn't
# [14:09] <fantasai> Tab: In the current draft, the alignment has to be the same for all flexobx children
# [14:09] <fantasai> dbaron: I guess that's not a problem then
# [14:10] <dbaron> except it is a problem in Tab's draft
# [14:10] <dbaron> since he uses vertical-align, which goes on children
# [14:11] <fantasai> Tab: But in my draft, you do vertical-alignment by applying vertical-align to each flexbox individually
# [14:11] <fantasai> Alex: Do we agree on doing first line of first item?
# [14:11] <fantasai> Alex: And if we find cases where it's not a good choice we'll add them
# [14:12] <dbaron> (might want to check if any boxes have baseline alignment first)
# [14:12] <TabAtkins_> http://www.w3.org/Style/CSS/Tracker/issues/142
# [14:12] <dbaron> trackbot, issue 142
# [14:12] <trackbot> Sorry, dbaron, I don't understand 'trackbot, issue 142'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
# [14:12] <dbaron> trackbot, issue 142 ?
# [14:12] <trackbot> Sorry, dbaron, I don't understand 'trackbot, issue 142 ?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
# [14:12] <Bert> issue-142?
# [14:12] * trackbot getting information on ISSUE-142
# [14:12] <trackbot> ISSUE-142 -- Does box-ordinal-group change drawing order? -- open
# [14:12] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/142
# [14:13] <dbaron> (We previously discussed issue-138, issue-139, issue-140, and issue-141)
# [14:13] <fantasai> Alex: So Appendix E
# [14:13] <fantasai> Alex: There is a few options
# [14:13] <fantasai> Alex: One is getting rearranged throught the ordinal group
# [14:13] <fantasai> Alex: either draw in source order or layout order
# [14:13] <fantasai> Alex: Argument in favor of layout order is that it's more visually expected
# [14:14] <fantasai> Alex: Minor inconvenience is it will need an update to appendix E
# [14:14] <fantasai> Alex: Other issue is if we get to 2D flexible grid
# [14:14] <fantasai> Alex: It is less clear what order to paint, and source order makes more sense
# [14:15] <dbaron> dbaron: I think Appendix E should refer to order in the box tree
# [14:15] <dbaron> dbaron: And I think box-ordinal-group should change order in the box tree
# [14:15] <dbaron> dbaron: so I think we're done
# [14:15] <fantasai> Alex: So let's use layout order
# [14:16] <fantasai> Tab: I think that's the right source, and ordinal-group should rearrange the box tree
# [14:16] <fantasai> Tab: I don't currently have ordinal-group in my draft. bz doesn't like it. Are we still down with it?
# [14:16] <fantasai> dbaron: Our implementation is a little flaky. We only started using it for really critical stuff in this Firefox release
# [14:16] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [14:18] <fantasai> Tab: His problem was that if you have a large group, you have to run sorting algorithms on it
# [14:18] * Bert considers 'box-ordinal-group: alphabetic', good to make an index...
# [14:18] <dbaron> issue-143
# [14:18] <fantasai> fantasai: Might want to note that authors should avoid doing that if they want to avoid perf problems...
# [14:18] <dbaron> issue-143?
# [14:18] * trackbot getting information on ISSUE-143
# [14:18] <trackbot> ISSUE-143 -- Does "shrink-to-fit" width of a flexbox child depend on available space? -- open
# [14:18] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/143
# [14:19] <dbaron> (we previously discussed ISSUE-138, ISSUE-139, ISSUE-140, and ISSUE-141)
# [14:19] <fantasai> Alex: I imagine someone sorting icons in the filesystm by assining fileize to box-ordinal-group
# [14:19] <fantasai> Alex: Is the pref width max by available, or not?
# [14:19] <fantasai> Alex: I believe in Mozilla it isn't
# [14:20] <fantasai> Alex: Given we're going to adjust that later with flex, it makes more sense to lay out in infinite width
# [14:21] <fantasai> dbaron: The issue here seems to be that WebKit is using fit-content where it should be using max-content
# [14:21] <fantasai> dbaron: I think we do want to use max-content
# [14:22] <fantasai> Tab: Ok, let's track Mozilla behavior here.
# [14:22] <dbaron> I can't really think of any use cases where this makes a big difference other than the text-in-tables type issue
# [14:22] <dbaron> ISSUE_144?
# [14:22] <dbaron> issue-144?
# [14:22] * trackbot getting information on ISSUE-144
# [14:22] <trackbot> ISSUE-144 -- distribution of negative available space -- open
# [14:22] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/144
# [14:22] <fantasai> Tab: How we distribute negative space.
# [14:22] <fantasai> Alex: currently, the exact same algorithm that is used for positive space is applied to negative space just with a negative sign
# [14:23] <fantasai> Alex: So if an item has a bigger flexibility, meaning it's greedier and wants to get more extra space available, then it will get significantly less space if there is not enough space.
# [14:23] <fantasai> Alex: I'm having a hard time finding any situation where it's useful.
# [14:23] <fantasai> Alex: For example if you have a lot of text in one box and not much text in the other, they'll balance in a way that's completely non-intuitive
# [14:24] <fantasai> Tab explains some algorithm
# [14:25] <fantasai> dbaron: what if one has flex 1 and the other has flex 2
# [14:26] <fantasai> fantasai: I don't think the one that's supposed to be twice as wide as the other should wind up half the size of the other b/c we dont' have enough space
# [14:26] <fantasai> ... TeX
# [14:26] <fantasai> dsinger: You should study the TeX glue model
# [14:27] <fantasai> dsinger: He solved this pretty solidly so you should go look at that
# [14:27] <fantasai> Alex: We should either ignore space when availspace is negative
# [14:27] <fantasai> Alex: and distribute some other way
# [14:27] <fantasai> Alex: Or have a separate value that is how to distribute when negative
# [14:28] <fantasai> dbaron: There are some cases where you want to distribute space in proportion to its flex
# [14:29] <fantasai> dbaron: e.g. you have two groups of flexboxes, one with 4 children and one with 2, and you want to distribute the extra space evenly among all the grandchildren
# [14:30] <fantasai> dbaron draws a box with two boxes inside it
# [14:30] <fantasai> one of which has 2 boxes inside, the other of which has 4 inside
# [14:30] <fantasai> dbaron: In a case like this you do want to maintain flex ratio when distributing negative space
# [14:31] <fantasai> Alex If you shrink, you want to shrink proportionally to the amount of text ....
# [14:31] <fantasai> Tab: If the flex is proportional to their preferred widths.
# [14:31] <fantasai> Tab: When the flexes and preferred widths don't match, that's when you get the non-intuitive results.
# [14:31] <fantasai> dbaron: Maybe completely ignoring flex is fine
# [14:32] <dbaron> (when shrinking)
# [14:32] <fantasai> Tab: And shrinking in proportion of their preferred widths is fine
# [14:32] <dbaron> ISSUE-145?
# [14:32] * trackbot getting information on ISSUE-145
# [14:32] <trackbot> ISSUE-145 -- inline-block children of flexbox -- open
# [14:32] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/145
# [14:33] <fantasai> fantasai: The spec should say 'inline-level elements' and then it's completely clear.
# [14:33] <fantasai> Tab: The spec groups inline elements together
# [14:34] <dbaron> dbaron: I think you at least want to group text and true inlines
# [14:34] <fantasai> Alex argues that inline-blocks should become individual items
# [14:35] <dbaron> Arron: whitespace?
# [14:36] <dbaron> Tab: just like tables
# [14:36] <dbaron> Alex: I want a model where flexbox with a bunch of buttons in it doesn't require display:flex on all the buttons
# [14:37] <dbaron> dbaron: I'd be fine with saying that you'd only wrap text and *non-replaced* inlines.
# [14:38] <fantasai> fantasai: Ok, so you want atomic inline-level elements to get individually wrapped, and non-replaced inlines get grouped
# [14:43] * Quits: mg (mg@88.131.66.80) (Ping timeout)
# [14:43] * Quits: dstorey_ (dstorey@213.236.208.247) (Quit: dstorey_)
# [14:46] * Quits: lstorset (lstorset@213.236.208.247) (Ping timeout)
# [14:50] * Joins: dstorey (dstorey@193.213.156.111)
# [14:51] * Joins: dstorey_ (dstorey@213.236.208.247)
# [14:53] * Quits: dstorey (dstorey@193.213.156.111) (Ping timeout)
# [14:54] * Joins: kubala (Kuba@195.116.30.193)
# [14:54] * Quits: kubal (Kuba@195.116.30.193) (Ping timeout)
# [14:57] <TabAtkins_> glazou: 2.1 issues
# [14:57] <TabAtkins_> fantasai: Issues 158, 159, and an unnumbered issue are all about margins and clearance.
# [14:57] <TabAtkins_> The original issue that caused this was issue 6.
# [14:58] <TabAtkins_> TabAtkins_: We really need to talk to Michael (Arron's coworker) about this.
# [14:59] <TabAtkins_> ACTION arron: Talk to coworker about proposed clearance changes.
# [14:59] * trackbot noticed an ACTION. Trying to create it.
# [14:59] * RRSAgent records action 6
# [14:59] <trackbot> Created ACTION-260 - Talk to coworker about proposed clearance changes. [on Arron Eicholz - due 2010-08-31].
# [14:59] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-195
# [15:00] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-158
# [15:00] <TabAtkins_> fantasai: Info about these issues was sent to the list.
# [15:00] <fantasai> with proposal http://lists.w3.org/Archives/Public/www-style/2010Aug/0458.html
# [15:00] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-159
# [15:00] <fantasai> with proposal http://lists.w3.org/Archives/Public/www-style/2010Aug/0391.html
# [15:00] <fantasai> 158 and 159 should be editorial
# [15:01] <fantasai> back to 195
# [15:01] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0462.html
# [15:01] <TabAtkins_> dbaron: For issue 195, you could maybe say it divides it into two pieces, one on either side of the block?
# [15:01] <TabAtkins_> Bert: The original problem was if one side was empty, like <span>foo<div>bar</div></span>. The new text doesn't seem to clarify this yet.
# [15:01] <TabAtkins_> Bert: Perhaps add an "even if either side is empty"?
# [15:01] <TabAtkins_> fantasai: Sounds good to me.
# [15:02] <TabAtkins_> TabAtkins_: Sounds good.
# [15:02] <TabAtkins_> fantasai: The other issue I editted was the bidi one.
# [15:03] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0465.html
# [15:03] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-187
# [15:03] <TabAtkins_> TabAtkins_: You have two possibilities in that proposal. Do you know if either should be preferred for compat reasons?
# [15:04] <TabAtkins_> Bert: The "atomic inline" one seems easier.
# [15:05] * Joins: lstorset (lstorset@213.236.208.22)
# [15:05] <TabAtkins_> fantasai: One wrinkle is that if you replace an image with its alt text, the bidi ordering may change. The more complex first option takes care of that and prevents it from changing.
# [15:06] <TabAtkins_> Bert: I'm not sure I understand what the "replaced element that would be inline if not replaced" means.
# [15:06] <TabAtkins_> TabAtkins_: An image, for example, will be replaced by ordinary alt text if not available.
# [15:08] <TabAtkins_> fantasai: The wording is to deal with the cse for when you can have either text or a replaced element. If you set an explicit embedding level and there's text, then the surrounding content will be affected by the direction of the embedding. If it's a replaced element and you define replaced elemenets to be neutral, though, then the replaced element won't have the directionality from the embed.
# [15:09] <TabAtkins_> fantasai: So now if you set unicode-bidi on the <img>, it'll affect how the surrounding text is ordered, in the same way regardless of whether it's a replaced element (image) or not (text).
# [15:10] <TabAtkins_> Bert: There's a parenthetical about run-ins?
# [15:10] <TabAtkins_> fantasai: That's why the wording is so weird, specifically to handle runins, or else I'd just say display:inline.
# [15:11] <fantasai> s/say/say elements with/
# [15:16] <TabAtkins_> [side-discussion about run-in stuff related to this]
# [15:18] <TabAtkins_> fantasai: It seems that no one disagrees in principle with this, they're just confused by the wording?
# [15:18] <TabAtkins_> Bert: It's very confusing.
# [15:19] <TabAtkins_> arronei: Agreed.
# [15:20] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0448.html
# [15:24] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [15:25] <TabAtkins_> szilles: I thought of a problem with my suggested fix for issue 198, but I can't recall it exactly right now.
# [15:25] * Joins: szilles (chatzilla@213.236.208.247)
# [15:26] <TabAtkins_> ACTION Steve: Respond to yourself about issue 198.
# [15:26] * trackbot noticed an ACTION. Trying to create it.
# [15:26] * RRSAgent records action 7
# [15:26] <trackbot> Created ACTION-261 - Respond to yourself about issue 198. [on Steve Zilles - due 2010-08-31].
# [15:26] <TabAtkins_> howcome: Multicol moved into CR and has 6 implementations!
# [15:26] <TabAtkins_> howcome: They have a baseline level of compatibility.
# [15:26] <TabAtkins_> fantasai: Probably pagination issues will be the worst.
# [15:27] <TabAtkins_> howcome: What I'd like to spend time on is to fix two problems in the spec.
# [15:27] <TabAtkins_> howcome: 1) We don't really define how column rules behave when the content doens't fit nicely.
# [15:27] <glazou> s/doens/doesn
# [15:27] <TabAtkins_> howcome: 2) We copied the border-style values from the border property, but some of them don't make a lot of sense in terms of columnn rules.
# [15:28] <TabAtkins_> howcome: double/solid/dashed/none make sense. I don't know about hidden.
# [15:28] <TabAtkins_> dbaron: hidden only exists for the collapsing border model in tables.
# [15:29] <TabAtkins_> howcome: Also dotted.
# [15:29] <TabAtkins_> howcome: I think we should remove inset and outset.
# [15:29] <TabAtkins_> howcome: They come from buttons for a pseudo-3d effect. But with columns you don't have that.
# [15:30] <TabAtkins_> fantasai: You should make it work like the collapsed borders model and treat them like ridge and groove.
# [15:30] <TabAtkins_> dbaron: Except that we got the spec backwards in collapsed borders years ago.
# [15:30] <TabAtkins_> fantasai: I think that inset/outset it isn't clear what's supposed to happen, so just go copy what the border-collapse thing does.
# [15:31] <TabAtkins_> howcome: That's an easy solution.
# [15:32] <dbaron> actually border collapse is the right way round
# [15:32] * glazou said "no changes because otherwise you lose consistency with border-style"
# [15:33] <TabAtkins_> howcome: Next issue is column rules. They're drawn between columns, and are the currently the height of the multicol element.
# [15:34] <TabAtkins_> howcome: So even if something overflows, you don't have column rules going down to it.
# [15:34] <TabAtkins_> howcome: I think that if we extend, we don't want individual rules to extend individually.
# [15:34] <TabAtkins_> howcome: But then you have long column rules sticking out the bottom for seemingly no reason in the rest of the multicol.
# [15:35] <TabAtkins_> howcome: Also, there's a question of if you should draw rules between columns that that overflow the multicol horizontally.
# [15:36] <TabAtkins_> howcome: Robert argues on the list that you should treat them the same.
# [15:36] * Joins: mg (mg@88.131.66.80)
# [15:37] <TabAtkins_> howcome: But also maybe it looks more elegant to keep the rules horizontally.
# [15:37] <TabAtkins_> [everyone agrees that it looks better to show them horizontally, cut them vertically]
# [15:38] <TabAtkins_> howcome: Also, what if people make column rules that are super wide and would overflow the content?
# [15:39] <TabAtkins_> [agreement that authors should be allowed to do that if they feel like it, don't try to clip]
# [15:40] <TabAtkins_> fantasai: What's the stacking order for column rules?
# [15:40] <fantasai> s/just above the background/between the background and the border/
# [15:40] <fantasai> proposed text ^
# [15:40] <TabAtkins_> howcome: Cool.
# [15:41] <fantasai> s/just above the background/immediately below the border (above the background)/
# [15:41] <TabAtkins_> alexmog: If you had only two columns, there'd only be one rule and nothing outside the box (in your example)?
# [15:41] <TabAtkins_> howcome: Yes.
# [15:42] <TabAtkins_> szilles: If it's balanced columns in an element with sufficient height that there's a gap at the bottom of each column, does the rule extend all the way to the bottom of the multicol, or only to the bottom of the content?
# [15:43] <TabAtkins_> howcome: The spec says to make them the full height.
# [15:43] <TabAtkins_> [agreement, looks good]
# [15:43] <TabAtkins_> howcome: though I think we might want to add border-clip ability to rules at some point
# [15:43] <TabAtkins_> [agreement]
# [15:44] <TabAtkins_> alexmog: Word doesn't extend it to the bottom of the element, but we can use height:auto to simulate the behavior, so we're okay.
# [15:44] <TabAtkins_> howcome: Also, rules are only generated between columns with content. If the element is wide enough to hold 5 columns, but there's only enough text to fill 2, only a single rule is generated.
# [15:44] <Bert> ISSUE-129?
# [15:44] * trackbot getting information on ISSUE-129
# [15:44] <trackbot> ISSUE-129 -- balanced columns in fixed-height -- open
# [15:44] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/129
# [15:45] <TabAtkins_> howcome: [draws a diagram with 3 columns. An h2 is col-span:all in the middle, with text above and below it.]
# [15:46] <TabAtkins_> alexmog: Conceptually, the text above the h2 comes before it in the source, text below it is after it in the source.
# [15:46] <TabAtkins_> alexmog: Now what if you have even more content, so you have overflow columns, and another h2 with col-span:all in that section?
# [15:47] <TabAtkins_> dbaron: Maybe col-span:all should be cancelled on overflow sections?
# [15:48] <TabAtkins_> alexmog: If you say that setting overflow makes new columns to the right, *unless* it's balanced and doesn't fit, that's an interdependency.
# [15:49] <TabAtkins_> alexmog: If the content fits and there's extra space, extra space is distributed betweeen columns. If there's not enough space, there's no balance - it just fills what it needs and overflows.
# [15:49] <TabAtkins_> fantasai: I don't know if I like that.
# [15:52] <TabAtkins_> [pagination discussion - how multicols work in paged media]
# [15:52] * Joins: miketaylr (miketaylr@38.117.156.163)
# [15:56] <TabAtkins_> dbaron: Why do we allow column balancing in a fixed-height container?
# [15:56] <TabAtkins_> howcome: I think it looks nice.
# [15:56] <TabAtkins_> alexmog: You might have a paged implementation where you want to balance the last page.
# [15:57] <TabAtkins_> howcome: Also if you have a min-height or max-height, it could suddenly stop balancing because the content got too large.
# [15:57] <TabAtkins_> [back to colspan discussion]
# [15:57] <TabAtkins_> [colspan gets turned off if the element is in an overflow situation]
# [15:58] <TabAtkins_> dbaron: That content ordering is crazy. Would anyone ever want that?
# [15:59] <TabAtkins_> dbaron: I'm also not sure it makes sense to have a colspan on a fixed height element.
# [16:00] <TabAtkins_> alexmog: It makes lots of sense in a paged situation.
# [16:02] <dbaron> s/on a fixed height element/in fixed height columns/
# [16:04] * Bert thinks 'div.article {overflow: auto; overflow-style: paginate}' -- makes flippable pages, instead of a scrollbar or something else continuous.
# [16:04] <TabAtkins_> howcome: I propose we go with alex's suggestion. col-span:all only spans the visible column, and colspans in an overflow situation don't colspan.
# [16:04] <fantasai> s/situation/column/
# [16:07] <TabAtkins_> dbaron: What I want to say is that colspan doesn't do anything if your column is fixed height.
# [16:07] <TabAtkins_> dbaron: The case where you're actually doing fixed-height columns, you're not wanting actual colspans.
# [16:07] <TabAtkins_> TabAtkins_: What about paged media?
# [16:08] <TabAtkins_> dbaron: I'm distinguishing fixed height from paged media. They work differently, and won't cause a problem.
# [16:09] * Quits: glazou (glazou@213.236.208.247) (No route to host)
# [16:09] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [16:09] * Quits: CesarAcebal (acebal@213.236.208.247) (Connection reset by peer)
# [16:09] * Quits: jdaggett (jdaggett@213.236.208.247) (No route to host)
# [16:09] * Joins: dsinger_ (dsinger@213.236.208.247)
# [16:09] * Quits: dstorey_ (dstorey@213.236.208.247) (Connection reset by peer)
# [16:09] * Joins: CesarAcebal (acebal@213.236.208.247)
# [16:09] * Joins: jdaggett (jdaggett@213.236.208.247)
# [16:09] * Joins: dstorey (dstorey@213.236.208.247)
# [16:09] * Joins: glazou (glazou@213.236.208.247)
# [16:09] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (No route to host)
# [16:10] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [16:15] <TabAtkins_> fantasai: How about columns overflow downwards?
# [16:15] <TabAtkins_> TabAtkins_: In multiples of the original height!
# [16:16] <TabAtkins_> fantasai: But an original use-case was specifically to flow columns sideways.
# [16:16] <TabAtkins_> fantasai: And we resolved on that.
# [16:17] * glazou sees sgalineau awake on twitter
# [16:18] * glazou meaning we'll move to box-shadow blur as soon as he can call in
# [16:18] * dsinger_ how do vertical languages do 'columns'? by rows?
# [16:18] * Joins: smfr (smfr@72.25.91.23)
# [16:19] <TabAtkins_> TabAtkins_: Maybe a property at some point to specify how multicols should place their overflow columns.
# [16:19] <TabAtkins_> szilles: And that solves dbaron's issue, I believe, if you overflow them downwards in a "paged" fashion.
# [16:19] <TabAtkins_> dbaron: Yeah.
# [16:20] * Bert repeats for the minutes:
# [16:20] <Bert> ('div.article {overflow: auto; overflow-style: paginate}' -- makes flippable pages, instead of a scrollbar or something else continuous.)
# [16:21] <TabAtkins_> howcome: I think we don't want to add anything for the vertical overflow yet. We'll just go with alex's proposal.
# [16:23] <dbaron> I still don't think anybody has shown any reasonable case that would be disabled.
# [16:23] <TabAtkins_> RESOLVED: Use Alex's suggestion for disabling colspan on elements located in overflow columns.
# [16:23] * Joins: nimbupani (nimbupani@24.22.131.46)
# [16:36] * Joins: tantek (tantek@213.236.208.247)
# [16:36] <tantek> topic: Box Shadow Blur
# [16:36] <smfr> ooh maybe i should call in
# [16:36] <fantasai> http://dev.w3.org/csswg/css3-background/#the-box-shadow
# [16:37] * dsinger_ we are wondering who wants to call in
# [16:37] * dsinger_ ooh yes
# [16:37] <tantek> (phone rings)
# [16:37] <dbaron> smfr, can you hear us?
# [16:38] <smfr> very badly
# [16:38] <smfr> garbled
# [16:38] <smfr> i'll try calling again
# [16:38] <tantek> fantasai: we want a note saying something about half the standard deviation
# [16:39] <fantasai> s/fantasai/dsinger/
# [16:39] <dbaron> (that's the coffee machine)
# [16:39] <tantek> dsinger: as long as we don't talk about the edge of it
# [16:40] <tantek> fantasai: I took some of the text and put it into an explanatory note - visibly apparent color transition ... twice ... fully transparent at the edge outside it.
# [16:40] <tantek> tab: we're no longer referring to the edge of the blur because that doesn't exist.
# [16:40] <fantasai> A non-zero blur distance indicates that the resulting shadow should be blurred, such as by a Gaussian filter. The exact algorithm is not defined; however the resulting shadow must approximate (with each pixel being within 5% of its expected value) the image that would be generated by applying to the shadow a Gaussian blur with a standard deviation equal to the blur radius
# [16:40] <anne5> (sorry about that)
# [16:40] <fantasai> Note this means for a long, straight shadow edge, the blur radius will create a visibly apparent color transition approximately the twice length of the blur radius that is perpendicular to and centered on the shadow's edge, and that ranges from the full shadow color at the endpoint inside the shadow to fully transparent at the endpoint outside it.
# [16:40] * anne5 is tired
# [16:40] <tantek> tab: ... two standard deviations and that's really easy
# [16:40] * tantek is tired + hungry
# [16:41] * anne5 true; that too
# [16:41] <tantek> tab: at the blur radius ... 97%
# [16:41] * Quits: Martijnc (Martijnc@91.176.11.131) (Ping timeout)
# [16:41] <tantek> q&a between jdagget and tabatkins
# [16:42] <tantek> tab: that's the old text
# [16:42] <tantek> fantasai: i thought i fixed that. tab: i thought i did too.
# [16:42] <fantasai> "with a standard deviation equal to the half the blur radius "
# [16:42] <smfr> this phone is terrible
# [16:42] <smfr> i'm fine with the current spec btw
# [16:42] <fantasai> mispasted the old text, sorry
# [16:43] <tantek> tab: 97% isn't even the point where it hits 100% transparent but I've found thru experimentation, the difference between those two is pretty big, to the point where the shadow looks smaller than it should.
# [16:43] <dsinger_> I think 2*sigma is actually 95%
# [16:43] <tantek> tab: if you want the shadow to extend out....
# [16:43] <fantasai> visibly by the amount of the blur radius
# [16:43] * dsinger_ see 'standard deviation and confidence intervals' at http://en.wikipedia.org/wiki/Normal_distribution
# [16:44] <tantek> tab: dsinger you're right, 95% lies between both sides, but in this, we're looking only at one side which is ~97% from there
# [16:44] <tantek> fantasai: if everybody is happy with current text we can resolve this issue
# [16:45] <tantek> jdaggett - it may affect pixels beyond
# [16:45] <tantek> tab: it will
# [16:45] * Joins: Curt` (DorkeyDear@75.10.129.150)
# [16:45] <tantek> dsinger: if I'm running on a 16 bit system...
# [16:45] <tantek> tab: but even there, you won't be able to see ...
# [16:46] <tantek> jdaggett - I would watch that assertion - with the right color and background you will see it for a long way
# [16:46] <tantek> jdaggett - if you have issues where the surrounding geometry is very distinguishable, you'll be able to see it more.
# [16:46] <tantek> szilles: isn't this an implementation issue?
# [16:46] <tantek> tab: within the bounds it is safe to drop to full transparency at that point. if you wanted to you can do that. it's just not required.
# [16:46] <anne5> http://dev.w3.org/csswg/css3-background/#the-box-shadow
# [16:47] <tantek> (skype discussion for getting another person on the phone)
# [16:48] * Joins: Martijnc (Martijnc@91.176.6.55)
# [16:48] <smfr> don't they have conference calls in norway?
# [16:48] <anne5> we use telepathy here
# [16:49] <glazou> vikings use empty bottles ok aquavit only
# [16:49] <glazou> s/ok/of
# [16:49] * dsinger_ smfr: run iChat
# [16:49] <tantek> (dbaron sets up a moz conf)
# [16:49] <dbaron> 650-903-0800, 92#, 210#
# [16:50] <tantek> (bert sets up zakim)
# [16:50] <Bert> caonf code 83261
# [16:50] * Joins: bradk (bradk@67.188.133.45)
# [16:50] <tantek> welcome bradk
# [16:50] <dbaron> 617-761-6200, conf 83261
# [16:51] * Joins: Ms2ger (Ms2ger@91.181.23.251)
# [16:51] <dbaron> Zakim, this is 83261
# [16:51] <tantek> +1.617.761-6200,,,83261#
# [16:51] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [16:51] <dbaron> Zakim, this is 83261
# [16:51] <Zakim> dbaron, I see Team_(test)14:46Z in the schedule but not yet started. Perhaps you mean "this will be 83261".
# [16:51] <dbaron> Zakim, this is 83261
# [16:51] <Zakim> dbaron, Team_(test)14:46Z is already associated with an irc channel; use 'move 83261 to here' if you mean to reassociate the channel
# [16:51] <tantek> (Håkon dials Zakim)
# [16:51] <Bert> zakim, move 83261 to here.
# [16:51] <Zakim> ok, Bert; that matches Team_(test)14:46Z
# [16:52] <dbaron> zakim, who is on the phone?
# [16:52] <Zakim> On the phone I see +47.23.69.aaaa, smfr
# [16:52] <dbaron> Zakim, aaaa is [Opera]
# [16:52] <Zakim> +[Opera]; got it
# [16:52] <TabAtkins_> bradk: Yo, if you're in the room, call in.
# [16:52] <tantek> (static on phone, laughter)
# [16:52] <smfr> btw i have to leave early again (physical therapy today)
# [16:53] <tantek> fantasai: we have another topic, which is the stacking order of the inset shadows
# [16:53] <tantek> fantasai: the proposal that came in was that the inset shadows should be painted *above* replaced content, so we asked why not all content to be consistent
# [16:54] <Zakim> +bradk
# [16:54] <tantek> fantasai: the proposal is to paint the inset shadows above the content layer, but not z-index things
# [16:54] <tantek> dbaron: so if you have an inner box shadow it overlaps the text in the box?
# [16:54] <tantek> fantasai, tab: yes
# [16:55] <tantek> dbaron: ok
# [16:55] <smfr> i don't like this proposal
# [16:55] <smfr> it has stacking context implications
# [16:55] <bradk> Im here, connection is bad.
# [16:55] <tantek> fantasai: the z-index lets you pop things out and bring them forward
# [16:55] <tantek> tabatkins: children with a higher z-index are painted above
# [16:55] <tantek> dbaron: you want to say it in terms of [CSS21] appendix C, not in terms of z-index
# [16:55] <dbaron> s/appendix C/appendix E/
# [16:56] <smfr> agreed
# [16:56] <tantek> fantasai: it's a lot of layers so you need something more precise
# [16:56] <tantek> fantasai: it's between layers 8 and 9
# [16:56] <tantek> dbaron: you don't want to say it that way either
# [16:56] <smfr> http://www.w3.org/TR/CSS2/zindex.html
# [16:56] <tantek> fantasai: 8 & 9 in the sublist of 7
# [16:56] <tantek> fantasai: not it is top level 8 & 9 - not sublist
# [16:57] <smfr> so does an inset shadow make the element a stacking context?
# [16:57] <Zakim> -bradk
# [16:57] <tantek> dbaron: we need a new top level paint layer for inset box shadows
# [16:58] <Zakim> +bradk
# [16:58] <tantek> if you put it above rel-pos things, it's not just above rel-pos things in that element, but also above rel-pos things in ....
# [16:58] <tantek> (that was dbaron)
# [16:59] <tantek> dbaron: that top level list is what to do for each stacking context
# [16:59] <tantek> dbaron: for each stacking context you paint ... i'm trying to think about what this means
# [17:00] <bradk> My connetion is bad, but would it be possible to only paint above the content when there is non-visible clipping?
# [17:00] <tantek> dbaron and fantasai discuss
# [17:00] <bradk> That would also make it look best with things that protrude outside due to negative margin, etc.
# [17:00] * Joins: sylvaing (sylvaing@76.104.131.10)
# [17:00] <tantek> fantasai: where is a block child painted ... here....
# [17:01] <smfr> so if you paint the shadow above the content, think about what things look like with overflow
# [17:01] <smfr> borders draw under the content
# [17:01] <tantek> dbaron: you can stick it in point 3 or 4 in sublist 7
# [17:01] <smfr> if the shadow draws on top, it's just weird
# [17:02] * sylvaing apologies for lateness; phone # just rings ?
# [17:02] <smfr> gonna drop off the phone; it's useless
# [17:02] <Zakim> -smfr
# [17:02] <smfr> also, doesn't this mean that the inset shadow draws above the border?
# [17:03] <fantasai> So the proposal is to paint inset shadows immediately below the outline.
# [17:04] <fantasai> And yes, this would have the side-effect of drawing the shadow above a border-image
# [17:04] <smfr> i think this is weird
# [17:04] <fantasai> (since it will never overlap with the border)
# [17:04] <smfr> i think the shadow should be between the background and the border
# [17:04] <dbaron> sylvaing, Zakim bridge?
# [17:04] <tantek> tab: if you're having the border-image extend into the box - that's how it works
# [17:04] * dbaron Zakim, who is on the phone?
# [17:04] * Zakim sees on the phone: [Opera], bradk
# [17:04] <sylvaing> dbaron, no was using number sent by Hakon. trying bridge now
# [17:05] <sylvaing> conf code ?
# [17:05] <Bert> zakim, code?
# [17:05] <Zakim> the conference code is 83261 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Bert
# [17:05] * dbaron Zakim, passcode?
# [17:05] * Zakim saw 83261 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479) given for the conference code, dbaron
# [17:05] <smfr> if it's just under the outline, then you've lost the "pop out with z-index" trick
# [17:06] <bradk> TThe call quality is like listening to a tin can
# [17:06] <smfr> so the shadow will draw over abs pos, z-index children, which is also weird
# [17:06] * Joins: dsinger (dsinger@213.236.208.247)
# [17:06] <dbaron> tab: the point of having box-shadow back into the draft was having something simple that we could accomplish now
# [17:06] * Quits: dsinger_ (dsinger@213.236.208.247) (Connection reset by peer)
# [17:06] * Quits: tantek (tantek@213.236.208.247) (Connection reset by peer)
# [17:06] * Quits: jdaggett (jdaggett@213.236.208.247) (No route to host)
# [17:06] * Quits: CesarAcebal (acebal@213.236.208.247) (Connection reset by peer)
# [17:06] * Quits: glazou (glazou@213.236.208.247) (No route to host)
# [17:06] * Joins: CesarAcebal (acebal@213.236.208.247)
# [17:06] * Joins: tantek (tantek@213.236.208.247)
# [17:06] * Joins: jdaggett (jdaggett@213.236.208.247)
# [17:06] * Joins: glazou (glazou@213.236.208.247)
# [17:06] <tantek> ...
# [17:06] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (No route to host)
# [17:06] <smfr> i'm with tab; we're making too many changes to box-shadow at this point
# [17:06] * Joins: dstorey_ (dstorey@213.236.208.247)
# [17:07] * Quits: dstorey (dstorey@213.236.208.247) (No route to host)
# [17:07] <bradk> smfr, can look good if you have light colored items inside a scrollable box with inset shadow.
# [17:07] <dbaron> I'm with smfr
# [17:07] <tantek> tab: "i'm with you you're wrong"
# [17:07] <tantek> dbaron: I'd really like to get box-shadow unprefixed
# [17:07] <Zakim> + +1.206.324.aabb
# [17:07] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [17:08] <tantek> dbaron: we're going to ship FF4 with box-shadow to indicate invalid form fields, and authors are going to want to turn it off, and they're not want to going to use a prefixed property to do that
# [17:08] * sylvaing now understands what smfr meant. it's like you guys are standing on a freeway overpass :)
# [17:08] * dbaron tries an experiment with the phone for 20 seconds, starting in 5
# [17:09] * dsinger testing...
# [17:09] <fantasai> fantasai: So you either get inset shadows over the content, or you get it under the border-image. You can't have both.
# [17:09] <smfr> yep
# [17:09] <fantasai> fantasai: Unless, perhaps, you have two different inset-ing keywords, one which paints at one layer and one which paints at another.
# [17:10] <smfr> ugh
# [17:10] <tantek> tab: so no change to box-shadow now, but plans for v4 that will somehow draw intelligently on top of content
# [17:10] <fantasai> fantasai: and we could add the other keyword in CSS4 Backgrounds and Borders
# [17:10] <bradk> Overflow can be the trigger
# [17:10] <smfr> or wait for future filtery things
# [17:10] <tantek> tab: overflow could be the trigger
# [17:10] * dsinger Brad, say more?
# [17:10] <dbaron> s/tab:/bradk:/
# [17:11] <tantek> tab: brad, could you explain what you mean?
# [17:11] * sylvaing believes everyone is still on the sailboat
# [17:11] <tantek> brad: if overflow is the trigger, then if you have a scrolling box with a shadow, then the content should be inside underneath... hello?
# [17:12] <tantek> tab: .... --- .... ----
# [17:12] <smfr> i think interaction between different properties like that should be discouraged
# [17:12] <sylvaing> it sounds like we're trying to make inset more 'realistic' and I'm not sure why it should be more so than other aspects of the feature
# [17:12] * smfr is now known as smfr_bbiab
# [17:12] <tantek> brad: when i did an experiment with ...
# [17:12] <tantek> brad: it looks kind of strange to have the shadows behind them and scrolled out of view - it just doesn't seem natural
# [17:13] <tantek> tab: this might be trying to make box-shadow too realistic
# [17:13] <tantek> tab: in the mean time we do nothing. we recognize the use-case, but not with box-shadow
# [17:13] <sylvaing> agrees with tab; if we want realism the feature already has many shortcomings
# [17:13] <tantek> tab: inset box-shadows above the background layer - what they do now, below the content
# [17:13] <TabAtkins_> I think that the above-content shadow makes scrolling look a lot better, but I don't think it's a good trigger for the new shadow. I don't like that kind of interconnection. Also, it won't solve the basic problem of images.
# [17:13] <sylvaing> unclear why inset needs to be more real than the rest
# [17:14] <TabAtkins_> Agreed, sylvaing.
# [17:14] <tantek> fantasai: they are using it for glowy effects
# [17:14] <sylvaing> is comfortable with a simple decorative effect
# [17:14] <fantasai> lightbox
# [17:14] <sylvaing> but is not a designer either. argh.
# [17:14] * dsinger Brad, type to us, do not speak :-(
# [17:14] <TabAtkins_> I think we're best off by saying "We'll solve this *properly* with filter effects; box-shadow is supposed to be really simple"
# [17:15] <bradk> typing...
# [17:15] <Zakim> -bradk
# [17:15] * sylvaing stays on the phone; it's like holding a huge seashell to my ear....
# [17:15] <tantek> zakim, attendees
# [17:15] <Zakim> I don't understand 'attendees', tantek
# [17:15] <dbaron> Zakim, who is on the phone?
# [17:15] <Zakim> On the phone I see [Opera], +1.206.324.aabb
# [17:15] <dbaron> Zakim, aabb is sylvaing
# [17:15] <Zakim> +sylvaing; got it
# [17:16] <bradk> It is not so much that I want super realisom, it is that scrolling things outside the box tends to destroy the effect of it being a rectangle cut out of the canvas.
# [17:16] <bradk> It really looks pretty weird when you do that, IMO
# [17:16] <fantasai> bradk: if it paints over the content, it has to paint over the border-image
# [17:16] <fantasai> bradk: so there's an unfortunate tradeoff here
# [17:17] <bradk> Agreed it is unfortunate. But in my way, it would be limited to when you have overflow:[not visible]
# [17:17] <fantasai> bradk: I think we have consensus that that kind of out-of-left-field trigger is a bad idea
# [17:17] <bradk> And that can be turned on and off for a lot of content without much other noticiable effect
# [17:18] <tantek> (tab makes an example)
# [17:18] <tantek> tab: scrolling with a box-shadow does look bad
# [17:18] <fantasai> bradk: If we want a trigger, it should be in the box-shadow property itself
# [17:18] <tantek> tab: oh wait - it's fine
# [17:18] <tantek> tab: this is right, the shadow shouldn't scroll
# [17:19] <bradk> It's just that, with overflow:scroll, for instance, that it almost always looks wrong, unless all the content is black.
# [17:19] <TabAtkins_> data:text/html,<!doctype html><div style="width: 100px; height: 100px; -webkit-box-shadow: inset 5px 5px 10px black; overflow:scroll; color:red;">foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo</div>
# [17:19] <TabAtkins_> fantasai: I think Brad's right - it will look bad in a *lot* of cases.
# [17:19] <anne5> (WebKit only does box-shadow prefixed)
# [17:19] <tantek> fantasai: then we have the implementation issue that people want to drop prefixes
# [17:19] <sylvaing> it looks bad in a lot of other cases too
# [17:20] <bradk> Now make even bigger blurrier shadows in that example...
# [17:20] <sylvaing> e.g. when background-color is transparent and you can't see the shadow underneath but can see the body backgroundc-olor
# [17:20] <tantek> Håkon introduces David of Opera who is implementing box-shadow
# [17:20] <sylvaing> the feature already has a very limited scope
# [17:20] <tantek> David: I think I agree with what you're saying
# [17:20] <tantek> David: we should leave box-shadow as it is
# [17:20] <sylvaing> yet there is no doubt that it already is useful to authors
# [17:21] <TabAtkins_> sylvaing: Yeah, I think that's the thing. Sure, it's rarely useful as-is, but you can't fix it *properly* without a lot of work.
# [17:21] <anne5> (Opera currently does box-shadow unprefixed)
# [17:21] <bradk> What is the downsde of an overflow trigger?
# [17:22] <tantek> tab: with scrolling it looks really bad, but ehhh, doing it properly - there's more cases that can be relatively common, that will also look bad, and we'll also have to do more stuff to make them look good.
# [17:22] <anne5> (Gecko prefixed)
# [17:22] <tantek> tab: with repairing this issue, a majority of things will still look bad with inset box-shadows
# [17:22] <sylvaing> tab, yes. I too wish it were more useful than adding a shadow to a custom button control and the like. but it turns out that as simplistic as it may be, it is very useful. we might already have 80% of the feature.
# [17:22] <tantek> tab: that's just how it is, we'll do it properly later
# [17:22] <bradk> Just limits border-image in overflow inset-shadow situations, as upposed to all overflow inset-shadow situations looking weird
# [17:23] <tantek> fantasai: we can put both definitions in the spec, with different keywords and mark them both at risk.
# [17:23] <tantek> we mark both inset and inner shadows as at risk
# [17:23] <bradk> Then you could properly fix it for border-image later and have a good default now?
# [17:23] <tantek> tab: acceptable to you dbaron?
# [17:23] <tantek> tab: add another keyword for the additional behavior and mark it at risk
# [17:23] * smfr_bbiab is now known as smfr
# [17:23] <tantek> dbaron: i'd rather not keep adding stuff
# [17:23] <smfr> i don't want a new keyword at all
# [17:23] <tantek> dbaron: two years ago we wanted to be done
# [17:24] <sylvaing> agree with dbaron and smfr
# [17:24] <Zakim> -sylvaing
# [17:24] * sylvaing has had enough soothing static for today
# [17:24] <tantek> we can always add a new keyword later if someone has a solid proposal
# [17:24] <dbaron> Zakim, who is on the phone?
# [17:24] <Zakim> On the phone I see [Opera]
# [17:24] <Zakim> -[Opera]
# [17:24] <Zakim> Team_(test)14:46Z has ended
# [17:24] <tantek> fantasai: we have a solid proposal
# [17:24] <Zakim> Attendees were +47.23.69.aaaa, smfr, [Opera], bradk, +1.206.324.aabb, sylvaing
# [17:24] * jdaggett (laughter erupts at sylvain's comment)
# [17:25] <tantek> URL for said solid proposal?
# [17:25] <tantek> fantasai: what you want to do to make everything look supercool is to put content on the shadow and border-image and ...
# [17:25] <tantek> tab: hopefully someday filters will let us do this
# [17:25] <tantek> (like IE4 filters? ;) )
# [17:26] <tantek> tab: we want something like that
# [17:26] <jdaggett> jdaggett: in java2d if possible...
# [17:26] <fantasai> Proposal is to have an 'inset-overlay' keyword that behaves just like the 'inset' keyword except the shadows it generates paint immediately underneath the outline layer (when it is not painted at the #10 option in Appendix E)
# [17:26] <bradk> That might be supercool, but I'd settle for reasonable in the majority use cases
# [17:26] <fantasai> RRSAgent: pointer
# [17:26] <RRSAgent> See http://www.w3.org/2010/08/24-CSS-irc#T15-23-35
# [17:26] <fantasai> there's your url
# [17:26] <tantek> so noted
# [17:27] <tantek> (quiet typing)
# [17:27] * dsinger silence. a troubled calm.
# [17:27] <tantek> tab: that's what we want to do
# [17:27] <tantek> fantasai: nothing right now?
# [17:28] <tantek> tab: nothing right now
# [17:28] <tantek> håkon: let's go to CR
# [17:28] <Ms2ger> Håkon++
# [17:29] <bradk> I'm hearing that 'inset-overlay' would be "at-risk" (code for "never to be implemented")
# [17:29] <sylvaing> Hakon++; this is about adding a simple shadow to that facebook dialog that confirms you have given up on all your privacy (again). Not accurate 3D rendering of the stacking context based on the sun's position. Ship it !
# [17:29] <bradk> True?
# [17:30] <TabAtkins_> bradk: No, we're just not going to do it at all right now.
# [17:30] * TabAtkins_ wants a physically accurate rendering based on the simulated position of the sun. Using geolocation.
# [17:30] <bradk> It is really only in overflow situations that it bothers me, and then almost always in those situations
# [17:31] * sylvaing yeah, well. bite me.
# [17:31] <bradk> Come on, I'm not asking for ray tracing
# [17:31] * dbaron reminds TabAtkins_ that that requires geolocation, gravitometer, and compass :-P
# [17:31] <tantek> (slightly more furious typing)
# [17:32] <tantek> Bert: so is the resolution CR?
# [17:32] <tantek> Bert: I'm waiting for the chair
# [17:32] * sylvaing lives in Seattle, where shadows are a completely abstract concept
# [17:32] <bradk> Well and in some replaced objects too
# [17:32] <tantek> glazman: absolutely
# [17:32] <tantek> RESOLVED: publish as CR
# [17:32] * TabAtkins_ bradk, I know, but it's still a decent chunk of complexity. And we really want B&B to go CR.
# [17:33] <TabAtkins_> bradk, B&B4!
# [17:33] <tantek> dbaron: we might want a work item in the charter for some sort of a filters spec
# [17:33] <tantek> fantasai: that would be something with the SVG folks
# [17:33] <bradk> OK. What about images? As is on those too?
# [17:33] <tantek> fantasai: maybe make them primarily responsible for that?
# [17:33] <fantasai> images are no different than other content
# [17:33] * smfr has an action item for public-fx to draft a filters spec
# [17:33] <bradk> OK with me
# [17:34] <fantasai> RESOLVED: add filters spec to charter, as a joint item with SVG
# [17:34] <tantek> glazman: how should we name that?
# [17:34] <bradk> on rectangular images with no alpha channel, you can't see the inner shadow. Minor limitation. OK.
# [17:34] <tantek> szilles: i have to raise an objection unless it is specified more closely than that
# [17:34] <tantek> fantasai: the application of SVG filters to CSS
# [17:34] <tantek> dbaron: making SVG filters usable for CSS
# [17:35] <tantek> szilles: I'm ok with what dbaron said
# [17:35] <tantek> (cross talk)
# [17:35] <tantek> glazman: what should we name it?
# [17:35] <tantek> fantasai: CSS filters?
# [17:35] <bradk> Extended visual effects?
# [17:35] <tantek> glazman: ok
# [17:36] <tantek> (naming bikeshed)
# [17:36] * dsinger boustrophedonic palindromic names
# [17:36] * gsnedders finishing at 6?
# [17:36] <fantasai> CSS Filter Effects
# [17:36] <tantek> håkon: the idea is to use SVG syntax?
# [17:36] <tantek> dbaron: I think we may want a more CSS like syntax for it
# [17:36] <tantek> dbaron: we need better notions of CSS layers
# [17:36] <tantek> dbaron: SVG has notion of using fill or stroke as input to the filter
# [17:37] <tantek> dbaron: we need content, or border, or background as inputs to a filter
# [17:37] <smfr> i anticipate some "convenience" properties for common filters
# [17:37] <tantek> tab: yes we want to do that
# [17:37] <fantasai> Tab: That was the whole point ofBrad's presentation at tpac
# [17:37] <tantek> tab: at least for the canned filter effects, we want a convenient syntax for it
# [17:37] <bradk> yep
# [17:37] <tantek> bert: url()
# [17:37] <tantek> tab: I don't want that
# [17:37] <tantek> fantasai: you still have to type the input
# [17:37] <tantek> bert: that's what the web is for , URLs
# [17:38] <smfr> div { filter: blur(10px); }
# [17:38] <tantek> tab: I don't want to type URLs!
# [17:38] <smfr> or div { blur: 10px; }
# [17:38] <fantasai> no
# [17:38] <bradk> I agree with tab
# [17:38] <tantek> dsinger: let's table this argument
# [17:38] <tantek> bert: i object to reinventing the wheel
# [17:38] <tantek> (syntax bikeshed)
# [17:38] <tantek> glazman: we are not going to discuss this now
# [17:38] <smfr> gog
# [17:38] * dbaron considers demonstrating use of the square sign on the table as a wheel
# [17:38] <smfr> gtg
# [17:38] * Quits: smfr (smfr@72.25.91.23) (Quit: smfr)
# [17:38] <tantek> dsinger: once we have a editor's draft we can then argue
# [17:38] <sylvaing> i don't object to reinventing bert
# [17:39] <tantek> glazman: we can close this topic now
# [17:39] <tantek> next topic
# [17:39] <tantek> ------------------------
# [17:39] <tantek> glazman: next meeting in Lyon in November
# [17:39] <tantek> glazman: dbaron proposed to host next meeting after that in Mozilla in Mountain View
# [17:39] <tantek> glazman: March
# [17:39] <tantek> szilles: we also need summer
# [17:40] <tantek> glazman: june or august?
# [17:40] <anne5> is http://software.hixie.ch/utilities/js/live-dom-viewer/saved/596 a bug in Firefox?
# [17:40] <tantek> szilles: tpac will be in oct or nov and not in europe
# [17:40] <tantek> dbaron: boston in november is not that bad
# [17:40] <tantek> glazman: we still need one between tpac and moz
# [17:41] <tantek> jdaggett: proposal, it would be really good to get a set of people in Japan
# [17:41] <sylvaing> thinks we are due to host and strongly suggests august
# [17:41] <sylvaing> but definitely prefers Japan :)
# [17:41] <tantek> dbaron: march, june or august? i don't know.
# [17:41] <tantek> tab: bay area is great in june
# [17:42] <tantek> dbaron: maybe we shouldn't sched too much for the weather
# [17:42] <bradk> +1 for bay area
# [17:42] <sylvaing> dbaron: weather is important so we can show seattle people what a shadow looks like
# [17:43] <sylvaing> would actually prefer june, early august at the latest. just remembered I'm getting married around that time (ahem)
# [17:44] <bradk> Congrats!
# [17:44] <tantek> (office discussions)
# [17:45] <TabAtkins_> woo!
# [17:45] <dbaron> sounds like things moving towards Mozilla/Mountain View in March and Tokyo in June or so...
# [17:45] <TabAtkins_> sylvaing, when's the honymoon?
# [17:45] * Bert ... and a honeymoon at a CSS ftf, doesn't tempt you? :-)
# [17:45] <mollydotcom> Sylvaing: Glazou wants to know when the honeymoon is, as he'd like to crash the party ;)
# [17:46] <tantek> jdaggett: who is minuting?
# [17:46] <sylvaing> writes up a proposal for an HTML5 <shudder> element
# [17:46] <tantek> jdaggett: adobe, opera, mozilla, google will check availability
# [17:46] <fantasai> Adobe, Opera, Google, and Mozilla will check availability for Tokyo in June
# [17:46] <tantek> sylvaing - see emotionML from w3c
# [17:48] <anne5> I think it's https://bugzilla.mozilla.org/show_bug.cgi?id=319729
# [17:48] <bradk> Where/when is next tpac?
# [17:48] * anne5 added a comment with the above test
# [17:48] <fantasai> boston november 2011
# [17:48] <gsnedders> bradk: November, Lyon
# [17:48] <gsnedders> OR you mean after that?
# [17:48] <fantasai> best guess above :)
# [17:48] <fantasai> for the one after 2010
# [17:48] <dbaron> fantasai is guessing about Boston November 2011
# [17:48] <dbaron> but it seems somewhat likely
# [17:48] * Joins: Lachy (Lachlan@84.215.59.50)
# [17:48] <bradk> K, thanx
# [17:49] <sylvaing> if Mozilla hosts in Tokyo in August, shouldn't someone else host in March ?
# [17:49] <tantek> (discussion of weather continues)
# [17:49] <jdaggett> sylvaing: talking about tokyo in june
# [17:50] <jdaggett> at (mozilla, adobe, google, or opera)
# [17:50] <tantek> (holiday family reunion discussions)
# [17:50] <sylvaing> jdaggett, check. thx.
# [17:50] * Quits: JohnJansen (qw3birc@128.30.52.28) (Ping timeout)
# [17:51] <tantek> (minuter taking a break)
# [17:51] <fantasai> first week of June, 2nd half, works for me, Bert, and Steve
# [17:51] <fantasai> glazou, too
# [17:51] <sylvaing> sylvaing++
# [17:51] <tantek> (calendar math discussions continue)
# [17:51] <dbaron> 2nd half == wed-thu-fri
# [17:51] <fantasai> WTF first week of June
# [17:52] <fantasai> 2-4
# [17:52] <dbaron> 1-3 or 8-10 ?
# [17:52] <fantasai> 1-3
# [17:52] <fantasai> I think
# [17:52] <jdaggett> jdaggett: yeah, june 1-3 sounds good
# [17:54] <dbaron> dsinger says bad for March 14 or March 21 weeks
# [17:54] <dbaron> Elika has conflict Feb 26
# [17:54] <jdaggett> talking about early march at mozilla in mv
# [17:54] <jdaggett> week of feb 28th/march 7th
# [17:56] <dbaron> Feb28-Mar1-Mar2 is a M-T-W
# [17:57] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
# [17:57] * Joins: bradk (bradk@67.188.133.45)
# [17:58] * Joins: lstorset1 (lstorset@213.236.208.247)
# [17:58] <bradk> Sorry, is the meeting over?
# [17:59] <gsnedders> bradk: You think they can agree meeting dates that quickly?
# [17:59] <dbaron> Mar 2-3-4 (W-R-F) or Mar 7-8-9 (M-T-W)
# [17:59] <glazou> bradk: yes tech discussions over
# [17:59] <Bert> We're just discussing ftf dates, no more topics for today.
# [18:00] * Quits: lstorset (lstorset@213.236.208.22) (Ping timeout)
# [18:01] <bradk> OK. I don't think I have anything to block me for 2011 meeting dates at this point, so I will sign out. Bye.
# [18:01] * Quits: lstorset1 (lstorset@213.236.208.247) (Ping timeout)
# [18:01] * Quits: bradk (bradk@67.188.133.45) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
# [18:02] * Quits: glazou (glazou@213.236.208.247) (Quit: glazou)
# [18:02] <dbaron> SXSWi is Mar 11-15
# [18:02] <dbaron> ok, so tentatively Mar 7-8-9 (M-T-W)
# [18:02] * Joins: glazou (glazou@213.236.208.247)
# [18:02] * Quits: CesarAcebal (acebal@213.236.208.247) (Quit: CesarAcebal)
# [18:02] <tantek> glazman: that's it for today
# [18:02] <tantek> MEETING CLOSED FOR THE DAY
# [18:02] * Quits: jdaggett (jdaggett@213.236.208.247) (Quit: jdaggett)
# [18:03] <tantek> ---------------------------------------------------------
# [18:03] * Quits: mollydotcom (mollyh@213.236.208.247) (Quit: mollydotcom)
# [18:03] * Quits: glazou (glazou@213.236.208.247) (Quit: glazou)
# [18:04] * Quits: dstorey_ (dstorey@213.236.208.247) (Quit: dstorey_)
# [18:05] * Quits: dbaron (dbaron@213.236.208.247) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:06] * Quits: alexmog (alexmog@213.236.208.247) (Ping timeout)
# [18:06] * Quits: anne5 (annevk@213.236.208.247) (Quit: anne5)
# [18:06] * Quits: dsinger (dsinger@213.236.208.247) (Quit: dsinger)
# [18:07] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (Ping timeout)
# [18:07] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [18:07] <howcome> http://cafeisabella.no/
# [18:11] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [18:11] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [18:15] * Quits: howcome (howcome@213.236.208.247) (Ping timeout)
# [18:26] * Quits: sylvaing (sylvaing@76.104.131.10) (Ping timeout)
# [18:40] * Joins: tantek (tantek@84.215.183.68)
# [18:49] * Joins: tantek_ (tantek@84.215.183.68)
# [18:49] * Quits: tantek (tantek@84.215.183.68) (Connection reset by peer)
# [18:49] * tantek_ is now known as tantek
# [18:52] * Joins: tantek_ (tantek@84.215.183.68)
# [18:52] * Quits: tantek (tantek@84.215.183.68) (Connection reset by peer)
# [18:52] * tantek_ is now known as tantek
# [18:57] * Joins: tantek_ (tantek@84.215.183.68)
# [18:57] * Quits: tantek (tantek@84.215.183.68) (Ping timeout)
# [18:58] * tantek_ is now known as tantek
# [19:10] * Quits: tantek (tantek@84.215.183.68) (Ping timeout)
# [19:12] * Joins: sylvaing (sylvaing@76.104.131.10)
# [19:16] * Quits: davve (davve@83.218.67.122) (Ping timeout)
# [19:23] * Parts: Doofl (mstensho@213.236.208.247)
# [19:37] * Zakim excuses himself; his presence no longer seems to be needed
# [19:37] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [19:44] * Joins: tantek (tantek@84.215.183.68)
# [19:50] * Quits: tantek (tantek@84.215.183.68) (Connection reset by peer)
# [19:50] * Joins: tantek_ (tantek@84.215.183.68)
# [20:07] * Joins: tantek (tantek@84.215.183.68)
# [20:07] * Quits: tantek_ (tantek@84.215.183.68) (Connection reset by peer)
# [20:14] * Quits: tantek (tantek@84.215.183.68) (Ping timeout)
# [20:39] * Joins: Arron (arronei@84.208.66.187)
# [20:40] * Joins: jdaggett (jdaggett@195.159.215.166)
# [20:40] * Joins: tantek (tantek@84.208.66.187)
# [20:49] * Quits: jdaggett (jdaggett@195.159.215.166) (Quit: jdaggett)
# [20:55] * Joins: dbaron (dbaron@84.208.66.187)
# [20:56] * Quits: sylvaing (sylvaing@76.104.131.10) (Quit: sylvaing)
# [21:41] * Joins: TabAtkins_ (chatzilla@84.208.66.187)
# [21:47] * Quits: TabAtkins_ (chatzilla@84.208.66.187) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.13/2009073109])
# [21:55] * Joins: dsinger (dsinger@84.208.66.187)
# [22:00] * Joins: dsinger_ (dsinger@84.208.66.187)
# [22:00] * Quits: dsinger (dsinger@84.208.66.187) (Connection reset by peer)
# [22:00] * dsinger_ is now known as dsinger
# [22:13] * Joins: lstorset (lstorset@84.215.115.49)
# [22:16] * Quits: dbaron (dbaron@84.208.66.187) (Ping timeout)
# [22:32] * Joins: howcome (howcome@80.203.20.237)
# [22:41] * Quits: dsinger (dsinger@84.208.66.187) (Quit: dsinger)
# [22:46] * Quits: lstorset (lstorset@84.215.115.49) (Ping timeout)
# [22:47] * Parts: howcome (howcome@80.203.20.237)
# [22:56] * Joins: lstorset (lstorset@84.215.115.49)
# [23:04] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
# [23:39] * Quits: Ms2ger (Ms2ger@91.181.23.251) (Quit: nn)
# [23:39] * Joins: dsinger (dsinger@84.208.66.187)
# [23:39] * Quits: dsinger (dsinger@84.208.66.187) (Quit: dsinger)
# Session Close: Wed Aug 25 00:00:00 2010

The end :)