15:30:44 <RRSAgent> RRSAgent has joined #css
15:30:44 <RRSAgent> logging to http://www.w3.org/2015/06/24-css-irc
15:30:50 <glazou> Zakim, this will be Style
15:30:50 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 30 minutes
15:30:56 <glazou> RRSAgent, make logs public
15:31:14 <glazou> and this will be our last conference call with Zakim
15:32:30 <svillar> svillar has joined #css
15:48:47 <hyojin> hyojin has joined #css
15:53:56 <dael> dael has joined #css
15:54:08 <antenna> antenna has joined #css
15:55:28 <jdaggett> jdaggett has joined #css
15:56:24 <Zakim> Style_CSS FP()12:00PM has now started
15:56:31 <Zakim> +plinss
15:56:50 <Zakim> + +1.479.764.aaaa
15:56:55 <Florian> Zakim, I am aaaa
15:56:55 <Zakim> +Florian; got it
15:57:14 <Zakim> +??P2
15:57:19 <glazou> Zakim, ??P2 is me
15:57:19 <Zakim> +glazou; got it
15:57:30 <Zakim> +smfr
15:57:38 <adenilson> adenilson has joined #css
15:57:44 <alex_antennahouse> alex_antennahouse has joined #css
15:57:45 <Zakim> +Plh
15:57:53 <Zakim> + +1.631.398.aabb
15:58:04 <antenna> zakim, aabb is me
15:58:04 <Zakim> +antenna; got it
15:58:18 <Zakim> +??P5
15:58:40 <Zakim> +[IPcaller]
15:58:47 <alex_antennahouse> zakim IPcaller is me
15:58:52 <bkardell_> bkardell_ has joined #css
15:58:59 <Zakim> +dauwhe
15:59:08 <Zakim> -??P5
15:59:14 <myles> myles has joined #css
15:59:29 <Zakim> +BrianKardell
15:59:37 <Zakim> +??P8
15:59:49 <hyojin> zakim, P8 is me
15:59:49 <Zakim> sorry, hyojin, I do not recognize a party named 'P8'
16:00:00 <glazou> Zakim, ??P8 is hyojin
16:00:00 <Zakim> +hyojin; got it
16:00:09 <tantek> tantek has joined #css
16:00:14 <hyojin> thanks
16:00:16 <glazou> np
16:00:21 <bkardell_> Zakim, things just won't be the same without you...
16:00:21 <Zakim> I don't understand you, bkardell_
16:00:25 <Zakim> + +1.908.982.aacc
16:00:27 <dael_> dael_ has joined #css
16:00:28 <adenilson> adenilson has joined #css
16:00:33 <glazou> Zakim, we’ll miss you :-)
16:00:33 <Zakim> I'm glad that smiley is there, glazou
16:00:55 <Zakim> +dael
16:01:22 <jdaggett> jdaggett has joined #css
16:01:31 <Zakim> + +93016aadd
16:01:35 <andrey-bloomberg> andrey-bloomberg has joined #css
16:01:40 <antonp1> Zakim, aadd is me
16:01:40 <Zakim> +antonp1; got it
16:02:56 <myles> Zakim, aacc is me
16:02:56 <Zakim> +myles; got it
16:03:18 <Zakim> +[Microsoft]
16:03:38 <glazou> Reminder to all : https://www.w3.org/2006/tools/wiki/WebExBestPractices
16:03:42 <glazou> for next week
16:03:52 <Zakim> + +1.281.305.aaee
16:03:53 <glazou> https://www.w3.org/2006/tools/wiki/InstallingWebEx
16:03:54 <dael_> ScribeNick: dael
16:03:57 <TabAtkins> zakim, aaee is me
16:03:57 <Zakim> +TabAtkins; got it
16:03:59 <Zakim> +??P13
16:04:00 <glazou> https://www.w3.org/2006/tools/wiki/WebExFAQ
16:04:15 <Zakim> +BradK
16:04:17 <Zakim> -BradK
16:04:54 <MaRakow> MaRakow has joined #CSS
16:05:00 <AH_Miller> AH_Miller has joined #css
16:05:04 <Rossen> zakim, microsoft has me
16:05:04 <Zakim> +Rossen; got it
16:05:10 <Zakim> +??P17
16:05:11 <adenilson> Zakim, ??P13 is me.
16:05:11 <Zakim> +adenilson; got it
16:05:23 <dael_> plinss: Let's get started.
16:05:29 <dael_> plinss: Anything to add to the agenda?
16:05:36 <Zakim> +BradK
16:05:49 <BradK> BradK has joined #CSS
16:05:59 <Zakim> +[IPcaller.a]
16:06:01 <tgraham> zakim, P17 is me
16:06:01 <Zakim> sorry, tgraham, I do not recognize a party named 'P17'
16:06:09 <tgraham> zakim, ??P17 is me
16:06:09 <Zakim> +tgraham; got it
16:06:15 <dael_> Florian: To clarify, item 10 links to a mail of mine and is named CSS UI Issues and it has other issues. For CSS UI all issues have fixed and I'd like to go to publication. If we could disucss it early in the call that would be nice.
16:06:27 <bcampbell> bcampbell has joined #css
16:06:30 <dael_> plinss: We have other pub things to talk about too so that's fine. I wasn't sure if you were ready for CR
16:06:38 <dael_> Florian: I'm ready.
16:06:39 <Zakim> +MikeMiller
16:06:42 <gregwhitworth> gregwhitworth has joined #css
16:06:49 <dael_> Topic: status of will-change
16:07:08 <dael_> plh: So I'm trying to see, was there a transition request? I didn't see any.
16:07:12 <dael_> plh: So it was never asked.
16:07:19 <dael_> plh: As far as I can tell.
16:07:19 <jdaggett> jdaggett has joined #css
16:07:31 <dael_> glazou: We havea  resolution from end of March to publish so let's do that.
16:07:48 <dael_> plh: I'm happy to help, the action wasn't asked so that's why it didn't get a responce.
16:07:59 <dael_> plinss: Sounds liek something got dropped. We'll take care of that offline.
16:08:14 <dael_> Topic: spec publication
16:08:23 <dael_> plinss: There was a q about letting editors publish own specs
16:09:08 <dael_> TabAtkins: So according to Robin every other WG lets spec authors publish own spec. There is literly no requirement for team contacts to do that, so why aren't we letting authors publish own spec
16:09:19 <Zakim> +[Sophia]
16:09:31 <dael_> plh: The answer is I don't know. Not every other WG does that, some do, some don't. it varies widely. There is no req. that it be team contacts.
16:09:44 <dael_> glazou: So that's mostly the WG history. We've always gone through team contacts.
16:10:11 <plh> q+
16:10:15 <dael_> Florian: It has pros and cons. Givent hat it's annoying having team contacts manage is nice, but we have lots of specs and requests so asking them is often inconvenient.
16:10:30 <dael_> plh: My rec would be if you could move to a system that would be better.
16:10:37 <dael_> TabAtkins: I'm working on getting bikeshed on it.
16:10:46 <Zakim> +Lea
16:10:52 <dael_> plh: There are some use cases for this group that we're not support ing yet. We're working on it.
16:11:17 <dael_> plh: It only supports WD from a single WG. It doesn't support any other status. If your WD is with another WG that doesn't work.
16:11:25 <tantek> tantek has joined #css
16:11:49 <dael_> plh: We also don't support exceptions such as the CSS Validator stuff this group has been asking about. We have ideas on how to support it, but it's a question of the most urgent thing at the moment.
16:12:07 <TabAtkins> s/to a system/to the Echidna system/
16:12:21 <dael_> Florian: Where we can use it we should try, but it's not everywhere. Another down side of our way is when something bad happens the editor doesn't know.
16:13:09 <dael_> glazou: Let's not go back to that. We discussed that during the last F2F and I've discussed it witht he webmaster. The webmaster will use the original e-mail with CCs for other authors to notify about publicaiton.
16:13:15 <dael_> ??: Is that written anywhere?
16:13:23 <smfr> smfr has joined #css
16:13:23 <TabAtkins> s/??/smfr/
16:13:37 <dael_> TabAtkins: There's a page on the wiki. I'm not sure if it is there, but it should be in the how to publish on the wiki.
16:13:55 <dael_> glazou: I think I sent an e-mail to the WG a few weeks ago saying that all pub requests should be CCed to the editors.
16:14:01 <TabAtkins> (Step-by-step guide, I check it every time: https://wiki.csswg.org/spec/publish)
16:14:02 <dael_> glazou: Yes, I did it on 29 May.
16:14:10 <Zakim> +??P22
16:14:15 <tantek> zakim, ??p22 is me
16:14:15 <Zakim> +tantek; got it
16:14:17 <dael_> Florian: That removes one down side.
16:14:27 <dael_> Florian: But can editors do it themselves.
16:14:27 <Zakim> -antonp1
16:14:39 <antonp1> Zakim, mute me
16:14:39 <Zakim> sorry, antonp1, I do not know which phone connection belongs to you
16:14:58 <dael_> plinss: I have no obj to editors pub themselves. According to the guidelines we've discussed I'm okay.
16:15:07 <dael_> TabAtkins: Lets work out the details on the ML.
16:15:17 <dael_> Topic: CSS UI to CR
16:15:17 <tantek> yay!
16:15:26 <Florian> http://dev.w3.org/csswg/css-ui/#changes
16:15:34 <dael_> Florian: Yes, it's down to 0 issues. I updated the spec to have the list of changes WD by WD.
16:15:38 <tantek> Thanks Florian
16:15:38 <dael_> Florian: I also made the DoC
16:15:44 <Florian> http://dev.w3.org/csswg/css-ui/issues-2012-2015.html
16:16:16 <dael_> Florian: There are a few changes, very small. They're listed in the URL above. I think we can go to CR, though if people disagree we can do a WD for a week. I don't think we need that.
16:16:21 <tantek> we made changes that the group expected, e.g. dropping padding-box
16:16:25 <dael_> Florian: We'll publish and likely update again.
16:16:33 <tantek> I think we should go directly to CR
16:16:35 <dael_> TabAtkins: I'm fine.
16:16:46 <dael_> plinss: Any objections to CR?
16:16:56 <dael_> RESOLVED: Publish CR for CS UI 3
16:17:03 <dael_> s/CS/CSS
16:17:18 <dael_> plh: So who has the action to send the transition request.
16:17:30 <tantek> transition request? up to staff?
16:17:34 <dael_> Florian: If there's a how to guide I'm happy to do it. Or I can bother a team contact to tell me how to.
16:17:39 <dael_> plh: I'm happy to point you to them.
16:17:58 <dael_> Action: Florian to handle publication for CSS UI 3
16:17:58 <trackbot> Created ACTION-697 - Handle publication for css ui 3 [on Florian Rivoal - due 2015-07-01].
16:18:16 <dael_> Florian: Is that okay tantek?
16:18:23 <dael_> tantek: That's fine. I thought it was just a staff thing.
16:18:31 <dael_> Florian: Yes, be we just talked about letting editors do it.
16:18:37 <dael_> tantek: Alright, whatever makes it faster.
16:18:41 <tantek> Zakim, mute tantek
16:18:41 <Zakim> tantek should now be muted
16:18:52 <dael_> glazou: The transition call will still be between W3C staff and chairs.
16:18:59 <tantek> Does there always need to be a call? Just curious
16:19:08 <tantek> in terms of what's required for process
16:19:09 <dael_> glazou: We have to make sure whoever is invited to the call is in the loop.
16:19:16 <dael_> Florian: Just give me the how to and I'll do it.
16:19:20 <Zakim> -adenilson
16:19:24 <dael_> plh: I'll be happy to draft it, Florian.
16:19:28 <tantek> thanks plh
16:19:33 <dael_> Topic: calc() serialization
16:20:11 <gregwhitworth_> gregwhitworth_ has joined #css
16:20:14 <Florian> q+
16:20:15 <dael_> TabAtkins: SO it's not def how calc() serializes. I agree it should be specified. There's one bit I'm not sure about which is if you can simplify something down to a single unit, does it have to be mantained as a calc() or can you reduce that to a simple value, like 5pm
16:20:33 <dael_> TabAtkins: I'm fine with serializing down all the way and I'm fine with writing what we decide in values and units.
16:20:45 <dael_> TabAtkins: If there are opinions let me know here ot on ML, otherwise I'll spec it up.
16:21:04 <Zakim> +??P11
16:21:14 <dael_> Florian: If that's the question, it implies for other situations you're trying to serialize as much as possible.  I'm not objecting, but that's what you mean.
16:21:19 <plinss> ack Florian
16:21:21 <plinss> ack plh
16:21:24 <glazou> q+
16:21:31 <dael_> TabAtkins: Yes, I think we're not going to remember the exact form, we're serializing to the smallest tuple.
16:21:35 <adenilson> Zakim, ??P11 is me.
16:21:35 <Zakim> +adenilson; got it
16:21:40 <plinss> ack glazou
16:21:42 <dael_> glazou: I'm looking at the org. e-mail, that is the serialization about.
16:21:46 <dael_> TabAtkins: All of them.
16:21:58 <dael_> glazou: I'm obj to the OM part. It is a complete blocker for editors.
16:22:29 <bkardell_> tabatkins, what would it look like in devtools?
16:22:31 <dael_> glazou: If you add to a stylesheet calc(something complex) and you're editing through a UI and the serialization somewhere gets read of the complexity that is good for editing, it invalidates it.
16:22:37 <dael_> TabAtkins: Okay, so we should give back the exact.
16:23:00 <TabAtkins> bkardell_: DevTools has hooks into low-level stuff, can represent however they want (probably keep it literal).
16:23:15 <dael_> glazou: Computed is whatever you want. Reduction to a unit is fine. For the OM when you serialize you shouldn't tweek thte value of calc(). You can do some optimization, but if you have different units it should be preserved.
16:23:21 <dael_> TabAtkins: How about we preseve everything as is.
16:23:22 <Zakim> +antonp1
16:23:47 <dael_> Rossen: I know a lot of expressions go down to a sinlge value, what is the motivation of just reporting the value and dropping the calc(). Is there a use case or ask for it?
16:23:50 <bkardell_> TabAtkins, doesn't _glazou want the same sort of powers as devtools there?
16:24:02 <dael_> TabAtkins: We'd like to be able to simplify in the engine so dropping the calc and just having a plain value is nice.
16:24:24 <glazou> s/gets read/gets rid
16:24:27 <dael_> Florian: We have 2 use cases. glazou where we want author intent or in the case where we want to simplify as much as you can including dropping the calc()
16:24:28 <Zakim> +[Bloomberg]
16:25:10 <dael_> TabAtkins: There is still...the policy of it being exactly eq I don't think we can keep. When there's a pixal and %, I think the % is meaningful. If you're in a transition, you don't want a sudden shape change.
16:25:20 <dael_> Florian: If it means the same thing, don't preserve...
16:25:34 <dael_> TabAtkins: Where there are multi units wirtten in, we should preserve the units.
16:26:18 <dael_> TabAtkins: If you are writing something that works on string values and you do 5px 5% and -5px and -5%, you hit a point where it's 0 when you transition. If you get rid of the % you have a problem at 0.
16:27:09 <dael_> Rossen: I'm in favor of preserving. We're not going to keep the calc when we go to a single value unit in the computed style, serializing it back we can always have the calc around the value, but it's easier to serialize jsut the value without hte calc and that has nothing to do with the specified value so glazou scenario isn't effected.
16:27:22 <dael_> Rossen: I was asking why you brought it up to see if there were users asking for it.
16:27:42 <dael_> TabAtkins: It needs to be specified and we have differing impl. I have a mild preference, but we have to decide.
16:27:47 <dael_> Rossen: Should we reolve?
16:28:08 <dael_> TabAtkins: Yes. If anyone disagrees with the rest, raise those issues. Elsewise we need to decide if we're stripping the calc()
16:28:30 <dael_> TabAtkins: For computed values and further, if the calc is a single unit, remove the calc and just have the naked value
16:28:39 <dael_> Rossen: serialize out the simplification
16:28:53 <dael_> TabAtkins: In specified values we'd only combine identical units.
16:29:00 <dael_> Florian: I'd rather that be nothing at all.
16:29:14 <dael_> TabAtkins: I don't know if we keep around exact strings or reserialize the exact value.
16:29:30 <dael_> Rossen: The computed one if it reduces to a single unit, it would be better to serialize out hte single unit.
16:29:37 <dael_> glazou: I agree with Rossen from an editing POV
16:29:53 <dael_> plinss: My only concern is we don't have anyone form Moz and we can provisionally resolve.
16:29:55 <tantek> no objections
16:29:57 <dael_> plinss: Any obj?
16:30:12 <tantek> plinss - I'm from Mozilla - do you want me to check with dbaron too?
16:30:13 <dael_> RESOLVED: for computed values and further, if the calc() is a single unit, remove the calc() and just have the naked value
16:30:19 <dael_> Topic: reslution MQ
16:30:58 <dael_> Florian: I realized we define what happens when printing, but it's not how typical printing works. They render to a PDF that is sent to the printer and we don't define what happens tot he resolution MQ when the medium is a vector enviroment
16:31:01 <dbaron> dbaron has joined #css
16:31:25 <dael_> Florian: Even when you are in a vector medium, it happens that if your page contains any rastor image, it will be downsampled.
16:31:36 <dael_> Florian: That's the space we're in. TabAtkins and I have been talking on the ML
16:32:23 <dael_> TabAtkins: We add an infinity value to the resolution MQ to indicate it's vector. Then we add an additional MQ with the same syntax and is the max resolution of the rastor. It will be no lager thant he resolution, but may be smaller.
16:32:59 <dael_> Florian: 600dpi is a common value you could expect. It's common to have a quality setting that includes downsampling.
16:33:27 <dael_> Florian: We're both okay with that. I also suggested a boolean MQ to say if you're in vector or medium.
16:33:46 <dael_> Florian: I think the advantage of that is it doesn't let me do non-interesting cases, but TabAtkins syntax is easier.
16:34:16 <dael_> TabAtkins: When I was doing EX you have to use both the boolean and the resolution together. I think that's non-intuitive. With my solution you can use them independantly.
16:34:30 <Zakim> -antonp1
16:34:51 <dael_> Florian: I think TabAtkins prop. is fine. The only issue I have is when the rastor is higher than resolution.  It's more expressive than we need, but it's easier to understand so I'm okay.
16:35:01 <dael_> TabAtkins: If there are opinions express them on the ML
16:35:14 <dael_> smfr: When the browser is printing, it may know the resolution of the output device.
16:35:42 <dael_> TabAtkins: I agree that if you're going through an intermediate format you're right, but if you're going just to a PDF, getting that you want it better.
16:36:01 <dael_> Rossen: Would this have an inpact on source set? Would any re-evaluation need to happen?
16:36:07 <dael_> TabAtkins: No more than today.
16:36:25 <Zakim> -adenilson
16:36:33 <dael_> Florian: They're orthagonal, but they're independant. sourceSet needs to work witht he rasteraztion, but it's a clarification. There's not behavior change.
16:36:35 <dael_> Rossen: Okay.
16:36:47 <dael_> plinss: Do people want to let these guys sort it out or make a decision?
16:37:02 <dael_> Florian: I'm okay with TabAtkins proposal. If people want something else we can go to the ML
16:37:06 <Zakim> +[IPcaller.aa]
16:37:08 <dael_> Rossen: How critical is it?
16:37:39 <adenilson> adenilson has joined #css
16:37:45 <dael_> Florian: Not really. I don't know anyone is asking for it, I just realized it was ambig and I wanted to fix that.
16:38:07 <dael_> Florian: My use case is if you're high resolution use serif and if not use sans-serif and resolution MQ couldn't do it.
16:38:08 <Zakim> +antonp1
16:38:09 <dael_> Rossen: OKay.
16:38:19 <BradK> BradK has joined #CSS
16:38:28 <dael_> plinss: Sounds like we're learning toward TabAtkins. Should we resolve?
16:38:30 <dael_> Florian: Sure.
16:38:32 <dael_> plinss: Obj?
16:38:50 <dael_> RESOLVED: Accept TabAtkins proposal for removing ambiguity from resoltuon MQ
16:38:57 <dael_> Topic: unicode range tokens.
16:39:48 <Zakim> +[Microsoft.a]
16:40:10 <dael_> TabAtkins: A while ago there was a bug where something lik U+A was triggering as invalid. I agree it was wierd and the unicode-range was odd in CSs syntax. I tried to remove it with something like An+B. That almost worked until I realized we have exponentials and those are giving me numbers instead of the correct value.
16:40:11 <MaRakow_> MaRakow_ has joined #CSS
16:40:26 <MaRakow_> Zakim, [Microsoft.a] is me
16:40:26 <Zakim> +MaRakow_; got it
16:40:29 <BradK> Infinity symbol for media query: ∞
16:40:39 <MaRakow> MaRakow has left #css
16:40:45 <dael_> TabAtkins: This just screws it up. Certain hex numbers just won't show up right. We have two choice. a) we call it a failure and we have have wierd special purpose token.
16:41:08 <dael_> TabAtkins: B) we accept that the current syntax is hosed and invent a new syntax. specify the old for backwards compat, but with a strong warning not to use it.
16:41:19 <dael_> TabAtkins: My suggestion is just replacing the + with a -
16:41:32 <dael_> TabAtkins: simonsapin most wanted to comment on this, but I want other opinons.
16:41:48 <adenilson_> adenilson_ has joined #css
16:41:53 <dael_> TabAtkins: You can write a unicode as U+ or U- and we say don't use U+
16:42:06 <dael_> Florian: and you mean only fully support it for lagacy?
16:42:08 <dael_> Florian: Yeah.
16:42:14 <dael_> Florian: What about webcompat?
16:42:44 <dael_> TabAtkins: I don't know, but I could ifgure it out. It's not hard to find all the ranges in unicode that show up. We can see if there's stuff that would trigger this. I should get someone to help me run that query.
16:42:56 <dael_> TabAtkins: Assuming it shows up with no webcompat, what do we prefer?
16:43:15 <Zakim> +??P25
16:43:20 <dael_> TabAtkins: And if there's no strong opinion, I'll wait for SimonSapin to get out of his meeting and wait for the results.
16:43:24 <adenilson_> Zakim, ??P25 is me.
16:43:24 <Zakim> +adenilson_; got it
16:43:43 <glazou> Zakim, mute me
16:43:43 <Zakim> glazou should now be muted
16:43:44 <dael_> Florian: Uses of unicode ranges that happen to be scientific notation aren't that common, but the selectors aren't what common either.
16:44:05 <dael_> TabAtkins: We know selector breakage happens because there's a MOzilla bug report. We'll see if we'll cause any breakage if we make this change.
16:44:14 <dael_> Florian: My guess is they're both rare and both used.
16:44:33 <dael_> plinss: My thoughts are if we're going to have wierd behavior I'd rather have it in places where unicode-ranges will occur.
16:44:44 <jdaggett> this is entirely an edge case
16:44:44 <dael_> TabAtkins: That's my opinion too. So you're leaning to option B?
16:44:54 <jdaggett> u+a breaks, u + a won't
16:45:16 <dael_> plinss: Yeah. I'm also concerned that you're proposing these as the only two solutions and I canthink of more. You special case a unicode where if it is in a selector you have to break it down.
16:45:24 <dael_> TabAtkins: That doesn't work well because you have to recombine.
16:45:41 <dael_> plinss: It's not pretyt, but it is possible.  If you know it's a unicode token treat it as a string.
16:45:50 <dael_> TabAtkins: That's currently not allowed in the syntax spec.
16:46:16 <dael_> TabAtkins: Yeah, so I had thought of those ideas and rejected them.
16:46:23 <dael_> plinss: I'm happy to wait for Mozilla feedback
16:46:29 <dael_> Topic: an+b selectors
16:46:34 <glazou> Zakim, unmute me
16:46:34 <Zakim> glazou should no longer be muted
16:47:29 <dael_> TabAtkins: Danial Tan suggested allowing a comma seperated list of an+b in the selectors that allow that. It's fine grammatically and works great for nth of type. The complication is there are a few places you could comma seperat in child. The easiest way is saying that the entire an+b piece has to be comma seprated
16:47:34 <tantek> my initial feeling is it's not worth it
16:47:41 <dael_> TabAtkins: Or we reject the whole thing, Daniel came back and said ti might not be worth it.
16:47:51 <bkardell_> +1 this is pretty minor sugar - there are bigger fish to fry
16:48:00 <dael_> glazou: As you said, I understand the request and the use case, I'm not so sure the number of people using it is worth the impl time.
16:48:02 <tantek> exactly what glazou said
16:48:13 <fantasai> +1 to what glazou said
16:48:14 <dael_> glazou: I have no real technical objection, we can solve the issues, but is it worth it?
16:48:28 <tantek> consensus on rejection then?
16:48:28 <dael_> TabAtkins: That's my conclusion too. I'm comf with rejecting until more author need.
16:48:31 <dael_> Rossen: Agreed.
16:48:40 <dael_> Florian: I like it put can live without
16:48:44 <Zakim> -antonp1
16:48:47 <Florian> s/put/but/
16:48:52 <MaRakow> MaRakow has joined #CSS
16:49:00 <dael_> TabAtkins: I'm fine to reject an+b comma seperation w/o predjudice
16:49:03 <dael_> RESOLVED: reject an+b comma seperation w/o predjudice
16:49:18 <dael_> Topic: fixed z-index interop issue
16:49:31 <dael_> gregwhitworth_: We don't have the people we need on the call, I think.
16:49:56 <Zakim> +antonp1
16:50:17 <dael_> gregwhitworth_: We don't really, Blink, Edge and Webkit agree. The only people who may reject is Gecko. They started hitting some of the things that made us bring this up, but they're the ones that will be affected still.
16:50:22 <dael_> plinss: Okay. Deferred.
16:50:50 <dael_> Topic: proposal to modify inline-block with non-empty block...
16:51:11 <dael_> TabAtkins: That was from koji, but it was before we had control over baseline more so maybe we should refine. I don't have strong opinions on it.
16:51:20 <dael_> TabAtkins: I defer to fantasai
16:51:24 <Florian> +1 to defering to fantasai
16:52:01 <dael_> TabAtkins: This is okji suggestion to make inline-block different in the presenece of different baselines.
16:52:30 <dael_> fantasai: I'm happy to do whatever makes the most sense to the people who use it. If he thinks that we should change it, I'm happy to do so, but I need to dig in more.
16:52:46 <dael_> fantasai: Do they want to be central aligned to first or last baseline, or be centered?
16:52:58 <dael_> TabAtkins: I don't know. I think we should look at the e-mail more and deal with it on the ML.
16:53:00 <dael_> fantasai: Yeah.
16:53:03 <dael_> TabAtkins: Okay.
16:53:17 <dael_> plinss: Okay, we'll take that back to the list.
16:53:37 <dael_> Topic: Elements and nested scrollers
16:53:50 <dael_> smfr: Should I summerize?
16:54:33 <dael_> smfr: This is with scrool-snap-point. If you haev an overscroll and has position absolute with a containing block, but it's container is outside the scroller so it seems wrong to spec that scroll-snap-points with elements will take position from the absolute things.
16:54:46 <dael_> smfr: I think it needs to be reorded to talk about an in-block.
16:55:01 <dael_> ??: I've been going through and I'm trying to wrap it all into one thing.
16:55:08 <dael_> smfr: Do you expect a new ED?
16:55:08 <glazou> s/??/MaRakow
16:55:12 <fantasai> s/dig in more/dig into the machanics/
16:55:14 <dael_> MaRakow: I'm working through it now.
16:55:24 <dael_> smfr: The other issue is if it's independant of x and y
16:55:28 <dael_> TabAtkins: I think they are.
16:55:58 <dael_> MaRakow: One thing we brought up previously is if you should have the ability of non-grad snap points. There was some interest in that, so I'm wondering if there's a way to satisfy both approches.
16:56:12 <fantasai> Maps is a use case for snap points in 2D
16:56:14 <dael_> smfr: The non-grid worries me because the user case of scrolling and suddenly getting pulled sideways
16:56:58 <dael_> MaRakow: Yeah, right now the manditory snap points are implying that it makes no sense to have scroll and a non manditory point. With that interp it would make sense to move in both direction. I can see a way that makes sense with nested columns and rolls.
16:57:29 <dael_> smfr: It could be where you allow diag but if you're scrolling sideways, your locked on that axis. Maybe the spec should say more on how it moves on each axis.
16:57:38 <dael_> MaRakow: Do you have a a motivating story we could use?
16:57:55 <dael_> smfr: The typical brick wall style layout that an image designer was trying to use. It's not written.
16:58:13 <dael_> TabAtkins: Like the typical google image search. It fills in with what it needs.
16:58:21 <dael_> Rossen: So are we expecting a WD?
16:58:33 <dael_> MaRakow: I'll be coming up with ways to satisfy both scenarios. That's the idea.
16:58:40 <Zakim> -adenilson_
16:58:44 <dael_> TabAtkins: Sounds good.
16:58:51 <dael_> plinss: So we're jsut waiting for spec prose?
16:58:57 <Zakim> -[Bloomberg]
16:59:02 <dael_> MaRakow: Yeah, I need a little bit of time to work through feedback.
16:59:05 <dael_> Topic: CSS 3 UI
16:59:10 <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html
16:59:25 <dael_> Florian: Just something worth mentioning, I'd like fantasai and maybe other people to reply to that e-mail
17:00:00 <dael_> Florian: We resolved to add pre-wrap auto to level 3.  The pre-wrap whiespace for level 4 is tricky.  There's a suggestion in the mail, look at it and reply.
17:00:08 <dael_> s/CSS 3 UI/CSS Text
17:00:19 <Zakim> -smfr
17:00:20 <Zakim> -Plh
17:00:20 <Zakim> -TabAtkins
17:00:21 <dael_> plinss: Okay, that's the top of the hour. Thanks everyone and we'll talk next week.
17:00:21 <Zakim> -[IPcaller.a]
17:00:21 <Zakim> -MaRakow_
17:00:22 <tantek> thanks!
17:00:25 <tantek> and by Zakim
17:00:26 <Zakim> -Bert
17:00:27 <Zakim> -Florian
17:00:27 <Zakim> -BradK
17:00:29 <Zakim> -[IPcaller]
17:00:29 <Zakim> -antonp1
17:00:30 <Zakim> -myles
17:00:30 <Zakim> -glazou
17:00:32 <Zakim> -antenna
17:00:33 <Zakim> -plinss
17:00:35 <Zakim> -[Microsoft]
17:00:36 <Zakim> -tgraham
17:00:37 <Zakim> -tantek
17:00:39 <Zakim> -dael
17:01:03 <Zakim> -dauwhe
17:01:05 <Zakim> -BrianKardell
17:01:20 <Zakim> -MikeMiller
17:01:24 <Zakim> -[IPcaller.aa]
17:01:29 <Zakim> -hyojin
17:01:46 <Florian> s/pre-wrap auto/pre-wrap-auto/
17:02:08 <Florian> s/to level 3/ to level 3, and pre-wrap-trim to level 4/
17:02:45 <Florian> s/is tricky/is tricky because white-space becomes a shorthand, and it's not quite clear how to split these values between the longhands/
17:03:03 <Florian> s/There's a suggestion/There are some suggestions/
17:06:29 <Zakim> disconnecting the lone participant, Lea, in Style_CSS FP()12:00PM
17:06:30 <Zakim> Style_CSS FP()12:00PM has ended
17:06:30 <Zakim> Attendees were plinss, +1.479.764.aaaa, Florian, glazou, smfr, Plh, +1.631.398.aabb, antenna, [IPcaller], dauwhe, BrianKardell, hyojin, +1.908.982.aacc, dael, +93016aadd, antonp1,
17:06:31 <Zakim> ... myles, +1.281.305.aaee, TabAtkins, BradK, Rossen, adenilson, tgraham, MikeMiller, Bert, Lea, tantek, [Bloomberg], [Microsoft], MaRakow_, adenilson_
17:10:47 <Ms2ger> Ms2ger has joined #css
17:14:25 <Florian> Florian has joined #css
17:14:38 <Florian> Florian has joined #css
17:15:39 <dholbert> dholbert has joined #css
17:15:45 <Florian> Florian has joined #css
17:16:50 <Florian> Florian has joined #css
17:18:56 <smfr> smfr has left #css
17:28:51 <renoirb> renoirb has joined #css
17:31:30 <adenilson> adenilson has joined #css
17:42:47 <tantek> tantek has joined #css
17:56:25 <renoirb> renoirb has joined #css
18:00:23 <JohnMcLear> JohnMcLear has joined #css
18:03:16 <jdaggett> jdaggett has joined #css
18:10:10 <tantek> tantek has joined #css
18:15:11 <dauwhe> dauwhe has joined #css
18:28:39 <myles> myles has joined #css
18:45:23 <tantek> plh: how long do you think it takes on average between WG resolution to publish CR, and the CR showing up on /TR ? and how can we shorten that time?
18:46:05 <Ms2ger> Months, because people forget
18:51:02 <tantek> Ms2ger - when was the last time it took months? which WG?
18:51:39 <Ms2ger> CSS
18:51:46 <Ms2ger> I don't remember which, but fantasai might
18:54:26 <tantek> ugh
18:55:04 <plh> tantek, I don't have the stats for CSS
18:55:07 <SimonSapin> SimonSapin has joined #css
18:55:28 <plh> ideally, it shouldn't take more than 10 days
18:57:33 <Florian> Florian has joined #css
18:57:36 <plh> I try to ensure that the transition requests get responded within 7 days
18:59:16 <Florian> plh: I'll try to prepare the request tonight or tomorrow at the latest for CSS-UI. Since it's a first time, I might send it to you (or to Chris or Bert) for review before sending it for real, depending on how confident I'm with the result
18:59:21 <jdaggett> jdaggett has joined #css
18:59:58 <Guest53> Guest53 has joined #css
19:00:12 <plh> Florian, sure
19:02:02 <Florian> Florian has joined #css
19:07:09 <Zakim> Zakim has left #css
19:18:13 <Florian> Florian has joined #css
19:30:51 <dauwhe_> dauwhe_ has joined #css
19:36:32 <jdaggett> jdaggett has joined #css
19:38:15 <svillar> svillar has joined #css
19:45:04 <antonp> antonp has joined #css
19:48:41 <SimonSapin> TabAtkins: U- would be in addition to the legacy U+ syntax, right? That doesn’t solve the u+a selector issue
19:49:55 <Florian> SimonSapin: The suggestion is to support the u+a syntax only throught Tab's work-around reinterpreting existing tokens, not the actual unicode range token. It would fail in some cases, and in those cases, you're supposed to use the u- syntax
19:50:10 <SimonSapin> ugh
19:50:17 <antonp1> antonp1 has joined #css
19:50:37 <Florian> so you got a mostly-but-not-always working legacy syntax, or a new clean one.
19:51:18 <SimonSapin> can’t we just slap some quotes on there? unicode-range:  "U+04e4";
19:51:27 <Florian> Authors should use the clean new one. Legacy content would still work. Most of the time.
19:51:38 <SimonSapin> but the new clean one is ugly :p
19:51:45 <SimonSapin> Unicode uses U+ everywhere
19:52:35 <tantek> tantek has joined #css
19:54:49 <Florian> I'm in favor of parentheses.
19:55:09 <Florian> Or we can even throw in a function if we want to be verbose. u("04e4") unicode("u+04e4") unicode-character("icanhaz-u+04e4")
19:55:30 <SimonSapin> hahaha "you'll need to enable Java on your browser" https://www.w3.org/2006/tools/wiki/InstallingWebEx
19:55:36 <Florian> :)
19:55:39 <Florian> Saw that
19:55:50 <SimonSapin> that’s not happening
19:55:53 <Florian> Even my bank no longer asks for that.
20:00:56 <antonp> antonp has joined #css
20:09:02 <Guest53> Guest53 has joined #css
20:15:56 <TabAtkins> SimonSapin: "slap some quotes" is identical to "u-f00" in terms of handling back-compat.
20:41:37 <renoirb> renoirb has joined #css
21:04:47 <adenilson> adenilson has joined #css
21:12:08 <liam> SimonSapin, it's OK, CSS is turing complete, we'll rewrite the audo codec that way
21:12:14 <liam> and no longer need Java :)
21:18:40 <SimonSapin> liam: careful, your jokes might come true :) https://people.xiph.org/~xiphmont/demo/daala/player-demo.shtml
21:19:35 <liam> Loading... it says
21:20:16 <liam> eep
21:20:23 <liam> moving pictures! scary!
21:20:50 <renoirb> renoirb has joined #css
21:24:20 <SimonSapin> with a js codec :)
21:35:40 <lajava> lajava has joined #css
21:35:44 <tantek> tantek has joined #css
22:04:57 <w3c-webi> w3c-webi has joined #css
22:05:11 <liam> SimonSapin, but that's JS, not CSS
22:05:16 <dbaron> dbaron has joined #css
22:07:08 <tantek> tantek has joined #css
22:22:03 <fantasai> I think requiring quotes around unicode-range is less weird than most of the other options presented here...
22:22:39 <fantasai> doesn't solve back-compat, though
22:25:03 <Florian> Florian has joined #css
22:26:43 <SimonSapin> agreed, and agreed
22:32:41 <w3c-webi> w3c-webi has left #css
23:10:04 <TabAtkins> Strings or idents, either work for me, they're functionally equivalent.  Strings just let us retain the "+" in the syntax.
23:12:44 <tantek> tantek has joined #css
23:17:26 <TabAtkins> I suppose it's easier to explain "put it in strings, or you might get weird behavior", since font names have the same problem.
23:24:59 <SimonSapin> right