Hallo

Bastle gerade an meiner ersten Homepage die ich mittels css layoute.
Es fehlen noch die richtigen Texte und Links aber ich würde euch trotzdem bitten einen blick auf den css code (ist nicht viel ;-) ) zu werfen.
ich denke schon dass ich das css layout richtig gemacht habe aber css layouts sind ja nicht so einfach.




Hornet (http://members.chello.at/hornet/)

grüße

Ich hab das mal in das Projekthilfe-Forum verschoben. Du möchtest ja, dass sich jemand deinen Quelltext ansieht und ggf. kritisiert. Eine "Seite" hast du ja noch nicht ;-)

Ich hab das mal in das Projekthilfe-Forum verschoben. Du möchtest ja, dass sich jemand deinen Quelltext ansieht und ggf. kritisiert. Eine "Seite" hast du ja noch nicht ;-)
ja stimmt dort ist es besser aufgehoben. danke

aber ich würde euch trotzdem bitten einen blick auf den css code (ist nicht viel ;-) ) zu werfen.
Vor dem CSS kommt immer das HTML - und das sollte erst mal "sauber" und sinnvoll aufgebaut sein, bevor man überhaupt an CSS denkt.

Und diesbezüglich sieht's noch nicht so dolle aus.
Fragwürdiger Doctype - bitte einen der folgenden wählen: SELFHTML: HTML/XHTML / Allgemeine Regeln für HTML / Grundgerüst einer HTML-Datei (http://de.selfhtml.org/html/allgemein/grundgeruest.htm#dokumenttyp). Und anschliessend Code mit dem Validator auf Korrektheit prüfen, The W3C Markup Validation Service (http://validator.w3.org/)
Informiere dich über das Stichwort Quirks Mode; warum und wie er zu vermeiden ist.
Das Problem vieler Anfänger zeigt sich auch hier - es wird eine "DIV-Suppe" gekocht, statt die Inhalte mit HTML strukturell sinnvoll auszuzeichnen. Für Überschriften gibt es Hx, Fliesstextabsätze in P, eine Navigation wird zeitgemäß als Liste von Links (UL>LI>A) aufgebaut, etc.
DIV und SPAN sind gruppierende Elemente und kommen auch nur dafür zum Einsatz, oder wenn es wirklich kein passenderes Element für den jeweiligen Inhaltsteil gibt, das dessen Bedeutung besser repräsentieren könnte.
Statt mehrere IDs wie #content, #content2, #content3 etc. durchzunummerieren, solltest du Klassen verwenden, wenn mehrere Elemente gleicher "Art" dies rechtfertigen.
Und im CSS nicht immer gleiche Definitionen mehrfach wiederholen, sondern gleiches zusammenfassen. Man kann auch mehrere Selektoren mit Komma getrennt notieren, und dahinter in den geschweiften Klammern die CSS-Eigenschaften, die sie gemeinsam haben sollen. (Auch ein Stichwort, worüber du dich informieren solltest: Selektoren. Ohne Kenntnisse darüber kann man kaum sinnvolles CSS schreiben.)

Hallo
Danke für dein Feedback

Also mein HTML ist normalerweise nicht so schlampig wie in diesem Fall.
Dass da einiges sauberer gehört weiß ich.
Ich hab mich in den letzten Tag mit css layout beschäftigt weils mich sehr interessiert und habe jetzt versucht so etwas umzusetzen zumindest zu verstehen wie das mit floats funktioniert. Manuals und Anleitungen schon viele durchgelesen, in der Praxis - vor allem wenn man so ein Layout wie ich es haben möchte umsetzen möchte - schauts dann schon wieder anders aus.

Für die Navigation kommen wahrscheinlich eh noch Grafiken.
Ist es eigentlich noch zeitgemäß Tabellen zu verwenden für so eine Navigationsleiste? also pro Button eine Spalte usw...

Der Teil mit #content, #content2, #content3 ist noch unklar ob das so viele "kästchen" hinkommen Das werde ich falls dann überhaupt so viele notwendig sind auf alle Fälle mit Klassen umsetzen.

Hallo hornet,

es war nie zeitgemäß, Tabellen für irgendetwas anderes zu verwenden als tabellarische DATEN ;)

Auch, wenn in der Praxis immer noch viele Agenturen Tabellen 5-fach verschachteln, sollte man sich diese nicht zum Vorbild nehmen, denn:

Es gibt kein tabellenbasiertes Layout, dass sich nicht ohne Tabellen und mit CSS genauso gut oder besser realisieren lässt.

Gruß,

Anja

Hallo hornet,

es war nie zeitgemäß, Tabellen für irgendetwas anderes zu verwenden als tabellarische DATEN ;)

Auch, wenn in der Praxis immer noch viele Agenturen Tabellen 5-fach verschachteln, sollte man sich diese nicht zum Vorbild nehmen, denn:

Es gibt kein tabellenbasiertes Layout, dass sich nicht ohne Tabellen und mit CSS genauso gut oder besser realisieren lässt.

Gruß,

Anja
stimmt schon, tabellen haben nich den Sinn des layoutens und trotzdem hat man es bis dato immer verwendet weils praktisch und einfach war.
layouts mittels Css zu erstellen ist schwierig, zumindest für mich.
Kann mich auch nur ganz kurz an die dhtml zeit erinnern wo dutzende dhtml menüs enstanden. schlimm war das.

dann mache ich die Buttons am besten nur mit normalen Text und nicht als Grafik und kämpfe/quäle mich durch den restlichen Code. *gg*

Das Problem vieler Anfänger zeigt sich auch hier - es wird eine "DIV-Suppe" gekocht, statt die Inhalte mit HTML strukturell sinnvoll auszuzeichnen. Für Überschriften gibt es Hx, Fliesstextabsätze in P, eine Navigation wird zeitgemäß als Liste von Links (UL>LI>A)



Noch eine Frage wegen css layouts.

hab mir gerade den Artikel durchgelesen yatil!: Der Div-Wahnsinn (http://yatil.de/artikel/der-div-wahnsinn) wo ein Beispiel gebracht ähnlich meines Layouts.
Es wird aber nicht wirklich genau drauf eingegangen wie man die divs wegbekommt bzw welche man stattdessen nehmen soll. Dass man eine Liste (ul) nicht mit mehreren divs macht ist verständlich. Gut der Teil mit #content2, #content3, #content4 ist natürlich nicht schön da man es zusammenfassen kann wie du es ja schon erwähnt hast aber das Grundgerüst welches ich gemacht habe kann man ja nicht so einfach komplett stanzen oder? ich habe einen oberen bereich wo ein Hintergrundbild sein soll. Darüber eine Navigationsleiste (horizontales menü) und drunter zwei Spalten, einmal wo Text drinnen ist und rechts mit mehreren Boxen wo man zb mittels gefloateten <p>block mit kurzem text</p> arbeiten könnte.

Was in dem yatil-Artikel als Negativbeispiel angegeben wird, ist meiner Meinung nach unter gewissen Umständen absolut okay. (Nur die Navigation ist vielleicht etwas zu übertrieben.) Man könnte mit gleichem Recht behaupten, dass ausschweifendes CSS-Selektoren-Gebastel gegen das KISS-Prinzip (http://en.wikipedia.org/wiki/KISS_principle) verstößt. Sein CSS kann man vielleicht noch einmal auf diese Weise optimieren, wenn das Layout steht.

Mach mal erst weiter, aktuell ist zu wenig auf deiner Seite, um wirklich etwas dazu sagen zu können.

Es gibt übrigens fertige HTML-Tags wie header, section, article usw., die statt div-Tags eingesetzt werden können, um die Elemente im HTML-Code "semantischer" zu gruppieren. Ich finde spontan allerdings weder eine Übersicht noch weiß ich, wie ältere Browser damit umgehen. Habe mich insgesamt noch nicht damit beschäftigt.

Der Artikel sagt es eigentlich: Nimm die HTML-Elemente, die semantisch dem am nächsten kommen, was du machen willst. In deinem Falle z. B. p statt div#contentX. Auf SELFHTML: HTML/XHTML / Referenz /HTML-Elementreferenz (http://de.selfhtml.org/html/referenz/elemente.htm) findest du eine Übersicht.

Wenn es kein Element gibt oder wenn du lediglich Code-Blöcke gliedern willst, hat niemand was gegen den sinnvollen Einsatz von div-Elementen.

Gruß,

Anja

@mermshaus:

HTML5 isn't a standard yet (W3C)

@AmicaNoctis:

Ja, sehe es auch gerade. Dachte, die wären schon in einer Pre-HTML5-Version fest dabei. ;)

header, section, article, footer and html5 | Is This A Blog? (http://www.isthisablog.com/2008/04/28/header-section-article-footer-html5/)

Unter anderem yatil setzt sie ein und google.com wird bereits als HTML5 ausgeliefert. *schulterzuck*

Gegen den Einsatz spricht auch nichts, solange der Browser XML-fähig ist und ihm per CSS beigebracht wird, wie er die anzeigen soll. Allerdings sollte es dann auch als application/xhtml+xml ausgeliefert werden und einen entsprechenden xmlns deklarieren, was nicht der Fall ist, soweit ich das sehe, nicht mal der Quelltext ist XML-konform. Browser schlucken halt alles...

Edit: Ich war zu voreilig: Laut W3C gibt es HTML5 auch in der Geschmacksrichtung SGML, also ist es OK, wie z. B. yatil es macht. Trotzdem bin ich der Meinung, dass man neuere Versionen von HTML ausschließlich XML-basiert hätte definieren sollen. Ich hätte z. B. keine Lust, Microcode mit nem SGML-Parser auszulesen.

Naja, wieder was gelernt.

Offtopic:

Gegen den Einsatz spricht auch nichts, solange der Browser XML-fähig ist und ihm per CSS beigebracht wird, wie er die anzeigen soll. Allerdings sollte es dann auch als application/xhtml+xml ausgeliefert werden und einen entsprechenden xmlns deklarieren, was nicht der Fall ist, soweit ich das sehe, nicht mal der Quelltext ist XML-konform. Browser schlucken halt alles...

Das wäre dann aber nicht mehr im Sinne des Erfinders. ;)

Die Probleme mit "echtem" XHTML (also XHTML mit XML-MIME-Type) sind wohl bekannt (verzeiht keine Fehler, wird im IE iirc gar nicht (?) gerendert), und eine private, nicht-standardisierte Namespace-Ergänzung hat nicht die nutzbaren Semantik-Vorteile eines im HTML-Standard enthaltenen Tags, der überall im Internet dieselbe Bedeutung hat.

Vom Standpunkt der maschinellen Verarbeitung ist eine eigene XHTML-Ergänzung <header> nicht sinnvoller als <div id="header">, was wiederum keinen Deut semantischer ist als <div>. Das taugt nur etwas, wenn ganz oben (W3C) definiert wird, dass <header> ein Tag ist, der Header-Daten enthält.

header, section, article usw. sind übrigens wohl existierende HTML5-Tags. Wenn ich das nicht völlig falsch sehe, macht yatil nichts anderes, als HTML5 zu nutzen.

Die Schwierigkeit mit striktem XML-Code ist schlicht und ergreifend das drakonische "fail on first" Error-Handling.

Schöner Artikel dazu: Thought experiment [dive into mark] (http://diveintomark.org/archives/2004/01/14/thought_experiment)
"XHTML" in HTML5: HTML 5 + XML = XHTML 5 | HTML5 Doctor (http://html5doctor.com/html-5-xml-xhtml-5/)
An Unofficial Q&A about the Discontinuation of the XHTML2 WG (http://hsivonen.iki.fi/xhtml2-html5-q-and-a/)

Sorry für Thread-Hijacking und Linkbombing (war ein wenig unter Zeitdruck). Ist ein spannendes Thema. Sollten wir aber vielleicht nicht hier fortführen. :)

Edit: Oh, es wäre möglich, dass ich dich falsch verstanden habe.

Edit: Oh, es wäre möglich, dass ich dich falsch verstanden habe.

Im Großen und Ganzen nicht. Bezüglich xmlns meinte ich zwar schon einen vom W3C (kommt nicht so rüber, ich seh's ein), aber bezüglich XML-Validität muss ich aufgrund des Gedankenexperiments Abstriche machen.

Unbetroffen davon ist meine Meinung zu neuen HTML-Versionen auf Nur-XML-Basis, was nicht heißt, dass Browser diese dann strikt validieren und im Fehlerfall abweisen sollten, also doch als text/html ausliefern.

Danke jedenfalls für den interessanten Denkanstoß!

Gruß,

Anja

Die Schwierigkeit mit striktem XML-Code ist schlicht und ergreifend das drakonische "fail on first" Error-Handling.
Das mag Noobs betreffend noch korrekt sein - aber für die gibt es ja die HTML-"Variante", in der bei HTML 5 sogar genauere Regeln und Vorgehensweisen für die Fehlerbehandlung enthalten sind.

Für Leute mit etwas Ahnung von der Materie mag ich das aber nicht gelten lassen, und erst recht nicht als "drakonisch" bezeichnen - wenn man in (Script-)Sprachen wie PHP, JavaScript, sonstwas programmiert, dann gibt's da auch keine "Fehlertoleranz" hinsichtlich der Syntax, sondern bei Verstössen schlicht und einfach einen Abbruch.

so jetzt habe ich ein bisserl was geändert.

verwende jetzt für die boxen rechts p.boxen{mehrmals} und p.infokasten{} also keine #box1, #box2, usw.... mehr.


den div container #boxenrechts verwende ich damit die boxen rechts immer schön untereinander verlaufen selbst wenn der linke textbereich kürzer ist.

Ein Problem hab ich jetzt mit der Navigation, liegt momentan ein einem div container. die Navigations leiste soll genau über dem weißen Streifen liegen. Jedoch gibts da eben Abweichungen in der Höhe beim Internetexplorer.
Mir ist bis jetzt noch keine Lösung eingefallen. Vielleicht mit dem Hintergundbild eine andere Lösung finden oder per Java script vielleicht die höhe um so und so viel pixel anpassen.


ach ja das gerüst ist hier zu sehen
http://members.chello.at/hornet/img/geruest.gif wobei die einzelnen rahmen ein eigener container darstellt

den div container #boxenrechts
Auch das, IDs/Klassen nach der derzeit gewünschten Darstellung benennen, solltest du nicht machen.
Der (leicht theoretische) Vorteil von CSS ist, dass du damit das Aussehen komplett verändern kannst, ohne das HTML anzufassen. Wenn #boxenrechts jetzt irgendwann mal nicht mehr rechts, sondern links angezeigt werden soll - dann wäre dieser Bezeichner plötzlich widersinnig und irreführend.

Deshalb: IDs/Klassen immer nach der Funktion/Bedeutung der jeweiligen Elemente benennen, nicht nach darstellerischen Gesichtspunkten.


Zu deinem Problem mit der Navigation kann man wenig sagen, so lange du nur ein Bild zeigst.

verwende jetzt für die boxen rechts p.boxen{mehrmals} und p.infokasten{} also keine #box1, #box2, usw.... mehr.

Was machst du, wenn du in einen der gestrichelt umrahmten Infokästen plötzlich mehrere Absätze eintragen willst? Oder zusätzlich eine Liste oder ein Bild? Nimm diese "Divteritis"/"Div-Suppe"-Artikel bloß nicht zu ernst. ;)

Jedoch gibts da eben Abweichungen in der Höhe beim Internetexplorer.

Ich empfehle, sowas erst anzugehen, wenn das Layout in einem Browser, der korrekter rendert, fertig ist.

Was machst du, wenn du in einen der gestrichelt umrahmten Infokästen plötzlich mehrere Absätze eintragen willst? Oder zusätzlich eine Liste oder ein Bild? Nimm diese "Divteritis"/"Div-Suppe"-Artikel bloß nicht zu ernst. ;)
Das eine hat wenig mit dem anderen zu tun. Hier gilt es natürlich auch, nicht im Eifer des Gefechts über's Ziel hinaus zu schiessen - DIVs sind nicht per se "böse".

Fliesstext gehört selbstverständlich in P-Elemente, ganz unabhängig von sämtlichen sonstigen Gegebenheiten und Bedingungen.
Dass mehrere solcher Absätze ggf. mit einem gruppierenden DIV zusammengefasst werden, steht auf einem anderen Blatt - das wiederum hat aber nichts mit DIV-Suppe zu tun.
Und wenn man schon so ein gruppierendes Element vorliegen hat, und seine Nachfahrenelemente gleichartig formatieren will, dann nutzt man natürlich auch im CSS entsprechende Selektoren, um dies zu erreichen - dann verpasst man nicht jedem P einzeln eine ID/Klasse, sondern dem gruppierenden DIV, und spricht die P-Elemente darin dann bspw. mit dem Nachfahrenselektor an, um sie gemeinsam zu formatieren.

Das eine hat wenig mit dem anderen zu tun.

Das stimmt. Aber genau dieser nicht bestehende Zusammenhang zwischen gruppierendem Rahmen-Div und falsch benanntem "Inhalts"-Tag (<div class="absatz"> statt <p>) wird leider immer mal wieder suggeriert. Wie auch in der hier im Thread verlinkten yatil-Übersetzung dieses Artikels (http://juicystudio.com/article/div-mania.php) (s. u.).

Deshalb schrieb ich das. Ansonsten volle Zustimmung.

Ein typisches Dokument, das im Div-Wahn erstellt wurde, könnte so aussehen:

<div id="wrapper">
<div id="container">
<div id="navigation">
<div id="navhead">
...
</div>
<div id="navcontent">
...
</div>
</div>
<div id="content">
<div class="panel">
...
</div>
<div class="panel">
...
</div>
</div>
</div>
</div>


Vielleicht könnte man folgende Faustregeln festhalten:

- Text sollte nie direkt in einem div-Tag stehen.
- Jedes div-Element sollte einen begründbaren Zweck erfüllen, der sich nicht sinnvoll auf seine Kindelemente übertragen lässt.

Was machst du, wenn du in einen der gestrichelt umrahmten Infokästen plötzlich mehrere Absätze eintragen willst? Oder zusätzlich eine Liste oder ein Bild? Nimm diese "Divteritis"/"Div-Suppe"-Artikel bloß nicht zu ernst. ;)


verstehe schon was du meinst


Ich empfehle, sowas erst anzugehen, wenn das Layout in einem Browser, der korrekter rendert, fertig ist.
Nun ja das Layout so wie man es auf der Seite sieht ist fertig. nur sollte ich das mit der navigation nicht gebacken kriegen werd ich natürlich was ändern müssen. d.h. eigentlich hätte ich mir zuerst die navigationsleiste oben anschauen sollen.
ich dachte mir ich mache einfach mal zb nen div layer schmeiß die Navigationspunkte rein mach einen margin-top mit 200 pixel zb und die sache hat sich. nur hab ich dann festgestellt bzw hab ich beim erstellen der seite in photoshop nicht an das problem gedacht welches ich jetzt habe und zwar der Internetexplorer zieht mir ein paar pixel ab somit landen die Navi Punkte nicht genau über dem weißen Balken sondern oberhalb

nur zur info: der große gelbe kasten wird ein startbild welches ich geliefert bekomme.

ich dachte mir ich mache einfach mal zb nen div layer schmeiß die Navigationspunkte rein
Pfui! Aus! Nein!

Du wolltest doch keine DIV-Suppe kochen?
Dann pack die Navigation in eine Liste, und formatiere diese.

mach einen margin-top mit 200 pixel zb und die sache hat sich. nur hab ich dann festgestellt bzw hab ich beim erstellen der seite in photoshop nicht an das problem gedacht welches ich jetzt habe und zwar der Internetexplorer zieht mir ein paar pixel ab somit landen die Navi Punkte nicht genau über dem weißen Balken sondern oberhalb
Tja, pixelgenau und browserübergreifend ist nicht immer so trivial.

Da müsste man jetzt untersuchen, wo der IE die paar Pixel weniger her nimmt und warum.
Oder man positioniert bspw. die Navigation absolut, das ist in so einem Falle durchaus vertretbar und vermutlich leichter zu handhaben.

nur zur info: der große gelbe kasten wird ein startbild welches ich geliefert bekomme.
Ist damit etwas gemeint, was wirklich Inhalt transportiert?
Wenn nicht, dann hast du mit diesem Layout schon mal eine komplette Bildschirmhöhe verschwendet, die ich erst mal herunterscrollen muss, um zum eigentlichen Inhalt zu gelangen - das wäre auch nicht optimal.

Pfui! Aus! Nein!

Du wolltest doch keine DIV-Suppe kochen?
Dann pack die Navigation in eine Liste, und formatiere diese.

*gg* das war zumindest mein Plan, den hab ich jetzt eh geändert und überlege was neues


Tja, pixelgenau und browserübergreifend ist nicht immer so trivial.

Da müsste man jetzt untersuchen, wo der IE die paar Pixel weniger her nimmt und warum.
Oder man positioniert bspw. die Navigation absolut, das ist in so einem Falle durchaus vertretbar und vermutlich leichter zu handhaben.

du meinst mit Position:absolute arbeiten. das wäre ne Möglichkeit.


Ist damit etwas gemeint, was wirklich Inhalt transportiert?
Wenn nicht, dann hast du mit diesem Layout schon mal eine komplette Bildschirmhöhe verschwendet, die ich erst mal herunterscrollen muss, um zum eigentlichen Inhalt zu gelangen - das wäre auch nicht optimal.
das Startbild wird fix sein, ist zumindest bis jetzt so angedacht gewesen. wird immer gegen ein neues ausgetauscht, drunter sollen dann kurze news stehen in diesen Blöcken.
Vom Sichtbereich her ist es nicht optimal ich weiß. Man könnte die Grafik oben rechts (Flattermann) kleiner machen ab da muß ich meinen Freund erst davon überzeugen *gg*

dann werd ich mich mal wieder an die Arbeit machen und an der Seite rumpfuschen*gg*

ich danke Euch auf alle Fälle für eure Hilfe :jo: