Absolute Pfadangabe

[Jnnbo]

Moin,

auf vielen Seite sehe ich wenn Bilder, CSS und JavaScripte eingebenden werden absolute Pfadangabe also mit http://www. beginnend.

Hat dieses irgendwelche Vorteile, sollte man dieses auf der eigenen Seite auch machen oder ist dieses einfach nur eine Geschmackssache?

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

auf vielen Seite sehe ich wenn Bilder, CSS und JavaScripte eingebenden werden absolute Pfadangabe also mit http://www. beginnend.

Hat dieses irgendwelche Vorteile, sollte man dieses auf der eigenen Seite auch machen oder ist dieses einfach nur eine Geschmackssache?

Es hat sogar Nachteile, wenn man z.B. mal den Domainnamen oder das Protokoll (http -> https) wechsel will.

Aber absolut zur Document Root, also "/images/thumbs/myimage.jpg" ist mMn besser, als "../../myimage.jpg"

Spirituelle Grüße
Euer Robert
[e-mail]

[Jnnbo]

Hallo robertroth,

Es hat sogar Nachteile, wenn man z.B. mal den Domainnamen oder das Protokoll (http -> https) wechsel will.

dieses Problem könnte man bestimmt mit PHP bewerkstelligen mit $_SERVER["HTTP_HOST"] oder?

Aber absolut zur Document Root, also "/images/thumbs/myimage.jpg" ist mMn besser, als "../../myimage.jpg"

mit ../.. habe ich noch nie gearbeitet. Lass meine Bilder so einbinden img/icons/ok.png und im Kopf meiner Seite befindet sich <base href="">

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Hallo robertroth,

Es hat sogar Nachteile, wenn man z.B. mal den Domainnamen oder das Protokoll (http -> https) wechsel will.

dieses Problem könnte man bestimmt mit PHP bewerkstelligen mit $_SERVER["HTTP_HOST"] oder?

jein. Da fehlt noch das passende Protokoll.

Aber absolut zur Document Root, also "/images/thumbs/myimage.jpg" ist mMn besser, als "../../myimage.jpg"

mit ../.. habe ich noch nie gearbeitet. Lass meine Bilder so einbinden img/icons/ok.png und im Kopf meiner Seite befindet sich <base href="">

Das ist doch das Gleiche. Das ist eine relative Pfadangabe. Wenn Du nun das Modul an anderer Stelle unterbringen willst, oder nochmal benutzten willst, dann passt der Pfad nicht mehr.

die Angabe "/img/icons/ok.png" ist da stabiler. Sie hat allerdings den Nachteil, dass sie (unter Normalumständen) nicht im Filesystem, also ohne Webserver funktionirt.

Spirituelle Grüße
Euer Robert
[e-mail]

[suit]

dieses Problem könnte man bestimmt mit PHP bewerkstelligen mit $_SERVER["HTTP_HOST"] oder?

jein. Da fehlt noch das passende Protokoll.

Schema :) und das lässt sich entweder Serverseitig lösen, in dem man aufgrund des Protokolls ein passendes Schema auswählt (das ginge zur not auch z.B. mit mod_rewrite) und anderseits in dem man die verweise Schema-Relativ angibt

also anstatt http://example.com/foo.png einfach //example.com/foo.png

die Angabe "/img/icons/ok.png" ist da stabiler. Sie hat allerdings den Nachteil, dass sie (unter Normalumständen) nicht im Filesystem, also ohne Webserver funktionirt.

Das läst sich durch ein base-Element korrigieren :)

Aber imho gehts bei absoluten Angaben (bzw. relativ zum DocumentRoot) nicht um eine "stabilere" Angabe, sondern um Traffic zu sparen.

Warum soll ich da 100x den Hostnamen an jede Ressourcen dranhängen, wenn der eh immer derselbe ist? Der ist ist völlig egal und ggf. eine Mikrooptimierungsaufgabe - ob man jetzt 75 Zeichen für ein base-Element mit Attribut verschwendet oder 75 mal einen Slash voranstellt ist schon fast egal.

Aber genauso ist es egal wenn man 75x den Hostnamen vorne dranhängt, wenn das Dokument entsprechend ausgeliefert wird (z.B. mittels mod_deflate), sollte nach der Kompression nicht mehr viel Unterschied bestehen.

[Jörg Reinholz]

Moin!

Welcome Back!

Jörg Reinholz

[suit]

Threaddrift!

Wenigstens die Tags entsprechend anpassen :)

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

die Angabe "/img/icons/ok.png" ist da stabiler. Sie hat allerdings den Nachteil, dass sie (unter Normalumständen) nicht im Filesystem, also ohne Webserver funktionirt.

Das läst sich durch ein base-Element korrigieren :)

das base-element ist böse. Es wirkt leider auch auf "myimage.jpg", also auf echte relative Pfadangaben für die Ressourcen.

Man ist dann gezwungen, wieder alle Pfade vom Basepath aus anzugeben.

Spirituelle Grüße
Euer Robert
[e-mail]

[Camping_RIDER]

Aloha ;)

das base-element ist böse. Es wirkt leider auch auf "myimage.jpg", also auf echte relative Pfadangaben für die Ressourcen.

Ja und Nein... Was aber sicher ist, ist, dass es ein möglichst konsequentes Vorgehen bedingt.

Das ist aber eigentlich sowieso Voraussetzung für sinnvolles Programmieren ;)

Aber natürlich, spätestens wenn man anfängt Code mehrerer Beteiligter einzuspeisen wird base problematisch (weil der Kollege vielleicht nicht bedacht hat, dass er keine "echten" relativen Pfadangaben machen darf).

Insofern also doch besser der "/" von Anfang an. Und das Problem mit dem Filesystem wird auch marginal, wenn man sich angewöhnt, Testversionen auf einem lokalen Server statt auf dem Filesystem zu betreiben. Bei größeren Projekten kommt man doch sowieso nicht um die Verwendung serverseitiger Systeme drumrum, muss also sowieso auf einem Server testen (und nicht im Filesystem).

Grüße,

RIDER

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

das base-element ist böse. Es wirkt leider auch auf "myimage.jpg", also auf echte relative Pfadangaben für die Ressourcen.

Ja und Nein... Was aber sicher ist, ist, dass es ein möglichst konsequentes Vorgehen bedingt.

Das ist aber eigentlich sowieso Voraussetzung für sinnvolles Programmieren ;)

Aber natürlich, spätestens wenn man anfängt Code mehrerer Beteiligter einzuspeisen wird base problematisch (weil der Kollege vielleicht nicht bedacht hat, dass er keine "echten" relativen Pfadangaben machen darf).

Insofern also doch besser der "/" von Anfang an. Und das Problem mit dem Filesystem wird auch marginal, wenn man sich angewöhnt, Testversionen auf einem lokalen Server statt auf dem Filesystem zu betreiben. Bei größeren Projekten kommt man doch sowieso nicht um die Verwendung serverseitiger Systeme drumrum, muss also sowieso auf einem Server testen (und nicht im Filesystem).

Genau so ist es.

MMn hat <base ...> den Designfehler, dass es nicht genauso/ähnlich arbeitet, wie die Pfadauflösung in Dateisystemen:

• bei einfacher Namensangabe zuerst im aktuellen Pfad gucken und dann erst die Path-Variable hinzu nehmen, im Filesystem sogar noch gestaffelt mit mehreren Möglichkeiten

• bei relativer Pfadangabe wird nur diese ausgehend vom aktuellen Pfad berücksichtigt

• bei Angabe mit führendem Slash (Backslash) immer ausgehend von der aktuellen Wurzel (Systeme, die mit Laufwerkskennungen arbeiten, haben mehrere)

Das könnte man bei <base ...> ähnlich handhaben. Dann gäb's diese Fragen gar nicht. Man könnte dann angstfrei polymorph adressieren.

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

MMn hat <base ...> den Designfehler, dass es nicht genauso/ähnlich arbeitet, wie die Pfadauflösung in Dateisystemen:

• bei einfacher Namensangabe zuerst im aktuellen Pfad gucken und dann erst die Path-Variable hinzu nehmen, im Filesystem sogar noch gestaffelt mit mehreren Möglichkeiten

Das hört sich für mich an, als könnte man base genausogut weg lassen, denn das System bezieht sich offensichtlich nicht auf eine Basis.

• bei relativer Pfadangabe wird nur diese ausgehend vom aktuellen Pfad berücksichtigt

Hmm, da ist für mich auch keine einzelne, gemeinsame Basis erkennbar.

• bei Angabe mit führendem Slash (Backslash) immer ausgehend von der aktuellen Wurzel (Systeme, die mit Laufwerkskennungen arbeiten, haben mehrere)

Ja, das ist übrigens die Entsprechung von base. Ein Wurzelverzeichnis, von dem aus referenziert wird. Allerdings kribbelts mir bei deinen Ausführungen zu den angedachten betriebssystemabhängigen Bestandteilen (Slash vs. Backslash, Laufwerksnamen). Das wäre, wenn überhaupt, Aufgabe des Browsers, nicht des HTML-Elements als solchem. Das bekomme mal mit den Browserherstellern geregelt, wo doch base eher selten benutzt wird, seitdem Frames mehr oder minder out sind.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

MMn hat <base ...> den Designfehler, dass es nicht genauso/ähnlich arbeitet, wie die Pfadauflösung in Dateisystemen:

• bei einfacher Namensangabe zuerst im aktuellen Pfad gucken und dann erst die Path-Variable hinzu nehmen, im Filesystem sogar noch gestaffelt mit mehreren Möglichkeiten

Das hört sich für mich an, als könnte man base genausogut weg lassen, denn das System bezieht sich offensichtlich nicht auf eine Basis.

Genauso, wie im Filesystem könnte die Pfadauflösung mit <base ...> auch nicht laufen, da der Browser dann beim Nichtfinden im aktuellen Pfad einen 404 bekommen müsste und erst dann im <base ...>-Pfad suchen dürfte. Das will man aber vermutlich nicht implementieren.

Man könnte <base ... note="after404, root"> aber für zukünftige Versionen von HTML aber ein zusätzliches Attribut verpassen, das über bestimmte Werte dann das Verhalten steuert. after404 = erst nachdem die Ressource im aktuellen Pfad nicht gefunden wurde, root = füe alle Pfade, die mit "/" beginnen, usw.

Aber für pfadlose ("ressource.html") Ressourcenangaben oder für relative ("../../pfad/ressource.html") könnte <base ...> einfach ignoriert werden, obwohl es für Angaben mit Pfad ("/pfad/zur/ressource.html") dann benutzt werden würde.

Dann könnte <base ...> ein clientseitiges Äquivalent für das serverseitige umschreiben der Document Root sein.

Du schreibst "man könnte es einfach weglassen". <base ...> wirkt aber dokumentweit. Da kann man es nicht für den einen Pfad weglassen und für den anderen benutzen.Man kann es nur in dem einen Dokument weglassen und im anderen benutzen.

"Einfach weglassen" ist also auch keine Lösung.

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

• bei einfacher Namensangabe zuerst im aktuellen Pfad gucken und dann erst die Path-Variable hinzu nehmen, im Filesystem sogar noch gestaffelt mit mehreren Möglichkeiten

Das hört sich für mich an, als könnte man base genausogut weg lassen, denn das System bezieht sich offensichtlich nicht auf eine Basis.

Du schreibst "man könnte es einfach weglassen". <base ...> wirkt aber dokumentweit.

Ja natürlich. Genau deswegen widerspricht dein Ansinnen erst hier, dann dort und dann noch an anderer Stelle zu suchen, dem Sinn und dem wortwörtlichen Sinn von base.

Da kann man es nicht für den einen Pfad weglassen und für den anderen benutzen.

Das habe ich auch nicht geschrieben.

Man kann es nur in dem einen Dokument weglassen und im anderen benutzen.

"Einfach weglassen" ist also auch keine Lösung.

Doch, denn du gibst base einen Sinn/Zweck, den es nicht hat. Also lasse es weg, denn es führt nicht zu einer Lösung. Über eine hypothetische Browserimplementation deiner Idee brauchen wir ja wohl nicht ernsthaft nachzudenken, oder? Zumal das bisher auf irgendwelchen Websites eingesetze base dann nicht mehr funktionieren würde, wie es soll.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

"Einfach weglassen" ist also auch keine Lösung.

Doch, denn du gibst base einen Sinn/Zweck, den es nicht hat. Also lasse es weg, denn es führt nicht zu einer Lösung. Über eine hypothetische Browserimplementation deiner Idee brauchen wir ja wohl nicht ernsthaft nachzudenken, oder? Zumal das bisher auf irgendwelchen Websites eingesetze base dann nicht mehr funktionieren würde, wie es soll.

Dass Du darüber nicht ernsthaft nachdenken willst, gibst Du hier leider schon zu verstehen. Ich denke sehr wohl darüber nach, ob das nicht sinnvoll wäre.

Du scheinst dabei die Möglichkeit zu missachten, dass "ich" bei der Erstellung von Mudulen oder Teilseiten <base ...> nicht weglassen kann, weil das derjenige, der die Teile zusammenstöpselt, warum auch immer, für das Hauptdokument benutzt - oder umgekehrt: ich erhalte ein Teilmodul, das leider (als standalone) <base ...> enthält und nur so funktioniert und nun als Ausschnitt nicht mehr funktioniert.

Ich mag darüber auch nicht weiter diskutieren. Der OP mag seine eigenen Schlüsse aus der bisherigen Diskussion ziehen. Nur um die Beantwortung einer abschließenden Frage bitte ich noch:

Würdest Du die Verwendung von <base ...> (noch) empfehlen?

Spirituelle Grüße
Euer Robert
[e-mail]

[Der Martin]

Moin,

Würdest Du die Verwendung von <base ...> (noch) empfehlen?

ich bin zwar nicht direkt angesprochen, aber: Nein, würde ich nicht.

Ich habe das base-Element noch nie für eine gute Idee gehalten, weil seine tatsächliche Wirkungsweise manchmal schwer zu durchschauen ist und daher zu unerwarteten Problemen führt.

Ich empfehle eher, der Klarheit wegen jede abhängige Ressource explizit zu adressieren. Ob man dabei eher relative oder eher absolute Pfade bevorzugt, ist teils Geschmackssache, hängt aber teils auch vom Anwendungsfall ab, da beide Varianten Vor- und Nachteile haben.

So long,
 Martin

[Auge]

Hallo

"Einfach weglassen" ist also auch keine Lösung.

Doch, denn du gibst base einen Sinn/Zweck, den es nicht hat. Also lasse es weg, denn es führt nicht zu einer Lösung. Über eine hypothetische Browserimplementation deiner Idee brauchen wir ja wohl nicht ernsthaft nachzudenken, oder? Zumal das bisher auf irgendwelchen Websites eingesetze base dann nicht mehr funktionieren würde, wie es soll.

Dass Du darüber nicht ernsthaft nachdenken willst, gibst Du hier leider schon zu verstehen. Ich denke sehr wohl darüber nach, ob das nicht sinnvoll wäre.

HTML will abwärtskompatibel sein. Schon von daher verbietet sich eine Umwidmung von base oder irgendeines anderen Elements. Schon sich darüber Gedanken zu machen, ist verschwendete Energie.

Du kannst natürlich über ein ähnlich arbeitendes Element nachdenken, wobei das über die Durchsetzung einer Browserimplementation gesagte gilt (letzter Absatz, letzter Satz). Oder du (oder wer auch immer) arbeitet mit einem Testserver, wie es so viele tun und sparst dir die Energie des Nachdenkens über ein neues HTML-Element.

Du scheinst dabei die Möglichkeit zu missachten, dass "ich" bei der Erstellung von Mudulen oder Teilseiten <base ...> nicht weglassen kann, weil das derjenige, der die Teile zusammenstöpselt, warum auch immer, für das Hauptdokument benutzt - oder umgekehrt: ich erhalte ein Teilmodul, das leider (als standalone) <base ...> enthält und nur so funktioniert und nun als Ausschnitt nicht mehr funktioniert.

Ich denke mal, dieser Fall ist heutzutage hypothetisch. Mir ist base seit Jahren nicht in freier Wildbahn begegnet. Deshalb …

Würdest Du die Verwendung von <base ...> (noch) empfehlen?

… nein. Niemand (außer dir?) braucht das. Benutze /absolute/Pfad/Angaben und einen Testserver mit intern identischer Verzeichnisstruktur. Kein (diesbezügliches) Problem, kein Bedarf für base.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

"Einfach weglassen" ist also auch keine Lösung.

Doch, denn du gibst base einen Sinn/Zweck, den es nicht hat. Also lasse es weg, denn es führt nicht zu einer Lösung. Über eine hypothetische Browserimplementation deiner Idee brauchen wir ja wohl nicht ernsthaft nachzudenken, oder? Zumal das bisher auf irgendwelchen Websites eingesetze base dann nicht mehr funktionieren würde, wie es soll.

Dass Du darüber nicht ernsthaft nachdenken willst, gibst Du hier leider schon zu verstehen. Ich denke sehr wohl darüber nach, ob das nicht sinnvoll wäre.

HTML will abwärtskompatibel sein. Schon von daher verbietet sich eine Umwidmung von base oder irgendeines anderen Elements. Schon sich darüber Gedanken zu machen, ist verschwendete Energie.

Ich wollte ja nicht weiterdiskutieren...
Aber überdenke bitte nochmal Deine obige Aussage und bitte korrigiere sie ggf. :-)

Welche Probleme hat denn HTML mit der Abwärtskompatibilität durch die Einführung eines neuen Attributes bei <base ...> oder irgendeinem anderen Element?

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

Zumal das bisher auf irgendwelchen Websites eingesetze base dann nicht mehr funktionieren würde, wie es soll.

Dass Du darüber nicht ernsthaft nachdenken willst, gibst Du hier leider schon zu verstehen. Ich denke sehr wohl darüber nach, ob das nicht sinnvoll wäre.

HTML will abwärtskompatibel sein. Schon von daher verbietet sich eine Umwidmung von base oder irgendeines anderen Elements. Schon sich darüber Gedanken zu machen, ist verschwendete Energie.

Ich wollte ja nicht weiterdiskutieren...
Aber überdenke bitte nochmal Deine obige Aussage und bitte korrigiere sie ggf. :-)

Welche Probleme hat denn HTML mit der Abwärtskompatibilität durch die Einführung eines neuen Attributes bei <base ...> oder irgendeinem anderen Element?

Ok, das mit einem Attribut zu lösen, nimmt die Befürchtung der Inkompatibilität zum bisherigen Verhalten weg. Bleibt die fehlende Browserimplementierung (viel Spaß dabei) und die fehlende Notwendigkeit. Es ist kein Grund für eine Meinungsänderung hinzugekommen.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Zumal das bisher auf irgendwelchen Websites eingesetze base dann nicht mehr funktionieren würde, wie es soll.

Dass Du darüber nicht ernsthaft nachdenken willst, gibst Du hier leider schon zu verstehen. Ich denke sehr wohl darüber nach, ob das nicht sinnvoll wäre.

HTML will abwärtskompatibel sein. Schon von daher verbietet sich eine Umwidmung von base oder irgendeines anderen Elements. Schon sich darüber Gedanken zu machen, ist verschwendete Energie.

Ich wollte ja nicht weiterdiskutieren...
Aber überdenke bitte nochmal Deine obige Aussage und bitte korrigiere sie ggf. :-)

Welche Probleme hat denn HTML mit der Abwärtskompatibilität durch die Einführung eines neuen Attributes bei <base ...> oder irgendeinem anderen Element?

Ok, das mit einem Attribut zu lösen, nimmt die Befürchtung der Inkompatibilität zum bisherigen Verhalten weg. Bleibt die fehlende Browserimplementierung (viel Spaß dabei) und die fehlende Notwendigkeit. Es ist kein Grund für eine Meinungsänderung hinzugekommen.

*ROTFL*

Sorry, ist nicht böse gemeint, nur suggeriert es mir, dass DU <base ...> in der bisherigen Form genauso überflüssig hältst (wenn nicht sogar kontraproduktiv), wie ich. Ich habe auch jahr(zehnte)lang darauf verzichten können, bis ich eben dazu gezwungen wurde, mich damit auseinanderzusetzen.

Es ist hier manchmal extrem schwer, von Anderen eine klare Aussage zu bekommen. Ich bemühe mich immer darum, was dann eben auch nervig erscheinen kann. Da muss ich durchaus auch mal meine Meinung ändern während einer Diskussion. Und das ist nix schlimmes - das ist eben Diskussion :-)

ICH habe allerdings versucht, eventuell noch etwas aus dem "Denkansatz" <base ...> zu machen, indem ich weiter darüber nachgedacht habe. Wegwerfen kann jeder Idiot.

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Du scheinst dabei die Möglichkeit zu missachten, dass "ich" bei der Erstellung von Mudulen oder Teilseiten <base ...> nicht weglassen kann, weil das derjenige, der die Teile zusammenstöpselt, warum auch immer, für das Hauptdokument benutzt - oder umgekehrt: ich erhalte ein Teilmodul, das leider (als standalone) <base ...> enthält und nur so funktioniert und nun als Ausschnitt nicht mehr funktioniert.

Nachvollziehbar, aber wieso bist du denn so sehr daran interessiert, dass die Seite auch ohne HTTP-Server läuft? Gehen wir mal davon aus, dass deine Seite ohne serverseitige Logik auskommt, dann wäre dein HTTP-Server im Prinzip nur ein statischer Fileserver, der URLs auf Dateisystem-Pfade mapt. Aber selbst dann könntest du eine Vielzahl von clientseitigen APIs gar nicht nutzen, zum Beispiel den localStorage, Cookies oder indexedDB, alles was einen Origin vorraussetzt, und das ist typischerweise eben der Hostname deines Webservers. Das <base>-Element ist dagegen wohl nur ein ungergerodnetes Problem. Die gute Nachricht für dich ist, dass es eine einfache und eleganter Lösung dafür gibt, die Camping_RIDER dir bereits empfohlen hat: Du installierst dir einen lokalen Webserver als Entwicklungsumgebung. Stattdessen denkst du schon darüber nach, wie du den Standard ändern könntest, das hört sich für mich vollkommen realitätsfern an.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Du scheinst dabei die Möglichkeit zu missachten, dass "ich" bei der Erstellung von Mudulen oder Teilseiten <base ...> nicht weglassen kann, weil das derjenige, der die Teile zusammenstöpselt, warum auch immer, für das Hauptdokument benutzt - oder umgekehrt: ich erhalte ein Teilmodul, das leider (als standalone) <base ...> enthält und nur so funktioniert und nun als Ausschnitt nicht mehr funktioniert.

Nachvollziehbar, aber wieso bist du denn so sehr daran interessiert, dass die Seite auch ohne HTTP-Server läuft?

• Dokumentationszwecke
• Wissenserhaltung
• einfache Weitergabe von Contents
• ...

Gehen wir mal davon aus, [...]

Wir können uns immer Rahmenbedingungen ausdenken, wo das Eine nicht ohne das Andere funktioniert. So weit wollte ich aber bei der Diskussion nicht gehen.

Es sollte immer möglich sein, ein offline verfügbares (passives, also ohne Datenbankkopplung) HTML-Dokument, mit einem Browser hauptsächlich zu lesen. Der Browser sollte beim Verweis auf (derzeit) nicht verfügbare externe Referenzen eine deutliche, aber durchaus eingebettete Information geben.

Ich denke, dass es hier noch Nachbesserungsbedarf gibt.

Spirituelle Grüße
Euer Robert
[e-mail]

[Camping_RIDER]

Aloha ;)

Nachvollziehbar, aber wieso bist du denn so sehr daran interessiert, dass die Seite auch ohne HTTP-Server läuft?

• Dokumentationszwecke
• Wissenserhaltung
• einfache Weitergabe von Contents
• ...

Da widerspreche ich. Dokumentationszwecke und Wissenserhaltung sind für mich in dem Sinne nicht nachvollziehbar. Wo liegt der Vorteil bzgl. Dokumentation und Wissenserhaltung, wenn es ohne HTTP-Server läuft? Ob die Seite zu Dokumentationszwecken und Wissenserhaltung nun im FS oder auf einem lokalen Server liegt, ist vollkommen schnuppe.

Die einfache Weitergabe von Contents ist imho auch nicht wirklich nachvollziehbar. Genausowenig wie ich das Internet ausdrucke, verteile ich Websites per USB-Stick. Wer von mir einen Quelltext zum Weiterbearbeiten bekommt, von dem erwarte ich auch, dass er in der Lage ist, einen Testserver zu betreiben.

Gehen wir mal davon aus, [...] Wir können uns immer Rahmenbedingungen ausdenken, wo das Eine nicht ohne das Andere funktioniert. So weit wollte ich aber bei der Diskussion nicht gehen.

Das sind keine abstrusen Rahmenbedingungen, sondern das Standardumfeld, in dem Webseiten vorkommen. Weder im Internet noch in einem Intranet sollten Webseiten ohne Server ausgeliefert werden. Webseiten werden für den Einsatz auf einem Server geschrieben, und wie 1unitedpower schon herausgearbeitet hat, gibt es dementsprechend massenhaft Technologien, die ohne Server nicht einsetzbar sind.

Es sollte immer möglich sein, ein offline verfügbares (passives, also ohne Datenbankkopplung) HTML-Dokument, mit einem Browser hauptsächlich zu lesen. Der Browser sollte beim Verweis auf (derzeit) nicht verfügbare externe Referenzen eine deutliche, aber durchaus eingebettete Information geben.

Verstehe ich nicht. Dafür hat der Browser die Möglichkeit eine Seite 'as is' zu speichern. Das hat jeder Browser und jeder User kann das - für den unwahrscheinlichen Fall, dass er es braucht - auch nutzen. Die Referenzen werden dann übrigens automatisch korrigiert.

Warum derzeit nicht verfügbare Ressourcen grundsätzlich nochmal statisch eingebettet werden sollten verstehe ich auch nicht, aber da hab ich dich wahrscheinlich falsch verstanden.

Ich denke, dass es hier noch Nachbesserungsbedarf gibt.

Den sehe ich nicht.

Grüße,

RIDER

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Nachvollziehbar, aber wieso bist du denn so sehr daran interessiert, dass die Seite auch ohne HTTP-Server läuft?

• Dokumentationszwecke
• Wissenserhaltung
• einfache Weitergabe von Contents
• ...

Da widerspreche ich. Dokumentationszwecke und Wissenserhaltung sind für mich in dem Sinne nicht nachvollziehbar. Wo liegt der Vorteil bzgl. Dokumentation und Wissenserhaltung, wenn es ohne HTTP-Server läuft? Ob die Seite zu Dokumentationszwecken und Wissenserhaltung nun im FS oder auf einem lokalen Server liegt, ist vollkommen schnuppe.

Das erzähl mal nochmal in 150 Jahren, wenn man zufällig gerade ein HTML-File wiederherstellen konnte (zum Glück in ASCII, ...) und auch noch einen Netscape Browser auf einem Win311 wiederherstellen konnte.

Warum sollte man eine Funktionalität, die man haben könnte, vernichten?

Wir entfernen uns immer weiter von den Tontalfeln der Sumerer und denen mit Keilschrift. Wie lange werden Dokumente lesbar bleiben?

Da sind die Microfiches im Bergwerk wohl doch noch die z. Zt, beste Lösung ;-P

Spirituelle Grüße
Euer Robert
[e-mail]

[Camping_RIDER]

Aloha ;)

Das erzähl mal nochmal in 150 Jahren, wenn man zufällig gerade ein HTML-File wiederherstellen konnte (zum Glück in ASCII, ...) und auch noch einen Netscape Browser auf einem Win311 wiederherstellen konnte.

Kein Problem. Alle Inhalte liegen ja (im Quelltext) in klarem ASCII vor - sind halt so n paar störende < > drumrum. Nen Ascii-Interpreter zu haben ist übrigens viel wahrscheinlicher als nen entsprechend alten Browser ;)

Nein, wirklich. Du konstruierst hier Anwendungsfälle, die es real oder nach vernünftiger Begutachtung nicht gibt. In 150 Jahren ist die Datei eventuell nicht mal mehr lesbar, weil ander Kodierungen verwendet werden. Frag die mit der Keilschrift. Die kann man nicht deshalb nicht mehr lesen, weil man inhaltlich nicht mitkommt (aka Darstellung im FS obwohl Serverseitige Technologien zur Erstellung verwendet wurden), sondern weil man ihre Schrift nicht lesen kann (als Normalsterblicher).

Ich bin vom hier und jetzt ausgegangen und da haben die von dir genannten Argumente keinen für mich deutlichen Anwendungsfall.

Grüße,

RIDER

[Auge]

Hallo

• einfache Weitergabe von Contents

Es sollte immer möglich sein, ein offline verfügbares (passives, also ohne Datenbankkopplung) HTML-Dokument, mit einem Browser hauptsächlich zu lesen.

Dann nimm halt relative Pfadangaben, womit folgendes …

Der Browser sollte beim Verweis auf (derzeit) nicht verfügbare externe Referenzen eine deutliche, aber durchaus eingebettete Information geben.

… hinfällig wird

Ich denke, dass es hier noch Nachbesserungsbedarf gibt.

Seufz, es scheint dir Freude zu bereiten, ein totes Pferd zu reiten. Mir fällt da nur folgendes ein: Warum einfach, wenn es auch kompliziert geht‽

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Seufz, es scheint dir Freude zu bereiten, ein totes Pferd zu reiten. Mir fällt da nur folgendes ein: Warum einfach, wenn es auch kompliziert geht‽

Verstehe ich nicht. Was hat ein totes Pferd mit Mängeln beim <base ...>-Element zu tun?

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

Seufz, es scheint dir Freude zu bereiten, ein totes Pferd zu reiten. Mir fällt da nur folgendes ein: Warum einfach, wenn es auch kompliziert geht‽

Verstehe ich nicht. Was hat ein totes Pferd mit Mängeln beim <base ...>-Element zu tun?

Zum allerletzten Mal: base ist mausetot.

Tschö, Auge

[Der Martin]

Hi,

Was hat ein totes Pferd mit Mängeln beim <base ...>-Element zu tun?

Zum allerletzten Mal: base ist mausetot.

und das war es IMO schon per se, als es eingeführt wurde.

So long,
 Martin

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Was hat ein totes Pferd mit Mängeln beim <base ...>-Element zu tun?

Zum allerletzten Mal: base ist mausetot.

und das war es IMO schon per se, als es eingeführt wurde.

Es fehlen dem <base ...>-Element nur ein paar sinnvolle Attribute.

Es ist auch scheinbar noch nicht "deprecated" oder wie man das bei der Definition des nächsten HTML-Standards dann gerade mal nennt.

Und ich verstehe auch nicht, warum ich hier in diesem Thread nun quasi für das <base ...>-Element verantwortlich gemacht werde. Ich mochte das nie. Ich habe nur versucht, die Einsatzmöglichkeiten und -widrichkeiten abzuwägen und zu überlegen, ob man ihm den vielleicht ursprünglich angedachten Sinn noch nachträglich beibringen könnte, ohne Rückwärtsinkompatibel zu werden.

Andere Diskussionen der vergangenen Wochen haben das Thema schon einmal gestreift oder getroffen. Das war mir noch in Erinnerung nebst der Aufgabenstellung "Eine Webdarstellung für Kunden (ohne Internetzugeng) per CD verfügbar machen".

Spirituelle Grüße
Euer Robert
[e-mail]

[Der Martin]

Hallo,

Zum allerletzten Mal: base ist mausetot.

und das war es IMO schon per se, als es eingeführt wurde.

Es fehlen dem <base ...>-Element nur ein paar sinnvolle Attribute.

nein, es ist meines Erachtens ein Element, das noch nie einen wirklichen Sinn hatte. Denn ich kann meine Ressourcen in jedem Fall gezielt an der richtigen Stelle adressieren - egal ob ich vom Normalfall ausgehe, dass wir uns in einer HTTP-Umgebung befinden, oder im lokalen Filesystem.

Zugegeben, absolut adressieren kann ich nur, wenn ich den Ursprung des Verzeichnisbaums und die Position des aktuellen Dokuments darin kenne. Daran ändert aber das base-Element auch nichts.

Also wo bleibt der eigentliche Sinn? Ich kann ihn nicht entdecken.

Und ich verstehe auch nicht, warum ich hier in diesem Thread nun quasi für das <base ...>-Element verantwortlich gemacht werde.

Weil du es ins Spiel gebracht hast. ;-)
Und weil du so argumentierst, als wolltest du für dieses Element Partei ergreifen.

Andere Diskussionen der vergangenen Wochen haben das Thema schon einmal gestreift oder getroffen. Das war mir noch in Erinnerung nebst der Aufgabenstellung "Eine Webdarstellung für Kunden (ohne Internetzugeng) per CD verfügbar machen".

Überhaupt kein Problem, wenn innerhalb des Projekts alle Ressourcen konsequent relativ adressiert sind. Das base-Element würde auch in diesem Fall nicht helfen, denn das müsste sich ja dann auch je nach Nutzer-Umgebung ändern - also je nachdem, welchen Laufwerksbuchstaben das CD-Laufwerk hat bzw. in welchem Verzeichnis es gemountet ist.

Wenn überhaupt, dann müsste es eine dem base-Element entsprechende Einstellung im Browser geben, die das momentan aktive Dokument (in einem limitierten Scope) zum Ausgangspunkt aller unqualifizierten Referenzen macht. Aber nicht im Dokument selbst. Da ist es sinnlos.

So long,
 Martin

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Verstehe ich nicht. Was hat ein totes Pferd mit Mängeln beim <base ...>-Element zu tun?

Zum allerletzten Mal: base ist mausetot.

Das ist doch mal eine Aussage!
Und wo kann ich das nachlesen?

Da steht noc nix von "maustot" http://www.w3.org/TR/html-markup/base.html

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Nachvollziehbar, aber wieso bist du denn so sehr daran interessiert, dass die Seite auch ohne HTTP-Server läuft?

• Dokumentationszwecke
• Wissenserhaltung

Das müsstest du mir genauer erklären.

• einfache Weitergabe von Contents

Dateien zu verschieben und manuell zwischen Kollegen/Freunden auszutauschen und zu synchronisieren ist so ziemlich das genaue Gegenteil von Einfachheit, wenn du mich fragst. Ein Link zu verschicken ist dagegen wirklich einfach.

Gehen wir mal davon aus, [...] Wir können uns immer Rahmenbedingungen ausdenken, wo das Eine nicht ohne das Andere funktioniert. So weit wollte ich aber bei der Diskussion nicht gehen.

Du hast mich offenbar falsch verstanden. Ich habe hier einen möglichst gutmütugen, idealistischen Fall konstruiert, den du in der Relaität so beinahe nie herbeiführen können wirst, und selbst dabei treten unerüberwindbare technische Hürden auf. Von Fällen, die der Realität mehr entsprechen, wollte ich gar nicht anfangen.

Es sollte immer möglich sein, ein offline verfügbares (passives, also ohne Datenbankkopplung) HTML-Dokument, mit einem Browser hauptsächlich zu lesen.

Mit einem reinen HTML-Dokument wird dir das auch gelingen, aber sobald du mit anderen Technologien jonglierst, wie JavaScript oder CSS stößt du an technische Grenzen. Servereitige Technologien und Netzwerk-Operationen sind ebenfalls kategorisch ausgeschlossen. Du endest also mit einer sehr restriktiven Teilmenge, von dem was im Web eigentlich möglich wäre.

Der Browser sollte beim Verweis auf (derzeit) nicht verfügbare externe Referenzen eine deutliche, aber durchaus eingebettete Information geben.

Ich denke, dass es hier noch Nachbesserungsbedarf gibt.

Nein, denn die primäre Zielplatform von HTML und anderen Web-Technologien ist eben das Web, nicht der lokale Computer. Den Standard davon abweichend in eine andere Richtung zu verändern, halte ich für destruktiv und glücklicherweise auch für utopisch. Wenn du eine in sich geschlossene Lösung möchtest, die nicht im Web läuft, dann würde ich dir empfehlen, zu einem der diversen Deployment-Dienste zu greifen, die dir deine Webseite samt Webserver in einem Paket schüren können. Dann bist du technisch so nicht so eingeschränkt und kannst trotzdem die Vorteile genießen, die du bei lokal lauffähigen Programmen so schätzt. Oder du entwickelst gleich native Software.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

• bei Angabe mit führendem Slash (Backslash) immer ausgehend von der aktuellen Wurzel (Systeme, die mit Laufwerkskennungen arbeiten, haben mehrere)

Ja, das ist übrigens die Entsprechung von base. Ein Wurzelverzeichnis, von dem aus referenziert wird. Allerdings kribbelts mir bei deinen Ausführungen zu den angedachten betriebssystemabhängigen Bestandteilen (Slash vs. Backslash, Laufwerksnamen). Das wäre, wenn überhaupt, Aufgabe des Browsers, nicht des HTML-Elements als solchem. Das bekomme mal mit den Browserherstellern geregelt, wo doch base eher selten benutzt wird, seitdem Frames mehr oder minder out sind.

Welches HTML-Element ist nicht "Aufgabe des Browsers"?

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

Ein Wurzelverzeichnis, von dem aus referenziert wird. Allerdings kribbelts mir bei deinen Ausführungen zu den angedachten betriebssystemabhängigen Bestandteilen (Slash vs. Backslash, Laufwerksnamen). Das wäre, wenn überhaupt, Aufgabe des Browsers, nicht des HTML-Elements als solchem. Das bekomme mal mit den Browserherstellern geregelt, wo doch base eher selten benutzt wird, seitdem Frames mehr oder minder out sind.

Welches HTML-Element ist nicht "Aufgabe des Browsers"?

Jaja. Hast du mal auf die Uhrzeit meines Postings geschaut?

Ich bezog mich heute nacht primär darauf, dass einige Elemente im- und explizite Pfadangaben beinhalten, die schlimmstenfalls um Domain und Pfad ergänzt werden. Base ist ja auch so ein Beispiel. In diesen Fällen hat der Browser ja „nicht mehr viel zu tun“.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Ein Wurzelverzeichnis, von dem aus referenziert wird. Allerdings kribbelts mir bei deinen Ausführungen zu den angedachten betriebssystemabhängigen Bestandteilen (Slash vs. Backslash, Laufwerksnamen). Das wäre, wenn überhaupt, Aufgabe des Browsers, nicht des HTML-Elements als solchem. Das bekomme mal mit den Browserherstellern geregelt, wo doch base eher selten benutzt wird, seitdem Frames mehr oder minder out sind.

Welches HTML-Element ist nicht "Aufgabe des Browsers"?

Jaja. Hast du mal auf die Uhrzeit meines Postings geschaut?

Sorry, irgendwas mit dem Forum ist mir noch suspekt.
Das kam erst eben als neu formatiert hoch. Da habe ich das Datum nicht beachtet.

Trotzdem sind alle HTML-Elemente Aufgabe des Browsers. Bleibt also - unabhängig von der Uhrzeit - eine "urige Aussage" von Dir, die der Richtigstellung bedarf :-)

<base ...> in der aktuellen Form gehört also in die "Urzeit". Das würde ich sogar unterschreiben ;-)

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

• bei Angabe mit führendem Slash (Backslash) immer ausgehend von der aktuellen Wurzel (Systeme, die mit Laufwerkskennungen arbeiten, haben mehrere)

Ja, das ist übrigens die Entsprechung von base. Ein Wurzelverzeichnis, von dem aus referenziert wird. Allerdings kribbelts mir bei deinen Ausführungen zu den angedachten betriebssystemabhängigen Bestandteilen (Slash vs. Backslash, Laufwerksnamen). Das wäre, wenn überhaupt, Aufgabe des Browsers, nicht des HTML-Elements als solchem. Das bekomme mal mit den Browserherstellern geregelt, wo doch base eher selten benutzt wird, seitdem Frames mehr oder minder out sind.

Welches HTML-Element ist nicht "Aufgabe des Browsers"?

Man trifft üblicherweise eine Unterscheidung zwischen Author-Conformance und Implementator-Conformance. Es ist zum Beispiel die Aufgabe eines Autors/Webentwicklers dafür zu sorgen, valides HTML schreiben, auf der anderen Seite ist es Aufgabe des Browsersherstellers dafür zu sorgen, auch invalides Markup auf eine fehlertolerante Art zu behandeln. In diesem Sinne verstehe ich hier auch Auge, es fiele in den Bereich des Browserherstellers dafür zu sorgen, die Pfadauflösung auf Betriebssystemebene anzupassen. Ich verstehe ich allerdings deine Argumentation überhaupt nicht, wieso das nötig sein sollte.

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Man trifft üblicherweise eine Unterscheidung zwischen Author-Conformance und Implementator-Conformance.

Könntest Du bitte versuchen, das für EDV-Rentner nochmal auf Deutsch erklätren, wenn Du kannst?

Es ist zum Beispiel die Aufgabe eines Autors/Webentwicklers dafür zu sorgen, valides HTML schreiben, auf der anderen Seite ist es Aufgabe des Browsersherstellers dafür zu sorgen, auch invalides Markup auf eine fehlertolerante Art zu behandeln.

Von invalidem HTML hat hier niemand gesprochen, sondern von der Auswirkug des HTML-Codes

In diesem Sinne verstehe ich hier auch Auge, es fiele in den Bereich des Browserherstellers dafür zu sorgen, die Pfadauflösung auf Betriebssystemebene anzupassen.

Jein, das ist wirr. Der Browser hat mit der Betriebssystemebene nichts zu tun. Meisntest Du eventuell "die Pfadauflösung des Browsers auf Ressourcen ähnlich zu gestalten, wie die Pfadauflösung auf Filesystemebene stattfindet"?

Ich verstehe ich allerdings deine Argumentation überhaupt nicht, wieso das nötig sein sollte.

Wie soll ich das jetzt verstehen?
Warum sollte es unnötig sein, über fragwürdiges Verhalten nachzudenken und zu versuchen, es ggf. sogar zu berichtigen?

Wenn Du mir nicht folgen kannst, brauchst Du meine Ideen nicht gleich abzuwiegeln, versuch doch einfach mal, mich zu verstehen, auch wenn Du viel schlauer bist als ich. Manchmal haben auch die Doofen brauchbare Ideen. :-P

Bedenke:

Und aus dem Chaos sprach eine Stimme zu mir: "Lächle und sei froh, es könnte schlimmer kommen!", und ich lächelte und war froh, und es kam schlimmer...!

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

In diesem Sinne verstehe ich hier auch Auge, es fiele in den Bereich des Browserherstellers dafür zu sorgen, die Pfadauflösung auf Betriebssystemebene anzupassen.

Jein, das ist wirr. Der Browser hat mit der Betriebssystemebene nichts zu tun. Meisntest Du eventuell "die Pfadauflösung des Browsers auf Ressourcen ähnlich zu gestalten, wie die Pfadauflösung auf Filesystemebene stattfindet"?

Du wolltest, dass ein Browser mit base mit einem neu einzuführenden Attribut prüft, wo die verlinkten Ressourcen sein könnten. Dazu muss er beim Server nachfragen können, aber, und das war dein Begehr in Bezug auf Flexibilität, auch im Dateisystem suchen können. Das träfe z.B. zu, wenn das Dokument lokal aufgerufen würde. Und genau dazu braucht der Browser XYZ die Fähigkeit, die verschiedenen Syntaxen der Laufwerke und Pfade unter den unterschiedlichen Betriebsystemen für diese neue Funktion zu kennen. Huch, schon wieder das Thema Browserimplementation.

Ich verstehe ich allerdings deine Argumentation überhaupt nicht, wieso das nötig sein sollte.

Wie soll ich das jetzt verstehen?
Warum sollte es unnötig sein, über fragwürdiges Verhalten nachzudenken und zu versuchen, es ggf. sogar zu berichtigen?

Weil, um es nochmal zu sagen, base praktisch tot ist und es für das ursprüngliche Ansinnen, unabhängig davon, ob der Aufruf lokal oder über den (nicht lokalen) Webserver erfolgt, problemlos testen zu können, andere Techniken zur Verfügung stehen, die base obsolet machen.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Du wolltest, dass ein Browser mit base mit einem neu einzuführenden Attribut prüft, wo die verlinkten Ressourcen sein könnten. Dazu muss er beim Server nachfragen können,

Wenn das Scheme ihm das so vorschreibt: JA

aber, und das war dein Begehr in Bezug auf Flexibilität, auch im Dateisystem suchen können.

Wenn das Scheme ihm das so vorschreibt: JA

Das träfe z.B. zu, wenn das Dokument lokal aufgerufen würde. Und genau dazu braucht der Browser XYZ die Fähigkeit, die verschiedenen Syntaxen der Laufwerke und Pfade unter den unterschiedlichen Betriebsystemen für diese neue Funktion zu kennen.

kennt er die nicht schon?
Je nachdem, wie ihm das Scheme das so vorschreibt?

Huch, schon wieder das Thema Browserimplementation.

Ich verstehe ich allerdings deine Argumentation überhaupt nicht, wieso das nötig sein sollte.

??

Bemühst Du dich denn wirklich?

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Man trifft üblicherweise eine Unterscheidung zwischen Author-Conformance und Implementator-Conformance.

Könntest Du bitte versuchen, das für EDV-Rentner nochmal auf Deutsch erklätren, wenn Du kannst?

Soll heißen, man unterscheidet schon bei der Standardisierung von HTML, was in den Aufgabenbereich von Webentwicklern fällt und was in den Bereich der Browserhersteller fällt. Indem du sagst, man könnte dem <base>-Element ein weiteres Attribut verleihen, machst du es zur Aufgabe des Webentwicklers, dieses Attribut korrekt zu pflegen. Natürlich ist es dann auch die Aufgabe des Browsers, die Anweisungen des Webentwicklers richtig zu interpretieren.

Es ist zum Beispiel die Aufgabe eines Autors/Webentwicklers dafür zu sorgen, valides HTML schreiben, auf der anderen Seite ist es Aufgabe des Browsersherstellers dafür zu sorgen, auch invalides Markup auf eine fehlertolerante Art zu behandeln.

Von invalidem HTML hat hier niemand gesprochen, sondern von der Auswirkug des HTML-Codes

Ich schrieb hier "zum Beispiel" um den Unterschied zwischen Author- und Implementator-Conformance nochmal exemplarisch zu verdeutlichen.

In diesem Sinne verstehe ich hier auch Auge, es fiele in den Bereich des Browserherstellers dafür zu sorgen, die Pfadauflösung auf Betriebssystemebene anzupassen.

Jein, das ist wirr.

Neuer Versuch: Wenn Auge schreibt, das sei Aufgabe des Browsers, dann verstehe ich ihn so, dass es nicht die Aufgabe des Webentwicklers sich darum zu kümmern. Dein Vorschlag ein neues Attribut für das <base>-Element zu definieren, macht aber genau das.

Ich verstehe ich allerdings deine Argumentation überhaupt nicht, wieso das nötig sein sollte.

Wie soll ich das jetzt verstehen?
Warum sollte es unnötig sein, über fragwürdiges Verhalten nachzudenken und zu versuchen, es ggf. sogar zu berichtigen?

Ich verstehe nicht, was du fragwürdig findest. Du konstruierst Lösungen für Probleme, die es nicht gibt.

Wenn Du mir nicht folgen kannst, brauchst Du meine Ideen nicht gleich abzuwiegeln, versuch doch einfach mal, mich zu verstehen, auch wenn Du viel schlauer bist als ich. Manchmal haben auch die Doofen brauchbare Ideen. :-P

Das versuche ich ja, aber ich kann das Problem, von dem du ausgehst, schon nicht erkennen. Beantworte doch mal die folgenden Fragen: Du hast zwei Offline-Dokumente, die gegenseitig aufeinander verlinken. Welches Problem gibt es nun, dass den Einsatz von <base> als Lösung erfordert? Nachdem dieses Problem gelöst ist, welches neue Problem tritt in Folge von <base> auf?

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

[...] SO langsam kann ich eure Argumentation auch verstehen, auch wenn ich sie teilweise immer noch für unlogisch halte.

Neuer Versuch: Wenn Auge schreibt, das sei Aufgabe des Browsers, dann verstehe ich ihn so, dass es nicht die Aufgabe des Webentwicklers sich darum zu kümmern. Dein Vorschlag ein neues Attribut für das <base>-Element zu definieren, macht aber genau das.

Aber doch nur für neu erstellte Webseiten, die genau diese Funktionalität, die dann auch sinnvoll sein könnte, nutzen wollen. Es würde endlich ein belastbares Verhalten geben: Die (grundlegende) Nutzbarmachnung von Websites in beliebiger(1) Umgebung.

Für alle alten Websites bliebe doch der Unsinn so unsinnig wie immer. Entweder sie funktionieren auch in anderer Umgebung zufällig oder auch nicht.

(1) "beliebig" ist Stoff genug für ein eigenes Forum. Bitte lest es ert einmal tendenziell sinngemäß ;-)

Spirituelle Grüße
Euer Robert
[e-mail]

[1unitedpower]

Neuer Versuch: Wenn Auge schreibt, das sei Aufgabe des Browsers, dann verstehe ich ihn so, dass es nicht die Aufgabe des Webentwicklers sich darum zu kümmern. Dein Vorschlag ein neues Attribut für das <base>-Element zu definieren, macht aber genau das.

Aber doch nur für neu erstellte Webseiten, die genau diese Funktionalität, die dann auch sinnvoll sein könnte, nutzen wollen.

Das kann ich nicht beurteilen, bisher macht das auf mich keinen sinnvollen Eindruck. Du hast mich gebeten, mir Mühe zu geben dich zu verstehen, jetzt bitte ich dich darum mir eben dabei zu helfen. In meiner letzten Antwort, habe ich dir ein paar Fragen gestellt, dir mir beim Verständnis helfen könnten, wenn du mir die beantworten könntest, wären wir einen Schritt weiter.