nicht angemeldet
div als Hauptelement einer Seite?
Moin!
Ich habe (erst mal als Spielerei) ein halbwegs schickes Layout http://www.robertbienert.de/heimat/Schatten-Wallpaper-3-4.html für ne Internetseite entworfen, allerdings sind dabei noch ein paar Fragen:
* Das Design enthält den hauptsächlichen Inhalt in einem div. Dieses Element ist ja prinzipiell inhaltsleer, wie verhalten sich also Screenreader bei so etwas?
* Wie hätte XHTML denn gerne Script- und Style-Bereiche? Ich habe mal irgendwo was von CDATA-Sections gehört, aber sowohl Safari als auch Camino scheinen davon eine sehr genaue Vorstellung zu haben, die ich noch nicht kenne.
* Alternativ: Ich habe das Haupt-div eingerückt. Wenn ich statt dem body dem html den Hintergrund zuweise und den body anstelle des div einsetze, habe ich nur noch Probleme mit den Ecken.
(Wer will, darf auch was zum Layout sagen ;-) )
Vielen Dank schon mal im voraus,
Robert
-
Hi,
* Das Design enthält den hauptsächlichen Inhalt in einem div. Dieses Element ist ja prinzipiell inhaltsleer,
nein, semantikfrei.
wie verhalten sich also Screenreader bei so etwas?
Da das Element keine Bedeutung besitzt, kann auch weder eine beachtet werden, noch kann sie bei einem Ignorieren verloren gehen.
* Wie hätte XHTML denn gerne Script- und Style-Bereiche?
XHTML hätte ganz gerne <script src> und <link> ;-)
Ich habe mal irgendwo was von CDATA-Sections gehört, aber sowohl Safari als auch Camino scheinen davon eine sehr genaue Vorstellung zu haben, die ich noch nicht kenne.
Ja. Tipp: Vermeide den Fall. Arbeite mit externen Ressourcen. Noch'n Tipp: Bei <script> niemals die <emptytag/>-Schreibweise verwenden, da stellt der IE nämlich die ganze Seite nicht mehr dar.
* Alternativ: Ich habe das Haupt-div eingerückt. Wenn ich statt dem body dem html den Hintergrund zuweise und den body anstelle des div einsetze, habe ich nur noch Probleme mit den Ecken.
Die sich da wie äußern? Es mag jedenfalls daran liegen, dass je nach Browser der <body> dem Viewport entspricht, für den einige Sonderregeln gelten.
(Wer will, darf auch was zum Layout sagen ;-) )
Och, nee Du, lass mal, wir verstehen uns gerade so gut ;-)
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hallo,
* Das Design enthält den hauptsächlichen Inhalt in einem div. Dieses Element ist ja prinzipiell inhaltsleer,
nein, semantikfrei.
Die »Semantik« von div ist eben, dass damit Zusammenhängendes gruppiert wird und somit das Dokument strukturiert wird.
Es gibt atürlich viele div-Anwendungen, denen kein direkt erkennbarer inhaltlicher Zusammenhang zwischen den umspannten Elementen entgegensteht. Diese werden für gewöhnlich Präsentationsgliederungen genannt, weil sie meist reine Angriffspunkte für Stylesheets sind, was ja auch ein vorgesehener Zweck des div-Elements ist. Sie haben dann meist entsprechende Klassen oder IDs, die ihrerseits nach dem Präsentationeffekt benannt sind. Je komplexer das Layout, desto mehr Präsentations-divs und desto mehr »div-Suppe«.Da das Element keine Bedeutung besitzt, kann auch weder eine beachtet werden, noch kann sie bei einem Ignorieren verloren gehen.
Die Datenstruktur ist eine vollkommen andere, wie man gut am Elementbaum sehen kann.
<div>
<p>bla</p>
<p>blub</p>
</div>
<div>
<p>foo</p>
<p>bar</p>
</div>erzeugt zwei Knoten, die ihrerseits jeweils zwei Knoten beinhalten. Durch die Unterbringung der Daten »blub« in einer gesonderten Extra-»Schublade« entsteht ein stärkerer Zusammenhang zum Vorgänger »bla« als zum Nachfolger »foo«.
Wenn hier div eine sinnige Klasse hat, macht man diesen Zusammenhang auch durch die Präsentatin klar: Die divs erhalten z.B. einen Rahmen und Außenabstände, sodass die Gruppierung visuell kommuniziert wird. Dasselbe ist für Sprachausgabe usw. denkbar (z.B. durch :before und :after mit content). (at würde es natürlich mit einer Liste machen.)
Mathias
-
Hi,
* Das Design enthält den hauptsächlichen Inhalt in einem div. Dieses Element ist ja prinzipiell inhaltsleer,
nein, semantikfrei.
Gut. Da hätte ich selbst drauf kommen können: Wer lesen kann, ist klar im Vorteil ;-)
wie verhalten sich also Screenreader bei so etwas?
Da das Element keine Bedeutung besitzt, kann auch weder eine beachtet werden, noch kann sie bei einem Ignorieren verloren gehen.
D.h. die Unter-Knoten innerhalb des div werden ganz normal bearbeitet.
* Wie hätte XHTML denn gerne Script- und Style-Bereiche?
XHTML hätte ganz gerne <script src> und <link> ;-)
Klar, das ist ja auch nur konzeptionell. Dahinter steckt natürlich die deutliche Trennung von Inhalt und Layout.
Ich habe mal irgendwo was von CDATA-Sections gehört, aber sowohl Safari als auch Camino scheinen davon eine sehr genaue Vorstellung zu haben, die ich noch nicht kenne.
Ja. Tipp: Vermeide den Fall. Arbeite mit externen Ressourcen.
Das könnte einiges einfacher machen. Ich hab wenig Lust auf irgendwelche Kompatibiliäts-Hacks.
Noch'n Tipp: Bei <script> niemals die <emptytag/>-Schreibweise verwenden, da stellt der IE nämlich die ganze Seite nicht mehr dar.
Meinst du damit <script type="text/javascript" src="pfad/zum/script.js" /> ? Ist dass denn nach der XHTML-Spezifikation überhaupt zulässig? Ich kenne vom "guten alten" HTML nur <script type="text/javascript" src="pfad/zum/script.js"></script>
* Alternativ: Ich habe das Haupt-div eingerückt. Wenn ich statt dem body dem html den Hintergrund zuweise und den body anstelle des div einsetze, habe ich nur noch Probleme mit den Ecken.
Die sich da wie äußern? Es mag jedenfalls daran liegen, dass je nach Browser der <body> dem Viewport entspricht, für den einige Sonderregeln gelten.
Naja, man sieht nur noch Reste der vier Ecken (Bilder), da diese ausgerückt werden. Sie verschwinden sozusagen hinter dem body (z-index bringt damit auch nichts).
(Wer will, darf auch was zum Layout sagen ;-) )
Och, nee Du, lass mal, wir verstehen uns gerade so gut ;-)
OK
Cheatah
Gruß, Robert
-
Hallo,
Noch'n Tipp: Bei <script> niemals die <emptytag/>-Schreibweise verwenden, da stellt der IE nämlich die ganze Seite nicht mehr dar.
Meinst du damit <script type="text/javascript" src="pfad/zum/script.js" /> ?
Das sollst du _nicht_ verwenden.
Ist dass denn nach der XHTML-Spezifikation überhaupt zulässig?
Ja.
Ich kenne vom "guten alten" HTML nur <script type="text/javascript" src="pfad/zum/script.js"></script>
Das ist in HTML 4.01, XHTML 1.0 und XHTML 1.1 zulässig,
wahrscheinlich auch in XHTML 2.0 (Hypothese).(Wer will, darf auch was zum Layout sagen ;-) )
Du hast es so gewollt ;-))
Ich habe fürs erste nur einen Kritikpunkt:
Das Hintergrund-Bild (bzw. die damit verbundene optische Täuschung)
erzeugt den Eindruck, der Kasten in der Mitte sei ein bisschen
nach links gekippt. Das stört permanent beim Lesen/Betrachten.Gruß
Alexander Brock--
SelfCode: ie:{ fl:{ br:> va:) ls:# fo:) rl:( n4:( ss:| de:> js:( ch:| sh:( mo:) zu:}
http://againsttcpa.com-
Hallo,
Moin!
Noch'n Tipp: Bei <script> niemals die <emptytag/>-Schreibweise verwenden, da stellt der IE nämlich die ganze Seite nicht mehr dar.
Meinst du damit <script type="text/javascript" src="pfad/zum/script.js" /> ?
Das sollst du _nicht_ verwenden.
OK, auf diese Idee käme ich gar nicht, wenn es Cheatah nicht angesprochen hätte. In meinem Kopf steckt irgendwie die Vorstellung (von HTML), dass <script> kein "leeres" Element ist.
Ist dass denn nach der XHTML-Spezifikation überhaupt zulässig?
Ja.
Hätte ich nicht gedacht. Das erklärt auch, warum man auf einigen "Pseudo-XHTML" Seiten auch solche Konstrukte wie <p /> findet.
Ich kenne vom "guten alten" HTML nur <script type="text/javascript" src="pfad/zum/script.js"></script>
Das ist in HTML 4.01, XHTML 1.0 und XHTML 1.1 zulässig,
wahrscheinlich auch in XHTML 2.0 (Hypothese).Das W3C will zwar einerseits XML "durchboxen", schaut aber lobenswerter Weise auch auf die Kompatibilität. Und wenn der IE damit Probleme hat, kann man das nicht vernachlässigen (Fluchen hilft eh nicht ;-) ).
(Wer will, darf auch was zum Layout sagen ;-) )
Du hast es so gewollt ;-))
Auf jeden Fall.
Ich habe fürs erste nur einen Kritikpunkt:
Der kann aber entscheidend sein.
Das Hintergrund-Bild (bzw. die damit verbundene optische Täuschung) erzeugt den Eindruck, der Kasten in der Mitte sei ein bisschen nach links gekippt.
Die optische Täuschung ist auch so gewollt. Momentan handelt es sich dabei nur um eine kleinere Spielerei, aber trotzdem gut zu wissen.
Das stört permanent beim Lesen/Betrachten.
Das ist ein wichtiger Hinweis. Ich denke, von einer "Veröffentlichung" sollte ich deshalb erst mal absehen.
Gruß
Alexander BrockDanke, sagt der Robert
-
Hi,
OK, auf diese Idee käme ich gar nicht, wenn es Cheatah nicht angesprochen hätte. In meinem Kopf steckt irgendwie die Vorstellung (von HTML), dass <script> kein "leeres" Element ist.
Naja, es gibt zwei Arten leerer Elemente.
Die erste ist die mit content-model EMPTY - diese Elemente können nie Inhalt haben (z.B. in HTML: img, hr, br, area, base, basefont, link, col, frame, input usw.).
Und dann gibt es noch die leeren Elemente, die zwar Inhalt haben dürfen, aber zufällig gerade mal keinen haben. Das trifft aber nicht auf alle Elemente zu, die nicht EMPTY als content-model haben - es gibt auch Elemente, die nicht leer sein dürfen (z.B. in HTML muß head ein title-Element enthalten oder ul muß mindestens ein li enthalten).
Bei der ersten Sorte ist in XHTML die ein-tag-Schreibweise (mit Leerzeichen vor dem /) empfehlenswert (nicht-XHTML-fähige Browser könnten über ein extra-end-tag stolpern).
Bei der zweiten Sorte ist in XHTML die zwei-tag-Schreibweise empfehlenswert (nicht-XHTML-fähige Browser suchen sonst vergeblich nach dem schließenden tag).Ist dass denn nach der XHTML-Spezifikation überhaupt zulässig?
Ja.
Hätte ich nicht gedacht. Das erklärt auch, warum man auf einigen "Pseudo-XHTML" Seiten auch solche Konstrukte wie <p /> findet.XHTML ist XML - XML erlaubt für Elemente ohne Inhalt (ob zufällig oder zwangsweise) immer die ein-tag-Schreibweise.
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
-
-
-
-