Einfache „Klassenvariablen“

class Cat
  
  @@size = :small
  
  def self.size
    @@size
  end

  def self.size= new_size
    @@size = new_size
  end

  def size
    @@size
  end

end

expect(Cat.size).to be :small
expect(Cat.new.size).to be :small
Cat.size = :medium
expect(Cat.size).to be :medium
expect(Cat.new.size).to be :medium

Vererbung

class HouseCat < Cat
end

class Lion < Cat
end

expect(Lion.size).to be :small
Lion.size = :big
expect(Lion.size).to be :big
expect(HouseCat.size).to be :big

Hauskatze und Löwe teilen die selbe Variable, was zu erwarten war. Lässt sich das trennen?

@@-Variablen sind keine Klassenvariablen

class HouseCat < Cat
end

class Lion < Cat
  @@size = :big
end

expect(Lion.size).to be :big
expect(HouseCat.size).to be :big # !!!

Nein. Die gesetzte Variable gilt für die gesamte Klassenhierarchie aufwärts.

Superklassen haben übrigens keinen Zugriff:

class Cat
  
  def self.size
    @@size
  end

end

class Lion < Cat
  @@size = :big
end

expect{ Lion.size }.to raise_error NameError

Richtige Klassenvariablen

Da in Ruby auch Klassen Objekte sind, sind Instanzvariablen dieser Objekte auch Klassenvariablen. Bemerkenswert ist hier die strenge Sichtbarkeitsbeschränkung: Selbst wenn @small und self.size in der selben Klassen definiert werden, kann self.size nach der Vererbung in die HouseCat nicht länger mit @small auf die Klassenvariable von Cat zurgreifen.

class Cat
  
  @size = :small
  
  def self.size
    @size
  end

end

class HouseCat < Cat
end

class Lion < Cat
  @size = :big
end

expect(Lion.size).to be :big
expect(Cat.size).to be :small
expect(HouseCat.size).to be_nil

Aber hier können ja wieder Klassenhierarchievariablen helfen.

<div id="page_wrap" class="container row">
 <header class="row span_12">
  <hgroup class="row span_12">
   <h1 class="col span_4">Site Title</h1>
   <h2 class="col span_8">Site Description</h2>

Fünf Elemente, zehn Klassen, eine ID? Diese netten Zusatzinformationen führen zu 193 statt 68 Zeichen. Ich weiß nicht, wer einmal beschlossen hat, Stylesheets vom Markup zu trennen. Und ich weiß auch nicht wie lange das her ist. Aber ich bin mir sicher: Das hat er oder sie sicher nicht gewollt.

Auch Style-Klassen sind Designinformationen…

… und haben im Markup nichts zu suchen. HTML hat im wesentlichen genau eine Aufgabe: Den Inhalt der Seite zu transportieren. Zudem können noch zusätzliche Informationen angegeben werden, etwa wo sich Dateien befinden, welche Scripts oder eben auch Stylesheets enthalten. Diese Dateien sind optional, es steht jedem zu sie wegzulassen.

Ein großer Teil von Website-Besuchern sind Bots, die solche Sachen in der Regel nicht interessiert. Trotzdem verdoppeln die meisten ihre HTML-Größe auf oben beschriebene Weise.

Fehlende Wiederverwendbarkeit von CSS

Auf den meisten Websites bestimmt also das HTML durch seine Klassen selbst, wie es dargestellt werden soll. Der Grund hierfür ist aus meiner Sicht der stark begrenzte Funktionsumfang von CSS: Es gibt keine Variablen, keine Vererbung und keine anderen Wiederverwendungstechniken. Sollen Header und Footer die selbe Hintergrundfarbe haben, muss diese für beide definiert werden. Das führt zu einer problematischen Code-Dopplung: Will man die Farbe ändern, muss man dies an zwei Stellen tun.

Viele Webdesigner und Framework-Schreiber versuchen daher, diese Eigenschaften, die für beide Elemente gleich sind, in eine neue Klasse auszulagern. Da CSS diese Klassenstyles aber nicht mit bestimmten Elementen verknüpfen kann, wird diese Information ins HTML ausgelagert. Auch wenn man es nicht immer direkt wahrnimmt: Solche Klassen sind ein direkter Teil von CSS.

Um dieses Problem abzuschwächen, gibt es viele interessante erweiterte Sprachen, die CSS erzeugen. Less ist sicher einer der prominentesten Vertreter, den ich aber meist in seiner PHP-Variante Less-PHP benutze.

Schlimmer geht immer: Wrapper-Elemente

Das obige Beispiel enthält mit <div id="page_wrap" class="container row"> ein noch viel schlimmeres Problem: Wrapper-Elemente. Typo 3 geht hier mit schlechtem Beispiel voran. Überschrift gefällig?

<div id="c304" class="csc-default">
 <div class="csc-header csc-header-n1">
  <h1 class="user class">Impressum</h1>
 </div>
</div>

Das sind 130 Zeichen Markup für neun Buchstaben. Und das ist durchaus üblich.

Meine Vorsätze für künftige Websites

• Akzeptieren, dass eine Gruppe von Elementen nicht umrandet werden kann, wenn es an der Stelle kein Elternelement gibt. Meist ist dort kein Extra-Div, weil es dort nicht hingehört. Wenn es semantisch nicht zusammengehört, warum sollte man es optisch gruppieren?
• Warum nicht mal Javascript? Wenn man es trotzdem nicht lassen kann, kann man die Wrapper doch einfach mit Javascript ergänzen. Auch das hält das ausgelieferte HTML rein.
• Es geht auch semantisch: Klassen und IDs sind nichts schlechtes. Sie können Informationen über ein HTML-Element enthalten. Klassen wie article, comment oder author sind Metainformationen des Inhalts und somit legitimer Teil des Markups. Stylesheets sollten solche Informationen adressieren.
• HTML-5-Elemente: Besser sind die vielen neuen HTML-5-Elemente, die solche semantischen Informationen bereits in sich tragen.
  • section
  • article
  • header
  • footer
  • figure
  • aside
  • und viele, viele mehr…
• Alte Browser fallenlassen. Schluss mit Browserweichen und Zusatz-Wrappern.
• Eine Weiche vielleicht doch: Für IE < 8 CSS und Javascript gleich ganz abschalten.

Ich träume von einer Welt, in der man Websites auch im Quelltext lesen kann…