Ich möchte noch ein paar Punkte anführen:
Mit Frames spart man keine Ladezeit!
Oft wird als Pro-Argument von Frames aufgeführt, dass der eine Teil der Seite doch nicht jedesmal neu geladen werden muss und das man deshalb Ladezeitvorteile hat. Das ist nicht so. Alle Bilder werden vom Browser sowieso gecached und müssen nicht nochmal gelesen werden. Also muss nur der Text neu geladen werden. Dafür hat man aber den Vorteil, dass man den (X)HTML overhead nicht mehrmals laden muss (wie im Frameset, wo jeder Bereich seinen Doketype, seinen Head usw. braucht). Und wer mal einen HTTP Header gesehen hat, der wird soetwas nicht wieder behaupten.
Frames sind sehr unflexibel!
Die sind sogar noch schlimmer als Tabellen, was die Flexibilität angeht. Möchte man irgendwas etwas exotischer gestalten, ufert das in verdammt viele Frames aus, was dann schlecht wartbar und auch schlecht zu benutzen ist (Stichwort: Focus). Eine Anpassung an die größe des Anwendungsfenster ist sehr schwierig.
Frames gehören nicht zum XHTML Standard
Zum Beispiel ist das target Attribut nicht mehr im Standard enthalten (ohne das kann man aber praktisch keine Frames benutzen). Das hat auch einen Grund, denn der Benutzer soll lernen seinen Browser zu bedienen und nicht von der Webseite bevormundet werden. Ich möchte entscheiden, wann eine neue Seite geladen wird und wann nicht.
Genauso sind solche Sachen, wie das weglassen des Randes usw. nicht mehr möglich.
Frames verleiten dazu JavaScript einzusetzen
Auf Seiten, die Frames benutzen kommt man nur selten um JavaScript herum (weshalb JavaScript nicht für elementare Dinge eingesetzt werden soll ist eine andere Sache. Nur so viel dazu: Nicht jeder hat JavaScript aktiviert und möchte damit belästigt werden (Mozilla für Linux hat es z.B. standardmäßig deaktiviert)).
Zum Beispiel ist es normalerweise nicht möglich zwei Frames gleichzeitig zu ändern. Und das nachladen von Framesets ist auch nur mit JavaScript möglich.
Anpassung des Menüs ist kaum möglich!
Wo bin ich denn gerade auf der Seite? Das fragt man sich öfter auf Seiten, die Frames zur Navigation einsetzen. Der Grund ist, dass sich das Menü nicht der Seite anpasst. Oft findet man auch die Untermenüpunkte ganz woanders, weil es eben ohne viel JavaScript nicht möglich ist das Menü zu erweitern.
sorry wenn ich jetzt Punkte doppelt nenne.
Wenn ich jetzt Tabellen sage, dann meine ich Tabellen als Layout mittel! Tabellen zum tabellieren von Daten sind nicht nur nützlich sondern auch wichtig!
Der Hauptgrund:
Tabellen sind dafür nicht gemacht worde
Tabellen sollen zum zusammenfassen von daten dienen - nicht zum positionieren von daten!
Browser die auf semantik parsen sind somit verloren. zB Sprach-Browser die die Seite als Sprachausgabe ausgeben. Denen ist die Positionierung egal. Und wie wollen die jetzt tabellen ausgeben? semantisch einfach eine katastrophe
Using tables for layouts is like wearing dress shoes jogging?both work, but they're the wrong tools for the job.
oder
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.
W3C HTML4.01 Spezifikation
Trennung von Design und Inhalt
Mit Tabellen webe ich das Design fest in die Seite ein -> keine Trennung vorhanden
Tabellen sind langsam.
Opera7 ist der 1. Browser den ich kenne der Tabellen rendern kann bevor er die ganze tabelle runtergeladen hat!
Das bedeutet, dass erst die ganze Seite geladen werden muss, bevor der Inhalt angezeigt wird!!!
das kann auf 36,6 Modems ganz schön lange sein.
Tabellen sind performance intensiv
Eine Tabelle zu rendern kostet viel CPU Zeit. OK, auf Desktop Systemen ist das egal, aber auf handheld systemen nicht!
Tabellen sind statisch
Man kann Tabellen nicht so flexible gestalten wie wenn man mit CSS könnte.
Wartbarkeit
Verschachtelte Tabellen sind recht kompliziert zum warten - CSS ist da viel klarer und feiner.
Traffic
Tabellen sind groß -> viel text.
verschachtelte Tabellen müssn eingerückt werden, sonst verliert man ganz die übersicht.
CSS dagegen wird gecacht -> einmal pro webseite runterladen und der browser cached die *.css Datei.
Tabellen sind auch nicht cross Browser fähig
Gegen CSS wird immer gebracht: ohne CSS-Support sieht die Seite scheiße aus.
ABER: exotische Browser stellen Tabellen auch nicht immer gut da - vorallem Handheld systeme
Suchmaschinen
Suchmaschinen können nicht immer Layout-Tabellen richtig lesen. Wie auch, sematisch ist da ja nix getrennt.
Templating
Wenn man viele verschachtelte Tabellen hat - dann wird das templating immer komplizierter!
Line Breaks
Wenn das Browser Fenster schmal ist, dann bricht eine Tabellenzeile trotzdem nicht um, und der user muss scrollen -> ganz böse
Drucken
Es kann Probleme beim Drucken von so großen Tabellen geben
Zukunft
Die Zukunft gehört CSS! Mit den ganzen Media-Typen ist CSS unschlagbar, da man verschiedene style für verschiedene medien angeben kann -> tabellen verhindern dieses feature dann teilweise (weil man ja die tabelle nicht ändern kann)
und er CSS Support wird immer besser werden - das problem mit den Tabellen bleibt!
[ Dieser Beitrag wurde am 08.03.2003 um 16:03 Uhr von Shade Of Mine editiert. ]
Das schöne daran ist, daß man alles auf Windows testen kann und es läuft ohne Änderungen dann unter LinApache.
Was mich etwas wundert ist, daß WIN MD5 verwendet in der htpasswd aber kein MD5 drin steht.
Quelle: dcljs FAQ:
<a href="xyz.htm" onclick="if(this.blur) this.blur()">Link</a>
Man sollte aber daran denken, dass damit der schöneren Optik auch Funktionalität zum Opfer fällt; u.a. hängt daran die Möglichkeit, Links mit der Tab-Taste anzuspringen.
Ab IE5.5 existiert für das HTML-Element a auch das Attribut hidefocus.
Aus:
http://www.php-center.de/faq/faq-open_exec.html#open_exec-4
Grundsätzlich kann man einen Dateidownload auf zwei verschiedene Arten realisieren: Entweder man schreibt ein PHP-Script, das einen Redirect (siehe Wie erzeuge ich mit PHP einen Redirect auf eine andere Seite?) auf die zu ladende Datei generiert, oder man startet den Download durch das PHP-Script. Die Methode mit dem Redirect hat den Nachteil, daß Anwender die Ziel-URL des Redirect mitbekommen und später dann direkt und ungeschützt auf diese Datei zugreifen können.
Will man das verhindern, muß man den Download innerhalb von PHP abhandeln. Die zu ladenden Dateien liegen dann außerhalb der Document Root des Webservers (haben also keine URL) und sind nur durch PHP zugreifbar. In PHP sendet man den passenden MIME-Typ als Header und schickt dann die gewünschte Datei hinterher. Natürlich kann man vorher noch einen Downloadzähler aktualisieren oder überprüfen, ob der Anwender überhaupt für den Download autorisiert ist.
# $download sei der Bezeichner für die zu ladende Datei
# Dieses Verzeichnis liegt außerhalb der Document_Root und
# ist nicht per URL zuzugreifen.
$basedir = "/home/www/download";
# Übersetzung von Download-Bezeichner in Dateinamen.
$filelist = array(
"file1" => "area1/datei1.zip",
"file2" => "area1/datei2.zip",
"file3" => "area2/datei1.zip"
);
# Einbruchsversuch abfangen.
if ($filelist[$download] == "")
die("Datei $download nicht vorhanden.");
# Vertrauenswürdigen Dateinamen basteln.
$filename = sprintf("%s/%s", $basedir, $filelist[$download]);
# Passenden Datentyp erzeugen.
header("Content-Type: application/octet-stream");
# Passenden Dateinamen im Download-Requester vorgeben,
# z.B. den Original-Dateinamen
$save_as_name = basename($filelist[$download]);
header("Content-Disposition: attachment; filename=\"".$save_as_name."\"");
# Datei ausgeben.
readfile($filename);
Achtung:
Hier noch ein Bug im IE: http://www.zend.com/manual/function.header.php
<?php
header("Content-type: application/pdf");
header("Content-Disposition: attachment; filename=downloaded.pdf");
/* ... output pdf file ... */
Note: There is a bug in Microsoft Internet Explorer 4.01 that prevents this from working. There is no workaround. There is also a bug in Microsoft Internet Explorer 5.5 that interferes with this, which can be resolved by upgrading to Service Pack 2 or later.
[ Dieser Beitrag wurde am 26.03.2002 um 09:03 Uhr von Loggy editiert. ]
XHTML hat gegenüber HTML 4.01 keine Kompatiblitätsprobleme, wenn man das eine oder andere beachtet. Deshalb gibt es überhaupt keinen Grund mehr HTML Dokumente zu entwickeln.
JavaScript hat natürlich ein gewissen Sicherheitsrisikopotential. Jedoch kann man mittlerweile behaupten, dass in Browsern, die auf Sicherheit Wert legen, wie etwa Mozilla, es da zu keinen Problemen kommen dürfte. Ein weit wichtigerer Punkt, weshalb JavaScript nicht von allen gemocht und somit ausgeschaltet wird, ist, dass man damit einfach viel zu sehr in die privaten Vorlieben des Surfers eingreifen kann (Popup Werbung, Veränderung der Browsergröße, löschen der History, Popup bei Beenden, Browser ohne Menü usw.).
CSS (Cascading Style Sheets)
Dies ist eine "Sprache", mit der man HTML und XHTML bzw. XML Dokumenten ein Aussehen verleihen bzw. individualisieren kann. In Strict HTML gibt es keine Elemente, die das Aussehen der Seite dahingehen verändern, dass es vom normalen inhaltlichen Kontext abweicht. Mit CSS kann man jedem HTML Element ein spezielles Aussehen verleihen und über Klassen und die direkte Ansprache spezieller Objekte das Ausehen der Website nach seinen Wünschen ändern. CSS sollte das einzige Mittel sein, seine Website zu designen.
[ Dieser Beitrag wurde am 05.03.2002 um 17:06 Uhr von Loggy editiert. ]
Das mit dem Auto ist quatsch. Dein Auto ist ist nämlich Standard konform, denn es wurde ja vom TÜV zugelassen. Natürlich sieht nicht jedes Auto gleich aus. Es ist auch nicht jedes Auto gleich gut und das ist mit Websiten genauso gut. Nur irgendwie halten es hier viele nicht für nötig, sich an den Standard zu halten. Beim Auto wäre gleich das Geschrei groß, wenn du den Standard der Autobreite von 2,55 m mal eben auf 2,75 m verbreitern würdest.
Es ist zwar richtig, dass dein propritäres Feature vielleicht in den Standard mit eingebaut wird. Aber wer sagt dir, dass es so eingebaut wird, wie du dir das gedacht hast. Keiner!
Und warum musst du alle Features ausreizen? Du musst eine Seite erstellen, die gut Aussieht, leicht zu benuzten ist und in der man gut Informationen konsumieren kann. Dazu brauche ich keine propritären CSS-Elemente!
Dass damit der Fortschritt nach vorne getrieben wird ist falsch. Hast du schonmal ein paar Working Drafts für CSS3 gesehen? Ich sage dir, da sind Sachen drin, von denen du noch nichtmal geträumt hast und ohne, dass sie irgendwer vorher benutzen müsste.
Was wäre, wenn jeder in seine Seiten einbaut, was ihm gerade gefällt? Ich baue mal ein <format> Tag ein, weil ich lustig bin. Wieso nicht? Geht doch nichts bei kaputt.
Ne, das kann es einfach nicht sein.