Closed excitedbox closed 2 years ago
Thanks for your feedback and support! You get a mention on the credits page :) [edit] Actually you are there already! I've got a three-second memory...
I'll implement a drag and drop for the release after 2.5.1 - I agree it should definitely be there. I've been putting it off as drag and drop isn't an area I've done much work with, but you're absolutely right...
It's a case of getting the commands right for it, and making sure the functionality is higher-level enough to be useful, but not so higher-level that the flexibility isn't there. The drag events are already supported in the core, so it's a case of isolating the most common UI result that people are likely to want and working out the syntax for the action command and any additional events for it. It could be there's one command for drag and drop, and another for swipe - both with different options - something like that. I'll have a think about it, but if you have a eureka idea for a specific one-liner command or extra events that may be needed to address a specific use case then do let me know.
When you mention a framework of most commonly used functions, could you elaborate on your vision for that? Do you mean like having separate functionality libraries for commands? Ie. one collection of commands for form handling, one collection for drag and drop, etc.? And then let developers pick and choose the commands they need? I agree that there is so much scope for new commands, and I must admit that I am beginning to get concerned about the potential for the core size to get large...
Been doing a bunch of work this last week on a complex drag and drop editing thing in vanilla JavaScript for a work project. I think I know enough about vanilla dnd now to work on this after 2.5.1. I'll attempt a combined syntax for both desktop and mobile, as I think the only reason mobile touch and desktop drag/drop events are separate is because of a perceived scrolling issue on mobile. But non-programmers (like my boss) expect drag and drop just to work the same on mobile, as fingers and mouses aren't that different. And as the developer know mobiles need to scroll, they could just leave enough space on the page for the user to scroll. So I don't see a good enough reason to warrant the events being separate, and I think they can be combined into one syntax. I'll give it a go when I get onto it and see what happens. An issue programmatically could be an android scrolling issue during the drag motion, but in theory I should be able to do something about that by detection through a touch event.
Sorry I didn't see your response. By libraries I meant things like array iterator functions string replace, character checking, getting data from a DB, submitting a form. So basically you would split these functions into sections like Utility (iterators etc), UI (Form stuff, Dropdown menus, Scroll out sidebars), DB (Getting or setting data in a DB, query filtering). Kinda like what jQuery did for JS or if you are familiar with C the std or boost libs. PHP has these built into the language (string replace, mysql etc.) and it is what makes it so useful over other languages where you have to do this yourself or use the ecosystem (JS before Jquery). Splitting it into libraries is just to allow people to find the functions they are searching for quicker, since for a bigger project you will most likely need all of them anyway.
Yeah, that's a good idea. I'm going to redo the documentation site later on in the year, so I'll split things up like you suggest to make it more obvious how you can do certain things. Like model it on the jQuery docs or something.
I guess the docs are currently a bit like a dictionary reference, and what's needed is a phrase book entry-level. Like you can't look up a word if you don't know what to look up. Most of the current docs should really just go into a section named "Reference", and then have the other areas like you suggest.
Closing - drag and drop can be handled in ACSS via a mixture of the regular DOM events for that and the new dollar variable syntax on the 2.11.0 branch, which handles raw JS syntax. That's a general handling to allow for all drag and drop scenarios and to avoid the addition of a new math/manipulation language in the browser. ACSS Docs will be re-done in the new year to hopefully make things a bit easier to grasp.
Example working syntax of a mobile-only touch slide-to-close menu using just ACSS (which makes use of JS syntax) with the mechanism as left/right CSS values. Note that the CSS transitions are just regular delay transitions and are in the CSS file - not here - this is just to show example UI syntax - additional regular, static CSS is needed for the menu HTML to smoothly close (just a transition, basically):
body:preInit {
$menuInMotion: false;
$newMenuLeftPos: 0;
}
@media (max-width: 750px) {
body.menuOpen .menuSectionsWrap:touchstart {
/* Get the starting left position */
$menuInitialLeft: parseInt(getComputedStyle(o.secSelObj).left);
$menuMouseInitialX: o.e.pageX ? o.e.pageX : o.e.originalEvent ? o.e.originalEvent.touches[0].pageX : o.e.changedTouches[0] ? o.e.changedTouches[0].pageX : 0;
$menuPointerX: $menuMouseInitialX;
$menuInMotion: true;
transition: none;
}
body.menuOpen .menuSectionsWrap:touchmove {
@if ($menuInMotion) {
$menuPointerX: o.e.pageX ? o.e.pageX : o.e.originalEvent ? o.e.originalEvent.touches[0].pageX : o.e.changedTouches[0] ? o.e.changedTouches[0].pageX : 0;
$menuSlideDirection: ($menuPointerX >= $menuMouseCurrentX) ? 1: 0;
$menuMouseCurrentX: $menuPointerX;
$newMenuLeftPos: $menuPointerX - $menuMouseInitialX;
@if ($newMenuLeftPos < 0 && Math.abs($menuMouseInitialX - $menuPointerX) > 30) {
left: {$newMenuLeftPos}px;
}
}
}
body.menuOpen .menuSectionsWrap:touchend {
@if ($menuInMotion) {
$menuInMotion: false;
remove-property: left, transition;
@if (Math.abs($menuMouseInitialX - $menuPointerX) > 30 && $menuSlideDirection == 0) {
body {
remove-class: .menuOpen;
}
}
}
}
}
I just looked at your project, and it is quite amazing what you have achieved.
I think one of the big features missing for interactivity is the drag and drop commands and get position. This will open up a world of possibilities for making editors, UIs, image uploaders, and many other tools.
I also suggest that a framework of the most commonly used functions will help increase adoption and decrease the load on the dev team as others start adding to the project. Having things like UI libraries, Db functions, form processing without having to build from scratch speeds up development and allows users to implement the modifications to make it fit their needs quickly while also giving them more code examples to work from. This will quickly build up an ecosystem of tools and show people what Active CSS can do.
Keep up the great work. I am going to keep reading, and hopefully I can make use of it very soon.