nicht angemeldet
Frameset erzwingen?!
0 0
Frameset erzwingen?!
Hallo Forum,
zunächst einmal Hallo, heute ist mein erster Beitrag hier im Forum. Auch ich bin ein reger HTML-Bastler und dabei war Self-html mir immer eine gute Hilfestellung.
Auch diesmal habe ich eine Vorstellung, die ich umsetzen möchte, nur weiss ich nicht wie?!
Folgendes:
Ich habe ein Frameset, folgender Quelltext:
<frameset rows="*,60" border="0" frameborder="0" framespacing="0">
<frame name="headframe" target="headframe" src="home.htm" scrolling="auto" noresize marginwidth="0" marginheight="0">
<frame name="footframe" src="footframe.htm" scrolling="no" target="headframe" marginwidth="0" marginheight="0">
</frameset>
Oben ein grosser Frame, in dem alle angeklickten Seiten auch im selben Fenster wieder geöffnet werden. Unten eine kleiner Zusatzframe mit einer permanent sichtbaren (!) Seite, die quasi immer erscheinen soll. Klicke ich also im oberen Frame eine Seite und will diese in einem neuen Browserfenster öffnen, öffnet sich natürlich ein neues Fenster mit entsprechender Seite. Der untere Frame fehlt dann aber.
Ich will, dass wenn ich Seite aus dem oberen Frame in einem neuen Fenster öffne oder direkt linke, diese vollständig im gewünschten Frame angezeigt werden, ohne dass ich zu jeder Seite ein neues Frameset schreiben muss, schliesslich habe ich zahlreiche Inhalte.
Ich habe irgendwo im Internet - blöderweise weiss ich die URL nicht mehr - eine passende Lösung des Problems gesehen. Mittels irgendeinem JavaSkript - Codes wird quasi ein Frameset erzwungen, sodass binnen kurzer Zeit die einfache Seite ins Frameset umspringt, sprich auch mit dem unteren Frame; oben die gewünschte Seite. Der entsprechende Quelltext ist mir leider unbekannt.
Toll wäre es, wenn mir jemand eine ähnliche Lösung erleutern kann, oder den erforderlichen Quelltext mit kurzer Erklärung zum Verständnis geben kann. Das ganze möglichst schnell natürlich.
RIESEN Dank im Vorraus. Ansonsten stöber ich mal zum Spass im Forum, vielleicht kann ich hier und da auch eine Antwort beisteuern.
CYA
Euer Christian
-
Noch eine Frage, aber ist nicht unbedingt wichtig. Mich hat es gestört, dass bei Opera im unteren Frame die Seite kompakter interpretiert wird (fällt eigentlich nicht auf).
Wie kann man es erwirken, dass Opera die Breite und Höhe wie IE interpretiert ? (Stichwort Doctype?)
Auch hierfür danke im Vorraus ;-)
CYA
Christian -
Hallo, Christian,
zunächst einmal Hallo, heute ist mein erster Beitrag hier im Forum. Auch ich bin ein reger HTML-Bastler und dabei war Self-html mir immer eine gute Hilfestellung.
Die Freude ist ganz meinerseits. ;)
[...] Klicke ich also im oberen Frame eine Seite und will diese in einem neuen Browserfenster öffnen, öffnet sich natürlich ein neues Fenster mit entsprechender Seite. Der untere Frame fehlt dann aber.
Ich will, dass wenn ich Seite aus dem oberen Frame in einem neuen Fenster öffne oder direkt linke, diese vollständig im gewünschten Frame angezeigt werden, ohne dass ich zu jeder Seite ein neues Frameset schreiben muss, schliesslich habe ich zahlreiche Inhalte.
Richtig, das hast du soweit sehr treffend erkannt. Eine Möglichkeit, wie du bereits sagst, wäre natürlich, für jede Unterseite ein Frameset zu schreiben - glücklicherweise ist das nicht nötig, da du das Frameset mit Parametern versorgen kannst und die Frames dynamisch füllen kannst (in diesem Fall den oberen Frame, denn der ändert sich).
Ich habe irgendwo im Internet - blöderweise weiss ich die URL nicht mehr - eine passende Lösung des Problems gesehen. Mittels irgendeinem JavaSkript - Codes wird quasi ein Frameset erzwungen, sodass binnen kurzer Zeit die einfache Seite ins Frameset umspringt, sprich auch mit dem unteren Frame; oben die gewünschte Seite. Der entsprechende Quelltext ist mir leider unbekannt.
Exakt beschrieben, genauso funktioniert der Mechanismus. Es handelt sich dabei wahrscheinlich um eine Methode, wie sie im Artikel http://aktuell.de.selfhtml.org/artikel/javascript/dyn-frames/index.htm beschrieben wurde.
Dabei enthält jede Unterseite ein JavaScript-Code, welcher überprüft, ob die Seite im Frameset geladen wurde, das geht beispielsweise über window.name, welches in deinem Fall im positiven Falle »headframe« heißen müsste, oder über parent.headframe, also die Überprüfung, ob im darüberliegenden Frame (sofern vorhanden) ein Frame beziehungsweise Fensterobjekt namens »headframe« existiert.Falls kein Frameset gefunden wird, wird das Frameset-Dokument annavigiert (über location.href, http://selfhtml.teamone.de/javascript/objekte/location.htm#href). Dieser Frameset-Ressource wird aber über den Query String, das ist der Bestandteil der URL, welcher nach dem ? (Fragezeichen) folgt, die Adresse der aktuellen Unterseite übergeben, genauer gesagt der Pathname, das ist beispielsweise der folgende Teil:
http://www.domain.de/verzeichnis/unterseite123.html
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Wie in http://aktuell.de.selfhtml.org/artikel/javascript/dyn-frames/index.htm#a3 beschrieben, sieht die Adresse des Framesets inklusive dem Parameter dann beispielsweise folgendermaßen aus:http://www.domain.de/frameset.html?/verzeichnis/unterseite123.html
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
oder wahrscheinlich mit url-encodetem Parameter:
http://www.domain.de/frameset.html?%2Fverzeichnis%2Funterseite123.html
(Sofern ich mich nicht irre. ;))Im Frameset kann nun dieser Parameter, der Query String (siehe auch: http://selfhtml.teamone.de/cgiperl/intro/umgebungsvariablen.htm#uebersicht), entweder serverseitig beispielsweise über Perl oder PHP oder clientseitig über JavaScript ausgelesen werden. In dem genannten Artikel ist die JavaScript-Lösung geschildert, ich würde jedoch eine serverseitige Lösung empfehlen, da du dadurch Links zu den Frameset-Seiten mit dem jeweiligen Parameter setzen kannst, ohne dass der Benutzer JavaScript aktiviert haben muss; das dürfte auch eventuell für Suchmaschinen interessant sein. Eine solche Variante mit Perl oder PHP ist im Artikel http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/index.htm beschrieben. Im Frameset-Script wird der Query String ausgelesen und einfach als src-Attributwert in das betreffende frame-Element geschrieben (sofern Parameter übergeben wurden, ansonsten wird die Startseite eingebunden).
Toll wäre es, wenn mir jemand eine ähnliche Lösung erleutern kann, oder den erforderlichen Quelltext mit kurzer Erklärung zum Verständnis geben kann.
Die genannten Artikel erklären sich größtenteils von selbst, die Beispiele sind relativ einfach ohne große Veränderungen einbaubar.
Das ganze möglichst schnell natürlich.
Hehe. Sicherlich.
RIESEN Dank im Vorraus. Ansonsten stöber ich mal zum Spass im Forum, vielleicht kann ich hier und da auch eine Antwort beisteuern.
Immer gerne. ;)
Die Frage mit der Framehöhe, MSIE und Opera verstehe ich nicht ganz - kannst du eventuell eine Beispielseite vorbereiten und hochladen, anhand welcher der Unterschied ersichtlich wird? (Vielleicht helfen auch detaillierte Angaben über die verwendeten Browserversionen, Screnshots wären auch hilfreich, wenn möglich.) Am DOCTYPE liegt es meines Wissens nicht, der Opera 7.x hat zwar neuerdings auch einen DOCTYPE-Switch, also zwei verschiedene Rendermodi, aber die Darstellung von Framesets ist meines Wissens in beiden Browsern unabhängig vom Rendermodus. Welche Dokumenttypdeklarationen verwendest du auf den betreffenden Seiten?
Grüße,
Mathias-
Boah, danke für deine ausführliche Antwort!
Das witzige bei der ganze Angelegenheit, ich verwende keine Doctypes, weil ich eigentlich die Standardeinstellungen der Browser bevorzuge bzw. eher noch nicht die exakte Bedeutung erfasst hatte.Das mit der Frage bezüglich der Höhe und Breite hatte ich hier im Forum aufgeschnappt. Die untere Frame-Seite des folgenden von mir kreirten Rohlings http://home.t-online.de/home/wterme/Chasebase.de/index2.htm wurde z.B. kompakter dargestellt, sodass der Hintergrund im unteren Bereich zu sehen ist (was nicht sein soll) -> Tabelle von der unteren Seite wird bei Opera im GG. zu NS/IE mit weniger als 60 Pixel Höhe interpretiert. Man kann das Problem leicht umgehen, indem ich für diese Seite einfach nur einen simplen schwarzen Hintergrund definiere oder einfach die Tabellenhöhe knallhart auf 60 Pixel festlege, dann gibs dahingehend keine Differenzen in der Darstellung IE/NS zu Opera.
Fazit: Opera interpretiert Tabellenhöhe bei nicht festgelegten Werten anders als Netscape oder mein Favorit IE (anderes Rendering?).
An sich will ich indirekt wissen, ob eine Doctype-Definition erforderlich und inwiefern sich diese Sache auf Opera vornehmlich auswirkt und wie ich bewirken kann, dass unbestimmte (keine konkreten Angaben in Pixel) Tabellenhöhen von allen Browsern auch identisch interpretiert werden.
CYA
Christian-
Hallo,
Das witzige bei der ganze Angelegenheit, ich verwende keine Doctypes, weil ich eigentlich die Standardeinstellungen der Browser bevorzuge bzw. eher noch nicht die exakte Bedeutung erfasst hatte.
Solange du zumeist nur Tabellen für das Layout benutzt und width und padding nicht primär mit CSS vergibst, merkst du die Unterschiede auch nicht in vollster Auswirkung.
Der MSIE interpretiert bis zur Version 6 das CSS-Boxmodell nicht standardgemäß, er bezieht das padding in die Breite der Box mit ein, siehe http://www.fabrice-pascal.de/artikel/ie5boxmodel/. Im MSIE 6 wird nur standardgemäß gerendert, wenn eine voller DOCTYPE (Dokumenttypdeklaration) am Dokumentanfang angegeben ist, ansonsten schaltet er in den Quirks-Modus, in welchem er weiterhin gemäß diesem fehlerhaften Boxmodell anzeigt.
http://gutfeldt.ch/matthias/articles/doctypeswitch/table.html zeigt, welche DOCTYPEs welchen Modus auslösen (natürlich sollte dein Dokument dem entsprechend, das wäre bei dir vermutlich HTML 4.01 Transitional).
Opera 7 ahmt diesen Fehler nach (!), wenn kein DOCTYPE beziehungsweise ein unvollständiger angegeben ist, siehe http://www.opera.com/docs/specs/doctype/.In der Regel solltest du bemüht sein, in allen Browsern - Mozilla hat übrigens auch verschiedene Rendermodi - den standardkonformen Modus anzuschalten, weil du dann meist auf eine einheitliche Darstellung hoffen kannst. Im MSIE 4-5.x müsstest du allerdings im ersten Link genannte Workarounds zur Umgehung des Problems anwenden usw., aber das ist vorerst wahrscheinlich nicht relevant.
Für das beschriebene Problem ist der DOCTYPE aber meines Wissens nicht wichtig, weil bei Tabellen das width/padding-Problem eigentlich nicht vorhanden ist. Da der MSIE auch zusätzlich noch einen komischen Scrollleisten-Bug hat, wenn der standardkonforme Modus angeschaltet ist, würde ich dir explizit zum Quirks-Mode raten. Das hieße entweder kein DOCTYPE (wie jetzt auch schon), oder: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Das mit der Frage bezüglich der Höhe und Breite hatte ich hier im Forum aufgeschnappt. Die untere Frame-Seite des folgenden von mir kreirten Rohlings http://home.t-online.de/home/wterme/Chasebase.de/index2.htm wurde z.B. kompakter dargestellt, sodass der Hintergrund im unteren Bereich zu sehen ist (was nicht sein soll) -> Tabelle von der unteren Seite wird bei Opera im GG. zu NS/IE mit weniger als 60 Pixel Höhe interpretiert.
Zunächst einmal würde ich dir raten, das Markup aufzuräumen, konkret schmeiße erst einmal die font-Element heraus. Im Stylesheet hast du die Schriftgröße bereits in der Einheit px festgelegt - das ist wichtig, denn das font-Element kann nur relative Werte vergeben! Somit würde <font size="1"> je nach eingestellter Standardschriftgröße immer unterschiedlich angezeigt, dies kann ein Grund für die vonn dir beobachteten Differenzen sein.
Ich weiß nicht, ob die Netscape 4.x unterstützen willst, ich würde dir raten, nahezu alle Formatierungen mit Styles vorzunehmen, dadurch hast du in der Regel mehr Kontrolle und hast vor allem eine größere Sicherheit, dass die Regeln wirken, da du Möglichkeiten hast, welche du mit HTML-Formatierungen per se nicht hast.
Du hast bereits im Stylesheet die margins für body abgeschaltet, ich würde das ausdehnen und explizit auch padding deaktivieren, zusätzlich auch die des html-Elements (dürfte im Quirks-Mode irrelevant sein, aber sicher ist sicher):
html,body {margin:0; padding:0;}bgproperties="FIXED" <-- Das kann meines Wissens herausfliegen, da sich das Hintergrundbild sowieso fortsetzt und ein Scrollen sowieso unmöglich ist.
Wozu ist das Hintergrundbild eigentlich nötig...?Zuerst einmal die obere Tabelle, folgendes dürfte reichen:
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr><td><img src="line1000.gif" height="1" width="100%" alt=""></td></tr>
</table>
... das könntest du natürlich auch ohne »blinde Tabelle« lösen, mit <div style="margin:0; padding:0">...</div> würde vermutlich dasselbe bezwecken.Mit den folgenden Styles kannst du das Markup ziemlich verkleinern:
td {color:white; background-color:black; text-align:center;}
table {border-style:none; border-spacing:0; border-collapse:collapse; height:59px}
div {margin:0; padding:0;}
(Die border-Eigenschaften für table sind nicht unbedingt nötig.)Beispielmarkup *ohne Scripts*:
<div><img src="line1000.gif" height="1" width="100%"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%" height="59">
<tr>
<td width="28%"><b>Datum:</b> Sonntag, 16. Februar 2003</td>
<td width="44%"><b>LAST NEWS: </b><marquee width="325">Chasebase.de in neuer Aufmachung (Februar 2003)! <a href="http://home.t-online.de/home/wterme/Chasebase.de/news.htm" target="headframe">Click!</a></marquee></td>
<td width="28%"><i>Du bist Besucher-Nr.:</i><br><img src="countergrafik.png"></td>
</tr>
</table>Hintergrundfarbe und Hintergrundbild von body könntest du auch im Stylesheet (im lokalen, welches nur für die Datei gilt, also im style-Element im head) festlegen.
In wie weit du leftmargin="0" rightmargin="0" usw. verwendest, hängt natürlich davon ab, ob du Netscape 4.x und andere prä-CSS-Browser noch unterstützen willst.Unabhängig von den kosmetischen Änderungen, bei welchen HTML-Formatierungen durch Styles ersetzt werden, zeigt das Beispiel folgendes: Schalte die Innenabstände der Tabelle ab, damit du viel Spielraum hast. Ich würde es nicht zulassen, dass sich die Höhe der Tabelle selbst regelt, die Faktoren, die das beeinflussen könnten, sind zu zahlreich, wenngleich alles festgelegt sein sollte. Eventuell gebe allen td-Elementen zusätzlich eine line-height (http://selfhtml.teamone.de/css/eigenschaften/ausrichtung.htm#line_height), damit die Zeilenhöhe fest ist. Die Tabellenhöhe würde ich fixieren, sodass die Zeilen darin bis auf die Maximalhöhe anwachsen können, ohne die Tabelle zu vergrößern (deshalb kein padding). Das Problem ist nämlich, dass beispielsweise das marquee-Element in manchen Browsern zweizeilig angezeigt wird, Opera 7 ignoriert es anscheinend vollkommen...
Anders herum könntest du die Tabelle natürlich auch mit height:100% formatieren und die weiße Liniengrafik einbeziehen... oder oder oder.
Man kann das Problem leicht umgehen, indem ich für diese Seite einfach nur einen simplen schwarzen Hintergrund definiere oder einfach die Tabellenhöhe knallhart auf 60 Pixel festlege, dann gibs dahingehend keine Differenzen in der Darstellung IE/NS zu Opera.
Das würde ich dir sogar raten (in dem Fall eher 59 Pixel, weil die weiße Grafiklinie oben einen Pixel einnimmt, sofern sie außerhalb der Tabelle untergebracht wird).
Fazit: Opera interpretiert Tabellenhöhe bei nicht festgelegten Werten anders als Netscape oder mein Favorit IE (anderes Rendering?).
Im Grunde genommen sollten sie diese einfache Übung gleich anzeigen, mit dem Rendermodus sollte es nichts zu tun haben (meiner Mutmaßung nach). Ich tippe konkret eher auf die Schriftgröße (wegen den font-Elementen), auf die vertikale Ausrichtung der Counter-Grafik (vielleicht mit vertical-align:bottom herumspielen), auf die line-height (jedoch eher unwahrscheinlich) und auf das marquee-Element, welches nur im MSIE funktioniert.
An sich will ich indirekt wissen, ob eine Doctype-Definition erforderlich und inwiefern sich diese Sache auf Opera vornehmlich auswirkt und wie ich bewirken kann, dass unbestimmte (keine konkreten Angaben in Pixel) Tabellenhöhen von allen Browsern auch identisch interpretiert werden.
Siehe oben, das dürfte keine großen Auswirkungen haben. Auf Opera <7 sowieso nicht, bei den anderne Browsern dürfte es momentan auch keine Unterschiede (für den speziellen Frame) machen.
Verzeihe, wenn ich zu durcheinander geschrieben habe, ;) es gibt viele Verbesserungsmöglichkeiten.
Grüße,
Mathias-
Hi,
Solange du zumeist nur Tabellen für das Layout benutzt und width und padding nicht primär mit CSS vergibst, merkst du die Unterschiede auch nicht in vollster Auswirkung.
Der MSIE interpretiert bis zur Version 6 das CSS-Boxmodell nicht standardgemäß, er bezieht das padding in die Breite der Box mit ein, siehe http://www.fabrice-pascal.de/artikel/ie5boxmodel/. Im MSIE 6 wird nur standardgemäß gerendert, wenn eine voller DOCTYPE (Dokumenttypdeklaration) am Dokumentanfang angegeben ist, ansonsten schaltet er in den Quirks-Modus, in welchem er weiterhin gemäß diesem fehlerhaften Boxmodell anzeigt.
http://gutfeldt.ch/matthias/articles/doctypeswitch/table.html zeigt, welche DOCTYPEs welchen Modus auslösen (natürlich sollte dein Dokument dem entsprechend, das wäre bei dir vermutlich HTML 4.01 Transitional).
Opera 7 ahmt diesen Fehler nach (!), wenn kein DOCTYPE beziehungsweise ein unvollständiger angegeben ist, siehe http://www.opera.com/docs/specs/doctype/.Danke für diese Information. Was diese Grundlagen technischer Hinsicht betrifft, bin ich als Hobbybastler nicht bewandert genug.
In der Regel solltest du bemüht sein, in allen Browsern - Mozilla hat übrigens auch verschiedene Rendermodi - den standardkonformen Modus anzuschalten, weil du dann meist auf eine einheitliche Darstellung hoffen kannst. Im MSIE 4-5.x müsstest du allerdings im ersten Link genannte Workarounds zur Umgehung des Problems anwenden usw., aber das ist vorerst wahrscheinlich nicht relevant.
Wenn es zu Komplikationen kommen sollte, werde ich dahingehend handeln.
Für das beschriebene Problem ist der DOCTYPE aber meines Wissens nicht wichtig, weil bei Tabellen das width/padding-Problem eigentlich nicht vorhanden ist. Da der MSIE auch zusätzlich noch einen komischen Scrollleisten-Bug hat, wenn der standardkonforme Modus angeschaltet ist, würde ich dir explizit zum Quirks-Mode raten. Das hieße entweder kein DOCTYPE (wie jetzt auch schon), oder: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Scrolleisten-Bug ? Was exakt ?
Zunächst einmal würde ich dir raten, das Markup aufzuräumen, konkret schmeiße erst einmal die font-Element heraus. Im Stylesheet hast du die Schriftgröße bereits in der Einheit px festgelegt - das ist wichtig, denn das font-Element kann nur relative Werte vergeben! Somit würde <font size="1"> je nach eingestellter Standardschriftgröße immer unterschiedlich angezeigt, dies kann ein Grund für die vonn dir beobachteten Differenzen sein.
Frage vorweg: Bin ich richtig in der Annahme, dass du auf den footerfame.htm eingegangen bist ?
Im oberen Frame hatte ich explizit das Problem, dass in der Tabelle die Schriftfarbe (nur Farbe) beim IE6 trotz vordefinierten CSS nicht angezeigt wurde, darum habe ich - meiner eigentlichen Annahme zunächst nach - dazu entschlossen nur zur Sicherheit diese deiner Meinung nach überflüssige Markup reinzunehmen. Werde das von dir angesprochene mal austesten und meinen Bedürfnissen anpassen!
Zur Grössendefinition: Ich habe in einer extra platzierten CSS-Datei der <font size="1"> Tag eine feste Pixelformatierung zugeordte (1-3, mehr verwende ich wenn dann nicht). Opera hat dies genau wie NS korrekt erfasst, daher rührt mein Problem sicher nicht.
Dürfte eher die schwammige Interpretation der Tabellenhöhe sein, gemäss dem von dir angesprochen Punkt des Innenabstand!
Ich weiß nicht, ob die Netscape 4.x unterstützen willst, ich würde dir raten, nahezu alle Formatierungen mit Styles vorzunehmen, dadurch hast du in der Regel mehr Kontrolle und hast vor allem eine größere Sicherheit, dass die Regeln wirken, da du Möglichkeiten hast, welche du mit HTML-Formatierungen per se nicht hast.
Danke für den Rat!
Du hast bereits im Stylesheet die margins für body abgeschaltet, ich würde das ausdehnen und explizit auch padding deaktivieren, zusätzlich auch die des html-Elements (dürfte im Quirks-Mode irrelevant sein, aber sicher ist sicher):
html,body {margin:0; padding:0;}Wird gemacht!
bgproperties="FIXED" <-- Das kann meines Wissens herausfliegen, da sich das Hintergrundbild sowieso fortsetzt und ein Scrollen sowieso unmöglich ist.
Denke ich auch!
Wozu ist das Hintergrundbild eigentlich nötig...?
Nachdem ich die Testseite hochgeladen hatte, frage ich mich das auch, vor allen Dingen, wenn man das Hintergrundmotiv eh nicht sieht ;-) Rührt eher daher, dass ich für diesen Footerframe was anderes gebastelt habe und beim Umändern mir das abhanden kam. Kommt sicher weg ! ;-)
Zuerst einmal die obere Tabelle, folgendes dürfte reichen:
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr><td><img src="line1000.gif" height="1" width="100%" alt=""></td></tr>
</table>
... das könntest du natürlich auch ohne »blinde Tabelle« lösen, mit <div style="margin:0; padding:0">...</div> würde vermutlich dasselbe bezwecken.Mit den folgenden Styles kannst du das Markup ziemlich verkleinern:
td {color:white; background-color:black; text-align:center;}
table {border-style:none; border-spacing:0; border-collapse:collapse; height:59px}
div {margin:0; padding:0;}
(Die border-Eigenschaften für table sind nicht unbedingt nötig.)Beispielmarkup *ohne Scripts*:
<div><img src="line1000.gif" height="1" width="100%"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%" height="59">
<tr>
<td width="28%"><b>Datum:</b> Sonntag, 16. Februar 2003</td>
<td width="44%"><b>LAST NEWS: </b><marquee width="325">Chasebase.de in neuer Aufmachung (Februar 2003)! <a href="http://home.t-online.de/home/wterme/Chasebase.de/news.htm" target="headframe">Click!</a></marquee></td>
<td width="28%"><i>Du bist Besucher-Nr.:</i><br><img src="countergrafik.png"></td>
</tr>
</table>Hintergrundfarbe und Hintergrundbild von body könntest du auch im Stylesheet (im lokalen, welches nur für die Datei gilt, also im style-Element im head) festlegen.
In wie weit du leftmargin="0" rightmargin="0" usw. verwendest, hängt natürlich davon ab, ob du Netscape 4.x und andere prä-CSS-Browser noch unterstützen willst.Prinzipiell so viel unterstützen wie möglich, aber ohne auf bestimmte Darstellungsfinessen, die umgesetzt sind, zu verzichten.
Danke für die ausführlichen Tip!
Unabhängig von den kosmetischen Änderungen, bei welchen HTML-Formatierungen durch Styles ersetzt werden, zeigt das Beispiel folgendes: Schalte die Innenabstände der Tabelle ab, damit du viel Spielraum hast. Ich würde es nicht zulassen, dass sich die Höhe der Tabelle selbst regelt, die Faktoren, die das beeinflussen könnten, sind zu zahlreich, wenngleich alles festgelegt sein sollte. Eventuell gebe allen td-Elementen zusätzlich eine line-height (http://selfhtml.teamone.de/css/eigenschaften/ausrichtung.htm#line_height), damit die Zeilenhöhe fest ist. Die Tabellenhöhe würde ich fixieren, sodass die Zeilen darin bis auf die Maximalhöhe anwachsen können, ohne die Tabelle zu vergrößern (deshalb kein padding). Das Problem ist nämlich, dass beispielsweise das marquee-Element in manchen Browsern zweizeilig angezeigt wird, Opera 7 ignoriert es anscheinend vollkommen...
Zeilenhöhe sollte aber eigentlich auch exakt definiert sein (so würde ich es jetzt machen) ?
Anders herum könntest du die Tabelle natürlich auch mit height:100% formatieren und die weiße Liniengrafik einbeziehen... oder oder oder.
Wie meinst ? ;-). Wenn ich die Liniegrafik in das Tabellenkonstrukt einbeziehe, meckern doch die Browser, dass die erste Zeile einspaltig ist und die 2. beispielsweise 3.spaltig ? Oder meinst du was völlig anderes ? ;-)
Das würde ich dir sogar raten (in dem Fall eher 59 Pixel, weil die weiße Grafiklinie oben einen Pixel einnimmt, sofern sie außerhalb der Tabelle untergebracht wird).
So mache ich das dann ;-)!
Im Grunde genommen sollten sie diese einfache Übung gleich anzeigen, mit dem Rendermodus sollte es nichts zu tun haben (meiner Mutmaßung nach). Ich tippe konkret eher auf die Schriftgröße (wegen den font-Elementen), auf die vertikale Ausrichtung der Counter-Grafik (vielleicht mit vertical-align:bottom herumspielen), auf die line-height (jedoch eher unwahrscheinlich) und auf das marquee-Element, welches nur im MSIE funktioniert.
Siehe oben, das dürfte keine großen Auswirkungen haben. Auf Opera <7 sowieso nicht, bei den anderne Browsern dürfte es momentan auch keine Unterschiede (für den speziellen Frame) machen.
Danke!
Verzeihe, wenn ich zu durcheinander geschrieben habe, ;) es gibt viele Verbesserungsmöglichkeiten.
Als Hobbybastler ist man oft noch weit entfernt von einem perfekten Allfunktionstüchtigen Quelltext. Du hilst mir weiter! Ich bedanke mich für deine - mit manchmal zu langem Text ;-) - grosse Aufmerksamkeit.
Grüße,
MathiasCYA
Christian-
Moin, warum so kompliziert? setze einfach in Dein frame diesen javascript code rein:
if (parent.frames.length == 0)parent.location.href="haubtseite.html";
Grüsse vom Alain
--
...nobody is perfect I am nobody -
Hallo,
Für das beschriebene Problem ist der DOCTYPE aber meines Wissens nicht wichtig, weil bei Tabellen das width/padding-Problem eigentlich nicht vorhanden ist. Da der MSIE auch zusätzlich noch einen komischen Scrollleisten-Bug hat, wenn der standardkonforme Modus angeschaltet ist, würde ich dir explizit zum Quirks-Mode raten.
Scrolleisten-Bug ? Was exakt ?
Hm, scheinbar ist das Posting, in dem ich es erklärte, gerade im Zwischenreich (nicht mehr auf der Hauptseite, aber auch noch nicht im Archiv verfügbar).
Noch einmal anhand von Inner Frames (das Problem ist ähnlich, quasi dasselbe wie bei Frames):
<img src="http://home.t-online.de/home/dj5nu/fanhost/msie-compatmode.png" border="0" alt="">
Zwei ordinäre iframe-Elemente mit gleicher Größe. Die Dokumente in den iframes sind absolut identisch bis auf den DOCTYPE, sie enthalten im Grunde genommen nur ein paar Textabsätze und sind ansonsten unformatiert. Das Dokument im linken Inner Frame enthält einen XHTML 1.0 Strict-DOCTYPE und löst im Internet Explorer den standardkonformen Rendermodus aus. Das Dokument im rechten Inner Frame enthält neben dem XHTML 1.0 Strict-DOCTYPE eine XML-Deklaration am Anfang und löst den Quirks-Modus aus. Dies hat noch mit einem anderen Bug des MSIE zu tun, hier ist lediglich interessant, dass der Quirks-Modus ausgelöst wird, dies kann wie gesagt durch eine unvollständige Dokumenttypdeklaration oder eben über eine XML-Deklaration passieren.
Zu beobachten ist, dass der MSIE die Breite des Dokuments im linken Inner Frame so anlegt, dass sie der Breite des iframe-Elements ohne Abzug der Scrolleisten entspricht - dadurch geht der Text unter der Scrollbar her und es wird eine horizontale Scrollbar angezeigt.
Im konkreten Fall lässt sich so etwas nur mit bestimmten Styles und der proprietären Eigenschaft overflow-x unterdrücken:
html {margin:0; padding:0; overflow-x:hidden;}
body {margin:0 17px 0 0; /* 17px entspricht der ungefähren Breite der vertikalen Scollbar */ padding:10px;}
Das Problem ist, dass andere Browser alles korrekt machen und man deshalb jedem Browser verschiedene Styles liefern müsste, weil nur der MSIE einer Sonderbehandlung diesbezüglich bedarf (meist werden »CSS-Hacks« verwendet, über welche durch bestimmte Tricks und Selektoren Styles vergeben werden, welche von dem einen Browser ignoriert werden, weil dieser den Selektor nicht versteht, und von anderen Browser interpretiert werden).Mir ist nicht bekannt, wieso der MSIE diese komischen Sperenzchen macht und auch nicht, wie man sie sauber umgehen kann. In vielen Fällen ist es notwendig, die Breite des body-Elements explizit festzulegen - nur ist diese Möglichkeit nur bei Frames/Inner Frames gegeben, deren Breite fest ist, bei Frames mit variabler Breite lässt sich höchstens raten (95%? 98%? ...).
Frage vorweg: Bin ich richtig in der Annahme, dass du auf den footerfame.htm eingegangen bist ?
Ja.
Im oberen Frame hatte ich explizit das Problem, dass in der Tabelle die Schriftfarbe (nur Farbe) beim IE6 trotz vordefinierten CSS nicht angezeigt wurde, darum habe ich - meiner eigentlichen Annahme zunächst nach - dazu entschlossen nur zur Sicherheit diese deiner Meinung nach überflüssige Markup reinzunehmen. Werde das von dir angesprochene mal austesten und meinen Bedürfnissen anpassen!
Im Grunde sollte diesbezüglich zumindest im MSIE 6 kein Problem bestehen, denn dieser sollte Formatierungen auch in die Tabelle vererben. Meine kurzen Tests zeigen keine Schwierigkeiten.
Was ich absolut nicht verstehe (es muss nicht heißen, dass es falsch ist):
<font color="#ffffff">> </font><a href="home.htm">homeBase</a><font color="#ffffff"> < | </font>
<a href="">news</a><font color="#ffffff"> | </font>
<a href="">chase</a><font color="#ffffff"> | </font>
<a href="">gallery</a><font color="#ffffff"> | </font>
...Warum sind hier die font-Elemente nötig? Du kannst für die Zelle (über theoretisch für jedes Element darüber) color:white; angeben, dadurch sollte der Text in der Zelle weiß sein. *Links hingegen* haben, sofern die CSS-Regeln dafür entsprechend und richtig angebracht sind (und dass sind sie in deinem Fall), immer die Formatierung, die du ihnen zuweist - insofern kannst du ruhig pauschal eine Schriftfarbe vergeben, ohne dass die Links davon beeinträchtig werden.
<font color="#ffffff">> </font>
^ Dort ist übrigens ein > zuviel.Zur Grössendefinition: Ich habe in einer extra platzierten CSS-Datei der <font size="1"> Tag eine feste Pixelformatierung zugeordte (1-3, mehr verwende ich wenn dann nicht). Opera hat dies genau wie NS korrekt erfasst, daher rührt mein Problem sicher nicht.
Ja, ich wusste nicht, ob das eventuell ein Problem darstellen könnte. Ich hätte eher darauf getippt, dass die lokalen Formatierungen über das font-Element in ihrer Wichtigkeit ähnlich wie style-Attribut behandelt werden, nämlich dass sie die globalen Styleregeln überschreiben.
Zeilenhöhe sollte aber eigentlich auch exakt definiert sein (so würde ich es jetzt machen) ?
Die Zeilenhöhe wird meist implizit über die Schriftgröße definiert, das heißt, die Zeilenhöhe/der »Durchschuss« (meines Wissens definiert als Abstand der Basislinien der Zeilen) ist in der Regel Pi mal Daumen Schriftgröße multipliziert mal 1,4 oder so etwas. Du könntest jetzt mit verschiedenen Wertepaaren herumspielen, sodass die zwei Zeilen in der rechten Spalte (Test und Countergrafik) zusammen oder auseinanderrücken, beispielsweise font-size:13px; und line-height:16px;. Zusätzlich wäre wie gesagt die vertikale Ausrichtung (vertical-align) der Grafik (des img-Elements) interessant, dabei machen auch einige Browser Unterschiede (aber eher Mozilla/Gecko, siehe http://www.dodabo.de/html+css/img-table/).
Anders herum könntest du die Tabelle natürlich auch mit height:100% formatieren und die weiße Liniengrafik einbeziehen... oder oder oder.
Wie meinst ? ;-). Wenn ich die Liniegrafik in das Tabellenkonstrukt einbeziehe, meckern doch die Browser, dass die erste Zeile einspaltig ist und die 2. beispielsweise 3.spaltig ? Oder meinst du was völlig anderes ? ;-)
Das wäre durchaus möglich, es besteht die Möglichkeit, mehrere Zellen zeilen- und spaltenübergreifend zu einer Zelle zusammenzufassen. Dazu bedient man sich der HTML-Attribute colspan (column span, Spalten-»Spannweite«, folglich die Anzahl von horizontalen Spaltenzellen, über welche sich die Zelle erstrecken soll) und rowspan (row span, Zeilen-»Spannweite«, folglich die Anzahl von vertikalen Zeilenzellen, über welche sich die Zelle erstrecken soll). Siehe: SELFHTML -> HTML/XHTML -> Tabellen -> Zellen verbinden http://selfhtml.teamone.de/html/tabellen/zellen_verbinden.htm. Das sähe in der Anwendung folgendermaßen aus:
<table>
<tr>
<td colspan="3"><img src="liniengrafik.png"></td>
</tr>
<tr>
<td>erste Spalte</td>
<td>zweite Spalte</td>
<td>dritte Spalte</td>
</tr>
</table>Die erste Zeile erhält folglich eine Zelle, welche sich über drei Spalten erstreckt (deshalb muss in dieser Zeile nur ein td-Element enthalten sein). Da diese Tabelle das einzige wäre, was in dem unteren Framedokument enthalten wäre, könntest du ihr per CSS height:100%; verpassen (das Attribut height ist für das Element table nicht erlaubt, aber wahrscheinlich für alte Browser notwendig, falls du diese unterstützen willst).
Als Hobbybastler ist man oft noch weit entfernt von einem perfekten Allfunktionstüchtigen Quelltext.
Ja, den Großteil der Zeit verbringt man mit dem Umgehen von Browserunterschieden, -unzulänglichkeiten und -bugs.
Grüße,
Mathias-
Hoi ;-),
Hallo,
Noch einmal anhand von Inner Frames (das Problem ist ähnlich, quasi dasselbe wie bei Frames):
<img src="http://home.t-online.de/home/dj5nu/fanhost/msie-compatmode.png" border="0" alt="">
Zwei ordinäre iframe-Elemente mit gleicher Größe. Die Dokumente in den iframes sind absolut identisch bis auf den DOCTYPE, sie enthalten im Grunde genommen nur ein paar Textabsätze und sind ansonsten unformatiert. Das Dokument im linken Inner Frame enthält einen XHTML 1.0 Strict-DOCTYPE und löst im Internet Explorer den standardkonformen Rendermodus aus. Das Dokument im rechten Inner Frame enthält neben dem XHTML 1.0 Strict-DOCTYPE eine XML-Deklaration am Anfang und löst den Quirks-Modus aus. Dies hat noch mit einem anderen Bug des MSIE zu tun, hier ist lediglich interessant, dass der Quirks-Modus ausgelöst wird, dies kann wie gesagt durch eine unvollständige Dokumenttypdeklaration oder eben über eine XML-Deklaration passieren.
Zu beobachten ist, dass der MSIE die Breite des Dokuments im linken Inner Frame so anlegt, dass sie der Breite des iframe-Elements ohne Abzug der Scrolleisten entspricht - dadurch geht der Text unter der Scrollbar her und es wird eine horizontale Scrollbar angezeigt.
Im konkreten Fall lässt sich so etwas nur mit bestimmten Styles und der proprietären Eigenschaft overflow-x unterdrücken:
html {margin:0; padding:0; overflow-x:hidden;}
body {margin:0 17px 0 0; /* 17px entspricht der ungefähren Breite der vertikalen Scollbar */ padding:10px;}
Das Problem ist, dass andere Browser alles korrekt machen und man deshalb jedem Browser verschiedene Styles liefern müsste, weil nur der MSIE einer Sonderbehandlung diesbezüglich bedarf (meist werden »CSS-Hacks« verwendet, über welche durch bestimmte Tricks und Selektoren Styles vergeben werden, welche von dem einen Browser ignoriert werden, weil dieser den Selektor nicht versteht, und von anderen Browser interpretiert werden).Mir ist nicht bekannt, wieso der MSIE diese komischen Sperenzchen macht und auch nicht, wie man sie sauber umgehen kann. In vielen Fällen ist es notwendig, die Breite des body-Elements explizit festzulegen - nur ist diese Möglichkeit nur bei Frames/Inner Frames gegeben, deren Breite fest ist, bei Frames mit variabler Breite lässt sich höchstens raten (95%? 98%? ...).
Danke! Eine ähnliche Beobachtung durfte ich machen, als ich spassighalber den von dir erwähnten Doctype bei der home.htm Seite eingebaut habe. Prompt war im Frame ein horizontaler, absolut sinnloser Scrollbalken (Breite von Tabellle war schliesslich festgelegt). Ich werds wenn nötig umgehen!
Im Grunde sollte diesbezüglich zumindest im MSIE 6 kein Problem bestehen, denn dieser sollte Formatierungen auch in die Tabelle vererben. Meine kurzen Tests zeigen keine Schwierigkeiten.
Dachte ich auch, ich werde nochmal schauen und beheben!
Was ich absolut nicht verstehe (es muss nicht heißen, dass es falsch ist):
<font color="#ffffff">> </font><a href="home.htm">homeBase</a><font color="#ffffff"> < | </font>
<a href="">news</a><font color="#ffffff"> | </font>
<a href="">chase</a><font color="#ffffff"> | </font>
<a href="">gallery</a><font color="#ffffff"> | </font>
...Warum sind hier die font-Elemente nötig? Du kannst für die Zelle (über theoretisch für jedes Element darüber) color:white; angeben, dadurch sollte der Text in der Zelle weiß sein. *Links hingegen* haben, sofern die CSS-Regeln dafür entsprechend und richtig angebracht sind (und dass sind sie in deinem Fall), immer die Formatierung, die du ihnen zuweist - insofern kannst du ruhig pauschal eine Schriftfarbe vergeben, ohne dass die Links davon beeinträchtig werden.
Die Links sind nicht extra doppelt mit Markup versehen, hier *zieht* die CSS-Datei so wie es sein soll. Das bestehende Markup ist für die Zeichen zwischen den Links angedacht, es reicht aber sicher aus, wenn ich das in der Zeile nur einmal definiere, mal schauen.
<font color="#ffffff">> </font>
^ Dort ist übrigens ein > zuviel.Keine Sorge, das ist beabsichtigt, das Zeichen soll man extra sehen. Sollte Komplikationen auftreten (Könnte?) werde ich einfach ein anderes Zeichen nehmen, oder es wie die Umlaute und das Leerzeichen allverständlich kodieren. Ich bin dahingehend meist ein wenig faul, aber wenn der Rohling erstmal vernünftig fertig ist, brauche ich die schon fertigen Inhalte ja fast nur per Copy & Paste nachtragen ;-)
Das wäre durchaus möglich, es besteht die Möglichkeit, mehrere Zellen zeilen- und spaltenübergreifend zu einer Zelle zusammenzufassen. Dazu bedient man sich der HTML-Attribute colspan (column span, Spalten-»Spannweite«, folglich die Anzahl von horizontalen Spaltenzellen, über welche sich die Zelle erstrecken soll) und rowspan (row span, Zeilen-»Spannweite«, folglich die Anzahl von vertikalen Zeilenzellen, über welche sich die Zelle erstrecken soll). Siehe: SELFHTML -> HTML/XHTML -> Tabellen -> Zellen verbinden http://selfhtml.teamone.de/html/tabellen/zellen_verbinden.htm. Das sähe in der Anwendung folgendermaßen aus:
<table>
<tr>
<td colspan="3"><img src="liniengrafik.png"></td>
</tr>
<tr>
<td>erste Spalte</td>
<td>zweite Spalte</td>
<td>dritte Spalte</td>
</tr>
</table>Die erste Zeile erhält folglich eine Zelle, welche sich über drei Spalten erstreckt (deshalb muss in dieser Zeile nur ein td-Element enthalten sein). Da diese Tabelle das einzige wäre, was in dem unteren Framedokument enthalten wäre, könntest du ihr per CSS height:100%; verpassen (das Attribut height ist für das Element table nicht erlaubt, aber wahrscheinlich für alte Browser notwendig, falls du diese unterstützen willst).
Danke, ausführlich und in einem Beispiel erklärt. Man lernt halt immer wieder Tags kennen. ;-)
Ja, den Großteil der Zeit verbringt man mit dem Umgehen von Browserunterschieden, -unzulänglichkeiten und -bugs.
*sehr* viel ist nicht mehr zu tuen. Einen Teil habe ich auf meiner Festplatte schon geändert, unabhängig von der Online-Version. Werde noch hier und da Kleinigkeiten entdecken und *lifte* den Quelltext immer weiter, er soll auch möglichst sauber sein im GG. zu vielen von mir vorher geschriebenen Webseiten, wo man daran nicht so dachte. Hat ja auch alles funktioniert, aber 1-2 Leute gibs dann doch immer, bei denen die Seite *verhunzt* dargestellt wurde, weil eben was wichtig falsch gemacht wurde, oder mal ein Hack zur Behebung von Bugs unbekannt war.
Dar Exkurs weitet sich ja ganz schön aus, hilft mir aber, mein teilweise nur sporadisches Wissen weiterzuverarbeiten.
CYA
ChristianGrüße,
Mathias-
Ich glaube, ich hätte noch einen IE-Bug entdeckt. Wenn ich das richtig verstanden habe, schaltet der Browser mit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org./loose.dtd">
in den Quirks-Modus. Dabei kommt der Scrollbalken-Bug zum Tragen. Da ich speziell auf meinen oberen Frame-Seiten ein Hintergrund-Motiv verwende, dass grösser als das Fenster ist, murrt der Browser IE6/Win rum und bringt einen eigentlichen sinnlosen horizontalen Scrollbalken (den NS/Mozilla nicht zeigen). Diesen Bug kann man mit HTML {overflow-x: hidden} umgehen, was ich dann auch in meiner CSS-Datei so getan habe. Der horizontale Scrollbalken wäre weg, aber die farbigen Scrollbalken, die ich ebenso in der Datei definiert habe, diese kann der IE aus welchem Grund auch immer nicht anzeigen, stattdessen gibt es die Standardbalken. Kein Beinbruch, auf die farbigen Scrollbalken kann ich verzichten, aber es ist scheinbar auch ein Bug ;-)CYA
Christian-
Hallo Christian,
Ich glaube, ich hätte noch einen IE-Bug entdeckt. Wenn ich das richtig verstanden habe, schaltet der Browser mit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org./loose.dtd">
in den Quirks-Modus. Dabei kommt der Scrollbalken-Bug zum Tragen.Es muss wenn überhaupt folgendermaßen heißen:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Mit diesem DOCTYPE schalten aber die meisten Browser in den standardkonformen Modus, der genannte Bug (beziehungsweise das unerklärliche Verhalten, vielleicht hat es eine mir unbekannte Ursache beziehungsweise Absicht) mit den Scrollbars und der Dokumentbreite tritt ebenfalls *nur* im standardkonformen Modus auf, *nicht* im Kompatibilitätsmodus (»Quirks«-Modus). Vielleicht habe ich mich unklar ausgedrückt.Der horizontale Scrollbalken wäre weg, aber die farbigen Scrollbalken, die ich ebenso in der Datei definiert habe, diese kann der IE aus welchem Grund auch immer nicht anzeigen, stattdessen gibt es die Standardbalken. Kein Beinbruch, auf die farbigen Scrollbalken kann ich verzichten, aber es ist scheinbar auch ein Bug ;-)
Nein, das ist gewollt, siehe </archiv/2003/2/37666/#m206224>. Im standardkonformen Modus musst du die Scrollbar-Eigenschaften für das html-Element, nicht für das body-Element vergeben. Ab besten gibst du beiden Elementen dieselben Deklarationen: html,body {scrollbar... ...}.
Warum du aber unbedingt den standardkonformen Modus auslösen willst, verstehe ich nicht, ich habe dir bereits davon abgeraten, weil es vor allem mit Ärger verbunden ist.
Grüße,
Mathias-
Hallo Mathias,
Hallo Christian,
Es muss wenn überhaupt folgendermaßen heißen:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Mit diesem DOCTYPE schalten aber die meisten Browser in den standardkonformen Modus, der genannte Bug (beziehungsweise das unerklärliche Verhalten, vielleicht hat es eine mir unbekannte Ursache beziehungsweise Absicht) mit den Scrollbars und der Dokumentbreite tritt ebenfalls *nur* im standardkonformen Modus auf, *nicht* im Kompatibilitätsmodus (»Quirks«-Modus). Vielleicht habe ich mich unklar ausgedrückt.Ein bisschen ausführlich hattest du es geschrieben, kurz und direkt bringt es oft besser auf den Punkt. Von mir kenne ich lange Texte ja bestens, und in der Masse wird der kleine Inhalt manchmal nicht mehr erkannt.
Ich hatte jedenfalls herausgelesen, dass es sogar nutzvoll sein kann, den Doctype weg zu lassen. Ich werde das vorerst auch weiter so handhaben, bin damit eigentlich browserunabhängig generell gut gefahren ;-)
Nein, das ist gewollt, siehe </archiv/2003/2/37666/#m206224>. Im standardkonformen Modus musst du die Scrollbar-Eigenschaften für das html-Element, nicht für das body-Element vergeben. Ab besten gibst du beiden Elementen dieselben Deklarationen: html,body {scrollbar... ...}.
Ich bedanke mich ein weiteres Mal ;-)
Warum du aber unbedingt den standardkonformen Modus auslösen willst, verstehe ich nicht, ich habe dir bereits davon abgeraten, weil es vor allem mit Ärger verbunden ist.
Zum Test ;-)
Grüße,
MathiasIch bedanke mich *abschliessend* bei dir für deine rege Aufmerksamkeit. Werde einen Grossteil umsetzen, so z.B. feste Werte für alle Tabellenbestandteile zu verteilen. In diesem Thread habe ich viel gelernt. ;-)
CYA
Christian
-
-
-
Hallo,
<font color="#ffffff">> </font>
^ Dort ist übrigens ein > zuviel.Keine Sorge, das ist beabsichtigt, das Zeichen soll man extra sehen. Sollte Komplikationen auftreten (Könnte?) werde ich einfach ein anderes Zeichen nehmen, oder es wie die Umlaute und das Leerzeichen allverständlich kodieren.
Achso. Es dürfte kein Problem sein, dennoch würde ich > stattdessen schreiben, siehe http://selfhtml.teamone.de/html/allgemein/zeichen.htm#html_eigene.
[colspan/rowspan]
Danke, ausführlich und in einem Beispiel erklärt. Man lernt halt immer wieder Tags kennen. ;-)
Es sind übrigens *Attribute*, Tags begrenzen Elemente (beziehungsweise stellen Elemente dar und begrenzen den Elementinhalt): http://selfhtml.teamone.de/html/allgemein/textauszeichnung.htm. Das führt des öfteren zu Sprachverwirrung, also gewöhne dir besser die das richtige Vokabular an, sonst wirst du schnell missverstanden.
Grüße,
Mathias
-
-
-
-
-
-