15:59:59 RRSAgent has joined #css 15:59:59 logging to http://www.w3.org/2014/06/25-css-irc 16:00:08 It feels lonely without him. Who is going to tell me to use commas? 16:00:14 lol 16:00:14 krit: much sad 16:00:38 bkardell_ has joined #css 16:00:53 zakim, who's here? 16:00:55 sorry, glenn, I don't know what conference this is 16:00:55 On IRC I see bkardell_, RRSAgent, Zakim, glenn, gregwhitworth, lmclister, dael, abinader, adenilson, dauwhe, dbaron, plh, darktears, Liam, stryx`, dholbert, logbot, kangil, 16:00:55 ... pdurbin, krijnhoetmer, fantasai, plinss, astearns_, shepazu, gsnedders, CSSWG_LogBot, Bert, hober, birtles, abucur__, sylvaing__, amtiskaw, mihnea___, paul___irish, ed, 16:00:56 ... _martinwolf, SimonSapin, sylvaing, shans, leaverou_away, projector, alexmog, renoirb, Hixie, dfreedm, slightlyoff, cbiesinger__, achicu____, cabanier, jacobg____, TabAtkins, 16:00:56 ... Teoli__, lmclister___ 16:01:02 Zakim, this is style 16:01:02 ok, fantasai; that matches Style_CSS FP()12:00PM 16:01:05 zakim, this is style 16:01:05 plinss, this was already Style_CSS FP()12:00PM 16:01:05 zakim, this is 78953 16:01:06 ok, plinss; that matches Style_CSS FP()12:00PM 16:01:06 glenn, this was already Style_CSS FP()12:00PM 16:01:06 ok, glenn; that matches Style_CSS FP()12:00PM 16:01:07 smfr has joined #css 16:01:21 \o/ 16:01:38 + +1.206.675.aaaa 16:01:41 +SteveZ 16:01:44 + +1.281.305.aabb 16:01:46 zakim, aaaa is me 16:01:46 +astearns_; got it 16:01:49 Zakim, who is on the call? 16:01:50 On the phone I see dael, [IPcaller], glenn, ??P26, [Microsoft], ??P30, BrianKardell, astearns_, SteveZ, +1.281.305.aabb 16:01:50 +dauwhe 16:01:55 koji has joined #css 16:01:57 zakim, aabb is me 16:01:57 +TabAtkins; got it 16:01:59 zakim, Microsoft has me 16:01:59 +gregwhitworth; got it 16:02:01 Zakim, IPcaller is me 16:02:01 +krit; got it 16:02:06 +smfr 16:02:08 +plinss 16:02:17 MaRakow has joined #CSS 16:02:26 tantek has joined #css 16:02:28 SteveZ has joined #css 16:02:32 +??P3 16:02:56 +dbaron 16:03:06 -??P26 16:03:26 +cabanier 16:03:52 +??P48 16:03:58 + +1.415.231.aacc 16:04:01 Zakim, ??P48 is me 16:04:01 +SimonSapin; got it 16:04:03 +Plh 16:04:14 zakim, +1.415.231.aacc is me 16:04:14 +koji; got it 16:04:28 +fantasai 16:04:45 Is plh-mobile like the Batmobile? 16:05:06 I wish :) 16:05:20 +hober 16:05:29 plinss: Let's get started 16:05:32 plinss: Anything to add? 16:05:42 plh: I can do a charter update 16:05:44 plinss: Okay 16:06:06 plh: I'veg ot allt he nes. stuff. I expect the charter to the CRs and approved no later than Fri. We're all good on that front 16:06:15 plinss: Cool. Be nice to be under a charter again. 16:06:23 Topic: Upcoming F2F location 16:06:30 plinss: we were looking in Zurich? 16:06:31 + +1.206.992.aadd 16:06:43 Zakim, aadd is me 16:06:43 +MaRakow; got it 16:06:44 TabAtkins: I'm in a resturant. Can you hear me? 16:06:50 TabAtkins: I've not yet done so. Sorry. 16:06:52 plinss: ETA? 16:07:00 TabAtkins: Next week if we don't decide prior 16:07:17 +??P58 16:07:26 SteveZ: I assumed that we were set for Sophia/Anti so I have reservations for those dates and would obj. changing 16:07:33 plinss: Is thata non-refundable situation? 16:07:38 SteveZ: It is. 16:07:48 plinss: Anyo ther input, or should we commit? 16:07:50 +[IPcaller] 16:07:53 TabAtkins: I have no problem with that. 16:08:03 -fantasai 16:08:13 plh: I don't know if we have approval to host in Antib Is W3C hosting there? 16:08:17 SteveZ: That was the proposal 16:08:18 Zakim,[IPcaller] is fantasai 16:08:18 +fantasai; got it 16:08:44 plh: I won't obj, but I want people to realize we're not doing it in Zurich. I hope clilly and bert made sure we have the budget 16:08:57 plinss: clilly or bert are you there? Doesn't look like it. We need to do research 16:09:15 action plh to ping bert or clilly about budgeting for the Sept F2F 16:09:15 Created ACTION-633 - Ping bert or clilly about budgeting for the sept f2f [on Philippe Le Hégaret - due 2014-07-02]. 16:09:38 plh: FYI for those on the call the next extensible web is in Berlin on Sept 11. 16:09:44 plinss: There's something else in Berlin too 16:09:58 plh: 12th there's a CSS conf. and 13th there's another conf. 16:10:03 arybka has joined #css 16:10:11 Zakim, P58 is tantek 16:10:11 sorry, tantek, I do not recognize a party named 'P58' 16:10:14 SteveZ: If you fly on luftansa you can get to berlin easily from nice. 16:10:17 plh: Yes 16:10:22 zakim, ??P58 is tantek 16:10:22 +tantek; got it 16:10:25 Topic: CSS Masking to CR 16:10:27 http://www.w3.org/TR/css-masking-1/ 16:10:28 zakim, mute tantek 16:10:28 tantek should now be muted 16:10:41 krit: The LC period is over. I got a lot of positive feedback. 16:10:45 http://dev.w3.org/fxtf/css-masking-1/issues-lc-2014.html 16:10:49 As I said before, I and other Mozilla folks probably won't be able to make the week of Sept 8-12 16:10:59 although I still don't know for sure. 16:11:06 krit: I got one feedback with one issue so there's a typo with bordor-box initial value. I changed it to border. 16:11:19 s/border/auto/ 16:11:21 right? 16:11:22 krit: Other than that there were no change requests, so I'd like to go to CR 16:11:29 plinss: Any objections? 16:11:42 TabAtkins: No 16:11:52 fantasai: I didn't review, but I can't object because of that. 16:12:03 RESOLVED: CSS Masking to CR 16:12:13 plinss: How are the test suites? I see 53. 16:12:41 krit: It's particular to SVG, but I'll upload from webkit. For the new parts we need mroe tests for coverage since they're not in browsers yet. 16:12:54 plinss: You'll prep the draft and ping clilly or bert? 16:12:56 krit: Yes. 16:13:03 Topic: Explaining
16:13:11 plinss: TabAtkins? 16:13:18 ChrisL has joined #css 16:13:31 (plh, was the september extensible web summit announced yet? I only find stuff about the one last April.) 16:13:38 TabAtkins: At the last F2F we discussed def. the style of
using display-box: content and other prop 16:13:51 TabAtkins: Since there in the whatwg bug dbaron objected due to performance. 16:14:05 Simon, not yet, it will be announced before the end of the week. I'm working with Dan on this. 16:14:10 TabAtkins: That's fine, but I want to define it some way. A way would be to create anew display value for new lines. 16:14:22 thanks plh 16:14:29 TabAtkins: Does dbaron thinks the performance concern is large enough to presue a new method? 16:14:31 +ChrisL 16:14:44 dbaron: I don't know off the top of my head Maybe we can special case the one thing. 16:15:05 dbaron: If sommething is display-box: content and has this thing inside we don't take the normal code path,, but do this other thing. 16:15:16 TabAtkins: I would pref not odd speical cases if poss 16:15:20 dbaron: Special is in code 16:15:28 I would prefer not having had a br element, but there we are 16:15:38 TabAtkins: If our rec. style for it requires wierd special cases, we should address it more directly 16:16:06 fantasai: I don't agree. I think if we have a special code path that construct a frame with eq. behaviour but if other prop are different you use the normal code path, that's fine. 16:16:29 fantasai: As long as to the author it behaves in a consistant way that's good. If we create a dispaly value for new lines that's harder to understand for author 16:16:40 fantasai: IN addition you have various code paths you have to write in the engine 16:17:04 fantasai: If we're doing this for performance improvements, creating a hole new feature seems overkill and extra work for testing and impl. and esp. author 16:17:07 agree with fantasai. This is a legacy special case that we can't get rid of 16:17:08 fantasai: I think it's fine. 16:17:29 fantasai: We do something wierd and special because this is common, elsewise we do the normal path. 16:18:12 TabAtkins: While I would agree in the past, as more impl experience, I think having these special paths slows things down 16:18:20 fantasai: You'd need one anyway for a new method 16:18:41 TabAtkins: But specifically if you have this style as this way do something magic, that's different. 16:19:02 s/different/different from having a special display value/ 16:19:26 Is the issue one of code path complexity and therefore maintenance? 16:19:58 TabAtkins: Having the special case path where if something has part styles treat it different ends up being annoying for the code and slows everything down. Removing these helps performance. I'd pref. if we do weird special, I'd rather it being it's own case. 16:20:16 TabAtkins: I don't like where if you make a small change it goes to hell because there's a specific optimized path 16:20:24 yes that ^^^ 16:20:29 very bad for web authors 16:20:31 Agreed 16:20:33 TabAtkins: What were asking is if you do this in this particular way it's fast, but elsewise it goes slow 16:20:39 /* Don't change this code, it will
*/ 16:20:40 fantasai: How many people will style
? 16:20:43 zakim, unmute tantek 16:20:43 tantek should no longer be muted 16:20:58 How much slower will this BR form be? 16:20:59 fantasai: I don't think it is worth a new feature that we have to work on and create a generic impl. 16:21:18 ??: Lots of style sheets do style with universal selector. There's lots out there and we don't know it. 16:21:29 dbaron: I think that lots of people will style is an arguement for not worrying 16:21:30 s/??/tantek 16:21:32 s/??/tantek 16:21:42 TabAtkins: You mean we should make
special magic? 16:21:48 dbaron: Yes. 16:22:06 TabAtkins: I don't like it,b ut I like it better than a weird special case. 16:22:14 plinss: Sounds like it's a special case one way or the other. 16:22:24 fantasai: Maybe your impl doesn't need that optimization 16:22:38 TabAtkins: We almost certainly do. It's it's a prob for Mozilla, it's likely for us. 16:22:46 dbaron: I don't know it is, but I suspec it will be slower. 16:22:59 TabAtkins: That's our expectationf or display-box. It'll be useful but slower 16:23:09 plinss: Sounds like this goes back on the shelf? 16:23:15 zakim, mute tantek 16:23:15 tantek was already muted, tantek 16:23:45 tantek: If we were to impl with display-content it would have perf implementaiton. For us now
is line-layout without more drama. Anything more will add something to perf. 16:23:54 s/tantek/rossen 16:24:15 fantasai: Would it be possible to define as rendered as CSS rule? Like non-overrideable? Tht was it's defined as how it's supposed to behave, but it's defined. 16:24:33 rossen: I think people mentioned that they do style
a bit and i've seen evidence of it. 16:24:42 zakim, who is noisy? 16:24:47 s/I think that lots of people will style/I think that authors not changing it much/ 16:24:49 fantasai: Would it be possible to define
as rendered equivalent to this CSS rule, except impl are allowed to make it non-overrideable 16:24:52 astearns_, listening for 10 seconds I heard sound from the following: ??P3 (19%), plinss (4%) 16:24:52 rossen: We'd take a compat hit with breaking
styling and I'm not a fan of that. 16:25:27 rossen: If we end up breaking the content it'll likely be old legacy content and not likely to change. II'm not sure that's ag ood trade-off 16:25:47 s/arguement/argument/ 16:25:48 plinss: My concern is we explicitly define it, it makes it harder to come up with a better approach later. 16:26:00 fantasai^: Then browsers can keep their current implementations, but at least the rendering is defined. 16:26:11 TabAtkins: Another problem is that we're assuming we wont' have anything in the future that would over-ride that style. I don't think it's a stable solution overall 16:26:12 s/worrying/worrying about
/ 16:26:28 plinss: I think we need to let this percolate until we come up with something better. 16:26:46 fantasai: I thought the conclusion was we can't come up with something better because it involves makingt his a style-able box. 16:27:05 plinss: I'm saying one day someone might come up with another solution. I'm not willing to declare it forever unsolveable 16:27:10 yes that ^^^ 16:27:16 Topic: Flexbox percentage heights in column direction 16:27:39 TabAtkins: There is some disagreement between browsers about when a length is definate or indefenetant when it's the size of a flex-item 16:27:54 TabAtkins: Chrome says indefiniate unless there's a defined flex-basis 16:27:59 my call just dropped 16:28:27 TabAtkins: Other browsres have different rules that I havent' been able to intuit. I'm not sure when they decide they're definite for purposes of inhereting to their children 16:28:51 TabAtkins: The things we defined as definite would say that things are definite when they have a defined flex-basis, but I'm not sure 16:29:05 fantasai: Even with a definite flex-basis, they're flexiable so should we be defining? 16:29:39 TabAtkins: With a definite flex-basis and they're flexible, it's at least theroritically okay to resolve perfentages. Firefox does. Chrome calls it indefinite 16:30:14 rossen: Question, what is the test case? You have a flex box will column directin and a flex item that's auto-suze and an item inside that is percent height? 16:30:17 Alright, I'm back 16:30:40 s/will/with/ 16:30:50 TabAtkins: There's varitions. The flex item is always flexible but the basis is auto, % or fixed size. The three impl are different on every one of those cases. 16:30:56 TabAtkins: I don't know the correct answer. 16:31:14 TabAtkins: The posting from gregwhitworth aren't loading for me. I'm having troble giving a sensible answer. 16:31:40 fantasai: If you resolve % against any of these things, you'd resolve against a hypotetical size that may or may not be the size of the flex item? 16:31:42 TabAtkins: Why? 16:31:46 fantasai: It's flexible 16:31:59 TabAtkins: When child % is resolved against flex, it's after flex sizing. 16:32:04 rossen: Thta's our code. 16:32:13 TabAtkins: You run flex, lay out children, resolve % 16:32:20 rossen: I think we do the same for grid 16:32:52 rossen: This is the same arguement that was being made where with componants it is nice to resolve at the top and let grid take care of the inner layers and outer shape 16:32:55 smfr_ has joined #css 16:33:05 rossen: I think we resolved on this issue back in Leon TPAC. 16:33:18 rossen: We discussed allowing % inside auto-size 16:33:38 TabAtkins: You're thinking of the cross demension where what we have is mostly right and in the spec already. This is the main demension 16:34:01 dbaron: For what it's worth dholbert prefer IE where we treat it as definitie if ti's definite at the time that matters 16:34:13 TabAtkins: I don't know if that applies to flex items with a auto base size. 16:34:28 s/Leon/Lyon/ 16:34:45 TabAtkins: That should be fine for the other cases when you have a length, flex, and then lay out your children. Auto you count your children and then lay out and I'm not surei f that's definite 16:35:15 rossen: Did we resolve that flex-basis is a use time value and defined as used not computed 16:35:16 s/prefer IE/prefers the Firefox\/IE behavior/ 16:35:51 rossen: I think about a month ago we decided that flex-basis was a use value, not computed. It assumes that allt he flex items are already measured to their flexability and then we have a use size we can resolve % against 16:35:54 TabAtkins: Hmm. 16:35:59 TabAtkins: You may be right on that. 16:36:06 TabAtkins: Okay. I need to go and research that. 16:36:24 TabAtkins: I've been avoiding the thread, but I think I need ot load flex into my brain. 16:37:10 TabAtkins: Now that I have a grasp on the discussion, let's go back to the thread and sort out how our previous resolutions deal with this. I think I can be convinced Chrome is a bug with some or all of these. 16:37:14 rossen: I'm fine with that. 16:37:16 TabAtkins: Cool. 16:37:25 Tab, I don't think used vs. computed value of flex-basis is a relevant thing here 16:37:28 Topic: background-blend on the root element 16:37:42 TabAtkins: Is cabanier around? 16:38:22 cabanier: So it looks like there was feedback from Alan this morning. I'm not sure what's supposed to be happening, there's different Firefox and WebKit behaviour 16:38:43 cabanier: Firefox pulls up the background layer and draws. Webkit draws an external layer in white. 16:39:05 cabanier: now that we expect these layers to be in order, it's different. It's possible for others to work around it, but it's a bit wierd. 16:39:55 TabAtkins: I completely agree with your q on the thread. We should say the root element blends and then transposes. It's odd that the final background is white and that's an odd detail we shouldn't expose 16:40:05 dbaron: I don't think the final is white in iFrames. 16:40:18 cabanier: It seems it's only the root elements. There's something going on 16:40:18 s/iFrames/iframes, in some cases/ 16:40:25 TabAtkins: It may be an impl bug. 16:40:44 cabanier: Firefox sometimes draws differently. That's a bug. Should it be fixed in blending or color? 16:40:58 cabanier: We need to define that the root element is different. 16:41:06 krit: Does it apply to SVG as wel? 16:41:22 cabanier: I think it would apply there, I haven't tried it because there isn't blending in SVG 16:41:38 TabAtkins: If you're doing background blending in SVG you wouldn't sure white, yuo'd do transparent. 16:42:07 TabAtkins: Likely we want to do it in colors so that if we want anything that goes uses root it blends against hte transparent and untouchable background 16:42:23 TabAtkins: The backdrop color if untouchable and you can't do anything with it except map your page. 16:42:32 cabanier: I think that's the behaviour most would expect. 16:43:03 plinss: I think that's correct. I don't want to bake an opaque background into the platform. 16:43:16 cabanier: That CSS Colors needs to define this 16:43:30 TabAtkins: That whatever browsers do for the backdrop, the page maps against that. 16:43:35 TabAtkins: I'll wordsmith. 16:43:58 http://lists.w3.org/Archives/Public/www-style/2014Jun/0280.html 16:44:10 RESOLVED: Solve as Rik requests in http://lists.w3.org/Archives/Public/www-style/2014Jun/0280.html 16:44:12 Rossen_ has joined #css 16:44:17 s/maps/mattes/g 16:44:37 plinss: I think that's it. WE had Animations issues from sylvain, but he sent his regrets. 16:44:40 plinss: Anything else? 16:44:48 plinss: Talk to everyone next week 16:45:55 Zakim, are you here? 16:45:55 I don't understand your question, tantek. 16:46:15 turing test failed, zakim 16:46:23 he is here but he is not with us 16:46:32 lol so did I 16:47:08 Zakim, disconnect tantek 16:47:08 tantek is being disconnected 16:47:32 new Zakim feature for the NSA 16:47:46 "for transparency" 16:48:46 “War is peace. 16:48:46 Freedom is slavery. 16:48:46 Ignorance is strength.” 16:48:47 actually, it looks like zakim thinks there are two css meetings, one where everyone hung up, the other where everyone is still around: https://www.w3.org/1998/12/bridge/Zakim.html 16:49:42 omg I bet the alternate meeting was solved the break issue. Causing a bifurcation of the space time continuum 16:55:49 alright, bedtime! 18:38:47 glenn_ has joined #css 18:46:06 glenn has joined #css 19:26:07 dbaron has joined #css 19:27:56 dauwhe has joined #css 21:09:04 glenn_ has joined #css 22:45:05 cbiesinger__ has joined #css 22:46:09 mvujovic____ has joined #css 23:00:45 TabAtkins_ has joined #css 23:00:46 achicu_____ has joined #css 23:03:16 Teoli__ has joined #css 23:03:38 cabanier has joined #css 23:03:39 lmclister____ has joined #css 23:03:51 slightlyoff__ has joined #css 23:04:15 krit has joined #css 23:04:41 dfreedm__ has joined #css 23:05:40 jacobg____ has joined #css 23:10:14 achicu_____ has joined #css 23:10:16 jacobg_____ has joined #css