So geht’s: Drag & Drop mit HTML5
Die Slides von CSS-Ninja führen in das Thema Drag and Drop unter HTML5 ein.
Mit JavaScript-Bibliotheken wie jQuery ist es zwar möglich, Drag and Drop innerhalb eines Browsers zu realisieren, will man aber den Desktop einbeziehen oder mit verschiedenen Browsern arbeiten, kommt man an HTML5 nicht vorbei. Die dafür vorgesehene Drag-and-Drop-API wurde ursprünglich von Microsoft bereits 1999 mit dem IE5 auf den Markt gebracht, später von Safari und Mozilla übernommen (Chrome unterstützt sie ebenfalls) und fand deshalb Eingang in den HTML5-Standard. Eine saubere Cross-Browser-Verwendung macht aber, wie sollte es anders sein, ein wenig Mühe.
Tücken, Fallen und Implementierungsschwächen
Alle Image- und Anker-Elemente sind per Default „draggable“, also für Drag-and-Drop verwendbar, anderen Elementen muss man das HTML-Attribut draggable mitgeben, damit es klappt, so die HTML5-Specs. Webkit hält sich nicht an den Standard, hier muss der Draggable-Status über CSS gesetzt werden (was viele Experten für eine eher merkwürdige Idee halten), und im IE muss man, da er das draggable-Attribut nicht kennt, mit einem Trick nachhelfen und ein <div>-Element, das draggable sein soll, zu einem <a>-Element umbauen. Man sieht mal wieder: Die schöne neue Cross-Browser-Welt war noch nie einfach und schmerzfrei. Das HTML-Attribut dropzone für die Zielzone des Vorgangs, in die „gedropt“ werden soll, wird gar von noch überhaupt keinem Browser unterstützt, stattdessen muss man sich auch hier mit JavaScript behelfen.
HTML5 heißt: JavaScript
Verschiedene DOM-Events stehen nun zur Verfügung, um mit dem Drag-and-Drop-Vorgang umzugehen, zum Beispiel dragstart („Jetzt geht’s lohos“), drag („Es passiert!“) und dragged („Das war’s, wir sind fertig“). Über setData lassen sich per Drag-and-Drop auch Daten übertragen, denen man einen MIME-Type mitgeben kann. Diese Daten lassen sich dann auf der anderen Seite der Operation mit getData wieder auslesen.
Auf diese Weise Dateien und Daten zwischen Browserfenstern oder sogar auf den Desktop hin und her zu schieben, eröffnet Möglichkeiten, die Browser-Apps wieder ein Stück näher an native Applikationen heranrücken. Die detaillierte technische Abwicklung (sprich, der JavaScript-Code) ist freilich etwas anspruchsvoller, und die 15 Slides von The CSS Ninja bieten nur einen Einstieg. Alles in allem ist die HTML5-Drag-and-Drop-API kein Anfängerthema, hat man aber Lust, sich mit JavaScript und HTML5 näher zu beschäftigen, ist sie sicher eine lohnenswerte Spielwiese. Und wenn es mal nicht klappt, kann man sich trösten: Selbst HTML5-Editor Ian Hickson nannte die API höchstselbst furchtbar (horrible). Man darf die Schuld für Fehlschläge im Zweifel also ruhig beim „Hersteller“ suchen.
Habt Ihr Erfahrung mit der Drag-and-Drop-API? Haltet Ihr sie für bereits sinnvoll benutzbar?
Weiterführende Links:
- jQuery Mobile in Zusammenarbeit mit HTML5: Local Storage – t3n News
- CSS3: Neue Möglichkeiten mit Hintergrundgrafiken – t3n News
- Tutorial: Websites auf HTML5 umstellen – so geht’s – t3n News
IE5 ist aber schon so lange her, das Standard-„Fehler“ eher keine Fehler sondern frühe Erst-Versuche aus Monopol-Zeiten sind an denen leider anscheinend nichts verbessert wurde.
SVG-2 beispielsweise hat vieles was man sich nach ein paar Stunden mit SVG-1 selber gewünscht hätte und gleich in SVG-1 reingehört hätte. „Tolles“ W3C. Sowas ist ein Design-Fehler. Und da gibts noch einiges weiteres.
http://www.plupload.com/ … warum das Rad neu erfinden?
Die Artikel sind mir persönlich ein wenig zu oberflächlich- aber das ist ja bekannterweise Geschmacksache.
Viel schlimmer finde ich, dass unsere lieben Browserhersteller es immer noch nicht geschafft haben die grundlegendsten Standards von HTML5 und CSS3 richtig und gleich zu interpretieren. Ich wünsche mir einen Browser-TÜV, der die Veröffentlichung von Browsern verbieten kann, wenn Regeln des W3C falsch umgesetzt werden. Fehlende Funktionen sind da ja nicht das größte Problem.
@inovator…dieser nickname und diese einstellung…selten etwas gesehen, was sich so sehr widerspricht ^^
wenn man sich die geschichte der browser ansieht kommt man zwangsläufig zu der schlussfolgerung, dass ein großteil der features die wir heute in einem browser erwarten von den jeweiligen herstellern der browser kommt nicht vom W3C.
hätten sich die lieben browser hersteller sich an die standards gehalten, wären wir heute noch auf dem niveau von vor 10 jahren.
eigentlich müsste das W3C weg, schließlich ist die planwirtschaft nachweislich fehlgeschlagen :). die hersteller sollen machen, was ihnen gefällt, bzw. was sie für sinnvoll erachten und der anwender entscheidet dann.
zugegeben, eine ketzerische ansicht, aber so denke ich, wäre das am besten…..und ja, ich bin webprogrammierer!