Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allocate from existing dom node #92

Closed
ghost opened this issue Jun 9, 2014 · 5 comments
Closed

Allocate from existing dom node #92

ghost opened this issue Jun 9, 2014 · 5 comments
Assignees
Labels

Comments

@ghost
Copy link

ghost commented Jun 9, 2014

we get our ember.js integration nearly ready to publish.
To prevent dirty overwriting of methods in both frameworks we need any way to create any famous Surface, Group, Scrollview ( mostly the allocator work ) from an existing dom element.

Is something like this planed and if yes can you provide a timing?

@ghost
Copy link
Author

ghost commented Jun 30, 2014

any news on this?

@MylesBorins
Copy link
Contributor

@DnMllr can you help answer this question?

@MylesBorins
Copy link
Contributor

I believe that you can simply provide a selector when creating a context

@DnMllr
Copy link
Contributor

DnMllr commented Aug 5, 2014

@onceatime

You can turn an existing dom node into a famo.us context by passing the node itself to Engine.createContext(), but you cannot turn an existing dom node into a famous element such as a surface or a scroll view. It is fairly important to maintain a wall of separation between the dom that famo.us controls and the dom outside of our control because we maintain a contract with existing dom content.

The problem becomes clear if we allow an arbitrary dom node to become a surface. If we manage it by making it position absolute and applying a matrix3d property to it, then it will no longer block content on the page and could mess with the way in which surrounding elements flow or are sized. Furthermore, we need to apply the preserve 3d tag to its containing element and also potentially apply perspective. Because these changes need to happen to the parent, we would be altering dom content that we weren't given explicit permission to alter. It's safer for everyone if we just make the context the clear divide between famous and non-famous.

However, for most use cases, establishing the context is usually sufficient for properly applying famous to a preexisting page. If you are trying to do something for which this is insufficient, feel free to hit me up with your more specific example.

@michaelobriena
Copy link
Member

It is possible to slurp DOM nodes and set them as the content of a Surface. There is no direct conversion to Scrollview or other higher order views but this is a matter of implementation instead of feasibility. Let us know if you have any questions and we can try and point you to some examples. Thanks!

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants