/irc-logs / w3c / #css / 2010-11-02 / end

Options:

# Session Start: Tue Nov 02 00:00:00 2010
# Session Ident: #css
# [00:10] * Joins: plinss_ (plinss@212.180.75.100)
# [01:19] * Quits: plinss_ (plinss@212.180.75.100) (Ping timeout)
# [01:45] * Quits: TabAtkinsTPAC (chatzilla@212.180.75.100) (Ping timeout)
# [02:28] * RRSAgent excuses himself; his presence no longer seems to be needed
# [02:28] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
# [03:09] * Joins: arron (Arron@24.17.123.244)
# [04:55] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [05:17] * Joins: nimbupani (Adium@24.22.131.46)
# [05:39] * Quits: bradk (bradk@99.7.175.117) (Quit: Computer has gone to sleep)
# [05:53] * Joins: arron (Arron@24.17.123.244)
# [06:29] * Quits: nimbupani (Adium@24.22.131.46) (Quit: Leaving.)
# [06:43] * Disconnected
# [06:44] * Attempting to rejoin channel #css
# [06:44] * Rejoined channel #css
# [06:44] * Topic is 'CSS Working Group discussion'
# [06:44] * Set by fantasai on Sun Aug 01 23:49:50
# [07:25] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [07:33] * Joins: plinss_ (plinss@212.180.75.100)
# [07:34] * Joins: arron (Arron@24.17.123.244)
# [08:09] * Quits: plinss_ (plinss@212.180.75.100) (Quit: plinss_)
# [08:13] * Joins: kennyluck (kennyluck@128.30.52.28)
# [08:18] * Joins: TabAtkinsTPAC (chatzilla@212.180.75.100)
# [08:35] * Joins: mjs (mjs@84.14.50.82)
# [08:38] * Joins: mgylling (mgylling@84.14.50.82)
# [08:44] * Joins: dethbakin (dethbakin@84.14.50.82)
# [08:47] * Joins: mollydotcom (mollyh@68.225.52.230)
# [08:48] * Joins: freedom (freedom@84.14.50.82)
# [08:52] * Quits: freedom (freedom@84.14.50.82) (Quit: freedom)
# [08:53] * Joins: jdaggett (jdaggett@84.14.50.82)
# [08:53] * Joins: freedom (freedom@84.14.50.82)
# [08:54] * Joins: dsinger (dsinger@84.14.50.82)
# [08:54] * Joins: myakura (myakura@84.14.50.82)
# [08:57] * Joins: glazou (glazou@84.14.50.82)
# [08:58] * Joins: sylvaing (sylvaing@84.14.50.82)
# [08:59] <glazou> test
# [09:00] * Joins: homata (homata@84.14.50.82)
# [09:02] * Joins: shan (qw3birc@128.30.52.28)
# [09:02] * Joins: plinss_ (plinss@84.14.50.82)
# [09:03] * Joins: johnjan (qw3birc@128.30.52.28)
# [09:03] * Joins: parkjy (qw3birc@128.30.52.28)
# [09:03] * Joins: Kai (chatzilla@84.14.50.82)
# [09:03] * mollydotcom tells glazou his test appears to have worked :P
# [09:04] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [09:04] <glazou> Zakim, this is Rhone_1
# [09:04] <Zakim> sorry, glazou, I do not see a conference named 'Rhone_1' in progress or scheduled at this time
# [09:04] * Joins: mmielke (mmielke@84.14.50.82)
# [09:04] <plinss_> zakim, room for 3?
# [09:04] <Zakim> ok, plinss_; conference Team_(css)08:01Z scheduled with code 26631 (CONF1) for 60 minutes until 0901Z
# [09:04] * Joins: shepazu (schepers@128.30.52.169)
# [09:04] <plinss_> zakim, code?
# [09:04] <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), plinss_
# [09:06] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [09:06] <RRSAgent> logging to http://www.w3.org/2010/11/02-CSS-irc
# [09:06] <glazou> ScribeNick: jdaggett
# [09:06] <glazou> Meeting: CSS fatf @ TPAC
# [09:06] * Joins: komasshu (kensaku.ko@84.14.50.82)
# [09:06] <Bert> zakim, call Rhone_1
# [09:06] <Zakim> ok, Bert; the call is being made
# [09:06] <Zakim> Team_(css)08:01Z has now started
# [09:06] <glazou> Meeting: CSS ftf @TPAC
# [09:06] <Zakim> +Rhone_1
# [09:06] <Zakim> +[Microsoft]
# [09:06] <plinss_> rrsagent, make logs public
# [09:06] <RRSAgent> I have made the request, plinss_
# [09:06] * Joins: hidetaka (hidetaka@84.14.50.82)
# [09:07] * jdaggett having fun with phones
# [09:07] <jdaggett> topic: grids
# [09:07] * Joins: szilles (chatzilla@84.14.50.82)
# [09:08] <jdaggett> phil cupp on the phone from ms
# [09:08] * TabAtkinsTPAC will be there in a sec
# [09:08] * Joins: MoZ (540e3252@128.30.52.43)
# [09:09] * Joins: alexmog (qw3birc@128.30.52.28)
# [09:09] * Joins: dbaron (dbaron@63.245.220.240)
# [09:09] * Joins: anne (annevk@84.14.50.82)
# [09:09] <mmielke> http://www.interoperabilitybridges.com/css3-grid-align/
# [09:09] <Zakim> +unl
# [09:10] <jdaggett> alex: need some good 2d layout mechanism in css
# [09:11] <jdaggett> alex: need for ui apps not just free-flowing text
# [09:11] <Zakim> -unl
# [09:11] <jdaggett> alex: several proposals for grids/table like layout
# [09:11] * Quits: TabAtkinsTPAC (chatzilla@212.180.75.100) (Ping timeout)
# [09:12] <jdaggett> alex: looked at requirements first
# [09:12] <Zakim> -Rhone_1
# [09:12] * jdaggett sylvain kills the phone
# [09:12] <Bert> zakim, call Rhone_1
# [09:12] <Zakim> ok, Bert; the call is being made
# [09:12] <Zakim> +Rhone_1
# [09:13] * Quits: dbaron (dbaron@63.245.220.240) (Ping timeout)
# [09:13] * jdaggett this is fun
# [09:13] * Joins: dbaron (dbaron@63.245.220.240)
# [09:13] <Zakim> -Rhone_1
# [09:13] * jdaggett how many ms engineers does it take to fix an electrical problem?
# [09:13] * jdaggett we now have three...
# [09:14] * jdaggett markus demurs
# [09:14] * jdaggett he's management
# [09:14] <Bert> zakim, call Rhone_1
# [09:14] <Zakim> ok, Bert; the call is being made
# [09:14] <Zakim> +Rhone_1
# [09:14] <johnjan> eureka
# [09:15] * sylvaing this is french power. works 35 hours/week
# [09:15] * dbaron wonders what sort of reader glazou wanted
# [09:15] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [09:15] <jdaggett> alex: now back to the show
# [09:15] * Quits: freedom (freedom@84.14.50.82) (Quit: freedom)
# [09:15] * glazou SDHC on USB
# [09:15] <jdaggett> alex: we like our proposal
# [09:15] <jdaggett> alex: how does this relate to previous proposals?
# [09:16] * Joins: freedom (freedom@84.14.50.82)
# [09:16] <jdaggett> alex: this proposal is based on xul, wpf-grid, probably closest to wpf-grid
# [09:17] <jdaggett> alex: but uses flex box like elements (?)
# [09:17] <jdaggett> alex: make sense?
# [09:17] <jdaggett> alex: let's go over the spec
# [09:18] * Joins: TabAtkinsTPAC (chatzilla@84.14.50.82)
# [09:18] <jdaggett> alex: grid works by defining grid lines
# [09:18] <jdaggett> alex: layout using row, column coords and how many columns it overlaps
# [09:18] * Joins: fsasaki (Felix@84.14.50.82)
# [09:19] <jdaggett> alex: grid sizes to content
# [09:19] * Joins: jun (jun@84.14.50.82)
# [09:19] <jdaggett> alex: works for both fixed/float cases
# [09:20] <jdaggett> alex: define using
# [09:20] <jdaggett> alex: display: grid | inline-grid
# [09:20] * Joins: kennyluck (kennyluck@128.30.52.28)
# [09:21] * Quits: fsasaki (Felix@84.14.50.82) (Quit: Verlassend)
# [09:21] * Joins: cslye (cslye@84.14.50.82)
# [09:21] * Joins: r12a-nb (ishida@128.30.52.28)
# [09:21] <jdaggett> alex: grid-column, grid-row with value to define grid
# [09:22] <jdaggett> alex: (looking at ex 2)
# [09:22] <jdaggett> dbaron: what are the values of grid-columns, grid-rows?
# [09:23] <jdaggett> alex explains syntax
# [09:23] * fantasai is having a hard time understanding why this is better than Template
# [09:25] <jdaggett> present currently: elika, bert, håkon, peter, markus, tab, beth dakin, richard ishida, steve z, daniel, ms john, sylvain, koji, dbaron
# [09:26] <jdaggett> markus: values are from template spec
# [09:27] <jdaggett> alex: columns, rows can overlap
# [09:27] <jdaggett> alex: lots of interesting overlap cases
# [09:27] <jdaggett> alex: for example, equivalent of xul stack layout with single slot w/ multiple items stretching to largest
# [09:28] <jdaggett> jdaggett: does this have features that template doesn't support?
# [09:29] <jdaggett> alex: overlapping elements
# [09:29] <jdaggett> bert: also, this allows you to automatically grows grid with content
# [09:29] <fantasai> bert: I explicitly left that out of Template to keep it simple
# [09:30] <jdaggett> sylvain: yeah, if you add content at 5,5 to a 3,3 grid it grows automatically
# [09:30] <jdaggett> alex: useful for sparse grids, or grids where order can change
# [09:30] <jdaggett> markus: no-brainer if know tables
# [09:30] <jdaggett> alex: no ascii art
# [09:31] <jdaggett> jdaggett mourns this
# [09:31] * mollydotcom mourns no ascii art too
# [09:31] * TabAtkinsTPAC too!
# [09:31] <jdaggett> bert: syntax question, many ways to express concept
# [09:31] * TabAtkinsTPAC suggested a way to still mix-in ascii layouts that mesh well with the rest of Grid.
# [09:31] <jdaggett> fantasai: snap to grid functionality?
# [09:32] <jdaggett> alex: not yet, every item is explicitly placed
# [09:32] <jdaggett> fantasai: not a fan of positioning aspect
# [09:33] <jdaggett> fantasai: but a flex box layout aligned to grid woud be groovy
# [09:33] <glazou> glazou 'grid-cell: 'selector'' can be added afterwards
# [09:33] <jdaggett> fantasai: using flexbox or template to align would not break with reflow
# [09:34] * mollydotcom agrees with fantasai - the positioning isn't design-intuitive but a flexbox aligned to grid would make designers drool with happiness. Snap to grid would do so as well.
# [09:34] <jdaggett> peter: typically grids are defined by lines not cells
# [09:34] <jdaggett> peter: and align to line, not cell
# [09:35] <fantasai> mollydotcom, exacty. I think flexbox or template + snap-to-grid would be great
# [09:35] <jdaggett> jdaggett: didn't you propose grid positioning with grid lines?
# [09:35] <jdaggett> alex: no real contradiction between the two
# [09:35] <fantasai> mollydotcom, It seems to me easier to lose, and less likely to break with reflow effects (window resizing, font resizing, changing content, etc.)
# [09:36] <jdaggett> alex: we didn't want to combine the two
# [09:36] <fantasai> peter: I want to align to a gridline. And I'd probably want to align to a named gridline, so I can insert arbitrary grid lines later and not have it move
# [09:36] <jdaggett> alex: could have circular dependencies
# [09:37] <jdaggett> alex: i would to see both
# [09:37] <jdaggett> alex: but don't want to spend the whole time resolving dependencies
# [09:37] <jdaggett> alex: can do the same with this as with gridlines
# [09:38] <fantasai> jdaggett: Graphic design books that talk about grids, was more along what Peter was saying
# [09:38] <fantasai> jdaggett: This model you're going to have to do extra work to define that
# [09:39] <jdaggett> markus: two core use cases
# [09:39] <jdaggett> markus: 1. print design layouts
# [09:39] <jdaggett> markus: 2. app layouts
# [09:39] * Quits: Peter` (peter@85.223.116.170) (Ping timeout)
# [09:39] <jdaggett> markus: this is more for (2)
# [09:40] <jdaggett> alex: grids in print don't deal with resizing issues
# [09:40] <jdaggett> alex: much better to have some that are fixed, some that flex
# [09:41] <jdaggett> alex: when grid is sized by content is actually more useful but doesn't cover all scenarios
# [09:41] <jdaggett> stevez: symbolic identification
# [09:41] * Joins: Peter` (peter@85.223.116.170)
# [09:41] <jdaggett> stevez: names to cells?
# [09:42] <jdaggett> fantasai: that's what template does
# [09:42] * dbaron Zakim, who is noisy?
# [09:42] <jdaggett> alex: we have started with minimal feature set
# [09:42] * Zakim dbaron, listening for 11 seconds I could not identify any sounds
# [09:42] <jdaggett> peter: i don't want to name cell, i want to name lines
# [09:42] <jdaggett> peter: if a grid row/line is added in the middle, the grid shrinks
# [09:43] <jdaggett> peter: i want to span from one gridline to another
# [09:43] <jdaggett> peter: even if lines are added in between
# [09:43] <jdaggett> peter: could be dynamic or for additive layout
# [09:44] <jdaggett> peter: like in the case when you just want to add a logo to a layout
# [09:44] <anne> Bert, files are in http://dev.w3.org/cvsweb/csswg/css-device-adapt/ but not in http://dev.w3.org/csswg/css-device-adapt/ ?
# [09:44] * Peter` is now known as beverloo
# [09:45] <jdaggett> pcupp: we thought about a pseudo-element that spans cells (?)
# [09:45] <jdaggett> pcupp: the cell defines a region for content to be laid out
# [09:45] <Bert> (Maybe Peter is thinking of something like: 'grid-columns: a=0%, b=75%, c=50%' and then 'grid-column: c'?)
# [09:45] <jdaggett> pcupp: maybe it's aligned, maybe it stretches
# [09:46] <jdaggett> pcupp talking about an example...
# [09:46] <jdaggett> markus: just a slightly different use case
# [09:47] <jdaggett> alex: can it be used as gridlines? no, not just with this
# [09:47] * Bert to anne: I don't know how that works. There is some Apache config that is supposed to automatically create and cache the latter. Somebody has to file a bug with sysreq...)
# [09:47] <jdaggett> alex: but we want to have some form of gridline like capability
# [09:47] * Joins: fsasaki (Felix@84.14.50.82)
# [09:47] <jdaggett> sylvain: i think we need to capture peter's use case
# [09:47] <jdaggett> sylvain: of inserting new gridlines
# [09:48] <jdaggett> peter: this defines cells but i don't think we need another way of defining cells
# [09:48] <jdaggett> alex: this is about grid alignment of cells
# [09:49] <fantasai> peter: I understand this gives some more capabilities that template doesn't have, but let's improve template and use this module to do something different
# [09:49] <jdaggett> alex: obviously we can take it further
# [09:49] <jdaggett> peter: give me the ability to name a gridline
# [09:50] <jdaggett> peter: so that i can say "this thing goes in a box that goes between these things"
# [09:50] <fantasai> s/things/gridlines/
# [09:50] <jdaggett> peter: this way i can define my cells arbitrarily
# [09:51] <jdaggett> peter: rows/columns we already have, i want new toys
# [09:52] <jdaggett> daniel: peter's proposal is not far away from my proposal to define layout with respect to other elements
# [09:52] <jdaggett> murmurs of disagreement
# [09:52] * mollydotcom laughs but reminds - these are not toys. Layout is the missing piece for designers in CSS.
# [09:52] <dbaron> I think this is pretty different, since this contains things properly so things won't overlap.
# [09:53] * jdaggett note taker license, he didn't say toys
# [09:53] <jdaggett> continuing through spec
# [09:53] * mollydotcom it is something that must be worked out. Grids/lines is a very familiar paradigm in design. And as Peter points out, we have rows and columns already
# [09:53] <glazou> dbaron: : no verlap ?
# [09:53] * mollydotcom noted, jdaggett ;)
# [09:53] * Bert thinks the problem is that layout may be the missing piece, but everybody defines layout differently...
# [09:54] <jdaggett> alex: there is a property that controls the order of rendering
# [09:54] * Joins: joonho (joonholee@84.14.50.82)
# [09:54] <jdaggett> alex: to deal with overlapping elements
# [09:54] * mollydotcom adds that the medium often defines layout limitations too, screen v. handheld, etc.
# [09:54] <jdaggett> alex: not super important
# [09:55] <jdaggett> (section 8 of spec)
# [09:55] <jdaggett> peter: what if you just use z-index?
# [09:55] <jdaggett> alex: we can discuss that
# [09:55] <jdaggett> peter: i don't see the difference
# [09:55] <jdaggett> alex mumbles...
# [09:55] <jdaggett> and smiles
# [09:56] <jdaggett> daniel: i'm considering working on peter's proposals
# [09:56] <jdaggett> daniel: i have a few ideas about this
# [09:56] <jdaggett> howcome: use cases would be interesting
# [09:56] <jdaggett> howcome: for comparison
# [09:57] <jdaggett> daniel: i'll work on the ideas, then the use cases if i have time
# [09:57] <jdaggett> stevez: there were previous proposals for...
# [09:57] * fantasai notes that flexbox was intended to solve the app-centric layout model
# [09:58] <jdaggett> stevez: a two-column layout with a figure in the middle
# [09:58] <jdaggett> stevez: there's an issue with how to overlay
# [09:58] <jdaggett> howcome: that's in gcpm!!
# [09:58] <jdaggett> howcome: but this is app centric, not document centric
# [09:59] <jdaggett> peter: lots of use cases for document centric uses
# [09:59] <jdaggett> daniel: this is really about app centric use
# [09:59] <jdaggett> alex: concurs
# [09:59] <jdaggett> stevez: i'm dazed and confused
# [10:00] <fantasai> I believe template + flex coudl do most of these layouts, aside from the overlapping ones
# [10:00] <jdaggett> stevez: i thought you were tailoring the syntax for one use
# [10:00] * Quits: joonho (joonholee@84.14.50.82) (Ping timeout)
# [10:00] * Joins: exr (joonholee@124.39.135.110)
# [10:00] <jdaggett> markus: there's an aspect....
# [10:01] * glazou said he's accepting an action item to work on a new proposal more line-centric
# [10:01] <jdaggett> pcupp: we think it's the common case where controls are composed using this
# [10:01] <jdaggett> section 2.4, figure 6
# [10:01] <jdaggett> picture of a slider
# [10:02] <jdaggett> because the world needs more sliders...
# [10:02] <jdaggett> alex: what can we do with this? new module? merge with another?
# [10:02] <jdaggett> bert: seems close to flex box
# [10:02] <jdaggett> tab mumbles
# [10:03] <jdaggett> bert: i have a number of comments
# [10:03] <jdaggett> bert: when you put two elements in the grid they overlap, they don't add
# [10:03] <jdaggett> bert: might be good or bad
# [10:04] <jdaggett> markus: you need it as in the slider example
# [10:04] <jdaggett> tab: this example is also nice for being able to overlap
# [10:04] <szilles> +1 for tab's comment
# [10:04] <jdaggett> bert: what's the intrinsic size in this case?
# [10:04] <fantasai> <slider style="display: flexbox"><lower-fill style="flex: 0.5"/><thumb style="position: absolute; width: 2N; left: -N"><upper-fill style="flex: 0.5"/></slider> ?
# [10:05] <jdaggett> alex: multiple items in cell all affect sizing
# [10:05] <TabAtkinsTPAC> tab: I provided an example in my response to the grid-align thread where it was useful to be able to position multiple items in one cell and have them flow together, rather than overlap. However, overlapping is *also* useful.
# [10:05] <jdaggett> bert: don't like three props, why not one
# [10:05] <jdaggett> alex: yeah but that would be a long line
# [10:06] <jdaggett> alex: well you don't need to specify predefined size
# [10:06] <jdaggett> bert: wondering float and position
# [10:06] <jdaggett> alex: works just like flex box
# [10:06] <dbaron> I'd prefer not to put complicated syntax inside values of 'display'.
# [10:07] * fantasai too
# [10:07] <jdaggett> alex: float ignored, position with regards to nearest positioned element
# [10:07] <jdaggett> tab says something i don't understand
# [10:08] <jdaggett> alex: position might also work the same way but not affect sizing
# [10:08] <jdaggett> tab: in my position layout proposal, i came up with a good model for positioning in new layout proposals
# [10:09] <dbaron> I think alex said there are two options for position: absolute: the normal way (placeholder, etc.) or position according to grid rows/columns but not affect sizes of the grid rows/columns.
# [10:09] <jdaggett> argh, not following tab again...
# [10:09] <jdaggett> alex: the way to think about absolute positioning
# [10:10] <jdaggett> alex: with a grid it's obvious where it's positioned
# [10:10] * Joins: yuma_1985 (yuma_1985@84.14.50.82)
# [10:10] <TabAtkinsTPAC> TabAtkinsTPAC: In my Positioned Layout proposal I specified a consistent and easy way to make positioning interact with other layout modes.
# [10:10] <jdaggett> alex and bert discuss this
# [10:10] <TabAtkinsTPAC> TabAtkinsTPAC: The positioned element leaves behind a placeholder element.
# [10:11] <jdaggett> bert: difference between grid-row and grid-rows is just one letter
# [10:11] <jdaggett> same for columns
# [10:11] <jdaggett> syntax discussion
# [10:12] <TabAtkinsTPAC> TabAtkinsTPAC: You could then use the grid properties to position the placeholder, which would affect the 'auto' position of the abspos box (what it means for "top:auto", etc.)
# [10:12] <jdaggett> bert: for flex box the content is in a given order
# [10:12] <jdaggett> bert: with this proposal the source order doesn't affect the order in the grid
# [10:12] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [10:12] <jdaggett> alex: one possible extension is auto-incrementing rows/columns
# [10:12] <jdaggett> alex: this is closer to xul grid
# [10:13] <jdaggett> dbaron: also auto-incrementing row-groups/column-groups
# [10:13] <dbaron> and you could allow them to take grid-row/grid-column (or lines) and not start at the top-left
# [10:14] <jdaggett> bert: the idea that you auto-create the table based on a single cell
# [10:14] <jdaggett> bert: but you can't catch errors in your design
# [10:15] <jdaggett> bert: because it's not based on explicitly named entities
# [10:15] <jdaggett> alex: either way you need to define a protocol here
# [10:15] <jdaggett> bert: i'm not sure plus/minus but it does mask errors
# [10:16] <jdaggett> bert: you don't allow % in cell size
# [10:16] <jdaggett> alex: could be added
# [10:16] <jdaggett> tab: what exactly do you want to base the % on
# [10:17] <jdaggett> tab: you need to explain which the % is based one
# [10:17] * Parts: komasshu (kensaku.ko@84.14.50.82)
# [10:18] * Joins: komasshu (kensaku.ko@84.14.50.82)
# [10:18] <jdaggett> dbaron: i was thinking of someone designing a page
# [10:18] <jdaggett> with embedded grids with constraints between elements
# [10:19] <jdaggett> dbaron: with this proposal you would use nested grids
# [10:19] <Kai> +1 to David's proposal
# [10:20] <jdaggett> dbaron: are there cases where nested grids need to line up with ...
# [10:20] <jdaggett> peter: this is why gridlines are handy
# [10:20] * Joins: Ibrahima_ (qw3birc@128.30.52.28)
# [10:20] <fantasai> s/why/why named/
# [10:20] <Bert> (DBaron wants something like constraints on the columns widths: a = b = c, d = e, sum(a.e) = parent, but not relation between a,b,c on one hand and d,e on other...)
# [10:21] <jdaggett> pcupp: so you're talking about how to line up nested grids with outer grid
# [10:21] <jdaggett> pcupp: with unioned gridlines, spanning behavior becomes hard to predict
# [10:21] <jdaggett> pcupp: things tend to grow in unpredictable ways
# [10:22] <fantasai> dbaron's drawing:
# [10:22] <fantasai> +--------------+
# [10:22] * Zakim wonders where --------------+ is
# [10:22] <fantasai> | |
# [10:22] <fantasai> | +--+--+
# [10:22] <fantasai> | | | |
# [10:22] <fantasai> +--+--+--+--+--+
# [10:22] * Zakim wonders where --+--+--+--+--+ is
# [10:22] <fantasai> | | | | |
# [10:22] <fantasai> +--+--+--+ |
# [10:22] <jdaggett> bert: also, you can't put something in your cousin grids, only grids within single tree
# [10:22] <fantasai> | |
# [10:22] <fantasai> +--------------+
# [10:22] * Zakim wonders where --------------+ is
# [10:23] <jdaggett> ah, we do so need ascii art
# [10:23] <jdaggett> bert: just a remark
# [10:23] <jdaggett> bert: this is hard
# [10:23] <jdaggett> bert: cesar found examples where this might be handy
# [10:23] * fantasai notes that ascii art requires a monospace font, which the projecting comp isn't using ;)
# [10:23] <jdaggett> stevez: why is that a good thing?
# [10:24] <jdaggett> bert and steve discuss trees and kissing cousins
# [10:25] <jdaggett> stevez: similar to separating template from content
# [10:25] <jdaggett> bert: you can select different grids from screen size
# [10:25] <jdaggett> bert: you can use the body element to hook your grid on
# [10:26] <jdaggett> bert: those are my comments
# [10:26] <jdaggett> fantasai: you might also want named grids
# [10:26] <jdaggett> fantasai: main and secondary
# [10:27] <jdaggett> fantasai: but maybe i don't totally understand
# [10:27] <jdaggett> alex: we would like to make this an editor's draft
# [10:27] <Bert> (Something like: 'grid-column: a.1' for column 1 in grid a?)
# [10:27] <jdaggett> alex: what else do we need to get there?
# [10:28] <jdaggett> alex: we can make changes to deal with use cases and functionality discussed
# [10:28] <jdaggett> stevez: how many table-like layout mechanisms do we need
# [10:28] <jdaggett> ?
# [10:28] <jdaggett> markus: you need a variety
# [10:28] <jdaggett> markus: you need abosolute positioning, flex box, grid
# [10:29] * fantasai wonders if xul has abspos
# [10:29] <jdaggett> markus: each solves a different use case
# [10:29] * Joins: howcome (howcome@84.14.50.82)
# [10:29] <jdaggett> pcupp: overlap in grid / flexbox use
# [10:29] <jdaggett> pcupp: they're complimentary
# [10:30] <jdaggett> peter: this is a 2d flexbox
# [10:30] <jdaggett> stevez: there are comonalities
# [10:30] <jdaggett> stevez: declaring size
# [10:30] * Quits: mmielke (mmielke@84.14.50.82) (Ping timeout)
# [10:30] <jdaggett> stevez: concerned about complexity
# [10:30] <jdaggett> markus: in the end it all makes sense
# [10:30] <jdaggett> markus: app vs. doc roles
# [10:30] <fantasai> s/size/size constraints/
# [10:31] <jdaggett> tab: steve, your concern is that we get too much complexity?
# [10:31] <jdaggett> stevez: it's that we have a lot of ways of defining cellsize
# [10:31] <jdaggett> stevez: are the pieces the same across all three sizes?
# [10:31] * Bert wonders if we should have not just a CSS Beijing, with the stable features for typography, but also a CSS Lyon, with the stable features for GUIs. Maybe few UAs need to do both...
# [10:31] <jdaggett> tab: you can express everything in one master model
# [10:32] <jdaggett> tab: different uses require different layout models
# [10:32] <jdaggett> tab: layout models interact in orthogonal ways
# [10:32] * glazou thinks we spend far too much time on specs that don't provide new technical stuff and does not want another "snapshot" for every ftf
# [10:32] <jdaggett> tab: make each as easy as possible
# [10:33] <jdaggett> stevez: i'm ok with that but i want to make sure that concepts carry across the models
# [10:33] <jdaggett> stevez: the base primitives need to be consistent
# [10:34] <jdaggett> tab: yes, you want primitives to work across layout models (?)
# [10:34] <jdaggett> howcome: healthy competition across modules is good
# [10:34] <jdaggett> howcome: this model and template don't make sense together
# [10:35] * Kai is concerned about authors being able to distinguish between the various modules and starting to mix and match, perhaps creating problems down the road
# [10:35] <jdaggett> stevez: is there an action item for bert/alex to combine these ideas
# [10:36] <jdaggett> bert: future ideas, non-rectangular cells, chained cells
# [10:36] <jdaggett> howcome: and across pages
# [10:36] <jdaggett> bert: so the question is how these concepts fit with that
# [10:36] <jdaggett> peter: grids that flow across pages or grids that repeat
# [10:37] <jdaggett> peter: can we use the same syntax for both
# [10:37] <jdaggett> markus: need to be careful about use cases
# [10:37] <jdaggett> markus: if combination is complex, life sucks for everyone
# [10:37] * Quits: fsasaki (Felix@84.14.50.82) (Quit: This computer has gone to sleep)
# [10:37] <jdaggett> peter: one problem is that you're calling this a grid
# [10:38] <jdaggett> peter: it's not really a grid
# [10:38] <jdaggett> stevez talking about the beauty of xsl
# [10:38] <jdaggett> markus: need to solve both print-like and app use cases
# [10:39] <jdaggett> markus: two action items, alex/bert to kibbitz
# [10:39] <jdaggett> markus: and talk with daniel about his ideas
# [10:39] <jdaggett> peter: may end up with 90% overlap
# [10:40] <jdaggett> stevez: could be true, punchout or overlay, small set of props captures both
# [10:40] <jdaggett> stevez: a model for both is important
# [10:40] <jdaggett> stevez: no problem if app is favored, since docs are harder
# [10:40] <jdaggett> peter: i just want us to be thinking about this
# [10:41] <jdaggett> markus: yeah, maybe grid is not the best name here
# [10:41] <jdaggett> fantasai: grid-columns and grid-rows are common to both grid specs?
# [10:41] * Quits: r12a-nb (ishida@128.30.52.28) (Ping timeout)
# [10:41] <jdaggett> alex: yeah, we have to merge or redefine
# [10:41] <jdaggett> discussion of what to do with the document
# [10:42] <jdaggett> daniel: grids are already in the charter
# [10:42] <jdaggett> stevez: not sure this is FPWD ready
# [10:43] <jdaggett> stevez: we should do some vetting
# [10:43] <jdaggett> daniel: don't need to name it now
# [10:43] <jdaggett> markus: first agree on what's in these specs
# [10:43] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [10:43] <Zakim> -[Microsoft]
# [10:43] * Joins: timeless_mbp (timeless@84.14.50.82)
# [10:43] * Quits: komasshu (kensaku.ko@84.14.50.82) (Client exited)
# [10:44] * Quits: Kai (chatzilla@84.14.50.82) (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854])
# [10:44] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
# [10:44] <jdaggett> break for coffee and champagne
# [10:44] * Quits: cslye (cslye@84.14.50.82) (Quit: cslye)
# [10:44] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [10:44] <myakura> RRSAgent, make minutes
# [10:44] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html myakura
# [10:45] * Quits: shan (qw3birc@128.30.52.28) (Ping timeout)
# [10:46] * Joins: kennyluck (kennyluck@128.30.52.28)
# [10:46] * mollydotcom wants some champagne! The real stuff :: hands over glass ::
# [10:46] <Zakim> -Rhone_1
# [10:46] <Zakim> Team_(css)08:01Z has ended
# [10:47] <Zakim> Attendees were Rhone_1, [Microsoft], unl
# [10:47] * Quits: homata (homata@84.14.50.82) (Ping timeout)
# [10:47] * Quits: MoZ (540e3252@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
# [10:47] * Joins: komasshu (kensaku.ko@84.14.50.82)
# [10:49] * Quits: hidetaka (hidetaka@84.14.50.82) (Ping timeout)
# [10:49] * Quits: jun (jun@84.14.50.82) (Quit: jun)
# [10:50] * Joins: glazou (glazou@84.14.50.82)
# [10:51] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [10:52] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [10:52] * Quits: yuma_1985 (yuma_1985@84.14.50.82) (Connection reset by peer)
# [10:52] * Joins: yuma_1986 (yuma_1985@84.14.50.82)
# [10:52] * Joins: mjs (mjs@84.14.50.82)
# [10:55] * Joins: cslye (cslye@84.14.50.82)
# [11:01] * Joins: shan (qw3birc@128.30.52.28)
# [11:07] * timeless_mbp is now known as timeless
# [11:09] * Quits: Ibrahima_ (qw3birc@128.30.52.28) (Ping timeout)
# [11:09] * Joins: dethbakin (dethbakin@84.14.50.82)
# [11:09] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
# [11:10] * Joins: jun (jun@84.14.50.82)
# [11:11] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
# [11:11] * Joins: homata (homata@84.14.50.82)
# [11:11] * Joins: shepazu (schepers@128.30.52.169)
# [11:12] * Joins: hidetaka (hidetaka@84.14.50.82)
# [11:12] * Joins: dethbakin (dethbakin@84.14.50.82)
# [11:14] * Joins: glazou (glazou@84.14.50.82)
# [11:14] <TabAtkinsTPAC> ScribeNick: TabAtkinsTPAC
# [11:14] * Quits: shepazu (schepers@128.30.52.169) (Client exited)
# [11:14] <sylvaing> http://dev.w3.org/csswg/css3-writing-modes/
# [11:14] <fantasai> http://dev.w3.org/csswg/css3-writing-modes/
# [11:14] * Quits: timeless (timeless@84.14.50.82) (Client exited)
# [11:15] <TabAtkinsTPAC> fantasai: In the draft, I define some terms and drew some pictures.
# [11:15] * Joins: fsasaki (Felix@84.14.50.82)
# [11:16] * Joins: MikeSmith (MikeSmith@84.14.50.82)
# [11:16] <TabAtkinsTPAC> howcome: I suggest simplifying the terms to 'inline direction' and 'block direction', not '* flow directionality'.
# [11:16] <TabAtkinsTPAC> szilles: I think "directionality" is a hard word for non-English speakers.
# [11:16] <TabAtkinsTPAC> fantasai: Okay, don't have an opinion much.
# [11:16] * Joins: timeless_mbp (timeless@84.14.50.82)
# [11:17] <TabAtkinsTPAC> fantasai: Most of the bidi text here is just copied from css 2.1.
# [11:17] <sylvaing> section 3.2. title typo: 'uncode-bidi'
# [11:18] <TabAtkinsTPAC> dbaron: Could we have an additional set of parens on the unicode-bidi property, so we don't have to rely on knowing the relative strength of the opeerators?
# [11:18] <TabAtkinsTPAC> fantasai: 'isolate' is a new unicode-bidi value, proposed by the bidi for html group.
# [11:18] <TabAtkinsTPAC> fantasai: That prevents strings that have a different directionality from having an effect on the text around them.
# [11:18] * Joins: Kai (chatzilla@84.14.50.82)
# [11:19] <TabAtkinsTPAC> fantasai: There's also a plaintext value, which is intended to use the unicode bidi algorithm to determine the bidi direction of each paragraph.
# [11:19] * Joins: r12a-nb (ishida@128.30.52.28)
# [11:19] <TabAtkinsTPAC> fantasai: This does *not* affect the direction property, it just affects bidi resolution.
# [11:19] <TabAtkinsTPAC> aharon: Should I give use-cases for 'isolate' and 'plaintext'?
# [11:19] <TabAtkinsTPAC> szilles: Would be helpful.
# [11:19] <TabAtkinsTPAC> aharon: 'isolate' is useful in the context of a webapp that is inserting data into a page.
# [11:20] <dbaron> http://www.w3.org/TR/2010/WD-html-bidi-20100304/ has some use cases for these new features, no?
# [11:20] * Joins: MoZ (540e3252@128.30.52.43)
# [11:20] * Joins: shepazu (schepers@128.30.52.169)
# [11:20] <TabAtkinsTPAC> aharon: Frex, I'm displaying search results, and the title of the results are outside data and may not be in the same language as the rest of the UI.
# [11:20] <TabAtkinsTPAC> aharon: If you don't isolate the titles, it quite often interacts with the stuff around it, such as numbers and other neutral characters.
# [11:21] <TabAtkinsTPAC> aharon: Outside of an app, it's useful for quotes and links - I can't imagine why you'd want a link to be broken up into two parts due to its directionality interacting oddly with the surrounding content.
# [11:21] <TabAtkinsTPAC> fantasai: It drastically reduces the number of LRM/RLM you have to use.
# [11:22] <TabAtkinsTPAC> aharon: Side thought - I think instead of "inline direction", use "inline base direction".
# [11:22] <TabAtkinsTPAC> aharon: The base direction is controlled by the 'direction' property.
# [11:22] <dbaron> aharon: Might be good to use the term "inline base direction" instead of "inline directionality"
# [11:22] <dbaron> (given the previous discussion about avoiding the term "inline directionality")
# [11:22] <TabAtkinsTPAC> aharon: There are a couple of problems. You might not know what the direction is - it could be outside data.
# [11:23] <TabAtkinsTPAC> aharon: It is very useful to let the UA guess what the direction is using standard algos based on the characters in the data.
# [11:23] <TabAtkinsTPAC> aharon: There is a separate proposal in HTML for @dir=auto to do this.
# [11:23] <TabAtkinsTPAC> s/to do this//
# [11:23] <TabAtkinsTPAC> aharon: That's not precisely what we have here in 'plaintext'.
# [11:24] <TabAtkinsTPAC> aharon: The UA, in HTML, sees dir=auto, looks at the content, decides whether the direction is rtl or ltr, then sets the CSS 'direction' appropriately.
# [11:24] <TabAtkinsTPAC> aharon: That's good, but doesn't go quite far enough.
# [11:24] <TabAtkinsTPAC> aharon: Let's say I have a textarea - plaintext - that the user is typing into.
# [11:25] <TabAtkinsTPAC> aharon: Is it fairly useful to have some paragraphs in one language and some paragraphs in another language. Frex, I'm typing in a restaurant review in Hebrew.
# [11:25] <TabAtkinsTPAC> aharon: I give the review in Hebrew, then say "the address is:..." and give it in French because the restaurant is in Lyon. If I don't switch the direction of the paragraph, the number at the start of the address will go on the wrong side.
# [11:25] <TabAtkinsTPAC> aharon: So you want the ability to have paragraphs that go in different directions.
# [11:25] <TabAtkinsTPAC> aharon: If you're doing markup, that's great - you can just make separate paragraphs.
# [11:26] <TabAtkinsTPAC> aharon: If you're just typing into a textarea, though, you cant' do that.
# [11:26] <TabAtkinsTPAC> aharon: The unicode bidi algorithm defines a simple way to define the directionality of each paragraph (where "paragraph" is defined by the bidi algorithm).
# [11:26] <TabAtkinsTPAC> aharon: So 'plaintext' would say that the textarea isn't necessarily ltr or rtl, it's plaintext where each paragraph can go either way.
# [11:27] <TabAtkinsTPAC> aharon: It's still not limited to textarea, of course - often after taking the data from a textarea you want to then display it.
# [11:27] <TabAtkinsTPAC> aharon: So you want to still be able to apply this same directionality algorithm to the results outside of a textarea.
# [11:28] <TabAtkinsTPAC> aharon: You can't hide the directionality determination from CSS with dir=auto here, because the different paragraphs aren't marked up as explicit elements.
# [11:28] * Joins: dsinger (dsinger@84.14.50.82)
# [11:28] <TabAtkinsTPAC> dbaron: [question about which characters serve as paragraph separators]
# [11:28] * timeless_mbp is now known as timeless
# [11:28] <TabAtkinsTPAC> aharon: The unicode algorithm is very precise about which characters are paragraph separators. In the past, some browsers didn't follow that exactly, which is basically a bug.
# [11:29] <TabAtkinsTPAC> Bert: What's the difference between 'embed' and 'isolate'?
# [11:29] <TabAtkinsTPAC> aharon: 'embed' says "this element has a base direction", but that doesn't prevent the element from affecting stuff outside of it.
# [11:30] <TabAtkinsTPAC> aharon: So, if I have an english paragraph, but in the middle is an arabic word and then an embed of a separate element which is explicitly rtl.
# [11:30] <TabAtkinsTPAC> aharon: The unicode algorithm says that the arabic and the rtl are merged together and will both flow rtl together.
# [11:30] <TabAtkinsTPAC> aharon: You don't want this - logically, the arabic and the embed are separate, and shouldn't stick together.
# [11:31] <TabAtkinsTPAC> Bert: So inside, 'embed' and 'isolate' are the same. They're different outside?
# [11:31] <TabAtkinsTPAC> aharon: Yes.
# [11:31] <TabAtkinsTPAC> howcome: It seems that you need to explicitly set all block-level elements to 'isolate'?
# [11:31] <TabAtkinsTPAC> dbaron: That should be in the default stylesheet.
# [11:32] * fantasai checked in the change to "inline base direction"
# [11:32] <TabAtkinsTPAC> aharon: You don't necessarily need it. It's just that if you have a block-level element and you use CSS to make it display inline, you really want it to still be isolated.
# [11:32] <TabAtkinsTPAC> aharon: Right now HTML5 effectively says that all block-level elements should be 'embed'; we just changed it to 'isolate', which is closer to the intenet.
# [11:33] <TabAtkinsTPAC> aharon: As to making a block inline, one example is an inline list. If some of those values are opposite direction, it's important to have isolation apply to them.
# [11:33] <TabAtkinsTPAC> howcome: So, can we in any way hinge this behavior on the existing CSS display?
# [11:33] <TabAtkinsTPAC> fantasai: If the display is anything other than inline, you already *effectively* have the isolate value.
# [11:34] <TabAtkinsTPAC> fantasai: The problem is just that when you change the display value to inline, there's no CSS distinction to tell us that this *used* to be a block-level, so you need 'isolate' there.
# [11:35] * kennyluck http://dev.w3.org/csswg/css3-writing-modes/#bidi-html looks relevant
# [11:35] <TabAtkinsTPAC> TabAtkins: You can in the UA stylesheet just set all the block elements to 'isolate', so the author doesn't have to think about it.
# [11:35] <TabAtkinsTPAC> howcome: But you have to remember to set 'isolate' in new XML languages.
# [11:35] <MikeSmith> RRSAgent, make minutes
# [11:35] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html MikeSmith
# [11:35] <TabAtkinsTPAC> TabAtkins: Yes.
# [11:36] * Quits: timeless (timeless@84.14.50.82) (Client exited)
# [11:36] <TabAtkinsTPAC> Bert: Does this cover all known cases?
# [11:36] <TabAtkinsTPAC> fantasai: This covers all of CSS2.1 + all of the proposals from the bidi subgroup for i18n.
# [11:36] <TabAtkinsTPAC> fantasai: Now, 'writing-mode'.
# [11:37] <TabAtkinsTPAC> fantasai: The previous writing-mode property was a shorthand for block-flow-direction and 'direction'.
# [11:37] <TabAtkinsTPAC> fantasai: One of the things I was tasked with was to sync with SVG, which is very explicit that the writing-mode and direction property don't interact.
# [11:37] <TabAtkinsTPAC> fantasai: The SVG spec has these valuees (lr, lr-tb, rl, tb, tb-rl)
# [11:37] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
# [11:38] <TabAtkinsTPAC> fantasai: I could figure out what the 'rl' value was and how it differs from 'lr'.
# [11:38] <TabAtkinsTPAC> fantasai: The SVG spec says you do bidi reordering, then use writing-mode to change the inline progression direction.
# [11:38] <MikeSmith> i/css3-writing-modes/Topic: Writing modes
# [11:38] <MikeSmith> RRSAgent, make minutes
# [11:38] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html MikeSmith
# [11:38] <TabAtkinsTPAC> fantasai: Which is left to right in 'lr' - this is *after* bidi reordering, in visual ordere.
# [11:39] <TabAtkinsTPAC> fantasai: As far as I can tell, 'rl' should maybe just mean reverse the text, but I only found one impl that does that.
# [11:39] <TabAtkinsTPAC> fantasai: So, I just mapped both of them to the same thing - 'horizontal-tb'.
# [11:40] <TabAtkinsTPAC> fantasai: So now, in CSS, the 'direction' and 'writing-mode' are distinct. You first do bidi reordering, then 'writing-mode' just defines the axis to use.
# [11:40] * Joins: Hixie (ianh@129.241.93.37)
# [11:40] <TabAtkinsTPAC> fantasai: I thought that saying 'lr' was confusing, since it doesn't have anything to do with ltr text, so I called the value "horizontal-tb".
# [11:40] <TabAtkinsTPAC> shepazu: The hreason SVG does it the way it does, is because XSL did it that way.
# [11:41] <TabAtkinsTPAC> fantasai: I don't have any objection to the way SVG did it. I don't think it's good for authors to be using a property that resets all the bidi in the document just to get vertical text.
# [11:41] <TabAtkinsTPAC> sylvaing: Is there content out there using 'writing-mode:lr-tb'?
# [11:41] <TabAtkinsTPAC> fantasai: Yes, but it's not relying on the direction-reset stuff.
# [11:42] <TabAtkinsTPAC> fantasai: I think the number of people who are mixing rtl with vertical text right now is basically ignorable, though I suspect it will increase as we support this.
# [11:42] <TabAtkinsTPAC> shepazu: Let's say I have a table in HTML, and I want a header going down the side, with english vertical text...
# [11:42] <TabAtkinsTPAC> fantasai: That's addressed by other stuff in the draft.
# [11:43] <TabAtkinsTPAC> fantasai: So, with 'writing-mode', the first value gives you the line axis, the second gives you the block-flow. "horizontal-tb", and "vertical-lr".
# [11:43] <TabAtkinsTPAC> fantasai: [I missed the line about mongolian]
# [11:44] <TabAtkinsTPAC> jdaggett: I don't understand why we need horizontal-bt.
# [11:44] <TabAtkinsTPAC> fantasai: I did it because MS implemented it.
# [11:44] <TabAtkinsTPAC> alexmog: Mainly for completeness.
# [11:44] <TabAtkinsTPAC> jdaggett: I don't understand completeness.
# [11:45] <TabAtkinsTPAC> alexmog: It's simple and obvious what it means. There aren't large use-cases, but it takes a very minimal impl cost.
# [11:45] <TabAtkinsTPAC> jdaggett: Agreed that it's a minimal cost, but I still don't think that we should have random property values. Someone still has to test that.
# [11:45] <TabAtkinsTPAC> jdaggett: Frex, this can affect what PgUp/PgDn mean, which means manual testing.
# [11:45] <TabAtkinsTPAC> fantasai: I completely abstain from this.
# [11:46] <TabAtkinsTPAC> shepazu: Are there any scripts that have used it?
# [11:46] <TabAtkinsTPAC> [maybe some archaic scripts, but not commonly]
# [11:46] <TabAtkinsTPAC> howcome: I don't think we need to try for complete here.
# [11:47] <TabAtkinsTPAC> howcome: What does it mean in a paged medium?
# [11:47] * dbaron wonders what direction the writing in http://maps.google.com/?ll=35.663524,139.763601&t=k&z=21 is
# [11:47] <TabAtkinsTPAC> [chatter about pagination]
# [11:47] <TabAtkinsTPAC> fantasai: You paginate up.
# [11:48] <TabAtkinsTPAC> shepazu: Small but serious use-case.
# [11:48] * myakura thought that with horizontal-bt we no longer need http://www.w3.org/StyleSheets/TR/logo-WD!
# [11:48] <TabAtkinsTPAC> shepazu: There are efforts now to go back to ancient texts and transcribe them in some format. There are people who want to represent dead languages.
# [11:49] <TabAtkinsTPAC> jdaggett: I think we can remove it for now, and then put it back if someone has a language that needs it.
# [11:49] <TabAtkinsTPAC> dbaron: I don't think it's minimal cost, because dealing with overflow/scrollable region handling, you'll need to test initial scroll position being at th bottom, etc.
# [11:50] <TabAtkinsTPAC> alexmog: We've already defined 6 of the 8 possible directions, which already bring up the issues you mention. Is it additional burden to add the last two?
# [11:50] <TabAtkinsTPAC> plinss: Can we mark it as optional?
# [11:51] <TabAtkinsTPAC> jdaggett: It's either in the test suite or not.
# [11:51] * sylvaing myakura, that logo is vertical-lr...
# [11:51] <TabAtkinsTPAC> plinss: We can spend as much time debating it as it would take to implement it.
# [11:52] * kennyluck myakura, that is vertical-lr or vertical-rl and text-orientation: rotate-left
# [11:52] <TabAtkinsTPAC> fantasai: I don't care what we do. I just want to resolve.
# [11:52] * sylvaing resolved: moved to gcpm!
# [11:53] <TabAtkinsTPAC> RESOLVED: remove the horizontal-bt property.
# [11:53] <TabAtkinsTPAC> Bert: The name is fine, but I think that 'writing-mode' in XSL does influence the direction, so there's a difference there.
# [11:53] * myakura sylvaing, kennyluck, doh!
# [11:54] <TabAtkinsTPAC> fantasai: The disconnect between XSL-FO and SVG/CSS has existed since SVG 1. I don't think bringing up the incompatibility is useful, since the incompat already exists in SVG, so you'll have to support it anyway.
# [11:55] <TabAtkinsTPAC> jdaggett: I don't know why XSL compat is an issue.
# [11:56] <TabAtkinsTPAC> szilles: SVG needs to work in both XSL and CSS.
# [11:57] <TabAtkinsTPAC> fantasai: SVG is already incompatible with XSL.
# [11:57] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [11:58] <TabAtkinsTPAC> Bert: I thought that SVG copied from XSL.
# [11:58] * Joins: mjs (mjs@84.14.50.82)
# [11:58] <TabAtkinsTPAC> fantasai: They must have copied badly here, then.
# [11:59] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [11:59] <TabAtkinsTPAC> shepazu: I don't know if there's a lot of existing content, but I think in general the SVGWG is okay with changing behavior to match the CSS model, as long as it doesn't break existing content.
# [11:59] <TabAtkinsTPAC> Bert: I'd like to be able to use CSS and XSL together.
# [12:00] <TabAtkinsTPAC> shepazu: There is a japanese SVG interest group, so they'll look at the issue.
# [12:01] <TabAtkinsTPAC> fantasai: Next interesting bit is text-orientation.
# [12:01] <TabAtkinsTPAC> fantasai: szilles and XXX and I worked out these values a long time ago.
# [12:02] <TabAtkinsTPAC> fantasai: The default is "vertical-right", because that's the natural orientation for vertical scripts.
# [12:02] <TabAtkinsTPAC> jdaggett: The Latin-1 version of the latin alphabet and the fullwidth version usually act differently in vertical text, and this is captured in opentype.
# [12:02] <TabAtkinsTPAC> fantasai: The spec actually specifies that.
# [12:03] <TabAtkinsTPAC> jdaggett: We probably want to be explicit about the interaction with opentype, or refer to the spec.
# [12:03] <TabAtkinsTPAC> fantasai: I'll need help with that, because I have no clue.
# [12:03] <MikeSmith> RRSAgent, make minute
# [12:03] <RRSAgent> I'm logging. I don't understand 'make minute', MikeSmith. Try /msg RRSAgent help
# [12:03] <TabAtkinsTPAC> jdaggett: You use the term "grapheme clusters", which I think won't be underestood by most people.
# [12:03] <MikeSmith> RRSAgent, make minutes
# [12:03] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html MikeSmith
# [12:04] <TabAtkinsTPAC> ishida: Sometimes grapheme clusters aren't sufficient in indic scripts.
# [12:04] <TabAtkinsTPAC> fantasai: Is that captured in the "extended grapheme cluster" definition?
# [12:04] <TabAtkinsTPAC> ishida: No. You either need a new definition, or need to punt it to the UAs.
# [12:05] <TabAtkinsTPAC> fantasai: Let's mark that as an issue. It's the same problem we have with first-letter, so we need to fix it the same way.
# [12:05] <TabAtkinsTPAC> Bert: Could we call the default 'normal' or 'auto'?
# [12:06] <TabAtkinsTPAC> howcome: I don't understand what you mean by "not native writing mode".
# [12:06] <TabAtkinsTPAC> fantasai: horizontal script in a vertical orientation is "non-native", and vice versa.
# [12:07] <TabAtkinsTPAC> Bert: The default value is the normal way that english is embedded in japanese, so it should have a simple name.
# [12:07] <TabAtkinsTPAC> ishida: Not always normal - acronyms are often not rotated.
# [12:07] <TabAtkinsTPAC> fantasai: Those are usually done with fullwidth glyphs, which do their rotation correctly.
# [12:07] <TabAtkinsTPAC> fantasai: Compat with SVG; we're not using glyph-orientation.
# [12:08] <TabAtkinsTPAC> fantasai: It doesn't well handle a lot of corner cases. I recommend we not going into the precise details.
# [12:08] <TabAtkinsTPAC> fantasai: The interaction between text-orientation and glyph-orientation is well-defined, though - text-orientation will by default defer to glyph-orientation in a UA that implements both.
# [12:09] <fantasai> Make auto value default value for everyone -- maps to vertical-right for impl that don't support glyph-orientation
# [12:10] <TabAtkinsTPAC> fantasai: Now, text-combine.
# [12:11] <TabAtkinsTPAC> fantasai: It can be used for an effect called "tate-chu-yoko". It's different from just doing an inline-block, because the combination is treated like a single glyph.
# [12:11] <TabAtkinsTPAC> jdaggett: I think that since this is a vertical-only property, maybe the name should reflect that.
# [12:11] <TabAtkinsTPAC> jdaggett: Also we can probably drop the 'cluster' property.
# [12:12] * Joins: mjs (mjs@84.14.50.82)
# [12:12] <TabAtkinsTPAC> ishida: You can have kumimoji (sp?) in horizontal text too.
# [12:12] <TabAtkinsTPAC> jdaggett: You can either do that as direct codepoints, or many fonts have ligatures for those, which are different for vertical vs horizontal and will do the right thing.
# [12:13] <TabAtkinsTPAC> jdaggett: I just don't think we want the UAs to synthesize these. A font will have something that looks nice with the text surrounding it.
# [12:13] <TabAtkinsTPAC> ishida: Then there's warichu (sp?). Are you discounting that?
# [12:13] <TabAtkinsTPAC> jdaggett: That's a known hard problem. Not currently addressed by this draft.
# [12:13] <dbaron> http://www.w3.org/International/articles/css3-text/#Slide0190 has pictures of kumimoji and warichu
# [12:14] <TabAtkinsTPAC> szilles: I think what's being proposed is that the 'cluster' should be split out, because it's a different thing from tate-chu-yoko.
# [12:14] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [12:14] <TabAtkinsTPAC> jdaggett: Also, some people from the japanese TF came back and said that it's not really good typography to do this.
# [12:14] <TabAtkinsTPAC> ishida: It makes some sense to me to not bundle it with the tate-chu-yoko.
# [12:15] <TabAtkinsTPAC> jdaggett: For tate-chu-yoko, some authors may only want to do this style (2-characters only), but newspapers will sometimes use third-width or quarter-width glyphs (for things like years).
# [12:15] <TabAtkinsTPAC> jdaggett: It would be nice to say "I want tate-chu-yoko for 2-character runs, but not 3 or more". So maybe a number in the property.
# [12:16] <TabAtkinsTPAC> jdaggett: Fallback behavior - I think I said behavior that quarter-width falls back to third-width, falls back to half-width, falls back to full-width. I think instead if one doesn't exist it should scale.
# [12:16] <TabAtkinsTPAC> fantasai: Or just have it overflow.
# [12:16] <TabAtkinsTPAC> szilles: I think if you had a year that was expeected to be a single line, splitting it into two segments would be confusing.
# [12:16] <TabAtkinsTPAC> jdaggett: Right.
# [12:18] <TabAtkinsTPAC> szilles: Also, tate-chu-yoko is sometimes done with letters, for acronyms like "IBM".
# [12:18] * Joins: mjs (mjs@84.14.50.82)
# [12:18] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [12:18] <TabAtkinsTPAC> jdaggett: Unfortunately, fonts have quarter-width numbers much more commonly than letters.
# [12:18] * Joins: exr2 (joonholee@84.14.50.82)
# [12:19] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [12:19] <TabAtkinsTPAC> ishida: Perhaps we should ask the Japanese here in our group what they think.
# [12:19] * Quits: cslye (cslye@84.14.50.82) (Quit: cslye)
# [12:19] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
# [12:19] * Quits: exr (joonholee@124.39.135.110) (Ping timeout)
# [12:19] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [12:19] <TabAtkinsTPAC> dbaron: Also, is falling back to scaling bettere than falling back to no tate-chu-yoko at all?
# [12:19] * Quits: shan (qw3birc@128.30.52.28) (Quit: Page closed)
# [12:19] * Quits: Kai (chatzilla@84.14.50.82) (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630])
# [12:19] * Quits: freedom (freedom@84.14.50.82) (Quit: freedom)
# [12:19] * Quits: komasshu (kensaku.ko@84.14.50.82) (Client exited)
# [12:19] * Quits: fsasaki (Felix@84.14.50.82) (Quit: This computer has gone to sleep)
# [12:20] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
# [12:21] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [12:21] * Quits: jdaggett (jdaggett@84.14.50.82) (Quit: jdaggett)
# [12:21] * Quits: parkjy (qw3birc@128.30.52.28) (Ping timeout)
# [12:21] * Quits: jun (jun@84.14.50.82) (Quit: jun)
# [12:22] * Quits: howcome (howcome@84.14.50.82) (Ping timeout)
# [12:22] * Quits: TabAtkinsTPAC (chatzilla@84.14.50.82) (Ping timeout)
# [12:23] * Quits: szilles (chatzilla@84.14.50.82) (Ping timeout)
# [12:23] * Quits: sylvaing (sylvaing@84.14.50.82) (Ping timeout)
# [12:24] * Joins: mjs (mjs@84.14.50.82)
# [12:24] * Quits: exr2 (joonholee@84.14.50.82) (Ping timeout)
# [12:25] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
# [12:25] * Quits: homata (homata@84.14.50.82) (Ping timeout)
# [12:25] * Quits: r12a-nb (ishida@128.30.52.28) (Ping timeout)
# [12:25] * Quits: hidetaka (hidetaka@84.14.50.82) (Ping timeout)
# [12:26] * Quits: johnjan (qw3birc@128.30.52.28) (Ping timeout)
# [12:27] * Quits: myakura (myakura@84.14.50.82) (Ping timeout)
# [12:27] * Joins: seungjae (seungjae@84.14.50.82)
# [12:28] * Quits: seungjae (seungjae@84.14.50.82) (Quit: seungjae)
# [12:28] * Joins: seungjae (seungjae@84.14.50.82)
# [12:29] * Quits: seungjae (seungjae@84.14.50.82) (Quit: seungjae)
# [12:30] * Joins: seungjae (seungjae@84.14.50.82)
# [12:31] * Quits: yuma_1986 (yuma_1985@84.14.50.82) (Ping timeout)
# [12:31] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [12:31] * Joins: yuma_1986 (yuma_1985@84.14.50.82)
# [12:33] * Joins: timeless_mbp (timeless@84.14.50.82)
# [12:35] * Joins: TabAtkinsTPAC (chatzilla@84.14.50.82)
# [12:37] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
# [12:37] * Quits: seungjae (seungjae@84.14.50.82) (Quit: seungjae)
# [12:38] * Quits: plinss_ (plinss@84.14.50.82) (Quit: plinss_)
# [12:40] * Quits: timeless_mbp (timeless@84.14.50.82) (Quit: timeless_mbp)
# [12:40] * Quits: TabAtkinsTPAC (chatzilla@84.14.50.82) (Ping timeout)
# [12:42] * Zakim excuses himself; his presence no longer seems to be needed
# [12:42] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [12:55] * Joins: glazou (glazou@84.14.50.82)
# [12:57] <MikeSmith> RRSAgent, make minutes
# [12:57] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html MikeSmith
# [12:59] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [13:11] * Parts: mollydotcom (mollyh@68.225.52.230)
# [13:14] * Joins: murakami (murakami@118.154.209.3)
# [13:18] * Joins: jdaggett (jdaggett@84.14.50.82)
# [13:25] * Joins: plinss_ (plinss@84.14.50.82)
# [13:28] * Joins: dsinger (dsinger@84.14.50.82)
# [13:31] * Joins: glazou (glazou@84.14.50.82)
# [13:32] * Joins: dethbakin (dethbakin@84.14.50.82)
# [13:32] * Joins: yuma_1987 (yuma_1985@84.14.50.82)
# [13:33] * Quits: yuma_1986 (yuma_1985@84.14.50.82) (Connection reset by peer)
# [13:34] * Joins: timeless_mbp (timeless@84.14.50.82)
# [13:34] * Joins: myakura (myakura@84.14.50.82)
# [13:35] * timeless_mbp is now known as timeless
# [13:35] * Joins: DavidClarke (DavidClark@82.144.242.94)
# [13:35] * Joins: anthony (qw3birc@128.30.52.28)
# [13:36] * Parts: anthony (qw3birc@128.30.52.28)
# [13:36] * Joins: r12a-nb (ishida@128.30.52.28)
# [13:36] * Joins: anthony (qw3birc@128.30.52.28)
# [13:36] * Joins: dbaron (dbaron@63.245.220.240)
# [13:36] * Joins: joonho (joonholee@124.39.135.110)
# [13:37] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [13:37] * Joins: shan (qw3birc@128.30.52.28)
# [13:37] * Joins: anne (annevk@84.14.50.82)
# [13:38] * Joins: jun (jun@84.14.50.82)
# [13:38] * Joins: mjs (mjs@84.14.50.82)
# [13:39] * Joins: freedom (freedom@84.14.50.82)
# [13:39] * Joins: shepazu (schepers@128.30.52.169)
# [13:40] * Joins: johnjan (qw3birc@128.30.52.28)
# [13:41] * Joins: sylvaing (sylvaing@84.14.50.82)
# [13:41] <sylvaing> scribenick: sylvaing
# [13:42] <timeless> RRSAgent, make minutes
# [13:42] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html timeless
# [13:43] <sylvaing> fantasai starts reviewing section 7 of http://dev.w3.org/csswg/css3-writing-modes/
# [13:43] <dbaron> http://dev.w3.org/csswg/css3-writing-modes/
# [13:43] <sylvaing> http://dev.w3.org/csswg/css3-writing-modes/#abstract-layout
# [13:43] <sylvaing> fantasai: i could not come up with a use-case for making overflow-x and overflow-y absolute
# [13:43] * Joins: alexmog (qw3birc@128.30.52.28)
# [13:43] <sylvaing> dbaron: people could have an expectation of what x and y map to ?
# [13:44] <sylvaing> fantasai: so y is the block direction and x is the line direction
# [13:44] <dbaron> transforms has translateX(), translateY(), skewX(), skewY()
# [13:44] <sylvaing> jdaggett, dbaron: x and y are used for transforms and map to a physical concept
# [13:45] * Joins: homata (homata@84.14.50.82)
# [13:45] * Joins: Kai (chatzilla@84.14.50.82)
# [13:45] <sylvaing> jdaggett: this is a really large change. the use-case is not clear to me.
# [13:46] * Joins: szilles (chatzilla@84.14.50.82)
# [13:46] <sylvaing> jdaggett: we are talking about transforming coordinate systems within the page
# [13:47] <sylvaing> plinss: it doesn't mean a true coordinate transform. this is attempting to solve a specific problem.
# [13:47] * Joins: fsasaki (Felix@84.14.50.82)
# [13:47] <sylvaing> plinss: it's just keeping overflow-x instead of having overflow-line-progression-direction
# [13:48] * Joins: hidetaka (hidetaka@84.14.50.82)
# [13:48] <sylvaing> dbaron: i think overflow-x and overflow-y horizontal and vertical (respectively)
# [13:48] <dbaron> ... and the spec should use the terms block-axis and inline-axis rather than redefining x-axis and y-axis
# [13:49] <sylvaing> jdaggett: why does vertical text require these changes ?
# [13:49] * Joins: glazou_ (glazou@84.14.50.82)
# [13:50] * Quits: glazou (glazou@84.14.50.82) (Connection reset by peer)
# [13:50] <timeless> q?
# [13:51] * Joins: komasshu (kensaku.ko@84.14.50.82)
# [13:51] * timeless discovers this group doesn't use zakim/q
# [13:51] <sylvaing> szilles: this is similar to asking why we need both flexbox and layout. we think they are valuable because they fit to certain tasks. likewise, these might be useful in some cases for people who use vertical text. Murakami-san's showed that it helped with maintenance.
# [13:51] <sylvaing> jdaggett: if you author content in both modes, yes
# [13:51] <sylvaing> jdaggett: this is still not related to vertical text
# [13:51] <sylvaing> aharon: logical properties are not just related to vertical text, they also matter for bidi
# [13:52] <sylvaing> aharon: the use-case for logical properties - start, end - in bidi is not theoretical
# [13:52] <sylvaing> aharon: an application that needs to support UI in different languages currently needs to provide different stylesheets.
# [13:52] <sylvaing> aharon: they're the same stylesheets, one effectively generate from the other
# [13:52] <timeless> s/start/(padding,*)-start/
# [13:52] <timeless> s/end/(padding,*)-end/
# [13:53] <sylvaing> aharon: e.g. margin-left in this stylesheet becomes margin-right in the other
# [13:54] <sylvaing> jdaggett: but is the stylesheet for vertical text really going to be a rotation of the western ltr stylesheet ? The design is not completely symmetrical e.g. controls may not rotate
# [13:54] <sylvaing> jdaggett: authors want to be able to describe what they'll do for this writing-mode vs. that other one.
# [13:55] <sylvaing> fantasai: this is not about making every automatic; there will still be a lot of fine-tuning e.g. drop shadows might have to change side
# [13:56] <sylvaing> fantasai: but this should get you 90%+ of what you need. for instance, for a book.
# [13:56] <sylvaing> howcome: you do want to set different values. duplicating properties does not address the problem
# [13:57] <sylvaing> dbaron: I think john is asking whether there is a use-case for having something that is vertical in one context and horizontal and another on the web. this is not about asking whether there is a use-case for vertical
# [13:57] <sylvaing> fantasai: is sharing the stylesheet between ltr and rtl a valid use-case ?
# [13:58] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [13:58] <r12a-nb> q+
# [13:58] * Zakim sees r12a-nb on the speaker queue
# [13:58] <sylvaing> fantasai: but if I want to do the same thing for my Japanese translation, it will not work ?
# [13:59] <sylvaing> jdaggett: this is not at all the same typography. Japanese layout is not rotated english
# [13:59] * glazou_ is now known as glazou
# [14:01] <sylvaing> jdaggett: in the webkit UA stylesheet, the default margin for paragraphs is 1em 0px. that's not a valid default for vertical Japanese paragraphs
# [14:02] <fantasai> koji: Whether paragraphs are separated by 1em margin or no margin + indentation is not a vertical vs. horizontal cas
# [14:02] <fantasai> e
# [14:02] <timeless> ack r12a-nb
# [14:02] * Zakim sees no one on the speaker queue
# [14:03] * Joins: parkjy (qw3birc@128.30.52.28)
# [14:03] <fantasai> koji: If you talk about blockquote default stylesheet, you want the left and right margins to 2em in horizontal mode. But in vertical mode you want top and bottom margins
# [14:04] <r12a-nb> q+
# [14:04] * Zakim sees r12a-nb on the speaker queue
# [14:05] <sylvaing> jdaggett: the claim that a UA stylesheet can be made to work as is by using logical properties is not true. that use-case is not addressed by logical properties
# [14:06] <sylvaing> jdaggett: a default for Latin text cannot be used as a default for Japanese text
# [14:06] <timeless> ack r12a-nb
# [14:06] * Zakim sees no one on the speaker queue
# [14:06] <szilles> q+
# [14:06] * Zakim sees szilles on the speaker queue
# [14:06] <johnjan> present: koji; dbaron; alexmog; jdaggett; sylvaing; johnjan; szilles; fantasai; plinss; howcome; shan
# [14:06] <timeless> q+ to ask what percentage of the problem needs to be solved
# [14:06] * Zakim sees szilles, timeless on the speaker queue
# [14:07] <timeless> present+ timeless
# [14:07] <sylvaing> r12a-nb: I thought the goal was to have the ability to move horizontal japanese to vertical japanese
# [14:07] <fantasai> fantasai: You're arguing that the default UA stylesheet, which specifies suboptimal layout for Japanese text whether in horizontal or vertical, must handle proper japanese layout in vertical
# [14:07] <fantasai> fantasai: but for horizontal layout it doesn't matter
# [14:07] <sylvaing> r12a-nb: I find logical properties much easier to use in practice
# [14:07] * Joins: mgylling (mgylling@84.14.50.82)
# [14:08] <sylvaing> jdaggett: the issues are: what do we need to support and change to do vertical text intelligently. then there are things that make it more convenient to write stylesheets. these things have been merged together
# [14:09] <sylvaing> jdaggett: retrofitting virtual properties in CSS is a large change.
# [14:09] <sylvaing> jdaggett: this doesn't address all the properties that may need to be affected
# [14:09] <sylvaing> fantasai: it covers all the properties in CSS2.1
# [14:09] * glazou pfffff first reaction I got after CSS WG photo twitted is "and of course Daniel is right between the two only ladies of the WG"
# [14:09] * Joins: howcome (howcome@84.14.50.82)
# [14:10] <sylvaing> jdaggett: but what about CSS3 properties such as border-radius ? what about 2d transforms and their coordinate spaces ?
# [14:10] <sylvaing> jdaggett: I don't think any of this is required to support vertical text.
# [14:11] <sylvaing> kojiishi: but what if Japanese users want to be able to change margin and padding logically ?
# [14:11] <sylvaing> jdaggett: then let's see what we can do for margin and padding
# [14:14] <sylvaing> szilles: the top and left are irrelevant to the task of laying out lines in blocks. I want to set properties on the beginning of the line, the end of the line, on the block etc.
# [14:15] <timeless> q?
# [14:15] * Zakim sees szilles, timeless on the speaker queue
# [14:15] * fantasai notes that we are discussing the very last section of the draft, with several intervening sections, and there's no way we're going to get to any of them now
# [14:15] <timeless> ack szilles
# [14:15] * Zakim sees timeless on the speaker queue
# [14:16] * sylvaing is in some kind of minuting hell
# [14:16] * Joins: jaeyeollim (chatzilla@84.14.50.82)
# [14:16] <fantasai> jdaggett: I don't think we should do this in one fell swoop
# [14:16] * timeless could try to help
# [14:16] <fantasai> jdaggett: I think we should add start and end keywords where needed e.g. in text-align
# [14:16] * timeless is not likely to be able to identify names
# [14:17] * sylvaing it's all right. just that we're going in a loop
# [14:17] * timeless chuckles
# [14:17] <fantasai> jdaggett: And then for margins and padding, we just add 'logical' keyword to the shorthands
# [14:17] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [14:17] <fantasai> jdaggett: and not deal with, e.g. border properties
# [14:17] * timeless boggles @Zakim
# [14:17] <sylvaing> kojiishi: so you're questioning the number of properties that should be logical ?
# [14:18] <fantasai> koji: So you are not against logical properties, you don't agree on the amount
# [14:18] <sylvaing> jdaggett: I think having a logical keyword in a small set of relevant shorthands is enough
# [14:18] * timeless frowns, does anyone have a link to real .jp sites that use vertical layout in IE?
# [14:18] <sylvaing> kojiishi: so you're not saying all margins should be physical
# [14:18] <sylvaing> jdaggett: I don't have a problem with retrofitting logical into the margin shorthand
# [14:18] * Zakim sylvaing, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [14:18] <fantasai> jdaggett: I think a logical keyword on the margin shorthand is sufficient
# [14:19] <timeless> RRSAgent, make minutes
# [14:19] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html timeless
# [14:19] <sylvaing> jdaggett: but we shouldn't try to make everything logical at once
# [14:19] <r12a-nb> q?
# [14:19] * Zakim sees timeless on the speaker queue
# [14:19] <sylvaing> discussion of Zakim's feelings follows
# [14:20] * timeless can't recall seeing zakim unhappy like this, -- having used zakim for a couple of yearrs
# [14:20] * Joins: cslye (cslye@84.14.50.82)
# [14:21] <sylvaing> szilles: it was said that it was an expensive change. for instance, it's expensive in storage. but the alternative involves multiple stylesheets. i think the computational issue is a red herring
# [14:21] <fantasai> szilles refers to messages on the mailing list that discuss the perf impact
# [14:21] <sylvaing> howcome: you're right, it's not a blocker. but it's expensive in other ways: for authors who get a lot of new properties
# [14:22] <sylvaing> howcome: adding a keyword to a shorthand, otoh, is reasonable
# [14:22] <sylvaing> howcome: likewise, we could have keywords for inside/outside for printing
# [14:23] <sylvaing> szilles: so you are OK with the ability to specify certain values in a logical coordinate system
# [14:23] <sylvaing> howcome: yes
# [14:23] * Joins: Aharon (aharon@84.14.50.82)
# [14:23] <Aharon> +queue
# [14:23] * Zakim sees timeless, Aharon on the speaker queue
# [14:24] <sylvaing> r12n-ab asks for an example of the logical keyword
# [14:24] <johnjan> fantasai fights the flip chart
# [14:24] <myakura> margin: logical? <length>{1, 4}
# [14:24] <sylvaing> the physical coordinate of the flip chart rotates in mid-air
# [14:25] <howcome> margin: script 1em 0px;
# [14:25] <howcome> margin: writing-mode 1em 0px;
# [14:25] <howcome> margin: beas 1em 0px; /* before-end-after-start */
# [14:25] <sylvaing> flip chart now stands in vertical-rl
# [14:26] <howcome> margin: tobi 1em 0px; /* top-outside-bottom-inside */
# [14:26] <sylvaing> jdaggett: so the logical keyword means that the shorthand values are slotted to top/right/bottom/left based on the writing-mode
# [14:26] <Bert> q?
# [14:26] * Zakim sees timeless, Aharon on the speaker queue
# [14:26] <sylvaing> jdaggett: this proposal is not what is in the spec
# [14:26] <sylvaing> szilles: the principal of logical direction has been accept
# [14:27] <timeless> s/accept/accepted/
# [14:27] <sylvaing> (howls of protest)
# [14:27] <sylvaing> jdaggett: not by doing this for so many properties
# [14:28] <sylvaing> (more Mozilla people standing up to make their point)
# [14:28] <timeless> (references to Dave Hyatt and Webkit)
# [14:28] <fantasai> dbaron: hyatt implemented it quickly because webkit's architecture makes logical properties easy
# [14:28] <fantasai> s/architecture/style system architecture/
# [14:28] * dsinger ooh, fun, are those logical howls or real physical howls?
# [14:28] <timeless> s/easy/easy based on an assumption which is not required by any specification/
# [14:29] <dbaron> s/style system architecture/data structure for storage of declarations within declaration blocks/
# [14:29] * sylvaing dsinger they have no starts or ends
# [14:29] * timeless chuckles
# [14:29] <fantasai> koji: But what you're saying is that you accept the idea of logical space, just not of scoping it so widely
# [14:29] <sylvaing> jdaggett agrees this is about scoping logical
# [14:30] <timeless> ack Aharon
# [14:30] * Zakim sees timeless on the speaker queue
# [14:31] <sylvaing> aharon: I think the situation with CSS2.1 with padding-right, padding-left etc. also involves a lot of properties already. why not just have shorthands ?
# [14:31] <sylvaing> jdaggett: I don't think we can remove properties
# [14:31] <sylvaing> aharon: but we may be able to deprecate properties that are harmful to i18n.
# [14:32] * fantasai would like to get rid of the border-radius longhands :)
# [14:32] * glazou is afraid deprecating will have just no effect on the web
# [14:32] * fantasai thinks that would help us more
# [14:32] <sylvaing> aharon: it's much easier to add logical than turning left to top etc
# [14:32] * glazou thinks turning directions is crazy
# [14:33] * dsinger I may be out of scope here, but if we are introducing a new idea -- edges that are relative to text or block progression directions -- introducing new words is better than overloading old ones, especially overloading left to mean top etc., which is just horribly confusing
# [14:33] * fantasai dsinger, nobody's suggesting that
# [14:34] * dsinger ok, I thought I had heard that
# [14:34] <sylvaing> aharon: in several of our rtl localization projects, we had to introduce a rule in the system to make sure 'left' and 'right' did not appear in our CSS templates
# [14:35] <sylvaing> aharon: we use start/end or absolute-left/absolute-right. 99% of the time, people mean start/end
# [14:35] <fantasai> s/99/95
# [14:36] * fantasai would use Word instead of CSS when writing a pamphlet, too...
# [14:36] * fantasai would not use Word instead of CSS when writing a thesis, however
# [14:36] * dsinger s/Word/InDesign/
# [14:37] <Bert> q?
# [14:37] * Zakim sees timeless on the speaker queue
# [14:37] <fantasai> koji agrees with aharon's assessment of physical vs. logical usage; same applies in horizontal vs. vertical
# [14:38] <sylvaing> aharon: most of the time when authoring a document that needs to be used both ways, logical is very useful
# [14:40] <sylvaing> fantasai: section 7 is split in multiple sections. 7.1. maps various parts of CSS21. No new values are introduced.
# [14:40] <sylvaing> fantasai: the only section that introduces new values is for caption-side
# [14:41] <sylvaing> fantasai: 7.3 is about HTML attributes; for replaced elements they're treated as absolute; on table elements these attributes are logical
# [14:41] <dbaron> I don't think we should make width and height attributes behave differently for different elements.
# [14:42] <sylvaing> bert: some of the terms used are also defined in the Box Model module. we should look at any overlaps and synch up the two modules
# [14:42] <sylvaing> fantasai: yes
# [14:42] <sylvaing> (now addressing dbaron's point)
# [14:43] <sylvaing> dbaron: I think it's going to be very confusing
# [14:43] <sylvaing> szilles: the proposal is that for those elements the width and height attribute are interpreted per the writing mode of the element
# [14:44] <sylvaing> fantasai: yes. the alternative is to ignore them
# [14:44] <sylvaing> dbaron: I'd rather add new HTML attributes
# [14:44] <sylvaing> szilles: see the other room
# [14:45] <sylvaing> dbaron: width and height attributes on table should not be logical while physical everywhere else as well as CSS width and height being physical. we should be 100% physical
# [14:46] <sylvaing> fantasai: section 8.1 http://dev.w3.org/csswg/css3-writing-modes/#logical-value
# [14:46] <sylvaing> defines properties that do before/after/start/end
# [14:47] <sylvaing> dbaron: note that caption-side already has 6 keywords
# [14:48] <sylvaing> jdaggett: I think vertical-align might need to have different defaults in vertical vs. horizontal. I need to confirm that but it'd need to default to middle in vertical
# [14:48] <sylvaing> jdaggett: vertical-align:auto ?
# [14:49] <sylvaing> howcome: I think adding new values is easier than adding properties
# [14:50] <sylvaing> fantasai: http://dev.w3.org/csswg/css3-writing-modes/#logical-page
# [14:50] * Joins: toto (toto@84.14.50.82)
# [14:51] * sylvaing had never thought of 'recto' in that way. thanks, jdaggett
# [14:51] <timeless> http://en.wikipedia.org/wiki/Recto_and_verso
# [14:51] <timeless> The verso is the "back" side and the recto the "front" side of a leaf of paper in a bound item such as a book, broadsheet, or pamphlet. ...
# [14:51] <timeless> en.wikipedia.org/wiki/Recto_and_verso
# [14:52] <sylvaing> fantasai: these have always been logical.
# [14:52] <sylvaing> fantasai: the original proposal was even and odd but if you change the page countering and things get confusing.
# [14:54] <sylvaing> howcome: I'm not sure we want to use the same stylesheet for an ltr book and an rtl book
# [14:55] <sylvaing> (arronei agrees with howcome)
# [14:55] <timeless> s/arronei/aharon/
# [14:55] <johnjan> s/aharon/arronei
# [14:56] * timeless ?
# [14:56] * Quits: hidetaka (hidetaka@84.14.50.82) (Ping timeout)
# [14:56] <sylvaing> aharon: what about front and back ?
# [14:56] <sylvaing> fantasai: that is usually interpreted as the first and last page
# [14:56] <johnjan> timeless: arronei pinged me
# [14:57] * timeless so this isn't the guy sitting at the end next to r12a-nb ?
# [14:58] <johnjan> correct
# [14:58] * sylvaing aharon linen, google
# [14:58] <glazou> s/linen/lanin ?
# [14:58] * sylvaing doh. yes, lanin
# [14:58] * timeless sylvaing: apparently the person being referenced is someone else
# [14:58] * Joins: toto_ (toto@84.14.50.82)
# [14:58] * sylvaing yes, arronei is a CSS tester as msft. he's not here.
# [14:59] * arron I am sitting in Seattle trying to weed through the IRC conversation. :)
# [14:59] * Quits: toto (toto@84.14.50.82) (Ping timeout)
# [14:59] <sylvaing> howcome: I think it's too early to spec the printing part of this.
# [14:59] * timeless wishes arron luck
# [14:59] * timeless is having trouble w/o being limited to irc
# [14:59] * sylvaing arronei, good luck with that. I'm here and I can't keep up
# [14:59] <glazou> g'luck arron ;-)
# [15:00] <timeless> [ a discussion of why 8.2 exists ]
# [15:01] <sylvaing> fantasai: the goal for these sections was to cover all of CSS2.1
# [15:01] <sylvaing> howcome: I don't think we should proceed until we understand spread layout
# [15:01] <timeless> [ the explanation for why 8.2 exists is because page-break-before/page-break-after exist, as clearly indicated in the first indented paragraph of 8.2 ]
# [15:02] <timeless> [ people explain how the binding side changes based on being LTR or TTB ]
# [15:02] * sylvaing logical-writing-mode-discussion-avoid: always
# [15:03] * timeless ...
# [15:03] <timeless> [ moving to 8.3 ]
# [15:04] * arron sylvaing, we could always talk about text-replace :)
# [15:04] <dbaron> q+
# [15:04] * Zakim sees timeless, dbaron on the speaker queue
# [15:04] <timeless> [ howcome is asked if he objects to logical-height ]
# [15:04] <timeless> [ howcome objects to adding anything ]
# [15:05] * dbaron should "anything" be "any new properties"?
# [15:05] <timeless> s/anything/any new properties/
# [15:05] * timeless shrugs, it's funnier the other way
# [15:05] <dbaron> ack dbaron
# [15:05] * Zakim sees timeless on the speaker queue
# [15:05] <timeless> q+ dbaron
# [15:05] * Zakim sees timeless, dbaron on the speaker queue
# [15:05] <dbaron> ack timeless
# [15:05] <Zakim> timeless, you wanted to ask what percentage of the problem needs to be solved
# [15:05] * Zakim sees dbaron on the speaker queue
# [15:06] <dbaron> ack dbaron
# [15:06] * Zakim sees no one on the speaker queue
# [15:07] * Quits: jaeyeollim (chatzilla@84.14.50.82) (Connection reset by peer)
# [15:07] * Quits: fsasaki (Felix@84.14.50.82) (Quit: This computer has gone to sleep)
# [15:07] * Joins: fsasaki (Felix@84.14.50.82)
# [15:08] <timeless> [ i asked my question. jdaggett indicated he felt the proposal by fantasai, et al addressed 150% and he wanted something simpler which could be implemented and then we would later investigate what else needs to be added later ]
# [15:08] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [15:08] <sylvaing> dbaron: the challenge of implementing the logical keyword is the number of pieces of information you need to cascade separately. so even though you have the same number of properties for the author , the implementation deals with 8 underlying properties
# [15:09] <dbaron> not really cascade, but store until you cascade
# [15:09] * Quits: jun (jun@84.14.50.82) (Quit: jun)
# [15:09] * sylvaing right. and 8 values, not 8 properties...right ?
# [15:09] * Quits: fsasaki (Felix@84.14.50.82) (Quit: This computer has gone to sleep)
# [15:10] <sylvaing> jdaggett: i'm not saying this solves all use-cases. but adding the logical keyword in those two places potentially covers a lot of use-cases.
# [15:11] <sylvaing> fantasai: i'm fine with scoping it to margin and padding but if we add the logical keyword we should also add support for before/after/start/end
# [15:12] * Joins: hidetaka (hidetaka@84.14.50.82)
# [15:12] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [15:13] <sylvaing> fantasai walks through an explanation of margin shorthand cascade and associated storage required...
# [15:14] <sylvaing> margin: logical 1em 2em 3em 4em;
# [15:14] <sylvaing> b e a s
# [15:14] <timeless> [ fantasai draws a paragraph ]
# [15:14] * Joins: jun (jun@84.14.50.82)
# [15:15] * timeless ... it's cute!
# [15:16] <timeless> margin-top: 5em;
# [15:16] * Quits: hidetaka (hidetaka@84.14.50.82) (Ping timeout)
# [15:16] <sylvaing> p { margin: logical 1em 2em 3em 4em; margin-top: 5em; }
# [15:17] <sylvaing> fantasai: if you don't store 8 values, margin-top would affect the physical right margin
# [15:17] * Joins: TabAtkinsTPAC (chatzilla@84.14.50.82)
# [15:18] <sylvaing> discussion of how inside/outside is even more fun to implement
# [15:20] <fantasai> argument was that you only need to store 4 values plus a flag if you only implement the shorthand
# [15:20] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [15:20] <fantasai> dbaron pointed out that 8 values is necessary
# [15:20] <fantasai> to store
# [15:20] <fantasai> fantasai walked through an example so people would understand
# [15:20] <timeless> s/is/are/
# [15:20] <fantasai> p { b e a s
# [15:20] <fantasai> margin: logical 1em 2em 3em 4em;
# [15:20] <fantasai> margin-top: 5em;
# [15:20] <fantasai> }
# [15:20] <fantasai> 4em
# [15:20] <fantasai> +--------------+
# [15:20] * Zakim wonders where --------------+ is
# [15:20] <fantasai> 3em | LR ||||||| <del>1em</del> <ins>5em</ins>
# [15:20] <fantasai> +--------------+
# [15:20] * Zakim wonders where --------------+ is
# [15:20] <fantasai> 2em
# [15:21] <sylvaing> jdaggett: i think just having a shorthand is intuitive for authors.
# [15:22] <sylvaing> plinss: but you use functionality. you can't just specify the start
# [15:22] <sylvaing> fantasai: I'm ok with just doing margin and padding for now. but i don't think the shorthands are sufficient
# [15:22] <sylvaing> plinss: wouldn't you need to do border as well ?
# [15:22] <sylvaing> fantasai: UA stylesheets only need margin and padding
# [15:23] <plinss_> s/use/lose/
# [15:23] <timeless> [ howcome suggests media queries ]
# [15:23] * sylvaing time for break
# [15:24] * Joins: hidetaka (hidetaka@84.14.50.82)
# [15:24] <timeless> scribe has noted that it's time for a break.
# [15:24] <timeless> the fact that people are talking locally instead of to the group supports this.
# [15:26] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
# [15:26] * Quits: jun (jun@84.14.50.82) (Quit: jun)
# [15:27] * Quits: joonho (joonholee@124.39.135.110) (Ping timeout)
# [15:27] * Quits: szilles (chatzilla@84.14.50.82) (Ping timeout)
# [15:27] * Quits: toto_ (toto@84.14.50.82) (Ping timeout)
# [15:28] * Quits: shan (qw3birc@128.30.52.28) (Ping timeout)
# [15:28] * Quits: dbaron (dbaron@63.245.220.240) (Ping timeout)
# [15:30] <myakura> RSSAgent, make minutes
# [15:30] <myakura> RRSAgent, make minutes
# [15:30] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html myakura
# [15:32] * Joins: shan (qw3birc@128.30.52.28)
# [15:33] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
# [15:33] * Joins: nimbupani (Adium@24.22.131.46)
# [15:33] * Parts: nimbupani (Adium@24.22.131.46)
# [15:37] <arron> From what I have gathered over IRC we have talked about these few options for logical properties:
# [15:37] <arron> a. leave everything as it is (all physical)
# [15:37] * Quits: komasshu (kensaku.ko@84.14.50.82) (Client exited)
# [15:37] <arron> b. create actual logical properties for all relevant cases
# [15:37] <arron> c. alter only the shorthand properties to take additional keyword(s)
# [15:38] <arron> d. create a small set of logical properties covering only a small set of cases
# [15:38] <arron> d.1. create only margin/padding-(start, end, before, after)
# [15:38] <arron> d.2. create only properties that do not take <length> as a value (e.g. border-*-color)
# [15:38] <arron> There might be a few others that I missed from the conversation but I think this covers the scenarios that have been discussed.
# [15:38] <arron> I am not saying that we should vote on these but I think we should really look at each one of these further and see the pros/cons of each. I am still not convinced that we all know the design/author side of these type of changes.
# [15:41] * Quits: yuma_1987 (yuma_1985@84.14.50.82) (Connection reset by peer)
# [15:41] * sylvaing arron, the big question here was whether and how much of this was needed to address vertical text in the first place
# [15:41] * arron yeah but I don't think we know enough to actually make that decision yet.
# [15:42] * arron hence the reason why the conversation is probably going round and round
# [15:42] * Joins: mgylling (mgylling@84.14.50.82)
# [15:43] * Joins: glazou (glazou@84.14.50.82)
# [15:43] * Joins: jun (jun@84.14.50.82)
# [15:46] * Joins: komasshu (kensaku.ko@84.14.50.82)
# [15:46] * sylvaing arron, yup. that it's very useful in some cases e.g. bidi makes it all the harder
# [15:49] * arron text-replace would solve the bidi cases probably.
# [15:50] * Joins: dbaron (dbaron@63.245.220.240)
# [15:51] * Quits: DavidClarke (DavidClark@82.144.242.94) (Ping timeout)
# [15:51] * glazou mouhahahaha :)
# [15:56] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
# [15:57] * Joins: szilles (chatzilla@84.14.50.82)
# [15:58] * Quits: freedom (freedom@84.14.50.82) (Ping timeout)
# [15:59] * Joins: freedom (freedom@84.14.50.82)
# [16:01] * Joins: mjs (mjs@84.14.50.82)
# [16:05] * Quits: Aharon (aharon@84.14.50.82) (Ping timeout)
# [16:05] <TabAtkinsTPAC> ScribeNick: TabAtkinsTPAC
# [16:06] * Quits: cslye (cslye@84.14.50.82) (Client exited)
# [16:07] * timeless notes we're discussing dropping things
# [16:07] * timeless ... to drive to a FPWD
# [16:08] * Joins: johnjan (qw3birc@128.30.52.28)
# [16:08] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-variant-alternates-prop
# [16:08] <jdaggett> topic: css3 fonts
# [16:08] <TabAtkinsTPAC> jdaggett: We've looked at this property before - opentype fonts have the capability to have alternate glyphs.
# [16:09] <TabAtkinsTPAC> jdaggett: There are many features that let you pick one of severeal alternates.
# [16:09] <TabAtkinsTPAC> jdaggett: In the past I specified this as just putting in a number to select a glyph. A lot of people objected to this.
# [16:09] * Joins: joonho (joonholee@84.14.50.82)
# [16:09] <TabAtkinsTPAC> jdaggett: It doesn't look nice, it doesn't play nice with fallback, etc.
# [16:10] * Joins: cslye (cslye@84.14.50.82)
# [16:10] <TabAtkinsTPAC> jdaggett: So Elika and I sat down and created a way to establish a name-value mapping that applies to a family or families, so when you select an alternate you use the named value, not a numbeer.
# [16:10] <TabAtkinsTPAC> jdaggett: If the font has that named value defined for it, it's used, otherwise it's ignored.
# [16:10] <TabAtkinsTPAC> jdaggett: The syntax is a new @-rule, @font-feature-values.
# [16:10] <TabAtkinsTPAC> jdaggett: Syntax is slightly different than what I had on the list originally.
# [16:11] <TabAtkinsTPAC> jdaggett: It takes severeal font variant definitions.
# [16:11] * Joins: dethbakin (dethbakin@84.14.50.82)
# [16:11] <TabAtkinsTPAC> jdaggett: Like @font-feature-values Jupiter Sans { swash: delicate 1, flowing 2; }
# [16:11] <TabAtkinsTPAC> jdaggett: And then "h2 { font-family: Jupiter Sans; } h2::first-letter { font-variant-alternates: swash(delicate); }"
# [16:12] <TabAtkinsTPAC> jdaggett: There are some features tha tonly take one value, but some take multiple values.
# [16:12] <jdaggett> http://www.typography.com/fonts/font_documentation.php?docID=6&productLineID=100026#sets
# [16:12] <TabAtkinsTPAC> jdaggett: [shows a font-variant page]
# [16:12] <TabAtkinsTPAC> jdaggett: This page goes through and defines all the selectors for different font features.
# [16:13] <TabAtkinsTPAC> jdaggett: So somebody using this font can enable these independently from each other.
# [16:13] <TabAtkinsTPAC> jdaggett: So in the opentype spec you have 20 of these features available. When you specify them via CSS you're specifying a set of them, so you want multiple values.
# [16:15] <TabAtkinsTPAC> jdaggett: The way I've defined this is that you can define multiple variants, and they all get turns on. Like "@font-feature-values Mars Serif { styleset: code 4 5; }", which turns on two separate features under the single label "code".
# [16:16] * Quits: freedom (freedom@84.14.50.82) (Quit: freedom)
# [16:16] <TabAtkinsTPAC> plinss: I think it's slightly confusing that you can use multiple declarations of the same type, and it means the same as a single comma-separated decl.
# [16:16] <TabAtkinsTPAC> fantasai: Maybe you could swap the name and the feature, so like "{ code: styleset 4 5; }"
# [16:18] <TabAtkinsTPAC> plinss: And what if you have another @font-feature later that defines another swash variant, frex?
# [16:18] * Joins: freedom (freedom@84.14.50.82)
# [16:18] <TabAtkinsTPAC> jdaggett: It continues to be additive. If you use the same name for thee value, it overrides the previous value of the same name, but otherwise different names for the same feature collect together.
# [16:20] <TabAtkinsTPAC> fantasai: [Here] you have a different things for styleset and character-variant.
# [16:20] <TabAtkinsTPAC> jdaggett: Right. character variants are just somewhat different than anything else.
# [16:22] <TabAtkinsTPAC> jdaggett: character-variant is the only feature that takes two values. Everything else takes one value.
# [16:22] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [16:24] <TabAtkinsTPAC> plinss: Suggestion for fixing the syntax implication - make @styleset, @swash, etc. sub-@rules underneath the @font-variant.
# [16:24] <TabAtkinsTPAC> [discussion of syntax variants]
# [16:26] * Joins: mjs (mjs@84.14.50.82)
# [16:27] <TabAtkinsTPAC> [appears to be consensus that later definitions for the same property/name should override]
# [16:29] <TabAtkinsTPAC> fantasai: In character-variant, since it only takes 1 or 2 numbers, if you put 3 numbers it should be an invalid rule, not just ignore the 3rd value.
# [16:30] <TabAtkinsTPAC> jdaggett: Are you okay with the syntax difference between character-variant and the other properties?
# [16:30] <TabAtkinsTPAC> fantasai: It's unfortunate, but not bad enough to overly object to.
# [16:30] * Joins: smfr (smfr@68.183.26.22)
# [16:32] <smfr> RRSAgent: pointer
# [16:32] <RRSAgent> See http://www.w3.org/2010/11/02-CSS-irc#T15-28-56
# [16:32] <fantasai> doodles:
# [16:32] <fantasai> @font-feature-values Jupiter Sans {
# [16:32] <fantasai> @styleset code 5 6;
# [16:32] <fantasai> @styleset swishy 5;
# [16:32] <fantasai> }
# [16:32] <fantasai> @font-feature-values Jupiter Sans {
# [16:32] <fantasai> swash: delicate 1, /* not apply */
# [16:32] <fantasai> flowing 2,
# [16:32] <fantasai> delicate 7;
# [16:32] <fantasai> }
# [16:32] <fantasai> @font-feature-values Jupiter Sans {
# [16:32] <fantasai> swash: delicate 1; /* not apply */
# [16:32] <fantasai> swash: flowing 2;
# [16:32] <fantasai> swash: delicate 7;
# [16:32] <fantasai> }
# [16:32] <fantasai> @font-feature-values Jupiter Sans {
# [16:32] <fantasai> code: styleset 5 6; /* not apply */
# [16:32] <fantasai> code: styleset 8;
# [16:32] <fantasai> swishy: styleset 5;
# [16:32] <fantasai> }
# [16:32] * Joins: yuma_1985 (yuma_1985@84.14.50.82)
# [16:32] <fantasai> @font-feature-values Jupiter Sans {
# [16:32] <fantasai> styleset {
# [16:32] <fantasai> code: 5, 6; /* not apply */
# [16:32] <fantasai> code: 8;
# [16:33] <fantasai> swishy: 5, 7, 9;
# [16:33] <fantasai> }
# [16:33] <fantasai> character-variant {
# [16:33] <fantasai> zeta: 20 3; /* cv20 = 3 */
# [16:33] <fantasai> }
# [16:33] <fantasai> }
# [16:33] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [16:34] * Joins: mjs (mjs@84.14.50.82)
# [16:38] * Joins: Aharon (aharon@84.14.50.82)
# [16:39] <fantasai> @font-feature-values Jupiter Sans {
# [16:39] <fantasai> styleset {
# [16:39] <fantasai> code: 5, 6; /* not apply */
# [16:39] <fantasai> code: 8;
# [16:39] <fantasai> swishy: 5, 7, 9;
# [16:39] <fantasai> }
# [16:39] <fantasai> character-variant {
# [16:39] <fantasai> zeta: 20 3; /* cv20 = 3 */
# [16:39] <fantasai> gamma: 12 5; /* cv12 = 5 */
# [16:39] <fantasai> }
# [16:39] * Quits: Aharon (aharon@84.14.50.82) (Quit: Aharon)
# [16:39] <fantasai> }
# [16:39] <fantasai> @font-feature-values Jupiter Sans {
# [16:39] <fantasai> @styleset code 5, 6; /* not apply */
# [16:39] <fantasai> @styleset code 8;
# [16:39] <fantasai> @styleset swishy 5, 7, 9;
# [16:39] <fantasai> @character-variant zeta 20 3; /* cv20 = 3 */
# [16:39] <fantasai> @character-variant gamma 12 5; /* cv12 = 5 */
# [16:39] <fantasai> }
# [16:39] <fantasai> @font-feature-values Jupiter Sans {
# [16:39] <fantasai> styleset: code 5 6, code 8, swishy 5 7 9;
# [16:39] <fantasai> character-variant: zeta 20 3, gamma 12 5;
# [16:39] <fantasai> }
# [16:39] <fantasai> fantasai: Problem with last option, even though it's more compact, is that repeating the declaration of a particular feature, it blows out all previous features
# [16:39] * Quits: mjs (mjs@84.14.50.82) (Connection reset by peer)
# [16:40] * Joins: mjs (mjs@84.14.50.82)
# [16:40] <fantasai> fantasai: I think it's better to allow an additive syntax, so either the @styleset syntax or the selector-like one
# [16:41] <fantasai> fantasai: The selector-like one has additive and overriding behavior that is is very closely analogous to existing CSS syntax
# [16:41] * Joins: yongil_jang (yongil@84.14.50.82)
# [16:41] <fantasai> jdaggett: In many cases you'll have a global style sheet that defines a bunch of feature, bu the author might want to tweak a few more in a local style sheet
# [16:42] <fantasai> jdaggett: in which case an additive behavior would be better than having a new feature declaration erase the old one
# [16:44] * timeless ... @break as fantasai runs out of power
# [16:47] * glazou jdaggett: see private message
# [16:47] * Quits: beverloo (peter@85.223.116.170) (Connection reset by peer)
# [16:48] * timeless jdaggett is standing up away from computer
# [16:48] <TabAtkinsTPAC> Bert: This all seems very complicated for something that is already complex.
# [16:48] * glazou timeless: let him know please ?
# [16:48] * timeless done
# [16:49] * glazou thanks Josh!
# [16:50] <TabAtkinsTPAC> cslye: Yes, but this isn't a feature that a normal author is going to use anyway. This is basically just for opentype junkies.
# [16:50] <TabAtkinsTPAC> Bert: I also don't like the fact that the value names are author-created, not standardized.
# [16:52] <TabAtkinsTPAC> Bert: There was another proposal for just turning on variants inside of a @font-face rule, so you could just define several font names with particular variants baked in.
# [16:52] * Parts: cslye (cslye@84.14.50.82)
# [16:52] <TabAtkinsTPAC> jdaggett: That option is also there.
# [16:52] * Joins: cslye (cslye@84.14.50.82)
# [16:54] <timeless> [ Digression to talk about Corporate Style Sheets]
# [16:55] * Joins: Peter` (peter@85.223.116.170)
# [16:55] <fantasai> Bert argues that this is complicated and people will have to learn it which is bad
# [16:55] <fantasai> Timeless and Bert discuss corporate style sheets and how this will require them to deal with syntax they don't want to learn
# [16:56] <fantasai> Peter turns this around and shows that this syntax allows better cascading behavior between corporate global and local style sheets
# [16:56] <fantasai> Peter: Say I have a corporate style sheet that defines an @font-face rule and that turns on various features
# [16:56] <fantasai> Peter: I want to turn on an additional two new features.
# [16:57] <fantasai> Peter: You're saying I have to copy the corporate @font-face rule into my local style sheet and tweak it.
# [16:57] <fantasai> Peter: A week later, corporate style sheet is updated, tweaking its features to be slightly differen
# [16:57] <fantasai> t
# [16:57] <fantasai> Peter: I don't pick up those changes because my @font-face rule overrides theirs
# [16:58] <fantasai> Peter: Whereas if I use this syntax, I can pick up those changes because it's additive rather than overriding
# [16:59] <TabAtkinsTPAC> howcome: In 4.1, it says "[downloaded fonts] must not be made availalbe to other applications or documents". I think it should be clear that things like caching don't violate this requirement.
# [17:01] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [17:02] <timeless> s/albe/able/
# [17:02] * Joins: bradk (bradk@99.7.175.117)
# [17:02] * Joins: mjs (mjs@84.14.50.82)
# [17:03] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
# [17:03] * johnjan slaps arronei around a bit with a large fishbot
# [17:03] <fantasai> dbaron: ping css3-values?
# [17:04] <dbaron> fantasai, probably should stay here for another half hour
# [17:04] * Joins: DavidClarke (DavidClark@82.144.242.94)
# [17:06] <arron> I am here
# [17:07] * Joins: bradk_ (bradk@99.7.175.117)
# [17:07] * Quits: freedom (freedom@84.14.50.82) (Ping timeout)
# [17:13] <johnjan> ah, hi arron.
# [17:13] <johnjan> we're waiting for the AC meeting to end, I believe.
# [17:13] <johnjan> 15 minutes.
# [17:13] <arron> ok, that gives me a few minutes to do email.
# [17:14] <glazou> johnjan: yes official end 17h30
# [17:16] * Joins: freedom (freedom@84.14.50.82)
# [17:16] <bradk> Hello
# [17:17] * Joins: murakami (murakami@118.154.209.3)
# [17:18] * arron waves to bradk from Seattle
# [17:22] <fantasai> Topic: MultiCol
# [17:23] <fantasai> Alex: Why aren't percentages are valid in column-width?
# [17:23] <fantasai> fantasai: Because it makes more sense to use column-number
# [17:23] <fantasai> howcome: And doesn't have the problem of what to do with 33% vs 34%
# [17:23] <fantasai> Alex: Other issue was column rules in overflow columns
# [17:24] <fantasai> Alex: Are rules drawn between overflow columns?
# [17:24] <fantasai> howcome: yes
# [17:24] <fantasai> discussion of column rules between empty columns
# [17:24] <fantasai> howcome: both of them have to be empty
# [17:24] <fantasai> Topic: position layout
# [17:25] * Quits: yongil_jang (yongil@84.14.50.82) (Ping timeout)
# [17:25] <TabAtkinsTPAC> http://www.xanthir.com/blog/b48H0
# [17:25] <fantasai> Tab: Position-layout extends the positioning power by letting you position edges of boxes relative to other arbitrary boxes
# [17:25] <fantasai> Tab: Some use cases...
# [17:26] <fantasai> Tab: In Google Docs, for example, when you're doing annotations, you'll attach annotations to particular spans of text
# [17:26] <fantasai> Tab: In that case you would set the top of the annotation to be equal to the text being annotation, and the other side to the doc edge
# [17:26] <fantasai> Tab: Also want to measure this edge from this other edge
# [17:27] * Quits: bradk_ (bradk@99.7.175.117) (Quit: Signing Off. Buh-bye. )
# [17:27] <fantasai> Tab: Our layout for our experimental newsreader app is good, but can only be done with a ton of fragile CSS hacks
# [17:27] <fantasai> Tab: There are three columns in importance of news
# [17:28] <fantasai> Tab: and then the rows represent timezones
# [17:28] * Quits: shan (qw3birc@128.30.52.28) (Ping timeout)
# [17:28] <fantasai> Tab: Stories are titles, or title and picture and blurb
# [17:28] <fantasai> Tab: Want to expand the story to take up the whole width
# [17:29] <fantasai> Tab: Wound up using a JS constraint solver to do this switching
# [17:29] <fantasai> Tab: Another issue is resize handles
# [17:30] <fantasai> Tab: Want to position them relative to whatever image you want to resize
# [17:30] <fantasai> fantasai: I'm a little concerned about prioritizing work
# [17:31] <fantasai> fantasai: and you're editing a lot of drafts
# [17:31] <fantasai> Tab: I want to work on this in the context of the CSSWG
# [17:31] * Quits: smfr (smfr@68.183.26.22) (Quit: smfr)
# [17:31] <fantasai> Tab: Want to have it in the charter
# [17:31] <fantasai> several concerned about prioritization of work and amount of work items
# [17:32] <fantasai> Tab: This is somewhat inspired by Daniel's proposals
# [17:32] <fantasai> Tab: ...
# [17:32] <fantasai> Tab talks about cycles and breaking cycles in the constraint solver
# [17:33] <fantasai> Tab talks about expanding functionality of fixed and absolute positioning
# [17:33] <fantasai> Tab: This is a superset of Daniel's proposal
# [17:34] * Joins: shan (qw3birc@128.30.52.28)
# [17:34] <fantasai> Alex: Is it specific to positioning, or do you want it to be more general and e.g. make this table row as wide as that table column
# [17:34] <fantasai> Tab: Don't want to expand beyond positioning. If it gets to complicated, it gets very very tangled
# [17:34] * Joins: yongil_jang (yongil@84.14.50.82)
# [17:35] <fantasai> Alex ... Instead of positioning, could be a special layout type
# [17:35] <fantasai> Alex: Instead of applying positioning anywhere, applies only within a particular element
# [17:35] <fantasai> Alex: a special kind of contianer
# [17:35] <fantasai> s/tian/tain
# [17:36] <fantasai> Tab: Interesting, but for now, I think I'd want to keep it as extension of positioning.
# [17:36] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [17:36] <fantasai> Tab: But let's talk and see if we can satisfies the use cases along the lines you're talking about
# [17:37] <fantasai> No one here objects to putting in charter as low priority
# [17:37] <fantasai> RESOLVED: add to charter as low priority
# [17:37] <fantasai> Topic: Transforms
# [17:38] <fantasai> Tab: Had a question of transforms applied to inlines
# [17:38] <fantasai> from Simon
# [17:38] <fantasai> Tab draws some text and a span
# [17:38] <fantasai>
# [17:38] <fantasai> .... bla bla bla RTL RTL RTL bla ...
# [17:39] <fantasai> Span breaks across multiple lines
# [17:39] <fantasai> Tab: When you rotate, how do you rotate?
# [17:39] <fantasai> Tab: First option is transforms don't apply to inlines
# [17:39] <fantasai> Tab: Second option is to make a bounding box. Transform the bounding box.
# [17:40] <fantasai> Tab: Third option is to transform each box of the element independently.
# [17:41] <fantasai> Tab: Sub-issue: are bidi boxes transformed independently
# [17:42] <fantasai> fantasai: I would go with the bounding box option
# [17:43] <fantasai> Tab: what do you do with page breaks/column breaks?
# [17:43] * dbaron notes ac meeting is ending
# [17:43] <fantasai> fantasai: use same bounding box def as for backgrounds
# [17:43] * Quits: jun (jun@84.14.50.82) (Quit: jun)
# [17:43] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [17:43] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [17:44] * Quits: Kai (chatzilla@84.14.50.82) (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630])
# [17:44] * Quits: mgylling (mgylling@84.14.50.82) (Quit: mgylling)
# [17:44] <fantasai> discussion of relpos
# [17:44] <fantasai> and how that works
# [17:44] * Quits: glazou (glazou@84.14.50.82) (Quit: glazou)
# [17:44] * Quits: DavidClarke (DavidClark@82.144.242.94) (Ping timeout)
# [17:44] <fantasai> Anthony: Browsers: Opera and FF, do not rotate text if you put in the span
# [17:44] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
# [17:44] <fantasai> Anthony: Mobile solutions do rotate
# [17:45] * Parts: freedom (freedom@84.14.50.82)
# [17:45] * Zakim excuses himself; his presence no longer seems to be needed
# [17:45] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [17:45] <fantasai> Anthony: I haven't tried multiline in SVG
# [17:46] * Joins: kennyluck (kennyluck@128.30.52.28)
# [17:47] <fantasai> fantasai: I would just use the bounding box definition from the old css3-background drafts. Seems the simplest
# [17:47] * Joins: mjs (mjs@84.14.50.82)
# [17:47] <arron> the simplest would be to not apply transforms to inlines.
# [17:48] <fantasai> well, true
# [17:48] * kennyluck RRSAgent, make minutes
# [17:48] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html kennyluck
# [17:49] <fantasai> fantasai: define 2 and mark it at risk (fall back to 1)
# [17:49] * Quits: szilles (chatzilla@84.14.50.82) (Ping timeout)
# [17:49] * Quits: MoZ (540e3252@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
# [17:49] <fantasai> RESOLVED: transforms apply to bounding box of the inline. Mark application of transforms to inlines at-risk. (Grab bounding-box definitions from old css3-background background-break drafts.)
# [17:50] <fantasai> Topic: css3-values
# [17:50] <johnjan> here we go
# [17:51] <fantasai> dbaron: I don't have anything to say...
# [17:51] <fantasai> arron, ping
# [17:51] * Quits: homata (homata@84.14.50.82) (Ping timeout)
# [17:51] * Quits: joonho (joonholee@84.14.50.82) (Quit: TakIRC)
# [17:51] <arron> I don't see the removal of min/max
# [17:51] <fantasai> wasn't it marked at-risk?
# [17:51] <arron> I thought we said we were going to remove those
# [17:51] <fantasai> no, we were going to mark them at-risk
# [17:52] <fantasai> http://www.w3.org/blog/CSS/2010/10/19/resolutions_126
# [17:52] * Quits: jgraham (jgraham@74.53.238.210) (Ping timeout)
# [17:52] * Joins: dbaron (dbaron@63.245.220.240)
# [17:53] <arron> Have all the updates been made? I am not seeing it in the Aug draft. Am I looking at the wrong version?
# [17:54] * Joins: glazou (glazou@84.14.50.82)
# [17:54] * Quits: MikeSmith (MikeSmith@84.14.50.82) (Quit: MikeSmith)
# [17:54] * fantasai doesn't know, should ask howcome
# [17:54] <fantasai> ?: Haptics proposal sent to www-style a couple months ago
# [17:54] <arron> Well If the updates have been made I have nothing more on this and we should just publish a new version
# [17:54] <ilkka> http://www.starlight-webkit.org/CSS/css3-haptics.html
# [17:55] <dbaron> s/?:/Ilkka Oksanen:/
# [17:55] <fantasai> Ilkka: Names in proposal not important
# [17:56] * Quits: glazou (glazou@84.14.50.82) (Client exited)
# [17:56] <fantasai> Ilkka: The use case we're trying to fulfill here is devices that have a touchscreen
# [17:56] <fantasai> Ilkka: can then have tactile feedback that's linked to the user interactions
# [17:57] <fantasai> Ilkka: Properties are style and strength
# [17:57] <fantasai> Alex: I know nothing about the area. Looks like different kind of feedback.
# [17:57] <fantasai> Alex: Seems like analogue of colors or sounds
# [17:58] <fantasai> Alex: Kind of properties I would expect are ... vibrate ...
# [17:58] <fantasai> Alex: I would expect that there are selectors that select when to feedback
# [17:58] * Quits: komasshu (kensaku.ko@84.14.50.82) (Client exited)
# [17:58] <dbaron> Aren't the descriptions of 'unchecked-checkbox' and 'checked-checkbox' backwards?
# [17:58] <fantasai> Alex: and then style the items
# [17:58] <fantasai> Tab: Use case is mobile phone applications
# [17:59] <fantasai> Tab: Using names rather than specifying effects is to match OS conventions
# [17:59] * Quits: anne (annevk@84.14.50.82) (Quit: anne)
# [17:59] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
# [17:59] <fantasai> Alex: Buttons etc. UI elements are in the system. Why doesn't it just launch the appropriate haptics?
# [18:00] <fantasai> Peter: Use case is for adding button feel to things that arent' actually buttons
# [18:00] <fantasai> jdaggett: So it's like the system colors?
# [18:00] <timeless> s/arent'/aren't/
# [18:01] <dbaron> and the input[type="radio"] style also seems backwards (shouldn't it be -down rather than -up?)
# [18:01] <fantasai> Peter: Have an issue where starting activation, ending activation might need separate effects
# [18:01] <fantasai> Peter: Have same issue with transitions
# [18:01] * Quits: mjs (mjs@84.14.50.82) (Quit: mjs)
# [18:02] <fantasai> Discussion of conferring semantics
# [18:02] <fantasai> Discussion of triggers
# [18:02] <fantasai> Alex: Are there hidden triggers that are not available for any other feedback, like color?
# [18:03] <fantasai> Alex: If a browser implementing this has to implement internal triggers
# [18:03] <fantasai> Alex: Why not make triggers available to other effects?
# [18:03] <fantasai> Peter: We had related discussion at Apple wrt transitions -- we don't have ability to trigger transitions in and transitions out
# [18:04] <fantasai> dbaron: Doesn't seem to be related to :active
# [18:04] <fantasai> dbaron: Just what happens when you touch the element
# [18:04] <fantasai> Ilkka: The feedback is not related to how long you touch the element
# [18:04] <fantasai> Ilkka: When I touch an element on touchscreen, the vibrator is activated
# [18:05] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
# [18:05] * Quits: hidetaka (hidetaka@84.14.50.82) (Ping timeout)
# [18:05] <fantasai> dbaron: The spec is defining this as an inherited property, which seems reasonable.
# [18:05] <fantasai> dbaron: Don't see a problem with this applying to things that cannot be :active
# [18:06] <fantasai> Peter: Does this apply to everything? Or only if I have something that has buttonlike behavior?
# [18:06] <fantasai> Peter: What happens if I apply unlatch to a ?
# [18:06] * Joins: hidetaka (hidetaka@84.14.50.82)
# [18:06] <fantasai> dbaron: Not a good idea to do that?
# [18:06] * Parts: cslye (cslye@84.14.50.82)
# [18:06] <fantasai> dbaron: I think the default of the type being none is needed
# [18:06] <fantasai> dbaron: given the strength default is none
# [18:08] * Quits: r12a-nb (ishida@128.30.52.28) (Ping timeout)
# [18:08] <fantasai> Peter: If I style a like a button and add haptics, will it behave like a button?
# [18:08] <fantasai> dbaron: No, it just feels like a button when you touch it.
# [18:08] <fantasai> fantasai: This is like a property to make a sound when you click the mouse on an element.
# [18:08] <fantasai> fantasai: except it's not a sound
# [18:09] <dbaron> And the default style sheet shouldn't use '-webkit-'
# [18:09] * Joins: jgraham (jgraham@74.53.238.210)
# [18:10] * Quits: parkjy (qw3birc@128.30.52.28) (Quit: Page closed)
# [18:11] <fantasai> Peter: There are issues here similar to 'appearance', transitions, etc.
# [18:11] <fantasai> jdaggett: How common is it for phones to implement all the types you list?
# [18:12] <fantasai> jdaggett: Or rather, are all UAs on all phones capable of matching those types to something reasonable?
# [18:12] <fantasai> jdaggett: We have this problem with system colors, where it only maps reasonably in Windows 3
# [18:13] <fantasai> Peter: So should we scope this into the UI module?
# [18:13] <fantasai> jdaggett: Also, would you want to do this to other types of feedback? e.g. iphone uses sound
# [18:14] <fantasai> Peter describes a haptic mouse he had along time ago that gave the feel of running over a button when you cursored over a ubtton
# [18:15] * Quits: dethbakin (dethbakin@84.14.50.82) (Quit: dethbakin)
# [18:15] * Quits: yuma_1985 (yuma_1985@84.14.50.82) (Quit: TakIRC)
# [18:15] <fantasai> Meeting closed.
# [18:15] * Quits: jdaggett (jdaggett@84.14.50.82) (Quit: jdaggett)
# [18:15] * Quits: sylvaing (sylvaing@84.14.50.82) (Quit: sylvaing)
# [18:15] * Joins: hidetaka_ (hidetaka@84.14.50.82)
# [18:15] * Quits: hidetaka (hidetaka@84.14.50.82) (Ping timeout)
# [18:16] * Quits: plinss_ (plinss@84.14.50.82) (Quit: plinss_)
# [18:16] <myakura> RRSAgent, make minutes
# [18:16] <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html myakura
# [18:17] * Quits: anthony (qw3birc@128.30.52.28) (Quit: Page closed)
# [18:17] * Quits: TabAtkinsTPAC (chatzilla@84.14.50.82) (Ping timeout)
# [18:18] * Quits: howcome (howcome@84.14.50.82) (Ping timeout)
# [18:20] * Joins: homata (homata@84.14.50.82)
# [18:22] * Quits: johnjan (qw3birc@128.30.52.28) (Ping timeout)
# [18:23] * Quits: myakura (myakura@84.14.50.82) (Ping timeout)
# [18:23] * Quits: yongil_jang (yongil@84.14.50.82) (Quit: 전 이만 갑니다.)
# [18:23] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
# [18:24] * Joins: myakura (myakura@84.14.50.82)
# [18:26] * Quits: shan (qw3birc@128.30.52.28) (Quit: Page closed)
# [18:32] * Joins: plinss_ (plinss@212.180.75.100)
# [18:32] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [18:33] * Quits: bradk (bradk@99.7.175.117) (Quit: Computer has gone to sleep)
# [18:33] * Quits: myakura (myakura@84.14.50.82) (Ping timeout)
# [18:36] * Quits: timeless (timeless@84.14.50.82) (Quit: timeless)
# [18:37] * Parts: arron (Arron@24.17.123.244)
# [18:37] * Joins: arron (Arron@24.17.123.244)
# [18:37] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [18:39] * Quits: plinss_ (plinss@212.180.75.100) (Quit: plinss_)
# [19:03] * Quits: homata (homata@84.14.50.82) (Ping timeout)
# [19:04] * Quits: hidetaka_ (hidetaka@84.14.50.82) (Ping timeout)
# [19:10] * Joins: Hixie (ianh@129.241.93.37)
# [19:13] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [19:24] * Quits: kennyluck (kennyluck@128.30.52.28) (Quit: kennyluck)
# [20:08] * Joins: dsinger (dsinger@84.14.50.82)
# [20:18] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
# [20:41] * Joins: dsinger (dsinger@84.14.50.82)
# [20:42] * Quits: dsinger (dsinger@84.14.50.82) (Connection reset by peer)
# [20:44] * Joins: Ms2ger (Ms2ger@91.181.144.192)
# [20:47] * Joins: anne (annevk@80.14.101.159)
# [20:47] * Joins: dsinger (dsinger@84.14.50.82)
# [20:48] * Quits: dsinger (dsinger@84.14.50.82) (Quit: dsinger)
# [21:32] * Quits: Ms2ger (Ms2ger@91.181.144.192) (Quit: nn)
# [21:37] * Quits: Martijnc (Martijnc@91.176.19.240) (Ping timeout)
# [21:43] * Joins: Martijnc (Martijnc@91.176.227.6)
# [21:45] * Joins: plinss_ (plinss@212.180.75.100)
# [22:08] * Quits: anne (annevk@80.14.101.159) (Quit: anne)
# [22:19] * Joins: nimbupani (Adium@24.22.131.46)
# [22:27] * Joins: hidetaka (hidetaka@81.253.24.125)
# [23:05] * Joins: jdaggett (jdaggett@93.158.28.13)
# [23:24] * Quits: jdaggett (jdaggett@93.158.28.13) (Quit: jdaggett)
# [23:33] * Quits: plinss_ (plinss@212.180.75.100) (Ping timeout)
# [23:34] * Joins: plinss_ (plinss@212.180.75.100)
# [23:37] * Quits: arronei (arronei@131.107.0.94) (Ping timeout)
# [23:41] * Joins: arronei (arronei@131.107.0.94)
# [23:46] * Joins: plinss__ (plinss@212.180.75.100)
# [23:46] * Quits: plinss_ (plinss@212.180.75.100) (Connection reset by peer)
# [23:54] * Quits: plinss__ (plinss@212.180.75.100) (Ping timeout)
# Session Close: Wed Nov 03 00:00:00 2010

The end :)