nicht angemeldet
Hi Stefan,
Ich bin selber kein grosser Freund von Frames, aber die Art,
wie W3C diese immer noch ausklammern will, finde ich idiotisch.
Ich bin ein Freund von Frames - aber andererseits bin ich durchaus der
Meinung, daß ein Frameset-Dokument etwas substantiell Anderes ist als
ein 'normales' Dokument.
Ich finde die Idee, dafür zwei getrennte DTDs zu verwenden, naheliegend.
Daß ein Frameset im <noframes>-Bereich ein /fast) normales Dokument ent-
halten kann, halte ich für keinen Widerspruch zu meiner Aussage.
Ich fände es aber sinnvoll, wenn diese Trennung zwischen Dokument und
Frameset konsequenter durchgezogen würde.
Was ich an dieser Stelle schon mal andiskutiert hätte, wäre ein Konzept
(RFC?) zur Definition eines "Uniform Frameset Locators", also der
Codierung eines gesamten Frameset-Baums in linearer Form (und damit als
potentiellen Subset von URLs!).
Das, was ein Browser bei der Entstehungsgeschichte seines Fenster-Inhalts
durchgeführt hat, um einen beliebig tief geschachtelten Frameset-Baum zu
erzeugen, resultiert in einer Datenstruktur, die strukturell gesehen
nicht komplexer ist als ein HTML-Dokument selbst.
Wenn dann aber ein HTML-Dokument letztlich ein byte stream ist, wieso
kann das ein UFL nicht auch sein, und damit als URL (Bookmark, Link, ...)
verwendbar?
Gäbe es Ideen in dieser Hinsicht (und eine Umsetzung in einem der experi-
mentellen Browser, i. e. Opera / Mozilla), dann wären die bestehenden
Usability-Probleme von Frames zumindest deutlich reduzierbar.
Eine strict-Variante, die das Frames-Konzept mit integrieren wuerde,
waere begruendbar
Ja. Das Gegenteil ist es m. E. aber ebenfalls.
(Man kann alles beweisen, solange man von den richtigen Axiomen ausgeht. ;-)
und wuerde eine wesentliche hoehere Akzeptanz haben als es jetzt der
Fall ist.
Bei wem?
Ich halte eine wie auch immer geartete ästhetische DTD für Framesets nicht
für den Weg, deren Akzeptanz spürbar zu erhöhen.
Eine verbesserte Usability dagegen könnte helfen.
Viele Grüße
Michael