Firefox stellt <p>-Tag nicht dar

[alex]

Hallo,

hier mein Problem:

Ich habe eine Liste von Bildern die ich nebeneinander darstellen will. Um die liste habe ich einen <p>-Tag gelegt. EIgentlich sollte dann der nächste Inhalt in einer neuen Zeile beginnen. Im IE funktioniert das auch. Im FF jedoch nicht. Woran liegts?Hier mein Code:

<p>  
    <div id="screen">  
     <ul>  
      <li><img src="bilder/screen_egr_01.png"/></li>  
      <li><img src="bilder/screen_egr_02.png"/></li>  
      <li><img src="bilder/screen_egr_03.png"/></li>  
     </ul>  
    </div>  
   </p>  
   <p>  
     <a href="pdf/praktikumsbericht.pdf" target="_blank"><img src="bilder/pdf_icon.png" border="0"/>praktikumsbericht.pdf (78 KB)</a>  
   </p>

CSS-Code:

#screen ul{  
 margin:0;  
 padding:0;  
 list-style-type:none;  
 width:780px;  
}  
  
#screen ul li{  
 display:block;  
 float:left;  
 margin-right:20px;  
 margin-left:0px;  
 margin-top:0px;  
 margin-bottom:0px;  
}

[Ole]

Hallo Alex,

ich vermute der Link wird bei dir neben deinen Listenelementen angezeigt, daher die Problembeschreibung.

Die Ursache ist, dass deine Listenelemente float, dieses float aber nicht gecleart wird. Abgesehen davon ist dein Quelltext...sagen wir mal verbesserungswürdig :).

Das p um das div ist imho nicht valide und auch überflüssig, wie das div eigentlich auch.

Wenn du dem zweiten p ein "clear: left;" mitgibst, wird der Umfluss deiner Listenelemente beendet und der Absatz erscheint unterhalb.

Gruß
Ole
(8-)>

[EKKi]

Mahlzeit alex,

Ich habe eine Liste von Bildern die ich nebeneinander darstellen will. Um die liste habe ich einen <p>-Tag gelegt. EIgentlich sollte dann der nächste Inhalt in einer neuen Zeile beginnen. Im IE funktioniert das auch. Im FF jedoch nicht. Woran liegts?

Daran, dass der IE bei invalidem HTML gern mal rät und irgendwas darstellt: <http://de.selfhtml.org/html/referenz/elemente.htm#p@title=ein <p> darf nur #PCDATA und Inline-Elemente beinhalten> - ein <div> ist jedoch ein http://de.selfhtml.org/html/referenz/elemente.htm#block_elemente@title=Block-Element.

Was soll das <div> da überhaupt? Es ist komplett überflüssig.

Dummerweise würde es wenig ändern, wenn Du es weglässt, <http://de.selfhtml.org/html/referenz/elemente.htm#block_elemente@title=da auch <ul> ein Blockelement ist> ... überdenke Deinen Code.

MfG,
EKKi

[LX]

Im IE funktioniert das auch. Im FF jedoch nicht.

Mit solchen Beschreibungen kommst Du nicht weit. Du solltest davon ausgehen, dass FF ein Beispiel für standardkonformes Verhalten ist und der IE vom Standard abweicht.

In diesem Fall haben wir ein gutes Beispiel für die Unfähigkeit des IE, gefloatete Elemente korrekt zu behandeln.

Wie schon der weise Pongfuzius sagte: "Wo ein Ping, da ein Pong. Wo ein Float, da ein Clear".

Gruß, LX

[Gunnar Bittersmann]

@@alex:

Ich habe eine Liste von Bildern die ich nebeneinander darstellen will. Um die liste habe ich einen <p>-Tag gelegt.

Nein, hast du nicht.

1. Kein Tag, sondern ein Element. [Meiert]

2. Da 'p' kein 'div' enthalten darf, wird das 'p'-Element durch das <div>-Starttag implizit geschlossen:

<p><div id="screen"></div> ist in HTML 4.01 dasselbe wie <p></p><div id="screen"></div>

Das </p>-Endtag nach </div> ist ein HTML-Fehler. Das hätte dir der Validator auch verraten.

Live long and prosper,
Gunnar

[Jens Holzkämper]

Tach,

2. Da 'p' kein 'div' enthalten darf, wird das 'p'-Element durch das <div>-Starttag implizit geschlossen:

die Schreibweise des img-Elements legt allerdings nahe, dass er XHTML schreibt, dort gibt es kein implizites Schließen mehr auch wenn die Browser das nicht so handhaben.

mfg
Woodfighter

[Gunnar Bittersmann]

@@Jens Holzkämper:

2. Da 'p' kein 'div' enthalten darf, wird das 'p'-Element durch das <div>-Starttag implizit geschlossen:

die Schreibweise des img-Elements legt allerdings nahe, dass er XHTML schreibt, dort gibt es kein implizites Schließen mehr auch wenn die Browser das nicht so handhaben.

Warum sollten sie es auch nicht so handhaben, wenn sie das XHTML als 'text/hrml' verarbeiten?

Bei der Validierung gegen XHTML hätte es zwar eine andere, aber dennoch eine Fehlermeldung gegeben.

Live long and prosper,
Gunnar

[suit]

Bei der Validierung gegen XHTML hätte es zwar eine andere, aber dennoch eine Fehlermeldung gegeben.

bei der verarbeitung als application/xml oder application/xhtml+xml wäre die parser vermutlich gestorben - aufgrund dem nicht wohlgeformten code

[at]

Hallo.

Warum sollten sie es auch nicht so handhaben, wenn sie das XHTML als 'text/hrml' verarbeiten?

Schließlich steht text/hrml für Text/harmlos.
MfG, at