HorrorWeb

Aus mosfetkiller-Wiki
Version vom 29. Februar 2012, 18:36 Uhr von Jwacalex (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen
Diese Seite befindet sich immer in Bearbeitung. Es steht dir frei sofort etwas hinzuzufügen



Nachdem sich das Forum "Computer" um Webdesign und -programmierung dreht wollen wir hier einige gruseligen Konstrukte sammeln. Vermeidet sie wenn es geht (also immer)

Strukturprobleme

goto hell;

Zuerst einmal ein kleines Beispiel des Vergehens:

 <?php
  hell:
   echo "don't do it\n";
  goto hell;
 ?>

"The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one's program." -- Edsger Dijkstra Quelle

Warum ist goto böse?

Einfach gesagt es zerstört den (lesbaren) Programmfluss und die Wartbarkeit des Codes. Es gibt eigentlich keinen Fall in dem man das Problem nicht auch anderes lösen kann. Wenn du es doch brauchen solltest, ist es sinnvoller die Struktur deines Scripts zu ändern. Ob der Interpreter oder Compiler intern ein oder eintausend gotos erzeugt interessiert den Programmierer meistens nicht. Der Compiler weiß in der Regel was er macht, der Programmierer in der Regel weniger. Wenn du es doch verwendest, pass auf, dass dir nicht das passiert.

Webdesign

JavaScript

Frameworks

Gerade bei JavaScript empfiehlt es sich auf ein gutes Framework wie z.B. jQuery zu setzen. Neben den "üblichen" Vorteilen wie fluent interfaces und anderen Vereinfachungen der Syntax bietet es eine gute Crossbrowser-Kompatibilität. Hierdurch kann man sehr einfach Manipulationen am DOM-Baum vornehmen (sogar mit Effekten und CSS3-Kompatibitiät) ohne sich um irgendwelche Browsereigenheiten rumärgern zu müssen.

 $("#test").show("slow"); 

Dies würde z.B. das DIV-Element mit der Id "test" langsam einfaden. Und überlege wie viel JavaScript-Code du normalerweise gebraucht hättest.

Kompatibilität

JavaScript ist eine sehr schöne Variante den Webauftritt zu verbessern. Der Schwachpunkt davon ist allerdings, dass keine Website auf JavaScript basieren sollte. Dafür gibt es zwei markante Gründe: Zum einen gibt es Browser, die JavaScript ungenügend oder gar nicht unterstützen, zum anderen ist jeder Bestandteil aus JavaScript ein Eingriff in die Freiheit des Benutzers.

Eine sehr gute Variante von dynamisch generierten Seiten ist, wenn ein eigentlich statischer Inhalt mittels JavaScript abgeändert wird. So ist gewährleistet, dass der User trotz eines Browsers ohne JavaScript Unterstützung die Website benutzen kann, oder dass er, wenn ihn die dynamische Seite nervt, das JavaScript auf der Seite deaktivieren kann.

Beispiel anhand eines Popups:

 <a href="diePopupSeite.html" onclick="openFancyPopup('diePopupSeite.html'); return false;">PopUp öffnen</a>

Hier wird ein klassischer Link definiert, mit dem Zusatz dass beim Klicken das JavaScript im onclick="" ausgeführt wird, und durch das "return false;" wird das Öffnen des eigentlichen Links verhindert. Wenn nun der Browser kein JavaScript unterstützt, kann er den Link dank des "href"-Attributes trotzdem öffnen.

Es gilt also nicht, JavaScript zu vermeiden, sondern es sinnvoll einzusetzen!

Häufige Fehler

IDs

Auf einer HTML Seite darf eine ID nur einem Element zugeordnet werden. Eine ID, wie der Name schon sagt, soll ein Element zweifelsfrei identifizieren, daher darf sie nicht doppeldeutig sein:

  <style type="text/CSS">
     #MenuLink{
        color:red;
        text-decoration:blink;
     }
  </style>
  <a href="http://google.com/" id="MenuLink">Google</a>
  <a href="http://www.lycos.com/" id="MenuLink">Lycos</a>

In diesem Fall bietet sich die Zuweisung über Klassen an:

  <style type="text/CSS">
     .MenuLink{
        color:red;
        text-decoration:blink;
     }
  </style>
  <a href="http://google.com/" class="MenuLink">Google</a>
  <a href="http://www.lycos.com/" class="MenuLink">Lycos</a>

Encoding

Viele Leute sind mit dem Encoding ihrer Seite inkonsequent. Es empfiehlt sich, das Encoding von Anfang an zu setzen und bis zum Ende durchzuziehen. Dem Browser sollte das Encoding auch noch mitgeteilt werden:

  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />

Welches Encoding ihr schlussendlich verwendet ist euch überlassen. Nur verkorkste Zeichen will niemand sehen!

W3C-Validität

Es ist zwar keine Regel, trotzdem zeugt es von gutem Stil wenn die Webseite HTML4.01-Strict valide ist. Dazu sollte man den Header einer Datei in der Form ausführen:

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
         "http://www.w3.org/TR/html4/strict.dtd">

Und danach schickt man die Seite durch den W3C-Validator und korrigiert solange, bis er keine Fehler mehr ausgibt. Wenn man es ganz strikt haben will, empfiehlt sich allerdings XHTML1.0-Strict.

Alternativ ist es möglich, das ganze HTML5 zu deklarieren

  <!DOCTYPE html>

Deprecated Tags / Attributs

Etliche Tags sind noch aktuell aus der Zeit als Mosaic gerade modern war. Schon in HTML4 sind diese (nicht vollständig) als veraltet markiert. Und in HTML5 sind einige rausgeflogen, andere veraltet.

  • center
  • u
  • strike
  • frame(set)
  • nobr

Weiterhin ist das Nutzen folgender Attribute auch eine moderne Form der Nekromatie

  • align z.B. in div, table, hr
  • *link z.B. in body
  • language in script