07:15:29 RRSAgent has joined #css 07:15:29 logging to http://www.w3.org/2015/08/25-css-irc 07:16:29 zakim, this will be style 07:16:29 I do not see a conference matching that name scheduled within the next hour, plinss 07:16:30 rrsagent, make logs public 07:17:36 andrey-bloomberg has joined #css 07:17:47 hyojin has joined #css 07:19:37 nvdbleek has joined #css 07:22:53 scribeNick: dael 07:23:02 dbaron has joined #css 07:23:25 jh_hong has joined #css 07:23:33 skk has joined #css 07:24:07 haletuse has joined #css 07:24:13 skk has joined #css 07:24:36 MaRakow has joined #CSS 07:24:49 plinss: First topic, agenda. 07:24:57 plinss: Req to do FX topics first 07:25:04 hober: Dino will be here on Thursday. 07:25:09 plinss: FX on Thursday? 07:25:27 heycam: We'll still be here Thursday...we can just pop downstairs 07:25:34 plinss: FX thursday morning? 07:25:41 [general yes] 07:25:54 plinss: So we'll do FX Thursday 07:26:07 tkonno has joined #css 07:26:11 plinss: anyone with time constraints? 07:26:17 fantasai: Writing modes not today 07:26:30 michaelmiller: inline not today. 07:26:44 hober: Simon wanted to do will-change so he's here Thursday. 07:27:16 s/michaelmiller/Steve Zilles/ 07:27:29 hyojin: Display tomorrow? 07:27:42 s/Display/Round display/ 07:27:45 johannes: page floats on Thursday if possible 07:27:50 SteveZ has joined #css 07:27:54 esprehn has joined #css 07:28:04 shans: Can I propose a topic? We'd like to talk about animations 2 07:28:07 plinss: Time constraints? 07:28:15 shans: I don't think so. 07:28:24 hober: Is that Thursday? 07:28:26 johanneswilm has joined #css 07:28:33 plinss: We're shoving a lot off to Thursday. 07:28:59 s/michaelmiller/SteveZ/ 07:29:58 present+ tantek 07:30:00 Present+ Tab Atkins, Google 07:30:01 Simon Pieters, Opera Software 07:30:03 weinig has joined #css 07:30:04 Present+ Elika J Etemad, Invited Expert 07:30:04 gregwhitworth has joined #css 07:30:04 present+ Dave Cramer, Hachette 07:30:09 present+ Peter Linss, HP 07:30:09 present+ Simon Pieters, Opera Software 07:30:10 Present+ Florian, Invited Expert 07:30:14 present+ Matt Rakow, Microsoft 07:30:15 Hiroshi Sakakibara, from BPS co.LTD, and Keio University. 07:30:16 present+ Dael Jackson, Invited Expert 07:30:17 present+ Greg Whitworth, Microsoft 07:30:18 present+ Edward O'Connor, Apple 07:30:19 Present+ Shane Stephens, Google 07:30:20 present+ Alan Stearns, Adobe 07:30:20 < Andrey Rybka 07:30:30 present+ Tantek Çelik, Mozilla 07:30:39 present+ Sam Weinig, Apple 07:31:03 present+ Brian Birtles, Mozilla Japan 07:31:10 present+ Bert Bos, W3C 07:32:04 plinss: UI today? 07:32:07 Florian: That's fine. 07:32:11 present+ Simon Sapin, Mozilla 07:32:16 plinss: Morning/afternoon? Let's do afternoon. 07:32:23 plinss: Anything else time constrained? 07:33:11 plinss: Let's just do times. There's the github conversation. 07:33:20 fantasai: I think we should save that. 07:33:36 s/that/that for when we're technically worn out/ 07:33:42 ed_work_ has joined #css 07:33:58 plinss: snapshot, prefix policy? 07:34:09 plinss: We're pushing a lot to Thursday. 07:34:19 tkonno_ has joined #css 07:34:27 plinss: Let's not do that on Thursday. 07:34:39 fantasai: We could do it after lunch. Not in the morning. 07:34:44 plinss: This afternoon? 07:34:47 fantasai: We could. 07:34:50 plinss: Grid issues? 07:34:59 fantasai: Tomorrow? I'd rather Flexbox today. 07:35:06 fantasai: We could even do that this morning. 07:35:17 plinss: User style sheets, clilly isn't here yet. 07:35:21 plinss: CSS IG? 07:35:33 fantasai: That can fill in whenever. It's not super important. 07:35:36 present+ Hyojin Song, LG Electronics 07:35:38 plinss: Cascade to LC. 07:35:42 fantasai: That's 10 minutes. 07:35:46 plinss: Fragmentation 07:36:01 fantasai: We have one issue left, it's naming. You can drop that where it's appropriate. 07:36:07 present+ Jihye Hong, LG Electronics 07:36:17 plinss: % heights and abspos, is that part of Flexbox? 07:36:21 fantasai: Can be any time. 07:36:29 fantasai: Is scroll snapping on the agenda? 07:36:31 kwkbtr has joined #css 07:36:47 fantasai: We should prob. do that today. Is Simon coming? 07:36:50 plinss: Thursday. 07:36:56 fantasai: We should waint until he's here. 07:37:06 hober: WE can prob. do it then. 07:37:12 fantasai: Does he want to call in? 07:37:19 hober: Prob. not. I can ask. 07:37:37 hober: Let's plan for tomorrow and if he says he wants to be there we'll push back. 07:37:43 plinss: Keyframe interactions 07:37:52 TabAtkins: I was waiting on Moz to say yes, that's cool. 07:37:58 plinss: uoby? 07:38:07 s/uoby/Ruby 07:38:35 fantasai: Ruby has a large chunk of issues and I'm not sure they're prep for WG discussion. I think we can put that off until the telecons. 07:38:52 astearns: Except I put them on the agenda because on the telecon we said we should discuss it at the F2F. 07:39:08 fantasai: If I get through all the other things we can do Ruby. 07:39:14 vollick has joined #css 07:39:32 plinss: fill-available sizing? 07:39:37 fantasai: I'm not prep. today 07:39:43 plinss: Tomorrow afternoon? 07:39:46 fantasai: Sure. 07:39:57 plinss: Control character status. 07:40:16 gregwhitworth: Should be short 07:40:26 plinss: Japanese interest group 07:40:28 Florian: Short. 07:40:32 plinss: CSS text 4? 07:40:41 fantasai: Maybe this afternoon or after the break? 07:40:46 plinss: Pagination 07:41:11 dauwhe: This is mixed up with houdini, but I thought there should be a discussion during CSS because some is extremely related. 07:41:18 plinss: CSS apply rule 07:41:21 TabAtkins: Whenever. 07:41:25 plinss: How long? 07:41:29 TabAtkins: 45 min 07:41:39 plinss: Tomorrow morning. 07:41:51 fantasai: I forgot to put selectors on the agenda. We can do that this morning. 07:42:01 Florian: Perhaps some other time? I'd like to review first. 07:42:25 present+ Elliott Sprehn, Google 07:42:28 fantasai: If we need to do topics to pull earlier we can do that. We likely have to go back to it, but there's a bunch of issues we can go through. 07:42:31 plinss: Animations 2? 07:42:44 plinss: It's on the agenda. 07:42:56 shane: I thought we had said Thursday. 07:43:10 hober: I guess it depends what we should talk about. 07:43:31 shane: It would be better if dino is there. 07:43:45 hober: dino threatened to come tomorrow, so he may. 07:43:55 shane: Do we have room Thursday? 07:43:58 plinss: Maybe. 07:44:04 shane: Wednesday afternoon? 07:44:24 SimonSapin: jdaggett's e-mail said he'd prefer the afternoon for call. 07:44:48 plinss: Which topic 07:45:20 css-inline, dpub, writing modes 07:45:25 SimonSapin: writing modes and digipub priorities and css-inline 07:45:40 dholbert has joined #css 07:45:46 fantasai: WE could do the github this afternoon. WE can do digipub and inline this afternoon. 07:45:56 s/github/digipub/ 07:45:59 dauwhe: I think Steve asked for inline tomorrow. 07:47:21 BogdanBrinza has joined #css 07:47:51 plinss: The only thing we haven't picked is user stylesheets and CSS interest group 07:48:03 s/picked/picked a time for 07:48:32 plinss: wiki is edited. 07:48:37 Topic: CSS cascade 07:48:55 plinss: Whose topic? 07:49:20 TabAtkins: Cascade is ready for CR, but we want to first pub as a last WD for review just so that anything can be sussed out before we go to CR. 07:49:32 Florian: So you're doing a WD? 07:49:38 fantasai: Yeah, there's no open issues. 07:49:52 TabAtkins: We'll do a WD and ask for CR is a bit. Just ot make sure there's no final obj. 07:49:56 plinss: Anyone opposed? 07:50:08 RESOLVED: Publish a new WD for CSS Cascade 07:50:16 fantasai: Do we want a deadline for comments? 07:50:20 Florian: 4 weeks? 07:50:22 fantasai: Sure. 07:50:33 astearns: Are you asking anyone becides the WG to look? 07:50:40 TabAtkins: I don't think there's any WG this is of interest. 07:50:44 fantasai: HTML? 07:50:52 Florian: This is pretty internal. 07:50:56 tantek: Do you need 4 weeks? 07:51:21 fantasai: We have almost no comments. It would be useful to collect comments one way or antother since we need wide review to go to CR. 07:51:40 plinss: Anything else on cascade? 07:51:45 Topic: Fragmentation 07:52:00 fantasai: We have one open issue. The naming of the any and always values fro break-before and break-after 07:52:09 fantasai: It's kind of confusing what either of these things mean. 07:52:36 SteveZ: The last time we talked on the phone I don't remember what tantek suggestion was, but I liked it. You had a problem because you fealt it was confusing 07:52:48 fantasai: Nearest. it implies that it's distance wise, not lateral. 07:53:09 SteveZ: I think that issue is deeper than all and any. Nearest would still be better. I understand there's confusion, but it's less. 07:53:16 fantasai: So nearest and farthest? 07:53:32 Florian: I was thinking yesterday. I'm not sure, but break-shallow and break-deep for any and all 07:53:52 TabAtkins: He asked me what I thought it meant and I wasn't paying attention and I got it right, so it seems reasonable. 07:53:54 s/break-shallow/break-before: shallow/ 07:53:59 s/break-deep/break-before: deep/ 07:54:18 fantasai: Other thoughts? 07:54:31 hober: I like the compond names with force. 07:54:37 fantasai: force-page and force-column 07:54:53 fantasai: WE don't use force as a prefix for page or column. WE should have. 07:54:57 dauwhe: It's widely used. 07:55:06 tantek: When did we last talk about this on telecon? 07:55:10 Rossen: A month ago. 07:55:22 tantek: I remember trying to draw sim. to page break prop. 07:55:30 astearns: It was on 29 July 07:56:18 fantasai: Do you know if the always values are widely used? 07:56:27 dauwhe: We tend to use page-break before always a lot. 07:56:40 s/page-break-before/ 07:56:42 fantasai: page break prop won't change, they're being folded in but keeping their own syntax. 07:56:57 s/page-break before/page-break-before/ 07:57:12 2015-07-29 minutes https://lists.w3.org/Archives/Public/www-style/2015Jul/0459.html 07:57:33 fantasai: This is for break-before and break-after. I don't htink they're widely used. they're not in browsers. 07:57:40 fantasai: They'd only be in AH and Prince 07:57:42 MozParis has joined #css 07:57:58 (Not used on the Web) 07:58:00 dauwhe: I'm looking in prince right now. They just have column and page. They don't have pure break-before and break-after 07:58:23 Prince has page-break-before/after: auto | always | avoid | left | right 07:58:34 fantasai: AH I think is just the break-before and break-after....well, we can put this on a board somewhere and people can think. 07:58:44 SteveZ: Basically any solution is better than any and all. 07:58:56 hober: I like shallow and deep. It's confusing, but a bit more obvious. 07:59:08 dauwhe: It aids in understanding if you have a certain level of knowledge. 07:59:15 skk_ has joined #css 07:59:27 hober: Can we change those now since they're an improvement and leave a note saying if you have better ideas prop them? 07:59:37 non-zero usage on the web for page-break-before / page-break-after https://github.com/search?l=css&q=page-break-before+OR+page-break-after&ref=searchresults&type=Code&utf8=✓ 07:59:40 fantasai: So resolve change to shadow and deep unless there's a better idea? 07:59:46 Bert: I can't say I like it. 07:59:50 SteveZ: Relative to the tree. 07:59:53 I think I need to see the previous discussion before that telcon 08:00:05 Bert: But I don't like to think about the tree. A page is more like a seq. then the tree. 08:00:38 fantasai: But this is about nested frag context. if you have multicol in a region in a paged media, shallow is just the colomn, deep is the page. 08:01:00 Bert: How about soon or first available. 08:01:06 fantasai: We could also drop these values. 08:01:23 Rossen: That was a prop resolution. We've been sttuck on this for weeks for a name. 08:01:29 tantek: Who was asking for this level? 08:01:50 fantasai: We had an always because someone copied it into a CR spec and then we got an issue of what does it mean. 08:02:06 Rossen: And to have sym with always we added any. You can have context that's agnostic. 08:02:11 tantek: So we can drop both? 08:02:26 fantasai: Prob. We only have one impl of always. We'd have to re-pub multi-col. 08:02:39 Rossen: The prop was to push any to the next level and keep always for backwards compat. 08:02:59 Florian: But there's no backwards compat. I'm not okay with punting just one because then you're stuck with it. 08:03:21 fantasai: So defer always and any to next level and also resolve to replub multical without the break prop 08:03:35 SteveZ: Doe sanyone else becides bert obj to renaming to deep and shallow. 08:03:44 tantek: I don't like them. 08:03:53 Rossen: I'm not a huge fan. 08:04:28 dauwhe: I think the deep and shallow on the next level will be better with having examples. I think we need drawings. 08:04:31 tantek: Agreed. 08:04:40 s/stuck with it/stuck with the naming of half the pair/ 08:04:45 tantek: So we're dropping break before and break after? 08:04:47 present+ Ian Kilpatrick, Google 08:04:50 astearns: Just those values. 08:04:53 BogdanBrinza has joined #css 08:05:06 tantek: Before re-raising the values someone should produce real world use cases. 08:05:44 fantasai: astearns poitned out there's one issue about we're doing this does it make sense and maybe dauwhe you can take a look at that. 08:05:47 let's make that the burden for "new information" for re-raising those values, you must provide real world use cases with diagrams to justify re-introducing values like any/all/shallow/deep 08:06:07 plinss: So we're removeing those values from frag and removing breaks from multi-col and repub it as CR. 08:06:18 fantasai: Yes, and hopefully publish this as CR soon. 08:06:29 plinss: So removing the entire breaks section? 08:06:30 s/and hopefully/when we/ 08:06:34 s/soon// 08:06:47 Florian: Last time I talked to morgan he wanted to do mantainence of multi-col. 08:06:59 s/morgan/Håkon/ 08:07:07 Rossen: Yes, but we have a resolution from Tuscon to add me as a co-editor 08:07:12 Florian: And we have me as level 2. 08:07:23 Florian: So we can ping him and then we can take over. 08:07:39 Rossen: Before I was able to do the edit, he read the thread and made the edit. 08:07:49 Florian: He made some recently for a resolution we made a while back. 08:08:00 fantasai: If he's active then okay. 08:08:20 RESOLVED: Drop any and always from level 3 fragmentation 08:08:53 RESOLVED: drop break before and after from multi-col and reference frag definitions and republish as CR 08:09:26 action dauwhe to look at the last issue in fragmenetation 08:09:26 Created ACTION-703 - Look at the last issue in fragmenetation [on Dave Cramer - due 2015-09-01]. 08:09:39 http://krijnhoetmer.nl/irc-logs/css/20150825 08:09:53 Rossen: Is issue 13 resolved? 08:09:58 CSSWG_LogBot has joined #css 08:10:06 fantasai: I don't remember, I have to check. 08:10:13 Rossen: I think you replied on ML. 08:10:14 logs are missing from here: http://logs.csswg.org/irc.w3.org/css/ from Sunday onwards 08:10:21 fantasai: Then we just need to update DoC. 08:10:37 fantasai: Once we get dauwhe feedback and update the DoC we'll come back for the resolution to go to CR 08:10:50 Topic: keyframes 08:10:59 fantasai: That's just can dbaron look at this. 08:11:02 dbaron: What is this? 08:11:29 TabAtkins: Remember some time ago when we were talking on IRC and everyone had diff ideas of how keyframes should be parsed in different situations. I wrote it up. 08:11:33 dbaron: I need to read it. 08:11:37 TabAtkins: So revisit tomorrow? 08:11:42 dbaron: I don't know if I'll have time. 08:11:52 TabAtkins: moz is the only one left for a yes/no call. 08:11:57 dbaron: Do you have a URL? 08:12:00 TabAtkins: I'll send. 08:12:23 Topic: control char status update. 08:12:31 http://logs.csswg.org/irc.w3.org/css/2015-02-08/#e520447 08:12:53 gregwhitworth: We all resolved, bascially every UA agreed to impl control characters blocks 0 and 1 as hexboxes if they have them. 08:13:26 gregwhitworth: We've done it for C0. For almost every browser they throw away C1 blocks. We were looking to see if other browsers were doing this. I wanted to get an update. 08:13:36 TabAtkins: We haven't done the work but we're fine with going ahead. 08:13:43 fantasai: We wanted to release this all together. 08:13:51 dbaron: Jonathan Q would know, maybe Jet. 08:13:56 s/Q/Kew/ 08:14:03 TabAtkins, do you guys have someone assigned to it? 08:14:22 gregwhitworth: I'll follow up witht he list on the C1 issue. Maybe put in the spec that if you have a new browser, you should throw out C1. 08:14:33 hober: I don't remember, but dino will be here soon. 08:14:49 gregwhitworth: So TPAC it should be in everyone's code and do the PR to announce it. 08:14:54 rachelandrew has joined #css 08:14:59 Bert: Do you find many console characters in the style sheets? 08:15:31 gregwhitworth: We haven't shipped it out witht he flag so we don't know. There are some sites, I don't know how they're getting it in there. That's why we need to do the PR hit, actually for the customers, not the devs. 08:15:38 s/console/control/ (?) 08:15:45 plinss: So do we need to come back? 08:15:51 gregwhitworth: I'll talk to dino. 08:15:59 Topic: Japanese industry meetup 08:16:52 Florian: We were talking about this yesterday. Since the next F2F is in Japan and there's lots of companies in Japan int. in this group, espeically writing modes, so it seemed to make sense to have a meet-up next to the WG meeting. Maybe on Sunday before TPAC have a room somewhere. 08:17:22 Florian: We can have the members of the WG that are interested meet with Japanese business people. Maybe have it mixed langauge. 08:17:39 ??: I talked to the site manager today and he can set up a room for that. Please let me know. 08:17:40 present+ David Baron, Mozilla 08:17:45 fantasai: Does everyone think this is a good idea. 08:17:47 s/??/hiroshi/ 08:17:57 dauwhe: I like the idea, but I'm concerned a lot of us have made travel plans. 08:18:17 astearns: Would an evening work? Instead of during the day of sunday, meet after the TPAC sessions? 08:18:23 hiroshi: Yes. 08:18:30 SteveZ: Monday night doesn't have an event. 08:18:34 fantasai: Is that enough time? 08:18:46 fantasai: It'll be 4 hours at most. 08:19:01 Florian: I'm not sure having ti during the meeting is as good. 08:19:08 Florian: Personally I'm good with any random time. 08:19:15 fantasai: Who is interested in attending? 08:19:31 interested 08:19:35 +0.5 08:19:36 interested 08:19:37 interested 08:19:37 interested 08:19:38 interested 08:19:39 interested 08:19:39 intreseted 08:19:40 +1 08:19:41 possibly 08:19:41 interested 08:19:45 Rossen Atanassov, Microsoft 08:19:48 interested 08:19:51 I would be interested in attending a Japanese Meet-up 08:19:52 interested 08:19:52 interested 08:19:53 interested 08:20:03 interested 08:20:03 fantasai: Of those interested who has travel plans. 08:20:08 bert and dauwhe 08:20:14 fantasai: Can you make a sunday? 08:20:21 Bert: I arrive sunday early afternoon. 08:20:47 fantasai: So if we did it in the evening and not have dinner, we can do 2 hr. If we include dinner we have 4 hr 08:20:59 Florian: Are we doing TPAC with the gigantic lunch break? 08:21:04 dauwhe: Didn't we ignore that? 08:21:08 astearns: We did. 08:21:24 Florian: We were offered the options to meet from 9-11 and resume at 3 with joint sessions. 08:21:30 hober: We only meet for 2 days. 08:22:14 fantasai: So we can do 2 hours, 4 hours if we get catered, and that can be monday evening. We can do a large chunk of Wednesday. Or we do Sunday and have a schedule conflict with Bert and dauwhe. I suspect 2 hr is too short 08:22:36 Florian: And if we do 4hr we can do the thing were you mingle with food. So 3 hr of meeting and 1 hr of food. 08:22:51 dbaron: How many people would travel to Sapporo for the 2 hr meeting? 08:23:02 hiroshi: 20 or 30 people 08:23:14 fantasai: I think 4 hours is too short with lots of questions 08:23:21 Rossen: How much time would you prefer to have? 08:23:27 hiroshi: I have no idea. 08:23:32 Rossen: Is 2 hours enough? 08:23:45 fantasai: We can do 2 hr, 4 hr, or 6-8hrs 08:24:03 hiroshi: I want to talk with some guys in Japan to answers. 08:24:13 Florian: I think we shouldn't do it Sunday because the conflicts. 08:24:24 fantasai: It'll depand on what they need. 08:24:39 fantasai: So we have several options and we need to know from the community what they want. 08:24:54 hiroshi: I understand the options and I can talked to the community and have answers tomorrow. 08:25:08 hober: Before we move on, dino will be here half the day tomorrow. 08:25:29 plinss: So maybe now is break time? 08:25:37 fantasai: Any other random topics? 08:26:07 TabAtkins: A few years ago we switched to 3 meetings/year plus TPAC. I think the WG is moving abit slower and I was suggesting 2016 switches to 2 meetings plus TPAC. 08:26:17 fantasai: I think we might want to wait until TPAC to make that decision. 08:26:29 TabAtkins: Okay, put it in everyone's head to think about it. 08:26:40 tantek: Is the based on metrics or a feeling? 08:26:50 TabAtkins: We're not doing as much work as we were a month ago. 08:27:07 dbaron: We could schedule for May/June and decide if we're scheduling for Spetember later. 08:27:16 tantek: You could also look at things we can measure. 08:27:28 fantasai: And do we consume all the agenda or are we filling time. 08:27:35 Florian: We've had several with light agenda. 08:27:40 Rossen: NY had overflow. 08:27:50 hober: It seems like we've expanded to a 5 day F2F. 08:27:58 TabAtkins: I think we can expand to fill any space. 08:28:08 fantasai: There have been meetings were we've been scrounging for topics. 08:28:11 s/5 day F2F/5 day F2F including Houdini/ 08:28:22 dauwhe: It could also be an issue of do we need three days. 08:28:35 fantasai: I think we should wait until later to figure out. 08:28:50 SteveZ: May be a good exercise for Thursday afternoon to help ID things that need work. 08:28:54 s/a month ago/a year or two ago/ 08:29:10 08:29:18 s/that decision/that decision because I've been increasing my hours recently/ 08:30:14 s/with light agenda/with light agenda, but not this one/ 08:30:25 s/5 day F2F/5 day F2F with Houdini/ 08:30:35 s/There have been/No, there have been/ 08:30:57 s/need three days/need three days, could do 3 meetings 3 days or 4 meetings 2 days/ 08:35:37 liam has joined #css 08:41:25 antonp1 has joined #css 08:52:42 weinig has joined #css 08:54:44 johanneswilm has joined #css 08:55:42 Ms2ger: Those tests should be updated, yes. 08:55:56 Ms2ger: We can't always predict when invalid stuff will become valid in future CSS specs. :) 08:56:24 Ms2ger: So it's good the tests were written, to make sure implementations didn't use e.g. quirks mode color processing in CSS. 08:56:49 Ms2ger: But now that we have a valid interpretation of 4/8 digit hex colors, we should update the CSs2.1 tests to pass when those are correctly implemented 08:56:55 r? https://github.com/w3c/csswg-test/pull/814 08:57:07 rachelandrew has joined #css 08:58:04 fantasai, and I believe https://github.com/w3c/csswg-test/issues/830 is about a test you wrote :) 08:58:04 plinss: Let's get started 08:58:07 kwkbtr has left #css 08:58:20 Topic: Flexbox 08:58:24 kwkbtr has joined #css 08:58:38 Ms2ger: You should have double match references for that test, so it passes if either one matches. 08:59:05 fantasai: Let me pull up the DoC 08:59:25 Ms2ger: Since a 2.1 client should parse those as invalid, and L4 UA should parse and interpret the color as 4/8 color hex 08:59:26 https://drafts.csswg.org/css-flexbox/issues-lc-20140925 08:59:36 Mm 08:59:48 fantasai: Okay. It's a long issues list since I updated it. 09:00:46 https://drafts.csswg.org/css-flexbox/issues-lc-20150514 09:01:08 fantasai: We've got a couple of open issues. 09:01:33 fantasai: First one is if min and max content size of flex containters should consider the flex basis or just work off the max content. 09:02:12 fantasai: I think dholbert was leaning to what the spec currently says. If I have a flex item whose flex basis is 50px and the max content is 10px, when I shrink should it be 50 or 10. 09:02:15 TabAtkins: 50. 09:02:28 fantasai: It's flex basis so it can shrink or grow. 09:03:09 fantasai: So if I have a flex cont. with one item and that item has "hi" and I give flex basis of 10em and I shrinkwrap should it be 2em or 10em? 09:03:15 dbaron: What do existing impl do. 09:03:24 dbaron: We've been shipping this for a while. 09:03:31 gregwhitworth: I think this one we're all over the map. 09:03:44 gregwhitworth: Flex is just shrink/grow? 09:03:47 fantasai: Yeah. 09:04:25 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20*%20{%20border%3A%20solid%3B%20}%0A%3C%2Fstyle%3E%0A%3Cdiv%20style%3D%22display%3A%20flex%3B%20float%3A%20left%3B%22%3E%0A%3Cp%20style%3D%22flex%3A%201%201%2050px%22%3Eem%3C%2Fp%3E%3C%2Fdiv%3E 09:04:26 dbaron: With flexbox it seems like the issues should have test cases and results when they come up for discussion. A year ago when we made an imcompat change, we had a lot of problems and we're not going to do that again. 09:04:30 Rossen: You're not alone. 09:04:41 fantasai: This test case uses max content size. That's fine with me. 09:05:45 fantasai: There's an issue on % inside flex items with min size auto which we've discussed. There were 3 options. 1 was tech impossible. 2nd was make % not resolvable 3rd is 2 pass layout. It looks like impl are converging on 2 pass and we don't have a preference. We'd like impl to get together and decide. 09:06:07 fantasai: Does anyone else have anything. I plan to get gregwhitworth and dholbert and Christian on a call and have them figure it out. 09:06:23 dbaron: I'm a bit concerned about perf characteristics of flexbox right now, but that's all. 09:06:35 fantasai: I have no opinion. It's perf vs author expecations. 09:06:57 action fantasai to get people on a call to make a decision about % inside flex items with min size auto 09:06:57 Created ACTION-704 - Get people on a call to make a decision about % inside flex items with min size auto [on Elika Etemad - due 2015-09-01]. 09:07:39 fantasai: Last one, if you have a flex container and you put two table cells in it, they won't become flex items independantly. They'll wrap in an anon table and that will be flex. Chrome has impl so that each item is flex. 09:07:46 dbaron: They do anon box after? 09:07:49 fantasai: Not at all. 09:07:59 dbaron: So it turns the table cells into blocks. 09:08:48 fantasai: I've seen at least one presentation at a conf where they took advantage of this to create fallback behavior for a flex 09:08:54 dbaron: But that only works in chrome 09:08:56 fantasai: Yes. 09:09:05 Rossen: Sounds like a terrible hack. 09:09:51 fantasai: That indicates to me that there are people taking advantage of this and could be a useful behavior. Do we want to change the spec to use chrome's behavior? 09:10:10 Rossen: They are doing fixup, but they're creating 2 anon tables instead of one according to your code. 09:10:30 smfr: You could get table layout with non level layout. 09:10:39 fantasai: That won't work because flex isn't a value for display. 09:10:46 s/smfr/zcorpan/ 09:11:05 plinss has changed the topic to: F2F Agenda - https://wiki.csswg.org/planning/paris-2015#agenda 09:11:24 [discussion that resolves in chrome not doing fixup] 09:11:40 ??: The conversion we do for position absolute, we're doing it for flex 09:11:49 dbaron: Some of this is a function of what hte order of the fixup steps are. 09:12:05 TabAtkins: The spec has been explicit for a long time about when you do fixup. It's not the chorme behavior. 09:12:10 s/??/ojan/ 09:12:19 s/hte/the/ 09:12:50 ojan: We didn't violate the spec when we impl that, the spec changed. We're open to fixing it. I think this is better and simplier, it's better for when we do custom layout. 09:13:21 fantasai: I don't think there's a strong arguement one way or the other. Webcompat would swing it. I had brought this up about people may want to do this backwards compat thing. 09:13:39 dbaron: So it sounds like we shoulds witch to coercing the block. 09:14:31 fantasai: I don't know how much it's an issues, but it would be safer to switch to webkit behavior. I can't think of a good use case of putting a table in a flex unless you're trying to do this fallback. If you're not trying to trigger fallback, I don't know why you'd put a bunch of table cells in flex and get it wrapped in anon stuff. 09:14:39 ojan: It sounds like no one is opposed to changing. 09:14:47 Rossen: So we'll want to do the same thing for grid. 09:15:17 fantasai: So proposal is: Don't wran an anon table around consecutive flex of a flex container. 09:15:25 TabAtkins: In the paragraph that spec the other behavior. 09:15:28 s/wran/wrap/ 09:15:34 fantasai: We'll have to dig into what about having a table row. 09:15:57 ojan: I'll share with you the code Chrome uses. Somewhere the cooercing behavior needs to be expalined. 09:16:10 https://drafts.csswg.org/css2/visuren.html#dis-pos-flo 09:16:11 slide 39 in this deck is an example of display:table as a fallback http://www.slideshare.net/zomigi/enhancing-responsiveness-with-flexbox-css-day 09:16:13 TabAtkins: If you have two siblings and one is pos abs it should be a part of the table. 09:16:25 dbaron: I think a bunch of the coercing behavior is in that link 09:16:30 s/should/shouldn't/ 09:16:33 Here's what chrome does: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp&q=equivalentBlockDis&sq=package:chromium&l=58 09:16:34 fantasai: There's an eq section in display spec 09:16:38 https://drafts.csswg.org/css-display/#transformations 09:16:54 plinss: So everyone is okay with making the change. 09:16:56 And I believe that's what WebKit does as well. 09:17:26 RESOLVED: Just blockify the children of flex and grid containers. Don't do anon box fixup 09:17:57 fantasai: I think the resolution to the first item was no for issue 2 09:18:00 https://drafts.csswg.org/css-flexbox/issues-lc-20150514#issue-2 09:18:40 Zakim has left #css 09:19:06 RESOLVED: no for issue 2 because it most closly matches existing behavior 09:19:19 s/closly/closely 09:19:44 fantasai: There's a couple things where we need to edit. Last issue is the % margin stuff. 09:19:50 TabAtkins: It's a good idea to do now. 09:19:54 TabAtkins: Soooo.... 09:21:28 TabAtkins: At several previous meetings we've talked about how vert % margins and paddings are defined. LAst meeting I tried to convince people where making it behave against height. One of the strongre arguements that's comeout if the behavior of an abspos element. If it currently uses the legacy behavior, if you have an abspops block where the containing block is grid or flexbox, what do you do? If you have legacy you have a off thing where fixed uses height. 09:22:00 TabAtkins: Currently the only thing a block cares about is it's size. The only thing it cares about is that's it's a block and the thigns that make it a containing block. 09:22:24 fabioth has joined #css 09:22:48 TabAtkins: Other than writing mode, abspos are ambiv about the containing block. Either abspos are inconsitant, or their behavior changes based on what ancestor has position relative. Also, no one cares about this so we can keep it simple witht he old legacy behavior. 09:23:04 ojan: It's more that moz has a number of bugs where web authors ask for legacy. 09:23:12 TabAtkins: We have no bugs for the new behavior. 09:23:52 tantek: This is really going to hurt the kind of people that aren't filing bugs, it's going to hurt new people. 09:24:02 TabAtkins: Aspect ratio hack is in tutorials. 09:24:07 tantek: They're not beginners. 09:24:34 gregwhitworth: I think that people do use % margins. 09:24:42 ojan: I've asked for the list of sites and I don't have it. 09:24:46 gregwhitworth: I'll get it to you. 09:24:56 shane: Is it inside flexbox or outside flexbox? 09:24:59 gregwhitworth: I don't know. 09:25:20 Rossen: I wanted to go back to your opening about how abspos is supposed to work in oblivious way of what the layout type of the containing block. 09:26:06 Rossen: That is almost true, it's a bit of a simplistic view. I would disagree with your statement because, by adding flexbox and grid and all their properties, you are taking dependancy on that layout type. I agree in the ideal case abspos should be simple canvas layout. It's the simpliest layout. 09:27:07 Rossen: If that's the only lang I have to express my layout, then there is a layout type which the only thing it cares about is the 2d containing block. Witht he addition of flex and grid, these items are speaking a different lang. Such as BTW when you're setting up this rectangle, I what to take up this number of columns. You're starting to take some dependency and context. 09:27:12 I tend to agree with Rossen's analysis 09:27:52 Rossen: At the end of the day you're saying you're still predending to be only in the 2d space. YOu either have abspos which was nothing to do with grid and flex, but we're not there. We've made abspos items able to speak in terms of grid and flex and we are extending this simple layout to be more. 09:28:38 TabAtkins: There's nothing in flex that makes abspos care. We have static defined, but that's not difference. Grid 2, abspos don't care unless they opt in with grid behavior. Nothing else with abspos changes when you make a grid cont the cont block. You don't have a prop that changes to a different type of behavior. 09:28:47 TabAtkins: So grid sin't a great example, flexbox isn't great. 09:28:55 Rossen: It is because you are allowing prop of grid. 09:29:39 TabAtkins: We are allowing grid prop, we're not chaning the behavior of any other properties. If you explicitly want an abspos to live in a grid, you can. But we don't make width act differently because it's ain a grid. The rest of abspos works the same. 09:30:04 TabAtkins: Whatever is used as the positioning block is arbitary. That can change with simple page layout. YOu attach it to whatever positions as you need. 09:30:10 Rossen: How does aligning work? 09:30:22 TabAtkins: It just cares about wha thte continaing block is and aligns insude. 09:30:39 Rossen: I don't believe this is what we talked about for flex items abspos whose containing isn't flex. 09:30:51 TabAtkins: Every display mode defines static position. 09:31:02 ojan: For the static position it's controlled by parent. 09:31:14 TabAtkins: Yes. 09:31:43 TabAtkins: Mainining the prop is nice because it means that the layout doens't change because if you change from abspos to fixedpos nothing changes. But here it would. 09:32:09 There's no need to change abspos behavior here. 09:32:20 Florian: If you're thinking in terms of encapsulation, you are trying to applyt he same style to them that's different if you're in grid. That's not great. If you're in two types they're different and that's not good. 09:32:51 TabAtkins: We vary particulrly made it so taht if you're doing a flexbox it's similar to a block. They will change layout if you switch to abspos in a minor but random way. 09:33:01 fantasai: I thinkt he behavior is more logical if we had started that way. 09:33:15 TabAtkins: I don't nec agree. Having the ability to do consistant padding is nice too. 09:33:20 fantasai: This is true. 09:33:51 iank: I've been running a small script 2% is using % margin padding and they're all aspect ratios for iframes. 09:35:00 gregwhitworth: I had something two weeks ago. I know there are sites out there. i'm not going to claim the % margin hack isn't the most common use, but it's not the only use. I think we've all made out points on this. I stand by it's the more logical case and they reason we switched is it's more modern layout. I agree it's confusing, but I guess in all honestly, I hear youre arguement, but I don't htink it's that strong. 09:35:56 fantasai: I think a key point that's different is it also affects abspos elements, weither or not it should. We can conclude on that. We can make abspos consistant across layout modes, but abspos won't be consistent with other tiems in grid. Or we can make them inconsistant to themselves. 09:36:03 dbaron: I would pick option 1 09:36:04 tkonno_ has joined #css 09:36:16 TabAtkins: Where abspos always uses legacy? 09:36:17 dbaron: Yes. 09:36:27 tantek: The other option seems like a strawman. 09:36:36 fantasai: People were seriously proposing that. 09:36:49 TabAtkins: If they're always legacy your grid items having different layout if they're abspos item. 09:37:14 fantasai: If a abspos item is positioned against the grid should it have the same % interp for margins and padding as if it was positioned against any other box. 09:37:22 tantek: Rossen, why did you argue the other way. 09:37:35 Rossen: Consistancy in grid. So if you have two items, you want consistancy. 09:37:57 fantasai: Abspos can position in relation to grid lines. They don't effect the sizing, but they can position as a grid item in certain ways. 09:38:11 tantek: So they're top/left bottom/right aligned. 09:38:18 Rossen: Yes, plus grid properties. 09:39:00 fantasai: So abspos positioned to a grid container can have some abilities of a grid item which is why Rossen argued they should have the same behavior. I think consistancy is good here, but consistancy across abspos is a good thing too. 09:39:08 TabAtkins: We have one self-consistant option. 09:39:47 TabAtkins: So you'll intimated before there might be legacy grid prob with microsoft using MS grid. Can we fix that without infecting standardized CSS 09:39:52 we don't have any one self-consistent layout across all layout methods. e.g. table layout (in particular cells) is already very different 09:40:34 fantasai: One thing you could do is have boxes whose containing block is a grid cont whose display value of MS-grid would have the % behavior you have, but ones with the standard prefix would follow standard rules. They would be sep. values internally. 09:40:41 Rossen: We'd prefer to drop the prefix if we can. 09:40:56 fantasai: But the content out there depends on the prefic as well. 09:41:21 TabAtkins: in so far as people are going to update their content...we're well aware people don't update content. 09:41:29 s/prefic/prefix/ 09:42:01 fantasai: A lot of the content they're depending on isn't web content. Those are less likely to be doing anything becides what's coded in a MS enviroment. 09:42:16 Florian: And it makes no sense to future-proof in that enviroment. 09:42:22 fantasai: Anyone else have something to add. 09:42:45 ojan: I haven't been here for the previous conversations. Has the possibility of adding a new prop to control this been considered? 09:42:53 fantasai: Yeah, and we hate that idea. 09:43:00 Rossen: I had a mock-up 09:43:04 gregwhitworth: I'm against it. 09:43:14 tantek: So add a switch instead of a unit. 09:43:22 TabAtkins: Unit doesn't let us retrofit old content. 09:43:32 Rossen: And if you have the unit you have to deal with it everywhere. 09:43:38 fantasai: Let's not go there. 09:43:51 ro 09:44:20 Rossen: The two options on the table are, usetop and bottom % margin and padding as they're spec for inline grid and flex and don't do for abspos 09:44:31 Rossen: That would be because we want to leave abspos as legacy beahvior 09:44:46 Rossen: 2nd is make all the layout types ot be legacy behavior including grid and flex items. 09:45:05 Rossen: 3rd is where we are, everything is following inside of grid and flex, they resolve against height even for abspos. 09:45:26 Rossen: So it's all new, all legacy, or mixed where inline flex and grid behave new and abspos behaves legacy. 09:46:11 [whiteboarding of options] 09:47:14 kwkbtr has left #css 09:47:33 kwkbtr has joined #css 09:48:37 tantek: There's a strong arguement for Rossen 3rd option. This is the basis of the NY arguement. New authors coming to CSS are then able to use not just flex and grid from the top down and have that consistant treatment, they can also reuse abspos elements in a way thtat is also consistant. That almost gives us an opportunity to continue repairing that maistake form the past. 09:48:52 TabAtkins: You're assuming there's a pop of authors that are fed up with the behavior 09:49:06 tantek: That was the miority. It was new authors. Ever single new author. 09:49:25 astearns: They're confused by how % of top and bottom resolve into width and height. 09:49:39 TabAtkins: There are a lot of parts of CSS that are confusing. 09:49:46 Rossen: Which is what where' trying to repair. 09:49:52 s/and height// 09:50:09 dbaron: ONe point is block layout has two directions that are fundimentally different whereas flex in more neutral. 09:50:13 fantasai: So's abspos. 09:50:17 dbaron: Not as much. 09:50:22 ChrisL has joined #css 09:50:29 dbaron: It does a bunch of stuff that is biased to top left or right. 09:50:37 fantasai: We do lots of stuff that's biased. 09:50:44 fantasai: We have 3 options. 09:51:34 fantasai: 1 is keep it all consistant. 2 is make the block inline calc as width. 3 is [missed] 09:51:46 http://pastebin.com/5MZyq1gc 09:52:16 Florian: I was convinced by tantek last time and TabAtkins is strong. Neither sounds great to me. 09:52:47 tantek: I'm talking about B. The method I'm trying to take is from the new author perspective. I like less the implementor way. We're solving for new authors. 09:53:04 ojan: I think the new authors are doing the aspect ratio hack. They search for how to do it and copy/paste. 09:53:18 tantek: I disagree on gregwhitworth data and every time I teach CSS this confuses people. 09:53:42 ojan: It's not 100% the aspect ratio, but the vast majority is. I'm not saying 100%. There are some sites that don't. 09:54:08 fantasai: Helping new authors, having 2 diff behaviors depending on layout mode isn't helping authors either. It would be great if we could switch everything... 09:54:12 tantek: I disagree. 09:54:25 tantek: New authors don't load the whole world into your head. 09:54:34 TabAtkins: You have to teach a confusing behavior 09:54:46 TabAtkins: Are you trying to claim we can't teach block anymore. 09:54:53 TabAtkins: Flexbox isn't replacing block. 09:55:05 zcorpan: You have to learn that behavior. 09:55:10 TabAtkins: They're not legacy display. 09:55:19 tantek: For % margins they are. 09:55:26 TabAtkins: I don't see why that's a flexbox thing 09:55:33 tantek: They're more useful. 09:55:44 q+ 09:56:21 tantek: This author focus is important. You teach them the subset of stuff that is useful, not the crap before. We don't teach the spacers, we teach them the subset that works and is consistant and they can model. We want to cut stuff out over time if it's confusing, in terms of what we teach. 09:56:45 ojan: I would cut % margin and padding from the model, thought I agree with you we should work toward the future where we should cut the crap. 09:57:03 tantek: It does because you either don't teach it or teach the piece that just works. Or you end up with the proposal to drop 09:57:21 fantasai: I think you end up teaching them how it works on grid and flex and then they try and do it elsewhere. 09:57:31 tantek: And then they realize that's old CSS is broken. 09:57:38 fantasai: It's not broken, it's used. 09:58:12 Zakim has joined #css 09:58:55 dbaron: I guess I feel like we're overdesigning here. All this stuff ends up getting used in ways...we've gotten to the point where the major use case for % margins is a hack. Why are we adding more features that are designed in a WG meeting. Maybe we should try and make progress on houdini instead. I don't think grid is something we, moz, should work on because I don't think flexbox went well. 09:59:21 dbaron: I'd rather put in the resources to houdini and I think that we'll wait until it's stable and do it then for webcompat. 09:59:25 fantasai: You're off topic. 09:59:48 dbaron: I think this comes up because of grid, though. We have features, but they don't use them for the things we've intended. 10:00:28 iank: Is there more strategy beyond this...for ex there's vertical align. There's vert-align where people go to that, but it doesn't do what they think. What things will we change the behavior of so that it makes more sense. 10:00:46 s/iank/esprehn/ 10:00:58 tantek: I think for this there's just a strong reaction to " what, this doesn't make sense" meanwhile vertical align doesn't make sense to anyone. 10:01:22 fantasai: People have expectations of what top-center should do, but we can't fix it since it's been in the langauge so long. 10:02:08 tantek: If you ID other parts of the platform where you can alter in some way or a new prop like box sizing to better match...that's good. If 90% think that it should work a different way, we've screwed up. 10:02:21 ojan: This is the not. problem where you can't center on the web. 10:02:35 tantek: I think vertical align in general is confusing. 10:02:48 esprehn: As we release do we plan to keep doing this? 10:02:53 TabAtkins: My answer is no. 10:03:14 esprehn: Do we switch the box model...what fixups do we change to meet author expectations? 10:03:26 tantek: For a new author it's not a switch. 10:03:34 TabAtkins: People still use block. 10:03:56 q? 10:04:02 SimonSapin: You talk about legacy things that are wrong like blocks as things people don't use anymore? 10:04:14 tantek: I think that's right, I'd tell authors not to use it because it's broken. 10:04:37 We're not adding `div { display: flex; }` to our stylesheets. 10:04:50 s/not to use it/not to use percentage margins and padding/ 10:05:11 TabAtkins, UA stylesheet? 10:05:12 Florian: So, based on your arguement that we shouldn't teach authors the broken pieces...I don't think the situation where grid items are and aren't abspos behave differently, I don't think it makes anyone happy. 10:05:19 SimonSapin: trololol 10:05:53 tantek: My initial reaction to making abspos based on context is kind of odd. Rossen arguement is as soon as you start nesting abspos or putting them in a grid layout you're going to be using things that are gird specific. 10:06:05 TabAtkins: Not nec. You'll often treat it as an ordinary item. 10:06:30 fantasai: You might have a new banner. You want to put it on any top of the box, doesn't matter the type. 10:06:40 fantasai: We have two authors in the room. 10:07:37 ??: I think, I've done a lot of work with grid. When we talk about new authors, they're sitting down and learning bootstrap and working out how to do things in CSS from that framework. People will have a legacy understanding of CSS because those frameworks use it. 10:07:44 s/??/rachelandrew/ 10:08:24 rachelandrew: Being able to use a fragement anywhere is important. You don't want that position to change through any context. You don't want that to be different. It's going to take people a very long time to change how they have been thinking for years. 10:08:45 rachelandrew: People's understanding is very much based around those frameowkrs. 10:08:48 q+ re: frameworks 10:08:55 fantasai: leaverou? 10:08:58 leaverou: I just got here. 10:09:46 fantasai: So we have % top and bottom margins that are measured against the heights. A few new arguements have been brought up. The prop was to have flex and grid interp differently. There was an arguement for consistancy across CSS or the arguement about making flex and grid easy 10:10:30 fantasai: The other thing was what about abspos items. abspos items follow the same layout as blocks. The question is what if youre abspos item containing block is a grid container. Is it like a grid item or as an abspos everywhere else. 10:10:52 BogdanBrinza has joined #css 10:11:22 fantasai: Before we could say there's one consistancy break. Abspos creates a bridge where abspos parented to a block with behave like a blokc. Should they be different then abspos parented to a grid? Is abspos internally consistant or consistant to the containing block. 10:11:25 vollick has joined #css 10:12:11 fantasai: Abspos have special properties when they are parented to a grid container. So some of the positioning will work the same as a grid item, but % margin and padding will behave differently. Somewhere there will have to be a break if we want flex and grid to be consistant. 10:12:36 fantasai: So there could be consistancy across all. Or there's a break in how abspos behave, or inflow and out of flow grid items. 10:12:48 fantasai: That's what's here on this chart. 10:13:44 q? 10:13:48 leaverou: As long as grid acts differently it will be inconcstant no matter what we pick. I do see why there should be an exception there. 10:14:14 tantek: I think everything dbaron said and rachelandrew said were signored. 10:15:12 tantek: The point about frameworks is very important. New authors more and more have been switching toward using frameworks. I'm going to include SaaS as a frameowkr. I thinkw e should ask why is that happening. I would hypothosize that part of why is that CSS has gotten too big and complex. Also too many features that are handled in bizaro ways. 10:15:45 fabioth_ has joined #css 10:15:55 Bert has joined #css 10:16:00 s/SaaS/Sass/ 10:16:05 tantek: Authors look at their options for the bizarre CSS rules or the framework that just has these simple features, they choice is obvious is that they go to the frameworks. Everyone needs to ask is do they care about making something authors can do directly or do you want to make more frameowkrs? 10:16:34 tantek: I think that the second option is for houdini. I think we should make CSS able to do it's own thing. 10:16:54 leaverou: I think I agree with tantek. We need to make the language easy to use. 10:17:04 tantek: I am trying to fix that. 10:17:14 fantasai: You argue for consistancy, but you're arguing against consistancy. 10:17:18 s/leaverou: I think I agree/leaverou: I completely agree/ 10:17:32 tantek: You keep reframing this as something different from what I'm proposed. 10:17:37 hyojin has joined #css 10:17:41 andrey-bloomberg: tantek which option would a framewokr use? 10:18:07 tantek: We don't have a framework author here. They have to build on top of whatever randomness we build and figure out what is the common use case. 10:18:27 dbaron has joined #css 10:19:06 fantasai: Let's consider that someone is a framework author and they're building a grid layout framework. They're basing it off flexbox, but they have a lot of fallback behaviors. Let's say we release the grid spec and they author says they can use grid where it's supported, flexbox where it's not, and float layout as the last choice. 10:19:22 s/andrey-bloomberg/zcorpan/ 10:19:32 fantasai: If they author puts a % margin on their items, it will be one way on flex and grid, but differenly on floats. 10:19:44 tantek: I think your ex has too many assumtions. 10:20:01 ed has joined #css 10:20:18 SteveZ: A framework is to hide the complexity. I don't think from a framework author pov we can answer this. They'll figure out how to calculate it for %. 10:20:27 ojan: Except they can't because the author will do that. 10:20:46 tantek: The author will do it, it'll break, and they'll look in the framework community for an answer. 10:20:57 fantasai: How would you like this strawpoll framed? 10:21:04 tantek: They're in the minutes. 10:21:29 tantek: Rossen proposed how every person was advocating it. 10:22:25 Rossen: Option 1: Keep everything consistant in terms of % resolution- that was aligned with your option a 10:23:08 Rossen: Option 2: Mixed where abspos items are an exception inside grid and flex in terms of % margin 10:23:39 Rossen: Option 3: Everything we did in grid and flex, inc abspos is following the new model 10:23:40 Option 1: Keep vertical % margins/padding always dependent on horizontal metrics 10:23:54 Rossen: From the PoV of the layout type, not abspose. 10:24:00 "consistent" is an oversimplification in option 1 10:24:21 fantasai: tantek are you happy? 10:24:39 tantek: I think it's better to make clear that option 1 vertical % margins/padding always dependent on horizontal metrics 10:24:51 tantek: I think that's important to call out. 10:26:41 option 1: keep old mistakes everywhere, option 2: keep old mistakes in some places, option 3: fix old mistakes everywhere we can 10:27:42 ChrisLilley has joined #css 10:28:24 leaverou: it's about do we want to try to keep making CSS more usable over time, or do we want to forever shackle ourselves with bad decisions of the past? 10:28:40 Rossen: One more point for impl.: as soon as you start adding logical properties you will find yourself wishing you had choosen the symmetry. 10:28:53 Rossen: Espeically for vertical mode in horizontal. 10:28:57 tantek: but it's not about making CSS more usable, it's making it more internally inconsistent 10:29:01 https://usercontent.irccloud-cdn.com/file/xkTN5ySI/IMG_20150825_122812.jpg 10:29:06 fantasai: To be clear this chart is the logical width and height. 10:29:07 tantek: given that we are not going to change the past behavior 10:29:11 exceptions are hard to teach 10:29:14 The idea that making the language inconsistent in tiny ways in successive waves, is "making the language more usable", is incorrect. 10:29:17 leaverou: I disagree, it's about making the set of modern CSS more usable 10:29:22 TabAtkins++ 10:29:31 Florian: So what strawpoll do we take? 10:29:32 which is a subset of making the platform as a whole more usable over time 10:29:34 We should only be inconsistent with legacy when the new behavior is actually strongly good. 10:29:40 fantasai: We do 1 2 or 3. 10:29:42 Like switching to using Promises over callbacks. 10:29:52 which requires us to drop / obsolete / or even ignore bad things in the past - just don't teach them to authors 10:30:24 https://usercontent.irccloud-cdn.com/file/1kuGPaOM/IMG_20150825_122940.jpg 10:30:26 Bert: I prefer #1 10:30:29 Except that authors need to be able to edit existing code 10:30:29 esprehn: #1 10:30:31 Rossen: 3 10:30:38 tantek: 3 10:30:41 astearns: 3 10:30:45 fantasai: 1 10:30:49 tantek: it's not universally a bad thing. Having it depend on horizontal metrics is useful sometimes for e.g. equal spacing between items (horizontally and vertically) 10:30:54 jet: 1 10:30:58 andrey-bloomberg: abs 10:31:01 SimonSapin: abs 10:31:05 TabAtkins: 1 10:31:06 Florian: 1 10:31:07 tantek: it's confusing in many cases, sure, but exceptions are even more 10:31:09 leaverou: 1 10:31:13 ChrisL: 1 10:31:18 zcorpan: 1 10:31:21 leaverou: we avoid exceptions by dropping the past broken things 10:31:21 hober: abs. 10:31:27 ??: abs 10:31:32 dauwhe: 1 10:31:37 s/??/weinig/ 10:31:38 SteveZ: 3 10:31:41 plinss: abs 10:31:48 tantek: we are never going to drop the past broken thing here Tantek, it would break too many things. Unless you think we're gonna drop block altogether 10:31:50 hyojin: 3 10:32:00 leaverou: we always drop past broken things, like using tables+gifs for layout 10:32:01 ojan: 1 10:32:10 by "drop" I mean what we teach authors 10:32:14 modern web practices 10:32:28 tantek: in that case it's dropping a methodology, not the tech. The tech is still there to do layout by tables 10:33:05 leaverou: that's the author-centric point of view, that we drop things effectively by dropping them from how we teach 10:33:15 tantek: so we're gonna stop teaching block? 10:33:17 that's basically what frameworks do, they drop all of the platform 10:33:24 no, we stop teaching % margins/padding on block 10:33:32 johanneswilm: 1, greg: 3, matt: 3, brian: abs, iank: 1, shans: 1, rachelandrew: 1 dbaron: 2 or 3 10:33:53 tantek: people will try them anyway. IF anything, by changing something from grid to block and forgetting to change the margin 10:34:07 plinss: Is there anyone voting for 3 that obj to 1 10:34:08 tantek: but mostly because "they work here, why wouldn't they work there?" 10:34:13 tantek, Rossen yes 10:34:17 plinss: And the reverse? 10:34:20 TabAtkins: Yes. 10:34:40 tantek: We did have resolution consensus before. 10:34:47 TabAtkins: Then we'll obj to the current situation. 10:34:57 fantasai: There's sig. new information. 10:35:05 ojan: The resolution from last time was option 2. 10:35:27 dbaron: Did the discussion last time distinguish between 2 and 3? 10:35:34 tantek: No. 10:35:45 The resolution from last time was effectively (2 or 3) 10:35:54 plinss: I'm open to suggestions on how to move forward. 10:36:01 what we found out today is that 3 is a clarification of the past resolution 10:36:35 TabAtkins: If I understand, MS main objection is dealing witht he legacy content. I'm looking for a solution that keeps your content working and lets this move forward. If we knock that out, does it remove enough obj that you're okay with it? 10:36:36 Rossen: No. 10:36:45 TabAtkins: We're at an impass. 10:36:47 leaverou - I'd like to understand how you'd propose making CSS *better* for authors, not just consistent with all legacy 10:36:59 Rossen: The abspos information doesn't bring anything new because we're already doing #3. 10:37:13 Rossen: But it's a thing we needed to clarify. 10:37:40 dbaron: I think one reality is that in a lack of consensus we go with impl market share. Does safari match chrome? 10:37:44 TabAtkins: Yeah. 10:37:46 tantek: I don't think you realize how hard exceptions make CSS to understand and teach. 10:37:52 gregwhitworth: But they said they'd switch. 10:38:04 Rossen: He said he would switch on the telecon. 10:38:12 TabAtkins: It's easier to not switch. 10:38:20 TabAtkins: We can make it officially undefined. 10:38:22 leaverou: unfortunately I do realize how painful that is and hence want to avoid teaching authors the bad ways of old 10:38:30 s/He said/Hyatt said/ 10:38:31 fantasai: Either way we're closing this with a formal objection. 10:38:54 Florian: Is leaving it undefined and let it converge work? 10:39:08 tantek: Having one consistent but suboptimal rule is better than having that in most cases, but not in grid, but wait, it's different if you have abspos etc etc 10:39:11 tantek: I'd rather have that then an arbitrary top-down decision 10:39:23 shane: Is it possible to remove % margins from flexbox? 10:39:42 TabAtkins: Taking out doesn't mean it's not unspec. 10:39:55 shane: It means there's no expectation on when it should be impl. 10:39:59 no but going to loo so will search 10:40:04 TabAtkins: We'll have to say % margins do not work in this context. 10:40:08 tantek: Or ignored. 10:40:28 fantasai: You can't ignore because you have to parse in. 10:40:41 plinss: Earlier we rejected a user switch 10:40:47 fantasai: I disagree with switch. 10:40:53 hober: I think it's a terrible idea. 10:41:32 Florian: Can we consider the option of leaving it undefined? Let the market sort it out. 10:41:38 SteveZ: But then you don't have interop 10:41:43 hober: You eventually do. 10:41:59 gregwhitworth: With the rest of the CSS2.1 stuff we're dealing with I'd rather not. 10:42:01 block-percentage ? 10:42:16 gregwhitworth: We're stuck, I'd rather we circle back and talk again later. 10:42:17 leaverou: % margins and padding are *already* inconsistent with % height 10:42:20 this is trying to fix that 10:42:32 gregwhitworth: I think we should move on to the next item. 10:42:38 tantek: yes, but you will have this inconsistency *anyway*! 10:42:40 plinss: I agree. We're not getting anywhere. 10:43:16 TabAtkins: So the spec if currently listing th ebehavior that we're not happy with. We can't push to CR as it is with and active obj from a major impl. I will just undefine it if we leave it as it is. 10:43:27 gregwhitworth: I was suggesting we go sit around a table and talk about this. 10:43:39 TabAtkins: Assuming nothing comes out of a conversation we undefine it. 10:43:43 plinss: So a timeline? 10:43:48 gregwhitworth: I was thinking tomorrow 10:43:59 TabAtkins: A day or two is fine. I don't want to hold up the spec. 10:44:06 plinss: Let's do that. 10:44:11 plinss: Other flexbox issues? 10:44:21 fantasai: No, we've got some editing to do. 10:45:08 Topic: Old tests that are invalid 10:45:55 SimonSapin: We've seen that happen in two cases. One is that for hex colors we have tests in 3 or 4 or 8 are not supported, but in color 4 they are supported so the old tests fail. What should we do about such tests? 10:46:11 SimonSapin: Should tests be updated if a later version of the spec changes behavior 10:46:32 ChrisLilley: We usually remove the text or change to point to where ever the new spec is. 10:46:41 s/text/test/ 10:46:43 SimonSapin: If that's okay for everyone, we should change the tests. 10:47:10 fantasai: Fo that test you have two permissable renderings. If you're a 2.1 agent you treat it one was, if you're level 4 you render another way. 10:47:20 ChrisLilley: I don't think CSS2.1 UA is a concept. 10:48:09 fantasai: I think there's impl that aren't caught up and they shouldn't be flagged as failing for that. If you mark something as invalid it should last. We tested for this because there was a quirky method of doing hex and we wanted to test for that. 10:48:30 fantasai: So this is an importat test to make sure people that don't support colors 4 parse correctly. 10:48:42 fantasai: For ref tests we can have two references and you have to match either one. 10:48:50 SimonSapin: Okay. 10:49:32 fantasai: For a given UA they'll only have one reference, but for the test suite at w3c we should have two references. 10:49:48 dbaron: It would be useful to have a resolution to fix old tests that fail due to new specs. 10:49:54 TabAtkins: Is anyone actioned to update? 10:49:58 ... so that they pass either way 10:49:58 plinss: We havea pull request 10:50:05 gregwhitworth: How are the tests attached? 10:50:20 s/remove the text/remove the test/ 10:50:30 fantasai: There's metadata that tags to a specific section in the spec. You'll have a tag to however many specs you're testing. 10:50:42 SimonSapin: So each test is in a seperate test suite. 10:50:52 … per spec 10:51:00 @ gregwhitworth https://wiki.csswg.org/test/format#specification-links 10:51:22 RESOLVED: We want to update old tests but leaving the old pass conditions in tact 10:51:47 ChrisLilley: Thanks 10:52:13 SimonSapin: And the other case is that we sited the way to go...and declaration including style rules should only accept @rule like @page does. Even if there is no such @rule defined yet because it makes a difference in the error recording. 10:52:40 SimonSapin: There's a CSS2.1 test that fails there. 10:52:49 dbaron: That's a case where we should fix CSS level 2. 10:52:54 fantasai: That should be backported. 10:53:06 SimonSapin: I sent an e-mail to the list asking to include an erratta. 10:53:31 Bert: I missed that, but there is something strange about that. It allows @keywords inside declarations which is disallowed by CSS2. 10:53:37 TabAtkins: It's fine by syntax. 10:53:48 Bert: We're breaking a promise that's explicite in a spec 10:53:59 SimonSapin: It's a declaration that contains @rules 10:54:05 Florian: It is a breaking change. 10:54:10 fantasai: It won't break any impl. 10:54:24 SimonSapin: I made that change in FF and the test doesn't pass anymore 10:54:44 TabAtkins: Like dbaron said we should fix 2.1 to no longer say the opposite and then fix the test suite. 10:55:04 SimonSapin: I wrote an eratta and there was a resolution. 10:55:08 s/I made that change in FF and the test doesn't pass anymore/I made the change in FF a coule years ago, and the only bug report is that the test doesn't pass anymore/ 10:55:16 plinss: So we just need that reincorporated. 10:55:29 Bert: I have the text. I'll put in the errata. 10:55:36 plinss: That takes us to lunch. 10:55:48 Change proposed in https://lists.w3.org/Archives/Public/www-style/2013Apr/0506.html , resolved on in https://lists.w3.org/Archives/Public/www-style/2013May/0783.html 10:55:55 10:55:56
10:57:24 s/no but going to loo so will search// 11:15:37 skk has joined #css 11:30:26 jdaggett has joined #css 11:33:46 johanneswilm has joined #css 11:43:32 lunch time? 11:44:18 yes 11:44:27 till 21:00 JST. 11:45:28 thanks! 11:45:52 :) 11:52:38 skk: そのNHKの記事が面白い！それと写真ありがとう！ 11:55:06 Ms2ger` has joined #css 11:59:03 tkonno has joined #css 12:17:24 ChrisLilley has joined #css 12:18:24 weinig has joined #css 12:19:38 plinss: Let's get started 12:19:52 Topic: CSS UI 12:20:05 MaRakow has joined #CSS 12:21:17 tantek has joined #css 12:22:48 hyojin has joined #css 12:22:49 Florian: There's a few subtopics 12:23:02 Florian: Tab sent a mail with some feedback that we can address as a group 12:23:14 https://lists.w3.org/Archives/Public/www-style/2015Aug/0238.html 12:23:28 rachelandrew has joined #css 12:23:51 jihye has joined #css 12:24:06 Florian: There is a note...We added on a request from the WG a note on user-select:none about how the combo of that and content:editable was supposed to behave b/c there are use cases where this is reasonable and we wanted to capture this req. 12:24:22 Florian: Given the way the editing TF is progressing I'm thinking we should drop it b/c how it will be addressed. 12:24:31 s/content:editable/contenteditable=true 12:25:14 Florian: There's no near-term plan to sync what every browser does for contenteditable=true. However, what is happening is there will be a number of events dispashed that will let a JS react to anything that is happening and cancel if the author wants something else to happen. 12:25:29 rachelandrew has joined #css 12:25:44 Florian: If they are editing the kind of JS we had in mind we should do it. If they're doing something different, the semantics in the note would not even apply. 12:26:13 Florian: If it belongs somewhere, it's there, but authors will be able to do what they want to so we should drop the note. 12:26:29 Florian: I agree that it should be possible, but we don't tend to put that in our specs 12:26:36 tantek: It's an exception, not a rule 12:26:49 Florian: Given where conteneditable is going, the note isn't needed. 12:27:10 tantek: However we spec user-select, it allows the editing folks to use it how they need to. 12:27:49 Florian: But the people writing the editing spec will not make it behave any way. The JS authors will be able to control it. If they're writing a code editor, they won't care about this use case. It's not an evil note, I think it's not applicaple. 12:27:54 tantek: Then leave it out. 12:28:29 johanneswilm: As someone in the TF, the problem with the note is that it's the only one aimed at JS editors, not browser vendors. It would be new for JS. 12:29:47 johanneswilm: No matter where the note is, if you want to target the old contenteditable then it makes sense. If you want to target the new stuff, you're talking to the JS editors who build this stuff. That's fine, but it should be somewhere that pulls a bunch of things about how to pull a JS editor. The only reason JS editors are reading this is to find bugs. 12:29:54 Florian: Proposal is to drop the note. 12:30:07 TabAtkins: Obj? 12:30:19 RESOLVED: Remove the note regarding user-select and contenteditable 12:30:48 Florian: We also desc renaming user-select: element to user-select:contain. We had general agreement, but I think we were pending agreement from MS. 12:31:05 s/pull/build 12:31:12 Florian: You used element under a flag, we were waiting for you to let up know. 12:31:49 Florian: On a sep topic, we also mentioned that user-select: text is terrible because it selects more than text, but everyone supported that for a while. TabAtkins suggested a new name. 12:31:54 TabAtkins: We can drop it for now. 12:32:08 RESOLVED: user-select: text stays named as-is 12:32:35 Florian: Another comment was they had reviewed appearance and it was fine except they didn't want the bottom value. 12:33:21 Florian: The current version has none, auto, and a long series of many values that are used to make form controls look the way they should. There's been no sucess on sync browsers on that. The new appearance has none and auto and just has magic for the form controls. 12:34:03 Florian: It's either none and you can't style or auto and you get the magic. There's a handful of values that are useful, for ex. button so you can say this link looks like a button. I put that in there because I don't think it's a crazy usecase. 12:34:37 Florian: MS also recently created support for -webkit's appearance. I took that support as evidence that the web needs it. Google doesn't like it. 12:34:44 tantek: Does Google support the back compat? 12:34:53 TabAtkins: And we're investigating the usage. 12:35:11 ojan: We'd like to drop as much as we can and whatever is left for backcompat can go in the spec. 12:35:24 gregwhitworth: I have no interest in standardizing for backcompat 12:35:48 esprehn: It implies more than BG image. On mac there's padding and windows it doesn't. There's a bunch of heuristic behavior that's scrange to spec. 12:36:12 Florian: If we spec appearance button, this lets an author opt into appearing like a native button, whatever that means. 12:36:32 esprehn: For layout, is there a give me the padding that may be on every platform. THat seems author hostile. 12:36:40 Florian: Except when the author asks for it. 12:36:48 gregwhitworth: We don't want to cement that. 12:36:59 tantek: I'd rather drop and spec a backcompat. 12:37:25 ??: WE often when going from prefix to non-prefix is to fix that. 12:37:37 dbaron: For backcompat we'll need to deal with a lot of prefix prop 12:37:48 s/deal with/spec/ 12:37:55 fantasai: If we have a prefix we need to have a path forward for those that want to move the path forward. 12:38:01 ??: There's a clear path forward. 12:38:22 s/??/greg 12:38:22 Florian: I'm not married to the button. If you want it off I'm okay removing it. If Chrome is investigating what's nec. we might as well wait. 12:38:26 https://github.com/search?l=css&q="appearance+button"&type=Code&utf8=✓ github search for "appearance button" 12:38:36 fantasai: The reason not to use it is it doesn't behave like a form. 12:38:47 TabAtkins: If you wrap it in a form with the method=git 12:39:04 plinss: I would rather not put in extra values until we've proven we must have them 12:39:06 tantek: Agreed. 12:39:10 Florian: I'm okay with that. 12:39:27 gregwhitworth: If you test our browser you'll find more, but hopefully that's not a perm. thing. 12:39:33 s/git/GET/ 12:39:50 Florian: so do we resolve to drop all the values except none or auto 12:40:23 gregwhitworth: I'm looking for bugs, but if we're doing them they're in as stop gaps. There is a button tag. Because it exists doesn't mean it has to be standardized. 12:40:41 tantek: So let's drop everything except all and none. 12:40:49 plinss: Obj? 12:40:59 RESOLVED: Drop all values except for auto and non 12:41:03 s/non/none 12:42:08 Florian: A while back I put a blink time prop which controls how the caret blinks. I was told this was a bad idea and we should expore this using CSS animations. Having explored that, the conclusion was that's overkill. We might just need caret-animation auto and none. TabAtkins suggested fade. Just a limited list. 12:42:20 ChrisLilley: I don't think theyre should be a caret specific property. 12:43:04 Florian: If we have the prop as spec now, caret animation is auto by default. If you want to do something specific, such as you don't want it to blink. If caret color is a color which exists you can't animation. 12:43:26 Florian: There's bunch of text editors that let you control caret. 12:43:42 ???: Does anyone let you control the caret? On windows? 12:43:48 gregwhitworth: We only have 3 values. 12:44:02 s/???/sam/ 12:44:02 fantasai: If you have no blinking and the caret is animatable you can do anything you want. 12:44:05 weinig has joined #css 12:44:10 s/caret/caret-color/ 12:44:20 s/I don't think theyre should be a caret specific property./I don't like the animation model for caret being different to the rest of animation/ 12:44:44 Florian: Right now the caret-color can cange to match the text. I don't think we should work to make something stop working that already does. 12:44:54 sam: What's the use case for not blinking? 12:45:02 Florian: a11y 12:45:19 sam: Then that's the browser that should control. It just seems like a... 12:45:34 Florian: You said OSX doesn't have controls at the API? There's terminal 12:45:48 sam: terminal is non-standard. It's completely custom. 12:45:55 tantek: The only use case is a11y? 12:46:15 Florian: That's the main one. There's minor use cases for blinking in and fading out. Like when you're doing retro things. 12:46:24 tantek: I think in those cases you rebuild your own caret. 12:46:36 hober: I think that the a11y is better as a system setting. 12:47:06 Florian: I think the homepages of 2 WG members have a blocky caret. People are doing it and so it's out there. 12:47:17 TabAtkins: A number of text editors offer minor control over this. 12:48:02 Florian: There's a bunch of web text editors that would want to behave like regular text editors. I think it would be wrong...it's open ended. Having a limited set to choose from, though, is good. 12:48:42 tantek: I don't think there's sufficent use case in this group. I think we should punt ot the editoring task force and say if you want it, you spec it. If you guys need it write the requirement. Otherwise we'll drop it. 12:49:11 tantek: You cited web based text editors, so that's what made me think of it. 12:49:22 fantasai: What if they come back and say let Florian spec this? 12:49:26 tantek: Then we cross that bridge. 12:49:38 Zakim has left #css 12:49:55 Zakim has joined #css 12:50:05 johanneswilm: The main problem in some browsers is you couldn't put anything on top of the caret. I don't know if that's still the case, but it had an infinate-z. If you could put something on top if it you could animate to whatever. 12:50:16 fantasai: We can animate it, but it intersects with blinking. 12:50:31 johanneswilm: Editing has the major JS editors. 12:50:42 Florian: WE don't have the people that write the code editors. 12:50:54 johanneswilm: We have them. Martin wasn't at the meeting, but he's on the task force. 12:51:15 Florian: How do you want that action/resolution to be phrased, tantek? 12:51:40 tantek: We resolve that we drop the prop. We action you to go to the editing TF to ask if it's a requirement and to document it if it is. 12:52:11 RESOLVED: drop the caret-animation property 12:52:29 ACTION Florian to figure out with the editing TF if there are and what are the requirements for caret-animation 12:52:30 Created ACTION-705 - Figure out with the editing tf if there are and what are the requirements for caret-animation [on Florian Rivoal - due 2015-09-01]. 12:52:47 s\Martin\Marijn Haverbeke 12:53:14 https://lists.w3.org/Archives/Public/www-style/2015Aug/0010.html 12:53:15 Florian: Next topic is this e-mail 12:53:41 dael - and drop caret-blink-time to be precise 12:53:57 - drop all properties to do with caret animation 12:54:38 Florian: We got a test case contributable that was trying to test that if you set the cursor on the select element and you set the cursor to something else on the parent of the select element and you click and it shows the dropdown. Some versions of IE show the parent. In general the spec says what to do when cursor is in an element, but it doesn't say anything about overlapping. We might need to clarify and I don't know how to explain that. 12:55:18 Florian: So you're overlapping several things and this has something to do with which thing would get the event if you click, which we also don't define. It's def. undefined and would be worth clarifying if we could 12:55:26 tantek: We've punted on this because it's hit testing. 12:56:02 Florian: So should I write nothing, or write that it depends on the overlapping element. 12:56:12 tantek: I don't think you need to write a test case. 12:56:26 Florian: We've written tests to find out UA behavior to find out how to spec it. 12:56:52 tantek: So we can accept the test. We've resolved not to accpt hit testing in UI 3 and I'd advise against it in 4. 12:57:10 ChrisLilley: I don't think this has to be hit testing. One thing we should say is what part of the cursor has to be over something. 12:57:18 tantek: That I'd be okay clarifying. 12:57:34 that the hotspot of the cursor is what should be in the border box 12:57:53 ChrisLilley: The prop from the guy wasn't sufficent. You've got two items in a stacking context. Things can be overlapping for different reasons. If there's two abspos elements we know what's on top. 12:58:02 tantek: I don't want any hand waving about hit testing 12:58:09 ChrisLilley: I said which renders on top. 12:58:26 zcorpan: If the cursor depends on hit testing, what appears on top doesn't matter. 12:58:35 ChrisLilley: If we have 2 abspos elements we know what's on top. 12:58:43 Florian: Hit testing depends on what's on top and other things 12:58:59 tantek: And you want it to matter, the hit testing. 12:59:42 Florian: Now the test was written because there was a disconnect between the testing. IE had a version where the cursor would click in the dropdown, but looked like the cursor behind it. Even if we don't define hittesting we can refer to it. 12:59:57 MaRakow: When was hit testing dropped? 13:00:11 Florian: I think we have a resolution that chrsaid about using hot spots. 13:00:27 chrislilley: I'd prefer to refer to hit testing. 13:00:42 tantek: I don't know how without opening a can of worms because people will ask where to look for it. 13:01:19 Florian: Interop with hit testing is still something worth striving for and specing eventually, but hit testing is still something that's used. However you do hit testing, use that to pick the element for the cursor. 13:01:29 Florian: And then I can accept the test with spec justification. 13:01:39 Florian: So I'm tempted to put that in the spec. 13:01:49 s/MaRakow: When was hit testing dropped?/MaRakow: The cursor hit testing through the select dropdown was a bug, not design/ 13:01:57 tantek: So rather than leave it undefined, we refer to something undefined? 13:02:11 s/Florian: We've written tests to find out UA behavior to find out how to spec it./ChrisLilley: We've written tests to find out UA behavior to find out how to spec it./ 13:02:15 Florian: Yes, it lets us refer to several different ways of testing. 13:02:20 tantek: Sure, let's try it. 13:02:34 Florian: So two resolutions to talk about hit testing and hot spots 13:02:59 tantek: And to say the hot spot is what matters and in the case of overlapping elements what's clicked is what counts, and to not define that. 13:03:18 Florian: If we do that we can try and use the term. 13:03:30 cssom view refers to hit testing in e.g. https://drafts.csswg.org/cssom-view/#dom-document-elementfrompoint 13:03:41 Florian: Side question, can this be a way that UI level 4 is more precise, or should this go in level 3? I think we can just say level 4. 13:04:00 tantek: If it's a detail that there's interop, I think add it to level 3. It's a clarification, not a CR breaking change. 13:04:07 Florian: I wouldn't want to break CR. 13:04:19 +1 zcorpan 13:04:19 fantasai: You're in the new process. You're just republishing. 13:04:33 tantek: It's a clirification, not a sig. change. 13:04:35 ChrisL has joined #css 13:05:26 RESOLVED: Clarify that we're using the hotspot to determine which element is relevant 13:05:44 "within the element's border edge" 13:05:44 RESOLVED: depend on hit testing 13:05:52 RESOLVED: Do not define hit testing 13:06:19 http://w3cmemes.tumblr.com/image/127554590107 13:06:33 Florian: it was brought up with should have text-overflow-fade. We have ellipsis, but if it's a line another desirable effect is to fade to transparancy. 13:06:56 Rossen: We have a resolution on this from Seoul. We added this, you just need to add the text. 13:07:02 Florian: You're sure we resolved? 13:07:12 Rossen: I clearly remember we had the fade added to ellipsis. 13:07:21 astearns: We talked about it, but there was no resolution. 13:07:38 Rossen: There was the whole discussion about adding the pseudo element. 13:07:43 ChrisL: Can we resolve it now? 13:08:11 fantasai: Maybe there was a proposed resolution with no final resolution. 13:08:52 astearns: I don't see a prop resolution in the minutes. 13:09:01 Florian: There was discussion about how long the fade should be. 13:09:08 tantek: Who was asking for this? 13:09:12 TabAtkins: Bloomberg. 13:09:24 Florian: And now there's someone else on the mailing list 13:10:07 Bert: Can someone remind me, I wasn't there. 13:10:19 Florian: Instead of doing ... at the end, you would just fade out. 13:10:39 tantek: You would render the characters but where the ellipsis would go, you would fade them out. 13:10:57 plinss: Rather than some random set of prop, I'd rather see a pseudo element that can be styled 13:11:22 fantasai: I think we were planning to do that too, but this was a stop-gap. You can instead content witht he pseudo, not remove it. 13:11:34 Florian: The pseudo matches the existing... 13:11:38 s/instead/insert/ 13:11:58 fantasai: There's no way to do this with existing properties. We cannot just add a pseudo element to get this. 13:12:07 tantek: Do you have screenshots of this? 13:12:12 TabAtkins: Yeah, it's everywhere. 13:12:31 andrey: The tabs in chrome do this is you have narrow enough text. 13:12:34 http://snook.ca/archives/html_and_css/handling-overflow 13:12:46 fantasai: Even if we added pseudo magic, we'd want a keyword for common behaviors. 13:13:24 s/behaviors/behaviors and this is clearly one of them/ 13:13:24 Florian: CSS UI level 4 isn't near CR yet. I think we can resolve to edit and I come back later with text. I'll read the notes from the last meeting. 13:13:26 andreyr has joined #css 13:13:47 tantek: When does dino get here? When we talked about this in Sydney, dino had particularly strong inputs on this. 13:13:54 hober: We basically do it in the location bar. 13:13:59 I'm not sure why we need to spec the fade. If we give them an equivalent of -webkit-line-clamp, they can do the fade themselves with a mask or pseudoelement and customize it as they want, no? 13:14:20 fantasai: They wanted more control over where the ellipsis happens. That kind of thing is stuff they need, but we won't do it immediatly. 13:15:12 Florian: Can we resolve that we add it somehow or do we resolve nothing? I think we agree that we want it. 13:15:50 fantasai: I think this makes sense to add. Even if we have a more sophisticated mech we want to have a short keyword to do this. I imagine this being a keyword to decide on for whatever we do in the future. I'm in favor of adding it. 13:16:06 Florian: Objections? 13:16:10 RESOLVED: add text-overflow-fade and let Florian figure out the details 13:16:31 dino has joined #css 13:17:14 Florian: With the exception of having not written the text for the last resolution, I don't have intentions to add more to CSS UI 4, so I think we should go to FPWD soonish. Does anyone have a requirement of something they'd like to have as a part of UI 4 that should be added? 13:17:29 ChrisL: If someone has a prop they can do it for the next draft. Let's go for it. 13:17:33 plinss: objections? 13:17:43 RESOLVED: publish FPWD of CSS UI 4 13:17:54 antonp2 has joined #css 13:18:03 Florian: Does this let me pub now and add fade later? 13:18:12 plinss: publish early, publish often. 13:18:22 fantasai: Do whatever you want 13:18:31 dbaron: FPWD has implication on patent 13:18:36 astearns: So better to put it in. 13:18:41 s/patent/patent policy/ 13:19:08 Florian: That's all for CSS UI today. You're all welcome to read the doc. 13:19:24 Topic: css-text-4 13:20:00 plh has joined #css 13:20:57 Florian: In NY we were discussing whitespace pre-wrap and we resolved to add a pre-wrap-auto and for pre-wrap to have a specific value and to add that to level 3. WE also resolved to add pre-wrap-trim to level 4 which would drop the spaces at the end of the line. White space is a simple prop in 3, but a shorthand of two prop in level 4. 13:21:18 Florian: So how is pre-wrap-auto and -trim related to these new longhands. 13:21:29 fantasai: So we resolved to you can see the spaces? 13:21:51 Florian: We discussed three. pre-wrap, pre-wrap-auto, and pre-wrap-trim which drops the spaces at the end of the line. 13:22:01 fantasai: Why are we not using three lines. 13:22:47 Florian: What we didn't discuss in NY is that the whitespace is a shorthand of two longhands and I don't know how to express that. I have two options. The new option 3 is that the longhands were a bad idea and lets get rid of them. 13:23:02 Florian: So, first, do we want whitespace to have long hands? 13:23:20 zcorpan: usecase for longhands? 13:23:35 fantasai: They seemed useful, but I don't remember the exact use case. 13:23:42 tantek: Did you have an option you pref? 13:23:51 s/useful/orthogonal/ 13:24:10 Florian: I've been back and forth. I think I prefer what I called option 2 which is to not change text space collapse prop. 13:24:21 fantasai: I prefer option 1. But I can merge them back in. 13:24:26 antonp1 has joined #css 13:24:52 fantasai: At this point we have 3 prop that are related. There's text-space-collapse, -trim, and text-wrap. 13:25:29 Florian: And the reason it's tricky is with prewrap auto things aren't entirely orthogonal. The wrapping and collapsing are not different concepts. If you do collapse the space you won't wrap. 13:25:46 fantasai: I think option 1 makes more sense because how you wrap depends on how you collapse, not the other way around. 13:26:25 fantasai: I'd be happy with option 1. As far as longhands or not, they're very orthogonal things. If you ever want the set to cascade independantly, I'm not sure. But wrapping and spaces are two independant variables. 13:26:34 Florian: So re-reading, I prefer option 1. 13:26:38 fantasai: Any other opinions? 13:26:50 tantek: I think we should try and make option 1 work and report back if it doesn't. 13:26:51 https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html 13:27:14 fantasai: dbaron can you have a shorthand that has inheriting and non-inheriting prop? 13:27:27 dbaron: We haven't and I prefer not to, but it could be done. We've done all. 13:27:47 fantasai: I think whitespace should be in trim as well. If you reset to normal it should do all the normal things. 13:28:12 Florian: So, resolve option one? 13:28:19 s/whitespace should be in trim/text-space-trim should be in white-space shorthand/ 13:28:42 Florian: If we do that option 3 isn't excluded anymore. If we make whitespace trim that that part is possible. It might be an option, but it's not a good idea. 13:28:51 fantasai: No, that wouldn't work because you need it to inherit. 13:29:18 fantasai: I thinkw e also have a resolution that we need to add the other two longhands of white-space if we're adding white-space-trim 13:29:26 RESOLVED: Use option 1 13:29:34 Try option 1, report back if you run into problems. 13:29:53 fantasai: So should write-space-trim be added longhand which I think yes. 13:30:10 astearns: It makes sense that white space needs to be a shorthand. I'm not sure we need the longhands. 13:30:22 fantasai: It needs to reset to normal. 13:30:44 Florian: So astearns are you saying pre-wrap auto and trim should not exist or only as longhands? 13:31:10 astearns: I'd prefer not to add any values unless they're needed. We aren't goingto add values to the shorthand unless there's a demonstrated need. 13:31:38 Florian: For that I'd be okay for trim, but auto is justified on the shorthand because it gets you browser behavior. Also we have it on level 3 and there's no long hand on level 3. 13:31:58 Florian: So keep the behavior of white-space-trim but only on the long hand. Is that okay with you, Bert? 13:32:07 Florian: We'd still have the behavior, but you need a long hand. 13:32:32 Bert: I'm not sure. I see you have the functionality, but I'm not sure I want whitespace to become a short hand. I don't have a def. opinion. 13:32:42 Bert: It's at the level I want to spec things. 13:33:00 fantasai: New lines and spaces are in the same longhand. The first one is how you collapse and the second is how you wrap. 13:33:32 fantasai: It allows you to set wrap independanlty of how you collapse. I agree with you that the previous XSL had three different prop and it was confusing. 13:34:11 Florian: With a bit of discomfort with the shorthands being linked to different longhands with behavior...it's weird. 13:34:21 jihye has joined #css 13:34:25 fantasai: Once place is where they get conflated is trim has a trim inner prop. 13:34:40 fantasai: If you're using consume before and after you might want that inherited sep. Or reset. 13:34:41 s/prefer not to add any values/prefer not to add any shorthand values/ 13:34:59 fantasai: I'm not sure and I don't feel too strongly about that. 13:35:04 s/inherited/cascaded/ 13:35:36 Florian: But we're not on my issue anymore 13:35:53 fantasai: I guess for simplicity lets group it under the shorthand and if there's an issue people can raise it. 13:36:30 RESOLVED: text-space-trim, text-space-collapse, and text-wrap are longhands of whitespace 13:36:57 and people can raise issues if that's a problem. 13:37:28 Florian: astearns I think a while about you tried to get the WD out of text level 4. 13:37:43 dauwhe: I'll prob have suggestions for features around hyphenation 13:38:01 fantasai: I've been told it's all wrong, but asked him to list them on the ML and never heard back. 13:38:44 plinss: Anything else on text? 13:39:17 Florian: Does this change if we should do FPWD? 13:39:21 fantasai: Go, we should. 13:39:33 RESOLVED: FPWD for text 4 13:39:56 Topic: user stylesheets 13:40:35 ChrisL: There was some discussion about user stylesheets that originated about customization. I did a twitter survey and most people didn't know this feature exists. It's a developer feature that we pretend is for authors, but they can't use it. 13:41:03 ChrisL: It seems to be a misfeature that's mostly, but not always implemented. I think Chrome removed it. 13:41:19 TabAtkins: Yep. All we have is UA styles and page styles 13:41:43 Safari has them 13:41:56 you can pick one at a time 13:42:06 q+ 13:42:06 not really a great UI 13:42:08 ChrisL: I was asked if this feature is going to be extended or depricated by the group. I'm aware for someusers that need customization they're not using that mech. Do we have any evidence it's being used? Should we leave it alone? Should we drop and make something better? 13:42:17 ChrisL: I wanted to surface that discussion 13:42:38 SimonSapin: There's a FF extension called stylish that types in CSS and I think it uses the user stylesheet. 13:42:42 ChrisL: Does it use our doc? 13:42:45 TabAtkins: Yes. 13:43:08 dbaron: It may or may not. We have user stylesheets for extensions. I think we now have a per page one. 13:43:39 ChrisL: A lot could have been done with user stylesheets and it wasn't. For example bookmark could have used the stylesheet. It could be a mech where people trade their stylesheets. 13:43:53 actually, not sure about the API; might just be thinking about https://bugzilla.mozilla.org/show_bug.cgi?id=988266 13:44:07 Florian: There's nothing wrong witht he design of user stylesheet. What's been missing is a UI for this. I don't think it's impossible, I think it hasn't been an important feature for broswers. 13:44:30 q+ 13:44:49 ack florian 13:45:09 Florian: I think you have something that lets you apply user stylesheets. I think this is a good feature for a11l and good for people who want to customize their stylesheet. I think it's fine if people want to use it. Or here's a variant of the dev tools. Let people experiment or ignore. 13:45:35 hober: Chrome means that the user style is always just 0. 13:46:33 esprehn: There's little evidence that people want it. It's been Safari for years and people weren't using it, it wasn't powerful enough. The Safari sheet applies to everything. You want something powerful like stylish so you can have if statements and the like. That might be out of scope 13:46:36 Marijn Haverbeke (the person behind the CodeMirror editor): CodeMirror's vim mode does use a custom caret (in non-contentEditable 13:46:36 mode), which currently doesn't work in contentEditable mode, so sure, 13:46:36 this would be nice to have. But that use case, where the caret needs 13:46:36 to overlay the character after it, might be more than browser vendor 13:46:37 are willing to chew. See http://codemirror.net/demo/vim.html 13:46:52 ChrisL: That's one of the comments I got. When people want to over-ride they want rules. 13:46:53 MaRakow has joined #CSS 13:47:06 Florian: Once we have this, the rest is UI 13:47:24 ChrisL: And there's various things that use browser engines. If they want per user they need it. 13:47:34 hober: We provide support for user stylesheets. 13:47:45 Florian: And one of the epubs that lets you change the background 13:48:11 ack dauwhe 13:48:19 dauwhe: I think ebook is a huge usecase. ebook devs right now are putting a lot of work into trying to detect night or day mode, there's a lot of work into that and lots of misunderstandings. 13:48:44 dauwhe: I just hope for a wide API or something to make it easier for ebooks. 13:49:02 Florian: It wouldn't be a JS API for web authors, it's for people that edit the engine into a larger application. 13:49:22 Florian: I think we're missing that doc and UI innovation. It'll always be a niche issue, but it's not ever used. 13:49:30 fantasai: Day and night mode, there's a spec for that 13:49:45 astearns: Amazon isn't letting them use it, was dauwhe's point. 13:50:04 hober: I guess the question is, what is the ongoing burdon of retaining this. 13:50:08 ??: I'd say 0 13:50:19 hober: So there's some value to it and no reason to get rid of it. 13:50:29 esprehn: From our view this should be solved by UAs 13:50:33 s/??/Florian/ 13:51:04 day/night spec - http://www.idpf.org/epub/altss-tags/ 13:51:22 esprehn: We don't care about the spec. Chrome has an extension API that lets you build this feature yourself and we support authors building those tools because it will benefit devs.The low level stylesheet facility is too complicated. THe people that want to use this want to pick a them. 13:51:55 hober: The point is user stylesheets have an implication for how specificity is calculated. If we go into the spec and say have some way to specify style, it's a loss. 13:52:09 Florian: Once we have a WG that standardizes browser extensions, we don't need this. 13:52:32 esprehn: I don't believe we should standardize how browser stylesheets interact with user stylesheets. 13:52:43 sam: So my proposal was not to change the spec. 13:52:49 esprehn: We're not going to add it back. 13:52:57 tantek++ 13:53:08 tantek: It also represents preferences, such as the font. It's all user stylesheets. 13:53:27 TabAtkins: Some of those are not. What you want your serif to be isn't represented that way. 13:53:34 TabAtkins: It's not true from Chrome, it never has been. 13:53:39 tantek: It was 15 years ago. 13:53:51 fantasai: You can't communicate the mapping of a font to a serif family. 13:54:05 tantek: I'm not saying that is, I'm saying that things like link color are. 13:54:21 tantek: So if you have a thing that says pick a user stylesheet, you still have to cascade like you have it. 13:54:41 dauwhe: There's lots of complaining in the ebook about how author and user stylesheets interact. 13:54:46 TabAtkins: I prefer having that control. 13:54:56 s/serif family/to the generic serif family/ 13:54:56 hober: It's unfortunitly nec. 13:55:30 Florian: given that the difference between the browser not impl and impl and not loading is the same to the user, I think keeping it in the spec is the right way 13:55:51 ChrisL: So the conclusion is that it should stay in the spec. It doesn't need changes or improvement. 13:56:30 Florian: I wouldn't say that. @document would make this more useful. UAs that think it would be useful to expose this to their user should innovate at the wide level. There may be other ways that go through extensions, but that's not a part of the WG. 13:56:45 ChrisL: That was the discussion I wanted to have. 13:56:46 s/complaining in the ebook/complaining in the ebook developer community/ 13:56:58 Bert: Can we be more concret about the @document. I'd like to see it. 13:57:04 TabAtkins: It was in conditional rules 13:57:34 dbaron: It was dropped because there were parts we didn't know how to spec and it was holding up the rest of the spec. We might be able ot do a better job with URL comparision, but I think that was the main issue. 13:57:40 Florian: That' was my memory. 13:57:54 http://www.w3.org/TR/2011/WD-css3-conditional-20110901/#at-document 13:57:59 Bert: So we can spec this @document so I'd like to raise the priority. 13:58:22 hober: Anna has been working on adding a couple of comparision functions to the URL spec. 13:58:27 fantasai: Bert, would you volunteer to edit css-conditional-2? 13:58:32 s/Anna/Anne/ 13:58:37 SimonSapin: I believe these are compare a URL or the fragment. 13:58:42 TabAtkins: Also just the host. 13:58:51 hober: Someone should file a bug on the URL spec then. 13:58:53 http://www.w3.org/TR/2012/WD-css3-conditional-20120911/#at-document 13:59:07 sam: What was the matching granualrity intended to be? prefix? 13:59:18 s/a URL or the fragment/an entire URL or a an URL without the fragment/ 13:59:38 dbaron: There were three in the spec. URL, URL prefix, and domain. There's also regex in gecko. There's some issues with that. That does go away if we don't expose it to author stylesheets. 13:59:39 zcorpan: https://url.spec.whatwg.org/#url-equivalence no API yet 13:59:39 zcorpan: if you have specific use cases, I recommend filing issues 13:59:48 dbaron: "excluding any fragment identifiers"?! Why? This could be very useful 14:00:02 sam: Was it a full regex or a subset? 14:00:12 dbaron: Full as in calls the JS engine and tells it to deal with it. 14:00:34 sam: This is where your URL comparision question comes in, how connonization is dealt with? 14:00:57 sam: I don't think Anne's spec deals with regex but we may want to ask them to deal with it. 14:01:12 (Re: editing css-conditional-2: I'd be OK to edit css-conditional-2 if I'm guaranteed that that is the only new feature. :-) ) 14:01:17 14:02:08 Bert, I think it would be 14:05:53 Bert: are you really asking for a guarantee of stagnation? :P 14:06:48 Bert, if you finish it quickly enough, you can push for -3 :) 14:17:55 rachelandrew has joined #css 14:22:18 Trying to figure out what this is a meme for http://openpuppies.com/#3V37Hqr 14:27:18 weinig has joined #css 14:32:31 btw, Ms2ger++++++++++++++++++++++ 14:32:38 (thank you for all the test suite cleanup) 14:34:38 I try :) 14:35:24 fantasai, if you can get people to review https://github.com/w3c/csswg-test/pull/829 , that'd be great :) 14:35:47 plinss: Let's get started 14:36:13 Topic: Snapshot 2015 and prefix policy 14:37:12 TabAtkins: There's a question of what criteria do we use to include in the snapshot. Things in CR, things widely implemented? I think the latter is more useful to authors. 14:38:18 fantasai: The org purpose of the snapshot is we had a bunch of specs in CR and a bunch that we're but kinda were, but the CSS statuses didn't mean a lot. We're a lot better at not having things in CR that shouldn't be. But we also have some things in WD that are a bit behind. The previous snapshot was things in CR and had been in CR long enough that we were sure things weren't going to change much. 14:38:58 fantasai: So we had impl experience through out all the tests. We could see all of it being impl and most issues being shaken out. We knew all the parts had been tested and impl to some extent. 14:39:11 johanneswilm has joined #css 14:39:56 fantasai: So we agree the spec isn't wrong and it is pretty stable. Flexbox when it hit CR wouldn't have been in the snapshot because we didn't have the experience yet. At this point, flexbox is really stabilizing and in the next 6 months we would be able to say its pretty stable and won't have many changes. 14:40:54 fantasai: I think that's a useful delimited. To get into PR and REC you have to have two passes of everything and a lot of the time we're waiting on bug fixes. That spec is still almost as stable as REC, we're just not there. The snapshot is to break the CR into two different pieces. 14:41:43 fantasai: It's kind of like when we have WD where it's exporatory and things lock down toward the end and that's not reflected in W3C process. I think that's a useful distinction in the snapshot and we should maintin that. We might want to include more and have all the spec in CR and the stuff that's stable. 14:41:49 TabAtkins: Sure. Okay. Seems reasonable. 14:42:09 Florian: We've also suggested that the intro of what CSS is would fit in the snapshot well. 14:42:19 fantasai: I think that's a great idea and we shouldn't work on it right now. 14:42:28 Florian: And CSS 2.1 hasn't been completely replaced. 14:42:53 fantasai: We've inforporated all the property indexes. We split down the list and put a short description of what are all these specs. 14:43:09 TabAtkins: If you were to look chapter 4 is an index of all the terms we've included. 14:43:23 https://drafts.csswg.org/css-2015/#css 14:43:27 fantasai: And it maps all the things in 2.1 that have been replaced. That's what's in the snapshot right now. 14:43:35 fantasai: So questions for the group: 14:43:50 fantasai: One is transitions and animations. How far are the edits behind the resolutions? 14:44:10 dbaron: animations is a bit behind. transitions I don't htink there's resolutions, it's just going through e-mail backlog. 14:44:17 fantasai: Should we pub an update to transitions? 14:44:20 ChrisL has joined #css 14:44:29 dbaron: We have a resolution to pub a CR, but I have to do a DoC first. 14:44:39 dbaron: I don't know that that much has been updated from the last draft. 14:44:43 fantasai: What about transforms? 14:44:56 hober: I can't remember... 14:45:29 dbaron: There were a bunch of preserve-3d changes that need to be edited in. They're still scary in terms of web compat. I think there's some other issues with the spec not explaining it well. 14:46:12 fantasai: So what I think would be a good idea, we did resolve on a list of things to add to the snapshot, but I would rec that we put transitions, animations and flexbox into the snapshot as things that are impl widely, but not quite stable yet. 14:46:12 s/hober: I can't remember...// 14:46:41 TabAtkins: Can we just base it on the work status of the spec? That would auto-update the snapshot. We'd have to make sure work statuses are used correctly. 14:47:05 fantasai: I think we could, but the text we're using and the order is significant, so we couldn't auto-gen right now. Maybe for next year? 14:47:12 TabAtkins: We could do it now. 14:47:37 fantasai: I don't want to deal with all this text that needs to stay in. I'd like transitions, animations, transforms, and flexbox into a section os snapshot that's marked as not stable. 14:47:45 dbaron: I'm not convinced it needs to be stable. 14:47:50 TabAtkins: The web is depending on it. 14:47:57 fantasai: But the spec isn't synced to the web. 14:48:12 hober: Should the specs be in, yes. How you orgniaze it I don't think we need to talk about. 14:48:31 dbaron: If you create more categories, there's more categories for us to argue about what goes into them so we're better off not creating more. 14:48:54 fantasai: I just feel that if we put them in as-is, it's just here's bunch of stuff that you can use as is. The job of this thing is to tell you what's stable. 14:49:08 hober: I hear you saying we organize this in a way to make it useful. Sure. 14:49:22 dbaron: At the level the snapshot audience is going to look at it, it's fine. 14:49:45 fantasai: There's a variety of audiences. There's Japanese market and digipub market and they're going to look at it differently. 14:49:59 fantasai: The snapshot is for us to communicate with other people in the industry. 14:50:31 hiroshi:Is the writing-mode in this document? 14:50:55 fantasai: Not yet. Hopefully writing-mode and flexbox will be stable by the end of the year. 14:51:09 Florian: so writing-mode is not yet, but soon. 14:51:18 hiroshi: OKay. That one is important for me. 14:51:27 fantasai: That's most of the issues other then prefixing. 14:52:01 Florian: While we're talking about stability, different communities care about different levels. Japan's industry and publishing want things that have a big stamp that says it's ready. 14:52:33 fantasai: I think the snapshot level is what they want to be looking at. I think for them the distinction i nthe snapshot is a useful one. 14:52:47 adenilson has joined #css 14:53:25 https://drafts.csswg.org/css-2015/#experimental 14:53:32 fantasai: So, implementation of unstable and prioritry features 14:53:38 TabAtkins: Prefixing policy. 14:53:50 TabAtkins: I believe gregwhitworth had some obj to the text in the prefixing policy 14:53:58 gregwhitworth: Obj is strong, but yes I sent some. 14:54:08 https://lists.w3.org/Archives/Public/www-style/2015Jul/0447.html 14:55:17 q+ 14:55:30 gregwhitworth: I believe someone, I think hober or SimonSapin, shared the concerns that CSS shouldn't get into how or where people ship things. I think we should leave it out and that we just ultimatly don't want prefixes. I think the TAG needs to be a part of this. I think it should be up to the UA on how they handle shipping things. If it's reg keys or no matter the mech. 14:56:10 Florian: I think you are correct that the issue isn't CSS specific, but I think the solution might be lang specific. To the extent that the previous policy is being replaced, giving it the same title makes sense. 14:56:25 gregwhitworth: And that's what I said. I do understand that. Just try and make it as broad as poss. 14:57:16 Florian: I don't think anyone here has the delusion that the W3C can boss around browsers. It is useful to doc what, as of today, the WG and broswer community feels is the best policy to release things. There will be exceptions, there will have to be, but it's important to say. 14:58:08 Florian: Getting this wrong, as we've done it in the past, significnatly hampers our ability to do things in the future. The best way to release a work in progress is worthwhile to document. If you do it the way we describe but sometimes for business reasons you can't, that is life. 14:58:17 hober: I think I agree/disagree with both of you. 14:59:16 hober: I basically agree with Florian. We cshouldn't characterize contingent facts of one browser's implementation policy as fact. I preferred gregwhitworth's wording. I tallows heterogenious release. It doesn't have you must haves. 14:59:31 hober: In the current snaposhot, 3.3.1 [reads the draft] 14:59:45 As long as we make it clear that shipping prefixed properties is bad 14:59:57 hober: This assumes there's such a thing as a non-release build. 15:00:20 Then he's wrong :) 15:00:22 gregwhitworth, https://hg.csswg.org/drafts/diff/a8ffa9d7d989/css-2015/Overview.bs ? 15:00:59 Florian: The word might not be great, but if unfinished products are exposed finding a term to cover that, sure. The wording in gregwhitworth mail is too vauge, saying that authors should only be allowed to experiment with those. What does that mean? Is that what we've been doing and users are a part of the experiment? 15:01:58 gregwhitworth: So let's say we have a feature that we think is great. We do a prefix, it's behind the flag, but we give you a key and it lets us turn it on for 10% of your users. That gives us live data and it doesn't handcuff us for years. 15:02:01 s/basically agree with Florian/basically agree with Florian's intent/ 15:02:17 s/cshouldn't/shouldn't say/ 15:02:38 s/implementation policy as fact/implementation policy as the best practice/ 15:02:45 gregwhitworth: I don't think you should constrict it. I only stress this because we're trying to do responsible work. I don't think anyone disagrees with the goal, but we carry the burdon of you're not using the spec. If I want to opt-in to a solution that should be possible. 15:02:50 I think there's an important piece missing in greg's email. Things that are shipped should also come along with the ability for others to implement them, which includes specifications that are good enough for other implementors for implement from. 15:02:54 s/I tallows/It allows for/ 15:02:58 TabAtkins: If you have a good reason not to follow spec, you can. 15:03:46 s/It doesn't have you must haves.// 15:03:48 fantasai: We have two problems with prefixing. 1 is if you don't support that prefix prop and the author assumes everybody is webkit, the site breaks. second is that we lock people in because it's on production websites that aren't updating. 15:04:29 ed_work_ has joined #css 15:04:32 gregwhitworth: The example I gave is contract based...it's something we spitballed in TPAC. WE won't have a one size fits all solution. Instead of constraining it, we should be more open. Have a note saying please don't prefix. 15:05:01 ojan: What you're both saying is shipping vendor prefixes ends up shipping a feature. If the CSS spec should be weighing in on that is a sep question. 15:05:20 Florian: People starrted shipping prefixes because we said that the previous suggestion was bad. 15:05:31 gregwhitworth: So remove the prefix suggestion 15:06:08 dbaron: I wrote this in IRC a few minutes ago, but I think it's important that if you do ship something you provide what's nec to let others ship that too. In some cases that's a spec that you bring to the WG to say here's the thing we shipped. 15:06:18 gregwhitworth: I'm not seeing how my statement disagrees. 15:06:28 dbaron: It doesn't, it's just something that should also be said. 15:06:32 gregwhitworth: Okay, I agree. 15:06:53 Florian: And if you ship something with your name on it, we all feel back when we have to impl prop that have the word webkit in it. 15:07:19 gregwhitworth: I think we agree, I'm just saying don't constrain as much as these. You say release vehicle and I can't guar that there will be. 15:07:46 fantasai: We don't want to release things that are unstable and non-standard for production use and we don't want to relsease it in a general way until it's stable. 15:07:48 s/feel back/feel bad/ 15:08:05 fantasai: So maybe the wording change is "should not be released for production use" 15:08:25 gregwhitworth: current-color is an example of where we'd violate the spec but it worked in our case. 15:08:33 fantasai: This is for use on the web, that's the key here. 15:09:32 Florian: That's a distinction we're trying to do. Yes, CSS is also used on not-web and it's alos in that case useful to have some guidelines indicating the best way to do this. If you're going to do something not exposed to the web and you release something, you might be dumb. Prefixes are great in a non-web space. 15:09:55 Florian: Things not built for web content would be things that are good not to be able to be used on the web. Maybe later you want that on purpose. 15:10:05 Florian: Trying to phrase around web and non-web is difficult. 15:10:22 SteveZ: I don't understand the web distinction. If i'm writing tutorials I can put anything on the web. 15:10:42 fantasai: What we mean is for use in and enviroment where you'll be interacting with other CSS applications. 15:10:48 TabAtkins: We mean in a browser 15:10:52 fantasai: Not just that. 15:10:59 s/interacting/interoperating/ 15:11:04 s/applications/implementations/ 15:11:13 Florian: So if you add a CSS prop for specifically Firefox's UI, it's not from a HTTP server. 15:11:32 SteveZ: So when MS word started putting out it's stuff, it added prop for use in word, but they could be in the web. 15:11:43 TabAtkins: But that's when you choose HTML. 15:11:50 Florian: That's exposing to the web. 15:12:10 SteveZ: You're dealing with an impossible situation. It takes years to standardize. 15:12:19 TabAtkins: If it's not standardized you can't use it. 15:13:21 SteveZ: I don't see the disnction. I want to put everything I'm doing on the web. I agree about not polluting hte namespace, but you're a level beyond. I understand the webkit prefix policies. I also support that you ought to come in with a spec if you think you could standardize. It's unrealistic for a vendor to wait to have something stanardized. 15:13:34 TabAtkins: Then you're not publishing to the web. 15:14:14 gregwhitworth: It sounds like you want 3 hthings. If you want to pub something propriatary, bring it to us, if the group says that's stupid and we have business reasons to, we tried. 15:14:22 Florian: The wording doesn't constrain you from that. 15:14:43 hober: So he's saying he'll ship things anyone. If he does do it unprefixed. 15:14:54 Florian: If you can't standardize, don't prefix. 15:15:16 gregwhitworth: It sounds like being a good web citizen. So just try and put it on standard track and go from there. 15:15:28 fantasai: I changed ot to rec for best practices. 15:15:37 gregwhitworth: You changed the title? 15:15:45 "To avoid clashes with future stable CSS features, the CSSWG recommends the following best practices for the implementation of unstable features and proprietary extensions to CSS. " 15:15:49 fantasai: The first sentence. That's the only place policy appeared. 15:16:15 fantasai: I only fied the first paragraph 15:16:35 Florian: As for generally replacing the content for something more general is okay, but I don't want to say be reasonable please. 15:16:44 s/fied/fixed 15:16:58 gregwhitworth: I want to have prefixes are bad. 15:17:28 Florian: If you're writing UI specific that won't be sent to the web, do use prefixes. That's useful because they won't clash with anything and won't render on the web. 15:17:46 gregwhitworth: It feels like we've talked about it, don't want prefixes, so that's what this should say. 15:17:59 gregwhitworth: Also, we want it but we can't hold anyone accountable, so why write it? 15:18:24 darktears has joined #css 15:18:48 fantasai: We want to express a lot of things to people like don't impl something in FPWD and never make any changes. We do that because we want people to have better ideas and to help us improve before anything ships. It's a nightmare for authors to have all these different stages. 15:19:59 Rossen: You're implying something targetable by content. If it's something like UA flags, all the behavior you just explained is implementable. I would argue early impl are very useful to drive spec and clarify hurdles. What you're implying is that the holdback mech that was prefixes sucks. No one has aregued that using prefixes as holdbacks sucks. Flags or experimental features are better and we're starting to use them. 15:20:51 Rossen: Whether or not, gregwhitworth 3rd point, during the early phases of dev and playing witht hte feature we also want to collect user feedback. There are features that allow lighting up of those for random users. That's different and an experimental way of using holdback without exposing to everyone. 15:21:09 TabAtkins: We agree, we should have something like that. But in the meantime we know prefixes are a terrible way of doing this. 15:21:28 Florian: But we agree they're terrible, but the sentence we prop you didn't like. 15:21:39 fantasai: We all fundimentally agree of what we're trying to do. 15:22:02 hober: People think gregwhitworth wording is underconstrained, the current is thought overconstrained. Let's go away and make edits and come back. 15:22:37 Florian: Yes, but not having a wording means the curent snapshot is 5 years old. Should we say the old policy is bad and please hold on a new one. 15:22:51 fantasai: I think those of us interested should wordsmith this and come back to the group. 15:22:57 Florian: The current wording was from this. 15:23:03 fantasai: That was five years ago. 15:23:11 Florian: So, let's do that. 15:23:12 kwkbtr has left #css 15:23:21 fantasai: We had flags in the five years ago. 15:23:42 2012 15:23:47 2012 15:23:51 fantasai: We were intending for flags to be the way forward, but if we failed to do that we failed to do that. 15:23:53 http://www.w3.org/blog/CSS/2012/08/30/resolutions-53/ 15:24:03 weinig has joined #css 15:24:48 fantasai: We didn't fully resolve because we hadn't worked out wording yet. We're working on translation right now. I get the sense we agree what we're trying to do so we should wordsmith it and make sure we get what's in all our heads. If we find a real difference of opinion we should come back to the group. 15:25:19 SteveZ: I think I now understand why I obj to the use of the web. You're telling me it's okay to use prefixes for features used for non-interop features. 15:25:49 Florian: I'm not sure. There has been an ex of apple adding something to iphone and telling people to make websites with it, but then they say they don't intend it to be used elsewhere. 15:26:02 Florian: I'm not trying to exclude these. 15:26:08 s/for non-interop features/for implementations not intended to interoperate/ 15:26:24 SteveZ: The web is a mythical thing. I think the wording you have will be misinterp by everyone. It didn't suggest to me what we're trying to include. 15:26:32 Florian: You can join the convo when we fix that. 15:26:49 plinss: WE should exclude content on public websites using prefixes. 15:26:54 tantek: It should be HTP 15:27:04 plinss: But there's intranet. 15:27:11 tantek: I'm saying that's the bar. 15:27:21 gregwhitworth: I think we're trying to define the web. 15:27:31 fantasai: I'd we're serving it over HTP. 15:28:08 plinss: If HP makes a propriaty server for a client that can browser the web, but it can also suck down these hp things, who gives? It's walled off to yourself and not exposed. 15:28:09 HTTP 15:28:16 s/HTP/HTTP 15:28:23 Florian: This is hard to wordsmith, but it's meant to be the web. 15:28:35 plinss: If it's somehwere people can get ot it shouldn't be using prefixed. 15:28:48 SteveZ: I don't see why you can't have a propriatry content 15:28:58 plinss: Then you have the iphone web and the kindle web. 15:29:02 BogdanBrinza_css has joined #css 15:29:20 SteveZ: What's bothering me is this body because a gateway for what people can do and we don't move fast enough. 15:29:32 Bert: This is for a small part of the web. Just CSS. 15:29:54 A pretty essential part 15:29:59 Bert: You can make your own format, MyCustomizedCSS, and do whatever you want with that 15:30:02 SteveZ: When we get to the houdini meeting it gets worse, I don't know what you do. 15:30:19 plinss: If you expect the prop to work you ship the code along witht he prop and that can run one anyone's browser. 15:30:30 SteveZ: There's still the standardization and namespace polution issue. 15:30:39 CSS is only for online manner? How about for offline situation? (if it's not the point, sorry) 15:30:46 plinss: Houdini isn't the way to make a new prop, it's a new custom property. 15:30:52 SteveZ: How do I know? 15:30:53 ChrisLilley has joined #css 15:31:04 plinss: Prefix. That one prefix we've disignated for that process. 15:31:26 plinss: So you guys will wordsmith and come back? 15:31:30 Florian: We'll try. 15:31:44 tantek: Should we doc current objections? 15:31:48 Steve's phrase, something like "intended for an environment with multiple interoperable implementations", captures our target, I think. 15:31:55 Florian: That's going to take too long. We'll do it over beer. 15:32:18 esprehn: Can we talk about this in terms of population size instead of prefixing? If you ship it to enough people that other people have to impl too. 15:32:38 fantasai: If you're intending to send this page to an enviroment where there's multiple interop, you shouldn't prefix. 15:32:46 dbaron: I don't think number of people isn't the criteria. 15:32:52 gregwhitworth: I think he means impact. 15:33:05 tantek: The current text talks about preventing accental lock-in 15:33:28 hober: I don't think it's the place of the WG to go too much into how you determine lock-in. 15:33:35 tantek: I don't know how you improve the wording right now. 15:33:42 fantasai: We just need to improve the first sentence. 15:33:50 tantek: It doesn't sound like we're that far. 15:34:16 plinss: Are we done on this? 15:34:26 fantasai: For now. I think we should resolve by the end of the meeting. 15:34:35 tantek: So you'll come back by the end of the meeting. 15:34:38 fantasai: Yes. 15:35:30 Topic: @apply rule 15:36:29 TabAtkins: So I just sent the thing and haven't e-mailed the WG, but it's a tiny spec. 15:36:48 TabAtkins: polimer and post-css have used variables in an interesting way to port chunks of style. 15:36:55 [shows example 1] 15:37:04 TabAtkins: That is totally valid. 15:37:38 TabAtkins: Polimer has things like the apply rule that lets you refer to this and inlines them. This seems like a fine application and there's reasons to have reusable styles in a variable. 15:37:54 TabAtkins: These seems like a nice easy application of custom prop. That shouldn't be too hard to work with. 15:38:01 dbaron: It seems annoyingly cyclic 15:38:23 TabAtkins: No more so than var. There is an issue where if you define that property in there it would be cyclic. 15:38:39 dbaron: I don't see how they do this with pre-processing. 15:38:52 TabAtkins: It's not full fidelity. Maybe they pack it into JS. 15:38:58 TabAtkins: This is the entire example. 15:39:01 dbaron: It seems nice. 15:39:19 TabAtkins: We do want to make sure we deal with setting variables in the theme used by @apply. 15:39:24 for anyone else who can't see the screen: http://tabatkins.github.io/specs/css-apply-rule/ 15:40:16 SimonSapin: In variables in custom prop you have a declaration that contains var. You don't pass it yet. It's only when you do all the variables that you pass it. You have integration of the property and that's why you need the cascade. For here, for @apply rule you don't know what prop make sense. In differnet places in the tree it could have different rules 15:40:37 TabAtkins: You can't resolve until computed value time and you have multiple instances. 15:41:13 dbaron: This would require us to do the work we decided to avoid doing in variables by taking the worst solution in cascading. 15:41:16 TabAtkins: Where we did the default fallback rather than cascading fallback. 15:41:23 s/polimer/Polymer/ 15:41:26 s/worst/worse/ 15:41:30 TabAtkins: Yeah. We did decide that for the var function. That may have killed this. 15:41:43 shane: Maybe there's a default fallback you can do that works. 15:41:59 TabAtkins: Thank you for bringing that up. We'll see if there's anything you can do that's reasonable. 15:42:09 shane: If we can make this work you said it looked interesting 15:42:25 dbaron: How important is it to use cascading variables rather than system. 15:42:31 s/system/global variables/ 15:42:39 esprehn: Cascading variables seems counterintutive. 15:42:49 TabAtkins: We have it so you can override the them for some things. 15:43:22 TabAtkins: Like that you can do with variables where you could say inside a toolbar it's red in error state and this packages it up nicely. 15:43:40 shane: One of the uses that Polymer adopted it's just like custom prop you inherit down. 15:43:43 ^TabAtkins shows example with --tolbar-title-theme, which is set to one set of rules on :root, and differently on .warning 15:44:21 TabAtkins: That's why it's important to use with cascade. It's uing variables for theming and that's cumbersome with variables. This lets you package them up in a way that could obviate how you do something like shadow styling. 15:44:31 esprehn: Can I use a var in @apply? 15:44:33 skk` has joined #css 15:45:07 TabAtkins: No. There's nothing nievely preventing that. It has enough context, but it might involke circularity. This is an early bound variable, it takes the value theme from the root element. 15:45:16 esprehn: So you don't have to remix the variables. 15:45:24 TabAtkins: It's just one big custom property. 15:45:29 TabAtkins: Okay. 15:45:35 Florian: Try and fix it, it looks useful. 15:45:59 TabAtkins: Copying hte defaulting of current variables might work. We need to have something where you need to maintain a shape for a style. 15:46:08 Florian: Some kind of typing where each rule has the same set? 15:46:12 TabAtkins: Yes. 15:46:18 Florian: That seems strange and restraining. 15:46:23 TabAtkins: It might be nonsense too. 15:46:42 TabAtkins: Right now we can take the custom prop, remove the opening and closing brakcets, and span it out. 15:47:00 SimonSapin: If you [missed] 15:47:20 TabAtkins: That might be. Maybe we can do that. It lets you do the theming. You're namespacing variables in a more compact way. 15:47:33 TabAtkins: I know that will work, but let's see if we can make less space work. 15:47:41 shane: If that will work can you specify all. 15:47:55 TabAtkins: If your custom prop isn't valid, you'd lose all of them. You'd get unset for everything. 15:48:18 SimonSapin: So don't forget your speciificity. 15:48:22 Chris_Lilley has joined #css 15:48:33 shane: Wouldn't be ba able to add another toolbar? 15:48:40 TabAtkins: If your specificity is okay, yes. 15:49:32 TabAtkins: Another issue, here in the CSSOM. Modifying CSS styles OM to allow @rules, we can't just do what I said because CSS grouping rule. UNless we decide that it doesn't matter and it's at the end, which I don't like. We need a different way of representing it. 15:49:42 Florian: And the declaration is aligning? 15:50:10 TabAtkins: Yes. We need a new way of defining. It's pretty trivial, but it's something we'd have to write. 15:50:22 TabAtkins: It's new, it would be a CSS prop interface with a name and a property. 15:50:30 SimonSapin: For the CSS style interface? 15:50:51 TabAtkins: It doesn't expose anything for child rules so we can invent what we want. CSS style interface gives a bunch of camelface prop. 15:50:55 SimonSapin: Can you interate? 15:51:11 TabAtkins: I don't know...no. You shouldn't be able to because we don't define an interator. 15:51:32 SimonSapin: It's not a real iterator, but we should have an item. Will @apply rules show up there? 15:51:38 I think iterate. 15:52:09 TabAtkins: The ones it's applying to ren't obvious until you apply. The @apply rule...I would say no. There's no reason to expose them in that interface. You do it off of .cssrules or something sim names. 15:52:37 BogdanBrinza has joined #css 15:52:39 fantasai has joined #css 15:52:54 SimonSapin: For get compute and all that, for the element side, don't you only get the declarations that are specified? 15:53:06 skk_ has joined #css 15:53:10 darktears has joined #css 15:53:16 TabAtkins: Okay. What as? I guess just prop names. So there's DOM string there. WE could maybe expose the @apply there. 15:53:28 leaverou: If you use variables in these props are they defined in the scope they're in? 15:53:46 krijnhoetmerbot has joined #css 15:53:46 TabAtkins: They're just custom properties. We in the future want late binding vars. 15:54:00 paul___irish has joined #css 15:54:08 leaverou: It would be good if the option is resolved at the time they're used. This would be like mixes and would help authors use mixes. 15:54:19 TabAtkins: I agree, I'm just going for the simpliest form now. 15:54:31 s/mixes/mixins/ 15:54:33 s/mixes/mixins/ 15:54:53 TabAtkins: Okay, sounds pretty good. We know some issues. Assuming we can resolve these issues are people interested? 15:54:58 leaverou: Can this be nested? 15:55:00 TabAtkins: Yeah. 15:55:12 leaverou: And apply rule inside the declaration of the prop. 15:55:19 TabAtkins: You can use the var itself. 15:55:29 Florian: That will insert extra. 15:55:39 TabAtkins: I haven't spec it, but that's the direction. 15:55:57 Florian: If you have an @aplly inside the custom prop, it doesn't seem poss to make it work. 15:56:08 dbaron: On the inner you'll get the value of the variable it's getting applied to. 15:56:22 shane: So maybe applying late would be better. 15:56:28 ... rather than the value where it was declared 15:56:31 Florian: You need to define it now to make it clear. 15:56:39 s/leaverou: If you use variables in these props are they defined in the scope they're in?/leaverou: If you use variables in these property sets are they resolved from the scope they’re defined in or the scope they’re used in?/ 15:56:48 TabAtkins: My current def is bracket wrapped block of prop, which obviously isn't a real set. 15:56:57 fantasai: When is variables getting pub as CR? 15:57:11 dbaron: I thought it was. Did we just resolve to publish and not do it? 15:57:23 fantasai: Let's put this in a pipeline please. 15:57:29 TabAtkins: I'll talk with Chris. 15:57:37 dbaron: We shipped it on the basis of the resolution. 15:57:41 fantasai: I think that's okay. 15:57:48 TabAtkins: I'm not changing anything about variables. 15:58:04 plinss: You can have multi @apply and they don't interact? 15:58:08 s/It would be good if the option is resolved at the time they're used. This would be like mixes and would help authors use mixes./It would be good if variables are resolved where they are used. @apply is already trying to give authors mixins, and this would even give them parameterized mixins/ 15:58:13 TabAtkins: They cascade normally. 15:58:20 TabAtkins: I should add an example of that. 15:58:31 zcorpan: Can you use @apply in other @rules? 15:58:34 TabAtkins: No. 15:58:46 dbaron: I feel lik eyou have previous prop that did some of this? 15:59:05 TabAtkins: A long time ago I had an @mixin that was someone similar, but a global rules. 15:59:08 s/And apply rule inside the declaration of the prop./I mean @apply rules inside the property set/ 15:59:21 TabAtkins: You couldn't reset based on certain parts of your tree. 15:59:36 shane: It's also, the same thing happened with global variables that people didn't like. 15:59:49 dbaron: I think we have recognized that some of these things need to be global. 16:00:03 TabAtkins: That's what custom MQ are, really. There's use cases for things like that. 16:00:19 myakura has joined #css 16:00:34 fantasai: You may also consider file-scope stuff. Like selector variables might be a good case for that. Like the chance of you using the same selector variable is different. 16:00:43 TabAtkins: It's the same as style nesting. 16:00:58 fantasai: There's cases like :matches blah blah and you want to use that as the child. 16:01:01 TabAtkins: You can do that. 16:01:11 fantasai: As a subject of the selector. 16:01:13 TabAtkins: Yes. 16:01:27 fantasai: I think that requires you to have your styles in a particular configuation. 16:01:45 fantasai: I might want to have all my sidebars together and not organize it by what I'm styling. 16:02:00 TabAtkins: That's a good point. 16:02:17 btw authors are pretty excited about the idea https://twitter.com/leaverou/status/636202346259836928 (15 RTs and 9 faves in a just few minutes) 16:02:22 TabAtkins: Right now I'm doing global variables in a lot of context specific ways. 16:02:27 BogdanBrinza has joined #css 16:02:35 s/all my sidebars together/all my sidebar rules together and all my article rules together and all my front page rules together/ 16:02:38 BogdanBrinza has left #css 16:02:41 TabAtkins: Okay, I'll bring this up to the WG again after fixing these issues. 16:02:44 s/what I'm/which element I'm/ 16:02:52 plinss: Okay, we're adjorned 16:03:27 s/adjorned/adjourned/ 16:04:30 zcorpan has joined #css 16:05:34 zcorpan has joined #css 16:07:37 Florian has joined #css 16:09:09 Florian has joined #css 16:25:11 weinig has joined #css 16:26:21 Florian has joined #css 16:27:08 tantek has joined #css 16:27:45 Florian has joined #css 16:31:53 skk has joined #css 16:34:43 weinig has joined #css 16:45:19 skk_ has joined #css 16:55:07 antonp1 has joined #css 16:59:49 renoirb has joined #css 17:30:19 Zakim has left #css 17:30:46 tantek has joined #css 17:46:56 myles has joined #css 18:29:13 nvdbleek has joined #css 18:47:06 zcorpan has joined #css 19:10:43 nvdbleek has joined #css 19:11:25 myakura has joined #css 19:16:35 nvdbleek has joined #css 19:29:24 johanneswilm has joined #css 19:33:25 skk has joined #css 19:38:21 Florian has joined #css 19:59:30 darktears has joined #css 20:00:40 Florian has joined #css 20:04:56 Florian_ has joined #css 20:13:40 Florian has joined #css 20:23:41 Florian has joined #css 20:33:40 Florian has joined #css 20:34:16 Florian_ has joined #css 21:11:51 dauwhe has joined #css 21:11:59 tantek has joined #css 21:24:31 Florian has joined #css 21:26:16 tantek has joined #css 21:26:19 Florian has joined #css 21:29:47 Florian_ has joined #css 21:34:21 tkonno has joined #css 21:34:41 dbaron has joined #css 21:42:09 dauwhe_ has joined #css 21:45:45 zcorpan has joined #css 22:02:52 ed_work_ has joined #css 22:24:03 dauwhe has joined #css 22:26:17 ed_work_ has joined #css 23:50:55 jdaggett has joined #css