- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 12 Nov 2015 05:25:40 -0500
- To: www-style@w3.org
New WD for Device Adaptation ---------------------------- - RESOLVED: Publish new WD for Device Adaptation. CSS Snap Points Path Forward ---------------------------- - MaRakow, TabAtkins, and fantasai got a chance to speak and come to a consensus on how to fold the change in approach to snap points into the existing WD. - This change-over will occur over the next several weeks. - Once the new version is ready, the group will publish a last version of the old approach right before publishing the new approach, both as WDs. - This allows a good record of how the spec progressed without sending the wrong signal about the direction of the spec to implementors. Round Display ------------- - There was support for the proposal of 2D rotation transform function for polar coordinates, though it was thought they should be named polar-angle and reverse-polar-angle or polar-reverse-angle to explicitly link them with the polar properties. - An additional question was raised about how it would interact with animation, but it was decided that that interaction was dependent on if it's a computed value or a specified value. - RESOLVED: Accept the proposal for a 2D rotation transform function for polar coordinates and make it clear if it's a computed value or a specified value and make a note on the implication of that decision on animations. - RESOLVED: Accept the polar-origin changes. - The polar-origin proposal lead to a conversation about adding a center value to fixed and absolute positioning. - The conversation will continue on the mailing list. - If this change ends up happening, it may negate the need for polar-origin. Page Floats ----------- - There wasn't telecon time for a full conversation, but it was suggested that the interested parties get on a separate call to work through the mailing list topics. - johanneswilm and Florian will work on organizing a call. Match-Parent and Orthogonal Flows --------------------------------- - RESOLVED: Line-grid will restart in the case of orthogonal flows between parent and child. Additional Page Sizes --------------------- - RESOLVED: Add JIS-B4 and JIS-B5 to page-floats. - Florian will summarize other page sizes that could be added to the spec in an e-mail. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2015Nov/0185.html Present: Rossen Atanassov Dave Cramer Elika Etemad Tony Graham Jihye Hong Dael Jackson Brian Kardell Brad Kemper Peter Linss Myles Maxfield Simon Pieters Anton Prowse (IRC Only) Matt Rakow Florian Rivoal Simon Sapin Alan Stearns Lea Verou Greg Whitworth Johannes Wilm Steve Zilles Regrets: David Baron Bert Bos Angelo Cano Adenilson Cavalcanti Alex Critchfield Simon Fraser Daniel Glazman Michael Miller Edward O'Connor Zhong Xu Scribe: dael Rossen: First thing, any extra items? <Florian> https://lists.w3.org/Archives/Public/www-style/2015Nov/0154.html Florian: I doubt we'll get to it, but it would be good to talk about this (link above) this time or next. Rossen: This is the pre-wrap/pre-wrap-auto? We'll add it. Rossen: Any other topics? WG Administrative Discussion ============================ [un-minuted] New WD for Device Adaptation ============================ <astearns> https://drafts.csswg.org/css-device-adapt/#changes Florian: I've been through the log. It's been a long time and there are substantive changes. I think we should publish a new WD. I've made a change section. If anyone wants issues logged before we publish it would be good, but I'd rather add issues and publish as-is because it's been a long time. What do people think? <astearns> +1 to new WD MaRakow: We had a side discussion about the two issues I raised. I'll add those as issues so we can move ahead with publishing a WD. Florian: Okay. Anything else people would like marked in the document? SteveZ: Good for me. Rossen: Sounds like everyone is okay with publishing. I'm also in favor of publishing with the added issues. RESOLVED: Publish new WD for Device Adaptation. Rossen: Who will help with the publication? Rossen: Are ChrisL or Bert on? No. Florian can you ping one of them to get it published? ACTION Florian to work with Chris or Bert on publication <trackbot> Created ACTION-743 CSS Snap Points Path Forward ============================ Rossen: This was worked on extensively with conversations, so we need a follow-up. MaRakow: I had a telecon with TabAtkins and fantasai last week. They gave me a walk through of the technical changes. We discussed on there some changes and wording. As far as procedure goes, over the next couple of weeks we'll do a detailed review of the spec and pull them into the existing ED so we can isolate and identify items. MaRakow: There were a couple of issues, I think we were going to remove edges from snap-align and a couple of others, but that will happen over the next few weeks and we'll have a merged draft. Rossen: So it sounds like in a couple of weeks we can republish the merged draft? MaRakow: Sounds right. Rossen: Do we have anything we want to publish prior to have a good before/after? MaRakow: The spec has the Japan changes using the old syntax. We could publish that as the furthest progression of the old syntax. So before moving to the new terms this is as far as the old one went. Rossen: Is everyone okay with publishing a WD first and publish the merged draft including the new syntax? fantasai: Only if we're super clear with a message in the status with what the changes will be. I don't want implementors to think we're not going the new way and implement this other thing. MaRakow: That makes sense. <astearns> would rather wait until we have the draft set with everything we've agreed on. Florian: I'm okay with preserving a current state, but I'm worried about the signal. Can we save the draft on the side, work on the new one, and publish both in a row? That way we don't have a long piece of time with the old one. MaRakow: Main problem with delaying publishing updates is what will be up will be less up to date. Florian: It's a matter of signaling. If you update with something we no longer want that could be confusing. Rossen: What are the types of changes you have? MaRakow: I don't have full list, but it included removal of repeat syntax and some text. I can send the full list to the mailing list if that helps. Florian: If we do a gigantic warning that's probably fine. Rossen: So we can wait until the merged draft is ready and publish both drafts one after another. That would buy you safety if it takes longer, which I think worries some people. The other option is if you're committed to the short timeline, I doubt this will provoke too much implementor confusion. fantasai: It would be fairly easy to snapshot the draft right now, save it, and publish later. MaRakow: I can go with whatever the group recommends. I wanted to raise the potential of having the midpoint. Rossen: I think we agree it's important, it's all about timing. Rossen: We'll take the snapshot for now and then we'll publish the two specs one after another once you're ready. MaRakow: Sounds good. Rossen: Let's go with that. We'll resolve once you're ready with the new draft. MaRakow: Procedurally, who takes the snapshot? fantasai: Easiest way is for you to note the change set that corresponds to what you want as the snapshot. Then whoever publishes can pull down that change set and make it a WD to pass off to the staff. Rossen: Two topics on page floats are next on the agenda. These had the highest number of people wanting to talk about, but they'll take a while. The Round Display was brought by LG and they're in an awkward time zone. If fantasai and johanneswilm are okay, I'd rather do round display first. johanneswilm: Okay. Round Display ============= 2D rotation transform function for polar coordinates ---------------------------------------------------- <jihye> https://lists.w3.org/Archives/Public/www-style/2015Oct/0177.html <jihye> https://drafts.csswg.org/css-round-display/#2d-rotation-transform-function jihye: There was discussion about the polar orientation property at TPAC. It was decided to achieve the effect by the rotate function with additional keywords.n <jihye> rotate() = rotate( <angle> | center | counter-center) jihye: Therefore I extended 2D rotation transform for polar coordinates. In most polar positioning cases elements are rotated on anchor point to origin point. So we need center and counter-center value. jihye: Center enables us to achieve the kind of positioning elements more easily than specifying an exact value. Also counter-center, which means center value + 180deg for when elements are positioned downward in the shape of a containing block. <jihye> http://anawhj.github.io/jRound/demo/facebook/circle.html jihye: In this use case [above link] there are several menu icons. The upper menus are rotated with center and lower are with counter-center. <astearns> (demo does not work in FF, but does in Chrome) <gregwhitworth> @astearns strange, works in edge - makes me think it's probably webkit related somehow jihye: Is this extension of rotate reasonable and are our keyword value names appropriate? <Florian> rotate() = rotate( <angle> | polar-angle | reverse-polar-angle ) Florian: I think proposal is reasonable, but maybe change the names to what I have in IRC? <astearns> would the keywords also need to be added to https://drafts.csswg.org/css-transforms-2/#propdef-rotate ? <fantasai> astearns, no <fantasai> astearns, e.g. css-ruby extends 'display' <fantasai> astearns: so not necessary to fold in Rossen: What do others think? The proposal is add to rotate that takes polar and reverse-polar. Rossen: Your current function will take...it could be both polar-angle and reverse-polar-angle for the given angle? jihye: No, polar-angle and reverse-polar-angle can be used instead of angle value. Rossen: And the little icons like the like button in the demo, is that the icons you were referring to? jihye: Yes. Like and share are using counter-center which means reverse-polar-angle value. Florian: It does the same thing as typing an angle manually, but it picks the value from the computed value of the polar angle property so you don't have to manually sync. * fantasai would go with polar-angle/polar-reverse so they both start with polar- myles: If this is inside an animation, what do you expect to occur? myles: Is this function animatable and if so what is the behavior? jihye: When the rotation function has center value, then when the elements are moving on the edge of the circular shape, then always elements are rotated toward the center point of the containing block. So you don't have to manually adjust the angle of the rotation function. Rossen: So if you're animating from an angle to another angle... myles: Like if one side of the keyframe has center and the other an angle. Rossen: So since both are computable, you're animating from degrees to degrees. myles: The polar-angle value can also be animated. So you animated between things that can be animated? Or am I misunderstanding? Florian: Wouldn't the behavior fall out of our existing rules? jihye: I didn't consider animating. myles: Regarding Florian's comment, I'm not sure we have existing behavior where we're animating between something we're also animating, so it may be worth considering that case. Rossen: That's something we should take as an issue if we accept this. <astearns> so change to polar-angle | reverse-polar-angle and add an issue about animating? Rossen: So, what do people think about the addition of polar-angle | reverse-polar-angle BradK: I like it. <astearns> I like it <Florian> +1 fantasai: I think it makes sense. I would go with names that start with polar to make it clear the values come from the polar properties. Rossen: That makes sense. It sounds like we'll have to record an issue about if this is something that will be requiring special animation handling. fantasai: If you're animating polar, if it doesn't compute through, which I don't think it should, as you're animating polar-angle the transform will change. If it computes through you will probably...it won't work as well. fantasai: Animating between...that would work. If you don't compute through it will animate just fine. If you're animating between rotate: polar-angle and rotate: 0 Florian: It doesn't sound unreasonable to animate between polar-angle and another of the keywords. But when you combine both, what happens? If you simultaneously animated the transform property from rotate a keyword to an angle and animating the polar-angle. <fantasai> Florian, this is the same problem as border-color. Rossen: If you're animating something to inherit and the inherited value is being animated, as long as the computed values resolve to animate-able it should work. Both center and counter-center are just two angles. I don't see how this is bringing something new to the way you would resolve your animation graph. Florian: I was hoping it wouldn't, but the previous discussion suggests that we may need to make it explicit. fantasai: We need to make it clear if they're computed values on their own or if they compute through. How they animate falls out from that. We had a similar issue with animating border and border-color. Rossen: Reasonable. How about accept the change to rotate and record an issue to make the interaction between the keywords and animations clear. Rossen: Is that okay? jihye: Yes. fantasai: I think the issue is make it clear if it's a computed value and we can make a note on the implication of that decision on animations. We need to make sure if they compute through to the value on the other property or not. fantasai: We probably want dbaron to look at that decision. Florian: We can record as an issue and move on. RESOLVED: Accept the proposal and make it clear if it's a computed value or a specified value and make a note on the implication of that decision on animations. Polar Origin ------------ <Rossen> https://lists.w3.org/Archives/Public/www-style/2015Nov/0155.html <jihye> https://drafts.csswg.org/css-round-display/#polar-origin-property jihye: At TPAC it was resolve dot add polar-origin independent of transform origin. I updated round display. jihye: There was consideration of positioning elements with polar positioning and abspos. jihye: Before adding the polar-origin property the origin of polar coordinate was always the center point. jihye: For that reason we can't use...without polar-origin we can't use abspos with polar positioning. With polar-origin we can achieve the same effect as abspos. Polar positioning is then applied based on polar-origin. jihye: There may be a situation about adjusting the element's position horizontal or vertical after being positioned in polar coordinates. Do we need to apply abspos to elements in polar coordinates? <Florian> I don't think polar-origin should have any effect unless polar positioning is turned on. I don't think polar- origin should turn on polar positioning on its own. Florian: If I'm understanding correctly, I don't think I agree that polar-origin should turn polar position on. It should do nothing unless we're doing polar positioning. <fantasai> +1 Florian: That seems like a simpler model. I saw the suggestion on the mailing list, but it confused me more. BradK: I think some of the thread was in response to my e-mail. I haven't had a chance to review the e-mail. My idea was polar would work within abspos or fixedpos. It would be more similar to top, right, bottom, left. They start as auto and when you set a value they position themselves. That's why I suggested one would be auto as a start and when you give it a value it positions according to polar- coordinates and you can use top, right, bottom, left. Florian: If we did that, I think polar-distance should have the auto. BradK: It's either polar-distance or polar-origin. One being non-auto would be the trigger. Florian: I think we should think on that separately and add polar-origin non-magic now. BradK: I don't know if it's magic. It's more in keeping with other position properties. Florian: The wording wasn't good. But if we switch away is a different conversation than if we should have polar-origin. I think they're both worth discussing. BradK: Is polar-origin still needed if we have the polar properties as part of abspos? Florian: Ah. I see what you mean. Maaaayybe. Florian: So you're saying if we could use abspos it would be left/right instead of polar-origin? BradK: Yeah. Florian: That sounds confusing because you want polar-origin to default to the center. BradK: I think it would be by default horizontal center if you didn't have left/right. Or you have a center property which I've been wanting for a long time. Rossen: Value or property? BradK: Property. One that works like left and right, one that works like top and bottom. BradK: Or, in the example I gave, for horizontal center, you position the center of the positioned item with whatever you want in terms of percentage. The center could line up with the end of a slider. Rossen: Going back to the issue. Do we feel like we have enough to resolve now, or does this go back to the mailing list? It sounds like there's quite a few opinions and it sounds like a more general change of the actual model. I don't think we can resolve on a large change with only a subset of the WG and not much thinking. Rossen: I'd suggest we take this all back to the mailing list. Florian: So either we take everything back or resolve to add polar-origin with the understanding that BradK's suggestion may change the whole model and make it unnecessary. Rossen: That sounds reasonable. <fantasai> +1 to resolving on polar-origin and also on exploring Brad's proposal further Rossen: So accept the current model, resolve on polar-origin and continue the discussion on changing the model as per BradK's suggestion. jihye: Okay, we can discuss at mailing list. BradK: I'm okay accepting polar-origin for now with the understanding it might change if we move it into positioning properties. Rossen: So BradK's challenge will continue on the mailing list. As the polar-origin stands in the current model, anyone opposed to adding? RESOLVED: Accept the polar-origin changes. Rossen: We'll continue the other conversation on the mailing list. Page Floats =========== Rossen: Which topic do you think we can do in 10 minutes? fantasai: I don't think we can do either. There's a lot going on in that thread that's really interesting. I don't think solving them will work yet. johanneswilm: If we don't have anything else, I think we could say something about inline-start. Rossen: We have enough things on the agenda. Those topics were brought up by the most people. If you're okay to continue on the mailing list we can postpone the page floats topics for a week. It's up to you. johanneswilm: It's fine to take them up next week if we continue on the mailing list. Rossen: Continue on the mailing list for the time being. Florian: For the page floats. The subject is large enough we may want a separate call since it could take an entire conference call. johanneswilm: Agreed. Rossen: Agreed. I think a number of people will want to participate. If johanneswilm and Florian, you can coordinate, we can get on the phone and get it out of the way. johanneswilm: I can try and coordinate with Florian. <gregwhitworth> Can you include me Johannes as well Match-Parent and Orthogonal Flows ================================= Rossen: 3 topics left. line-grid, css-page, and the pre-wrap topic brought up at the beginning of the call. Florian, which can we do in 7 minutes? Florian: line-grid <Rossen> http://lists.w3.org/Archives/Public/www-style/2015Oct/0233.html fantasai: I think you're right we create new grid. <astearns> Makes sense to me. Rossen: With my implementor hat restarting the grid makes the most sense. When we do have subgrids in the grid module, if the subgrids have orthogonal flows I wouldn't want to match. Rossen: Objections? RESOLVED: Line-grid will restart in the case of orthogonal flows between parent and child. Additional Page Sizes ===================== <Rossen> http://lists.w3.org/Archives/Public/www-style/2015Oct/0234.html Florian: We have two values of the size property/descriptor. The sizes can be B4 or B5. These are ISO sizes which are different from JIS sizes. Japan uses JIS sizes and they are one of the few places that use the B sizes frequently. I don't believe many people use ISO B sizes. Japan uses B sizes for paper, it would be good to actually use it. Florian: I propose to add JIS-B4 and JIS-B5. There's a whole bunch more we could support, such as A6. But since we already have the B values, adding JIS version would save a lot of confusion. Rossen: Sounds reasonable to me. <dauwhe> Prince has quite a long list of supported sizes: http://www.princexml.com/doc/page-size/ Rossen: The current spec has B4 and B5. Are you proposing to add JIS-B4 or also rename the existing? Florian: Minimum is to add JIS-B4 AND JIS-B5. We could also add ISO-B4 and ISO-B5 which alias to B4 and B5 since they're already there. I don't care strongly between those options. I think the original proposal was to add the ISO but as long as we have JIS I'm good. Rossen: I'm in favor of the minimal change of just adding JIS-B4 and JIS-B5 and leaving B4 and B5 as they are. Other opinions? dauwhe: That minimal change sounds reasonable to me. Rossen: Any objections? RESOLVED: Add JIS-B4 and JIS-B5 to page-floats. fantasai: I'm happy to add the changes, but Florian can just add them. ACTION Florian add JIS-B4 and JIS-B5 values to the page spec. <trackbot> Created ACTION-744 Rossen: Looking through, are all the listed editors active? plinss: Melinda isn't active. <dauwhe> https://drafts.csswg.org/css-page/ Florian: The editor changes are done in the ED. Rossen: Okay, great. Florian: In the 12 sec left, in a future version of the spec we should consider a more robust list. All editors that care about print have a longer list. More things would make sense. Rossen: It would be great if you can summarize those in an e-mail. Rossen: That's the top of the hour. Thank you everyone.
Received on Thursday, 12 November 2015 10:26:39 UTC