/irc-logs / w3c / #css / 2009-01-14 / end

Options:

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

The end :)