Options:
- # Session Start: Wed Sep 12 00:00:01 2012
- # Session Ident: #css
- # [00:12] * Quits: dbaron (dbaron@206.15.76.122) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [00:22] * Quits: jet (jet@67.169.43.128) (Connection reset by peer)
- # [00:22] * Joins: jet (jet@67.169.43.128)
- # [00:26] * Joins: nimbu (Adium@192.150.10.201)
- # [00:26] * Parts: nimbu (Adium@192.150.10.201)
- # [00:45] * Quits: miketaylr (miketaylr@70.3.230.70) (Quit: Leaving...)
- # [00:55] * Joins: dbaron (dbaron@206.15.76.122)
- # [01:18] * Joins: miketaylr (miketaylr@70.112.101.224)
- # [01:21] * Joins: nimbu (Adium@81.221.12.118)
- # [01:22] * Parts: nimbu (Adium@81.221.12.118)
- # [01:25] * Quits: SteveZ (chatzilla@128.31.35.234) (Ping timeout)
- # [02:57] * Quits: dholbert (dholbert@98.248.36.12) (Quit: dholbert)
- # [03:03] * Joins: jdaggett (jdaggett@103.5.142.7)
- # [03:15] * Quits: jdaggett (jdaggett@103.5.142.7) (Quit: jdaggett)
- # [03:58] * Quits: arno (arnog@192.150.10.200) (Quit: Leaving.)
- # [04:32] * Joins: SteveZ (chatzilla@70.91.193.41)
- # [05:32] * Quits: dbaron (dbaron@206.15.76.122) (Ping timeout)
- # [05:35] * Quits: SteveZ (chatzilla@70.91.193.41) (Ping timeout)
- # [06:01] * Joins: shepazu (shepazu@128.30.52.169)
- # [06:05] * Joins: jdaggett (jdaggett@180.235.8.216)
- # [06:15] * Joins: cabanier (cabanier@81.221.12.118)
- # [06:17] * Joins: dbaron (dbaron@70.36.140.99)
- # [06:24] * Joins: kennyluck (kennyluck@119.161.158.96)
- # [06:48] * Quits: cabanier (cabanier@81.221.12.118) (Ping timeout)
- # [07:28] * Joins: cabanier (cabanier@81.221.12.118)
- # [07:39] * Quits: cabanier (cabanier@81.221.12.118) (Quit: Leaving.)
- # [07:47] * Quits: miketaylr (miketaylr@70.112.101.224) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
- # [07:54] * heycam|away is now known as heycam
- # [07:58] * heycam is now known as heycam|away
- # [08:02] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
- # [09:00] * Quits: jet (jet@67.169.43.128) (Connection reset by peer)
- # [09:00] * Joins: shepazu (shepazu@128.30.52.169)
- # [09:00] * Joins: jet (jet@67.169.43.128)
- # [09:59] * Quits: jdaggett (jdaggett@180.235.8.216) (Quit: jdaggett)
- # [10:07] * Joins: victor (Adium@92.163.100.60)
- # [10:08] * Joins: cabanier (cabanier@82.130.73.1)
- # [10:10] * Quits: dbaron (dbaron@70.36.140.99) (Ping timeout)
- # [10:14] * Joins: drublic (drublic@77.2.138.155)
- # [10:15] * Quits: cabanier (cabanier@82.130.73.1) (Quit: Leaving.)
- # [10:17] * Quits: drublic (drublic@77.2.138.155) (Ping timeout)
- # [10:30] * Joins: drublic (drublic@80.152.164.43)
- # [10:46] * Quits: kennyluck (kennyluck@119.161.158.96) (Connection reset by peer)
- # [10:46] * Joins: kennyluck (kennyluck@119.161.158.96)
- # [11:13] * Joins: SimonSapin (simon@82.232.219.95)
- # [11:21] * leaverou is now known as leaverou_away
- # [11:25] * leaverou_away is now known as leaverou
- # [11:26] * Joins: cabanier (cabanier@82.130.71.190)
- # [11:34] * Quits: cabanier (cabanier@82.130.71.190) (Ping timeout)
- # [11:45] * leaverou is now known as leaverou_away
- # [11:47] * leaverou_away is now known as leaverou
- # [11:47] * Quits: jet (jet@67.169.43.128) (Quit: jet)
- # [11:49] * Joins: cabanier (cabanier@82.130.71.190)
- # [11:53] * Quits: cabanier (cabanier@82.130.71.190) (Ping timeout)
- # [12:10] * Joins: cabanier (cabanier@82.130.71.190)
- # [12:13] * Quits: cabanier (cabanier@82.130.71.190) (Ping timeout)
- # [12:17] * Joins: cabanier (cabanier@82.130.71.190)
- # [12:18] * Quits: cabanier (cabanier@82.130.71.190) (Quit: Leaving.)
- # [12:23] * Joins: macpherson_ (macpherson@216.239.33.104)
- # [12:23] * Joins: cabanier (cabanier@82.130.71.190)
- # [12:25] * Quits: macpherson__ (macpherson@74.125.56.17) (Ping timeout)
- # [12:34] * Quits: cabanier (cabanier@82.130.71.190) (Quit: Leaving.)
- # [12:52] * Joins: macpherson__ (macpherson@74.125.56.17)
- # [12:54] * Quits: macpherson_ (macpherson@216.239.33.104) (Ping timeout)
- # [12:54] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
- # [13:50] * Joins: shepazu (shepazu@128.30.52.169)
- # [14:32] * Joins: SteveZ (chatzilla@128.31.35.234)
- # [14:36] * leaverou is now known as leaverou_away
- # [14:56] * Joins: cabanier (cabanier@82.130.73.34)
- # [15:12] * Quits: cabanier (cabanier@82.130.73.34) (Quit: Leaving.)
- # [15:13] * Joins: cabanier (cabanier@82.130.73.34)
- # [15:18] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
- # [15:20] * Quits: cabanier (cabanier@82.130.73.34) (Quit: Leaving.)
- # [15:42] * heycam|away is now known as heycam
- # [15:42] * Joins: shepazu (shepazu@128.30.52.169)
- # [15:43] * Quits: shepazu (shepazu@128.30.52.169) (Client exited)
- # [15:44] * Joins: shepazu (shepazu@128.30.52.169)
- # [16:03] * Quits: kennyluck (kennyluck@119.161.158.96) (Quit: kennyluck)
- # [16:05] * Joins: cabanier (cabanier@82.130.72.90)
- # [16:20] * leaverou_away is now known as leaverou
- # [16:27] * Joins: miketaylr (miketaylr@70.112.101.224)
- # [16:30] * Quits: cabanier (cabanier@82.130.72.90) (Quit: Leaving.)
- # [16:31] * leaverou is now known as leaverou_away
- # [16:41] * heycam is now known as heycam|away
- # [17:13] * Joins: koji (koji@222.158.227.129)
- # [17:19] * leaverou_away is now known as leaverou
- # [17:45] * Joins: glazou (glazou@82.247.96.19)
- # [17:45] * Joins: Zakim (rrs-bridgg@128.30.52.169)
- # [17:45] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
- # [17:45] <RRSAgent> logging to http://www.w3.org/2012/09/12-css-irc
- # [17:45] <glazou> Zakim, this will be Style
- # [17:45] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 25 minutes
- # [17:45] <glazou> RRSAgent, make logs public
- # [17:45] <RRSAgent> I have made the request, glazou
- # [17:46] * Joins: dbaron (dbaron@70.36.140.99)
- # [17:49] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
- # [18:01] * Joins: jdaggett (jdaggett@180.235.8.216)
- # [18:01] * Joins: lstorset (lastorset@91.203.96.240)
- # [18:01] * Quits: jdaggett (jdaggett@180.235.8.216) (Quit: jdaggett)
- # [18:02] * Joins: jdaggett (jdaggett@180.235.8.216)
- # [18:05] * Joins: cabanier (cabanier@81.221.12.118)
- # [18:06] * Joins: antonp (Thunderbir@80.174.132.58)
- # [18:06] * Joins: rhauck (Adium@192.150.10.200)
- # [18:07] <Zakim> Style_CSS FP()12:00PM has now started
- # [18:07] <Zakim> + +1.415.615.aaaa
- # [18:07] <Zakim> - +1.415.615.aaaa
- # [18:07] <Zakim> Style_CSS FP()12:00PM has ended
- # [18:07] <Zakim> Attendees were +1.415.615.aaaa
- # [18:08] <Zakim> Style_CSS FP()12:00PM has now started
- # [18:08] * Joins: oyvind (oyvinds@91.203.97.251)
- # [18:08] <Zakim> + +1.415.615.aaaa
- # [18:08] <Zakim> +Lea
- # [18:08] <Zakim> +??P33
- # [18:09] <Zakim> +plinss
- # [18:09] <jdaggett> zakim, ??p33 is me
- # [18:09] <Zakim> +jdaggett; got it
- # [18:09] <Zakim> +stearns
- # [18:09] <Zakim> +??P41
- # [18:09] <glazou> Zakim, ??P41 is me
- # [18:09] <Zakim> + +1.206.324.aabb
- # [18:09] <Zakim> +glazou; got it
- # [18:09] <glazou> Zakim, who is here ?
- # [18:10] <jdaggett> yup
- # [18:10] <Zakim> On the phone I see +1.415.615.aaaa, Lea, jdaggett, plinss, stearns, glazou, +1.206.324.aabb
- # [18:10] <Zakim> On IRC I see oyvind, rhauck, antonp, cabanier, jdaggett, lstorset, dbaron, RRSAgent, Zakim, glazou, koji, miketaylr, SteveZ, macpherson__, SimonSapin, drublic, victor, vhardy_, ed,
- # [18:10] <Zakim> ... plinss, Bert, paul___irish, hober, decadance, fantasai, Hixie, TabAtkins_, gsnedders, jwir3, Liam, stearns, isherman, krijnhuman, logbot, leaverou, arronei, trackbot, alexmog,
- # [18:10] <Zakim> ... vhardy, sylvaing, shans, CSSWG_LogBot, heycam|away
- # [18:10] <Zakim> + +1.619.846.aacc
- # [18:11] <glazou> Regrets: szilles (AB meeting), brad, smfr (Apple event), florian, rbetts
- # [18:11] <Zakim> + +93192aadd
- # [18:11] <antonp> Zakim, aadd is me
- # [18:11] <Zakim> +lstorset
- # [18:12] * Joins: JohnJansen (qw3birc@128.30.52.28)
- # [18:12] <Zakim> -lstorset
- # [18:12] <Zakim> +antonp; got it
- # [18:12] * Joins: jarek (jarek@83.27.237.96)
- # [18:12] * Parts: rhauck (Adium@192.150.10.200)
- # [18:12] <hober> Zakim, aacc is me
- # [18:12] <leaverou> Zakim, Lea is me
- # [18:12] <Zakim> +lstorset
- # [18:13] <Zakim> +hober; got it
- # [18:13] <Zakim> +leaverou; got it
- # [18:13] <Zakim> -leaverou
- # [18:13] * Joins: PhilCupp (PhilCupp@131.107.147.10)
- # [18:13] <Zakim> +[Microsoft]
- # [18:13] <Zakim> +[Microsoft.a]
- # [18:13] <arronei> zakim, microsoft has me
- # [18:13] <JohnJansen> Zakim, Microsoft has JohnJansen
- # [18:13] <Zakim> +??P78
- # [18:13] <Zakim> +arronei; got it
- # [18:13] <Zakim> +JohnJansen; got it
- # [18:13] * fantasai joined, not sure who
- # [18:14] <Zakim> +leaverou
- # [18:14] <fantasai> Zakim, P78 is me
- # [18:14] <fantasai> ScribeNick: fantasai
- # [18:14] <Zakim> sorry, fantasai, I do not recognize a party named 'P78'
- # [18:14] <fantasai> glazou: any additions to agenda?
- # [18:14] <glazou> Zakim, ??P78 is fantasai
- # [18:14] * Joins: rhauck (Adium@192.150.10.200)
- # [18:14] * leaverou I'm in a Greek island and internet connections here are as stable as a Hollywood relationship, so I might have disconnects
- # [18:15] <Zakim> +??P82
- # [18:15] <Zakim> +[Microsoft.aa]
- # [18:15] <Zakim> +fantasai; got it
- # [18:15] <fantasai> glazou: First topic is Sunday of TPAC, but we don't have any news unless Bert joins
- # [18:16] <fantasai> glazou: Any info on TTWF location in Paris?
- # [18:16] <Zakim> +Bert
- # [18:16] <Zakim> +dbaron
- # [18:16] <fantasai> rhauck: We're working on it,
- # [18:16] <fantasai> rhauck: if anyone has suggestions, let us know
- # [18:16] <fantasai> rhauck: we'll email the list when we know
- # [18:16] <fantasai> rhauck: hoping by end of week
- # [18:17] <fantasai> Bert: We reserved the room for Sunday, will be in the Hotel de la Cité Concorde, in the conference center
- # [18:18] <Zakim> -stearns
- # [18:18] <fantasai> glazou: Marie-Claire is planning a W3C meetup on Monday evening at the city hall of Lyon
- # [18:18] <fantasai> glazou: Will be general meetup aobut W3C and our specs and tools built on our specs
- # [18:18] <fantasai> glazou: Will collect items, if you want to speak, ping Marie-Claire
- # [18:19] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Sep/0222.html
- # [18:19] * stearns not sure why my phone dropped the call, getting a busy signal now. will keep trying
- # [18:19] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Aug/0916.html
- # [18:19] <fantasai> glazou: maybe defer this until Florian can attend
- # [18:20] <fantasai> Topic: Font Load Events
- # [18:20] <glazou> http://dev.w3.org/csswg/css3-fonts/#font-load-events
- # [18:20] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-load-events
- # [18:20] <fantasai> jdaggett: started out as proposal from Florian (?)
- # [18:20] <fantasai> jdaggett: topic brought up a number of times, need for events that indicate when fonts have been loaded
- # [18:20] <fantasai> jdaggett: reason for this is that there could be content on the page need to be measured, can't happen until fonts are loaded
- # [18:21] <Zakim> +??P19
- # [18:21] <koji> zakim, ??p19 is me
- # [18:21] <Zakim> +koji; got it
- # [18:21] <fantasai> jdaggett: we've had several rounds of posts about font events from a couple years ago
- # [18:21] <fantasai> jdaggett: Tab recently proposed something
- # [18:21] <fantasai> jdaggett: I didn't like it, so I posted another proposal, in the spec now
- # [18:22] <fantasai> jdaggett: we need events for @font-face fonts b/c used lazily; not loaded until they're used
- # [18:22] <fantasai> jdaggett: Wanted to get from this call whether ppl happy with this proposal, flush out any possible objections
- # [18:22] <fantasai> jdaggett: Interface is still in flux; several ppl sent me private emails discussing certain parts of interface, things they find confusing, etc.
- # [18:23] <fantasai> jdaggett: Basically 2 types of events
- # [18:23] <fantasai> jdaggett: 1 gives you a way of identifying when all fonts are ready
- # [18:23] <fantasai> jdaggett: page could include multiple fonts, e.g. a bold and an italic
- # [18:23] <fantasai> jdaggett: It's hard for an author to track
- # [18:23] <fantasai> jdaggett: Also events that fire per font
- # [18:23] <fantasai> jdaggett: An app that wants to manage fonts very carefully would use those
- # [18:23] <fantasai> jdaggett: The existing WebLoader interface put together by Google is supported
- # [18:24] <fantasai> jdaggett: by several type [...] is more like per font detail
- # [18:24] * fantasai isn't sure that was minuted correctly
- # [18:24] <fantasai> Bert: I have no problem with the technology, just wondering what it does to the schedule of the draft
- # [18:24] <fantasai> Bert: Will it push back LC, or so easy will go ahead without loss of speed?
- # [18:25] <glazou> glazou: I read it and have no general comment; like it
- # [18:25] <antonp> [...] = online type services, I think
- # [18:25] <fantasai> jdaggett: Think it can go ahead without loss of speed, b/c ppl are very interested and sending lots of feedback
- # [18:25] <fantasai> jdaggett: caveat is that the OM for CSS font face rule, leftover from CSS2
- # [18:25] <fantasai> jdaggett: it uses CSSStyleDeclaration, which is odd
- # [18:25] <fantasai> jdaggett: I'm starting to hear rumblings of ppl that this isn't a good idea, switch to something else
- # [18:25] <fantasai> jdaggett: others are ambivalent
- # [18:25] <fantasai> jdaggett: Would influence this to a certain degree
- # [18:26] <fantasai> glazou: Could you use a CSS Rule instead?
- # [18:26] <fantasai> jdaggett: You need some place to define something like GetPropertyValue so you can get value of descriptors
- # [18:26] <fantasai> jdaggett: don't think need a setter for that...
- # [18:26] <fantasai> glazou: To avoid putting null CSSFontFaceRule in document, use a CSSRule
- # [18:26] <fantasai> jdaggett: What does that get you?
- # [18:27] <fantasai> glazou: In the future if we change CSSFontFaceRule [..] you will get it through CSSRule
- # [18:27] <fantasai> glazou: The result would be CSSRule, but you say in prose it is a CSSFontFaceRule
- # [18:27] * fantasai is so confused
- # [18:27] <fantasai> several ppl confused
- # [18:27] * leaverou is confused too
- # [18:27] <fantasai> glazou: You said that CSSFontFaceRule is subject to changes, b/c ppl don't like how it is right now.
- # [18:28] <fantasai> glazou: Suppose it becomes CSSFontFaceRule2 in the future
- # [18:28] <fantasai> glazou: That will still query interface to CSSRule, and you can use that as a reply to font-face attribute
- # [18:28] <fantasai> jdaggett: Don't think on CSSRule there's any way to access info currently contained in CSSStyleDeclaration
- # [18:28] <fantasai> glazou: No, not saying that. Saying that giving reply as CSSRule lets you have another interface in the future
- # [18:29] <fantasai> dbaron: Not a question of which interface, question of what we want on that interface
- # [18:29] <fantasai> jdaggett: Existing implementations implement the old interface, so have to consider that carefully.
- # [18:29] <fantasai> jdaggett: I think I need to do more research on this.
- # [18:29] <fantasai> jdaggett: Direct answer to Bert, but other OM issue could influence the schedule.
- # [18:29] <fantasai> jdaggett: If no one has other comments, then will continue to work through details on the list
- # [18:30] <fantasai> jdaggett: Since this is relatively major piece, once syntax worked out on the list, would like to publish another WD
- # [18:30] <fantasai> jdaggett: Sound reasonable?
- # [18:30] <fantasai> yes
- # [18:30] <fantasai> jdaggett: Ok, I'll work on this another week, then ask WG for publish
- # [18:30] <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0293.html
- # [18:30] <fantasai> topic: CSs2.1
- # [18:31] <fantasai> anton: First is table box vs wrapper box and 'overflow'
- # [18:31] <fantasai> anton: Observed that it's implemented on table box, but only some values are supported
- # [18:31] <fantasai> anton: others are handled as visible
- # [18:31] <antonp> http://lists.w3.org/Archives/Public/www-style/2012Aug/0308.html
- # [18:31] * stearns all long distance calls are failing for me at the moment. I'll just follow along on IRC
- # [18:31] <fantasai> anton: I proposed some wording, hope everyone's happy with it.
- # [18:32] <fantasai> works for me
- # [18:32] <Zakim> +TabAtkins_
- # [18:32] <fantasai> Bert: Looks fine to me too
- # [18:32] <fantasai> glazou: no objection, no other comments?
- # [18:32] <fantasai> RESOLVED: Accepted
- # [18:33] <fantasai> anton: Second issue is an idea to help the wording in various places
- # [18:33] * Quits: jarek (jarek@83.27.237.96) (Quit: jarek)
- # [18:33] <fantasai> anton: going down a path we're going down a lot: defining terms we can reuse
- # [18:33] * Joins: jarek (jarek@83.27.237.96)
- # [18:33] <fantasai> anton: Want to define the term "block container element"
- # [18:33] <fantasai> anton: "block container box" was introduced in CSS2.1
- # [18:33] <glazou> slow down antonp please
- # [18:33] <fantasai> anton: A "block container element" is an element that generates a "block container box"
- # [18:34] <fantasai> anton: Don't have this wording in CSS2.1 yet, but would make fixing various issues much easier
- # [18:34] <fantasai> anton: I proposed this on the list, talked with fantasai, but no one else involved in conversation.
- # [18:34] <antonp> http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html
- # [18:34] <fantasai> anton: Looking what other ppl think
- # [18:34] <fantasai> anton: It's a long email, starts with motiviation
- # [18:34] <fantasai> anton: follows with prposal
- # [18:35] <fantasai> Rossen: Can I give you feedback a little bit later?
- # [18:36] <fantasai> glazou: Ok, let's take a week to review this proposal and discuss it next week.
- # [18:36] <glazou> http://lists.w3.org/Archives/Public/www-style/2012Sep/0112.html
- # [18:36] <fantasai> Topic: Consuming height at breaks
- # [18:36] <TabAtkins_> ScribeNick: TabAtkins_
- # [18:37] <TabAtkins_> fantasai: I've been going back and forth on this.
- # [18:37] <TabAtkins_> fantasai: Rossena nd I were talking last week about edits from the San Diego f2f.
- # [18:37] <TabAtkins_> fantasai: one of the issues taht came up was...
- # [18:37] <TabAtkins_> fantasai: If you have specified height on a box, that'll terminate *above* the bottom of the page, and continue on the next page.
- # [18:37] * Quits: SteveZ (chatzilla@128.31.35.234) (Connection reset by peer)
- # [18:37] <Zakim> +stearns
- # [18:37] <TabAtkins_> fantasai: You wont' consume height between the cut and the next page, and won't draw there either.
- # [18:37] <TabAtkins_> fantasai: That seems weird when you consider floats.
- # [18:38] <TabAtkins_> fantasai: Normally you ahve text wrapping around floats, and eventually wrapping under it.
- # [18:38] <TabAtkins_> fantasai: But here, there's space you can't wrap text around it.
- # [18:38] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
- # [18:38] <TabAtkins_> fantasai: Because the element isn't visibly taking up space there.
- # [18:38] <TabAtkins_> fantasai: So we were discussing whether you can flow content under a broken float.
- # [18:38] <Zakim> -[Microsoft]
- # [18:38] <TabAtkins_> fantasai: And the answer is no.
- # [18:38] <TabAtkins_> fantasai: And so - should you draw backgrounds, if you're taking up space (for the float)? If you're not drawing backgrounds, what are you doing with floats?
- # [18:39] <TabAtkins_> fantasai: So we're considering reversing, and just making everything draw to the bottom of the page and consume height. Thoughts?
- # [18:39] <TabAtkins_> antonp: I think it should draw to the bottom of the page. It's confusing as a reader to see something appear to terminate, but then it's there again at the next page.
- # [18:40] <TabAtkins_> antonp: I think I don't want it to consume height, though. Just calculate the extra space and add it on afterwards.
- # [18:40] <TabAtkins_> rossen: In essense, what Anton is asking for is to have a fairly tight coupling of content and containers, which is not present anywhere else in layout.
- # [18:41] <TabAtkins_> rossen: You have content, which draws independently of its container (to some degree).
- # [18:41] <TabAtkins_> rossen: The content is free to extend to whatever extent it needs.
- # [18:41] <TabAtkins_> rossen: The container may or may not take a dependency on that content.
- # [18:42] <TabAtkins_> rossen: If your height is auto, you stretch to the height; if it's specified, you just stick with that regardless of content.
- # [18:42] <TabAtkins_> rossen: Let's take as an example a block container with something with clearance on it.
- # [18:42] <TabAtkins_> rossen: If it's height auto, the clearance int he presence of a float will extend the height of the container.
- # [18:42] <TabAtkins_> rossen: Back to fragmentation, we're asking the same question.
- # [18:42] <TabAtkins_> rossen: I have something inside which needs to be longer than it was originally (extending to the next page).
- # [18:43] <TabAtkins_> rossen: The container may or may not take a dependency on that content, and stretch to the content's height.
- # [18:43] <TabAtkins_> rossen: But if it's fixed, it's just fixed.
- # [18:43] <TabAtkins_> rossen: So if, in this specific case, we don't consume from the specified height, now we're coupling content and containers.
- # [18:43] <TabAtkins_> rossen: And then my question is, why don't we do the same thing for 'clear' or similar mechanics?
- # [18:43] <TabAtkins_> rossen: That's why specified height is specified - if it's exhausted, it's exhausted.
- # [18:44] <TabAtkins_> antonp: That makes sense to me. You're right to bring up that there's two ways to look at it.
- # [18:44] <TabAtkins_> antonp: The question "why is height specified?"
- # [18:44] <TabAtkins_> antonp: It could be because of the relationship between the box and its surroundings, or between the box and its contents.
- # [18:45] <TabAtkins_> antonp: If you're specifying a height because you're going to specify properties on it that rely on that height, my answer won't be good - backgrounds won't look nice.
- # [18:45] <TabAtkins_> antonp: But equally, if you *don't* consume height, you might get the same visual problem as before.
- # [18:45] <TabAtkins_> antonp: I can imagine a situation where content is fragmented onto the next page.
- # [18:45] <TabAtkins_> antonp: There's a gap, but it's only partially filled now by the content.
- # [18:46] <TabAtkins_> antonp: You lose the visual indication that there can't be any more content.
- # [18:46] <TabAtkins_> TabAtkins_: In that case, it's kinda like overflow:visible, which does look horrible sometimes.
- # [18:46] <TabAtkins_> fantasai: Yes, you might have a background positioned relative to the top of the box, so it looks bad if it continues.
- # [18:47] <TabAtkins_> fantasai: On the other hand, you may have two boxes that have a specified height, because you want them to be the same specific size (maybe they're side-by-side). If they break at different points, they'll end at different points, when the layout of the rest of the box depends on them being the same height.
- # [18:48] <TabAtkins_> fantasai: There's no answer that'll give us the right behavior in all cases.
- # [18:48] <TabAtkins_> rossen: You can also usually address this by specifying min-height instead. In the non-fragmented case, they're the same height; if height extends to higher than expected during fragmentation, it's auto height and the container will stretch as necessary.
- # [18:49] <TabAtkins_> fantasai: One data point is that existing impls draw to the bottom fo the page and consume height.
- # [18:49] <TabAtkins_> fantasai: At least in Moz's codebase, it requires an extra level of bookkeeping if we want to draw to the bottom of the page but not consume height. You either do both or do neither.
- # [18:50] <TabAtkins_> fantasai: We're getting to the point of having more layout algorithms with boxes side-by-side, which should be the same height, and it makes sense for block flow to have the same behavior, so you're consistent.
- # [18:50] <fantasai> s/should be the same height/should draw to the bottom of the page/
- # [18:51] <TabAtkins_> antonp: I wouldnt' object to taht status quo.
- # [18:51] <TabAtkins_> antonp: I think it should draw to the bottom. If it's easier, let's have it consume height.
- # [18:51] * hober has to drop off; Apple event.
- # [18:51] <TabAtkins_> rossen: Again, I don't think anyone is suggesting the opposite.
- # [18:51] <glazou> ok bye hober
- # [18:51] <Zakim> -hober
- # [18:52] <TabAtkins_> rossen: The visual should be consistent with the layout.
- # [18:53] <fantasai> TabAtkins: [...]
- # [18:53] <TabAtkins_> TabAtkins_: Agreed. I liked the ability to sometimes do good, but you've convinced me that we cant' do good sufficiently often, so let's just do the simple thing that's usually good enough.
- # [18:53] <TabAtkins_> plinss: My only concern is having a box accidentally overflow when it wasn't intended to.
- # [18:54] <TabAtkins_> TabAtkins_: Right, that's the time when it turns bad. But as Rossen points out, there are ways around that (use min-height), and we can always expose an explicit swtich afterwards if we want.
- # [18:54] <TabAtkins_> rossen: Reiterating, looking at different impls, that's the beahvior you have today with pagination. So the spec will be fairly consistent with that.
- # [18:54] <TabAtkins_> rossen: So if we do introduce a smarter behavior, we may be looking at compat problems.
- # [18:55] <TabAtkins_> plinss: I'll point out that the "impls already do this" is usually a good argument, but most impls do such a bad job at pagination, it's not really a very strong argument here.
- # [18:55] <TabAtkins_> fantasai: I'd agree with that.
- # [18:56] <TabAtkins_> fantasai: But there are cases where consuming the specified height will cause overflow, and other cases where it will prevent overflow - by not consuming the remaining space on the page, the container may be longer than expected, and *it's* parent now overflows.
- # [18:56] <TabAtkins_> fantasai: Two boxes that are 100% tall in a fixed-height box, side by side.
- # [18:56] <TabAtkins_> fantasai: I break the page, one consumes height, the other doesn't, one of the boxes will overflow its parent.
- # [18:56] <TabAtkins_> fantasai: So neither behavior works in all cases. It depends on the layout, and depends on the content.
- # [18:57] <TabAtkins_> fantasai: Both answers are 50% good and 50% bad. So, the argument to be consistent seems to win otu.
- # [18:58] <TabAtkins_> Bert: I think it's fine, but could you summarize the conclusion again?
- # [18:58] <TabAtkins_> fantasai: The conclusion is that all boxes draw and consume height as normal in the presence of breaks, to the bottom of the page past the break.
- # [18:58] <TabAtkins_> Bert: Okay, I can agree with that.
- # [18:59] <Zakim> -jdaggett
- # [18:59] <TabAtkins_> TabAtkins_: The point is that a break just does the equivalent of putting a big spacer element in there.
- # [18:59] <TabAtkins_> antonp: If you glue the boxes back together, it's the total height.
- # [18:59] <Bert> (The key is "consumes height", the border may indeed not even reach the bottom of the page.)
- # [18:59] <TabAtkins_> glazou: Objections?
- # [19:00] <TabAtkins_> RESOLVED: Conclusion by fantasai about breaking, above, accepted.
- # [19:00] * dbaron Zakim, who is noisy?
- # [19:01] * Zakim dbaron, listening for 10 seconds I heard sound from the following: glazou (9%)
- # [19:01] <Zakim> -??P82
- # [19:01] * sylvaing who's attending the call from the dentist?
- # [19:01] <TabAtkins_> Topic: Counter Styles
- # [19:01] * leaverou sylvaing LOL
- # [19:01] <glazou> http://lists.w3.org/Archives/Public/www-style/2012Aug/0916.html
- # [19:01] * dbaron Zakim, who is noisy?
- # [19:01] <glazou> sylvaing: lol
- # [19:01] <TabAtkins_> fantasai: I think florian's issue is that he'd like the counter styles that weren't in 2.1 to be marked as at-risk.
- # [19:01] * Zakim dbaron, listening for 10 seconds I heard sound from the following: glazou (12%)
- # [19:02] * dbaron thinks Zakim can't hear anyone other than glazou
- # [19:02] <TabAtkins_> TabAtkins_: I'm fine with marking all the non-2.1 styles (the 2.0 styles, and the replacement CJK styles) as at-risk.
- # [19:02] <Zakim> -fantasai
- # [19:02] <TabAtkins_> RESOLVED: Mark the non-2.1 Counter Styles as at-risk.
- # [19:03] <Zakim> +??P33
- # [19:03] <TabAtkins_> glazou: I have one additional thing.
- # [19:03] <fantasai> Zakim, ??P33 is fantasai
- # [19:03] <Zakim> +fantasai; got it
- # [19:03] <TabAtkins_> glazou: Koji, you're right that I missed CSS Ruby in the list of documents int he prioritization email.
- # [19:03] <TabAtkins_> glazou: So please consider it included. I missed it by accident.
- # [19:03] <TabAtkins_> arronei: I ahve another comment on that list.
- # [19:04] <TabAtkins_> arronei: Did you send that list to some influentials, like Molly or Designers?
- # [19:04] <TabAtkins_> glazou: The Invited Experts in the WG got it.
- # [19:04] <TabAtkins_> glazou: I didn't ping anyone outside the WG.
- # [19:04] <TabAtkins_> TabAtkins_: I think between our IEs we ahve enough "designer voice" to be useful - Molly, Lea, etc.
- # [19:04] * leaverou Did I hear my name or was it my idea?
- # [19:05] <glazou> you heard well
- # [19:05] * leaverou glazou: Should I respond to that? I figured Bert will respond for W3C
- # [19:06] <TabAtkins_> sylvaing: I don't see anything in there that says "you ahve to be an implementor to answer this", but if Anton thought he shouldn't answer it...
- # [19:06] <TabAtkins_> glazou: Be sure that the entire WG's answer will be valued.
- # [19:07] <TabAtkins_> glazou: Lea, you have two faces in this group - on the one hand, you're W3C staff, on the other hand, you're an influential member of the design community. So we'd probably be interested in your more personal opinions.
- # [19:07] <TabAtkins_> leaverou: Like what devs would like the most? Sure.
- # [19:08] <TabAtkins_> glazou: So, everyone, ping your AC reps so we can get the surveys back in two weeks time.
- # [19:08] <Zakim> -[Microsoft.aa]
- # [19:08] <Zakim> -dbaron
- # [19:08] <Zakim> -[Microsoft.a]
- # [19:08] <Zakim> -TabAtkins_
- # [19:08] <Zakim> -leaverou
- # [19:08] <Zakim> -glazou
- # [19:08] * Quits: koji (koji@222.158.227.129) (Quit: Leaving...)
- # [19:08] * Quits: PhilCupp (PhilCupp@131.107.147.10) (Quit: PhilCupp)
- # [19:08] <Zakim> -stearns
- # [19:08] <Zakim> - +1.206.324.aabb
- # [19:08] <Zakim> -lstorset
- # [19:08] <Zakim> -antonp
- # [19:08] <Zakim> - +1.415.615.aaaa
- # [19:08] <Zakim> -koji
- # [19:08] <Zakim> -Bert
- # [19:08] * Quits: lstorset (lastorset@91.203.96.240) (Quit: Leaving.)
- # [19:08] <Zakim> -plinss
- # [19:09] <Zakim> -fantasai
- # [19:09] <Zakim> Style_CSS FP()12:00PM has ended
- # [19:09] <Zakim> Attendees were +1.415.615.aaaa, plinss, jdaggett, stearns, +1.206.324.aabb, glazou, +1.619.846.aacc, +93192aadd, lstorset, antonp, hober, leaverou, arronei, JohnJansen,
- # [19:09] <Zakim> ... [Microsoft], fantasai, Bert, dbaron, koji, TabAtkins_
- # [19:10] * Quits: rhauck (Adium@192.150.10.200) (Ping timeout)
- # [19:11] * Quits: jarek (jarek@83.27.237.96) (Quit: jarek)
- # [19:12] * Joins: rhauck (Adium@192.150.10.201)
- # [19:14] * Joins: rhauck1 (Adium@192.150.10.200)
- # [19:15] * Quits: rhauck (Adium@192.150.10.201) (Ping timeout)
- # [19:15] * sylvaing is now known as sylvaing_away
- # [19:21] <leaverou> glazou: what's the best way to reply? Copy the table in the email client and fill it in? Is there something better?
- # [19:21] * Joins: SteveZ (chatzilla@128.31.35.234)
- # [19:21] <leaverou> e.g. a wiki
- # [19:21] <glazou> leaverou: no, copy/paste + email please
- # [19:21] <TabAtkins_> I was going to just make a list with headings for the priority categories.
- # [19:22] <leaverou> TabAtkins_: ah, that sounds better!
- # [19:22] <glazou> guys, NO
- # [19:22] <leaverou> :(
- # [19:22] <glazou> some membres may request confidentiality
- # [19:22] <glazou> let Peter and I handle this
- # [19:22] <TabAtkins_> Yeah, I was saying for *my* response.
- # [19:22] <glazou> members even
- # [19:22] <glazou> ok
- # [19:22] <TabAtkins_> That is, Google's.
- # [19:22] <glazou> ok then
- # [19:23] <leaverou> yes, i was talking about my response too
- # [19:23] <leaverou> ah, nevermind, I found a good way to do it with Apple’s Mail. I'll send the table
- # [19:23] <leaverou> for anyone interested: Right click the email, choose "Redirect"
- # [19:24] <leaverou> then you get the table without any quotation
- # [19:25] <TabAtkins_> In most clients, you can just select "forward" and then remove the additional headers it puts in. No additional quotation added.
- # [19:26] <leaverou> TabAtkins_: when you forward, the original message is usually in a quote
- # [19:26] <TabAtkins_> Not in Gmail, at least.
- # [19:26] <leaverou> I guess Gmail is an exception then
- # [19:27] <leaverou> Thunderbird and Apple’s Mail put it in a quote
- # [19:28] <leaverou> dbaron: you there?
- # [19:28] <dbaron> leaverou, yes
- # [19:29] <leaverou> dbaron: I had never seen color correction before
- # [19:29] <leaverou> may I ask
- # [19:29] <leaverou> Why is there only default and sRGB? What about specifying a custom color profile?
- # [19:31] <dbaron> leaverou, because the spec is trying to solve the problem that it describes in the abstract & introduction
- # [19:32] <dbaron> leaverou, which is finding a path through which we can migrate to actually being in a defined color space at all
- # [19:32] <leaverou> dbaron: so there are thoughts about extending it in the future to allow custom color profiles, right?
- # [19:33] * Quits: drublic (drublic@80.152.164.43) (Client exited)
- # [19:33] <dbaron> leaverou, I'm not sure; images can, of course, have custom color profiles
- # [19:33] <dbaron> leaverou, but I'm not sure it's really that valuable for CSS colors
- # [19:33] * Joins: drublic (drublic@80.152.164.43)
- # [19:33] <leaverou> dbaron: It certainly would be valuable if cmyk() colors were allowed outside of paged media
- # [19:33] <dbaron> leaverou, cmyk() is a mess
- # [19:34] <dbaron> leaverou, there's no standard for what it means
- # [19:34] <leaverou> there are multiple color profiles that define how it converts to sRGB, non?
- # [19:34] <dbaron> leaverou, I've really got to run now, though
- # [19:35] <dbaron> leaverou, can talk more another time
- # [19:35] <leaverou> dbaron: sure, lets pick this up later
- # [19:35] <leaverou> I'm very interested in the topic
- # [19:36] * Quits: drublic (drublic@80.152.164.43) (Ping timeout)
- # [19:46] * Quits: oyvind (oyvinds@91.203.97.251) (Quit: oyvind)
- # [19:50] <leaverou> glazou: the FXTF specs are missing, is that intentional?
- # [19:53] <fantasai> leaverou: I'm guessing css3-background is LI because it's implemented already?
- # [19:53] <leaverou> fantasai: exactly
- # [19:53] * fantasai doesn't think border-radius qualifies as "low interest"
- # [19:53] <fantasai> :P
- # [19:54] <leaverou> once something is implemented in the big four, the community's interest shifts
- # [19:54] <leaverou> they don't really care much about the edge cases
- # [19:54] <leaverou> in my experience
- # [19:57] <leaverou> for example, background-clip is still not implemented correctly by WebKit, but nobody seems to care
- # [19:58] * Quits: SimonSapin (simon@82.232.219.95) (Ping timeout)
- # [20:00] * Joins: drublic (drublic@77.2.138.155)
- # [20:02] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
- # [20:06] * Quits: dbaron (dbaron@70.36.140.99) (Ping timeout)
- # [20:06] * Joins: dbaron (dbaron@70.36.140.99)
- # [20:10] * Quits: dbaron (dbaron@70.36.140.99) (Ping timeout)
- # [20:12] <leaverou> TabAtkins_: you there?
- # [20:12] * Joins: arno1 (arnog@192.150.10.201)
- # [20:15] * Quits: arno1 (arnog@192.150.10.201) (Quit: Leaving.)
- # [20:17] <TabAtkins_> leaverou: pong
- # [20:17] * Joins: arno1 (arnog@192.150.10.200)
- # [20:17] <leaverou> TabAtkins_: I think I remember a discussion about this, but I can't find it
- # [20:17] <leaverou> in CSS hierarchies
- # [20:17] <leaverou> can you do things like .foo > & > .bar ?
- # [20:18] <TabAtkins_> The current state of the spec, no. Just this morning I sent an email to Shane arguing that we should bite the bullet and allow it.
- # [20:19] <leaverou> TabAtkins_: ha, nice coincidence. Was that email to a list?
- # [20:19] <leaverou> TabAtkins_: I've recently started using LESS to experiment a bit with these concepts
- # [20:19] <TabAtkins_> Nah, private.
- # [20:19] <leaverou> and even though LESS doesn't allow it
- # [20:19] <leaverou> I think it would be immensely useful
- # [20:19] <TabAtkins_> LESS doesn't allow it? Sass does.
- # [20:19] <leaverou> e..g. When using .foo as a "conditional" type of thing
- # [20:20] <leaverou> e.g. I want the h1 to be styled this way, but when inside section#foo I want it to be styled a bit differently, but I still want to have everything in one place
- # [20:20] <TabAtkins_> Yeah, definitely. Clear and obvious use-cases.
- # [20:20] <TabAtkins_> I'm surprised that LESS doesnt' support it, but that's why Sass is better.
- # [20:21] <leaverou> TabAtkins_: also, does it allow @media rules to be nested inside it?
- # [20:21] <leaverou> e.g. I want this heading to be styled this way, but another way in print
- # [20:22] <TabAtkins_> Not yet. That's another, separate thing I'd like to make happen.
- # [20:22] <leaverou> awesome!
- # [20:22] <TabAtkins_> Unrelated to Hierarchies - that should be part of Conditional.
- # [20:24] <leaverou> TabAtkins_: I'm not sure about that. I'm not talking about nesting @rules inside @rules, I'm talking about nesting @rules in CSS rules
- # [20:24] <TabAtkins_> Yes.
- # [20:24] <TabAtkins_> The problems that make Hierarchies somewhat difficult are non-existent for nesting at-rules.
- # [20:25] <leaverou> and still be able to use & inside the @rule
- # [20:28] <leaverou> TabAtkins_: also, is & still necessary in the beginning? I remember there was a parsing issue?
- # [20:29] <TabAtkins_> That's the issue I was talking about up above.
- # [20:29] <leaverou> is it that you have to lookahead to more tokens to realize it's a nested rule?
- # [20:29] <TabAtkins_> Theoretically, it requires infinite lookahead to disambiguate, yeah.
- # [20:30] <leaverou> due to pseudo classes, I guess?
- # [20:30] <TabAtkins_> In practice, it requires 1-token lookahead for anything in HTML, and three-token for virtually anything in arbitrary XML.
- # [20:30] <TabAtkins_> Yeah, "a:hover" looks like a property named "a" with a value starting with the keyword "hover".
- # [20:30] <leaverou> oh, why is it different for XML? I'd guess due to namespaces, but I don't see the collision
- # [20:31] <TabAtkins_> HTML has a limited set of tagnames. XML has infinite.
- # [20:31] <TabAtkins_> There are no collisions between html tagnames and CSS properties so far. (SVG has 5.)
- # [20:31] <leaverou> authors can still use invalid arbitary tag names in HTML
- # [20:31] <leaverou> and CSS is still supposed to style them
- # [20:31] <leaverou> though I'm not sure that's specced
- # [20:32] <TabAtkins_> Sure, but that's okay.
- # [20:32] <leaverou> also, CSS has to remain forwards compatible, we can't restrict the tag selector to only known tag names, right?
- # [20:32] <TabAtkins_> Just check the first three tokens. If they look like "ident colon ident", interpret as a selector. Otherwise, interpret as a property.
- # [20:33] <TabAtkins_> This effectively means we're requiring a space on at least one side fo the colon in properties.
- # [20:33] <leaverou> TabAtkins_: could they still look like ident colon ident and look as a declaration?
- # [20:34] <leaverou> for example, border-style:solid
- # [20:34] <TabAtkins_> No, because of forward-compat. We don't want legacy browsers to break when we add new tagnames or pseudoclasses.
- # [20:34] <leaverou> yes
- # [20:35] <leaverou> that's exactly what I'm saying
- # [20:35] <leaverou> my IRC client isn't helping much, it has this weird bug where I have to type /reload style to get new messages sometimes
- # [20:36] <leaverou> my IRC client (Colloquy) isn't helping much, it has this weird bug where I have to type / reload style to get new messages sometimes
- # [20:36] * Joins: jet (jet@206.15.76.122)
- # [20:36] <leaverou> including my messages, e.g. it seemed I didn't send this until I did that, which is why I sent it twice :(
- # [20:37] <TabAtkins_> Jeez.
- # [20:37] <leaverou> it only does it on W3C rooms for some reason, both private and public
- # [20:38] * leaverou if anyone has another OSX IRC client to suggest that doesn't look like crap, I'd be eternally grateful
- # [20:41] <leaverou> TabAtkins_: anyway, what I was saying is that many CSS files don't use a space after the colon for declarations. Especially minified CSS. We can't require that.
- # [20:44] <TabAtkins_> Then we're stuck. Shrug.
- # [20:44] <leaverou> :(
- # [20:48] <leaverou> TabAtkins_: is there a mailing list discussion about this problem? Perhaps someone else has an idea of how to solve it
- # [20:58] * Joins: dbaron (dbaron@206.15.76.122)
- # [21:15] * Quits: SteveZ (chatzilla@128.31.35.234) (Ping timeout)
- # [21:23] * Zakim excuses himself; his presence no longer seems to be needed
- # [21:23] * Parts: Zakim (rrs-bridgg@128.30.52.169)
- # [21:30] * leaverou is now known as leaverou_away
- # [21:52] * Quits: cabanier (cabanier@81.221.12.118) (Quit: Leaving.)
- # [22:03] * Quits: arno1 (arnog@192.150.10.200) (Connection reset by peer)
- # [22:03] * Joins: arno (arnog@192.150.10.200)
- # [22:10] * Quits: drublic (drublic@77.2.138.155) (Client exited)
- # [22:10] * Joins: drublic (drublic@77.2.138.155)
- # [22:13] * Quits: drublic (drublic@77.2.138.155) (Ping timeout)
- # [22:16] * Quits: dbaron (dbaron@206.15.76.122) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [22:35] * sylvaing_away is now known as sylvaing
- # [23:16] * Joins: dbaron (dbaron@206.15.76.122)
- # [23:27] * Quits: antonp (Thunderbir@80.174.132.58) (Quit: antonp)
- # [23:41] * Quits: arno (arnog@192.150.10.200) (Ping timeout)
- # [23:43] * Joins: arno (arnog@192.150.10.201)
- # Session Close: Thu Sep 13 00:00:00 2012
The end :)