Hinweis: Am 9. April beteiligen wir uns auf webkrauts.de am Naked CSS Day. Die Stylesheets sind an diesem Tag absichtlich abgeschaltet.

Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Denn Sie tun es – CSS und JavaScript

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Denn Sie tun es – CSS und JavaScript

In den letzten zwei Jahren gab es mehr und mehr Beispiele im Netz die vorgaben, ehemalige JavaScript-Effekte wie dynamisch aufklappbare Menüs rein mit CSS erreichen zu können. Der Grund war, daß es scheinbar geht und daß JavaScript ja sowieso schwarze Magie sei, die jeden Webdesigner überfordert.

CSS allein kann nicht soo viel…

Diese CSS only”-Lösungen sind ganz tolle technische Beispiele, aber im echten Anwendungsbereich auch großer Unfug. Ich habe mich lang und breit darüber in einem englischen Artikel ausgelassen, doch hier sind die Hauptgründe:

  • CSS hat nur eine Möglichkeit um dynamische Effekte zu erstellen: Pseudoselektoren wie :focus und :hover. Microsoft Internet Explorer versteht diese nur für Links und Textfelder.
  • CSS hat nur eine begrenzte Möglichkeit zusätzliches HTML und Inhalte zu erstellen, wenn sie nötig sind, und ein dynamisches Menü sollte weder JavaScript noch CSS zwangsweise erfordern.
  • CSS kann nur binär ein- oder ausschalten, in JavaScript kann man Effekte zeitlich verzögern, um es dem Besucher zu erlauben, auch mal mit der Maus auszurutschen.
  • Es gibt keine Möglichkeit zu testen ob CSS eingeschaltet ist, was bedeuten kann, daß man den Besucher mit viel zu vielen Links verwirrt.

JavaScript kann viel mehr…

JavaScript dahingegen kann einiges mehr was CSS nicht kann:

  • Mittels des DOM und BOM kann man das Dokument nach Belieben verändern und erweitern.
  • Mittels timeout() kann man Besuchern erlauben Fehler zu machen.
  • Mittels Event Handling kann man auf alles, was im Dokument passiert, reagieren – egal ob das per Maus oder Tastatur geschieht.
  • Ich kann in JavaScript jederzeit überprüfen ob das, was ich erreichen will, auch von dem Anzeigeprogramm unterstützt wird. Wenn das der Fall ist, kann es losgehen, ansonsten nicht (der klassische Fall von “Tiefe des Wassers prüfen bevor man reinspringt”)
  • Ich kann Daten, die nur mit CSS und JavaScript Sinn machen, per Ajax laden, nachdem die eigentliche Seite geladen ist.

Gemeinsam sind sie stark!

Diese Pro-JavaScript-Punkte bedeuten allerdings nicht, daß man nur JavaScript verwenden sollte, sondern wann immer möglich den CSS-Parser seine Arbeit erledigen lassen.

Hier ein paar Beispiele wie JavaScript und CSS zusammen arbeiten können:

Ist CSS eingeschaltet?

Einer der Hauptpunkte, den selbsternannte Barrierefreiheit-Sheriffs immer gerne anbringen, ist, daß Produkte nicht funktionieren, wenn JavaScript eingeschaltet, aber das passende CSS nicht erreichbar oder durch ein User Style Sheet überschrieben wurde.

In JavaScript ist es allerdings mit einem kleinen Trick ganz einfach möglich zu überprüfen, ob ein Style Sheet geladen wurde. Der Trick ist, die Höhe oder Breite eines Elementes (was extra dafür angefügt werden kann oder eines, das sowieso auf der Seite ist) zu definieren:

#ichkannCSS{height:20px;}

Dann überprüft man in JavaScript, ob die offsetHeight beziehungsweise offsetWidth des Elementes den gleichen Wert hat:

var CSStestDingen = document.getElementById(‘ichkannCSS’);
if(CSStestDingen !== undefined){
  if(CSStestDingen.offsetHeight === 20){
     // hier wird CSS gekonnt!
  } else {
    // der kann fei kei CSS ned.
  }
}
Unterschiedliches Styling für JavaScript- und nicht-JavaScript-Versionen

Oft ist es nötig, daß die Seite mit und ohne JavaScript unterschiedlich daherkommt – gerade wenn man beispielsweise eine Liste in ein Menü verwandelt. Die einfachste Möglichkeit ist es, in JavaScript, nachdem die Seite geladen wurde, eine CSS Klasse an das BODY-Element anzufügen und es damit dem CSS-Designer zu erlauben, zwei verschiedene Styles zu erstellen.

window.onload = function(){
  var klasse = document.body.className ? ‘ dynamisch’:’dynamisch’;
  document.body.className = klasse;
}

Natürlich gibt das die normalen Ladeprobleme und man sollte statt eines onloads eben addEvent verwenden. Mehr dazu gibt es bei “Barrierefreies JavaScript nachzulesen.

Schnelleres JavaScript als Gratiszugabe

Diese Technik hat auch noch einen anderen Vorteil: Man kann die schwere Arbeit, Teile der Seite zu verstecken, dem CSS-Parser überlassen, der dafür erstellt wurde. Wenn man ältere JavaScripte analysiert, findet man des öfteren solche Schoten:

var n = document.getElementById(‘nav’);
if(n!==undefined){
  var uls = n.getElementsByTagName(‘ul’);
  for(var i=0; i<uls.length;i++){
    uls[i].style.display = ‘none’;
  }
}

Schleifen sind hübsch im Haar, doch machen Sie JavaScript langsam, und wenn man Sie vermeiden kann, sollte man das tun.

Mit einer BODY-ID kann man diese Schleife durch eine Zeile im CSS ersetzen:

body.dynamisch #nav ul {display:none;}

Hausaufgabe

Als Hausaufgabe bitte ich darum, einige CSS only”-Lösungen mal mit der Tastatur oder einer wackligen Maus zu testen und generell darüber nachzudenken, wie praktisch doch gute JavaScript Lösungen sind, die es dem Designer erlauben, sie einfach im Style Sheet anzupassen und neu zu gestalten.

Kommentare

Manuel Bieh

Manuel Bieh (Webkraut)
am 23.12.2006 - 03:50

wordpress hat echt ne scheiß angewohnheit aus hochkommas single quotes zu machen. ich befürchte die codebeispiele werden alle nicht funktionieren sofern man sie denn 1:1 übernimmt. sollte man ändern.

Permanenter Link
Tomas Caspers

Tomas Caspers (Webkraut)
am 23.12.2006 - 08:09

Manuel, ja, das Problem ist bekannt und das ist beileibe nicht das einzige - wir alle haben hier beim Einbau der Artikel regelmäßig Brüllanfälle bekommen. Der Vorteil ist, dass wir jetzt eine lange Liste von Dingen haben, die sich zum Beginn des nächsten Jahres hier ändern werden...

Permanenter Link

Eugen Wirz
am 23.12.2006 - 09:12

Allerdings ist es viel angenehmer und schneller, dynamisches mit CSS zu versehen, da JS langsamer ist.
Wie es mit AJAX (wie es hier erwähnt worden ist) geht, weiß ich nicht.

Permanenter Link

alexander farkas
am 23.12.2006 - 13:15

@eugen
angenehmer für wen. in dem artikel geht es darum, dass man es dem user angenhemer macht.

ein suckerfish-dropdown-menue ist beispielsweise zwar sehr geil, um zu zeigen was man mit css machen kann, aber der user findet es nicht angenehm, wenn die unterkategorie sofort verschwindet. mit javascript kannst du da eine verzögerung einbauen. (mit css nicht)

bei ajax kommt noch ein http request hinzu, ist also im prinzip langsamer. aber ajax soll, sinnvoll eingesetzt, ja das laden einer ganzen seite verhindern, wenn sich eh nur ein kleiner ausschnitt ändert. ist also doch schneller....

Permanenter Link

Milian Wolff
am 23.12.2006 - 13:34

Da hat sich wohl ein Fehler eingeschlichen:
window.onload = function(){
var klasse = document.body.className ? ‘ dynamisch’:’dynamisch’;
document.body.className = klasse;
}

Das sollte wohl eher wie folgt heißen:
window.onload = function(){
var klasse = document.body.className;
klasse += klasse ? ' ' : '';
document.body.className = klasse + 'dynamisch'
}

Oder ähnlich ;)

Zum Artikel: Gefällt mir sehr gut. Die Frage ist auch, inwiefern es gerechtfertigt sein kann, viel Zeit für cross-browser Dropdown Menüs etc. aufzuwenden, wenn man mit JS recht einfach das ganze regeln kann (sodass es auch überall gut aussieht).

Permanenter Link

alexander farkas
am 23.12.2006 - 14:32

@milian

>Die Frage ist auch, inwiefern es gerechtfertigt sein kann, viel Zeit für cross-browser Dropdown Menüs etc. aufzuwenden, wenn man mit JS recht einfach das ganze regeln kann (sodass es auch überall gut aussieht).

mir gefällt der artikel auch sehr gut. aber cross-browser dropdown auf css basis, wie beispielsweise das suckerfish (ich weiss da hilft ein bißchen javascript nach), ist ja schon kurz und gut. wenn man dann javascript nimmt, sollte man dann meiner meinung nach ein bißchen mehr liefern, sprich doch etwas mehr scripten und dadurch die funktionalität deutlich anheben.

Permanenter Link

Willi Stöger
am 23.12.2006 - 15:09

Danke für den Artikel. Zur dynamischen Erweiterung der body-CSS-Klasse habe ich eine technische Frage (@ Milian Wolff bzw. Christian Heilmann): Was spricht gegen folgendes Konstrukt:

window.onload = function() {
document.body.className += ' dynamisch';
}

So wie ich das im Firefox 2.0.0.1 + Firebug 1.0b7 gesehen habe, wird eine vorhandene Klasse dadurch korrekt erweitert bzw. ' dynamisch' ohnehin auf class="dynamisch" getrimmt.

Möglicherweise sprechen aber andere Gründe gegen dieses einfache Konstrukt (das Ganze sozusagen am Rande und weil ich es schnell ausprobiert habe).

Beste Grüße aus Wien :-)

Permanenter Link

alexander farkas
am 23.12.2006 - 16:06

bei dem konstrukt von milian, wird darauf geachtet, dass das leerzeichen, welches du immer einfügst nur dann eingefügt wird, wenn das body bereits eine klasse hat.

ansonsten hättest du häufig class=" dynamisch" statt class="dynamisch" im body stehen.

Permanenter Link

alexander farkas
am 23.12.2006 - 16:08

@Willi Stöger

ist mir erst jetzt aufgefallen, dass du den unterschied bereits erkannt hast.

es wird den beiden wohl vor allem darum gehen. es sauber hinzuzufügen und sich nicht darauf zu verlassen dass, der browser es richtig macht.

Permanenter Link

Willi Stöger
am 23.12.2006 - 17:12

@alexander - alles klar, danke für die Antwort.

Permanenter Link

.carsten
am 23.12.2006 - 18:44

Barrierefreiheit ist sicherlih eine sinnvolle und gute Sache, die es beim Aufbau eienr Internetseite zu bedenken gilt. Aber der Artikel zeigt sehr schön auf, daß es an einem bestimmten Punkt nur noch ein Entweder-oder gibt. Dann muß man bedenken, daß über 90% der Nutzer immer noch Menschen sind, die einen ganz normalen Browser benutzen und auf Barrierefreiheit nicht unbedingt angewiesen sind. Die sinnvolle Mischung aus allem macht mal wieder das Rennen.

Permanenter Link

alexander farkas
am 23.12.2006 - 19:28

@carsten
würde das nicht so eng mit barrierefreiheit verbinden. zum einen passt das konzept von progressive enhancement durch javascript in eine barrierefreie seite sehr gut rein, zum anderen können ja moderne assitive technolgien sehr gut mit javascript zusammenarbeiten (web 2.0 und -barrierefreiheit).

in diesem sinne passen die artikel von chris und der oben genannte von tomas ganz gut zusammen.

Permanenter Link

listener
am 25.12.2006 - 19:31

Also ist warten auf das neue Menü ein Komfort-Vorteil?
http://developer.yahoo.com/yui/examples/menu/example13.html

Permanenter Link

alexander farkas
am 26.12.2006 - 22:00

Also ist warten auf das neue Menü ein Komfort-Vorteil?

ne, aber vielleicht, dass das Script auf dich wartet, mit der Tastatur bedienbar ist etc.

http://pfirsichmelba.de/artikel-scripts/dropdown/horizontal.html

Permanenter Link

Joachim Durchholz
am 03.01.2007 - 12:11

Auch wenn ich hier jetzt des Hauses verwiesen werde:
Ich mag JS nicht.

Es verschiebt das "Machtgleichgewicht" zugunsten des Webdesigners.
Und das hat in der Praxis vielerlei Konsequenzen.
Beispielsweise kann es Malware auf den Rechner des Besuchers installieren.
Oder es kann dem Besucher die Designphilosophie des Webdesigners aufzwingen.

Endeffekt: Die Leute fühlen sich unsicher. Wer kann und weiß, wie, schaltet es ab. Und nur für die Webseiten ein, denen er vertraut (und die JS sparsam einsetzen).

JS hat durchaus seinen Platz. Aber nur auf Seiten, wo die Leute immer wiederkehren und bereits ein Vertrauensverhältnis besteht.

Permanenter Link
Christian Heilmann

Christian Heilmann (Autor)
am 03.01.2007 - 12:27

Joachim: Ich mag keine Zwiebeln und doch wird jeder Koch dir sagen das sie noetig sind. Das "die leute" sich unsicher fuehlen liegt daran, das ueber Jahre hinweg JavaScript als Sicherheitsrisiko gepusht wurde obschon das eigentliche Problem der Browser oder das OS waren. Wenn Microsoft meint der Desktop sollte ActiveX ausfuehren dann ist es auch kein Wunder das boese Menschen das als moeglichen Angriffspunkt auswaehlen.

Bitte Bitte, hoert auf alles JavaScript ueber einen Kamm zu scheren. Wir haben als Entwickler ne Menge gelernt und JS kann dir helfen OHNE im Weg zu stehen oder was aufs Auge druecken zu wollen.
Kurs und Info dazu: http://ichwill.net/

Ich wuerde allerdings gerne mal ein Beispiel sehen wie ich mit einem JavaScript bei Dir Malware installieren kann. Im Endeffekt muss man eine Datei ausfuehren, und da liegt das Problem. Die Technologie ist egal, um ein System anzugreifen brauche ich einen User der nicht kapiert was fuer Konsequenzen sein Tun hat. Das ist der Web Surfer der auf tolle Smileyinstaller klickt oder die Sekretaerin die am Telefon darauf reinfaellt das man angibt vom IT Helpdesk zu sein und doch bitte mal ihr Login und Passwort braeuchte.

Die Designphilosophie von verblendeten Designern kann ich auch per CSS und HTML (Tabellen) dem End-User aufzwingen, das ist auch kein Argument.

Im Gegentum, die Einstellung das JavaScript ja boese ist und abgestellt werden muss weil man sonst an ganz boesen Viren stirbt oder 300 Scanner, Firewalls und Adaware Programme braucht fuehrt ja dazu das echte Angreifer und unsoziale Werber mit anderen Geschuetzen wie kleinen Java Applets oder Flash advertising ankommen.

Permanenter Link

Alexander Beutl
am 11.01.2007 - 12:45

Tja - das Thema JS ist umstritten.
Es nutzt aber nichts es im Webentwicklerkreis zu diskutieren. Denn entscheidend ist, was erlaubt der User!

Und die User sind teilweise noch verunsichert - teilweise stellen Sie JS ab, teilweise lassen sie es an. Inzwischen steigt der Anteil mit eingeschalteten JS wieder an - aber solange er das nicht noch ein wenig tut, werde ich mir kein spezielles Design für diejenigen , die JS an haben ausdenken.

Alles muss mit und ohne funktionieren, wieso sollte ich also etwas funktionierendes, was trotzdem Benutzerfreundlich ist (auch unter Accessablility-Gesichtspunkten) mit etwas erweitern, dass mir und dem Besucher keinen Mehrwert bringt?

Gut manche Sachen sehen mit JS besser aus - gut, dann bietet man eben mal beides an (Lightbox als Bild in Originalgröße z.B.), aber an JS-Menü-Spielereien werde ich mich vorerst nicht versuchen.

Ein Drop-Down Menü ist zwar hüpsch hat aber (egal mit welcher Technik) große Nachteile - Vorteil ist eigentlich nur, dass es Platz spart und Übersichtlicher ist, als alle Links gleichzeitig an zu zeigen.

Spätestens in Bezug auf Suchmaschienen versagt eine solche Menüführung aber garantiert - besonders wenn sie JS-gestützt ist.

Ob man mit der Tastatur durch ein solches Menü navigieren kann - naja, die Umsetzungen die ich dazu bisher gesehen haben stellen mir eine neue Frage: Will ich das überhaupt?
Will ich mich erst durch die gesamte Seitenstrucktur tabben, nur weil ich auf den - nicht DropDown - Punkt ganz unten (Impressum) will? NEIN! Will ich nicht!

Also von mir ganz klar: JS ist ein Zusatz für Sachen, bei denen etwas nettere Sachen möglich sind - es darf aber nicht für Spielereien an den wirklich wichtigen Punkten der Website dienen.

Ist CSS da "besser"? Nein und Ja... Wenn ich es brauche um Funktion her zu stellen, dann habe ich den Sinn eines "Style"-Sheets nicht verstanden. Wenn ich es zum reinen Stylen verwende, dann mache ich nichts falsch, gute Seitstruckturen lassen sich auch Plain betrachten und die gestylte Version sieht einfach nur besser aus.

Permanenter Link

/T
am 11.01.2007 - 13:43

»Tja - das Thema JS ist umstritten.«

Tja - was wäre denn alternativ ein Thema, zu dem es auf diesem Planeten keine unterschiedlichen Meinungen gibt?

»Und die User sind teilweise noch verunsichert - teilweise stellen Sie JS ab, teilweise lassen sie es an.«

Frage: sind das die selben User, die in Diskussionen an anderer Stelle immer wieder aus dem Hut gezaubert werden – die User, die angeblich nicht wissen, dass man Schriften vergrößern kann, weil die Optionen dafür im Internet Explorer so gut versteckt seien?

»Alles muss mit und ohne funktionieren, wieso sollte ich also etwas funktionierendes, was trotzdem Benutzerfreundlich ist (auch unter Accessablility-Gesichtspunkten) mit etwas erweitern, dass mir und dem Besucher keinen Mehrwert bringt?«

Wo wir gerade von »funktionieren« sprechen – was ist denn mit Web-basierten Anwendungen, die gar nicht ohne JavaScript funktionieren können? Und was hat das im übrigen mit Accessibility (schreibt man übrigens mit i in der Mitte) zu tun?

»Gut manche Sachen sehen mit JS besser aus«

Ok, ich denke wir haben hier ein grundlegendes Verständnisproblem: JavaScript hat nichts, aber auch wirklich gar nichts mit dem Aussehen eines Dokumentes oder einer Anwendung zu tun. JavaScript ist die Verhaltensebene, für's Aussehen gibt's CSS. Um genau das geht's in Chris' Artikel.

»Spätestens in Bezug auf Suchmaschienen versagt eine solche Menüführung aber garantiert - besonders wenn sie JS-gestützt ist.«

Wilkommen im Jahr 2007: der Googlebot kann JavaScript. Wenn man verbreitete Bibliotheken wie Prototype einsetzt wird man beim Blick in die Logfiles mit Erstaunen feststellen, dass der Robot auch JavaScript-Links ausführt - ein Verhalten, dass mittlerweile sogar von Google bestätigt wurde.

Permanenter Link

alex
am 11.01.2007 - 19:18

@alexander beuti

Inzwischen steigt der Anteil mit eingeschalteten JS wieder an - aber solange er das nicht noch ein wenig tut, werde ich mir kein spezielles Design für diejenigen , die JS an haben ausdenken.

laut logfile meiner seite ist der anteil bei 0.3%...
der höchste anteil, den ich bei einem kunden (heute für diesen monat) gesehen habe liegt dagegen bei 2.3% (da dürften aber auch robots, spider und ähnliches bei sein, die sich lediglich als browser ausgegeben haben)

Alles muss mit und ohne funktionieren, wieso sollte ich also etwas funktionierendes, was trotzdem Benutzerfreundlich ist (auch unter Accessablility-Gesichtspunkten) mit etwas erweitern, dass mir und dem Besucher keinen Mehrwert bringt?

genau darum ging es ja in dem artikel. mit richtig eingesetztem javascript kann man mehrwert bieten (progressive enhancement, wurde in diesem artikel inhaltlich angesprochen, ist im verlinkten artikel mehrmals angesprochen und auch hier schon in den kommentaren gefallen)...

Ein Drop-Down Menü ... hat aber große Nachteile - Vorteil ist eigentlich nur, dass es ... Übersichtlicher ist, als alle Links gleichzeitig an zu zeigen.

das ist doch ein bedeutender vorteil für alle user?

Drop-Down...
Spätestens in Bezug auf Suchmaschienen versagt eine solche Menüführung aber garantiert - besonders wenn sie JS-gestützt ist.

bevor du so etwas behauptest (der hinweis von tomas mit google hat mich überrascht/wusste ich nicht, ist aber eh egal), lies dir vielleicht mal chris´ tutorial zum unobtrusivem javascript durch -> http://ichwill.net/ (wurde zwar schon gepostet, aber scheint nicht wirklich angekommen zu sein).

... mit der Tastatur ...
Will ich mich erst durch die gesamte Seitenstrucktur tabben, nur weil ich auf den Punkt ganz unten (Impressum) will? NEIN! Will ich nicht!

auch, wenn ich mich wiederhole: http://pfirsichmelba.de/artikel-scripts/dropdown/horizontal.html

geh mal da drauf und tabbe dich durch´s menü, kannst von mir aus auch mal mit opera´s spatial navigation probieren (danke übrigens an chris: spatial navigation kannte ich bis zu diesem artikel nicht).

vielleicht liest du dir auch den dazugehörigen artikel durch/guckst dir das script mit den einstellmöglichkeiten an, bevor du urteilst.
wäre für eine diskussion auf jeden fall vorteilhaft.

@tomas

Frage: sind das die selben User..., die angeblich nicht wissen, dass man Schriften vergrößern kann...?

von denen gibt es deutlich mehr als von den usern, um die es hier geht.

Und was hat das im übrigen mit Accessibility zu tun?

weiss nicht genau wie du das meinst, aber einen gewissen zusammenhang mit "accessibility 1.0" und rücksicht auf user ohne javascript (ist das eine persönliche behinderung?) wird man nicht unter´n tisch kehren können.

spätestens seit deinem/n flash-artikel/n ist klar, dass du schon in "accessibility 2.0" denkst...

Permanenter Link

Uwe
am 06.04.2007 - 08:23

Ist das Problem von Java Script nicht, dass nur ca 90 % aller User dieses aktiviert haben. 90 % ist zwar viel, aber nicht jeder kann diese Seite dann so sehen wie er sie sehen soll..

Naja wie auch immer CSS Fetzt !! :-))
Uwe

Permanenter Link

razq
am 20.05.2007 - 11:17

Dankeschön für die informativen Sachen :)
VIEL SPAß NOCH

Permanenter Link

Detlef Garbrecht
am 11.08.2008 - 23:21

Hallo, ich weiß gar nicht, ob sich hier noch etwas tut - ich versuche es trotzdem.

Letztes Wochenende war ich auf der Suche nach einer Lösung für das "Ist-CSS-eingeschaltet-Problem" und bin so auf diese Seite gestoßen. Dummer Weise musste ich feststellen, dass iCab 4.1.1, Safari 3.1.2 und Sunrise 1.7.4 (also insgesamt 60% aller auf meinem Mac installierte Browser) egal, ob CSS ein- oder ausgeschaltet ist, das selbe Resultat liefern. Ich habe auch mit "visibility.hidden" und "display:none" experimentiert und dabei in einer "for in"-Schleife alle Eigenschaften ausgelesen - jeweils mit dem gleiche Ergebnis.

Nun zu meiner eigentlichen Frage: Gibt es noch eine andere Methode der CSS-Detektion mittels JavaScript? Denn wenn nicht, kann man doch alles in dieser Richtung vergessen. Oder man kehrt zu Meldungen à la "Diese Seite wurde für Internet Explorer optimiert" zurück.

MfG

Permanenter Link

Die Kommentare sind geschlossen.