Vorgehensweise progressive enhancement?
0 0 0 0 0 0 0 0 0 0 0
0 
Matthias Apsel
3 
molily
Vorgehensweise progressive enhancement?
Gunnar BittersmannHallo,
wie geht man das prinzipiell an?
Mal ein Beispiel: Eine Upload-Seite.
Standardfall:
<input name="Datei" type="file>
Wenn es aber möglich ist und der Browser JS aktiviert hat, dann soll eine Lösung mit Drag and Drop (z.b. html5doctor) zum Einsatz kommen. Das versteht man doch unter progressive enhancement, oder?
In dem Fall wäre <input name="Datei" type="file> durch eine entsprechende "Droparea" (mit JavScript) zu ersetzen. Die Frage: Wann und wie? Ist das Inputfeld erstmal gerendert wäre das ja eine unschöne Sache. Also auf "Dom ready" warten ist zu spät. Aber ein Element zuersetzen, dass noch nicht im DOM-Baum ist, ist auch unschön. Und wird die "Droparea" schon als html-Element ausgeliefert oder im JS generiert?
Viele Grüße
Siri
-
Hi,
und der <noscript> Tag geht nicht?
Sollte genau das sein, was Du suchst.Grüße
- Steffen
PS
Ich würde auch deaktiviertes JavaScript, wenn nicht unbedingt erforderlich, keine Rücksicht nehmen.-
Hallo,
und der <noscript> Tag geht nicht?
Sollte genau das sein, was Du suchst.Nein, da natives Drag und Drop nicht von allen Browsern unterstützt wird nützt das nichts und das hat -glaub ich- auch mit progressive enhancement nichts zu tun.
PS
Ich würde auch deaktiviertes JavaScript, wenn nicht unbedingt erforderlich, keine Rücksicht nehmen.Ich auch nicht, aber darum gehts mir ja auch nicht ;-)
Viele Grüße
Siri-
Hi,
und der <noscript> Tag geht nicht?
Sollte genau das sein, was Du suchst.Nein, da natives Drag und Drop nicht von allen Browsern unterstützt wird nützt das nichts und das hat -glaub ich- auch mit progressive enhancement nichts zu tun.
dann würde ich es gleich on-the-fly machen.
text text text <div id=upload></div> <script> if (altes_upload) { document.getElementById('upload').innerHTML = " input type file ..."; } else { document.getElementById('upload').innerHTML = " drag and drop ..."; } </script>Zum Zeitpunkt des Scripts ist der DOM-Baum schon bis zum div#upload aufgebaut und kann manipuliert werden.
So sollten keine sichtbaren Effekte auftreten.Grüße
- Steffen
-
Hallo,
text text text
<div id=upload></div>
<script>
if (altes_upload) {
document.getElementById('upload').innerHTML = " input type file ...";
}
else {
document.getElementById('upload').innerHTML = " drag and drop ...";
}
</script>> > Zum Zeitpunkt des Scripts ist der DOM-Baum schon bis zum div#upload aufgebaut und kann manipuliert werden. Das wäre aber so die unelegante Variante, die überall hart codiert werden muss... Da muss es doch auch etwas unobtrusives geben, dass man in ein Framework packen kann. Viele Grüße Siri-
Hi,
text text text
<div id=upload></div>
<script>
if (altes_upload) {
document.getElementById('upload').innerHTML = " input type file ...";
}
else {
document.getElementById('upload').innerHTML = " drag and drop ...";
}
</script>> > > > Zum Zeitpunkt des Scripts ist der DOM-Baum schon bis zum div#upload aufgebaut und kann manipuliert werden. > > Das wäre aber so die unelegante Variante, die überall hart codiert werden muss... Da muss es doch auch etwas unobtrusives geben, dass man in ein Framework packen kann. Das sollte ja auch nur Beispielcode sein. Ja nachdem, was Du zur Verfügung hast, kannst Du es in eine client- oder serverseitige Library packen. z.B. ~~~html text text text <div id=upload></div> <script>doIt("upload");</script>Eventuell kannst Du sogar das
<div id=upload></div>sparen.Alles weitere liegt in Deiner Hand.
Grüße
- Steffen
-
Hallo,
vielleicht habe ich meine Frage nicht klar gestellt: Mich interessiert das Prinzip beim progressive enhancement. Wann, was, an welcher Stelle? Unobtrusive.
Da muss es doch Lösungen und Anätze geben und zwar clientseitig.Viele Grüße
Siri-
Hallo Siri!
vielleicht habe ich meine Frage nicht klar gestellt: Mich interessiert das Prinzip beim progressive enhancement. Wann, was, an welcher Stelle? Unobtrusive.
Lese-Tipp: http://www.w3.org/wiki/Graceful_degredation_versus_progressive_enhancement
Gruß Gunther
-
Hi,
vielleicht habe ich meine Frage nicht klar gestellt: Mich interessiert das Prinzip beim progressive enhancement. Wann, was, an welcher Stelle? Unobtrusive.
Da muss es doch Lösungen und Anätze geben und zwar clientseitig.Ansätze ja, aber Lösungen müssen für jeden einzelnen Fall entwickelt werden.
Siehe GuntherEventuell bietet ja die Library(?), die Du einsetzt eine solche Lösung mit an.
Wenn Du keine Library einsetzt, dann bau Dir ein.Grüße
- Steffen
-
Hallo,
Ansätze ja, aber Lösungen müssen für jeden einzelnen Fall entwickelt werden.
Siehe GuntherDen "einzelnen Fall" gibt es in meinem Ausgangsposting.
Wenn Du keine Library einsetzt, dann bau Dir ein.
Das war genau meine Ansinnen:
Da muss es doch auch etwas unobtrusives geben, dass man in ein Framework packen kann.
Und genau dieses Prinzip will ich verstehen. JS-Code im HTML kann nicht die Lösung sein.
Viele Grüße
Siri-
Hi,
Wenn Du keine Library einsetzt, dann bau Dir ein.
Das war genau meine Ansinnen:
Da muss es doch auch etwas unobtrusives geben, dass man in ein Framework packen kann.
Und genau dieses Prinzip will ich verstehen. JS-Code im HTML kann nicht die Lösung sein.Warum nicht? Dafür ist es ja da. Spricht etwas dagegen?
Zumindest kenn ich ansonsten für Dein Problem keine Lösung. Wenn Du auf onload (o.ä.) warten willst, dann wirst Du immer einen sichtbaren Effekt haben.
Grüße
- Steffen
PS
Argumente wie JavaScript nur im HEAD sind eher aus dem letzten Jahrtausend.PPS
Noch nie probiert - ohne einen DIV#upload:text text text <script> (function () { var mydiv = document.createElement("div"); mydiv.innerHTML = "..."; // oder was auch immer var myscripts = document.getElementsByTagName("script"); var myscript = myscripts[myscripts.length - 1]; myscript.parentNode.insertBefore(mydiv, myscript); })(); </script>-
Hallo,
Da muss es doch auch etwas unobtrusives geben, dass man in ein Framework packen kann.
Und genau dieses Prinzip will ich verstehen. JS-Code im HTML kann nicht die Lösung sein.Warum nicht? Dafür ist es ja da. Spricht etwas dagegen?
Argumente wie JavaScript nur im HEAD sind eher aus dem letzten Jahrtausend.
Du solltest dich vielleicht erstmal auf Stand bringen, z.B. bei molily.
Viele Grüße
Siri-
Hi,
Da muss es doch auch etwas unobtrusives geben, dass man in ein Framework packen kann.
Und genau dieses Prinzip will ich verstehen. JS-Code im HTML kann nicht die Lösung sein.Warum nicht? Dafür ist es ja da. Spricht etwas dagegen?
Argumente wie JavaScript nur im HEAD sind eher aus dem letzten Jahrtausend.
Du solltest dich vielleicht erstmal auf Stand bringen, z.B. bei molily.
In Bezug auf was?
Das es Dir anscheinend mehr um die Theorie geht habe ich mit meinen Beispielen vielleicht eher daneben gelegen.
Schönen Tag noch
- Steffen
-
Hallo,
Da muss es doch auch etwas unobtrusives geben, dass man in ein Framework packen kann.
Und genau dieses Prinzip will ich verstehen. JS-Code im HTML kann nicht die Lösung sein.Warum nicht? Dafür ist es ja da. Spricht etwas dagegen?
Argumente wie JavaScript nur im HEAD sind eher aus dem letzten Jahrtausend.
Du solltest dich vielleicht erstmal auf Stand bringen, z.B. bei molily.
In Bezug auf was?
Im Bezug auf die zitierten Aussagen natürlich. Ich weiß jetzt nicht, ob du die verlinkte Seite gelesen hast, da steht ziemlich deutlich, welche Schichten man voneinander getrennt halten sollte und warum und auch wo man JS am besten verlinkt (i.d.R am Ende des Markups vor dem schließenden Body). Wenn man viele Seiten zu produzieren hat, dann will man doch den JS-Code auslagern und nicht in jede HTML-Datei reinschreiben. Man vergibt Klassen anhand derer das Script erkennen kan was zu tun ist.
Viele Grüße
Siri
-
-
Hallo!
Also im Prinzip hast du zwei Fragen:
Die erste ist die nach dem Unterschied zwischen 'graceful degredation' und 'progressive enhancement'
Diese sollte eigentlich u.a. durch den verlinkten Artikel geklärt sein.Die zweite Frage ist, wie du 'progressive enhancement' realisieren kannst.
Da muss es doch auch etwas unobtrusives geben, dass man in ein Framework packen kann.
Und genau dieses Prinzip will ich verstehen. JS-Code im HTML kann nicht die Lösung sein.In aller Regel wird 'progressive enhancement' mit einer Manipulation des DOMs einhergehen.
Dazu sei an dieser Stelle auf Mathias (molily) sehr interessanten Artikel verwiesen: http://molily.de/js/event-handling-onload.html.Normalerweise ist 'progressive enhancement' ja auch immer auf einen bestimmten und speziellen Fall bezogen. Du kannst natürlich auch alle denkbaren Fälle in einem Framework vereinen und "bei Bedarf" die jeweiligen Funktionen aufrufen/ ausführen.
Ansonsten verstehe ich deine Aussage:"Da muss es doch auch etwas unobtrusives geben, dass man in ein Framework packen kann. JS-Code im HTML kann nicht die Lösung sein." nicht!?
Gruß Gunther
-
@@Gunther:
nuqneH
Die erste ist die nach dem Unterschied zwischen 'graceful degredation' und 'progressive enhancement'
Diese sollte eigentlich u.a. durch den verlinkten Artikel geklärt sein.Oder ganz einfach mit diesem Vergleich. Und diesem Zitat.
Qapla'
--
„Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer) -
Hallo,
Die erste ist die nach dem Unterschied zwischen 'graceful degredation' und 'progressive enhancement'
Diese sollte eigentlich u.a. durch den verlinkten Artikel geklärt sein.Ja, da sind die Prinzipien auch gut erklärt.
In aller Regel wird 'progressive enhancement' mit einer Manipulation des DOMs einhergehen.
Dazu sei an dieser Stelle auf Mathias (molily) sehr interessanten Artikel verwiesen: http://molily.de/js/event-handling-onload.html.Normalerweise ist 'progressive enhancement' ja auch immer auf einen bestimmten und speziellen Fall bezogen. Du kannst natürlich auch alle denkbaren Fälle in einem Framework vereinen und "bei Bedarf" die jeweiligen Funktionen aufrufen/ ausführen.
Nimm mal mein Eingangsbeispiel oder stell dir vor, man entscheidet sich dafür, bei einer bestimmten Oberfläche ganz andere Controls zu verwenden (UA-Sniffing sei mal ausgeschlossen). Jetzt wäre ein theoretischer Ansatz:
body.visibilty: hidden;
Das DOM wird mainpuliert, wenn alles abgeschlossen ist, dann halt:
body.visibilty: visible;
-> Nichts flackert auf.
Jetzt kann man dabei auch schon alle Controls ausliefern und ihre Sichtbarkeit ändern oder die Elemente mit JS nach bedarf erzeugen.Vielleicht gibt's aber noch was schlaueres? Obiger Ansatz hat ja auf Anhieb erkennbare Schwächen.
Viele Grüße
Siri-
Hallo!
Vielleicht gibt's aber noch was schlaueres? Obiger Ansatz hat ja auf Anhieb erkennbare Schwächen.
Mathias hat doch in seinem Beitrag hier schon alles dazu gesagt. ;-)
Man kann sich halt nur innerhalb der jeweiligen Möglichkeiten bewegen. Dass das nicht immer "der Idealfall" ist, mag einen zwar wurmen, ändert aber nichts an der Tatsache.
Gruß Gunther
-
Hallo,
Man kann sich halt nur innerhalb der jeweiligen Möglichkeiten bewegen. Dass das nicht immer "der Idealfall" ist, mag einen zwar wurmen, ändert aber nichts an der Tatsache.
Aber man kann ja mal fragen! Vielleicht habe ich ja auch nicht alle Möglichkeiten gesehen.
Ob einem immer "alles" erzählt wird ist eine andere Geschichte. Es gibt ja sicher auch know-how, dass man für sich behält.Viele Grüße
Siri-
Hallo!
Aber man kann ja mal fragen!
Natürlich - immer! ;-)
Wie heißt es ja so schön:"Wer nicht fragt bleibt dumm!"Vielleicht habe ich ja auch nicht alle Möglichkeiten gesehen.
Ob einem immer "alles" erzählt wird ist eine andere Geschichte.Davon würde ich aber eigentlich ausgehen.
Es gibt ja sicher auch know-how, dass man für sich behält.
Speziell in dem "Bereich" wohl eher nicht ...
Aber eine der Schwierigkeiten, die hier auch immer wieder auftaucht ist, dass es halt häufig mehrere Optionen gibt. Und die Entscheidung, welche jeweils die "Beste" ist, vom jeweiligen (individuellen) Einzelfall abhängig ist.
Und die möchtest ja ein "universell" einsetzbares Framework bauen. Also kannst du auch nur auf "universell" verwendbare Optionen setzen.
Womit du auch gleich an die "Grenzen" von Frameworks stößt. Denn ich sage ja immer:"Ein Framework ist immer dann eine echte Hilfe, solange man mit dem gesteckten Rahmen zurecht kommt."
Gruß Gunther
-
-
-
Hi,
Nimm mal mein Eingangsbeispiel oder stell dir vor, man entscheidet sich dafür, bei einer bestimmten Oberfläche ganz andere Controls zu verwenden (UA-Sniffing sei mal ausgeschlossen). Jetzt wäre ein theoretischer Ansatz:
body.visibilty: hidden;
Das DOM wird mainpuliert, wenn alles abgeschlossen ist, dann halt:
body.visibilty: visible;
-> Nichts flackert auf.
Jetzt kann man dabei auch schon alle Controls ausliefern und ihre Sichtbarkeit ändern oder die Elemente mit JS nach bedarf erzeugen.Vielleicht gibt's aber noch was schlaueres? Obiger Ansatz hat ja auf Anhieb erkennbare Schwächen.
Yep. Hat er.
Mit inline-JavaScript[*] und on-the-fly und alternativen Elementen würde es gehen.
Wenn nichts flackern soll, muss man die Elemente halt in ihrer endgültigen Form zur Anzeige bringen und darf einen bereits sichtbaren Dom-Baum nicht mehr manipulieren.
Ich habe noch keinen anderen Weg kennengelernt.
Grüße
- Steffen
[*] Soll jetzt nicht heißen, dass hier mehr als ein Funktionsaufruf stehen muss.
-
-
-
-
-
-
-
Om nah hoo pez nyeetz, Steffen!
und der <noscript> Tag geht nicht?
Sollte genau das sein, was Du suchst.Verwechsle nicht Tag und Element.
Matthias
-
Om nah hoo pez nyeetz, Steffen!
und der <noscript> Tag geht nicht?
Sollte genau das sein, was Du suchst.Danke :-)
Aber dazu fällt mir folgendes ein:
Die Leute evakuieren ...
vs.
Das Gebäude evakuieren ...Grüße
- Steffen
-
-
Hallo,
Wenn es aber möglich ist und der Browser JS aktiviert hat, dann soll eine Lösung mit Drag and Drop (z.b. html5doctor) zum Einsatz kommen. Das versteht man doch unter progressive enhancement, oder?
Das Beispiel ist etwas schlecht gewählt.
Ein <input type="file"> ist robust und du solltest es immer anbieten. Drag and Drop von Files ist eine weitere Möglichkeit, Dateien dem Script zur Verfügung zu stellen. Sie funktioniert auf vielen Geräten nicht so einfach wie <input type="file">. Bestenfalls solltest du beides anbieten. DnD muss natürlich mit JavaScript umgesetzt werden. Falls der Browser DnD unterstützt, erzeugt das JavaScript die Dropzone. Andernfalls tut es nichts und vertraut auf <input type="file"> als Fallback. Das ist Progressive Enhancement. Natürlich könnte dieses Script das input-Feld verstecken, aber ich sehe dazu keinen Grund.
Ist das Inputfeld erstmal gerendert wäre das ja eine unschöne Sache. Also auf "Dom ready" warten ist zu spät. Aber ein Element zuersetzen, dass noch nicht im DOM-Baum ist, ist auch unschön.
Ganz allgemein gesprochen:
Scripte sollten asynchron geladen werden, also ja, man wartet auf “document ready”. Klar, dabei kann es zum Aufblitzen von Bedienelementen kommen, die später durchs Script ersetzt werden. Wenn das Script erst Feature-Abfragen vornehmen muss, geht es nicht anders.
Falls die Verfügbarkeit von JavaScript ausreicht, so kann man die zu ersetzenden Elemente vor dem Parsen der Seite ausblenden. Dazu fügt man im head ein kleines nicht-blockendes Script ein, das dem html-Element eine Klasse verpasst:
<html>
<head>
<link rel="stylesheet" href="main.css">
<script>
document.documentElement.className += ' js';
</script>Mithilfe dieser »js«-Klasse blendet man im CSS alle Elemente aus, die durch JavaScript-Logik ersetzt werden:
.js .bereich-der-durch-js-logik-ersetzt-wird { display: none; }Das kann man natürlich auch tun, wenn Feature-Abfragen nötig sind. Dann muss das Script die ausgeblendeten Elemente wiederherstellen – das führt auch zu einem »Aufblitzen«, aber immerhin sieht der Nutzer nicht zwei verschiedene Elemente.
Und wird die "Droparea" schon als html-Element ausgeliefert oder im JS generiert?
In der Regel sollte ein Element, das nur im Kontext eines Scripts sinnvoll ist, von diesem Script erzeugt werden.
Aus Performance-Gründen kann man Elemente, die von Scripten verwendet werden, natürlich schon direkt im HTML-Dokument ausliefern. Die sollten aber versteckt sein.
Mathias
-
Hallo,
vielen Dank für deine -wie immer- fundierte Aussage!
Da waren jetzt richtig wertvolle Tipps und Anregungen dabei!
Viele Grüße
Siri
-
