You're piling on massive amounts of attributes, making your app almost impossible to read and figure out the transitions. Anything complex is going to become a tangled pile of nodes and code. It would take anyone but the original designer a long time to puzzle out what exactly is going on and figure out the workflow, unless there's also a ton of HTML comments in there too.
You have attributes that should just be classes with CSS (overflow: hidden prevents scrolling, not sure why you need lj-no-scrolling), you have html elements that actually need to have attributes to define their neighbours, and you're just overloading your HTML with a bunch of extra baggage that doesn't need to be there.
Look at your parallax example. A 30KB library, a bunch of superfluous divs, and a ton of extra attributes you need to try to figure out have successfully replaced "background-attachment: fixed". The sliding divs could be done so much more clearly with just a bit of javascript that tracks "current frame" and hides them all then shows the next one when you click the button. The ZoomUI is admittedly pretty, but I feel like you could do it much easier with just a click event that expands the frame via changing the classes on it, rather than all the extra baggage and divs and wrappers you need to make that work. The animations are pretty, but not worth the extra baggage it takes to use them.
It's a neat toy, but I can really only see it being usable by people who are inherently terrified of javascript and will do anything to avoid it. And even then they'd only need the simplest of use-cases, and they'd need to make sure it wouldn't be on something that would need updates, because I wouldn't want to have to come back to a project with this in 6 months.
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!
While I agree with you that the implementation is not ideal, the use of "awful" is a little harsh and unnecessarily discouraging! To the creator, please don't take it to heart, but do look at the more constructive observations mentioned above :)
You are talking about their implementation. It's done in an old-school way(by extending HTML), and it would be very hard to build any sort of complex UI on this implementation.
However, the idea behind this project is pretty interesting. If you haven't already, do check out their presentation in the section "How LayerJS works".
The idea seems to be inherently "UI Composition in pure HTML", at least from the user's perspective. Which, sure, it's possible. But that's not a great idea. And the video is just how HTML works already. Firefox has had a neat inspector tool that showed you all that for years. "A div that loads above the rest and is anchored to the window" isn't new.
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...
You're piling on massive amounts of attributes, making your app almost impossible to read and figure out the transitions. Anything complex is going to become a tangled pile of nodes and code. It would take anyone but the original designer a long time to puzzle out what exactly is going on and figure out the workflow, unless there's also a ton of HTML comments in there too.
You have attributes that should just be classes with CSS (overflow: hidden prevents scrolling, not sure why you need lj-no-scrolling), you have html elements that actually need to have attributes to define their neighbours, and you're just overloading your HTML with a bunch of extra baggage that doesn't need to be there.
Look at your parallax example. A 30KB library, a bunch of superfluous divs, and a ton of extra attributes you need to try to figure out have successfully replaced "background-attachment: fixed". The sliding divs could be done so much more clearly with just a bit of javascript that tracks "current frame" and hides them all then shows the next one when you click the button. The ZoomUI is admittedly pretty, but I feel like you could do it much easier with just a click event that expands the frame via changing the classes on it, rather than all the extra baggage and divs and wrappers you need to make that work. The animations are pretty, but not worth the extra baggage it takes to use them.
It's a neat toy, but I can really only see it being usable by people who are inherently terrified of javascript and will do anything to avoid it. And even then they'd only need the simplest of use-cases, and they'd need to make sure it wouldn't be on something that would need updates, because I wouldn't want to have to come back to a project with this in 6 months.