thomnah

well you should be able to place more "sub" conversions into parameters of the same event name

true, i think the new design saves them money (more efficient data model); and drives people into BigQuery which will eventually be paid. But i have to say that GA4+BigQuery gives a powerful combination.

Custom CSS properties make CSS even more powerful. For example you can configure a menu to fade in fullscreen on mobile while sliding in from left on desktop.

That probably a good way to follow in future...

that's funny because i was always annoyed about the back functionality deleting all my carefully entered form data when unintentionally activating this gesture. Anyway you are right. we need to make this configurable. Apart from that i find it very intuitive to use the touchpad swipe for in app navigation as it feels very much as on mobile devices.

The concept behind layerJS is very fundamental, so fundamental that one even thinks its already there. It must be there, but it's not. We looked deep. So we created a polyfill (please see my previous response). Of course you can code every effect that layerJS can do manually. But then you would need to do so...

this is a very valid request. And we are thinking about it. But note that layerJS is not a collection of effects. It actually uses the same mechanism for every effect (that's the concept behind it). Maybe we can off-load some of the routers and some of the transitions types...

Oh hey, that's quite a critical comment. But usually the best comes out of criticism. So let me go a bit deeper to explain our case. layerJS is not implementing a single UX effect. Then it would be indeed a bit too big for that. (Actually using jQuery + 1 plugin per effect would be even bigger) layerJS implements a general UX concept that can handle basically all UX navigation pattern. It actually thinks HTML further: Instead of documents that are linked and loaded one after each other it actually links fragments (frames) into different views (stages) in an animated way. With regular HTML documents you need code everything that is dynamic. And that actually makes things more complicated because you can't see from the declarative HTML how the final UI will look like. layerJS makes the UI layout and most of the interaction declarative, so everything is clearly declared in static HTML. And i think that the boilerplate for this is pretty small. So your notion that some of the declarations should be in CSS or so is totally agreed. But we can't do this right now because the browsers do not support this yet. So for example the scrolling example is not working in pure CSS because we are actually allow something like "background-size: cover" (which usually only works for background images) to actually work on any frame while still allowing (or not allowing) scrolling. This we have to implement in javascript today and for this we need something like "lj-no-scrolling". If the browser guys find the concept intriguing they may at some point implement similar mechanisms directly in HTML. For now I see layerJS as a polyfill for these concepts that may vanish at some time. I hope i could clarify things a bit. Please let me know if that raises more questions. I really appreciate your long feedback, even if negative. I know from experience that out of those often good things arise!

no there is no dependency in layerJS. Also not on jQuery.

yes, that's on the todo list to couple scrolling of two overlapping layers (e.g. scroll other layer x times)

totally agreed. I went into the declarative/static argumentation on medium https://medium.com/@layerjs/getting-started-with-layerjs-17f... but it really depends on the audience if these terms trigger the interest.

basically layerJS will reparse if it detects a change rigth inside one of its objects. This works for example in a vuejs app we create. If the framework actually rebuilds the whole DOM hierarchy the layerJS parse would need to be triggered manually. Let me know if you get into this situation so we can tackle it.

this actually works. I just use the short forms in the documentation because it is more compact and more understandable

actually this is currently handcoded calling the JS api of layerJS at specific time points. Let me know if you need this somewhere i can share the code.

This is really not meant restrictive. Its basically MIT and only restricting one particular use case (if you want to build a webeditor like WIX, etc. ) It's currently protecting our baby startup (layerjs.com) and should avoid that someone is using layerjs.org (which will be used inside) to get an competitive edge on our baby (: So don't be to harsh on this. We will remove this clause altogether once time is ready to launch.

not intentionally. It's scrolling inside a div and not on the body. So the reason must be somewhere there. I have to look into it.

Thanks!

can you post a screenshot at [email protected]? and which device are you using? Thx!

Thanks. Yes you are absolutely right. It is of course a JS library, but its API is full "HTML". So you only need to do things to your HTML to control it. Actually we think that the concepts of layerJS are pretty much in line with the HTML concepts esp. the box model. So maybe one day all this fitting and transitioning (==linking) will be natively supported by the browsers and then really no JS will be needed.

The video (actually an animation) had some trouble on safari where the container background was on top of the 3d elements. I hope its that one. This is hot-fixed right now

The chat window should actally open only after a minute. I know it can be a bit nasty but we need feedback (:

Made a hotfix. Still has a little issue that the overlay text sticks through the frames. Should be useable for now. Thanks!

The way it is getting along with other frameworks is that makes as little asumptions as possible. So layerJS will only deal with divs that have the attribute "lj-type". The it will only show, animate or hide them. There are a few exceptions to this but that's basically it. So if another framework like vue modifies other elements on the page its free to do so. layerJS actually has a few mutation observers lurking around to see if the dimensions of frames or stages change to adapt the view accordingly. So that means that other frameworks can modify the DOM the way they want and layerJS will adapt. If there may be some hickups in special cases, please let us know so we can fix it.

hmm, is it that you can't see the content when it enters the 3d view? It's weird safari seems to put the containing divs background color in front if the 3d animation. I'll try to hotfix that

Thx! Will fix!

That's a pitty because i think this explains the concept best. The "video" is indeed not a video. It's actually layerJS operating on a "dummy" website. We tested it on a few devices including iOS. Which device version are you using?

(: good old times

Thanks for reporting! The website uses a mechanism to load subpages dynamically. I guess the closing and opening restores the history, but reloads the page from the server. The the content from layerjs.org is missing, but the history "thinks" its there. So we need to catch this...

yes, layerJS needs a "Stage" where navigation can happen so the scrollable content will be inside that Stage. In this case the body is the stage and the page is a frame inside it. We are working on something where the stage length adapts to the frame length. Then the body will become as long as the full content and native scrolling would even work if there is no JS