14:43:42 RRSAgent has joined #css 14:43:42 logging to http://www.w3.org/2015/07/01-css-irc 14:43:57 Zakim has joined #css 14:44:12 It's Zakim! 14:45:18 yeah the bot still exists 14:45:37 but not connected to the bridge 14:46:01 Aw 14:46:24 I think the various w3c confcalls this week are going to be a bit messy :-D 14:46:44 RRSAgent, make logs public 14:46:54 Still glad I don't attend any :) 14:47:02 eh 15:42:02 SimonSapin: Yes, use `Boilerplate: omit feedback-header` 15:45:43 antenna has joined #css 15:49:19 dauwhe_ has joined #css 15:53:48 dael has joined #css 15:58:40 Present+ glazou 15:59:28 Present+ dael 15:59:32 ScribeNick: dael 16:00:07 Agenda+ Gecko intends to ship css-logical-props (among other things) https://groups.google.com/d/msg/mozilla.dev.platform/zQgw_4WeBkc/oyVZ5-k1D6cJ 16:00:27 Present +plinss 16:01:01 bcampbell has joined #css 16:01:11 smfr has joined #css 16:01:15 Present+ antonp 16:01:32 alex_antennahouse has joined #css 16:01:34 Present+ astearns 16:01:41 gregwhitworth has joined #css 16:01:43 Present+ SimonSapin 16:02:26 ChrisL has joined #css 16:02:33 is passcode the same? having trouble. 16:02:50 bcampbell: are you using the webex phone number? 16:03:00 bcampbell, not it is a new number and new system today, see agenda 16:03:11 bcampbell: https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0206.html 16:03:11 ok, sorry, thanks 16:03:16 Present+ smfr 16:04:03 attendee number? does it matter? 16:04:45 fantasai, no 16:05:08 dbaron has joined #css 16:05:19 Ah, I'm in. 16:05:23 Present+ tabatkins 16:05:25 Present+ leaverou 16:06:17 Present+ Rossen 16:06:27 Present+ fantasai 16:06:39 Present+ dbaron 16:07:13 glazou: Let's try to start 16:07:34 glazou: There were a few additions. I saw a msg from Florian about the backlog and one from Koji. 16:07:42 Present+ bcampbell 16:08:03 SimonSapin: Gecko is intending to ship css-logical-properties which isn't a WD yet, it's full of issues 16:08:10 glazou: And you'll ship the full of issues? 16:08:16 SimonSapin: I'm not sure exactly what. 16:08:27 ??: Unprefixed? 16:08:30 SteveZ has joined #css 16:08:32 https://groups.google.com/d/msg/mozilla.dev.platform/zQgw_4WeBkc/oyVZ5-k1D6cJ 16:08:39 s/??/Florian/ 16:08:57 fantasai: If any issues are on ww-style with Moz prop resolution somewhere it's good to have that. Otherwise I'll get around to connecting everything later 16:09:02 glazou: Was that a q or an announce 16:09:18 SimonSapin: I wanted to bring to the groups attn. I don't know if it's a problem to ship early 16:09:34 MaRakow has joined #CSS 16:09:45 dbaron: The pieces we're planning on shipping aren't the pieces with the problem. We're not shipping the shorthand on logical. I think we're shipping margin-padding, border-* and one other, I think. 16:09:50 glazou: Behind a flag? 16:09:56 dbaron: No. Only longhand. 16:10:03 dbaron: It's been behind a flag for a year. 16:10:08 Present+ Bert 16:10:22 Florian: If you want to ship, why not help finish the spec first to be sure things won't break. I think that's what we generally said we'd be doing. 16:10:58 dbaron: Fundimentally b/c we're the last browser to ship this, ie veritical text support, and shipping it depends on logical prop for us. 16:11:05 dbaron: And we'd really like to get it shipped. 16:11:29 glazou: We're not going to do this right discussion right now. Thanks for the announcement. I suggest disucssing the furture of the spec on the ML. 16:11:30 bkardell_ has joined #css 16:11:35 glazou: Anything else before we really start? 16:11:45 Topic: fixed z-index interop issue 16:11:55 Present+ GregWithworth 16:11:55 gregwhitworth: Basically, is dbaron there? 16:11:56 dbaron: Yes. 16:12:31 the logical props we have are margin-*, border-*, padding-*, top/right/bottom/left, (min-/max-/)width/height 16:12:34 andrey-bloomberg has joined #css 16:12:46 gregwhitworth: We've been pushing htis off a bit. Blink, WK and Edge basically give anything with z-index it's own layer but the spec says it should work like abspos and not get a new layer. We want to change the spec so that it represents the reality of the other browsers. Marco has been seeing issue in mobile 16:12:55 gregwhitworth: I want to get your input and see if you're against it. 16:13:06 gregwhitworth: position-fixed, not z-index. 16:13:11 dbaron: I think I'm okay with it. 16:13:26 smfr^: you mean position:fixed getting a stacking context 16:13:58 Rossen: It's worht mentioning that I had, when we pushed this early in Edge dev phases I added this behind a flag to see if anyone complains, we didn't hear any but we do know of a number of pages that will be broken when the opp. is broken, when fixed pos don't create stacking 16:14:38 Rossen: The interesting bit of info is during Sydney F2F someone from Chrome, I think Rick Byers, said they want to revert and support a partical context on z-index. I'm okay either way, with our impl both are possible, but I'd prefer to lock on one of those. 16:14:48 Rossen: If anyone from Chrome can comment that would be great. 16:15:10 TabAtkins: I can ask, but I think it's that our recent improvements make it possible to go back to partial. I don't think there's anything wrong with full stacking context. 16:15:32 smfr: I'd prefer we maintain a full stacking. OUr painting can't deal with interweaving. 16:15:42 Rossen: So if we decide to support partial, you won't be able to for technicaly. 16:15:57 smfr: We've been shipping with fixed for 2 years so going back would be a compat risk for us 16:16:42 smfr: So it sounds like w'ere back to the question as to if Gecko will make position: fixed create a stacking context. 16:16:49 dbaron: I think it's fine given that it's compat 16:17:07 Florian: As an author I think this is sufficently confusing and having the semi-stacking makes it worse. If we can avoid it's better. 16:17:26 gregwhitworth: So can we resolve on this? I don't know if we put it in 2.2 or what, but can we call for resolution? 16:17:36 glazou: If everyone agrees to impl the same thing we can resolve 16:17:53 Present+ koji 16:17:58 Rossen: I missed it, did we resolved to make position: fixed a full stacking context, always? 16:18:03 Florian: We seemed to be about to 16:18:22 gregwhitworth: It seems there's no disagreement. dbaron is saying it's okay. If no one is against it I say we resolve. 16:18:43 Present+ Florian 16:18:48 Rossen: Only reason I brought it up is there was impl consideration from Chrome and I don't want to have the same conversation in 6 months with the opp. arguement. 16:19:15 TabAtkins: There's nothing technical making stacking context hard. There's something technical with making partial hard, but full isn't a technical issue. I think we'll be fine. 16:19:24 Rossen: Sounds great. So we can resolve on it and that's it. 16:19:27 glazou: Obj? 16:19:48 smfr: Clarification, if a position fix element has a transformed ancestor and it doesn't behave in a fixed way, does this apply? 16:20:05 smfr: I want to clarify if it'st he position: fixed itself or having the containing block be the viewport. 16:20:10 TabAtkins: I think it's just position: fixed. 16:20:15 smfr: Okay, that's fine. 16:20:40 Rossen: That sounds really good. Tieing it down is better than looking up ancestry 16:20:41 RESOLVED: make position: fixed a full stacking context 16:20:55 gregwhitworth: So how does this make it into the spec? 16:21:01 Rossen: I can add it to position level 3 16:21:12 fantasai: It needs to go into level 2. We should action Bert to update. 16:21:15 Rossen_ has joined #css 16:21:26 antonp: Isn't this already in level 2? 16:21:40 Rossen: I'm not sure why you think that's the case, but it's not true. 16:21:41 (Is it just a clarification?) 16:22:07 fantasai: In 2.1 position: fixed is considered a stuck catagory of abspos 16:22:25 antonp: I think I'm thinking of something else. I think I'm wrong. I'll write to the list if I correct myself, but I think I'm wrong. 16:22:28 tommyjtl has joined #css 16:22:54 Bert: For CSS 2 does it need a change? 16:23:21 Rossen: I think there's agreement you have a note in CSS 2.2. That was fantasai arguement and I don't have an opinion. I will add the requirement to CSS 3 positioning. 16:23:26 fantasai: It needs to go into both. 16:23:43 ACTION Rossen add position: fixed as s full stacking context to positioning 16:23:43 Created ACTION-698 - Add position: fixed as s full stacking context to positioning [on Rossen Atanassov - due 2015-07-08]. 16:23:55 Bert: I can look at Rossen text and create an ereata 16:24:03 Rossen: It'll be one sentence and we can use in both 16:24:12 ACTION bert to take Rossen text and export it to level 2 16:24:12 Created ACTION-699 - Take rossen text and export it to level 2 [on Bert Bos - due 2015-07-08]. 16:24:38 Topic: aggregating CSS modules 16:24:48 glazou: We started the discussion, but I'm not sure we went far. 16:24:57 astearns: I started it to prod plinss and TabAtkins 16:25:28 TabAtkins: We keep being lazy about creating hte index of all things in CSS> Altering bikeshed so that it can make a huge document is something I haven't done. I've been doing bikeshed issues for a bit and I might get there. 16:25:42 Rossen_away: SVG has been asking for the same thing. They've been waiting for this so they can switch to bikeshed. 16:26:08 TabAtkins: It'll be on my list. I think I have it as an issue. 16:26:14 https://lists.w3.org/Archives/Public/www-style/2015Jun/0160.html 16:26:17 Topic: Language specfic support... 16:26:48 Florian: This is somethign I was wondering about. We have @supports, but it doesn't quite work for hyphenation b/c when the browser impl hypenation it doesn't do it for all the browsers in the world. 16:27:11 Florian: If you think something is ugly without hyphenation, you need to know if it supports hyphenation on the languague you're using for the leemnt. 16:27:45 Rossen: IIRC it was vollick@ who said he felt guilty about us insisting on a full stacking context for position:fixed now that our implementation no longer requires it. I.e. we recognized a fundamental flaw in WebKit/blink compositing architecture (that causes correctness issues elsewhere) and are close to finally eliminating it. 16:27:46 Florian: I'm not saying that's enough to give nice hyphenation, but it's a datapoint that's useful. I was thinking we might want to introduce either a special syntax or a psuedo class that you can tag onto any element. 16:28:06 Florian: The language that it uses, if it's one the browser can hyphenate than you use that to style. 16:28:43 Florian: A second part is if you want to turn on justification but only if the broswer can do it nicely, which might mean hyphens for some languages, but not all. Trying to detect it sounds useful, but it's hard to tell what 'nice' means. 16:29:03 Florian: I think they hyphenation case is less fuzzy. If it's supported is non-ambig 16:29:29 TabAtkins: I agree that multiple ambiguous hints aren't something we want. The hyphenation is unambig. It sounds reasonable and I see the usecase. 16:30:06 Florian: The diff between the syntaxes is if you're using @support you can inside that have any number of rules and combine. What's nicer with pseudo-class, in @supports you have to ask about one language specifically. 16:30:08 MaRakow_ has joined #CSS 16:30:28 Florian: That makes me lean toward the pseudo class. You have multiple declariations, just on rule block. 16:30:35 s/therefore/therefore unsure/ 16:30:42 TabAtkins: This is classically a MQ type thing. That seems to be more natural, but I have to think on it. 16:31:18 astearns: I'm not entirely sure that's enough justification for this new feature. If a UA doesn't support a lang for hyphenation, maybe that's a bug. As UA gets more sophisticated the need deminishes. 16:31:37 Florian: I doubt we'll reach a point where all UA support hyphens for all lang. It's too large a set. 16:31:47 astearns: So you're talking about a stylesheet for near infinante rules? 16:31:54 q+ 16:32:02 q+ 16:32:19 Zakim, ack Rossen_ 16:32:19 I see glazou on the speaker queue 16:32:23 Florian: If you're creating something where you expect a lang tag and you want to go with : or - depending on what's supported, we should be able to do that. There won't be a browser that knows all local lang. 16:33:22 https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens#Notes_on_supported_languages_2 16:33:23 Rossen_: I'm a bit hesitant for a feature like this. When we were adding conditional lang abilities for windows apps, we had similar problems where content written for RTO lang or hosted in RTO it needed to adapt properly so on/off buttons are right. Hypheantion in that respect I don't see as an outlyer in lang-specific behaviour 16:33:40 Rossen_: It's also a minor use case. Making sure a huge exceptionf ro a minor feature is a stretch. 16:33:40 s/RTO/RTL/ 16:34:19 Rossen_: The fallback here isn't really that bad. The third thing I wanted to point out, we have a service that we use which is shared across many components. Simply booting the service is quite costly so doing it per element is crazy. 16:34:19 q+ 16:34:23 Zakim, ack me 16:34:23 I see Florian on the speaker queue 16:34:57 glazou: Doing this on a per element basis, as soon as you have th einfo for a given lang you can cache. You don't hyphenate differently between elements. As soon as the info is aquired you have it for the whole session. 16:35:01 Rossen_: Does that go for mixed lang? 16:35:18 glazou: This is related to my question. Florian mentioned the pseudo class, but does it take an arguement? 16:35:27 Florian: It matches the lang of the element. No arguement. 16:35:41 glazou: I don't see the problem. in 99.9% of cases the language will be the same. 16:36:06 Florian: and if you have a bunch of lang this isn't more costly. If we didn't have it you would apply hyphens and have to turn on the engine anyway. 16:36:23 glazou: I understand the perf concern, but we should stick to the usefulness of the feature. THere's an issue there. 16:37:00 Florian: I don't think it's majorly useful, but the same is true of hyphenation. Hypenation itself is more difficult to use if you can't know if you have it. You can't use @supports, so you're stuck right now. 16:37:11 Florian: Narrow columns without hyphenation can be ugly so it's reasonable 16:37:20 TabAtkins: There are layout types you only want with hyphenation 16:37:50 Florian: And you only want this if you have a lang that doesn't need hyphenation or if you can have hyphenation. We can have the broswer tag if it doens't need it. 16:38:19 glazou: So the official French typographic rules, which we've used in the past, I've seen some prose about not using hyphenation in that case. BUt the use-case exists. 16:38:32 Florian: You mean not using justification if there's not hyphenation? 16:38:35 glazou: Yes. 16:38:40 Rossen_: Can you find a reference to that? 16:38:47 glazou: Yes, it's at home, but I will. 16:39:16 glazou: I'm not so sure the cost of impl for this is expencive, I think it's straight forward. It could solve a case in some lang for layout. I feel, personally, that we should investigate. 16:39:22 glazou: What do others think? 16:39:52 Rossen_: From impl POV this will be low on the stack. I can see the completeness arguement from Florian. If there are use cases that can hit somewhere...but cost to benefit is off. 16:39:56 fantasai: I agree w/ Rossen_ 16:40:00 glazou: Other impl? 16:40:11 I don't have a strong opinion either way. 16:40:15 TabAtkins: I'm not able to speak on this now. 16:40:29 smfr: I'm not aware we've had any requests on this so I think it's low priority 16:40:39 glazou: Florian would you keep some prose under the radar for now? 16:40:54 Florian: Yes, I can see how it's not high priority, even though it's not wrong. I'll keep the text. 16:40:55 https://lists.w3.org/Archives/Public/www-style/2015May/0153.html 16:41:09 Topic: CSS text-decor Example 3 16:41:20 tantek has joined #css 16:41:21 fantasai: Currently we have an auto value and an under value anda right value. 16:41:29 fantasai: If we look at the spec [link]... 16:41:34 http://dev.w3.org/csswg/css-text-decor-3/#text-underline-position-property 16:41:58 (Maybe there is way to generalize this: provide alternative styles based on whether each of them can deliver a certain quality, where "quality" can be an aggregate or a set of detailed typographic measurments...) 16:42:25 fantasai: You can combine under with left or right so you can have different behavior from vertical and left and right. The feedback we got was that we want to have, there's a suggestion the UA stylesheet should have a rule taht sets the underline to the correct side for Chinese and JApanese 16:42:36 Japanese and Korean on right, Chinese on left, no? 16:43:00 tantek, https://lists.w3.org/Archives/Member/w3c-css-wg/2015AprJun/0206.html 16:43:02 fantasai: That's in the spec as a recommedation. But b/c you can only combine right with under is it causes a problem. The suggestion is to let auto and under both be combined with left or right 16:43:07 fantasai: dbaron is correct 16:43:34 ??: I'm not clear about what the symantics is 16:43:44 s/??/Koji/ 16:43:52 koji: I'm unclear about how to interpret another value 16:44:06 fantasai: That is another issue. if left or right is spec without the other key word, what do we do. 16:44:15 koji: Or if under is spec, is it left or right. 16:44:19 fantasai: It's just going to be left 16:44:26 Rossen_: And under start won't work? 16:45:01 fantasai: It has less to do with start and end of block and more with text orientation. for ex Mongolian the underline will be on the right side, even if it's the end side. 16:45:31 fantasai: It'st he end side on CJK. under if you spec by itself it means it goes on that side of the text. left and right give a direction, either the left or right side. 16:45:44 w3c-webir has joined #css 16:45:51 Rossen_: In that case, I'm okay with auto. It's magic enough for people to get it from the get go. It's better off to be left as magic. 16:45:59 glazou: Other opinions? 16:46:19 glazou: Any disagreement? Objection? 16:46:48 koji: I'm okay with the syntax, but from the original proposal I can't read what they're expectation is for some of the values. I want to confirm that they think it means. 16:46:51 1. Do we allow auto to combine with left|right 16:46:54 fantasai: There's two issues. [types] 16:47:07 Present+ tantek 16:47:14 2. If left | right is specified alone, is the behavior in horizontal text under or auto 16:47:37 fantasai: I'm gussing it should be auto since that's the initial value 16:47:53 koji: Does that imply when under is spec left or right is auto? 16:48:11 fantasai: Under has a meaning that isn't left or right, it means it's on the underside which depends on the text orientation. 16:48:29 fantasai: Most cases it will be left, but in sideways-left ir would be right. 16:48:37 koji: Japanese is right. 16:48:38 fantasai: Yes. 16:48:48 Rossen_: When is left and right used when auto does it when it's needed. 16:48:50 fantasai: It doesn't. 16:49:03 koji: auto applies only for horizonal, I think is what she's saying. 16:49:21 fantasai: We discussed having auto adjest based on the lang and we decided not to have it change based on the language. 16:49:41 fantasai: Let's all look at the word alphabetic. 16:50:25 fantasai: There's a p and the line crosses the tail. That side of the text is the underside. If we rotate the text 90 counterclockwise, the underline is on the right side. clockwise it's on the left. 16:50:54 tantek has joined #css 16:51:15 fantasai: Auto puts the underline on the side of the text that's the bottom after you rotate the text. Since Japanese and Korean have their typesettings rule place it on the right side of the text, we added a UA rule that sais for those two lang change the value so that in veritical text it is on the right side 16:51:52 koji: We allow auto to adjust beween CJK and non-CJK for horizontal. I also requested not to have UA stylesheets request what you want. Like that you said in the ML. 16:52:00 <|orion> |orion has joined #css 16:52:20 glazou: Amoung the two people discussing, I'm not seeing consensus. I don't know what to do with your discussion now. 16:52:35 koji: I think we can resolve syntax now. We can continue the semantics discussion on the ML 16:52:40 glazou: fantasai? 16:52:49 fantasai: I think that that's fine. 16:52:55 Rossen_: Is the ML discussion happening? 16:53:42 fantasai: ONe thing that's confusing is if we change the meaning of auto to switch sides, not jsut adjust the position. It doesn't flip to the other side of the text, it's always on the under side of the text. If we change auto to also place on the over side it doesn't make sense to combine it anymore. 16:54:28 koji: I asked for clarification yesterday on the list. Maybe it's worth waiting a bit more to see if the discussion continues. 16:54:32 glazou: Okay. Done deal. 16:54:40 koji: We can resolve the syntax change. 16:54:55 fantasai: I think if we're changing the sematics of auto, we may want to rethink the syntax. 16:54:58 koji: Okay. 16:55:10 https://lists.w3.org/Archives/Public/www-style/2015Jun/0347.html 16:55:13 Topic: Splititng CSS-speech 16:56:19 Big question here is who are the implementers that have any interest at all? 16:56:20 fantasai: I was thinking speak and speak-as are something we would encourage general authors to us since it lets them control is some text is visable to speech. Such as websites will position stuff off to the weeds so that it's there for speech but you don't want it for visual people. speak could override that so you do display: none and speak: normal and it overrides it. 16:57:02 Without indication of even a hint of implementer interest I'd say it's too low a priority to bother with group time on. 16:57:05 what agent supports css-speech? 16:57:05 shepazu has joined #css 16:57:15 fantasai: That seems like it would be generally useful and be impl without much interaction witht he speech rendering. It seems like that might be useful for general authors, while styling the voice-rate and other things in CSS speech, they're interesting, but it's unlikely authors will take advantage of them in a useful way. 16:57:30 Even *interest* nevermind code. 16:57:31 smfr: I think tantek is making a useful point that there's such little impl it might not be worth talking about. 16:57:49 fantasai: I don't think there's interest in the rest of css-speech, but I think speak and speak-as will be useful. 16:58:11 If even a single implementer speakers up indicating interest in impl, then let's re-assess 16:58:20 fantasai: And might be interesting to implementers, if they were not buried in the rest of speech 16:58:20 it seems to me leonie watson recently told me she couldn't find any if that is worth anything 16:58:21 glazou: I'm not sure we're the best place to know about special application tools. I suggest piging Daniel Veck (?). He was the author and will know about where it's used. 16:58:29 glazou: I'd like him contacted before we move on. 16:58:38 glazou: I can bring it up in a11y task force if that is helpful 16:58:40 Otherwise not worth the time. But agreed with glazou - ok to ask around. 16:58:48 bo_campbell: I'd be interested in understanding this further and getting opinions from screenreader users. 16:58:59 glazou: fantasai do you want me to take an action to contact? 16:59:00 s/Veck/Weck/ 16:59:15 fantasai: I'm mostly interested in what the browsers are doing right now. It seems it would be useful for a11y 16:59:29 Documentation of those use cases would be a good start. 16:59:35 https://lists.w3.org/Archives/Public/www-style/2015Jun/0346.html 16:59:36 ACTION: contact Daniel Weck to see if there's any evolution on speak and speak-as so we can see if we can extract it 16:59:36 Error finding 'contact'. You can review and register nicknames at . 16:59:44 That fantasai mentioned 16:59:47 tantek, look on the web for text-indent: 16:59:51 ACTION glazou contact Daniel Weck to see if there's any evolution on speak and speak-as so we can see if we can extract it 16:59:53 Created ACTION-700 - Contact daniel weck to see if there's any evolution on speak and speak-as so we can see if we can extract it [on Daniel Glazman - due 2015-07-08]. 17:00:07 yes! 17:00:10 Topic: Display WD 17:00:17 +1 to publish 17:00:24 fantasai: I suggest we pub and deal with issues late 17:00:31 fantasai, big neg text-indent is a hack for all kinds of crap. SEO nonsense etc. 17:00:35 RESOLVED: New WD for Display 17:00:52 glazou: Thanks everyone. Sorry if the first day of webex wasn't perfect 17:00:59 tantek: ok, on a page that isn't doing SEO crap :) 17:01:08 Lol 17:01:23 Please mark yourself as present if you didn't already! 17:01:40 present+ 17:01:43 dael: what's your preferred syntax for that? 17:01:45 present+ antenna 17:01:51 present+ MaRakow 17:01:53 Yeah see? 17:01:54 present+ gregwhitworth 17:01:58 did that work? 17:02:03 What they did I think shoudl work 17:02:04 tantek: « Present+ nickname » 17:02:04 Present+ tantek 17:02:14 Present+ MaRakow 17:02:15 Case insensitive? 17:02:19 *shrug* 17:02:21 tantek: probably 17:02:24 One has to ask these things :) 17:02:30 We'll find out :) If nothing else I can pull them out in a text editor. 17:02:52 thanks dael ! 17:03:00 Thanks dael. Report back on the case-sensitivity of our new webex syntax :) 17:03:07 Will do! 17:03:20 tantek: what kind of case insensitivity? (: 17:03:20 dael++ 17:03:40 SimonSapin: present+ vs. Present+ 17:04:03 (Asks the guy with a CamelCase IRC nick ;) ) 17:11:59 smfr has left #css 17:14:41 (this was an attempt at a joke about the Unicode C+F v.s. C+S v.s. ASCII-only discussions) 17:15:30 w3c-webir has left #css 17:16:14 TabAtkins: You publishing or me? 17:18:12 TabAtkins: Fixed the prose of my PR as per your code review. By the way, who do we get css-containment into bikeshed's database of autolinkable things, so that I can rid of pre-anchoring css-containment terms in css-overflow? 17:18:26 Me, I'll do it in a few minutes. 17:18:46 oops, I meant how, not who. but that still works :) 17:18:46 k 17:19:03 TabAtkins: I'm gonna link in the issues mail I sent, and then you can go 17:20:56 TabAtkins or fantasai: Could either of you review this TC before I forget why I wrote it :) https://github.com/w3c/csswg-test/pull/779 17:21:24 I did yesterday - it's good to go. 17:21:40 oh, cool. 17:21:49 Should I click merge, or do you want the privilege? 17:22:09 well, for metadata reasons, It's probably better if you do. 17:22:19 (reviewer != author) 17:29:56 TabAtkins: OK, all pushed 17:30:00 TabAtkins: All set to go :) 17:51:43 Kurisu has joined #css 17:52:19 Florian has joined #css 17:55:19 fantasai: k, i'll get publishing ready 17:55:36 Florian_dinner: Will probably bug you to help with the publishing part. Has your experience been documented in the wiki yet? 17:58:48 myles has joined #css 18:00:07 TabAtkins: he's doing CR publication, this is just a WD 18:00:51 TabAtkins: The process is the same as before, but send a reply to the pubrequest with a zipfile of the prepared publication 18:01:09 Then that should be easy to put into the wiki. ^_^ 18:01:34 Hopefully Echidna will make this process obsolete 18:01:36 :p 18:01:41 it's very annoying 18:07:42 Yus. 18:08:02 I have an issue to dive into Echidna and figure this out. I should probably get on that. 18:08:24 TabAtkins: https://wiki.csswg.org/spec/publish#steps-for-manual-publication 18:08:30 It's... hard, because there's a publication token that's supposed to be secret. 18:08:38 As in, it shouldn't be stored in public repo. 18:09:00 But that means you have to keep around a secret token out-of-band and pass it to Bikeshed every time you want to publish. :/ 18:09:06 Then bikeshed might need a per-person config file 18:10:04 Hm, yeah, that might work. 18:10:26 Annoying that I still have to spam these around all my computers (and "secretly" share them with the other editors of a given spec). 18:10:36 lol 18:11:20 Are the tokens per spec or per spec-editor pair? 18:11:52 nope, per spec 18:11:55 eh 18:11:56 *shrug* 18:12:40 I'm of the mind that the first Echidna CSSWG publication should be done by a Staff Contact, so they can figure out all the kinks, and then we can try it ourselves 18:13:16 And if that works, *then* we can see what happens when tantek tries to publish :PPPPP 18:16:57 Tokens are per spec, yeah. 18:17:04 Plus editor tokens, which are per editor. 18:59:44 renoirb has joined #css 19:05:35 TabAtkins: No, I have not yet documented the CR publication process, I'm waiting for it to succeed first. This has partially happened (Director approved), but it's not actually out yet. 19:24:44 it's pretty much a done deal at this point btw 19:25:01 so you can start documenting the first steps :) 19:25:29 if you want, I can provide more info on what I'm going to do between today and Tuesday 19:25:49 so that your documentation will be more complete 19:26:02 That'd be great, thanks 19:29:33 I'm happy to review your doc once it's up btw 19:30:25 dbaron has joined #css 19:50:29 plh: I'll get to it in the next few days. Lots of balls to juggle right now. 19:50:39 sure, not hurry 19:50:42 no 19:50:53 rego has joined #css 19:51:54 by the way, I cannot access the minutes of the transition call, my credentials don't seem to be enough. Is that expecteD? 19:54:24 it is expected 19:54:41 but there is nothing there 19:54:45 besides ok 19:55:20 sounds important to keep confidential then :) 19:55:46 yes indeed :) 19:58:59 dbaron has joined #css 20:27:38 lajava has joined #css 20:59:19 zcorpan has joined #css 21:50:27 jdaggett has joined #css 22:10:23 dbaron has joined #css 22:32:54 TabAtkins: FYI, Adobe is on summer break - Dirk may be far away from a keyboard at the moment 22:33:07 astearns: "summer break"? 22:33:20 I wonder if that's similar to our "no meetings fortnight" we're in the middle of right now 22:33:28 TabAtkins: the company shuts down on the week of the 4th 22:33:53 most of the XML WGs have always shut down for a month or so in the summer, as it's too hard to get the right people on calls 22:35:00 We don't actively shut down, just declare that no meeting may take place, so people are free to take vacations. 22:35:12 (Or just get some work done for once.) 22:39:04 Ugh, this deltaE2000 algorithm is SO HARD. 22:40:09 oh, for colour difference? 22:41:11 Yeah. 22:41:23 Tho it looks like my actual difficulty is in the rgb->lab conversion. 22:41:34 Which, unbeknownst to me, was *super wrong*. 22:42:25 yeah, GIMP's conversions had some problems too, that have been worked on recently. This stuff is much harder than it seems it ought to be. 22:42:31 (My color library stores everything in rgb, so initializing from a lab and then doing stuff based on lab means converting to/from rgb.) 22:42:56 yeah. 32bit per channel? 22:43:04 JS double 22:43:09 yeah, ok 22:43:36 gimp/gegl these days uses 32bit float 22:43:56 and it wasn't as slow as i'd been afraid 22:45:31 Phew, somehow I'm initializing a Lab as (50, 1, 2) and getting back (50, 5.4, 2.1) 22:45:41 Something about my a calculations is *way* off. 22:45:49 L and b are a little off, but not far. 22:46:24 groovy colour correction curves! 22:50:40 Hmmmmmmmmm, my rgb to lab exactly matches other sample code I'm seeing. Maybe my lab to rgb is wrong? 22:50:59 http://www.brucelindbloom.com/index.html?Eqn_DeltaE_CIE2000.html might be helpful 22:52:18 Yeah, I have the original paper by the deltaE2000 people that I was implementing from. 22:52:29 It just looks like I'm doing some wrong things somewhere in it. 22:53:01 i meant that the calculator there might be useful to test intermediate values & see if you're in the same ballpark, although colour temp, gamma etc make it non-trivial 22:57:25 Where's the calculator? 22:57:41 Oh, on the calc page. 23:01:39 Florian has joined #css 23:23:21 :) yes, sorry, i thought i'd pasted a link directly to it 23:23:33 but it's using frame-based navigation