CSS Menühöhe an li-höhe anpassen.

[MisterPresident]

Hallo,

wieder mal habe ich ein Problem - eigentlich ein Klassiker aber ich bekomme es einfach nicht in den Griff:

ich habe ein Menü

<div id="menu">
<ul>
<li>
<a href="home.php">Home</a>
</li>
<li>
<a href="status.php">Status</a>
<ul>
</li>
<li>
<a href="einstellungen.php">Einstellungen</a>
</li>
<li>
<a href="support.php">Support</a>
<ul>
</li>

das formatiere ich als Vertikalmenü:

#menu
{
	font-family:"Verdana";
	width: 100%;
	[B]height: 35px;[/B]
	background-image: url(../images/menu_bg.jpg);
}

#menu ul
{
	margin: 0;
	padding: 0;
	list-style: none;
	z-index: 5;
}

#menu li
{
	position: relative;
	background-image: url(../images/menu_bg.jpg);
	padding: 5px 20px;
	float: left;
}

#menu li:hover a
{
	text-decoration: underline;
}

#menu li:first-child
{
	background-image: url(../images/menu_bg.jpg);
}

#menu ul ul
{
	display: none;
	margin-left: -20px;
}

#menu ul li:hover ul
{
 	display: block; 
	position: absolute;
	top: 100%
	/*left: 100%;*/
}

#menu ul li ul li:hover ul
{
 	display: block; 
	position: absolute;
	top: 0;
	left: 100%;
}


#menu ul li:hover ul ul
{
	display: none;
}

#menu ul li:hover ul li a
{
	text-decoration: none;
}

#menu ul li ul li:hover a
{
	text-decoration: underline;
}

#menu ul li ul li:hover ul li a
{
	text-decoration: none;
}

#menu ul li ul li ul li:hover a
{
	text-decoration: underline;
}

#menu ul ul ul
{
	margin: 0;
	display: none;
}

#menu a
{
	color: white;
	text-decoration: none;
}

#menu ul li ul li
{
	width: 100%;
}

#menu ul li:after
{
	clear: both;
}

mein Problem ist jedoch, dass das Menü nach dem erstellen eine Höhe von 0px hat (deswegen habe ich es gerade auf 35px gesetzt) nun möchte ich es auf "auto" setzen und bekomme es einfach nicht hin.
Gecleart hätte ich ja?


Danke für eure Hilfe, bin echt am verzweifeln.

 

[Daaron]

Liegt am float:left bei den <li>. Setz sie lieber auf display:inline-block, das verhält sich in der Beziehung angenehmer.

Oh, und n kleiner Tip zur Semantik. Falls du mit HTML5 schreibst, dann heißt es
<nav id="menu">, nicht <div>

 

[fz21z]

Zeile 9, das <li> Tag ist an der falschen Stelle.

<div id="navi">
	<ul>
		<li>
			<a href="#">Link1</a>
		</li>
		<li>
			<a href="#">Link2</a>
			<ul>
				<li><a href="#">Link2 - Sub1</a></li>
				<li><a href="#">Link2 - Sub2</a></li>
			</ul>
		</li>
	</ul>
</div>

edit: Daaron's inline-block sollte auch passen.

 

[MisterPresident]

Danke, somit wäre das Problem gelöst .
Weiters, ja ich programmiere mit HTML5 - danke für den Hinweis. Ich bringe mir das ganze selber bei und lese immer div, aber Dankeschön werde ich ausbessern

Rein aus Interesse: wie hätte das ganze ohne display:in-line sonder mit float: left funktioniert?

Edit: danke für die Infofz21z habe scheinbar ein wenig zu viel rauskopiert.

LG

 

[fz21z]

#navi ul { margin: 0; padding: 0; }

#navi ul li { display: inline; position:relative; }
#navi ul ul, #navi4 ul ul ul { display: none; }
#navi ul li:hover > ul { display: block; position: absolute; left:0px; top: 100%; }
#navi ul ul li:hover ul { left: 100%; top: 0px; }
#navi ul ul li { display: block; }
#navi a { color: black; text-decoration: none; }
#navi ul li a { padding-left: 20px; }

Das müsste mit dem Html von mir auch ohne inline korrekt dargestellt werden, nicht getestet.

 

[Daaron]

Rein aus Interesse: wie hätte das ganze ohne display:in-line sonder mit float: left funktioniert?

Nicht inline sondern inline-block. Der Unterschied ist klein aber fein.

float verändert den gesamten umgebenden Dokumentenfluss, z.B. die Art und Weise, wie sich die Höhe des Elternelements errechnet. Bei float muss man oftmals zusätzlich noch irgendwo ein clear-Element verwenden, um dämlichen Nebeneffekten vorzubeugen.

Inline-Elemente kennst du ja, die ordnen sich horizontal im Textfluss an, sie können mit text-align und vertical-align manipuliert werden (Block-Elemente nicht). Dafür kann man Inline-Elemente nicht mit height und width (sowie min- und max-) ändern.
Und hier kommt der Unterschied zu inline-block: Diese Elemente verhalten sich vom Fluss und der Positionierung wie Inline-Elemente, können aber hinsichtlich ihrer Größe und dem Overflow behandelt werden wie Block-Elemente.

Auf inline-block gesetzte <li>'s würden sich horizontal anordnen (wie bei float) und am horizontalen Ende des <ul> gibts einen Zeilenumbruch.

 

[Reglohln]

Aufgrund der Browserkompatibilität bei inline-block würde ich hier wohl eher mittels clear arbeiten, was man einfach per clearfix einarbeiten kann. Clearfix setzt zwar auch inline-block, berücksichtigt aber auch Browser, die diese display-Eigenschaft nicht unterstützen.

Folglich unterstützen das Menü ohne viel Aufwand dann mehr Browser und ein clearfix ist nun auch nicht wirklich schwer zu implementieren.

Dazu kommt, dass der TE wohl float und clear nicht recht verstanden hat und so erstmal Erfahrung sammelt, warum clear hier notwendig ist.

 

[unre4l]

#menu ul {
  overflow:hidden;
}

damit sollte ul die eigentliche Höhe bekommen, wirkt "quasi" wie ein Clearfix.

 

[Reglohln]

Was mich zudem am Code noch irritiert ist, wozu du die <div> #navi überhaupt nutzt?

Ich kenne jetzt zwar das Design nicht, aber es schaut so aus, als kannst du getrost auf das div verzichten und stattdessen <ul> die klasse "navi" zuweisen.

 

[Daaron]

Aufgrund der Browserkompatibilität bei inline-block würde ich hier wohl eher mittels clear arbeiten, was man einfach per clearfix einarbeiten kann.

http://caniuse.com/#feat=inline-block
Alles relevante leuchtet grün. Alles, was älter ist, kostet den Kunden dann den fünffachen Stundensatz. Fertig.

Was mich zudem am Code noch irritiert ist, wozu du die <div> #navi überhaupt nutzt?

Also mir ist noch kein Template unter die Augen gekommen, bei dem eine <ul>-Navigation "allein" im Fluss stand. Die war eigentlich immer in einem Wrapper.
Außerdem hättest du meinen Hinweis zu HTML5 lesen sollen. <div> mag noch zweifelhaft sein, spätestens wenn man seine Navigation aber in <nav> hüllt macht dieser Container verdammt viel Sinn.

 

[Reglohln]

Warum sollte es den fünffachen Stundensatz kosten, wenn man eine Kompatibilität zu nahezu allen Browsern gewährleisten kann, indem man einen einfachen Clearfix anwendet, den man sowieso immer mit im Standard-CSS-Template hat?

Ältere Browser bei speziellen Sachen nicht mehr zu unterstützten ist die eine Sache. Aber hier definitiv nicht notwendig, wenn man es mit geringstem "Aufwand" auch so hin bekommt. Im Prinzip ist dein inline-block ja genau der clearfix, nur eben nicht vollständig.

Und ich glaube, wir beide hatten uns schon einaml "in den Haaren" zum Thema Browserunterstützung, kann das sein?
(nicht böse gemeint )

Wozu sollte man die Navi zusätzlich in ein div packen? Verstehe ich nicht. <ul> reicht vollkommen aus. Sofern man nicht zwingend Markup benötigt, um spezielle Designelemente einzuarbeiten, ist es völlig unnötig.

Bei HTML5 ist es so vorgesehen, aber nicht bei HTML4. OK - der TE nutzt HTML5, sofern macht es die Diskussion zu diesem speziellen Fall hinfällig. Aber generell muss man bei HTML4 die Liste nicht noch in ein zustätzliches Element Hüllen. Verstehe eh nicht ganz, warum HTML5 da nicht einfach Kind-Elemente für <nav> bereitstellt, sondern man dann trotzdem wieder eine komplette Liste einfügen "muss". Muss halt alles nur abwärtskompatibel sein, aber dann kann man sich es auch fast sparen

 

[Daaron]

Warum sollte es den fünffachen Stundensatz kosten, wenn man eine Kompatibilität zu nahezu allen Browsern gewährleisten kann, indem man einen einfachen Clearfix anwendet, den man sowieso immer mit im Standard-CSS-Template hat?

Clearfix ist ein Hack. Man muss dafür einen Clear-Container erstellen, der KEINE semantische Relevanz hat. Das ist schlichtweg nicht zweckmäßig und nicht semantisch korrekt.
Außerdem: wie würdest du bei einer Float-Lösung deine Navigationspunkte in 2 Zeilen zentriert anordnen?

Und der 5x Stundensatz gilt für ALLE Anpassungen für Uralt-Browser. Man wird für die Holzkisten eh massig Fixes schreiben, da kann man auch gleich so einen Kram mit einpacken. Leute, die IE<8 supportet haben wollen, sollen dafür gefälligst bluten.

Ältere Browser bei speziellen Sachen nicht mehr zu unterstützten ist die eine Sache. Aber hier definitiv nicht notwendig, wenn man es mit geringstem "Aufwand" auch so hin bekommt. Im Prinzip ist dein inline-block ja genau der clearfix, nur eben nicht vollständig.

Inline und Inline-Block haben ein paar Eigenschaften, die man mit Floats einfach nicht hin bekommt, die aber verdammt geile Effekte ermöglichen.

Wozu sollte man die Navi zusätzlich in ein zusätzliches div packen? Verstehe ich nicht. <ul> reicht vollkommen aus. Sofern man nicht zwingend Markup benötigt, um spezielle Designelemente einzuarbeiten, ist es völlig unnötig.

Die meisten CMS spucken Container-Elemente aus, um das Skinning einfacher zu machen. Außerdem könnte man in sein Navi-Div ja mehrere verschiedene Navigationen packen, z.B. neben der <ul> noch ein Select-Formular, um für Mobilgeräte eine platzsparende Schnellnavigation anzubieten.

Verstehe eh nicht ganz, warum HTML5 da nicht einfach Kind-Elemente für <nav> bereitstellt, sondern man dann trotzdem wieder eine komplette Liste einfügen "muss".

Weil man Navigationen nicht zwingend als Listen schreibt, und erst recht nicht als unsortierte Listen. Angenommen, du hast einen längeren Artikel mit vielen Abschnitten, für den du eine Navigation schreibst... die wäre dann semantisch eher eine sortierte Liste. Und dann sind da eben noch Navigationsformulare oder einfach eine unsortierte Aneinanderreihung von <a>'s. Sogar ein <img> mit <map> gehört sich in ein <nav>, wenn man damit durch die Seite navigiert und nicht nur die Map dazu dient, um Overlays/Popups zu ermöglichen. Auch Inline-SVG kann als Navigation dienen.

 

[Reglohln]

Clearfix ist ein Hack. Man muss dafür einen Clear-Container erstellen, der KEINE semantische Relevanz hat. Das ist schlichtweg nicht zweckmäßig und nicht semantisch korrekt.

Ok - der zusätzliche Inhalt in bezug auf :after ist sicher semantisch nicht korrekt. Dennoch eine einfache Möglichkeit, bestimmte Browser zu unterstützen. Mir geht es hier halt einfach um den Aufwand, welcher beim Clearfix einfach nicht hoch ist. Es ist natürlich auch vom Projekt abhängig, was sonst noch so rumschwirrt. Man kommt ja Dank des IEs (und auch anderen Browsern) auch in der jeweils letzten Version kaum um Hacks herum, somit dürfte der Clearfix auch nicht ins Gewicht fallen.

Außerdem: wie würdest du bei einer Float-Lösung deine Navigationspunkte in 2 Zeilen zentriert anordnen?

Weiß ich auf die Schnelle nicht. Muss ich im speziellen Fall testen. Aber hier ging es ja gerade nicht um 2-spaltige Menüs und meine vorherigen Posts bezogen sich eigentlich alle auf das Problem des TE.
Ansonsten würde ich es wohl mittels fester Breite für <ul> lösen. Wobei ich jetzt auch nicht wüsste, was inline-block daran ändert, denn dann stehen die <li>s ja auch nebeneinander, wenn man die feste Breite weg lässt.

Und der 5x Stundensatz gilt für ALLE Anpassungen für Uralt-Browser. Man wird für die Holzkisten eh massig Fixes schreiben, da kann man auch gleich so einen Kram mit einpacken. Leute, die IE<8 supportet haben wollen, sollen dafür gefälligst bluten.

Wie gesagt: da hatten wir schonmal Meinungsverschiedenheiten. Da muss sicher jeder für sich die Entscheidung fällen und es gibt sicher auch aufwändigere Fälle, in denen eine Unterstützung weit aufwändiger ist.

Inline und Inline-Block haben ein paar Eigenschaften, die man mit Floats einfach nicht hin bekommt, die aber verdammt geile Effekte ermöglichen.

Das habe ich ja auch niemals bestritten. Ich will ja nicht, dass man inline-block garnicht mehr verwendet

Die meisten CMS spucken Container-Elemente aus, um das Skinning einfacher zu machen. Außerdem könnte man in sein Navi-Div ja mehrere verschiedene Navigationen packen, z.B. neben der <ul> noch ein Select-Formular, um für Mobilgeräte eine platzsparende Schnellnavigation anzubieten.

Genau - einige CMS spucken beschissenen Code aus. Andere wieder etwas besser. Benötigt man Markup, um spezielle Effekte zu erziehen (Beispiel: runde Ecken mittels Bildern), muss man dieses halt des Öfteren über divs lösen. Aber wenn es nicht nötig ist, ist es nunmal nicht nötig und kann weggelassen werden.

Weil man Navigationen nicht zwingend als Listen schreibt, und erst recht nicht als unsortierte Listen. Angenommen, du hast einen längeren Artikel mit vielen Abschnitten, für den du eine Navigation schreibst... die wäre dann semantisch eher eine sortierte Liste. Und dann sind da eben noch Navigationsformulare oder einfach eine unsortierte Aneinanderreihung von <a>'s. Sogar ein <img> mit <map> gehört sich in ein <nav>, wenn man damit durch die Seite navigiert und nicht nur die Map dazu dient, um Overlays/Popups zu ermöglichen. Auch Inline-SVG kann als Navigation dienen.

Ein Menü, wie es der TE erstellen möchte, ist eine Liste. Punkt. Ob nun unsortiert oder sortiert ist ja auch egal. Navi-Formulare (Dropdown, um z.B. auf eine bestimmte Seite zu springen) ist ja prinzipiell auch eine Liste, welche aber mittels eines speziellen Objektes erzeugt wird.
Und eine Aneinanderreihung von Links (z.B. eine Tag-Cloud) wäre eigentlich ebenfalls eine Liste, weil es eben Links auflistet.

Natürlich gibt es immer wieder Fälle, in denen das ein oder auch das andere passt. Darum ging es mir auch nicht. Ich möchte schon hier beim aktuellen Fall bleiben und wenn der TE einfach nur ein Menü in einer Liste hat, ohne sonstige Elemente wie Überschrift, ect. pp, dann reicht eine <ul> ohne umgebendes div. Da er aber HTML5 nutzt, nutzt er halt entsprechend nav und macht semantisch nichts falsch

 

[Daaron]

Ok - der zusätzliche Inhalt in bezug auf :after ist sicher semantisch nicht korrekt.

Browser, die mit inline-block nicht klar kommen, scheitern auch an :after. Für die Krücken musst du ein vollwertiges <div> in den Quelltext tippen. Dieses Div vermurkst einem dann für alle Browser das Markup, außer man hüllt es wiederum in einen Conditional Comment für IE<=7. Sauberes, modernes und vor allem kurzes Markup erlaubt solchen Scheiß einfach nicht.

Ansonsten würde ich es wohl mittels fester Breite für <ul> lösen. Wobei ich jetzt auch nicht wüsste, was inline-block daran ändert, denn dann stehen die <li>s ja auch nebeneinander, wenn man die feste Breite weg lässt.

Inline-Block kann man ganz einfach mit text-align:center; auf dem Elternelement mittig ausrichten. Großer Vorteil.

 

[Reglohln]

Browser, die mit inline-block nicht klar kommen, scheitern auch an :after.

Das ist falsch, wie du hier und hier nachlesen kannst.
Einzig der Netscape4 und IE bis Version 6 bzw. 7 unterstützt beides nicht. Aber selbst ich würde auf diesen Netscape4 pfeifen, da er einfach nicht wirklich verbreitet ist (nutzt den überhaupt jemand?) und zudem halt wirklich alt.
Der IE ist sowieso ne Sonderstellung, da man Lösungen zu verschiedenen Problemen dort schon extrem schnell durch haslayout findet. Und für nen clearfix reicht dort einfach eine Höhenangabe aus.

Für die Krücken musst du ein vollwertiges <div> in den Quelltext tippen. Dieses Div vermurkst einem dann für alle Browser das Markup, außer man hüllt es wiederum in einen Conditional Comment für IE<=7.

Man braucht kein div eintippen. Und ist das :after-Element im Quelltext eigentlich sichtbar?

Sauberes, modernes und vor allem kurzes Markup erlaubt solchen Scheiß einfach nicht.

Dass es sauerberer Wäre, wenn alle Browser alle Sachen korrekt unterstützten würden und wir uns über solche Dinge nicht den Kopf zerbrechen müssten, ist wohl allen klar. Aber so ist es nunmal leider nicht. Ich hab damit kein Problem. Ich finde es persönlich eher eine Herausforderung, solche Probleme browserübergreifend zu lösen. Dass man als beruflicher Webentwickler dadurch irgendwann genervt ist, leuchtet mir vollkommen ein.

Inline-Block kann man ganz einfach mit text-align:center; auf dem Elternelement mittig ausrichten. Großer Vorteil.

Ging es nicht gerade noch um zweispaltige Menüs? Das geht mit inline-block nicht besser/einfacher, als mit float und clear.

 

[Daaron]

Das ist falsch, wie du hier und hier nachlesen kannst.

css4you ist alles andere als der Weisheit letzter Schluss. Die haben oft genug Mumpitz auf ihren Seiten. Ich verlass mich lieber hierauf:
http://caniuse.com/#feat=css-gencontent (Optionen einblende, usage threshold auf <0.1% senken, dann siehst du was ich meine)

Eine kurze Google-Suche ergab auch noch direkt das hier:
http://stackoverflow.com/questions/4181884/after-and-before-css-pseudo-elements-hack-for-ie-7
http://stackoverflow.com/questions/...to-using-the-pseudo-elements-after-and-before
...

Nein, der IE6 & 7 können kein :before und :after. Der IE8 kanns, aber der kann auch inline-block.

Man braucht kein div eintippen. Und ist das :after-Element im Quelltext eigentlich sichtbar?

Nein, :before und :after sind Pseudo-Elemente, die tauchen nirgends auf. Ich bin mir nicht einmal sicher, ob man Click-Events auf sie setzen kann.
Hilft dir aber bei IE6&7 nichts, die können keine Pseudo-Elemente.

Dass man als beruflicher Webentwickler dadurch irgendwann genervt ist, leuchtet mir vollkommen ein.

"genervt" ist noch untertrieben. Bei einigen unserer Kunden MUSS ich Holzklasse unterstützen, weil deren Kunden typische Holzklasse-User sind. Wenn du an 4 Tagen in der Woche mit rgba(), box-shadow und border-radius arbeitest, dann kriegst du am 5. Tag nur noch Krämpfe, wenn du IE6-Hacks dafür schreibt.

Nein, ich sehe keinen Sinn mehr darin, überhaupt Zeit und Nerven in so einen Mist zu investieren. Aktuell hab ich ein Projekt auf dem Tisch, bei dem relativ komplexe Grafiken animiert klickbar sein müssen. Die Frage, wo so etwas möglich ist, ergibt genau 2 Antworten: Flash und SVG. Da Flash definitiv ausfällt, bleibt hier also auch direkt der Support für IE<9 auf der Strecke... aber da habe ich kein Mitleid.

Ging es nicht gerade noch um zweispaltige Menüs? Das geht mit inline-block nicht besser/einfacher, als mit float und clear.

mehrzeilig. Macht sich z.B. sehr gut bei Bildergalerien mit variabler Gesamtbreite. Float ist bei sowas weit schlechter als inline-block.

 

[Reglohln]

css4you ist alles andere als der Weisheit letzter Schluss. Die haben oft genug Mumpitz auf ihren Seiten. Ich verlass mich lieber hierauf:
http://caniuse.com/#feat=css-gencontent (Optionen einblende, usage threshold auf <0.1% senken, dann siehst du was ich meine)

Eine kurze Google-Suche ergab auch noch direkt das hier:
http://stackoverflow.com/questions/4181884/after-and-before-css-pseudo-elements-hack-for-ie-7
http://stackoverflow.com/questions/...to-using-the-pseudo-elements-after-and-before
...

Nein, der IE6 & 7 können kein :before und :after. Der IE8 kanns, aber der kann auch inline-block.

Bezüglich falschen Angaben auf css4you kann ich jetzt nichts sagen. Da fehlen mir einfach die Erfahrungen. Wenn das so ist, dann waren meine Links sicher nicht representativ.

Aber für IEs, welche weder :after, noch inline-block unterstützen, reicht in diesem Fall einfach haslayout aus, was also extrem einfach zu handhaben ist und sich in bestimmten Fällen sogar ohne einen extra clearfix von selbst löst

"genervt" ist noch untertrieben. Bei einigen unserer Kunden MUSS ich Holzklasse unterstützen, weil deren Kunden typische Holzklasse-User sind. Wenn du an 4 Tagen in der Woche mit rgba(), box-shadow und border-radius arbeitest, dann kriegst du am 5. Tag nur noch Krämpfe, wenn du IE6-Hacks dafür schreibt.

Nein, ich sehe keinen Sinn mehr darin, überhaupt Zeit und Nerven in so einen Mist zu investieren. Aktuell hab ich ein Projekt auf dem Tisch, bei dem relativ komplexe Grafiken animiert klickbar sein müssen. Die Frage, wo so etwas möglich ist, ergibt genau 2 Antworten: Flash und SVG. Da Flash definitiv ausfällt, bleibt hier also auch direkt der Support für IE<9 auf der Strecke... aber da habe ich kein Mitleid.

Das kann ich mir wirklich gut vorstellen Mir reichte es bei früheren privaten Projekten auch irgendwann, weil irgendwas in irgendeinem Browser nicht ganz passte. Und irgendwo ist sicher auch mal Schluss mit der Unterstützung. So habe ich z.B. mittels CCs CSS für IE<=5 komplett weggelassen. Aber ich denke trotzdem, dass man im Fall des TE sehr simpel viele Browser unterstützen kann. Für aufwändige und nahezu unmögliche Sachen, wie du sie beschreibst, ist ein ganz anderes Thema. Welche Browser man unterstützen muss, kann und will muss man in jedem Projekt neu definieren.

mehrzeilig. Macht sich z.B. sehr gut bei Bildergalerien mit variabler Gesamtbreite. Float ist bei sowas weit schlechter als inline-block.

Wie bereits geschrieben: ich halte inline-block ja nicht für falsch oder will es nicht nutzen. Ich stimme dir völlig zu, dass es in vielerlei Hinsicht sehr vorteilhaft ist.

 

[MisterPresident]

Leider bin ich jetzt aus der Diskussion ausgestiegen da ich davon kurz und gut nichts verstehe und gerade noch am erlernen der Basics der Webseitenentwicklung bin.

Vl. habt ihr ja noch Zeit mir ein paar Fragen zu beantworten:

• Wieso ist es "schlecht" das Menü in ein "div" zu packen?
• Ersetzte ich alle "div" durch "nav" oder nur beim Menü
• Wie ist es jetzt sinnvoll mein Problem zu lösen, grundsätzlich benutze ich kein CMS, einfach um hinter den ganzen Spaß zu kommen und alles selber erstellen zu müssen
• FF stellt mir meine Webseite super dar (mit display: inline-block jedoch werden meine einzelnen <li> Elemente nicht nebeneinander sondern untereinander Dargestellt
• Wie weit meint ihr soll ich meine Browser-Kompatibilität herunter setzten?
• Habt ihr ein Tutorial, dass "Up-To-Date" ist und für mich (Programmiererfahrung, jedoch eher nicht im Web") verständlich ist?
• Buhhh ich glaube ich mache 90% falsch was ich so bei eurer Diskussion mitbekommen habe

Danke LG

Lukas

 

[Reglohln]

Nun mach dir mal keine Sorgen

Zum Thema "Wie lerne ich HTML/CSS" kann ich dir garkeine wirklich Antwort gehen, da ich selbst garnicht mehr weiß, wie ich damals die ganzen Basics (und sooo verdammt viel mehr weiß ich heute auch nicht) gelernt habe. Folglich habe ich auch kein wirkliches Tutorial für dich. Einfach immer weiter an Websites basteln und neue erstellen. Da hilft schon eine Menge.
Aber in Sachen fortgeschrittenes CSS kann ich dir das Buch Fortgeschrittene CSS-Techniken empfehlen. Das ist das Einzige, was ich wirklich zum Thema Webdesign/-entwicklung gelesen habe. Sonst nur Seiten wie css4you und eben SelfHTML besucht. Aber Tutorials findet man zum Thema wie Sand am Meer


Zur Frage "Menü nicht in ein div": Das stimmt so pauschal nicht. Natürlich kann es sinnvoll sein, auch ein Menü oder andere Sachen in ein Div zu packen. Aber ein div ist einfach nichts. Du musst dir HTML (rein ohne CSS jetzt) so vorstellen: Du musst dem Browser mitteilen, was ein Element darstellen soll. Dafür gibt es Elemente, die eine Sache auf einer Website eindeutig beschreiben. Zum Beispiel eine unsortierte Liste <ul>. Du könntest ja deine Links des Menüs auch einfach nur als Link <a> hinklatschen. Aber damit ist einfach keine Aussage getroffen, worum es sich bei dem Link handelt. Es ist halt einfach nur ein Link. Aber niemand weiß, dass es ein Menü sein soll.

Und so handhabst du das mit allen Elementen deiner Seite. Und ein <div> beschreibt nun einfach keinerlei Objekt. Ein div fasst mehrere Elemente zusammen (um sie z.B. gemeinsam zu positionieren, ect. pp), gibt aber keinerlei Rückschluss darauf, um was es sich dabei handelt.

Aber um divs kommt man halt dennoch nicht immer herum. Meist unterteilt man eine Seite in mehrere Abschnitte, wie header, content, footer und ggf. noch linke und/oder rechte spalte.

Im header ist meist das Hintergrundbild bzw Banner und auch das Menü. Ggf. auch noch eine Suchzeile, ect. pp. Um dies dann zum header zu "vereinen" kann man es in ein div mit der ID "header" packen. Lässt sich teils einfach nicht vermeiden, ist aber halt nicht schön. Und da setzt halt teilweise HTML5 an, indem es ein neues Element "nav" ins leben ruft, was dann eindeutig auf eine Navigation, also ein Menü, hinweist.

Befasse dich mit dem Begriff "Semantik" im Zusammenhang mit HTML und du wirst es relativ schnell verstehen. Das schwierige ist eigentlich eher, wirklich das passende Element für eine Sache zu finden (also ein Menü in eine Liste und nicht nur mittels <a>).

Und du musst dir merken: HTML ist nur der Inhalt. Das Design kommt ausschließlich durch CSS. Also erstellst du deine Seite am besten erstmal komplett ohne CSS und versuchst im Nachhinein diese mit CSS so zu formatieren, wie du es dir vorgestellt hast.


Zu deinem Problem mit dem Menü: Poste doch bitte mal deinen bisherigen lauffähigen Code (also von Anfang bis Ende, sodass man direkt per Copy&Paste speichern kann) und ggf. auch Screenshots zum Problem.


Wie weit du Browser unterstützen willst, hängt von dir ab. Ich habe meine Meinung hier denke ich kund getan und da es im Falle deines Menüs relativ einfach ist, auch ältere Browser sehr einfach zu unterstützen, würde ich persönlich das auch so tun. Aber es gibt andere Fälle, in denen der Aufwand nicht mehr so recht im Verhältnis zum Nutzen steht. Aber darüber würde ich mir an deiner Stelle nicht mehr den Kopf zerbrechen. Es gibt Tools, mit denen du dir sämtliche IE-Versionen gleichzeitig installieren kannst. Dann installiere dir sonstige Browser und gucke, was passiert und arbeite daran, bis du zufrieden bist. Es gibt auch Onlinedienste, welche dir Screenshots von allen nur erdenklichen Browsern für deine Seite generieren. Das ist wirklich nicht schlecht. Frag mich aber bitte nicht mehr nach der Internetseite. Hab ich schon ewig nicht mehr genutzt. Sorry.

Hoffe, das war einigermaßen verständlich

 

[Daaron]

[*]Wieso ist es "schlecht" das Menü in ein "div" zu packen?

Is nicht schlecht. Ist manchmal sogar zwingend nötig, um gewisse Anforderungen ans Layout zu erfüllen. Für HTML5 ist es aber in soweit schlecht, weil <nav> das bessere Element ist. Grundregel für HTML5: <div> nur da, wo kein semantisch passenderes Blockelement vorhanden ist.

[*]Ersetzte ich alle "div" durch "nav" oder nur beim Menü

Bloß nicht. <nav> markiert, wie man vielleicht erraten kann, Navigationen.... und ausschließlich die. Analog dazu gibt es in HTML5 z.B. noch die Elemente <section>, <article> und <aside>.

[*]Wie ist es jetzt sinnvoll mein Problem zu lösen, grundsätzlich benutze ich kein CMS, einfach um hinter den ganzen Spaß zu kommen und alles selber erstellen zu müssen

Semantisch korrekt ist es, Navigationen in ein <nav> zu hüllen. Semantisch am sinnigsten (aber nicht allein seelig machend) ist eine Navigation als unsortierte Liste (<ul>).

[*]FF stellt mir meine Webseite super dar (mit display: inline-block jedoch werden meine einzelnen <li> Elemente nicht nebeneinander sondern untereinander Dargestellt

Zeig mal den Code, sowohl HTML als auch CSS. Das sollte nicht so sein.

[*]Wie weit meint ihr soll ich meine Browser-Kompatibilität herunter setzten?

Wer sind deine potentiellen Kunden/Besucher? Welche Technologie-Ebene kannst du erwarten? Wie viel Profit entgeht deiner Seite, wenn du veraltete Systeme nicht unterstützt?


Der wichtigste Tip ist wirklich, sich mit Semantik, insbesondere den neuen Semantik-Elementen in HTML5, auseinander zu setzen. So wäre es z.B. semantisch falsch, <aside> als Spalten-Element zu verwenden, nur weil es nach "Seite" klingt.... <aside> enthält "zusätzlichen/ergänzenden" Inhalt zum Hauptinhalt (z.B. eines <article> oder <section>. Das könnte eine Inhalts-Navigation sein, ein Rudel Social Media Links, weiterführende Links,....

Im header ist meist das Hintergrundbild bzw Banner und auch das Menü. Ggf. auch noch eine Suchzeile, ect. pp. Um dies dann zum header zu "vereinen" kann man es in ein div mit der ID "header" packen. Lässt sich teils einfach nicht vermeiden, ist aber halt nicht schön. Und da setzt halt teilweise HTML5 an, indem es ein neues Element "nav" ins leben ruft, was dann eindeutig auf eine Navigation, also ein Menü, hinweist.

...und weil Seiten quasi immer einen Kopf- und Fußbereich haben, und weil auch einzelne Artikel, Sektionen oder Zitate durchaus einen eigenen Kopf- und Fußbereich haben können, gibt es die neuen Elemente <header> und <footer>.
So gehört z.B. die Quellenangabe eines <blockquote>-Zitatblockes nicht in ein <div> oder <p>, sondern in einen <footer> innerhalb des Blockquotes.


Also man könnte in HTML5 auch dieselbe <div>-Hölle schreiben wie in HTML4 oder XHTML1.1, aber warum sollte man? Sowohl für Menschen als auch für Maschinen ist ein semantisch korrektes Element eben deutlich leichter verständlich.