- From: Erik Dahlström <ed@opera.com>
- Date: Wed, 12 Nov 2014 16:16:18 +0100
- To: public-fx@w3.org
*Sigh*, bots... The minutes posted were missing the first half of the meeting, included below: http://www.w3.org/2014/10/30-fx-irc As text below: IRC log of fx on 2014-10-30 Timestamps are in UTC. 20:57:24 [RRSAgent] RRSAgent has joined #fx 20:57:24 [RRSAgent] logging to http://www.w3.org/2014/10/30-fx-irc 20:57:53 [ed] Meeting: TPAC 2014 day 1 20:58:12 [ed] RRSAgent, make minutes public 20:58:12 [RRSAgent] I'm logging. I don't understand 'make minutes public', ed. Try /msg RRSAgent help 20:58:29 [ed] RRSAgent, make logs public 20:58:36 [ed] chair: ed 21:00:48 [smailus] smailus has joined #fx 21:01:03 [dino] dino has joined #fx 21:01:06 [Cyril] Cyril has joined #fx 21:01:06 [shans_] shans_ has joined #fx 21:01:17 [BogdanBrinza] BogdanBrinza has joined #fx 21:01:18 [dael] dael has joined #fx 21:01:19 [cabanier] cabanier has joined #fx 21:01:25 [Rossen_] Rossen_ has joined #fx 21:01:26 [dbaron] dbaron has joined #fx 21:01:29 [astearns] astearns has joined #fx 21:01:54 [kurosawa_] kurosawa_ has joined #fx 21:02:01 [ed] Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda#Thursday_14.00_-_15.30 21:02:07 [JackAlmage] JackAlmage has joined #fx 21:02:25 [stakagi] stakagi has joined #fx 21:02:48 [ChrisL] ChrisL has joined #fx 21:03:32 [Cyril] +present Cyril_Concolato 21:03:33 [ChrisL] ChrisL: 21:03:35 [krit] Dirk Schulze, Adobe 21:03:36 [shans_] Shane Stephens, Google 21:03:36 [cabanier] rik cabanier 21:03:37 [shepazu] shepazu has joined #fx 21:03:37 [bradk_] bradk_ has joined #fx 21:03:37 [TabAtkins] Tab Atkins, Google 21:03:39 [dbaron] David Baron, Mozilla 21:03:40 [birtles] Brian Birtles, Mozilla 21:03:43 [smailus] participant: Thomas Smailus 21:03:44 [plinss] Peter Linss - HP 21:03:45 [astearns] Alan Stearns, Adobe 21:03:46 [nikos] Nikos Andronikos, CiSRA/Canon 21:03:47 [ed] Erik Dahlström, Opera 21:03:47 [BogdanBrinza] Bogdan Brinza, Microsoft 21:03:51 [smailus] participant: Thomas Smailus, Boeing 21:03:54 [bradk_] Brad Kemper, Invited Expert 21:03:54 [ChrisL] ChrisL W3C 21:04:11 [dino] Dean Jackson, Apple 21:04:16 [Rossen_] Rossen Atanasov, Microsoft 21:04:29 [smfr] smfr has joined #fx 21:05:09 [shepazu] Doug Schepers, W3C 21:05:09 [ChrisL] ^^ Simon Frazer, Apple 21:05:12 [stakagi] Satoru Takagi,KDDI 21:05:12 [dael] ed: Let's start 21:05:17 [mihnea_____] mihnea_____ has joined #fx 21:05:35 [dael] Topic: Filters 21:06:00 [dael] krit: I'd like to split this into two parts, the first is dino part. 21:06:19 [Tav] Tav has joined #fx 21:08:45 [dael] dino: I had an image on Tuesday that was showing something in the OSX UI which was basically a transparency effect where you blinked through the bg into the UI foreground. Windows has done that for a while 21:09:12 [dael] dino: We have many quests for it in web content. Parts of Safari want to do it in web content because we want to replicate the platform look/feel 21:09:48 [dael] dino: He's an image with no filter. There was curretnly no way to add a filter and have it add behind. What I proposed is a filter exactly like the filter we have now, but it takes the backdrop and applies a filter to it 21:10:12 [dael] dino: In here to apply sepia you get a nice cutout. 21:10:24 [dael] ChrisL: So it applied to the background. Is it the same as enable bg in SVG? 21:10:26 [dael] dino: It is. 21:11:04 [dael] dino: The most common is blur where we're giving that frosted glass effect. At least on OSX we extend so we feel the content is passing underneath. 21:11:16 [dael] dino: It works fine in Animations in this hack demo. 21:11:31 [dael] dino: I'm doing it all in the compositor so I can do a second rendering pass. 21:12:08 [dael] dino: You can see performance is pretty good, but it almost always req a second rending pass. Well, always. 21:12:47 [dael] dino: I wanted to show an image with 3d transforms, it's really just the backdrop as whatever is behind. There's a lot of edge cases and that terrifies me. What happens with two elements overlapping you can end up with n^2 21:13:08 [dael] dino: It was easy for me to impl this as it is now, but the edge cases may have limitations. Or if I have to do multi rendering. 21:13:16 [dael] ChrisL: Is this the same def of BG as SVG? 21:13:22 [dael] dino: Right, tree up to your point. 21:13:57 [dael] dbaron: There's a def in comp and blending for mixed blending. What if you're in something that has opacity 0.75, are you considering the stuff outside as part of your backdro. I think with mixed bend you're not 21:14:08 [dael] rik: I think we agreed it's the same. 21:14:19 [dael] dino: We can get crazy. 21:14:27 [dael] s/rik/cabanier 21:14:38 [dael] dino: [shows an edge case] 21:14:47 [dael] cabanier: So this won't do a background image, it paints before? 21:14:57 [dael] dino: Yes. If you do a solid bg color you wouldn't see anything. 21:15:05 [dael] dino: That's why it's a backdrop filter. 21:15:20 [adenilson] adenilson has joined #fx 21:15:40 [dael] shepazu: WE resolved to add bg color to SVG elements and at least outlines, maybe not borders, I don't...which would be to the bounding box. I don't think this effects that but I wanted to make you aware. 21:16:07 [dael] shepazu: I mentioned we're adding bg color to SVG elements. I don't think it interacts, but if you use this on an SVG circle with a bg it wouldn't composit with backdrop. 21:16:19 [dael] dino: I propose this is added to filters lvl 2. 21:16:26 [dael] ChrisL: And background in CSS syntax. 21:16:36 [dael] dbaron: So this is filtering and replacing backdrop? 21:16:42 [dael] dino: It's painted as a new image. 21:16:46 [dael] dbaron: transparancy? 21:16:56 [dael] ChrisL: That's why it's the enitre tree up to where you are. 21:17:11 [dael] dbaron: Where if you're something that establishes a new stacking context... 21:17:19 [dael] ChrisL: Oh, now I see lots of edge cases. 21:17:46 [dael] dino: I've taken the blurr off. If you put it really high you get a lot of transparancy and you can see the background at all. 21:17:55 [dael] dino: That's because you're seeing more of the solid backdrop. 21:18:08 [stakagi_] stakagi_ has joined #fx 21:18:11 [dael] dino: If I did blur 10 it's a softer edge b/c the filter is making more non-transparent pixels. 21:18:21 [dael] BlackCatkins: So it's a composite. 21:18:25 [dbaron] so it's not replacing the backdrop, just painting over 21:19:04 [dael] dino: There are edge cases is what I'm saying. 21:19:19 [dael] cabanier: If you do opacity on the div it'll still work. We did that the other day. 21:19:29 [dael] krit: Mixed bg mode isolates. 21:19:38 [dael] dino: b/c it's a filter it's another prop that stacks. 21:19:44 [dael] cabanier: No, because it's on the background. 21:20:15 [dael] dino: There's advantage to stacking, you can acc easier. You're giving people something to distroy page perform if it's used bad. You could end up pre rendering at least twice. 21:20:26 [dael] plinss: Do you really want to render norm or just hte filter? 21:20:40 [dael] dino: The BG is still there's it's normal paint. This says suck it out and paint again. 21:20:46 [dael] plinss: Do you want the BG to have been painted? 21:20:53 [dael] dino: It's hard to paint with a whole. 21:21:12 [dael] plinss: You almost wantt o paint, cut it out, filter what you cut out, and put it back. I'm not sure you're adding any value. 21:21:22 [fantasai] fantasai has joined #fx 21:21:24 [dael] BlackCatkins: And you don't have to paint witht he hol.e 21:21:45 [dael] dino: It will be more likely people want the effect...right now it's on the element, but you'll see the limits on my impl. 21:21:53 [dael] dbaron: It's visible in the lower right corner. 21:22:01 [fantasai] dino shows example of applying border-radius 21:22:15 [dael] dino: I think people would just want it on the content text. That's more common. That would be really hard to draw and cut out. 21:22:24 [fantasai] the blur filter is applied to the area within the border box rectangle, but not within the borders 21:22:48 [dael] krit: For filter effects we spec isolation prop to know when we have to have the backdrop. This isn't...you're suggesting we don't isolate. 21:22:59 [bradk] bradk has joined #fx 21:23:14 [dael] dino: I'm not set. I'm not 100% certain we want this. I'm getting requests and we want it internally, but people were asking for reflections 5 years ago. 21:23:25 [dael] dino: I suggest we put it in an experement and get feedback. 21:23:41 [dael] fantasai: Is this filter being applied to contents behind or to the background? 21:23:44 [dael] plinss: Behind the bg 21:24:12 [dael] dbaron: One other thought, if you still want it the way you did it where it doesn't replace, maybe this is a value of te bg property instead of sep. 21:24:24 [dael] dino: bg applies block background rather then content. 21:24:34 [dael] dbaron: I was talking about what you have there, not the other thing. 21:24:44 [dael] BlackCatkins: It sounds like you can treat it as a lower bg layer. 21:24:49 [dael] plinss: Or a filter in the list of bg. 21:24:53 [dael] dbaron: That's what I was saying. 21:25:03 [dael] plinss: And if it'st he last applies to whatever is behind. 21:25:06 [ChrisL] s/And background in/Enable-background in 21:25:11 [dael] dino: We want a keyword to say grab behind. 21:25:19 [dael] fantasai: bg images list sets how long the thing is. 21:25:31 [dael] plinss: If it's the last there's nothing to filter but the backdrop 21:25:44 [dael] fantasai: We've had a suggestion of filters to just the background. 21:25:49 [dael] cabanier: We have that in the default prop 21:25:57 [dael] fantasai: How would that play with it... 21:26:01 [dael] BlackCatkins: Then we have it. 21:26:09 [dael] dbaron: It feels like it might be harder to accel. 21:26:22 [Tav] Tav has joined #fx 21:26:40 [dael] krit: We don't have to talk about the how. This is a prop and I think it's a good one. We can discuss how to actually make the effect possible. I'm not sure if it's nec. I'd like ot hear if the WG agrees on if we want to have this. 21:26:55 [dael] BlackCatkins: The only reason we've turned things like this down before is impl/perf complexity. 21:27:02 [dael] krit: You saw there was media playing 21:27:06 [dael] BlackCatkins: It looked fine. 21:27:23 [dael] dino: Perf isn't how often you repaint it. It's more like something like nested iframes. 21:27:30 [dael] BlackCatkins: But if you only go back to the nearest. 21:27:37 [dael] cabanier: Or say you cannot nest. 21:27:43 [dael] dino: No point in discussing more. 21:27:51 [BlackCatkins] s/the nearest/the nearest stacking context/ 21:27:57 [dael] BlackCatkins: You showed witht he border radius it blurred. That was accident of early impl. 21:27:58 [dael] dino: Yes. 21:27:59 [fantasai] s/bs/bgs/ 21:28:07 [jun] jun has joined #fx 21:28:35 [dael] dino: In general you'll want to apply blend. At least in iOS and OSX it's a few filters to pop it out. As a designer you'll want to do a few extra things. 21:28:42 [dael] cabanier: And we can use noral bg for that 21:28:50 [dael] bradk: So it should follow bg clip? 21:28:57 [dael] dino: It should. I'm not a fan of that prop. 21:29:04 [dael] ed: So are we in agreement to add? 21:29:21 [dael] krit: I'm getting to level 1, but I'd say we switch back. 21:30:58 [dael] Topic: Compositing and Blending 21:31:48 [dael] cabanier: I want to give an overview of the state of the prop 21:32:00 [dael] cabanier: I have a diagram [projected] 21:32:53 [dael] cabanier: FF impl everything. Isolation is on its way. Safari shipped with complete support. They didn't impl blend-modes. 21:33:03 [dael] ChrisL: When FF does isolation can we exit CR? 21:33:22 [dael] cabanier: I don't think it needs to be shipping. Chrome supports everything if you turn on experimental features. 21:34:02 [dael] cabanier: ed Is working with adobe on accelerating in Chrome, he's making a lot of progress so hopefully it'll run optimally even on mobile 21:34:11 [dael] krit: It's performance optimatization 21:34:17 [dael] cabanier: Correct. It'll run. 21:34:32 [dael] ChrisL: Anything on IE that will give us pause. 21:34:41 [adenilson] Hell no! 21:34:50 [dael] Rossen_: It will happen, it's not a hell no. 21:35:02 [dael] cabanier: There's no flaws that make you unable to impl? 21:35:06 [dael] Rossen_: I don't believe so. 21:35:39 [cabanier] google doc: https://docs.google.com/spreadsheets/d/1vVyNnV4RwA9ga0ARgHY51v37MObpJX7jyFRlIs92-BI/edit#gid=2066776056 21:35:50 [ChrisL] https://status.modern.ie/compositingandblendingincanvas2d?term=composit 21:35:57 [dael] cabanier: It shows it's not just adobe working on it. 21:36:44 [dael] cabanier: krit went in and went over the individual, who commited what and when. The impl are completely diff. There'a almost no shared codes, the blending is done diff on backends. 21:36:56 [myakura] myakura has joined #fx 21:37:16 [dael] cabanier: So now we have support on background-modes. The Chrome dashboard shows it's going up a bit. There's a trend. 21:37:30 [dael] cabanier: If you go to code pen you find new examples every day for blend modes. 21:37:47 [dael] cabanier: People are excited about it and loggin bugs. 21:38:00 [dael] cabanier: Safari shipped and has good performance. 21:38:33 [dael] cabanier: [shows and example with lots of blends] 21:39:22 [dael] cabanier: People are making little animations, seems to work okay on all browsers. This morning there were a couple things on the spec. We resolved on the last issue and decided to keep as is. Someone from Samsung noticed an error in the spec. 21:39:50 [dael] cabanier: I talked to stevez and he believes since we're taking out a feature and isn't impl anywhere we don't have to go back. 21:40:06 [dael] stevez: y ou need a revision for the PR. 21:40:15 [dael] cabanier: So I think we're ready. 21:40:49 [dael] cabanier: We also have many tests on the CSS WG repository. The HTML part is tested well. SVG has a couple tests. I'm sure we'll write more. We need to test the feature we talked about this morning. 21:41:00 [dael] krit: 80 doesn't sound like much, but each has sub-tests. 21:41:20 [dael] krit: Since we have 2 impl of every feature, I think it's popular to move on. 21:41:32 [dael] ChrisL: Since we have a chair from each WG we can decide 21:41:35 [dael] ed: Any obj? 21:41:49 [dael] RESOLVED: Move Compositing and Blending to PR 21:42:06 [dael] cabanier: We have 4 weeks since there's a revision doc. 21:42:29 [dael] plinss: Do we have sufficent passes on all tests? Have we met the CR exit criteria. WE have a test suite, does it pass? 21:42:32 [dael] cabanier: Yes. 21:42:38 [dael] plinss: Okay. So we can gen a report. 21:42:45 [dael] Topic: Filtering Level 1 21:42:50 [Tav] Tav has joined #fx 21:43:27 [jun] jun has joined #fx 21:43:31 [dael] krit: Level 1 there's many things added. They're shorthand filters. 21:43:52 [dael] krit: Something that is still missing is auto computed filter regions. For SVG you need a clipping region. 21:44:18 [dael] krit: By default the filter has a reach of 10% margin. To define automatic filter isn't simple b/c browsers have diff optimaizations. 21:44:39 [dael] krit: I suggest that we delay the automated filter reach to second level b/c everything else except one thing is impl in 2 broswers. 21:45:37 [dael] krit: There's a shorthand that ref bendmodes. There's two impl for shorthand filters. It's not in SVG yet, but I'm suggesting we finalize filter effects so we can get to CR in the next few weeks and go to the 2nd letter to add features that were requested. 21:45:54 [dael] krit: I'd like agreement from both WG that we dealty filter regions. 21:46:16 [dael] BlackCatkins: So right now the filter region is bounding block plus margin? 21:46:51 [dael] krit: Yes, for SVG. You can make it bigger and as a sizable canvus, but they're not common. You don't see it to make this computation automitically. There aren't actually impl. You can do notes. 21:47:06 [dael] dbaron: The idea of the auto filter region is to behave as thought the region is infinite? 21:47:20 [dael] krit: Yes but many primitives aren't optimized. 21:47:45 [dael] krit: The second part is the code needs to be rewritten in several places. Right now you can assume a % and I think this is delaying the whole spec. 21:48:02 [dael] krit: Shorthand filters aren't supported by a few, but I assume this will change not too far in the future. 21:48:13 [dael] ChrisL: So it's one of those not enough days in the week? 21:48:23 [dael] krit: Yes. There's no limit on doing it, it's just the time. 21:48:46 [dael] ed: So objections to moving the automated filter to level 2? 21:49:08 [dael] dbaron: I thought we had code to automatically figure out which regions were needed. Maybe some of those hard filters miss that? 21:49:16 [dael] krit: Yes, they cannot use it for automatic filter. 21:49:20 [dael] dbaron: I guess I'm okay with it. 21:49:31 [dael] krit: I'm not saying you can't... 21:49:51 [dael] BlackCatkins: Since for the CSS shorthands you can't spec a filter region you're stuck with a large blur only extending 10%? 21:50:20 [dael] krit: If you haev SVG referened. If you have blur you don't have the margin. If you look at te actual filter, there's only 2 that extend area. The others make in pixel changes. 21:50:29 [dael] krit: There's code for SVG displacement. 21:50:40 [dael] BlackCatkins: So blur and drop shadow have a filter that makes it work? 21:50:41 [dael] krit: Yes. 21:50:54 [BlackCatkins] s/filter/filter region/ 21:50:59 [dael] ???: That works for SVG. The drop shadow? 21:51:02 [dael] krit: Yes. 21:51:10 [ChrisL] s/???/Tav/ 21:51:22 [dael] RESOLVED: move automatic margin computation to level 2 21:51:32 [jun] jun has joined #fx 21:51:46 [dael] ed: Any more on that? 21:52:04 [dael] krit: I'd like to pub a new WD. A new one would be good. 21:52:11 [dael] ed: Can we resolve on a new WD? 21:52:21 [dael] Tav: When do you start level 2? 21:52:48 [dael] krit: I'm trying to get this to CR this year. I'm happy with another editor working on the next level, but for me the focus is to move this to CR. 21:53:03 [dael] ChrisL: But if you're taking out of this it makes sense to have somewhere to put it. 21:53:11 [dael] ed: I'm jsut thinking since we're in the same room. 21:53:21 [dael] s/jsut/just 21:53:44 [dael] RESOLVED: Publish a new working draft of Level 1 21:53:57 [dael] ed: Anything more? 21:54:08 [dael] krit: Nothing right now. There's a lot that needs to work through the process. 21:54:19 [dael] ed: So the pertinant parts are edited. 21:54:44 [dael] Topic: Motion Path 21:55:24 [dael] krit: So this spec allows you to spec path and the obj gets positioned on this path. When you animate the offset you get smoothe animation. The prob is when we have % values than it must be relative to something. 21:56:10 [dael] krit: For HTML it might be relevent to boxes. I don't believe for HTML we need a ref box. It doesn't make sense to switch between margin box b/c they're similar. For SVG we don't want to limit by bounding box for instance. You might want it relevant to bounding box. 21:56:30 [dael] krit: I suggest adjust acording to canvas size or allow to switch between canvas and bounding box. 21:56:38 [dael] Tav: Why not the path length? 21:56:54 [dael] ChrisL: I think tht's more consistant with outer parts of SVG where we've had 2. 21:57:12 [dael] krit: On CSS model I'd like to stick what we have in masking if we switch between html reference. 21:57:30 [dael] krit: I'm not sure if stroke box is nec, but fill box and ??box they can be useful. 21:57:33 [Tav] Tav has joined #fx 21:57:46 [dael] krit: I'm not sure how to integrate, but I'd like feedback to see if we should explore this. 21:58:05 [dael] krit: I can explain again. 21:58:13 [dael] birtles: What percentage? 21:58:47 [dael] krit: We have the motion path that has different shapes, this has length and percentage so the diff coordinates must be relative to a reference box, generally. 21:59:17 [dael] krit: So what do people think? Should we default to canvas and shoul we have a second box? 21:59:26 [dael] ChrisL: I think you should have a second and that makes it more consistant. 21:59:37 [dael] krit: I think if you have a viewport it would be interesting. 21:59:47 [dael] BlackCatkins: Since we're using basic shape it makes sense. 22:00:14 [dael] krit: You want to animate an element with its whole box to something. I'm not sure it's useful to switch, but since basic shapes take lengths you can make it absolute. 22:00:35 [dael] BlackCatkins: I'm not sure I see the reason why a shape inside allows a ref box. You might want an element animation around the edge of an element. 22:00:38 [dael] krit: I can see that. 22:00:52 [dael] astearns: You might want the boxes themselves to animate along 22:00:56 [dael] krit: For the content? 22:01:03 [dael] BlackCatkins: You can do that as an inset. 22:01:17 [dael] astearns: And you'd need to redo the border radius. You can do it but we have that short hand. 22:01:29 [dael] BlackCatkins: It sounds like basic shape needs to sprout a value that means shape of the lement. 22:01:37 [dael] krit: You can also say in basic shapeyou can reference the box. 22:01:50 [dael] krit: I'll try and add it, prob to motion path. 22:02:00 [dael] BlackCatkins: Which sub property? 22:02:07 [dael] krit: I think it goes witht he shape prop. 22:02:13 [dael] BlackCatkins: That seems appropriate. 22:02:32 [dael] krit: So the resolution would align motion path with shape outside to take a reference box. 22:02:54 [dael] ed: Okay. Is that it? 22:03:00 [dael] ChrisL: Do you need a resolution? 22:03:07 [dael] RESOLVED: align motion path with shape outside to take a reference box 22:03:35 [dael] Topic: transforms 22:03:49 [dael] krit: transform origin in SVG. 22:03:58 [dael] krit: [shows and example] 22:04:24 [dael] krit: The transform origin has always been the top left corner (with lots of simplification) 22:05:20 [dael] krit: Now if we have a abspos circle element which means the origin is still top left, but if you want to rotate around the axis, the issue is that center/center can have a %, just absolute values. 22:05:45 [dael] krit: What people want to do is to do the rotate around its own axis. 22:06:13 [dael] krit: What I want to come up with is make this compat with old model and hook up to what people want. abs value is always top left, % is from object bounding box. 22:06:35 [dael] krit: It is a hack. We knew that at the time. 22:07:23 [dael] krit: The bproblem is when you have a side(?) function. If you use transform it changes the size and it's confusing. The way to get out is that we spec reference points. WE say we have a viewbox and everything is relative to that. Or the fill box. 22:07:56 [dael] krit: Then 0px is 0% but it depends on the ref box where it actually is. You need to modify the current transform spec to allow user to spec reference box, which would be the same as for shape outside. 22:08:16 [dael] krit: It kind of breaks the webkit method where it's magic. They'll need to change. 22:08:33 [dael] shans_: WOuld this effect content? 22:08:44 [dael] krit: Content that already uses transform origin. 22:08:50 [dael] cabanier: Do you know how much? 22:09:06 [dael] krit: Mostly codepens. They don't work in FF anyway. 22:09:11 [dael] ??: So it's broken in FF. 22:09:22 [Cyril] s/??/Tav/ 22:09:36 [dael] krit: They're all broken. It's a hack, but we think this makes more sense. The question is getting to blink/opera/google to see if they'd change 22:09:45 [dael] ed: So the imp would change how? 22:10:04 [BlackCatkins] s/can have a %/can't have a %/ 22:10:14 [dael] krit: It's mostly the prefixes. So the webkit transform org property would need to change. For SVG people it's kind of messy with new model b/c they have to spec fill box. 22:10:32 [dael] krit: The default needs to be compat with existing SVG content which is much more likely to break. 22:10:39 [dael] krit: So did everyone understand the problem? 22:10:49 [dael] Tav: It won't break existing? 22:10:54 [dael] Rossen_: So you don't support this at all? 22:11:01 [dael] Tav: It uses a global rotation matrix. 22:11:18 [dael] krit: It didn't support transofrm origin. Blink doesnt' support either transform. 22:11:25 [dael] ChrisL: Which means impact is small. 22:11:32 [dael] Rossen_: Which is good. 22:11:41 [dael] shans_: I think if te SVG working group is happy. 22:11:56 [dael] krit: I'm not sure how long it takes for webkit to change. Safari likely wants this fix first. 22:12:05 [dael] dino: Yep, that'st e only thing stopping us. 22:12:08 [ChrisL] s/is happy/is happy, Blink would change 22:12:10 [dael] krit: That's why it's a high priority. 22:12:15 [dael] cabanier: Did you write this? 22:12:24 [dael] krit: no. I'd like feedback first. 22:12:37 [dael] krit: birtles for dbaron do you have an opinion? 22:12:43 [dael] dbaron: I didn't follow. 22:12:52 [dael] birtles: I think we only backed out due to performance. 22:13:03 [dael] ed: I'm not exactly following. You need a keyword to make things work now? 22:13:24 [dael] krit: Just for transform origin, 0px in SVG means take the top left. 0% means top left of object bounding box. 22:13:31 [dael] ChrisL: Then when you use calc it's a mess. 22:13:36 [dael] dbaron: Fixing it sounds good. 22:14:41 [dael] krit: Fix it to prob create a new...you need to have reference boxes, that's the first thing. They're prob not needed for HTML since they can use margin box. We need fill box and stroke box for defaults. I want to have those two keywords added to transform prop or a new one because transform has the same problem. You also have translate with that problem. 22:14:52 [dael] BlackCatkins: So CSS has no prob because ref box is the border box. 22:15:10 [dael] krit: I'd rather a new prop because it's diff with animating the property. It's more difficult with SVG. 22:15:17 [dael] BlackCatkins: So a new transform sub property. 22:15:26 [dael] cabanier: You wouldn't want to extend transform org. 22:15:32 [dael] krit: Correct. 22:15:39 [dael] birtles: And the default? 22:15:48 [dael] krit: Viewbox for SVG and border box for HTML. 22:16:00 [dael] krit: Viewbox falls abck tot border box, so it's just SVG effected. 22:16:07 [dael] ed: So is it viewbox what you want? 22:16:30 [dael] krit: The problem is if you spec center/center you need the bounding box We have to think about what exists already so it needs to be viewbox. 22:16:43 [dael] krit: It's bad but nec. 22:16:59 [dael] krit: I'm not sure on a name yet if there's a suggestion. transform-box. 22:17:03 [dael] Tav: transform-reference 22:17:12 [dael] krit: That makes it sound like you're referencing something. 22:17:19 [dael] ChrisL: transform-box makes more sense. 22:17:30 [dael] krit: Can we have a resolution? 22:17:38 [jun] jun has joined #fx 22:17:38 [dael] RESOLVED: add a new prop called transform-box 22:18:13 [dael] and keywords all fillbox viewbox and borderbox 22:18:31 [dael] krit: We could add stroke box. I don't see value in that. 22:18:37 [dael] Tav: I want to make sure. 22:18:58 [dael] krit: fillbox is a bounding box. That name already was chosen. 22:19:11 [dael] Tav: It's the same as a geometry box. 22:19:26 [dael] krit: s/all/are 22:19:38 [dael] ed: I think for consistancy we should have boxes. 22:19:49 [jun] jun has joined #fx 22:19:49 [dael] krit: Will any impl support them? 22:20:12 [ed] s/have boxes./have all the available *-box keywords./ 22:20:14 [dael] ChrisL: For impl are they going to put the extra code in to do it? They may be parsing those string and need to add a special case. 22:20:30 [dael] krit: I say the others don't make sense and we shouldn't add them there for consistancy. 22:20:52 [dael] shans_: It really just needs to be a top left width and height value. 22:21:02 [dael] ed: I'll settle. It's not extra cost. 22:21:23 [dael] krit: Do we want to add something not used to make it consistant? If people request it we add it. It's not a big cost. 22:21:26 [dael] ed: Yeah. I guess. 22:21:39 [dael] krit: If impl do the other boes, by all means we'll add it. 22:21:47 [dael] s/boes/boxes 22:22:05 [dael] krit: That's it. 22:22:22 [ed] s/I'll settle/I'd settle for adding stroke-box/ 22:22:48 [dael] Topic: Geometry Interfaces 22:23:23 [dael] ed: We have 5 minutes to break. 22:23:33 [dael] krit: Mine might be long. Let's do a break. 22:23:43 [dael] Tav: I've got a 5 min topic 22:23:46 [Tav] http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/index.html 22:23:55 [jun_] jun_ has joined #fx 22:24:04 [dael] Tav: I don't have anything to propose. 22:24:17 [dael] Topic: Color Interpolation 22:24:48 [dael] Tav: [Goes to the bottom of the ex and shows a color change with zoom] 22:24:55 [dael] ChrisL: It's because of gamma function 22:25:21 [dael] Tav: As we move to things using 16 bit color you're not going to get the right answer. WE want to keep this in mine that we want to do this in the right color space. 22:25:29 [dael] BlackCatkins: Can you explain the squares? 22:25:45 [dael] Tav: Top left is 2x2 bitmap, a checker board 22:26:01 [dael] Tav: The other is SVG rectangles, same thing. 22:26:10 [dael] Tav: What you expect is bottom right, what you get is the left. 22:26:26 [dael] BlackCatkins: So the SVG averages to #bbbbbb 22:26:54 [dael] Tav: If you're color is right, te top two should be the same at zoom 0. 22:27:05 [dael] BlackCatkins: So the top two and bottom right should be the same. 22:27:50 [dael] Tav: They should look like the bottom left. 22:28:02 [dael] Tav: This only works with normal def screen. 22:28:25 [dael] Tav: For the future when you think about imaging, think about the color space. 22:28:31 [dael] krit: What's the request? 22:28:42 [dael] Tav: When you scale p/down it should be in a linear color space. 22:29:02 [dael] Tav: Also gradient interp stuff. Weird colors and washedout stuff. 22:29:07 [dael] ChrisL: It needs to be linear like. 22:29:17 [ChrisL] so it needs to be in a linear-light colorspace 22:29:21 [dael] [30 minute break] 22:29:32 [ChrisL] s/like/light/ 22:54:35 [shans_] shans_ has joined #fx 22:59:19 [shans__] shans__ has joined #fx 23:00:39 [jun] jun has joined #fx 23:00:52 [smfr] smfr has changed the topic to: http://tavmjong.free.fr/SVG/tpac_2014.html 23:04:17 [bradk] bradk has joined #fx 23:10:11 [dael] Topic: Geometry Interfaces 23:10:18 [dael] ed: Let's start. 23:10:29 [dael] krit: The idea is that it defines basic geometry interfaces 23:11:03 [dael] krit: It uses CSS OM view, SVG DOM. They're DOMPoint, DOMRect, DOMQuad and DOMMatrix. 23:11:10 [dael] krit: There's one impl, which is FF.. 23:11:25 [dael] krit: Most are in Blink, but there's a discussion about how. It's not if, though. 23:11:45 [dael] krit: DOMRectList is in there fore legacy. 23:11:55 [dael] krit: Some browsers call it ClientRecList 23:12:27 [dael] krit: Things that are less controversial are DOMPoint, DOMREct, and DOMQuad. So far they're agreed with. 23:12:48 [dael] krit: One issue on DOMMatrix interfaces. There's an issue that was submitted here. 23:13:23 [dael] krit: First, it's supposed to be an interface that does everything SVG Matrix and the webkit and trident impl do. This is to unit the interfaces. 23:13:38 [dael] krit: There's nothing specified for inverse, which algo it actually takes. 23:14:05 [bradk] s/unit/unite 23:14:12 [dael] krit: There was a discussion on the ML, but we cannot gaur the inverse givs you the mathematically correct result due tot he biany system. So should we have an algo that we try and follow? 23:14:54 [dael] krit: I say we don't. Most things require functions that are trignomic fuctions that aren't precisely speced. Every hardware differes on these so we can't give the same on all platforms. 23:15:32 [cabanier] spec: http://dev.w3.org/fxtf/geometry/ 23:15:35 [dael] krit: Also because invers is supposed to reflect what the impl itself does because the DOMMatrix is reflecting the rendering part of the browsers. So it should be up to each browsers. I suggest not spec an algo, but they should use one part of their engine already. 23:15:42 [dael] dino: As long as it does inverse. 23:15:59 [dael] cabanier: If it cannot be inverted, we wanted it to return a matrix, not throw. 23:16:10 [dael] krit: We agreed on that. So should we have a spec algo. 23:16:16 [dael] adenilson: I say no. 23:16:27 [smailus] smailus has joined #fx 23:16:27 [dael] BlackCatkins: Who requested it? 23:16:36 [dael] krit: adenilson. 23:18:14 [dael] adenilson: We're on the same page with algo, my sug was in the domain of math. We have an inverse math part of the interface. 23:18:57 [adenilson] http://en.wikipedia.org/wiki/Moore%E2%80%93Penrose_pseudoinverse#Existence_and_uniqueness 23:19:22 [BogdanBrinza_] BogdanBrinza_ has joined #fx 23:19:24 [smailus_] smailus_ has joined #fx 23:19:37 [dael_] dael_ has joined #fx 23:19:48 [Rossen__] Rossen__ has joined #fx 23:19:58 [dael_] adenilson: The second property of hte matrix is such that the inverse will be the same. 23:20:27 [dael_] ChrisL: So to restrate. The normal inverting has correct, incorrent, or can't. For this you always have an inverse for correct, if you have something else it still gives you an inverse. 23:20:34 [ChrisL] so it gives the same result if it was invertible 23:20:46 [dael_] adenilson: This is a pseudo inverse for real or imaginare, so if you have non-square you can still calc the pseudo inverse. 23:21:48 [dael_] adenilson: I have two alt proposals. The first is could we add a pseudo inverice interface to the DOMMatrix? Second is since we have this mathematical property where the pseudo is the same, why don't we specify so that if there is a cononical inverse you return it and, if not, say you're wroking with non-square. 23:22:49 [dael_] adenilson: There's problems with both. Mathematical software has two mathods, one for cononical and one of pseudo. There's one called maple that goes with my second suggestion. If there isn't a canonical inverse you return the pseduo 23:22:55 [dael_] Rossen_: How do you know which you get? 23:23:35 [dael_] adenilson: If we always return a valid matrix, we may have an attr to let the user know what he is recieving. 23:23:53 [dael_] adenilson: To have a better feeling, I'm going to demonstrate the concepts. 23:24:27 [dael_] adenilson: I have a matrix, I can calc the pseudo inverse. Since this was well behaved I can calc the inverse. 23:25:09 [dael_] adenilson: If neither suggestion sounds right, I would suggest we have the single value composition matrix avail so if you have non-sq you can use SVG to calculate. 23:25:46 [dael_] adenilson: I have a 4x9 can use SVG to calc the inverse. So it would be the same. But there is other algo where you can implement it 3 to 5 times faster than SVG. 23:26:21 [dael_] adenilson: If we have bigger matrixes the same algo can be 5 to 7 times faster. So it may sound like this is a silver bullet, but everyone knows that's not possible. 23:26:58 [dael_] adenilson: There's an example where you may have numerical instability. It will be slightly different, but it is very close. 23:27:58 [dael_] adenilson: I think we have benefits of supporting non-square matrix. The morpin rules have some great properties. So if there is the real inverse it'st he same. If we don't have this, we should have SVG, but there are more performance tradeoffs. 23:28:23 [dael_] ChrisL: So you're proposing something that always gives inverse and is faster and gives you the same result or the same if rounded to a decent level of percision. 23:29:10 [dael_] adenilson: The morpin rule's inverse of itself will be the martrix itself as expected. 23:29:13 [bradk] http://cdn.meme.am/instances/500x/55804757.jpg 23:30:16 [ChrisL] s/percision/precision 23:30:24 [dael_] adenilson: I think we can have the argument that we can always have perfectly formatted matrix. I think once this is impl we will have people using all kinds of matrixes. I think addressing the non-square matrix would be nice since part of the reason for spec is for contrent authors to have power. A canonical inverse would cover some cases, but this would cover even more cases. 23:30:27 [dael_] adenilson: Questions? 23:30:35 [adenilson] https://gist.github.com/Adenilson/faddfbf29b5f9dc77d81 23:30:41 [adenilson] https://gist.github.com/Adenilson/96354ee274d2864cdcae 23:30:47 [adenilson] https://gist.github.com/Adenilson/5ad519e92edb8a5f6041 23:31:13 [adenilson] http://cran.r-project.org/bin/macosx/ 23:31:15 [dael_] adenilson: There are several ways to impl this. We can suggest faster, but the browser impl would have the freedom to impl in whatever way they want. 23:31:31 [dael_] adenilson: The last link is the math program referenced. 23:32:13 [dael_] krit: I like this algo, but we're not looking for mathematical precision, we're looking for the same answer as impl. If they decide to use this to compute an inverse, that's absolutely fine. 23:32:48 [dael_] krit: You also showed us it could be more efficent so it might be used. We want the same result the engine gets for the rendering, not something mathematically interesting. If it's used for rendering, they should use it the same way. 23:33:21 [dael_] ChrisL: It's not an algo. You're saying they must calc an inverse. This prop is defining what sort of inverse you should get. They can use whatever algo they want to get the result. 23:34:26 [dael_] shans__: There's matrix we can calc, there's ones the we can't, and it's the ones at the edge that are the problem. Diff impl get different results for those IT would be a shame if the JS inverse and the browser inverse weren't the same. It's making sure of consistency. I think we should try and persuade browsers to switch to this, but it's a diff conversation. 23:35:11 [dael_] adenilson: If you phrase the spec that the user by calling the inverse will get a canonical inverse or a morpin rule pseudo, you free up users to work with non-square matrix. How they're impl the algo is up to them 23:35:30 [dael_] adenilson: If you say by calling inverse you only calc a canonical inerse, you rule out non-square. 23:35:36 [dael_] dino: This is always square. 23:35:42 [dael_] adenilson: So you should change the name. 23:35:51 [dael_] cabanier: It's the matrix in DOM, it's not a general class. 23:36:15 [dael_] dino: What would be interesting is if JS exposed a matrix class that is generic n x m 23:36:48 [bradk] http://cdn.meme.am/instances/500x/55804968.jpg 23:36:56 [dael_] dino: in this case we're really only talking about exposing the API to what we already have in the impl. It's never designed for general math use, it's really only for transforms and to match the ones don natively in SCG and CSS. 23:37:08 [dael_] cabanier: And the inverse is to re-calc the origin or something. 23:37:10 [ed] s/SCG/SVG/ 23:37:46 [myakura] myakura has joined #fx 23:37:56 [dael_] shans__: I think this is interesting and I think we should use this internally in Chrome. Maybe as a WG we can pub a technical manual that suggests using this, but I think it's counter-productive to say this is required. 23:39:03 [dael_] adenilson: I'm not sure if I made it clear, I'm not recommending an algo, tere's a couple ways to calc this. I think that if we add on the desc of the method that the user agents try and calc canoloical and, if not possible, they can calc the moprin rules we can make it more powerful. It addresses all our current needs and gives room for a case that we maybe cannot image at this moment. 23:39:19 [dael_] adenilson: I don't see the need to have an artificial restraint on the matrix class. 23:39:42 [dael_] ChrisL: So the matrix in DOMMatrix are always 4x4 but not always invertable. 23:39:53 [dael_] shans__: And if they're not invertable the browser behavior is different. 23:40:04 [dael_] shans__: I think there's a benefit for browsers to get into this. 23:40:58 [dael_] dino: It's worth desc the most common use for the API which is if yu're wrighting script to do a transform we waste a lot of time writing a long string. The idea is you can get a transform out, make the changes, and put it back a lot more quickly. It's supposed to match what you do in CSS. 23:41:39 [dael_] dino: And we should discuss, it's still not clear on if we can provide this API or it'll be worse performance since it's jumping from JS to native code. 23:41:46 [dael_] krit: The spec describes in JS. 23:41:56 [dael_] dino: I mean req that it's impl in JS. 23:42:09 [dael_] cabanier: And that's something the spec can't do. 23:42:18 [dael_] dino: It does feed into what the API should look like. 23:42:33 [dael_] ??: Is the background infomration that it should match what's inside he browser in the spec? 23:42:38 [dael_] krit: No. 23:42:52 [dael_] dino: Many people read the spec and come to the conclusion it's designed for general things. 23:42:59 [dael_] ChrisL: It's not and should say so. 23:43:20 [dael_] ??: And maybe this inverse should indicate it doesn't give you mathematically correct because it's floating point. 23:43:29 [shans__] s/??/Cyril/ 23:43:31 [astearns] s/??/Cyril/ 23:43:43 [dael_] Cyril: The wording is too vague. 23:43:53 [dael_] ChrisL: Add the word transformation matrix to start. 23:44:03 [dael_] shans__: It says witht he purpose of desc transformation. 23:44:11 [dael_] ChrisL: How would yu use a 10x10 matrix? 23:44:29 [dael_] ed: It sounds like we're getting toward a conclusion. 23:44:45 [dael_] ChrisL: It sounds like the text clarifies but people aren't understanding. 23:45:07 [dael_] shans__: If you're looking at the spec you look at background and drop down. Maybe it should be the first sentence of the doc. 23:45:16 [dael_] cabanier: It's the first sentence of the section. 23:45:23 [dael_] krit: Even the first sentence helps. 23:45:45 [dael_] krit: In general this is the last issue for this spec. I think it was pub last time beginning of Oct and no issues since then. 23:46:06 [dael_] krit: So do we proceed witht his spec? We've fixed and resolved the mentioned issues. 23:46:19 [dael_] krit: I'd like to publish a CR. Do others agree? 23:46:28 [dael_] ChrisL: I'd ask if it's okay to close with no change. 23:46:50 [dael_] krit: Would you be fine closing with no changes? 23:47:07 [dael_] adenilson: I think this is something, the spec as a whole, now so let's go to CR. 23:47:11 [dael_] ed: Are we resolved? 23:47:18 [dael_] ChrisL: So what will the next version be? 23:47:26 [dael_] ChrisL: Is it WD or...? 23:47:32 [dael_] krit: It's a WD, I'm asking for CR. 23:47:39 [dael_] ChrisL: For you have a full DoC? 23:47:40 [dael_] krit: Yes. 23:47:53 [dael_] RESOLVED: CR for Geometry Interfaces 23:48:22 [dael_] shans__: Can we capture the information on the the computational matrix? 23:48:31 [dael_] ed: Should that be Geometry interfaces. 23:48:53 [dael_] shans__: It's tc39 that needs to look at it. 23:49:13 [ed] s/Geometry interfaces./Geometry interfaces or as an ecmascript type?/ 23:49:29 [Tav] http://tavmjong.free.fr/SVG/TEXT_IN_A_BOX/index.html 23:49:34 [dael_] Topic: fitting text into a box 23:49:46 [dael_] dino: Can we do text fill first? 23:49:51 [dael_] Tav: decoration? 23:50:02 [dael_] dino: Yeah. 23:50:07 [dael_] Topic: Text Decoration 23:50:16 [Tav] http://tavmjong.free.fr/SVG/TEXT_DECORATION/index.html 23:52:36 [dael_] Tav: SVG 1.1 text decoration uses fill and stroke color 23:53:24 [dael_] Tav: If you go down a little bit, you can do things like set a section to different for text and decoration, or just part. The decoration is picked up by where you set it. 23:53:55 [dael_] Tav: CSS3 text decoration intro line, style, and color. SG can do line and style, but what about color? Do we use fill color, fill and stroke, how does it work? 23:54:27 [dael_] Tav: There's no way to do diff fill and stroke using CSS3 Text, but you'd expect that for SVG 23:55:17 [dael_] [we discover fantasai isn't here and go looking.] 23:57:09 [nikos] http://www.w3.org/2014/05/22-svg-minutes.html 23:59:35 [dael_] [we discover she's in HTML and carry on] 23:59:50 [dael_] dino: So what's the CSS proposal to do the 2nd link? -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Received on Wednesday, 12 November 2014 15:17:14 UTC