frames oder tabellen?

[Melanie]

hallo,

hätte eine frage an die mehr-als-ich-htmler: verwende ihr für die gestaltung eurer seite tabellen oder frames?

ich habe vor, auf der seite oben quer eine überschrift und links einen Navigationsbereich zu setzen, die sich nicht ändern.
der inhalt wird dann praktisch im restlichen bereich angezeigt.

ich weiß bloß nicht, ob ich mich für tabellen oder frames entscheiden soll. hab im selfhtml nachgelesen, dass tabellen länger zu laden brauchen, wenn die tabellengröße nicht vorher angegeben wird. das ist blöd, weil ich die mit %angaben veränderbar halten möchte.
frames kann halt scheinbar nich jeder browser anzeigen. dann ist die ersatznavigation natürlich blöd zu handhaben.

was tun? wie macht ihrs und warum?

danke im voraus
mfg, melanie

[Tobias]

Hallo,

frames kann halt scheinbar nich jeder browser anzeigen. dann ist die ersatznavigation natürlich blöd zu handhaben.

Also das ist inzwischen irrelvant geworden. Eigentlich beherschen alle Browser, die genutzt werden, inzwischen diese Möglichkeit. Es sei denn du willst hundertprozent Barrierefreie Seite erstellen, dann musst du auf Frames verzichten.

Ich verzichte inzwishcen auf Frames und mach das ganze mit Tabellen und ein bischen Php.

Allerdings solltest du auch mal im Archiv nach gucken. es gab bisher schon ne Menge Threads dazu.

Tschau

Tobias

[Melanie]

Danke für die schnelle antwort.

Allerdings solltest du auch mal im Archiv nach gucken. es gab bisher schon ne Menge Threads dazu.

ich hab eigentlich ins archiv geschaut, da aber nix passendes gefunden (habe tabelle frame eingeben)

wenn du alles mit tabellen und php machst - legst du dann vorher die breite der tabellen fest oder sind die langen ladezeiten nicht so problematisch ? (ich hab dsl und kanns deshalb nicht nachvollziehen, ob meine seite langsam oder schnell ist)

mfg
melanie

[Tobias]

Hallo,

wenn du alles mit tabellen und php machst - legst du dann vorher die breite der tabellen fest oder sind die langen ladezeiten nicht so problematisch ? (ich hab dsl und kanns deshalb nicht nachvollziehen, ob meine seite langsam oder schnell ist)

Die breite und höhe gebe ich mit % an, damit ich nicht Probleme kriege wenn der Anwender ne andere Auflösung hat.

Ich Denke bei solch recht einfachen Tabellenkonstruktionen ist die längere Ladezeit nicht wirklich messbar. Problematisch wird wahrscheinlich erst wenn du mehere Tabellen verwendest, die wiederum tabellen enthalten.

Tschau

Tobias

[Heiner]

Hallo,

Probleme von Frames sind, dass die Seiten einzeln in Suchmaschinen gelistet werden, Du aber nicht durch einen Klick von dort zum Frameset kommst. Das macht Frames zu einer unsauberen Sache.

Tabellen empfinde ich als besser, gerade wenn sie dynamisch erzeugt werden. Statt Tabellen kannst Du noch besser div-Elemente verwenden, die Du ähnlich wie Tabellen einsetzt. Das ist das sauberste, weil Tabellen eigentlich nur zum Darstellen von tabellarischen Inhalten (z. B. Bundesligatabelle) gedacht sind, Du sie sonst aber misbrauchst.

Es gibt sicher aber auch einzelne Anwendungen, in denen Frames seine Berechtigung haben mögen. Meines Erachtens sind das aber Ausnahmen.

Grüße,
Heiner

[Tim Tepaße]

Hallo Heiner,

Statt Tabellen kannst Du noch besser div-Elemente verwenden, die Du ähnlich
wie Tabellen einsetzt. Das ist das sauberste, (..)

Nö. Das sauberste ist es, die Inhalte mit den HTML-Elementen auszuzeichnen,
die dem Inhalt am besten wiedergeben und das div-Element, das ja keine
Zusatzinformationen hat, nur in Notfällen zu verwenden. ;-)

Und dann erst kommt die Gestaltung der Seite, für mich ist das bitte
CSS. Ich komme damit gedanklich am besten klar; mit Tabellen oder gar
Frames rumzumurksen ist mir inzwischen ein Graus.

Tim

[at]

Hallo.

Nö. Das sauberste ist es, die Inhalte mit den HTML-Elementen auszuzeichnen,
die dem Inhalt am besten wiedergeben und das div-Element, das ja keine
Zusatzinformationen hat, nur in Notfällen zu verwenden. ;-)

Eine Einschränkung sollte man aber machen: <div>s sind nicht nur dafür geeignet, sondern sogar dafür gedacht, zusammenhängende Elemente zusammenzufassen, um etwa die Navigation vom gesamten Inhalt zu trennen.
MfG, at

[Tim Tepaße]

Hallo at,

Eine Einschränkung sollte man aber machen: <div>s sind nicht nur dafür
geeignet, sondern sogar dafür gedacht, zusammenhängende Elemente
zusammenzufassen, um etwa die Navigation vom gesamten Inhalt zu trennen.

Wo habe ich das bestritten?

Tim

[at]

Hallo.

Wo habe ich das bestritten?

Nirgends, weshalb ich das ja auch nicht behauptet hatte. Du hattest es lediglich nicht erwähnt, weswegen ich es ergänzt habe.
MfG, at

[Melanie]

hallo zurück,

ich finde frames aber halt auch praktisch, weil ich die navigation immer im blick habe und nicht mit nach oben scrolle, wenn die inhalte mal bissle länger sind.

das nervt mich eigentlich an tabellen-basierten seiten als surfer schon manchmal...

[benni]

Weder Noch - CSS ist dein Freund ;-).

viele grüße,
benni

[Melanie]

hallo,

Weder Noch - CSS ist dein Freund ;-).

ich benutze css sehr ausgiebig, habs aber halt immer so gemacht, dass ich als header eine <p> hab und das per css an die richtige stelle setzt.
auch die navigation links war immer im <p>.
dann hab ich als inhaltsfenster ein <iframe>, auch mit css an den richtigen ort gesetzt.

vielleicht stell ich mich ja blöd an, aber ich hab die links immer so gemacht, dass der inhalt dann im frame geöffnet wurde.
<a .... target="frame"> und dann hat alles gefunzt.

kann ich als target auch ein anderes tag nehmen? keine ahnung. experimentiere grad mit php, aber stecke noch in den baby-schuhen.

danke,
melanie

[Tim Tepaße]

Hallo Melanie,

ich benutze css sehr ausgiebig, habs aber halt immer so gemacht, dass ich
als header eine <p> hab und das per css an die richtige stelle setzt.

Äh. Wieso hast Du nicht die dafür vorgesehen Elemente h1 bis h6 genommen?

Tim

[Melanie]

Äh. Wieso hast Du nicht die dafür vorgesehen Elemente h1 bis h6 genommen?

ich hab ja nicht gesagt, dass ich alles kann, aber für meine belange reichts meistens. ich dachte eigentlich, das headline für eine überschrift (z.b. das verhalten von murmeltieren) da ist. ich setzt als überschrift aber ein gif rein, sieht schöner aus (find ich).

mfg
melanie

[Thomas Luethi]

Hallo,

ich dachte eigentlich, das headline für eine überschrift (z.b. das verhalten von murmeltieren) da ist. ich setzt als überschrift aber ein gif rein, sieht schöner aus (find ich).

Du hast schon richtig verstanden - h1 ist die Hauptueberschrift, h2 - h6 sind Zwischenueberschriften.

Und du kannst ruhig eine Grafik ins h1 packen
* wenn Dir die spezielle Schriftart so wichtig ist
* solange Du den Text auch als ALT-Text hinmachst
* wenn Dir das Suchmaschinen-Ranking egal ist.

Gruesse + gute Nacht,

Thomas

[Michael Jendryschik]

Hallo,

Und du kannst ruhig eine Grafik ins h1 packen [...]
* solange Du den Text auch als ALT-Text hinmachst
* wenn Dir das Suchmaschinen-Ranking egal ist.

Hast du Belege dafür, dass Suchmaschinen

<h1><img ... alt="Foo" /></h1>

geringer bewerten als

<h1>Foo</h1>

?

Gruß,

MI

[Thomas Luethi]

Hallo,

Hast du Belege dafür, dass Suchmaschinen
  <h1><img ... alt="Foo" /></h1>
geringer bewerten als
  <h1>Foo</h1>

Nein.
Es ist blosse Spekulation meinerseits, basierend auf folgendem:
a) Falls Suchmaschinen den ALT-Text fuer's Ranking (nicht bloss
   fuer die Indizierung) benuetzen wuerden, wuerden die Leute doch
   gleich anfangen, saemtliche Keywords in den ALT-Text
   von 1x1-Pixel-Blind-GIFs zwischen H1-Tags zu packen.
   Und Suchmaschinen moegen es nicht, wenn man sie betruegt.
   Also vermute ich, dass sie es gleich sein lassen.
b) Ich denke, dass Klaus Schallhorn nicht bloss spekuliert,
   sondern dass seine Aussagen auf Tatsachen beruhen.
   http://www.kso.co.uk/glossar/ALT-Parameter.html

Du hast natuerlich recht - man muesste Testreihen machen
mit entsprechenden Seiten und schauen, wie die
Suchmaschinen sie bewerten.
Aber wer hat schon Zeit fuer sowas?

Freundliche Gruesse,

Thomas

[molily]

Hallo,

Ich denke, dass Klaus Schallhorn nicht bloss spekuliert, sondern dass seine Aussagen auf Tatsachen beruhen.
http://www.kso.co.uk/glossar/ALT-Parameter.html

Tja, auf meinen Seiten bestätigt sich, dass Google das alt-Attribut ignoriert:

http://www.reichenbach-gymnasium.de/eltern.php
http://www.google.at/search?ie=UTF-8&q=site%3Areichenbach-gymnasium.de+sch�lerexperimentiermaterial (im Fließtext)
http://www.google.at/search?ie=UTF-8&q=site%3Areichenbach-gymnasium.de+kohleförderturm (im alt-Attribut)
http://www.google.at/search?q=site%3Areichenbach-gymnasium.de+kohle+beifall (Snippet, alt-Attribut kommt nicht vor)

http://home.t-online.de/home/dj5nu/sterne-biografie.html
http://www.google.at/search?q=subpopkultur+site%3Ahome.t-online.de (im Fließtext)
http://www.google.at/search?q=subpopkultur+mitglieder+site%3Ahome.t-online.de (im Fließtext bzw. alt-Attribut)
http://www.google.at/search?q=leich+webarchiv+site%3Ahome.t-online.de
 (Snippet, alt-Attribut kommt nicht vor)

http://home.t-online.de/home/dj5nu/sterne-tourtermine.html
http://www.google.at/search?q=kulturlounge+site%3Ahome.t-online.de (im Fließtext)
http://www.google.at/search?q=kulturlounge+deutschland+site%3Ahome.t-online.de (im Fließtext bzw. alt-Attribut, alt-Attribut kommt nicht im Snippet vor)

Jetzt erkläre mir, was du richtig machst und ich falsch...
http://www.tiptom.ch/gratis/nojsmenu.html
http://www.google.at/search?ie=UTF-8q=nachrüsten+site%3Awww.tiptom.ch
Stolpert Google über <img /> anstatt <img>? Auf anderen XHTML-Seiten geht es (beispielsweise http://www.google.at/search?ie=UTF-8q=site%3Awww.jendryschik.de+deutschland). Ich mache mal einige Tests. Die genannte Sterne-Seite verwendet übrigens <h1><img alt="Die Sterne" /></h1>.

Mathias

[molily]

Linkkorrektur:

http://www.google.at/search?ie=UTF-8&q=site%3Areichenbach-gymnasium.de+sch%FClerexperimentiermaterial (im Fließtext)

Falsche Input Encoding-Angabe, das war ISO-8859-1, in UTF-8 wäre es:
http://www.google.at/search?ie=UTF-8&q=site%3Areichenbach-gymnasium.de+schülerexperimentiermaterial

http://www.google.at/search?ie=UTF-8q=nachr%C3%BCsten+site%3Awww.tiptom.ch

»&« vergessen, das sollte natürlich heißen:
http://www.google.at/search?ie=UTF-8&q=nachrüsten+site%3Awww.tiptom.ch

...

M.

[Thomas Luethi]

Hallo,

Tja, auf meinen Seiten bestätigt sich, dass Google das alt-Attribut ignoriert:

Manchmal...

Jetzt erkläre mir, was du richtig machst und ich falsch...
http://www.tiptom.ch/gratis/nojsmenu.html

Huch, meine Jugensuende. Dies ist der Fallback fuer's JavaScript-Menue im Frameset.
Und ich missbrauche dort den ALT-Text wegen dem Tooltip-Effekt...
(Das Redesign dieses Bereichs steht hoch oben auf meiner "ToDo"-Liste...)

http://www.google.at/search?ie=UTF-8&q=nachrüsten+site%3Awww.tiptom.ch

Offenbar reicht der ALT-Text für die Indizierung.

Stolpert Google über <img /> anstatt <img>?

Keine Ahnung. Google hat mich lieb;-)

http://www.google.com/search?q=theremin+kilcher+site%3Atiptom.ch
gibt als einziges Resultat
http://www.tiptom.ch/album/keramik/fest.html
Das Wort "Theremin" kommt im sichtbaren Text und in einem ALT-Text vor,
"Kilcher" nur in einem ALT-Text.
Google zeigt die ALT-Texte im Snippet an.

[http://www.google.com/search?q=dessertbuffet+kilcher+montanato]
gibt das gleiche Resultat.
Alle drei Worte kommen nur im ALT-Text vor, Google zeigt die ALT-Texte
der Thumbnails als Snippets an.

Deshalb wusste ich, dass die ALT-Texte bei Google fuer die
_Indizierung_ eine Rolle spielen. Meine Frage ist mehr, ob
sie fuer das _Ranking_ eine Rolle spielen.

Auf anderen XHTML-Seiten geht es (beispielsweise http://www.google.com/search?q=deutschland+site%3Awww.jendryschik.de).

Eine moegliche Erklaerung:
Die betreffenden Bilder bei mir und MI sind verlinkt. Vielleicht macht das etwas aus?
Zurst dachte ich, dass die betreffenden Woerter auf den Ziel-Seiten
auch im normalen, sichtbaren Text  bzw. im TITLE-Element vorkommen,
aber "nachruesten" kommt bei mir dort
( http://www.tiptom.ch/gratis/win95vorb.html )
nirgends vor.

Ich mache mal einige Tests. Die genannte Sterne-Seite verwendet übrigens <h1><img alt="Die Sterne" /></h1>.

Fraglich ist eben, ob es das Ranking erhoeht.
Man muesste wohl zwei - sonst identische - Seiten haben, die sich
dadurch unterscheiden, dass in der einen Dein obiges Konstrukt
steht, in der andern nur <p><img alt="Die Sterne"></p>

Gruesse,

Thomas

[molily]

Hallo Michael,

Hast du Belege dafür, dass Suchmaschinen

<h1><img ... alt="Foo" /></h1>

geringer bewerten als

<h1>Foo</h1>

?

Meinen Tests zufolge (siehe auch meine anderen Postings im Thread) ignoriert Google alt-Attribute von nicht von einem Link umschlossenen Grafiken komplett. Das heißt, <h1><img ... alt="Foo"></h1> entspricht im Hinblick auf Google <h1></h1>.

http://home.t-online.de/home/dj5nu/
http://www.google.at/search?q=cache:home.t-online.de%2Fhome%2Fdj5nu%2F
http://www.google.at/search?q=yuppieschuhglanz
http://www.google.at/search?q=youspoafoa (siehe auch Snippet...)

http://home.t-online.de/home/dj5nu/sterne.html
http://www.google.at/search?q=cache:home.t-online.de%2Fhome%2Fdj5nu%2Fsterne.html
http://www.google.at/search?q=moahoudrou

Das ist übrigens der Grund, warum viele das sogenannte Fahrner Image Replacement beziehungsweise ähnliche Techniken einsetzen.

Ich werde die Sterne-Seite umstellen, sodass Google das h1-Element nicht gänzlich ignoriert.

Mathias

[Thomas Luethi]

Hallo,

hätte eine frage an die mehr-als-ich-htmler: verwende ihr für die gestaltung eurer seite tabellen oder frames?

Weder noch;-)

Frames solltest Du wirklich nicht mehr verwenden.
Du machst Dir, den Benutzern und den Suchmaschinen nur das Leben schwer.
Ein paar Argumente: http://www.subotnik.net/html/frames.html

Die Frage (die manche hier gerne heiss diskutieren) ist vielmehr:
Tabellen-Layout oder CSS-Layout?

Beides hat seine Vor- und Nachteile.

ich habe vor, auf der seite oben quer eine überschrift und links einen Navigationsbereich zu setzen, die sich nicht ändern.
der inhalt wird dann praktisch im restlichen bereich angezeigt.

Mit _einer_ Layout-Tabelle geht das ganz bequem.

<h1>Ueberschrift</h1>
<table>
<tr>
  <td> <!-- Navigation --> </td>
  <td> <!-- Inhalt --> </td>
</tr>
</table>

Das ist einfach umzusetzen und wird von den grafischen Browsern
sehr zuverlaessig so dargestellt, wie Du es moechtest, ohne
Ueberlagerungen, ohne boese Ueberraschungen. Es ist zudem
auch recht flexibel, d.h. es passt sich der Fenstergroesse gut an.
Ein Nachteil ergibt sich vor allem fuer Blinde Benutzer, denen
die Webseiten von speziellen Programmen vorgelesen werden.

Wenn Du Deine Seiten auch fuer Behinderte gut zugaenglich
machen moechtest, kannst Du versuchen, auch ohne
Tabellen auszukommen, und alles nur mit CSS zu formatieren.
Meist packt man dann die Inhalte in <DIV>-Elemente,
damit man sie besser plazieren und formatieren kann:

<h1>Ueberschrift</h1>
<div id="navi"> <!-- Navigation --> </div>
<div id="inhalt"> <!-- Inhalt --> </div>

Vorteil: Bessere Zugaenglichkeit fuer Behinderte.
Nachteile fuer Dich:
* Du musst CSS lernen. OK, ist nicht unbedingt ein
  Nachteil, sondern macht auch Spass;-)
  Dabei hilft Dir z.B. http://selfhtml.teamone.de/css/
  Vorbilder fuer mehrspaltige Layouts: http://glish.com/css/
* Du musst es stundenlang in allen moeglichen Browsern
  ausprobieren und musst damit leben, dass viele Browser
  sehr eigene Vorstellungen von CSS haben
  oder ueberhaupt nicht damit klarkommen.
* Es kann boese Ueberraschungen geben, d.h.
  die Seite kann in gewissen (alten, kaputten) Browsern
  unbenutzbar sein. Davor kannst Du Dich etwas
  schuetzen, indem Du das CSS vor diesen Browsern
  versteckst:
  http://w3development.de/css/hide_css_from_browsers/

Da Du offenbar ganz "neu" bist, rate ich Dir, zuerst mal
mit Layouttabellen zu arbeiten. Natuerlich kannst Du
auch dort CSS einsetzen, z.B. fuer Vorder- und Hintergrund-
Farben, Raender, Rahmen, Abstaende, Schriftgroessen u.s.w.

Lass CENTER- und FONT-Tags, BGCOLOR-Attribute weg,
nimm stattdessen von Anfang an CSS.

Freundliche Gruesse,

Thomas

[Melanie]

bin ehrlich gesagt nicht ganz neu, hab schon 4-5 homepages programmiert, aber immer mit frames. mit css kenn ich mich- denk ich - recht akzeptabel aus.
aber ich fang grad wieder was neues an und bin irgendwie unzufrieden. weiß net so richtig, wie ich das etz anfangen soll.

mfg,
melanie

[molily]

Hallo, Thomas,

Frames solltest Du wirklich nicht mehr verwenden.
Du machst Dir, den Benutzern und den Suchmaschinen nur das Leben schwer.

Heutzutage ist dieses »Argument« rein formal relevant, nicht mehr praktisch. Mittlerweile ist es nur noch eine Urban Legend, dass irgendwo da draußen(tm) Suchmaschinen existieren, welche nach fünf Jahren Frames immer noch nicht hinreichend verstehen. Dabei sind die meisten Framesets selbst ohne passende noframes-Inhalte problemlos crawlbar. Es treten lediglich beachtenswerte indirekte Folgeprobleme auf - Benutzer findet eine Unterseite über Suchmaschinen, die schlechte Verlinkbarkeit wirkt sich eventuell auf den PageRank aus usw. Voraussetzung jeder Frame-Verwendung ist natürlich sowieso die Reduzierbarkeit auf eine framelose Navigation, sofern das beachtet wird, fallen die gängigen Probleme mit Suchmaschinen weg.

[Tabellenlayout]
Ein Nachteil ergibt sich vor allem fuer Blinde Benutzer, denen die Webseiten von speziellen Programmen vorgelesen werden.

Warum, worin besteht dieser Nachteil? Es ist höchstens ein Ärgernis, wenn der Screenreader eine Layouttabelle als Datentabelle erkennt, davon abgesehen sind Layouttabellen unter Beachtung einiger Grundregeln, welche auch in den WCAG genannt werden, diesbezüglich kein großes Übel.

Wenn Du Deine Seiten auch fuer Behinderte gut zugaenglich machen moechtest, kannst Du versuchen, auch ohne Tabellen auszukommen, und alles nur mit CSS zu formatieren. [...]

Das ist eine Urban Legend, Tabellenlayouts sind nicht per se problematisch hinsichtlich Barrierefreiheit. Man kann höchstens damit argumentieren, dass CSS-Layout letztlich anpassungsfähiger ist, da es sich im kritischen Falle benutzerseitig einfacher abschalten beziehungsweise manipulieren lässt. Spaltenlayout mittels Tabellen hingegen geht von einer x-fachen Anzeigebreite aus, als zur Textanzeige minimalst nötig. Allerdings lassen sich auch - als letztes Mittel - Tabellen mittels Benutzerstylesheets zwangslinearisieren...

Vorteil: Bessere Zugaenglichkeit fuer Behinderte.

Inwiefern?

Mathias

[Thomas Luethi]

Hallo Mathias,

Danke fuer die kritischen Erwiderungen auf meine pauschalen Aussagen.

Frames solltest Du wirklich nicht mehr verwenden.
Du machst Dir, den Benutzern und den Suchmaschinen nur das Leben schwer.
[...] Mittlerweile ist es nur noch eine Urban Legend, dass irgendwo da draußen(tm) Suchmaschinen existieren, welche nach fünf Jahren Frames immer noch nicht hinreichend verstehen.

OK, das war etwas etwas unsorgfaeltig/knapp formuliert.
Ich dachte vor allem an die Besucher, die ueber eine Suchmaschine
direkt auf eine Seite kommen, welche normalerweise in einem Frameset
angezeigt wird, und die deswegen den Kontext und die Navigation nicht haben.
(Was Du ja auch beschreibst.)
Es ist mir schon klar, dass die Suchmaschinen heutzutage Frames-Seiten
spidern und indizieren koennen.

[Tabellenlayout - Nachteil fuer blinde Benutzer mit Screenreader]
Warum, worin besteht dieser Nachteil? Es ist höchstens ein Ärgernis, wenn der Screenreader eine Layouttabelle als Datentabelle erkennt, davon abgesehen sind Layouttabellen unter Beachtung einiger Grundregeln, welche auch in den WCAG genannt werden, diesbezüglich kein großes Übel. [...]

Es waere interessant zu wissen, was die Betroffenen dazu sagen.
Du glaubst also, dass eine einfache (nicht verschachtelte) Layouttabelle,
Linke Spalte z.B. Navigation in Form einer UL-Liste, Rechte Spalte Inhalt,
bei entsprechender Anpassung (Summary-Attribute u.s.w.) heute auch
blinden Benutzern "zumutbar" ist?

Es freut mich, auch mal eine solche Meinung zu hoeren, und ich bin
gespannt auf weitere Stimmen.

[CSS-Layout behindertenfreundlicher als Tabellen-Layout]
[...] Man kann höchstens damit argumentieren, dass CSS-Layout letztlich anpassungsfähiger ist, da es sich im kritischen Falle benutzerseitig einfacher abschalten beziehungsweise manipulieren lässt.

Genau. Ich koennte mir vorstellen, dass Sehbehinderte durch Ausschalten
des Autoren-CSS und Anwendung eines eigenen Benutzerstylesheets
ein Dokument _ohne_ Layouttabelle besser nutzen koennen als eines
mit erzwungener Spalten-Darstellung mittels Tabelle.
Aber wie Du sagst, kann man ja mit CSS sogar Tabellen "linearisieren",
was meine Aussage natuerlich relativiert...

Kommt dazu, dass _Sehbehinderte_ es in der Praxis offenbar vorziehen,
"normal" gelayoutete Seiten in einem "normalen" Browser mit einer
"Bildschirmlupe" oder aehnlichem anzuschauen, anstatt einen speziellen
Text-Browser oder gar einen Screenreader anzuwenden.
(Ich glaube, das hat kuerzlich jemand hier gepostet.
Vielleicht meine ich Dein Posting
http://forum.de.selfhtml.org/archiv/2003/8/55949/#m313312
Man moege mich korrigieren bzw. den Link zum Posting ergaenzen.)

Bleibt also als einziges stichhaltiges Argument gegen Layout-Tabellen
die "reine Lehre", dass man Tabellen nur fuer tabellarische Daten brauchen
sollte? Und dass es in der HTML Specification steht? ;-)

Als ich das vordere Posting schrieb, waren irgendwo in
meinem Hinterkopf die folgenden Zeilen aus der
HTML 4.01 Spezification (1999):
http://www.w3.org/TR/html401/struct/tables.html#h-11.1
"Tables should not be used purely as a means
to layout document content as this may present
problems when rendering to non-visual media.
[...] To minimize these problems,
authors should use style sheets to control
layout rather than tables."

Gemaess Deiner Einschaetzung sind diese
"problems when rendering to non-visual media"
also Schnee von gestern?

Vorteil: Bessere Zugaenglichkeit fuer Behinderte.
Inwiefern?

Siehe oben - ich gehe davon aus, dass ein lineares Dokument
mit speziellen Programmen besser nutzbar ist.
Beruht aber auf Hoerensagen/Spekulation, und nicht auf Erfahrung.

---

Ein Argument, das sicher noch fuer CSS-Layouts (und gegen
Tabellen) spricht, ist, dass sich solche Seiten auf kleinen
Bildschirmen (Handhelds, Handys) besser anzeigen lassen,
und dass man sogar ein spezifisches Stylesheet fuer solche
Geraete anbieten koennte.

In der Hoffnung auf weitere Voten aendere ich mal das Subject
und setze die Kategorie auf "Barrierefreiheit".

Freundliche Gruesse,

Thomas

[Christian Seiler]

Hallo Thomas,

Ein Argument, das sicher noch fuer CSS-Layouts (und gegen
Tabellen) spricht, ist, dass sich solche Seiten auf kleinen
Bildschirmen (Handhelds, Handys) besser anzeigen lassen,
und dass man sogar ein spezifisches Stylesheet fuer solche
Geraete anbieten koennte.

Könnte ist der richtige Ausdruck.

</archiv/2002/11/30239/#m164960>

Viele Grüße,
Christian

[Thomas Luethi]

Hallo Christian,

... dass man fuer Handhelds/Handys ein spezifisches
Stylesheet fuer solche Geraete anbieten koennte.
Könnte ist der richtige Ausdruck.

Aargh!

</archiv/2002/11/30239/#m164960>

Danke fuer den Hinweis. Traurig, zu hoeren, dass
die Hersteller das tolle media="handheld" Konzept von CSS
bisher einfach links liegen lassen und stattdessen etwas
eigenes basteln...

mfg

Thomas

[Stefan]

Hallo Thomas

<h1>Ueberschrift</h1>
<div id="navi"> <!-- Navigation --> </div>
<div id="inhalt"> <!-- Inhalt --> </div>

Das heisst aber doch auch, dass die Navigation jedes Mal neu aufgebaut wird, auch wenn sie eigentlich immer die selbe ist, oder?
Und ich muss dann jeder Datei quasi im <div id="navi"> die Links mitgeben. Das kann doch bei einem Projekt mit sehr vielen Seiten sehr mühsam sein, oder?

Bis denn

Stefan

[Thomas Luethi]

Hallo,

Das heisst aber doch auch, dass die Navigation jedes Mal neu aufgebaut wird, auch wenn sie eigentlich immer die selbe ist, oder?

Ja. So what?
Das Ladezeiten-Maerchen ("Frames sparen Ladezeit") ist nonsens.

Und ich muss dann jeder Datei quasi im <div id="navi"> die Links mitgeben. Das kann doch bei einem Projekt mit sehr vielen Seiten sehr mühsam sein, oder?

Nicht, wenn Du es schlau anstellst.
Z.B. mit Includes (SSI, PHP, offline mit guten Editoren...)

Gruesse,

Thomas

[Stefan]

Ja. So what?
Das Ladezeiten-Maerchen ("Frames sparen Ladezeit") ist nonsens.

Wieso?
Wenn man immer die Navigation aufbauen muss läd man die Daten doch, beim Frame werden sie nur einmal gelesen.

Nicht, wenn Du es schlau anstellst.
Z.B. mit Includes (SSI, PHP, offline mit guten Editoren...)

Das heisst quasi die <div> im include aufbauen und dann nur noch einhängen?
An was für Editoren dachtest Du da?

[wahsaga]

hi,

Das Ladezeiten-Maerchen ("Frames sparen Ladezeit") ist nonsens.
Wieso?
Wenn man immer die Navigation aufbauen muss läd man die Daten doch, beim Frame werden sie nur einmal gelesen.

na und, dass bezieht sich auf ein paar hundert bytes reine textdaten.
wenn du umfangreiches javascript in deiner navigation verwendest, kannst du das ja extern auslagern,
und verwendete bilder wird ein browser sowieso cachen.

Nicht, wenn Du es schlau anstellst.
Z.B. mit Includes (SSI, PHP, offline mit guten Editoren...)
Das heisst quasi die <div> im include aufbauen und dann nur noch einhängen?
An was für Editoren dachtest Du da?

z.b. ulli meybohms "phase 5" beherrscht so etwas AFAIK.

gruss,
wahsaga

[Thomas Luethi]

Hallo,

Z.B. mit Includes (SSI, PHP, offline mit guten Editoren...)
Das heisst quasi die <div> im include aufbauen und dann nur noch einhängen?

Ja, der HTML-Baustein mit der Navigation ist in einer
eigenen Datei. Diese wird in allen anderen Dateien eingebaut.
Am bequemsten geht es serverseitig.
btw: Ein DIV drumrum ist nicht unbedingt notwendig.

An was für Editoren dachtest Du da?
z.b. ulli meybohms "phase 5" beherrscht so etwas AFAIK.

Genau.
Den Editor gibt's bei: http://www.qhaut.de/
Das Tutorial zu den Includes hier: http://tutorial.clairette.de/lektionen/include.html

Gruesse,

Thomas

[Stefan]

Hallo,

Am bequemsten geht es serverseitig.
btw: Ein DIV drumrum ist nicht unbedingt notwendig.

Serverseitig?

[Thomas Luethi]

Hallo,

Am bequemsten geht es serverseitig.
Serverseitig?

Ich meinte: Falls Du auf Deinem Webserver SSI oder PHP
anwenden kannst, ist es bequemer, eine dieser Technologien
zu verwenden, als z.B. die Offline-Includes von Phase 5
oder einem andern HTML-Editor.

Die Arbeits-Schritte, wenn es eine Aenderung der Navigation gibt:

Bei serverseitiger Loesung:
1. Aenderungen in der Datei (z.B. "navi.inc") machen.
2. Diese eine Datei hochladen.
Fertig.

Bei Offline-Include-Loesung:
1. Aenderungen in der Datei (z.B. "navi.inc") machen.
2. Mit dem Automatismus des HTML-Editors saemtliche
   Dateien aktualisieren, die das Include enthalten.
3. Alle diese Dateien hochladen.
Fertig.

Die Offline-Includes haben wiederum den Vorteil, dass die Seiten
lokal auf Deinem Rechner auch ohne Webserver genau so
aussehen, wie nachher, wenn sie auf dem Webserver sind.

Bei serverseitigen Includes siehst Du das Endresultat
eben nur, wenn es ueber einen Webserver an den Browser
gelangt. Das heisst, eventuell ist es nuetzlich,
lokal einen Webserver (am besten gleich mitsamt PHP)
zu installieren. Aus Sicherheitsgruenden solltest Du
den aber nur laufen lassen, wenn Dein Computer physisch
vom Netzwerk getrennt ist. Ausser Du weisst genau, was Du tust:-)

"Bequeme" Installationspakete (XAMPP - X=Windows oder Linux,
A=Apache, M=MySQL, P=PHP, P=Perl) zum lokalen Ausprobieren
gibt es bei den ApacheFriends:
http://www.apachefriends.org/
Wenn Dir das (fuer den Augenblick) zuviel Arbeit ist, lass es sein.
Eines Tages wirst Du vielleicht darauf zurueckkommen.

Ein paar einfuehrende Worte zu PHP und SSI findest Du auf meinen
Seiten unter http://www.tiptom.ch/tests/phpssi/

Wenn Du beides (PHP und SSI) zur Verfuegung hast, nimm PHP!
Dann hast Du spaeter viel mehr Moeglichkeiten.
Die Dateien duerfen ruhig Namen auf *.html haben;
einen anstaendigen Webserver (Apache) bringt man locker dazu,
auch in solchen Dateien PHP-Code auszufuehren:
http://www.tiptom.ch/tests/phpssi/server1.html

Gruesse,

Thomas

[Stefan]

Hallo,

Ich meinte: Falls Du auf Deinem Webserver SSI oder PHP
anwenden kannst, ist es bequemer, eine dieser Technologien
zu verwenden, als z.B. die Offline-Includes von Phase 5
oder einem andern HTML-Editor.

Ja, unterstützt mein Webspace.

Die Arbeits-Schritte, wenn es eine Aenderung der Navigation gibt:

Bei serverseitiger Loesung:

1. Aenderungen in der Datei (z.B. "navi.inc") machen.
2. Diese eine Datei hochladen.
   Fertig.

Und wie könnte dann eine solche navi.inc ausschauen?
Arbeitet man dort auch mit <html><body> usw. und wird nur der Text oder halt die Links dort angegeben.
Wenn ich zuvor eine externe css bekannt gebe, sind die Styles dann im Include auch bekannt?

Bei serverseitigen Includes siehst Du das Endresultat
eben nur, wenn es ueber einen Webserver an den Browser
gelangt. Das heisst, eventuell ist es nuetzlich,
lokal einen Webserver (am besten gleich mitsamt PHP)
zu installieren. Aus Sicherheitsgruenden solltest Du
den aber nur laufen lassen, wenn Dein Computer physisch
vom Netzwerk getrennt ist. Ausser Du weisst genau, was Du tust:-)

Ja, ich habe einen lokalen Webserver und kann es dementsprechend dort testen ;-).

Ein paar einfuehrende Worte zu PHP und SSI findest Du auf meinen
Seiten unter http://www.tiptom.ch/tests/phpssi/

Wenn Du beides (PHP und SSI) zur Verfuegung hast, nimm PHP!
Dann hast Du spaeter viel mehr Moeglichkeiten.
Die Dateien duerfen ruhig Namen auf *.html haben;
einen anstaendigen Webserver (Apache) bringt man locker dazu,
auch in solchen Dateien PHP-Code auszufuehren:
http://www.tiptom.ch/tests/phpssi/server1.html

Vielen Dank für die Links, werde ich mir mal bei Gelegenheit durchlesen *g*.

Bis denn

Stefan

[Thomas Luethi]

Hallo,

Und wie könnte dann eine solche navi.inc ausschauen?
Arbeitet man dort auch mit <html><body> usw. und wird nur der Text oder halt die Links dort angegeben.

Regel Nr. 1 bei Includes: Der Browser kriegt ueberhaupt nicht mit,
wie die Seite zusammengebaut wurde. Das ist ihm auch sch***egal
Der Browser kriegt einfach das fertige HTML.

Dieser HTML-Quelltext sollte valide sein, darf also nur genau _ein_ <HTML>-Element
enthalten, nur _ein_ <BODY>-Element, nur _ein_ <TITLE>-Element.
Deshalb waere es kreuzfalsch, eine vollstaendige HTML-Seite
als Include in eine andere Seite einzubetten, dann haettest Du
naemlich jedes dieser Elemente zweimal...

=> Das Include muss einfach die paar Zeilen HTML-Code enthalten,
die Du an der gewuenschten Zeile einfuegen willst.
z.B.
<p class="fusszeile">
  <a href="impressum.html>Impressum</a> |
  <a href="kontakt.html>Kontakt</a> |
  <a href="home.html>Home</a> |
</p>

Wenn ich zuvor eine externe css bekannt gebe, sind die Styles dann im Include auch bekannt?

Natuerlich. Siehe Regel Nr. 1;-)

Gruesse,

Thomas

[Stefan]

Vielen Dank für die Hilfe ... in der Hoffnung, dass dann alles so hinzubekommen *g*.

Bis denn

Stefan

[Michael Jendryschik]

Hallo,

hätte eine frage an die mehr-als-ich-htmler: verwende ihr für die gestaltung eurer seite tabellen oder frames?

Bitte lies http://forum.de.selfhtml.org/archiv/2003/4/44257/. Dort findest du auch Beiträge von mir, in denen ich meine Sicht der Dinge beschreibe, wie man eine Website aufbauen und strukturieren sollte.

Gruß,

MI