15:25:07 <RRSAgent> RRSAgent has joined #css
15:25:07 <RRSAgent> logging to http://www.w3.org/2014/04/23-css-irc
15:25:12 <glazou> Zakim, this will be Style
15:25:12 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 35 minutes
15:25:15 <glazou> RRSAgent, make logs public
15:29:34 <rhauck> rhauck has joined #css
15:35:28 <dbaron> dbaron has joined #css
15:44:31 <MaRakow> MaRakow has joined #CSS
15:50:49 <zcorpan> zcorpan has joined #css
15:53:39 <lmclister> lmclister has joined #css
15:54:47 <dael> dael has joined #css
15:55:26 <florian> florian has joined #css
15:56:09 <Zakim> Style_CSS FP()12:00PM has now started
15:56:15 <Zakim> +plinss
15:56:26 <Zakim> +dael
15:56:44 <dael> ScribeNick: dael
15:57:38 <SimonSapin> B
15:57:45 <SimonSapin> (sorry, typo)
15:58:00 <antonp> antonp has joined #css
15:58:30 <Zakim> +??P11
15:58:36 <Zakim> +??P2
15:58:36 <SimonSapin> Zakim, ??11 is me
15:58:37 <Zakim> sorry, SimonSapin, I do not recognize a party named '??11'
15:58:42 <glazou> Zakim, ??P2 is me
15:58:42 <Zakim> +glazou; got it
15:58:43 <SimonSapin> Zakim, ??P11 is me
15:58:43 <Zakim> +SimonSapin; got it
15:58:52 <Zakim> +[IPcaller]
15:58:56 <AH_Miller> AH_Miller has joined #CSS
15:59:18 <kawabata> kawabata has joined #css
16:00:48 <BradK> BradK has joined #CSS
16:00:57 <Zakim> +Stearns
16:01:10 <Zakim> +??P17
16:01:11 <Zakim> +??P21
16:01:22 <Zakim> +hober
16:01:24 <koji> koji has joined #css
16:01:47 <Zakim> +Bert
16:01:49 <glazou> http://www.tug.org/tugboat/tb27-2/tb87benatia.pdf
16:01:49 <Zakim> +MaRakow
16:01:55 <kawabata> zakim, ??P17 is kawabata
16:01:55 <Zakim> +kawabata; got it
16:02:26 <glazou> Zakim, who is noisy?
16:02:26 <BradK> I'm trying the ip phone, but I'm not sure which one is me. Maybe p21?
16:02:30 <gregwhitworth> gregwhitworth has joined #css
16:02:36 <glazou> BradK, yes
16:02:36 <Zakim> glazou, listening for 10 seconds I heard sound from the following: 11 (35%), ??P21 (34%)
16:02:41 <Zakim> +fantasai
16:02:47 <Zakim> +florian
16:02:57 <Zakim> + +999999aaaa
16:02:58 <BradK> Zakim, ?.p21 is me.
16:02:58 <Zakim> sorry, BradK, I do not recognize a party named '?.p21'
16:03:07 <glazou> Zakim, ??P21 is BradK
16:03:07 <Zakim> +BradK; got it
16:03:13 <antonp> Zakim, aaaa is me
16:03:13 <Zakim> +antonp; got it
16:03:18 <BradK> Thanks
16:03:20 <glazou> Zakim, who is noisy?
16:03:26 <Zakim> +TabAtkins
16:03:31 <Zakim> glazou, listening for 10 seconds I heard sound from the following: [IPcaller] (9%)
16:03:34 <jet> jet has joined #css
16:03:47 <TabAtkins> ...wat
16:03:48 <glazou> Zakim, who is noisy?
16:03:58 <Zakim> +dbaron
16:04:00 <Zakim> glazou, listening for 10 seconds I heard sound from the following: glazou (19%), [IPcaller] (47%), Stearns (5%), BradK (13%)
16:04:03 <BradK> Zakim mute me
16:04:15 <Zakim> +koji
16:04:15 <glazou> Zakim, mute BradK
16:04:16 <Zakim> BradK should now be muted
16:04:30 <Zakim> +[Microsoft]
16:04:36 <Zakim> -kawabata
16:04:43 <gregwhitworth> Zakim, Microsoft has me
16:04:43 <Zakim> +gregwhitworth; got it
16:04:54 <ChrisL> ChrisL has joined #css
16:04:58 <Zakim> +??P17
16:05:00 <glazou> Zakim, [IPcaller] has AH_Miller
16:05:00 <Zakim> +AH_Miller; got it
16:05:07 <glazou> BradK, no
16:05:07 <kawabata> zakim, ??P17 is kawabata
16:05:07 <Zakim> +kawabata; got it
16:05:11 <Zakim> +??P44
16:05:29 <zcorpan> Zakim, ??p44 is zcorpan
16:05:29 <Zakim> +zcorpan; got it
16:05:45 <dael> plinss: Let's get started
16:05:48 <Zakim> +ChrisL
16:05:49 <BradK> I just found my phones
16:05:49 <dael> plinss: Any additions?
16:06:10 <dael> fantasai: I'd like to ask about backgrounds and borders if anyone can help with author outreach
16:06:11 <BradK> I just found my phone' smite button anyway.
16:06:14 <dael> plinss: Go ahead
16:06:19 <BradK> Argh, mute button
16:06:29 <dael> plinss: Anything you want to say?
16:06:39 <dael> fantasai: We have a LC there's a couple of comments from MaRakow
16:06:55 <dael> fantasai: What' I'm hesitating is we haven't gotten comments from spread-radius change
16:06:59 <Zakim> +[Microsoft.a]
16:07:06 <dael> ...: To make it continuous from 0 to non-zeor
16:07:13 <Zakim> +glenn
16:07:24 <Rossen_> zkim, microsoft has me
16:07:26 <dael> ...: I'd like someone to help me write an article that helps explain it with pictures since from there prspective it's significant
16:07:29 <dael> ???: I can help
16:07:33 <Rossen_> zakim, microsoft has me
16:07:33 <Zakim> +Rossen_; got it
16:07:38 <dael> TabAtkins: We can write it on Thursday
16:07:50 <dael> s/???/TabAtkins
16:08:02 <dael> fantasai: Also grid layout is looking for review with algorythms
16:08:05 <Zakim> +SteveZ
16:08:13 <dael> plinss: There was a request for selectors non-element to FPWD
16:08:24 <dael> plinss: Any obj?
16:08:29 <plinss> http://dev.w3.org/csswg/selectors-nonelement/
16:08:32 <dael> glazou: Nope. I'm strongly in favor
16:08:37 <dael> plinss: Okay.
16:08:39 <ChrisL> no objection: got a link to ED?
16:08:48 <dael> RESOLVED: FPWD of Non-element Selectors
16:08:59 <dael> plinss: 1 req. I have to to add a level 1 to the title.
16:09:09 <dael> plinss: We lose track when specs don't advertise their level
16:09:19 <dael> fantasai: I feel like it's a piece of selectors which is at level 4 now
16:09:43 <dael> glazou: I'm glad to see this outside selectors b/c I don't think browsers will want to impl
16:09:55 <dael> ...: At least not in CSS engine. It won't work as the rest of selectors
16:10:07 <dael> plinss: I don't feel strongly about level, I just want to see some level added to it
16:10:31 <dael> glazou: It's only a proposal for the time being and if it doesn't make progress and selectors 4 does I don't want to block selectors
16:10:38 <dael> fantasai: Oh, yeah, it shouldn't be in 4
16:10:44 <dael> glazou: It's good where it is
16:10:52 <dbaron> I wonder if it's a problem that there's material in the Abstract ("not intended to be used in CSS") that's not in any other part of the document.
16:10:55 <dael> plinss: At some point we should see where it fits, but not on the call
16:11:05 <dael> Topic: calc() unit algebra
16:11:11 <astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0101.html
16:11:31 <dael> TabAtkins: I can addres this. It's proposing how to deal with mailing deviding by united values
16:11:42 <dael> ...: It works widely when we add more math op to calc
16:11:45 <Zakim> -hober
16:11:54 <dael> ...: Right now when you devide in calc it must be a number.
16:12:08 <dael> ...: B/c we cannot in general case decide if a unit will be 0 at parse time
16:12:19 <dael> ...: We like making division by 0 a parse time error
16:12:47 <dael> ...: This prop is we allow unit and division by 0 at parse is an error. Div at 0 not at parse becomes an infinity and infinities propigate
16:13:05 <dael> ...: At the end of the experssion is if it's an infinity it's just the largest value possible.
16:13:13 <dael> ...: Impl have a unit if doesn't go beyond.
16:13:15 <ChrisL> s/propigate/propogate
16:13:28 <dael> ...: IN addition a few of the units that are recipicols would flip themselves around.
16:13:42 <dael> ...: And that's basically it. It doesn't req tracking complicated unit algebra
16:13:51 <ChrisL> s/recipicols/reciprocals/
16:13:57 <dael> ...: For ex you can't mulitply links together. You have to do order so you don't stack units
16:14:36 <dael> ...: The proposal seems simple to me. It doesn't seem like it would be complex extra tracking. The largest available size is wierd, but seems legit and it's continuous as the value appraoches 0
16:14:51 <dael> ...: If we get a very small number we might exceed the largest allowed value anyway
16:15:14 <dael> ...: I am totally willing to accept this into values and units and I want impl interest before I pull the trigger
16:15:22 <Zakim> +hober
16:15:26 <fantasai> This should go into V&U L4
16:15:36 <dael> ChrisL: You said this is a large number rather than inifinity, what happens if you divide two infinities
16:15:50 <SimonSapin> q+ two different behaviors for division by zero is weird
16:15:53 <dael> TabAtkins: Just like an NaN it effects all things. If inifinity shows up in any context it becomes inifinity
16:16:02 <dael> TabAtkins: Technically we need to trach the sign
16:16:09 <dael> ChrisL: What about the recipicol.
16:16:10 <SimonSapin> q+ to say two different behaviors for division by zero is weird
16:16:17 <dael> TabAtkins: Let's see if the proposal tracks that.
16:16:31 <dael> TabAtkins: Dividing by an infinity produces 0
16:16:31 <ChrisL> in general its good and better than throwing an exception
16:16:43 <dael> ??: Do we track the sign of 0?
16:16:56 <SimonSapin> s/??/florian
16:17:01 <dael> ??: If you do 1m - 0px from one end ...
16:17:10 <glenn> -0 = 0
16:17:14 <dbaron> q+ to say that length * length / length seems like it might be more desirable than the other aspects of unit algebra
16:17:29 <dael> TabAtkins: This is true. I can go either way either simplily not care about - 0 or let's be consistant and deviding by -0 creates negative
16:17:56 <dael> florian: But we don't have it. If we have 1n-15px and you n transitions from 5 to smaller, you're going there but there's not trace of where you came from
16:18:11 <dael> TabAtkins: You can type -0 and it means something distinct in JS
16:18:14 <glenn> thinks it should not be treated as distinct
16:18:28 <dael> TabAtkins: Coninuity does matter. If you're going from -0 to +0 it does matter
16:18:53 <dael> florian: If you plan to cross yes, but if you plan to stop there the cont. arguement doesn't work
16:19:06 <dael> TabAtkins: It works most of the time, but when you have a - link fly off to inifinity
16:19:19 <dael> TabAtkins: In the proposal he calls that out and says we only have one 0 and it goes to + inifinity
16:19:28 <dael> TabAtkins: Youc an get - infinity, but not from 0
16:19:44 <dael> florian: It's defined byt doesn't give the arguement of cont. at the end
16:20:05 <dael> TabAtkins: Int he case wehre you're approach - inf from one side it doesn't work. Where you're doing + it's fine and where you're crossing it's fine.
16:20:16 <dael> TabAtkins: In a rare case we lose con't but it ususally wrosk
16:20:17 <Zakim> -kawabata
16:20:24 <Zakim> -zcorpan
16:20:28 <dael> florian: I don't have a good grasp on use cases, but why is it rarer
16:20:37 <BradK> -infinity / -0 = black hole?
16:20:41 <dael> TabAtkins: b/c mostvalues are positive. We don't have many instances of negative
16:20:51 <Zakim> +??P30
16:20:59 <kawabata> zakim, ??P30 is me.
16:20:59 <Zakim> +kawabata; got it
16:21:01 <dael> florian: In general that makes sense but in relation to this I'm not sure what people would use this for. IT sounds reasonable, but I'm not sure
16:21:12 <glazou> Zakim, mute kawabata
16:21:12 <Zakim> kawabata should now be muted
16:21:14 <SimonSapin> Do we allow attr() on other non-literals in calc()? What does this do? <p data-z=0 style="width: calc(100px / attr(data-z))">
16:21:14 <dael> TabAtkins: It's either that or adopt full floating point semenatics
16:21:27 <dael> ChrisL: It prob is complex but is also prob being implemented
16:21:41 <dael> TabAtkins: I can argue for simple, but if the complex is being use that's fine.
16:21:42 <Zakim> +??P44
16:21:53 <zcorpan> Zakim, ??p44 is zcorpan
16:21:53 <Zakim> +zcorpan; got it
16:21:57 <dael> TabAtkins: We can leave that open as an issue ands ee what people think with more time
16:22:01 <ChrisL> s/implemented/implemented on to of IEEE floating point anyway/
16:22:12 <plinss> ack
16:22:12 <dael> ???: I like it in general, but don't like two different behaviours for division by 0
16:22:31 <glazou> s/???/SimonSapin
16:22:32 <dael> SimonSapin: It's not always obvious 0 division is detectable at parse time
16:22:42 <dael> TabAtkins: It is completely detectable.
16:23:05 <glazou> Zakim, mute zcorpan
16:23:05 <Zakim> zcorpan should now be muted
16:23:07 <dael> plinss: When you can't detect at parse you fallback and when you can't you don't get the fallback behaviour
16:23:33 <dael> TabAtkins: I'm fine with making detectable division by infinity use case as well. Unlike that's in the wild a lot
16:23:49 <glazou> Zakim, unmute zcorpan
16:23:49 <Zakim> zcorpan should no longer be muted
16:23:57 <dael> dbaron: I'm fine as well, but want to note TabAtkins discription is wrong. Issue isn't if it has units, but is if you have to analize them
16:24:18 <dael> TabAtkins: The calc() spec makes the statement that producing a 0 unit isn't the same as 0. It's still united and therefore invalid.
16:24:30 <dael> TabAtkins: 5px/0px breaks current parsing
16:24:47 <dael> dbaron: I'm answering a q about Zach's proposal. I'm fine with changing it and prob a good idea
16:24:56 <plinss> ack SimonSapin
16:24:56 <Zakim> SimonSapin, you wanted to say two different behaviors for division by zero is weird
16:24:57 <dael> SimonSapin: I'd rather have only 1 behavious of div by 0
16:25:01 <dbaron> s/changing it/changing it so that all division by zero uses the same rules/
16:25:13 <dael> TabAtkins: Then all div by 0 uses this semeantic we don't have about parse time error checking
16:25:27 <dael> ???: Is this the only issue?
16:25:44 <zcorpan> what about 0/0 ?
16:25:48 <zcorpan> also +infinity?
16:25:50 <dael> TabAtkins: Yes, I think that's the issue. What I'm saying is all 0 division creates infinity and remove parse time detections
16:25:59 <dael> TabAtkins: Does a resolution sound resonable.
16:26:02 <plinss> q?
16:26:03 <ChrisL> q?
16:26:07 <dbaron> ack dbaron
16:26:07 <Zakim> dbaron, you wanted to say that length * length / length seems like it might be more desirable than the other aspects of unit algebra
16:26:40 <dael> dbaron: So I think the, I'm concerned about limits on unit algebra b/c length * length/length seems more useful and not that hard to track.
16:26:46 <SimonSapin> zcorpan, 0/0 is +infinity in the proposal IIRC
16:26:51 <dael> dbaron: I'd be inclinded to allow instead of forbid
16:26:58 <dael> TabAtkins: What do you mean it's a bunch of int?
16:27:01 <plh> plh has joined #css
16:27:04 <dael> dbaron: You just have to track it
16:27:07 <zcorpan> SimonSapin: ok. that's different from JS though
16:27:15 <dael> TabAtkins: You'd be okay with length * time/length - time
16:27:18 <dbaron> s/track it/track a bunch of dimensions/
16:27:29 <dael> TabAtkins: We were going for simplicity, but if you think it's better I'm fine with that.
16:27:32 <Bert> (I agree with dbaron: a / b * c should always be a * c / b, except, possibly, for overflow.)
16:27:39 <dael> SimonSapin: I think it's non-obvious if we don't do that.
16:27:46 <dael> TabAtkins: I have 0 problems with that.
16:27:51 <SimonSapin> s/SimonSapin/florian (once)
16:27:51 <MaRakow> Some of the unit conversions look a bit off to me but I'll catch up and respond on the mail (e.g. <number> / <resolution> = <length>?)
16:28:17 <dael> TabAtkins: IN that case... Does adopting unit algerba to calc with a issue that we need to decide if we have to adobt floating point
16:28:19 <dbaron> q+ to ask about implementor interest (Tab's original question)
16:28:32 <dael> florian: I'm not sure if that right. Do we already have units?
16:28:38 <dael> TabAtkins: We're liniar by nature
16:28:48 <ChrisL> except for color values which are not linear
16:28:48 <dael> florian: So length is the only case?
16:28:52 <dael> TabAtkins: Correct.
16:28:56 <dbaron> dbaron: we have time and frequency
16:28:58 <dael> florian: That makes it easier.
16:28:58 <plinss> ack dbaron
16:28:58 <Zakim> dbaron, you wanted to ask about implementor interest (Tab's original question)
16:28:59 <dbaron> Tab: and length and resolution
16:29:15 <dael> dbaron: One thins TabAtkins asked is is there impl interest and we didn't disuss that
16:29:26 <dael> dbaron: I think this is interesting, but not top of our priority list right now
16:29:39 <dael> TabAtkins: Okay. I don't know how to decide if that's good to add, though
16:29:46 <dael> fantasai: I think that means add it to level 4
16:30:01 <dael> TabAtkins: Okay. If we did that we'd need to add infinity to current level for future compat
16:30:07 <dael> glazou: Sounds okay to me
16:30:14 <dael> dbaron: What's the calc impt now?
16:30:28 <dael> TabAtkins: Blink does. It's not usniversal but almost. I'm not sure about ??
16:30:33 <dael> fantasai: IE does impl
16:30:39 <Zakim> -TabAtkins
16:30:46 <dael> dbaron: It sounds like if we have imterop we should do it
16:30:57 <dbaron> s/we should do it/the new thing should be level 4/
16:30:59 <dael> florian: Well, calc doesn't work with MQ
16:30:59 <zcorpan> s/??/WebKit/
16:31:10 <Zakim> +TabAtkins
16:31:18 <dael> fantasai: That's a impl bug. The division should be in level 3 b/c it's deployed and impl
16:31:45 <dael> plinss: There's an issues with division that's small and perhaps should be in 3 if implementors are willing to do it now, perhaps
16:31:46 <fantasai> s/The division should be in level 3 b/c it's deployed and impl//
16:31:55 <dael> dbaron: Maybe, but changing it is glossing over compat problem
16:32:17 <dael> TabAtkins: A moment ago you said you were fine, but you say you're fine will all 0 div into infinity
16:32:24 <dael> dbaron: Yes, but it's a denet chunk of work
16:32:27 <fantasai> fantasai^: We shouldn't add new stuff to L3, because there's a subset that's deployed and implemented and people need to know what that is.
16:32:34 <dael> florian: Are you saying it's okay now or in future?
16:32:47 <dael> TabAtkins: Future makes compat worse. I think Blink would be okay
16:32:53 <dael> fantasai: What's effectied?
16:33:05 <dael> TabAtkins: If you're dividing by 0 or a unit that becomes 0.
16:33:32 <dael> fantasai: So currently that gets parsed to error so presumptively not many people are relying on it so let's ignore that
16:33:43 <BradK> It could be used as a CSS browser filter
16:33:46 <dael> dbaron: IN general we don't worry about compat when changing previous invalid into valid
16:33:53 <dael> fantasai: That's kinda the point
16:34:02 <fantasai> of forwards-compatible parsing
16:34:08 <dael> TabAtkins: There is the chance you rely on it not working, but every change may have that campt problem
16:34:26 <fantasai> fantasai^: calc(2em/5px) is also currently parsed as invalid, and we'd be changing that, too.
16:34:28 <dael> TabAtkins: So res would be add calc algebra to level 4 and keep an issue in there about +0/-0 handling
16:34:35 <dael> TabAtkins: Does that sound good?
16:34:40 <dael> plinss: Any obj?
16:35:03 <dael> RESOLVED: Add calc() algebra to level 4 and kepp an issue in there about +0/-0 handling
16:35:28 <dael> plinss: What about the division behaviour in 3?
16:35:41 <dael> TabAtkins: We can just change that in future when we do full unit algebra
16:35:48 <dael> plinss: Is that okay? Okay.
16:35:57 <dael> Topic: subgrid keyword
16:36:06 <dael> fantasai: There was no ML discussion until last night.
16:36:12 <Zakim> -kawabata
16:36:15 <dael> fantasai: I don't think we have any consensus on ML
16:36:26 <dael> TabAtkins: The main issue is there's not discussion b/c you're the one obj
16:36:44 <Zakim> +??P30
16:36:56 <dael> fantasai: Yes but we were going to discuss use cases and no one commented on that except dbaron whose questions I answered and Simon removed his objection
16:37:02 <Zakim> -zcorpan
16:37:06 <dael> plinss: So one more pass for ML discussion?
16:37:13 <dael> SimonSapin: Yes, let's move on.
16:37:18 <fantasai> s/objection/support for removing the feature/
16:37:23 <SimonSapin> s/SimonSapin:/???:/
16:37:23 <astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0184.html
16:37:24 <Zakim> +??P44
16:37:29 <zcorpan> Zakim, ??p44 is zcorpan
16:37:29 <Zakim> +zcorpan; got it
16:37:29 <dael> Topic: % Margins/padding on grid/flexbox
16:37:33 <fantasai> s/???:/rossen:/
16:37:37 <dael> TabAtkins: This was raised by 2 people seperately
16:37:40 <kawabata> zakim, ??p30 is me
16:37:40 <Zakim> +kawabata; got it
16:37:56 <SimonSapin> s/removed his objection/retracted his position that was in favor of punting/
16:38:04 <dael> TabAtkins: They argued current behavious of flexbox is different than how it works in block where vertical positions are resolved against width
16:38:27 <dael> TabAtkins: They say this is inconcsistant and allows certain hacks that allow you to use % padding
16:38:41 <dael> TabAtkins: They argue we should revert to previous version like Block
16:38:54 <dael> TabAtkins: And where flexbox and grid should be consistant, we should change grid too
16:39:08 <dael> TabAtkins: WE had done this in grid and then back imported to flexbox
16:39:32 <tantek> tantek has joined #css
16:39:33 <dael> TabAtkins: I can go either way, but I strongly think they should be consistant.  Either works, but I want to hear from impl so we edit one way or another
16:39:34 <BradK> Why was grid different?
16:40:01 <dael> TabAtkins: I think Microsoft felt okay with changing flex, but wanted to keep grid the same.  Can someone explain why it's okay to break consistancy?
16:40:27 <dael> Rossen_: The arguement for keeping same length for % resolution kinds makes sense to me. We have a sign compat hit if we changed grid at this point
16:40:39 <dbaron> q+ to comment on why vertical makes sense
16:40:40 <dael> Rossen_: I'm not sure we can make sure a deep change for apps using grid.
16:41:00 <dael> Rossen_: So our concern is breaking compat. I hear you and conisstancy is important between flex and grid
16:41:16 <dael> Rossen_: I'm not sure we can make a comprimise. I need to go dig into data and see how much breakage.
16:41:32 <dael> Rossen_: We have enough apps built on % resolution from height in grid, but not for flex.
16:41:37 <dael> Rossen_: That's the reasoning.
16:41:40 <dael> TabAtkins: Okay.
16:42:03 <dael> TabAtkins: If necessary we could work around that compat issue with as switch that's one way for legacy and another way for the rest
16:42:28 <dael> Rossen_: That's always...havingt he ability to take relative size resolution from height or width...if you can choose from height now width...
16:42:41 <dael> Rossen_: That would be cool if you could do it universally, but we don't have that
16:42:50 <dael> Rossen_: Are you suggesting a switch like that?
16:43:11 <dael> TabAtkins: It's a resolution to the problem and portentially interesting b/c it would let you use vertical % on block
16:43:26 <dael> TabAtkins: I'm okayw ith this and if this makes everyone happy it's good
16:43:43 <dael> Rossen_: Let us see what we can find out interenally the baddness a change to % resolution would create.
16:44:02 <plinss> ack dbaron
16:44:02 <Zakim> dbaron, you wanted to comment on why vertical makes sense
16:44:05 <dael> Rossen_: For now I'd say flex should go back to the rest of CSS and we need to decide what it would do to us
16:44:23 <BradK> -ms-grid-padding-percent-sizing: ??
16:44:27 <dael> dbaron: I think there's a good bit of logic to changing. The block layout is based on tradition width is input, height is putput
16:44:41 <plh> plh has joined #css
16:44:53 <dael> dbaron: In flex and grid there isn't that big difference and having this wierd difference breaks the model that is actually more selemtric
16:45:07 <dael> dbaron: And it think it ought to be more semetric and having the way flex is spec'ed is a good thing
16:45:16 <fantasai> symmetric
16:45:24 <dael> TabAtkins: I think that's why fantasai and I saw grid was doing semetric, we switched felxbox to it
16:45:45 <dael> TabAtkins: If we stay semetric, that would address microsoft's concerns, it would make our impl less happy, but it's not a huge deal for us
16:46:06 <dael> ??: I was going through the mail, do they want to change it back so it's more consistant with doc centric?
16:46:15 <dbaron> s/??/Rossen/
16:46:32 <dael> TabAtkins: Yes, theri agruement is based on expectations. You can use % padding to control an aspect ratio, but I'd say we can control aspect ratio directoly
16:46:46 <dael> TabAtkins: there's also an issue about the layout for the containing block, but that's not big
16:47:11 <fantasai> I think the use case for having both reference width isn't aspect ratios, but rather having consistent padding in both dimensions while having that padding respond to space available
16:47:14 <dael> Rossen_: So going back to resolving width and height, I have to think more about impl, but I'm pretty sure it's not a stretch to allow behaviour controlled at container level
16:47:30 <dael> Rossen_: Where you have either traditional witdh or this and we can argue which is default
16:47:44 <dael> Rossen_: That way authors can have doc centric or more semetric behavious
16:48:11 <dael> TabAtkins: But if the current is the default, there's less reason for a flag, I introduced that for compat. It would be somewhat useful, but not worth effort
16:48:30 <dael> TabAtkins: Based on the discussion so far I think we can keep current and maybe investigate sep. property to switch
16:48:37 <dael> TabAtkins: Is that okay with you dbaron?
16:48:45 <dael> dbaron: That's fine. I'm uneasy about switchs
16:49:11 <dael> TabAtkins: So I thinkw e should res to keep current behaviour where % vertical padding/margins resolve against heigth
16:49:25 <dael> TabAtkins: And as a seperate action investigate if a switch is useful
16:49:30 <dael> TabAtkins: Any obj to the resolution?
16:49:37 <dael> plinss: Doens't sound like it
16:49:47 <dael> RESOLVED:  keep current behaviour where % vertical padding/margins resolve against heigth
16:49:55 <dael> TabAtkins: I'll investigate the switch
16:50:13 <dael> Topic: Item height when max-height applied to flex container
16:50:26 <astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0292.html
16:50:30 <dael> TabAtkins: This is a simple tweek to flex brought up by gregwhitworth
16:51:00 <dael> TabAtkins: If flex is indefinite but has a max height and the contect is bigger than max, does flex item grow to contain or is content constrained
16:51:10 <gregwhitworth> You're right
16:51:12 <dael> TabAtkins: Spec says item should...I forget, hang on.
16:51:46 <dael> TabAtkins: The flex item gets set to 150px to size of content and overflows the constrainged flex container
16:51:59 <dael> TabAtkins: Blink is different and makes felx item stay the size of flex continaer
16:52:07 <Zakim> -kawabata
16:52:10 <dael> TabAtkins: This is same as if you set a height instead of max heigth
16:52:21 <dael> TabAtkins: Some people think this makes sense.
16:52:39 <dael> TabAtkins: Suggestion is we change spec slightly so that a max height on flex container constrains item
16:52:39 <Zakim> +??P30
16:52:49 <Zakim> -zcorpan
16:53:00 <Zakim> +??P52
16:53:05 <tantek> Zakim, ??p52 is tantek
16:53:05 <Zakim> +tantek; got it
16:53:11 <Zakim> +??P44
16:53:11 <dael> fantasai: So how flex should work is you layout contents and max height is violated, you relayout and this change seems to make sense where violating max height doesn't work
16:53:19 <zcorpan> Zakim, ??p44 is zcorpan
16:53:19 <Zakim> +zcorpan; got it
16:53:23 <dael> TabAtkins: I agree. The change would be consistant with how it should work
16:53:33 <dael> fantasai: If there's other inconsistant we should change that
16:53:34 <fantasai> s/flex/max-height/
16:53:38 <antonp> +1 for encouraging consistency with the principle that fantasai described
16:53:53 <fantasai> s/relayout with the max height as height/
16:53:54 <dael> TabAtkins: I'm not sure where, but perhaps where we have aspect ratios, but if there's nother changes I'm happy to bring them to the list
16:53:58 <fantasai> er
16:54:05 <fantasai> s/relayout/relayout with the max height as height/
16:54:07 <dael> TabAtkins: For now is there any obj to changing the algorythm to match Blink
16:54:21 <dael> TabAtkins: Fireforx imp is for that and I believe gregwhitworth is for it from IE too
16:54:26 <dael> TabAtkins: So any obj?
16:54:31 <ar> ar has joined #css
16:54:53 <dael> RESOLVED to change the spec's max-height impl to match Blink's impl
16:55:08 <dael> gregwhitworth: How does that compere with Firefox and Webkit
16:55:15 <dbaron> s/gregwhitworth/glennadams/
16:55:26 <dael> TabAtkins: Webkit matches blink, firefox and IE impl current spec, but the impl are for making the change.
16:55:39 <dael> glenn: Okay.
16:56:01 <dael> Topic: Box model/render tree
16:56:10 <dael> TabAtkins: It's better to move to a different topic
16:56:21 <dael> plinss: Okay. We'll come back
16:56:27 <dael> Topic: :role() selector
16:56:29 <astearns> http://lists.w3.org/Archives/Public/www-style/2013Jul/0099.html
16:56:44 <dael> TabAtkins: The original thread was for a pseudo-calss that match arrea roles
16:57:11 <SimonSapin> s/arrea/ARIA/
16:57:13 <dael> TabAtkins: That seemed acceptable to me but a recent addendum to the thread that said some aren't computed until layout, so having a pseudo would create bad dependancies.
16:57:25 <dael> TabAtkins: Does anyone have insight into this?
16:57:37 <dael> tantek: It seems similar to old appearence prop but that was in other direction
16:57:40 <dael> TabAtkins: Yes.
16:57:53 <dbaron> It seems like a good idea, except for the issue you just mentioned about ARIA roles not being computed until layout.
16:57:57 <dael> TabAtkins: The ideal is it's most useful for query selector
16:58:11 <dael> tantek: I'm concerned that ARIA would be effective by layout
16:58:13 <dael> TabAtkins: Yes.
16:58:22 <dael> tantek: That's my resolnce so we can resolve in a good way
16:58:23 <dbaron> s/effective/affected/
16:58:31 <dael> TabAtkins: I think we should take this to the list and ask how it happens
16:58:51 <dael> tantek: ARIA affects the semeantic and not the layout and we can do a pseduo based on that. That makes sense to me
16:58:57 <dael> TabAtkins: Let's continue on the list
16:59:08 <astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0230.html
16:59:10 <dael> Topic: The LAst Grammar Combinator
16:59:35 <fantasai> summary: need combinator for "one or more, in this order"
16:59:38 <dael> TabAtkins: I argue we have 6 common grammer combinations of which we can exress 5
16:59:42 <fantasai> proposal: Use ?? as combinator
16:59:45 <dael> TabAtkins: We've talked about this before but couldn't get a good syntax and there was general malase about adding more syntax
17:00:07 <dael> TabAtkins: I think the usecase is common. We often have a thing with a main content and a fallback and you need to expess something, but don't care which one
17:00:13 <jcraig> jcraig has joined #css
17:00:27 <dael> TabAtkins: In order to do that now you need to do a lot of tricks. It's not easy and unclear and gets worse with 3 terms
17:00:31 <fantasai> example:
17:00:32 <fantasai> [left | right] |
17:00:32 <fantasai> [left | right]? [<length> | <percentage>]
17:00:36 <fantasai> becomes
17:00:44 <dael> TabAtkins: So I propose we plug this hole so out 2x3 matrix of combinators is complete.
17:00:48 <fantasai> [left | right] ?? [<length> | <percentage> ]
17:01:21 <dael> TabAtkins: I propose we use ?? for the combinator. It also matches combinator which is 0 or more which you do with juxtipose. It put the ? between instead if on either end
17:01:25 <dael> TabAtkins: So any obj?
17:01:31 <dael> fantasai: I put an ex in the IRC
17:01:33 <tantek> wow ?? looks like an error
17:01:38 <dael> dbaron: ?? Seems odd.
17:01:48 <plinss> ¿?
17:01:51 <dael> TabAtkins: We're open to other idea. That was just what came to mind for me
17:01:56 <MaRakow> &|
17:02:02 <dael> plinss: Any thoughts?
17:02:26 <tantek> interrobang?
17:02:30 <dael> TabAtkins: If the idea is okay and want to talk more syntax, that's fine. We've got a thread so please comment. I think this would make a lot of things better and just want good syntax
17:02:38 <Zakim> -hober
17:02:43 <Zakim> -zcorpan
17:02:44 <Zakim> -dbaron
17:02:45 <Zakim> -glazou
17:02:47 <Zakim> -[Microsoft]
17:02:48 <Zakim> -SimonSapin
17:02:48 <dael> plinss: Okay, that's the top of the hour. I'll talk to you next week, well, I won't be here, but the week after.
17:02:48 <Zakim> -BradK
17:02:49 <Zakim> -koji
17:02:50 <Zakim> -ChrisL
17:02:51 <Zakim> -plinss
17:02:51 <Zakim> -glenn
17:02:51 <Zakim> -florian
17:02:52 <Zakim> -Bert
17:02:52 <Zakim> -[Microsoft.a]
17:02:54 <Zakim> -fantasai
17:02:54 <Zakim> -Stearns
17:02:56 <Zakim> -SteveZ
17:02:58 <Zakim> -??P30
17:02:58 <Zakim> -dael
17:02:59 <Zakim> -MaRakow
17:02:59 <Zakim> -tantek
17:03:01 <kawabata> kawabata has left #css
17:03:01 <Zakim> -[IPcaller]
17:03:01 <Zakim> -antonp
17:03:04 <Zakim> -TabAtkins
17:03:04 <Zakim> Style_CSS FP()12:00PM has ended
17:03:04 <Zakim> Attendees were plinss, dael, glazou, SimonSapin, Stearns, hober, Bert, MaRakow, kawabata, fantasai, florian, +999999aaaa, BradK, antonp, TabAtkins, dbaron, koji, gregwhitworth,
17:03:04 <Zakim> ... AH_Miller, zcorpan, ChrisL, [Microsoft], glenn, Rossen_, SteveZ, tantek
17:03:05 <TabAtkins> dbaron: Saying "either A or B, or both" is not overly complex.
17:03:22 <AH_Miller> AH_Miller has left #css
17:03:47 <TabAtkins> It happens in lots of places for simple reasons - image() wants "a list of urls" and/or "a fallback color".  The <picture> sizes='' attribute wants "a list of MQ/size pairs" and/or "a fallback size".
17:04:04 <florian> florian has left #css
17:04:08 <TabAtkins> In essence, this is the "and/or" combinator.
17:04:38 <TabAtkins> (I suspect that's why &| came up as a suggestion in previous discussions of this.)
17:04:40 <zcorpan> &/?
17:04:58 <TabAtkins> Maybe just // ?
17:05:09 <TabAtkins> Or is that still too associated with comments?
17:05:21 <MaRakow> || means one or more with comma separation, right?
17:05:43 <MaRakow> because normally || would be the logical notation
17:06:02 <TabAtkins> MaRakow: No, you're thinking of multipliers.
17:06:13 <TabAtkins> <foo># is "one or more repetitions, with commas".
17:06:18 <MaRakow> o right
17:06:30 <TabAtkins> a || b means "a or b or both, in any order".
17:06:41 <TabAtkins> Sorry, my use of the terms "one or more" was ambiguous.
17:06:51 <TabAtkins> One or more among these choices, not one or more repetitions.
17:07:35 <zcorpan> http://picture.responsiveimages.org/#valid-source-size-list is the current spec for sizes="" which could use this
17:07:43 <TabAtkins> [a? b?]!
17:07:58 <TabAtkins> With ! meaning "can't be empty"?
17:08:20 <zcorpan> that looks ok to me
17:09:21 <zcorpan> [ <source-size>* [ , <source-size-value> ]? ]!
17:09:53 <TabAtkins> [ <source-size># [ , <source-size-value> ]? ]! , rather.
17:10:09 <TabAtkins> But dammit, commas strike again!
17:10:21 <zcorpan> right
17:11:00 <TabAtkins> I think we need to just express in the grammar that commas always implicitly must be omitted if the two options they separate are missing.
17:11:24 <TabAtkins> Or if it separates the first/last from the rest in a juxtaposed list, must be omitted if the first/last is missing.
17:11:38 <TabAtkins> I'd like to say:
17:11:51 <TabAtkins> [ <source-size>#? , <source-size-value>? ]!
17:13:04 <zcorpan> that seems reasonable
17:13:08 <TabAtkins> I'm warming to the use of ! to mean "required".
17:13:56 <TabAtkins> And it means no new combinators, which is nice, because I seriously do still have to think about what && means every damn time.
17:14:14 <TabAtkins> And regularly try to write it when I mean what we were discussing today.
17:14:58 <zcorpan> i don't know if `[ <source-size>#? , <source-size-value>? ]!` is more understandable than `<source-size>#+ [ , <source-size-value> ]? | <source-size-value>`
17:15:43 <zcorpan> but the latter might become hairy if more stuff gets added
17:16:10 <TabAtkins> Note that #+ is invalid.
17:16:19 <TabAtkins> You can't stack multipliers like that.
17:17:04 <zcorpan> oops. it should be just # ?
17:17:29 <TabAtkins> Yeah.
17:17:36 <TabAtkins> Meant to fix taht a while ago, but forgot.
17:26:14 <Ms2ger> Ms2ger has joined #css
18:20:37 <adenilson> adenilson has joined #css
18:24:22 <zcorpan> zcorpan has joined #css
18:30:42 <fantasai> I don't like []!
18:31:00 <fantasai> Looks like it's supposed to be a multiplier, and it's not
18:31:42 <fantasai> also, too many brackets makes grammars hard to read
18:32:06 <fantasai>  // seems reasonable, it's like || except it requires ordering
18:32:18 <fantasai> and // has a directionality to it that || doesn't
18:38:37 <zcorpan> so what would the sizes grammar look like with // ?
18:39:11 <TabAtkins> Commas actually make it impossible to use a combinator for the sizes attr. :/
18:39:21 <TabAtkins> Goddam commas.
18:39:25 <fantasai> heh
18:39:38 <TabAtkins> (Any separator, really.)
18:41:05 <zcorpan> >,>
18:42:00 <MaRakow> MaRakow has joined #CSS
18:42:44 <TabAtkins> Just allow commas between the two characters of the combinator!
18:46:06 <zcorpan> that's right
18:46:27 <TabAtkins> I... guess I'm not too opposed to that.
18:46:58 <zcorpan> at least we'd have an opportunity for having emoticons in the grammar
18:47:08 <TabAtkins> &_&
18:56:39 <Zakim> Zakim has left #css
20:07:02 <zcorpan> zcorpan has joined #css
20:41:57 <rhauck> rhauck has joined #css
20:51:49 <jet> jet has joined #css
21:12:32 <rhauck> rhauck has joined #css
22:40:46 <glenn> glenn has joined #css
22:50:17 <zcorpan> zcorpan has joined #css
22:53:22 <zcorpan_> zcorpan_ has joined #css
23:20:41 <zcorpan> zcorpan has joined #css
23:22:30 <zcorpan_> zcorpan_ has joined #css
23:30:29 <jdaggett> jdaggett has joined #css
23:31:53 <glenn> glenn has joined #css
23:44:47 <glenn> glenn has joined #css