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:

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:

1 | Hasch schrieb am 13.09.2007 um 23:14
Gravatar dieses Kommentators

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…

2 | Christian schrieb am 14.09.2007 um 00:38
Gravatar dieses Kommentators

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 | Hasch schrieb am 14.09.2007 um 09:30
Gravatar dieses Kommentators

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 :)

4 | Christian schrieb am 14.09.2007 um 10:06
Gravatar dieses Kommentators

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.

5 | Veit schrieb am 14.09.2007 um 12:19
Gravatar dieses Kommentators

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.

6 | Florian schrieb am 14.09.2007 um 22:18
Gravatar dieses Kommentators

> 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.

Demo

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 ;-)

7 | Christian schrieb am 15.09.2007 um 14:39
Gravatar dieses Kommentators

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 :)

8 | [Bitte keine SEO Namen] schrieb am 24.09.2007 um 20:18
Gravatar dieses Kommentators

Nun wenn man Java kann ist das sicher von vorteil, ein tolles Design wirds auf jeden fall, Aber.. das Problem ist immer das der Google robot hier keinen Content findet, also lieber weniger Webdesign und mehr inhalt ;)

9 | Christian schrieb am 24.09.2007 um 21:19
Gravatar dieses Kommentators

Ö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.

10 | Dietmar schrieb am 21.05.2008 um 16:44
Gravatar dieses Kommentators

der link ist sehr interessant :) und stellt eine alternative zu dem üblichen grafischen lösungen dar

11 | solidcolor schrieb am 04.06.2008 um 15:26
Gravatar dieses Kommentators

@[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




Dein Kommentar:


HTML-Tags werden entfernt.
Formatierung bitte mit Textile.
Gravatare werden unterstützt.

Werbeabwehr: (bitte lass dieses Feld auf jeden Fall leer)

Name: (erforderlich)

E-Mail: (wird NICHT angezeigt)

Homepage: (wird bei Spamverdacht manuell gelöscht)



Blogsuche

RSS-Feeds

Plaste & Plastik

plasteundplastik.de - Das Geocaching-Weblog

Die Kategorien


Netz-Fundstücke


Meta / Propaganda