16:32:11 <RRSAgent> RRSAgent has joined #css
16:32:11 <RRSAgent> logging to http://www.w3.org/2012/01/18-css-irc
16:32:16 <glazou> Zakim, this will be Style
16:32:16 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 28 minutes
16:32:22 <glazou> RRSAgent, make logs public
16:37:42 <bradk> bradk has joined #css
16:50:44 <Rossen> Rossen has joined #css
16:51:29 <glazou> bradk: the forum thread and others
16:51:30 <glazou> agreed
16:51:37 <glazou> that happens from time to time
16:52:37 <bradk> I still have 184 unread messages, and I was actually caught up a couple days ago (just skimming some long threads).
16:52:48 <oyvind> oyvind has joined #css
16:53:31 <Zakim> Style_CSS FP()12:00PM has now started
16:53:38 <Zakim> +arno
16:54:00 <nimbu> hmm i am on the call but dont see myself :/
16:54:12 <Zakim> -arno
16:54:14 <Zakim> Style_CSS FP()12:00PM has ended
16:54:14 <Zakim> Attendees were arno
16:54:37 <Zakim> Style_CSS FP()12:00PM has now started
16:54:44 <Zakim> +bradk
16:54:45 <Zakim> +arno
16:55:20 <jdaggett> jdaggett has joined #css
16:56:41 <glenn> glenn has joined #css
16:56:55 <Zakim> +plinss
16:57:27 <antonp> antonp has joined #css
16:57:38 <Zakim> +Molly_Holzschlag
16:57:47 <Zakim> +??P26
16:57:59 <nimbu> i think my number has been appropriated by arno
16:57:59 <sylvaing> sylvaing has joined #css
16:58:00 <jdaggett> zakim, +??p26 is me
16:58:00 <Zakim> sorry, jdaggett, I do not recognize a party named '+??p26'
16:58:01 <nimbu> some how.
16:58:09 <Zakim> +??P27
16:58:17 <glazou> Zakim, ??P27 is me
16:58:17 <Zakim> +glazou; got it
16:58:18 <Zakim> +??P34
16:58:19 <jdaggett> zakim, ??p26 is me
16:58:19 <Zakim> +jdaggett; got it
16:58:20 <Zakim> +antonp
16:58:29 <nimbu> glazou: how do i change a number that has been allocated to arno to myself?
16:58:43 <Zakim> +GlennAdams
16:59:14 <Zakim> +??P37
16:59:19 <florianr> Zakim, I am ??P37
16:59:20 <Zakim> +??P36
16:59:27 <fantasai> florianr: or are you P36? :)
16:59:33 <fantasai> zakinm, mute P36
16:59:34 <Zakim> +florianr; got it
16:59:35 <florianr> not sure
16:59:54 <smfr> smfr has joined #css
16:59:58 <fantasai> Zakim, mute P36
16:59:58 <Zakim> +[Apple]
16:59:59 <hober> Zakim, Apple has me
17:00:01 <Zakim> sorry, fantasai, I do not know which phone connection belongs to P36
17:00:04 <Zakim> +hober; got it
17:00:05 <fantasai> Zakim, mute ??P36
17:00:06 <Zakim> ??P36 should now be muted
17:00:08 <Zakim> +??P41
17:00:23 <fantasai> zakim, florianr is fantasai
17:00:24 <Rossen> Zakim, ??41 is me
17:00:29 <Zakim> +fantasai; got it
17:00:33 <Zakim> sorry, Rossen, I do not recognize a party named '??41'
17:00:33 <nimbu> zakim, arno is me
17:00:33 <fantasai> zakim ??P36 is florianr
17:00:35 <Rossen> Zakim, ??P41 is me
17:00:39 <Zakim> +smfr
17:00:43 <Zakim> +nimbu; got it
17:00:48 <Zakim> +Rossen; got it
17:00:48 <dbaron> dbaron has joined #css
17:00:49 <Zakim> +[IPcaller]
17:00:57 <sylvaing> Zakim, [IPcaller] is sylvaing
17:01:03 <Zakim> -??P36
17:01:07 <Zakim> +stearns
17:01:09 <Zakim> +sylvaing; got it
17:01:15 <plinss> nimbu: the zakim number to name mapping page is here: https://www.w3.org/1998/12/bridge/info/name.php3
17:01:22 <Ms2ger> sylvaing, btw, I believe the process document states that WG chairs appoint editors
17:01:39 <Zakim> +TabAtkins
17:01:46 <Zakim> +??P53
17:01:50 <florianr> Zakim, I am ??P53
17:01:58 <Zakim> + +1.415.766.aaaa
17:02:06 <dbaron> Zakim, aaaa is me
17:02:22 <Zakim> +??P58
17:02:29 <kojiishi> zakim, ??p58 is me
17:02:30 <Zakim> +florianr; got it
17:02:48 <Zakim> +dbaron; got it
17:02:51 <sylvaing> Msger, I believe you. I'm only reporting on how the WG does it
17:03:15 <Zakim> +kojiishi; got it
17:03:26 <sylvaing> or are you shocked WG implementations differ from the w3c spec? :)
17:03:32 <Ms2ger> Hah
17:04:08 <TabAtkins> ScribeNick: TabAtkins 
17:04:57 <TabAtkins> Topic: Feb f2f
17:05:05 <plinss> http://wiki.csswg.org/planning/paris-2012
17:05:10 <TabAtkins> plinss: our agenda page is still kinda light, so please enter things as soon as you can
17:05:29 <TabAtkins> glazou: I need a firm list of people attending the meeting next week because I need it for security reasons - there will be badges every day.
17:05:32 <Zakim> +Bert
17:05:41 <TabAtkins> glazou: Even if you don't have your flight details, please add yourself asap.
17:05:42 <sylvaing> the list of msft attendees is complete. well, we even have to Alex Mogilevskys
17:05:48 <TabAtkins> plinss: Also there are no hotels listed on that page yet?
17:06:00 <TabAtkins> glazou: I sent an email a while back with a short list of hotels.  I'll add that to the wiki page.
17:06:30 <TabAtkins> glazou: One thing I'm missing is meal prefs - any food restrictions for the group meal?
17:06:41 <TabAtkins> glazou: Also there is no food inside the building.  So I can't get catering inside.
17:07:02 <TabAtkins> glazou: They'll tolerate breakfast, so I"ll bring croissants and such, but we'll have to get lunch outside.
17:07:07 <TabAtkins> glazou: Drinks are allowed.
17:07:24 <TabAtkins> glazou: There's a shopping mall on the other side of the street, chinese district is walking distance, and plenty of other restaurants.
17:07:59 <TabAtkins> Topic: Status of CSSOM and CSSOM View.
17:08:08 <Zakim> + +1.425.246.aabb
17:08:17 <TabAtkins> glenn: The work is in progress.  I've been updating and will soon bring a draft forward to the group for review.
17:08:23 <tpod> tpod has joined #css
17:08:44 <TabAtkins> sylvaing: Can you characterize the changes?
17:09:22 <alexmog> alexmog has joined #css
17:09:37 <TabAtkins> glenn: The main changes have been filling out text that was basically blank in the spec, and I'm planning to bring that forward for discussion at the f2f.
17:10:02 <TabAtkins> Topic: Publishing Writing Modes
17:10:18 <TabAtkins> plinss: We deferred this from last week, and jdaggett has sent in a bunch of comments.
17:11:00 <TabAtkins> jdaggett: I posted some issues that I think exist with text-orientation. I think we should let some of those discussions continue.
17:11:06 <TabAtkins> jdaggett: Koji responded and I need to respond back.
17:11:29 <TabAtkins> jdaggett: I think there's some wording about text-orientation and the unicode properties, but I don't think it describes authors intent.
17:12:02 <TabAtkins> jdaggett: Once those list discussions seem to be resolved, I think I'll be okay.
17:12:10 <tantek> Zakim, mute tantek
17:12:10 <Zakim> sorry, tantek, I do not know which phone connection belongs to tantek
17:12:32 <TabAtkins> plinss: Anyone else have thoughts on that?
17:12:36 <jdaggett> there's new wording for text-orientation but I don't think it accurately describes how the editors intended this should work
17:12:51 <jdaggett> so discussion on the list should continue for a bit I think
17:13:00 <tantek> Glazou, someone selling you a .ie domain?
17:13:34 <TabAtkins> florianr: I havent' followed too closely the details of these issues, but I think that what jdaggett is trying to resolve is worth figuring out.
17:14:22 <TabAtkins> plinss: So do we think it's worth publishing a WD and then publish LC later?
17:14:35 <glazou> tantek: paypal folks after I complained their site sucks, unable to output an activity report of 15 days without failing
17:15:09 <jdaggett> i think it's impor
17:15:21 <TabAtkins> plinss: Is there a current conversation going, or does someone need to raise an issue?
17:15:22 <glazou> even on IRC jdaggett is cut :-)
17:15:22 <jdaggett> relates to http://lists.w3.org/Archives/Public/www-style/2012Jan/0655.html
17:15:32 <TabAtkins> jdaggett: There's currently a convo.  It just nees to resolve.
17:15:39 <TabAtkins> plinss: Okay, we'll let it settle and revisit later.
17:15:46 <TabAtkins> Topic: Processing Model for Transforms
17:15:46 <alexmog> zakim, aabb is me
17:15:47 <Zakim> +alexmog; got it
17:15:55 <plinss> http://lists.w3.org/Archives/Public/www-style/2011Dec/0000.html
17:17:10 <TabAtkins> dbaron: Tab responded on the list, so nothing needs to be discussed here.
17:17:45 <TabAtkins> Topic: Collapsed space break opportunities
17:17:47 <plinss> http://lists.w3.org/Archives/Public/www-style/2012Jan/0408.html
17:18:39 <TabAtkins> fantasai: We resolved for 2.1 that if you have two spaces that collapse and the first one is non-breaking (so the breakble one disappears) you're still allowed to break there.
17:18:53 <TabAtkins> fantasai: But what happens if you have a bunch of different element boundaries?  Where does this break occur?
17:19:13 <TabAtkins> fantasai: If the non-breaking was within a border but the breaking was outside, does the break happen within or without the border?
17:19:25 <TabAtkins> fantasai: I can see conceptually that any space is valid.
17:19:28 <arno> arno has joined #css
17:19:38 <TabAtkins> fantasai: Or I can see saying that the non-breaking space is now breakable, so that you must break there.
17:19:43 <TabAtkins> fantasai: These both make sense to me.
17:20:05 <TabAtkins> fantasai: FF and Opera will break right before the following text (last breaking opporutunity) even if that's not actually a valid break point.
17:20:09 <Zakim> -nimbu
17:20:16 <TabAtkins> fantasai: So I don't really know what we should do.
17:20:47 <Zakim> +nimbu
17:20:49 <TabAtkins> fantasai: I'm not sure I want to spec what FF/Opera does, because it doesn't make much sense.
17:20:57 <TabAtkins> TabAtkins: What does Webkit do?
17:21:11 <TabAtkins> fantasai: Webkit refuses to render empty inlines, so it's not detectable what their behavior is.
17:21:19 <TabAtkins> dbaron: Why do we collapse across visible borders?
17:21:25 <TabAtkins> fantasai: I dunno.
17:21:30 <TabAtkins> dbaron: It would seem less crazy if we didn't do that.
17:21:43 <TabAtkins> plinss: But do you really want the presence of borders to change your whitespace-collapsing behavior?
17:21:52 <TabAtkins> dbaron: Doesn't seem that different from the presence of an image.
17:22:21 <TabAtkins> TabAtkins: collapsing already depends on other properties.
17:22:24 <TabAtkins> fantasai: I see four options.
17:22:38 <TabAtkins> fantasai: (1) don't collapse spaces across non-zero borders, non-zero padding, or non-zero margins.
17:22:50 <TabAtkins> fantasai: (2) anywhere a space used to be is a break point
17:23:05 <TabAtkins> fantasai: (3) when a non-breaking space collapses with a breakable, the resulting space is breakable
17:23:35 <TabAtkins> fantasai: (4) break right before the next thing after the collapsed stuff (even if it's not actually a valid breakpoint) (FF/Opera behavior)
17:23:51 <TabAtkins> dbaron: You've got borders with width in them in this example, so you can tell whether there's one breakpoint or multiple.
17:25:05 <TabAtkins> mollydotcom: If there's a non-breaking and a breakable space, they all collapse, and that point is the break point.  That's #2, right?
17:25:06 <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jan/0408.html
17:25:24 <TabAtkins> fantasai: Not quite.  When you collapse spaces, the first space nominally stays put, and the rest get dropped.
17:25:35 <TabAtkins> fantasai: So I've got a space inside the no-wrap, and two empty inlines, then a B.
17:26:08 <TabAtkins> mollydotcom: The integrity of the borders shouldn't be broken, right?  Doesn't that make sense?
17:26:21 <TabAtkins> mollydotcom: If something breaks in a border, a designer will be confused by that.
17:26:41 <TabAtkins> dbaron: If you have a multi-word thing wtih a border around it, breaking inside there is normal.
17:26:52 <TabAtkins> fantasai: But you wouldn't break *just* within the border on either end.
17:27:10 <TabAtkins> fantasai: And we can expand that to say you don't break inside an empty inline, because that's a degenerate case.
17:27:16 <TabAtkins> fantasai: But we can break *between* the inlines.
17:27:33 <TabAtkins> mollydotcom: It seems the most natural point to make the break is the first point where all the space has collapsed and there is no border.
17:28:19 <TabAtkins> TabAtkins: So this sounds like break opportunities at the beginning or end of an element with visible borders or whatever migrate outside of the element.
17:28:25 <TabAtkins> fantasai: Yes, there's spec text for that.
17:28:57 <TabAtkins> fantasai: I think what Molly's saying is that you collapse everything, then the break point must go at that last point, but if it's at the end of an element witha  border or whatever, move it outside the element.
17:29:21 <TabAtkins> bradk: Not just borders, box-shadow too right?
17:29:39 <TabAtkins> fantasai: It's all boxes, not just those with visible decorations.
17:30:06 <TabAtkins> fantasai: If you thinka bout it, if you put a word in a box and put it against the edge of a line, the breakpoint is just inside the box, technically, but we instead move it outside the box.
17:30:26 <TabAtkins> fantasai: So what about if the breakpoint determined by this rule is within the non-breaking area?
17:30:37 <fantasai> <p><nowrap>A <em> </em></nowrap> <em> </em> B
17:30:42 <dbaron> (Did that discussion just conclude something weird about what happens when the only space is just inside the edge of the border?)
17:32:26 <TabAtkins> Rossen: In IE we would preserve a break oppurtunity after the </nowrap> for the case int he email.
17:32:31 <TabAtkins> fantasai: And waht about the case in IRC?
17:33:04 <TabAtkins> fantasai: I think the logical place would be to break after the </nowrap>, but that's between the two empty <em>s.
17:33:45 <dbaron> dbaron: might have more than one breakpoint
17:33:49 <TabAtkins> Rossen: We still preserve the space inside the nowrap, and break outside the nowrap.
17:34:32 <TabAtkins> fantasai: If you look at teh last example, Moz breaks right before the B.
17:34:58 <TabAtkins> antonp: The last example is the key one - you can't honor both nowraps unless you break in the middle.
17:36:16 <TabAtkins> TabAtkins: I think we want to specify that break opportunities collapse separately from the spaces that generate them, and won't enter no-break areas.
17:36:24 <fantasai> fantasai^: Ok, I propose we spec what IE does, because that makes sense.
17:36:34 <tantek> tantek has joined #css
17:36:57 <TabAtkins> antonp: Does that mean in the second example in elika's email, the space after the A is preserved, but the whitespace collapsing between them is independent?
17:37:11 <TabAtkins> fantasai: There's two phases to whitespace - the first collapses, the second trims from teh begin/end of the line.
17:37:47 <TabAtkins> TabAtkins: dbaron had an issue about borders.
17:38:02 <TabAtkins> fantasai: They'll make the breaks that would visible coincide be visibly separate.
17:38:18 <TabAtkins> fantasai: Once you put borders, they'll take up space, so you can see where teh break opportunity happens.
17:38:44 <TabAtkins> mollydotcom: If you ahve content, and it's right up to the border, it would be devasating to have a break right at the end.
17:40:09 <TabAtkins> fantasai: The migration rule applies to all elements, regardless of decoration.  So that addresses david's issue.
17:40:48 <TabAtkins> bradk: What if you have a zero-width box with a box-shadow at the end of a line (and a space inside of it)?
17:41:06 <TabAtkins> TabAtkins: I think it would migrate the break opportunity both before and after the box, so the break would happen before it.
17:41:15 <TabAtkins> fantasai: box-shadow doesn't take up sapce, so it's not detectable.
17:41:26 <fantasai> s/not detectable/doesn't affect layout/
17:41:32 <TabAtkins> TabAtkins: But the box-shadow lets you tell whether the box is at the end of one line or the beginning of the next.
17:41:57 <TabAtkins> antonp: There was a convo about a year ago with Boris about this issue - whether zero-width boxes stay at the end of a line or wrap around.
17:42:06 <TabAtkins> antonp: So it may be wroth digging that up.
17:42:46 <TabAtkins> dbaron: Another warning - a fun thing to introduce in text cases is negative margins.
17:43:00 <TabAtkins> dbaron: They can give you cases where adding more stuff to the line gives you an earlier breakpoint.
17:43:07 <TabAtkins> mollydotcom: I was jsut imagining that.
17:43:46 <TabAtkins> dbaron: I don't know if we properly define, given a set of breakpoints, how you choose the one that is actually used.
17:44:09 <antonp> neg margin was, I think, the main subject of the convo I was referring to IIRC
17:44:11 <TabAtkins> dbaron: Because there may be a set of breakpoints that are not monotonically non-precessing in the line direction, due to negative margins.
17:44:39 <TabAtkins> mollydotcom: [explains an issue]
17:44:43 <dbaron> s/set/sequence/
17:44:54 <TabAtkins> plinss: I think it just changes where the breakpoint would be between two elements.
17:45:02 <dbaron> s/non-precessing/non-decreasing/
17:45:16 <TabAtkins> mollydotcom: It seems that even getting down to that level - why would we want it? I would avoid those.
17:45:18 <Bert> (A line might be overfull already, but after adding the next elt with negative margins, it is suddenly no longer full...)
17:46:53 <TabAtkins> fantasai: We don't define which breakpoint gets chosen, only where the possible breaks are.
17:47:08 <TabAtkins> fantasai: This is intentional, so you can frex do paragraph-level breaking/balancing instead of line-level.
17:47:15 <sylvaing> i can't object to that
17:47:18 <TabAtkins> fantasai: So I think we're done with this issue if everyone's happy with IE's behavior.
17:48:11 <TabAtkins> glenn: We're defining sematnics for what is breakpoint or not. Is this meant to be normative to all scenarios, or just in the absence of a higher-level protocol.
17:49:29 <TabAtkins> florianr: The intent is that any breaking algorithm can pick between the breaking points we define.  It can choose any of them, but it shouldnt' break at anywhere that doesnt' produce a breaking point.
17:50:47 <TabAtkins> TabAtkins: For example, a more advanced mechanism that does hyphenation by finding more breakpoints inside of words.
17:51:03 <TabAtkins> glenn: I ask because languages like Thai uses a dictionary to determine breakpoints.
17:51:13 <TabAtkins> fantasai: I suggest you read the section on line-breaking, because it covers all this.
17:51:46 <Bert> (Even with 'overflow-wrap: break-word', there won't be a break between the last letter and the border, I assume?)
17:52:04 <TabAtkins> RESOLUTION: Breaks are allowed wherever there was a breakpoint, even if it was collapsed away.
17:52:46 <TabAtkins> Topic: currentColor and inheritance in text-decorations
17:52:55 <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2012Jan/0521.html
17:53:16 <TabAtkins> fantasai: The problem is that currentColor *computes* to the color value, then inherits as that color.
17:53:34 <TabAtkins> fantasai: We need one that turns into the color at used value time.
17:53:50 <TabAtkins> fantasai: text-emphasis-color takes a color.  By default, they should take the color of the text.
17:54:19 <TabAtkins> fantasai: Right now, you computed color on the root element of the document, then use that throughout the document.
17:54:35 <TabAtkins> dbaron: So it sounds like we want a new value.
17:54:46 <TabAtkins> fantasai: Yes, but there are other places where we may want this behavior - text-shadow is one such case.
17:55:59 <TabAtkins> TabAtkins: Small issue - because computed value is used for multiple things, if it stays as the keyword in computed value, it won't transition.
17:56:17 <TabAtkins> dbaron: I'd have to look into it, but I think this would be quite a bit more work to implement for text-shadow than for text-emphasis-color.
17:56:54 <TabAtkins> fantasai: You already implement it for text-shadow.
17:57:08 <TabAtkins> dbaron: We implement currentColor, but not the thing that has to inherit not as a color.
17:57:21 <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20{%20text-shadow%3A%200%200%204px%3B%20}%0A%3C%2Fstyle%3E%0A%0ASOME%20TEXT%20%3Cem%20style%3D%22color%3A%20red%22%3EMore%20text%3C%2Fem%3E%0A
17:57:22 <TabAtkins> fantasai: That's not true - you do implement it.  Testcase coming.
17:57:59 <TabAtkins> dbaron: It's the "no-color" case.  It's not defined, but everyone uses this behavior.
17:58:07 <TabAtkins> plinss: So we just need a keyword for this behavior.
17:58:13 <tantek> stayCurrentColor
17:58:16 <tantek> ;)
17:58:19 <nimbu> :)))
17:58:33 <TabAtkins> Bert: Too late to change currentColor?
17:58:35 <tantek> elementColor
17:58:46 <glenn> CSS3 §4 answers my question "CSS does not fully define where line breaking opportunities occur"
17:58:58 <glenn> s/CSS3/CSS3 Text/
17:59:16 <TabAtkins> TabAtkins: Given the small usage of currentColor, we probably could.
17:59:23 <TabAtkins> fantasai: And basically no one inherits, say, a border-color.
17:59:33 <tantek> remember, we got the term 'currentColor' from SVG
17:59:49 <tantek> so if they're dependent on a specific interpretation...
17:59:51 <dbaron> I think Gecko's implementation of the default border-color and outline-color actually works this way rather than the way currentColor works
17:59:57 <TabAtkins> dbaron: In FF, we actually implement border-color and outline-color in this way, because it's cheaper than the actual implementation for currentColor.
18:00:00 <tantek> otherwise we would have called it 'current-color'
18:00:01 <TabAtkins> fantasai: We should check with SVG on this.
18:00:18 <TabAtkins> plinss: Is there any use-case for the current currentColor behavior?  Would we lose anything from it?
18:00:32 <TabAtkins> TabAtkins: I can take this to SVG and see what they say.
18:00:32 <fantasai> fantasai^: If we want to redefine currentColor
18:00:44 <Zakim> -jdaggett
18:00:47 <Zakim> -TabAtkins
18:00:48 <tantek> thanks Tab
18:00:48 <Zakim> -dbaron
18:00:53 <Zakim> -nimbu
18:00:55 <Zakim> -stearns
18:01:14 <Zakim> -smfr
18:01:25 <Zakim> -glazou
18:01:29 <Zakim> -??P34
18:01:34 <Zakim> -kojiishi
18:01:41 <Zakim> -bradk
18:01:44 <Zakim> -florianr
18:01:51 <Zakim> -Bert
18:01:53 <Zakim> -Molly_Holzschlag
18:01:54 <Zakim> -antonp
18:01:56 <Zakim> -[Apple]
18:01:59 <Zakim> -plinss
18:02:05 <Zakim> -alexmog
18:02:11 <Zakim> -Rossen
18:02:15 <Zakim> -fantasai
18:02:17 <Zakim> -GlennAdams
18:02:26 <arron> arron has left #css
18:03:22 <glenn> glenn has left #css
18:05:31 <Bert> Fantasai, should we plan something for after the ftf in Paris? I'll come by train and my ticket can be modified, so I'm flexible.
18:06:10 <fantasai> Bert: Sure
18:07:17 <Zakim> disconnecting the lone participant, sylvaing, in Style_CSS FP()12:00PM
18:07:19 <Zakim> Style_CSS FP()12:00PM has ended
18:07:23 <Zakim> Attendees were bradk, plinss, Molly_Holzschlag, glazou, jdaggett, antonp, GlennAdams, hober, fantasai, smfr, nimbu, Rossen, stearns, sylvaing, TabAtkins, +1.415.766.aaaa, florianr,
18:07:26 <Zakim> ... dbaron, kojiishi, Bert, +1.425.246.aabb, alexmog
18:07:34 <Bert> Haven't thought about location yet, but let's start with the dates.
18:07:56 <Bert> I may have to do some visits of a few hours as well.
18:08:21 <fantasai> Bert: Okay. Let's work on stuff Thurs/Fri -- I'm flexible, aside from possibly dialing into the UTC meeting
18:09:06 <fantasai> Bert: And if we need more time, I can also take the train down to Sophia
18:09:09 <fantasai> the week after
18:09:45 <fantasai> Bert: I'm guessing we will need more time, if we're to tackle *all* of CSS3 layout ;)
18:10:03 <Bert> I have time that week, so no problem.
18:10:09 <fantasai> great
18:19:32 <oyvind> oyvind has left #css
18:25:07 <mollydotcom> mollydotcom has left #CSS
18:27:16 <tantek_> tantek_ has joined #css
18:46:49 <dbaron> dbaron has joined #css
19:27:32 <Zakim> Zakim has left #css
19:35:38 <arno> arno has joined #css
20:16:08 <arno> arno has joined #css
20:17:28 <arno> arno has joined #css
21:07:39 <shepazu> shepazu has joined #css
22:49:09 <tantek> tantek has joined #css
22:50:29 <tantek> tantek has joined #css
23:09:19 <fantasai> Bert: Are we publishing CSS3 Text tomorrow then?
23:09:30 <fantasai> Bert: Or did you miss my email?
23:13:56 <fantasai> Bert: Thanks!
23:18:31 <TabAtkins> fantasai: Can you help me find the relevant spec text that applies to this webkit bug? https://bugs.webkit.org/show_bug.cgi?id=76465#c3
23:18:52 <TabAtkins> I think it's a valid bug, as we shouldn't generate a linebox there, but I can't find the text in 2.1 about throwing away empty lineboxes.
23:20:48 <TabAtkins> I don't know inline layout well enough. ;_;
23:22:00 <fantasai> TabAtkins: 9.4.2
23:22:10 <fantasai> "Line boxes that contain no text ..."
23:22:52 <TabAtkins> Thank you! That's exactly the line I was looking for.
23:43:04 <nimbu> nimbu has joined #css