06:42:36 <RRSAgent> RRSAgent has joined #CSS
06:42:36 <RRSAgent> logging to http://www.w3.org/2010/08/24-CSS-irc
06:43:19 <glazou> RRSAgent, make logs public
07:03:05 <oyvind> oyvind has joined #css
07:03:24 <dstorey> dstorey has joined #css
07:04:05 <dsinger> dsinger has joined #css
07:04:40 <TabAtkins_> TabAtkins_ has joined #css
07:04:47 <dsinger> dsinger has joined #css
07:04:59 <anne5> anne5 has joined #css
07:05:56 <JohnJansen> JohnJansen has joined #css
07:06:17 <jdaggett> jdaggett has joined #css
07:07:22 <mollydotcom> mollydotcom has joined #css
07:07:23 <Bert> scribenick: bert
07:07:52 <Arron> Arron has joined #css
07:07:59 <Bert> Tantek: Add UI to end of extra topics list?
07:08:07 <Bert> Glazou: OK
07:08:42 <dbaron> dbaron has joined #css
07:09:14 <Bert> Topic: GCPM
07:09:43 <Bert> Hakon introduces Leif, from Opera
07:09:56 <anne5> dsinger, http://dev.w3.org/csswg/cssom/ is the draft
07:10:10 <davve> davve has joined #css
07:10:37 <anne5> dsinger, last updated a couple of days ago; CSS Value API is the thing that I want to work out next
07:10:38 <dsinger_> dsinger_ has joined #css
07:10:40 <Bert> Leif introduces himself. Worked on microformats, among other things.
07:10:49 <jdaggett_> jdaggett_ has joined #css
07:10:52 <Bert> Interested in hit testing.
07:11:48 <Bert> Hakon: GCPM is [not] the garbage collection module. :-)
07:12:02 <Bert> ... We have two impls of most of the features.
07:12:11 <Bert> ... Prince and AntennaHouse.
07:12:21 <glazou> glazou has joined #css
07:12:31 <Bert> ... Last time we cut out the mst experimental stuff. 
07:12:42 <Bert> .. What's left is ready for CR this year.
07:12:48 <Bert> ... (First LC, of course.)
07:12:59 <CesarAcebal> CesarAcebal has joined #css
07:13:04 <Bert> s/.. Wha/... Wha/
07:13:23 <Bert> John: Hyphenation is more useful than just print, should move to othe rmodule.
07:13:24 <glazou> +1
07:13:34 <Bert> Hakon: Several things are not just for print.
07:13:52 <Bert> ... I *do* like hyphenation to move fast.
07:13:55 <szilles> szilles has joined #css
07:14:01 <Bert> ... Not sure Text module will move faster.
07:14:17 <Bert> Glazou: But the title of the module is "Print."
07:14:26 <glazou> s/Print/Paged
07:14:28 <Bert> s/Print/Paged/
07:14:37 <alexmog> alexmog has joined #css
07:15:05 <Bert> Hakon: A question about hyphen was how to do hyphenation dictionaries.
07:15:16 <Bert> ... Could be a separate module,
07:15:39 <Bert> Dave: As a naive user, I'd look for hyphenationin Text module
07:15:50 <Bert> Hakon: And how about a separate module?
07:15:57 <Bert> Dave: That works, too.
07:16:06 <Bert> John Related to justification.
07:16:12 <Bert> s/John/John:/
07:16:35 <Bert> Tantek: What languages do the impls. hyphenate?
07:17:01 <Bert> Hakon: Whatever they have dictionaries for. Prince uses TeX hyphenation algo and dicts,
07:17:25 <Bert> ... The 'hyphenate-resource' points to the dict.
07:17:42 <Bert> John: Format of those files defined?
07:18:05 <Bert> Hakon: No, like 'icon', it is not defined what the reosurce format is.
07:18:15 <Bert> ... TeX is well-defined.
07:18:34 <Bert> Fantasai: Fonts have a way to specify format.
07:18:54 <Bert> John: It's not more than a hint, still need to ask server.
07:19:15 <Bert> Hakon: Should it be the same as in fonts, then?
07:19:42 <Bert> John: One reason fonts is the way it is is that there was no font mime type.
07:20:06 <Bert> Hakon: OpenOffice uses a different format, derived from TeX but not the same.
07:20:15 <Bert> ... So there is indeed a problem.
07:20:31 <Bert> ... But the impls. expect to ship with their own resources.
07:21:20 <Bert> John: Sometimes want to use system resource insyead of the url of the 'hyp-resource'property
07:22:08 <Bert> fantasai: Use a 'local' value to allow local resources.
07:22:34 <Bert> Glazou: The proeprty is currently meant for exteranl (additional) resulrces only.
07:22:58 <Bert> Dave: So you can get control by putting a 'local' value somewhere in the list.
07:23:13 <TabAtkins_> TabAtkins_ has joined #css
07:23:20 <Bert> fantasai: Mentionsomewhere that UA doesn't *have* to parse and use the external resources,
07:23:36 <Bert> John: Is that handled as a synatx error?
07:23:50 <Bert> fantasai: No, just not a supported value.
07:24:08 <Bert> Steve: How does it show up? Do you need to parse the property?
07:24:37 <lstorset> lstorset has joined #css
07:24:44 <Bert> glazou: From a pov of testing, failing the test is still succes.
07:25:00 <Bert> ... DOM doesn't matter for that.
07:25:28 <Bert> Hakon: A more experimental, but very useful feature is 'hyphens: all'
07:25:52 <Bert> ... It puts a marker in the text at *all* possible hyphenation points.
07:26:11 <Bert> John: Limit to certain number of lines?
07:26:25 <Bert> Hakon: See 'hyphenate-lines'
07:26:59 <Bert> [Discussion about the keyword 'no-limit']
07:27:09 <Bert> John: Can you hyphenate arabic?
07:27:16 <Bert> fantasai: Yes, I think so.
07:27:33 <Bert> Hakon: Justification can be used with or without hyphenation.
07:28:03 <Bert> Fantasai: Typical impl. is to hyphanate first, then justify the resulting lines.
07:28:53 <Bert> glazou: Hyphenate character: in some languages, you use a symbold both before and after the break. Is it always the same character?
07:29:10 <Bert> ... That has to be checked.
07:29:35 <Bert> Hakon: Do we need to go as far as support a pair of characters?
07:29:44 <dstorey_> dstorey_ has joined #css
07:29:46 <Bert> Steve: Ask the i18n WG...
07:30:04 <Bert> glazou: If you have hyphenation, you need to do this as well.
07:30:19 <Bert> [Dave gives example of old italian.]
07:30:50 <Bert> glazou: May need a separate property.
07:31:08 <Bert> Hakon: Chris drew hanging hyphen. How do you do that?
07:31:15 <Bert> fantasai: That is in Tetx module.
07:32:09 <Bert> JohnJ: Could you find that in the dict?
07:32:19 <Bert> fantasai: Don't know.
07:32:40 <dsinger> s/Tetx/Text/
07:33:05 <Bert> Hakon:Does anybody volunteer to do the research?
07:33:35 <Bert> glazou: We originally thought for list module to only have something simple. We were very wrong. Still not have all cases.
07:34:31 <Bert> Hakon: I'd say reasonable approach is to provide what TeX provides.
07:34:44 <Bert> glazou: We have an I18N group, let's ask them.
07:35:06 <Bert> ... When they don't repsond, we can go ahead ourselves.
07:35:22 <Bert> Chris: Could make 'hyp-char' a shorthand.
07:35:57 <Bert> fantasai: Not really ncessary to make separate proeprties if they don't cacade independently.
07:36:35 <Bert> Hakon: One common knob is to not allow hyphen on last line. No property for that currently.
07:37:27 <Bert> fantasai: Can suggest in the spec that UA *should* not hyphenate the last line of the page.
07:37:37 <Bert> glazou: It is not a "should."
07:37:50 <Bert> fantasai: Ask for it in LC.
07:38:25 <fantasai> People can ask for it in LC
07:38:31 <fantasai> if they really feel it's needed
07:38:37 <Bert> glazou: 'hyphenate: auto avoid'?
07:38:51 <Bert> John: Need a way to indicate languages?
07:39:08 <Bert> fantasai: The lang= attribute.
07:39:36 <Bert> John: But then need language selector. Can also mark the hyphenate resource with a language.
07:39:59 <Bert> fantasai: If the doc doesn't indicate language, it will not be hyphenated.
07:40:25 <Bert> glazou: Why is the resource a proeprty and not an at-rule?
07:40:46 <Bert> Hakon: Possibly use different dicts for diff elements.
07:40:58 <Bert> Dave: Could be a technical dict for special terms.
07:41:18 <Bert> fantasai: But glazou was asking if that can eb a global resource.
07:41:28 <Bert> Steve: But if there are two languages?
07:41:43 <Bert> fantasai: Need to set a global resource *per language*
07:42:13 <Bert> Dave: Still need to suppress hyphens for certain elements.
07:42:25 <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
07:42:29 <Bert> glazou: Can still turn it off per elt.
07:43:10 <dsinger_> dsinger_ has joined #css
07:43:16 <Bert> Steve: Say I want math and chemistry, would need two dicst.
07:43:21 <CesarAcebal> CesarAcebal has joined #css
07:43:25 <jdaggett> jdaggett has joined #css
07:43:25 <dstorey> dstorey has joined #css
07:43:27 <glazou> glazou has joined #css
07:43:44 <Bert> [Discussion about wording: "try resources *in turn*, *in order*...]
07:44:21 <Bert> fantasai: Compares more  to 'font' or to @font-face'?
07:45:41 <Bert> Dave: But the math/chem example is only a pb if there is a word that it is hyphenated differently in them.
07:46:14 <Bert> Chris: LANG= allows extensiona fter the dash: en-chemical, etc,
07:46:40 <Bert> Steve: But then you ened to change your mark-up.
07:46:56 <Bert> Chris: But it probably belongs in the mark-up.
07:47:50 <Bert> glazou and fantasai draw on the board: @htphen-doc { en-us: url(en.hy); ... }
07:48:12 <Bert> Hakon: What is the reason for at-rule over prop?
07:48:52 <TabAtkins_> TabAtkins_ has joined #css
07:48:54 <Bert> glazou: Performance (only one, and fewer props) and conceptual.
07:49:16 <Bert> ... Performance is even a pb for batch processors, if style and doc grows.
07:49:41 <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
07:50:00 <Bert> glazou: Would you wait for a download of a dict when rendering an element?
07:50:36 <Bert> glazou: I want the at-rule to come before any other rules.
07:50:52 <Bert> [several: seems not important]
07:51:10 <fantasai> [to enforce putting it first]
07:51:17 <Bert> Alex: I like the at-rule.
07:51:32 <Bert> Tantek: Seems indeed analogous to @font-face.
07:51:48 <Bert> Hakon: How do you reference them in the style rules?
07:52:17 <Bert> Glazou: The 'hyphens' property can refer to the resource.
07:53:01 <Bert> glazou: Let's talk about other topics, time is limited.
07:53:44 <Bert> Hakon: 'super-decimal' is a new keyword for list-style.
07:54:03 <Bert> [several: already added to list module at last ftf.]
07:54:35 <Bert> Chris: Refer to value of counter of a list item?
07:54:46 <Bert> Hakon: Yes, target-counter()
07:54:56 <Bert> Hakon: image-resolution...
07:55:09 <Bert> fantasai: Will move that to image module.
07:56:19 <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.
07:56:37 <Bert> ... Two or three are not regular and remain as keyword.
07:57:03 <Bert> glazou: So GCPM should refer to that and allow at-rule-defined list numbers.
07:57:30 <Bert> Hakon: But shouldn't make GCPM depend on something that has no clear time line.
07:58:29 <Bert> [General discussion about moving forward and dependencies...]
07:59:31 <Bert> [Hakon explains 'bookmarks']
07:59:58 <Bert> Tab: HTML5 has an outline algorithm. Does that interact?
08:00:09 <Bert> Steve: Independent.
08:00:43 <lstorset1> lstorset1 has joined #css
08:01:13 <Bert> ... In PDF, anything can be put in a bookmark, it's not necessarily an outline. Could make a list of figures, for example.
08:01:40 <Bert> Tantek: That example should be in the spec, to make clear what bookmarks mean.
08:02:56 <Bert> Hakon: Also, document not necessarily HTML, so not always defined how to make a toc from it.
08:03:17 <Bert> Chris: Yes, example of table of figures is good to add.
08:03:58 <Bert> Hakon: The spec should not become an introduction to publishing, but some examples can be added.
08:04:21 <Bert> ... Bookmarks are not restricted to those examples.
08:04:31 <Bert> Molly: Show it with pictures.
08:04:54 <Bert> hakon: But careful that rendering is not necesarily the same everywhere.
08:05:07 <Bert> Hakon: CMYK...
08:05:29 <Bert> fantasai: Didn't we decide to rename it to 'device-cmyk'? To stress that it is device-dependent.
08:05:43 <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jun/0186.html
08:05:51 <Bert> Steve: There are various specs, but different in several countries.
08:05:59 <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0343.html
08:06:19 <Bert> Dave: Can't you add a way to specify the desired color space?
08:06:40 <Bert> Chris: We had that discussion last time. Hakon didn't want that at this point.
08:07:11 <Bert> Hakon: I'd rather not change the notation. It's implemented and the spec is clear that it is device-depnedent.
08:07:22 <Bert> Chris: SVG has 'device-cmyk()'
08:07:35 <Bert> Hakon: OK, then I will change it here, too.
08:08:28 <Bert> [David remarks that "this page intentionally left blank" should really be ... *nearly* blank. :-) ]
08:08:49 <Bert> Hakon: Aligning baselines...
08:08:58 <Bert> Chris: Is this diff. from multicol?
08:09:34 <Bert> Hakon: Yes, more advanced control over lines when there are images somewhere in the text, e.g.
08:10:01 <Bert> Steve: Also need that for page spreads. (Similar to columns.)
08:10:41 <Bert> Hakon: Proposal here is to use 'line-box-contain' property from line box module (which is currently not being worked on).
08:11:10 <Bert> glazou: From the example, I can't understand what the property does...
08:11:36 <Bert> Steve: Easy enough to fix. Take Japanese, e.g., they need some sort of "snap to grid."
08:12:14 <Bert> ... So you need a way to define what the grid is and then say when you to snap to it.
08:12:32 <Bert> John: But nobody knows what a "line box" is.
08:13:03 <Bert> glazou: Is this baseline aligning only for multicol?
08:13:25 <Bert> Hakon: Yes, although page spreads would be another application.
08:14:10 <Bert> Steve: It really only matters for the body font. HEaders rarely need to be aligned.
08:14:55 <Bert> Hakon: Another proposal than 'line-box-contain' was 'line-stacking-strategy'.
08:15:00 <Bert> Steve: XSL has that.
08:15:16 <Bert> Hakon: Yes, but XSL doens't have the 'grid-height' value that we need here.
08:15:49 <Bert> glazou: Would aligning baselines be the default behavior for columns?
08:15:57 <Bert> Steve: No, I don't think so.
08:16:15 <Bert> [Glazou draws on white board...]
08:16:59 <Bert> [Two columns, 2nd column has a big header in the middle.]
08:17:05 <tantek> tantek has joined #css
08:17:34 <Bert> Hakon: You want to be able to force the lines after that heading to snap.]
08:17:55 <Bert> [Result shows last lines in both columns on shared baselines]
08:18:49 <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.
08:19:24 <Bert> [Hakon/Steve talk about other cases, Japanese, e.g., where that is not enough.]
08:20:15 <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...
08:21:05 <Bert> ... The former allowed, e.g., to choose explicitly what is currently quirks-mode behavior.
08:21:41 <Bert> Steve: I will need to ask in Adobe if this is too limited.
08:22:02 <Doofl> Doofl has joined #css
08:23:03 <Bert> ACTION steve: examine stack stacking, line box contain, and suggest a way out of the problem.
08:23:04 <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].
08:23:41 <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.
08:24:17 <Bert> ... FF seems to do that currently, but it's not per CSS2.
08:24:26 <Bert> [10 min break]
08:28:20 <tantek> Peanuts + Joy Division = http://blip.tv/file/4037922
08:37:06 <Bert> Topic: Hit testing
08:37:23 <Bert> [Leif introduces the topic, writes on whiteboard...]
08:38:37 <Bert> Leif: Elements can overlap without one being descendant of another.
08:39:04 <Bert> ... Imagine that one has transparent background and below is one that expects click events.
08:39:25 <Bert> ... Depending on where you click and on the browser, you get different results.
08:39:58 <Bert> ... In some browsers, the transparent bg blocks events, in others not.
08:40:17 <fantasai> isn't pointer-events supposed to address this?
08:40:17 <Bert> ... So we'd like to see a standard for it.
08:40:41 <Bert> ... Gecko & Webkit have a proeprty to specify behavior.
08:40:56 <Bert> ... Can even be more detailed.
08:40:58 <dbaron> http://webkit.org/specs/PointerEventsProperty.html
08:41:04 <ChrisL> ChrisL has joined #css
08:41:23 <Bert> ... But important is that there is a common default behavior, less important *which* behavior it is.
08:41:47 <Bert> Chris: SVG has 'pointer-events' property.
08:42:17 <ChrisL> pointer-events in SVG http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty
08:42:20 <Bert> David: Yes, but it talks about things like 'stroke' and 'fill'. So we need a way to extend it to talk about backgrounds.
08:42:35 <Bert> ... Dean had a proposal for hwo to do that.
08:43:06 <Bert> Tantek: I plan to work on that. Auto and none values seem interoperable, at least.
08:43:15 <ChrisL> ‘pointer-events’
08:43:15 <ChrisL>     Value:  	visiblePainted | visibleFill | visibleStroke | visible |
08:43:15 <ChrisL>     painted | fill | stroke | all | none | inherit
08:43:16 <ChrisL>     Initial:  	visiblePainted
08:43:23 <Bert> ... 'Auto' needs more specification.
08:43:48 <Bert> ... I just wanted to have 'auto' and 'none' for now.
08:44:02 <Bert> Anne: But there is hardly interoperablilty.
08:44:16 <Bert> Tantek: Two impls of those that do the same thing.
08:44:33 <anne5> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
08:44:36 <Bert> David: Gecko/Webkit behavior is easy enough to specify.
08:45:05 <Bert> Tantek: 'auto' means the front element gets the event.
08:45:54 <Bert> Leif: Opera/IE  close to SVG's 'painted' value, Gecko/Webkit close to 'visible'
08:46:46 <Bert> David: IE/Opera isn't really like 'painted'. They actually look at the shape of the painted text.
08:46:58 <Bert> ... But not clear what the exact behavior is.
08:47:38 <Bert> Tantek: So what does Opera do?
08:47:48 <Bert> ... Events include selecting text.
08:48:00 <Bert> Leif: Not sure what we do with that.
08:48:23 <Bert> Tantek: Current draft has basically the 'visible' behavior as default.
08:48:37 <anne5> Hixie's draft: http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
08:48:49 <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
08:48:57 <Bert> Leif: Hixie analyzed IE behavior a few years back. Opera used that as base for its behavior.
08:49:17 <Bert> ... Can IE switch? Sicne we have IE people here...
08:50:02 <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.
08:50:38 <Bert> JohnJ: Arron is testing right now...
08:50:54 <Bert> ACTION Arron: make a test for the pointer events behavior.
08:50:54 <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.
08:51:26 <Bert> Leif: I sent a text last Friday to www-style. Look for my name or for hit testing.
08:51:39 <glazou> http://www.w3.org/mid/op.vhqsajuxtmo5g6@nynorsk
08:51:42 <tantek> http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
08:52:39 <Bert> Leif: I used Dean Jackson's spec. Mine has more comments.
08:52:43 <tantek> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
08:53:57 <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?
08:54:05 <Bert> Tantek: No, all the same way.
08:54:41 <Bert> Tantek: I was planning to put 'pointer-events' in UI module and make it LC.
08:54:54 <Bert> Leif: Yes, that wa smy idea as well.
08:55:15 <Bert> Tantek: I want to make that module smaller, with only what has two impls.
08:55:25 <Bert> Anne: It is not currently in that module.
08:55:31 <Bert> Tantek: Right, I want to add it.
08:56:32 <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.
08:56:44 <Bert> Tantek: Would Opera be able to change its behavior.
08:56:56 <Bert> Leif: Yes, we would like to simplify.
08:57:22 <Bert> Anne: Some east-asian sites especially seem to rely heavily on IE's behavior.
08:57:51 <Bert> Anne: Gecko seems to have bug as well.
08:58:07 <Bert> David: Yes, a known bug. No fix planned right now.
08:58:34 <Bert> ... If there were a spec, we might be more willing to change behavior.
08:58:36 <anne5> https://bugzilla.mozilla.org/show_bug.cgi?id=102695
08:59:27 <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.
08:59:55 <Bert> David: I want to get Robert O'callahan's opinion.
09:00:42 <Bert> Anne: Need to define what element corresponds to (x,y) on the screen.
09:01:14 <Bert> David: The Firefox bug doesn't seem to get a lot of duplicates, so not a big problem at the moment.
09:02:09 <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.
09:02:56 <Bert> glazou: UI is not in our *current* charter. Can we publish an update nevertheless?
09:04:14 <Bert> Fantasai: A charter revision is possible, but since we're rechartering in a few months...
09:05:09 <Bert> Tantek: OK, I'll just work on the editor's draft and prepare it for LC.
09:05:20 <Bert> ... Can still receive comments on it.
09:06:50 <Bert> [Discussion about speeding up the rechartering. Could recharter earlier, but thend we can't put CSS in it as "finished"...]
09:07:28 <Bert> Chris: We'd need good text about CSS2 if we recharter early.
09:07:36 <Bert> glazou: That's doable.
09:08:37 <Zakim> Zakim has left #CSS
09:08:37 <Bert> ... We already said Chris, Bert, Peter and me would work on charter in next three weeks.
09:08:56 <Zakim> Zakim has joined #CSS
09:09:53 <Bert> RESOLUTION: try and move AC review of charter forward, to get UI module in it and publish a LC asap.
09:10:36 <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)
09:11:12 <Bert> Chris: We should inform SVG of the planned work.
09:11:34 <Bert> ACTION chris: tell SVG about planned work on pointer-events in CSS WG.
09:11:34 <trackbot> Sorry, amibiguous username (more than one match) - chris
09:11:34 <trackbot> Try using a different identifier, such as family name or username (eg. ChrisWilson, clilley)
09:11:49 <Bert> ACTION chris lilley: tell SVG about planned work on pointer-events in CSS WG.
09:11:49 <trackbot> Sorry, amibiguous username (more than one match) - chris
09:11:49 <trackbot> Try using a different identifier, such as family name or username (eg. ChrisWilson, clilley)
09:11:57 <Bert> ACTION chrisl: tell SVG about planned work on pointer-events in CSS WG.
09:11:57 <trackbot> Created ACTION-258 - Tell SVG about planned work on pointer-events in CSS WG. [on Chris Lilley - due 2010-08-31].
09:12:17 <Bert> Topic: Publish style attribute as PR?
09:12:24 <Bert> s/PR/CR/
09:13:04 <tantek> http://dev.w3.org/csswg/css-style-attr/
09:13:10 <ChrisL> ChrisL has joined #css
09:13:20 <Bert> [Some problem getting the doc from the server]
09:13:59 <Bert> Tantek: What did the exponent issue have to do with this draft?
09:14:30 <Bert> Chris: CSS2 doesn't have scientific notation, so style attribute doesn't have it either. So SVG asked about that.
09:14:47 <Bert> fantasai: But is that an issue with this draft?
09:15:39 <Bert> Anne: Style attrib draft can refer to CSS latest state, not necessarily CSS 2.1.
09:16:00 <howcome> howcome has joined #css
09:16:13 <Bert> fantasai: Draft links to core grammar, which doesn't change anyway.
09:17:11 <arronei> arronei has joined #CSS
09:17:28 <Bert> Tantek: Where in the style draft is the restriction?
09:18:04 <TabAtkins_> font-size: .00026em
09:18:09 <TabAtkins_> What's the difference?
09:18:40 <Bert> [Old discussion about scientific notation not needed.]
09:19:36 <lstorset> lstorset has joined #css
09:20:02 <Bert> David: style attr should not have a different grammar than full CSS.
09:20:49 <Bert> Chris: If you rewrite a stylistic attribute to a style attribute, you need to be able to allow everything.
09:21:02 <anne5> anne5 has joined #css
09:21:15 <Bert> David: This draft is not the place to change CSS.
09:21:42 <Bert> Fantasai: The draft carefully points to just the core grammar, nothing that restricts the attribuet value to CSS2
09:22:26 <Bert> glazou: Draft cannot refer to documents that aren't CR, if it is to become CR or better itself.
09:23:39 <Bert> Tantek: Can Chris show the specific text to change?
09:24:08 <Bert> ... This can go to CR as is.
09:24:35 <Bert> ... If CSS's core grammar is revised, we can just make a quick revsion of the style attribute spec.
09:25:06 <Bert> fantasai: Changing the core grammar isn't going to be soon anyway. Time enough to uodate the style attr spec.
09:25:21 <Bert> glazou: Objections to CR?
09:25:32 <Bert> RESOLUTION: publish style attr as CR.
09:26:04 <Bert> ACTION fantasai: send response to SVG comments about exponential notation.
09:26:04 <trackbot> Created ACTION-259 - Send response to SVG comments about exponential notation. [on Elika Etemad - due 2010-08-31].
09:26:12 <glazou> <br type="lunch" />
10:32:42 <glazou> glazou has joined #css
10:32:47 <jdaggett> jdaggett has joined #css
10:32:57 <Arron> Arron has joined #css
10:33:11 <dbaron> dbaron has joined #css
10:33:35 <szilles> szilles has joined #css
10:34:45 <glazou> glazou has joined #css
10:34:55 <anne5> anne5 has joined #css
10:35:11 <lstorset> lstorset has joined #css
10:35:33 <TabAtkins_> glazou: I'd like to come back to the charter for a bit.
10:35:50 <TabAtkins_> ScribeNick: TabAtkins_
10:35:54 <tantek> tantek has joined #css
10:36:17 <TabAtkins_> glazou: Anne, what is the status/priority of the two specs you own?  CSSOM and CSSOM View.
10:36:36 <TabAtkins_> anne5: View is still somewhat in flux, but getting progressively better.
10:36:58 <TabAtkins_> anne5: There have been requests for new features.  Hixie wanted scrollIntoView(), for example.  Also a few other legacy properties.
10:37:06 <TabAtkins_> anne5: It also has the Media Query api.
10:37:14 <TabAtkins_> anne5: Overall it's still in flux, but it's being implemented.
10:37:43 <TabAtkins_> glazou: So View remains in the charter, medium priority.
10:37:59 <TabAtkins_> glazou: And CSSOM?
10:38:19 <TabAtkins_> anne5: I thought I'd poll again recently to make sure there was value in the the Value API.
10:38:34 <TabAtkins_> anne5: It hasn't ever been published as a WD, but it's in the charter.  It's still got a lot of red boxes.
10:39:06 <TabAtkins_> anne5: It's pretty high priority for me personally; it has a lot of necessary stuff.
10:39:24 <TabAtkins_> anne5: It does value serialization, getComputedStyle(), etc.
10:39:42 <TabAtkins_> anne5: For the Value API, I just need to invent something and hope it's good enough.
10:40:00 <TabAtkins_> glazou: So keep it in the charter, at medium priority.
10:40:24 <TabAtkins_> anne5: After MQ was done, I thought about defining MQ2, which defines both the query and the types so it can be truly standalone.
10:40:40 <TabAtkins_> anne5: Right now it depends on CSS2.1 and HTML4 for the definitions of several types.
10:40:50 <TabAtkins_> fantasai: That sounds like basically an editorial issue.
10:41:48 <TabAtkins_> glazou: So, next issue is MQ - issues, test suite, further steps.
10:41:54 <TabAtkins_> glazou: Anne, what's the status?
10:42:03 <TabAtkins_> anne5: I think I sent an email with my issues.
10:42:26 <anne5> http://lists.w3.org/Archives/Public/www-style/2010Jul/0448.html
10:42:53 <TabAtkins_> anne5: With the test suite, there are a few things.  For one, it uses something moz-specific.
10:43:05 <TabAtkins_> ChrisL: What does it use?
10:43:20 <TabAtkins_> anne5: -moz-initial for font sizes.  I guess we can just remove it and use 16px.
10:43:29 <TabAtkins_> anne5: color-index doesn't appear to be implemented much.
10:43:46 <TabAtkins_> dbaron: The spec says that color-index should only work if you have an indexed-color supply.
10:43:54 <TabAtkins_> dbaron: Which we don't support, so we always return false.
10:44:10 <TabAtkins_> s/supply/device/
10:44:24 <TabAtkins_> ChrisL: Are there any impls that support a 256-color device?
10:44:39 <TabAtkins_> anne5: Personally I don't really know what the feature means or does.
10:44:50 <TabAtkins_> ChrisL: [explains color-indexed displays]
10:46:46 <TabAtkins_> ChrisL: Basically there's nothing *left* to test this on.  All the devices it could apply to are long past obsolete, like a black and white tty device that CSS also talks about supporting.
10:48:18 <TabAtkins_> TabAtkins_: Can we just drop this, then, since nobody actually needs it and we can't do a non-trivial test?
10:48:29 <TabAtkins_> anne5: We could, but we have to go through LC again.
10:48:59 <TabAtkins_> ChrisL: I don't think there's a decent reason to drop it.
10:51:05 <TabAtkins_> anne5: So let's keep it then.
10:51:29 <TabAtkins_> anne5: Do we have guidelines for what the sourcecode of the tests should look like?
10:52:14 <TabAtkins_> ChrisL: Given that it's a single page, [something about the way the test displays results].
10:52:26 <TabAtkins_> dbaron: We could change the javascript up a bit to make it easier.
10:52:52 <TabAtkins_> anne5: We'll have two complete implementations very soon.
10:53:11 <TabAtkins_> ChrisL: So we can get an impl report out of it moderately easy?
10:53:21 <TabAtkins_> dbaron: Yeah, and we can tweak it if necessary.
10:54:20 <TabAtkins_> glazou: How many people reviewed these tests?
10:54:31 <TabAtkins_> anne5: dbaron wrote them and I reviewed them.
10:56:01 <TabAtkins_> glazou: On my Mac, safari is more fail than pass.  All green on Firefox.
10:56:39 <glazou> http://www.w3.org/Style/CSS/Test/MediaQueries/20100726/media-queries-test.html
10:58:31 <TabAtkins_> glazou: ETA for all green on Opera?
10:59:10 <TabAtkins_> anne5: It's all parsing failures.  I can push it, but otherwise it's sorta near future.
11:00:23 <anne5> dev.w3.org/csswg/css3-mediaqueries
11:00:27 <anne5> http://dev.w3.org/csswg/css3-mediaqueries/
11:00:31 <oyvind> (also missing support for dcpm)
11:00:43 <oyvind> s/dcpm/dpcm/
11:00:48 <TabAtkins_> glazou: Next steps?  When can we move?
11:00:57 <dbaron> dots centi per meter :-)
11:01:21 <TabAtkins_> glazou: So we just need implementation reports.
11:01:50 <TabAtkins_> anne5: I guess let's leave the tests as beta until we have one more implementation, then we'll push it as final.
11:01:54 <TabAtkins_> anne5: Then we can go to PR.
11:02:23 <TabAtkins_> arronei: Do we want a deadline set for reviewing?
11:02:35 <TabAtkins_> anne5: Nah, just fix the bugs.  Reviewing should just happen at the same time.
11:02:49 <TabAtkins_> RESOLVED: 2010 Snapshot is 2007 Snapshot + MQ.
11:03:13 <TabAtkins_> howcome: I think B&B should go in the snapshot.
11:03:23 <TabAtkins_> fantasai: We need to wait for a test suite for it.  It'll probably go into 2011.
11:04:15 <fantasai> also, the spec isn't as stable as MQ either
11:04:16 <TabAtkins_> glazou: Next topic, selector serialization.
11:04:39 <anne5> http://lists.w3.org/Archives/Public/www-style/2010May/att-0372/SSEL.html
11:04:43 <anne5> http://lists.w3.org/Archives/Public/www-style/2010May/0372.html
11:04:53 <dstorey> dstorey has joined #css
11:05:20 <TabAtkins_> anne5: I don't have a problem with rewriting it; I'm not entirely certain I like this structure.
11:05:42 <TabAtkins_> glazou: It's just editorial work making it more coherent with how we describe selectors in the Selectors spec.
11:06:13 <dbaron> my comments were http://lists.w3.org/Archives/Public/www-style/2010Apr/0452.html
11:06:24 <dbaron> Tab's comments were http://lists.w3.org/Archives/Public/www-style/2010Apr/0382.html
11:07:45 <TabAtkins_> anne5: Ideally, I think serializing selectors and some hook into parsing a selector would go into the Selectors spec.
11:07:59 <TabAtkins_> glazou: Is that more relevant to the selectorText attribute in the CSSOM?
11:08:12 <TabAtkins_> anne5: There might be other things that need to use the serialization.
11:08:51 <TabAtkins_> anne5: Parsing and serializing seems like critical infrastructure that should be in the core spec.
11:09:20 <TabAtkins_> glazou: That would require moving Selectors in the priority part of the charter.
11:09:30 <TabAtkins_> TabAtkins_: Didn't we put Selectors 4 in Low Priority?
11:09:35 <TabAtkins_> glazou: Not yet.  We can.
11:10:30 <anne5> (I didn't address your comment TabAtkins_ on selector serialization if you mean that.)
11:10:47 <TabAtkins_> Bert: I don't think we need another Selectors spec; second, selectors isn't about parsing or serializing.
11:11:04 <TabAtkins_> fantasai: If you don't implement the DOM, the conformance criteria should say that the OM stuff doesn't apply to you.
11:11:05 <anne5> (I deferred them hoping for what we just agreed to :))
11:11:55 <TabAtkins_> glazou: We agreed to dispatch OM sections to individual drafts.  We absolutely need OM improvements - it's the worst part of CSS right now.
11:12:34 <TabAtkins_> glazou: Since it's only serialization, not new selectors, it can just be a revision.
11:13:37 <TabAtkins_> tantek: There'll be new selectors in CSS3 UI.
11:14:04 <TabAtkins_> fantasai: You might want to split that into a separate "UI Selectors" spec, so thinks like QuerySelector can refer to it without depending on all of UI.
11:15:01 <TabAtkins_> glazou: Next topic, Flexbox!
11:15:07 <anne5> yay flexbox
11:15:31 <TabAtkins_> alexmog: We have an old spec and a new proposal; we have a number of very specific issues in the tracker I've opened which apply to either proposal.
11:15:41 <TabAtkins_> alexmog: Should we discuss where the spec is going, or the issues?
11:17:01 <fantasai> ScribeNick: fantasai
11:17:11 <fantasai> dbaron: Additive spec is important to us
11:17:17 <dbaron> s/spec/flex/
11:17:29 <fantasai> Tab: I have several options for representing additive flex in addition to absolute flex
11:17:43 <fantasai> Alex: There should be a very simple mapping from the old spec behavior to the new spec behavior
11:17:49 <fantasai> Tab: One option is to have an additive flex unit
11:17:59 <fantasai> Alex: One thing I liked about the old spec is that it's really really simple
11:18:08 <fantasai> Alex: And it's exactly what you need for building UI
11:18:21 <fantasai> Alex: Office UI is built with something similar to flexbox, or maybe even simpler than that.
11:18:57 <fantasai> Alex: You can get lots of pieces built by different people put together in a coherent way only if the behavior is really simple.
11:19:15 <fantasai> Alex: Don't want interactions with other things, margin collapsing, etc.
11:19:28 <fantasai> Alex: I really liked the simplicity, and also the isolation from everything else
11:19:44 <fantasai> Alex: The ability add a new module that adds really useful algorithms without complexifying everything else.
11:20:19 <fantasai> Tab: All it's essentially doing is taking the abilities in the current draft, and generalizing them slightly.
11:20:43 <fantasai> Tab: There's no interaction outside the flexbox container.
11:20:55 <fantasai> dbaron: What happens to flex units outside a flexbox?
11:21:07 <fantasai> Tab: It would have to default to something. Haven't figured that out yet.
11:21:48 <fantasai> dbaron: That's a concern I have is that the flex units leak out 
11:22:46 <fantasai> Alex: There's a temptation to apply flex units outside the flexbox model
11:22:52 <fantasai> dbaron: e.g. flex margins in abspos
11:22:56 <fantasai> Tab: We totally want that
11:23:22 <fantasai> Alex: I would like to come up with Grid very soon. If you look at ... Grid and Flexbox play together very nicely.
11:23:34 <fantasai> Alex: I would hope that other layout models interoperate with flexbox as well.
11:24:12 <fantasai> Tab: you can have flexboxes spill into multiple lines, sortof like a table
11:24:23 <fantasai> dbaron: ...
11:24:33 <fantasai> Tab: You could do a XUL-type grid in flexbox easily
11:24:33 <dbaron> s/.../XUL has a grid model, but it's not in the flebox spec/
11:24:57 <fantasai> Tab: You could also use flex concepts in Template Layout, where it would be very useful.
11:25:55 <fantasai> howcome: I'm hesitant to define units that are only useful within a specific layout algorithm
11:26:09 <TabAtkins_> http://www.xanthir.com/document/document.php?id=615d486a4dd75e8f4ae644eaa02af778211809483881e4964e66c29d5618b7ae457190b450c9e53abee05aa2e590cefc8100663c8d91328a1bd786ab9f1e7f2b
11:26:14 <fantasai> fantasai: You'd want to specify exactly which properties accept flex. e.g. text-indent should not take flex units
11:26:16 <dbaron> text-indent flex would be like text-align-start: end
11:26:25 <Bert> (Me thinks, on the contrary, a fexible text-indent would be very nice: can have the last line of the para flush with the right margin that way... :-) )
11:26:28 <dbaron> s/text-align-start/text-align-first/
11:27:09 <fantasai> Alex: I considered having Grid do layout computations similar to flexbox
11:27:28 <fantasai> Alex: .. specify width of multiple columns, without defining some kind of flex unit
11:27:46 <fantasai> Alex: Also it would be useful for flex units to not complicate ...
11:28:17 <fantasai> Alex: Maybe there is a compromise where there is a flex unit that can be parsed into a grid unit, but can't be parsed into a length.
11:28:35 <fantasai> Alex: Currently in grid positioning, there is an fr unit that only applies to that feature
11:29:12 <fantasai> Tab: I want to apply flex to margin/border/padding/width/height
11:29:43 <fantasai> Alex: maybe you could have a different property that specifies a flexible margin
11:30:11 <fantasai> Tab: I don't think it makes sense to add ... to avoid having flex units in the margin
11:30:26 <dbaron> could we do something like height: flex(1) [non-additive] or height: 50px flex(1) [additive] ?
11:30:39 <fantasai> Alex: margin is a way for flexbox to spill outside the flexbox
11:30:50 <fantasai> Tab: The use of flexes is only defined within the context of flexbox.
11:31:01 <fantasai> Alex: ... isolation.
11:31:53 <fantasai> Tab: If you were to use a flex unit outside a flexbox, it would compute to a used value of zero
11:31:58 <fantasai> fantasai: or maybe even a computed value
11:32:32 <fantasai> Tab: I understand your concern about the application of flex to normal flow, but I don't think it is actually a problem.
11:33:09 <fantasai> Alex: If that's the only thing we are disagreeing on, we're doing pretty good.
11:33:19 <fantasai> Alex has some concerns about syntax of various properties
11:33:33 <krijnh> krijnh has joined #css
11:34:21 <fantasai> Tab: Could probably get a test impl in Webkit
11:34:34 <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
11:35:06 <fantasai> dbaron points to his proposal in IRC
11:35:25 <fantasai> Alex: I would prefer that slightly over a general unit
11:35:36 <fantasai> Alex: It's obviously not a length
11:35:42 <fantasai> Alex: It's something specific
11:36:13 <Zakim> Zakim has left #CSS
11:37:21 <fantasai> Alex suggests adding an additional set of margin properties for flexible margins
11:38:13 <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
11:38:15 <TabAtkins_> http://www.w3.org/Style/CSS/Tracker/issues/open
11:39:32 <fantasai> Tab: Is this similar to the way abspos inside tables is handled?
11:40:05 <fantasai> Alex explains the proposal
11:40:11 <fantasai> fantasai: yeah, that's just like tables
11:40:20 <fantasai> dbaron: We've institutionalized placeholders now.
11:40:35 <fantasai> Tab: It makes me sad, but yeah.
11:41:16 <fantasai> Alex: Next issue is what reversing pack: start does
11:41:42 <fantasai> dbaron: The whole pack-align-direction stuff is probably one of the more confusing  things in the current spec
11:42:11 <fantasai> dbaron: The current proposal still has box-direction?
11:42:19 <fantasai> Tab: It does have display: flex
11:42:31 <fantasai> Tab: and it does have direction. It takes two directions, one for the main flow
11:42:39 <fantasai> Tab: Another for which side they're placed on
11:42:59 <fantasai> fantasai: So you have like an inline-progression-direction and a block-progression-direction
11:43:49 <fantasai> dbaron: how do you justify the boxes in the transverse direction?
11:44:34 <fantasai> Tab: You give all the boxes a flex of one
11:44:50 <fantasai> Tab: auto heights and widths evaluate to one flex on flexbox
11:44:56 <fantasai> dbaron: In transverse direction?
11:44:59 <fantasai> Tab: yes
11:45:19 <dstorey_> dstorey_ has joined #css
11:45:21 <dbaron> dbaron: ok, that solves it
11:47:39 <fantasai> dbaron: min/max widths assign intrinsic widths, rather than assigning constraints
11:47:44 <fantasai> dbaron: in Mozilla's implementation
11:48:16 <fantasai> Alex: At which point do you apply min/max height?
11:48:24 <fantasai> Alex: in the primary direction, I thin it should have its normal meaning
11:48:31 <fantasai> Alex: So we've run all of the normal algorithms
11:48:45 <fantasai> Alex: And then max it with max-width and height, redistributing available space if necessary
11:48:58 <fantasai> dbaron: Which is the same problem you'd have with height in a fixed-height environment
11:49:33 <fantasai> Tab: Horizontal flexbox, max-height on one of the flexbox children, and box-align: stretch.
11:49:39 <fantasai> dbaron: Ah, the table problem
11:49:47 <fantasai> Tab: And one of the children is taller than the max-heights
11:49:55 <fantasai> Tab: Everyone wants to stretch to the height of that child
11:50:19 <fantasai> Tab: Do we honor the max-height, or do we ignore it
11:50:23 <fantasai> dbaron: Or shorten the parent
11:50:49 <fantasai> Alex: I think shrinking the parent is the worst option
11:50:53 <fantasai> dbaron: I think it's the best option
11:51:06 <fantasai> Tab: You wouldn't want to do that if box-align is start.
11:51:39 <fantasai> Tab: So it's really weird if we apply max-height to the flexbox
11:51:42 <fantasai> parent
11:52:00 <fantasai> Alex: I prefer an approach where everything is normal, and whoever chooses to have a max-height just becomes smaller
11:52:10 <fantasai> Alex: I don't think it matters where it aligns
11:52:19 <fantasai> Tab: It has to be defined
11:52:38 <fantasai> Tab: And I would like to control that
11:53:25 <fantasai> fantasai: So allow stretch + a direction
11:53:46 <fantasai> Alex: I prefer start being the default alignment
11:53:51 <fantasai> Tab talks about vertical alignment within the box
11:53:58 <fantasai> Bert suggests using 'vertical-align' just like in tables
11:54:02 <fantasai> fantasai: or flex the padding
11:54:38 <fantasai> fantasai: I'd suggest centering by default
11:55:31 <fantasai> discussion of directional terms
11:55:45 <fantasai> transverse direction and progression direction?
11:55:53 <Bert> (Tab's gestures suggest "wavelength" and "amplitude" :-) )
11:56:25 <fantasai> dbaron: I lean towards centering as well
11:56:27 <fantasai> JohnJansen: me too
11:57:31 <fantasai> Alex: But the contents align to the top by default
11:57:42 <fantasai> Alex: It looks odd to center the box, but top-align its content
11:57:47 <fantasai> Tab: Yeah, that makes sense
11:58:37 <fantasai> Tab: to keep those two consistent
12:00:17 <fantasai> Alex: Need to define the baseline of the flexbox
12:00:33 <fantasai> inline-blocks it's the bottom line
12:00:39 <fantasai> inline-table it's the first line of the first row
12:01:15 <fantasai> Alex: Should aligning contents of flexbox to the baseline align the same way as table cells, or something different?
12:01:52 <fantasai> dbaron has a preference for copying inline-block
12:02:11 <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
12:02:22 <fantasai> dbaron: and given you're using the first line, you might as well use the first row
12:03:02 <lstorset> lstorset has joined #css
12:03:47 <fantasai> Alex: The most common case for flexbox would be form controls
12:03:55 <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.)
12:03:59 <fantasai> Alex: They will usually be only one line of flexboxes
12:04:06 <fantasai> Alex: but you do want baseline alignment
12:04:41 <fantasai> dbaron: You first line when you have a flexbox with a checkbox and a multiline label fo rit
12:05:00 <dbaron> (or center, in which case you're not doing baseline alignment at all)
12:05:05 <fantasai> Tab: So let's go with inline-table model
12:05:25 <fantasai> Alex: My implementation uses the first line of the first item
12:05:37 <fantasai> Alex: It's super simplistic, but I'm still looking for a case where it wouldn't be a good choice
12:06:10 <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
12:06:40 <fantasai> Tab: In the current draft, the alignment has to be the same for all flexobx children
12:07:02 <fantasai> dbaron: I guess that's not a problem then
12:07:22 <dbaron> except it is a problem in Tab's draft
12:07:29 <dbaron> since he uses vertical-align, which goes on children
12:08:10 <fantasai> Tab: But in my draft, you do vertical-alignment by applying vertical-align to each flexbox individually
12:08:25 <fantasai> Alex: Do we agree on doing first line of first item?
12:08:33 <fantasai> Alex: And if we find cases where it's not a good choice we'll add them
12:09:19 <dbaron> (might want to check if any boxes have baseline alignment first)
12:09:37 <TabAtkins_> http://www.w3.org/Style/CSS/Tracker/issues/142
12:09:43 <dbaron> trackbot, issue 142
12:09:43 <trackbot> Sorry, dbaron, I don't understand 'trackbot, issue 142'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
12:09:46 <dbaron> trackbot, issue 142 ?
12:09:46 <trackbot> Sorry, dbaron, I don't understand 'trackbot, issue 142 ?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
12:09:48 <Bert> issue-142?
12:09:48 <trackbot> ISSUE-142 -- Does box-ordinal-group change drawing order? -- open
12:09:48 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/142
12:10:13 <dbaron> (We previously discussed issue-138, issue-139, issue-140, and issue-141)
12:10:22 <fantasai> Alex: So Appendix E
12:10:33 <fantasai> Alex: There is a few options
12:10:45 <fantasai> Alex: One is getting rearranged throught the ordinal group
12:10:52 <fantasai> Alex: either draw in source order or layout order
12:11:05 <fantasai> Alex: Argument in favor of layout order is that it's more visually expected
12:11:16 <fantasai> Alex: Minor inconvenience is it will need an update to appendix E
12:11:35 <fantasai> Alex: Other issue is if we get to 2D flexible grid
12:12:03 <fantasai> Alex: It is less clear what order to paint, and source order makes more sense
12:12:30 <dbaron> dbaron: I think Appendix E should refer to order in the box tree
12:12:38 <dbaron> dbaron: And I think box-ordinal-group should change order in the box tree
12:12:41 <dbaron> dbaron: so I think we're done
12:12:53 <fantasai> Alex: So let's use layout order
12:13:19 <fantasai> Tab: I think that's the right source, and ordinal-group should rearrange the box tree
12:13:34 <fantasai> Tab: I don't currently have ordinal-group in my draft. bz doesn't like it. Are we still down with it?
12:13:57 <fantasai> dbaron: Our implementation is a little flaky. We only started using it for really critical stuff in this Firefox release
12:15:29 <fantasai> Tab: His problem was that if you have a large group, you have to run sorting algorithms on it
12:15:58 <dbaron> issue-143
12:16:02 <fantasai> fantasai: Might want to note that authors should avoid doing that if they want to avoid perf problems...
12:16:05 <dbaron> issue-143?
12:16:05 <trackbot> ISSUE-143 -- Does "shrink-to-fit" width of a flexbox child depend on available space? -- open
12:16:05 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/143
12:16:20 <dbaron> (we previously discussed ISSUE-138, ISSUE-139, ISSUE-140, and ISSUE-141)
12:16:37 <fantasai> Alex: I imagine someone sorting icons in the filesystm by assining fileize to box-ordinal-group
12:16:50 <fantasai> Alex: Is the pref width max by available, or not?
12:17:00 <fantasai> Alex: I believe in Mozilla it isn't
12:17:22 <fantasai> Alex: Given we're going to adjust that later with flex, it makes more sense to lay out in infinite width
12:18:44 <fantasai> dbaron: The issue here seems to be that WebKit is using fit-content where it should be using max-content
12:18:58 <fantasai> dbaron: I think we do want to use max-content
12:19:08 <fantasai> Tab: Ok, let's track Mozilla behavior here.
12:19:16 <dbaron> I can't really think of any use cases where this makes a big difference other than the text-in-tables type issue
12:19:19 <dbaron> ISSUE_144?
12:19:21 <dbaron> issue-144?
12:19:22 <trackbot> ISSUE-144 -- distribution of negative available space -- open
12:19:22 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/144
12:19:28 <fantasai> Tab: How we distribute negative space.
12:19:45 <fantasai> Alex: currently, the exact same algorithm that is used for positive space is applied to negative space just with a negative sign
12:20:12 <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.
12:20:24 <fantasai> Alex: I'm having a hard time finding any situation where it's useful.
12:21:00 <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
12:21:38 <fantasai> Tab explains some algorithm
12:22:25 <fantasai> dbaron: what if one has flex 1 and the other has flex 2
12:23:17 <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
12:23:45 <fantasai> ... TeX
12:23:55 <fantasai> dsinger: You should study the TeX glue model
12:24:24 <fantasai> dsinger: He solved this pretty solidly so you should go look at that
12:24:48 <fantasai> Alex: We should either ignore space when availspace is negative
12:24:53 <fantasai> Alex: and distribute some other way
12:25:07 <fantasai> Alex: Or have a separate value that is how to distribute when negative
12:25:43 <fantasai> dbaron: There are some cases where you want to distribute space in proportion to its flex
12:26:50 <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
12:27:16 <fantasai> dbaron draws a box with two boxes inside it
12:27:27 <fantasai> one of which has 2 boxes inside, the other of which has 4 inside
12:28:07 <fantasai> dbaron: In a case like this you do want to maintain flex ratio when distributing negative space
12:28:32 <fantasai> Alex If you shrink, you want to shrink proportionally to the amount of text ....
12:28:41 <fantasai> Tab: If the flex is proportional to their preferred widths.
12:28:53 <fantasai> Tab: When the flexes and preferred widths don't match, that's when you get the non-intuitive results.
12:29:03 <fantasai> dbaron: Maybe completely ignoring flex is fine
12:29:10 <dbaron> (when shrinking)
12:29:19 <fantasai> Tab: And shrinking in proportion of their preferred widths is fine
12:29:39 <dbaron> ISSUE-145?
12:29:39 <trackbot> ISSUE-145 -- inline-block children of flexbox -- open
12:29:39 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/145
12:30:33 <fantasai> fantasai: The spec should say 'inline-level elements' and then it's completely clear.
12:30:45 <fantasai> Tab: The spec groups inline elements together
12:31:54 <dbaron> dbaron: I think you at least want to group text and true inlines
12:31:58 <fantasai> Alex argues that inline-blocks should become individual items
12:33:05 <dbaron> Arron: whitespace?
12:33:08 <dbaron> Tab: just like tables
12:33:40 <dbaron> Alex: I want a model where flexbox with a bunch of buttons in it doesn't require display:flex on all the buttons
12:34:28 <dbaron> dbaron: I'd be fine with saying that you'd only wrap text and *non-replaced* inlines.
12:35:13 <fantasai> fantasai: Ok, so you want atomic inline-level elements to get individually wrapped, and non-replaced inlines get grouped
12:47:09 <dstorey> dstorey has joined #css
12:48:11 <dstorey_> dstorey_ has joined #css
12:51:15 <kubala> kubala has joined #css
12:54:21 <TabAtkins_> glazou: 2.1 issues
12:54:50 <TabAtkins_> fantasai: Issues 158, 159, and an unnumbered issue are all about margins and clearance.
12:55:04 <TabAtkins_> The original issue that caused this was issue 6.
12:55:58 <TabAtkins_> TabAtkins_: We really need to talk to Michael (Arron's coworker) about this.
12:56:17 <TabAtkins_> ACTION arron: Talk to coworker about proposed clearance changes.
12:56:17 <trackbot> Created ACTION-260 - Talk to coworker about proposed clearance changes. [on Arron Eicholz - due 2010-08-31].
12:56:59 <fantasai> http://wiki.csswg.org/spec/css2.1#issue-195
12:57:10 <fantasai> http://wiki.csswg.org/spec/css2.1#issue-158
12:57:14 <TabAtkins_> fantasai: Info about these issues was sent to the list.
12:57:16 <fantasai> with proposal http://lists.w3.org/Archives/Public/www-style/2010Aug/0458.html
12:57:25 <fantasai> http://wiki.csswg.org/spec/css2.1#issue-159
12:57:32 <fantasai> with proposal http://lists.w3.org/Archives/Public/www-style/2010Aug/0391.html
12:57:38 <fantasai> 158 and 159 should be editorial
12:58:22 <fantasai> back to 195
12:58:25 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0462.html
12:58:26 <TabAtkins_> dbaron: For issue 195, you could maybe say it divides it into two pieces, one on either side of the block?
12:58:53 <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.
12:59:03 <TabAtkins_> Bert: Perhaps add an "even if either side is empty"?
12:59:06 <TabAtkins_> fantasai: Sounds good to me.
12:59:28 <TabAtkins_> TabAtkins_: Sounds good.
12:59:54 <TabAtkins_> fantasai: The other issue I editted was the bidi one.
13:00:10 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0465.html
13:00:22 <fantasai> http://wiki.csswg.org/spec/css2.1#issue-187
13:01:06 <TabAtkins_> TabAtkins_: You have two possibilities in that proposal.  Do you know if either should be preferred for compat reasons?
13:02:01 <TabAtkins_> Bert: The "atomic inline" one seems easier.
13:02:46 <lstorset> lstorset has joined #css
13:02:48 <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.
13:03:31 <TabAtkins_> Bert: I'm not sure I understand what the "replaced element that would be inline if not replaced" means.
13:03:51 <TabAtkins_> TabAtkins_: An image, for example, will be replaced by ordinary alt text if not available.
13:05:29 <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.  
13:06:40 <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).
13:07:26 <TabAtkins_> Bert: There's a parenthetical about run-ins?
13:07:45 <TabAtkins_> fantasai: That's why the wording is so weird, specifically to handle runins, or else I'd just say display:inline.
13:09:06 <fantasai> s/say/say elements with/
13:13:25 <TabAtkins_> [side-discussion about run-in stuff related to this]
13:15:58 <TabAtkins_> fantasai: It seems that no one disagrees in principle with this, they're just confused by the wording?
13:16:03 <TabAtkins_> Bert: It's very confusing.
13:16:11 <TabAtkins_> arronei: Agreed.
13:18:02 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0448.html
13:22:47 <TabAtkins_> szilles: I thought of a problem with my suggested fix for issue 198, but I can't recall it exactly right now.
13:22:58 <szilles> szilles has joined #css
13:23:10 <TabAtkins_> ACTION Steve: Respond to yourself about issue 198.
13:23:10 <trackbot> Created ACTION-261 - Respond to yourself about issue 198. [on Steve Zilles - due 2010-08-31].
13:23:35 <TabAtkins_> howcome: Multicol moved into CR and has 6 implementations!
13:23:48 <TabAtkins_> howcome: They have a baseline level of compatibility.
13:24:01 <TabAtkins_> fantasai: Probably pagination issues will be the worst.
13:24:11 <TabAtkins_> howcome: What I'd like to spend time on is to fix two problems in the spec.
13:24:24 <TabAtkins_> howcome: 1) We don't really define how column rules behave when the content doens't fit nicely.
13:24:45 <glazou> s/doens/doesn
13:24:49 <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.
13:25:21 <TabAtkins_> howcome: double/solid/dashed/none make sense.  I don't know about hidden.
13:25:38 <TabAtkins_> dbaron: hidden only exists for the collapsing border model in tables.
13:26:11 <TabAtkins_> howcome: Also dotted.
13:26:28 <TabAtkins_> howcome: I think we should remove inset and outset.
13:26:59 <TabAtkins_> howcome: They come from buttons for a pseudo-3d effect.  But with columns you don't have that.
13:27:19 <TabAtkins_> fantasai: You should make it work like the collapsed borders model and treat them like ridge and groove.
13:27:38 <TabAtkins_> dbaron: Except that we got the spec backwards in collapsed borders years ago.
13:28:07 <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.
13:28:53 <TabAtkins_> howcome: That's an easy solution.
13:29:10 <dbaron> actually border collapse is the right way round
13:30:50 <TabAtkins_> howcome: Next issue is column rules.  They're drawn between columns, and are the currently the height of the multicol element.
13:31:12 <TabAtkins_> howcome: So even if something overflows, you don't have column rules going down to it.
13:31:29 <TabAtkins_> howcome: I think that if we extend, we don't want individual rules to extend individually.
13:32:00 <TabAtkins_> howcome: But then you have long column rules sticking out the bottom for seemingly no reason in the rest of the multicol.
13:33:00 <TabAtkins_> howcome: Also, there's a question of if you should draw rules between columns that that overflow the multicol horizontally.
13:33:12 <TabAtkins_> howcome: Robert argues on the list that you should treat them the same.
13:33:52 <mg> mg has joined #CSS
13:34:16 <TabAtkins_> howcome: But also maybe it looks more elegant to keep the rules horizontally.
13:34:35 <TabAtkins_> [everyone agrees that it looks better to show them horizontally, cut them vertically]
13:35:49 <TabAtkins_> howcome: Also, what if people make column rules that are super wide and would overflow the content?
13:37:06 <TabAtkins_> [agreement that authors should be allowed to do that if they feel like it, don't try to clip]
13:37:19 <TabAtkins_> fantasai: What's the stacking order for column rules?
13:37:29 <fantasai> s/just above the background/between the background and the border/
13:37:37 <fantasai> proposed text ^
13:37:46 <TabAtkins_> howcome: Cool.
13:38:28 <fantasai> s/just above the background/immediately below the border (above the background)/
13:38:29 <TabAtkins_> alexmog: If you had only two columns, there'd only be one rule and nothing outside the box (in your example)?
13:38:32 <TabAtkins_> howcome: Yes.
13:39:31 <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?
13:40:34 <TabAtkins_> howcome: The spec says to make them the full height.
13:40:39 <TabAtkins_> [agreement, looks good]
13:40:52 <TabAtkins_> howcome: though I think we might want to add border-clip ability to rules at some point
13:40:54 <TabAtkins_> [agreement]
13:41:18 <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.
13:41:51 <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.
13:42:05 <Bert> ISSUE-129?
13:42:05 <trackbot> ISSUE-129 -- balanced columns in fixed-height -- open
13:42:05 <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/129
13:42:59 <TabAtkins_> howcome: [draws a diagram with 3 columns.  An h2 is col-span:all in the middle, with text above and below it.]
13:43:22 <TabAtkins_> alexmog: Conceptually, the text above the h2 comes before it in the source, text below it is after it in the source.
13:43:56 <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?
13:44:41 <TabAtkins_> dbaron: Maybe col-span:all should be cancelled on overflow sections?
13:46:06 <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.
13:46:47 <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.
13:47:04 <TabAtkins_> fantasai: I don't know if I like that.
13:49:20 <TabAtkins_> [pagination discussion - how multicols work in paged media]
13:49:22 <miketaylr> miketaylr has joined #css
13:53:16 <TabAtkins_> dbaron: Why do we allow column balancing in a fixed-height container?
13:53:43 <TabAtkins_> howcome: I think it looks nice.
13:53:56 <TabAtkins_> alexmog: You might have a paged implementation where you want to balance the last page.
13:54:19 <TabAtkins_> howcome: Also if you have a min-height or max-height, it could suddenly stop balancing because the content got too large.
13:54:41 <TabAtkins_> [back to colspan discussion]
13:54:56 <TabAtkins_> [colspan gets turned off if the element is in an overflow situation]
13:55:22 <TabAtkins_> dbaron: That content ordering is crazy.  Would anyone ever want that?
13:56:51 <TabAtkins_> dbaron: I'm also not sure it makes sense to have a colspan on a fixed height element.
13:57:30 <TabAtkins_> alexmog: It makes lots of sense in a paged situation.
13:59:23 <dbaron> s/on a fixed height element/in fixed height columns/
14:01:16 <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.
14:01:44 <fantasai> s/situation/column/
14:04:16 <TabAtkins_> dbaron: What I want to say is that colspan doesn't do anything if your column is fixed height.
14:04:55 <TabAtkins_> dbaron: The case where you're actually doing fixed-height columns, you're not wanting actual colspans.
14:05:05 <TabAtkins_> TabAtkins_: What about paged media?
14:05:37 <TabAtkins_> dbaron: I'm distinguishing fixed height from paged media.  They work differently, and won't cause a problem.
14:06:41 <dsinger_> dsinger_ has joined #css
14:06:48 <CesarAcebal> CesarAcebal has joined #css
14:06:52 <jdaggett> jdaggett has joined #css
14:06:54 <dstorey> dstorey has joined #css
14:06:54 <glazou> glazou has joined #css
14:07:22 <TabAtkins_> TabAtkins_ has joined #css
14:12:11 <TabAtkins_> fantasai: How about columns overflow downwards?
14:12:21 <TabAtkins_> TabAtkins_: In multiples of the original height!
14:13:12 <TabAtkins_> fantasai: But an original use-case was specifically to flow columns sideways.
14:13:32 <TabAtkins_> fantasai: And we resolved on that.
14:16:02 <smfr> smfr has joined #css
14:16:35 <TabAtkins_> TabAtkins_: Maybe a property at some point to specify how multicols should place their overflow columns.
14:16:53 <TabAtkins_> szilles: And that solves dbaron's issue, I believe, if you overflow them downwards in a "paged" fashion.
14:16:54 <TabAtkins_> dbaron: Yeah.
14:17:27 <Bert> ('div.article {overflow: auto; overflow-style: paginate}' -- makes flippable pages, instead of a scrollbar or something else continuous.)
14:18:11 <TabAtkins_> howcome: I think we don't want to add anything for the vertical overflow yet.  We'll just go with alex's proposal.
14:20:08 <dbaron> I still don't think anybody has shown any reasonable case that would be disabled.
14:20:19 <TabAtkins_> RESOLVED: Use Alex's suggestion for disabling colspan on elements located in overflow columns.
14:20:23 <nimbupani> nimbupani has joined #css
14:33:30 <tantek> tantek has joined #css
14:33:49 <tantek> topic: Box Shadow Blur
14:34:03 <smfr> ooh maybe i should call in
14:34:06 <fantasai> http://dev.w3.org/csswg/css3-background/#the-box-shadow
14:35:05 <tantek> (phone rings)
14:35:07 <dbaron> smfr, can you hear us?
14:35:17 <smfr> very badly
14:35:19 <smfr> garbled
14:35:25 <smfr> i'll try calling again
14:35:38 <tantek> fantasai: we want a note saying something about half the standard deviation
14:36:14 <fantasai> s/fantasai/dsinger/
14:36:34 <dbaron> (that's the coffee machine)
14:36:45 <tantek> dsinger: as long as we don't talk about the edge of it
14:37:15 <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.
14:37:27 <tantek> tab: we're no longer referring to the edge of the blur because that doesn't exist.
14:37:38 <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
14:37:42 <anne5> (sorry about that)
14:37:43 <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. 
14:38:00 <tantek> tab: ... two standard deviations and that's really easy
14:38:36 <tantek> tab: at the blur radius ... 97%
14:38:55 <tantek> q&a between jdagget and tabatkins
14:39:13 <tantek> tab: that's the old text
14:39:31 <tantek> fantasai: i thought i fixed that.  tab: i thought i did too.
14:39:34 <fantasai> "with a standard deviation equal to the half the blur radius "
14:39:37 <smfr> this phone is terrible
14:39:49 <smfr> i'm fine with the current spec btw
14:39:51 <fantasai> mispasted the old text, sorry
14:40:25 <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.
14:40:27 <dsinger_> I think 2*sigma is actually 95%
14:40:42 <tantek> tab: if you want the shadow to extend out....
14:40:53 <fantasai> visibly by the amount of the blur radius
14:41:34 <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
14:41:48 <tantek> fantasai: if everybody is happy with current text we can resolve this issue
14:42:21 <tantek> jdaggett - it may affect pixels beyond
14:42:24 <tantek> tab: it will
14:42:31 <Curt`> Curt` has joined #css
14:42:41 <tantek> dsinger: if I'm running on a 16 bit system...
14:42:50 <tantek> tab: but even there, you won't be able to see ...
14:43:12 <tantek> jdaggett - I would watch that assertion - with the right color and background you will see it for a long way
14:43:30 <tantek> jdaggett - if you have issues where the surrounding geometry is very distinguishable, you'll be able to see it more.
14:43:38 <tantek> szilles: isn't this an implementation issue?
14:43:57 <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.
14:44:03 <anne5> http://dev.w3.org/csswg/css3-background/#the-box-shadow
14:45:01 <tantek> (skype discussion for getting another person on the phone)
14:45:17 <Martijnc> Martijnc has joined #CSS
14:45:35 <smfr> don't they have conference calls in norway?
14:46:02 <anne5> we use telepathy here
14:46:12 <glazou> vikings use empty bottles ok aquavit only
14:46:16 <glazou> s/ok/of
14:46:50 <tantek> (dbaron sets up a moz conf)
14:46:54 <dbaron> 650-903-0800, 92#, 210#
14:47:14 <tantek> (bert sets up zakim)
14:47:15 <Bert> caonf code 83261
14:47:23 <bradk> bradk has joined #css
14:47:29 <tantek> welcome bradk
14:47:38 <dbaron> 617-761-6200, conf 83261
14:48:12 <Ms2ger> Ms2ger has joined #css
14:48:25 <dbaron> Zakim, this is 83261
14:48:26 <tantek> +1.617.761-6200,,,83261#
14:48:35 <Zakim> Zakim has joined #CSS
14:48:36 <dbaron> Zakim, this is 83261
14:48:36 <Zakim> dbaron, I see Team_(test)14:46Z in the schedule but not yet started.  Perhaps you mean "this will be 83261".
14:48:42 <dbaron> Zakim, this is 83261
14:48:42 <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
14:48:51 <tantek> (HÃ¥kon dials Zakim)
14:49:03 <Bert> zakim, move 83261 to here.
14:49:04 <Zakim> ok, Bert; that matches Team_(test)14:46Z
14:49:11 <dbaron> zakim, who is on the phone?
14:49:11 <Zakim> On the phone I see +47.23.69.aaaa, smfr
14:49:19 <dbaron> Zakim, aaaa is [Opera]
14:49:19 <Zakim> +[Opera]; got it
14:49:22 <TabAtkins_> bradk: Yo, if you're in the room, call in.
14:49:45 <tantek> (static on phone, laughter)
14:49:57 <smfr> btw i have to leave early again (physical therapy today)
14:50:38 <tantek> fantasai: we have another topic, which is the stacking order of the inset shadows
14:51:03 <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
14:51:15 <Zakim> +bradk
14:51:35 <tantek> fantasai: the proposal is to paint the inset shadows above the content layer, but not z-index things
14:51:56 <tantek> dbaron: so if you have an inner box shadow it overlaps the text in the box?
14:52:01 <tantek> fantasai, tab: yes
14:52:23 <tantek> dbaron: ok
14:52:24 <smfr> i don't like this proposal
14:52:29 <smfr> it has stacking context implications
14:52:30 <bradk> Im here, connection is bad.
14:52:35 <tantek> fantasai: the z-index lets you pop things out and bring them forward
14:52:44 <tantek> tabatkins: children with a higher z-index are painted above
14:52:59 <tantek> dbaron: you want to say it in terms of [CSS21] appendix C, not in terms of z-index
14:53:07 <dbaron> s/appendix C/appendix E/
14:53:10 <smfr> agreed
14:53:12 <tantek> fantasai: it's a lot of layers so you need something more precise
14:53:27 <tantek> fantasai: it's between layers 8 and 9
14:53:33 <tantek> dbaron: you don't want to say it that way either
14:53:41 <smfr> http://www.w3.org/TR/CSS2/zindex.html
14:53:42 <tantek> fantasai: 8 & 9 in the sublist of 7
14:53:52 <tantek> fantasai: not it is top level 8 & 9 - not sublist
14:54:09 <smfr> so does an inset shadow make the element a stacking context?
14:54:12 <Zakim> -bradk
14:55:04 <tantek> dbaron: we need a new top level paint layer for inset box shadows
14:55:49 <Zakim> +bradk
14:55:49 <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 ....
14:55:54 <tantek> (that was dbaron)
14:56:18 <tantek> dbaron: that top level list is what to do for each stacking context
14:56:29 <tantek> dbaron: for each stacking context you paint ... i'm trying to think about what this means
14:57:13 <bradk> My connetion is bad, but would it be possible to only paint above the content when there is non-visible clipping?
14:57:38 <tantek> dbaron and fantasai discuss
14:57:42 <bradk> That would also make it look best with things that protrude outside due to negative margin, etc.
14:58:00 <sylvaing> sylvaing has joined #css
14:58:07 <tantek> fantasai: where is a block child painted ... here....
14:58:24 <smfr> so if you paint the shadow above the content, think about what things look like with overflow
14:58:32 <smfr> borders draw under the content
14:58:35 <tantek> dbaron: you can stick it in point 3 or 4 in sublist 7
14:58:40 <smfr> if the shadow draws on top, it's just weird
14:59:09 <smfr> gonna drop off the phone; it's useless
14:59:15 <Zakim> -smfr
14:59:38 <smfr> also, doesn't this mean that the inset shadow draws above the border?
15:00:27 <fantasai> So the proposal is to paint inset shadows immediately below the outline.
15:01:14 <fantasai> And yes, this would have the side-effect of drawing the shadow above a border-image
15:01:20 <smfr> i think this is weird
15:01:20 <fantasai> (since it will never overlap with the border)
15:01:38 <smfr> i think the shadow should be between the background and the border
15:01:45 <dbaron> sylvaing, Zakim bridge?
15:01:59 <tantek> tab: if you're having the border-image extend into the box - that's how it works
15:02:04 <sylvaing> dbaron, no was using number sent by Hakon. trying bridge now
15:02:43 <sylvaing> conf code ?
15:02:49 <Bert> zakim, code?
15:02:49 <Zakim> the conference code is 83261 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), Bert
15:02:52 <smfr> if it's just under the outline, then you've lost the "pop out with z-index" trick
15:03:25 <bradk> TThe call quality is like listening to a tin can
15:03:27 <smfr> so the shadow will draw over abs pos, z-index children, which is also weird
15:03:29 <dsinger> dsinger has joined #css
15:03:32 <dbaron> tab: the point of having box-shadow back into the draft was having something simple that we could accomplish now
15:03:38 <CesarAcebal> CesarAcebal has joined #css
15:03:39 <tantek> tantek has joined #css
15:03:42 <jdaggett> jdaggett has joined #css
15:03:42 <glazou> glazou has joined #css
15:03:47 <tantek> ...
15:04:02 <smfr> i'm with tab; we're making too many changes to box-shadow at this point
15:04:07 <dstorey_> dstorey_ has joined #css
15:04:26 <bradk> smfr, can look good if you have light colored items inside a scrollable box with inset shadow.
15:04:31 <dbaron> I'm with smfr
15:04:34 <tantek> tab: "i'm with you you're wrong"
15:04:52 <tantek> dbaron: I'd really like to get box-shadow unprefixed
15:05:03 <Zakim> + +1.206.324.aabb
15:05:06 <TabAtkins_> TabAtkins_ has joined #css
15:05:30 <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
15:06:39 <fantasai> fantasai: So you either get inset shadows over the content, or you get it under the border-image. You can't have both.
15:06:50 <smfr> yep
15:06:58 <fantasai> fantasai: Unless, perhaps, you have two different inset-ing keywords, one which paints at one layer and one which paints at another.
15:07:08 <smfr> ugh
15:07:14 <tantek> tab: so no change to box-shadow now, but plans for v4 that will somehow draw intelligently on top of content
15:07:16 <fantasai> fantasai: and we could add the other keyword in CSS4 Backgrounds and Borders
15:07:24 <bradk> Overflow can be the trigger
15:07:27 <smfr> or wait for future filtery things
15:07:56 <tantek> tab: overflow could be the trigger
15:08:06 <dbaron> s/tab:/bradk:/
15:08:09 <tantek> tab: brad, could you explain what you mean?
15:08:38 <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?
15:09:12 <tantek> tab: .... --- .... ----
15:09:21 <smfr> i think interaction between different properties like that should be discouraged
15:09:21 <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
15:09:38 <tantek> brad: when i did an experiment with ...
15:09:57 <tantek> brad: it looks kind of strange to have the shadows behind them and scrolled out of view - it just doesn't seem natural
15:10:21 <tantek> tab: this might be trying to make box-shadow too realistic
15:10:37 <tantek> tab: in the mean time we do nothing. we recognize the use-case, but not with box-shadow
15:10:52 <sylvaing> agrees with tab; if we want realism the feature already has many shortcomings
15:10:56 <tantek> tab: inset box-shadows above the background layer - what they do now, below the content
15:11:00 <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.
15:11:03 <sylvaing> unclear why inset needs to be more real than the rest
15:11:16 <TabAtkins_> Agreed, sylvaing.
15:11:17 <tantek> fantasai: they are using it for glowy effects
15:11:20 <sylvaing> is comfortable with a simple decorative effect
15:11:24 <fantasai> lightbox
15:11:41 <sylvaing> but is not a designer either. argh.
15:12:06 <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"
15:12:19 <bradk> typing...
15:12:24 <Zakim> -bradk
15:12:44 <tantek> zakim, attendees
15:12:44 <Zakim> I don't understand 'attendees', tantek
15:12:47 <dbaron> Zakim, who is on the phone?
15:12:47 <Zakim> On the phone I see [Opera], +1.206.324.aabb
15:12:52 <dbaron> Zakim, aabb is sylvaing
15:12:52 <Zakim> +sylvaing; got it
15:13:10 <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.
15:13:22 <bradk> It really looks pretty weird when you do that, IMO
15:13:35 <fantasai> bradk: if it paints over the content, it has to paint over the border-image
15:13:47 <fantasai> bradk: so there's an unfortunate tradeoff here
15:14:37 <bradk> Agreed it is unfortunate. But in my way, it would be limited to when you have overflow:[not visible]
15:14:55 <fantasai> bradk: I think we have consensus that that kind of out-of-left-field trigger is a bad idea
15:15:06 <bradk> And that can be turned on and off for a lot of content without much other noticiable effect
15:15:15 <tantek> (tab makes an example)
15:15:27 <tantek> tab: scrolling with a box-shadow does look bad
15:15:27 <fantasai> bradk: If we want a trigger, it should be in the box-shadow property itself
15:15:35 <tantek> tab: oh wait - it's fine
15:15:49 <tantek> tab: this is right, the shadow shouldn't scroll
15:16:10 <bradk> It's just that, with overflow:scroll, for instance, that it almost always looks wrong, unless all the content is black.
15:16:15 <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>
15:16:42 <TabAtkins_> fantasai: I think Brad's right - it will look bad in a *lot* of cases.
15:16:52 <anne5> (WebKit only does box-shadow prefixed)
15:16:57 <tantek> fantasai: then we have the implementation issue that people want to drop prefixes
15:17:01 <sylvaing> it looks bad in a lot of other cases too
15:17:09 <bradk> Now make even bigger blurrier shadows in that example...
15:17:30 <sylvaing> e.g. when background-color is transparent and you can't see the shadow underneath but can see the body backgroundc-olor
15:17:43 <tantek> HÃ¥kon introduces David of Opera who is implementing box-shadow
15:17:44 <sylvaing> the feature already has a very limited scope
15:17:49 <tantek> David: I think I agree with what you're saying
15:18:02 <tantek> David: we should leave box-shadow as it is
15:18:05 <sylvaing> yet there is no doubt that it already is useful to authors
15:18:13 <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.
15:18:53 <anne5> (Opera currently does box-shadow unprefixed)
15:19:06 <bradk> What is the downsde of an overflow trigger?
15:19:26 <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.
15:19:28 <anne5> (Gecko prefixed)
15:19:40 <tantek> tab: with repairing this issue, a majority of things will still look bad with inset box-shadows
15:19:47 <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.
15:19:48 <tantek> tab: that's just how it is, we'll do it properly later
15:20:04 <bradk> Just limits border-image in overflow inset-shadow situations, as upposed to all overflow inset-shadow situations looking weird
15:20:16 <tantek> fantasai: we can put both definitions in the spec, with different keywords and mark them both at risk.
15:20:25 <tantek> we mark both inset and inner shadows as at risk
15:20:32 <bradk> Then you could properly fix it for border-image later and have a good default now?
15:20:33 <tantek> tab: acceptable to you dbaron?
15:20:48 <tantek> tab: add another keyword for the additional behavior and mark it at risk
15:20:58 <tantek> dbaron: i'd rather not keep adding stuff
15:21:06 <smfr> i don't want a new keyword at all
15:21:06 <tantek> dbaron: two years ago we wanted to be done
15:21:19 <sylvaing> agree with dbaron and smfr
15:21:34 <Zakim> -sylvaing
15:21:42 <tantek> we can always add a new keyword later if someone has a solid proposal
15:21:56 <dbaron> Zakim, who is on the phone?
15:21:56 <Zakim> On the phone I see [Opera]
15:22:00 <Zakim> -[Opera]
15:22:01 <Zakim> Team_(test)14:46Z has ended
15:22:02 <tantek> fantasai: we have a solid proposal
15:22:02 <Zakim> Attendees were +47.23.69.aaaa, smfr, [Opera], bradk, +1.206.324.aabb, sylvaing
15:22:09 <tantek> URL for said solid proposal?
15:22:35 <tantek> fantasai: what you want to do to make everything look supercool is to put content on the shadow and border-image and ...
15:22:45 <tantek> tab: hopefully someday filters will let us do this
15:22:58 <tantek> (like IE4 filters? ;) )
15:23:16 <tantek> tab: we want something like that
15:23:17 <jdaggett> jdaggett: in java2d if possible...
15:23:27 <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)
15:23:28 <bradk> That might be supercool, but I'd settle for reasonable in the majority use cases
15:23:35 <fantasai> RRSAgent: pointer
15:23:35 <RRSAgent> See http://www.w3.org/2010/08/24-CSS-irc#T15-23-35
15:23:42 <fantasai> there's your url
15:23:53 <tantek> so noted
15:24:38 <tantek> (quiet typing)
15:25:01 <tantek> tab: that's what we want to do
15:25:04 <tantek> fantasai: nothing right now?
15:25:08 <tantek> tab: nothing right now
15:25:14 <tantek> håkon: let's go to CR
15:25:35 <Ms2ger> HÃ¥kon++
15:26:08 <bradk> I'm hearing that 'inset-overlay' would be "at-risk" (code for "never to be implemented")
15:27:02 <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 !
15:27:03 <bradk> True?
15:27:16 <TabAtkins_> bradk: No, we're just not going to do it at all right now.
15:28:05 <bradk> It is really only in overflow situations that it bothers me, and then almost always in those situations
15:28:29 <bradk> Come on, I'm not asking for ray tracing
15:28:40 <tantek> (slightly more furious typing)
15:29:13 <tantek> Bert: so is the resolution CR?
15:29:17 <tantek> Bert: I'm waiting for the chair
15:29:24 <bradk> Well and in some replaced objects too
15:29:32 <tantek> glazman: absolutely
15:29:44 <tantek> RESOLVED: publish as CR
15:30:11 <TabAtkins_> bradk, B&B4!
15:30:24 <tantek> dbaron: we might want a work item in the charter for some sort of a filters spec
15:30:31 <tantek> fantasai: that would be something with the SVG folks
15:30:35 <bradk> OK. What about images? As is on those too?
15:30:40 <tantek> fantasai: maybe make them primarily responsible for that?
15:30:47 <fantasai> images are no different than other content
15:31:04 <bradk> OK with me
15:31:29 <fantasai> RESOLVED: add filters spec to charter, as a joint item with SVG
15:31:36 <tantek> glazman: how should we name that?
15:31:42 <bradk> on rectangular images with no alpha channel, you can't see the inner shadow. Minor limitation. OK.
15:31:47 <tantek> szilles: i have to raise an objection unless it is specified more closely than that
15:31:56 <tantek> fantasai: the application of SVG filters to CSS
15:32:02 <tantek> dbaron: making SVG filters usable for CSS
15:32:12 <tantek> szilles: I'm ok with what dbaron said
15:32:20 <tantek> (cross talk)
15:32:25 <tantek> glazman: what should we name it?
15:32:37 <tantek> fantasai: CSS filters?
15:32:49 <bradk> Extended visual effects?
15:32:50 <tantek> glazman: ok
15:33:08 <tantek> (naming bikeshed)
15:33:29 <fantasai> CSS Filter Effects
15:33:38 <tantek> håkon: the idea is to use SVG syntax?
15:33:47 <tantek> dbaron: I think we may want a more CSS like syntax for it
15:33:53 <tantek> dbaron: we need better notions of CSS layers
15:34:03 <tantek> dbaron: SVG has notion of using fill or stroke as input to the filter
15:34:13 <tantek> dbaron: we need content, or border, or background as inputs to a filter
15:34:17 <smfr> i anticipate some "convenience" properties for common filters
15:34:17 <tantek> tab: yes we want to do that
15:34:21 <fantasai> Tab: That was the whole point ofBrad's presentation at tpac
15:34:35 <tantek> tab: at least for the canned filter effects, we want a convenient syntax for it
15:34:37 <bradk> yep
15:34:39 <tantek> bert: url()
15:34:43 <tantek> tab: I don't want that
15:34:52 <tantek> fantasai: you still have to type the input
15:35:02 <tantek> bert: that's what the web is for , URLs
15:35:09 <smfr> div { filter: blur(10px); }
15:35:11 <tantek> tab: I don't want to type URLs!
15:35:15 <smfr> or div { blur: 10px; }
15:35:18 <fantasai> no
15:35:20 <bradk> I agree with tab
15:35:21 <tantek> dsinger: let's table this argument
15:35:29 <tantek> bert: i object to reinventing the wheel
15:35:36 <tantek> (syntax bikeshed)
15:35:49 <tantek> glazman: we are not going to discuss this now
15:35:51 <smfr> gog
15:35:53 <smfr> gtg
15:36:03 <tantek> dsinger: once we have a editor's draft we can then argue
15:36:05 <sylvaing> i don't object to reinventing bert
15:36:24 <tantek> glazman: we can close this topic now
15:36:26 <tantek> next topic
15:36:28 <tantek> ------------------------
15:36:36 <tantek> glazman: next meeting in Lyon in November
15:36:48 <tantek> glazman: dbaron proposed to host next meeting after that in Mozilla in Mountain View
15:36:56 <tantek> glazman: March
15:37:07 <tantek> szilles: we also need summer
15:37:15 <tantek> glazman: june or august?
15:37:23 <anne5> is http://software.hixie.ch/utilities/js/live-dom-viewer/saved/596 a bug in Firefox?
15:37:27 <tantek> szilles: tpac will be in oct or nov and not in europe
15:37:38 <tantek> dbaron: boston in november is not that bad
15:37:54 <tantek> glazman: we still need one between tpac and moz
15:38:39 <tantek> jdaggett: proposal, it would be really good to get a set of people in Japan
15:38:39 <sylvaing> thinks we are due to host and strongly suggests august
15:38:50 <sylvaing> but definitely prefers Japan :)
15:38:51 <tantek> dbaron: march, june or august? i don't know.
15:38:59 <tantek> tab: bay area is great in june
15:39:10 <tantek> dbaron: maybe we shouldn't sched too much for the weather
15:39:21 <bradk> +1 for bay area
15:39:44 <sylvaing> dbaron: weather is important so we can show seattle people what a shadow looks like
15:40:54 <sylvaing> would actually prefer june, early august at the latest. just remembered I'm getting married around that time (ahem)
15:41:18 <bradk> Congrats!
15:41:27 <tantek> (office discussions)
15:42:16 <TabAtkins_> woo!
15:42:37 <dbaron> sounds like things moving towards Mozilla/Mountain View in March and Tokyo in June or so...
15:42:41 <TabAtkins_> sylvaing, when's the honymoon?
15:43:04 <mollydotcom> Sylvaing: Glazou wants to know when the honeymoon is, as he'd like to crash the party ;)
15:43:18 <tantek> jdaggett: who is minuting?
15:43:24 <sylvaing> writes up a proposal for an HTML5 <shudder> element
15:43:29 <tantek> jdaggett: adobe, opera, mozilla, google will check availability
15:43:30 <fantasai> Adobe, Opera, Google, and Mozilla will check availability for Tokyo in June
15:43:48 <tantek> sylvaing - see emotionML from w3c
15:45:12 <anne5> I think it's https://bugzilla.mozilla.org/show_bug.cgi?id=319729
15:45:17 <bradk> Where/when is next tpac?
15:45:24 <fantasai> boston november 2011
15:45:25 <gsnedders> bradk: November, Lyon
15:45:37 <gsnedders> OR you mean after that?
15:45:43 <fantasai> best guess above :)
15:45:48 <fantasai> for the one after 2010
15:45:48 <dbaron> fantasai is guessing about Boston November 2011
15:45:52 <dbaron> but it seems somewhat likely
15:45:54 <Lachy> Lachy has joined #css
15:46:06 <bradk> K, thanx
15:46:25 <sylvaing> if Mozilla hosts in Tokyo in August, shouldn't someone else host in March ?
15:46:38 <tantek> (discussion of weather continues)
15:46:57 <jdaggett> sylvaing: talking about tokyo in june
15:47:15 <jdaggett> at (mozilla, adobe, google, or opera)
15:47:24 <tantek> (holiday family reunion discussions)
15:47:29 <sylvaing> jdaggett, check. thx.
15:48:24 <tantek> (minuter taking a break)
15:48:27 <fantasai> first week of June, 2nd half, works for me, Bert, and Steve
15:48:29 <fantasai> glazou, too
15:48:45 <sylvaing> sylvaing++
15:48:45 <tantek> (calendar math discussions continue)
15:48:46 <dbaron> 2nd half == wed-thu-fri
15:48:54 <fantasai> WTF first week of June
15:49:18 <fantasai> 2-4
15:49:25 <dbaron> 1-3 or 8-10 ?
15:49:42 <fantasai> 1-3
15:49:46 <fantasai> I think
15:49:59 <jdaggett> jdaggett: yeah, june 1-3 sounds good
15:51:32 <dbaron> dsinger says bad for March 14 or March 21 weeks
15:51:36 <dbaron> Elika has conflict Feb 26
15:51:37 <jdaggett> talking about early march at mozilla in mv
15:52:04 <jdaggett> week of feb 28th/march 7th
15:53:17 <dbaron> Feb28-Mar1-Mar2 is a M-T-W
15:55:02 <bradk> bradk has joined #css
15:55:31 <lstorset1> lstorset1 has joined #css
15:55:57 <bradk> Sorry, is the meeting over?
15:56:10 <gsnedders> bradk: You think they can agree meeting dates that quickly?
15:56:40 <dbaron> Mar 2-3-4 (W-R-F) or Mar 7-8-9 (M-T-W)
15:56:56 <glazou> bradk: yes tech discussions over
15:56:59 <Bert> We're just discussing ftf dates, no more topics for today.
15:58:29 <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.
15:59:33 <dbaron> SXSWi is Mar 11-15
15:59:46 <dbaron> ok, so tentatively Mar 7-8-9 (M-T-W)
15:59:54 <glazou> glazou has joined #css
16:00:01 <tantek> glazman: that's it for today
16:00:07 <tantek> MEETING CLOSED FOR THE DAY
16:00:10 <tantek> ---------------------------------------------------------
16:04:41 <howcome> http://cafeisabella.no/
16:37:13 <tantek> tantek has joined #css
16:46:38 <tantek_> tantek_ has joined #css
16:50:05 <tantek_> tantek_ has joined #css
16:54:44 <tantek_> tantek_ has joined #css
17:09:36 <sylvaing> sylvaing has joined #css
17:20:30 <Doofl> Doofl has left #css
17:34:08 <Zakim> Zakim has left #CSS
17:41:54 <tantek> tantek has joined #css
17:47:38 <tantek_> tantek_ has joined #css
18:04:52 <tantek> tantek has joined #css
18:37:04 <Arron> Arron has joined #css
18:37:31 <jdaggett> jdaggett has joined #css
18:37:55 <tantek> tantek has joined #css
18:53:00 <dbaron> dbaron has joined #css
19:38:44 <TabAtkins_> TabAtkins_ has joined #css
19:52:34 <dsinger> dsinger has joined #css
19:57:55 <dsinger_> dsinger_ has joined #css
20:10:10 <lstorset> lstorset has joined #css
20:29:47 <howcome> howcome has joined #css
20:44:49 <howcome> howcome has left #css
20:53:13 <lstorset> lstorset has joined #css
21:36:27 <dsinger> dsinger has joined #css
22:55:23 <lstorset> lstorset has joined #css
23:11:43 <nimbupani> nimbupani has joined #css
23:58:54 <dstorey> dstorey has joined #css