Options:
- # Session Start: Fri Nov 04 00:00:00 2011
- # Session Ident: #css
- # [00:09] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
- # [00:16] * Joins: miketaylr (miketaylr@76.229.242.92)
- # [00:22] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
- # [00:23] * Joins: Mike5 (Mike5@mcclure.w3.org)
- # [00:23] * Joins: dbaron (dbaron@63.145.238.4)
- # [00:25] * Quits: stearns (anonymous@63.145.238.4) (Quit: stearns)
- # [00:32] * Quits: Kai (chatzilla@63.145.238.4) (Ping timeout)
- # [00:34] * Quits: miketaylr (miketaylr@76.229.242.92) (Quit: miketaylr)
- # [00:37] * Joins: ojan (ojan@72.14.229.81)
- # [00:37] <ojan> random question...anyone know the history behind percentage sizes in standards mode? specifically, in quirks mode, to resolve a percentage, you walk up the tree until you hit the first non-auto, non-percentage valu (roughly)...for standards mode, if you hit an auto value you bail.
- # [00:37] <ojan> this behavior seems totally wrong to me and i'm wondering how the decision got made, so i can propose a fix for the future
- # [00:38] <ojan> dbaron: ^^^ maybe you know?
- # [00:38] <dbaron> which behavior seems wrong?
- # [00:38] <dbaron> quirks or standards?
- # [00:38] <ojan> dbaron: standards
- # [00:39] <ojan> dbaron: right or wrong is irrelevant...it's clearly not what people want/expect
- # [00:39] <dbaron> yeah
- # [00:39] <dbaron> it's what the spec says, and I suppose we've never argued
- # [00:39] <dbaron> yeah
- # [00:39] <dbaron> it mgiht be a compat problem now, though
- # [00:39] <ojan> dbaron: oh yeah...no way we can change it
- # [00:39] <ojan> dbaron: but, if there wasn't a good reason for it, we could always add a new unit
- # [00:40] <ojan> dbaron: the way you get the behavior you want these days is to have to put height 100% on every ancestor including the html element
- # [00:40] <ojan> dbaron: == the suck
- # [00:40] <ojan> dbaron: web dev after web dev is confused by this and it sucks to have to litter your tree with height values
- # [00:41] <ojan> dbaron: hwen you change your structure a little, you have to remember to put height 100% on any new elements you add
- # [00:56] * Joins: hober2 (ted@173.255.247.253)
- # [00:57] <ojan> dbaron: a coworker had an interesting idea of an altnerative to a new unit, we could add a new property a la box-sizing to control the behavior in a subtree
- # [00:58] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Ping timeout)
- # [01:00] * Quits: hober (ted@174.143.153.77) (Ping timeout)
- # [01:00] * Joins: Kai (chatzilla@63.145.238.4)
- # [01:02] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
- # [01:08] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
- # [01:09] <tantek> ojan - what's the use case you're trying to address?
- # [01:10] <ojan> tantek: making an element fill one of it's ancestors...which is very common...e.g.
- # [01:10] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
- # [01:10] <tantek> ojan - doesn't flexbox solve that?
- # [01:10] <ojan> tantek: making a UI that fills the whole viewport, making a dialog whose contents fill the dialog
- # [01:10] <tantek> cc: TabAtkins
- # [01:10] <ojan> tantek: but the flexbox itself needs to fill it's container
- # [01:11] <tantek> ojan, hmm, maybe position:absolute;left:0;top:0;right:0;bottom:0;height:auto;width:auto ?
- # [01:12] * Quits: hober2 (ted@173.255.247.253) (Client exited)
- # [01:12] <ojan> tantek: yes, that works, but it's not at all intuitive and very few people learn to do it
- # [01:12] <tantek> yeah, it's copy-pasteo
- # [01:13] <tantek> but that should avoid the "you have to set height explicitly all the way down" thing right?
- # [01:13] * Joins: hober (ted@63.145.238.4)
- # [01:14] <ojan> tantek: that also doesn't let you do non 100% sizes...whcih i realize i didn't list as a use-case just now...but is totally valid
- # [01:14] <ojan> tantek: e.g. if you want a split-pane view
- # [01:15] <tantek> left:0;right:50%; … left:50%;right:0
- # [01:15] <ojan> tantek: how do you resolve the 50%?
- # [01:15] <ojan> oh
- # [01:15] <ojan> wait
- # [01:15] * Quits: plinss (plinss@63.145.238.4) (Ping timeout)
- # [01:15] <ojan> i'm confused
- # [01:15] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
- # [01:15] * Quits: karl (karlcow@128.30.54.58) (Ping timeout)
- # [01:15] <ojan> yeah...how do you resolve right:50%?
- # [01:15] <tantek> positions are inset from the respective edges
- # [01:15] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
- # [01:15] <ojan> isn't that the same problem?
- # [01:15] <ojan> 50% of what?
- # [01:15] <tantek> no it works like you want it
- # [01:16] <tantek> (AFAIK)
- # [01:16] * Quits: hober (ted@63.145.238.4) (Client exited)
- # [01:18] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
- # [01:18] <ojan> wth...i can't believe percentage for width/height is resolved totally differently from left/right
- # [01:18] <ojan> i mean...i just tested it in webkit and it worked
- # [01:18] <ojan> but wth
- # [01:19] <ojan> that's even more broken
- # [01:19] <ojan> works in gecko too
- # [01:19] <ojan> sigh
- # [01:20] <tantek> ahem
- # [01:20] <tantek> ojan, it's not totally broken
- # [01:21] <tantek> it's exactly what happens when we pursue a strategy like you were suggesting
- # [01:21] <tantek> to fix the situation
- # [01:21] <tantek> the latter technology "does the right thing"
- # [01:21] <tantek> improving on the legacy standards compat
- # [01:21] <ojan> oh i see...percentages work with position: absolute actually
- # [01:21] <ojan> so height: 50% works fine if it's position:absolute
- # [01:25] * Joins: ChrisL (ChrisL@128.30.52.169)
- # [01:27] * Quits: tcelik (tantek_@63.145.238.4) (Quit: tcelik)
- # [01:29] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
- # [01:30] * Quits: myakura (myakura@63.145.238.4) (Client exited)
- # [01:45] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
- # [01:45] * Joins: szilles (chatzilla@63.145.238.4)
- # [01:46] * Quits: Mike5 (Mike5@mcclure.w3.org) (Ping timeout)
- # [01:52] * Quits: dbaron (dbaron@63.145.238.4) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [01:56] * Joins: tantek (tantek@63.145.238.4)
- # [02:05] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
- # [02:05] * Joins: szilles (chatzilla@63.145.238.4)
- # [02:08] * Joins: myakura (myakura@209.131.48.67)
- # [02:09] * Quits: myakura (myakura@209.131.48.67) (Client exited)
- # [02:20] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
- # [02:36] * Joins: dino (dino@166.205.136.86)
- # [02:36] * Quits: dino (dino@166.205.136.86) (Client exited)
- # [02:38] * Joins: arronei_ (arronei@131.107.0.109)
- # [02:38] * Quits: arronei (arronei@131.107.0.117) (Ping timeout)
- # [02:39] * Joins: myakura (myakura@209.131.48.67)
- # [02:39] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
- # [02:46] * Joins: miketaylr (miketaylr@76.229.242.92)
- # [02:48] * Joins: bradk (bradk@99.7.175.117)
- # [03:14] * Quits: myakura (myakura@209.131.48.67) (Client exited)
- # [03:24] * Joins: hober (ted@174.143.153.77)
- # [03:34] * Quits: drublic (drublic@95.115.12.97) (Client exited)
- # [04:13] * Joins: myakura (myakura@209.131.48.67)
- # [04:16] * Quits: bradk (bradk@99.7.175.117) (Ping timeout)
- # [04:20] * Joins: bradk (bradk@99.7.175.117)
- # [04:21] * Quits: myakura (myakura@209.131.48.67) (Client exited)
- # [04:33] * Joins: myakura (myakura@209.119.68.98)
- # [04:35] * Joins: dsinger (dsinger@68.126.177.197)
- # [05:05] * Joins: tikimask (bensmithet@115.146.71.1)
- # [05:05] * tikimask is now known as bensmithett
- # [05:28] * Joins: plinss (plinss@63.145.238.4)
- # [05:32] * Quits: miketaylr (miketaylr@76.229.242.92) (Quit: miketaylr)
- # [05:34] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
- # [05:50] * Quits: bradk (bradk@99.7.175.117) (Quit: Computer has gone to sleep)
- # [06:05] * Quits: myakura (myakura@209.119.68.98) (Client exited)
- # [06:35] * Joins: tantek (tantek@70.36.139.219)
- # [06:38] * Joins: tcelik (tantek_@70.36.139.219)
- # [07:13] * Quits: bensmithett (bensmithet@115.146.71.1) (Quit: bensmithett)
- # [07:55] * Quits: tcelik (tantek_@70.36.139.219) (Quit: tcelik)
- # [08:27] * Quits: ChrisL (ChrisL@128.30.52.169) (Client exited)
- # [08:48] * Joins: plinss (plinss@63.145.238.4)
- # [09:16] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
- # [11:35] * RRSAgent excuses himself; his presence no longer seems to be needed
- # [11:35] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
- # [12:36] * Joins: drublic (drublic@77.2.154.153)
- # [14:50] * Joins: Ms2ger (Ms2ger@91.181.107.198)
- # [15:27] * Quits: tantek (tantek@70.36.139.219) (Quit: tantek)
- # [15:31] * Quits: dsinger (dsinger@68.126.177.197) (Quit: dsinger)
- # [15:42] * Joins: plinss (plinss@63.145.238.4)
- # [16:19] * Joins: stearns (anonymous@192.150.22.5)
- # [16:21] * Joins: bradk (bradk@99.7.175.117)
- # [16:22] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
- # [16:24] * Joins: Kai (chatzilla@63.145.238.4)
- # [16:24] * Quits: drublic (drublic@77.2.154.153) (Client exited)
- # [16:24] * Joins: karl (karlcow@128.30.54.58)
- # [16:28] * Joins: anne (annevk@63.145.238.4)
- # [16:45] * Joins: lgombos (Laszlo@63.145.238.4)
- # [16:53] * Joins: dsinger (dsinger@63.145.238.4)
- # [16:59] * Joins: plinss (plinss@63.145.238.4)
- # [16:59] * Parts: dsinger (dsinger@63.145.238.4)
- # [17:05] * Joins: szilles (chatzilla@63.145.238.4)
- # [17:06] * Joins: cyril (chatzilla@63.145.238.4)
- # [17:08] * Joins: Mike5 (Mike5@mcclure.w3.org)
- # [17:09] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
- # [17:10] * Joins: Rossen (Rossen@63.145.238.4)
- # [17:10] * Quits: bradk (bradk@99.7.175.117) (Quit: Computer has gone to sleep)
- # [17:11] * Joins: jdaggett_ (jdaggett@63.145.238.4)
- # [17:14] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Quit: leaving)
- # [17:14] * Joins: r12a (rishida@128.30.52.169)
- # [17:15] * Joins: bensmithett (bensmithet@115.146.71.1)
- # [17:19] * Joins: TabAtkins_ (tabatkins@208.54.86.218)
- # [17:28] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
- # [17:28] * Joins: lgombos (Laszlo@63.145.238.4)
- # [17:28] * Joins: gilles (gilles@63.145.238.4)
- # [17:29] * Quits: Kai (chatzilla@63.145.238.4) (Ping timeout)
- # [17:29] * Joins: Kai (chatzilla@63.145.238.4)
- # [17:29] * Quits: karl (karlcow@128.30.54.58) (Client exited)
- # [17:30] * Quits: anne (annevk@63.145.238.4) (Ping timeout)
- # [17:30] * Joins: karl (karlcow@128.30.54.58)
- # [17:32] * Joins: shepazu (shepazu@128.30.52.169)
- # [17:32] * Joins: dsinger (dsinger@63.145.238.4)
- # [17:33] * Quits: Ms2ger (Ms2ger@91.181.107.198) (Ping timeout)
- # [17:47] * Joins: anne (annevk@63.145.238.4)
- # [17:47] * Joins: Ms2ger (Ms2ger@157.193.12.138)
- # [17:54] * Joins: Ms2ger` (Ms2ger@91.181.107.198)
- # [17:56] * Quits: Ms2ger (Ms2ger@157.193.12.138) (Ping timeout)
- # [18:10] * Joins: ChrisL (ChrisL@128.30.52.169)
- # [18:28] * Joins: tantek (tantek@63.145.238.4)
- # [18:35] * Quits: gilles (gilles@63.145.238.4) (Quit: gilles)
- # [18:36] * Quits: Kai (chatzilla@63.145.238.4) (Ping timeout)
- # [18:36] * Quits: dsinger (dsinger@63.145.238.4) (Ping timeout)
- # [18:37] * Joins: dsinger (dsinger@63.145.238.4)
- # [18:37] * Quits: anne (annevk@63.145.238.4) (Ping timeout)
- # [18:37] * Quits: karl (karlcow@128.30.54.58) (Client exited)
- # [18:39] * Joins: karl (karlcow@128.30.54.58)
- # [18:39] * Joins: Kai (chatzilla@63.145.238.4)
- # [18:42] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
- # [18:45] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
- # [18:47] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
- # [18:49] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
- # [18:50] * Joins: r12a (rishida@128.30.52.169)
- # [18:52] * Quits: r12a (rishida@128.30.52.169) (Client exited)
- # [18:53] * Joins: r12a (rishida@128.30.52.169)
- # [18:54] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
- # [18:56] * Joins: r12a (rishida@128.30.52.169)
- # [19:08] * Joins: gilles (gilles@63.145.238.4)
- # [19:11] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
- # [19:12] * Joins: r12a (rishida@128.30.52.169)
- # [19:13] * Joins: jdaggett_ (jdaggett@63.145.238.4)
- # [19:16] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
- # [19:17] * Joins: szilles (chatzilla@63.145.238.4)
- # [19:21] * Joins: tcelik (tantek_@63.145.238.4)
- # [19:22] * tcelik is now known as tantek_
- # [19:23] * tantek_ is now known as tantek
- # [19:35] * Joins: Rossen (Rossen@63.145.238.4)
- # [19:46] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
- # [19:47] * Quits: tantek (tantek_@63.145.238.4) (Quit: tantek)
- # [19:49] * Joins: tantek (tantek@63.145.238.4)
- # [19:50] * Joins: r12a (rishida@128.30.52.169)
- # [19:55] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
- # [19:58] * Joins: dbaron (dbaron@63.145.238.4)
- # [19:59] * Joins: r12a (rishida@128.30.52.169)
- # [20:09] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
- # [20:11] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
- # [20:15] * Quits: gilles (gilles@63.145.238.4) (Ping timeout)
- # [20:21] * Joins: brianman_ (brianman@131.107.0.72)
- # [20:21] * Quits: brianman_ (brianman@131.107.0.72) (Quit: brianman_)
- # [20:21] * Quits: brianman (brianman@131.107.0.116) (Ping timeout)
- # [20:31] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
- # [20:33] * Joins: cyril (chatzilla@63.145.238.4)
- # [20:34] * Quits: shepazu (shepazu@128.30.52.169) (Ping timeout)
- # [20:34] * Quits: Mike5 (Mike5@mcclure.w3.org) (Ping timeout)
- # [20:34] * Joins: Mike5 (Mike5@mcclure.w3.org)
- # [20:37] * Joins: shepazu (shepazu@128.30.52.169)
- # [20:40] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
- # [20:42] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
- # [20:43] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
- # [20:44] * Joins: jdaggett_ (jdaggett@63.145.238.4)
- # [20:44] * Joins: r12a (rishida@128.30.52.169)
- # [20:44] * Quits: Kai (chatzilla@63.145.238.4) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238])
- # [20:44] * Quits: r12a (rishida@128.30.52.169) (Quit: r12a)
- # [20:44] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
- # [20:44] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
- # [20:47] * Joins: arno (arno@192.150.10.200)
- # [20:50] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
- # [20:51] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
- # [20:52] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
- # [20:53] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
- # [20:54] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
- # [20:55] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
- # [20:55] * Joins: cyril_ (chatzilla@63.145.238.4)
- # [20:56] * Quits: TabAtkins_ (tabatkins@208.54.86.218) (Ping timeout)
- # [20:57] * Quits: cyril (chatzilla@63.145.238.4) (Ping timeout)
- # [20:57] * cyril_ is now known as cyril
- # [21:04] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
- # [21:05] * Joins: szilles (chatzilla@63.145.238.4)
- # [21:07] * Joins: tantek (tantek@63.145.238.4)
- # [21:09] * Joins: Mike5 (Mike5@mcclure.w3.org)
- # [21:11] * Joins: arronei (arronei@131.107.0.91)
- # [21:17] * Joins: lgombos (Laszlo@63.145.238.4)
- # [21:24] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
- # [21:27] * Joins: szilles (chatzilla@63.145.238.4)
- # [21:32] * Quits: tantek (tantek@63.145.238.4) (Quit: tantek)
- # [21:36] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
- # [21:39] * Quits: TabAtkins_ (tabatkins@63.145.238.4) (Ping timeout)
- # [21:41] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
- # [21:41] * Joins: szilles (chatzilla@63.145.238.4)
- # [21:43] <fantasai> TabAtkins: I'm in the lunch rom, on a telecon. Let me know where we're meeting wrt gradients
- # [22:02] * Joins: shepazu (shepazu@128.30.52.169)
- # [22:05] * Joins: TabAtkins_ (tabatkins@63.145.238.4)
- # [22:06] * Joins: vhardy (vhardy@192.150.10.201)
- # [22:07] * Joins: Rossen (Rossen@63.145.238.4)
- # [22:07] * Joins: r12a (rishida@128.30.52.169)
- # [22:10] * Joins: ChrisL (ChrisL@128.30.52.169)
- # [22:10] * Joins: BradK (bradk@166.147.67.205)
- # [22:10] <BradK> Hello?
- # [22:10] <fantasai> still figuring out the skype thing
- # [22:11] <BradK> Me too, I guess. I seem to call and then get disconnected right away.
- # [22:11] <BradK> Or maybe I am just the only one there
- # [22:11] <BradK> Hard to tell
- # [22:12] * Joins: brianman (brianman@131.107.0.72)
- # [22:14] <fantasai> brianman: you're singed into skype, if I call you can you pick up?
- # [22:14] <brianman> That machine doesn't like the mic so it's useless.
- # [22:14] <fantasai> ok
- # [22:14] <fantasai> well, you can listen and I can minute and you can type?
- # [22:14] <brianman> We could try that I suppose.
- # [22:15] <brianman> Ring me again.
- # [22:16] * Joins: dsinger (dsinger@63.145.238.4)
- # [22:17] <brianman> Lots of feedback.
- # [22:17] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
- # [22:18] <brianman> I hear Elika and Brad.
- # [22:19] * Joins: Mike5 (Mike5@mcclure.w3.org)
- # [22:19] * Joins: Kai (chatzilla@63.145.238.4)
- # [22:20] <brianman> Shall we start with David's as Proposal 1?
- # [22:20] <fantasai> yes, we'll start with dbaron's proposal
- # [22:21] <TabAtkins_> brianman: You on the skypes?
- # [22:21] <brianman> Correct, I can hear but mic busted up.
- # [22:21] <TabAtkins_> brianman: kk
- # [22:21] * Joins: jdaggett_ (jdaggett@63.145.238.4)
- # [22:21] <fantasai> http://dev.w3.org/csswg/css3-images/#radial-gradients
- # [22:21] <TabAtkins_> r-g(<shape> to <extent> at <position>, <color-stop>#)
- # [22:22] <TabAtkins_> (1) r-g(<shape> to <extent> at <position>, <color-stop>#)
- # [22:23] <TabAtkins_> (2) r-g(<shape> to <extent> from <position>, <color-stop>#)
- # [22:23] * Joins: dbaron (dbaron@63.145.238.4)
- # [22:23] <fantasai> Any other proposals we care about?
- # [22:23] * dbaron RRSAgent, pointer?
- # [22:23] <fantasai> brianman, BradK ?
- # [22:23] <brianman> Prefer 1
- # [22:24] <fantasai> Asking first whether there's others we care about
- # [22:24] <brianman> "From" suggests color is radiating from the point, when it's not for the offset case.
- # [22:24] <fantasai> should be
- # [22:24] <fantasai> hang on
- # [22:24] <brianman> aye, holding
- # [22:24] <BradK> Don't know what's happening with my Skype
- # [22:24] <fantasai> dbaron: Question, should order of position and size matter?
- # [22:24] <arronei> I prefer 1
- # [22:24] <fantasai> tab, fantasai: no, either way is fine
- # [22:25] <fantasai> any objections to order flexibility?
- # [22:25] <TabAtkins_> tab: Specifically, the order of the clauses is arbitrary from an english and logical standpoint, so having to remember a "correct" order is annoying
- # [22:25] <BradK> Argh.
- # [22:25] <brianman> (3) r-g(<shape> [ [to <extent>] || [at <position>] ]? , <color-stop-list> )
- # [22:25] <fantasai> what's three?
- # [22:25] <fantasai> how's it different?
- # [22:25] <brianman> Skype just disconnected for me :(
- # [22:26] <fantasai> I just hung up
- # [22:26] <fantasai> too many technical problems
- # [22:26] <fantasai> we'll IRC
- # [22:26] <brianman> (3) is "order doesn't matter" captured in grammar
- # [22:26] * Joins: plinss (plinss@63.145.238.4)
- # [22:26] <fantasai> Let's not add that to the list, please
- # [22:26] <fantasai> let's just iterate
- # [22:26] <arronei> could we use the bridge that we use for telecons?
- # [22:26] <brianman> (3) = 1prime then
- # [22:26] * Quits: jdaggett_ (jdaggett@63.145.238.4) (Quit: jdaggett_)
- # [22:26] <fantasai> I have no idea how to set it up
- # [22:26] * Joins: Zakim (rrs-bridgg@128.30.52.169)
- # [22:26] <fantasai> I want to deal with the issues one by one, not make a gian list of proposals
- # [22:26] <plinss> zakim, room for 4?
- # [22:26] <Zakim> ok, plinss; conference Team_(css)21:21Z scheduled with code 26634 (CONF4) for 60 minutes until 2221Z
- # [22:26] <BradK> OK. Skype seems to kind of suck.
- # [22:26] <TabAtkins_> plinss: Thanks!
- # [22:27] <plinss> :-)
- # [22:27] <fantasai> ok, I"m going to call us in
- # [22:28] <Zakim> Team_(css)21:21Z has now started
- # [22:28] <fantasai> hang on, interruptd
- # [22:28] <brianman> While Elika is doing that...
- # [22:28] <brianman> Tab - <shape> has to come first or can be reordered also? IYO?
- # [22:28] <fantasai> perils of sittin gin the hallway
- # [22:29] <TabAtkins_> brianman: Come first. *That* is pretty much required by english standards, I think.
- # [22:29] <brianman> k, good. I was trying to capture that in (3)
- # [22:29] <fantasai> BradK: Going to call into zakim
- # [22:30] <TabAtkins_> brianman: Best capture is r-g([<shape> && [ [to <extent>] || [at <position>] ], ]? <color-stop>#)
- # [22:30] <BradK> I think I am on Zakim now
- # [22:30] <BradK> Zakim, who is here
- # [22:30] <Zakim> BradK, you need to end that query with '?'
- # [22:30] <brianman> You need another ? on that Tab
- # [22:30] <brianman> for the to/at bracket
- # [22:30] <fantasai> we're on zakim
- # [22:31] <TabAtkins_> brianman:
- # [22:31] <TabAtkins_> brianman: Don't think so.
- # [22:31] <BradK> Zakim, who is here?
- # [22:31] <Zakim> On the phone I see no one
- # [22:31] <Zakim> On IRC I see plinss, dbaron, Kai, Mike5, dsinger, brianman, BradK, ChrisL, r12a, Rossen, vhardy, TabAtkins_, shepazu, szilles, lgombos, arronei, cyril, arno, Ms2ger`, bensmithett,
- # [22:31] <Zakim> ... stearns, hober, arronei_, ojan, danielfilho, dholbert, trackbot, Hixie, lhnz, dglazkov, jdaggett, CSSWG_LogBot, krijnh, gsnedders, TabAtkins, pjrm, Bert, fantasai, ed
- # [22:31] * Ms2ger` waves
- # [22:31] * fantasai waves back
- # [22:31] <TabAtkins_> brianman: && means I can ignore either one.
- # [22:31] <brianman> r-g(<shape>, red, blue) is rejected by your syntax I thought.
- # [22:31] <TabAtkins_> brianman: Nope, it works.
- # [22:32] <brianman> && is optional but same order, || is optional but diff order?
- # [22:32] <fantasai> Let's not worry about getting the grammar right
- # [22:32] <brianman> I keep forgetting.
- # [22:32] <fantasai> we'll figure it out later
- # [22:32] <TabAtkins_> brianman: Yes.
- # [22:32] <brianman> k
- # [22:32] <fantasai> that's a programming problem, not an actual problem
- # [22:32] <brianman> Key point - shape has to come first if present?
- # [22:32] <fantasai> IssueOk, I'm chairing this.
- # [22:32] <fantasai> ISSUE 1
- # [22:32] <fantasai> Is the order of position and size flexible?
- # [22:32] <fantasai> Tab and I vote yes.
- # [22:32] <brianman> Relative to each other?
- # [22:33] <fantasai> yeah
- # [22:33] <fantasai> any other opinions?
- # [22:33] <TabAtkins_> Specifically, I vote that shape comes first, and te rest of the options are flexible order.
- # [22:33] <brianman> I'm fine with that; slower parse but that's ok.
- # [22:33] <fantasai> bradk: you ok with that?
- # [22:34] <BradK> I am
- # [22:34] <arronei> shape first others can switch order is fine with me
- # [22:34] <brianman> ...and colors must be last
- # [22:35] <TabAtkins_> RESOLVED: shape first, other options in any order, colors last
- # [22:35] <arronei> yes I agrre
- # [22:35] <fantasai> ISSUE 2
- # [22:35] <fantasai> 'from' vs 'at'
- # [22:35] <arronei> I vote 'at'
- # [22:35] <brianman> commentary: from is wrong for offset case in CSS27
- # [22:35] <BradK> I prefer from and to
- # [22:35] <fantasai> I think for this issue, we need to think about the offset radials
- # [22:35] <fantasai> and figure out what syntax we want for that
- # [22:35] <TabAtkins_> Whatever makes the most sense with 'offset' or something similar for Images 4 is what I want.
- # [22:35] <brianman> I prefer at because it's describing the location of the ellipse.
- # [22:35] <fantasai> So the thing about offset is that it'll have to be relative to the center
- # [22:36] <fantasai> because that's what offset implies
- # [22:36] <brianman> correct
- # [22:36] <fantasai> If we want to allow arbitrary positioning of the focus
- # [22:36] <fantasai> then we should not use 'offset'
- # [22:36] <brianman> <shape> AT <position> OFFSET <size>
- # [22:36] <TabAtkins_> Also, consider fantasai's recent proposal to drop 'cover' and 'contain', and make them size the ellipse from the center later.
- # [22:36] <brianman> <size>t describes the offset of the focal point from the <position>
- # [22:36] <fantasai> My preference is to have one argument give the position of the center and one to give the position of the focus
- # [22:36] <fantasai> independently
- # [22:37] <fantasai> E.g.
- # [22:37] <BradK> A keyword can determine if the bgpos is for offsetting just the center,, or the whole ellipse
- # [22:37] <fantasai> r-d(circle at center from 25% 25%, ...)
- # [22:37] <TabAtkins_> I would prefer less relativity as well. Relative offsets are useful for some things, but otherwise make it trickier to think about.
- # [22:37] <fantasai> that would give a centered ellipse with a focus at 25% 25%
- # [22:38] <TabAtkins_> I think I like that.
- # [22:38] <brianman> Question
- # [22:38] <fantasai> if either center or focus is missing, it defaults to the other
- # [22:38] <BradK> Asym from a to b
- # [22:38] <fantasai> yeah?
- # [22:38] * Quits: danielfilho (dcosta@187.31.77.7) (Ping timeout)
- # [22:38] <brianman> What if 25% 25% is outside the ellipse?
- # [22:38] * Joins: dcosta (dcosta@187.31.77.7)
- # [22:38] <TabAtkins_> brianman: Do what SVG does, and find the cloest point on the ellipse
- # [22:38] <brianman> Like previously discussed, ok.
- # [22:38] <brianman> Still tricky but ok.
- # [22:38] <TabAtkins_> It's not difficult geometry.
- # [22:38] <brianman> (curve / line intersection)
- # [22:38] <brianman> It's easy to calc and code. Hard for authors.
- # [22:39] <TabAtkins_> I forget how to do it, but I've done it in canvas before.
- # [22:39] <TabAtkins_> brianman: Yeah.
- # [22:39] <brianman> Elika/Tab fine with that clamping?
- # [22:39] <fantasai> You have the same problem with offset, it's not unique to syntax
- # [22:39] <fantasai> yep
- # [22:39] <brianman> Elika/Brad*
- # [22:39] <brianman> Offset has the same problem but less likely to hit authors.
- # [22:39] <brianman> because you can visually inspect the offset is within the explicit radii
- # [22:39] <brianman> for the explicit case
- # [22:40] <brianman> (Not a huge issue, just calling it out.)
- # [22:40] <TabAtkins_> brianman: We could always offer both 'from' and 'offset', making them mutually exclusive.
- # [22:40] <brianman> Elika doesn't like aliases.
- # [22:40] <brianman> :P
- # [22:41] <fantasai> bradk: What's the downside of haiving it outside the elipse?
- # [22:41] <fantasai> er, that was minuting
- # [22:41] <fantasai> bradk asked that question
- # [22:41] <fantasai> tab is answering...
- # [22:41] <brianman> The desired rendering is -a- inconsistent across libraries -b- conical
- # [22:41] <fantasai> brianman: It's not an alias, it would be a ifferent computatation
- # [22:41] <fantasai> brianman: I'm fine with having both options :)
- # [22:41] <TabAtkins_> BradK: Outside of the ellipse isn't well-defined. It depends on the details of how you're doing it.
- # [22:41] <brianman> point noted on offset vs. from
- # [22:42] <TabAtkins_> And as brianman says, it's inconsistently rendered.
- # [22:42] <fantasai> bradk says he's ok with clamping
- # [22:42] <BradK> Ok with clamping
- # [22:42] <TabAtkins_> But really, parity with SVG is what I'd going for.
- # [22:42] <fantasai> RESOLVED: use clamping just like SVG for focus outside ellipse cases
- # [22:42] <brianman> [SVG alignment - That's a bonus and a simplifier, yes]
- # [22:42] <fantasai> back to syntax...
- # [22:42] <brianman> wait.
- # [22:42] <brianman> Question
- # [22:42] <TabAtkins_> It seems like using 'at' for now is most readable, when combined with 'from' or 'offset' later.
- # [22:42] <TabAtkins_> brianman: Yo.
- # [22:42] <brianman> clamping and offset/location-of-focus -- css4?
- # [22:43] <TabAtkins_> Yeah.
- # [22:43] <brianman> k
- # [22:43] <fantasai> or you can use 'from' now and add 'at' later -- they'll map later
- # [22:43] <brianman> oh I think what you're saying...
- # [22:43] <brianman> today if you say from or at...they behave the same; later they don't
- # [22:43] <brianman> hmm
- # [22:43] <arronei> i would prefer that we just use 'at'
- # [22:43] <fantasai> bradk says "Seems early to resolve on calamping now'
- # [22:43] <TabAtkins_> I think it's clearer to use 'at' now, as the sizing keywords apply to that.
- # [22:43] <brianman> agree with arron, it paves the way
- # [22:43] <fantasai> fantasai: Just resolving within the context of this discussion
- # [22:44] <arronei> clamping is fine if its css4
- # [22:44] <fantasai> brianman, no saying we pick whichever of 'from' or 'at' is most readable
- # [22:44] <brianman> concur, brad, let's vette that with CSS4; we were just going for collective mental closure
- # [22:44] <fantasai> brianman, and then when we add the other keyword late,r that lets the focus and center be different
- # [22:44] <brianman> @elika - I meant that's why from/at language isn't a problem.
- # [22:44] <brianman> pre-css4
- # [22:44] <stearns> I think we should use 'intersection-of-major-and-minor-axes' instead of 'at'
- # [22:44] <brianman> but yes, let's pick 1...i prefer at
- # [22:44] <TabAtkins_> stearns: Good idea.
- # [22:45] <BradK> What is wrong with from and to?
- # [22:45] <fantasai> I prefer 'from' :)
- # [22:45] <TabAtkins_> BradK: to is for the sizing.
- # [22:45] <arronei> so can we list out the options. Just so I am clear
- # [22:45] <brianman> Tab do it :P
- # [22:45] <fantasai> hang on
- # [22:45] <BradK> It is easy to remember from and to, especially with 'to' being in linear g
- # [22:45] <fantasai> I think we all seem to agree that for CSS4 we want 'from' to be the focus and 'at' to be the center
- # [22:45] <brianman> yes
- # [22:45] <TabAtkins_> And I think we want 'to' to be the extent.
- # [22:46] <fantasai> ok, so that's resolved for now
- # [22:46] <brianman> fantasai - can you repeat the css3 resolve
- # [22:46] <fantasai> none yet
- # [22:46] <brianman> ah, that's a css4 tentative resolve? got it.
- # [22:46] <TabAtkins_> r-g(<shape> to <extent> at <shape-center>)
- # [22:46] <BradK> From can be focus and be center. Another keyword chooses which
- # [22:46] <fantasai> but we have a resolve on css4
- # [22:46] * Joins: gilles (gilles@144.189.101.1)
- # [22:46] <TabAtkins_> BradK: Right, at the moment both focus and shape-center are identical.
- # [22:46] <brianman> that was my point above
- # [22:47] <fantasai> (1) 'at' for focus/center in CSS3
- # [22:47] <fantasai> (2) 'from' for focus/center in CSS3
- # [22:47] <TabAtkins_> BradK: But I think that, since the sizing keywords base off of shape-center, we should use the shape-center word now.
- # [22:47] <TabAtkins_> And then add the focus keyword later.
- # [22:47] <fantasai> ooh, interesting point
- # [22:47] <brianman> Tab, use @ for talking to. and : for minuting. :P
- # [22:47] <TabAtkins_> So we can decide which is which today.
- # [22:47] <TabAtkins_> brianman: Will do.
- # [22:48] <brianman> Concur on the assessment in the long shape-center sentence.
- # [22:48] <TabAtkins_> fantasai: (minuted) When we do focus/center different, will the sizing keywords base off of the focus or the center?
- # [22:48] <brianman> It matches the way I was thinking about it, just unstated til now.
- # [22:48] <BradK> r-g(assym? <shape> from <extent> to <0%-center>)
- # [22:49] <fantasai> So...
- # [22:49] <fantasai> you size from the center of the ellipse
- # [22:49] <brianman> the shape-center
- # [22:49] <brianman> not the focus-center
- # [22:49] <brianman> correct?
- # [22:49] <TabAtkins_> Yes.
- # [22:49] <TabAtkins_> focus is a point, not a center. ^_^
- # [22:49] <BradK> BradK: r-g(assym? <shape> to <extent> from <0%-center>)
- # [22:49] <brianman> assertion: focus-center and it's keyword are CSS4 only
- # [22:49] <fantasai> but do you pick the closest/farthest-corner/side based on the focus or the center?
- # [22:50] * fantasai doesn't like the assym keyword
- # [22:50] <brianman> based on the shape-center
- # [22:50] <brianman> imo
- # [22:50] <TabAtkins_> @brian: Yes.
- # [22:50] <fantasai> I'm not so sure
- # [22:50] <fantasai> I think if I wanted the focus in the upper right
- # [22:50] <brianman> In D2D, it's off the shape center.
- # [22:50] <fantasai> ...
- # [22:50] <fantasai> I don't know
- # [22:50] <brianman> I have trouble understanding shape deriving from focus center.
- # [22:50] <BradK> Asym or whatever as placeholder for now
- # [22:50] <brianman> ...would even look like.
- # [22:50] <TabAtkins_> @brian Me too.
- # [22:51] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
- # [22:51] <brianman> Let me try an example...
- # [22:51] <TabAtkins_> @brad I'm not sure what assym does.
- # [22:51] <fantasai> bradk says "you're picking whether you want to move the whole ellipse or the focus of the ellipse"
- # [22:52] <fantasai> brad "assym would make you move the focus without moving the ellipse
- # [22:52] <TabAtkins_> @Brad: Does that mean you always center the ellipse in the box?
- # [22:52] <arronei> this seems like a bigger change than what we agreed to talk about
- # [22:52] <brianman> width: 200px; height 100px; r-g(circle at 25px 25px offset 5px 5px, red, blue 100%, transparent);
- # [22:52] <TabAtkins_> When it's assym, that is.
- # [22:52] <brianman> ^ example 1
- # [22:53] <BradK> Yes, for asymmetrical offsets in Css4
- # [22:53] <TabAtkins_> I think we might be able to do from/to now, and then use 'focus' and 'offset' for absolute/relative positionin gof the focus later.
- # [22:53] <TabAtkins_> @Brad That makes it hard to do some good patterns you can do now that would be better with an offset focus.
- # [22:54] <brianman> what's <0%-center> ?
- # [22:54] <brianman> That part of the semi-grammmar confuses me.
- # [22:54] <brianman> grammar*
- # [22:54] <BradK> It's an edge case anyway to begin with
- # [22:54] <TabAtkins_> @Brian He means focus.
- # [22:54] <brianman> My understanding of offset focus is that you drag the color center within the shape, the shape doesn't move.
- # [22:55] <TabAtkins_> @Brad If you just omit 'from' you'd get a centered shape anyway. It's useful and current gradient engines can do it.
- # [22:55] <brianman> Brad/Elika - Are you thinking of it as a different thing?
- # [22:55] <TabAtkins_> brianman: No, that's right.
- # [22:55] <BradK> It is where the 0% color stop would be in both cases
- # [22:55] * fantasai is still trying to wrap her head around sizing keywords with offset radials
- # [22:55] <TabAtkins_> So, my current thought: 'to' is for offsets. 'from' is for shape-center. We define these in level 3.
- # [22:55] <TabAtkins_> In level 4 we define 'focus' and 'offset' for absolute and relative focus positioning.
- # [22:55] <brianman> I still am bothered by from.
- # [22:56] <brianman> To me "from" means "where the color starts"
- # [22:56] <brianman> not "where the shape is centered"
- # [22:56] <TabAtkins_> brianman: That's kind of my objection to, but I'm not sure.
- # [22:56] <fantasai> yeah, the problem is... we are using 'to' to describe the size
- # [22:56] <TabAtkins_> Dammit, I can't get used to using @ for mentioning.
- # [22:56] * stearns agrees with brianman
- # [22:56] <fantasai> or rather the extent
- # [22:56] <BradK> Me too, and that aligns with the way I am considering focus
- # [22:56] <fantasai> so you're thinking "from the center to the extent" to size the gradient
- # [22:57] <fantasai> but I agree, I also think of that as eing the color originating point
- # [22:57] <BradK> Keep the number of numbers to a minimum, and just use a keyword to say what center it applies to
- # [22:57] <TabAtkins_> BradK: Behavior switches are bad - they're hard/impossible to transition.
- # [22:57] * Quits: Ms2ger` (Ms2ger@91.181.107.198) (Quit: nn)
- # [22:58] <brianman> (4) r-g(1 3 4 5 7, red, blue)
- # [22:58] <brianman> just kidding
- # [22:58] <TabAtkins_> brianman: SHIP IT
- # [22:58] <TabAtkins_> [elika and brad are chatting]
- # [22:59] <brianman> I give 3:1 odds on Elika.
- # [23:00] <stearns> for some reason, using 'at' to describe the center of the shape with an offset to where the colors start from seems more clear to me than using 'from' to describe the center
- # [23:01] <fantasai> I agree
- # [23:01] * Joins: dsinger (dsinger@63.145.238.4)
- # [23:01] <fantasai> my concern is how 'farthest-corner' is determined
- # [23:01] <fantasai> how do you pick that corner? is it the farthest from the focus or the center?
- # [23:02] <brianman> wait
- # [23:02] <brianman> Are we resolved on 2 - use at?
- # [23:02] <TabAtkins_> Always size relative to the shape-center.
- # [23:02] <fantasai> no
- # [23:02] <brianman> can we focus on 2 before we get into <extent> keywords?
- # [23:02] <fantasai> I'm talking about 2
- # [23:02] <fantasai> we have to think about what
- # [23:03] <brianman> ah, k
- # [23:03] <fantasai> r-d(from 25% 25% to farthest-corner) means
- # [23:03] <fantasai> once you have the split of focus and center
- # [23:03] * Quits: gilles (gilles@144.189.101.1) (Quit: gilles)
- # [23:03] <brianman> it means the ellipse meets the bottom right
- # [23:03] * Quits: vhardy (vhardy@192.150.10.201) (Ping timeout)
- # [23:03] <fantasai> r-do(from 25% 25% offset 50% 50% to farthest-corner)
- # [23:03] <brianman> if you use "at" instead of "from"
- # [23:03] <fantasai> vs
- # [23:03] <fantasai> r-do(at 25% 25% offset 50% 50% to farthest-corner)
- # [23:03] <fantasai> ?
- # [23:03] <brianman> The latter makes sense
- # [23:03] <fantasai> oh
- # [23:03] <fantasai> another question
- # [23:04] <brianman> The former confuses me
- # [23:04] <fantasai> what's being offset, the focus or the center?
- # [23:04] <fantasai> if we use offset
- # [23:04] <TabAtkins_> The focus!
- # [23:04] <BradK> From and to could describe the color stops (0 and 100%), while a
- # [23:04] <brianman> wait...
- # [23:04] <brianman> offset is a way of setting focal-origin relative shape-center
- # [23:04] <BradK> 'at' describes the focus
- # [23:04] <TabAtkins_> @Brad Wait. 0% color *is* the focus. I'm confused now.
- # [23:04] <BradK> Ya...
- # [23:05] <fantasai> or is offset a way of setting shape center relative to focal origin?
- # [23:05] <BradK> I got that wrong
- # [23:05] <fantasai> could go either way
- # [23:05] <fantasai> have to figure out which makes more sense
- # [23:05] <brianman> "or is"...no
- # [23:05] <brianman> that's craziness
- # [23:05] <BradK> Right now the focus is the center, right?
- # [23:05] <TabAtkins_> @fantasai: it makes the most sense to, for level 3, position and size the shape.
- # [23:05] <brianman> you have to build things in a bizarre order that way, E
- # [23:05] <fantasai> yeah, they're equivalent right now
- # [23:05] <TabAtkins_> @fantasai: Then you move the focus in level 4. That's all it does.
- # [23:05] <brianman> I would say it another way...
- # [23:06] <fantasai> the question gets trickier when you use lengths
- # [23:06] <brianman> in CSS3 the offset is hardcoded to 0px 0px
- # [23:06] <fantasai> or percentages beyond 100%
- # [23:06] <TabAtkins_> @Brian: Yeah, basically.
- # [23:06] <brianman> (and that should be the initial value in CSS4)
- # [23:06] <fantasai> so
- # [23:06] <fantasai> if I have
- # [23:07] <fantasai> radial-gradient(from/at 25% 25% to cover)
- # [23:07] <brianman> Tab, should we just start coding -vendor-radial-gradient for CSS4 while Elika and Brad figure this out? ;)
- # [23:07] <fantasai> would like it to be offset radial that covers the box
- # [23:07] <fantasai> focused at 25% 25%
- # [23:07] <brianman> you can't do that
- # [23:07] <TabAtkins_> @fantasai: then you want r-g(from/at center focus 25% 25% to cover
- # [23:07] <fantasai> from makes mjore sense there ..
- # [23:07] <brianman> in css3 feature set
- # [23:07] <fantasai> brianman: no, agreed
- # [23:08] <fantasai> we have duplicate keywords
- # [23:08] <fantasai> we should drop cover/contain
- # [23:08] <brianman> @Tab - that's about right
- # [23:08] <BradK> radial-gradient(at 25% 25% to cover) means you are moving the focus, radial-gradient(from 25% 25% to cover) means you are moving the center and resizing the ellipse
- # [23:09] <fantasai> yeah!
- # [23:09] <brianman> Disagree.
- # [23:09] <fantasai> er
- # [23:09] <fantasai> otherway around
- # [23:09] <brianman> Brad, add these color stops...
- # [23:09] <brianman> red, blue 100%, transparent
- # [23:09] <brianman> and change to contain
- # [23:09] <brianman> and observe the no-paint regions
- # [23:10] <TabAtkins_> I think the focus-moving keywords should *definitely* be 'focus'/'offset'. They need to be *unambiguous*.
- # [23:10] <brianman> Yah, that avoids any ambiguity.
- # [23:10] <brianman> should we replace from/at with another non-ambiguous keyword?
- # [23:10] <TabAtkins_> alan had one.
- # [23:10] <fantasai> target
- # [23:11] <BradK> OK, that allows us to still use to and from then
- # [23:11] <brianman> Disagree.
- # [23:11] <brianman> from = where the first color is placed
- # [23:11] <fantasai> no, that's weird too
- # [23:11] <brianman> and thus it's wrong for CSS4 offset/focus cases
- # [23:11] <fantasai> um
- # [23:11] <fantasai> ok
- # [23:11] <TabAtkins_> I wish we could use 'center'. :/
- # [23:12] <fantasai> hehehehe
- # [23:12] <brianman> question
- # [23:12] <fantasai> Ok, from is where the color originates
- # [23:12] <brianman> ... position <position>
- # [23:12] <fantasai> then..
- # [23:12] * arronei we could use bikeshed
- # [23:12] <TabAtkins_> Ah, hm. position might be good
- # [23:12] * stearns objects to bikeshed
- # [23:12] <BradK> 'at' just sounds weird, compared to to and from
- # [23:12] <fantasai> 'to farthest-corner' picks which corner?
- # [23:12] <BradK> Weird in context
- # [23:12] <TabAtkins_> brad: I kind of agree.
- # [23:12] * brianman -ms-bikeshed
- # [23:12] <fantasai> that's really where I'm stuck on
- # [23:13] * stearns says if you look at the original documents, the term was bicycleshed
- # [23:13] <TabAtkins_> Better explanation of elika's question:
- # [23:13] <brianman> elaborate, i'm unclear on what you're stuck on
- # [23:13] * Quits: lgombos (Laszlo@63.145.238.4) (Ping timeout)
- # [23:13] <brianman> ok, Tab is doing that...
- # [23:13] <BradK> Hyphen between bike and shed, I think
- # [23:14] * stearns ooh ooh! how about 'centre'?
- # [23:14] <TabAtkins_> For the implicit keywords, should they *choose* the side/corner from the focus or the shape-center? (Once chosen, the actual size is calculated from the shape-center)
- # [23:14] <fantasai> yeah, that's what I meant!
- # [23:14] <fantasai> Ok
- # [23:14] <fantasai> so
- # [23:14] <fantasai> Straw Proposal:
- # [23:14] <brianman> wait..hold one
- # [23:14] <brianman> on
- # [23:14] <brianman> i can answer your question
- # [23:15] <brianman> Q: are the extents relative to the focus-center or the shape-center? A: if they are relative to the focus-center, then you have to use non-elliptical shapes.
- # [23:15] <fantasai> r-d(from <focus> to <size> at <center>) with <size>'s corner-picking keywords picking corners relative to <focus>
- # [23:15] <brianman> A2: it's shape-center relative
- # [23:15] <TabAtkins_> brianman: No, not the extent itself. The side/corner chosen for figuring the extent
- # [23:15] <brianman> that doesn't work
- # [23:15] <brianman> see A:
- # [23:15] <fantasai> and once the corner is picked, the size is computed from the center
- # [23:15] <fantasai> (shape center)
- # [23:16] <TabAtkins_> (But I think it should be always from the shape-center. If we want chosen from focus, we can add keywords.)
- # [23:16] <brianman> @Tab - concur
- # [23:16] <BradK> Agreed
- # [23:16] <brianman> focus-crazy-keywords @ css4
- # [23:16] <brianman> shape-center-keywords @ css3
- # [23:17] * brianman -ms-bike-shed-writing-mode-farthest-shopping-center
- # [23:17] <BradK> I have to get back to work, guys
- # [23:17] <BradK> Maybe continue later? Monday maybe?
- # [23:17] <fantasai> ok
- # [23:18] <fantasai> sure
- # [23:18] <brianman> did we resolve 2?
- # [23:18] <fantasai> let's all think about it
- # [23:18] <fantasai> nope
- # [23:18] <brianman> ... /cry
- # [23:18] <TabAtkins_> We resolved some other things.
- # [23:18] <TabAtkins_> I'll figure out what it was we resolved later. ^_^
- # [23:18] <brianman> yah, we wrote have of CSS5
- # [23:18] <arronei> do we at least have a list of ideas
- # [23:18] <brianman> half
- # [23:18] <arronei> that we can list out
- # [23:18] <fantasai> Tab and I will list them out
- # [23:18] <fantasai> we'll make a wiki page ^_^
- # [23:18] <brianman> question:
- # [23:18] <brianman> what is r-d?
- # [23:18] <fantasai> radial-gradient
- # [23:18] <fantasai> :)
- # [23:18] <BradK> Ok. See ya.
- # [23:19] <TabAtkins_> radial-dreidel
- # [23:19] <brianman> tuesday reconvene with Sylvain perhaps present?
- # [23:19] * Quits: Rossen (Rossen@63.145.238.4) (Ping timeout)
- # [23:19] <TabAtkins_> kk
- # [23:19] <Zakim> Team_(css)21:21Z has ended
- # [23:19] <Zakim> Attendees were
- # [23:19] <fantasai> and dbaron
- # [23:20] * Quits: dsinger (dsinger@63.145.238.4) (Quit: dsinger)
- # [23:20] <brianman> Tab, can you list out a set of proposed resolutions on the wiki
- # [23:20] <brianman> as a headstart before next discussion
- # [23:20] <TabAtkins_> Yup
- # [23:20] <brianman> assertions may be a better word
- # [23:21] <brianman> One more note before you leave...
- # [23:21] <TabAtkins_> yeah?
- # [23:21] <brianman> Elika, I think your focus-sensitive keyword idea is a better reason to remove cover/contain than your email
- # [23:21] <brianman> reserving cover/contain to me a strict paint coverage concept
- # [23:21] <brianman> mean*
- # [23:22] <fantasai> yeah
- # [23:22] <brianman> whereas close/far are shape-related keywords and time-tested for css3 already
- # [23:22] <brianman> imo
- # [23:23] <arronei> what's the link to the wiki again for all of this r-g() stuff
- # [23:23] <fantasai> they'll mean the same thing in css4
- # [23:23] <fantasai> we're not changing what they mean in css3
- # [23:23] <fantasai> because focus and center are both the same thing in css3
- # [23:23] <fantasai> so nthat's not changing
- # [23:23] <fantasai> arronei: haven't create one yet, will do in a sec
- # [23:23] <fantasai> brianman: make sense?
- # [23:24] <brianman> did we resolve that "as" proposal is rejected, and stays ","?
- # [23:24] <fantasai> brianman: Question isn't about what they mean now, but what they will mean once the focus and center no longer coincide
- # [23:24] <brianman> yah, makes sense
- # [23:24] <fantasai> um
- # [23:24] <fantasai> I forgot to bring that up, but I think that's the direction we'll go in
- # [23:24] <TabAtkins_> My strong preference too
- # [23:24] <arronei> so , separates the color list?
- # [23:24] <brianman> Did our , precedence and formatting arguments convince you?
- # [23:24] <fantasai> dbaron convinced me
- # [23:24] <brianman> yes, it separates the color list and the colors within it
- # [23:24] * Quits: dbaron (dbaron@63.145.238.4) (Ping timeout)
- # [23:25] <arronei> ok that is what I want
- # [23:25] <fantasai> I think my proposal would be
- # [23:26] <fantasai> from <focus> to <size> at <center>
- # [23:26] <brianman> Your grammar above has to-size at-position... ship it ;)
- # [23:26] <fantasai> or
- # [23:26] <fantasai> from <focus> to <size> shift <offsets>
- # [23:26] <fantasai> that makes the colors go from "from" to "to"
- # [23:26] <fantasai> which is imo important
- # [23:26] <brianman> i don't like that one
- # [23:26] <brianman> from and shift/offset are exclusive imo
- # [23:26] <fantasai> and it shifts the result that you'd get otherwise
- # [23:27] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
- # [23:27] <brianman> at <position> - position drives the shape today, making the algorithm bounce that in CSS4 from CSS3's is trouble
- # [23:27] <fantasai> 'from' would pinpoint the focus, and 'shift' would calculate the center'
- # [23:27] <brianman> the bounding 100% shape i mean
- # [23:27] <brianman> yah, that's backwards imo
- # [23:27] <brianman> it's like "negative offset" kinda
- # [23:28] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
- # [23:28] <brianman> with a focal point, you're still filling the ellipse and the focal point is the calculated thing...not the ellipse center
- # [23:28] <brianman> doing it the opposite is, imo, confusing at best
- # [23:29] * Joins: Mike5 (Mike5@mcclure.w3.org)
- # [23:29] <fantasai> hmm
- # [23:30] <fantasai> you could also just use 'from' for both
- # [23:30] <brianman> that defeats the purpose of having the keywords...
- # [23:30] <brianman> (1) resolve ambiguity
- # [23:30] <brianman> (2) allow independent ordering
- # [23:30] <fantasai> if it doesn't specify a side, instead of defaulting to top left
- # [23:30] <fantasai> you default to the center position
- # [23:30] * Quits: szilles (chatzilla@63.145.238.4) (Ping timeout)
- # [23:31] <brianman> if you use the same keyword twice you're proving that it's not a specific enough keyword
- # [23:31] <fantasai> at <position> from -5px -5px would shift the focus from <position>
- # [23:31] * Joins: szilles (chatzilla@63.145.238.4)
- # [23:31] <brianman> disagree
- # [23:31] <fantasai> at <position> from left 5px top 5px would put the focus at that position in the box
- # [23:31] <brianman> in that form it should be an absolute location, not a relative one
- # [23:31] <brianman> rephrasing...
- # [23:31] <brianman> from <absolute-focal-position>
- # [23:32] <fantasai> if we used 'focus' instead of 'from', that would more obviously make sense :)
- # [23:32] <brianman> offset <of-focal-from-shape-position>
- # [23:32] <brianman> I'm fine with...
- # [23:32] <brianman> focus <position-absolute>
- # [23:32] <brianman> focus-offset <size-relative-to-shape-center>
- # [23:33] <brianman> Seeing that brings up another observation: offset is a size (1-2 fields), focus is a position (1-4).
- # [23:33] * Joins: drublic (drublic@77.2.154.153)
- # [23:34] <fantasai> combining both by defaulting the start position to the shape-center also let's you do different things in different dimensions
- # [23:34] <fantasai> not sure that's useful, but it becomes possible
- # [23:34] <brianman> "combining both"?
- # [23:34] <fantasai> <position> syntax has an implied start position
- # [23:34] <fantasai> in bgpos it defaults to the top left corner
- # [23:34] <fantasai> we could have it default to the shape-center
- # [23:35] <brianman> could have what default to shape-center?
- # [23:35] <fantasai> then you would do both relative offsets and absolute positioning with the same syntax
- # [23:35] <fantasai> could have the implied start position default to shape-center
- # [23:36] <brianman> "you could do ... absolute positioning with the same syntax"
- # [23:36] <brianman> ...no that would mean you're only using relative positioning
- # [23:36] <fantasai> no
- # [23:36] <brianman> elaborate
- # [23:36] <brianman> start with this...
- # [23:36] <brianman> <focal-params> =
- # [23:37] <brianman> (you fill in)
- # [23:37] <fantasai> <focal-params> = <position>
- # [23:38] <fantasai> from background-position
- # [23:38] <brianman> ok so...
- # [23:38] <fantasai> that allows each of horizontal and vertical position
- # [23:38] <brianman> "5px 5px" means what in that context?
- # [23:38] <fantasai> to be specified as a length/percentage, as a keyword, or as a pair
- # [23:38] <fantasai> when specified as a pair, it is offset from the keyword position
- # [23:38] <fantasai> when specified as a length/percentage, it is offset from the origin
- # [23:39] <fantasai> which for bgpos is the top left corner
- # [23:39] <fantasai> if we use the same syntax
- # [23:39] <brianman> yah, that's bad imo
- # [23:39] <fantasai> and define the origin as the shape-center
- # [23:39] <brianman> if thats how it behaves it shouldn't reuse <position> topic
- # [23:39] <brianman> token*
- # [23:39] <fantasai> then we can do both with that smae syntax
- # [23:39] <brianman> because it's totally differently used than in background with that interpretation
- # [23:39] <fantasai> I think it's perfectly reasonable. We're just defining a different default origin for the focus
- # [23:40] <brianman> no
- # [23:40] <brianman> you're defining "with one set of values, origin A" and "with another set of values, origin B"
- # [23:40] <brianman> which is chaotic at best
- # [23:41] <fantasai> no, I'm saying default origin is A
- # [23:41] <fantasai> so origin is A unless otherwise specified
- # [23:41] <brianman> a being....0,0 at shape-center?
- # [23:41] <fantasai> A being the shape center
- # [23:41] <fantasai> yes
- # [23:41] <brianman> that IS relative positioning
- # [23:41] <brianman> because it's not in box coord system
- # [23:41] <fantasai> that's the functionality you wanted in offset
- # [23:42] <brianman> = relative positioning
- # [23:42] <brianman> kind of
- # [23:42] <fantasai> k
- # [23:42] <brianman> but i wanted it to be a size not a position
- # [23:42] * Joins: gilles (gilles@144.189.101.1)
- # [23:42] <stearns> 'focus' is the center of the colors?
- # [23:42] <brianman> a position for an offset is weird/confusing
- # [23:42] <brianman> @stearns - concept yes, keywords still being discussed
- # [23:42] <fantasai> it's the same thing
- # [23:42] <fantasai> 5px 5px is an offset from the center
- # [23:42] <brianman> offset right 5px bottom 7px == bizarre
- # [23:43] <fantasai> you wouldn't use 'offset' there, obviously
- # [23:43] <brianman> why not?
- # [23:43] <fantasai> that would position the focus absolutely from the bottom right of the box
- # [23:43] <brianman> offset <position>
- # [23:43] <brianman> i'll reiterate: you're talking about "offset <size>" and not realizing it
- # [23:43] <fantasai> no, I"m not
- # [23:43] <brianman> so why would I "obviously" not use offset in the case above?
- # [23:44] <fantasai> I'm folding that into <position>
- # [23:44] <fantasai> the keyword 'offset' is weird when you are positioning absolutely by using keywords
- # [23:44] <fantasai> so you need a different keyword
- # [23:44] <brianman> I thought you were trying to say offset/focal can be one keyword
- # [23:44] <brianman> I guess I misunderstood you
- # [23:44] <fantasai> yes
- # [23:44] <fantasai> I was saying that :)
- # [23:45] * Quits: plinss (plinss@63.145.238.4) (Client exited)
- # [23:45] <brianman> <focal-params> = [focus <position> || focal-offset <size>]? <-- what I proposed above
- # [23:45] <fantasai> because by defining the default origin for <focal-position> to be the shape center, you get <position> to do both things
- # [23:45] <brianman> what does "focal-keyword right bottom" mean?
- # [23:46] * Joins: plinss (plinss@68.107.116.103)
- # [23:46] <fantasai> the focus is at the bottom right of the box
- # [23:46] <brianman> and "focal-keyword left top"?
- # [23:46] <fantasai> top left of the box
- # [23:46] <brianman> so how do you get relative positioning with that syntax?
- # [23:47] <fantasai> focal-keyword <length> <length>
- # [23:47] <fantasai> (or <percentage> instead of <length>)
- # [23:47] <brianman> so what does "focal-keyword left 0px top 0px" do?
- # [23:47] <fantasai> positions to the top left
- # [23:47] <fantasai> because you are not implying the origin of the lengths, you're stating them explicitly
- # [23:47] <brianman> so "focal-keyword left 0px top 0px" != "focal-keyword 0px 0px"?
- # [23:47] * Joins: lgombos (Laszlo@63.145.238.4)
- # [23:47] <fantasai> right
- # [23:47] <brianman> So it's not a <position>
- # [23:47] <fantasai> it is a <position>
- # [23:47] <brianman> no
- # [23:47] <fantasai> it's interpreted with a differnet defaultorigin
- # [23:48] <fantasai> the syntax is exactly the same
- # [23:48] <brianman> because you've pulled some of the variants inside <position> and given them a different origin
- # [23:48] <brianman> as such, you need to split position in two halves
- # [23:48] <brianman> position-when-used-in-bg and position-when-used-everywhere
- # [23:48] <fantasai> I've define a different DEFAULT
- # [23:48] <fantasai> I haven't changed anything else
- # [23:48] <brianman> position in radials should not include the left half of those two
- # [23:48] <dglazkov> what's the svg channel?
- # [23:48] <fantasai> #svg, isn't it?
- # [23:49] <dglazkov> yay
- # [23:49] * Joins: dbaron (dbaron@63.145.238.4)
- # [23:49] <brianman> So how do I say 2px right of the shape-center?
- # [23:50] <fantasai> focal-keyword 2px 0
- # [23:50] <brianman> and that behaves differently from...
- # [23:50] <brianman> focal-keyword left 2px top 0px?
- # [23:51] <fantasai> yes, because in that case you specified an explicit orign (top left) instead of relying on an implicit one
- # [23:52] <brianman> I interpret that as follows...
- # [23:52] * Quits: plinss (plinss@68.107.116.103) (Ping timeout)
- # [23:52] <brianman> 1. For some flavors of <position> you choose origin A and some you choose origin B.
- # [23:52] <brianman> or
- # [23:52] * Joins: plinss (plinss@63.145.238.4)
- # [23:52] * Quits: plinss (plinss@63.145.238.4) (Client exited)
- # [23:52] * Joins: plinss (plinss@68.107.116.103)
- # [23:52] <brianman> 2. For some flavors of <position>, they are not supported with focus-keyword.
- # [23:52] <brianman> Both are bad.
- # [23:52] * Joins: tantek (tantek@63.245.220.240)
- # [23:52] <fantasai> You're not making any sense
- # [23:53] * Quits: Mike5 (Mike5@mcclure.w3.org) (Quit: Mike5)
- # [23:53] <arronei> @fantasai: you are missing a point too.
- # [23:53] * Joins: plinss_ (plinss@68.107.116.103)
- # [23:53] <fantasai> arronei: what point?
- # [23:53] <arronei> I think we need to chat on the phone or in person to get the correct
- # [23:55] * Joins: plinss__ (plinss@63.145.238.4)
- # [23:55] <arronei> I am somewhat lost too but I think you are trying to define 2 different orgins with the positions depending on if they have keywords in them
- # [23:56] * Joins: Mike5 (Mike5@mcclure.w3.org)
- # [23:57] <fantasai> no, not doing that
- # [23:57] <fantasai> there's only one origin
- # [23:57] <fantasai> it's the shape-center
- # [23:57] * Quits: plinss (plinss@68.107.116.103) (Ping timeout)
- # [23:57] <brianman> let's try this again...
- # [23:57] <fantasai> but when you specify a keyword, you start fro m there
- # [23:57] <brianman> in the default state, the shape-center is where in a 200 x 200 box
- # [23:57] * plinss__ is now known as plinss
- # [23:57] <fantasai> if I specify bottom 2px left 5px
- # [23:58] <fantasai> the offsets there are relative to the bottom left
- # [23:58] <fantasai> not relative to the origin
- # [23:58] <fantasai> in bgpos the oriign is the top left corner
- # [23:58] <fantasai> but the position specifye that way is not related at all to the top left rcorner
- # [23:58] <fantasai> you are changing what the lengths are relative to
- # [23:58] <fantasai> by specifying the keywords
- # [23:58] <fantasai> same thing here
- # [23:59] <brianman> ok, let's try this from a computed value standpoint
- # [23:59] <fantasai> except the origin is the shape-center
- # [23:59] <brianman> what's the computed value of <position> = "left top"?
- # [23:59] <fantasai> that's a fair poin,t, in bgpos it's 0 0
- # [23:59] <brianman> so when you inherit it, your radial-gradient focal point moves
- # [23:59] <brianman> ?
- # Session Close: Sat Nov 05 00:00:00 2011
The end :)