Runde Ecken mit Javascript - Die perfekte Lösung
13.09.2007 - 21:17 Webdesign, JavaScript 11 Kommentar(e)
Ich weis nicht wie es euch geht, aber ich bekam immer kleine Schweißausbrüche sobald ein Kunde in einem skalierbarem Layout abgerundete Ecken für Boxen oder dergleichen haben wollte.
Nicht dass solche Rundungen nicht schick aussehen würden, doch aus semantischer Sicht bzw. aus Sicht auf Punkto “Wartbarkeit” war das für mich bisher immer ein Graus.
Was sich früher durch monströse Tabellenkonstrukte eh mehr schlecht als recht umsetzen ließ benötigte bis vor kurzem auch bei tabellenfreien Layouts meist bis zu vierfach verschachtelte DIV-Elemente, pro Box versteht sich.
Weil ich eigentlich immer versuche meinen Quelltext so übersichtlich und schlank wie nur möglich zu halten habe ich mich daher bisher oft vor den Rundungen gefürchtet.
Damit macht das gerade entdeckte jQuery-Plugin jQuery Roundcorners Canvas nun anscheinend endlich Schluss. Das Plugin scheint alle Faktoren die man an solch ein Script stellen könnte zu vereinen:
- kein zusätzliches Markup im Quelltext
- leicht konfigurierbar
- Ecken werden weich dargestellt (Antialiasing)
- es werden keine Grafiken benötigt
- es sind ebenfalls abgerundete Ränder möglich
- Rundungen können nur auf einzelne Kanten gesetzt werden
- funktioniert sowohl im IE6, IE7, Firefox, Safari und Opera
- ohne JS werden normale Kanten angezeigt
- zusätzliches Ladevolumen im Firefox mit GZip ca. 3KB, im IE6/7 ca. 7KB
Zum Ladevolumen muss zusätzlich natürlich noch das jQuery-Framework gerechnet werden.
Sicherlich, bei einer einzelnen und relativ festen Box macht das Plugin wahrscheinlich keinen wirklichen Sinn. Soll jedoch eine Box in der breite/höhe flexibel sein und zudem Ihre Farbe evtl. auch einmal schnell wechseln können, so ist das Plugin sicherlich eine echte Bereicherung.
Wo ich noch keine Schlüsse ziehen konnte ist die Performance. In der Demo konnte ich jetzt auf die schnelle keine Geschwindigkeitseinbußen feststellen, aber vielleicht sieht das auf älteren Systemen ja anders aus?
Kommentare zum Thema Runde Ecken mit Javascript - Die perfekte Lösung:
Ehrlich gesagt: Was die Optik angeht muss man in der heutigen Zeit aus meiner Sicht keine non-JS-User mehr großartig berücksichtigen. Logisch, es sollte alles auch ohne JS verfügbar sein und auch nichts gestört auseehen, aber nur wegen der 3% darauf zu verzichten? Mhm nein! Wie gesagt, es wäre sowieso nur eine optische Spielerei auf die die 3 Prozent auch gut verzichten könnten.
Der Quelltext wird nicht aufgebläht, sondern der DOM. Das sind im Prinzip doch zwei unterschiedliche Sachen. Baue ich mir selber meine verschachtelten Boxen muss die Verschachtelung auch jedesmal aufs neue geladen werden. Beim Plugin wird vom JS ja während des Renderns virtueller Code in den DOM eingeschleust, der aber im Prinzip nicht runtergeladen werden muss, sofern das JS erstmal im Cache ist.
Sicherlich gibt es viele Pros und Contras, und bei einer simplen Box im Layout werde ich auch keine 10KB JS einschleusen, aber manchmal werden eben sehr flexible dinge gewünscht…
Das Argument: Sehen ja aber nur die Leute mit JS ist finde ich übertrieben. Die Technik schreitet voran und ehrlich gesagt juckt es mich da nur gering wenn jemand der in dieser von Ajax und Co beherrschten Zeit immer noch Angst vor bösen JS-Scripten hat, dann keine runden sondern eben kantige Ecken sieht :)
3% können entscheidend sein, wenn da damit 3 von 100 Kunden schon im Vorraus “entwertest” ;) Gut bei den Ecken ist es ggf. noch zu verschmerzen, aber gerade in der Zeit des Web 2.0 sollte man auch non-JS-User die Chance geben – siehe Zugänglichkeit :)
Und die Angst vor JS ist nicht unbegründet, nicht umsonst gibt es Cross-Site-Scripting. Zumal Web 2.0 meines Erachtens vollkommen überbewertet wird und sich meiner Meinung nach nur in Nieschen durchsetzen kann, da die Usability einfach unzureichend ist. Das HTTP-Protokoll ist eben nicht für virtuelle Desktops gemacht…
Auf jeden Fall hat das JS-Skript den Vorteil, dass es den DOM erst aufbläht, da hast du wohl Recht :)
Cross-Site-Scripting betrifft allerdings wohl mehr den Seitenbetreiber als den Besucher, dem kann es im Prinzip egal sein, das siehst du glaube ich von der falschen Seite.
Und wie gesagt bin ich auch dafür bei Ajaxanwendungen eine geeignete Fall-Back-Lösung anzubieten, doch grafisch muss aus meiner Sicht ein non-JS-ler auch mal mit weniger zufrieden geben. Es ist eben eine Randgruppe, und ich glaube nicht das die bei meinen Kunden nicht kaufen würden nur weil die Navigationsbuttons nun eckig sind :)
Aber ich gebe dir recht, erstmal sollte man natürlich schauen ob das ganze nicht vielleicht auch ohne JS-Schnickschnack machbar ist.
Um hier auch mal wieder meinen Senf dazu zu geben: Wer JS ausschaltet, entscheidet sich ja schon bewusst gegen die bekannten Effekte wie LightBox, Fades und Ziehharmonika. Ob so jemand sich wirklich daran stört, wenn es für ihn keine runden Ecken gibt? Ich denke nicht, solange das Design dadurch nicht völlig aus dem Rahmen fällt.
Da überwiegen meiner Meinung nach doch die Vorteile: Einfach zu implementieren, zu warten und zu modifizieren und sauber für alternative Ausgabemedien. Klingt alles sehr gut. Ob es das auch ist, muss letztlich der Praxistest zeigen.
> Cross-Site-Scripting betrifft allerdings wohl mehr den Seitenbetreiber als den Besucher,dem kann es im Prinzip egal sein, das siehst du glaube ich von der falschen Seite.
Das erklärst Du mir jetzt bitte mal genauer.
- Wenn Dir durch XSS auf deiner Online-Banking Seite oder in einem Onlineshop ein monetärer Verlust entsteht, ist das ein Problem des Seitenbetreibers?
- Wenn Du Dir durch XSS Malware einfängst, die beliebige Software im Benutzerkontext auf deinem Rechner installieren kann ist das ein Problem des Seitenbetreibers?
- etc, etc.
Ich denke, Du solltest nochmal einen Blick auf die Wikipedia Seite zu XSS werfen und dich vor allem mit den unterschiedlichen Formen auseinandersetzen:
http://de.wikipedia.org/wiki/Cross-Site_Scripting
Zumindest in meinen Augen geht die größte Gefahr von XSS davon aus, dass das Gefahrenpotential wie bei vielen anderen Angriffspunkten in der Vergangenheit sehr unterschätzt wird. Ich denke da z.B. an SQL Injection, die nun bald 10 Jahre alt wird und erst vor einiger Zeit wirklich Beachtung fand.
Ein interessantes Blog zu dem Thema ist übrigens http://www.gnucitizen.org. Der Beitrag zum Tools XSS Shell überzeugt dich unter Umständen doch davon, dass die Gefahr auch für den User sehr konkret ist.
Aber was die Benutzer angeht, gebe ich Dir uneingeschränkt recht. Die ohne-JS Generation wird definitiv aussterben. Und sei es, weil Sie sich den neuen Rechner mit vorinstalliertem Vista + IE7 aus dem Media Markt holen.
Licht am Horizont: http://php-ids.org ;-)
Ok, sagen wir so: Wenn natürlich eine Seite “infiziert” wurde geht das Problem natürlich auch auf die Userseite über, das habe ich ehrlich gesagt nicht bedacht.
Doch wo will man die Linie ziehen? Javascript bringt für mich einfach zu viele Vorteile mit als das ich es deaktivieren würde.Um XSS aber erstmal ermöglichen zu können muss es immer auch erst die schludrigen Webseitenbetreiber geben die XSS zulassen, und wie will man die herausfiltern?
Mir geht es nur so: Ich bin seit 9 Jahren ein großer Internetkonsument, immer mit aktiviertem Javascript, und mir sind dadurch bisher noch keine direkten Nachteile entstanden. Vielleicht auch eine Sache der Browserwahl?
Aber Ok, ursprünglich ging es um simple Ecken, bzw. Rundungen, und ich glaube hier braucht der User erstmal nichts zu befürchten :)
Öhm, was bitte haben abgerundete Ecken denn bitte mit Content zutun? Was willst du dem Robot den wichtiges mit den Rundungen mitteilen? Ich verstehe deinen Einwand jetzt gleich 0.
Zudem solltest du dich wohl doch nochmal über den Unterschied zwischen Java, Javascript und letztendlich der Nutzung eines Frameworks informieren, erstere beiden sind nämlich völlig unterschiedliche Dinge.
@[Bitte keine SEO Namen] Javascript != Java …
Suchmaschinen haben evtl. mit Java und Flash ein Problem, weniger aber mit Javascript, vor allem nicht, wenn damit layoutet wird, das überliest der bot einfach.
Interessantes Script werd’s gleichmal ausprobieren
Kommentar-Feed für diesen Artikel
jQuery 1.2 veröffentlich jQuery UI 1.0 und jQuery 1.2.1 veröffentlicht

Habs mir grad mal angesehen – der generierte Quelltext ist ebenfalls etwas aufgebläht durch die canvas elemente und zusätzlichen style-Angaben im Quelltext. Wenn man mit <span>-Elementen arbeitet kann man auch gut runde Ecken anbringen (auch in skalierbaren Layouts). Interessant könnte dies werden, wenn es um sehr viele Ecken geht. Da gilt es von Projekt, zu Projekt zu entscheiden, aber sicher ein guter Weg – für diejenigen, die JS aktiviert haben ;) – auf kommerziellen Seiten schließlich ein no go oder man muss zweigleisig fahren…