css layout seite

[hornet]

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

grüße

[unset]

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 ;-)

[hornet]

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

[wahsaga]

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. Und anschliessend Code mit dem Validator auf Korrektheit prüfen, The W3C Markup Validation Service
• 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.)

[hornet]

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.

[AmicaNoctis]

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

[hornet]

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*

[hornet]

• 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 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.

[mermshaus]

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 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.

[AmicaNoctis]

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 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

[AmicaNoctis]

@mermshaus:

HTML5 isn't a standard yet

(W3C)

[mermshaus]

@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?

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

[AmicaNoctis]

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.

[mermshaus]

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]
"XHTML" in HTML5: HTML 5 + XML = XHTML 5 | HTML5 Doctor
An Unofficial Q&A about the Discontinuation of the XHTML2 WG

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.

[AmicaNoctis]

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