00:32:32 nvdbleek has joined #css 02:03:40 nvdbleek has joined #css 03:16:45 lmclister has joined #css 04:33:08 tommyjtl has joined #css 04:36:18 hober has joined #css 04:40:38 taoniud has joined #css 04:45:37 jdaggett has joined #css 05:51:20 lmclister has joined #css 06:16:08 tommyjtl has joined #css 06:24:20 tommyjtl_ has joined #css 06:26:28 tommyjtl has joined #css 06:27:22 tommyjtl_ has joined #css 06:40:21 tommyjtl has joined #css 06:48:49 shans_ has joined #css 06:49:12 tommyjtl_ has joined #css 06:50:29 tommyjtl has joined #css 06:53:04 tommyjtl_ has joined #css 06:53:31 tommyjtl has joined #css 06:54:19 tommyjtl_ has joined #css 06:58:04 tommyjtl_ has joined #css 07:00:19 plh has joined #css 07:00:19 florian has joined #css 07:01:57 tommyjtl has joined #css 07:06:50 Zakim has joined #css 07:07:08 zakim, remind me in 9 hours to go home 07:07:09 ok, plinss 07:11:18 tommyjtl has joined #css 07:12:08 dauwhe has joined #css 07:12:29 tommyjtl_ has joined #css 07:12:40 gregwhitworth has joined #css 07:13:13 glazou has joined #css 07:13:18 ScribeNick: gregwhitworth 07:13:21 dbaron has joined #css 07:14:06 andreyr has joined #css 07:14:22 Rossen_ has joined #css 07:16:07 Bert_projector has joined #css 07:16:55 text-overflow : ellipsis-lastline 07:16:58 andreyr: Text overflow ellipsis 07:17:06 > There's no way to ellipsis a multiline block of text. There's an Opera specific -o-ellipsis-lastline that does exactly, It should clamp an HTML element by adding ellipsis to it if the content inside is too long. 07:17:07 ikilpatrick has joined #css 07:17:15 andreyr: There doesn't seem to be a way to ellipsis multiline of text 07:17:16 glenn has joined #css 07:17:19 https://github.com/Merri/ellipsis-lastline 07:17:30 SteveZ has joined #css 07:18:02 andreyr: One of the versions of opera has ellipsis-lastline 07:18:18 tommyjtl has joined #css 07:18:27 zcorpan has joined #css 07:18:33 andreyr: You might have multiple boxes with wrapping, so it gets really complicated 07:18:58 andreyr: If you have 10 different rectangles with news info you would need ellipsis to show there is more text 07:19:21 Rossen: We have discussed block overflow ellipses 07:19:53 It seems easy with just text, if you have tables, flex, images where do you ellipse? 07:20:18 Rossen: When you try to generalize it as a web platform solution it becomes very difficult 07:20:28 we had a thread at http://lists.w3.org/Archives/Public/www-style/2013Oct/thread.html#msg624 07:20:41 Andreyr: Does it have to be anything beyond text 07:21:32 dbaron: Someone just needs to come up with a proposal in each case and then we can determine whether it is ok 07:21:49 dbaron: Authors will figure out how to/not to use it because it is in demand 07:21:57 See also -webkit-line-clamp 07:22:03 rossen: This is one of the number one requests 07:22:38 rossen: then when we start talking about how their going to use the content they tell us they don't have control over the content 07:23:17 rossen: can we assume that you only have text and the answer is normally "No" 07:24:00 rossen: it's easy to say this on the first level, but when we start referring to children with different display types and floats this becomes complicated 07:24:52 dbaron: text is normally inside something else, and inside something else 07:25:11 rossen: this makes it hard to determine what to truncate 07:25:19 rossen: it's not trivial 07:26:04 andreyr: Can I get help, TabAtkins and GregWhitworth offer for help 07:26:35 plh: Rossen, can you put these problem examples together? 07:27:10 bert: If you have a region but want a continuation mark, not ellipses how do you do this? 07:27:20 http://wiki.csswg.org/spec/css4-ui#text-overflow-block-hint 07:27:42 rossen: isn't this what we discussed in Seoul? Being able to control the overflow but also the marker so that you can add events and design it 07:28:28 rossen: Then having the regular ellipsi inserting the fade gradient and how to add eventing 07:29:00 andreyr: Hover if very common in this functionality 07:29:43 andreyr: here's a wiki about block elipsis http://wiki.csswg.org/spec/css4-ui#text-overflow-block-hint 07:29:46 bert: Is this the same mechanism for continuation mark, or is it a different? Can we combine overflow: ellipsis and overflow: paged? 07:30:08 rossen: yes, that is what we were wanting to have. It has to be mutually exclusive 07:30:29 rossen: I don't want to have overflow: scroll and ellipse 07:31:06 florian: yes scroll and ellipses doesn't make sense but I do think of use cases for ellipses and paged 07:31:36 florian: overflow ellipses doesn't send the content somewhere else 07:31:56 rossen: sure we can have overflow: block ellipses paged, and block ellipses continue 07:32:21 rossen: if we figure out block ellipses we can add this functionality 07:32:48 bert: we will want to be able to extend it, so let's not design ourselves into a corner 07:33:19 chrisl: you can have the content in a footnote and have it linked up 07:33:29 andreyr: We can meet up later to discuss this 07:33:34 andrey: now to the next one 07:33:35 Note to self: elt { flow-name: fo; } elt2 { content: extract-flow(foo) | copy-flow(foo) | continue-flow(foo); } 07:33:49 Ability to control the number of lines of "context" to show in a scrollable content editable 07:33:58 http://bloomberg.github.io/chromium.bb/repros/cursorContext.html 07:34:58 yamamoto has joined #CSS 07:34:58 (ideas discussed over dinner based on Bert's comments yesterday) 07:35:00 andrey: keep pressing enter, to add the scroll bar by going to the bottom of the viewport 07:36:11 andreyr: Currently this is working in Safari, Webkit, Firefox and IE 07:36:31 andreyr: I thought this was a bug in Chrome 07:37:49 fantasai: When you're in a content editable, and you move the cursor up it starts scrolling because you're beyond the edge of the screen. We could call it carrot context to to show visibility of lines 07:38:09 ted: it seems like a quality of implementation issue 07:38:42 glazou: the mechanism doing it is in the word editor, not the browser 07:38:59 bert: like highlighting text to show the cursor 07:39:29 alan: There is the editing explainer that this might be beneficial to be brought up to them 07:39:36 andreyr: Does Chrome agree with that 07:39:41 Tab: Sure, file a bug 07:39:59 Resolution: Quality of implementation issue 07:40:00 glazou: some online editors want to control finely caret's position inside the editable area but is this on the browser side or the app side? 07:40:00 perhaps add to http://w3c.github.io/editing-explainer/ 07:40:14 :focusWithin 07:40:21 > I'm sure there's a better name, but a selector that would match if that element or any of its children currently has > focus. Without this a parent can't change its appearance when focus enters an inner element, for example adding a glow > around a section for a page that has multiple forms on screen and you want an indication what larger subset of the page in > currently being operated on. 07:40:43 http://lists.w3.org/Archives/Public/www-style/2013Apr/0713.html 07:40:47 (it was previously proposed as :contains-focus) 07:40:54 :focus, :has(:focus) 07:41:08 andreyr: This is a previously reported issue 07:41:49 TabAtkins: We have the :has selector now so you should be able to test this without doing a special case 07:42:05 TabAtkins: It's already in the spec it just needs to be implemented 07:42:32 florian: Does this work on the children psuedo elements 07:42:41 TabAtkins: It should, not sure why it wouldn't 07:43:02 Fixed & Sticky positioning inside overflow:scroll inner divs 07:43:13 > Position:fixed and position:sticky are great, but for some strange reason they are only relative to the entire document. > If you have a little scrollable div in the middle of your page it is perfectly reasonable to expect the same fixed and > sticky positioning could be done relative to your nearest overflow scrolling parent. This would enable things like fixed > headers for scrolling tables and lists. 07:44:05 andreyr: If it would help, I can put together an example if that would help 07:44:14 dbaron: is sticky different from fixed here? 07:44:27 andreyr: Maybe it's better to wait for an example 07:45:09 Tab: What do you mean 07:45:41 glazou: If you scroll the window it will move, if you scroll the inner content it the fixed header will be there 07:45:49 TabAtkins: looking into abspos 07:45:52 Rossen: huh 07:46:17 Tab: Make a container, give it an abspos child and scroll. It will not act like a fixpos when scrolling 07:46:49 Tab: It's like fixed relative to the container than the document 07:46:57 Rossen: it's not going to scroll 07:47:01 glazou: just make the test 07:47:08 Tab: That's what I'm doing right now 07:47:50 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3167 07:48:14 Tab: Shows testcase 07:48:28 The red box should stay in the corner 07:48:46 Tab: Assuming we want to update the positioning spec, this sounds reasonable 07:49:09 Tab: if we build positioning primitives this will pop out as something we can do 07:49:57 rossen: there are still work arounds for this 07:50:37 andreyr: I guess this isn't a huge issue, but we have work arounds for everything already and we don't want to do them 07:50:46 Tab: I had a draft of them and the group didn't want it 07:50:52 Rossen: Well you went a little bit too far 07:51:05 andreyr: is there something I can start with 07:51:17 tab: There isn't currently, I went down a rabbit hole 07:51:25 andreyr: I'll put something together 07:51:36 Next item: Adoption of new process 07:52:02 glazou: Never mind, next face to face dates 07:52:50 dbaron: There are some price cliffs based on the dates. I think it happens to deal with vacations, so we should shift it by a week (at least right now) 07:53:09 dbaron: I think Dirk had issues 07:53:13 dirk: That's ok though 07:54:23 glazou: Suggest the 11th, 12, 13th of February 07:56:09 It would be beneficial if the SVG WG could move their's we would prefer the 9th, 10th and 11th 07:57:26 We will wait for SVG WG answer before resolution 07:57:36 plh: I am new to this new process 07:57:52 plh: We need to get rid of some of the pain between LC and CR 07:58:33 gregwhitworth has joined #css 07:58:46 plh: The new process does, it get's rid of LC 07:59:11 plh: you still have to do review, but in the state of WD - but when you're ready you move to LC and subsequently CR 07:59:35 plh: You're supposed to get a review of it, and then issue the change 08:00:47 plh: The expectation is if you want to republish a CR you need to get approval and it should occur quickly 08:01:11 plh: We did this recently for two of the CSS documents, there are some areas that we can streamline but that is the major change 08:01:31 plh: And the dance that you're doing between the LC and CR with the directors 08:02:37 szillis: If you do a change in CR it does trigger the patent policy, and only on the delta 08:02:56 s/szillis/SteveZ/ 08:03:25 plh: When should we switch to the new process, it is really up to the group? 08:03:33 plh: Also in CR, you can move to the new process 08:03:45 plh: Documents in LC you can not move to the new process 08:04:04 fantasai: Do we need to republish? 08:04:06 https://www.w3.org/wiki/ProcessTransition2014#Impact_on_Working_Groups 08:04:29 https://www.w3.org/wiki/ProcessTransition2014#What_is_the_transition_procedure_for_groups.3F 08:05:14 gregwhitworth_ has joined #css 08:05:33 plh: That is a good point, you don't want to trigger the patent policy between LC to CR 08:05:55 dbaron: We should move all of our documents to the new process as soon as possible 08:06:09 dbaron: I presume we can resolve right now to do this on all specs 08:06:17 chrisl: I propose we do that 08:06:36 florian: Will we need to republish for them to be on the new process 08:07:00 fantasia: Update the boilerplate 08:07:06 proposed resolution: We should convert all specs to the new process at the next publication at which such a conversion is allowed. 08:07:07 even WD has to say in SOTD whether its oldstyle or newstyle 08:07:53 Tab: Sure, it's a boilerplate I'll update it 08:08:12 zakim, list attendees 08:08:12 sorry, chrisl, I don't know what conference this is 08:09:09 Presebnt: andreyr, plinss, simonsapin, fantasai, dbaron, hober, rossen, plh, krit, greg, zcorpan, tabatkins, iank, chrisl, yamamoto, glazou, florian, bert, stevez, dhauwe, astearns, glenn 08:09:16 s/Presebnt/Present 08:09:32 all in favor but two "abstains": yamamoto + Bert 08:09:37 no objection 08:09:44 zakim, this is css 08:09:44 sorry, chrisl, I do not see a conference named 'css' in progress or scheduled at this time 08:09:45 RESOLVED: We should convert all specs to the new process at the next publication at which such a conversion is allowed 08:10:50 tommyjtl_ has joined #css 08:11:21 tommyjtl has joined #css 08:12:14 plh: it's not effecting you, it shouldn't be an issue it is just based on a delta. 08:12:30 glazou: Anything else on the new process 08:12:47 plh: We are trying to determine what is "wide review" and we want to define that 08:13:48 plh: We can talk about the pipeline that we've been working on 08:14:00 plh: We're trying to resolve the pain of publishing 08:14:10 s/pipeline/publishing pipeline/ 08:14:11 plh: It's a high cost on WD and the W3C directors 08:14:33 plh: You can update it as often as you want, we want to be able to do that 08:15:17 plh: if publication rules are ok then we'll let it go through based on the link sent in by the editor 08:15:36 plh: if you try to publish more than one on the same day, then we'll grab the latest one 08:15:48 plh: it should be automatic 08:16:10 glazou: Are you getting consensus from the WGs 08:16:14 tommyjtl_ has joined #css 08:16:20 plh: We didn't think it was necessary 08:16:31 plh: We want to leave this to the groups 08:17:15 glazou: If there is a form, do not make it mandatory but also make it so that we can have a URL for consensus 08:17:22 plh: Also, there will be a way to do an undo 08:17:34 plh: It will notify the chairs that a publication occurred 08:17:51 plh: With all that, do you want to have a link 08:18:07 fantasia: It could just be a general comment box for us to look up later 08:18:33 glazou: Is it possible for the form to know each Working Groups public mailing list 08:18:49 tommyjtl_ has joined #css 08:18:59 TabAtkins: The whole point is to push working drafts constantly 08:19:30 TabAtkins: I don't want the public list spammed for every new working draft 08:20:18 TabAtkins: I don't want the setup to post to the public mailing list to be used as an argument to preclude us from doing constant publication. 08:20:28 glazou: I disagree that you should push directly to the WD without consensus 08:21:19 fantasai: I think we do want to publish faster and allow editors to make quicker changes without consensus. That shouldn't have to go to telecon to make editorial changes 08:22:18 glazou: The point of the consensus is that it allows you to review complicated information 08:22:35 SteveZ: The TR page currently points to the WD and ED 08:23:46 plinss: The whole point of this is to get TR up to date so that everyone is using TR 08:24:26 TabAtkins: I agree with peter so I only brought this up that we shouldn't need this going to the mailing list 08:25:21 Ted: I agree that editorial changes should be published easily, but there have been examples that are controversial 08:25:37 Ted: We should treat our editors as adults, we have the Undo button 08:25:49 glazou: Who can push the undo button 08:25:55 plh: The chair can press the undo button 08:26:03 s/chair/chairs and team contacts/ 08:26:08 s/chair/chairs and team contacts/ 08:27:15 SteveZ: There are two audiences for these documents. Implementors and Authors 08:28:46 plh: Some groups will be updating the WD more frequently 08:29:19 fantasia: My ideal mode of operating will be, is that there is a history chain of changes 08:29:44 fantasia: Those snapshots are chained to discussions from the WG 08:29:58 s/fantasia/fantasai/g 08:30:00 fantasai: The TR page is the thing that EVERYONE uses to look at 08:30:36 fantasai: I'd like it so that every change that's not in the process of being edited gets to the TR page as soon as possible. 08:30:54 fantasai: Any edits to keep that up to date, that level of up to dateness be possible with the new process 08:31:27 fantasia: The only things that are not going to TR are the things that we are working out technical details on the mailing list 08:31:41 s/fantasia/fantasai 08:32:41 glazou: I still want consensus on publications of substantiative changes to publish a WD (non-editorial stuff) 08:34:02 plinss: I think this will need to be done on a spec by spec bases; based on the maturity of specs 08:35:07 TabAtkins: My issue is that editors push all the time to EDs that implementors and authors looking at 08:35:23 I don't want to see WD updated every day 08:35:51 plinss: I agree with most of what you say 08:36:49 plinss: If you can publish under TR more quickly you can use the ED as a scratchpad and the TR can be the one people look at 08:37:28 plinss: I think your issue with remembering to send emails to publish we should offer tooling 08:38:32 TabAtkins: I will send about 12 emails per day then 08:39:00 plinss: We just need to have it noted, it can be on a twitter account or email list, it doesn't have to be on www-style 08:39:33 fantasai: It's creating the ability to create a little bit of a break here as I leave things partially done in the ED 08:40:23 plins: That sounds fine, have the back and forth on the ED and then publish to WD 08:40:27 fantasai^: I don't filter on EDs. 08:40:31 s/plins/plinss 08:41:00 SteveZ: You've now added the work to all of us 08:41:26 TabAtkins: No I have not, you can still just review once a year 08:42:28 SteveZ: The people that have dependencies aren't looking at the ED 08:42:34 fantasai: That's not true 08:42:51 fantasia: if it's the thing you should look at, it should be the thing that the W3C should look at 08:43:11 dholbert: What is the end conclusion we're looking for here? 08:43:35 s/dholbert/dbaron/ 08:43:35 dholbert: Were there some changes to what PLH stated? 08:43:56 TabAtkins: No, we're ironing out some of the details on that now based on the auto publish feature 08:44:00 s/dholbert/dbaron/ 08:44:25 plh: There will be a checkbox for checking whether a draft has large changes 08:44:47 tommyjtl has joined #css 08:44:56 plh: The system was designed to trust individuals, and I don't want it to decide what the WG's should do 08:45:12 plh: It is designed to allow groups to publish daily. 08:46:06 astearns: I have a strong desire to trust the editors will publish WD appropriately and not add WG process until we actually have an issue 08:46:51 plh: If there are issues down the road there are steps that we can take, but we don't want to solve a problem that hasn't occurred yet 08:48:24 glazou: section 7.3.2 of new process says "a Working Group must record the group's decision to request publication" 08:48:44 SteveZ: This is a change, this making WD without consensus 08:49:18 TabAtkins: If you think this a change you're not following along today, we have everyone look at the ED. 08:50:22 fantasai: I think it is very important that people that go to the WD and it be the latest 08:50:48 fantasia: I want all consensus and approval done through the same system 08:51:06 s/SteveZ: This/glenn: This/ 08:51:31 SteveZ: The status section should be updated in all WD 08:51:57 florian: Are you suggested as having WDs and having a WD that states it has consensus. 08:52:20 fantasai: Yes, we can even have the color change, etc 08:52:26 q+ 08:53:01 plinss: We can even have links (Latest Working Draft, Latest Consensus Draft) 08:53:04 q+ 08:53:26 plh: Two points I'd like to make 08:53:43 plh: It does not make the decision for the group 08:54:22 plh: We still have a nightly draft link, but we are not going to copy the editors draft into the TR space 08:54:32 plinss: We should still retain the editors draft 08:54:38 plh: It will not go away 08:54:41 q- 08:54:46 q- 08:54:47 Zakim, ack plh 08:54:47 I see no one on the speaker queue 08:55:01 plinss: that then makes the ED become a scratch space 08:55:04 q+ 08:55:37 fantasai: I've had implementors reference my editors drafts when I'm trying to figure something out. 08:56:11 .... 08:56:14 glenn: My issue is that you're trying to relabel this as a Working Draft but it is an editors draft. It should be a group process output 08:57:01 glenn: I have a real problem with that. If you call it a Non-Consensus Working Draft then I'm fine with it 08:57:21 ack glenn 08:57:33 SteveZ: There is a presumption of working draft 08:57:59 q+ 08:57:59 TabAtkins: You're arguing the definition of working draft 08:58:25 SteveZ: Come up with the name that means Editor's Working Draft 08:59:03 SimonSapin: We are actually arguing about the URL more than the name since Tab doesn't care 08:59:09 s/SimonSapin/zcorpan/ 08:59:28 zcorpan: so why don't we leave the names as-is and just fix the URL so the editor's draft on TR? 08:59:57 plinss: We have our own tooling with bikeshed, we can make an ED published and then with consensus this can be updated. We can add additional tooling to make this easy and make the output result very clear to what we're doing 09:00:57 fantasai: Part of the update, was to allow the groups to practice and experiment with our own process 09:01:10 plinss: When will this tooling be available 09:01:18 plh: Between TPAC and 2015 09:01:35 plh: We will be testing between TPAC and 2015 09:02:18 ack zcorpan 09:02:59 Ms2ger has joined #css 09:26:45 Bert_projector has joined #css 09:32:31 andreyr has joined #css 09:40:02 Topic: Flexbox 09:40:08 http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325 09:40:24 ScribeNick: SimonSapin 09:40:50 TabAtkins: last call issues list 09:40:56 florian has joined #css 09:40:57 TabAtkins: check the open issues box so we can go through just the 5 open ones 09:41:05 fantasai: skip 12, talked with Rossen 09:41:09 (12, 20, 21, 27, 39) 09:41:09 TabAtkins: consider it closed 09:41:22 TabAtkins: issue 20. New keyword other than auto for flex bases 09:41:40 TabAtkins: "main size" would work, but did poll of authors, 20 responses 09:42:16 TabAtkins: 21 in favor of "main size", [...] 09:42:18 axis-size 09:42:18 flex-main-size 09:42:18 initial-size 09:42:18 main-size 09:42:21 use-size 09:42:43 TabAtkins: first 3 one vote each, use-size 4 09:42:54 TabAtkins: firefox nightly already has the new value 09:43:14 TabAtkins: seems fine for now, wrt compat issues 09:43:31 fantasai: confirming on the name, and whether we need to back out and do something different 09:43:49 fantasai: next publ is LC anyway, can mark as issue "waiting for back compat data" 09:44:02 TabAtkins: resolve to take this value, pending further issue reports 09:44:11 Rossen_: so, no 'auto' at all? 09:44:32 TabAtkins: can use auto, means same as usual 09:44:52 fantasai: now 'auto' just passes through from width/height, no way to flex 09:45:17 fantasai: either rename 'auto', or come up with a different keyword for automatic behavior 09:45:42 fantasai: that is, you looked at width/height and got auto 09:45:59 fantasai: so calling it 'auto' makes sense, but could rename if compat issue 09:46:32 gregwhitworth_: why not leave auto and add a new one 09:47:18 TabAtkins: it’s weird to have 'auto' have a different meaning as in width/height, while other values are the same 09:48:06 fantasai: [draws an example] 'flex-basis: auto' looks at the width prop 09:48:20 fantasai: need value A look at width, and value B automagic 09:48:36 fantasai: A, if width is auto, automagic 09:49:06 Rossen_: current behavior seems good 09:49:26 fantasai: disadvantages is that some existing content relies on the earlier meaning 09:50:16 TabAtkins: main-size does what auto used to, auto does what it does in width 09:50:44 TabAtkins: previously you could not specify auto in flex-basis without setting width as well 09:50:53 TabAtkins: new keyword does not collide with width values 09:51:30 fantasai: options are: auto keyword continues to look at width and do that, no compat issue, and we need a new keyword for magic 09:51:53 fantasai: other option that we’re trying: magic is called auto, and "look at my size property" called main-size 09:52:16 TabAtkins: that’s what firefox implemented. Minor compat issues 09:52:35 dbaron: the one existing was pretty major, on google search, but you fixed it 09:53:07 TabAtkins: issue not likely, we tell in the spec to use some patterns 09:53:18 TabAtkins: tutorials use the flex shorthand, which is fine 09:53:23 dbaron: this stuff is pretty new 09:53:40 TabAtkins: the google search issue was because of a tool 09:54:02 fantasai: other issue: shorthand 'flex: auto' means main-size, not auto 09:55:14 fantasai: for the main-size solution we have flex-basis: auto and width: auto match, but small back-compat issue. Not huge, but don’t know how trivial. Also flex: auto means flex: main-size, which is inconsistent. To preserve compat, but kinda awkward 09:55:54 fantasai: disadvantage of the magic solution is that flex-basis: auto does not match width: auto, but no back-compat issue and flex shorthand is consistent 09:56:13 fantasai: I’m leaving toward doing the keyword for magic instead 09:56:25 TabAtkins: no, let’s not change what we have unless forced by compat 09:56:36 TabAtkins: things are dumb no matter what 09:57:10 fantasai: comments? 09:57:20 dbaron: don’t wanna keep changing stuff 09:57:34 fantasai: was surprised that moz impl so quickly 09:57:43 dbaron: you should have said it was not ready 09:58:12 SteveZ: the point is that the meaning of a size keeps the same meaning 09:58:21 SteveZ: why not call it "use something"? 09:58:31 TabAtkins: because poll says people don’t like it 09:58:49 TabAtkins: "main" is a term of art in flexbox 09:58:56 SteveZ: not objecting 09:59:05 TabAtkins: name isn’t great, could do better 09:59:45 TabAtkins: does anyone object? There’s a small possibility of finding compat issue 09:59:50 fantasai: concerned about this 10:00:18 fantasai: auto often means do a special case 10:00:30 TabAtkins: but that complicates the grammar 10:01:30 dbaron: grammar is more than syntaxic, also defines meaning 10:01:56 fantasai: I’d prefer the grammar was just the grammar 10:02:29 TabAtkins: don’t want to say <'width'> in grammar if auto has a different meaning 10:02:55 gregwhitworth_: I’d rather stick with what we have 10:03:08 Rossen_: is that in nightly? 10:03:12 dbaron: in aurora now 10:03:34 Rossen_: want to see compat on mobile. Do you get numbers on desktop mostly? 10:03:43 dbaron: we do get bug reports from users 10:04:11 Rossen_: mobile usage of flexbox is way higher. If not capturing mobile, we’re understating compat issue 10:04:23 fantasai: put this in the spec, mark an issue 10:04:41 TabAtkins: this is what I would do from scratch 10:04:53 flex: auto; expands to flex-basis: main-size; 10:04:58 TabAtkins: 'flex: auto' meaning something strange is the only thing I’d do differently 10:05:55 Bert: no objection, but you mentioned current-size as one option? 10:05:59 TabAtkins: no 10:05:59 koji has joined #css 10:06:12 Bert: we have currentcolor, so current* would make sense 10:06:21 fantasai: I wish we had this idea 3 months ago 10:06:45 dbaron: is it really the current size, in the middle of the process, not the one you end up with? Feels weird 10:07:09 TabAtkins: sounds like no objections 10:07:41 fantasai: as long as we mark issue, waiting for compat feedback. Would love to hear from Microsoft on that. We already know what to do if it’s an issue 10:08:46 RESOLVED: Accept proposed solution for issue 20, with issue for waiting on compat feedback explaining alternate solution 10:09:02 http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-21 10:09:27 fantasai: issue 21, waiting for review from Rossen or anybody else. About cross-side of stretch items being definite 10:09:36 http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325#issue-27 10:09:45 Rossen_: yes, this is fine. Accept proposal 10:09:59 RESOLVED: accept proposed resolution for issue 21 10:10:08 TabAtkins: Issue 27: implications of adding min-content max-content to min/max-width/height properties 10:10:33 TabAtkins: previously, min/max were always definite 10:11:01 TabAtkins: resolved to 0 or something. now, you can say min-width:min-content, which is not definite. Can’t use for clamping 10:11:52