08:03:11 RRSAgent has joined #CSS 08:03:11 logging to http://www.w3.org/2010/11/02-CSS-irc 08:03:19 ScribeNick: jdaggett 08:03:29 Meeting: CSS fatf @ TPAC 08:03:33 komasshu has joined #css 08:03:36 zakim, call Rhone_1 08:03:36 ok, Bert; the call is being made 08:03:37 Team_(css)08:01Z has now started 08:03:38 Meeting: CSS ftf @TPAC 08:03:38 +Rhone_1 08:03:43 +[Microsoft] 08:03:48 rrsagent, make logs public 08:03:49 hidetaka has joined #css 08:04:37 topic: grids 08:04:43 szilles has joined #css 08:05:31 phil cupp on the phone from ms 08:05:40 MoZ has joined #css 08:05:53 alexmog has joined #css 08:06:00 dbaron has joined #css 08:06:02 anne has joined #css 08:06:12 http://www.interoperabilitybridges.com/css3-grid-align/ 08:06:24 +unl 08:07:37 alex: need some good 2d layout mechanism in css 08:07:52 alex: need for ui apps not just free-flowing text 08:08:05 -unl 08:08:20 alex: several proposals for grids/table like layout 08:08:55 alex: looked at requirements first 08:08:57 -Rhone_1 08:09:44 zakim, call Rhone_1 08:09:44 ok, Bert; the call is being made 08:09:46 +Rhone_1 08:10:14 dbaron has joined #css 08:10:25 -Rhone_1 08:11:13 zakim, call Rhone_1 08:11:13 ok, Bert; the call is being made 08:11:15 +Rhone_1 08:11:39 eureka 08:12:11 alex: now back to the show 08:12:19 alex: we like our proposal 08:12:42 alex: how does this relate to previous proposals? 08:12:56 freedom has joined #css 08:13:39 alex: this proposal is based on xul, wpf-grid, probably closest to wpf-grid 08:14:06 alex: but uses flex box like elements (?) 08:14:19 alex: make sense? 08:14:33 alex: let's go over the spec 08:15:07 TabAtkinsTPAC has joined #css 08:15:16 alex: grid works by defining grid lines 08:15:37 alex: layout using row, column coords and how many columns it overlaps 08:15:42 fsasaki has joined #css 08:15:57 alex: grid sizes to content 08:16:18 jun has joined #css 08:16:32 alex: works for both fixed/float cases 08:16:59 alex: define using 08:17:12 alex: display: grid | inline-grid 08:17:44 kennyluck has joined #CSS 08:18:32 cslye has joined #CSS 08:18:39 r12a-nb has joined #CSS 08:18:45 alex: grid-column, grid-row with value to define grid 08:19:04 alex: (looking at ex 2) 08:19:40 dbaron: what are the values of grid-columns, grid-rows? 08:20:11 alex explains syntax 08:22:42 present currently: elika, bert, håkon, peter, markus, tab, beth dakin, richard ishida, steve z, daniel, ms john, sylvain, koji, dbaron 08:23:02 markus: values are from template spec 08:23:54 alex: columns, rows can overlap 08:24:05 alex: lots of interesting overlap cases 08:24:45 alex: for example, equivalent of xul stack layout with single slot w/ multiple items stretching to largest 08:25:47 jdaggett: does this have features that template doesn't support? 08:25:53 alex: overlapping elements 08:26:29 bert: also, this allows you to automatically grows grid with content 08:26:49 bert: I explicitly left that out of Template to keep it simple 08:26:55 sylvain: yeah, if you add content at 5,5 to a 3,3 grid it grows automatically 08:27:31 alex: useful for sparse grids, or grids where order can change 08:27:41 markus: no-brainer if know tables 08:27:47 alex: no ascii art 08:27:54 jdaggett mourns this 08:28:32 bert: syntax question, many ways to express concept 08:28:40 fantasai: snap to grid functionality? 08:28:58 alex: not yet, every item is explicitly placed 08:29:50 fantasai: not a fan of positioning aspect 08:30:06 fantasai: but a flex box layout aligned to grid woud be groovy 08:30:36 glazou 'grid-cell: 'selector'' can be added afterwards 08:30:46 fantasai: using flexbox or template to align would not break with reflow 08:31:11 peter: typically grids are defined by lines not cells 08:31:44 peter: and align to line, not cell 08:32:04 mollydotcom, exacty. I think flexbox or template + snap-to-grid would be great 08:32:22 jdaggett: didn't you propose grid positioning with grid lines? 08:32:31 alex: no real contradiction between the two 08:32:34 mollydotcom, It seems to me easier to lose, and less likely to break with reflow effects (window resizing, font resizing, changing content, etc.) 08:33:11 alex: we didn't want to combine the two 08:33:13 peter: I want to align to a gridline. And I'd probably want to align to a named gridline, so I can insert arbitrary grid lines later and not have it move 08:33:29 alex: could have circular dependencies 08:33:58 alex: i would to see both 08:34:17 alex: but don't want to spend the whole time resolving dependencies 08:34:44 alex: can do the same with this as with gridlines 08:35:28 jdaggett: Graphic design books that talk about grids, was more along what Peter was saying 08:35:38 jdaggett: This model you're going to have to do extra work to define that 08:35:54 markus: two core use cases 08:36:06 markus: 1. print design layouts 08:36:21 markus: 2. app layouts 08:36:28 markus: this is more for (2) 08:37:01 alex: grids in print don't deal with resizing issues 08:37:36 alex: much better to have some that are fixed, some that flex 08:38:24 alex: when grid is sized by content is actually more useful but doesn't cover all scenarios 08:38:37 stevez: symbolic identification 08:38:44 Peter` has joined #css 08:38:45 stevez: names to cells? 08:38:54 fantasai: that's what template does 08:39:08 alex: we have started with minimal feature set 08:39:26 peter: i don't want to name cell, i want to name lines 08:39:51 peter: if a grid row/line is added in the middle, the grid shrinks 08:40:10 peter: i want to span from one gridline to another 08:40:22 peter: even if lines are added in between 08:40:43 peter: could be dynamic or for additive layout 08:40:58 peter: like in the case when you just want to add a logo to a layout 08:41:17 Bert, files are in http://dev.w3.org/cvsweb/csswg/css-device-adapt/ but not in http://dev.w3.org/csswg/css-device-adapt/ ? 08:42:00 pcupp: we thought about a pseudo-element that spans cells (?) 08:42:23 pcupp: the cell defines a region for content to be laid out 08:42:29 (Maybe Peter is thinking of something like: 'grid-columns: a=0%, b=75%, c=50%' and then 'grid-column: c'?) 08:42:41 pcupp: maybe it's aligned, maybe it stretches 08:43:26 pcupp talking about an example... 08:43:39 markus: just a slightly different use case 08:44:02 alex: can it be used as gridlines? no, not just with this 08:44:18 alex: but we want to have some form of gridline like capability 08:44:32 fsasaki has joined #css 08:44:38 sylvain: i think we need to capture peter's use case 08:44:48 sylvain: of inserting new gridlines 08:45:23 peter: this defines cells but i don't think we need another way of defining cells 08:45:45 alex: this is about grid alignment of cells 08:45:59 peter: I understand this gives some more capabilities that template doesn't have, but let's improve template and use this module to do something different 08:46:05 alex: obviously we can take it further 08:46:25 peter: give me the ability to name a gridline 08:47:05 peter: so that i can say "this thing goes in a box that goes between these things" 08:47:23 s/things/gridlines/ 08:47:27 peter: this way i can define my cells arbitrarily 08:48:15 peter: rows/columns we already have, i want new toys 08:49:08 daniel: peter's proposal is not far away from my proposal to define layout with respect to other elements 08:49:21 murmurs of disagreement 08:49:49 I think this is pretty different, since this contains things properly so things won't overlap. 08:50:26 continuing through spec 08:50:33 dbaron: : no verlap ? 08:51:17 alex: there is a property that controls the order of rendering 08:51:19 joonho has joined #css 08:51:27 alex: to deal with overlapping elements 08:51:32 alex: not super important 08:51:52 (section 8 of spec) 08:52:07 peter: what if you just use z-index? 08:52:12 alex: we can discuss that 08:52:19 peter: i don't see the difference 08:52:33 alex mumbles... 08:52:39 and smiles 08:53:07 daniel: i'm considering working on peter's proposals 08:53:21 daniel: i have a few ideas about this 08:53:34 howcome: use cases would be interesting 08:53:40 howcome: for comparison 08:54:01 daniel: i'll work on the ideas, then the use cases if i have time 08:54:14 stevez: there were previous proposals for... 08:55:01 stevez: a two-column layout with a figure in the middle 08:55:15 stevez: there's an issue with how to overlay 08:55:31 howcome: that's in gcpm!! 08:55:49 howcome: but this is app centric, not document centric 08:56:07 peter: lots of use cases for document centric uses 08:56:22 daniel: this is really about app centric use 08:56:30 alex: concurs 08:56:37 stevez: i'm dazed and confused 08:56:56 I believe template + flex coudl do most of these layouts, aside from the overlapping ones 08:57:17 stevez: i thought you were tailoring the syntax for one use 08:57:40 exr has joined #css 08:57:50 markus: there's an aspect.... 08:58:12 pcupp: we think it's the common case where controls are composed using this 08:58:31 section 2.4, figure 6 08:58:44 picture of a slider 08:58:56 because the world needs more sliders... 08:59:12 alex: what can we do with this? new module? merge with another? 08:59:34 bert: seems close to flex box 08:59:46 tab mumbles 09:00:01 bert: i have a number of comments 09:00:36 bert: when you put two elements in the grid they overlap, they don't add 09:00:43 bert: might be good or bad 09:00:57 markus: you need it as in the slider example 09:01:12 tab: this example is also nice for being able to overlap 09:01:23 +1 for tab's comment 09:01:24 bert: what's the intrinsic size in this case? 09:01:34

? 09:02:07 alex: multiple items in cell all affect sizing 09:02:14 tab: I provided an example in my response to the grid-align thread where it was useful to be able to position multiple items in one cell and have them flow together, rather than overlap. However, overlapping is *also* useful. 09:02:19 bert: don't like three props, why not one 09:02:43 alex: yeah but that would be a long line 09:03:27 alex: well you don't need to specify predefined size 09:03:38 bert: wondering float and position 09:03:46 alex: works just like flex box 09:03:50 I'd prefer not to put complicated syntax inside values of 'display'. 09:04:07 alex: float ignored, position with regards to nearest positioned element 09:04:23 tab says something i don't understand 09:05:01 alex: position might also work the same way but not affect sizing 09:05:37 tab: in my position layout proposal, i came up with a good model for positioning in new layout proposals 09:06:12 I think alex said there are two options for position: absolute: the normal way (placeholder, etc.) or position according to grid rows/columns but not affect sizes of the grid rows/columns. 09:06:14 argh, not following tab again... 09:06:42 alex: the way to think about absolute positioning 09:07:08 alex: with a grid it's obvious where it's positioned 09:07:10 yuma_1985 has joined #css 09:07:11 TabAtkinsTPAC: In my Positioned Layout proposal I specified a consistent and easy way to make positioning interact with other layout modes. 09:07:12 alex and bert discuss this 09:07:28 TabAtkinsTPAC: The positioned element leaves behind a placeholder element. 09:07:58 bert: difference between grid-row and grid-rows is just one letter 09:08:06 same for columns 09:08:32 syntax discussion 09:08:56 TabAtkinsTPAC: You could then use the grid properties to position the placeholder, which would affect the 'auto' position of the abspos box (what it means for "top:auto", etc.) 09:09:01 bert: for flex box the content is in a given order 09:09:21 bert: with this proposal the source order doesn't affect the order in the grid 09:09:34 alex: one possible extension is auto-incrementing rows/columns 09:09:40 alex: this is closer to xul grid 09:10:03 dbaron: also auto-incrementing row-groups/column-groups 09:10:45 and you could allow them to take grid-row/grid-column (or lines) and not start at the top-left 09:11:10 bert: the idea that you auto-create the table based on a single cell 09:11:26 bert: but you can't catch errors in your design 09:12:19 bert: because it's not based on explicitly named entities 09:12:36 alex: either way you need to define a protocol here 09:12:51 bert: i'm not sure plus/minus but it does mask errors 09:13:03 bert: you don't allow % in cell size 09:13:25 alex: could be added 09:13:41 tab: what exactly do you want to base the % on 09:14:05 tab: you need to explain which the % is based one 09:14:23 komasshu has left #css 09:15:03 komasshu has joined #css 09:15:23 dbaron: i was thinking of someone designing a page 09:15:39 with embedded grids with constraints between elements 09:15:58 dbaron: with this proposal you would use nested grids 09:16:35 +1 to David's proposal 09:16:55 dbaron: are there cases where nested grids need to line up with ... 09:17:06 peter: this is why gridlines are handy 09:17:09 Ibrahima_ has joined #css 09:17:16 s/why/why named/ 09:17:36 (DBaron wants something like constraints on the columns widths: a = b = c, d = e, sum(a.e) = parent, but not relation between a,b,c on one hand and d,e on other...) 09:17:58 pcupp: so you're talking about how to line up nested grids with outer grid 09:18:27 pcupp: with unioned gridlines, spanning behavior becomes hard to predict 09:18:39 pcupp: things tend to grow in unpredictable ways 09:19:19 dbaron's drawing: 09:19:24 +--------------+ 09:19:25 | | 09:19:25 | +--+--+ 09:19:25 | | | | 09:19:25 +--+--+--+--+--+ 09:19:27 | | | | | 09:19:30 +--+--+--+ | 09:19:30 bert: also, you can't put something in your cousin grids, only grids within single tree 09:19:32 | | 09:19:35 +--------------+ 09:19:58 ah, we do so need ascii art 09:20:05 bert: just a remark 09:20:11 bert: this is hard 09:20:29 bert: cesar found examples where this might be handy 09:20:44 stevez: why is that a good thing? 09:21:15 bert and steve discuss trees and kissing cousins 09:22:09 stevez: similar to separating template from content 09:22:24 bert: you can select different grids from screen size 09:22:46 bert: you can use the body element to hook your grid on 09:23:26 bert: those are my comments 09:23:37 fantasai: you might also want named grids 09:23:44 fantasai: main and secondary 09:24:09 fantasai: but maybe i don't totally understand 09:24:20 alex: we would like to make this an editor's draft 09:24:23 (Something like: 'grid-column: a.1' for column 1 in grid a?) 09:24:29 alex: what else do we need to get there? 09:25:03 alex: we can make changes to deal with use cases and functionality discussed 09:25:17 stevez: how many table-like layout mechanisms do we need 09:25:19 ? 09:25:26 markus: you need a variety 09:25:50 markus: you need abosolute positioning, flex box, grid 09:26:02 markus: each solves a different use case 09:26:20 howcome has joined #css 09:26:27 pcupp: overlap in grid / flexbox use 09:26:49 pcupp: they're complimentary 09:26:55 peter: this is a 2d flexbox 09:27:05 stevez: there are comonalities 09:27:12 stevez: declaring size 09:27:21 stevez: concerned about complexity 09:27:27 markus: in the end it all makes sense 09:27:36 markus: app vs. doc roles 09:27:50 s/size/size constraints/ 09:27:57 tab: steve, your concern is that we get too much complexity? 09:28:12 stevez: it's that we have a lot of ways of defining cellsize 09:28:26 stevez: are the pieces the same across all three sizes? 09:28:44 tab: you can express everything in one master model 09:28:59 tab: different uses require different layout models 09:29:19 tab: layout models interact in orthogonal ways 09:29:30 tab: make each as easy as possible 09:30:29 stevez: i'm ok with that but i want to make sure that concepts carry across the models 09:30:40 stevez: the base primitives need to be consistent 09:31:15 tab: yes, you want primitives to work across layout models (?) 09:31:34 howcome: healthy competition across modules is good 09:31:50 howcome: this model and template don't make sense together 09:32:30 stevez: is there an action item for bert/alex to combine these ideas 09:33:05 bert: future ideas, non-rectangular cells, chained cells 09:33:10 howcome: and across pages 09:33:25 bert: so the question is how these concepts fit with that 09:33:44 peter: grids that flow across pages or grids that repeat 09:33:57 peter: can we use the same syntax for both 09:34:09 markus: need to be careful about use cases 09:34:24 markus: if combination is complex, life sucks for everyone 09:34:41 peter: one problem is that you're calling this a grid 09:35:01 peter: it's not really a grid 09:35:15 stevez talking about the beauty of xsl 09:35:39 markus: need to solve both print-like and app use cases 09:36:07 markus: two action items, alex/bert to kibbitz 09:36:26 markus: and talk with daniel about his ideas 09:36:36 peter: may end up with 90% overlap 09:36:57 stevez: could be true, punchout or overlay, small set of props captures both 09:37:11 stevez: a model for both is important 09:37:25 stevez: no problem if app is favored, since docs are harder 09:37:34 peter: i just want us to be thinking about this 09:37:58 markus: yeah, maybe grid is not the best name here 09:38:23 fantasai: grid-columns and grid-rows are common to both grid specs? 09:38:36 alex: yeah, we have to merge or redefine 09:38:51 discussion of what to do with the document 09:39:25 daniel: grids are already in the charter 09:39:47 stevez: not sure this is FPWD ready 09:40:01 stevez: we should do some vetting 09:40:22 daniel: don't need to name it now 09:40:32 markus: first agree on what's in these specs 09:40:48 -[Microsoft] 09:40:50 timeless_mbp has joined #css 09:40:56 break for coffee and champagne 09:41:17 RRSAgent, make minutes 09:41:17 I have made the request to generate http://www.w3.org/2010/11/02-CSS-minutes.html myakura 09:43:02 kennyluck has joined #CSS 09:43:50 -Rhone_1 09:43:51 Team_(css)08:01Z has ended 09:43:53 Attendees were Rhone_1, [Microsoft], unl 09:44:51 komasshu has joined #css 09:47:06 glazou has joined #css 09:48:57 yuma_1986 has joined #css 09:49:28 mjs has joined #css 09:52:43 cslye has joined #CSS 09:58:43 shan has joined #css 10:06:17 dethbakin has joined #css 10:07:25 jun has joined #css 10:08:39 homata has joined #CSS 10:08:46 shepazu has joined #css 10:09:28 hidetaka has joined #css 10:09:36 dethbakin has joined #css 10:11:06 glazou has joined #css 10:11:16 ScribeNick: TabAtkinsTPAC 10:11:23 http://dev.w3.org/csswg/css3-writing-modes/ 10:11:38 http://dev.w3.org/csswg/css3-writing-modes/ 10:12:29 fantasai: In the draft, I define some terms and drew some pictures. 10:12:35 fsasaki has joined #css 10:13:00 MikeSmith has joined #css 10:13:15 howcome: I suggest simplifying the terms to 'inline direction' and 'block direction', not '* flow directionality'. 10:13:35 szilles: I think "directionality" is a hard word for non-English speakers. 10:13:41 fantasai: Okay, don't have an opinion much. 10:13:43 timeless_mbp has joined #css 10:13:57 fantasai: Most of the bidi text here is just copied from css 2.1. 10:14:22 section 3.2. title typo: 'uncode-bidi' 10:14:52 dbaron: Could we have an additional set of parens on the unicode-bidi property, so we don't have to rely on knowing the relative strength of the opeerators? 10:15:14 fantasai: 'isolate' is a new unicode-bidi value, proposed by the bidi for html group. 10:15:29 fantasai: That prevents strings that have a different directionality from having an effect on the text around them. 10:15:30 Kai has joined #css 10:15:52 fantasai: There's also a plaintext value, which is intended to use the unicode bidi algorithm to determine the bidi direction of each paragraph. 10:16:03 r12a-nb has joined #css 10:16:05 fantasai: This does *not* affect the direction property, it just affects bidi resolution. 10:16:20 aharon: Should I give use-cases for 'isolate' and 'plaintext'? 10:16:24 szilles: Would be helpful. 10:16:42 aharon: 'isolate' is useful in the context of a webapp that is inserting data into a page. 10:16:56 http://www.w3.org/TR/2010/WD-html-bidi-20100304/ has some use cases for these new features, no? 10:16:59 MoZ has joined #css 10:17:04 shepazu has joined #css 10:17:05 aharon: Frex, I'm displaying search results, and the title of the results are outside data and may not be in the same language as the rest of the UI. 10:17:34 aharon: If you don't isolate the titles, it quite often interacts with the stuff around it, such as numbers and other neutral characters. 10:18:23 aharon: Outside of an app, it's useful for quotes and links - I can't imagine why you'd want a link to be broken up into two parts due to its directionality interacting oddly with the surrounding content. 10:18:33 fantasai: It drastically reduces the number of LRM/RLM you have to use. 10:19:04 aharon: Side thought - I think instead of "inline direction", use "inline base direction". 10:19:15 aharon: The base direction is controlled by the 'direction' property. 10:19:19 aharon: Might be good to use the term "inline base direction" instead of "inline directionality" 10:19:30 (given the previous discussion about avoiding the term "inline directionality") 10:19:34 aharon: There are a couple of problems. You might not know what the direction is - it could be outside data. 10:19:53 aharon: It is very useful to let the UA guess what the direction is using standard algos based on the characters in the data. 10:20:13 aharon: There is a separate proposal in HTML for @dir=auto to do this. 10:20:21 s/to do this// 10:20:35 aharon: That's not precisely what we have here in 'plaintext'. 10:20:57 aharon: The UA, in HTML, sees dir=auto, looks at the content, decides whether the direction is rtl or ltr, then sets the CSS 'direction' appropriately. 10:21:12 aharon: That's good, but doesn't go quite far enough. 10:21:26 aharon: Let's say I have a textarea - plaintext - that the user is typing into. 10:21:53 aharon: Is it fairly useful to have some paragraphs in one language and some paragraphs in another language. Frex, I'm typing in a restaurant review in Hebrew. 10:22:25 aharon: I give the review in Hebrew, then say "the address is:..." and give it in French because the restaurant is in Lyon. If I don't switch the direction of the paragraph, the number at the start of the address will go on the wrong side. 10:22:38 aharon: So you want the ability to have paragraphs that go in different directions. 10:22:48 aharon: If you're doing markup, that's great - you can just make separate paragraphs. 10:22:58 aharon: If you're just typing into a textarea, though, you cant' do that. 10:23:20 aharon: The unicode bidi algorithm defines a simple way to define the directionality of each paragraph (where "paragraph" is defined by the bidi algorithm). 10:23:40 aharon: So 'plaintext' would say that the textarea isn't necessarily ltr or rtl, it's plaintext where each paragraph can go either way. 10:23:59 aharon: It's still not limited to textarea, of course - often after taking the data from a textarea you want to then display it. 10:24:20 aharon: So you want to still be able to apply this same directionality algorithm to the results outside of a textarea. 10:24:55 aharon: You can't hide the directionality determination from CSS with dir=auto here, because the different paragraphs aren't marked up as explicit elements. 10:25:12 dsinger has joined #css 10:25:12 dbaron: [question about which characters serve as paragraph separators] 10:25:50 aharon: The unicode algorithm is very precise about which characters are paragraph separators. In the past, some browsers didn't follow that exactly, which is basically a bug. 10:26:02 Bert: What's the difference between 'embed' and 'isolate'? 10:26:26 aharon: 'embed' says "this element has a base direction", but that doesn't prevent the element from affecting stuff outside of it. 10:27:01 aharon: So, if I have an english paragraph, but in the middle is an arabic word and then an embed of a separate element which is explicitly rtl. 10:27:16 aharon: The unicode algorithm says that the arabic and the rtl are merged together and will both flow rtl together. 10:27:34 aharon: You don't want this - logically, the arabic and the embed are separate, and shouldn't stick together. 10:27:58