ugrás a tartalomhoz

CSS menü szélesség

bnc1995 · 2013. Ápr. 9. (K), 20.30
Sziasztok!
Egy apró, de számomra mégis elég nagy problémába ütköztem.
Adott az alábbi html és css kód.

<div>
    <ul>
       <li>
          <a href="#">menü1</a>
       </li>
       <li>
          <a href="#">menü2</a>
          <ul>
             <li>
                <a href="#">almenü1</a>
             </li>
             <li>
                <a href="#">almenü2</a>
             </li>
             <li>
                <a href="#">almenü3</a>
             </li>
          </ul>
       </li>
       <li>
          <a href="#">menü3</a>
       </li>
    </ul>
</div>


div>ul>li{
float:left;
}

div>ul>li>ul>li{
float: left;
}
Így egy két soros menüt kapok. Az eredeti kódban ha ráviszem a főmenüben az egyik elemre a kurzort akkor akkor egy másik almenü jelenik meg(nem hiszem, hogy a probléma szempontjából releváns volna). és a probléma az, hogy ha az almenü tartalma szélesebb a főmenü eleménél, akkor megnő a hozzá tartozó főmenü elemének a szélesség is így a tovább főmenü elemek is eltolódnak.

Eddig rendben is volna, meg kéne határoznom a a főmenü elemek szélességét, de én ezt nem nagyon szeretném mert nem túl szép megoldás.

Tudtok rá valami elegánsabb módszert?

Segítségeteket előre is köszönöm

Bence
‹ min-height-es div feltöltése belső divvel Favicon-ok kezelése ›
 ■
1

div>ul>li{ float:left;

Poetro · 2013. Ápr. 9. (K), 20.38
div>ul>li{  
  float:left;  
  position: relative;
}  
div>ul>li>ul {
  position: absolute;
  left: 0;
  display: block;
  white-space: nowrap;
}

div>ul>li>ul>li{  
  float: left;  
}
2

Probléma

bnc1995 · 2013. Ápr. 9. (K), 20.51
Így az almenü elemei egymás alá kerülnek.
4

Nálam nem, de mi lenne, ha

Poetro · 2013. Ápr. 9. (K), 21.25
Nálam nem, de mi lenne, ha kipróbálnád.
6

Ezeken a böngészőkön kipróbáltam:

bnc1995 · 2013. Ápr. 9. (K), 22.18
Firefox/19.0 nem működik
Chrome/26.0 működik
MSIE 10.0 nem működik
7

Valahogy

Poetro · 2013. Ápr. 9. (K), 22.27
Valahogy kimaradt:
div>ul>li>ul>li{    
  display: inline-block;   
}
8

Műkdik

bnc1995 · 2013. Ápr. 9. (K), 22.52
Köszi a segítséget.
3

Gyerekválasztó

Hidvégi Gábor · 2013. Ápr. 9. (K), 21.12
Ajánlom figyelmedbe ezt a hozzászólást, feleslegesen használsz child selectorokat (>), az elsőnél elég egy div li, a másodiknál pedig div li li, szebb, egyszerűbb, gyorsabb.
5

Köszi

bnc1995 · 2013. Ápr. 9. (K), 22.04
Köszi a figyelmeztetést, átírom:)
9

Gyorsabb?

Endyl · 2013. Ápr. 10. (Sze), 11.02
Érdekes, még sehol nem hallottam, hogy a child selectornál gyorsabb lenne a sima descendant selector. Leginkább csak az ellenkezőjét (Mozilla, Google, stb.). Főleg nem-triviális méretű, összetettségű dokumentumoknál. Persze kis oldalnál nem lesz számottevő a különbség (akármelyik is gyorsabb).

Azt is tegyük hozzá, hogy a két fajta selector egészen mást jelent. Tehát a div li nem csak a div>ul>li-re illeszkedik, hanem a div>ol>li-re, vagy még rengeteg más szerkezetre is, ami nem biztos, hogy cél. A div li li pedig még több variációra fog illeszkedni, ami az idő előrehaladtával egyre zavaróbb lehet, ha bővül az oldal.

Ha már a css szépségéről, gyorsaságáról van szó, akkor inkább ajánljunk tag selectoroknál specifikusabb kiválasztókat (pl class), amiknél nem is kell azzal az egyre kisebb súlyú tényezővel foglalkozni, hogy esetleg régebbi böngészők (IE6) nem támogatják (vagy csak DOCTYPE meglétekor: IE7+) például a child selectort.
10

Amikor tegnap keresgéltem ezt

Hidvégi Gábor · 2013. Ápr. 10. (Sze), 11.40
Amikor tegnap keresgéltem ezt a hozzászólást, gondolkoztam a dolgon, amit említesz. Természetesen a div li változatnál figyelembe kell venni a környező kódot, mert valóban nem jó minden esetben, ahogy írod is; a példát az adott HTML-hez készítettem.

Jó lenne lemérni, mert nem egyértelmű. Persze nem ismerem pontosan a böngészők működését, de nagyjából így történhet:

1, div li esetében:
a div-en belül getElementsByTagName()-mel összegyűjti az összes li-t, egy cikluson belül

2, div > ul > li esetében:
a, a div-en belül összeszedi az összes gyermek közül az ul-eket
b, az ul-eken belül összeszedi az összes gyermek közül a li-eket

A helyzetet bonyolítja, ha minden li-re szeretnénk (a példából kiindulva) float:left;-et tenni, div > ul > li és div > ul > li > ul > li esetében kétszer kell, míg div li-nél pedig egyszer. Nekem úgy általában az a tapasztalatom, hogy minél kevesebb ciklus van egymásba ágyazva, azaz minél egyszerűbb a kód, annál gyorsabb.
11

Jobbról balra

Endyl · 2013. Ápr. 10. (Sze), 12.24
Tudomásom szerint a css szabályokat jobbról balra értelmezi a böngészőmotorok többsége (legalábbis a linkelt mozilla és google oldalakon ezt írják; csak tudják, hogyan csinálják).

Tehát:

1. div li esetében:
Minden egyes li esetében elkezd felfelé menni a DOM fában, egészen addig, amíg nem talál egy div-et, vagy el nem éri a fa tetejét.

2. div>ul>li esetében:
Minden egyes li esetében megnézi, hogy ul-e a szülője, ha nem, akkor nem alkalmazódik a szabály, ha igen, akkor megnézi, hogy az ul szülője div-e, ha igen, érvényes a szabály, egyébként nem.

Persze lehet méricskélni, csak kérdés, hogy JS esetén ugyanaz az algoritmus fut-e, mint a stílusok ellenőrzésénél, alkalmazásánál.

Ez a post is érdekes, még ha rég(ebb)i is.
[szerk]
Itt azt írja, hogy nem is csak a kész dokumentum kerül kirajzolásra, hanem nyilván, ahogy érkezik a tartalom, úgy kerülnek az egyes részek ki- és újrarajzolásra a stílusszabályok alapján, ahogy egyre több tartalom érhető el, amíg meg nem érkezik a teljes tartalom. Továbbá ha jól értem, minden egyes új elemre végigpróbálja az összes szabályt (első kirajzoláskor és reflow-nál), nem pedig a szabályok alapján keresi ki az elemeket (ami belegondolva logikus is ebben a folyamatban). Így azt gondolom, közepes méretű, összetettségű oldalnál is észrevehető lehet, ha nem kellő körültekintéssel íródik a CSS.
[/szerk]

Selectorok, szabályok írásánál érdemes mindezen elgondolkodni. Természetesen lehet olyan eset, ahol a kettő közül a div li lenne a nyerő, akár teljesítmény, akár jelentés szempontjából; ahogy írtuk, a környezettől függ, mérlegelni/mérni kell, ha gondot okoz a megjelenítés sebessége.
12

A JS-t most felejtsük el, az

Hidvégi Gábor · 2013. Ápr. 10. (Sze), 13.03
A JS-t most felejtsük el, az nem számít, azt csak azért írtam, mert naívan azt gondoltam, hogy úgy működik, csak a Mozillás linket olvastam el.

Továbbá ha jól értem, minden egyes új elemre végigpróbálja az összes szabályt (első kirajzoláskor és reflow-nál)
Ez tutira így van. A github és a youtube IE-ben tetűlassú, és nem értettem meg, hogy miért (ránézésre faék egyszerűségű a dizájn), ezért letöltöttem a kódot, és elkezdtem vele játszani. A következőre jutottam:

1, Minél kevesebb stílus van az oldalon, annál gyorsabb a renderelés és a scrollozás (ez megerősíti azt, amit idézel), ezt úgy értem el, hogy kitöröltem a css-ből azokat a stílusokat, amelyeket nem használt az oldal.

2, A css elején lévő "reset" definíciók, amelyek minden elemre vonatkoznak, nagymértékben lassítják a kirajzolást.

Mindezek hatására azzal az eretnek gondolattal is eljátszottam, hogy mi lenne, ha – ahol érdemes és lehetséges – inline stílusokkal dolgoznék? Ha dinamikusan állítjuk elő a HTML-t, ez nem gond, plusz ha tömörítjük, nem lesz sokkal nagyobb.