Orlando: Ersatz für target="_blank"

Beitrag lesen

Hi Michael,

<strong> als Ersatz für <h1> ist auch Mißbrauch.

jain, eher Unwissenheit, weil der Bereich ja von der Struktur her relativ unwichtig wird.

<span style="font-weight:bold>" für <h1> ist noch
schlimmerer Mißbrauch.

Vor allem, wenn da ein <span> so alleine in der Gegend rumsteht. Das sind aber alles Auswüchse der Hobby-DTPer, die einen WYSIWYG-Editor mit einem Malprogramm verwechseln. Ich sehe das nicht als spezifische CSS-Schwäche.

<h1 style="display:none">spam</h1> habe ich übrigens auch schon gesehen. Aber ich sag' nicht, wo ;D

Trotzdem wird <span> an-scheinend nicht abgeschafft.

Klar, wie soll man denn sonst arbeiten?

<p>bla <span class="bunti">noch mehr bla</span> bla</p>

lässt sich nicht anders umsetzen, wenn es für 'bunti' keinen entsprechenden Inline-Tag gibt. Und ein <b> in 'bunti' umzuformatieren, wäre krank - wenn auch valide.

Aber abgesehen davon sind Tabellen natürlich äußerst
sinnvoll, Formulare sowieso.

Eben. Genau wie Frames.

Nein ;) Gut, einigen wir uns bitte auf "für dich eher schon", "für mich eher nicht" und "pauschale Urteile sind falsch", ok?

wurde HTML überhaupt für Anwendungen geschaffen?

Wurden Computer für Privatanwender geschaffen?

Nein.

(Und ist das überhaupt relevant?)

Wenn man die Wurzeln nicht aus den Augen verlieren will, weil sie sich bis heute auswirken, denke ich schon.

Müssen sich diese Anwendungen in Seiten nach XHTML
1.1 befinden?

Wenn die Browser anfangen, den DOCTYPE auszuwerten,
wenn irgendwelche DIN-Normen erfunden werden, die
validen Code nach dem neuesten Standard erfordern,

Diese beiden Argumente lasse ich gerne gelten, nur muss es alternative Normen geben, falls eine bestimmte aus prinzipiellen Gründen nicht eingehalten werden kann. Blöd, wenn es nur eine als angesehen geltende Norm gibt, da hast du schon Recht.

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. Nein, ich wäre bestimmt kein guter Verkäufer ;)

Kannst du bitte mal konkret sagen, welche
Anwendungen du meinst?

Jede.

Das war konkret ;)

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? 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.

HTTP erlaubt, plattformübergreifend zu arbeiten.
Und "arbeiten" funktioniert in vielen Fällen mit
Mehrfensteranwendungen besser als ohne.

Wir reden von zwei verschiedenen Dingen. 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. Es ist ja auch bezeichnend, dass ich hier mit dir diskutiere, wo sich meine Abneigung doch im Missbrauch durch die Typen begründet, die auch hier 'reinschneien, nichts verstehen, sondern nur ihren Code abholen wollen. Wenn ich zum xten mal sage, "verwende keine Frames, die sind böse", dann geht's nicht vordringlich um einen pseudoreligiösen Kult, sondern um handfeste Probleme, die später mit Sicherheit auftauchen. ZweiFramesFragen usw...

Ich glaube übrigens auch, dass man mit dem DOM sehr viele Fälle abfangen kann, die bisher Frames unumgänglich machten.

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?

Dabei halte ich es für extrem kontraproduktiv, ohne
jede Not nicht aufwärtskompatibel zu sein.

Das bestreite ich absolut nicht, nur kann es von Zeit zu Zeit positiv sein, alte Zöpfe abzuschneiden. Gerade die Frames-Frage ist sehr diffizil, in bestimmten Fällen können sie sehrwohl sinnvoll sein. Allerdings kann sich das W3C nicht auf die Vernunft der Allgemeinheit verlassen, da hätte man ja <font> gleich drinlassen können. Gerade bei XHTML 1.1, das profundes Wissen voraussetzt, Frames zu verbieten, war tatsächlich sehr hart und trifft vielleicht wirklich die falsche 'Zielgruppe'. Vielleicht.

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.

Ich will ein WWW, das in letzter Konsequenz völlig
unabhängig von User Agents 'funktioniert'.

Das kann ich mir nicht vorstellen.

Meine Ausdrucksweise dürfte heute wieder mal absolut präzise sein :( Gemeint war jedenfalls, dass ich es gerne sähe, dass alle Seiten selbst in Browsern, die nur ein einziges Fenster kennen, keine Probleme bereiten.

Die User Agents orientieren sich letzten Endes an den
Bedürfnissen der User - ebenso wie andere Anwendungen.

Nicht umsonst bevorzuge ich Opera.

Daher würde ich es zB äußerst gerne sehen, wenn
Browser Links auf targets, die in keinem über-
geordneten Frameset definiert sind, schlicht
ignorieren, dazu gehört freilich auch "_blank".

Ich habe nichts gegen UserAgents, die so etwas kon-
figurierbar machen, wie auch den PopUp-Schutz in
JavaScript.
Nur ist das keine Aufgabe eines Standards, finde ich.

Gut, dann frage ich dich konkret: Was hat window.open() mit Hypertext zu tun? Ganz abgesehen von meiner PopUp-Allergie; ich verstehe es nicht.

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.

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.

Warum aber sollte Online-Banking ohne Frames nicht funktionieren? Diese Systeme sind doch in der Regel javabasiert. Ich bin ja dafür ohnehin zu paranoid...

Ü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 ;)

Auch solche Aspekte sollte man bei der Implementierung
neuer Features nicht völlig aus den Augen verlieren.
JavaScript ist ein gültiger Standard - und ein Browser,
der ihn absichtlich nur teilweise unterstützt, ohne
wenigstens abfragbar zu machen, da dem so ist, fördert
die Verbreitung von Standards nicht wirklich.

Es gibt <script> und <noscript>, <ein-bissl-script> wird's wohl nie geben. Da muss die Intelligenz beim Client liegen, klar.

Schönen Mittwoch & LG
Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html