#css
on 14th January 2009 (Real Data)Sunday 18th January 2009, 11:37pm CET.
Session Start: Wed Jan 14 00:00:00 2009
Session Ident: #css
00:28 Disconnected
00:28 Attempting to rejoin channel #css
00:28 Rejoined
02:28 plinss_ quits (peter.lins@15.243.169.72) (plinss_)
05:43 : fantasai: are you able to access cvs without any problems?
05:43 : i'm able to pull from WWW/Style/Group
but not WWW/Style
05:43 : i get a permissions error with WWW/Style
05:54 dbaron quits (dbaron@63.245.220.241) (8403864 bytes have been tenured, next gc will be global.)
06:12 : jdaggett: yeah, you don't have higher-level access
06:12 : hmm
06:12 : jdaggett: you shouldn't need higher-level access, though
06:12 : i did before…
06:12 : hm
06:12 : not to WWW/Style…
?
06:12 : that's the weird part
06:12 : well, I'm pretty sure you don't have write access there
06:12 : dunno about read access
06:13 : hmm, maybe the read/write permissions were swizzled
06:13 : i'll test
06:14 : k, but you don't need to access that part of the repo for your Tokyo page
06:14 : well, i need the stylesheets in WWW/Style
!!!
06:15 : what for?
06:15 : er, to see the page properly rendered…
06:15 : call me crazy…
06:15 : hehe
06:15 : stick a <base href="http://www.w3.org/Style/Group/2008/">
in your html
06:16 : IIRC the style sheet links are root-relative anyway, so they wouldn't show up properly unless you tweaked the links
06:17 : nope, they're all ../../xxx.css
06:32 shepazu quits (schepers@128.30.52.30) (Ping timeout)
06:50 fantasai quits (fantasai@75.20.202.215) (Connection reset by peer)
06:51 fantasai joins (fantasai@75.20.202.227)
07:02 shepazu joins (schepers@128.30.52.30)
08:49 fantasai quits (fantasai@75.20.202.227) (bedtime)
10:40 Lachy quits (Lachlan@85.196.122.246) (This computer has gone to sleep)
11:00 Lachy joins (Lachlan@213.236.208.247)
11:03 Lachy quits (Lachlan@213.236.208.247) (Ping timeout)
11:03 Lachy joins (Lachlan@213.236.208.22)
11:10 Lachy quits (Lachlan@213.236.208.22) (Leaving)
11:10 Lachy joins (Lachlan@213.236.208.22)
15:09 myakura joins (myakura@122.16.160.96)
16:06 emilyw joins (chatzilla@74.43.146.33)
16:11 emilyw quits (chatzilla@74.43.146.33) (Ping timeout)
16:37 fantasai joins (fantasai@75.20.202.227)
16:43 waves to Bert
16:45 : Hi fantasai. Slept well?
16:49 : yep
16:49 : ready to go?
16:49 Bert reading CVS log…
16:50 : :)
16:50 anne parts (annevk@77.163.243.203)
16:51 anne joins (annevk@77.163.243.203)
16:51 : I'm ready to go. Any particular place to start?
16:51 : mm, maybe we scan the document first for issues
16:51 : then look at tracker
16:51 : 1st one is background-repeat
16:51 : "Should background positioning area be background painting area here or vice versa?"
16:52 : I think the main concern is what do we want to happen for the :root
16:52 : the bgpos area for :root
is the :root
's box
16:52 : the bgpaint area for :root
is the canvas
16:55 : Bert?
16:56 : I think yu'll never want the paint area to be clip any of the tiles, so I prefer not to separate paint and pas areas.
16:56 : But the canvas is indeed special.
16:56 : It is infinite, you cannot base tile size on it….
16:56 : s/to be clip/to clip/
16:57 : (All this in the case of 'space
' and 'round
', it doesn't matter for the other kinds of tiling.)
16:57 : right
16:58 : you could say that the size of the canvas for the purpose of 'space
' and 'round
' size/pos calculations is the initial containing block
17:00 pokes Bert
17:00 : We've in the past referred to the canvas as "stealing" the bg from the root. I like that metaphor. It suggests that the root is in fact a normal element, but then the canvas steals (repeats) the bg of the root for its own purposes.
17:01 : but that's not exactly true
17:01 Bert excuses himself for being slow. Can;'t think and type…
17:01 : because the bgpos area of the canvas is the :root
box
17:01 : if the canvas stole the background, then it wouldn't have anything to do with the size of the :root
box
17:02 : Not sure I udnerstannd that last sentence.
17:02 : What is "it"?
17:02 : the canvas's background
17:03 Lachy quits (Lachlan@213.236.208.22) (This computer has gone to sleep)
17:04 : The canvas bg doesn't have much to do with the root size, does it? It simply takes any repeating bg from the root and repeats it ad infinitum.
17:05 : the canvas's bg tiles are positioned as if they belonged to the root only
17:05 : the only thing that isn't as if it belonged to the root only
17:05 : is that it tiles outside the root's border box
17:06 : i.e. it's not clipped
17:07 : but it's sized and positioned as for the root box only
17:08 : Not sure this helps us solve the issue…
17:08 : Canvas/root is special no matter what we do.
17:09 : the other thing is that the background painting area is not necessarily a rectangle
17:09 : whereas the bgpos area necessarily is
17:10 : I think the determining question is what we want for bgs drawn behind borders in case the bg is spaced/rounded:
17:10 : do you ever want a bg that is spaced to the padding box, but still tiles under the border?
17:11 : no
17:11 : but I never want a bg that is positioned wrt the padding box
17:11 : but tiles under the border
17:11 : it looks ugly
17:13 : If so, it seems it is simpler to say that the positioning area (along with the bg pos) simply has no influence on space/round.
17:14 : Although you're correct that we have non-rect areas to consider…
17:14 : if we're going to be consistent with the way normal tiling backgrounds behave
17:15 : which is they position in the top left padding corner and then tile through the border box
17:15 : then round, which is almost the same use cases except more polished
17:15 : should position in the top left and top right padding corners
17:15 : and the tile through the border box
17:15 : it is much simpler that way imo
17:16 : hm, although then we have to say what happens to a background that is zero height
17:16 : if the box is zero height and the tile continues out
17:16 : into the border area
17:16 : what does that mean
17:16 : Good question :-)
17:17 : We should address that in bg-size
17:17 : since you can get that effect with bg-size
17:18 : Isn't that already defined?
17:18 : and I think we should say that the effect is the same as if the image had zero height, i.e. it's treated as bg-image: none
17:18 : ah, yes
17:18 : sect 3.9: "A size of zero is allowed, but causes the image not to be displayed. (The effect is the same as if it had been a transparent image.)"
17:18 : well in that case it's defined :)
17:19 : but we need to shift it out, so that it applies to e.g. 100% resolving to 0
17:20 will do that
17:20 : Yes, and maybe not yet clear that it applies to round (assuming indeed we round to bg pos area).
17:22 : done
17:22 : reload
17:23 Bert doesn't see a change…
17:23 Bert ah, my fault.
17:24 : Good
17:26 : so, back to the issue…
17:27 : We round/space to the bg pos area? (It is at least as powerful as the alternative and avoids having to deal with background-break
separately for round/space.)
17:27 : ok
17:28 will remove the issue text
17:28 : OK
17:28 Bert brb
17:31 Bert b
17:35 : What are you doing?
17:35 : ah, was reading www-style
17:36 : next issue is for background-break
17:36 : hen boxes on subsequent lines are ordered according to the {containing block's | element's} inline progression direction and aligned on the baseline.
17:37 : I'm just noticing that there's a related issue in border-break
17:37 : which is, we should pick the answer that is consistent with the way borders are rendered
17:37 : so that if you have an element broken in 2 pieces
17:37 : pasting it together makes sense
17:39 : You mean: when pasting them together, the extra borders inserted by border-break
must be removed frst?
17:39 : no
17:39 : when there's no border at the break
17:39 : but there is elsewhere
17:39 : you get
17:39 : [===
17:39 : ===]
17:39 : for ltr text
17:40 : the answer to this shoudl be the same as what happens when you have an rtl
span inside an ltr
element
17:40 : Mozilla renders the rtl span as
17:40 : ===]
17:40 : [===
17:41 checks Opera
17:41 : Not sure I understand. The [
is a left border?
17:41 : run this in your favorite browser: <p style="width: 4em"><span style="border: solid; direction: rtl;">Some text</span></p>
17:41 : [
is a left border, yes
17:41 emilyw joins (chatzilla@129.21.79.15)
17:41 : and try removing 'direction: rtl
' as well
17:41 : to see the difference
17:42 : Opera uses the containing block's direction
17:42 : so it doesn't change depending on direction
17:43 : we need to spec this…
17:44 : oh, well, Opera doesn't use the containing block's direction either
17:44 : it just treats everything the same
17:45 : Bert, you getting anything on Safari?
17:45 : Not yet tried Safari.
17:46 : Not nice:
17:46 emilyw quits (chatzilla@129.21.79.15) (Ping timeout)
17:46 : [===]
17:46 : [===
17:46 : o_O
17:47 : I guess we need to check IE
17:47 : But I don't get what you got from Firefox.
17:47 : what do you get?
17:48 : [===
17:48 : ===]
17:48 : what build?
17:48 : 2.0.0.18
17:48 : I'm using 3
17:49 : 3.0.1
17:49 : So I guess someone intentionally fixed it
17:49 : makes sense
17:50 : otherwise you'd have something that looks like
17:50 : Yes, just tried: 3 does it like you said.
17:50 : =F=E=D=][=C=B=A=
17:50 : instead of [=F=E=D=C=B=A]
17:50 : if you tried to put it together
17:51 : Should I spec FF's behavior?
17:52 : Seems reasonable
17:53 : ok
17:53 : RESOLVED
17:53 : :)
17:53 glazou joins (glazou@82.247.96.19)
17:53 : hi
17:54 Zakim joins (rrs-bridgg@128.30.52.30)
17:54 RRSAgent joins (rrs-loggee@128.30.52.30)
17:54 : logging to http://www.w3.org/2009/01/14-css-irc
17:54 : Zakim, this will be Style
17:54 : ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 8 minutes
17:54 : Bert, do you think the section starting "The middle image's width is scaled"
17:54 : is clear?
17:54 : there's an issue marked there, I'm wondering if the wording needs tweaking or if I can just remove the issue
17:55 : The I automatically read "failing that" as "zero or infinity" so I don't hink a rewrite is really necessary.
17:56 : s/The//
17:56 : ok
17:56 : cool
17:56 : last issue in the text is whether the 'inset
' keyword for box-shadow
should be renamed 'inner
'
17:56 thinks 'inset
' is fine, and avoids another parser token
17:57 : Will bg style and bg shadow ever be used together in a shorthand?
17:57 : I sincerely doubt it
17:57 : bg-shadow
is complicated enough on its own
17:57 : er
17:57 : box shadow
17:57 : Yes, my mistake.
17:57 : Bert: : thanks for answer to ITU
17:58 : I think inset
is fine. But I don't know id there is already a traditional name for the effect among designers.
17:59 : ok
17:59 : I'll remove the issue for now then
17:59 emilyw joins (chatzilla@129.21.79.15)
17:59 : If there is no strong reason to change it, I prefer keeping inset
. Avoids having to remember an extra keyword.
17:59 : yeah
18:00 : Style_CSS FP()12:00PM has now started
18:00 : +plinss
18:00 : +dsinger
18:00 Bert dialing
18:00 : +Bert
18:01 melinda joins (melinda.gr@67.142.45.126)
18:01 Dsinger_ joins (mobile@67.218.105.78)
18:01 : Zakin, mute me
18:01 : +??P37
18:02 : Zakim, mute me
18:02 : sorry, Dsinger_, I do not know which phone connection belongs to you
18:02 : + +1.206.324.aaaa
18:02 : Zakim, who is here?
18:02 : On the phone I see dsinger, plinss, Bert, ??P37, +1.206.324.aaaa
18:02 : On IRC I see Dsinger_, melinda, emilyw, RRSAgent, Zakim, glazou, anne, fantasai, myakura, shepazu, krijnh, plinss, Hixie, Bert, jdaggett, trackbot, hsivonen
18:02 : +glazou
18:03 : Zakim, mute dsinger
18:03 : dsinger should now be muted
18:04 Dsinger_ is now Dsinger
18:04 : +Melinda_Grant
18:04 sylvaing joins (sylvaing@98.247.143.102)
18:04 ChrisL joins (ChrisL@128.30.52.30)
18:04 Dsinger is now dsinger
18:06 : Zakim, +1.206 is sylvaing
18:06 : +sylvaing; got it
18:06 : +ChrisL
18:06 : Zakim, +P37 is fantasai
18:06 : sorry, fantasai, I do not recognize a party named '+P37'
18:06 : Zakim, +??P37 is fantasai
18:07 : dsinger: do you have friends working on I18N at apple ?
18:07 : Zakim, ??P37 is fantasai
18:07 : sorry, fantasai, I do not recognize a party named '+??P37'
18:07 : +fantasai; got it
18:07 : zakim, mute me
18:07 : fantasai should now be muted
18:07 : No idea !
18:07 glazou found a very disturbing i18N bug in the ftp server
18:08 : zakim, unmute me
18:08 : fantasai should no longer be muted
18:08 ChrisL guesses that but was "ascii only"?
18:08 : s/but/bug/
18:09 : ChrisL: http://tinyurl.com/8tp7u5
18:10 : +SteveZ
18:10 ChrisL so its using composing characters? are they in utf-8 or in macRoman or something?
18:11 : utf-8
18:11 : apparenty, it's the ftp server turning é into e+'
18:11 szilles joins (chatzilla@24.6.113.228)
18:11 : -dsinger
18:11 dsinger quits (mobile@67.218.105.78) (Rooms • iPhone IRC Client • http://rooms.derflash.de)
18:12 dbaron joins (dbaron@63.245.220.241)
18:12 ChrisL zakim, who is here?
18:12 Zakim sees on the phone: plinss, Bert, fantasai, sylvaing, glazou, Melinda_Grant, ChrisL, SteveZ
18:12 Zakim sees on irc: dbaron, szilles, ChrisL, sylvaing, melinda, emilyw, RRSAgent, Zakim, glazou, anne, fantasai, myakura, shepazu, krijnh, plinss, Hixie, Bert, jdaggett, trackbot,
18:12 Zakim … hsivonen
18:12 : +dsinger
18:12 : ScribeNick: fantasai
18:12 Dsinger_ joins (mobile@67.218.105.78)
18:12 : http://wiki.csswg.org/spec/css2.1#issue-92
18:12 : Topic: Widows and Orphans
18:13 : +[Mozilla]
18:13 : Zakim, mute me
18:13 : sorry, Dsinger_, I do not know which phone connection belongs to you
18:13 : +dbaron; got it
18:13 : +??P18
18:13 Dsinger_ is now dsinger
18:13 : dsinger should now be muted
18:13 : zakim, ??P18 is me
18:13 : +emilyw; got it
18:13 : Zakim, mute me
18:13 : dsinger was already muted, dsinger
18:14 : zakim, mute me
18:14 : emilyw should now be muted
18:14 : hi emilyw
18:14 dbaron RRSAgent, pointer?
18:14 RRSAgent See http://www.w3.org/2009/01/14-css-irc#T17-12-27
18:14 : hi glazou
18:14 dbaron RRSAgent, make logs public
18:14 : I have made the request, dbaron
18:15 : Melinda: I would limit the proposal to the first line there
18:15 : http://lists.w3.org/Archives/Public/www-style/2008Dec/0008.html
18:16 : I suggest changing "minimum number of lines of a paragraph" to "minimum number of line boxes in a block element"
18:16 : This is a change we made to css3
18:16 : s/This/Melinda: This/
18:16 : s/I suggest/Melinda: I suggest/
18:17 : Melinda: I'm withdrawing the second half of the proposal (wrt table rows)
18:17 : Peter: Any objections?
18:18 : Bert: I think that's what we always meant it to be, just sloppy prose
18:18 ChrisL has no opinion
18:18 : SteveZ: I agree with Melinda's change
18:18 : RESOLVED: Accept proposal
18:18 : http://lists.w3.org/Archives/Public/www-style/2009Jan/0087.html
18:18 : Topic: Margins at page and column breaks
18:19 : Melinda: I wanted to talk about top margins with respect to page breaks
18:19 : Melinda: I don't have anything wrt columns that I want to put forward
18:19 : Melinda: Shall we plunge into that?
18:19 : +??P21
18:19 : zakim, who is talking?
18:19 : dbaron, listening for 10 seconds I heard sound from the following: ??P21 (75%), fantasai (20%), glazou (4%), Melinda_Grant (46%)
18:19 dsinger parts (mobile@67.218.105.78)
18:19 : +howcome; got it
18:20 : ChrisL, listening for 11 seconds I heard sound from the following: ??P21 (51%), fantasai (27%), glazou (23%), Melinda_Grant (61%)
18:20 : Melinda: Discussion on www-style started by Murakami-san about margins at page breaks.
18:20 : Melinda: Michael Day has a proposal, that I think is a very good one.
18:20 : Melinda: But a piece of it would require change to 2.1
18:20 : Melinda: Right now that we say that when a page break occurs between blocks, the margins get zeroed
18:20 : Melinda: Michael's proposal is that they only get zeroed if the break is not forced
18:21 : Melinda: If the break is forced, then the top margin is kept
18:21 : Melinda: this makes a lot of sense
18:21 : Melinda: You don't want the first page of the document, which might well be the first page of a chapter/section, to format differently from first page of a chapter or section
18:22 : Melinda: The first page is not after a page break, so the top margin there won't get zeroed
18:22 : Melinda: But when you force a page break before the first page of chapter 2, chapter 3, etc.
18:22 : Melinda: That top margin disappears
18:22 : Melinda: That means you have to do exception styling for the first page
18:22 : Melinda: Also it's very confusing for authors for the margin to disappear
18:22 : Melinda: So the proposal is to open up 2.1 to allow Prince's behavior
18:23 : Melinda: I would like to /allow/ that behavior: allow you to retain a top margin after a forced break
18:23 : Melinda: And in CSS3 we want to move to mandating that
18:23 : howcome: I support your proposal
18:23 : howcome: I think it's a logical behavior
18:23 glazou thinks howcome finds good excuses to remain mute
18:24 : howcome: I agree with allowing it in 2.1 and requiring it in 2.1
18:24 : s/2.1/3
18:24 :
18:24 Bert wonders: if we do a strawpoll, will the echo count as an extra vote?
18:24 : SteveZ: I'm not sure if on the 4th page you want to retain the margin
18:24 : SteveZ: XSL has a property to control this
18:24 : Melinda: XSL-FO does have a property to control whether margins are present or not
18:25 : Melinda: And I think we do want to have controls in the future
18:25 : -dsinger
18:25 : Melinda: But I think we want to get the best default behavior now
18:25 sylvaing is in danger of paneling with howcome at sxsw
18:25 dsinger joins (dsinger@17.202.35.52)
18:25 : Melinda: There were some interesting proposals for margin collapsing controls in that thread
18:25 : +[Apple]
18:25 : zakim, [Apple] has dsinger
18:25 : +dsinger; got it
18:26 : Melinda: The proposal for controls on margin collapsing on the margin properties is a good idea and somewhere we should go in the future
18:27 : I agree with fantasai, this does not block future extensibility
18:27 : SteveZ: I'm concerned about this proposal to preserve margins after forced page breaks
18:27 : SteveZ: what if you don't want the margin preserved?
18:28 : SteveZ: Wouldn't this block extensibility?
18:28 glazou brbs
18:28 : fantasai: No, this would just be the 'auto
' behavior.
18:28 : Zakim, mute me
18:28 : glazou should now be muted
18:28 : fantasai: you could then have other values that say always do this, or always do that.
18:29 : it sounds like what we are really defining here is the smart default/auto behavior.
18:29 glazou is back
18:29 : howcome: We don't want to add a new property for every issue
18:29 : (If table#t1
needs a page-break-before
, then you can give it margin:0
in the same rule)
18:30 : SteveZ: what if I have a table and I want to force a break to put it at the top of the page?
18:30 : fantasai: set margin-top: 0;
along with page-break-before: always;
18:31 : fantasai: If we preserve the margins by default, you always have the option of zeroing it out
18:31 : (We also can set the first top margin by using a named page with that top margin…)
18:31 : Yes, its a more sensible default. As fantasai says, if you are forcing a page break, you now have the option of retaining or removing the top margin
18:31 : fantasai: but you can't put it in if the algorithm requires deleting it
18:31 : q+ to suggest a "should"
18:31 Zakim sees ChrisL on the speaker queue
18:33 : Chris: Can we make it a should in 2.1?
18:33 myakura quits (myakura@122.16.160.96) (Leaving…)
18:33 : Melinda: I think that would be difficult, because we have several implementations that don't align on this
18:34 : Chris: but we should give some guidance to implementors
18:34 : Melinda: I'm thinking putting it in CSS3 Paged Media will give that guidance
18:34 : howcome: behavior on columns should be consistent with that for page breaks
18:35 : SteveZ: I certainly understand the argument, I'm just concerned that it's going to …
18:35 : Melinda: I've been trying to think of counter-examples for a long time
18:35 : Melinda: I'm happy with this solution
18:35 : SteveZ: I know that what I've done for prints, I've put in page breaks for many other reasons than starting a new chapter.
18:36 : SteveZ: i understand fantasai's point about being able to turn it off in that context
18:36 : SteveZ: I'm concerned that this kind of design is usually bad
18:36 : SteveZ: It makes an assumption that one case is more important than the others
18:36 : Howcome: I've been pushing for Prince to follow the specifications, and I've pushed Michael on this specific issue
18:36 : Howcome: But he won't change it, and he points to user feedback.
18:37 : does it make one case more important than the others, or does it pick what the default behavior should be ?
18:37 : SteveZ worries about this auto behavior closing off the possibility of controls in the future.
18:38 : Melinda: We don't want to close off the possibility of controls in the future. How about you think about that for the next week and report back if you find any issues
18:38 : …
18:39 : SteveZ: My concern is that the decision for whether you want to collapse or not doesn't depend on the element but on the container
18:39 : SteveZ: We're talking about a different behavior when you're positioned somewhere particular in a container
18:40 : Melinda: I don't understand. could you draw some use cases
18:40 : SteveZ: So your use case is the margin at the beginning of a chapter
18:40 div class="chapter"
18:41 : more discussion between Melinda and SteveZ, not much very clear
18:41 .chapter ::first-child {page-break-before: always; margin-top:0 }
18:41 : Howcome: THe one use case you've mentioned so far is you have a table, and you want it to start on a new page, and you want to collapse the margin.
18:41 : Howcome: When you set the break, you can remove the margin
18:42 : Melinda: The current behavior is not that the margin collapses, but that it is removed
18:42 : SteveZ: You want to remove all the margins at that point, however deep they are
18:42 : fantasai: So you want something like margin-top: hidden;
18:43 : SteveZ: You can't zero the margin if you don't know whether you're at the top of the page
18:44 : Melinda: You're always at the top of the page after a forced break
18:44 : SteveZ: what about keep-together?
18:44 : Melinda: That's not a forced break. The margins get zeroed as currently defined
18:44 : …
18:44 : SteveZ: Ok, I'm understanding the logic.
18:44 : SteveZ: I'm concerned about future compat.
18:45 : ACTION SteveZ: Think about this
18:45 trackbot noticed an ACTION. Trying to create it.
18:45 RRSAgent records action 1
18:45 : Created ACTION-121 - Think about this [on Steve Zilles - due 2009-01-21].
18:45 Bert thinks "this" is a bit ambiguous…
18:45 : Zakim, unmute me
18:45 : glazou should no longer be muted
18:45 : +SteveZ.a
18:45 sylvaing believes 'this' to be undefined in 2.1
18:45 : -SteveZ
18:46 : TENTATIVE RESOLUTION: Accept Melinda's proposal to allow margins to be kept after a forced page break
18:46 : PENDING: SteveZ's ok
18:47 : Topic: Background Layering
18:47 emilyw quits (chatzilla@129.21.79.15) (Ping timeout)
18:47 : fantasai: I heard from Hyatt that basing layering on background-image
only was ok
18:47 : dsinger confirms
18:47 : RESOLVED: layering based on background-image
only
18:47 : Topic: June F2F
18:48 : Peter: We'd like to confirm the dates for June in Sophia-Antipolis
18:48 : Peter: Currently listed for 24-26
18:48 arronei joins (arronei@131.107.0.80)
18:48 : Bert: With me those are still fine
18:48 : Howcome: The holidays start then, and kids are out of school
18:48 : Howcome: I will not be able to attend
18:49 : dbaron: I remember signs in Antibes that had parking restrictions starting the middle of June
18:49 : overlaps a 3GPP SA4 meeting (Ystad) but that's not serious
18:49 emilyw joins (chatzilla@129.21.79.15)
18:49 : Melinda: how far back would we have to move it to enable you to join, howcome?
18:49 : I always stay in Valbonne, where one can usually park (unless there is an antiques fair)
18:50 : Howcome: beginning of the month would be better
18:50 : Howcome: I think the holidays start around the 14th
18:50 : Howcome: 12th
18:50 : Howcome: Friday the 12th
18:50 : SteveZ: Bert, you're on vacation in June?
18:50 : Bert: I'm away from 7-20
18:50 : Howcome: What about the first week of June?
18:51 : please, no earlier, the current week already starts 5 on the road for me
18:51 : SteveZ and fantasai can't do the last week of May
18:51 : Glazou: 1st of June is a holiday in France
18:51 : Chris: What about 3-5th of June
18:51 : Bert: probably ok, but I'd like a few days to check that
18:52 : not sure I would travel as it would be a standalone…bit I don't have a conflict
18:52 : Melinda: Would we lose anyone on the call if we moved it there?
18:52 Bert suggests howcome offers the kids a holiday in France :-)
18:52 ChrisL david said the current ones are better
18:52 : *dsinger said
18:52 : Bert: excellent suggestion indeed !
18:53 : don't decide on me…
18:53 glazou ROFLs
18:53 : we can hang out on howcome's yacht. avoids parking issues.
18:53 : You have no idea how expensive parlking for yachts is here :-)
18:54 ChrisL 500 euro a day for example, in Monaco
18:54 : Peter: Ok, we'll give Bert a chance to look at that
18:54 : Peter: And we'll keep both sets of dates penciled in, come back to this
18:54 : Topic: Invited Experts
18:55 : [unminuted]
18:55 glazou agrees with the proposal
18:56 sylvaing does not need convincing on this one.
18:58 : RESOLVED: proposal accepted
18:59 : Topic: Backgrounds and Borders
18:59 : fantasai: Preparing for last call
18:59 : dbaron: thinking about at-risk
19:00 : dbaron, peter: put thinks at risk if they don't have at least one implementation
19:02 : thx
19:02 : -[Mozilla]
19:02 : -SteveZ.a
19:02 : -Melinda_Grant
19:02 : -ChrisL
19:02 : -[Apple]
19:02 : -sylvaing
19:02 : -plinss
19:02 : -emilyw
19:02 : -Bert
19:02 : -fantasai
19:02 : -glazou
19:02 : -howcome
19:02 : Style_CSS FP()12:00PM has ended
19:02 : Attendees were plinss, dsinger, Bert, +1.206.324.aaaa, glazou, Melinda_Grant, sylvaing, ChrisL, fantasai, SteveZ, dbaron, emilyw, howcome
19:02 dsinger quits (dsinger@17.202.35.52) (dsinger)
19:03 emilyw quits (chatzilla@129.21.79.15) (ChatZilla 0.9.84 [Firefox 3.0.5/2008120121])
19:04 glazou quits (glazou@82.247.96.19) (glazou)
19:13 ChrisL quits (ChrisL@128.30.52.30) (Client exited)
20:07 grmbls
20:07 is glad howcome was present
20:08 was eating Japanese and forgot about post-5PM meetings
20:09 thinks she'd rather have been eating Japanese… ;-)
20:19 sylvaing quits (sylvaing@98.247.143.102) (Ping timeout)
20:24 fantasai quits (fantasai@75.20.202.227) (reboot because klauncher died :/)
20:33 dbaron quits (dbaron@63.245.220.241) (Ping timeout)
20:34 dbaron joins (dbaron@63.245.220.241)
20:35 arronei quits (arronei@131.107.0.80) (Ping timeout)
20:41 arronei joins (arronei@131.107.0.102)
20:46 melinda quits (melinda.gr@67.142.45.126) (Connection reset by peer)
20:50 fantasai joins (fantasai@75.20.202.227)
21:01 Zakim excuses himself; his presence no longer seems to be needed
21:01 Zakim parts (rrs-bridgg@128.30.52.30)
21:01 melinda joins (melinda.gr@67.142.45.126)
21:19 Lachy joins (Lachlan@85.196.122.246)
21:21 : Bert: I've added a sentence to handle fixed backgrounds in paged media,
21:21 : http://dev.w3.org/csswg/css3-background/#the-background-attachment
21:21 : Let me know if that works
21:22 : Where is the image to be anchored?
21:23 : initial containing block
21:23 : http://dev.w3.org/csswg/css3-background/#background5
21:23 needs to fix those anchors, that's ugly
21:24 : But which corner of the image is anchored to which corner of the initial containing block?
21:24 : Bert, is that your post-processor?
21:24 : melinda: determined by background-position
21:55 manually adds in some more sane ids
21:55 : Bert, don't remove the sane IDs!
22:28 Disconnected
22:29 Attempting to rejoin channel #css
22:29 Rejoined
22:32 : (But I find it's rarely needed to invent anchors. The auto link from an inline elt to a dfn is usually enough.)
22:38 Disconnected
22:38 Attempting to rejoin channel #css
22:38 Rejoined
22:46 Disconnected
22:46 Attempting to rejoin channel #css
22:46 Rejoined
22:53 Disconnected
22:54 Attempting to rejoin channel #css
22:54 Rejoined
22:58 Disconnected
22:58 Attempting to rejoin channel #css
22:58 Rejoined
23:05 Disconnected
# Session Close: Wed Jan 14 23:05:25 2009
# Session Start: Wed Jan 14 23:07:26 2009
# Session Ident: #css
23:07 Now talking in #css
23:10 Disconnected
23:11 Attempting to rejoin channel #css
23:11 Rejoined
Session Close: Thu Jan 15 00:00:00 2009
A service by Krijn Hoetmer. Questions, improvements, suggestions & ideas are welcome! View the website statistics.