/irc-logs / w3c / #css / 2013-06-07 / end

Options:

# Session Start: Fri Jun 07 00:00:00 2013
# Session Ident: #css
# [00:01] * Joins: arno (~arnog@public.cloak)
# [00:01] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [00:04] * Joins: zcorpan (~zcorpan@public.cloak)
# [00:06] * Joins: dbaron (~dbaron@public.cloak)
# [00:08] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [00:10] * Joins: sgalineau (~sgalineau@public.cloak)
# [00:10] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [00:10] * Joins: sgalineau (~sgalineau@public.cloak)
# [00:14] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [00:20] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
# [00:25] * Joins: arno (~arnog@public.cloak)
# [00:31] * Joins: glenn (~gadams@public.cloak)
# [00:36] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [00:55] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [00:56] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [00:58] * Joins: SimonSapin (~simon@public.cloak)
# [01:00] * Joins: zcorpan (~zcorpan@public.cloak)
# [01:11] * Quits: r12a (rishida@public.cloak) (Ping timeout: 180 seconds)
# [01:22] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [01:44] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [01:52] * Joins: shans__ (~shans@public.cloak)
# [01:53] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:58] * Joins: glenn (~gadams@public.cloak)
# [02:01] * Joins: MikeSmith (~MikeSmith@public.cloak)
# [02:02] * Parts: MikeSmith (~MikeSmith@public.cloak) (MikeSmith)
# [02:03] * Joins: rhauck (~Adium@public.cloak)
# [02:06] * Joins: dbaron (~dbaron@public.cloak)
# [02:07] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [02:08] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [02:10] * Joins: zcorpan (~zcorpan@public.cloak)
# [02:16] * Parts: rhauck (~Adium@public.cloak) (rhauck)
# [02:16] * Joins: rhauck (~Adium@public.cloak)
# [02:17] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [02:19] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [02:19] * Joins: lmclister (~lmclister@public.cloak)
# [02:20] * Joins: SimonSapin (~simon@public.cloak)
# [02:24] * Joins: leif (~lastorset@public.cloak)
# [02:24] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [02:27] * Joins: myakura (~480ee730@public.cloak)
# [02:31] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [02:33] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [02:34] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [02:34] * Joins: leif1 (~lastorset@public.cloak)
# [02:35] * Quits: leif (~lastorset@public.cloak) (Client closed connection)
# [02:40] * Joins: cabanier (~cabanier@public.cloak)
# [02:41] * Joins: SimonSapin (~simon@public.cloak)
# [02:42] * Quits: leif1 (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [02:42] * Joins: dbaron (~dbaron@public.cloak)
# [02:43] <dbaron> trackbot, start meeting
# [02:43] * trackbot is preparing a teleconference.
# [02:43] <trackbot> RRSAgent, make logs member
# [02:43] <RRSAgent> I have made the request, trackbot
# [02:43] * Joins: Zakim (zakim@public.cloak)
# [02:43] <trackbot> Zakim, this will be Style_CSS FP
# [02:43] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [02:43] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [02:43] <trackbot> Date: 07 June 2013
# [02:43] <dbaron> Zakim, remind us in 8 hours to go home
# [02:43] <Zakim> ok, dbaron
# [02:43] <dbaron> RRSAgent, make logs public
# [02:43] <RRSAgent> I have made the request, dbaron
# [02:46] * Joins: leif (~lastorset@public.cloak)
# [02:46] * Joins: glenn (~gadams@public.cloak)
# [02:46] * Joins: ivan (ivan@public.cloak)
# [02:46] * Joins: kazutaka (~kazutaka@public.cloak)
# [02:47] * Joins: krit (~krit@public.cloak)
# [02:47] * Quits: myakura (~480ee730@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [02:47] * Joins: glazou (~glazou@public.cloak)
# [02:47] * Joins: myakura (~480ee730@public.cloak)
# [02:48] * Joins: liam (liam@public.cloak)
# [02:48] * Joins: plh (plehegar@public.cloak)
# [02:48] * Joins: Rossen (~Rossen@public.cloak)
# [02:48] <glazou> ScribeNick: Rossen
# [02:48] <Rossen> topic: Selectors 4
# [02:50] * Quits: glazou (~glazou@public.cloak) (glazou)
# [02:50] * Joins: glazou (~glazou@public.cloak)
# [02:54] <dbaron> topic: February-or-so Face-to-Face
# [02:54] <dbaron> dbaron: want to do a doodle for scheduling
# [02:54] * Bert suggests Dudle instead of Doodle, it's easier to use: https://dudle.inf.tu-dresden.de/?css=css/PrimeLife.css
# [02:55] <dbaron> [discussion of contintents, probably North America's turn]
# [02:55] <dbaron> [discussion of who can host, and who just hosted]
# [02:56] <Rossen> Feb is NYC tentative
# [02:56] * Joins: dino (~dino@public.cloak)
# [02:57] <dbaron> (some were going to look into hosting in California too, I think?)
# [02:57] <liam> ScribeNick: Liam
# [02:57] <Rossen> nm last topic... new topic is Grid
# [02:57] <TabAtkins> http://dev.w3.org/csswg/css-grid/
# [02:57] * Joins: r12a (rishida@public.cloak)
# [02:57] <liam> Tab: section 1...
# [02:58] <liam> [question of scope from fantasai]
# [02:58] <liam> question is about snapping items to grid
# [02:58] <liam> you cn already align things, but this is moer about sizing things
# [02:58] <liam> s/cn/can/
# [02:58] <liam> proposal from Tab is to push snap-to-grid off to a later spec
# [02:58] <liam> no objections
# [02:58] <liam> glazou: accepted.
# [02:59] <liam> tab: section 4.1 issue 3
# [02:59] <liam> positions of things not explicitly given a grid position
# [02:59] <liam> s/4.1/4/
# [03:00] <liam> [Tab goes through the four options in the isue]
# [03:00] <liam> s/isue/issue/
# [03:01] <liam> fantasai: [draws on the board]
# [03:01] <liam> 1. always auto-position
# [03:01] <liam> (by default)
# [03:01] <liam> 2. put unpositioned elements in slot 1 1
# [03:02] <liam> 3. add ability to define a default slot, and then do either 1 or 2
# [03:03] <liam> bert:first look at area, then look at flow, then look at normal positions just a process
# [03:03] <liam> tab: this is for the case there's no explicit position
# [03:03] <liam> Bert: if y udon't have a grid area there's still flow-into that may give you a position
# [03:03] <liam> fantasai: yuo have a doc, e.g 5 elements in body, and the only style is display:grid on the body
# [03:04] <liam> so these subelements have no explicit styles at all
# [03:04] <liam> bert: then they all go into the default slot
# [03:04] <liam> tab: what happens if yuo don't define a default slot?
# [03:04] <liam> bert: but 1 1 might be an empty slot
# [03:04] <liam> Rossen: we currently do 1 1
# [03:05] <liam> toggling display: grid on/off will have no effect in that case for us
# [03:05] <liam> if yuo have al lof the in one anyonymous grid item
# [03:06] <liam> alan: if you had discontiguous elements you might not want to put them all into the same container
# [03:06] <liam> fantasai: adv. of auto-positioning is that things don't pile on top of each other
# [03:07] <liam> adv. of everything piling up is tha tyou don't change the size of the grid, but then you can't see the top
# [03:08] <liam> tab: if you're using grid and not positioning things, you're doing it wrong
# [03:08] <liam> Rossen, we were strongly considering (4)
# [03:08] <liam> 4. Flow everything together into the default slot.
# [03:09] <liam> e.g. if there are 3 P elements you get all 3 stacked separately
# [03:09] <liam> alan: it runs into the complications we had with named flows
# [03:09] <liam> e.g. margins collapsing
# [03:10] * Joins: jet (~junglecode@public.cloak)
# [03:10] <jet> TabAtkins: @door with others
# [03:11] * Quits: jet (~junglecode@public.cloak) (jet)
# [03:11] <liam> tab: floxbox now, all elements get coerced into flex items
# [03:12] <liam> other option: autoposition everything with autoflow: row
# [03:12] <liam> margins will no longer collapse when grid is toggled but it'll be more like flexbox
# [03:13] <liam> fantasai: [agrees]
# [03:13] <liam> so either autoposition, or do the flow
# [03:13] <liam> bert: I'd like this to be more compatible with regions
# [03:13] <liam> tab: wherever we have slot pseudoelements they should be able to accept grid as well
# [03:13] * Joins: jdaggett (~jdaggett@public.cloak)
# [03:13] <liam> dbaron: I'm concerned about difficulty of implementation
# [03:14] <dbaron> I'm concerned about the difficulty of doing 4.
# [03:14] <liam> fantasai: I'm inclined to go with 1
# [03:14] <liam> alan: 4 isn't quite regions, still in same parent
# [03:14] <dbaron> fantasai: ... consistent with the way flexbox works, so you switch from flexbox to grid
# [03:14] <liam> tab: but taking discontiguous flow elements together
# [03:15] * Joins: Koji (~Koji@public.cloak)
# [03:15] <liam> tab: doing 4 is basically equiv. to taking all the flow items out and then taking what is left
# [03:15] <liam> and putting it into one big anonymous grid item in the default slot
# [03:15] * Joins: jet (~junglecode@public.cloak)
# [03:16] <liam> dbaron: presumably you can't have absolute positioning on grid items
# [03:16] <liam> tab: right, then it's not a grid item
# [03:16] <liam> alan: default slot is * or 1 1 if there isn't a * ?
# [03:16] <liam> tab: [agrees]
# [03:16] <liam> tab: template draft uses @ for it
# [03:16] * Joins: jdovey (~jdovey@public.cloak)
# [03:16] <liam> tab: we'll add properties for specifyingit
# [03:17] <liam> alan: if yo uhave more than one cell marked with a * ?
# [03:17] <liam> bet: an error if disjoint
# [03:17] <liam> s/bet/Bert/
# [03:17] <liam> fantasai: [elimination game for other alternatives]
# [03:18] <liam> 1 stacking everything on top of each other, i.e. auto position by default
# [03:18] <liam> Rossen: that's what we do today
# [03:19] <liam> 4: flow everything together into the default slot.
# [03:19] <liam> bert: 11 might be empty, "."
# [03:20] <liam> tab: so, if there's no eplicit default slot define, use a row-major seacrh to find the first non-empty slot and use that.
# [03:20] <liam> s/eplicit/explicit/
# [03:21] <liam> alan: if you want to avoid overlap, sometimes you'll have to create a new row.
# [03:22] <liam> tab: sometimes you'll need to specify a default position
# [03:22] <liam> bert: ok
# [03:22] <liam> this is fallback behaviour anyway
# [03:23] <liam> decision: accept proposal 4 for issue 3 in section 4 of css-grid, flow everything not explicitly grid-positioned together into a single item which is then auto-positioned, into the default slot or the first available slot
# [03:25] <liam> issue 4, non-children grid items
# [03:25] * trackbot doesn't understand that ISSUE command.
# [03:26] <liam> [[ This is a proposal to create the ability to have descendants of a grid item participate in a grid layout, similar to the behavior defined by the Template Layout module. ]]
# [03:26] <liam> position: grid makes a non-grid item an item in the nearest enclosing grid; if there's no such ancestor the item remains in the flow.
# [03:26] <liam> dbaron: what if it gives no position?
# [03:27] <liam> alan: it becomes a grid item
# [03:27] <liam> tab: so it must be autopostioned
# [03:27] <liam> tab: how about if we only do this if the item has both position: grid and an explicit position?
# [03:28] <dbaron> peterl: what about using the fact that it's positioned in a grid instead of using position:grid?
# [03:28] * liam could not hear plinss
# [03:28] * liam thanks
# [03:28] <liam> tab: we do need an explicit flag, "I want to be a grid item"
# [03:29] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [03:29] <liam> I'd be fine amending this to say you must also provide explicit positioning in addition to grid: position
# [03:29] * Joins: isra (~inoto@public.cloak)
# [03:29] <liam> If you're positioning to a named area/gridline, and the nearest grid doesn't have that, the spec says keep moving up the tre until yuo find a grid with that line
# [03:29] <liam> or we could say, you failed
# [03:29] <liam> s/tre /tree /
# [03:29] <liam> benefis - you can refer to the page grid anywhere in the document
# [03:30] <liam> plinss, is that true if you're asking for a line ot in yur grid?
# [03:30] <liam> fantasai: if you wanted to make that work yuo could just say position:grid on taht item
# [03:30] <liam> s/plinss,/plinss:/
# [03:31] <liam> tab: a normal line item referencing a line not in its grid just pops up?
# [03:31] * Quits: isra (~inoto@public.cloak) ("Leaving.")
# [03:31] <liam> fantasai: what if you speciy two grid lines and they come from different grids?
# [03:31] <liam> tab: goes in the first grid it can find
# [03:32] <liam> bert: so we'reusing the position property to turn this on?
# [03:32] <liam> tab: yes, if you're not a direct child of a grid
# [03:32] <liam> we have otehr ways we want to use the position properties so we want to make it an explicit switch
# [03:32] <liam> bert: you only do that for elements that are themselves of grid items?
# [03:33] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [03:33] <liam> fantasai: any descendent of a grid can take position: grid and become a participant in that grid
# [03:33] <liam> tab: what if yuo can't find something with tha tname?
# [03:33] <liam> maybe they should be autopositioned in the nearest grid?
# [03:33] * Joins: projector (~projector@public.cloak)
# [03:34] <liam> if you're a grandchild of a grid you need to opt in explicitly, if you're a child it's automatic
# [03:35] <liam> bert: default, you're inside your parent, that's always the case, so yuo want to become a grid item to be positioned differently, ok
# [03:35] <liam> Rossen: but if yuo have a name line that doesn't match you'll have a silent fail, Peter was saying, and that's not [good
# [03:35] <liam> ]
# [03:36] <liam> if you don't find any lines you should still be positioned in the closest grid you find
# [03:36] <liam> alan: be good to spearate the fallback from the sub-grid that works
# [03:36] <liam> tab: [agreed]
# [03:36] <liam> alan: on the subgrid that works I agree with Peter, display:gri isn't needed, using the grid properties should make you a grid item
# [03:36] <liam> plinss: nok because there are other uses for the properties
# [03:37] <liam> tab: section 4.2 has the abspos case
# [03:37] <liam> [4.2. Absolutely-positioned Grid Children http://dev.w3.org/csswg/css-grid/#abspos-items]
# [03:37] * Quits: myakura (~480ee730@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [03:37] <liam> fantasai: [draws a diagram]
# [03:37] * Joins: myakura (~myakura@public.cloak)
# [03:38] <liam> fantasai: everything is like abs-pos except that if the containing block is a grid you can position yourself with respect to the grid lines
# [03:39] <liam> tab, peter [discuss possible changes to abs pos]
# [03:39] <liam> tab: we don't want to change abs-pos too much
# [03:39] <liam> plinss: but the abs-pos'd items don't affect the grid layout
# [03:40] * liam not sure that was a good transcription
# [03:40] <liam> plinss, what if fixed position?
# [03:40] <liam> dbaron: with transforms, fixed works like abspos
# [03:41] <liam> tab: assuming fixed-pos can find a containing grid it should work just like abs
# [03:41] <liam> tab: example: {
# [03:41] <liam> grid-row-start: 2, auto
# [03:41] <liam> grid-col-end: auto
# [03:41] <liam> s/row-/col-/
# [03:41] <liam> }
# [03:42] <liam> tab: wondering about this only for abs-pos'd items
# [03:42] <liam> fantasai: if it's all auto you use the outer edge
# [03:43] <liam> plinss: a little bothered it's different for abspos and grid items
# [03:43] <liam> plinss: need to make sure auto gets you a regular abs-pos behaviour
# [03:43] * Quits: rhauck (~Adium@public.cloak) (Client closed connection)
# [03:44] <liam> tabL you can use the grid-col properties to change your containing block, for abs-pos
# [03:44] <glazou> test
# [03:45] <liam> plinss: normal abs positioning of the column edge, [scribe missed]
# [03:45] * Joins: r12a (rishida@public.cloak)
# [03:45] * Quits: projector (~projector@public.cloak) ("Page closed")
# [03:45] <myakura> s/tabL/tab:/
# [03:46] <liam> fantasai: if you have a grid ... [draws] that's 1 x 1 , autosized ...
# [03:47] <liam> my vertical gridlines will be, content edge, and sized out
# [03:48] <liam> so e.g. align: centre should centre that box (the grid) in the containing block
# [03:48] <liam> so the abs pos first and last grid line, you'll align to those, wherever they end up being
# [03:48] <liam> may or may not correspond to the content of th box
# [03:49] <liam> abspos auto means the normal containing block edge
# [03:49] <liam> plinss: but if it's a grid item it means something slightly different
# [03:49] <liam> fantasai, tab: [agree]
# [03:50] <liam> resolved: abspos for grid items accepted as described in the spec, with auto meaning use padding edge of containing box
# [03:50] <dbaron> plinss: to clarify, display:grid isn't always an abs pos containing block?
# [03:50] <dbaron> fantasai, Tab: correct
# [03:50] <liam> plinss, can we add "containing-block: always"?
# [03:51] <liam> back to issue 5, non-children grid items
# [03:51] <liam> plinss: these items only behave oddly if yuo positioni them absolutely
# [03:52] <dbaron> (plinss arguing that you shouldn't need position:grid, you can just apply the stuff in section 4.1 when not position:absolute)
# [03:52] <liam> tab: we still want an explicit indicator [for grid-item-ness] so yuo can opt into autoflow
# [03:52] <liam> plinss, so you can have a position: grid, but only necessary if you don't want auto?
# [03:52] <liam> tab: yes
# [03:53] <liam> tab: now have an additional problem, if you have position: grid, a named line, and can't find it
# [03:53] <liam> so we don't know what grid to put you in
# [03:53] <liam> we coud say you reman in flow
# [03:53] <liam> If you're a real grid item
# [03:54] <liam> your parent is a grid container
# [03:54] <liam> and we can't find your lines
# [03:54] <liam> we default you to auto
# [03:54] <liam> so auto-positioning or default slot
# [03:54] <liam> if you'er grid descendent we don't want tha tbehaviour
# [03:54] <liam> so are we OK with saying no, you're not a grid item, if w can't find the line
# [03:54] <liam> bert: first step is going up the tree
# [03:54] <liam> maybe all the way up to the page
# [03:55] <liam> tab: assuming w did that and can't find the grid
# [03:55] <liam> don't want to put grid items into the default slot
# [03:55] <liam> so it stays in flow in normal positioning
# [03:55] <liam> plinns: if autopositioning is turned on there's not reason why we couldn't autoposition it ...
# [03:56] <liam> so maybe "we do nothing" is the fallback, i.e. ignore the position: grid
# [03:56] <liam> tab: seems reasonable
# [03:56] <liam> ok
# [03:57] <liam> [accepted]
# [03:57] <liam> alan: so if you have a grid container, one of its direct children, but you put display: grid on it
# [03:57] <liam> tab: it goes into the default slot, normal flow, position: idd will act like position: static in that case
# [03:57] <stearns> s/display: grid/position:grid/
# [03:57] <liam> plinns: it seems to me all direct children of a grid will compute to position: grid
# [03:58] <liam> bert: that depends on the position property
# [03:58] <liam> position: static means they arein the normal flow
# [03:58] <r12a> rrsagent, minutes?
# [03:58] <RRSAgent> I'm logging. Sorry, nothing found for 'minutes'
# [03:58] <liam> fantasai: [disagrees]
# [03:58] <r12a> rrsagent, draft minutes
# [03:58] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/07-css-minutes.html r12a
# [03:58] <liam> tab: sometimes we do want to put things with position: grid in the default slot, if they are grid items
# [03:59] <liam> I'd be OK with position computing to grid
# [03:59] <liam> we don't do it to flexbox but we don't have children there
# [03:59] <liam> Rossen: how do you break out of your grid in that case?
# [03:59] <liam> plinss: same as before, you'd use a name of a higher grid line
# [03:59] <liam> bert: you'd put a div element wrapper in there
# [04:00] <Bert> (which, of course, is not desirable)
# [04:00] <liam> fantasai: I don't like that if you're a child of a grid you can suddenly jump around
# [04:00] <liam> plinns: but aren't immediate children grid items anyway?
# [04:01] <dbaron> I'm not crazy about all the use of the 'position' property (and 'display:grid' vs. 'position:grid' is especially confusing)
# [04:01] <liam> fantasai: yes, but nothing makes them jump about out f the grid
# [04:02] <dbaron> liam: is there a way to prevent content? e.g., third party content: don't want advertiser to position outside of their third-party content?
# [04:02] <dbaron> tab: use a seamless iframe
# [04:02] <stearns> +1 dbaron, particularly in that position:grid really means something like supra-grid or jump-into-an-ancestor's-grid
# [04:02] <liam> dbaron: I'm generally unhappy about adding more uses of the display property
# [04:03] <dbaron> s/display/position/
# [04:03] <dbaron> (explains IRC comment above)
# [04:03] * liam thanks
# [04:03] <liam> bert: we can reduce by one based on presence of template
# [04:03] <liam> tab: we wanted an explicit flag
# [04:04] <liam> you can set none of the properties and you'll be autopositioned
# [04:04] <liam> bert: which is more common?
# [04:04] <dbaron> dbaron^: ... since the 'position' property is mostly a list of things that should have been values of 'display' instead
# [04:04] <liam> fantasai: depends what you're doing, e.g. a catalogue where yuo want items in a grid
# [04:04] <liam> tab: we can do display: grid-item
# [04:05] <liam> plinss: but then you lose display: auto
# [04:05] <liam> tab: current values of position should have been position
# [04:05] <liam> dbaron: position fixed is really a display value, position relative is an unrelated feature
# [04:05] <liam> tab: could add display: outside-grid-item
# [04:06] <dbaron> tab: could add display-outside: grid-item instead of position:grid
# [04:06] * liam thanks :)
# [04:06] <liam> fantasai: it's getting complicated
# [04:06] <liam> I like how flex-box is very straight-forward
# [04:06] <liam> whereas here, when you turn on display: grid, shouldn't soemthing happen?
# [04:06] <dbaron> s/I like/fantasai: I like/
# [04:07] <liam> tab: are you saying we should default grid properties to more than a 1x1 grid?
# [04:07] <liam> fantasai: we don't generally have things jumping around reparenting themselves
# [04:07] <liam> it should be self-contained, you turn on grid and everything looks like a grid
# [04:07] <liam> plinss: that _is_ what's going to happen
# [04:08] <liam> [discussion about reparenting]
# [04:09] <liam> fantasai: I want the jumping to be opt-out on the jumpee item
# [04:09] <liam> tab: that only happens if you're using useless grid item properties
# [04:09] <liam> fantasai: I don't want setting something on a parent to trigger the ability of a child to jump out
# [04:10] <liam> plinss: the child is already opting into some grid behaviour
# [04:10] <liam> Rossen: do we need al lthis for level 1?
# [04:10] <liam> bert: yes!
# [04:10] <liam> Rossen: I mean the jumping out
# [04:10] <liam> alan: if we don't do it now, we'd have to invent entirely new properties to get this in the future
# [04:10] <liam> tab: can possibly do it more simply and interated way right now
# [04:11] <liam> plinss: if you're explicitly opting in to some grid line, why should you have to turn on another property to make that work?
# [04:12] <liam> fantasai: [scribe couldn't hear]
# [04:12] <liam> tab: probably opting in will be needed
# [04:12] <liam> plinss: position: snap, or something
# [04:12] <liam> plinss: what if everyone had to say position: grid?
# [04:12] <liam> and no magical behaviour
# [04:12] <liam> because now just being a child of a grid makes you magic
# [04:13] <liam> Bert: this should be like columns, not flexbox
# [04:13] <liam> tab: but flexbox isn't used in the same case, and neither is columns
# [04:13] <liam> bert: if you position yourself in the grid you get a position in the grid, doesn't matter if it's your parent
# [04:13] <liam> tab: opting in to autoposition would have to be explicit
# [04:14] <liam> couldn't just turnon grid and have everything positioned into row
# [04:14] <liam> s
# [04:15] <liam> fantasai: wants turning display:grid on to make a grid that's one column (if you don't do anything else)
# [04:15] <liam> tab: skipping
# [04:15] <liam> 4.3 issue 8 visibility
# [04:15] <dbaron> peterl: better to do other issues for next 15 minutes and come back to this
# [04:15] <liam> " Or should the track size be set to 0 regardless of its sizing function? "
# [04:16] <liam> tab: make visibility collapse, remove it from the grid, but still affect on sizing
# [04:16] <liam> collapse becomes visibility: hidden, except,
# [04:16] <liam> if everything in a track collapses the track size drops to zero
# [04:16] <liam> a. is this reasonable?
# [04:17] <liam> b. should this be intrinsic size ofthe track?
# [04:17] <liam> dbaron: if you set some of the items to visibility: collpased, no change on track size?
# [04:17] <liam> tab: yes
# [04:17] <liam> dbaron: that's not the same as tables
# [04:17] <liam> bert: you set it on the table row or col
# [04:17] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [04:17] <liam> dbaron: the intermediate state seems weird
# [04:18] <liam> if the featre is useful enough to exist, I'd be OK to change for each collapse change
# [04:18] <liam> tab: then it's same as display: none
# [04:18] <liam> dbaron: OK, I see why you did what you did
# [04:18] <dbaron> ... but it's still annoying
# [04:18] <liam> tab: there's a case for table-like behaviour where you can collapse away a col or row, but sounds like it might not be a popular way to do it
# [04:19] <liam> dbaron: for reference we still haven't defined how the table thing works!
# [04:19] <liam> tab: probably should kill this section and think about it some more
# [04:20] <liam> decision: change issue 8 into a more general issue about the feature
# [04:20] <liam> issue 9
# [04:20] * trackbot doesn't understand that ISSUE command.
# [04:20] <liam> [[ ince all three properties define the explicit grid, would it make sense to give them all a common prefix (and possibly a shorthand unifying them, as in Bert's ‘grid’ shorthand)? Current thoughts: ‘grid-template’ as the shorthand, with ‘grid-template-rows/columns/slots’ as the longhands, or ‘grid-definition’ as the shorthand, with ‘grid-definition-rows/columns/template’ as the longhands. Other suggestions welcome.
# [04:20] <liam> ]]
# [04:20] <liam> s/ ince/ Since/
# [04:20] <liam> tab: right now you have:
# [04:20] <liam> grid-definition-rows
# [04:21] <liam> grid-definition-columns
# [04:21] <liam> grid-template
# [04:21] <liam> }
# [04:21] <liam> tab: [suggests some alternate names for the properties]
# [04:22] <liam> A. grid-template-[rows|columns|slots]
# [04:22] <liam> B. grid-definition-[rows|columns|slots]
# [04:22] <liam> dbaron: so the rows and cols properties are really giving the sizes of each column/row
# [04:22] <dbaron> ?: and the number (as does slots)
# [04:22] <liam> tab: rows and columns also name lines and give the numbers of rows/columns
# [04:23] <dbaron> s/?/tab\/fantasai/
# [04:24] <liam> bert: I used the shorter name for defining grids
# [04:24] <liam> tab: you'll more likely be using the positioning properties, defs are once per container not once per item
# [04:24] <liam> bert: I want to use grids more as regions, so I don't need all these row and column properties, just naming the "region" is enough
# [04:24] * Joins: shans__ (~shans@public.cloak)
# [04:25] <liam> TabAtkins: tehre are strong use cases for [explicit definition properties]
# [04:25] <liam> bert: don't like the word definition, maybe "size"?
# [04:25] <liam> tab: we want a common prefix
# [04:25] <liam> bert: "grid" is the common prefix
# [04:26] <liam> fantasai: it's not just sizes, also names
# [04:26] <dbaron> I'm happy with A or B, probably slightly prefer A.
# [04:26] <jerenkrantz> prefer A
# [04:28] <dbaron> tab: I'd love to be able to say grid-rows and grid-columns, but I want grid-row and grid-column more, and don't want both at the same time.
# [04:28] <liam> tab: maybe we can say "area"?
# [04:28] <dbaron> tab: replaces A with grid-template-[rows|cols|areas]
# [04:28] <liam> so, grid-template-[rows|columns|areas]
# [04:28] <liam> and grid-template is a short-hand using Bert's draft
# [04:29] * Joins: Phil_Cupp_ (~Phil_Cupp@public.cloak)
# [04:30] <liam> [discussion of Bert's syntax for shorthand, plinss and tab agree it might need work
# [04:30] <liam> ]
# [04:31] <liam> tab: could say it's a slightly odd shorthand, can't omit the template from the shorthand, but this is weird
# [04:31] <liam> bert: it's not weird!
# [04:32] <liam> [discussion, do you need to mention the template in the shorthand property?]
# [04:32] <liam> tab: given a 3x3 you have to do ". . ." ". . ." ".. . ."
# [04:32] <liam> [lunch]
# [04:39] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [04:40] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [04:41] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [04:52] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [04:56] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [05:01] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [05:06] * Quits: Phil_Cupp_ (~Phil_Cupp@public.cloak) ("Page closed")
# [05:20] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [05:28] * Joins: sgalineau (~sgalineau@public.cloak)
# [05:34] * Joins: lmclister (~lmclister@public.cloak)
# [05:34] * Joins: rhauck (~Adium@public.cloak)
# [05:37] * Quits: sgalineau (~sgalineau@public.cloak) ("Computer has gone to sleep.")
# [05:39] * Joins: leif (~lastorset@public.cloak)
# [05:44] * Joins: sgalineau (~sgalineau@public.cloak)
# [05:56] * Joins: rhauck1 (~Adium@public.cloak)
# [05:58] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [05:58] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [06:01] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [06:03] * Joins: rhauck (~Adium@public.cloak)
# [06:04] * Joins: lmclister (~lmclister@public.cloak)
# [06:06] * Joins: rhauck1 (~Adium@public.cloak)
# [06:06] * Joins: myakura (~myakura@public.cloak)
# [06:09] * Joins: kawabata (~kawabata@public.cloak)
# [06:10] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [06:10] * Joins: lmclister (~lmclister@public.cloak)
# [06:10] * liam Zakim, pick a victim
# [06:10] * Zakim sorry, liam, I don't know what conference this is
# [06:11] <glazou> ScribeNick: dino
# [06:11] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [06:11] <dino> tab: we deferred a couple of issues
# [06:11] * Joins: shans__ (~shans@public.cloak)
# [06:12] <dino> tab: 1. Position: grid stuff. Peter, Elika and I decided on something.
# [06:13] <dino> tab: position:grid on anything makes it a grid item, and makes it jump up the tree looking for lines.
# [06:13] <dino> tab: this leads to interesting auto-placement....
# [06:13] <dino> dbaron: [interrupts]
# [06:13] <stearns> normal grid children do not jump up the grid
# [06:13] <dino> tab: ok, cool.
# [06:14] <dino> tab: we propose eliminate auto-flow:none, switch initial value to rows (grid-overflow), and have that as the overflow behaviour
# [06:14] <dbaron> s/overflow/autoflow/ ?
# [06:15] <dino> tab: this has the benefit that it is close in apparent behaviour to the default cell.
# [06:15] <dino> (with display: grid)
# [06:16] <dino> tab: and acts grid-like when you apply more of the grid properties
# [06:16] <dino> TabAtkins: and matches flexbox more closely
# [06:17] <dino> TabAtkins: -> unambiguous behaviour when pos:grid items that can't find lines (or are auto). they act the same as a grid child.
# [06:17] <dino> -> find nearest grid, and become autoflow item there
# [06:17] <dino> alan: soyou can no longer have pos:grid and have it remain in the flow
# [06:17] <dino> TabAtkins: correct
# [06:18] <dino> bert: means i can't use the same grid for templates.
# [06:18] <dino> TabAtkins: the region behaviour should be addressed separately.
# [06:18] <dino> TabAtkins: this is simpler overall.
# [06:18] <dino> Bert: but less useful
# [06:18] <dino> Bert: everything has to be parent child
# [06:19] <dino> TabAtkins: no, use position: grid
# [06:19] <dino> Bert: I want to use props starting with grid. they are useful.
# [06:19] <dino> Bert: they work like regions. content flows into the grid.
# [06:20] <dino> Bert: this is reversed. when i set the grid properties on an element, i need to duplicate the properties on children.
# [06:20] <dino> TabAtkins: (disagrees)
# [06:20] <dino> TabAtkins: a. regions lets you do everything right now
# [06:20] <dino> TabAtkins: b. if we want to do this later, it's easy
# [06:21] <dino> [ Bert requests maintaining existing behaviour. Tab explains that this is like flexbox ]
# [06:21] <dino> Bert: it is easier if you have markup designed to behave that way. this is not normally the case.
# [06:21] <dino> Bert: my approach is easier. if you want something floated, you put a property on it. that's what removes it from the normal flow.
# [06:22] <dino> TabAtkins: i understand there are strong reasons for your way, but my way is much more simple.
# [06:22] <dino> Bert: they were simple before too
# [06:23] <dino> elika: the point of having everything become a grid is that display:grid makes things appear like a grid.
# [06:23] <dino> elika: set rows, you get that number of rows, etc
# [06:23] <dino> elika: we wanted this for flexbox, and we're following here.
# [06:24] <dino> TabAtkins: we're proposing to start with this simple model, and add your case later.
# [06:25] <dino> Bert: both behaviours are useful. the nice thing was that you could use the same properties to set up for both.
# [06:25] <dino> TabAtkins: you can still do this.
# [06:25] * Joins: Rossen (~Rossen@public.cloak)
# [06:26] <dino> [ discussion about how many properties each case needs to set ]
# [06:26] <dino> s/discussion/disagreement
# [06:26] <dino> Bert: i've tried many different examples...
# [06:26] <dino> TabAtkins: all document-centric
# [06:26] <dino> TabAtkins: app-centric gravitate towards my model
# [06:27] <dino> Bert: yeah, it is very common to have flowing text. I don't want to have to set two properties.
# [06:27] <dino> elika: when you have flowing text you normally have a parent/child relationship
# [06:27] <dino> Bert: disagree.
# [06:28] <dino> TabAtkins: do that by changing grid:auto-flow into a new value
# [06:28] <dino> alan: i don't understand how this addresses bert's case
# [06:28] <dino> TabAtkins: once we add it, it is simple to turn on
# [06:29] * Joins: Phil_Cupp (~Phil_Cupp@public.cloak)
# [06:29] <dino> Bert: why not have it as part of the shorthand? it could say either the template or a keyword positioning v flowing
# [06:29] * Joins: r12a (rishida@public.cloak)
# [06:29] <dino> TabAtkins: right now grid:autoflow is not part of the shorthand. we could add that.
# [06:30] <dino> TabAtkins: this is not necessarily new stuff, we'd just changing what the auto value does.
# [06:30] <dino> Bert: you could also use the display property as the switch.
# [06:31] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [06:31] <dino> TabAtkins: it is simple to add this later. are we happy to change our default behaviour over to this?
# [06:32] <dino> Bert: flexbox is the wrong model to follow. multicolumn is a better example.
# [06:32] <dino> TabAtkins: i'm not trying to justify flexbox.
# [06:32] <dino> TabAtkins: can you live with the change I suggested?
# [06:33] * Joins: jdovey (~jdovey@public.cloak)
# [06:33] <dino> Bert: it's a radical change
# [06:33] <dino> TabAtkins: no, it's just the initial value of one property
# [06:33] <dino> Bert: syntax wise yes. but requires a new template layout model.
# [06:33] <dino> TabAtkins: [disagrees]
# [06:33] <dino> Bert: what does the default slot become?
# [06:34] <dino> TabAtkins: when you use the flowing behaviour you define what the slot is. We don't have to worry about this in default.
# [06:34] <dino> Bert: [explains a complicated example in a manner that would be difficult to minute, using hand gestures]
# [06:35] <dino> TabAtkins: [answers the example :]
# [06:35] <dino> TabAtkins: the two things you can't mix are the two types of auto-positioning. use regions for that.
# [06:36] <dino> Bert: i have a grid element, with a template, it isn't auto positioned, with some child that I do want positioned
# [06:37] <dino> Bert: do i then have to use pos:grid
# [06:37] <dino> ?
# [06:37] <dino> TabAtkins: no, use grid area
# [06:37] <dino> TabAtkins: the rest are auto-flowed
# [06:37] <dino> TabAtkins: look at grid: auto-flow and do what that says
# [06:38] <Rossen> #grid { grid-auto-flow: rows; display: grid; } #grid > * { grid-area: auto }
# [06:38] <dino> Rossen: is that enough to get all of the auto positioned in a row?
# [06:38] <Rossen> #grid { grid-auto-flow: columns; display: grid; } #grid > * { grid-area: auto }
# [06:39] <dino> TabAtkins: not even that much. just set display:grid.
# [06:39] <dino> TabAtkins: we're just saying the default value should be grid-auto-flow: rows
# [06:40] <dino> Bert: you still have to set two properties together
# [06:40] <dino> TabAtkins: one of them has to be privileged
# [06:41] <dino> Bert: what is interaction btw flow into and grid area?
# [06:41] <dino> TabAtkins: i have no idea and don't want to think about it now
# [06:41] <dino> Bert: we will have to prepare for it
# [06:41] <dino> TabAtkins: in the regions draft, sure.
# [06:41] <dino> Bert: flow-into is used, and grid-area is auto....
# [06:41] <dino> TabAtkins: YES
# [06:41] <dino> Bert: NO
# [06:41] <dino> TabAtkins: NO
# [06:41] <dino> Bert: YES
# [06:42] <dino> Peter: suggest accepting tab's proposal, bert's objection noted, we will discuss it again.
# [06:42] <dino> alan: the proposal said you'd change the default and defer auto? could we leave it in the draft for now?
# [06:43] <dino> TabAtkins: yes.
# [06:43] <dino> s/defer auto/defer none/
# [06:43] <dbaron> (grid-autoflow: none)
# [06:44] <dino> RESOLUTION: accept tab's proposal, bert's objection noted, we will discuss it again (issue marked in spec)
# [06:44] <dino> TabAtkins: shorthand.
# [06:45] <dino> TabAtkins: accept bert's shorthand with tiny changes (separators)
# [06:45] <dino> peter: do this later
# [06:45] <jerenkrantz> RRSAgent: make minutes
# [06:45] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/07-css-minutes.html jerenkrantz
# [06:45] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [06:45] <dino> Topic: Font Load Events
# [06:46] <stearns> http://dev.w3.org/csswg/css-font-load-events/
# [06:47] <TabAtkins> http://dev.w3.org/csswg/css-font-load-events/#fontloader-interface
# [06:47] <liam> [tab shows a picture of an earwig]
# [06:48] <jerenkrantz> Ok all - I need to leave. Those who will be here at AC meeting, I'll see you on Monday. Others, I'll see you on-list! Thanks.
# [06:48] <dino> JD: there is a problem when loading @font-face. they are lazily loaded. if you never reference the font... no font would be loaded. The flip side is that because it was never loaded, you can't use it.
# [06:49] <dino> eg. canvas
# [06:49] <dino> e.g. show a menu of available fonts
# [06:49] <dino> - you don't know metrics, etc
# [06:49] <dino> JD: been an issue, many people want a solution.
# [06:49] <dino> JD: I sketched out a proposal for a FontLoader that hangs off document.
# [06:50] <dino> JD: gives a way to trigger some loads... just tell me when I'm done.
# [06:50] <dino> JD: most authors don't need to know specifics
# [06:50] <dino> JD: there is a more complex use case where they want to know exactly when every font is available
# [06:50] <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2013Apr/0064.html
# [06:50] <dino> JD: two handlers, and a bunch of methods
# [06:51] <dino> JD: loadFont ( font, text, successCallback, errorCallback )
# [06:51] <dino> JD: it's the same as the font property
# [06:52] <dino> JD: text is provided to help selection
# [06:52] <dino> krit: ???
# [06:52] <dino> krit: so font is a list of fonts?
# [06:52] * Quits: Phil_Cupp (~Phil_Cupp@public.cloak) ("Page closed")
# [06:52] <dino> JD: yes
# [06:54] <dino> glenn: what are semantics of the text parameter?
# [06:54] <dino> JD: you go through the characters to see if you need fonts.
# [06:54] <dino> glenn: Please rename this parameter to something more descriptive.
# [06:54] <dino> JD: successcallback just tells you when things went ok
# [06:55] <dino> [ignore that last line]
# [06:55] <glenn> s/text parameter/text member of LoadFontParameters/
# [06:55] <dino> JD: explains checkFont and notifyWhenFontReady
# [06:55] <dino> [ they were obvious so I didn't minute ]
# [06:56] <dino> TabAtkins: [ explains futures ]
# [06:57] <dino> TabAtkins: most of the API is "do something and tell me when it completes"
# [06:57] <dino> TabAtkins: All of John's API is reproduced in my proposal.
# [06:58] <dino> TabAtkins: e.g. - tell we when everything is ready to draw
# [06:58] <dino> TabAtkins: ... is ready().. returns a Future
# [06:59] <dino> TabAtkins: you then register callbacks on the Future...
# [07:00] <dino> glenn: Is this the first place in the Web ecosystems that is using Futures?
# [07:00] <dino> TabAtkins: No. e.g. JSON Linked Data.
# [07:00] <dino> Rossen: How are they different from Promises?
# [07:00] <dino> TabAtkins: the name has changed, but the same.
# [07:01] <dino> TabAtkins: The new TAG likes Futures and will be pushing it.
# [07:01] <dino> Peter: The TAG has consensus that this is a good approach.
# [07:01] * glazou the day Futures becomes a REC, we'll hear "Future is now the present ; Promises, promises..."
# [07:01] * Joins: myakura (~myakura@public.cloak)
# [07:02] <dino> glenn: I object because this seems like a one-off case and we shouldn't invent new things for this.
# [07:02] <dino> glenn: if there is a concerted effort to change existing APIs towards this, then i accept it.
# [07:02] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [07:02] <dino> peter: that is the plan.
# [07:03] <SimonSapin> http://w3cmemes.tumblr.com/post/48887723979/does-your-api-use-futures-yet
# [07:03] <dino> JD: Microsoft/Rossen and Apple/Dean, have you heard about Promises? Are you using them?
# [07:03] <dino> Rossen: we shipped them already. they are the way you write apps in Win8.
# [07:04] <dino> Dean: I have been paying no attention.
# [07:05] <glenn> s/I object because this seems like a one-off case and we shouldn't invent new things for this./I object unless there is a concerted effort to convert to Futures across the board./
# [07:05] <dino> Peter: there were two people from mozilla that support this.
# [07:05] <dino> JD: just concerned about time lag if we have to depend on the feature
# [07:05] <dino> Glenn: my concern too
# [07:06] <dino> TabAtkins: there is an answer that avoids time lag. segment the API so that there is part of it that doesn't use Futures. Not as convenient.
# [07:06] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [07:07] <dino> Dean: It's new features like this that will drive the use of futures, so I support it.
# [07:08] <dino> TabAtkins describes how JD's proposal merges into his. Basically callbacks become futures.
# [07:09] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [07:09] <dbaron> onloading is any transition from 0 fonts loading to 1 font loading
# [07:09] <dino> JD: in my proposal onloading is fired when a font starts loading. onloadingdone fires when all fonts are loaded.
# [07:10] <dbaron> onloadingdone is any transition from 1 font loading to 0 fonts loading
# [07:10] <dino> JD: onloadstart fires on each font
# [07:10] <dino> JD: the difference is that if you want to know when fonts load you have to create a future for each of the fonts
# [07:11] <dino> TabAtkins: you just want to be notified when fonts load
# [07:12] <dino> dbaron: Tab, I think you've removed the low-level api that allows people to listen for each font load.
# [07:12] <dino> TabAtkins: no...
# [07:12] <dino> JD: e.g. i have an app with a lot of fonts. I want to know when any font loads. I don't want to have to set up a future for each load.
# [07:13] <dino> TabAtkins: that's a small use case. I suggest waiting for the all loaded event.
# [07:13] <dino> TabAtkins: it takes a little longer.
# [07:14] <dino> dbaron: that makes the basic api more complex
# [07:14] <dino> TabAtkins: no, the basic API is just knowing when all fonts are loaded
# [07:14] <dino> Krit: ???
# [07:14] <dino> Liam: Does the spec handle the case when the font failed.
# [07:14] <dino> ?
# [07:15] <liam> [answer: yes, I don't have to wait until all fonts have loaded before finding that one failed]
# [07:15] <dino> dbaron: in tab's proposal, what happens if one loads and one fails?
# [07:17] <dino> TabAtkins: loading done will fire when they are both finished. the event will have info on which ones worked and which ones didn't/
# [07:17] <dino> krit: ???
# [07:17] <dino> JD: it is weird to have a mix of futures and events
# [07:17] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [07:17] <dino> TabAtkins: it's not too weird
# [07:18] <dino> Peter: there is a promises-like thing for streaming situations
# [07:18] <ivan> (A blog of Tab on futures, for those (like me) who do not really know what those are: http://www.xanthir.com/b4PY0)
# [07:18] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [07:19] <dino> krit: ???
# [07:19] <dino> krit: is this API necessary?
# [07:19] <dino> everyone: YES!!
# [07:19] <dino> JD: e.g. webkit does not include font loads in the "load" event
# [07:20] <dino> TabAtkins: Google Docs slaps me every day about this
# [07:21] <dino> JD: We have a direction.... i'm not completely comfortable, but that's just details.
# [07:21] <dino> JD: issues - canvas web workers want fonts, but they have no DOM
# [07:22] <dino> JD: e.g. pdf.js wants to do work on a different thread.
# [07:23] <dino> JD: But Fonts are tied to a document
# [07:23] <dino> JD: It seems that the group wants to go in the direction of Futures...
# [07:23] <dino> glenn: Should we ask for a straw poll.
# [07:24] <dino> Straw poll: 11 people want a futures-based API. 1 against (for the record, it was Glenn)
# [07:25] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [07:25] <dino> JD: Next topic - Glenn wanted the ability to turn off all font settings. e.g. font-feature-settings: none.
# [07:26] <dino> JD: With Open Type, there are a set of features that are required (arabic ligatures), and there are some that are not required but are on by default.
# [07:26] <dino> JD: I don't see the need.
# [07:27] <dino> GA: It's a shorthand, so it isn't functionality. In the case where you don't know what features are present in the font, you can't necessarily enumerate all the ones you want turned off.
# [07:27] <dino> GA: Very useful for testing.
# [07:27] <dino> GA: You can already turn all these off. it's just a shorthand.
# [07:28] <dino> GA: If there was a way to enumerate the properties of a font... you could do that.
# [07:28] <dino> Elika: this is not a shorthand in the typical sense.
# [07:28] <dino> Dean: "shortcut" not "shorthand"
# [07:28] * fantasai agrees with Vladimir's response
# [07:29] <dino> Alan: Glen is saying if there was a way to enumerate all the available features, he might be able to avoid this.
# [07:29] <dino> fantasai: just list them all
# [07:29] <dino> GA: there are some custom/private ones
# [07:30] <dino> glazou: how can I know that ligatures are enabled?
# [07:30] <dino> GA: you can't
# [07:30] <dino> JD: you'd turn it off and on and see if there was a difference
# [07:30] <dino> JD: there is no computed value to check
# [07:30] <dino> dbaron: this is a low level control property
# [07:31] * Joins: jdovey (~jdovey@public.cloak)
# [07:31] <dino> JD: I have had this situation as a developer. I don't know what is enabled. I have to iterate through and see what's there.
# [07:31] <dino> GA: My example is that I get a font from a customer with strange results. I don't have any way to know why.
# [07:31] <dino> JD: this is a pretty edge use case
# [07:32] <dino> JD: but it is a weapon of mass destruction too
# [07:32] <dino> GA: Not really. This is not new - you can already do it.
# [07:32] <dino> Liam: is there a way to revert the font to its default behaviour
# [07:32] <dino> GA: But normal means different things for different fonts
# [07:32] <dino> JD: No.
# [07:33] <dino> GA: No. It does not mean turn on features.
# [07:33] <dino> JD: Propose to reject this feature request.
# [07:33] <dino> GA: I will implement it anyway
# [07:33] <liam> [yes you can revert to default feature set]
# [07:33] <dino> Peter: yes, as long as it is prefixed
# [07:33] <dbaron> alan: I'd object to having this value; too much of a footgun.
# [07:33] <dino> Alan: I reject to having this as an available feature.
# [07:33] <dbaron> fantasai: me too
# [07:34] <dino> RESOLUTION: We will not add Glenn's proposal of font-feature-settings: none
# [07:35] <dino> RESOLUTION: We will use Promises in the font loading API [From above - I didn't minute it at the time]
# [07:36] <dino> JD: [shows example of why text decoration on the baseline can cause problems in the synthetic case for superscripts and subscripts ]
# [07:37] * Joins: rhauck (~Adium@public.cloak)
# [07:39] <dino> JD: Suggestion: sup and sub metric don't work for text decoration placement. The way to handle this is similar to when all the variants are not in the font, if there are not variant sup or sub glyphs then synthesize. If there are any text decorations we should use the synth glyphs and adjust the decoration
# [07:40] <dino> fantasai: i can live with that
# [07:40] <dino> dbaron: i think that is reason
# [07:40] <dino> s/reason/reasonable/.
# [07:40] <dino> dbaron: you're saying do the glyphs, then do what text-decoration says
# [07:40] <dbaron> dbaron: so just doing synthesis and then text decoration stuff will be whatever the text decoration spec says?
# [07:40] <dino> JD: shows an example from The Guardian with some superscript
# [07:40] <dino> [which looks like shit]
# [07:40] * Joins: lmclister (~lmclister@public.cloak)
# [07:41] <dino> [the lines are not equally spaced]
# [07:42] <dino> [looks much better in chrome with the variants available]
# [07:43] <Bert> (That's why many authors nowadays set 'sup {line-height: 0}')
# [07:43] <r12a> people.mozilla.org/~jdaggett/tests/multicolumnsuperscript.html
# [07:43] <r12a> http://people.mozilla.org/~jdaggett/tests/multicolumnsuperscript.html
# [07:43] <dino> Leif: on wikipedia has superscripts that are underlined on hover.
# [07:43] <dino> JD: they get the fallback
# [07:44] <dino> Leif: is there a way to force synthesis
# [07:44] <dino> dbaron: it's only for sites that are using this new feature to do supsub
# [07:44] <dino> JD: However, if they are matched to the font, the text decorations are really hard to see. These variants are small.
# [07:47] <dino> RESOLUTION: If an element with text-decoration set and font-variant non-normal then we synthesize subs/sups, and then text-decoration follows
# [07:47] * Joins: zcorpan (~zcorpan@public.cloak)
# [07:47] <dbaron> <br data-duration="900s">
# [07:47] <myakura> rrsagent, make minutes
# [07:47] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/07-css-minutes.html myakura
# [07:47] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [07:47] * Joins: zcorpan (~zcorpan@public.cloak)
# [07:49] <SimonSapin> s/^RESOLUTION:/RESOLVED/g
# [07:51] <SimonSapin> s/^RESOLVED /RESOLVED: /g
# [07:53] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [07:54] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [07:56] * Joins: kawabata (~kawabata@public.cloak)
# [07:56] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [07:58] <plinss> rrsagent, pointer?
# [07:58] <RRSAgent> See http://www.w3.org/2013/06/07-css-irc#T05-58-09
# [08:02] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [08:04] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [08:09] * Joins: leif (~lastorset@public.cloak)
# [08:09] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [08:10] * Parts: myakura (~myakura@public.cloak)
# [08:10] * Joins: myakura (~myakura@public.cloak)
# [08:11] <leif> ScribeNick: leif
# [08:11] <leif> Topic: font-language override
# [08:11] * Joins: Rossen (~Rossen@public.cloak)
# [08:11] * Joins: rhauck (~Adium@public.cloak)
# [08:12] * Joins: lmclister (~lmclister@public.cloak)
# [08:12] <leif> jdaggett: OpenType has the ability to have language-specific features
# [08:13] <fantasai> Issue: http://lists.w3.org/Archives/Public/www-style/2013May/0578.html
# [08:13] * trackbot is creating a new ISSUE.
# [08:13] <trackbot> Created ISSUE-339 - Http://lists.w3.org/Archives/Public/www-style/2013May/0578.html; please complete additional details at <http://www.w3.org/Style/CSS/Tracker/issues/339/edit>.
# [08:13] <fantasai> comment: http://lists.w3.org/Archives/Public/www-style/2013May/0736.html
# [08:13] <leif> jdaggett: If a specific language has glyph variants that are more common (e. g. cyrillic), then based on the content language of the element, glyphs are automatically switched.
# [08:13] <leif> jdaggett: there are cases where the semantic language may not be support by the ont
# [08:14] <leif> jdaggett: e.g. Serbian and Macedonian uses the same traditions, so you want to say content language is Mac, but want to use a font that only supports Serbian
# [08:14] <leif> jdaggett: an uncommon use case
# [08:14] <leif> jdaggett: Some people unfortunately always want to set the low-level feature.
# [08:14] <leif> jdaggett: They view the property as a way to set the low-level property.
# [08:15] <leif> jdaggett: fantasai wants a fallback list instead of a single language
# [08:15] <leif> jdaggett: But when you're specifying it, you know the font, so no need to specify
# [08:15] <leif> fantasai: But if your font has Macedonian, you should be able to express that that is your first preference.
# [08:16] <leif> jdaggett: You're asking for a different feature.
# [08:16] <leif> jdaggett: You want fallback.
# [08:16] <leif> fantasai: You may or may not get the font that you specify.
# [08:16] <leif> jdaggett: The point is that when you know the font, youll specify it.
# [08:17] <leif> stearns: fantasai's use case is recognized, but sometimes you want an override instead of a fallback.
# [08:17] <leif> r12a: I'm not sure fantasai is asking for a fallback, because a fallback should go back to the language asked for.
# [08:17] <leif> jdaggett: This mechanism really is an override.
# [08:17] <leif> fantasai: UC in spec is if your font is missing glyphs
# [08:18] <leif> fantasai: Depending on which font you end up using, you still want to use the glyphs
# [08:18] <leif> fantasai: Another case is if you're using Mac. and have a few quotes of Serbian, and want that to work
# [08:18] <leif> jdaggett: As long as the font supports it, you can have multiple languages, each uses the right lgyphs from the same font.
# [08:19] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:19] * Joins: rhauck1 (~Adium@public.cloak)
# [08:19] <leif> jdaggett: This doesn't feel like a general-purpose feature. I'm worried about getting implementations.
# [08:19] <leif> jdaggett: Might be at risk.
# [08:19] <leif> jdaggett: To extend it, means a lot of work defining the fallback.
# [08:20] <leif> fantasai: I see two UCs: Using a language close to your desired font.
# [08:20] <leif> fantasai: 2nd case: You want your text to have a consistent typographic style.
# [08:20] * Joins: jdovey (~jdovey@public.cloak)
# [08:20] <leif> fantasai: If you have a quote from another language, you don't want to suddenly change shapes.
# [08:21] <leif> fantasai: Use style of surrounding paragraph. In that case, would make sense to have language override to use paragraph's language for that quote.
# [08:21] <leif> glenn: We need to knowwhat features and languages a font supports.
# [08:21] <leif> glenn: Having a fallback seems unnecessary, knowing what the font has.
# [08:22] <leif> fantasai: If font downloading is turned off, and you're using a system font, e.g. on a ebook reader, I don't want the font-language-override to tell me what overrides to use.
# [08:22] <leif> jdaggett: The fonts on your system are not going to be that sophisticated.
# [08:22] <leif> fantasai: How do you know?
# [08:22] <leif> jdaggett: I see your points, but I don't think there's a lot to be gained.
# [08:23] <leif> stearns: The existence of an override would not preclude a future fallback mechanism.
# [08:23] <leif> fantasai: The use case we're aiming for, you're telling the font to use the wrong thing.
# [08:23] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:23] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:23] <leif> stearns: In all the mailing list feedback, they're talking about an override where they know the font.
# [08:23] <leif> fantasai: But that's not always the case while loading the page
# [08:23] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [08:24] <leif> jdaggett: A system font won't have all these features.
# [08:24] <leif> jdaggett: Straw poll…?
# [08:24] <leif> glazou: fantasai, can you live with no change?
# [08:25] <leif> fantasai: I don't understand the objection to fallback
# [08:25] <leif> jdaggett: You're asking for more work, and I want to get the spec don.e
# [08:25] <leif> jdaggett: The feature is at risk anyways.
# [08:26] <leif> jdaggett: Prefer something simple that's actually implemented, then we'll go from there.
# [08:26] <leif> glazou: We've said for other things that "this is interesting, but we'll move forward"
# [08:26] <leif> fantasai: I can live with it. I just don't agree with the attitude "I know what fonts I have".
# [08:27] <leif> jdaggett: It can go on the css4-fonts wiki page.
# [08:27] <leif> glazou: or log an issue
# [08:27] <leif> glenn: Do you define that this string must be a case-sensitive match to opentype language?
# [08:27] <dbaron> fantasai, In theory, I'd agree, except the odds of a user happening to have a font with language-specific features already is probably pretty low
# [08:28] <leif> glenn: Should be case-sensitive
# [08:28] <leif> jdaggett: Have to look at that.
# [08:28] <leif> jdaggett: Lots of case-sensitivity stuff sprinkled around.
# [08:28] <leif> fantasai: Spec doesn't specify case-sensitivity, and I raised that as an issue.
# [08:29] <leif> jdaggett: Can discuss Text on the mailing list.
# [08:29] <leif> r12: spec says it's case sensitive
# [08:29] <leif> Topic: Backporting level 3 changes to 2.1
# [08:30] <leif> fantasai: My principle is that a change to L3 spec that would make a 2.1-compliant UA incompliant, that change needs to be backported.
# [08:30] <leif> fantasai: A L3 client should also be L2 client.
# [08:31] <leif> dbaron: Slight modification: if the change would make _all_ clients non-compliant.
# [08:31] <fantasai> s/clients/2.1 clients
# [08:31] <leif> TabAtkins: If there is an error in 2.1 fixed in 3, then should backport.
# [08:31] <leif> fantasai: Level 3 can tighten definitions, that should be backported.
# [08:32] <fantasai> s/that/changes/
# [08:32] <leif> dbaron: If it would break content, we shouldn't be making the change.
# [08:32] <leif> SimonSapin: When do we stop fixing CSS 2.1?
# [08:33] <leif> fantasai: When the spec has been completely superseded.
# [08:33] <leif> peter: when a module has replaced parts of it?
# [08:33] <leif> TabAtkins: No, when it's completely replaced.
# [08:34] <leif> fantasai: A L3 spec will replace parts of CSS 2.1
# [08:34] <leif> SimonSapin: Can we deprecate parts of 2.1?
# [08:35] <leif> fantasai: We tend to find issues in sections that haven't been rewritten, so I don't worry about it. If they've been rewritten, then we've found the inconsistencies.
# [08:35] <leif> peter: Does everyone agree to that proposal?
# [08:36] <leif> TabAtkins: Might not be worth it always, like every syntax change, but as a general principle, yes
# [08:36] <leif> fantasai: Syntax may actually be the most important.
# [08:36] <leif> TabAtkins: They're just really hard to get right.
# [08:36] <leif> SimonSapin: We should be able to deprecate one chapter.
# [08:36] <leif> glazou: What will be the result? 2.1 rev 2, or 2.2?
# [08:37] <leif> dbaron: 2.2 eventually, but not as much effort as 2.1.
# [08:37] <leif> glazou: People should be able to refer to 2.1
# [08:37] <leif> liam: small changes -> 2nd edition.
# [08:37] <leif> dbaron, liam: could be confusing.
# [08:37] <leif> Bert: Pick some time in the future, then bundle and publish errata
# [08:38] * plh Module 2 Level 1 Revision 2
# [08:38] * Quits: Koji (~Koji@public.cloak) (Ping timeout: 180 seconds)
# [08:39] <leif> SimonSapin: What's the conclusion?
# [08:39] <leif> fantasai, glazou: As outlined above.
# [08:39] <leif> Bert: We should pick a date
# [08:39] <leif> fantasai: We already picked this F2F
# [08:39] <leif> Bert: Assign someone to follow-up?
# [08:40] <leif> Bert: I have some other publications to do after the summer. Can follow it up October or after.
# [08:40] <leif> glazou: Let's decide later.
# [08:41] <leif> Topic: Text Decoration
# [08:41] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:41] <fantasai> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013
# [08:42] <leif> fantasai: Main issue: Position of underlines if you have an entire paragraph underlined
# [08:42] <leif> fantasai: Where should the underline be placed?
# [08:42] * Joins: koji (~koji@public.cloak)
# [08:42] <leif> fantasai draws on whiteboard: big and small text within an element
# [08:43] <leif> fantasai: Do we use the ancestor's underline? 2.1 leaves this undefined.
# [08:43] <leif> fantasai: Rossen posted a TC where if each line has different sizes, they get different sizes
# [08:43] <leif> dbaron: That's contrary to the 2.1 model.
# [08:44] <leif> fantasai: We want to have one line.
# [08:44] <fantasai> http://jsfiddle.net/4sC2T/1/
# [08:45] <leif> fantasai: for web compat, we probably need to stick with that behavior.
# [08:45] <leif> dbaron: In Gecko, the underline is constant thickness.
# [08:45] <leif> dbaron: and position
# [08:45] <leif> dbaron: There were a bunch of tradeoffs in implemnting 2.1
# [08:45] <leif> dbaron: We got rid of quirks mode in text decoration
# [08:45] <leif> dbaron: There was a quirk that wasn't compatible enough with 2.1
# [08:46] <leif> dbaron: We came up with a new, unitary model for decorations.
# [08:46] <leif> dbaron: One of the importnat requirements: Not do ransom-note style underlining
# [08:46] <leif> dbaron: if it crossed multiple pieces of text, you got a single undeline.
# [08:46] <leif> dbaron: The underline comes from the element with the text-decoration property.
# [08:47] <leif> dbaron: The spec implid that the position and thickness come from that element.
# [08:47] <leif> dbaron: The 2.1 spec has one part where we disagreed about the grammar.
# [08:47] <leif> jdaggett: What about vertical-aligin variatons?
# [08:48] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [08:48] <leif> dbaron: In 2.1 the underline is generated by the element with the text-decoration property. The various properties of the underline come from that.
# [08:48] <leif> dbaron: So superscript and subscript come from that.
# [08:48] <leif> dbaron: But there was a quirk.
# [08:48] * plh notes that IE and Opera behaves one way, and Firefox and Chrome behaves an other
# [08:48] <leif> dbaron: so be careful.
# [08:48] <leif> dbaron: fantasai's proposing that we switch to a model where we don't just use info from that model, but also its descendents.
# [08:49] <leif> dbaron: The union of them and all their fonts.
# [08:49] <leif> dbaron: Problematic because it's hard to implement and is slow
# [08:49] <leif> dbaron: and it breaks a number of invariants authors don't realize they depend on.
# [08:49] <leif> dbaron: Authors would be surprised if they have six things underlined, and one of the them is subscripted, and behavior changes.
# [08:50] <leif> fantasai: They'd also be surprised when underline goes through subscript.
# [08:50] <leif> dbaron: Yes, one author problem is fixed, another is caused.
# [08:50] <leif> Bert: One solution that we discussed about crossing the subscript is to interrupt the udnerline.
# [08:50] <leif> dbaron: The text-decoration model has a property to allow that.
# [08:50] <fantasai> Previous discussion on exactly this topic: http://lists.w3.org/Archives/Public/www-style/2012Nov/0129.html
# [08:50] <leif> r12a: isn't another solution to put a text-decor property on the subscript
# [08:51] <leif> dbaron: That needs canceling out
# [08:51] <leif> fantasai: Deferred to level 4
# [08:51] <leif> dbaron: Some people say text-decor feels like an inherited property,but it's not, to allow even baseline and thickness for entire element.
# [08:51] <leif> dbaron: I feel like this change would add a lot of complexity to fix one problem and cause another.
# [08:51] * liam is surprised by http://jsfiddle.net/Xfb9v/2/ with a double underline in firefox 17 but not in chromium
# [08:51] <leif> fantasai: We discussed this last year.
# [08:52] <leif> fantasai: Aryeh sent feedback that big text in strikthrough, the big text isn't striked through
# [08:52] <leif> fantasai: That resulted in the current text.
# [08:52] <leif> dbaron: I didn't understand it sufficiently at the time.
# [08:52] <leif> dbaron: I would not have agreed to averaging over descendants.
# [08:53] <leif> fantasai: So how can we solve both problems at once?
# [08:53] <leif> dbaron: We don't have a reasonable solutoin yet. We should stick with the existing model.
# [08:53] <leif> fantasai: Then I have to tell Aryeh that we're reverting the fix for his problem.
# [08:54] <leif> dbaron: We can't fix everything.
# [08:54] <leif> dbaron: And I really don't want to rewrite our text-decoration code every two eyars.
# [08:55] <leif> RESOLVED: Revert the change to text-decoration behavior and go back to Last Call.
# [08:55] <leif> fantasai: Actually, this was a clarification, and we don't want to go back, we want something completely different.
# [08:56] <leif> glazou: Other text-decoration issues/
# [08:56] <leif> ?
# [08:56] <leif> Bert: We're already in LC, we will have another one.
# [08:56] <leif> liam: If I take the obscure big-text example, and I add an underline in the middle of the big text, it gets its own, thicker underline?
# [08:57] <leif> fantasai: If you put a span in there, it gets a suitable underline.
# [08:57] <leif> liam: Lots of test cases needed here!
# [08:57] <leif> dbaron: If you specify three underlines on three elements, you should get three, even if they might cover eachother up
# [08:57] <liam> [ http://jsfiddle.net/Xfb9v/3/ - example ]
# [08:58] <leif> s/and go back to Last Call//
# [08:58] <jdaggett> rrsagent, make minutes pretty please
# [08:58] <RRSAgent> I'm logging. I don't understand 'make minutes pretty', jdaggett. Try /msg RRSAgent help
# [08:58] <jdaggett> rrsagent, make minutes
# [08:58] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/07-css-minutes.html jdaggett
# [08:59] <leif> Topic: pseudo-stacking contexts
# [09:00] <leif> dbaron: At some point we discussed whether flex items should be psc, and we decided that they should
# [09:00] <leif> dbaron: but table cells should be too.
# [09:00] <leif> dbaron: But then: table backgrounds and borders are complicated
# [09:00] <leif> dbaron: should they be included in the psc?
# [09:01] <leif> dbaron: Four issues with table backgrounds and borders:
# [09:01] <leif> dbaron: backbrounds versus borders
# [09:01] <leif> dbaron: separated vs. collapsed
# [09:02] <leif> dbaron: Okay with different answers for those
# [09:02] <leif> dbaron: But don't want different answers for backgrounds for separated vs. colapses
# [09:03] <leif> dbaron: If we look at appendix E of 2.1
# [09:03] <leif> dbaron: Table background painting is already described as part of the z-order in 2.1
# [09:04] <leif> dbaron quotes the spec
# [09:04] <leif> dbaron: Table through cell are painted in the backgrounds layer
# [09:04] <leif> dbaron: That says that if table cells establish a PSC, that even cellbackgrounds are not inside it
# [09:05] <leif> dbaron: Because painting them is associated with the table
# [09:05] <leif> … At this point I've already explicitly disagreed with fantasai and TabAtkins
# [09:05] <leif> … But I'm against changing any of this.
# [09:05] <leif> … table borders are also painted in this layer.
# [09:06] <leif> … This is a bit ambiguous
# [09:06] * Joins: jdovey (~jdovey@public.cloak)
# [09:06] <leif> … If we don't change it , then all we need to do is decide that tables form SC
# [09:06] <leif> … and cells are not part of that SC
# [09:07] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [09:07] <leif> fantasai: If we transform a table cell with backgrounds and borders, what do I get?
# [09:07] <leif> dbaron: the interesting part: do borders and backgrounds even move?
# [09:07] <leif> … in the collapsed model, shouldn't move.
# [09:08] <leif> fantasai: In some impls, if you set a transform, the backbround paints on top of the border.
# [09:08] <leif> dbaron: A bug.
# [09:08] <leif> dbaron: and poorly tested
# [09:08] <leif> fantasai: Probably all the implementations.
# [09:08] <leif> dbaron: I'm ok with cells being PSCs
# [09:08] <leif> dbaron: if it means that the PSC doesn't include the border and background
# [09:08] <leif> … Need a lot more work to define paint order inside cells.
# [09:09] <leif> … Are people ok with what cells being PSCs means?
# [09:09] <leif> … if so, just resolve.
# [09:09] <leif> TabAtkins agrees.
# [09:11] <dbaron> RESOLVED: table cells do create pseudo stacking-contexts (as resolved before) but borders and backgrounds (of the cell or its ancestors) are not in that pseudo stacking-context
# [09:11] <leif> jdaggett: When we publish a new spec, since the TR URL changes, do we need permission from plh?
# [09:11] <leif> plh: yes
# [09:12] <leif> jdaggett: can we get css3-fonts changed to css-fonts-3?
# [09:12] <leif> fantasai: Was going to do it all at once but can do it piecemeal
# [09:12] <leif> plh: I agree with the change
# [09:12] <leif> plh: All specs should be consistent
# [09:13] <leif> Bert: But will be hard to find old mailing-list messages
# [09:13] <leif> plinss: It's already been resolved.
# [09:13] <leif> Topic: Text decoration, one more issue
# [09:14] <leif> fantasai: text-underline-position: alphabetic
# [09:14] <leif> … says use font metrics
# [09:14] <leif> … is that reasonable?
# [09:14] <leif> jdaggett: Sounds like existing behavior.
# [09:14] <leif> dbaron: Part of the question is what the underlining metrics in CJK fonts look like
# [09:14] <leif> dbaron: Ideographic baseline?
# [09:14] * Joins: koji (~koji@public.cloak)
# [09:14] <leif> jdaggett: have to look it up
# [09:14] <leif> dbaron: What is existing behavior?
# [09:15] <koji> http://lists.w3.org/Archives/Public/www-style/2013May/0159.html
# [09:15] <leif> fantasai: auto behavior says to do whatever you want, but don't cross through glyphs that shouldn't be
# [09:15] <leif> jdaggett: We have a blacklist of fonts in Gecko, where we modify the underline if it's in the blacklist.
# [09:15] <leif> … That is more that the underline metrics are not in line with the font
# [09:16] <leif> fantasai: It's suggested that this property should do the right thing for the text, in cases like cjk.
# [09:16] <leif> jdaggett: My concern: different fonts on the line, would the underline vary?
# [09:16] <leif> fantasai: No, would pick one position for the underline.
# [09:16] <leif> … Currently pick the lowest alphabetic position, but dbaron said we shouldn't do that. That gives interesting results if not baseline-aligned.
# [09:17] <leif> dbaron: The spec has two values, with auto the initial value.
# [09:17] <leif> … not clear to me how auto matches current behavior or how implementable alphabetic is.
# [09:17] <leif> … also how useful alphabetic was
# [09:17] <leif> jdaggett: I got an e-mail about this…
# [09:18] <leif> … Not clear to me what you mean by 'alphabetic'. Are you trying to override the font metrics.
# [09:18] <leif> ?
# [09:18] <leif> … Are you basing it on the baseline?
# [09:18] <leif> fantasai: Expectation that font specifies the position of the baseline
# [09:18] <leif> … You might want to underline the bottom , accounting underline…
# [09:18] <leif> jdaggett: You use the metrics to infer where the unerline would be relative to the baseline?
# [09:19] <leif> fantasai: yes
# [09:19] <leif> jdaggett: What happens to implementations?
# [09:19] <leif> dbaron: Depends on how well 'auto' match implementations and how hard to implement alphabetic.
# [09:19] <leif> ACTION jdaggett to investigate those two questions
# [09:19] * trackbot is creating a new ACTION.
# [09:19] <trackbot> Created ACTION-564 - Investigate those two questions [on John Daggett - due 2013-06-14].
# [09:20] <leif> Topic: Reversing interrupted transitions
# [09:20] <leif> dbaron: Haven't quite finished my test case
# [09:20] <leif> … one algorithm and one proposal implemented, still need to impl the other one.
# [09:20] <leif> … in javascript
# [09:21] <leif> … Don't leave the page open in a tab after using it!
# [09:21] <leif> plinss: Let's get back to that.
# [09:21] <leif> Topic: white space in media queries
# [09:22] <leif> SimonSapin: We had an issue in both MQ and @supports
# [09:22] <leif> SimonSapin describes the issue
# [09:22] <leif> SimonSapin: The grammar had optional white space, meaning that if you used a comment to separate the tokens, it would be correct
# [09:22] <leif> … reader may not know this detail
# [09:23] <leif> … We changed the grammar to allow whitespace, like calc()
# [09:23] <leif> … Issue is resoled in @supports, but still exists in MQ. We should make the same change, but we have to wonder about compat.
# [09:23] <leif> dbaron: I don't worry about compat.
# [09:23] <leif> TabAtkins explains on whiteboard
# [09:24] <leif> TabAtkins: @media screen and/**/(color) — is that correct?
# [09:24] <leif> SimonSapin: With the current spec, and(color) looks correct, and it is not
# [09:25] <leif> TabAtkins: This problem applies to every ident in a parenthesis that can be next to eachother without being a function
# [09:25] <leif> dbaron: This is the problem with the function token
# [09:25] <leif> SimonSapin: Can use the function token in the grammar, but that is more complicated. Don't want to do that
# [09:25] <leif> TabAtkins: Agreed.
# [09:26] <leif> glazou: Shall we adopt SimonSapin's proposal?
# [09:26] <SimonSapin> SimonSapin: decided not to do function tokens in @supports
# [09:26] <leif> … require shite-space in MQs
# [09:26] <leif> s/shite/white
# [09:26] <leif> TabAtkins: This will come up every time we have parentheses
# [09:26] <leif> plinss: As long as you have some token between, should be valid.
# [09:26] <leif> … But want it to be consistent.
# [09:27] * Quits: jdovey (~jdovey@public.cloak) ("Colloquy for iPhone - http://colloquy.mobi")
# [09:27] <leif> glazou: People expect it to work, because it's * in the grammar.
# [09:27] <leif> Bert: Can just add a comment in the grammar.
# [09:27] <leif> plinss: But have to do it everywhere. But I don't feel strongly about and(color). Just want it consistent.
# [09:28] <leif> glazou: Why is white-space required in @supports?
# [09:28] <leif> TabAtkins: To avoid that removing a comment changes the meaning.
# [09:28] <leif> SimonSapin: @supports now requires white-space on both sides.
# [09:28] <leif> plinss: Need to adopt this anywhere we have parens.
# [09:29] <leif> glazou: Not everywhere, just when it's not a function.
# [09:29] <leif> plinss: Don't want white-space in nested parens.
# [09:29] <leif> TabAtkins: Any time an IDENT is next to a parenthesis, we require white-space.
# [09:29] <leif> plinss: on the outside of either parenthesis.
# [09:30] <leif> RESOLVED: MQ requires white-space on both sides of a parenthesis
# [09:30] <leif> Bert: Don't require it in the font shorthand
# [09:30] * Zakim leif, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [09:30] <leif> … basically the same case.
# [09:30] <leif> … If you have the font shorthand. "font: Times/**/10pt" is fine, but omit comment is not.
# [09:31] <leif> plinss: Times10pt becomes one item
# [09:31] <leif> SimonSapin: If you aren't familiar with the tokenizer, it's much more understandable than with parentheses.
# [09:31] <leif> Bert: But we're talking about consistency
# [09:31] <leif> plinss: Really only an issue with parentheses.
# [09:31] * Joins: Koji_ (~Koji@public.cloak)
# [09:32] <leif> Bert: An issue with all tokens with more than one character. Also with the ~= or the ||.
# [09:32] <leif> plinss: That's an interesting change, going back to syntax.
# [09:32] <leif> … if the attribute matcher becomes one token if they had a comment between before
# [09:32] <leif> … that's a functional change.
# [09:32] <leif> TabAtkins: A precedent of ignoring comments in weird places.
# [09:33] <leif> plinss: They kind of deserve it.
# [09:33] <leif> Bert: I guess I'm not sure which is better, but doesn't seem like a big problem at the moment. Can't see the big story yet.
# [09:33] <leif> TabAtkins: Where would we define this?
# [09:33] <leif> … Values and Units?
# [09:33] <leif> … because it changes the prop grammar.
# [09:33] <leif> plinss: Syntax?
# [09:33] <leif> … it's a fundamental thing.
# [09:34] <leif> TabAtkins: Don't want a resolution that requires us to re-ask about it.
# [09:35] <leif> RESOLVED: white-space between any IDENT an the outside of a parenthesis.
# [09:35] <leif> SimonSapin: The proposal was to require white-space on both sides.
# [09:35] <leif> plinss: Yes, do that everywhere
# [09:35] <leif> TabAtkins: That's what we require in @supports.
# [09:35] <SimonSapin> plinss: yes, both )<ident> and <ident>(
# [09:36] <leif> Bert: Just came to mind: can make 'and' a keyword, so it can be followed by paren.
# [09:36] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [09:36] <leif> TabAtkins: The issue is not related to 'and' specifically.
# [09:36] <leif> … Anytime you have keywords next to parens.
# [09:36] * Quits: kawabata (~kawabata@public.cloak) ("Page closed")
# [09:36] <leif> … Anytime a paren is valid by itself and an ident is valid next to it.
# [09:37] <leif> TabAtkins: One example is in grid syntax, if we switch to named line syntax
# [09:37] <leif> … (x y)auto needs white space.
# [09:37] <leif> … so no tightly-bounded set of keywords.
# [09:38] <leif> TabAtkins: All parentheses, or just naked parentheses? what about an ident following a function?
# [09:38] <leif> … function, the concept, not the token.
# [09:38] <leif> plinss: could it be a compat risk?
# [09:38] <leif> … ident after function.
# [09:38] * Quits: Koji_ (~Koji@public.cloak) (Ping timeout: 180 seconds)
# [09:39] <leif> fantasai: Yeah, gradient followed by length in background shorthand. A likely typo.
# [09:39] <leif> plinss: So we can't require it everywhere.
# [09:39] <leif> TabAtkins: So only naked parenthesis groups
# [09:39] <leif> plinss: We don't have naked parentheses anywhere else, so not a problem
# [09:39] <leif> dbaron: We have it inside calc()
# [09:39] <leif> TabAtkins: But you never have an ident.
# [09:39] <leif> … Need a delim, no implied multiplication.
# [09:40] <leif> fantasai: One reason why we feel it's awkard and want symmetry in MQ and @supports is that they are conjunctions.
# [09:40] <leif> … I'm happy if we just require it for conjunctions.
# [09:40] <leif> TabAtkins: If we did that, and didn't care about end parens, we could just make the parser recognize and( as a function token.
# [09:41] <leif> … dropping the comment.
# [09:41] <leif> … and be invalid.
# [09:41] <leif> plinss: I guess that's fine
# [09:41] <leif> TabAtkins: Can handle it either way
# [09:41] <leif> plinss: No, I don't think that's fine.
# [09:41] <leif> … url/**/( is not a URL token
# [09:41] <leif> … That would turn it into a function.
# [09:41] <leif> … making it valid.
# [09:42] <leif> TabAtkins: Handle it as grammar then.
# [09:42] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [09:42] <leif> … idents followed by open parenthesis must have white space between the two unless it's a function.
# [09:42] <leif> RESOLVED: (replaces previous resolution) Idents followed by open parenthesis must have white space between the two unless it's a function.
# [09:43] <SimonSapin> Topic: CSS escapes in attr() values
# [09:43] <leif> SimonSapin: attr() defined in the values spec
# [09:44] <leif> … This function now takes a parameter with expected type
# [09:44] <leif> … can pass integer etc.
# [09:44] <leif> … In the defining for string and url, we say that the absolute value is passed
# [09:44] * Joins: Rossen (~Rossen@public.cloak)
# [09:44] * Joins: myakura (~myakura@public.cloak)
# [09:44] <leif> … should clarify whether CSS escapes are interpreted, and I think they should not be.
# [09:44] <leif> … If they need to be serialized, we may need to add escapes, but that's a separate concern.
# [09:45] <leif> TabAtkins: att="foo\33", content: attr(att) displays "foo33" or "foo\33"?
# [09:45] <leif> plinss: Don't want to move escapes from one context to another.
# [09:45] <leif> … it should be resolved before.
# [09:46] <leif> glazou: Entities should not leave their context.
# [09:46] <leif> RESOLVED: String and URL types for attribute literally takes the attribute's value without parsing.
# [09:47] <leif> Topic: Alignment
# [09:48] <SimonSapin> (previous topic) In particular: clarify that no CSS escaping is involved. Probably remove wording like "parsed as the contents of a CSS <string>".
# [09:48] <leif> TabAtkins explains concepts, but not the basic properties
# [09:48] <leif> TabAtkins: This applies flexbox alignment props to rest of CSS
# [09:48] <leif> fantasai: Most keywords are axis agnostic, so put them in a separate section
# [09:49] <leif> TabAtkins: Only non-obvious are self-start and -end
# [09:49] <leif> … [missed] are defined based on the mode and directionality of the parent element
# [09:49] <leif> … self-* are defined based on the element itself.
# [09:49] <leif> … flex-start and -end are based on the flex directionality instead of the writing ode
# [09:50] <leif> dbaron: Do flex-start and -end fall back?
# [09:50] <leif> fantasai: to start and end.
# [09:50] <leif> … if not flexbox
# [09:50] <leif> fantasai: we have left and right, because sometimes you want that, but we can't always fulfil that.
# [09:50] <leif> TabAtkins: And helps explain <align>
# [09:51] <leif> fantasai: stretch depends on the layout mode, defined further down
# [09:51] <leif> … We pulled the baseline definition from 2.1 and put it here.
# [09:51] <leif> … Flexbox also has it
# [09:52] <leif> dbaron: doesn't distinguish between inline-block and [...]
# [09:52] <leif> … defined to use last-line baseline in 2.1
# [09:52] <leif> … Need to spec first-line basline and last-line baseline
# [09:52] <leif> … and which are used for different things.
# [09:53] <leif> … first-line and last-line baseline interaction is complicated, so need to define based on context, and research it.
# [09:53] <leif> … Don't expect impls to be sensible.
# [09:53] <leif> RESOLVED: Need more work on baseline section, define first-line and last-line baseline.
# [09:54] <leif> fantasai: Block-axis of table is undefined.
# [09:54] <leif> … Table with a block of text inside, with a vertical text context, then the block axis will align with the inline axis
# [09:54] <leif> … Need a concept of baseline for each box
# [09:55] <leif> … Is it based on the baseline of the first column, or does it not have a baseline?
# [09:55] <leif> TabAtkins: No testing yet
# [09:55] <leif> fantasai: Basing on first column makes sense
# [09:55] <leif> Bert: Why not center?
# [09:55] <leif> fantasai: then you would center it.
# [09:55] <leif> TabAtkins: There is a keyword for that.
# [09:56] <leif> fantasai: We'll do another pass, but needs review eventually.
# [09:56] <leif> fantasai explains distributed alignment
# [09:57] <leif> TabAtkins: space-evenly is new, based on requests to flexbox
# [09:57] <leif> fantasai: Useful for two-column layout with different layout models in each
# [09:57] <leif> TabAtkins: 'stretch' came from Grid Layout.
# [09:57] <leif> fantasai: Needed for flex lines.
# [09:58] <leif> fantasai explains overflow alignment
# [09:58] * Joins: jdovey (~jdovey@public.cloak)
# [09:59] <leif> fantasai explains justify-content and align-content
# [09:59] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [10:01] <leif> dbaron: not handled the same way as the 'align' attributes?
# [10:01] <leif> TabAtkins: We have special keyword.
# [10:02] <leif> dbaron: People have trouble following, not really working as an introduction.
# [10:02] <leif> TabAtkins explains justify-items
# [10:02] <leif> TabAtkins: can choose legacy behavior
# [10:03] <leif> dbaron: My issue was with how you mapped HTML alignment attributes that don't have a BFC.
# [10:03] <leif> fantasai: Vertical alignment in the vertical axis forces a BFC.
# [10:03] <leif> … but might need thinking about
# [10:03] <leif> … might also need horizontal axis.
# [10:04] <leif> TabAtkins: Can only use the block-axis one on blocks
# [10:04] <leif> … get center behavior by using legacy
# [10:04] <leif> … The property that does that does not have the BFC behavior
# [10:04] <leif> Bert: 'safe' and 'true' centering…
# [10:05] <leif> … I want to reintroduce true centering in text-align, even where there's a flow.
# [10:05] * Joins: jdovey_ (~jdovey@public.cloak)
# [10:05] <leif> … and margin: auto, where I want centering without clamping
# [10:05] * Parts: jdovey_ (~jdovey@public.cloak) (jdovey_)
# [10:05] <leif> fantasai: This spec takes those props and applies them to all box models
# [10:05] <leif> Bert: Don't use margins to center. Use align property to choose true center.
# [10:05] <leif> s/Bert/TabAtkins
# [10:05] * Quits: jdovey (~jdovey@public.cloak) ("Colloquy for iPhone - http://colloquy.mobi")
# [10:06] * Joins: jdovey (~jdovey@public.cloak)
# [10:06] <leif> fantasai draws case with shrink-wrapped table with margins and centering.
# [10:06] <leif> fantasai: Want at least a certain margin, but also want centering. This is a better model for that, using justify-self.
# [10:06] <leif> … have cake and eat it
# [10:07] <leif> fantasai: justify/align applies to block/inline.
# [10:08] <leif> SimonSapin: block-align and inline-align?
# [10:08] <leif> TabAtkins: Flexbox doesn't care about your writing direction
# [10:08] <leif> … prop names are not renameable.
# [10:08] <leif> … Need to discuss abspos
# [10:08] <leif> Bert: Can I use other props in the normal flow?
# [10:09] <leif> TabAtkins: Can align the entire block's contents
# [10:09] <leif> … It's defined in the spec.
# [10:09] <leif> fantasai: Vertical centering: use align-content on an element
# [10:09] <leif> TabAtkins: Spec is split into two axes and three alignments applied to them
# [10:10] <leif> Bert: last column "Applies to" answers my questions.
# [10:10] <leif> … Have to rewrite Box Model
# [10:10] <leif> Rossen: These apply to border box or margin box?
# [10:10] <leif> fantasai: Margin boxes.
# [10:11] <leif> TabAtkins: In case of vertical-aligned paragraphs, the outermost bounding box of the contents.
# [10:11] <leif> Rossen: justify-self: true center on box with 25% width and 50% left margin, will be centered with the margin box?
# [10:11] <leif> TabAtkins draws on board
# [10:11] <leif> Rossen is satisfied
# [10:12] <leif> TabAtkins: Let's talk about abspos
# [10:12] <leif> fantasai: The plan of this draft is to make it easy to center things, including abspos
# [10:12] <leif> … The containing block for your asbspos item has offsets specified
# [10:12] <leif> … That creates a modified containing block.
# [10:13] <leif> … by default, you do as in 2.1
# [10:13] <leif> … If you specify center, then you'll shrink-wrap.
# [10:13] <leif> dbaron: 2.1 isn't quite that simple. Function of wether widht and height are specified
# [10:13] <leif> TabAtkins: If neither is auto, then we do these things.
# [10:13] <leif> … was confusing to write!
# [10:14] <leif> … If you have explicit margins and left and right props, then when calculating auto width, shrink to fit.
# [10:14] <leif> dbaron: Also, when no auto width, also align.
# [10:14] <leif> Rossen: change of behavior?
# [10:14] <leif> fantasai: No, compatible with 2.1
# [10:15] <leif> TabAtkins: stretch is default. Absposes behave as in 2.1
# [10:15] <leif> TabAtkins: Possible that there are some deep details that we missed, so needs review at some point.
# [10:16] <leif> fantasai: Get true alignment in grid and flexbox, but safe alignment in doc-centric layout, i.e. tables and blocks.
# [10:16] <leif> … Can't make them all safe, because flexbox has true.
# [10:16] <leif> TabAtkins: Could define whatever for blocks
# [10:16] <leif> Rossen: Should keep doc-centric ones safe and app-centric true.
# [10:17] <leif> fantasai describes property index
# [10:17] <leif> TabAtkins: Please someone look at legacy left/right/center, is there a better way to do it?
# [10:17] <leif> fantasai: Want to express that we're enforcing alignment.
# [10:17] <leif> … Right now only with left/right/center, but if it's useful, can align with start/end.
# [10:18] <leif> … Think about: do we want to allow it for other keywords.
# [10:19] <leif> fantasai describes auto/legacy
# [10:19] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [10:20] <dbaron> http://dbaron.org/css/test/2013/transition-reversing-demo
# [10:20] <leif> Topic: Reversing interrupted transitions
# [10:21] <leif> dbaron: only tested in gecko
# [10:22] <leif> … relied on mouseenter/mouseover, but those are even worse than a decade ago
# [10:22] * Joins: myakura (~myakura@public.cloak)
# [10:22] <leif> dbaron and TabAtkins discuss JS implementation
# [10:28] <leif> dbaron explains various proposals in testcase
# [10:29] <leif> dbaron: There were other proposals, but I didn't implement
# [10:29] <leif> TabAtkins: Your proposal is better than the current spec, at least.
# [10:29] * Quits: glazou (~glazou@public.cloak) (glazou)
# [10:30] <leif> dino: Reversing is only when in a transition and you set the value to where you came from? If it has ended, run a normal transition?
# [10:30] <leif> dbaron: yes
# [10:30] <leif> SimonSapin: What if enter a transition and go to another one?
# [10:30] <leif> dbaron: No special treatment. Hard to impl. sensibly.
# [10:31] <leif> fantasai: if we have transitionin but not -out?
# [10:31] <leif> dbaron: Then will not have transitionout.
# [10:31] <leif> dino: What if a different timing function or duration? should break reversal.
# [10:31] <leif> dbaron: Disagree.
# [10:32] <leif> … in many cases people will want different timing functions, because they want that behavior.
# [10:32] <leif> … With my approach, they'll still get the specified timing function for each direction.
# [10:33] <leif> dbaron gives example with timing function on hover state
# [10:34] <leif> dino: People that care about this will want to tweak everything. Can't address that without adding props.
# [10:34] <leif> … Just make it work for the majority of cases
# [10:34] <leif> fantasai: If timing-in was 4s and -out was linear 4s…
# [10:34] <leif> dbaron: My proposal looks only at value, not timing.
# [10:35] <leif> … Sometimes 50 % through value space in 12 % of the time
# [10:35] <leif> … I say 50 % in 50 %
# [10:35] <leif> dino: If linear in both directions, 4s one way 2s in the other…
# [10:35] <leif> [not minuting clarifying discussion]
# [10:36] <leif> fantasai: What if the timing function is slow for 15% and then slow?
# [10:36] <leif> dbaron: That's ease-in
# [10:36] <leif> … If you mouse out at 50%, the time going back is close to the time going forward
# [10:36] <leif> … Time going back was shortened quite a bit
# [10:37] <leif> krit: ease-in is better with the current spec, ease-out is better with your proposal
# [10:37] <leif> dino: Depends on when you interrupt it
# [10:37] <leif> rik: goes too fast back when shortening the time
# [10:38] <leif> dbaron: Don't like discontinuity between 99% and 100%
# [10:38] <leif> dino: Some people might want an interrupted transition at 99%, pretend it finished.
# [10:38] <leif> dbaron: Mine: it gives 99% of the duration, so almost undetectable.
# [10:39] <leif> dino: Should just pick one, yours is fine. Let's implement it and see.
# [10:39] <leif> dbaron: Always like this in Gecko
# [10:39] <leif> krit: Safari just unprefixed transitions
# [10:39] <leif> dino: Concern is that people have content where they instead of transitionend event assumed that something happened.
# [10:40] <leif> … we're effectively changing t-duration on them.
# [10:40] <leif> TabAtkins: Adding a delay between the real end and the …
# [10:40] <leif> dbaron: Probably need some real events for interruption
# [10:40] <leif> … no transitionend event.
# [10:40] <leif> dino: There's interrupted and there's paused.
# [10:40] <leif> … suspended, e.g. if animations are paused on scroll
# [10:41] <leif> … duration is possibly longer
# [10:41] <leif> … People have requested that if prop is set to same value, then no transition.
# [10:41] <leif> … Adopt your proposal.
# [10:41] <leif> cabanier: Apple's spec is better, actually.
# [10:41] <leif> dino: I don't care much. Want to stop hover complaints.
# [10:42] <leif> … Safari has no reversing, so need to implement to see.
# [10:42] <leif> cabanier: Don't we already have a demo for side-by-side
# [10:42] <leif> ?
# [10:42] <leif> dino: Need a complete implementation.
# [10:43] <leif> krit: Can also be decided on CR.
# [10:43] <leif> plinss: Do we want to change?
# [10:43] <leif> TabAtkins: Spec behavior is bad.
# [10:43] <Zakim> dbaron, you asked to be reminded at this time to go home
# [10:43] <leif> krit, cabanier: no, not bad.
# [10:43] <leif> dino: We don't know, because we haven't implemented it.
# [10:44] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [10:45] <leif> … propose dbaron's suggestion. Firefox already shipped, looks good enough.
# [10:45] * Bert zakim, pointer?
# [10:45] * Zakim I don't understand your question, Bert.
# [10:45] <leif> RESOLVED: dbaron's proposal for reversing interrupted transitions is accepted.
# [10:45] * Quits: ivan (ivan@public.cloak)
# [10:45] <leif> Meeting adjourned.
# [10:45] <leif> rrsagent, make minutes
# [10:45] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/07-css-minutes.html leif
# [10:45] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [10:45] <myakura> rrsagent, make minutes
# [10:45] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/07-css-minutes.html myakura
# [10:45] * Quits: myakura (~myakura@public.cloak) ("Page closed")
# [10:47] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [10:47] * Joins: cabanier (~cabanier@public.cloak)
# [10:47] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [10:47] * Quits: kazutaka (~kazutaka@public.cloak) ("Page closed")
# [10:49] * Quits: dino (~dino@public.cloak) (dino)
# [10:49] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [10:50] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [10:51] * Joins: leif1 (~lastorset@public.cloak)
# [10:51] * Quits: leif (~lastorset@public.cloak) (Client closed connection)
# [10:51] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [10:51] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [10:52] * Quits: jet (~junglecode@public.cloak) (jet)
# [10:52] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [10:54] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [10:54] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 180 seconds)
# [10:58] * Quits: leif1 (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [10:58] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [11:01] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [11:05] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [11:06] * Joins: glenn (~gadams@public.cloak)
# [11:11] * Joins: leif (~lastorset@public.cloak)
# [11:15] * Joins: leif1 (~lastorset@public.cloak)
# [11:15] * Quits: leif (~lastorset@public.cloak) (Client closed connection)
# [11:22] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [11:24] * Joins: SimonSapin (~simon@public.cloak)
# [11:38] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [11:40] * Joins: leif (~lastorset@public.cloak)
# [11:40] * Quits: leif1 (~lastorset@public.cloak) (Client closed connection)
# [11:44] * Joins: ivan (ivan@public.cloak)
# [11:44] * Quits: ivan (ivan@public.cloak) ("bye guys")
# [12:01] * Joins: dbaron (~dbaron@public.cloak)
# [12:02] * Joins: SimonSapin (~simon@public.cloak)
# [12:03] * Joins: cabanier (~cabanier@public.cloak)
# [12:04] * Joins: krit (~krit@public.cloak)
# [12:09] * Joins: glenn_ (~gadams@public.cloak)
# [12:11] * Joins: lmclister (~lmclister@public.cloak)
# [12:13] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [12:16] * Joins: krit1 (~krit@public.cloak)
# [12:16] * Joins: liam (liam@public.cloak)
# [12:20] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [12:21] * Quits: krit (~krit@public.cloak) (Ping timeout: 180 seconds)
# [12:26] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [12:37] * Quits: krit1 (~krit@public.cloak) ("Leaving.")
# [13:00] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [13:01] * Joins: cabanier (~cabanier@public.cloak)
# [13:08] * Joins: krit (~krit@public.cloak)
# [13:14] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [13:19] * Joins: krit (~krit@public.cloak)
# [13:19] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [13:23] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [13:24] * Joins: dino (~dino@public.cloak)
# [13:38] * Quits: glenn_ (~gadams@public.cloak) (Client closed connection)
# [13:42] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [13:53] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [15:01] * Zakim excuses himself; his presence no longer seems to be needed
# [15:01] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [15:11] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [15:27] * Joins: plh (plehegar@public.cloak)
# [15:28] * Joins: plh3 (plehegar@public.cloak)
# [15:34] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [15:41] * Quits: plh3 (plehegar@public.cloak) ("Leaving")
# [15:45] * Joins: dbaron (~dbaron@public.cloak)
# [15:45] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [15:45] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:49] * Joins: leif (~lastorset@public.cloak)
# [15:52] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [15:58] * Joins: SimonSapin (~simon@public.cloak)
# [15:58] * Joins: cabanier (~cabanier@public.cloak)
# [16:02] * Quits: dino (~dino@public.cloak) (dino)
# [16:16] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:25] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [16:33] * Joins: leif (~lastorset@public.cloak)
# [16:33] * Joins: krit (~krit@public.cloak)
# [16:41] * Joins: tantek (~tpod@public.cloak)
# [16:41] * Quits: tantek (~tpod@public.cloak) ("Colloquy for iPod touch - http://colloquy.mobi")
# [16:48] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [16:49] * Joins: SimonSapin (~simon@public.cloak)
# [16:50] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [16:51] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
# [16:51] * Joins: leif (~lastorset@public.cloak)
# [16:52] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [16:58] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [16:58] * Joins: leif (~lastorset@public.cloak)
# [17:01] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [17:10] * Joins: leif1 (~lastorset@public.cloak)
# [17:10] * Quits: leif1 (~lastorset@public.cloak) ("Leaving.")
# [17:10] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
# [17:26] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:48] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:12] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:13] * Joins: arno (~arnog@public.cloak)
# [18:33] * Joins: arno1 (~arnog@public.cloak)
# [18:37] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [18:37] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:38] * Quits: arno (~arnog@public.cloak) (Ping timeout: 180 seconds)
# [18:44] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:52] * Joins: jet (~junglecode@public.cloak)
# [19:06] * Quits: arno1 (~arnog@public.cloak) (Client closed connection)
# [20:00] * Joins: arno (~arnog@public.cloak)
# [20:02] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [20:02] * Joins: arno (~arnog@public.cloak)
# [20:05] * Quits: jet (~junglecode@public.cloak) (jet)
# [20:10] * Joins: jet (~junglecode@public.cloak)
# [20:18] * Quits: abucur (~Adium@public.cloak) (Client closed connection)
# [20:18] * Joins: abucur (~Adium@public.cloak)
# [20:20] * Quits: jet (~junglecode@public.cloak) (jet)
# [20:32] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [20:44] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [20:56] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [21:06] * Joins: darktears (~darktears@public.cloak)
# [21:06] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [21:21] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [21:45] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [23:02] * Joins: arno (~arnog@public.cloak)
# [23:03] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [23:07] * Joins: arno (~arnog@public.cloak)
# [23:40] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# Session Close: Sat Jun 08 00:00:00 2013

The end :)