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