16:42:21 <RRSAgent> RRSAgent has joined #css
16:42:21 <RRSAgent> logging to http://www.w3.org/2011/02/16-css-irc
16:42:28 <glazou> Zakim, this will be Style
16:42:28 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 18 minutes
16:42:33 <glazou> RRSAgent, make logs public
16:42:38 <glazou> Zakim, code ?
16:42:39 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), glazou
16:43:52 <dbaron> dbaron has joined #css
16:57:30 <oyvind> oyvind has joined #css
16:57:38 <Zakim> Style_CSS FP()12:00PM has now started
16:57:41 <Zakim> +[Microsoft]
16:57:45 <Zakim> +??P0
16:57:55 <glazou> Zakim, ??P0 is me
16:57:55 <Zakim> +glazou; got it
16:58:09 <arronei> zakim, Microsoft is me
16:58:09 <Zakim> +arronei; got it
16:59:57 <TabAtkins_> TabAtkins_ has joined #css
17:00:01 <Zakim> + +1.858.216.aaaa
17:00:11 <plinss> zakim, aaaa is me
17:00:11 <Zakim> +plinss; got it
17:00:22 <smfr> smfr has joined #css
17:00:35 <Zakim> +smfr
17:00:38 <Zakim> +[Microsoft]
17:00:41 <alexmog> alexmog has joined #css
17:00:41 <Zakim> +TabAtkins_
17:01:07 <johnjan> johnjan has joined #css
17:01:13 <cesar> cesar has joined #css
17:01:14 <johnjan> zakim, microsoft is johnjan
17:01:14 <Zakim> +johnjan; got it
17:02:22 <sylvaing> sylvaing has joined #css
17:02:22 <Zakim> + +1.206.324.aabb
17:02:28 <Zakim> +fantasai
17:03:09 <Zakim> +Bert
17:03:36 <Zakim> + +46.0.94.0.aacc
17:03:55 <Zakim> +??P24
17:04:01 <Zakim> +??P25
17:04:11 <kojiishi> zakim, ??p24 is me
17:04:11 <Zakim> +kojiishi; got it
17:04:14 <cesar> Zakim, aacc is me.
17:04:14 <Zakim> +cesar; got it
17:04:15 <Zakim> -kojiishi
17:04:40 <TabAtkins_> ScribeNick: TabAtkins_
17:04:48 <Zakim> +??P24
17:04:51 <kojiishi> zakim, ??p24 is me
17:04:51 <Zakim> +kojiishi; got it
17:05:19 <ChrisL> ChrisL has joined #css
17:05:28 <TabAtkins_> glazou: Extra agenda item sent to the list from Koji.
17:05:43 <TabAtkins_> glazou: Asking to resurrect CSS Line Grid, with him assuming editorship.
17:06:00 <Zakim> +ChrisL
17:06:19 <TabAtkins_> glazou: Any objection to this?
17:06:45 <TabAtkins_> [no objections]
17:06:48 <TabAtkins_> glazou: Welcome, Koji.
17:06:56 <glazou> http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-css-profile
17:07:02 <TabAtkins_> glazou: Next topic.  Epub wants us to review the CSS-related section of their doc and send comments.
17:07:15 <Zakim> +SteveZ
17:07:23 <TabAtkins_> fantasai: I'm pretty sure we'll have some reasonably amount of time to discuss it.
17:07:34 <szilles> szilles has joined #css
17:07:45 <TabAtkins_> glazou: The CSS section is mostly a profile, right?
17:07:55 <TabAtkins_> fantasai: Yes, so we want to make sure they're profiling correctly.
17:08:09 <ChrisL> its also a profile of CSS 2.1, while EPUB2 was CSS2 iirc
17:08:11 <TabAtkins_> fantasai: jdaggett had some concerns, but I think they were addressed before publishing.
17:08:18 <Zakim> + +1.650.275.aadd
17:08:27 <TabAtkins_> fantasai: There are several features not in CR yet, so we need to make sure we're okay with dealing with that.
17:08:42 <bradk> bradk has joined #css
17:09:23 <TabAtkins_> ACTION on everyone: Review the CSS-related section of the epub document.
17:09:23 <trackbot> Sorry, couldn't find user - on
17:09:24 <fantasai> I don't see any mention of a deadline for comments.
17:09:39 <TabAtkins_> Topic: CSS 2.1 issues
17:09:41 <Zakim> +David_Baron
17:09:48 <TabAtkins_> glazou: Peter, you got a message from web2pdf.
17:09:56 <TabAtkins_> plinss: They're fixing a bunch of bugs in our blocked tests.
17:09:57 <glazou> WebToPDF.NET
17:10:00 <fantasai> Probably one month is good, so that they have time to address them and can make it in before their next draft (which I'm guessing will be more than one month out).
17:10:06 <TabAtkins_> plinss: They'll have a public beta release that fixes several of our blockers.
17:10:20 <glazou> http://test.csswg.org/harness/results?s=CSS21_HTML&t=0&f[]=1&f[]=1
17:10:32 <TabAtkins_> plinss: We're on 15 blocked tests now.
17:10:59 <TabAtkins_> plinss: I know they have fixes on two of them, and regressions on two more that they'll go back and fix.
17:11:14 <TabAtkins_> glazou: Any other 2.1 comments?
17:11:45 <TabAtkins_> johnjan: Looks like Elika's done a bunch of updates to the current issues list.
17:11:55 <TabAtkins_> fantasai: I just copied over the LC comments from the page I was stashing them on.
17:12:57 <Zakim> -glazou
17:13:20 <TabAtkins_> fantasai: There's a bunch of issues over clearance and margins that need a closer look at.
17:13:23 <glazou> one sec please
17:13:32 <fantasai> http://wiki.csswg.org/spec/css2.1#issue-209
17:13:33 <TabAtkins_> fantasai: Issue 209 should be easy to resolve.
17:13:37 <Zakim> +??P0
17:13:43 <glazou> Zakim, ??P0 is me
17:13:43 <Zakim> +glazou; got it
17:13:52 <fantasai> http://wiki.csswg.org/spec/css2.1#issue-207 probably requres some investigation by WG members; it involves clearance
17:13:58 <glazou> ChrisL: free.fr still cutting at 15mn despite of reregister settings...
17:14:01 <fantasai> also http://wiki.csswg.org/spec/css2.1#issue-211 is margin collapsing
17:15:46 <TabAtkins_> dbaron: The issue with the root element is that we never say what precisely establishes the root BFC, whether it's the root element or osmething above it.
17:16:22 <TabAtkins_> dbaron: The only place I've found that matters is if the root contains floats that extend below its normal content, or if the root has a background image vertically positioned anywhere other than "top".
17:16:33 <fantasai> s/or/and/
17:16:45 <TabAtkins_> dbaron: Gecko treats it as the root establishes a new BFC.  Opera and Webkit don't.
17:17:02 <TabAtkins_> fantasai: My inclination is to treat it as a BFC, since its margins don't collapse.  It would make things more consistent.
17:17:32 <TabAtkins_> alexmog: In IE we have a pagination problem, since if the root is a BFC then it won't break across pages.
17:18:04 <TabAtkins_> fantasai: Why would the root take the size of the page?
17:18:49 <TabAtkins_> alexmog: The root's layout box (whatever gets the scrollbar) gets set to the size of the first page.
17:19:02 <TabAtkins_> alexmog: I may not be able to describe the problems properly, and they may be impl-specific.
17:19:44 <glazou> https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
17:19:47 <dbaron> https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
17:20:04 <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20html%20{%20border%3A%20solid%20blue%3B%20}%0A%20%20.float%20{%20float%3A%20left%3B%20height%3A%2016in%3B%20border%3A%20solid%20orange%3B%20}%0A%3C%2Fstyle%3E%0A%0A%3Cdiv%20class%3D%22float%22%3E%3C%2Fdiv%3E
17:20:07 <TabAtkins_> dbaron: What matters in the test is the position of the orange stripe
17:20:14 <dbaron> in first test, what matters is position of orange stripe
17:20:34 <TabAtkins_> fantasai: In my test, if the blue box is large enough to hold the yellow, it's a BFC.
17:21:14 <TabAtkins_> alexmog: It's not a BFC in IE9 or IE8.  It was in IE7.
17:21:25 <TabAtkins_> fantasai: I suspect this isn't a web compat issue, since we have differeing implementations.
17:21:47 <TabAtkins_> fantasai: So I suggest to make it a BFC, because authors would get confused otherwise when root backgrounds don't contain their floats.
17:22:06 <TabAtkins_> alexmog: Can I check with Paged Media issues and get back to you on that?
17:22:08 <TabAtkins_> fantasai: Yup.
17:22:37 <TabAtkins_> alexmog: Another issue.  When pages change width, usually you take the width of the page where the BFC starts, and it stays that width.  This is how we treat tables and such.
17:22:55 <TabAtkins_> alexmog: But if the root is a BFC it has to act differently, so it can get larger if the page gets larger.
17:23:15 <TabAtkins_> Bert: Related, we have 'overflow' which can't apply to <body>.
17:24:27 <TabAtkins_> glazou: So do we need more time to decide on exactly how to handle this?
17:25:01 <TabAtkins_> dbaron: I'm okay with changing Moz, though we do need to define where the root BFC comes from.
17:25:52 <shan> shan has joined #css
17:26:05 <TabAtkins_> glazou: Is that okay with everyone?
17:26:12 <dbaron> I don't really understand alexmog's paged media issue, though.
17:26:42 <TabAtkins_> alexmog: Is it okay to say that the root is not a BFC in paged media?
17:27:01 <dbaron> I don't see any reference to block formatting contexts in the CSS 2.1 paged media chapter or in css3-page.
17:28:11 <TabAtkins_> alexmog: It's not written anywhere, but it's something that people will have to solve as they implement Paged Media.
17:28:27 <TabAtkins_> dbaron: is it related to BFCs specifically, or just to certian types of things that establish BFCs?
17:28:50 <TabAtkins_> alexmog: It's certainly easier to say that everything that establishes a BFC has that behavior.
17:29:02 <Zakim> -glazou
17:29:20 <TabAtkins_> fantasai: You say IE has special behavior for tables and such across pages to make their widths stay the same across pages?
17:29:27 <TabAtkins_> fantasai: You also do that for overflow:hidden?
17:29:29 <Zakim> +??P0
17:29:32 <glazou> Zakim, ??P0 is me
17:29:32 <Zakim> +glazou; got it
17:30:03 <TabAtkins_> alexmog: Yes, overflow:hidden elements also have this behavior.
17:30:28 <TabAtkins_> fantasai: I'd prefer that overflow:hidden elements act like normal elements.
17:30:45 <TabAtkins_> alexmog: So I don't strongly object to the root being a BFC, it would just make its pagination rules somewhat special.
17:31:14 <TabAtkins_> fantasai: Yeah, the pagination rules aren't clear in the first place.  We wrote something aobut chaning page widths into paged media, though it's not quite the same that you have.
17:31:16 <Zakim> +??P9
17:31:27 <TabAtkins_> alexmog: It's unlikely we'll make changes to IE9 in this regard, btw.
17:31:49 <TabAtkins_> glazou: So what do we do?
17:32:16 <shan> Zakim, ??P9 is me
17:32:16 <Zakim> +shan; got it
17:33:28 <TabAtkins_> TabAtkins_: It sounds like nobody has great disagreements, we just need to have some careful consideration of the issues and decide what to specify.
17:33:56 <TabAtkins_> johnjan: Is this really something we want to change right now?
17:35:03 <TabAtkins_> glazou: FF4 and IE9 are shipping with different behavior, so no matter what's decided there will be differeing impls.
17:35:12 <ChrisL> erratum for CSS 2.1 then?
17:35:20 <TabAtkins_> dbaron: I'm okay with waiting siz months and putting this into the next revision of 2.1, but I'm not okay with waiting for CSS3.
17:35:33 <TabAtkins_> RESOLVED: Discuss issue, resolve in CSS 2.1 errata.
17:35:44 <TabAtkins_> Topic: Gamma section in CSS 2.1 spec
17:36:04 <TabAtkins_> ChrisL: There was a discussion a few years ago from Chris Murphy, as a result of which we removed the section on gamma from CSS3 Color.
17:36:13 <TabAtkins_> ChrisL: It was confusing and outdated.
17:36:29 <TabAtkins_> ChrisL: It was recently pointed out to me that the same section is still there in CSS 2.1 as an informative note.
17:36:50 <TabAtkins_> ChrisL: It has no conformance weight, but it's still confusing and outdated and has negative value.  So we should delete it from CSS 2.1 as well.
17:37:21 <TabAtkins_> RESOLVED: Remove the gamma note from 2.1.
17:38:44 <arronei> http://wiki.csswg.org/spec/css2.1#issue-215
17:38:47 <arronei> http://wiki.csswg.org/spec/css2.1#issue-216
17:39:01 <TabAtkins_> arronei: There are two issues on the issues list that are super simple, 215 or 216.  We discussed at the testing f2f, and I think we all agreed to kill them.
17:39:44 <TabAtkins_> arronei: I'm not hearing any objections to leaving 215 undefined.
17:40:07 <TabAtkins_> arronei: dbaron, you said FF is the only one that passes 216, and everyone else goes the other way.  Do you object to dropping it?
17:40:24 <TabAtkins_> dbaron: I'm fine with that.  It can fall into a MAY.
17:40:44 <TabAtkins_> RESOLVED: Resolve issue 215 as undefined, and drop issue 216.
17:40:49 <TabAtkins_> Topic: Multicol algorithm.
17:40:51 <ChrisL> the comment from Chris Murphy about being ignored at W3C
17:40:52 <ChrisL> http://lists.freedesktop.org/archives/openicc/2011q1/002969.html
17:41:02 <TabAtkins_> glazou: howcome's not on the call, but he quoted two of his messages.
17:41:25 <TabAtkins_> alexmog: There are a few ways to treat a situation when there's no usable layout that satisfies the constraints.
17:41:41 <TabAtkins_> alexmog: One way is to honor everything that is exactly defined, and just overflow if necessary.
17:41:42 <plinss> s/drop issue 216/accept proposal for issue 216/
17:42:14 <TabAtkins_> alexmog: Another is to keep content visible, so users on a phone dn't get a pretty layout, but it's usable.
17:42:32 <TabAtkins_> alexmog: I think that nowhere in CSS do we alter the way we interpret properties based on whether an overflow is about to happen.
17:43:29 <TabAtkins_> alexmog: If we really care about the end-user and want to show them content, when the design intent totally fails, the best thing for the user is to just drop to a single column as soon as possible when the multicol properties can't be satisfied.
17:43:44 <TabAtkins_> alexmog: So once we shrink down to 0 col width, the next step should be to drop straight to 1 column.
17:44:39 <TabAtkins_> alexmog: I think these are the only two situations (honor exactly, or drop to 1col quickly), and not to try and gradually relax properties, hovering around unusable states.
17:44:44 <Zakim> -glazou
17:44:52 <TabAtkins_> Bert: I like the principle, but what's the practical effect of 0-width columns?
17:44:59 <Zakim> +??P0
17:45:05 <glazou> Zakim, ??P0 is me
17:45:05 <Zakim> +glazou; got it
17:45:09 <TabAtkins_> alexmog: I think the page becomes unusable before 0px-wide columns.
17:46:01 <TabAtkins_> alexmog: If the column is too small, the overflow just intrudes into the column-gap.
17:46:22 <Zakim> -ChrisL
17:46:31 <TabAtkins_> alexmog: If there's a single 0-width column, you'll see the overflow content.  With multiple columns you won't.
17:46:47 <TabAtkins_> szilles: I thought we discussed overflow columns just going to the right.  Does that help in this case?
17:46:55 <Zakim> +ChrisL
17:47:11 <TabAtkins_> alexmog: Different situation - that's where column width is specified, but not count.  This case is where column-count is specified, but not width.
17:48:14 <TabAtkins_> szilles: So really, if you want to service multiple screens, setting a fixed number of columns is a bad idea.
17:48:26 <TabAtkins_> alexmog: Without using media queries, yeah.  Setting column-width is a better approach in general.
17:50:02 <TabAtkins_> TabAtkins_: I think we should just honor things exactly.  It can produce an unusable situation, but that's easy to fix right with media queries.
17:50:10 <TabAtkins_> szilles: And what happens if I set both -width and -count?
17:50:15 <TabAtkins_> alexmog: Current spec ignores -count in that case.
17:50:29 <TabAtkins_> alexmog: I don't think that this extreme case is a good enough reason to add column-min-width.
17:50:35 <fantasai> I thought the -count became the maximum column count?
17:50:51 <TabAtkins_> alexmog: So we have two in favor of treating things exactly as specified.
17:50:54 <TabAtkins_> bradk: Me to.
17:50:58 <TabAtkins_> s/to/too/
17:51:01 <TabAtkins_> szilles: i could live with it.
17:51:09 <TabAtkins_> glazou: What's the option preferred by howcome?
17:51:24 <TabAtkins_> alexmog: I'd prefer to ask him directly, but I think he was okay with either option, and just wanted consensus.
17:51:36 <TabAtkins_> szilles: "Treating things exactly" is how the spec is now, right?
17:51:53 <TabAtkins_> alexmog: No, the current spec somewhat relaxes count in some situations.  It would remove 3 lines from the pseudo-algorithm.
17:52:24 <Zakim> -cesar
17:53:04 <TabAtkins_> fantasai: -count sets a minimum number of columns when used with -width, so if you set both values you effectively get a minimum width anyway.
17:53:19 <fantasai> s/minimum number/maximum number/
17:53:30 <TabAtkins_> alexmog: So I think we should ask howcome if he agrees with the consensus here.
17:53:35 <fantasai> You get your column count combined with a minimum width for the columns
17:53:53 <TabAtkins_> ACTION howcome to read the minutes from today and confirm if he agrees or not with the Multicol algo consensus.
17:53:53 <trackbot> Created ACTION-297 - Read the minutes from today and confirm if he agrees or not with the Multicol algo consensus. [on Håkon Wium Lie - due 2011-02-23].
17:54:01 <fantasai> So if is not room for all the columns given your -width, the algorithm drops columns until -width is honored
17:54:25 <TabAtkins_> Topic: :active disagreement between CSS and HTML
17:54:43 <fantasai> Could even recommend that authors set -width when setting -count, so that the columns don't get too narrow.
17:54:52 <TabAtkins_> Bert: I think the trouble is the definition of the word "activate".
17:55:04 <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Feb/0426.html
17:55:16 <TabAtkins_> Bert: We thought we needed some indirection at the time of speccing, so we just used the word "activate" and let the source language define that.
17:55:25 <TabAtkins_> Bert: But HTML already uses the word "activate" for something else.
17:55:50 <TabAtkins_> Bert: So this is just a wording problem.  They have to invent a new word for this or something, as the word "activate" is already taken in that spec.
17:55:54 <fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JanMar/0176.html
17:56:10 <TabAtkins_> ChrisL: So it seems that HTML can just say "For CSS purpose, 'activate' means XXX"
17:56:36 <TabAtkins_> Bert: Right.  Another option is for HTML to use a different word for what they currently call "activate", and then use "activate" in the CSS sense.
17:57:26 <TabAtkins_> TabAtkins_: I pinged Hixie this morning to ask him to change the wording.
17:58:07 <TabAtkins_> ACTION TabAtkins to report back to the group on the progress of this issue.
17:58:07 <trackbot> Sorry, couldn't find user - TabAtkins
17:58:15 <TabAtkins_> ACTION tab to report back to the group on the progress of this issue.
17:58:15 <trackbot> Created ACTION-298 - Report back to the group on the progress of this issue. [on Tab Atkins Jr. - due 2011-02-23].
18:00:25 <Zakim> -glazou
18:00:32 <glazou> shit
18:00:35 <glazou> cannotrejoin
18:00:36 <TabAtkins_> [discussion about communication between WGs]
18:00:50 <glazou> guys, end of call, will summarize by email
18:01:12 <glazou> sorry for that, blame my SIP client:(
18:01:12 <Zakim> -David_Baron
18:01:34 <Zakim> -ChrisL
18:01:55 <Zakim> -johnjan
18:01:57 <Zakim> -smfr
18:02:01 <Zakim> -plinss
18:02:02 <Zakim> -SteveZ
18:02:02 <Zakim> -kojiishi
18:02:03 <Zakim> -??P25
18:02:04 <Zakim> -Bert
18:02:11 <Zakim> -fantasai
18:02:12 <Zakim> - +1.650.275.aadd
18:02:12 <Zakim> -TabAtkins_
18:02:16 <Zakim> -shan
18:02:26 <Zakim> -arronei
18:02:32 <fantasai> Bert: can you forward your message to www-style?
18:02:43 <cesar> I'm sorry too: it seems I finished my Skype credit. :( (I have to try a SIP client). Bye!
18:07:27 <Zakim> disconnecting the lone participant, +1.206.324.aabb, in Style_CSS FP()12:00PM
18:07:29 <Zakim> Style_CSS FP()12:00PM has ended
18:07:32 <Zakim> Attendees were glazou, arronei, +1.858.216.aaaa, plinss, smfr, TabAtkins_, johnjan, +1.206.324.aabb, fantasai, Bert, +46.0.94.0.aacc, kojiishi, cesar, ChrisL, SteveZ,
18:07:35 <Zakim> ... +1.650.275.aadd, David_Baron, shan
18:07:51 <TabAtkins> Bert: Image Values should be all ready for WD publishing now, btw.
18:07:57 <TabAtkins> Bert: Anything else I need to do?
18:08:52 <fantasai> Bert: (Tab made a couple extra editorial edits yesterday)
18:10:38 <Bert> I'll try to have it published tomorrow.
18:12:18 <TabAtkins> Bert: Cool, thanks.
18:12:43 <Bert> Do you remember at what telcon we decided to publish it? Was it in January?
18:13:35 <Bert> Found it, Jan 26
18:16:06 <smfr> smfr has joined #css
18:28:51 <arronei> arronei has joined #CSS
19:02:59 <dbaron> dbaron has joined #css
19:07:42 <hey> hey has joined #css
19:09:14 <plinss> plinss has joined #css
19:12:19 <oickoame> oickoame has joined #css
19:12:40 <hey> hola
19:12:49 <hey> esto es una prueba
19:13:06 <hey> chao
19:13:16 <hey> hey has left #css
19:17:38 <smfr> smfr has joined #css
19:17:44 <smfr> smfr has left #css
19:24:21 <hober> hober has joined #css
19:38:21 <ChrisL> ChrisL has joined #css
20:12:42 <Zakim> Zakim has left #css
21:03:25 <jdaggett> jdaggett has joined #css
21:10:29 <sylvaing> sylvaing has left #css
21:25:58 <smfr_> smfr_ has joined #css
21:35:25 <myakura> myakura has joined #css
21:35:49 <myakura_> myakura_ has joined #css
23:08:13 <homata> homata has joined #CSS
23:22:39 <jdaggett> jdaggett has joined #css
23:23:41 <jdaggett_> jdaggett_ has joined #css
23:43:51 <plinss> plinss has joined #css