nicht angemeldet
Hi Orlando,
Trotzdem wird <span> an-scheinend nicht abgeschafft.
Klar, wie soll man denn sonst arbeiten?
Wie soll ich ohne Frames arbeiten? ;-)
wenn es eine vertragliche Bedingung zwischen Auftrag-
geber und Auftragnehmer ist, wenn ... also: Ja.
Wenn ein Kunde etwas will, das es so nicht gibt,
handelt es sich um ein Problem des Vertriebs, das
die Produktion dann ausbaden muss.
Dieser Wunsch resultiert aber ggf. aus den beiden
vorherigen Aussagen (Browser und ISO-Norm).
Beispielsweise das Programm, mit dem ein
Schalterbeamte bisher auf einer proprietären Windows-
Maschine irgendwas in irgend einem Datenbestand ein-
trägt, ändert, nachsieht oder was auch immer.
Gibt's sowas? Ich meine, mit einem richtigem HTML-
Frontend, nicht nur etwas, das Daten via HTTP
übermittelt?
Was ist ein "richtiges" HTML-Frontend?
Ich kenne soetwas von einem Zeiterfassungssystem,
in dem man die Daten via Java-Applet einsammelt
und an die AS/400 schickt. Das ist ziemlich
plattformunabhängig, erfordert nur ein Fenster und
funktioniert prächtig.
Ich habe meine Bedenken, was Java angeht, seitdem
M$ und Sun sich so in der Wolle haben.
HTTP erlaubt, plattformübergreifend zu arbeiten.
Und "arbeiten" funktioniert in vielen Fällen mit
Mehrfensteranwendungen besser als ohne.
Wir reden von zwei verschiedenen Dingen.
Richtig. Bisher gehen aber beide unter Verwendung von
HTML - und ich möchte nicht gerne sehen, daß sich nur
wegen der Frames (mit irgendwas geht es halt immer los)
zwei separate Sprachen nebeneinander bilden müssen.
Wenn es dir darum geht, eine Anwendung (bzw.
Datentransfer) über HTTP zur Verfüfung zu stellen
und dabei ein Beispiel für eine geschlossene
Benutzergruppe nennst, so ist das etwas ganz
anderes, als mein Standpunkt, dass ein Meister des
Netzes meine Fenster gefälligst in Ruhe zu lassen
hat.
Ja. Aber nochmal: HTML leistet bisher beides, und ich
sehe wirklich nicht den Bedarf, das kaputt zu machen.
Ich glaube übrigens auch, dass man mit dem DOM sehr
viele Fälle abfangen kann, die bisher Frames
unumgänglich machten.
Ich verstehe nicht, wieso Du überhaupt etwas gegen
Frames hast (abgesehen von deren Umsetzung in den
UserAgents).
Schau Dir mal das Layout des GUI Deines Browsers an.
Was siehst Du? Oben einen Navigations-Frame, und unten
einen Arbeitsframe. Wundert Dich da, das jeder, der
eine Anwendung mit HTML-Seiten bauen will, sich an
genau dieser (sinnvollen!) Aufteilung orientiert
(schon allein, um die Schulungskosten der Anwender
in Grenzen zu halten!).
Die Millionen von Frames-Seiten, die Du alle nicht
magst, tun nichts anderes als die Hersteller _aller_
bekannten Rechner-Anwendungen (egal ob Browser oder
Textverarbeitung oder ...).
Und _diese_ Funktionalität bau mir bitte mal allein
mit DOM nach, ohne Frames.
Ich möchte, daß sich XHTML 1.1 durchsetzt.
Das wird nicht der Fall sein, wenn Browser weiterhin
machen, was sie wollen und nicht, was man ihnen
vorschreibt. Da ist zusätzlicher Druck vonnöten -
nur, woher soll der kommen?
Nicht dadurch, daß die Benutzer XHTML 1.1 nicht ein-
setzen können, weil es weniger kann als XHTML 1.0.
Gerade bei XHTML 1.1, das profundes Wissen voraus-
setzt, Frames zu verbieten, war tatsächlich sehr
hart und trifft vielleicht wirklich die falsche
'Zielgruppe'. Vielleicht.
Ich denke, jetzt sind wir auf einer Linie. ;-)
Vor allem, wenn der Sprach-Entwurf ausdrücklich ein
Modul-Konzept vorgibt. Das wird höchstens dazu führen,
daß sich proprietäre Module verbreiten und durchsetzen,
weil der W3C an der Realität vorbei denkt.
Eine eigene DTD zu schreiben, war bisher auch
möglich, diese Befürchtung teile ich nicht.
Diese hat aber nicht den Norm-Charakter des W3C.
Du willst doch nicht die Entstehung proprietärer
Lösungen erzwingen, wo bisher ein funktionierender
Standard existiert?
Gemeint war jedenfalls, dass ich es gerne sähe,
dass alle Seiten selbst in Browsern, die nur ein
einziges Fenster kennen, keine Probleme bereiten.
Das ist kein Problem der Sprachdefinition, sondern
eines der Implementierung des entsprechenden Programms.
Gut, dann frage ich dich konkret: Was hat
window.open() mit Hypertext zu tun?
Nichts. (Aber wieso reden wir plötzlich von JavaScipt?)
Ganz abgesehen von meiner PopUp-Allergie; ich
verstehe es nicht.
Du wirfst jetzt das _eventuelle_ Öffnen _eines_ Links
bei dessen Anklicken durch den Benutzer in einen Topf
mit dem automatischen Öffnen beliebig vieler Fenster
ohne den Willen des Benutzers - ist das fair?
Bietet ein Browser wie Mozilla dem Seitenautor eigent-
lich die Möglichkeit, irgendwie herauszufinden, welche
Features abgeschaltet wurden? (Analog zu <noscript>.)
Nein, das ist derzeit tatsächlich (noch?) ein
Problem. Browser sollten den Wunsch nach einem
neuen Fenster (einen Klick vorausgesetzt) umbiegen,
nicht wortlos abwürgen.
Mir geht es aber um die gesamte Palette dieser Features
- insbesondere darum, daß Mozilla einen internen
Browserfehler (!) meldet, wenn eine Seite mit einem
Hover-Effekt für Graphik-Buttons angezeigt wird, aber
per Konfiguration JavaScript das Recht, Bilder zu än-
dern, entzogen wurde.
Wenn nein: Wie stellst Du Dir die Nutzbarkeit solcher
Browser für kommerzielle Anwendungen (Online-Banking
etc.) vor, wenn der Seitenautor nicht mal eine Meldung
ausgeben kann, daß seine Anwendung aufgrund einer be-
stimmten Browser-Konfiguration nicht funktionieren
kann.
Dokumentation und FAQ.
Du weißt genau, wie viele DAUs (sagen wir mal: Online-
Bank-Kunden) vorher das Manual lesen.
(Weniger als Forum-Besucher die FAQ. ;-)
Die Dokumentation kann ja auch nicht mehr sagen als:
"Diese Anwendung funktioniert nur mit Browsern, in
denen nicht wesentliche Teile der Funktionalität vom
Benutzer bewußt abgeschaltet wurde".
Fragt sich nur, ob dem Benutzer klar ist, was von dem,
das er da abschaltet, "wesentlich" ist - und für wen.
Und wenn es da auf die Dauer Probleme gibt, bleibt
dem Anbieter nur zu sagen: "Die Funktionsfähigkeit
dieser Anwendung für den Browser Mozilla kann nicht
garantiert werden, weil man in dem zuviel herumfummeln
kann - verwenden Sie den Internet Exploder, wenn Sie
auf Nummer Sicher gehen wollen."
Genau das wollen wir aber beide bestimmt nicht.
Warum aber sollte Online-Banking ohne Frames nicht
funktionieren? Diese Systeme sind doch in der Regel
javabasiert.
Vielleich funktionieren sie auch ohne Frames. Nicht
aber diejenigen, die für Millionenaufwand mit Frames
implementiert wurden und die jetzt niemand mal eben
in die Tonne tritt, bloß weil der W3C das befiehlt.
Überlege Dir mal, wieviel Hotline-Personal die ent-
sprechenden Anrufe der Kunden binden können ... was
dann wiederum dazu führt, daß kommerzielle Anwender
solche Browser boykottieren und "den Marktführer"
pushen werden.
Ja, wären da nicht die Sicherheitsbedenken ;)
Diese sind aber bisher eher abstrakter Natur. Ein
Benutzer, der noch nie ein Sicherheitsleck erlebt
hat, entwickelt nicht automatisch ein Gefühl dafür.
Daß er aber auf einer Seite, die eben _nicht_ so
aussieht, wie er das gewohnt ist, erst mal mühsam
die Navigation lernen muß, _das_ merkt er sofort.
Es gibt <script> und <noscript>, <ein-bissl-script>
wird's wohl nie geben.
Da muss die Intelligenz beim Client liegen, klar.
Es gibt ja die Möglichkeit, die Existenz von Objekten,
Funktionen etc. mit "if" abzufragen. Etwas Vergleich-
bares muß es für abschaltbare Features auch geben.
Und die Sprachdefinition von JavaScript sollte bitte
_zuerst_ dieses Problem behandeln, bevor Browser auf
den Markt geworfen werden, die JavaScript nur noch
in verstümmelter Form verstehen, ohne daß der Autor
einer Seite, der sich bisher auf <script> und
<noscript> verlassen konnte, im Regen steht.
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael