Skrivet av kevvs:
Helt korrekt. Jag skulle tippa på att det är för att paragraf är ett block-element medans span är ett inline-element.
Correctamundo . Ett inline-objekt upptar den bredd innehållet kräver. Att säga `text-align: right` till ett inline-element är att säga "lägg ditt innehåll längst till höger i denna box du skapat för att vara precis så bred som innehållet", vilket man ju förstår, om man tänker på meningen ett par gånger, inte kommer ge någon synlig skillnad alls.
Bredden av ett blockelement däremot är som standard bredden hos dess "container" oavsett innehåll. Alltså är det här möjligt att säga t ex "lägg ditt innehåll längst till höger i din box".
<p> är `display: block` som standard; <span> är `display: inline`. Det är möjligt att ändra dessa saker via CSS, men med måtta och eftertanke, då det kan leda till oväntade renderingar i olika webläsare. Det är inte tillåtet att ha block-element inuti inline-element (även om HTML5 reviderat detta en aning: man kan nu ha block-taggar inuti <a>-element), och olika block-element följer olika extraregler som bör/ska följas för att undvika problem. <p> kan inte innehålla block-element; <form> ska bara innehålla blockelement, etc. Även om man ändrar presentation via CSS så har HTML-parsern redan använt standardantaganden innan CSS laddats för att bygga upp sitt taggträd. Det är ingen slump att attributet heter just "display" och inget mer fundamentalt.
Exempel: försöker man trycka in block-element i <p>:
<p>Hej hopp, <div>här kommer ett block</div> och nu är det slut.</p>
så kommer DOM-parsern tolka detta som
<p>Hej hopp, </p>
<div>här kommer ett block</div>
och nu är det slut.</p>
Sista raden ligger utanför <p>-elementet, sista taggen stänger ingenting, och man ser att parsern inte tolkar så som författaren troligen tänkt. Detta gör att uppmärkningen i första kodrutan ovan i en webbläsare kommer renderas som:
Citat:
Hej hopp,
här kommer ett block
och nu är det slut.
Sätts `p {color: red;}` i CSS så fås:
Citat:
Hej hopp,
här kommer ett block
och nu är det slut.
Lägger vi till `div {display: inline;}` så ser vi problematiken med att tolkningen sker innan CSS kommer med i bilden:
Citat:
Hej hopp,
här kommer ett block och nu är det slut.
Notera att `color: red` inte har någon inverkan på de avslutande orden och att <div> brutit <p> trots att den satts till `display: inline`. Kort exempel, men det demonstrerar ett beteende som kan vara väldigt förvirrande om man inte har reglerna klara för sig.
Sluttagg för t ex <p> är nästan alltid är helt valbar i HTML, eftersom de implicita blockreglerna ändå tar prioritet. Faktum är att detta gäller många taggar, och ofta även starttaggar. Följande är ett komplett och välformat HTML-dokument:
<!DOCTYPE html>
<title>Taggtabell</title>
<h1>Defaultvärden för displayattributet</h1>
<p>Se tabell 1.
<table>
<caption>Tabell 1</caption>
<thead>
<tr>
<th>Tagg
<th>display
<tbody>
<tr>
<td>p
<td>block
<tr>
<td>span
<td>inline
</table>
Använd t ex "Inspect element" i Chrome på ett sådant dokument för att se hur taggträdet byggs upp helt korrekt (eller kör det i W3C Validator (innan någon klagar : markera att det är UTF-8; en korrekt konfigurerad webbserver hade gjort detta automatiskt, och/eller så hade <meta charset="utf-8"> kunnat läggas till innan <title>, men det spelar ingen roll för poängen), eller läs specifikationen).
Det må se väldigt märkligt avskalat ut om man var med under XHTML-eran då dokumenten skulle parsas som godkänd XML med "självstängande taggar" o dyl, men HTML är inte XML och tolkas inte på samma sätt. Personligen så skulle jag snarare föredra den minimalistiska kodformen ovan framför den ekvivalenta och vanligare formen:
<!DOCTYPE html>
<html>
<head>
<title>Taggtabell</title>
</head>
<body>
<h1>Defaultvärden för displayattributet</h1>
<p>Se tabell 1.</p>
<table>
<caption>Tabell 1</caption>
<thead>
<tr>
<th>Tagg</th>
<th>display</th>
</tr>
</thead>
<tbody>
<tr>
<td>p</td>
<td>block</td>
</tr>
<tr>
<td>span</td>
<td>inline</td>
</tr>
</tbody>
</table>
</body>
</html>
Dold text
Den senare med explicit stängda taggar må se mer konsekvent ut av vana, men den första belyser djupare aspekter av uppmärkningen. Dessutom blir koden i sig mer överblickbar och man slipper skriva en massa uppmärkning som tolken ändå kommer ignorera i bästa fall, eller förvirras av om man skriver fel. Att lära sig i vilka situationer taggar behöver stängas eller ej ger insikt i HTML:s DOM-tolkning.
Det kan nämnas att det finns lägen då man medvetet bör ha med generellt valbara stängande taggar för att exempelvis undvika att släpa med sig vitutrymme på oväntade sätt. Detta är i praktiken rätt sällan ett problem, i min erfarenhet, och det syns direkt om man exempelvis tittar i debuggningsverktyg. Jag tror det är fler som har haft problem med situationer likt mitt tidigare exempel med implicita taggstängningar som kodaren inte förväntar sig.
Inte för att det är ett argument i sig, men i Googles interna riktlinjer för HTML så rekommenderas det att skippa alla överflödiga taggar i uppmärkningen:
[quote=Google HTML/CSS Style Guide]For file size optimization and scannability purposes, consider omitting optional tags. The HTML5 specification defines what tags can be omitted.
(This approach may require a grace period to be established as a wider guideline as it’s significantly different from what web developers are typically taught. For consistency and simplicity reasons it’s best served omitting all optional tags, not just a selection.)
<!-- Not recommended -->
<!DOCTYPE html>
<html>
<head>
<title>Spending money, spending bytes</title>
</head>
<body>
<p>Sic.</p>
</body>
</html>
<!-- Recommended -->
<!DOCTYPE html>
<title>Saving money, saving bytes</title>
<p>Qed.
[/quote]
Dold text
I deras motivation ligger alltså att det minskar mängden data som behöver överföras, vilket ger snabbare sidor och sparar mätbara mängder pengar om man erbjuder tjänster i deras storlek, men även att det förenklar underhåll där det ofta (inom gränser) är eftersträvansvärt med mindre mängd kod för samma resultat.
Det är viktigt att veta hur HTML tolkas för att undvika problem så som de i denna tråd. Är man inte medveten om skillnaden mellan `block` och `inline` och HTML:s implicita taggtolkningar så fastnar man snabbt i oförståeliga problem.
