Guter Stil

[michael]

Moin,

nachdem ich meine Webseiten lange Zeit mit Tabellen gelayoutet habe, habe ich mich aufgrund wiederholter Kritik und Hinweise dazu entschieden, in Zukunft Divs zu verwenden.

Da ich immer wieder Probleme mit dem Setzen von irgendwelchen Abständen mit (den CSS-Eigenschaften margin und padding) sowie mit ungewollten "Zeilenumbrüchen" (wenn ich mehrere Divs aneinanderreihte) hatte, (Es wollt einfach nie so aussehen, wie ich mir das vorstellte  - und schon gar nicht in verschiedenen Browsern.) bin ich dazu übergegangen, die Divs nach absoluten Pixelwerten (normalerweise relativ zu einem Ober-Div, das dann z.B. zentriert wird) auszurichten.

Ist sowas eigentlich guter Stil? Oder verbaut man damit sich und seinen Benutzern irgendwelche Möglichkeiten? Hätte mir jemand ein _gutes_ Beispiel einer grösseren, wohldesignten Webseite, wo man gute Layout-Techniken mal 1:1 in der Realität ansehen könnte?

mfG, michael

[Cheatah]

Hi,

nachdem ich meine Webseiten lange Zeit mit Tabellen gelayoutet habe, habe ich mich aufgrund wiederholter Kritik und Hinweise dazu entschieden, in Zukunft Divs zu verwenden.

es ist schön, dass Du vom Tabellen-Layout abgekommen bist. Wie viel Kritik und Hinweise benötigst Du, um auch auf <div>-Suppen zu verzichten und statt dessen mit semantischem Markup zu arbeiten?

Ist sowas eigentlich guter Stil?

Das kommt darauf an, wie man es anwendet. Anfängern ist auf jeden Fall zu empfehlen, auf absolute Positionierung vollständig zu verzichten, bis diverse Grundlagen verinnerlicht wurden. Sie ist schwer zu handhaben, wenn man sich ihrer Konsequenzen nicht bewusst ist.

Hätte mir jemand ein _gutes_ Beispiel einer grösseren, wohldesignten Webseite, wo man gute Layout-Techniken mal 1:1 in der Realität ansehen könnte?

http://www.csszengarden.com/

Cheatah

[Michael]

Hi,

es ist schön, dass Du vom Tabellen-Layout abgekommen bist. Wie viel Kritik und Hinweise benötigst Du, um auch auf <div>-Suppen zu verzichten und statt dessen mit semantischem Markup zu arbeiten?

Eigentlich nicht viel. Ich werde mir das auf jeden Fall mal ansehen! Gibt es irgendwo gute Beschreibungen zum Thema semantisches Markup? Insbesondere die Grundprinzipien und Gründe dafür würden mich interessieren.

Ist sowas eigentlich guter Stil?

Das kommt darauf an, wie man es anwendet. Anfängern ist auf jeden Fall zu empfehlen, auf absolute Positionierung vollständig zu verzichten, bis diverse Grundlagen verinnerlicht wurden. Sie ist schwer zu handhaben, wenn man sich ihrer Konsequenzen nicht bewusst ist.

Hmmm...als Anfänger würde ich mich eigentlich nicht bezeichnen, ich habe schon diverse Webseiten gemacht. Auf der anderen Seite bin ich mir bewusst, dass meine HTML/CSS-Kenntnisse nicht perfekt sind und ich daher oftmals ziemliches Flickwerk erzeuge.

Die Handhabung von absolut-positionierten Divs ist also etwas schwieriger. Aber wie sieht es mit Barrierefreiheit, Standard- und Browserkompatibilität aus?

mfG, michael

PS: Es geht zurzeit speziell um diese Seite: http://www.thinkcool.ch. Da ist was den Programmierstil angeht doch noch so einiges schief. Aber das möchte ich jetzt nach und nach korrigieren.

[Cheatah]

Hi,

Gibt es irgendwo gute Beschreibungen zum Thema semantisches Markup?

da kann ich Dir jetzt leider keine explizite Website für empfehlen, sondern nur das regelmäßige Mitlesen in diesem Forum - und natürlich das Durchschreiten der Welt mit offenen Augen.

Insbesondere die Grundprinzipien und Gründe dafür würden mich interessieren.

Die Gründe sind exakt die, die gegen Tabellen-Layout sprechen, und das eine Grundprinzip lautet: HTML im Sinne von HTML. Strukturiere also z.B. Absätze im Fließtext mit <p>, Überschriften mit <h1> bis <h6>, tabellarische Daten mit <table> und all seinen Nachkommen (<thead>, <tbody>, <caption>, ...) usw. Im Endeffekt bedeutet das, dass Du beim Schreiben des HTML-Codes *nicht* an die derzeit gewünschte Darstellung denken *darfst*. Das ist schwierig, aber erlernbar.

Hmmm...als Anfänger würde ich mich eigentlich nicht bezeichnen, ich habe schon diverse Webseiten gemacht.

Laut Deiner Beschreibung bist Du zumindest im Bereich CSS Anfänger. In Folge dessen bist Du es bei HTML auch. Die (meiner Ansicht nach) einzige Chance, HTML zu beherrschen, ohne Meister in CSS zu sein ist, bisher Seiten gebaut zu haben, bei denen die Darstellung aber sowas von völlig egal war.

Die Handhabung von absolut-positionierten Divs ist also etwas schwieriger.

Ja. Man muss sich einiger Dinge bewusst sein, um Fehler zu vermeiden.

Aber wie sieht es mit Barrierefreiheit, Standard- und Browserkompatibilität aus?

Ist alles drei verhältnismäßig hoch. Aber insbesondere beim ersten und beim letzten Punkt kommt es immer(!) _sehr_ auf das Detail an.

PS: Es geht zurzeit speziell um diese Seite: http://www.thinkcool.ch. Da ist was den Programmierstil angeht doch noch so einiges schief. Aber das möchte ich jetzt nach und nach korrigieren.

Nun, den Programmierstil kann ich nicht beurteilen, weil ich ja nur das Resultat sehe, nicht den Programm-Code, der es erzeugt. Die wesentlichsten Fehler im HTML- und CSS-Code sind, vom Tabellen-Layout abgesehen: Quirks-Mode, fehlende Trennung von Struktur und Layout, Klassengesellschaft, unsemantisches Markup (Tabellen brauche ich nicht zu erwähnen, aber auch <center> und <br> gehören da nirgendwo hin), hohe Barrieresetzung (z.B. Schriftgrößen in px) und, am schlimmsten, invalider Code. Ich nehme an, einige der Punkte waren Dir bewusst, aber vielleicht ist da auch was Neues für Dich bei.

Cheatah

[Michael]

Hallo

Die Gründe sind exakt die, die gegen Tabellen-Layout sprechen, und das eine Grundprinzip lautet: HTML im Sinne von HTML.

Beim Inhalt habe ich dass bereits versucht umzusetzen. Aber beim Layout ist es halt wesentlich schwieriger - wobei machbar, wie mir ein soeben gelesener Text gezeigt hat.(http://www.vorsprungdurchwebstandards.de/theory/semantischer-code/

Die wesentlichsten Fehler im HTML- und CSS-Code sind, vom Tabellen-Layout abgesehen:

Ja, das kommt weg ;-)

Quirks-Mode,

Noch nie gehört ;-)

fehlende Trennung von Struktur und Layout

Wie meinst du das jetzt genau? Dass ich style-Attribute direkt eingebunden anstatt in ein separates CSS-File gepackt habe?

Klassengesellschaft

<tag class="meineklasse">? Nicht gut? Wie ersetzt man sowas sinnvoll?

unsemantisches Markup (Tabellen brauche ich nicht zu erwähnen, aber auch <center> und <br> gehören da nirgendwo hin)

Wurde ich mir soeben bewusst, aber beim eigentlichen Inhalt ist es schon besser umgesetzt,

hohe Barrieresetzung (z.B. Schriftgrößen in px) und

Wie sollte man Schriftgrössen besser definieren?

am schlimmsten, invalider Code.

Ja, ich weiss. Das ist auch der Hauptgrund, warum ich die Überarbeitung in Angriff nehmen will!

Ich nehme an, einige der Punkte waren Dir bewusst, aber vielleicht ist da auch was Neues für Dich bei.

Beides ;-)

Vielen Dank für deine ausführliche Betrachtung!

mfg, Michael

[wahsaga]

hi,

Klassengesellschaft

<tag class="meineklasse">? Nicht gut? Wie ersetzt man sowas sinnvoll?

Auch hier gilt wieder:
Überlege dir, welche Elemente du wie sinnvoll als zu bestimmten Klassen zugehörig auszeichnest, noch _bevor_ du an die Darstellung denkst.

Auch lässt sich der Einsatz von Klassen "für die Formatierung" oftmals stark zurückfahren, in dem man von den in CSS vorhandenen Selektoren stärker (und sinnvoller) Gebrauch macht.

Als Beispiel deine derzeitige Navigation auf der genannten Seite:
Die hast du derzeit als Tabelle realisiert, und die einzelnen Menü-"Ebenen" in den Zellen durch Klassen wie "menutitle" und "menulink" ausgezeichnet.

Eine Navigation als tabellarische Daten zu betrachten wäre u.U. ständen möglich - im Sinne der Semantik tendiert man heute allerdings eher dazu, sie als das auszuzeichen, was sie auch tatsächlich ist - eine _Liste_ von Links. Also bieten sich hier UL und LI an.

Und für die verschiedenen Ebenen benutzt du keine Klassen zur (ausschließlichen) Kennzeichnung, sondern zeichnest die _Bedeutung_ dieser Ebenen auch schon im HTML-Markup nach: In dem du Listen verschachtelst.

<ul>
   <li>Menu-Ebene 1
      <ul>
         <li>Punkt 1</li>
         <li>Punkt 2</li>
         <li>Punkt 3</li>
      </ul>
   </li>
   <li>Menu-Ebene 2
      <ul>
         <li>Punkt 1</li>
         <li>Punkt 2</li>
      </ul>
   </li>
   ...
</ul>

Für die unterschiedliche Formatierung der Ebenen brauchst du jetzt gar keine Klassen mehr, sondern kannst das z.B. über den Nachfahrenselektor lösen.

gruß,
wahsaga

[Michael]

Hi,

Für die unterschiedliche Formatierung der Ebenen brauchst du jetzt gar keine Klassen mehr, sondern kannst das z.B. über den Nachfahrenselektor lösen.

Hmmm...ja! Aber der obersten Liste muss ich ja irgendwie sagen, dass sie eben das Menü ist und z.B. keine Liste im Inhalt. Hier wäre doch eine class sicher angebracht?

mfG, michael

[Der Martin]

Hi Michael,

Hmmm...ja! Aber der obersten Liste muss ich ja irgendwie sagen, dass sie eben das Menü ist und z.B. keine Liste im Inhalt. Hier wäre doch eine class sicher angebracht?

eher unwahrscheinlich. Wieviele Navigationslisten hast du auf einer Seite? Ich habe normalerweise nur eine. Da bietet sich anstatt einer Klasse eher eine ID an, die das Element eindeutig kennzeichnet.

So long,
 Martin

[Cheatah]

Hi,

das eine Grundprinzip lautet: HTML im Sinne von HTML.
Beim Inhalt habe ich dass bereits versucht umzusetzen. Aber beim Layout ist es halt wesentlich schwieriger

niemand hat gesagt, es sei leicht ;-) Allerdings kann ich Dir sagen, dass es leicht _wird_. Und zwar nachdem Du verinnerlicht hast, das HTML und Layout zwei Begriffe sind, die absolut nicht das geringste miteinander zu tun haben. HTML mit Layout in Verbindung zu bringen ist, als würde man bei Schuhen an Dachziegel denken.

Quirks-Mode,
Noch nie gehört ;-)

Macht nix - googeln! ;-) Nutze auch die Archiv-Suche. Der Quirks-Mode ist etwas, was Du unter allen Umständen vermeiden solltest.

fehlende Trennung von Struktur und Layout
Wie meinst du das jetzt genau? Dass ich style-Attribute direkt eingebunden anstatt in ein separates CSS-File gepackt habe?

Jepp.

Klassengesellschaft
<tag class="meineklasse">? Nicht gut? Wie ersetzt man sowas sinnvoll?

Um wahsagas Ausführungen auf einen Punkt zu bringen: Überlege Dir, was dieses Element im Vergleich (bzw. im Unterschied) zu anderen, gleichartigen Elementen des Bereichs klassifiziert. Ein typischer Anwendungsfall _für_ eine Klasse ist <p class="warning">, absolute Antibeispiele sind <a class="navitem">, <p class="greenborder"> und <div class="headline"> (jeweils aus verschiedenen Gründen).

hohe Barrieresetzung (z.B. Schriftgrößen in px) und
Wie sollte man Schriftgrössen besser definieren?

Mit Einheiten, die sich (in letzter Instanz) nach den Systemeinstellungen richten. Ideal sind em und %.

am schlimmsten, invalider Code.
Ja, ich weiss. Das ist auch der Hauptgrund, warum ich die Überarbeitung in Angriff nehmen will!

Nun, zumindest ist es ein Grund :-)

Ernsthaft - ich nehme an, Dir ist es bewusst, aber ich sage es trotzdem noch einmal: Solange der HTML- und CSS-Code nicht valide ist, kann man über dessen Ergebnisse keinerlei Aussagen treffen[1]. Validität ist das Alpha und das Omega von Code.

Vielen Dank für deine ausführliche Betrachtung!

Ich sehe, dass meine Äußerungen bei Dir konstruktiv und produktiv umgesetzt werden, was meine Geduld merklich steigert :-)

Cheatah

[1] Sofern man nicht sehr, sehr erfahren ist und sich stetig auf dem Laufenden hält.

[Michael]

Hi,

Quirks-Mode,
Noch nie gehört ;-)

Macht nix - googeln! ;-) Nutze auch die Archiv-Suche. Der Quirks-Mode ist etwas, was Du unter allen Umständen vermeiden solltest.

Achso...jetzt dämmert mir einiges...

Aber was genau wirft den Browser in den Quriks-Mode? Die Doctype-Angabe (<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">) oder veraltete, invalide Elemente bzw. Attribute?

mfG, michael

[Ashura]

Hallo Michael.

Aber was genau wirft den Browser in den Quriks-Mode? Die Doctype-Angabe (<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">) oder veraltete, invalide Elemente bzw. Attribute?

Die DOCTYPE-Deklaration ohne URI, siehe http://de.selfhtml.org/css/formate/box_modell.htm#doctype_switch@title=SELFHTML.

Einen schönen Donnerstag noch.

Gruß, Ashura

[Gunnar Bittersmann]

Hello out there!

_gutes_ Beispiel
http://www.csszengarden.com/

Bedingt. Der HTML-Quelltext ist auch eher div-Suppe als vernünftiges[tm] Markup.

See ya up the road,
Gunnar

[Mel]

Bedingt. Der HTML-Quelltext ist auch eher div-Suppe als vernünftiges[tm] Markup.

Nun, ohne diese divs wäre eine differenzierte GEstaltung wie es die unzähligen zengarden-beispiele zeigen wohl nicht möglich.

vg mel

[Gunnar Bittersmann]

Hello out there!

Nun, ohne diese divs wäre eine differenzierte GEstaltung wie es die unzähligen zengarden-beispiele zeigen wohl nicht möglich.

Natäurlich nicht. Das ist ja gerade der Sinn des Zen Gardens: zu zeigen, was mit CSS alles möglich ist. Da passt er als „_gutes_ Beispiel einer grösseren, wohldesignten Webseite“.

Einen Absatz vorher wies Cheatah aber darauf hin, „auf <div>-Suppen zu verzichten und statt dessen mit semantischem Markup [sic!] zu arbeiten“. Und da passt der Zen Garden nicht als gutes Beispiel.

See ya up the road,
Gunnar

[Mel]

Natäurlich nicht. Das ist ja gerade der Sinn des Zen Gardens: zu zeigen, was mit CSS alles möglich ist. Da passt er als „_gutes_ Beispiel einer grösseren, wohldesignten Webseite“.

Einen Absatz vorher wies Cheatah aber darauf hin, „auf <div>-Suppen zu verzichten und statt dessen mit semantischem Markup [sic!] zu arbeiten“. Und da passt der Zen Garden nicht als gutes Beispiel.

Sehe ich ja auch so. Allerdings (und das ist nicht auf Dich bezogen sondern nur mal allgemein erwähnt) finde ich dass man vorsichtig sein sollte bevor man irgendjemandes Quelltext als "div-Suppe" abtut. Das mag  oft gerechtfertigt sein oft aber auch nicht. manche Konstruktionen lassen sich eben nur mit mehreren Containern erreichen, was man auf den ersten Blick nicht unbedingt sieht.

vg mel

[Gunnar Bittersmann]

Hello out there!

Das ist ja gerade der Sinn des Zen Gardens: zu zeigen, was mit CSS alles möglich ist. Da passt er als „_gutes_ Beispiel einer grösseren, wohldesignten Webseite“.

Wobei auch dort eine Einschränkung zu machen ist: Einige der Layouts gehen von bestimmten Viewportgrößen aus oder legen die Schriftgröße (wenn man bei Winzigkeit von Größe sprechen kann) in Pixel fest. Sobald die Gegebenheiten beim Nutzer nicht so sind wie beim Autor des Layouts oder der Nutzer gar in seinem Browser eine Mindestschriftgröße festlegt, zerschießt es diese Layouts.

Als Beispiel für modernes flexibles Webseitenlayout kann der Zen Garden auch nur sehr eingeschränkt dienen.

See ya up the road,
Gunnar

[molily]

Hallo,

Das ist ja gerade der Sinn des Zen Gardens: zu zeigen, was mit CSS alles möglich ist. Da passt er als „_gutes_ Beispiel einer grösseren, wohldesignten Webseite“.

Das halte ich auch für weit hergeholt, der Zen Garden ist keine größere Site, sondern ein Showcase auf Basis genau eines Dokuments.

Ein Design für eine größere, wohlgestaltete Site müsste von Grund auf von anderen Anforderungen ausgehen.

Wobei auch dort eine Einschränkung zu machen ist: Einige der Layouts gehen von bestimmten Viewportgrößen aus oder legen die Schriftgröße (wenn man bei Winzigkeit von Größe sprechen kann) in Pixel fest. Sobald die Gegebenheiten beim Nutzer nicht so sind wie beim Autor des Layouts oder der Nutzer gar in seinem Browser eine Mindestschriftgröße festlegt, zerschießt es diese Layouts.

Ich hatte das mal anhand einiger Zen-Garden-Designs geprüft: Es sind Grafikdesign-Demonstrationen, selten aber guten Mitteldinge zwischen anpassungsfähigem, barrierefreien und künstlerischem Design. Gut, das ist jetzt keine Kritik, das ist eigentlich selbst Dave Shea klar.

Was den Code vom Zen Garden angeht: Er ist zweckmäßig. Als Vorbild für Sites, die einen anderen Zweck verfolgen, kann er selbstverstädnlich nicht dienen – das gilt für die meisten Sites. Zwischen CSS-Layout und CSS-Layout liegen Welten, was den dahinterstehenden Code angeht. Wenn ich wie manche sogenannte Portalseiten jeden Wortfitzel herumpositionieren möchte, muss ich meist tausende Container-Divs einfügen. Ich nannte das einmal Präsentationsgliederung, es ging da um die Lycos-Startseite, die ohne divs quasi mit demselben WErt wie font gar nicht auskommt. So auch der CSS Zen Garden.

Mathias

[Cheatah]

Hi,

Der HTML-Quelltext ist auch eher div-Suppe als vernünftiges[tm] Markup.

ja, er ist ... offensiv. Best Practice ist etwas anderes.

Cheatah

[Michael]

Hi,

Bedingt. Der HTML-Quelltext ist auch eher div-Suppe als vernünftiges[tm] Markup.

Aber wie soll man denn Elemente grundsätzlich positionieren? Also ich meine, wenn man z.B. die Webseite in einem etwas schmaleren, zentrierten Bereich haben möchte? Oder den ganzen Menü-Block? Ohne divs geht es da wohl kaum(?)

Könnte man die Semantik wenn divs verwendet werden nicht durch irgendwelche Attribute beifügen? z.B. class oder id?

mfg, Michael

[wahsaga]

hi,

Aber wie soll man denn Elemente grundsätzlich positionieren? Also ich meine, wenn man z.B. die Webseite in einem etwas schmaleren, zentrierten Bereich haben möchte?

Dann _könnte_ man die Elemente in diesem "Bereich" durch ein umschließendes Div gruppieren, ja.

Oder den ganzen Menü-Block? Ohne divs geht es da wohl kaum(?)

Ein vernünftig ausgezeichnetes Menü hat bereits ein übergeordnetes Element (im Beispiel UL), welches du nach Belieben formatieren kannst. Da noch ein Div drumherum zu legen, wäre hyperfluid.

Könnte man die Semantik wenn divs verwendet werden nicht durch irgendwelche Attribute beifügen? z.B. class oder id?

Nein.

<div class="absatz"> o.ä. solltest du vermeiden.
Klar kannst du den Div damit so formatieren, dass er letztendlich so aussieht, wie du einen Textabsatz aussehen lassen möchtest - aber dadurch _wird_ er semantisch nicht zu einem Textabsatz.

gruß,
wahsaga

[Cheatah]

Hi,

Ein vernünftig ausgezeichnetes Menü hat bereits ein übergeordnetes Element (im Beispiel UL), welches du nach Belieben formatieren kannst. Da noch ein Div drumherum zu legen, wäre hyperfluid.

nun, wenn man dieses Menü als einen Seitenbereich kenntlich machen möchte, was oft sinnvoll ist, wäre es fehlerbehaftete Semantik, auf das <div> zu verzichten. Was man hieran auch sieht ist, dass HTML keine eineindeutige Wissenschaft ist.

Könnte man die Semantik wenn divs verwendet werden nicht durch irgendwelche Attribute beifügen? z.B. class oder id?
Nein.
<div class="absatz"> o.ä. solltest du vermeiden.

Ja, das macht allerdings keinen Sinn. Eine Klassifizierung ist jedoch durchaus eine Form der Semantik - nämlich eine solche, die über die im HTML-Sprachumfang enthaltene Semantik hinaus geht, obwohl sie darin (sinnvollerweise) enthalten sein könnte.

Klar kannst du den Div damit so formatieren, dass er letztendlich so aussieht, wie du einen Textabsatz aussehen lassen möchtest - aber dadurch _wird_ er semantisch nicht zu einem Textabsatz.

Jupp. Was die verfügbaren HTML-Elemente an Semantik ausdrücken können, hat auch genau damit strukturiert zu werden. Erst wenn HTML nicht mehr ausreicht, kann man zu Klassen greifen. Gibt es beispielsweise kein <date>-Element, mit dem man ein Datum als solches kenntlich machen könnte, verwendet man ein <span class="date"> (vorausgesetzt, <span> ist an der Stelle ein passendes Element). Wichtig ist das Bewusstsein, dass die Menge der Clients, die dieses Datum als solches erkennen werden, arg begrenzt ist.

Cheatah

[Gunnar Bittersmann]

Hello out there!

Gibt es beispielsweise kein <date>-Element, mit dem man ein Datum als solches kenntlich machen könnte, verwendet man ein <span class="date"> […] Wichtig ist das Bewusstsein, dass die Menge der Clients, die dieses Datum als solches erkennen werden, arg begrenzt ist.

In diesem Zusammenhang dürfte der RDF/A Primer 1.0 – Embedding RDF in XHTML interessant sein.

(Das macht auch deutlich, warum ich den Begriff „semantisches Markup“ in Zusammenhang mit HTML und Auszeichnung der Dokument_struktur_ meide.)

See ya up the road,
Gunnar

[Tim Tepaße]

Hallo Gunnar,

In diesem Zusammenhang dürfte der RDF/A Primer 1.0 – Embedding RDF in XHTML interessant sein.

Ich hab neulich sehr lachen müssen, als ich den Working Draft las und feststellte, dass sich die seit Jahren diskutierte und stark umstrittene Methode, RDF in HTML einzubetten, sich dann als dasselbe Prinzip heraus stellte, das die Bewegung um Microformate schon seit längerem einsetzt. Mal ganz abgesehen davon, dass RDF/A immer noch XHTML 2 voraussetzt, wegen der beiden benötigten Attribute aus dessem Namensraum. Ich bleibe weiter gespannt, ob da noch etwas mit derzeitigem HTML Praktikables herauskommen wird. Zu wünschen wäre es ja. Ich bezweifel es aber. XHTML 1.x leidet eindeutig daran, bei eingebettetem Fremd-XML ohne eigenen deklarierten Doctype invalid zu werden, d.h. man kann nicht plötzlich die Attribute xhtml2:about, xhtml2:datatype, xhtml2:property und xhtml2:content einführen, ohne das Dokument „kaputt“ zu machen. XHTML 2 scheint nach deren Relax NG auch immer noch unter dieser Krankheit zu leiden, für mich unbegreiflich.

Wenn man nicht unbedingt RDF braucht – überlegenswert ist es – spricht bislang nichts dagegen das datetime pattern zu nutzen, ähnlich wird es bereits bei den Microformaten hCalender und hAtom eingesetzt, inklusive es bereits verarbeitender Software.

(Das macht auch deutlich, warum ich den Begriff „semantisches Markup“ in Zusammenhang mit HTML und Auszeichnung der Dokument_struktur_ meide.)

Semantik liegt eh nur im Auge des Auszeichners. ;)

Tim

[Michael]

Guten Abend,

Ich habe mir jetzt folgenden Strategie zurechtgelegt:

• Die ganze Seite kommt in ein Ober-Div (zentriert, fixe Breite - eventuell nicht 100% optimal, aber ich sehe derzeit keine wirkliche Alternative)
• Die einzelnen Blöcke (Menü, Titelbereich, Inhalt, Blog-Vorschaukasten, Bild-Kasten) kommen in divs, die relativ zum Ober-Div (vorerst - ich sehe auch hier keine wirkliche Alternative) pixelgenau positioniert werden
• Innerhalb dieser Divs versuche ich soweit irgendwie möglich und meinen Fähigkeiten entsprechend semantisches Markup zu verwenden.

mfG, Michael

[Gunnar Bittersmann]

Hello out there!

• Die ganze Seite kommt in ein Ober-Div

Wozu? Mit html und body hast du schon zwei Elemente, die alles andere umschließen.

fixe Breite - eventuell nicht 100% optimal,

Nein, das ist alles andere als optimal. Bei Nutzern mit breitem Viewport wird Platz verschenkt, Nutzer mit schmalem Viewport müssen horizontal scrollen.

aber ich sehe derzeit keine wirkliche Alternative)

Gar keine Breitenangabe?

Oder Aufteilung des Viewports in Bereiche mit Breitenangaben in %, ergänzt durch min-width und max-width in em.

• Die einzelnen Blöcke (Menü, Titelbereich, Inhalt, Blog-Vorschaukasten, Bild-Kasten) kommen in divs, die relativ zum Ober-Div (vorerst - ich sehe auch hier keine wirkliche Alternative) pixelgenau positioniert werden

Die Alternative – und zwar weitaus bessere – ist ein fließendes Layout. Du kennst die float-Eigenschaft?

See ya up the road,
Gunnar

[Michael]

Hi,

Hmmm...eigentlich hast du Recht. Aber du bringst mich jetzt auch in eine gewisse Verzweiflung ;-)

Ich habe das folgende Design: http://www.thinkcool.ch - grafisch gefällt es mir und von den meisten Benutzern erhielt ich ein positives Feedback. Einzig Detailkorrekturen am Menü wurden explizit vorgeschlagen. Ok, es war in diesem Fall kein 'Fachpublikum', aber anspruchsvolle, kritische Benutzer.

Nach Möglichkeit möchte ich an diesem Layout festhalten. Gründe:

• Ich finde die Aufteilung einer Seite in 4 Blocks (Titel, Menü, Inhalt, Zusatzinfos) sinnvoll.
• Die gewählte Anordnung finde ich passend - ausbalanciert, strukturiert, grafisch ansprechend.
• Als Titel ein Bild zu verwenden finde ich praktisch und sinnvoll, da man so eine gute Möglichkeit hat, der Seite grafisch einiges zu verpassen ohne komplizierte und grafisch schwierige 'Verzierungen' verteilt über die Seite einbauen zu müssen. Zudem ist ein Bild flexibler und 'schöner' als HTML-Programmierte Bereiche. Kurz: Es ist einfach und es wirkt.
• Ich bin kein Grafiker und tue mich daher ziemlich schwer beim Entwerfen neuer Layouts. Das jetztige Layout war wieder ein ziemlicher Kampf, obwohl mir das Resultat eigentlich gefällt. Daher möchte ich nicht schon wieder ein Wochenende mit rauchendem Kopf und gequälten Augen hinter einem neuen Layout verbringen.

Wie könnte man das aktuelle Layout prinzipiell am besten neu umsetzen? Oder trotz allem ein neues entwerfen?

Gruss

Michael