16:22:43 RRSAgent has joined #css 16:22:43 logging to http://www.w3.org/2014/12/10-css-irc 16:22:48 Zakim, this will be Style 16:22:48 ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 38 minutes 16:22:53 RRSAgent, make logs public 16:24:07 dauwhe has joined #css 16:25:33 dauwhe has joined #css 16:25:36 dbaron has joined #css 16:32:57 dauwhe has joined #css 16:48:23 astearns: should ellipse(at 50% 50%) to ellipse(at 70% 70%) be animate able or not? The spec says “If both shapes are the same type, that type is ellipse() or circle(), and none of the radii use the closest-side or farthest-side keywords, interpolate between each value in the shape functions." 16:48:38 astearns: they are not specified but compute to these keywords, right? 16:50:29 Woohaa. Nice time travel. I'm done checking all messages tagged [css-ui] and [css3-ui] since the the beginning of www-style for issues that are still relevant. 16:50:33 krit: right, and you use the computed value for interpolation. So interpolation between those ellipses is not defined 16:50:51 astearns: thanks! 16:51:06 There's a lot less once you go beyond 2011, but I found one unadressed issue from 2004 from Boris Zbarsky 16:52:54 adenilson has joined #css 16:52:56 dael has joined #css 16:53:50 Zakim, code? 16:53:50 the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou 16:54:22 Style_CSS FP()12:00PM has now started 16:54:29 +dael 16:54:51 ScribeNick: dael 16:54:52 AH_Miller has joined #CSS 16:56:03 lajava has joined #css 16:56:03 liam has joined #css 16:56:05 +philm 16:56:32 +[IPcaller] 16:56:55 +glazou 16:56:56 Zakim, philm is dauwhe 16:56:56 +dauwhe; got it 16:57:09 Zakim, dauwhe has fantasai 16:57:09 +fantasai; got it 16:57:13 +plinss 16:57:19 murakami has joined #css 16:57:54 zcorpan has joined #css 16:58:10 +Florian 16:58:17 antenna has joined #css 16:58:24 -dauwhe 16:58:28 svillar_ has joined #css 16:58:51 +dauwhe 16:58:58 Rossen_ has joined #css 16:59:26 + +97455aaaa 16:59:26 tantek has joined #css 16:59:40 +Stearns 16:59:47 gregwhitworth has joined #css 16:59:51 Zakim, aaaa is me 16:59:51 +antonp; got it 17:01:07 +gregwhitworth 17:01:08 liam has joined #css 17:01:10 belated regrets for the first ~10min. will have IRC scrollback til then. 17:01:20 ok tantek 17:01:33 +hober 17:01:45 +??P25 17:02:00 +[IPcaller.a] 17:02:13 alex_antennahouse has joined #css 17:02:20 smfr has joined #css 17:02:25 vollick has joined #css 17:02:30 +krit 17:02:31 -gregwhitworth 17:02:48 +[Microsoft] 17:02:52 bcampbell has joined #css 17:02:54 +smfr 17:02:59 +[IPcaller.aa] 17:03:13 I'm IP caller I think 17:03:13 +Plh 17:03:18 +gregwhitworth 17:03:19 bradk has joined #css 17:03:23 +[Microsoft.a] 17:03:33 + +1.917.818.aabb 17:03:36 zakim, microsoft has me 17:03:36 +Rossen_; got it 17:03:53 Mike at Antenna House - I'm calling in via Skype today 17:04:05 +??P39 17:04:10 ok AH_Miller 17:04:17 +SteveZ 17:04:23 +koji 17:04:24 glazou: Let's get started 17:04:29 +SylvaIng 17:04:31 KeshavP has joined #css 17:04:37 andreyr has joined #css 17:04:39 SteveZ has joined #css 17:04:42 glazou: I saw that Bo posted an extra item on the ML. Any other extras? 17:04:45 zcorpan has joined #css 17:04:49 +BradK 17:04:56 ??: I have issues on Animations and the behavior of the key arguement 17:05:05 adenilson_ has joined #css 17:05:05 glazou: The delete and insertion rules? 17:05:12 sylvaing: Yep. 17:05:24 s/??/ sylvaing 17:05:37 Topic: Brief intro for API taskforce 17:05:46 Rossen_: I can do my best. Is TabAtkins on the phone? 17:05:53 glazou: He's not, apperently. 17:06:11 +antenna 17:06:21 Rossen_: Okay. I don't even know what to call it anymore. Thre's a TF which was formed just a few days ago and it's something we've been talking about and trying to get up and running. 17:06:45 Rossen_: The idea and purpose is to tackle some of the lower level layout primitives and expositing the programmability model of layout and styling to script 17:07:04 +dbaron 17:07:08 s/expositing/exposing/ 17:07:15 the TF’s mailing-list is public-wtf@w3.org 17:07:30 glazou, I'd like to briefly point out an email I sent about transitions 17:07:30 +BrianKardell 17:07:34 Ms2ger has joined #css 17:07:39 Rossen_: Why did we form a TF, if you read one of TabAtkins's e-mail in my responce to the org thread, he had a really good summary. Basicaly half the peoplein the WG are interested in layout and half are not. We want to have a focused group that deals with that alone and mothing else, similar to the FXTF and how the deal with effects. 17:07:48 dbaron: ok ; do that after the current item ? 17:08:08 +??P50 17:08:08 and even DISRUPTIVE INNOVATIONS ! 17:08:11 Zakim, ??P50 is me 17:08:11 +SimonSapin; got it 17:08:22 Rossen_: The group as it stands is most represented with impl. We have people from Mozilla, Google, Microsoft, Adobe, and I believe we may have people from Apple join. We're trying to set up a first meeting in Sydney. 17:08:23 :) 17:08:32 Rossen_: Oh, and HP and Ditruptive Innovations. 17:08:33 bkardell_ has joined #css 17:08:33 I have joined - jQuery 17:08:39 bradk: that’s why smfr suggested to change it 17:08:46 is there anyone from TAG besides Peter who are interested? 17:08:53 Rossen_: So we'll try and set up a meeting right before the Sydney F2F on Say and Sun, I believe that's 7 and 8 feb. 17:08:59 ChrisL has joined #css 17:09:07 Rossen_: shans will arrange and host the meeting, I'm assuming in a similar or same location. 17:09:21 tag is interested, they wanted it set up 17:09:40 +ChrisL 17:09:50 zakim, mute me 17:09:50 ChrisL should now be muted 17:10:03 Rossen_: That's pretty much what we have for now. We're hoping during hte initial meeting we'll clarify the chater of the group, so don't hold me to what exactly we'll do. We'll set up the charter at the F2F. Prior to that we're hoping the bikeshedding of the taskforce name will be done with. 17:10:18 Rossen_: The wft name I odn't think was ever meant to stick for a long time. 17:10:46 s/wft/wtf 17:10:50 Rossen_: It turned a bunch of heads. I got a bunch of emails about people who were passionate about being serious. I am too, so don't hate me for it. 17:10:55 just let me know what the eventual name will be, and i will create the new list 17:11:32 wiki.wctf.org 17:11:37 Rossen_: We'd love to have people join the list. It is publis. plinss and I set up mercurial and extf and if it sticks that's what we'll use to solidify proposals and start creating spec. 17:11:40 wiki.extf.org 17:12:01 Rossen_: And the wiki is this (above) and up and everyone in CSS should be cleared for access and to contribute. 17:12:15 Rossen_: That's the overall intro. Any questions or name proposals? 17:12:37 zakim, unmute me 17:12:37 ChrisL should no longer be muted 17:12:37 glazou: dauwhe has a good question. shans should forward the meeting notes from the end of TPAC to the list. 17:13:09 wctf.org directs to World Children Transplant Group. 17:13:27 Rossen_: Yes, once the wiki is up and running, there are some initial documents we'll use to introduce people to what we're doing and the problem space as well as meeting notes. At Sydney we'll figure out the telecon schedule and soforth. The initial meeting will be admin and chartering details. 17:13:59 What about "Layout Tree Task Force" 17:14:00 ChrisL: I would suggest waiting to forward the notes until the mailing list exits. As soon as you have a name you've settled on let me know. 17:14:09 Rossen_: I will and thank you ChrisL for being so patient with this. 17:14:13 zakim, mute me 17:14:13 ChrisL should now be muted 17:14:14 glazou: Okay. Any questions? 17:14:19 glazou: Thank you Rossen_ 17:14:32 Rossen_: I hope to see as many of you as possible in Sydney. 17:14:39 http://lists.w3.org/Archives/Public/www-style/2014Dec/0150.html 17:15:12 dbaron: I wanted to point out I sent an e-mail to www-style yesterday about edits to Transitions spec. I'd appriciate review of the edits and the spec in general because hopefullyw e can take this to the new process, maybe in January. 17:15:23 glazou: Let's do an action to the group. How much time is needed? 17:15:35 dbaron: I don't know if it's everyone. Some of these are technical. 17:16:07 Rossen_: Is this the write-up that you did...in a couple of F2F you mentioned that the position model is broken and you would rewrite. Is this it? 17:16:31 dbaron: No. That was in the last WD. This fixes one of the things that was missing from that. THe edits I did then didn't explain how transitions get cancelled. 17:16:42 Rossen_: Maybe now is a good time for an overall review of the whole model. 17:16:51 ??: Are there any tests the desc the behavior? 17:16:57 s/??/smfr/ 17:16:58 s/??/smfr/ 17:16:58 dbaron: I don't think so. That would be useful as well. 17:17:17 Action everyone to review the document and give feedback 17:17:17 Error finding 'everyone'. You can review and register nicknames at . 17:17:25 Topic: :lang() issues 17:17:34 glazou: smfr will you be discussing this? 17:17:40 smfr: I don't have the background, sorry. 17:17:43 http://lists.w3.org/Archives/Public/www-style/2014Dec/0046.html 17:18:06 glazou: Le'ts take the first one. That's about parsing the arguement of :lang(). In selectors 4 when there's a * to do matching. 17:18:07 http://lists.w3.org/Archives/Public/www-style/2014Dec/0130.html 17:18:16 +Liam 17:18:23 zakim, unmute me 17:18:23 ChrisL should no longer be muted 17:18:36 glazou: The 2nd message is sim but about how we tokenize the value of :lang(). So when we want to make *-number we can't because -number isn't a token. 17:18:44 "The conference is full, no more parties can be added at this time." 17:18:55 Zakim, I am here :P 17:18:55 I don't understand 'I am here :P', tantek 17:19:13 ChrisL: I think TabAtkins message recently about making that a string is the best way forward. When we org spec it was an easy thing. We can't tell what the future will be so we need to make it a string. 17:19:22 fantasai: We can't make it a string. We can allow it in addition to tokens. 17:19:24 I'm here, too, Zakim, but I don't know how to tell you that. 17:19:25 ChrisL: Yeah, sure. 17:19:45 fantasai: One of the things Webkit folks were asking is why not allow escaped asteris. 17:19:48 glazou: This is ugly. 17:20:03 MaRakow has joined #CSS 17:20:25 zakim, who is here? 17:20:25 On the phone I see dael, [IPcaller], glazou, plinss, Florian, dauwhe, antonp, Stearns, hober, ??P25, [IPcaller.a], krit, [Microsoft], smfr, [IPcaller.aa], Plh, gregwhitworth, 17:20:28 ... [Microsoft.a], +1.917.818.aabb, ??P39, SteveZ, koji, SylvaIng, BradK, antenna, dbaron, BrianKardell, SimonSapin, ChrisL, Liam 17:20:28 [Microsoft] has Rossen_ 17:20:28 On IRC I see MaRakow, ChrisL, bkardell_, Ms2ger, adenilson, SteveZ, andreyr, KeshavP, bradk, bcampbell, vollick, smfr, alex_antennahouse, liam, gregwhitworth, tantek, Rossen_, 17:20:28 fantasai: There's no reason to disallow, so why not allow. We might also want to allow strings as a less ugly optino. The only time you need a * is in the front since i nthe middle is like not putting it there. The front is only a problem when the subtag is a number. 17:20:31 ... svillar_, antenna, murakami, lajava, AH_Miller, dael, dauwhe, dbaron, RRSAgent, Zakim, glazou, dholbert, Florian, thinkxl, plh, antonp, nikos, Bert, stryx`, koji, cabanier, 17:20:31 ... astearns, lmclister______, achicu_____, TabAtkins, slightlyoff, JonathanNeal_, timeless, shepazu, ed, panzana`_, paul___irish, krijnhoetmer_, CSSWG_LogBot, gsnedders, hober, 17:20:31 ... wilhelm 17:20:35 -[IPcaller.aa] 17:20:50 fantasai: The only time it's an actual problem is when you're doing *-number. You can solve that with a string or escaping the *. 17:20:56 glazou: I prefer the string. 17:21:05 +??P30 17:21:08 Zakim, ??P30 is me 17:21:08 +tantek; got it 17:21:09 zakim, mute me 17:21:09 ChrisL should now be muted 17:21:12 fantasai: I imagine the corner case is rare. 17:21:15 zakim, mute me 17:21:15 tantek should now be muted 17:21:21 thanks whoever IPcaller.aa was 17:21:40 zcorpan has joined #css 17:21:46 glazou: But as ChrisL said we don't control this. This comes from another committee and we don't know what they'll do in the future. We should assume it's possible to happen in the future. It's not a complete edge case. 17:21:58 that was me, ran out of quarters for the pay phone 17:22:04 glazou: I'm in really in favor of allowing a scring and now going down the escaping path. What do others thinks? 17:22:11 fantasai: If we allow string, we should allow both. 17:22:23 q+ 17:22:30 glazou: Absolutely, but then we can say if you have * somewhere it has to be a string. This is new in Selectors 4. 17:23:05 Whoops, forgot about the call. I agree with glazou, btw. 17:23:10 +1 to fantasai allowing * at start 17:23:11 fantasai: I think I would pref for allowing the * in the beginning unquoted. That makes a minimal change for targeting a subtag, but allow a free range at the beginign. I don't mind having a string req for other situations. I want to commen place as easy as it was previously. 17:23:14 I think a string makes sense, it's still pretty easy, right? 17:23:29 +1 17:23:32 Better to make it a consistent "string if you use *" than an inconsistent "just type it, but if it doesn't work [due to arcane parsing things] then use a string" 17:23:33 fantasai: For usablility I'd like to allow the star. I'm fine with allowing the string for future wierdness and an alternative to escaping. 17:23:59 fantasai: One of Ben's emails was precisely about a problem with an initial *. 17:24:05 SimonSapin: An edge case is star is already a valid ident in :lang pseudo-class. We shouldn't dis-allow it. Escaping works. 17:24:14 sylvaing: That makes sense to me. Escaping is allowed. 17:24:16 s/edge case/escaped/ 17:24:26 glazou: Do we agree on the strategy here? 17:24:30 sylvaing: I do. 17:24:34 glazou: fantasai? 17:24:43 fantasai: Yes? I think TabAtkins isn't sure. 17:24:49 callin in now, one sec 17:24:50 glazou: [reads TabAtkins comments] 17:25:07 never mind, conf is full :( 17:25:08 glazou: One of Ben's e-mails is about the problem with the initial star. 17:25:12 was it s/sylvaing/florian/ ? 17:25:18 The two problems Ben brought up: 17:25:23 fantasai: I think that's wierd and archane and pretty much no one will run into it. 17:25:29 1. *-1996 is a valid code via the RFC, but invalid per CSS parsing. 17:25:32 -BradK 17:25:33 glazou: When the problem is plausable it always happens. 17:25:55 2. foo-*-bar is valid in the RFC. 17:25:56 glazou: So, let's keep allowing *-identifier when it's not digits and recommend a string when it is. 17:25:58 action: chris to extend the zakim bridge allocation 17:25:58 Created ACTION-663 - Extend the zakim bridge allocation [on Chris Lilley - due 2014-12-17]. 17:25:59 RESOLVED: keep allowing *-identifier when it's not digits and recommend a string when it is. 17:26:01 +BradK 17:26:04 fantasai: I'll make the edits. 17:26:10 http://lists.w3.org/Archives/Public/www-style/2014Nov/0580.html 17:26:10 RESOLVED: Allow strings as argument to :lang() 17:26:17 Topic: Fixed layout 17:26:57 SteveZ: "Layout Tree Task Force" would mean LTTF which is already taken by "Learning Technologies Task Force" lttf.org 17:27:16 SimonSapin: The part of fixed layout that is spec in CSS2.1 has one of the senetence. When all col have the spec width and the table has a spec with, if the table is larger, the extra should be dest between the col. The spec doesn't say how, but it turns out webcompat depends on it being proportional to the width of the columns. 17:27:23 fantasai: I recommend making the edits so that string is recommended, but then laying out cases when you can omit the quotes. Better than trying to say "you don't need quotes, but if you find that it doesn't work, use quotes". 17:27:34 SimonSapin: It seems like the spec needs to say this so we should add an errata. 17:27:50 Florian: There was an extra comment on the mailing list needing exceptions. 17:28:44 dbaron: And ou have to consider if it has % width as well. What Gecko does is it destributes extra space...if there's a non-0 width in col with a spec length, it distributes among them with nothing to the col that have %. Otherwise it distributes to those with % width. 17:28:51 TabAtkins, yes, makes sense. Well, I would recommend unquoted for anything that's not involving *, because that is backwards-compatible and strings are not. 17:28:59 Florian: Do we have interop on when there's col-span somewhere? 17:29:04 TabAtkins, but for cases with * I agree. 17:29:05 fantasai: Yeah, sure. 17:29:35 dbaron: I don't think it interacts, well, maybe you are looking at cell width. I'm not sure if this is looking at cell widths or only...fixed only looks at the first row. It may skip those with col-span. 17:29:47 SimonSapin: It does describute to those with col-span. 17:29:51 s/that is spec/that *is* specced/ 17:30:00 glazou: So do we have an answer to the question? 17:30:26 SimonSapin: We need to change something. It's unclear as to what the exact behavior should be. dbaron can you write on the ML what the Gecko behavior is? 17:30:36 Florian: And we want to make sure other browsers do the same? 17:30:41 SimonSapin: I can try to do that. 17:30:47 glazou: plh are you on the call? 17:30:51 plh: I am. 17:30:59 glazou: You want to mention something about CSS2 errata? 17:31:14 -BradK 17:31:37 plh: It would be nice to leave the spec as it is online. I brought this to the group and we were lacking tests. I'm not saying we should stop everything, but it would be great to update the TR verion of CSS 2 17:31:42 glazou: Comments? 17:32:07 glazou: SimonSapin will you create and errata based on the changes you want from your tests? 17:32:08 zakim, unmute me 17:32:09 tantek should no longer be muted 17:32:23 SimonSapin: I'll do more tests to find interop and then propose and errata 17:32:37 fantasai: While you do that, can you submit a test? 17:32:40 SimonSapin: I can do that. 17:32:50 tantek: What is the status of the lighter-weight TR process. 17:32:54 robertknight_clo has joined #css 17:33:05 fantasai: The process for updating REC is worse in the new version of the process. 17:33:26 plh: There has been discussion on the process list. There is a high bar to update REC and there's been a discussion about lowering that bar. 17:33:30 we published a CR under new process recently. actually it was the first one 17:33:38 ato has joined #css 17:33:49 tantek: I thought it was further than that. Allowing a group to update a TR page without the heavy lifting. 17:34:26 -??P39 17:34:48 fantasai: That's not about what W3C process we're on. For 2.1 we're stuck on process issues. We can't pub sbstantitive changes unless they pass CR and we have a bunch of items without tests or impl reports. So assing the current version of 2.1 we need all the reports to publish, or re-ublish. 17:34:56 ack SimonSapin 17:34:57 mihnea_____ has joined #css 17:35:05 (done earlier) 17:35:28 tantek: That's a long list of dependancies. I understand the need to not update the TR CSS2.1 immediatly, but this long list of dependancies seems like a bad problem. Can we pub as a ED? 17:35:31 fantasai: It is. 17:35:44 tantek: Can we slap a warning on the top of CSS2.1? 17:35:48 +??P9 17:35:51 birtles has joined #css 17:35:56 Zakim, ??P9 is me. 17:35:56 +adenilson; got it 17:35:59 plh: Because no one has asked. I don't think we've done it before... 17:36:10 fantasai: We have. We put something at the top of CSS2 saying look at 2.1 17:36:23 tantek: So I'm sayng put something at the top of 2.1 that links tot he ED. 17:36:26 fantasai: I'm in favor. 17:36:34 glazou: I am if we say there's extra ongoing work. 17:36:44 tantek: Saying we have substantial changes in process. 17:36:59 ChrisL: The usual is to put it in errata rather then link to an unsatable doc 17:37:09 tantek: I obj to hiding it the the errata. 17:37:22 glazou: We should put it in the real document. 17:37:24 s/ChrisL/Liam/ 17:37:30 tantek: This is a warning at the top. 17:37:34 +1 17:37:35 +1 17:37:37 +1 17:37:40 in favor 17:37:40 +1 17:37:41 glazou: So we have a proposal to put a new link at the top of CSS2.1 17:37:44 +1 17:37:49 +1 17:37:49 +1 17:37:52 +1 17:37:56 fantasai: I'm in favor. Someone mentioned a link to both the errata and the ED and that's good. 17:37:57 +1 17:37:59 we already have an errata and a link to it 17:37:59 glazou: Any objections? 17:37:59 we already have a link to the errata - no need to duplicate that 17:38:00 -1 but not objecting 17:38:05 +1 17:38:07 this is ONLY for linking to the editor's draft 17:38:13 +1 17:38:35 so this is an in-place edit on CSS 2.1 Rec? 17:38:46 errata must already be there for a rec 17:39:01 tantek: We have a link to the errata, so I don't think we should confuse it 17:39:04 glazou: Yeah, fine. 17:39:08 RESOLVED: Add a new link at the top of CSS2.1 linking to the Editor's Draft 17:39:09 What am I plusoneing? 17:39:17 "There are substantial changes in progress" 17:39:22 Topic: CSS3 UI 17:39:31 zakim, mute me 17:39:31 ChrisL was already muted, ChrisL 17:39:31 glazou: You have 20 minutes. Choose well. 17:39:38 http://lists.w3.org/Archives/Public/www-style/2014Dec/0145.html 17:39:40 Florian: Let's start with this. 17:40:06 plh: good question BTW 17:40:12 plh, nobody yet, I think 17:40:22 am stram gram :-) 17:40:28 Florian: We have a resolution about rounded outline. WE had a short discussion that raised issues, didn't answer them, and then concluded that i you have a rounded border, the outline should be as well. I agree this is what you'd normally want, but due to the vaugue definition, I'm not sure what it means. 17:40:53 Florian: We have interop on not doing that. Every browser keeps square corners. I'm not sure if there's a webcompat issue with switching. 17:40:55 +[Microsoft.aa] 17:40:56 glazou - who put the warning at the top of 2.0? 17:41:05 tantek: ChrisL or Bert? 17:41:12 Zakim, [Microsoft.aa] is me 17:41:12 +MaRakow; got it 17:41:15 oh wait you said 2.0 17:41:17 no idea 17:41:21 glazou any volunteers to update 2.1 with the warning? 17:41:22 hey that was EONS ago 17:41:24 Florian: options are 1)do nothing 2)do the same explicitlys aying you may, but not how 3) we do it with a must, prob don't say how, and test the obvious case. 17:41:38 tantek: plh and I recommend ChrisL or Bert 17:42:00 Florian: I would prefer an explicit may to allow experiemtnation and spec completely in level 4. I have ideas on how we'd attempt a full spec, but it's not a onn liner 17:42:24 fantasai: The definition wouldn'tbe that difficult. Tot he extent that the outline follow the border edge, it it must follow the rounding. 17:42:33 Can we make the warning fixedpos, like http://dev.w3.org/csswg/css-box/ ? 17:42:52 Florian: Not always. If the children overflow, some browssers include the overflowing bit in the outline. Also, the spec doesn't say if you transformt he outline when you transformt he elements. 17:43:18 fantasai: You can say to the extent that you follow the border edge. So when it does, you follow the curve. Where it doesn't follow the bordedr edge it's left undefined. 17:43:31 Florian: That sounds like something we can spec. If we spec as a must, no one passes. 17:43:52 Rossen_: I think we can easily push it to level 4. I don't see us rushing to impl this given everything else on the table. 17:44:03 q+ to explain WebTV outline history 17:44:26 Rossen_: On the priority level, this will be low for us. I'd be surprised if other rush to impl rounded corners. I'd be okay with this going to level 4. 17:44:34 tantek, you wanted to explain WebTV outline history 17:44:36 Zakim, ack tantek 17:44:36 I see fantasai on the speaker queue 17:44:53 abucur___ has joined #css 17:45:52 tantek: This feature started from the really good outline and focus of webTV. It did round the corners and provide a nice rounded implementation. We knew this was non-trivial to impl whichis why it's loose in the spec. I don't expect every impl can do that, we need to allow a broad range of fidelity. I'm okay with adding some more may to the existing spec with known best practices but it's premature to agree one specing this on any future level 17:46:14 amtiskaw has joined #css 17:46:25 tantek +1 17:46:28 tantek: I find it distrubing that the rounded-ness disappears at times, but I don't know how to say it's broken without breaking other implementations. I'm okay with may statements, but not saying how to do it. 17:46:42 Florian: So have fantasai proposed sentence with a may in it for level 3. 17:46:44 -BrianKardell 17:46:51 tantek: fantasai can you put your sentence in IRC? 17:47:05 "To the extent that the outline follows the border edge, it should follow the border-radius curve." 17:47:09 Florian: The the extent that the outline follows the border,t he outline should be rounded just like the border, I think. 17:47:31 Florian: I don't know about should vs may, but not must. 17:47:42 tantek: So should vs May is are we sure it's desirable behavior 17:47:52 fantasai: We're sure it's desirable, but not sure about webcompat 17:48:01 tantek: If we're sure we should use should. 17:48:17 Florian: That's why we resolved before on Must, but that's a bit impossible. 17:48:32 RESOLVED: To the extent that the outline follows the border edge, it should follow the border-radius curve 17:48:42 glazou: 10 more minutes 17:48:47 http://lists.w3.org/Archives/Public/www-style/2014Dec/0063.html 17:49:00 CSS3-UI Issue #?? 17:49:11 Florian said he would edit the CSS3-UI issue 17:49:31 Florian: Next one. resize. It's speced in terms of a resize factor. They do it by updating a style attr and they're imterop. Regardless of the spec behavior is good, we should drop in terms of what's impl. 17:50:21 fantasai: I'm not sure if what's in the spec is ideal, but I'm not sure on what's impl either. So if you resize a form element to make it bigger and it was, say, fill to viewpoprt, and then you resize your window to make it sign narrower or wider, the form element will no longer attempt to fit in your new layout. 17:50:55 fantasai: In which case the UA may want to do something smart. I don't know what's right, though I think what's in the spec shouldn't be what's there. It should be close to what's impl or more similar. 17:51:26 thanks Florian 17:51:42 q+ to say this is why the spec language specifically says "a resize factor applied internally by the UA" 17:51:42 Rossen_: So if the resizable element is relative to a containing block and the containing block is resized, do you resize the element again. You can decide which is the desribale behavior and you can respec by saying either it remains fixed or resizes on the next containing block resize. 17:52:07 glazou: We see that when you resize a table in an editor. When nothing is fixed length, you resize a field and then a container, you have that problem. 17:52:49 Rossen_: I think that half the time you want to resize and half the time yu don't. Perhaps we're missing an additional behavior which will further define what happenes during resize. It'll be up the the author to set the expected behavior the be resize as fixed or relative. 17:53:14 fantasai: That makes sense. We should explore that in the next level. For this level we may have the spec what's there and say the UA may reset the size when it feel like it. 17:53:18 glazou: I can agree to that. 17:53:37 tantek: That's a lot wording to restate what we have. The current lang was choosen to deal with all these variants. 17:53:56 tantek: That was the most expediant way to impl and it's not cooincidence that they arrived there. 17:54:03 Florian: I'm not sure they're equivellent 17:54:31 q+ 17:54:48 tantek: I said covered by. The language is very deliberate to cover the existing behavior and something in the future where the UA does something more intellegent in the future depending on how the item was layed out etc. I don'thtink the impl know wht's optimal. 17:55:14 tantek: Right now we don't have widespread use of Flexbox, but I think we will in the future and detailed languge will make an obstical in the future. 17:55:28 dbaron: So I don't think what implementations are doing is conformat to what the spec says. 17:55:41 fantasai: I agree. Interacting the the cascade is not an internal detail 17:55:52 dbaron: THe spec is clear that it's after width, so these are different. 17:56:15 tantek: I would be okay ith expanding what the spec allows to explicitly allow the style attr manipulation. 17:57:01 Florian: So I'd like to ask if the impl are ever willing to change. If they're not, we shouldn't spend time discussing the change. But if they're willing to change we can spend time deciding where this should be in the future. I don't have an opinion on which is better, I just want spec and impl to match. 17:57:28 dbaron: I think there's a difference in willing to change and willing to put in the energy to make the change happen. What's in the spec is more work, prob substantially. 17:57:41 s/difference in/difference between/ 17:57:50 tantek: That's why I'm saying the spec lang should be broadened to allow what impl are doing now and allows better approaches in the future. 17:58:02 Florian: I'm not sure how you do that given the infraction to the cascade. 17:58:27 tantek: We add a sentence saying something like impl may directly manipulate width and hight elements on the style attr being changed. 17:58:45 tantek: That's my prop. 17:58:50 glazou: Florian what do you thing? 17:59:02 s/thing/think 17:59:32 Florian: I'm willing to go with tantek, if impl are willing to go with what is in the spec, why not, but if impl won't change there's no point in specing something they won't use. I don't see much willingness to implthe other one. 18:00:16 fantasai: I think someone that isn't the core impl team will find a need for a better approach and will put pressure for the changes. If we think it's a better route we should leave it open. If we think we'd like to go there if we have the resources, we should leave it in the spec. 18:00:23 sgalineau has joined #css 18:00:41 -krit 18:00:54 fantasai: The current talks about a resize factor and that's multiplictive. Right now it's a fixed size. I think we might want to change it to information. 18:01:00 tantek: How about a resize transform? 18:01:02 fantasai: Sure. 18:01:13 tantek: That reasoning makes sense. That allows implt to do anything. 18:01:24 Florian: I'm not sure about transform because people might think it'st he transform prop. 18:01:30 fantasai^: Might want to be additive rather than multiplicative. 18:01:31 glazou: We have to wrap up. 18:01:40 proposal: change "resize factor" to "resize transform" to address fantasai's concern 18:01:49 -[IPcaller] 18:01:54 Florian: If we allow the current in the spec, I'm good with that. I'm not sure it's obvious that the rest is useful, but sure. 18:02:09 fantasai: An alternative to tantek's lanugague is to say information with is more vague. 18:02:12 s/transform/function 18:02:12 tantek: Or function. 18:02:12 I like function 18:02:16 let's use function 18:02:22 Florian: So we won't have tests for this? 18:02:24 -Stearns 18:02:26 tantek: Nothing more than now. 18:02:33 f(x) = x + 20px 18:02:38 f(x) = 278px 18:02:39 -[Microsoft] 18:02:40 Florian: I'm not sure how you test if we can say this way or that way with one way not defined. 18:02:42 proposal: change "resize factor" to "resize function" to address fantasai's concern 18:02:43 f(x) = x * 1.5 18:02:51 glazou: So can we continue offline or resolve? 18:02:58 tantek: I want a resolution on what I typed. 18:03:06 -Plh 18:03:15 both proposals 18:03:21 Florian: Was it your line plus the earlier? As long as you can do it with a style attr, I'm good. 18:03:32 -dbaron 18:03:36 -ChrisL 18:03:39 -SylvaIng 18:03:39 RESOLVED: impl may directly manipulate width and hight elements on the style attr being changed and change "resize factor" to "resize transform" to address fantasai's concern 18:03:41 -Liam 18:03:42 -koji 18:03:44 -adenilson 18:03:46 -gregwhitworth 18:03:51 dael: s/transform/function 18:03:53 -glazou 18:03:54 -hober 18:03:54 -[IPcaller.a] 18:03:55 -??P25 18:03:55 -[Microsoft.a] 18:03:57 -antonp 18:03:59 smfr has left #css 18:04:00 glazou: alright, bye! 18:04:00 -SteveZ 18:04:01 -plinss 18:04:01 -tantek 18:04:01 -SimonSapin 18:04:02 -smfr 18:04:02 - +1.917.818.aabb 18:04:04 -dauwhe 18:04:08 -antenna 18:04:10 -dael 18:04:11 -MaRakow 18:04:22 that was for CSS3-UI issues 47 and 53 18:04:32 cc: Florian 18:05:01 tantek: thanks 18:05:03 -Florian 18:05:05 Style_CSS FP()12:00PM has ended 18:05:05 Attendees were dael, [IPcaller], glazou, fantasai, plinss, Florian, dauwhe, +97455aaaa, Stearns, antonp, gregwhitworth, hober, krit, smfr, Plh, +1.917.818.aabb, Rossen_, SteveZ, 18:05:05 ... koji, SylvaIng, BradK, antenna, dbaron, BrianKardell, SimonSapin, ChrisL, Liam, tantek, adenilson, [Microsoft], MaRakow 18:05:57 tantek: I'll have to go through my notes again then, as there were issues that had been raised against the current wording. I had assumed we would replace it so they didn't matter, but as we keep it, we need to solve them 18:07:47 Florian ok. I think the change of factor to function is a good one. 18:10:07 Rossen___ has joined #css 18:11:31 tantek: Sure. I'll surface things other people had brought up on this. 18:15:10 iank__ has joined #css 18:23:20 I'll give a go at writing the full text for "may do with with the style attribute instead". It shouldn't be long, and since we're specing from implementations, I think it is worth being specific about the behavior we're allowing 18:23:25 ok? 18:27:59 hey 3 minutes isn't enough time to answer :P 18:28:18 I'm going to just go with the language proposed and resolved. We can make further editorial edits later. 18:31:27 vollick has joined #css 18:36:31 Florian has joined #css 18:43:04 Florian has joined #css 18:43:13 adenilson has joined #css 18:48:56 zcorpan has joined #css 19:06:28 dauwhe has joined #css 19:16:40 dauwhe has joined #css 19:44:38 Florian, ICYMI - re: "may do" - I'm going to just go with the language proposed and resolved. We can make further editorial edits later. 19:53:48 tantek, the change to /TR in the short term is to make it easier to publish WDs, does not affect transition to CR, or editing a Rec (I fear the result will be to make publishing a Rec seem even harder) 19:54:34 right, so until publishing a Rec is fixed, we should put warnings on all the Recs that point to replacement editor's drafts. 19:54:48 the warnings will continue until the Rec updating process is sufficiently improved 19:56:18 :) beatings will contunue etc etc 20:12:48 http://www.w3.org/TR/CSS21/visudet.html#line-height 20:14:39 Zakim has left #css 20:15:31 http://www.w3.org/TR/2002/WD-css3-linebox-20020515/ 20:19:08 Ms2ger has joined #css 20:36:15 gsnedders has joined #css 20:37:29 zcorpan has joined #css 21:25:29 As part of doing css3-ui issue archeology on www-style, I found this: http://lists.w3.org/Archives/Public/www-style/2011Oct/0552.html 21:26:15 given that we have move all pseudos to the selectors spec, this is no longer in scope for UI, and is selector material, just in case anyone wants to pick it up. 21:27:26 s/move/moved/ 21:29:15 (bringing this up, as the only response is TabAtkins pinging Tantek as the css-ui editor to tell him to pick it up, but it's now back on a spec he edits) 21:33:54 dbaron has joined #css 21:33:58 tantek has joined #css 21:46:00 Florian has joined #css 21:48:31 zcorpan has joined #css 22:18:38 Ugh, that's a dumb amount of time to go without a real response. 22:18:44 Yeah, we should add it to Selectors. 22:21:15 jcraig has joined #css 22:34:54 Florian has joined #css 22:50:51 is there an intended difference between the production and the production? 22:51:06 No. is supposed to go away. 22:51:48 ok, thanks 22:55:20 Florian, any such differences are being placed in an 22:56:02 :) 23:12:15 the Queen needs to make Timbl into an Earl, :) 23:12:29 Timblearl? 23:15:26 heh :) 23:15:42 and he cound say it eee yew ur ell 23:32:41 http://chanae.walon.org/pub/ttf/ttf_glyphs.htm 23:35:58 plinss: Working on the autolinking code a bit more, and ended up with a feature request for Shepherd (+ a minor one for widlparser). 23:36:49 If you have an IDL method like "foo(DOMString bar, optional long baz)", you can link to it normally with the normalized name, "foo(bar, baz)". This is standard widlparser output. 23:37:18 But I'd like to also allow linking to other valid call signatures, such as "foo(bar)" in this case, due to the fact that "baz" is optional. 23:38:54 I'm doing that manually right now in Bikeshed, forcing it to generate multiple linking texts. That's annoying if you're providing the "real" definition somewhere other than the IDL, though. 23:39:23 So point is, I'd like to be able to indicate the "length" of an IDL method/constructor/etc, meaning the number of required arguments. 23:41:41 (This only requires widlparser work because non-Bikeshed specs that you're parsing and extracting IDL from need to have this show up in their data as well.) 23:56:36 This mail is asking why we don't have "box-sizing: margin-box", and wondering if the answer has something to do with margin collapsing http://www.w3.org/mid/F3BE4F97-07F7-494F-AD7B-C698EDC109C6@idreamincode.co.uk 23:57:23 I guess that yes, that's why. But no-one replied, and we may want to handle this is the disposition of comments as a rejected suggestion 23:57:56 tantek: ^ 23:58:28 hmm - I think these days I would reply with could you link to a concrete use case rather than theoretical? E.g. where someone is attempting a layout effect like this with JS. 23:58:41 if not, I would reject as no evidence of real world use case 23:59:15 if not disposition of comments, then at least an FAQ 23:59:39 g2g meeting ttyl