nicht angemeldet
Probleme mit iframe
0 0 0 0 4 Probleme mit unsemantischem Code
0 
Der Martin
2
0 
Gernot Back
0
Probleme mit iframe
Gunnar BittersmannHallo, ich habe ein Problem mit meinem iframe.
Mit FF habe ich keine Probleme, mit Google Chrome ist es nur etwas verschoben und mit dem IE habe ich einen weißen Hintergrund, obwohl ich den Hintergrund transparent eingestellt habe.
Hier mal der Quellcode ohne den Fussbereich:
<html>
<head>
<link rel="SHORTCUT ICON" href="http://www4.pic-upload.de/29.03.10/j8rfh62vq2.gif">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="robots" content="INDEX,FOLLOW">
<meta name="page-type" content=" homepage">
<title>Lost Island Mini Aussies</title>
<!-- Der Copyright-Hinweis ist nicht zu löschen. Ein Entfernen des Copyright/Urheberrecht-Vermerks kann rechtliche Schritte nach sich ziehen -->
<!-- (c)Copyright by S.I.S.Papenburg / www.on-mouseover.de/templates/ -->
<link rel="stylesheet" href="http://file1.npage.de/006353/17/html/format.css" type="text/css">
<link rel="stylesheet" href="http://file1.npage.de/006353/17/html/menue.css" type="text/css">
</head><body class="backmain" scroll="no">
<table id="main" align="center" border="0" cellpadding="0" cellspacing="0" height="100%">
<tbody><tr>
<td valign="top" width="100%">
<table width="100%" border="0" cellpadding="0" cellspacing="0" height="100%">
<tbody><tr>
<td id="top"><span id="hpname"><i style="font-family: fantasy; font-size: 40px; color: black;"></i><center>Lost Island Mini Aussies</center><i style="font-family: fantasy; font-size: 40px; color: black;"></i></span></td>
</tr>
<tr>
<td width="100%" height="100%">
<table width="100%" align="left" border="0" cellpadding="0" cellspacing="0" height="100%">
<tbody><tr>
<td id="sp1" height="100%">
<!-- beginn hauptinhaltszelle-->
<iframe src="http://lost-island-aussies.npage.de/home_49800657.html" id="inframe" name="haupt" frameborder="1" scrolling="auto"></iframe>
<!--ende hauptinhaltszelle-->
</td>
</tr>
</tbody></table>
</td>
<!--links ende-->
<!--rechts-->
<td width="20%">
<table width="100%" border="0" cellpadding="0" cellspacing="0" height="100%">
<tbody><tr>
<td height="100%">
<table width="100%" align="left" border="0" cellpadding="0" cellspacing="0" height="100%">
<tbody><tr>
<td id="sp2" align="left" height="100%">
<div id="menu01">
<ul >
<li><a href="http://lost-island-aussies.npage.de/home_49800657.html " target="haupt">Home</a></li>
<li><a href="http://lost-island-aussies.npage.de/wir_23658147.html " target="haupt">Über uns</a></li>
<li><a href="http://lost-island-aussies.npage.de/mini_aussie_55916217.html " target="haupt">Der Mini Aussie</a></li>
<li><a href="http://parsonofpirates.npage.de/willkommen_home_98217954.html" target="_blank">Parson Russell Terrier</a></li>
<li><a href="http://charlie.de.to" target="_blank">♂ Charlie</a></li>
<li><a href="http://jenna.de.to" target="_blank">♀ Jenna</a></li>
<li><a href="http://lost-island-miniaussies.blogspot.com/">Aktuelles</a></li>
<li><a href="http://lost-island-aussies.npage.de/welpen_64002241.html " target="haupt">Welpen</a></li>
<li><a href="http://lost-island-aussies.npage.de/wurfplanung_9234795.html " target="haupt">Wurfplanung</a></li>
<li><a href="http://lost-island-aussies.npage.de/nachzucht_70058975.html " target="haupt">Nachzucht</a></li>
<li><a href="http://lost-island-aussies.npage.de/bilder_85770156.html " target="haupt">Bilder</a></li>
<li><a href="http://lost-island-aussies.npage.de/videos_8629290.html " target="haupt">Videos</a></li>
<li><a href="http://lost-island-aussies.npage.de/gästebuch_62715951.html" target="haupt">Gästebuch</a></li>
<li><a href="http://lost-island-aussies.npage.de/kontakt_74471663.html " target="haupt">Kontakt</a></li>
<li><a href="http://lost-island-aussies.npage.de/impressum_44831818.html " target="haupt">Impressum</a></li>
<li><a href="http://lost-island-aussies.npage.de/links_76870403.html " target="haupt">Links</a></li>
</ul>
</div>
<!--MENU 01 ENDE-->
</td>
</tr>
</tbody></table>
<!-- ende inhalt-->
-
Bei dieser Seite fehlt es leider schon an den Grundlagen. Beseitige bitte zunächst das Tabellenlayout auf der Seite, bevor Du Dir überlegst, ob es nicht auch sehr sinnvoll ohne den iframe gehen würde, da Du offensichtlich statische Inhalte darin einbindest, die genauso gut in der Seite selbst stehen können.
Gruß, LX
--
RFC 2324, Satz 7 (Sicherheit): Jeder, der zwischen meinem Kaffee und mir steht, gilt als unsicher.-
Bei dieser Seite fehlt es leider schon an den Grundlagen. Beseitige bitte zunächst das Tabellenlayout auf der Seite
Wenn ich so einen Quatsch immer lese.
Tabellen sind nicht für Layouts gedacht. Dennoch ist es kein "Fehler". Lediglich "unschön". Ich persönlich bevorzuge nach wie vor Tabellen zum Layouten, weil es mir schlicht einfacher fällt und ich damit viel schneller das erreiche, was ich möchte. Die Entscheidung dazu liegt auch einzig und allein bei mir, solange ich mich nicht an Barrierefreiheit o.ä. halten MUSS.Aber was ich hauptsächlich sagen möchte:
Überfordert die Leute nicht immer gleich mit "Bau erstmal Deine Seite komplett um", wenn es um ein einfaches Problem geht...-
Du kannst gerne weiterhin Tabellen für Layouts verwenden, wenn Du unsemantischen Code produzieren möchtest. Das ist Deine Sache Wenn Du Deine Ziele damit tatsächlich schneller erreichen solltest, läßt das zwar auf ein potentielles Unverständnis von CSS schließen, aber es ist letztlich nicht mein Job, Dich davon zu heilen.
Das ändert jedoch nichts daran, dass ich, wenn ich derartige Beispiele gezeigt bekomme, den unsemantischen Stil des Codes kommentieren werde - und damit bin ich hier im Forum sicher nicht der Einzige. Der Grund dafür besteht darin, dass ich in meinem Job eine Menge Code lesen und bearbeiten muss und sich semantischer Code einfach wesentlich angenehmer liest und warten läßt.
Gruß, LX
--
RFC 2324, Satz 7 (Sicherheit): Jeder, der zwischen meinem Kaffee und mir steht, gilt als unsicher.-
Du kannst gerne weiterhin Tabellen für Layouts verwenden, wenn Du unsemantischen Code produzieren möchtest. Das ist Deine Sache Wenn Du Deine Ziele damit tatsächlich schneller erreichen solltest, läßt das zwar auf ein potentielles Unverständnis von CSS schließen, aber es ist letztlich nicht mein Job, Dich davon zu heilen.
Richtig.
Das ändert jedoch nichts daran, dass ich, wenn ich derartige Beispiele gezeigt bekomme, den unsemantischen Stil des Codes kommentieren werde - und damit bin ich hier im Forum sicher nicht der Einzige.
Ja, ein generelles Manko dieses Forums.
Dein Beitrag ging mit keinem Wort auf das Problem ein. Stattdessen quasi nur ein "Bau erstmal Deine Seite komplett um". Und das ist und bleibt schlicht Quatsch und vor allem auch unnötig.Der Grund dafür besteht darin, dass ich in meinem Job eine Menge Code lesen und bearbeiten muss und sich semantischer Code einfach wesentlich angenehmer liest und warten läßt.
Ansichtssache. Ich komme mit einem Tabellenlayout deutlich schneller ans Ziel als mit 20 DIVs, in dem sich nur IDs befinden, die ich dann wieder in einer CSS-Datei zusammensuchen muss. Da ist es mir letztlich egal, ob das "schöner" ist. Aber wie gesagt, jedem das seine.
Wenn Dir das einfacher fällt oder Du nachts besser schläfst, weil Du weisst, dass Du semantisch besser dastehst, ist das Dein gutes Recht. Verlange aber nicht grundsätzlich, dass es jeder genauso sehen muss... Vor allem nicht von offensichtlichen Nicht-Profis (eine Webseite beim Free-Anbieter npage lässt darauf schließen)... Das wirkt nur arrogant. Funktional notwendig ist es nämlich in weiten Teilen schlicht nicht.
My 2 cents,
Andreas-
Hallo, Andreas
Ja, ein generelles Manko dieses Forums.
Nein, das ist genau das, was den Unterschied zu "ich würde gerne mal so tun, als hätte ich Ahnung vom Web"-Foren, auf denen Anfänger Anfängern zu helfen versuchen.
Dein Beitrag ging mit keinem Wort auf das Problem ein. Stattdessen quasi nur ein "Bau erstmal Deine Seite komplett um". Und das ist und bleibt schlicht Quatsch und vor allem auch unnötig.
Ich habe lediglich geschrieben: "Beseitige bitte zunächst das Tabellenlayout auf der Seite" - und das wäre mit 1-2 div-Containern (je nach Zielsetzung) und einem kleinen Schnipsel CSS bereits erledigt gewesen - kein Grund, einen Aufstand zu proben. Abgesehen davon war dies nur die Einleitung zum eigentlichen Kernpunkt - nämlich, dass die gestellte Aufgabe ohne iframes wesentlich problemloser zu lösen wäre.
Ansichtssache. Ich komme mit einem Tabellenlayout deutlich schneller ans Ziel als mit 20 DIVs, in dem sich nur IDs befinden, die ich dann wieder in einer CSS-Datei zusammensuchen muss. Da ist es mir letztlich egal, ob das "schöner" ist. Aber wie gesagt, jedem das seine.
Auch meine Fähigkeiten sind begrenzt. Statt jedoch diese Beschränkungen zu zelebrieren, wie Du es gerade demonstrierst, erkenne ich diese Grenzen als solche an und versuche, über meinen Tellerrand zu blicken und mich weiter zu entwickeln - und genau darum geht es hier auf dem Forum.
Wenn Dir das einfacher fällt oder Du nachts besser schläfst, weil Du weisst, dass Du semantisch besser dastehst, ist das Dein gutes Recht. Verlange aber nicht grundsätzlich, dass es jeder genauso sehen muss... Vor allem nicht von offensichtlichen Nicht-Profis (eine Webseite beim Free-Anbieter npage lässt darauf schließen)... Das wirkt nur arrogant. Funktional notwendig ist es nämlich in weiten Teilen schlicht nicht.
Ich verlange nicht, dass Du meine Ansicht teilst. Berücksichtige jedoch, dass hier auf dem Forum ein gewisser professioneller Standard gewahrt bleiben sollte. Wer von uns Hilfe erwartet, sollte es uns einfach machen, diese zu leisten. Schlecht les- und wartbarer Code ist dabei einfach ein Hindernis, das lediglich noch von unreichenden Fehlerbeschreibungen darin überboten wird, es uns schwer zu machen.
Abgesehen davon: ein Monitor ist für einen PC auch nicht funktional notwendig - man kann auch alles über den Drucker ausgeben (was in den 50er Jahren noch normale Praxis war) - aber Du würdest trotzdem auf Deinen Monitor ungern verzichten wollen, oder?
Gruß, LX
--
RFC 2324, Satz 7 (Sicherheit): Jeder, der zwischen meinem Kaffee und mir steht, gilt als unsicher.-
Hallo, Andreas
Mahlzeit.
Auch meine Fähigkeiten sind begrenzt. Statt jedoch diese Beschränkungen zu zelebrieren, wie Du es gerade demonstrierst, erkenne ich diese Grenzen als solche an und versuche, über meinen Tellerrand zu blicken und mich weiter zu entwickeln - und genau darum geht es hier auf dem Forum.
Das hat mit Fähigkeiten eher wenig zu tun. Ich KÖNNTE es auch mit DIVs & Co. erledigen. Würde ggf. länger dauern, weil ich es umständlicher finde, z.B. sowas darzustellen:
Da hab ich einfach schneller eine zweizeilige Tabelle gemacht. Erste Zeile mit colspan="2", zweite Zeile mit einer linksausgerichteten und einer rechtsausgerichteten Zelle. Farblich gestaltet wird das freilich auch über CSS, aber ich sehe keinen Grund, das aus DIVs zusammenzubasteln... Und so zieht sich das durch das gesamte Layout. Das hier ist nur ein Beispiel.
Weiter geht's, wenn ich alle Spalten gleich hoch haben möchte. Bei Tabellen geschieht das automatisch. Wenn Spalte 2 aufgrund ihres Inhalts 1000 Pixel hoch ist, ist das Spalte 1 auch. Ohne, dass ich irgendwas machen muss. Und genau so erwarte ich das auch... gerade beim Layout...
... und wie schon gesagt, ich finde ein paar verschachtelte Tabellen deutlich einfacher zu verwalten als eine wild durcheinanderpositionierte DIV-Suppe, mit IDs, die ich erst in der CSS-Datei heraussuchen muss. Notfalls Border auf 1 und man sieht genau die Grenzen... oder noch einfacher: per Developer-Toolbar Tabellenzellen hervorheben lassen. Da werden verschachtelte Tabellengrenzen sogar verschiedenfarbig dargestellt. Wenn Du bei sowas den Überblick verlierts... tja... ;)
Aber wie schon gesagt: Ansichtssache...Ich verlange nicht, dass Du meine Ansicht teilst. Berücksichtige jedoch, dass hier auf dem Forum ein gewisser professioneller Standard gewahrt bleiben sollte. Wer von uns Hilfe erwartet, sollte es uns einfach machen, diese zu leisten. Schlecht les- und wartbarer Code ist dabei einfach ein Hindernis, das lediglich noch von unreichenden Fehlerbeschreibungen darin überboten wird, es uns schwer zu machen.
Gerade als "Profi", sollte man auch solchen Code lesen können. Das kann ja sogar ich. Klar, sollte da nicht nur Gülle stehen, aber ein Rat "Bau erstmal Deine Seite neu" gegenüber einem Nicht-Profi bzgl. eines kleinen Problemes ist kein "professioneller Standpunkt", sondern - wie schon gesagt - "arrogant"...
Abgesehen davon: ein Monitor ist für einen PC auch nicht funktional notwendig - man kann auch alles über den Drucker ausgeben (was in den 50er Jahren noch normale Praxis war) - aber Du würdest trotzdem auf Deinen Monitor ungern verzichten wollen, oder?
Äpfel und Birnen...
Dem normalen Besucher der Seite fällt beim Betrachten der Webseite an sich kein Unterschied auf, ob diese nun aus Tabellen oder aus DIVs besteht. Und allein darum geht es mir... Und wenn die Seite einwandfrei funktioniert und so aussieht, wie sie aussehen soll, gibt es einfach keinen Grund, von Tabellen- auf CSS-Layout zu wechseln. Punkt. Es sei denn, man selbst fühlt sich mit dem Code besser.
Und mit meinem Posting ging es mir eigentlich auch nur um folgende Feststellung:
Aber was ich hauptsächlich sagen möchte:
Überfordert die Leute nicht immer gleich mit "Bau erstmal Deine Seite komplett um", wenn es um ein einfaches Problem geht...-
Das hat mit Fähigkeiten eher wenig zu tun. Ich KÖNNTE es auch mit DIVs & Co. erledigen. Würde ggf. länger dauern, weil ich es umständlicher finde, z.B. sowas darzustellen (...)
Das hat doch etwas mit Fähigkeiten zu tun, in diesem Fall die Fähigkeit, einen Aufbau semantisch zu gliedern.
--------------------------------------------------
Headline
--------------------------------------------------
Status Navigation
--------------------------------------------------Stattdessen hast Du Daten ohne jeden tabellarischen Bezug in eine Tabelle gepackt. Die Headline ist vermutlich h2 oder h3, je nachdem, in welcher Gliederungsebene man sich befindet. Status scheint semantisch am Besten in einem div aufgehoben zu sein, während die Navigation entweder eine ul-Liste ist oder in HTML5 sogar noch semantischer in einem nav-Element unterkommt.
Vergleichen wir also mal die beiden Ansätze vom Code her. Deiner sieht etwa so aus (ich habe ein wenig geraten, bitte sehe mir nach, wenn sich der Code nicht zu 100% mit Deinem deckt):
<table> <tr> <th colspan="2"> <strong>Forum</strong> </th> </tr> <tr> <td>29 Themen auf 3 Seiten (275 Beiträge)</td> <td align="right"><a href="..."><img .../> Foren-Suche</a> | <a href="">Neues Thema starten</a></td> </tr> </table>Semantischer geht es so:
<h3>Forum</h3> <div class="status">29 Themen auf 3 Seiten (275 Beiträge)</div> <ul class="nav"> <li class="first suche"><a href="...">Foren-Suche</a></li> <li class="last"><a href="...">Neues Thema starten</a></li> </ul>Ich habe an meinem Code wesentlich kürzer geschrieben als an Deinem - und das CSS, welches in jedem Fall für das Layout hinzukommt, wird auch nicht so viel komplizierter.
Weiter geht's, wenn ich alle Spalten gleich hoch haben möchte. Bei Tabellen geschieht das automatisch. Wenn Spalte 2 aufgrund ihres Inhalts 1000 Pixel hoch ist, ist das Spalte 1 auch. Ohne, dass ich irgendwas machen muss. Und genau so erwarte ich das auch... gerade beim Layout...
Dafür gibt es gleich mehrere praktikable Lösungen, die ohne den semantischen Mißbrauch einer Tabelle auskommen.
... und wie schon gesagt, ich finde ein paar verschachtelte Tabellen deutlich einfacher zu verwalten als eine wild durcheinanderpositionierte DIV-Suppe, mit IDs, die ich erst in der CSS-Datei heraussuchen muss. (...)
Bitte zeige mir, wo in meinem Code eine DIV-Suppe steckt? Bei Bedarf hätte ich das einzige div auch durch p oder dfn ersetzen können, sah jedoch dazu keine Veranlassung. Übrigens: Die Lösung für das Problem "Div-Suppe" sind flache HTML-Strukturen, nicht Tabellen-Layout.
Aber wie schon gesagt: Ansichtssache...
Semantik ist wie Objektorientierung ein Konzept. Natürlich kann man letztlich unterschiedlicher Ansicht sein, ob das Konzept der Problemstellung angemessen ist. Allerdings sehe ich keinen validen Grund, auf Semantik zu verzichten, wenn sie ohne zusätzlichen Aufwand funktioniert.
Gerade als "Profi", sollte man auch solchen Code lesen können. Das kann ja sogar ich. Klar, sollte da nicht nur Gülle stehen, aber ein Rat "Bau erstmal Deine Seite neu" gegenüber einem Nicht-Profi bzgl. eines kleinen Problemes ist kein "professioneller Standpunkt", sondern - wie schon gesagt - "arrogant"...
Ich kann solchen Code durchaus lesen und auch produzieren. Etwa Mailings können wegen Outlook fast nur mit Tabellenlayout erstellt werden - und an dieser Stelle habe ich auch durchaus Verständnis. Es gibt auch andere Situationen (etwa bei manchen mobilen Browsern), in denen man gezwungen ist, von semantischen Strukturen abzuweichen - aber genau das ist es: ein Abweichen. Wenn ich diese Code-Pathologie als Notwendigkeit erkenne, ist das etwas anderes, als wenn ich die Entartung als Normalität akzeptiere.
Abgesehen davon: wenn sich solche Schwächen erst einmal einschleifen, bekommt man später Probleme, sich wieder von ihnen zu lösen.
Dem normalen Besucher der Seite fällt beim Betrachten der Webseite an sich kein Unterschied auf, ob diese nun aus Tabellen oder aus DIVs besteht. Und allein darum geht es mir... Und wenn die Seite einwandfrei funktioniert und so aussieht, wie sie aussehen soll, gibt es einfach keinen Grund, von Tabellen- auf CSS-Layout zu wechseln. Punkt. Es sei denn, man selbst fühlt sich mit dem Code besser.
Das ist nur so lange wahr, wie man reine Desktop-Clients mit handelsüblichen Auflösungen annimmt. Sobald man in Themen wie mobiles Internet, Barrierefreiheit etc. einsteigt, macht es einen großen Unterschied. Abgesehen davon habe ich nicht den Browser War überlebt, um mir Jahre später den gleichen Müll anzusehen.
Aber was ich hauptsächlich sagen möchte:
Überfordert die Leute nicht immer gleich mit "Bau erstmal Deine Seite komplett um", wenn es um ein einfaches Problem geht...Wie ich schon sagte, wäre es kein kompletter Umbau, sondern lediglich ein paar Tags und etwas CSS, die ausgetauscht hätten werden müssen. Du tust gleich so, als wären damit gleich 30 Arbeitsstunden verbunden. Wer damit überfordert ist, kann durchaus Rückfragen stellen. Wir sind keine elitären Snobs, sondern mehr oder weniger erfahrene Entwickler.
Gruß, LX
--
RFC 2324, Satz 7 (Sicherheit): Jeder, der zwischen meinem Kaffee und mir steht, gilt als unsicher.-
<div id="section_xy">
<h3>Forum</h3>
<div class="status">29 Themen auf 3 Seiten (275 Beiträge)</div>
<ul class="nav">
<li class="first suche"><a href="...">Foren-Suche</a></li>
<li class="last"><a href="...">Neues Thema starten</a></li>
</ul></div>
Nur der Fairness halber. Semantisch musst du nämlich auch erklären, was eine Einheit bildet, für die ein header angewendet wird. Deshalb verwende ich eine ID. Eventuell kann ich mir dadurch ein paar innere Klassen sparen. mfg Beat -- ><o(((°> ><o(((°> <°)))o>< ><o(((°>o Der Valigator leibt diese Fische-
Nur der Fairness halber.
In der Tabellenstruktur wird dieser Teil auch nicht völlig frei stehen, deshalb hatte ich ihn aus dem Kontext gelöst betrachtet. Ansonsten hast Du natürlich Recht.
Ob eine ID oder eine Klasse gewählt werden sollte, hängt letztlich davon ab, wie oft sich auf der Seite die betreffende Struktur wiederholen wird.
Gruß, LX
--
RFC 2324, Satz 7 (Sicherheit): Jeder, der zwischen meinem Kaffee und mir steht, gilt als unsicher.
-
-
Mahlzeit,
Das hat doch etwas mit Fähigkeiten zu tun, in diesem Fall die Fähigkeit, einen Aufbau semantisch zu gliedern.
Das gliedern, ist das geringste "Problem". Lustiger wirds, am CSS zu schrauben, bis es so aussieht, wie ich möchte... Und dann auch noch in allen Browsern inkl. dem IE 6, den ich leider nach wie vor nicht vernachlässigen möchte... Klar geht es, aber der Aufwand ist schlicht höher.
Wie schon gesagt, ich KÖNNTE es (sicherlich), sehe aber keine Veranlassung, da Barrierefreiheit für mich kein Thema ist. Wäre es das, würde ich Dir wahrscheinlich zustimmen. Da geht ohne Semantik nichts.
Ich hab niedrigere Ziele: Eine gutaussehende Webseite, die möglichst in allen Browsern gleich aussieht. Und zwar so, wie ich es mir vorstelle. Den meisten Hobby-Webmastern geht es da sicherlich genauso. Und das schafft man mit Tabellenlayouts in der Regel eher...
Ich habe an meinem Code wesentlich kürzer geschrieben als an Deinem - und das CSS, welches in jedem Fall für das Layout hinzukommt, wird auch nicht so viel komplizierter.
Falsch. Bei Dir fehlt an sich noch ALLES, was das Layout ausmacht. Du hast nur den Inhalt semantisch strukturiert. Das eigentliche "Layout" steckt dann im CSS. Im Endeffekt wird es zusammengerechnet nicht wirklich kürzer...
Dafür gibt es gleich mehrere praktikable Lösungen, die ohne den semantischen Mißbrauch einer Tabelle auskommen.
Ohne Höhenangabe? Je nach Inhaltshöhe passend? Woher weiss Dein linkes DIV, wie hoch das rechte ist? Ist zwar OT, aber würde mich interessieren...
Bitte zeige mir, wo in meinem Code eine DIV-Suppe steckt? Bei Bedarf hätte ich das einzige div auch durch p oder dfn ersetzen können, sah jedoch dazu keine Veranlassung. Übrigens: Die Lösung für das Problem "Div-Suppe" sind flache HTML-Strukturen, nicht Tabellen-Layout.
DIV-Suppe entsteht, sobald das Layout komplizierter wird. Klar, bei Tabellen wird das nicht besser. Aber ich find's halt ÜBERSICHTLICHER, weil ich schlichtweg besser damit klarkomme. Gerade auch durch die Möglichkeit, die Tabellengrenzen bei Bedarf einzublenden. Lass mir das doch.
Zur Erinnerung:
Aber wie schon gesagt: Ansichtssache...
Dem normalen Besucher der Seite fällt beim Betrachten der Webseite an sich kein Unterschied auf, ob diese nun aus Tabellen oder aus DIVs besteht. Und allein darum geht es mir... Und wenn die Seite einwandfrei funktioniert und so aussieht, wie sie aussehen soll, gibt es einfach keinen Grund, von Tabellen- auf CSS-Layout zu wechseln. Punkt. Es sei denn, man selbst fühlt sich mit dem Code besser.
Das ist nur so lange wahr, wie man reine Desktop-Clients mit handelsüblichen Auflösungen annimmt. Sobald man in Themen wie mobiles Internet, Barrierefreiheit etc. einsteigt, macht es einen großen Unterschied.
Barrierefreiheit ist für 90% der privaten Webseiten vollkommen schnurz. Sorry, dass ich das so sage, aber letztlich ist es so, auch wenn es natürlich gerade für behinderte Menschen schön wäre, wenn es anders wäre. Hängt aber halt auch von der Zielgruppe der Webseite ab...
Mobiles Internet funktioniert mit Tabellenlayouts meiner Erfahrung nach oft besser. Dabei spreche ich allerdings von richtigen Browsern und nicht denen, die glauben, meine Inhalte auf Mini-Displays neu angeordnet darstellen zu wollen. Aber die wird's dank Smartphone-Entwicklung bald auch nicht mehr geben. Mein Desire HD (Android 2.2) stellt im Standard-Browser meine Webseiten genauso dar, wie sie am Desktop erscheinen. Bei Semantischen Webseiten jedoch oftmals recht verschoben und durcheinander...Gruß,
Andreas-
Hi,
Barrierefreiheit ist für 90% der privaten Webseiten vollkommen schnurz. Sorry, dass ich das so sage, aber letztlich ist es so, auch wenn es natürlich gerade für behinderte Menschen schön wäre, wenn es anders wäre. Hängt aber halt auch von der Zielgruppe der Webseite ab...
Immer wieder diese absolut dümmliche Argumentation: „Behinderte sind halt nicht meine Zielgruppe“.
Sie *wären* aber vielleicht gerne Teil deiner Zielgruppe, würden dein Angebot vielleicht gerne Nutzen - wenn sie nicht diskriminierender Weise ausgeschlossen würden.MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right? -
Das gliedern, ist das geringste "Problem". Lustiger wirds, am CSS zu schrauben, bis es so aussieht, wie ich möchte... Und dann auch noch in allen Browsern inkl. dem IE 6, den ich leider nach wie vor nicht vernachlässigen möchte... Klar geht es, aber der Aufwand ist schlicht höher.
Dem wage ich höflich zu widersprechen. Selbst im IE6 kann man mit einfachen Mitteln ein vernünftiges Layout erreichen, wenn man auf ein paar Kleinigkeiten achtet.
Wie schon gesagt, ich KÖNNTE es (sicherlich), sehe aber keine Veranlassung, da Barrierefreiheit für mich kein Thema ist. Wäre es das, würde ich Dir wahrscheinlich zustimmen. Da geht ohne Semantik nichts.
Barrierefreiheit ist nur ein Thema, das von Semantik mindestens profitiert, wenn nicht sogar davon abhängt. Wartbarkeit, Portabilität, Erweiterbarkeit, Wiederverwendbarkeit, White-Hat SEO und nicht zuletzt das Semantic Web sind alles Themen, in denen Semantik eine Rolle spielt.
Ich hab niedrigere Ziele: Eine gutaussehende Webseite, die möglichst in allen Browsern gleich aussieht. Und zwar so, wie ich es mir vorstelle. Den meisten Hobby-Webmastern geht es da sicherlich genauso. Und das schafft man mit Tabellenlayouts in der Regel eher...
Im Gegenteil: man macht es sich mit Tabellenlayouts oft unnötig schwer. Man muss bspw. ständig die Anzahl der Tabellenzellen im Hinterkopf behalten, berücksichtigen, dass viele Browser die Breiten- und Höhenangaben nur als grobe Richtlinien behandeln und wesentlich mehr tippen.
Falsch. Bei Dir fehlt an sich noch ALLES, was das Layout ausmacht. Du hast nur den Inhalt semantisch strukturiert. Das eigentliche "Layout" steckt dann im CSS. Im Endeffekt wird es zusammengerechnet nicht wirklich kürzer...
Schon wieder daneben getippt. Ich habe bereits für das mobile Umfeld Seiten sowohl mit Tabellen-Layout als auch mit HTML5/CSS3 gebaut - und Überraschung: die HTML5/CSS3-Seiten sind teilweise deutlich kleiner. Das hängt natürlich insbesondere damit zusammen, dass man bei semantischen Formaten CSS-Definitionen gezielt zusammenfassen kann.
Ohne Höhenangabe? Je nach Inhaltshöhe passend? Woher weiss Dein linkes DIV, wie hoch das rechte ist? Ist zwar OT, aber würde mich interessieren...
Vielleicht muss es das gar nicht, weil ein Div darunterliegt, welches die Formatierung beider Spalten erledigt. Ein wenig Out-of-the-box-Denken wirkt oftmals Wunder.
Außerdem kommen Dir Tabellen spätestens dann in den Weg, wenn Du eine Darstellung erreichen willst, die keiner tabellarischen Struktur folgt.
DIV-Suppe entsteht, sobald das Layout komplizierter wird. Klar, bei Tabellen wird das nicht besser. Aber ich find's halt ÜBERSICHTLICHER, weil ich schlichtweg besser damit klarkomme. Gerade auch durch die Möglichkeit, die Tabellengrenzen bei Bedarf einzublenden. Lass mir das doch.
Wie schon gesagt: es ist nicht meine Aufgabe, Deine Schwächen zu beheben, sondern (wenn überhaupt) Deine. Allerdings haben wir hier auf dem Forum einen gewissen Anspruch an Professionalität - und dazu gehört eben auch Semantik. Das mag für Dich jetzt vielleicht schon wieder überheblich klingen, ist aber aus unserer Sicht einfach nur eine Grundanforderung unserer Tätigkeit, die uns das Leben erleichtert.
Barrierefreiheit ist für 90% der privaten Webseiten vollkommen schnurz. Sorry, dass ich das so sage, aber letztlich ist es so, auch wenn es natürlich gerade für behinderte Menschen schön wäre, wenn es anders wäre. Hängt aber halt auch von der Zielgruppe der Webseite ab...
Übersetzt klingt das verdammt nach "Behinderte Menschen sind mir scheißegal" - und Du nennst mich überheblich? Du solltest ganz dringend mal einen Realitätstest machen lassen, Du bist offenbar falsch geeicht.
Mobiles Internet funktioniert mit Tabellenlayouts meiner Erfahrung nach oft besser. Dabei spreche ich allerdings von richtigen Browsern und nicht denen, die glauben, meine Inhalte auf Mini-Displays neu angeordnet darstellen zu wollen. Aber die wird's dank Smartphone-Entwicklung bald auch nicht mehr geben. Mein Desire HD (Android 2.2) stellt im Standard-Browser meine Webseiten genauso dar, wie sie am Desktop erscheinen. Bei Semantischen Webseiten jedoch oftmals recht verschoben und durcheinander...
Meine semantischen Seiten sehen auf Android genausogut aus wie auf iPhoneOS, Symbian Series60, Bold (Blackberry), Opera Mobile/Mini... Natürlich können diese Browser auch Tabellenlayout fressen, aber das wäre so, als würde man Trüffel mit Ketchup essen.
Gruß, LX
--
RFC 2324, Satz 7 (Sicherheit): Jeder, der zwischen meinem Kaffee und mir steht, gilt als unsicher.-
Moin,
Im Gegenteil: man macht es sich mit Tabellenlayouts oft unnötig schwer. Man muss bspw. ständig die Anzahl der Tabellenzellen im Hinterkopf behalten, berücksichtigen, dass viele Browser die Breiten- und Höhenangaben nur als grobe Richtlinien behandeln und wesentlich mehr tippen.
Sehe ich kein Problem drin. Beim Hinzufügen einer Zeile kann man auch notfalls in der vorhergehenden Zeile nochmal nachschauen, wieviele Spalten zur Verfügung stehen. Nochmal zusammenfassend: Ich hatte noch NIE Probleme mit Tabellenlayouts. Daher sehe ich keinen Grund, davon abzuweichen (Barrierefreiheit mal ausgenommen, aber die ist für mich - und für viele andere - kein Thema). Aussagen wie "Man macht es sich schwer", sind eh Quatsch. Ob einem etwas schwer fällt, muss man schon selbst entscheiden. Nicht andere.
Außerdem kommen Dir Tabellen spätestens dann in den Weg, wenn Du eine Darstellung erreichen willst, die keiner tabellarischen Struktur folgt.
Logisch. Aber machen wir uns nichts vor. Mehr als 90% aller Layouts passen in Tabellen. Gerade die von "Anfängern", die eh meist aus Kopf, Navi, Inhalt und Footer bestehen. Aber selbst wenn mal Elemente dabei sind, die das nicht tun, dann werden die halt über DIV-Layer positioniert. Das eine schließt das andere ja nicht aus.
Nochmal als Zusammenfassung: Man kann logischerweise mit BEIDEM seine Ziele erreichen. Jeder muss allerdings für sich selbst entscheiden, welchen Weg er geht. Wer meint, er WOLLE seine Seite semantisch gliedern und ausschließlich über CSS stylen, KANN das selbstverständlich tun. Worum es mir geht: Er MUSS es nicht. Es besteht keine PFLICHT dazu, auch wenn einige hier immer wieder so tun. Und DAS und zwar ganz allein DAS ist mein Punkt in dieser Diskussion. Einige hier tun einfach immer so, als wäre es PFLICHT. Und das stimmt schlicht nicht.
Übersetzt klingt das verdammt nach "Behinderte Menschen sind mir scheißegal" - und Du nennst mich überheblich? Du solltest ganz dringend mal einen Realitätstest machen lassen, Du bist offenbar falsch geeicht.
Tja, die Entscheidung liegt aber letztlich ganz allein bei MIR, für wen ich meine Inhalte anbiete. Ob ich dabei Behinderte, Frauen, Männer, Kinder, Rentner, Schüler, Informatiker, Biologen, Ökos, Muttis, Vatis oder wenauchimmer nicht explizit berüchtige, ist meine Entscheidung. Wer mir das als "Rassismus" auslegt, hat Pech. Vielleicht bin ich tatsächlich kein "Gutmensch", der es ALLEN recht machen will. Interessanterweise kann ich damit leben, denn ich muss es auch nicht. Ich pöser Pursche.
Meine semantischen Seiten sehen auf Android genausogut aus wie auf iPhoneOS, Symbian Series60, Bold (Blackberry), Opera Mobile/Mini... Natürlich können diese Browser auch Tabellenlayout fressen, aber das wäre so, als würde man Trüffel mit Ketchup essen.
Hmmm... lecker Ketchup. Ich kenn allerdings keinen, der Trüffel mag. Außer vielleicht ein paar überhebliche Snobs [nicht auf Euch bezogen!], mit denen ansonsten keiner was zu tun haben will, weil sie schlicht extremst langweilig sind. Aber das ist ein anderes Thema ^^
Grüße,
Andreas-
Guten Morgen,
Sehe ich kein Problem drin. Beim Hinzufügen einer Zeile kann man auch notfalls in der vorhergehenden Zeile nochmal nachschauen, wieviele Spalten zur Verfügung stehen. Nochmal zusammenfassend: Ich hatte noch NIE Probleme mit Tabellenlayouts. Daher sehe ich keinen Grund, davon abzuweichen (Barrierefreiheit mal ausgenommen, aber die ist für mich - und für viele andere - kein Thema). Aussagen wie "Man macht es sich schwer", sind eh Quatsch. Ob einem etwas schwer fällt, muss man schon selbst entscheiden. Nicht andere.
Gut, dann lasse es mich umformulieren: Du machst es demjenigen schwer, der nach Dir kommt und Deinen Code warten muss. Wenn diese rein hypothetische Person nicht existent ist, kannst Du gerne weiter so verfahren wie bisher. Nur: versuche bitte unter keinen Umständen, das als professionelles Webdesign zu verkaufen. In meiner Zeit als Freelancer hatte ich zu oft und viel damit zu tun, die Mängel, die von Leuten mit der gleichen Einstellung produziert wurden, aus Seiten zu tilgen.
Logisch. Aber machen wir uns nichts vor. Mehr als 90% aller Layouts passen in Tabellen. Gerade die von "Anfängern", die eh meist aus Kopf, Navi, Inhalt und Footer bestehen. Aber selbst wenn mal Elemente dabei sind, die das nicht tun, dann werden die halt über DIV-Layer positioniert. Das eine schließt das andere ja nicht aus.
...und dann braucht man mal eine Änderung, die eben gerade nicht in das Raster passt. Wenn man Schwächen im Markup hat, wenden sie sich früher oder später gegen einen. Tabellen-Layout ist da kaum besser als Div-Suppe.
Nochmal als Zusammenfassung: Man kann logischerweise mit BEIDEM seine Ziele erreichen. Jeder muss allerdings für sich selbst entscheiden, welchen Weg er geht. Wer meint, er WOLLE seine Seite semantisch gliedern und ausschließlich über CSS stylen, KANN das selbstverständlich tun. Worum es mir geht: Er MUSS es nicht. Es besteht keine PFLICHT dazu, auch wenn einige hier immer wieder so tun. Und DAS und zwar ganz allein DAS ist mein Punkt in dieser Diskussion. Einige hier tun einfach immer so, als wäre es PFLICHT. Und das stimmt schlicht nicht.
Und hier scheiden sich die Geister. Wir Profis sehen unsere Pflicht nicht nur gegenüber unseren Kollegen, die an den gleichen Seiten arbeiten müssen, sondern auch gegenüber dem Internet selbst, welches von einer Semantik sehr profitieren kann. Hierbei von einer Pflicht zu sprechen, kann für den einen oder anderen vielleicht übertrieben wirken, aber eine Verpflichtung ist es allemal.
Natürlich kann man für sich selbst auch hier eine "der Rest der Welt kann mich mal, ich ziehe meinen eigenen Stiebel durch" vertreten, sollte diese aber bitte nicht auf andere zu übertragen versuchen.
Natürlich können [moderne mobile] Browser auch Tabellenlayout fressen, aber das wäre so, als würde man Trüffel mit Ketchup essen.
Hmmm... lecker Ketchup. Ich kenn allerdings keinen, der Trüffel mag. Außer vielleicht ein paar überhebliche Snobs [nicht auf Euch bezogen!], mit denen ansonsten keiner was zu tun haben will, weil sie schlicht extremst langweilig sind. Aber das ist ein anderes Thema ^^
Dann hast Du einfach noch keine guten Trüffel gekostet oder Du kennst einfach nur sehr wenig Leute mit gutem Geschmack. Ein Tip: in italienischen Feinkostläden findet man häufig sehr, sehr gute Nougat- und Mokkatrüffel. Einer davon - und Du möchtest die ganze Woche keine Schokolade mehr essen, weil sie längst nicht so gut schmeckt... ;-)
Gruß, LX
--
RFC 2324, Satz 7 (Sicherheit): Jeder, der zwischen meinem Kaffee und mir steht, gilt als unsicher. -
@@GrandmasterA:
nuqneH
Ob einem etwas schwer fällt, muss man schon selbst entscheiden. Nicht andere.
Dass es dir schwerfällt, dich vom Denken in Tabellen zu lösen, mag sein.
Anfängern, die bisher weder mit Tabellenlayout noch mit semantischem Markup plus CSS in Berührung kamen, sollte letzteres nicht schwerer fallen. Es gibt keinen Grund, sie auf den Irrweg zu führen.
Mehr als 90% aller Layouts passen in Tabellen.
Unsinn. Sobald @colspan oder @rowspan auftaucht, ist dies ein sicheres Zeichen, dass es eben nicht passt.
Ob ich dabei Behinderte, Frauen, Männer, Kinder, Rentner, Schüler, Informatiker, Biologen, Ökos, Muttis, Vatis oder wenauchimmer nicht explizit berüchtige, ist meine Entscheidung.
Es ist deine Entscheidung, ob du zugusten besserer Zugänglichkeit zusätzlichen Aufwand betreibst. (ARIA-Attribute etc.)
Es ist aber sinnlos, zusätzlichen Aufwand zu betreiben, der die Zugänglichkeit verschlechtert.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)
-
-
-
-
-
-
-
Hallo,
Ich komme mit einem Tabellenlayout deutlich schneller ans Ziel als mit 20 DIVs, in dem sich nur IDs befinden, die ich dann wieder in einer CSS-Datei zusammensuchen muss.
würde mir vermutlich auch so gehen. Aber wir reden ja nicht von unzähligen div-Elementen, sondern von einem sematisch sinnvollen Markup. *Das* lässt sich nämlich meistens sogar im Quellcode relativ flüssig lesen und nachvollziehen.
Funktional notwendig ist es nämlich in weiten Teilen schlicht nicht.
Das ist natürlich wahr, man kann auch mit Tabellen ein Layout bauen. Die Wahrscheinlichkeit, dabei von Fachleuten Hilfe zu kriegen, ist aber eher gering, weil die "sowas umständliches" meist nicht machen würden. Das ist so, als hättest du dein Wohnzimmer mit Apfelsinenkisten und Pappkartons möbliert, und fragst dann einen Einrichtungsfachmann um Rat.
My 2 cents
And another two,
Martin--
Computer funktionieren grundsätzlich nicht richtig.
Wenn doch, hast du etwas falsch gemacht.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
-
-
-
Om nah hoo pez nyeetz, GrandmasterA!
Wenn ich so einen Quatsch immer lese. Tabellen sind nicht für Layouts gedacht. Dennoch ist es kein "Fehler". Lediglich "unschön". Ich persönlich bevorzuge nach wie vor Tabellen zum Layouten, weil es mir schlicht einfacher fällt und ich damit viel schneller das erreiche, was ich möchte.
Was bin ich froh, dass ich deine Seite nicht warten muss. Vielleicht ändert sich deine Meinung nach dem nächsten Umbau der Seite.
Hilfreich für den OP sind beide Antworten sicher nicht.
Hilfreich wäre: "Du bist über ein Symptom gestolpert, dass aufgrund von Iframes und Tabellenlayout für dich und für Außenstehende nur mit größerem Aufwand zu beseitigen ist. Wenn du dich von deinem Tabellenlayout und den Frames trennen möchtest, wird dir hier sicher geholfen. Du wirst feststellen, dass Darstellungsfehler nach einer gewissen Einarbeitungszeit sehr viel leichter zu bearbeiten sind. Aufgrund des Quelltextes ist davon auszugehen, dass du die Seite über einen WYSIWIG-Editor wie zum Beispiel frontpage erstellst. Zudem enthalten die Seiten mehrere Fehler, wie zum Beispiel ungültige Attribute. Außerdem schickst du die Browser wegen der fehlenden Doctype-angaben in den Rate-Modus (Quirks), was wahrscheinlich auch die Ursache für die unterschiedliche Darstellung ist. Die Einen raten halt besser als Andere, was du eigentlich zeigen wolltest.
Unschön ist auch, dass du die Benutzung der rechten Maustaste gesperrt hast, so musste ich erst javascript deaktivieren, um die Bilder herunterladen zu können.
Wenn du von vorn beginnen möchtest, wirst du wie gesagt hier Hilfe erhalten. Für den Anfang beschäftige dich mit den Grundlagen, zum Beispiel im Selfhtml-Wiki, vielleicht im Tutorial.
Nur Mut!
Dein Lohn wird eine übersichtliche und leicht zu wartende Internetpräsenz sein. "
Matthias
--
Wer ein Problem beschreiben kann, hat es schon halb gelöst. (Julian Huxley)
-
Was bin ich froh, dass ich deine Seite nicht warten muss. Vielleicht ändert sich deine Meinung nach dem nächsten Umbau der Seite.
Wie schon geschrieben. ICH muss sie warten. Und ICH komme damit locker klar, da ICH sie geschrieben habe. Wenn ich beruflich Webseiten baue, mit denen auch andere klarkommen sollen, mach ich es ggf. anders. Das kann man im genannten Beispiel der OP allerdings ausschließen...
Hilfreich wäre: "Du bist über ein Symptom gestolpert, dass aufgrund von Iframes und Tabellenlayout für dich und für Außenstehende nur mit größerem Aufwand zu beseitigen ist.
Was hat das Tabellenlayout mit dem iFrame-Problem zu tun, außer, dass Ihr Euch beim Anschauen des Codes denkt "Nee, das ist aber unschön"? Richtig: Nichts.
Wenn du dich von deinem Tabellenlayout und den Frames trennen möchtest, wird dir hier sicher geholfen.
Und da sind die wieder... die unnötigen Forderungen. Zumindest, was das Tabellenlayout angeht. Mit Tabellen kann man genauso gut "Layouten" wie mit semantischem Markup. Man kann natürlich bei beiden Wegen Fehler machen. Der einzige Unterschied besteht IMHO im Code-Aufbau und der Frage, wie verschiedene Ausgabegeräte damit klarkommen. Für einfache Webseiten, die in normalen Browsern betrachtet werden sollen, ist es aber schlichtweg EGAL und reine persönliche Einstellungssache.
Bis 2001 wurde jedem, der die Frage nach "Navi links, Content rechts" gestellt hat, geantwortet: "Mach es mit Frames", ab 2002 mit "Mach es mit Tabellen", wenig später mit "Mach es mit semantischem Markup". Alles richtig und der Weiterentwicklung geschuldet. Aber deswegen sind "ältere" Methoden nicht grundsätzlich falsch, sondern kommen auf den Anwendungsfall an. Frames haben eindeutige Nachteile, bei Tabellen sehe ich innerhalb normaler Browser und "Wartbarkeit" keine Unterschiede. Außer, dass Tabellen EIGENTLICH nur für tabellarische Daten gedacht sind. Aber wen juckt das, solange es FUNKTIONIERT? Mich nicht. Und ich wette, da bin ich ebenfalls nicht der einzige.
Aufgrund des Quelltextes ist davon auszugehen, dass du die Seite über einen WYSIWIG-Editor wie zum Beispiel frontpage erstellst.
Siehste. Die Seite stammt mit ziemlicher Sicherheit aus dem npage-Webseiten-Baukasten. Wenn man sowas schon erkennt, sollte man zumindest auch so viel Feingefühl haben, zu erkennen, dass man keinen Profi vor sich hat, dem so allgemeine Hinweise wie "Bau erstmal alles um" nicht weiterhelfen. Sicherlich kann man nebenbei darauf hinweisen, wenn man es sich nicht verkneifen möchte, aber "Mach erstmal und komm dann wieder" sorgt maximal für Frustration.
Unschön ist auch, dass du die Benutzung der rechten Maustaste gesperrt hast, so musste ich erst javascript deaktivieren, um die Bilder herunterladen zu können.
Das ist wirklich "unschön" aber heutzutage ignorieren die meisten Browser solche Angaben sowieso. Davon abgesehen musst Du das Bild nicht herunterladen, denn Du hast es schon heruntergeladen. Aber ich denke mal, das wissen wir hier alle schon und braucht nicht diskutiert werden.
Aber allgemein wirkt Dein Posting tatsächlicher weniger "arrogant" (absichtlich in Anführungszeichen!) als das von LX, obwohl es das gleiche ausdrücken will. Klar, hast Du dafür länger gebraucht als LX... Aber letztlich wird es sich die OP daher sicherlich eher zu Herzen nehmen. Es hilft, wenn man sich einfach mal ein bissel in die Lage des Hilfesuchenden versetzt.
Gruß,
Andreas -
Hilfreich wäre: "Du bist über ein Symptom gestolpert, dass aufgrund von Iframes und Tabellenlayout für dich und für Außenstehende nur mit größerem Aufwand zu beseitigen ist. Wenn du dich von deinem Tabellenlayout und den Frames trennen möchtest, wird dir hier sicher geholfen. Du wirst feststellen, dass Darstellungsfehler nach einer gewissen Einarbeitungszeit sehr viel leichter zu bearbeiten sind. Aufgrund des Quelltextes ist davon auszugehen, dass du die Seite über einen WYSIWIG-Editor wie zum Beispiel frontpage erstellst. Zudem enthalten die Seiten mehrere Fehler, wie zum Beispiel ungültige Attribute. Außerdem schickst du die Browser wegen der fehlenden Doctype-angaben in den Rate-Modus (Quirks), was wahrscheinlich auch die Ursache für die unterschiedliche Darstellung ist. Die Einen raten halt besser als Andere, was du eigentlich zeigen wolltest.
Ich habe diese on-mouseover.de Vorlage verwendet und lediglich meine Texte, Bilder und Links eingefügt.
Die Doctype-angaben habe ich eigtl. auf jeder Seite, ich wüsste nicht, dass ich sie aufirgendeiner vergessen habe.
Unschön ist auch, dass du die Benutzung der rechten Maustaste gesperrt hast, so musste ich erst javascript deaktivieren, um die Bilder herunterladen zu können.
Das habe ich gestern versehentlich gemacht, als ich entdeckt hatte das es geht, wollte ich es testen und habe vergessen es wieder zu deaktivieren. Habe es jetzt wieder rückgängig gemacht.
Wenn du von vorn beginnen möchtest, wirst du wie gesagt hier Hilfe erhalten. Für den Anfang beschäftige dich mit den Grundlagen, zum Beispiel im Selfhtml-Wiki, vielleicht im Tutorial.
Ich würde mich freuen, wenn mir jemand helfen würde! Da ich ein Anfänger bin, wären Beispiele sehr hilfreich und nett.
-
Om nah hoo pez nyeetz, Julia!
Ich würde mich freuen, wenn mir jemand helfen würde! Da ich ein Anfänger bin, wären Beispiele sehr hilfreich und nett.
na dann los:
Zum Bearbeiten deiner HTML-Dokumente benötigst du einen Text-Editor. Ich empfehle Notepad++. Dann musst du dich für eine HTML-Variante entscheiden. Für diese baust du dir für eine Seite ein Grundgerüst. In diesem Forum werden dir stricte Varianten empfohlen werden, ich empfehle HTML4.01 strict.
Weiter nach dem Abendbrot.
Matthias
--
Wer ein Problem beschreiben kann, hat es schon halb gelöst. (Julian Huxley)
-
-
-
-
-
Hallo Julia,
Hallo, ich habe ein Problem mit meinem iframe.
Mit FF habe ich keine Probleme,
mit Google Chrome ist es nur etwas verschobenIFRAME-Elemente werden von den meisten Browsern so wie IMG-Elemente von Hause aus mit der http://de.selfhtml.org/css/eigenschaften/positionierung.htm#display@title=Display-Eigenschaft
inline-blockdargestellt. Es gibt aber hierzu meines Wissens keine Empfehlungen des W3C. Einzelne Browser machen es daher möglicherweise ein bisschen anders. Setze Display-Eigenschaft mal aufblock, dann verhält sich der IFRAME wahrscheinlich auch in allen Browsern gleich.http://meiert.com/de/publications/articles/20080225/
und mit dem IE habe ich einen weißen Hintergrund, obwohl ich den Hintergrund transparent eingestellt habe.
... um das zu unterbinden, verwendest du das ie-proprietäre Attribut allowtransparency="true"
Gruß Gernot
-
Hallo Julia,
Hallo, ich habe ein Problem mit meinem iframe.
Mit FF habe ich keine Probleme,
mit Google Chrome ist es nur etwas verschoben
IFRAME-Elemente werden von den meisten Browsern so wie IMG-Elemente von Hause aus mit der http://de.selfhtml.org/css/eigenschaften/positionierung.htm#display@title=Display-Eigenschaftinline-blockdargestellt. Es gibt aber hierzu meines Wissens keine Empfehlungen des W3C. Einzelne Browser machen es daher möglicherweise ein bisschen anders. Setze Display-Eigenschaft mal aufblock, dann verhält sich der IFRAME wahrscheinlich auch in allen Browsern gleich.Die Display-Eigenschaften sind schon auf block gestetzt.
und mit dem IE habe ich einen weißen Hintergrund, obwohl ich den Hintergrund transparent eingestellt habe.
... um das zu unterbinden, verwendest du das ie-proprietäre Attribut allowtransparency="true"Gruß Gernot
»»
Vielen Dank! Ich hatte zwar schonmal allowtransparency eingesetzt, aber hatte mich wohl vertippt, weil es nichts genutzt hatte. Jetzt funktioniert es! :)
Es ist jetzt nur noch etwas verschoben... kann ich das noch irgendwie verbessern?
-
-
Kann mir keiner helfen? :(
-
Hi,
Kann mir keiner helfen? :(
Nein - wenn du die bisherigen Antworten nicht mal einer Reaktion würdigst, dann lässt das nur den Schluss zu, dass dir gar nicht zu helfen ist.
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
-