Layout (Grids)
Elmar
solange der umschließende Container nicht breiter ist als das
Darstellungsfenster im Browser. Zum Lesen am Bildschirm ist
mehrspaltiger Text unergonomisch, wenn die Spalten so lang sind, dass
am Ende jeder Spalte wieder mehrmals nach oben geblättert werden muss
zum Lesen der folgenden Spalte.
Ein nicht schnell zu lösendes Problem wird bleiben, dass Ausgabegerät
(Bildschirm) und Darstellungsfläche (Webbrowser-Teilbereich) unbekannt
sind sowie die Umgebungsbedingungen (Lichteinfall,
Betrachtungsentfernung). Eigentlich wären viele Layouts nötig.
Abgesehen von diesen Problemen stelle ich mir die Trennung von Layout
und Semantik so vor, dass die Layoutbeschreibung komplett außerhalb
des Codes ist, d.h., es gibt keine divs. Alle Elemente haben eine ID
(<p id="abstract"></p><p id="definition"></p>) und in einer
Layoutdatei steht die Positionierung und Formatierung für jedes
Element ("abstract", "definition").
HTML ist nicht geeignet für komplexe Semantik, es kann nicht erweitert
werden. Ich frage mich z.B. schon lange, weshalb Bildern keine
Beschreibung zugeordnet wurde (*nicht* alt oder longdesc) oder
Überschriften keine verbindliche Hierarchie.
Vergleiche ich Webseiten von 1995 mit den heutigen, halte ich CSS für
einen wichtigen Fortschritt. Ich bin der Meinung, dass gutes und
individuelles Layout nicht nur angenehm ist, sondern auch Inhalte
besser erfassen lässt. Deshalb ist jede genauere Layoutkontrolle
(Grid) zu begrüßen.
Stefan Münz
> Floats haben den Vorteil, dass nicht horizontal gescrollt werden muss,
> solange der umschließende Container nicht breiter ist als das
> Darstellungsfenster im Browser.
Das ist bei Grids nicht anders, solange die Summe der Grid-
Spaltenbreiten nicht mehr als 100% beträgt. Grids bedeuten ja nicht,
dass man auf relative Breitenangagen verzichten muss.
> Zum Lesen am Bildschirm ist
> mehrspaltiger Text unergonomisch, wenn die Spalten so lang sind, dass
> am Ende jeder Spalte wieder mehrmals nach oben geblättert werden muss
> zum Lesen der folgenden Spalte.
Da gebe ich dir Recht. Man muss wohl auch begrifflich unterscheiden
zwischen "mehrspaltigen Layouts" und "mehrspaltigem Textfluss". Mit
einem mehrspaltigen Layout ist normalerweise gemeint, dass man
verschiedene, nebeneinander angeordnete Bereiche hat für Navigation,
Hauptinhalt und vielleicht noch andere Inhalte. Mehrspaltiger
Textfluss wird so umgebrochen, dass sich ein Fließtext einigermaßen
gleichmäßig auf mehrere Spalten verteilt. Wo dann genau die
Spaltenumbrüche liegen, bestimmt die berechnende Software (in dem Fall
der Browser).
Übrigens konnte man schon 1996 zwischen beiden Formen wählen. Damals
gab es nämlich bereits Beides: mehrspaltige Layouts wurden mit
Tabellen gemacht, und für mehrspaltige Layouts kannte zumindest
Netscape 3, der bei den Browsern damals ungefähr so marktbeherrschend
war wie heute Google bei den Suchmaschinen, spezielle, proprietäre
HTML-Tags, die aber wunderbar funktionierten. Trotzdem benutzte kaum
jemand diese Tags, denn was die Leute wollten, war eigentlich kein
mehrspaltiger Textfluss, sondern eben mehrere, sauber getrennte,
nebeneinander angeordnete Bereiche. Deshalb griffen damals alle zu
Tabellen, weil es nichts anderes gab, wodurch das realisierbar gewesen
wäre.
> Ein nicht schnell zu lösendes Problem wird bleiben, dass Ausgabegerät
> (Bildschirm) und Darstellungsfläche (Webbrowser-Teilbereich) unbekannt
> sind sowie die Umgebungsbedingungen (Lichteinfall,
> Betrachtungsentfernung). Eigentlich wären viele Layouts nötig.
Das ist ja schon jetzt so, und wer was auf sich hält, definiert
unterschiedliche Layouts für unterschiedliche Ausgabemedien. Das
funktioniert bei den heutigen Clients ja schon leidlich. Die neuen
Möglichkeiten von CSS 3 werden daran sicher nichts ändern.
> Abgesehen von diesen Problemen stelle ich mir die Trennung von Layout
> und Semantik so vor, dass die Layoutbeschreibung komplett außerhalb
> des Codes ist, d.h., es gibt keine divs. Alle Elemente haben eine ID
> (<p id="abstract"></p><p id="definition"></p>) und in einer
> Layoutdatei steht die Positionierung und Formatierung für jedes
> Element ("abstract", "definition").
Den semantischen Riesenunterschied zwischen <div id="abstract"> und <p
id="abstract"> musst du mir aber erst mal erklären. Lass dich da bitte
nicht kirre machen von der Anti-div-Fraktion. In beiden Fällen (<div
id="abstract"> und <p id="abstract">) hast du eine für den Menschen
nachvollziehbare Semantik, und in beiden Fällen hast du für die
verarbeitende Software rein gar nichts Semantisches, außer p bzw. div.
Denn der Browser weiß nicht, was du mit "abstract" meinst - für ihn
ist da einfach nur ein Bezeichner, mit dem er zufrieden ist, solange
er dokumentweit eindeutig ist.
Für mehr Semantik auf Software-Seite braucht man mehr
bedeutungstragende Sprachelemente. Frei wählbare Bezeichner können
diese Aufgabe nicht leisten. HTML 5 geht ja genau diesen Weg. Da
werden herzhaft fröhlich neue Elemente eingeführt, eben um mehr
_software-seitig erkennbare_ semantische Sprachbestandteile zu haben.
Das gleiche Ziel verfolgen auf Sublevel-Ebene die Mikroformate.
> HTML ist nicht geeignet für komplexe Semantik, es kann nicht erweitert
> werden. Ich frage mich z.B. schon lange, weshalb Bildern keine
> Beschreibung zugeordnet wurde (*nicht* alt oder longdesc) oder
> Überschriften keine verbindliche Hierarchie.
HTML 5 wird genau dafür das <figure>-Tag einführen. Innerhalb von
<figure>...</figure> kann eine Grafik nebst Überschrift, Unterschrift,
Erklärung usw. notiert werden. Wie gesagt - man hat endlich kapiert,
dass HTML nicht keine höheren Normalisierungsniveaus braucht (wie
XHTML 2 das verfolgt, etwa mit der Universalisierung von Attributen
wie href), sondern mehr maschinenlesbare Semantik.
viele Grüße
Stefan Münz
Stefan Münz
ich wollte noch kurz nachreichen, dass dieser Thread sich auf ein
Blogposting bezieht:
http://webkompetenz.blogspot.com/2007/09/floating-divs-war-20-grids-sind-30.html
Denn es soll ja Leute geben, die nur hier lesen, nicht aber im
Blog ;-)
viele Grüße
Stefan Münz
Elmar
Hallo Stefan,
> Den semantischen Riesenunterschied zwischen <div id="abstract"> und <p
> id="abstract"> musst du mir aber erst mal erklären.
Semantisch gibt es keinen (wichtigen) Unterschied, ich meinte den
nichtsemantischen Gebrauch: So weit ich weiß, lässt sich p nicht
verschachteln, d.h., nicht dazu benutzen, im aktuellen CSS fehlende
Gestaltungsmöglichkeiten so zu erzielen, wie mit verschachtelten divs,
z.B. mehrere Hintergrundgrafiken oder "runde Ecken". Diese divs gibt
es nur der Gestaltung wegen und nicht zur Strukturierung des Inhalts
(ist die Gestaltung nicht auch ein Teil des Inhalts? Unwichtig ist sie
nicht.).
Grüße
Elmar
Stefan Münz
> Semantisch gibt es keinen (wichtigen) Unterschied, ich meinte den
> nichtsemantischen Gebrauch: So weit ich weiß, lässt sich p nicht
> verschachteln, d.h., nicht dazu benutzen, im aktuellen CSS fehlende
> Gestaltungsmöglichkeiten so zu erzielen, wie mit verschachtelten divs,
> z.B. mehrere Hintergrundgrafiken oder "runde Ecken". Diese divs gibt
> es nur der Gestaltung wegen und nicht zur Strukturierung des Inhalts
> (ist die Gestaltung nicht auch ein Teil des Inhalts? Unwichtig ist sie
> nicht.).
OK, das mit den runden Ecken verstehe ich. Das ist in der Tat ein
Beispiel dafür, wie auch heute noch Markup missbraucht wird, um
bestimmte optische Effekte zu erzielen, die gerade "in" sind. Aber ist
es wirklich den Webdesignern anzulasten, wenn die Not sie auch mal
erfinderisch und zu Tagsoup-Sündern werden lässt? Runde Ecken,
Schatteneffekte, Halbtransparenz usw. - all das sind nun mal beliebte
optische Effekte. CSS sollte mit seinen 11 Jahren, die es mittlerweile
auf dem Buckel hat, eigentlich längst weit genug sein, um das alles
adäquat zu unterstützen. Aber mit CSS 3 wird es wohl auch 2022 ...
damit beziehe ich mich auf eine nette Aussage, die ich neulich auf
http://wiki.whatwg.org/wiki/FAQ#When_will_HTML_5_be_finished.3F
gelesen habe:
"It is estimated that HTML5 will reach a W3C recommendation in the
year 2022 or later. This will be approximately 18-20 years of
development, since beginning in mid-2004."
Böse böse Worte, aber leider nicht ganz unberechtigt.
viele Grüße
Stefan Münz
konnexus
was haltet ihr davon, wenn man im html semantische einheiten mit "div"
zusammenfasst und mit "class=" auszeichnet, und sonst alle "p" und "h"
+ "class=" auszeichnet.
und wenn's dann um layout-formatierung geht, bei der u.u. mehr divs
und andere tags benötigt werden, werden sie per javascript (z.b.
jquery) dazugeschrieben.
bei einem projekt habe ich das mal ausprobiert:
http://konnexus.de/vs
was sagt ihr?
grüße, Konstantin Weiss
Niels Braczek
Dann kannst du genausogut auf die zusätzlichen DIVs verzichte. Mozilla
kann nämlich abgerundete Ecken. Und wenn du schon Benutzer ausschließen
willst, dann bitte nicht die, die sich korrekt verhalten (JavaScript nur
dann aktivieren, wenn es *ihnen* nützt), sondern die, denen eh alles
egal ist (die den IE benutzen).
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
konnexus
> willst, dann bitte nicht die, die sich korrekt verhalten (JavaScript nur
> dann aktivieren, wenn es *ihnen* nützt), sondern die, denen eh alles
> egal ist (die den IE benutzen).
hallo Niels,
kannst du kurz erklären was genau du mit "ausschließen" und mit "wenn
es ihnen nutzt" meinst?
vielleich noch dazu: die site ist nicht kompatibel mit allen browsern
aus meinem unvermögen heraus für alle browser zu programmieren. da sie
im studentischen rahmen entstand, war mir nicht wichtig das für IE zu
ende zu führen.
besten gruß, Konstantin
Stefan Münz
> was haltet ihr davon, wenn man im html semantische einheiten mit "div"
> zusammenfasst und mit "class=" auszeichnet, und sonst alle "p" und "h"
> + "class=" auszeichnet.
Es spricht nichts dagegen - aber es ist halt nur "semantisch" für
Menschen, denen die gewählten class-Namen etwas sagen, und die im HTML-
Quelltext nach semantischen Zusatzinformationen suchen ;-)
Dem Browser ist das alles egal. Er bekommt semantische Hausmannskost
(aha, ein div-Bereich, aha, eine Überschrift, aha, ein Textabsatz).
Damit kann er ganz gut leben, und die Site-Besucher können es auch.
Mehr maschinenlesbare Semantik, wie sie mit HTML 5 kommen soll, bringt
halt einige zusätzliche software-seitig verwertbare Informationen mit
ins Spiel. So gibt es dort beispielsweise auch ein article-Element.
Ein Suchrobot kann dann bei korrekter Anwendung im HTML-Code eines
Blogs die einzelnen Artikel erkennen. Auch ein Browser könnte sich das
zunutze machen und z.B. in einem Menü alle Artikel der Seite
auflisten.
> und wenn's dann um layout-formatierung geht, bei der u.u. mehr divs
> und andere tags benötigt werden, werden sie per javascript (z.b.
> jquery) dazugeschrieben.
Die Tagsoup steht also nicht gleich im Quelltext, sondern wird erst im
Arbeitsspeicher generiert. Ja, das wurde immer schon gern so gemacht -
invalides HTML einfach mit document.write in JavaScript schreiben, und
der HTML-Vali ist zufrieden. Aber sei vorsichtig, gerade viele böse
Kritiker haben die Webdeveloper-Extension für Firefox installiert, und
die erlaubt unter anderem, sich den aktuell _generierten_ Quelltext
einer Seite anzusehen.
Was beispielsweise runde Ecken betrifft, so halte ich es bei eigenen
Seiten auch lieber so, wie Niels es vorgeschlagen hat: einfach die
entsprechenden proprietären Mozilla- oder sonstigen CSS-Eigenschaften
verwenden, und wenn jemand einen anderen Browser benutzt und die
runden Ecken nicht sieht, geht die Welt auch nicht unter. Schwieriger
ist es nur, wenn es um Kundenauftragsarbeiten geht und der Kunde das
in allen Browsern gleich haben will.
viele Grüße
Stefan Münz
Niels Braczek
> kannst du kurz erklären was genau du mit "ausschließen" und mit "wenn
> es ihnen nutzt" meinst?
Du kannst nicht voraussetzen, dass JavaScript zur Verfügung steht. In
den Statistiken wird zwar eine sehr hohe Nutzungsquote angegeben, was
aber daran liegt, dass diese Statistik meist mithilfe von JavaScript
ermittelt wird. Bei verantwortlicher Nutzung (hier: Maximierung der
Sicherheit) ist JavaScript abgeschaltet und wird nur aktiviert, wenn es
dem Nutzer einen Vorteil bringt (zB. in der Administration eines CMS).
> vielleich noch dazu: die site ist nicht kompatibel mit allen browsern
> aus meinem unvermögen heraus für alle browser zu programmieren. da sie
> im studentischen rahmen entstand, war mir nicht wichtig das für IE zu
> ende zu führen.
Das ist für mich auch in Ordnung; das Web wäre viel schöner, wenn man
nicht immer nach Work-arounds für die Fehler Microsofts suchen müsste.