[CSS / HTML] Nesting paragraphs

[BratMokstrof]

Ik heb een CSS met de volgende syntax:

code:

p.quote {
  margin: 0px;
  border-left: 2px solid #A4241A;
  padding-bottom: 0px;
  padding-left: 4px;
}

Echter, als ik nu het volgende draai:

code:

<P CLASS = "quote">Test
    <P CLASS = "quote">Test2
    </P>
</P>

Krijg ik niet dat er 2 lijntjes komen
Dat wil ik wel (heel graag)...

Hoe komt dat?

Thnx!

[Verwijderd]

Gewoon blockquote gebruiken. Paragrafen mag je niet nesten. Dat is trouwens heel logisch.

[BratMokstrof]

Verwijderd schreef op woensdag 13 april 2005 @ 00:13:
Gewoon blockquote gebruiken. Paragrafen mag je niet nesten. Dat is trouwens heel logisch.

Sommige dingen zijn heel logisch, maar het moet je even verteld worden dat het logisch is
Nu je het zegt ... Ja, logisch.

Thnx voor je korte (maar prima) antwoord, het is opgelost.

Sorry voor deze wellicht "domme" vraag, maar ik had nooit van de blockquote gehoord.

Thnx dus

[simon]

je html moet net zo zijn als dat je een tekst maakt. En ja, in teksten heb je niet een paragraaf ín een paragraaf. Dan krijg je eerder een quote. En beide kun je totaal opmaken.

[Verwijderd]

Of gebruik div-jes. Hoef je alleen maar het woord div te onthouden /me Fate? rent snel weg voor de semantische tomatengooiers

[Woudloper]

divjes gebruiken is geen goede optie als je het mij vraagt. Om een quote te doen moet je geen gebruik maken van divs.

Overigens lijk mij de volgende opbouw het beste:

HTML:

<p>Hieronder een citaat uit een mooi boek:</p>
 <blockquote>
  <p>citaat alinea 1 en verder</p>
  <p>citaat alinea 2 en verder</p>
 </blockquote>
<p>Zoals jullie kunnen lezen bla bla bla</p>

[ Voor 19% gewijzigd door Woudloper op 13-04-2005 09:24 . Reden: wijzigingen n.a.v. post mophor ]

[Verwijderd]

mij niet (gooit tomaat)

een blockquote hoort niet in een p (die je overigens in het nederlands beter "alinea" kan noemen, dus:

HTML:

<p>Hieronder een citaat uit een mooi boek:</p>
<blockquote>
  <p>citaat paragraaf 1 en verder</p>
  <p>citaat paragraaf 2 en verder</p>
</blockquote>

[Verwijderd]

En als ik nu eens zeg dat ik zelf wel bepaal hoe het eruit gaat zien? Of moet ik alles gaan overriden met CSS? Een beetje nutteloos als je het mij vraagt.

edit:
[quote]Verwijderd schreef op woensdag 13 april 2005 @ 09:19:
mij niet (gooit tomaat)
[/quote]
Hèhè, stond gelukkig iemand tussen

[ Voor 44% gewijzigd door Verwijderd op 13-04-2005 09:26 ]

[simon]

Verwijderd schreef op woensdag 13 april 2005 @ 09:21:
En als ik nu eens zeg dat ik zelf wel bepaal hoe het eruit gaat zien? Of moet ik alles gaan overriden met CSS? Een beetje nutteloos als je het mij vraagt.

je override niets met css. Je maakt het op. Je geeft die elementen een uiterlijk. Je scheidt uiterlijk van inhoud. Op deze methode kan elke sjap de flap er een nieuwe draai aan geven, en dat is juist zo mooi aan CSS.

[RM-rf]

Verwijderd schreef op woensdag 13 april 2005 @ 08:55:
Of gebruik div-jes. Hoef je alleen maar het woord div te onthouden

Verwijderd schreef op woensdag 13 april 2005 @ 09:21:
En als ik nu eens zeg dat ik zelf wel bepaal hoe het eruit gaat zien? Of moet ik alles gaan overriden met CSS? Een beetje nutteloos als je het mij vraagt.

Als je het vergelijkt met programmeren, kun je dat idee zien als een programmeur die gebruik maakt van 'string variabele1', 'string variabele2', 'int variabele3', 'array variabele4' en 'functie1()', 'functie2()'....

een programma zal daar niet slechter of beter van werken .. en veel beginnende programmeur hebben een neiging zo te werken ...

zodra je wat dieper in de materie gaat kijken, merk je zelf ook het belang van consistente en vooral beschrijvende naamgeving ...

In het geval van semantische HTML is het ook zo dat een goed semanticus realisert dat 'layout', of een element randjes en een kleurtje krijgt weinig zegt over de onderliggende structuur, maar deze zal proberen om zijn code zelf al qua structuur 'beschrijvend' te maken.

Over de begin-vraag, waarom je P-elementen (alinea's) niet mag nesten: een alinea is een "tekstgedeelte dat op een nieuwe regel begint en doorloopt tot de volgende nieuwe regel" (Van Dale) ... op het moment dat je een hardbreak _in_ een alinea creeert, deel je die alinea op in twee afgescheiden alinea's ... omdat een alinea nu eenmaal gedefinieert is door zijn afscheiding.

[ Voor 7% gewijzigd door RM-rf op 13-04-2005 09:50 ]

[Verwijderd]

Ik denk dat je het anders moet zien:

Het verschil tussen "div" en "blockquote" is dat de één leeg is en de de andere een bepaalde waarde invulling heeft.

Iemand die een array declareert wil niet dat er al elementen in zitten of zelfs al elementen met een waarde toekenning. Dat is maar zelden bruikbaar.

Wat naamgeving betreft:

<div class="blockquote"> kan misschien iets lastiger zijn voor de leek om te lezen maar ik denk dat het net zo duidelijk is als <blockqoute>.

Ik onderken zeker wel het belang van semantiek maar zorg dat opmaak ook werkelijk aan css toebedeeld wordt. Dus een element als "blockqoute" zou dan specifieke css properties toegewezen moeten krijgen die alleen daarbij toegepast kunnen worden.

De vraag is of het dan allemaal niet nodeloos ingewikkeld wordt. Als je het vrij laat en hebt, laten we zeggen, twee elementen "span" en "div" en laat de ontwikkelaar zelf de verantwoordelijkheid nemen voor een layout en naamgeving. Veel zullen er een rommeltje van maken maar het zal in iedergeval eenduidiger worden dan dat het nu het geval is.(Specifieke elementen zoals "a" en "img" worden niet vergeten natuurlijk)

Moraal: minder html meer css.

Zoekmachines? Tja, google heeft al genoeg geld verdient dus een nieuw algoritme kan er wel af (Css lezen!)
Hmm, een uitzondering. Een lang verhaal.. Maar tegen de semantieken in gaan is wel leuk natuurlijk

[ Voor 5% gewijzigd door Verwijderd op 13-04-2005 10:42 ]

[Verwijderd]

meen je dit nu serieus? het is allemaal klets imho

weet je nog waar HTML voor uitgevonden is?

[curry684]

Verwijderd schreef op woensdag 13 april 2005 @ 09:21:
En als ik nu eens zeg dat ik zelf wel bepaal hoe het eruit gaat zien? Of moet ik alles gaan overriden met CSS? Een beetje nutteloos als je het mij vraagt.

Een document moet zonder stylesheet en in tekst-only, braille- of voorleesbrowsers ook nog perfect logisch en bruikbaar zijn, dat is semantiek.

[RM-rf]

Verwijderd schreef op woensdag 13 april 2005 @ 10:39:

Ik onderken zeker wel het belang van semantiek maar zorg dat opmaak ook werkelijk aan css toebedeeld wordt. Dus een element als "blockqoute" zou dan specifieke css properties toegewezen moeten krijgen die alleen daarbij toegepast kunnen worden.

Ik denk dat je de betekenis van 'semantiek' niet begrijpt.. semantiek is géén specifieke layout (al zullen browsers wel al default layoutinstellingen ervoor hebben, dus een P al een eigen 'margin' toekennen), maar is de erkenning dat Hypertekst bestaat uit een verzameling van specifieke tekst-elementen ..

Hooguit kun je beweren dat er een zeker verschil bestaat tussen inline en block-elementen, die erg groot is, en zelf eigenlijk al DTD-invloeden hebben (juist de eigenschap van HTML is die typische neiging tot inline-elementen, daar XML zelf alles eigenlijk poogt te verdelen in 'block-elementen').
Ik kan me voorstellen dat een pagina met enkel nette echte 'block' elementen een stuk sneller en effectiever te renderen is, terwijl al die inline-elementen als STRONG, EM alles een stuk ingewikkelder maken, zowel qua rendering als bv het DOM (denk ook aan innerHTML en textNode[n].Text ... innerHTML was nooit nodig geweest als er geen inline elementen bestonden, oftewel elementen die zich binnen de normale 'flow' van een textNode bevinden)

[ Voor 3% gewijzigd door RM-rf op 13-04-2005 12:04 ]

[Osiris]

Voor de mensen die het echt per see willen weten:

quote: http://www.w3.org/TR/html401/struct/text.html#h-9.3.1

The P element represents a paragraph. It cannot contain block-level elements (including P itself).

[ Voor 9% gewijzigd door Osiris op 13-04-2005 12:11 ]

[Verwijderd]

@ curry684 en RM-rf: Bedankt voor de uitleg.

Maar eigenlijk wordt dus het hele idee van html verkeerd geïnterpreteerd door de browsers. <strong>, <em>, <h1>, etc. hebben al een duidelijke opmaak in zich. Dit is voor mij een punt om ze niet te gebruiken.

Dus dan zou er in feite een soort extra code aan empty elementen/blocks meegegeven moeten worden voor de semantiek.

Een voorbeeld:

<div code:h1 class="My_custom_Head">
of
<span code:strong class="My_bold_Chars">

Dit zou dan mijn ideale html zijn.

[ Voor 8% gewijzigd door Verwijderd op 13-04-2005 13:12 ]

[curry684]

Verwijderd schreef op woensdag 13 april 2005 @ 13:12:
@ curry684 en RM-rf: Bedankt voor de uitleg.

Maar eigenlijk wordt dus het hele idee van html verkeerd geïnterpreteerd door de browsers. <strong>, <em>, <h1>, etc. hebben al een duidelijke opmaak in zich. Dit is voor mij een punt om ze niet te gebruiken.

Ow? Hoezo hebben die elementen opmaak? Het zijn puur semantische elementen, namelijk "dit stuk tekst heeft kracht", "dit stuk tekst heeft nadruk" en "dit is een kop voor de rest". Het feit dat de default stylesheet van de meeste browsers ze respectievelijk bold, italic en op ~200% rendert is wurscht, dat kun je zelf door het cascading effect van stylesheets zo overriden.

Specifiek <strong> en <em> zijn semantisch extreem correcte elementen: ze kunnen namelijk in tegenstelling tot <b> en <i> wel op ieder medium (dus ook een spraakbrowser!) gerenderd worden. Maar ook daar geldt dat 100 verschillende mensen allemaal op een andere manier nadruk leggen op een (stuk) zin, dus ook daar zit een verschil in de presentatie terwijl het semantisch identiek is

[blizt]

En als jij een div neerzet, dan heeft deze bijna geen opmaak. Hier ben je wel tevreden mee?
Tja, ik denk dat je dan de schuld aan de browser moet geven ... Maar het idee achter HTML/CSS is juist (zoals eerder gezegd), dat je de boel er mee opmaakt.
Snap niet wat er nu zoveel erger aan is om dit te doen:

code:

strong
{
font-weight:normal;
color:red;
}

i.p.v.:

code:

div.myBoldChars /* lekkere naam bedenk je ook zeg ;x */
{
color:red;
}

Maar misschien mis ik je punt?

[curry684]

Verwijderd schreef op woensdag 13 april 2005 @ 13:12:
@ curry684 en RM-rf: Bedankt voor de uitleg.

Maar eigenlijk wordt dus het hele idee van html verkeerd geïnterpreteerd door de browsers. <strong>, <em>, <h1>, etc. hebben al een duidelijke opmaak in zich. Dit is voor mij een punt om ze niet te gebruiken.

Als ik trouwens naar je website kijk heb je de scheiding tussen HTML en CSS sowieso niet zo goed door Ik citeer:

HTML:

        <div class="f_6D6A69_tagger" style="cursor:help" onmousedown="ViewAlert();">
            (Info 18-03-2005 [dd-mm-yyyy]) 
        </div>

Grofste fout natuurlijk is het gebruik van de classname "f_6D6A69_tagger", waarmee je alsnog de kleur van het element in je HTML vastlegt en heel CSS overbodig maakt. Dat is net zoiets als <div class="bold"> gebruiken en dan .bold { font-weight:bold; } in je CSS zetten: volstrekt nutteloos. De semantiek houdt juist in dat je meaningful elements, id's en classnames moet gebruiken. In dit geval betreft het een tekstparagraaf die info verschaft. Doe het dan gewoon zo:

code:

<p class="info" onmousedown="ViewAlert();">(Info 18-03-2005 [dd-mm-yyyy])</p>

Cascading Stylesheet:

p.info { 
  font-size:90%;
  color:#6D6A69;
  cursor:help;
}

Op die manier is je HTML zuiver en krijg je geen conflicten als je dadelijk besluit dat die tekst in groen moet, want eigenlijk moet je in dat geval nu alle classnames gaan wijzigen

Ben je trouwens bekend met het concept <ul> om bulleted lists te maken? Dit is namelijk wel extreem enge HTML:

code:

                    <span class="f_FCE34A_tagger">&#8226;</span>&nbsp;&nbsp;&nbsp;The HTML tags are coloured.<br />

                    <span class="f_916F2C_tagger">&#8226;</span>&nbsp;&nbsp;&nbsp;The changed text is coloured gray. You are be able to see what is changed at a single glance.<br />
                    <span class="f_FCE34A_tagger">&#8226;</span>&nbsp;&nbsp;&nbsp;Highlight code to find back certain parts very fast<br />
                    <span class="f_916F2C_tagger">&#8226;</span>&nbsp;&nbsp;&nbsp;Excellent and unlimited undo/redo tools<br />
...etc...

[Verwijderd]

Ik vroeg me al af wanneer het ging komen .

In iedergeval is het één en ander een stuk duidelijker geworden. T.z.t zal ik zo veel mogelijk fouten er wel uit gaan halen of gewoon vervangen.

(Of ik kan solliciteren naar de job Director of the W3 organization )