search

gadicc / meteor-famous-views

Famous, the Meteor Way (with Reactive Blaze Templates/Views)
http://famous-views.meteor.com/
GNU Lesser General Public License v3.0
332 stars 27 forks source link

translate issues #244

Open gadicc opened 9 years ago

gadicc commented 9 years ago

Originally by @der-ede in https://github.com/gadicc/meteor-famous-views/issues/240:

When I try to put a translate="[0,0,10]" in a Surface or Scrollview and translate another View by 20 or -10, it seems to be arbitrary which Surface is shown in the front. I have tried everything, like putting a View around it, with and without align and origin, proportions or size etc., but I cannot control the behaviour of two surfaces, one in front of the other. Sometimes one is shown in front, sometimes the other surface. Can anyone help here?

gadicc commented 9 years ago

You're right, this should be enough. Other things that can affect this are style z-index or CSS class z-index. If the z-index is the same, the order in which the surfaces are mentioned is used, but this is not reliable, since e.g. using a renderController or famousIf etc could result in DOM elements being created in a different order than how you've layed them out in your template. I don't think this is really your problem though, but for reference sake, to quote from https://famo.us/guides/pitfalls:

Why is my Surface behind this second Surface?

There are a few reasons this could happen.

The order in which Surfaces are instantiated matters, in regards to browser representation. Since Famo.us creates the DOM elements in the order that your Javascript runs, the default behavior is similar to how the browser parses standard HTML. Surfaces that are instantiated first render behind newer Surfaces because their associated DOM element is created first.

Famo.us translations could be affecting your Surface's position. Check your code to see if you have any Modifiers affecting your Surface's translation in z space.

CSS z-indexing still applies in Famo.us. For Surfaces that share the same translation in z space, default DOM layering will be overridden by explicit CSS z-index values.

Other issues I've had in the past is during a transition that I do from a rendered or other callback, if I don't specify the z-index, famous just removes it, and then the instance order can make weird things happen (like moving forwards and backwards on alternating frames).

In any event, what would be most helpful is if you provide some sample code, preferably in a repo or in meteorpad or in fview-lab that demonstrates the problem. If this is a bug on our side I'd love to fix it.

gadicc commented 9 years ago

Here's a simple example where everything works... I'm not sure exactly when things go wonky for you. https://fview-lab.meteor.com/pads/Ki76SseGeSsadLzoR

ghost commented 9 years ago

Hi @gadicc,

actually I thought so. Thank you for the long, detailed and very informative answers here and in #240. Now I can better estimate what's there now and what's going on in the development. Also I am not a Web-developer, just started with JS/Meteor etc. last fall.

Yes, famousIf and Z-Index are definitely two things to play around with. So this means it's also famo.us related, not famous-views then. What you wrote and also from what I've tested this isn't really "robust" or solid yet. But also people use it out there. Maybe I have to accept it's just version 0.3.

Re too much: Yes, so for me it was too much work for one person alone as well. That is why I moved with my project to an Incubator now, where I get some money and can build up a team to help me with the coding. So right now I am only checking this out, probably I assign a teammate to this. I can only recommend this. It takes some load off your shoulders. From what I've heard, Israel is a pretty cool place for Startups.

gadicc commented 9 years ago

Hey @der-ede... yeah we need to establish where the problem is. It could be in famous. The other thing I forgot to mention is it could also be in your browser. There specific versions of specific browsers which can mess up the z-index in specific circumstances :) I don't recall the exact specifics but it's something I should have mentioned. In some cases famous worked with the vendor to get the problem fixed in a later version.

I think I wasn't clear though, famousIf should never be a problem if you're using translate. It was just an example. Basically if you use translate you really shouldn't be having problems except in the known problem areas where it's a browser bug (iirc one common instance was when overflow: hidden was used).

But yes, definitely important to understand Famous is only at 0.3. I got involved in Meteor from 0.5. It's been a fun ride. There were some major hurdles, which I took in stride since I knew it was a perview release... other people didn't realize this and got a lot of unexpected surprises. In the last few months I've seen Famous clean up a lot of things (have proper reference docs, start developing a testing suite), things are definitely headed in a good direction. We can also expect a big API change in the summer for mixed mode.

Israel is a good place for startups. This year I'm trying to get more full time coders for my main startup, this well let me spend more time on famous-views and also I hope some of those coders can assist in famous-views too (the app we're developing is using famous-views, so it does make sense).

Anyway, back to the issue... the best thing would still be to give us a minimalist reproduction demonstrating the issue so we can figure out exactly what is going on in your case.

gadicc commented 9 years ago

Also not sure if anything relevant from https://github.com/gadicc/meteor-famous-views/issues/175.

ghost commented 9 years ago

hi @gadicc,

I can do that when I find the time, also I was experiencing some issues with Firefox (ubuntu 14.04), Google Chrome seems to be fine. Thank you again