Ersatz für target="_blank"

[Christoph Schnauß]

hallo Forum ;-)

in XHTML1.0 "strict" und dann auch in XHTML1.1 gibt es keine Möglichkeit mehr, mit "target" ein Verweisziel zu bestimmen. Ich habe versucht, einen möglichst unaufwendigen Ersatz zu finden, das heißt, ich wollte keine extra-Javascript-Funktion schreiben. Auzßerdem ist bei XHTML1.1 sowieso - wenn ich die DTD richtig verstanden habe - in <a> nur "onfocus" und "onblur" zulässig. Für 'target="_blank"' ist mir nix besseres bisher eingefallen als

<a href="" onfocus="window.open('http://forum.de.selfhtml.org',''); self.blur()">

das funktioniert im Prinzip ganz gut, es gibt nur einen "Schönheitsfehler: durch "self.blur()" verschwindet das aufrufende Fenster ganz in den Hintergrund, was so wirken kann, als ob es geschlossen würde. Weglassen kann mans allerdings nicht, da sonst der Focus auf dem Verweis stehenbleibt und sich das neue Fenster immer wieder öffnet, wenn man es zu schließen versucht. Gibts dazu nen Verbesserungsvorschlag?

Christoph S.

[Fabian Transchel]

hallo Forum ;-)

nabend

in XHTML1.0 "strict" und dann auch in XHTML1.1 gibt es keine Möglichkeit mehr, mit "target" ein Verweisziel zu bestimmen. Ich habe versucht, einen möglichst unaufwendigen Ersatz zu finden, das heißt, ich wollte keine extra-Javascript-Funktion schreiben. Auzßerdem ist bei XHTML1.1 sowieso - wenn ich die DTD richtig verstanden habe - in <a> nur "onfocus" und "onblur" zulässig. Für 'target="_blank"' ist mir nix besseres bisher eingefallen als

<a href="" onfocus="window.open('http://forum.de.selfhtml.org',''); self.blur()">

das funktioniert im Prinzip ganz gut, es gibt nur einen "Schönheitsfehler: durch "self.blur()" verschwindet das aufrufende Fenster ganz in den Hintergrund, was so wirken kann, als ob es geschlossen würde. Weglassen kann mans allerdings nicht, da sonst der Focus auf dem Verweis stehenbleibt und sich das neue Fenster immer wieder öffnet, wenn man es zu schließen versucht. Gibts dazu nen Verbesserungsvorschlag?

mhh, man könnte in des geöffnente fenster n timeout setzen, der es nach n paar milisecs wieder "vorholt"
ist nicht wesentlich eleganter, aber immerhin.

Christoph S.

Fabian

[Dmitri Rettig]

Hi,

dann ist aber das Fenster immer im Vordergrund, und das wollen wir ja alle nicht.

MfG Dmitri

[Stefan Einspender]

Hallo Christoph,

in XHTML1.0 "strict" und dann auch in XHTML1.1 gibt es keine Möglichkeit mehr, mit "target" ein Verweisziel zu bestimmen.

Gibts dazu nen Verbesserungsvorschlag?

verwende die Transitional-Variante. Was Du hier machst, und damit
meine ich ganz speziell den JS-Workaround, halte ich für groben
Unfug. Die Strict-Variante lässt das target-Attribut für das a-
Element nicht zu, wenn Du es benötigst, dann kannst Du dieses DTD
nicht verwenden.

Wo ist da das Problem, d.h. warum willst Du unbedingt Strict _und_
das target-Attribut verwenden?

Viele Grüße,
Stefan

[Christoph Schnauß]

hallo Stefan,

verwende die Transitional-Variante.

die gibts bei XHTML1.1 nicht :-(

Christoph S.

[Stefan Einspender]

Hallo Christoph,

verwende die Transitional-Variante.
die gibts bei XHTML1.1 nicht :-(

kenne mich da nicht so aus, aber XHTML 1.1 ist doch in dieser Modul-
bauweise, kann man da nicht einfach noch ein zusätzliches Modul ein-
binden, was Dir das target-Attribut für das a-Element ermöglicht?

Ist nur so eine Idee, theoretisch müßte es gehen.

Wenn nicht, dann kannst Du ja immernoch eine eigene DTD verwenden,
dann ist die Sache natürlich nicht mehr W3C XHTML 1.1 (Strict).

Viele Grüße,
Stefan

[Christoph Schnauß]

hallo Stefan,

kenne mich da nicht so aus, aber XHTML 1.1 ist doch in dieser Modul-
bauweise, kann man da nicht einfach noch ein zusätzliches Modul ein-
binden, was Dir das target-Attribut für das a-Element ermöglicht?

kein "offizielles". Also keines vom W3C. Zuständig ist für <a> in XHTML1.1 http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-hypertext-1.mod, und da steht drin:
<!ENTITY % a.attlist  "INCLUDE" >
<![%a.attlist;[
<!ATTLIST %a.qname;
      %Common.attrib;
      href         %URI.datatype;           #IMPLIED
      charset      %Charset.datatype;       #IMPLIED
      type         %ContentType.datatype;   #IMPLIED
      hreflang     %LanguageCode.datatype;  #IMPLIED
      rel          %LinkTypes.datatype;     #IMPLIED
      rev          %LinkTypes.datatype;     #IMPLIED
      accesskey    %Character.datatype;     #IMPLIED
      tabindex     %Number.datatype;        #IMPLIED

bei HTML "transitional" ist dagegen http://www.w3.org/TR/html4/loose.dtd zuständig, und da steht drin:
<!ELEMENT A - - (%inline;)* -(A)       -- anchor -->
<!ATTLIST A
  %attrs;                              -- %coreattrs, %i18n, %events --
  charset     %Charset;      #IMPLIED  -- char encoding of linked resource --
  type        %ContentType;  #IMPLIED  -- advisory content type --
  name        CDATA          #IMPLIED  -- named link end --
  href        %URI;          #IMPLIED  -- URI for linked resource --
  hreflang    %LanguageCode; #IMPLIED  -- language code --
  target      %FrameTarget;  #IMPLIED  -- render in this frame --
  rel         %LinkTypes;    #IMPLIED  -- forward link types --
  rev         %LinkTypes;    #IMPLIED  -- reverse link types --
  accesskey   %Character;    #IMPLIED  -- accessibility key character --
  shape       %Shape;        rect      -- for use with client-side image maps --
  coords      %Coords;       #IMPLIED  -- for use with client-side image maps --
  tabindex    NUMBER         #IMPLIED  -- position in tabbing order --
  onfocus     %Script;       #IMPLIED  -- the element got the focus --
  onblur      %Script;       #IMPLIED  -- the element lost the focus --
  >

Wenn nicht, dann kannst Du ja immernoch eine eigene DTD verwenden,
dann ist die Sache natürlich nicht mehr W3C XHTML 1.1 (Strict).

richtig, das wäre die Alternative (übrigens gibts "strict" bei XHTML1.1 nicht). Aber ich dachte mir halt in aller Unschuld, ich könnte mal hier im Forum nachfragen. Kommt ja manchmal vor, daß jemand was weiß, was mir nicht so ganz geläufig ist ;-)

Grüße aus Berlin

Christoph S.

[flgr]

hallo Forum ;-)

Moin!

in XHTML1.0 "strict" und dann auch in XHTML1.1 gibt es keine Möglichkeit mehr, mit "target" ein Verweisziel zu bestimmen. Ich habe versucht, einen möglichst unaufwendigen Ersatz zu finden

Jo, sollte meiner Meinung nach auch Sache des Users sein, ob er einen Link in einem neuen Fenster öffnen will.

<a href="" onfocus="window.open('http://forum.de.selfhtml.org',''); self.blur()">

Trotzdem werde ich versuchen dir zu helfen. Ist <a href="javascript:window.open('http://forum.de.selfhtml.org','');"> machbar? Klappt leider nicht in javascriptlosen Browsern (vielleicht sogar nur im Internet Explorer), das könnte man aber vielleicht per <script type="text/javascript">document.write("<a href="javascript:window.open('http://forum.de.selfhtml.org','');">Forumli</a>");</script><noscript><a href="http://forum.de.selfhtml.org">Forumli</a></noscript> umgehen.
Besonders elegant ist das aber auch nicht. Und ich bin mir nicht mals sicher, ob <noscript> da überhaupt so funktioniert (Braucht das nicht einen Bezug zu einem <script>-Tag?) und ob es das in XHTML 1.1 überhaupt noch gibt... :/

Christoph S.

Gruß,
flgr

[Christoph Schnauß]

hi,

Jo, sollte meiner Meinung nach auch Sache des Users sein, ob er einen Link in einem neuen Fenster öffnen will.

Nicht grundsätzlich. Wir hatten vor ganz kurzer Zeit mal ne Grundsatzdiskussion dazu (ist im Moment im "Zwischenreich"  -  also nicht mehr im Forum, aber auch noch nicht im Archiv). Wenn ich auf eine Seite verlinken möchte, deren Copyright nicht bei mir liegt, will ich das eben prinzipiell mit target="_blank" machen. Da interessiert mich der mögliche Wille meines Seitenbesuchers überhaupt nicht. Sonst soll er schon diese Entscheidung selbst treffen dürfen

Ist <a href="javascript:window.open('http://forum.de.selfhtml.org','');"> machbar?

machbar ja, aber die von mir gewählte "Kurzform" tuts auch, hab ich weniger Tipperei

Klappt leider nicht in javascriptlosen Browsern

richtig, aber irrelevant. Wer mit einem Browser unterwegs ist, der kein Javascript zuläßt, wird bereits vor Betreten der Seite woandershin umgeleitet, kommt also gar nicht erst in die Verlegenheit, hier nen Error zu produzieren

ich bin mir nicht mals sicher, ob <noscript> da überhaupt so funktioniert

tut es nicht, da es sich um XHTML1.1 handeln soll

Grüße aus Berlin

Christoph S.

[Michael Schröpl]

Hi Christoph,

ich auch, ich auch ... ;-)

Jo, sollte meiner Meinung nach auch Sache des
Users sein, ob er einen Link in einem neuen
Fenster öffnen will.
Nicht grundsätzlich. Wir hatten vor ganz kurzer Zeit
mal ne Grundsatzdiskussion dazu (ist im Moment im
"Zwischenreich"  -  also nicht mehr im Forum, aber
auch noch nicht im Archiv). Wenn ich auf eine Seite
verlinken möchte, deren Copyright nicht bei mir
liegt, will ich das eben prinzipiell mit
target="_blank" machen. Da interessiert mich der
mögliche Wille meines Seitenbesuchers überhaupt
nicht. Sonst soll er schon diese Entscheidung selbst
treffen dürfen

Und bei Verwendung von Framesets ist es sogar zwingend,
zur Vermeidung von "unfairen Schaufenster-Effekten"
Links nach externen Seiten durch Angabe eines targets
"nach draufen" zu lenken.

Mein aktueller Mißstand ist, daß ich halt invalide
Dokumente erzeuge, welche beim Validieren ausschließ-
lich diesen einen Fehler erzeugen.
Mal sehen, wann dem W3C etwas einfällt, das eine Al-
ternative zur Abschaffung von Frames darstellt ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Kai Lahmann]

hi

Mal sehen, wann dem W3C etwas einfällt, das eine Al-
ternative zur Abschaffung von Frames darstellt ...

Wenn endlich auch Microsoft position:fixed implementiert, sterben die Frames reihenweise.

Grüße aus Bleckede

Kai

[Michael Schröpl]

Hi Kai,

Wenn endlich auch Microsoft position:fixed
implementiert, sterben die Frames reihenweise.

ach ja, und Du paßt mir kostenlos meine ca. 1000
Dokumente mit verschachtelten (!) Frames an eine
div-Navigation an? Das freut mich aber ...

Merke: Etwas Neues wird nicht bloß deshalb verwendet,
weil es nur knapp schlechter ist als das Vorherige.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Malte1019]

g'nabend,

Wenn endlich auch Microsoft position:fixed implementiert...

hammse doch schon, nur halt in der Mac-version des IE... *fg*

Malte

[Orlando]

Hi Malte,

Wenn endlich auch Microsoft position:fixed implementiert...

hammse doch schon, nur halt in der Mac-version des IE... *fg*

wobei der Focus genauso wegscrollt, wie bei Opera...

LG Orlando

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

[Christoph Schnauß]

hallo Michael,

Und bei Verwendung von Framesets ist es sogar zwingend,
zur Vermeidung von "unfairen Schaufenster-Effekten"
Links nach externen Seiten durch Angabe eines targets
"nach draußen" zu lenken.

ich erinnere mich dunkel, daß es in SELFHTML eine Anmerkung zu "unfairen Schaufenstereffekten" gibt ;-)  -  und genau darum gehts mir bei diesem target=_blank"-Thema

Mal sehen, wann dem W3C etwas einfällt, das eine Al-
ternative zur Abschaffung von Frames darstellt ...

ich wiederhole mich ungern, aber: sparsam und bewußt eingesetzt, halte ich Frames nach wie vor für akzeptable Gestaltungsmittel, insbesondere, seitdem mozilla/Netscape sowie Konqueror sich iFrames gegenüber verständnisvoll zeigen. Ich bin sogar dankbar dafür, daß ich _vor_ dem Entwurf für irgendein neues Web-Layout jetzt entscheiden darf, ob ich auf Frames oder auf Layer (DIV's) setzen oder sogar beide Stilmittel kombinieren möchte.

Grüße aus Berlin

Christoph S.

[Stefan Einspender]

Hallo Christoph,

Wenn ich auf eine Seite verlinken möchte, deren Copyright nicht bei mir liegt, will ich das eben prinzipiell mit target="_blank" machen.

DU willst es so machen, es steht nirgends festgeschrieben, dass
es so gemacht werden muß. Ergo ist target="_blank" nicht zwingend
notwendig, ich z.Bsp. verwende es extrem selten ;-)

Da interessiert mich der mögliche Wille meines Seitenbesuchers überhaupt nicht.

Wirklich schade, was nützt es Deinen Besuchern, wenn sie Deinen
Willen "erdulden" müssen und umgekehrt, was nützt es Dir? Nichts,
ausser vielleicht die Gewissheit, Deinen Willen durchgesetzt zu
haben. Ich bin froh, dass es in Mozilla die Möglichkeit gibt,
target="_blank" generell zu unterbinden. Bei anderen Browsern
stelle ich erst beim Anklicken eines Links fest, ob der Ersteller
mir da ein neues Fenster aufzwingt :-/

Sonst soll er schon diese Entscheidung selbst treffen dürfen

?
Kennst Du etwa Websites, die bei internen Links target="_blank"
verwenden? DAS wäre ja dann die Frechheit schlechthin (ok, es mag
einige ganz seltene Ausnahmen geben), sowas ist mir bisher noch
nicht untergekommen. Ich denke mal, target="_blank" kommt nahezu
immer bei externen Links zu Einsatz.

richtig, aber irrelevant. Wer mit einem Browser unterwegs ist, der kein Javascript zuläßt, wird bereits vor Betreten der Seite woandershin umgeleitet

Meinst Du zufällig http://www.christoph-schnauss.de/? Ich war gerade
mal mit meinem Opera dort, wo ich nie JavaScript aktiviert habe und
muß sagen, ich bin ziemlich enttäuscht. Ich sehe nur eine komplett
leere Seite, kein Hinweis, kein Link, nichts :-(

Wieauchimmer, ich verstehe nach wie vor nicht, warum Du auf der
einen Seite eine Strict-DTD verwenden willst (oder eben XHTML 1.1)
und zugleich das target-Attribut benutzen willst. Da es dieses nun
eben nicht gibt, nimmst Du einen, wie ich finde, grauenvollen JS-
Workaround. Warum nicht XHTML 1.0 Transitional?

Es mag sein, dass Du Deine Dokumente dann syntaktisch korrekt sind,
d.h. erfolgreich validieren, aber semantisch bzw. strukturell sind
die "nachgebauten" target-Attributen in dieser XHTML-Version trotz-
dem falsch und wer da mal in den Quelltext schaut, dem wird es wohl
kalt den Rücken runterlaufen.

Vergleichen kann man es ungefähr mit jemand, der sich eine Sport-
wagen-Karosserie nimmt und da ganz normale Autoteile einbaut. Von
aussen schaut es dann wirklich gut aus und befriedigt die Eitel-
keit des Besitzer, bei einem Blick hinter die Kulissen sieht man
schnell, dass da mehr Schein als Sein ist ;-)

Viele Grüße,
Stefan

PS: Nimm's bitte nicht persönlich, ich hätte bei jedem anderen
    Forumsteilnehmer mit Deiner Absicht genau die gleichen Zeilen
    geschrieben, nur mit SO einer Idee war bisher keiner hier ;-)

[Christoph Schnauß]

rehi;-)

Wenn ich auf eine Seite verlinken möchte, deren Copyright nicht bei mir liegt, will ich das eben prinzipiell mit target="_blank" machen.
DU willst es so machen, es steht nirgends festgeschrieben, dass
es so gemacht werden muß. Ergo ist target="_blank" nicht zwingend
notwendig

nein, nicht zwingend. Aber für mich eine Prinzipienfrage, die ich inzwischen ein paarmal erläutert habe. Seiten, die ich nicht selbst gebaut habe, _dürfen_ nicht im selben Fenster (oder Frame) geöffnet werden, aber das Fenster soll auch nicht geschlossen werden.

Wirklich schade, was nützt es Deinen Besuchern, wenn sie Deinen
Willen "erdulden" müssen

wenn ich Besucher dazu erziehen kann, Copyrights zu beachten, nutzt das meines Erachtens sogar ziemlich viel

Kennst Du etwa Websites, die bei internen Links target="_blank"
verwenden?

darum gehts nicht. Aber auch bei "internen links" will ich mit Hilfe der rechten Maustaste entscheiden dürfen, ob es ein neues Fenster gibt oder nicht, und das soll natürlich auch jedem Besucher einer Seite, die ich gebaut habe, möglich sein.

Meinst Du zufällig http://www.christoph-schnauss.de/?

nein, _diese_ Adresse meinte ich jetzt grade nicht *g* Die war bis vor wenigen Minuten eine ziemlich schlecht gepflegte Kollektion, ich habe jetzt wenigstens erstmal die index-Datei korrigiert. Die Adresse dient mir im wesentlichen dazu, in nicht verlinkten Verzeichnissen allerhand Krimskrams durchzuspielen. Was da sonst noch zu sehen war, hätte ich seit knapp zwei Jahren erneuern müssen, kam aber immer nicht dazu.

Ich war gerade mal mit meinem Opera dort, wo ich nie JavaScript aktiviert habe und
muß sagen, ich bin ziemlich enttäuscht. Ich sehe nur eine komplett
leere Seite, kein Hinweis, kein Link, nichts :-(

prima, wenn das bei deaktiviertem Javascript so ist (hab ich auf diese Art nie überprüft), bin ich sehr zufrieden.

Im übrigen habe ich schlichtweg wenig Verständnis dafür, daß jemand Javascript in einem javascriptfähigen Browser abschaltet. Die einzige Begründung, die ich akzeptieren könnte, wäre ein Schutz vor unerwünschten popups

Wieauchimmer, ich verstehe nach wie vor nicht, warum Du auf der
einen Seite eine Strict-DTD verwenden willst (oder eben XHTML 1.1)
und zugleich das target-Attribut benutzen willst.

will ich gar nicht. Ich will XHTML1.1 ausprobieren, mehr nicht. Ich will einfach wissen, was ich in 5 Jahren sowieso als Standard werde machen müssen

Grüße aus Berlin

Christoph S.

PS: Nimm's bitte nicht persönlich, ich hätte bei jedem anderen
    Forumsteilnehmer mit Deiner Absicht genau die gleichen Zeilen
    geschrieben, nur mit SO einer Idee war bisher keiner hier ;-)

im Gegenteil: ich bin ein Forumsteilnehmer wie jeder andere auch, der einzige Unterschied besteht darin, daß ich in der Statistik etwas weiter oben (und unter dir) stehe. Das heißt eher, daß du  -  und jeder andere  -  mit mir "noch härter" reden müßtest. Ich nehme auf "Namen" auch keine Rücksicht. Das Forum hätte nun wirklich nix davon, wenn du mich anders behandeln wolltest als irgendwelche "newbies"

[Orlando]

Hi Christoph

DU willst es so machen, es steht nirgends festgeschrieben, dass
es so gemacht werden muß. Ergo ist target="_blank" nicht zwingend
notwendig

FULL ACK

nein, nicht zwingend. Aber für mich eine Prinzipienfrage, die ich inzwischen ein paarmal erläutert habe. Seiten, die ich nicht selbst gebaut habe, _dürfen_ nicht im selben Fenster (oder Frame) geöffnet werden, aber das Fenster soll auch nicht geschlossen werden.

Das verstehe ich nicht - wenn ich eine Seite konsequent in XHTML strict schreibe, dann impliziert das für mich mehr, als 'einfach nur validen Code zu schreiben'. Wie - nicht nur - ich hier schon des öfteren sagte: Dem Besucher muss es überlassen bleiben, ob er ein neues Fenster haben will, da hast du (du wolltest ja eine harte Kritik) einfach nicht mitzureden. Alles, was mein System zu beeinflussen versucht, lehne ich ab. Neue Fenster sind um nichts weniger ärgerlich als Werbe-PopUps. Wenn mein System ausgelastet ist, kann ein zusätzliches Fenster es abschmieren lassen (keine Kommentare, bitte) - da ich zT mit sehr vielen Fenstern arbeite, bin ich froh, dass Opera mich bei einem solchen Engpass warnt.

Wirklich schade, was nützt es Deinen Besuchern, wenn sie Deinen
Willen "erdulden" müssen

wenn ich Besucher dazu erziehen kann, Copyrights zu beachten, nutzt das meines Erachtens sogar ziemlich viel

Das hat mit Urheberrechtsverletzungen herzlich wenig zu tun, schließlich betreibst du ja kein Framing. Wenn du eine Unterscheidung für notwendig hältst, kennzeichne externe Links. Wenn du allerdings mit einem Frameset arbeitest, deklariere die Seiten nicht als 'strict', das ist aus gutem Grund nicht möglich.

Kennst Du etwa Websites, die bei internen Links target="_blank"
verwenden?

darum gehts nicht. Aber auch bei "internen links" will ich mit Hilfe der rechten Maustaste entscheiden dürfen, ob es ein neues Fenster gibt oder nicht, und das soll natürlich auch jedem Besucher einer Seite, die ich gebaut habe, möglich sein.

So sei es - sprach's und öffnete fortan alle Fenster im Hintergrund ;)

Meinst Du zufällig http://www.christoph-schnauss.de/?

nein, _diese_ Adresse meinte ich jetzt grade nicht *g*

*flöt*

Ich war gerade mal mit meinem Opera dort, wo ich nie JavaScript aktiviert habe und
muß sagen, ich bin ziemlich enttäuscht. Ich sehe nur eine komplett
leere Seite, kein Hinweis, kein Link, nichts :-(

prima, wenn das bei deaktiviertem Javascript so ist (hab ich auf diese Art nie überprüft), bin ich sehr zufrieden.

Und das nach so langer Zeit im Forum... *patsch* (das war berechtigte Notwehr). Tut mir leid, aber dafür habe ich absolut kein Verständnis, aber das sollte dich nicht überraschen.

Im übrigen habe ich schlichtweg wenig Verständnis dafür, daß jemand Javascript in einem javascriptfähigen Browser abschaltet.

Warum? Was, wenn mein Browser Javascript gar nicht beherrscht?

Wieauchimmer, ich verstehe nach wie vor nicht, warum Du auf der
einen Seite eine Strict-DTD verwenden willst (oder eben XHTML 1.1)
und zugleich das target-Attribut benutzen willst.

Wahrscheinlich, weil es in einer Frame-Seite externe Links gibt. Allerdings bedingt XHTML strict IMHO eine Einstellung, die auch keine Frames zulässt. Ich finde sie einfach furchtbar.

PS: Nimm's bitte nicht persönlich, ich hätte bei jedem anderen
    Forumsteilnehmer mit Deiner Absicht genau die gleichen Zeilen
    geschrieben, nur mit SO einer Idee war bisher keiner hier ;-)

Dochdoch...

</archiv/2002/4/9889/>
 </archiv/2002/6/13639/>
 </archiv/2002/4/9487/>

im Gegenteil: ich bin ein Forumsteilnehmer wie jeder andere auch, der einzige Unterschied besteht darin, daß ich in der Statistik etwas weiter oben (und unter dir) stehe. Das heißt eher, daß du  -  und jeder andere  -  mit mir "noch härter" reden müßtest. Ich nehme auf "Namen" auch keine Rücksicht. Das Forum hätte nun wirklich nix davon, wenn du mich anders behandeln wolltest als irgendwelche "newbies"

-> </faq/#Q-09b> *scnr*

LG Orlando

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

[Sven Rautenberg]

Moin!

nein, nicht zwingend. Aber für mich eine Prinzipienfrage, die ich inzwischen ein paarmal erläutert habe. Seiten, die ich nicht selbst gebaut habe, _dürfen_ nicht im selben Fenster (oder Frame) geöffnet werden, aber das Fenster soll auch nicht geschlossen werden.

Prinzipienfragen sind was feines. Damit kann man sich immer ganz fein rausreden, warum man ein bestimmtes Verhalten nicht zeigen möchte. Ist natürlich ganz legitim.

Allerdings ziehen Prinzipien eben manchmal zwingend Folgen nach sich. Beispiele:

Du willst das Bild vom Sonnenuntergang deines letzten Urlaubs auf der Seite zeigen -> du wirst nicht umhinkommen, entweder <img> auf der Seite einzubinden, oder ein Hintergrundbild zu definieren.

Du willst ein DHTML-Menü einbauen -> du wirst nicht umhinkommen, Javascript auf der Seite einzubauen.

Du willst nur mit HTML-Mitteln einen Link im neuen Fenster öffnen -> du wirst nicht umhinkommen, entweder eine Transitional-Variante einer DTD zu wählen, oder nicht valide Dokumente zu schreiben.

Ganz simpel: Das eine bedingt das andere. Wunschkonzert war mal, als jeder Browserhersteller sein eigenes Süppchen gekocht hat.

Wirklich schade, was nützt es Deinen Besuchern, wenn sie Deinen
Willen "erdulden" müssen
wenn ich Besucher dazu erziehen kann, Copyrights zu beachten, nutzt das meines Erachtens sogar ziemlich viel

Ich verstehe jetzt nicht ganz, wie man durch Öffnen oder Zulassen neuer Fenster irgendeinen Einfluß auf das Copyrightverhalten anderer Menschen ausüben kann.

Kennst Du etwa Websites, die bei internen Links target="_blank"
verwenden?
darum gehts nicht. Aber auch bei "internen links" will ich mit Hilfe der rechten Maustaste entscheiden dürfen, ob es ein neues Fenster gibt oder nicht, und das soll natürlich auch jedem Besucher einer Seite, die ich gebaut habe, möglich sein.

Hm, irgendwie ist deine Aussage erstens konfus im Bezug auf Stefans Einwurf, und zweitens ein Plädoyer gegen target_blank bei internen Links.

PS: Ich entscheide meist nicht mit der rechten Maustaste, sondern mit Shift-Strg-Klick. :)

Wieauchimmer, ich verstehe nach wie vor nicht, warum Du auf der
einen Seite eine Strict-DTD verwenden willst (oder eben XHTML 1.1)
und zugleich das target-Attribut benutzen willst.
will ich gar nicht. Ich will XHTML1.1 ausprobieren, mehr nicht. Ich will einfach wissen, was ich in 5 Jahren sowieso als Standard werde machen müssen

Aha. Dann nimm einfach zur Kenntnis: Wer Frames benutzt, ist scheinbar irgendwie mit (X)HTML Frameset und (X)HTML Transitional verbunden. Wer keine Frames benutzt, braucht auch keine Targets, und hat (X)HTML Strict zur Verfügung.

Wenn du target_blank benötigst, wende dich vertrauensvoll ans W3C und diskutiere das mit denen durch. Wenn das zu aufwendig wird, oder die Herrschaften gute Gründe für die Abwesenheit von target-Angaben in den strengeren Standards haben, die du entweder nicht als stichhaltig ansiehst oder schlicht nicht akzeptierst, dann wird das keine Einführung des Attributs bringen und dir auch nicht weiterhelfen, aber immerhin weißt du dann, welche DTD für deine Dateien zweckmäßig ist.

Ich hab übrigens ein wenig auf dem Maillist-Server vom W3C gestöbert nach möglichen Argumenten gegen das target-Attribut.

Zunächst hab ich das hier gefunden: http://lists.w3.org/Archives/Public/www-html/2001Oct/0032.html
Es wird doch allen ernstes vorgeschlagen, für Mozillas neue Tabs ein Linkziel "_tab" zu erfinden. Naja, daß damit beliebig viele Probleme bei alten Browsern verbunden sind, scheint dem Ideenhaber nicht aufzufallen.

Die Gegenargumente sind aber in der Tat gut: HTML ist nur dafür da, die Dokumentstruktur zu beschreiben - um das Aussehen und Browserverhalten soll sich im Prinzip CSS kümmern.

So ziemlich alle erklärenden Postings der Suchergebnisse unter http://www.w3.org/Search/Mail/Public/search?type-index=www-html&index-type=t&keywords=target+_blank&search=Search sagen aus, daß Strict-Varianten die Browserwelt beschreiben, wie sie sein soll, nicht wie sie schon ist. Insofern leite ich daraus ganz selbstverständlich ab, daß es Transitional noch eine ganze Zeit lang geben wird - HTML 4.01 stirbt ja nicht plötzlich aus, sondern es ist wohldefiniert und veröffentlicht - kein Browser der näheren Zukunft wird sich erlauben, HTML nicht mehr zu verstehen. Und mit XHTML 1.0 Transitional ist man genausogut bedient, hat vielleicht Vorteile bei irgendwelchen XML-Operationen. Aber warum denn nicht Transitional?

Wenn du strict bleiben willst, gibts keine Targets. Wenn du Targets willst, gibts kein strict. Da beißt sich die Katze in den Schwanz, das kann man endlos diskutieren, bis man alt und grau geworden ist, und endlich neue Standards existieren. :)

- Sven Rautenberg

[Michael Schröpl]

Hi Sven,

Aha. Dann nimm einfach zur Kenntnis: Wer Frames
benutzt, ist scheinbar irgendwie mit (X)HTML
Frameset und (X)HTML Transitional verbunden.

keineswegs. Ich habe etwa 95% Dokumente, die ich
prima innerhalb von Frames anzeigen lassen kann und
die gleichzeitig XHTML 1.1-valide sind. Nämlich alle,
die keinen Link nach einer externen Website enthalten.

Die Gegenargumente sind aber in der Tat gut: HTML
ist nur dafür da, die Dokumentstruktur zu be-
schreiben - um das Aussehen und Browserverhalten
soll sich im Prinzip CSS kümmern.

Mit dieser Einstellung dagegen könnte ich leben -
wenngleich ich mir keine "natürliche" Stelle in CSS
vorstellen kann, wo so etwas sinnvollerweise definiert
werden könnte. targets sind etwas zwingend an die je-
weilige tag-Instanz Gebundenes, man müßte also IDs
verwenden (bzw. eher mißbrauchen).

Ich finde zudem, daß CSS das Aussehen eines Dokuments
beschreibt und nicht das Verhalten des Browsers als
Mehrfenster-HTTP-Client insgesamt. Da in HTML über
die gesamte Formular-Verarbeitung eine ganze Menge
"Verarbeitungslogik" enthalten ist, passen targets
m. E. sehr viel besser nach HTML als nach CSS.

Ich bestehe nicht auf der Existenz eines HTML-Attributs
zu diesem Zweck - ich finde nur, der W3C sollte _zu-
erst_ die (CSS-) Ablösung anbieten und zu diesem Zeit-
punkt dann _anfangen_, das target-Attribut als
deprecated anzusehen. Nicht anders herum.
Bei allen anderen (mir bekannten) Dingen, die in XHTML
1.0 strict nicht mehr erlaubt sind, gibt es bereits
eine Ersatzlösung in CSS - bloß eben für die targets
nicht. Und das ist das Problem.

Und mit XHTML 1.0 Transitional ist man genausogut
bedient, hat vielleicht Vorteile bei irgendwelchen
XML-Operationen. Aber warum denn nicht Transitional?

Weil Validieren gegen 1.0 Strict bzw. 1.1 eben sehr
viel zuverlässiger prüft, daß man wirklich CSS ein-
setzt, wo man CSS einsetzen sollte.
Ich _will_ CSS verwenden, wo es sinnvoll ist - und ich
will den Validator als Hilfsmittel dafür einsetzen.

Wenn du strict bleiben willst, gibts keine Targets.
Wenn du Targets willst, gibts kein strict. Da beißt
sich die Katze in den Schwanz, das kann man endlos
diskutieren, bis man alt und grau geworden ist, und
endlich neue Standards existieren. :)

Genau diese fehlenden Standards beklagen Christoph
und ich. Es ist Unfug vom W3C, etwas Etabliertes schon
mal präventiv abzuschaffen mit dem Hinweis, daß es
aber demnächst in CSS wieder eingeführt wird.
Das ist kein Migrationskonzept - das ist Sabotage.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Orlando]

Hi Michael,

Aha. Dann nimm einfach zur Kenntnis: Wer Frames
benutzt, ist scheinbar irgendwie mit (X)HTML
Frameset und (X)HTML Transitional verbunden.

keineswegs. Ich habe etwa 95% Dokumente, die ich
prima innerhalb von Frames anzeigen lassen kann und
die gleichzeitig XHTML 1.1-valide sind. Nämlich alle,
die keinen Link nach einer externen Website enthalten.

mag sein, aber sobald du einen externen Link setzen willst, gibt's kein strict mehr - und das ist AFAIK Christophs Problem.

Die Gegenargumente sind aber in der Tat gut: HTML
ist nur dafür da, die Dokumentstruktur zu be-
schreiben - um das Aussehen und Browserverhalten
soll sich im Prinzip CSS kümmern.

Mit dieser Einstellung dagegen könnte ich leben -
wenngleich ich mir keine "natürliche" Stelle in CSS
vorstellen kann, wo so etwas sinnvollerweise definiert
werden könnte. targets sind etwas zwingend an die je-
weilige tag-Instanz Gebundenes, man müßte also IDs
verwenden (bzw. eher mißbrauchen).

So hat's Sven auch nicht gemeint, bestimmt nicht ;) Mit 'Browserverhalten' war wohl alles gemeint, was sich innerhalb eines Fensters abspielt, nicht das Fenster selbst.

Bei allen anderen (mir bekannten) Dingen, die in XHTML
1.0 strict nicht mehr erlaubt sind, gibt es bereits
eine Ersatzlösung in CSS - bloß eben für die targets
nicht. Und das ist das Problem.

Bei all den Problemen, die Frames verursachen, sehe ich das nicht als Problem, sondern als ernstzunehmenden Hinweis, tunlichst darauf zu verzichten. Übrigens, weil ich's vorher vergessen habe - die Frage, ob eine Site nun transitional oder strict zu sein hat ist lächerlich, wenn man bedenkt, dass man ohne Javascript nichtmal Zugang hat...

Genau diese fehlenden Standards beklagen Christoph
und ich. Es ist Unfug vom W3C, etwas Etabliertes schon
mal präventiv abzuschaffen mit dem Hinweis, daß es
aber demnächst in CSS wieder eingeführt wird.

Targets in CSS? Verwechselst du da nicht etwas?

LG Orlando

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

[Michael Schröpl]

Hi Orlando,

mag sein, aber sobald du einen externen Link setzen
willst, gibt's kein strict mehr

das ist ja okay. Aber es gibt auch kein XHTML 1.1 mehr

• und das finde ich falsch.
  Gerade wenn XHTML 1.1 aus Modulen bestehen soll, was
  spricht gegen Module für Frames? Du mußt sie ja nicht
  verwenden, genau wie eine Menge anderer tags.
  Willst Du auch gleich Formulare abschaffen, und
  Tabellen, und ... ?

Bei all den Problemen, die Frames verursachen, sehe
ich das nicht als Problem, sondern als ernstzu-
nehmenden Hinweis, tunlichst darauf zu verzichten.

Genau das ist es, was ich dem so W3C nicht zugestehe.

In HTTP plus HTML gibt es mehr als nur Dokumente -
nämlich Anwendungen. Und die funktionieren mit sepa-
raten Fenstern in einer ganz anderen Dimension als
mit nur einem.
Willst Du "zurück nach DOS", nur wegen der "reinen
Lehre" des W3C? Oder willst Du das WWW in zwei Netze
trennen, eines für Dokumente und eines für Dienste,
mit getrennten tags-Sprachen und Browsern?
Das kann's doch nicht wirklich sein.

Targets in CSS? Verwechselst du da nicht etwas?

</?m=85069&t=15222> - meine Idee war es nicht ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Orlando]

Hi Michael,

mag sein, aber sobald du einen externen Link setzen
willst, gibt's kein strict mehr

das ist ja okay. Aber es gibt auch kein XHTML 1.1 mehr

Wenn man sich die Entwicklung von HTML 4 über XHTML 1.0 strict zu XHTML 1.1 ansieht, ist der Weg konsequent und für mich nachvollziehbar. Ich sehe aber durchaus die Schwierigkeiten, die sich daraus ergeben. Allerdings _vermute_ ich hinter dem Schwenk zum Purismus eine übersteigerte Gegenbewegung zur Klickibunti-Meute... nennen wir es Besinnung.

Gerade wenn XHTML 1.1 aus Modulen bestehen soll, was
spricht gegen Module für Frames? Du mußt sie ja nicht
verwenden, genau wie eine Menge anderer tags.

Ich habe ja kein Problem mit Frames. Von mir aus kann sie jeder einsetzen - nur nimmt man damit eben zahlreiche Einschränkungen in anderen Bereichen in Kauf, die man im W3C offenbar nicht haben will.

Willst Du auch gleich Formulare abschaffen, und
Tabellen, und ... ?

Über die Abschaffung von Tabellen zwecks gewaltsamer Aufteilung einer Seite ließe sich reden. Das _ist_ Missbrauch. Du siehst in mir einen Fundi, ich wusste es ;) Aber abgesehen davon sind Tabellen natürlich äußerst sinnvoll, Formulare sowieso.

Bei all den Problemen, die Frames verursachen, sehe
ich das nicht als Problem, sondern als ernstzu-
nehmenden Hinweis, tunlichst darauf zu verzichten.

Genau das ist es, was ich dem so W3C nicht zugestehe.

Ich seh's anders, aber das ist ja auch nur eine Meinung ;)

In HTTP plus HTML gibt es mehr als nur Dokumente -
nämlich Anwendungen. Und die funktionieren mit sepa-
raten Fenstern in einer ganz anderen Dimension als
mit nur einem.

Wenn wir mal wieder bei einer Grundsatzdiskussion sind - wurde HTML überhaupt für Anwendungen geschaffen? Müssen sich diese Anwendungen in Seiten nach XHTML 1.1 befinden? Kannst du bitte mal konkret sagen, welche Anwendungen du meinst? Ich will dich da nicht falsch interpretieren (müssen).

Willst Du "zurück nach DOS", nur wegen der "reinen
Lehre" des W3C?

Nein, ich bin durchaus kein Geblendeter, kann mich nur zufällig mit dem Weg, den das W3C nimmt, identifizieren. Ich drehe den Spieß hiermit um und bezichtige dich der Hörigkeit, weil du nicht konforme Seiten um jeden Preis gegen eine falsche DTD validieren willst ;)

Oder willst Du das WWW in zwei Netze
trennen, eines für Dokumente und eines für Dienste,
mit getrennten tags-Sprachen und Browsern?

Ich will ein WWW, das in letzter Konsequenz völlig unabhängig von User Agents 'funktioniert'. Daher würde ich es zB äußerst gerne sehen, wenn Browser Links auf targets, die in keinem übergeordneten Frameset definiert sind, schlicht ignorieren, dazu gehört freilich auch "_blank".

Targets in CSS? Verwechselst du da nicht etwas?

</?m=85069&t=15222> - meine Idee war es nicht ...

Na, fühle dich beobachtet... :D

LG Orlando

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

[Michael Schröpl]

Hi Orlando,

Willst Du auch gleich Formulare abschaffen, und
Tabellen, und ... ?
Über die Abschaffung von Tabellen zwecks gewaltsamer
Aufteilung einer Seite ließe sich reden.
Das _ist_ Missbrauch.

<strong> als Ersatz für <h1> ist auch Mißbrauch.
<span style="font-weight:bold>" für <h1> ist noch
schlimmerer Mißbrauch.
Trotzdem wird <span> an-scheinend nicht abgeschafft.

Du siehst in mir einen Fundi, ich wusste es ;)
Aber abgesehen davon sind Tabellen natürlich äußerst
sinnvoll, Formulare sowieso.

Eben. Genau wie Frames.

Wenn wir mal wieder bei einer Grundsatzdiskussion
sind - wurde HTML überhaupt für Anwendungen
geschaffen?

Wurden Computer für Privatanwender geschaffen?
(Und ist das überhaupt relevant?)

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,
wenn es eine vertragliche Bedingung zwischen Auftrag-
geber und Auftragnehmer ist, wenn ... also: Ja.

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

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

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

Ich drehe den Spieß hiermit um und bezichtige dich
der Hörigkeit, weil du nicht konforme Seiten um
jeden Preis gegen eine falsche DTD validieren willst
;)

Ich möchte, daß sich XHTML 1.1 durchsetzt.
Dabei halte ich es für extrem kontraproduktiv, ohne
jede Not nicht aufwärtskompatibel zu sein.
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.

Oder willst Du das WWW in zwei Netze
trennen, eines für Dokumente und eines für
Dienste, mit getrennten tags-Sprachen und
Browsern?
Ich will ein WWW, das in letzter Konsequenz völlig
unabhängig von User Agents 'funktioniert'.

Das kann ich mir nicht vorstellen.
Die User Agents orientieren sich letzten Endes an den
Bedürfnissen der User - ebenso wie andere Anwendungen.

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.

Bietet ein Browser wie Mozilla dem Seitenautor eigent-
lich die Möglichkeit, irgendwie herauszufinden, welche
Features abgeschaltet wurden? (Analog zu <noscript>.)
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.
Ü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.
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.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Orlando]

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

[Michael Schröpl]

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

[Christoph Schnauß]

hallo Orlando,

Ich habe ja kein Problem mit Frames. Von mir aus kann sie jeder einsetzen - nur nimmt man damit eben zahlreiche Einschränkungen in anderen Bereichen in Kauf, die man im W3C offenbar nicht haben will.

Ich sehe einfach nicht richtig, was das für "einschränkungen" sein sollen. Was ich kenne, ist das Problem (besser Scheinproblem), daß Layer (DIV's) und also auch layer-basierte Menüs nicht über den Framebereich hinaus angezeigt werden können. Ein für meine Begriffe sehr leicht verkraftbares Manko. Welche Nachteile gibts denn sonst?

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

wie schön, daß wir an manchen Stellen durchaus übereinstimmen ;-)

Wenn wir mal wieder bei einer Grundsatzdiskussion sind

wir _sind_ bei einer Grundsatzdiskussion

wurde HTML überhaupt für Anwendungen geschaffen?

eindeutig nicht  -  aber _diese_ Fragestellung ist nicht korrekt. Obwohl die Frames _für_ HTML erdacht wurden, können sie mehr  -  in einem Frame kannst du innerhalb eines Framesets auch andere Protokolle als HTTP aufrufen, und das halte ich für einen unschätzbaren Vorteil.

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

nochmal: da verwechselst du was. "Anwendungen", wie Michael sie meint, sind nicht auf HTTP beschränkt. Daher erübrigt sich die Frage, ob sie XHTML1.1 sein müssen

Nein, ich bin durchaus kein Geblendeter

das hat niemand behauptet

kann mich nur zufällig mit dem Weg, den das W3C nimmt, identifizieren.

Ohne Frage ist das, was das W3C als "nicht legislative Organisation" leistet, enorm. Gerade das und die strenge Logik, mit der bisher dort vorgegangen wurde/wird, macht es so ärgerlich, daß bei einer solchen "Winzigkeit" wie den target-Angaben offenbar die Logik-Konzeption bisher nicht berücksichtigt wurde

Grüße US Berlin

Christoph S.

[Linksetzer]

Ich sehe einfach nicht richtig, was das für "einschränkungen" sein sollen. Was ich kenne, ist das Problem (besser Scheinproblem), daß Layer (DIV's) und also auch layer-basierte Menüs nicht über den Framebereich hinaus angezeigt werden können. Ein für meine Begriffe sehr leicht verkraftbares Manko. Welche Nachteile gibts denn sonst?

http://www.subotnik.net/html/frames.html
http://selfsuche.teamone.de/
http://www.google.de/

[Christoph Schnauß]

http://www.subotnik.net/html/frames.html

das bringt mir keine neuen Erkenntniss
e

http://selfsuche.teamone.de/

wonach soll ich da suchen?

http://www.google.de/

eine nette Adresse  -  aber es steht bei _dieser_ Seite nix zu Frames.

Ich finde es ziemlich ärgerlich, daß es immer noch jemanden gibt  -  sogar in gehäufter Zahl  -  der sich als "Linksetzer" maskeiren zu müssen glaubt und häufig keine hilfreichen links setzt. Ausnahmen bestätigen den Gesamteindruck.

[Linksetzer]

http://www.subotnik.net/html/frames.html
das bringt mir keine neuen Erkenntniss
e

</?m=85706&t=15222>:
"Ich sehe einfach nicht richtig, was das für "einschränkungen" sein sollen."
"Welche Nachteile gibts denn sonst?"

http://www.subotnik.net/html/frames.html#top
http://www.subotnik.net/html/frames.html#konzept
http://www.subotnik.net/html/frames.html#skalierung
http://www.subotnik.net/html/frames.html#beispiel
http://www.subotnik.net/html/frames.html#suchmaschinen
http://www.subotnik.net/html/frames.html#minibrowser
http://www.subotnik.net/html/frames.html#hinweise
http://www.subotnik.net/html/frames.html#alternativen
http://www.subotnik.net/html/frames.html#links

http://selfsuche.teamone.de/
wonach soll ich da suchen?

http://selfsuche.teamone.de/cgi-bin/such.pl?suchausdruck=%2Bframes+%2Bnachteil&feld=alle&index_1=on&index_2=on&index_3=on&index_4=on&index_5=on&index_6=on&index_7=on&index_8=on&hits=alle

http://www.google.de/
eine nette Adresse  -  aber es steht bei _dieser_ Seite nix zu Frames.

http://www.pedant.de/

Ich finde es ziemlich ärgerlich, daß es immer noch jemanden gibt  -  sogar in gehäufter Zahl  -  der sich als "Linksetzer" maskeiren zu müssen glaubt und häufig keine hilfreichen links setzt.

http://www.machs-besser.de/

[Michael Schröpl]

Hallo Linksetzer,

."

"Welche Nachteile gibts denn sonst?"
http://www.subotnik.net/html/frames.html#top
http://www.subotnik.net/html/frames.html#konzept
http://www.subotnik.net/html/frames.html#skalierung
http://www.subotnik.net/html/frames.html#beispiel
http://www.subotnik.net/html/frames.html#suchmaschinen
http://www.subotnik.net/html/frames.html#minibrowser
http://www.subotnik.net/html/frames.html#hinweise
http://www.subotnik.net/html/frames.html#alternativen
http://www.subotnik.net/html/frames.html#links

Das einzige echte Problem (das mit den URIs) hast Du
ausgerechnet nicht mit aufgelistet. Einiges Anderes,
das dort aufgelistet ist, halte ich für konstruiert:
Einen reinen Frameset einer Suchmaschinen zum
Indizieren zu geben ist natürlich Unfug, aber einen
mit einem guten <noframes>-Inhalt wiederum nicht, und
zudem gibt es ja <meta>-Tags, um dieses Problem zu
lösen.

Ich finde es ziemlich ärgerlich, daß es immer
noch jemanden gibt  -  sogar in gehäufter Zahl
-  der sich als "Linksetzer" maskeiren zu müssen
glaubt und häufig keine hilfreichen links setzt.

Du kannst Dir ja mal den Linken Setzer als Vorbild
nehmen (ca. 250 Postings im Archiv sollten reichen).

Wenn Du dessen Qualität erreichst, was deep links an
exakte Stellen der Beschreibung einer problembezogenen
Aussage angeht, wird Dich niemand mehr kritisieren.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Orlando]

Hi Christoph,

Frames ... nur nimmt man damit eben zahlreiche Einschränkungen in anderen Bereichen in Kauf ...

Ich sehe einfach nicht richtig, was das für "einschränkungen" sein sollen. Was ich kenne, ist das Problem (besser Scheinproblem), daß Layer (DIV's) und also auch layer-basierte Menüs nicht über den Framebereich hinaus angezeigt werden können. Ein für meine Begriffe sehr leicht verkraftbares Manko. Welche Nachteile gibts denn sonst?

ich will nicht alles wiederholen, was der Nachwuchs-Linksetzer (jaja, die forsche Jugend...) schon gepostet hat, daher kurz die wichtigsten Punkte:

- Bookmarks
 - Suchmaschinentreffer
 - Textbrowser
 - Screenreader

Dagegen ist schwerlich zu argumentieren, ich weiß >;)

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

wie schön, daß wir an manchen Stellen durchaus übereinstimmen ;-)

Nicht eher an vielen? Jetzt hast du glatt weggelöscht, was mir so wichtig war: Tabellen sind nicht dazu erfunden worden, ganze Teile einer Seite einzusperren, sondern um tabellarische(!) Daten vernünftig darzustellen. Seit CSS gibt es absolut keinen Grund, dafür Tabellen zu verwenden. Sie zerstören den logischen Aufbau einer HTML-Seite.

Wenn wir mal wieder bei einer Grundsatzdiskussion sind

wir _sind_ bei einer Grundsatzdiskussion

Hehe, deutsche Sprache - schwere Sprache: Speziell in Wien ist "wenn" in obigem Zusammenhang absolut gleichwertig mit "weil". :)

wurde HTML überhaupt für Anwendungen geschaffen?

eindeutig nicht  -  aber _diese_ Fragestellung ist nicht korrekt.

Warum? Wenn Anwendungen als Beispiel genannt werden, ist diese Frage doch legitim, oder nicht?

Obwohl die Frames _für_ HTML erdacht wurden,

Das bezweifle ich ernsthaft. Frames wurden (vorsicht: IMHO) erdacht, weil sie die gleichzeitige Anzeige mehrerer Dokumente vereinfachen sollten, nicht weil sie für die Textauszeichnung notwendig gewesen wären.

können sie mehr  -  in einem Frame kannst du innerhalb eines Framesets auch andere Protokolle als HTTP aufrufen, und das halte ich für einen unschätzbaren Vorteil.

Habe ich ehrlich gesagt noch nie verwendet, ist aber ein interessanter Aspekt. Wo benötigt man das?

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

nochmal: da verwechselst du was. "Anwendungen", wie Michael sie meint, sind nicht auf HTTP beschränkt. Daher erübrigt sich die Frage, ob sie XHTML1.1 sein müssen

Dann schon, ja. Man sollte über XFTP 1.1 nachdenken. Nein, war ein Scherz...

Nein, ich bin durchaus kein Geblendeter

das hat niemand behauptet

Gerade wenn ich mit euch diskutiere, die ihr ja selbst für die Einhaltung von Standards eintretet und immer noch _ich_ der bin, der meckert, dann ist das schon etwas seltsam. Dabei pfeife ich im RL so ziemlich auf Konventionen. Verrückte Welt.

Ohne Frage ist das, was das W3C als "nicht legislative Organisation" leistet, enorm. Gerade das und die strenge Logik, mit der bisher dort vorgegangen wurde/wird, macht es so ärgerlich, daß bei einer solchen "Winzigkeit" wie den target-Angaben offenbar die Logik-Konzeption bisher nicht berücksichtigt wurde

Hypertext + Logik != Frames, denn Frames sind eine clientseitigige Angelegenheit. Das ist ja das, was ich an CSS so gerne habe. Man kann die tollsten Dinge machen und wenn ein Browser dann mal kein CSS unterstützt passiert ... nichts als HTML pur. Das 'philosophische' Problem mit den Frames besteht für mich einfach darin, dass man Programmfunktionalität einer Textauszeichnungssprache aufgepfropft hat.

Bis Donnerstag & LG
Orlando

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

[Michael Schröpl]

Hallo Orlando,

Das 'philosophische' Problem mit den Frames besteht
für mich einfach darin, dass man Programmfunktiona-
ität einer Textauszeichnungssprache aufgepfropft hat.

dann mußt Du aber mit demselben Argument auch gegen
Formulare sein, die mit Hypertext genauso wenig zu tun
haben - mit Programmfunktionalität aber sehr viel.

Und deshalb verstehe ich nicht, wieso Formulare weiter-
hin XHTML 1.1 sind, Frames aber nicht.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Schnauß]

huhu ;-)

das ist ja okay. Aber es gibt auch kein XHTML 1.1 mehr

wow, wie kommst du denn darauf? Und wie stimmt diese Aussage zu http://www.w3.org/TR/xhtml11/ ?

Grüße

Christoph S.

[Orlando]

huhu ;-)

Kuckuck, Christoph :D

das ist ja okay. Aber es gibt auch kein XHTML 1.1 mehr

wow, wie kommst du denn darauf? Und wie stimmt diese Aussage zu http://www.w3.org/TR/xhtml11/ ?

Warum reißt du den Satz denn so erbarmungslos aus dem Kontext? Zuerst unterstelle ich Michael, er wolle targets in CSS und dann legst du ihm in den Mund, es gäbe kein XHTML 1.1 mehr - üble Nachrede nennt man das *g*

So kam's dazu:

mag sein, aber sobald du einen externen Link setzen
willst, gibt's kein strict mehr

das ist ja okay. Aber es gibt auch kein XHTML 1.1 mehr

Jaja, wer den Schaden hat, spottet jeder Beschreibung *fg*

LG Orlando

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

[Christoph Schnauß]

Kuckuck, Christoph :D

öhm :-(
direkt gegenüber meiner Wohnung rattern seit zehn Tagen 20 Stunden lang täglich Baumaschinen und heben eine Baugrube aus ,da soll was entstehen, was sich übrigens sogar unter http://www.wohnetagen-steinstrasse.de als Planung anschauen läßt. Ich leide geringfügig unter Schlafentzug

Jaja, wer den Schaden hat, spottet jeder Beschreibung *fg*

gutgut, ich plädiere für Streichung ;-)

genervte Grüße

Christoph S.

[Michael Schröpl]

Hi Leute,

nur zu - mit mir könnt ihr's ja machen ... ;-)

(Äh - wie war doch gleich noch das eigentliche Thema?)

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael