IRC Logs for #css on 14th January 2009 (Real Data)

Sunday 18th January 2009, 11:37pm CET.

Midnight

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

2am

02:28 plinss_ quits (peter.lins@15.243.169.72) (plinss_)

5am

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.)

6am

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)

7am

07:02 shepazu joins (schepers@128.30.52.30)

8am

08:49 fantasai quits (fantasai@75.20.202.227) (bedtime)

10am

10:40 Lachy quits (Lachlan@85.196.122.246) (This computer has gone to sleep)

11am

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)

3pm

15:09 myakura joins (myakura@122.16.160.96)

4pm

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

5pm

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

6pm

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

Widows and Orphans

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 : Zakim, [Mozilla] has dbaron

18:13 : +dbaron; got it

18:13 : +??P18

18:13 Dsinger_ is now dsinger

18:13 : Zakim, mute 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 : I agree as well.

18:18 : http://lists.w3.org/Archives/Public/www-style/2009Jan/0087.html

Margins at page and column breaks

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 noisy?

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 : Zakim, ??P21 is howcome

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 : Changing 2.1 to allow retention of the top margin after a forced page break sounds good to me.

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 : So, for what it's worth (since it's hard to get a word in), there are some other use cases for margins that disappear.

18:34 : It's a quirks mode behavior at the edges of the body and the edges of tables cells, at least.

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

Background Layering

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

June F2F

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 : http://lists.w3.org/Archives/Public/www-style/2008Nov/0022.html was our previous discussion of meeting scheduling for this meeting

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 : I think the reason we rejected first week of June before was Bert's constraints, since he was unsure of dates.

Invited Experts

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

Backgrounds and Borders

18:59 : Topic: Backgrounds and Borders

18:59 : fantasai: Preparing for last call

18:59 : dbaron: thinking about at-risk

7pm

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)

8pm

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)

9pm

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!

10pm

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

11pm

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.