Dragula: Drag and drop so simple it hurts
github.com
github.com
Just yesterday I wrote a little bit of JavaScript that will let you reposition any element by dragging it: http://codepen.io/tomhodgins/pen/LGJKdE
And of course, I also minified it so it can be used from the address bar or as a bookmarklet. The minified version is at http://staticresource.com/dragon.js
Ive been having fun loading up sites I know, invoking the JS and then trying to rearrage the elements into better designs! For example, how would HN look if the reply buttons were aligned to the right edge of the textarea they are under, that would be an improvement :) We can try it out!
Thanks for sharing.
> Have I considered making it a chrome plugin?
No, but you can run it by pasting 'javascript:' in the URL bar, followed by the contents of http://staticresource.com/dragon.js or as a bookmarklet in Chrome, but the real intended browser I was hoping to use this on was Mobile Safari - to rearrange sites via touch on limited hardware. It also works flawlessly on a $50 Amazon Fire tablet too!
What I created it for was the ability to load up a site, rearrange it, screenshot it - and refresh to have it return to normal (either for more screenshots or to use it). One reason this won't do what you're thinking it will 'saving the location to where you have dragged it' is that it does unexpected things when you resize the browser. If your browser always remembered where you positioned things I think it would quickly end up broken :/
> Can you implement an undo?
I was thinking about this last night. It is possible (you could remember the previous values for the top and left, then set those values when a keyboard key is pressed) but again the big target for this script for my use will be browsers without keyboard (for an undo shortcut) so I'd also need to add an on-screen undo button. I'm still thinking about this and how to accomplish it.
Feel free to use the source as well, consider it under MIT license :)
Once I ran an X window manager on XCalc's client window. Each button got its own window frame, and you could move them around and iconify the ones you didn't need. Unfortunately the icons were bigger than the buttons.
If you want to cosmetically hide it without deleting it, you can click in the sidebar where there are all of the CSS styles there that apply to the element you have selected you can add (double click at the top of the sidebar and start a new rule)
display: none
What you would find, if I tried to add an 'X' button to every element on the page, is that often things are in multiple containers - and the most broken sites are usually the ones with the biggest HTML. It would be nearly impossible for you to 'X' out of elements visually top-down, the only way I can see you being able to get in and actually select which element to delete is using the tree-view in inspect element where you can navigate through the elements in the stack as though you're looking from the side and can touch just the layer you want.
It's striking how the pendulum has swung away from programmer-orientated environments like X11 or Emacs where writing your own policy/component/tool/script is encouraged and attributes of internal widgets etc. are accessible. May it swing back soon.
I could totally see a visual web editor that could work by dragging things around like this, with the css properties in a sidebar updating as you drag things around. And it could also work for "power users" by letting you edit the css directly, like you would in the browser Inspector.
I myself like to design in the browser to quickly see changes but sometimes Inspect element > Manually track and copy all changes to actual editor gets a little annoying.
Would love to use what I just described.
The nature of responsive CSS is that the simplest way to build a responsive website isn't to use a tool - but just to write the CSS by hand. I don't even use SASS or Less to compile CSS for me. At the end of the day, if the result you want is lines of CSS in a file, the simplest way to arrive at that result is to write only the lines of CSS you need.
If you're wanting to design responsive websites I'd say the easiest tool to use would be a text editor!
I just meant that moving things around and seeing the CSS change accordingly would be an educating "bonus" tool for beginners within what would be a fully fledged "live view" editor for people like you or me.
You can also use some expressions to match selectors in CSS, for example I use `.float-none`, `.float-left`, and `.float-right` as class names for my basic image floats. I can select all images with these classes applied with `img[class^="float-"]` and I can catch individual classes with `.float-left` or something like `img[class*="-right"]`. I think people would sooner learn and use tools that promise to make CSS easy, instead of advancing their CSS skills.
Check out http://elementqueries.com for some of the crazy fun stuff you can do with CSS by extending the language with a little JS. I'd sooner write styles like this that let you reduce the amount of HTML and CSS you have to write than to start introducing extra steps and tools between my files and the browser that multiply the amount of HTML and CSS being output before I can see the result.
I do also author and publish my own CSS stylesheets and plugins that can be used in other sites, so pretty quickly I can bring good CSS into any codebase to fix most common problems.
- http://elementqueries.com/demos/pricing-chart.html
- http://elementqueries.com/demos/content-blocks.html
The biggest use case I see for this is making super fast screenshots of variations of pages to illustrate an idea for an improvement to developers, other designers, or stakeholders.
What I'm not sure how to do is block other things on the page specifically also set to happen on the same events.
On a desktop web browser playing around with this I've had success hammering on the Esc key while moving links though. If you press Esc right after releasing most links it won't leave the page :)
I figure effectively disabling everything you drag doesn't really matter as dragging stuff around kinda FUBARs the page anyway.
(In this very comments page, people are talking about their own code they wrote with links to it, etc.)
Yes, but there are rules, and we all should play by the same rules. HNs rules state that if your story got significant attention recently (this story was 1st six months ago) it'll be killed as dupe. But the user has been sending it w/o stop even after that...
>Are reposts ok?
If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok.
I did not include the one submission with >300 because 200 days is not "recently" imho.
Which is fine, but a side effect is people resubmit often hoping one submission will catch.
This may be entirely made up, but I remember hearing that the duplication detection doesn't apply if a submission doesn't get a certain amount of attention. Looks like the only submission to get more than 3 points was 297 days ago.
Haha, my bad! I actually did try to search around for it, but it didn't occur to me to check the FAQ. I even checked the github mirror of the code [0] (no idea how up-to-date it is), but I can't read Arc very well. It just goes to show you could probably plaster rules like that as a header over the entire website and people like myself would still look in the wrong place :P
I have read the FAQ before, so that's probably where I "heard it", but I didn't think to check it this time.
That's very true. I even alluded to that in my comment but took it out as off-topic. It isn't you, though, it's everybody. Disseminating knowledge to the community is hard.
To put it another way, I suspect that submitting the same thing about once a month or so, is line noise when it comes to spamming Hacker News. And if the content were bad it probably would have been flagged to death at least once. It hasn't been, because it's good but unnoticed.
It could be it went rather unnoticed because each submission wasn't tweeted to a bunch of friends for upvotes, it never was submitted to product hunt, and the author doesn't search engine optimize on Medium.
And anyway, as this comment by me illustrates, meta discussion is often dull. Hence, generally discouraged by Hacker News Guidelines.
More importantly, though, this submission has received significant attention on HN within the last year: https://news.ycombinator.com/item?id=9914045. That makes this post unequivocally a dupe.
It's obviously a good project and there are many people in the thread learning about it for the first time and finding it interesting, which is great. But 300 points 7 months ago is so obviously within the dupe window that I think justice has to trump mercy in this case, though our bias runs the other way.
The underlying problem is that so much good stuff streams through HN that nobody can see more than a fraction of it.
Looks very very nice after a short play with the demo!
Serious question: With nearly 20 years in JS development, the concept of placing scripts not in the head section as being desirable is new to me. (Just saying, it used to be the other way round. Common resources, like scripts were, aside from the title, the main reason, the head tag was introduced at all.) -- Is there a source to this notion of script embedding, or can anyone clarify? (What would be the winning propositions of not using parallel loading slots?)
(Edit: So this may be true for scripts that are requiring further resources, but there's no need for this with scripts that are completely self-contained, like dragula claims to be. Here, this might rather slow down the completion of the page.)
It has more to do w/ the DOM rendering. The rendering engine is required to wait for a javascript resource to download because it can't know in advance that the js file won't call `document.write`
`document.write` has a nasty property that it calls `document.open()` if the document is not open for writing (which clears the document). Before the DOMContentReady event, the document is open for writing (this is why, among other things, console.log(document.body) yields null and `document.write("<title>foo</title>") sets document.title` when called from <head>)
If parsing of the document was allowed to skip a js file until it downloaded, and if the script has a `document.write` call, then running the script upon download completion (which would typically happen much later than DOMContentReady fired) would trigger the implicit document.open() call, thus yielding different (and catastrophic) semantics.
As for the rendering engine having to wait for the resource as it hits it, this is exactly why you want it to be ready then, as opposed to just starting to download it and wait. (Even, if it is the very last tag, it will defer completion. And if every library were claiming to be the last one ...)
> If parsing of the document was allowed to skip a js file until it downloaded (…) – This is, what the "defer" and the "async" attributes are for. (And, again, you don't want to call document.open(), be it explicitly or implied, because you would lose any content there is, since it implies "document.clear()". This is Netscape Navigator 2.0 stuff, 1996, really.)
P.S.: What you're heading for, were mere work-arounds in times, when the document-object would have been created only as the parser hit the <body>–tag (up to and including Netscape 3) and when enumerated properties became available only after the body was opened (Netscape 4, etc). But even then, you would apologize in a comment, if such means were required. (E.g., while addressing Netscape 4's document.layers object in 1997.) Now, that there are so many means to do this appropriately, I see no reason at all of banning common resources from the head section and spreading them over the document.body.
As far as usage in the wild goes, I've seen document-stream-related functions in rich text editors and comet (old school "websocket polyfills") codebases, but that was many years ago. I can't say for certain why browsers still support those functions.
<script async src="script.js"></script>Not really. All it does is `var body = document.body` in an IIFE. In <head>, that yields undefined.
I was going to download it and found:
If you're not using either package manager, you can use dragula by downloading the files in the dist folder. We strongly suggest using npm, though.
Why would they strongly suggest installing npm? (obviously I don't use node)
And why a package manager? For many reasons, the most useful ones are :
- ease of install
- you can declare dependencies for your plugin instead of having the end user go to X differents pages to download everything needed
- the most important one : you don't have to check all your packages for important updates like security ones
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
The "drag-and-drop" metaphor tires to cover up the Unix file system, but so little of Unix is designed for the desktop metaphor that it's just one kludge on top of another with little holes and sharp edges popping up everywhere. Maybe the "sag-and-drop" metaphor is more appropriate for such ineffective and unreliable performance.
A shining example is Sun's Open Windows File Manager, which goes out of its way to display ore dump files as cute little red bomb icons. When you double-click on the bomb, it runs a text editor on the core dump. Harmless, but not very useful. But if you intuitively drag and drop the bomb on the DBX Debugger Tool, it does exactly what you'd expect if you were a terrorist: it ties the entire system up, as the core dump (including a huge unmapped gap of zeros) is pumped through the server and into the debugger text window, which inflates to the maximum capacity of swap space, then violently explodes, dumping an even bigger core file in place of your original one, filling up the entire file system, overwhelming the file server, and taking out the File Manager with shrapnel. (This bug has since been fixed.)
But that's not all: the File Manager puts even more power at your fingertips if you run it as root! When you drag and drop a directory onto itself, it beeps and prints "rename: invalid argument" at the bottom of the window, then instantly deletes the entire directory trwe without bothering to update the graphical directory browser.
(Yes, you could try to use an optimization algorithm to do this- at the time I had no access to the map information needed for it. Actually it would have been difficult to beat the shipper's knowledge anyway.)
Were I to make this app again, I would want drag and drop in a web application. I'm not sure if Dragula allows dragging between frames (and dragging frames themselves).
I still need to clean up my modifications, but I should have a pull-request out within the next day or two, adding 'grid' to the existing 'horizontal' and 'vertical' direction options :)
Any reason why jQuery isn't on this list?
https://news.ycombinator.com/item?id=9914045
I thought this was considered spammy behaviour: https://hn.algolia.com/?query=dragula&sort=byPopularity&pref...
I'm not saying that the lib isn't great.
>Are reposts ok?
If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok.
https://news.ycombinator.com/newsfaq.html
I've seen this story at least 3 times in the last months both on new & 1st place in the front page sections:
https://hn.algolia.com/?query=dragula&sort=byPopularity&pref...