Tetszik a bejegyzés? Iratkozz fel, oszd meg!


A “block” és “inline” elemekről

A HTML nyelv két elemtípus kategóriát definiál a legtöbb elem számára, a “block”-ot és az “inline”-t. Például “block” típusú egy bekezdés, egy címsor, míg inline típusú egy link, egy kép. Ezek azok az információk, melyet elvileg mindenki tud, azonban azt már kevésbé, hogy például milyen típusú egy táblázat, felsorolás – és hogy pontosan mit is jelentenek ezek a kategóriák. Nézzük végig!

A “block” kategóriába tartozó elemek jellemzően más “block” és “inline” elemeket tartalmaznak, tartalmazhatnak, és vizuális megjelenítésükkor jellemzően egy új sorban kezdődnek. Az “inline” kategóriába tartozó elemek csak és kizárólag “inline” elemeket tartalmazhatnak. A kiemelések nem véletlenek, és nagyon fontosak, több okból is.

Kezdjük azzal, hogy a HTML egy szerkezetet leíró, és nem egy megjelenést meghatározó nyelv. Ez sokmindent jelent, esetünkben azt, hogy egy “block” elem csak jellemzően jelenik meg úgy, hogy új sorban kezdődik, ezek a kategóriák ugyanis nem a megjelenésről szólnak. A legegyszerűbb ellenpélda az, amikor egy linket style=”display: block” CSS stílussal blokk megjelenésűre állítunk. Azonban ettől még a link nem lesz “block” kategóriájú elem, és ez semmiképpen sem fogja befolyásolni a HTML forrásban elfoglalt szerepét! Ezt nagyon fontos megérteni, mert sok szívástól menthet meg minket.

Másik fontos gondolat, hogy minden “block” elem esetében definiált, hogy tartalmazhat-e más “block” típusú elemet, vagy nem, még konkrétabban pontosan definiált, hogy mely elemeket tartalmazhat (jellemzően három kategória van: csak “block” elemet tartalmazhat, csak “inline” elemet tartalmazhat, mindkettőt tartalmazhatja). Például a bekezdést jelölő P elem nem tartalmazhat másik “block” elemet, így táblázatot, felsorolást, címsort, HR-t, FORM-ot sem. Tudtad?

Itt jelezném, hogy azt illetően, hogy egy elem pontosan milyen elemeket tartalmazhat, a HTML 4-en belül is létezik a “Transitional” és a “Strict” mód. Én az utóbbit preferálom, mivel jóval könnyebben felfedezhetőek a hibák, elgépelések, illetve ebben az üzemmódban sokkal szabványosabban is működik a böngésző. A “block” és “inline” elemek megítélését tekintve nincs különbség.

Nézzük, mely elemek “block” típusúak:

  • ADDRESS – cím
  • BLOCKQUOTE – blokkos idézet
  • DIV – általános “block” elem
  • DL – definíciós lista
  • FIELDSET – kérdőívek mezőit csoportosítja
  • FORM – kérdőív elem
  • H1, H2, H3, H4, H5, H6 – Különböző szintű címsor elemek
  • HR – Elválasztó elem
  • NOFRAMES – Alternatív tartalom, ha a böngésző nem támogatná a frame-eket
  • NOSCRIPT – Alternatív tartalom, ha a böngésző nem támogatná a script-eket
  • OL – Rendezett (számozott) lista
  • P – Bekezdés
  • PRE – Formázott szöveg
  • TABLE – Táblázat
  • UL – Rendezetlen lista (egyszerű felsorolás)
  • DD – Meghatározás leírója
  • DT – Meghatározás címe
  • FRAMESET – Keret befoglaló elem
  • LI – Lista elem
  • THEAD – Táblázat fejlécét jelölő elem
  • TBODY – Táblázat tartalmi részét jelölő elem
  • TFOOT – Táblázat láblécét jelölő elem
  • TD – Táblázatcella adatok számára
  • TH – Táblázatcella címek számára
  • TR – Táblázat sor

Pár egzotikus elemet kihagytam, de ezek a legfontosabbak.

Nézzük meg az “inline” elemeket is. Róluk azt kell tudni, hogy “block” elemeket semmiképpen nem tartalmazhatnak, másik “inline” elemet pedig a definíciójuk szerint igen. Íme a lista:

  • A – Link (főként)
  • ABBR – Rövidítés
  • ACRONYM – Betűszó
  • B – Vastag szöveg (ne használjuk, helyette STRONG)
  • BR – Sotörés
  • CITE – Idézet
  • CODE – Számítógépes kód
  • DFN – Definíciós kifejezés
  • EM – Hangsúlyozás
  • I – Dőlt szöveg (ne használjuk, helyette EM)
  • IMG – Kép
  • INPUT – Kérdőív beviteli mezője
  • KBD – Begépelhető szöveg
  • LABEL – Kérdőívelem címkéje
  • Q – Rövid idézet
  • S – Áthúzás (ne használjuk, helyett DEL)
  • SAMP – Példa kimeneti szöveg (amit program ír ki)
  • SELECT – Kérdőív választó eleme
  • SPAN – Általános “inline” elem
  • STRIKE – Áthúzás (ne használjuk, helyett DEL)
  • STRONG – Hangsúlyos kiemelés
  • SUB – Felső index
  • SUP – Alsó index
  • TEXTAREA – Több soros szövegmező
  • TT – Írógépelt szöveg
  • U – Aláhúzott szöveg (ne használjuk)
  • VAR – Változó

Végül vannak kaméleon elemek is, melyek “block” elemeken belül “inline” elemként kezelendőek, amúgy pedig maguk is “block” elemek:

  • APPLET – Java applet (kihalt)
  • BUTTON – Gomb (használjuk)
  • DEL – Törölt szöveg
  • IFRAME – Beágyazott keret
  • INS – Beszúrt szöveg
  • OBJECT – Beágyazott speciális objektum
  • SCRIPT – Kliens oldali kód

A teljes HTML definíciót nem fogom ide másolni, de nézzünk pár érdekességet, melyeket nem árt tudni.

Talán a legfontosabb: ha megszegjük ezeket a szabályokat, akkor a böngésző megpróbálhatja a hibát korrigálni (böngészőfüggő). Egy paragrafusba (P elem) helyezett lista (mondjuk UL) elem esetén az kikerül a paragrafusból, és az eredetileg egy paragrafusból P-UL-P hármas lesz a megjelenítés során. Lehet, hogy ezt senki sem fogja észrevenni, és minden úgy jelenik meg, ahogyan szeretnénk, de ilyenkor – értelemszerűen egy p ul li { … } nem fog működni, mivel a HTML kód értelmezése után az UL elem nem a P elemen belül lesz.

A helyes HTML kód egy felsorolást, táblázatokat tartalmazó oldal esetén az tehát, hogy a paragrafus elemeken kívülre helyezzük a felsorolás elem külső elemét (UL, OL), a táblázat befoglaló elemét (TABLE), az idézeteket (BLOCKQUOTE), a formokat (FORM), ésatöbbi. Ekkor gondolkodik el az ember azon, hogy csakazértis megkerüli a dolgot, és paragrafus elemek helyett akkor majd használ DIV-eket. Sokszor tettem ilyet én is, de nem tartom szép megoldásnak.

Azt megtudtuk, hogy a táblázatoknak paragrafuson kívül van a helyük, de azt még nem, hogy a táblázatok celláiban lehet-e paragrafus, felsorolás, vagy bármilyen más block elem. Lehet. A TD és TH elemek tartalmazhatnak más “block” elemeket, de lehet beléjük egyből “inline” elemeket is elhelyezni.

A következő kérdés, ami felmerülhet az emberben, hogy mi a helyzet a képekkel, hova kell őket tenni? A szabvány szerint egy kép (”inline” elem) lehet mind “block”, mind pedig “inline” elemen belül. Ez első ránézésre azt jelenti, hogy édesmindegy, hogy hova tesszük a képeket. Azonban ha megnézzük, hogy a BODY elem tartalmazhat-e képet, akkor azt fogjuk látni, hogy nem. Ennek értelmében egy képet inkább egy paragrafus, felsorolás vagy hasonló “block” típusú elemen belülre célszerű elhelyezni. Ide egy távolabbra vivő gondolatmorzsa: az IMG elemet mindenképpen a szöveges tartalom részeként kezeljük! IMG elemet ne használjunk díszítő elemként, logóként, hanem illusztációként szolgáljon, egy szövegfolyamon belül. Erre van. A miértet itt most nem részletezném.

Maradva a képeknél, egy jó gyakorlat nekik valamilyen általános osztályt definiálni (class-t), mely azt szabályozza, hogy balra, vagy jobbra legyenek illesztve a szövegfolyamon belül (jellemzően class=”left”, class=”right”). A CSS-ből értelemszerűen pedig bal és jobb oldali margókat definiálni, attól függően, hogy melyik oldalra van éppen az adott kép illeszve a float-tal. Ezt sokan is használják így. Akkor kell elgondolkodni, főként a fentiek függvényében, amikor a megrendelő szeretne képaláírást is. Az első gondolata ilyenkor az embernek, hogy akkor nekünk most egy képdobozra van szükségünk, használjunk tehát egy DIV elemet a kép körül, és annak adjuk meg a “left” és “right” class-okat. Azonban paragrafus elem nem tartalmazhat DIV elemeket! Tovább bonyolítva a kérdést, mi a helyzet akkor, ha a megrendelő egy paragrafuson belülre szövegdobozt szeretne? Paragrafuson belüle mint tudjuk, nem lehet másik P, BLOCKQUOTE vagy hasonló elem.

Két használható megoldást ismerek.

A kép esetében az egyik megoldás – ha a paragrafushoz kapcsolódónak érezzük a képet -, hogy SPAN elembe tesszük a hozzá tartozó képaláírással együtt, majd a SPAN elemet float-oljuk. Ugyanezt tehetjük a szövegdobozzal is – ha egy idézetről beszélünk, akkor tegyük egy Q elembe, és floatolhatjuk bátran. Ez utóbbi esetben viszont nem állhat több paragrafusból a szövegdoboz. A BR-t mint megoldást, vagy paragrafust jelölő SPAN elemeket felejtsük el.

A másik megoldás, mely képek esetében inkább valamilyen nem egy paragrafushoz, hanem általános kép beszúrására, szövegdoboz esetén pedig hosszabb, kiegészítő, akár több bekezdésből álló szöveg beszúrására alkalmas, hogy ezeket a tartalmakat a paragrafuson kívülre helyezzük – ahogy azt maga a szabvány is sugallja. Ha egy bekezdés elejére szeretnénk egy szövegdobozt, képet elhelyezni, akkor tegyük a dobozt/képet a bekezdés elé, és egyszereűen float-oljuk.

Még egy problémás HTML használatot emelnék ki, mégpedig azt, amikor egy UL elembe tesz valaki UL elemet. A HTML elem szerint több szintű listánál az LI elembe kell helyeznünk egy az az alá az elem alá tartozó további szintet. Egy ilyen szabványos többszintű listát mondjuk nem triviális feladat programból előállítani, de szintén csak bonyodalmaink lehetnek a böngészők automatikus korrekciója miatt, ha szépen szeretnénk formázni az ilyen listákat.

Ne vigyük túlzásba a DIV elemeket és olvasgassuk a szabványt (ez egy kivonatos változata) – érdemes.

9 Hozzászólás - “A “block” és “inline” elemekről”


  • Azért azt tegyük hozzá, hogy a szzabvány szerint nem csak ‘block’ és ‘inline’ elemek vannak. [http://www.w3.org/TR/CSS21/visuren.html#propdef-display]

    Ha megnézzük a HTML4-re értelmezett alap CSS-t [http://www.w3.org/TR/CSS21/sample.html], ott is láthatjuk, hogy csomó másik display típus használva, definiálva van.

    Igen, IE nem értelmezi az ‘inline’ és ‘block’ típusoktól eltérő display tulajdonságot — pontosabban az ‘inline-block’-ot ismeri Firefox-szal ellentétben –, de attól még létezik, és remélhetőleg a közeljövőben IE8(9?) is tudni fogja a lekezelését.

  • Adam, ne keverd ide a CSS-t! Pont arról írtam, hogy a HTML “block” és “inline” kategóriái a struktúrát írják le, és nem a megjelenítést. A megjelenítést illetően igen, vannak más módok (”véletlenül” hasonló nevekkel), melyeket konkrét elemekhez kapcsolhatunk, de ez egy teljesen másik kérdés. Az, hogy egy “block” kategóriájú HTML elemhez milyen megjelenítést párosítasz, az édesmindegy abból a szempontból, hogy egy HTML dokumentumban mi megengedett és mi tiltott.

  • Csak nem állom meg: paragrafus alatt a magyarban nem bekezdést értünk.

  • Ceriak, igazad van, de most már nem írom át. A kontextusból azért gondolom érthető a dolog.

  • szokták mondani, h minden latin szónak 3 jelentése van.
    a paragrafus szakasz, cikkely, bekezdés. kétségtelen, h a törvényszakasz, törvénycikkely értelme az elsődleges, de ettől még bekezdést is értünk rajta.

  • Azt tudjuk, ha egy inline elemnek css-ben block-ot adunk attól nem lesz blokk szintű elem, ez vonatkozik fordított esetben is? Tehát egy p elembe illesztett span aminek css-ben block-ra állítom a tulajdonságát, attól még szabályos hogy a p elemben van igaz?

    Tudomásom szerint a q elem használatát “erősen nem javasolják” most hirtelen nem ugrik be milyen megfontolásból, de utána nézek…
    Van erre valami alternatíva, tehát ha nem q és nem blocquote akkor mi?

  • docker, a megjelenítés (CSS) és a leírás (HTML) nincsen hatással egymásra abból a szempontból, hogy helyes, valid lesz-e a HTML vagy nem. Így “tökmindegy”, hogy a CSS-ben “block” megjelenésűre van állítva a P elemen belüli SPAN, a HTML-t ez nem fogja zavarni. Hozzáteszem, hogy egyrészt lehet, hogy az adott böngésző, kliens nem támogatja éppen a CSS-t, és anélkül jeleníti meg a dokumentumot, lehet, hogy éppen nem megjeleníti, hanem felolvassa, esetleg feldolgozza. És több CSS-t is rendelhetünk egy dokumentumhoz, általános böngészőkre, mobil böngészőkre és nyomtatókra optimalizálva a megjelenést.

    A Q elem “nem javasolt” voltáról még nem hallottam, nem tudom, hogy miért ne lehetne használni. Ha van konkrét infó, az jöhet, szerintem nyugodtan lehet használni.

  • A HTML Mastery c. könyvben olvastam róla, habár nem olyan egetrengető probléma, csak a szerző oly mértékben tiltakozik, hogy ez ragadt meg bennem.

    Arról van szó, hogy bizonyos böngészők behelyeznek idézetre utaló jelöléseket (”), némelyek pedig nem, valamint a nyelv megadásával történhet ez nyelvi területre vonatkozóan.
    Ezen tulajdonsága miatt nem lehet egységesen kezelni.
    a q {quotes: none} CSS beállítás megoldással szolgálhata problémára, de azt Safarinál el is felejthetjük.

    Valahogy emígyen volt fogalmazva…

  • Docker, igen, erről tudok, de nem érzem katasztrófának. :) Egyébként ha lesz egy kis időm, akkor megnézem mennyire gáz a mostani böngészőkkel.

Te mit gondolsz?