laenge von webadressen
Sven Guckes
> aber diese URLs sind bloed. viel zu lang. gibt
> es denn fuer die artikel keine kurzen adressen?
* Bernd Ullrich <ullric...@hotmail.com>:
> Das überflüssige abschneiden :-)
> http://makeashorterlink.com/index.php
ja - von solchen sites kenne ich bestimmt
ein halbes dutzend. aber das hilft nicht.
man kann nicht alle super-langen links,
die auch noch in the fly erzeugt werden,
mithilfe anderer sites abkuerzen.
die designer sollten solcher sites sollte
sich mal ein bischen mehr muehe geben..
Sven
Ulrike Jahnke-Soltau
(superlange Links)
> die designer sollten solcher sites sollte
> sich mal ein bischen mehr muehe geben..
... und wie würdest du z.B. folgenden Link abkürzen?
:-)
so long,
uja
p.s. der Link ist erfunden, also nicht klicken!
Steffen Schmidt
> ... und wie würdest du z.B. folgenden Link abkürzen?
> http://www.floraundfauna.de/cgi-bin/zeige_infos.cgi?hauptgruppe=pflanzen&familie=brassicaceae&art=lepidium&item=Gartenkresse
h++p://www.floraundfauna.de/gartenkresse.html
mod_rewrite machts möglich.
Michael Jendryschik
>... und wie würdest du z.B. folgenden Link abkürzen?
>
>http://www.floraundfauna.de/cgi-bin/zeige_infos.cgi?hauptgruppe=pflanzen&familie=brassicaceae&art=lepidium&item=Gartenkresse
<http://www.floraundfauna.de/pflanzen/brassicaceae/lepidium/gartenkresse>
>p.s. der Link ist erfunden, also nicht klicken!
Gruß,
MI
--
Einführung in XHTML, CSS und Webdesign: http://jendryschik.de/wsdev/einfuehrung/
XFrames Working Draft (Deutsche Übersetzung) : http://jendryschik.de/TR/xframes/
Disclaimer? Eine Stellungnahme zum Thema : http://jendryschik.de/misc/disclaimer
Was ist ein guter Standard? : http://jendryschik.de/wsdev/trans/designguide/
Uwe Schröder
> ... und wie würdest du z.B. folgenden Link abkürzen?
>
> http://www.floraundfauna.de/cgi-bin/zeige_infos.cgi?hauptgruppe=pflanzen&familie=brassicaceae&art=lepidium&item=Gartenkresse
<http://www.floraundfauna.de/pflanzen/brassicaceae/lepidium/Gartenkresse>?
> p.s. der Link ist erfunden, also nicht klicken!
dito :)
usch
Uwe Schröder
> h++p://www.floraundfauna.de/gartenkresse.html
>
> mod_rewrite machts möglich.
Nö. Eine Website gar nicht zu strukturieren, sondern alles ins Root zu
kippen, ist auch nicht sonderlich elegant. Weder aus der Sicht
desjenigen, der die Site pflegen muß, noch aus der Sicht des Besuchers,
der nicht auf Anhieb erkennen kann, in welchen Kontext die Seite
eingebettet ist, noch in Bezug auf Suchmaschinen, die URL-Teile als
exponierte Keywords bevorzugt indizieren.
usch
Ulrike Jahnke-Soltau
> <http://www.floraundfauna.de/pflanzen/brassicaceae/lepidium/Gartenkresse>?
gebe mich geschlagen :-)
(obwohl das andere System leichter zu pflegen ist)
so long,
uja
Ulrike Jahnke-Soltau
> h++p://www.floraundfauna.de/gartenkresse.html
>
> mod_rewrite machts möglich.
... wer hat und wer darf...
so long,
uja
Andreas Borutta
> <http://www.floraundfauna.de/pflanzen/brassicaceae/lepidium/Gartenkresse>?
http://floraundfauna.de/flora/brassicaceae/lepidium/gartenkresse.htm
Andreas, CNR
Lars Trebing
^^^^
Igitt!
Wirsing!
--
Lars Trebing | http://www.ltrebing.de/ | mailto:ltre...@ltrebing.de
Der Regenwald-Marketing-Gag: http://www.ltrebing.de/misc/krombacher-wwf/
Michael Jendryschik
>> <http://www.floraundfauna.de/pflanzen/brassicaceae/lepidium/Gartenkresse>?
>
>http://floraundfauna.de/...
Okay.
>...flora/brassicaceae/lepidium/gartenkresse.htm
^^^^
Warum das denn?
Volker Gringmuth
> Igitt!
... ähm ... wäre Dir ".doc" vielleicht lieber?
vG, ganz einklich.net in HTM programmiert habend
--
~~~~~~ Volker Gringmuth ~~~~~~~~~~~ http://einklich.net/ ~~~~~~~~~~~~~~~~~~~~~~~
"übrigens, ich bin nicht der Richtige Petrus!!" - "Ach ja? Das hast Du auch
schon in Mt 26,69-75 behauptet. Auf Dich fallen wir kein zweites Mal herein!"
("Petrus" und Bernd Gramlich in desd)
Johannes Lichtenberger
> Lars Trebing (ltre...@ltrebing.de) wrote:
>
>> Igitt!
>
> ... ähm ... wäre Dir ".doc" vielleicht lieber?
Die Informationslecks sind doch ganz nett.
Andreas Borutta
>>...flora/brassicaceae/lepidium/gartenkresse.htm
> ^^^^
> Warum das denn?
Der Herr nimmt, der Herr gibt.
Andreas
OK, ernsthaft:
Was sind bitte Eure Empfehlungen zum Weglassen von
Dateinamenserweiterungen in URLs?
Michael Jendryschik
>Was sind bitte Eure Empfehlungen zum Weglassen von
>Dateinamenserweiterungen in URLs?
Einfach die Dateinamenserweiterungen in URLs weglassen?
(Okay, ich glaube, es muss noch
Options +MultiViews
in der .htacces stehen...)
Gruß,
Andreas Borutta
>>Was sind bitte Eure Empfehlungen zum Weglassen von
>>Dateinamenserweiterungen in URLs?
>
> Einfach die Dateinamenserweiterungen in URLs weglassen?
Hört sich sehr gut an.
URLs ohne Dateinamenserweiterungen gefallen mir auch besser.
> (Okay, ich glaube, es muss noch
> Options +MultiViews
> in der .htacces stehen...)
Könntest Du mir, falls Du sie greifbar hast, bitte die konkrete Zeile
nennen, die man in der .htaccess ergänzen muss?
Mich würde auch ein Dokument interessieren, wo beschrieben wird, in
welcher Reihenfolge bei einer reinen Verzeichnisangabe in einer URL
nach Dokumenten in diesem Verzeichnis gesucht wird.
Wann soll man einen Backslash an das Ende einer URL hängen? Wann ist
er überflüssig?
Andreas
Uwe Schröder
>>(Okay, ich glaube, es muss noch
>> Options +MultiViews
>> in der .htacces stehen...)
>
> Könntest Du mir, falls Du sie greifbar hast, bitte die konkrete Zeile
> nennen, die man in der .htaccess ergänzen muss?
Hat er doch. "Options +MultiViews".
> Mich würde auch ein Dokument interessieren, wo beschrieben wird, in
> welcher Reihenfolge bei einer reinen Verzeichnisangabe in einer URL
> nach Dokumenten in diesem Verzeichnis gesucht wird.
http://httpd.apache.org/docs/mod/mod_dir.html
> Wann soll man einen Backslash an das Ende einer URL hängen?
Einen Backslash nach Möglichkeit gar nicht :)
Einen Schrägstrich schon eher.
> Wann ist er überflüssig?
Das kommt darauf an. "abc/url/" ist prinzipiell erst einmal ein völlig
anderes Dokument als "abc/url". Überflüssig ist er also nie.
Die meisten Webserver liefern allerdings für "abc/url/" das
Default-Dokument im Verzeichnis "url" aus und erzeugen für "abc/url"
einen Redirect auf "abc/url/". In diesem Fall wäre die Schreibweise mit
Schrägstrich die richtigere, weil sie pro Seitenaufruf einen
Request/Response-Dialog einspart.
usch
Andreas Borutta
>>>(Okay, ich glaube, es muss noch
>>> Options +MultiViews
>>> in der .htacces stehen...)
>>
>> Könntest Du mir, falls Du sie greifbar hast, bitte die konkrete Zeile
>> nennen, die man in der .htaccess ergänzen muss?
>
> Hat er doch. "Options +MultiViews".
Hups. Wegen der Schreibweise mit Großbuchstaben mitten im Wort hätte
ich das nicht vermutet.
Danke Euch. Funktioniert.
[...]
>> Wann soll man einen Backslash an das Ende einer URL hängen?
>
> Einen Backslash nach Möglichkeit gar nicht :)
> Einen Schrägstrich schon eher.
>
>> Wann ist er überflüssig?
>
> Das kommt darauf an. "abc/url/" ist prinzipiell erst einmal ein völlig
> anderes Dokument als "abc/url". Überflüssig ist er also nie.
>
> Die meisten Webserver liefern allerdings für "abc/url/" das
> Default-Dokument im Verzeichnis "url" aus und erzeugen für "abc/url"
> einen Redirect auf "abc/url/".
Aber nicht, wenn ein Dokument "abc/url.htm" existiert.
>In diesem Fall wäre die Schreibweise mit
> Schrägstrich die richtigere, weil sie pro Seitenaufruf einen
> Request/Response-Dialog einspart.
Alles klar. Das hatte ich vermutet.
In Kurzform also:
Mit Schrägstrich:
".../abc/xyz/" für ".../abc/xyz/index.htm"
^^^
Verzeichnisname
Ohne Schrägstrich:
".../abc/xyz" für ".../abc/xyz.htm"
^^^
Dateiname
Andreas
Lars Trebing
> Lars Trebing (ltre...@ltrebing.de) wrote:
>
>> Igitt!
>
> ... ähm ... wäre Dir ".doc" vielleicht lieber?
Nein. ".../gartenkresse/" reicht völlig aus. Oder meinetwegen
".../gartenkresse". Sogar ".../gartenkresse.html" wäre ja noch
akzeptabel, aber ".htm" ist ja mal wirklich eine ekelhafte
Microsoft-Krankheit.
Andreas Borutta
> Sogar ".../gartenkresse.html" wäre ja noch akzeptabel, aber ".htm"
> ist ja mal wirklich eine ekelhafte Microsoft-Krankheit.
Wie wirkt sich bei existierenden Dokumenten eine Änderung der
Dateinamen von ".htm" auf ".html" hinsichtlich Suchmaschinen aus?
Davon abgesehen:
Soll man ".xhtml" noch nicht verwenden?
Andreas
--
http://borumat.de/firebird-browser-tipps
http://borumat.de/40tude-dialog-newsreader-tipps
Uwe Schröder
>
>>Die meisten Webserver liefern allerdings [...] für "abc/url"
>
> Aber nicht, wenn ein Dokument "abc/url.htm" existiert.
... und MultiViews aktiv ist.
Korrekt. Wie gesagt, "xyz/" und "xyz" sind zwei völlig verschiedene
Dokumente, die durchaus auch beide gleichzeitig existieren können.
> In Kurzform also:
>
> Mit Schrägstrich:
> ".../abc/xyz/" für ".../abc/xyz/index.htm"
> ^^^
> Verzeichnisname
>
> Ohne Schrägstrich:
> ".../abc/xyz" für ".../abc/xyz.htm"
> ^^^
> Dateiname
Das war jetzt _sehr_ kurz, aber unter Vernachlässigung der diversen
Randbedingungen kann man das so stehen lassen.
usch
Johannes Lichtenberger
> Lars Trebing schrieb:
>
>> Sogar ".../gartenkresse.html" wäre ja noch akzeptabel, aber ".htm"
>> ist ja mal wirklich eine ekelhafte Microsoft-Krankheit.
>
> Wie wirkt sich bei existierenden Dokumenten eine Änderung der
> Dateinamen von ".htm" auf ".html" hinsichtlich Suchmaschinen aus?
>
> Davon abgesehen:
> Soll man ".xhtml" noch nicht verwenden?
Solange der HTTP-Server richtig konfiguriert ist, dürfte das Postfix
völlig egal sein.
Johannes Lichtenberger
Beim Apache für XHTML 1.0 als text/html ausgeliefert bspw.
AddType "text/html; charset=UTF-8" .xhtml
Lars Trebing
> Lars Trebing schrieb:
>
>> Sogar ".../gartenkresse.html" wäre ja noch akzeptabel, aber ".htm"
>> ist ja mal wirklich eine ekelhafte Microsoft-Krankheit.
>
> Wie wirkt sich bei existierenden Dokumenten eine Änderung der
> Dateinamen von ".htm" auf ".html" hinsichtlich Suchmaschinen aus?
Mit passend eingerichtetem "301 Moved Permanently" gar nicht,
andernfalls vorübergehend sehr schlecht.
> Davon abgesehen: Soll man ".xhtml" noch nicht verwenden?
GENAU deswegen ist es Blödsinn, URLs mit "htm", "html" o. ä. zu benutzen
- bei jeder Umstellung müßte man entweder alle URLs umstellen oder z. B.
XML-Daten unsinnigerweise hinter ".htm" verstecken.
Und natürlich gibt es auch noch einen zweiten Grund, keine URLs mit
"htm", "html" o. ä. zu benutzen: In die Adresse gehören relevante
Informationen zur Position der Daten und nicht irgendwelcher Datenmüll.
Ist übrigens auch alles irgendwo in
<http://www.w3.org/Provider/Style/URI> nachzulesen, teils explizit,
teils implizit.
Uwe Schröder
> Und natürlich gibt es auch noch einen zweiten Grund, keine URLs mit
> "htm", "html" o. ä. zu benutzen: In die Adresse gehören relevante
> Informationen zur Position der Daten und nicht irgendwelcher Datenmüll.
Das ist allerdings eine Frage, auf die ich noch keine befriedigende
Antwort gefunden habe: Daß ".php" oder ".cgi" als Endungen unsinnig
sind, sei unbestritten. Aber ist es wirklich Datenmüll, wenn man einem
URL ansehen kann, ob sich dahinter ein HTML-Dokument, ein Stylesheet,
ein PDF-File oder ein JPEG-Bild verbirgt?
usch
Uwe Schröder
> ".htm" ist ja mal wirklich eine ekelhafte Microsoft-Krankheit.
Eigentlich nicht mehr als ".jpg" für JPEG; trotzdem hat sich das
irgendwie durchgesetzt.
usch
Michael Jendryschik
>Das ist allerdings eine Frage, auf die ich noch keine befriedigende
>Antwort gefunden habe: Daß ".php" oder ".cgi" als Endungen unsinnig
>sind, sei unbestritten. Aber ist es wirklich Datenmüll, wenn man einem
>URL ansehen kann, ob sich dahinter ein HTML-Dokument, ein Stylesheet,
>ein PDF-File oder ein JPEG-Bild verbirgt?
Ich persönlich halte es so, dass ich bei Dokumenten (egal ob eigentlich
.html, .xhtml, .php, .cgi oder was auch immer) keine Endung angebe, bei
allen anderen Ressourcen (Grafiken, Textdateien, ZIP, PDF) hingegen
schon.
Andreas Borutta
>> Wie wirkt sich bei existierenden Dokumenten eine Änderung der
>> Dateinamen von ".htm" auf ".html" hinsichtlich Suchmaschinen aus?
>
> Mit passend eingerichtetem "301 Moved Permanently" gar nicht
Falls ich mich dazu entschliesse:
ist für jedes Dokument eine Zeile nötig oder kann man die Information
"alle *.htm der Site sind in *.html umbenannt worden* elegant mit
einem einzigen (RegEx) Muster ausdrücken?
> andernfalls vorübergehend sehr schlecht.
>
>> Davon abgesehen: Soll man ".xhtml" noch nicht verwenden?
>
> GENAU deswegen ist es Blödsinn, URLs mit "htm", "html" o. ä. zu benutzen
Da habt ihr offene Türen eingerannt. Ich habe das meiste schon
geändert.
Nein, hier ging es um Dateinamen, nicht um URLs.
Hat ".xhtml" am Ende des Dateinamens Nachteile?
Auf die Konfiguration des Servers (1&1) habe ich keinen Einfluss -
ausser über meine ".htaccess".
Uwe Schröder
> ist für jedes Dokument eine Zeile nötig oder kann man die Information
> "alle *.htm der Site sind in *.html umbenannt worden* elegant mit
> einem einzigen (RegEx) Muster ausdrücken?
Mit "RedirectMatch ..." oder mit "CheckSpelling On". Bitte lies endlich
die Apache-Dokumentation, da steht wirklich alles drin, was du hier
fragst. <http://httpd.apache.org/docs/>
usch
Michael Jendryschik
>Hat ".xhtml" am Ende des Dateinamens Nachteile?
Im Web nicht, nein.
Andreas Borutta
>>Hat ".xhtml" am Ende des Dateinamens Nachteile?
>
> Im Web nicht, nein.
Du verwendest
http://jendryschik.de/wsdev/einfuehrung/index.html
und
http://jendryschik.de/misc/disclaimer.xhtml
Warum verwendest Du verschiedene Endungen?
Hat es nur mit der "Evolution" Deiner Site zu tun?
Thomas Luethi
Andreas Borutta schrieb:
> Hat ".xhtml" am Ende des Dateinamens Nachteile?
In bezug auf was meinst Du?
Was das Web angeht, also ueber HTTP ausgelieferte Dokumente,
sollte theoretisch der Dateiname bzw. die URL voellig egal sein,
und nur der Content-Type (MIME-Type), den der Browser mit
dem Dokument schickt, sollte entscheidend sein.
Sollte.
(MS IE schaut zum Beispiel in die Dateien rein. Wenn in den ersten paar
Zeilen ein <html> oder so vorkommt, dann interpretiert er das HTML,
selbst wenn der Content-Type text/plain ist und die Endigung *.txt)
Zur Frage, welchen Content-Type fuer XHTML gebraucht werden soll:
http://www.w3.org/TR/xhtml-media-types/
http://schneegans.de/tips/apache-xhtml/
---
Ein Punkt wurde in dieser Diskussion allerdings bisher nicht erwaehnt:
Die lokale Betrachtung und Bearbeitung von HTML-Seiten.
Das betrifft natuerlich einerseits Webautoren, andererseits kann
es aber auch Benutzer betreffen. Naemlich dann, wenn sie
eine HTML-Seite bei sich lokal speichern (Datei -> Speichern unter...)
Beispiel: HTML-Seiten ohne Firlefanz und Bilder.
http://www.example.com/seite1.html
http://www.example.com/seite2.html
http://www.example.com/seite3.html
Benutzer speichert die Dateien lokal (nur den Quelltext, ohne Bilder
u.s.w., ohne "intelligente" Browser-Funktionen, die aus relativen
Links absolute Links mit "http://" machen.)
als seite1.html, seite2.html und seite3.html im gleichen Verzeichnis.
Wenn nun der Webautor das ".html" in den URLs und in den relativen
Links verwendet hat, dann funktionieren die relativen Links auch
wieder beim Benutzer lokal.
Und dank der Endung ".html" weiss Windows, dass es die Dateien bei
Doppelklick mit dem Standard-Browser des Benutzers oeffnen soll.
(Und ja, ich weiss, dass gewisse Betriebssysteme nicht auf
Dateiendungen angewiesen sind, sondern den Inhalt angucken.
Aber die ca. 80 - 90 % Windows-Benutzer haben es IMHO auch
verdient, so gut wie moeglich bedient zu werden. Und da gehoert
eine Dateiendigung fuer mich eben dazu.)
Ich plaediere deshalb dafuer, saemtlichen HTML- und XHTML-Dokumenten
Namen auf ".html" zu geben, und diese Endigung auch in Links und URLs
zu verwenden.
---
> Auf die Konfiguration des Servers (1&1) habe ich keinen Einfluss -
> ausser über meine ".htaccess".
Das reicht doch.
AddType text/html .xhtml .html .htm
AddDefaultCharset ISO-8859-1
und aehnliches duerfte doch meistens erlaubt sein...
mfg
Thomas
Thomas Luethi
Gemeint war natuerlich
... nur der Content-Type, den der Weberver mit dem Dokument schickt,
sollte entscheidend sein.
'tschuldigung, mfg
Thomas
Michael Jendryschik
>>>Hat ".xhtml" am Ende des Dateinamens Nachteile?
>>
>> Im Web nicht, nein.
>
>Du verwendest
>http://jendryschik.de/wsdev/einfuehrung/index.html
>und
>http://jendryschik.de/misc/disclaimer.xhtml
>
>Warum verwendest Du verschiedene Endungen?
Meine Einführung biete ich 1:1 als Download-Version an, um mir möglichst
wenig zusätzliche Arbeit zu machen (also packen und fertig). Daher
arbeite ich da mit relativen Verweisen und Angabe der Dateiendungen.
Alles andere macht nur Probleme.
Christoph Päper
>
> Eigentlich nicht mehr als ".jpg" für JPEG; trotzdem hat sich das
> irgendwie durchgesetzt.
Stimmt, schon lange kein .jfif mehr gesehen.
--
»Ich vergesse das meiste, was ich gelesen habe;
nichtsdestoweniger aber trägt es zur Erhaltung meines Geistes bei.«
Georg Christoph Lichtenberg
Christoph Päper
> Michael Jendryschik schrieb:
>
>>> Was sind bitte Eure Empfehlungen zum Weglassen von
>>> Dateinamenserweiterungen in URLs?
"Life's a bitch and then you die."
Soll heißen, eigentlich sollte es nur Vorteile haben und einfach umzusetzen
sein. Leider macht einem die Praxis bisweilen einen Strich durch die
Rechnung. Neben den Browsern, die beim lokalen Speichern keine vernünftigen
Anpassungen treffen, sind das UAs und Menschen, die URLs nach Gutdünken
anpassen.
> Mich würde auch ein Dokument interessieren, wo beschrieben wird, in
> welcher Reihenfolge bei einer reinen Verzeichnisangabe in einer URL
> nach Dokumenten in diesem Verzeichnis gesucht wird.
In der .htaccess oder übergeordneter Konfigurationsdatei die Zeile die
mit »DirectoryIndex« beginnt.
> Wann soll man einen Backslash an das Ende einer URL hängen? Wann ist
> er überflüssig?
Wenn dich kaputte Caches und Browser sowie Besucher, die sich URLs ohne
Dateiendung oder Schrägstrich am Ende nicht vorstellen können, unterstützen
willst, solltest du jeweils die Adresse der nicht existierenden Ressource
auf die der existierenden umleiten. Mod_speling (sic!) macht das in den
meisten Fällen automatisch, ist aber nicht überall vorhanden.
Alternativ benutze nur URLs mit Slash am Ende, auch wenn sie gar nicht auf
Verzeichnisse oder Indexdateien zeigen, damit haben weder UAs noch Us
Probleme.
--
»Der Klügere gibt nach -- Eine traurige Wahrheit:
Sie begründet die Weltherrschaft der Dummen.«
Marie von Ebner-Eschenbach
Alexander Reiter
> Soll heißen, eigentlich sollte es nur Vorteile haben und einfach umzusetzen
> sein. Leider macht einem die Praxis bisweilen einen Strich durch die
> Rechnung. Neben den Browsern, die beim lokalen Speichern keine vernünftigen
> Anpassungen treffen, sind das UAs und Menschen, die URLs nach Gutdünken
> anpassen.
Leider. Mit relativen Links ist ein Slash am Ende fatal.
Aus einem /dir/seite-01/ statt /dir/seite-01 wird dann schnell ein
/dir/seite-01/seite-02 statt dem gewünschten /dir/seite-02.
Mir wäre es im Zweifelsfall lieber, wenn Apache auf /dir/seite-01/ ein
404 erzeugt.
> Wenn dich kaputte Caches und Browser sowie Besucher, die sich URLs ohne
> Dateiendung oder Schrägstrich am Ende nicht vorstellen können, unterstützen
> willst, solltest du jeweils die Adresse der nicht existierenden Ressource
> auf die der existierenden umleiten. Mod_speling (sic!) macht das in den
> meisten Fällen automatisch, ist aber nicht überall vorhanden.
Gibt es auch eine andere, ohne mod_speling, praktikable Möglichkeit
überflüssige Slashes zu entfernen?
--
»Program (Änderungen vorbehalten und sowie so ist der Stifft an allen schuld)
[...] 13.00 Revulution [...] 14.30 EVA Skethc [...] 18.00 Miyo [...] Danach
eventuele Zuspätkommer und Siger Ehrung [...] Zwischen durch Anmoderation
der Events durch Team Rucket.« -- Aushang auf der Bonenkai 2001
Christoph Schneegans
> Ich plaediere deshalb dafuer, saemtlichen HTML- und XHTML-Dokumenten
> Namen auf ".html" zu geben, und diese Endigung auch in Links und URLs
> zu verwenden.
Konsequenterweise müßte man dann auch "http://www.example.org/" als
"http://www.example.org/index.html" schreiben. Dann kann's ja wohl
nicht sein, selbst man die Kanonizität der URL durch eine Umleitung
von / auf /index.html sicherstellt.
Außerdem gibt es auf IIS üblicherweise kein mod_rewrite-Äquivalent;
bei den meisten Providern ist es schlichtweg unmöglich, .html-Dateien
vom ASP-Interpreter verarbeiten zu lassen. Andererseits gibt es beim
IIS auch kein .htaccess-Äquivalent; wenn ich also einen
"charset"-Parameter im "Content-Type"-Header ausgeben will, muß ich
schon von .html auf .asp umstellen.
--
<http://schneegans.de/> |
Joachim Wiesemann
> Außerdem gibt es auf IIS üblicherweise kein mod_rewrite-Äquivalent;
> bei den meisten Providern ist es schlichtweg unmöglich, .html-Dateien
> vom ASP-Interpreter verarbeiten zu lassen. Andererseits gibt es beim
> IIS auch kein .htaccess-Äquivalent; wenn ich also einen
> "charset"-Parameter im "Content-Type"-Header ausgeben will, muß ich
> schon von .html auf .asp umstellen.
Da ist es einfacher und sinnvoller, von IIS auf Apache umzustellen.
Viele Grüße
Joachim
FUP2 .servers gesetzt
--
Dr. Joachim Wiesemann
http://www.bestviewed.de/ Seiten über Webdesign und Usability
http://jwiesemann.com/ Ingenieurdienstleistungen, Usabilityberatung
"Die schärfsten Kritiker der Elche waren früher selber welche!"
Konni Scheller
> Außerdem gibt es auf IIS üblicherweise kein mod_rewrite-Äquivalent;
Allein das ist ein Grund IIS nicht zu benutzen.
Servus,
Konni
Konni Scheller
> Soll heißen, eigentlich sollte es nur Vorteile haben
äh? Bitte erläutere mir diese. Ich sehe keine, bin ich blind?
Servus,
Konni
Christoph Päper
> Christoph Päper <crisso...@gmx.net> wrote:
>
>> Soll heißen, eigentlich sollte es nur Vorteile haben
>
> äh? Bitte erläutere mir diese. Ich sehe keine, bin ich blind?
IIRC stehen ein paar in <http://www.w3.org/Provider/Style/URI.html>.
Als Metainformation für den Besucher können einige wohlbekannte
Erweiterungen -- .html ist das möglicherweise -- durchaus einen Mehrwert
besitzen, aber IMHO gerade .htm[l] nicht, da Otto Normalsurfer i.d.R.
ohnehin erwartet, dass eine HTTP-URL auf eine HTML-Datei zeigt. Besser
gesagt, auch wenn er nicht weiß, was HTML ist, erwartet er doch, dass Links
in seinem Browserfenster geöffnet werden und sich die Bedienelemente des
Browsers nicht verändern, was generell nur auf HTML zutrifft.
Erweiterungen, die nur für serverseitige Methoden von Bedeutung sind, also
im Endeffekt doch nur HTML liefern, (.php[34], .asp, .jsp, .dll, .pl, .cgi,
.shtml ...) sind dagegen eher schädlich, tragen sie doch bestenfalls eine
für den Besucher völlig uninteressante Metainformation.
Die URLs von eingebundenen Bildern sehen die meisten sowieso nie.
Insbesondere wenn man sie in verschiedenen Formaten anbietet (»content
negotiation«) oder das möglicherweise irgendwann einmal tun bzw. auf ein
anderes Format umsteigen möchte (bspw. GIF -> PNG), bietet es sich an, die
Erweiterung wegzulassen. Vielleicht wäre es eine Idee, statt gar keiner eine
generische Erweiterung zu benutzen, z.B. .img, was dann auch Funktionen wie
die Icons in Operas Link-Panel weiterhin ermöglichen würde. Andererseits
gibt es das 'type'-Attribut auch beim 'a'-Element und viele Bilder liegen in
Pfaden mit Bezeichnern wie »bilder«, »img«, »images«, »pics« usw.
P.S.: Früher war die kanonische Adresse o.g.
Dokumentes »http://www.w3.org/Provider/Style/URI«; sie funktioniert auch
jetzt noch.
--
"There are painters who transform the sun into a yellow spot,
but there are others who, thanks to their art and intelligence,
transform a yellow spot into the sun."
Pablo Picasso
Christoph Schneegans
> P.S.: Früher war die kanonische Adresse o.g. Dokumentes
> »http://www.w3.org/Provider/Style/URI«;
Das ist sie immer noch, und genauso ist es u.a. von
<http://www.w3.org/Provider/Style/>, <http://www.w3.org/Addressing/>
und <http://www.w3.org/QA/Tips/uri-choose> verlinkt.
"http://www.w3.org/Provider/Style/URI.html" ergibt auch irgendwie
keinen Sinn, wenn dort gerade von Dateierweiterungen abgeraten wird.
> sie funktioniert auch jetzt noch.
Das wäre ja noch schöner.
--
<http://schneegans.de/> |
Andreas Borutta
>> Hat ".xhtml" am Ende des Dateinamens Nachteile?
> Ein Punkt wurde in dieser Diskussion allerdings bisher nicht erwaehnt:
> Die lokale Betrachtung und Bearbeitung von HTML-Seiten.
[...]
> Wenn nun der Webautor das ".html" in den URLs und in den relativen
> Links verwendet hat, dann funktionieren die relativen Links auch
> wieder beim Benutzer lokal.
Und wenn der Webautor ".xhtml" verwendet? Auf den Vergleich ".html"
versus ".xhtml" wollte ich hinaus.
Gebe ich z. B. "d:\example.xhtml" in das Adressfeld des IE6 ein,
öffnet die Seite auf hier Windows XP in Mozilla.
[...]
> Ich plaediere deshalb dafuer, saemtlichen HTML- und XHTML-Dokumenten
> Namen auf ".html" zu geben, und diese Endigung auch in Links und URLs
> zu verwenden.
Hhmm.
Selber benutze ich selten lokal gespeicherte Seiten, daher war es mir
nicht aufgefallen.
Du hast Recht. Links mit URLs ohne Dateiendungen laufen ins Leere.
Ein Zugänglichkeits-GAU.
Ich habe mir einige Seiten auf useit.com daraufhin angesehen.
URLs auf "Nicht-Standarddokumente" tragen die Endung "html".
Konni Scheller
> IIRC stehen ein paar in <http://www.w3.org/Provider/Style/URI.html>.
Da steht nur ein einziger "Vorteil" - der keiner ist.
Ich glaube nicht, dass es irgendwas bringt .html wegzulassen.
Servus,
Konni
Christoph Päper
>
> Ich glaube nicht, dass es irgendwas bringt .html wegzulassen.
Und das von einem Macnutzer.
--
"For every human problem, there is a neat, simple solution;
and it is always wrong."
H.L. Mencken, 1880-1956
Lars Trebing
> [<http://www.w3.org/Provider/Style/URI>]
>
> Da steht nur ein einziger "Vorteil" - der keiner ist.
>
> Ich glaube nicht, dass es irgendwas bringt .html wegzulassen.
Es hat den genannten Vorteil und den, daß der URL nicht künstlich
aufgebläht wird. Und es hat keinen Nachteil. Warum sollte man es also
nicht tun?
Konni Scheller
> Es hat den genannten Vorteil
erklär ihn mir nochmal auf deutsch, vielleicht verstehe ich es dann.
> und den, daß der URL nicht künstlich
> aufgebläht wird.
Aua.
> Und es hat keinen Nachteil.
Selbstverständlich. Du hast lokal ziemliche Probleme, wenn Du Files von
der Platte mittels Doppelklick starten willst.
> Warum sollte man es also nicht tun?
Weil es nur *Nach*Teile hat, aber keinen echten Vorteil.
Servus,
Konni
Matthias P. Wuerfl
>> .html wegzulassen.
>
> Warum sollte man es also nicht tun?
Wie ist es technisch einwandfrei und praktisch zu bewerkstelligen ohne
dass man sich irgendwas damit verbaut? Wie erkennt man am praktischsten
an einer URL, dass eine HTML-Resource angefordert wurde?
Gruesse, Matthias
Johannes Koch
> Ich glaube nicht, dass es irgendwas bringt .html wegzulassen.
Ich streue mal DIP-1 und DIP-2 aus
<http://www.w3.org/TR/2003/NOTE-di-princ-20030901/> in die Diskussion ein.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
Lars Trebing
> Lars Trebing <ltre...@ltrebing.de> wrote:
>
>> Es hat den genannten Vorteil
>
> erklär ihn mir nochmal auf deutsch, vielleicht verstehe ich es dann.
| "cgi", even ".html" is something which will change. You may not be
| using HTML for that page in 20 years time, but you might want today's
| links to it to still be valid. The canonical way of making links to
| the W3C site doesn't use the extension.
Was ist denn daran nicht verständlich?
>> und den, daß der URL nicht künstlich aufgebläht wird.
>
> Aua.
Oh. Tut es denn arg weh?
>> Und es hat keinen Nachteil.
>
> Selbstverständlich. Du hast lokal ziemliche Probleme, wenn Du Files
> von der Platte mittels Doppelklick starten willst.
Wer hat denn heutzutage lokal noch keinen Webserver installiert, über
den er das alles macht? Du ja wohl nicht, bei deinem exzessiven
Rewrite-Gebrauch. :)
Lars Trebing
> Lars Trebing wrote:
>
> [URLs ohne ".html"]
>
> Wie ist es technisch einwandfrei und praktisch zu bewerkstelligen
> ohne dass man sich irgendwas damit verbaut?
Was sollte man sich denn mit URLs ohne ".html" verbauen?
> Wie erkennt man am praktischsten an einer URL, dass eine
> HTML-Resource angefordert wurde?
Wozu sollte man an einem URL sehen wollen, in welchem Format die
angeforderten Sachen herauskommen? Ob das z. B. HTML oder XHTML ist,
kann doch recht egal sein; je nachdem, was der Browser für Accept-Header
verschickt, wird man wohl auch mit XML, WML oder gar PDF zufrieden sein.
Konni Scheller
> | "cgi", even ".html" is something which will change. You may not be
> | using HTML for that page in 20 years time, but you might want today's
> | links to it to still be valid. The canonical way of making links to
> | the W3C site doesn't use the extension.
>
> Was ist denn daran nicht verständlich?
Ganz einfach. Das ist nur Gelaber - ausgenommen, dass man kein
*.cgi *.pl etc. verwenden sollte. Aber deswegen gleich *.html aufgeben?
> >> und den, daß der URL nicht künstlich aufgebläht wird.
> >
> > Aua.
>
> Oh. Tut es denn arg weh?
Ja. "Künstlich aufblähen" sind URLs à la Spiegel.de. Nicht *.html.
> > Du hast lokal ziemliche Probleme, wenn Du Files von
> > der Platte mittels Doppelklick starten willst.
>
> Wer hat denn heutzutage lokal noch keinen Webserver installiert, über
> den er das alles macht? Du ja wohl nicht, bei deinem exzessiven
> Rewrite-Gebrauch. :)
Selbst ich richte für schnelle Änderungen an einer mit wget geholten
Seite nicht unbedingt ständig Virtual Hosts ein.
Alles in allem, überwiegen für mich die Nachteile gegenüber einem nicht
sichtbaren "Vorteil".
Servus,
Konni
Konni Scheller
> Ich streue mal DIP-1 und DIP-2 aus
> <http://www.w3.org/TR/2003/NOTE-di-princ-20030901/> in die Diskussion ein.
Also, dann, was genau? Das ist viel Stoff zum Lesen und die Kleine hat
Hunger ("Näng näng näng..." ;-)
Servus,
Konni
dem Englisch Lesen immer noch Anstrengung kostet
Johannes Koch
> Johannes Koch <ko...@w3development.de> wrote:
>
>
>>Ich streue mal DIP-1 und DIP-2 aus
>><http://www.w3.org/TR/2003/NOTE-di-princ-20030901/> in die Diskussion ein.
>
>
> Also, dann, was genau?
DIP-1 und DIP-2. Die wirst du beim Füttern wohl noch finden können, oder?
Konni Scheller
> DIP-1 und DIP-2. Die wirst du beim Füttern wohl noch finden können, oder?
Du hast keine Ahnung, was hier abgeht ;-)
Guggen wir mal:
> DIP-1: Device independent access
>
> For some web content or application to be device independent, it should be
> possible for a user to obtain a functional user experience associated with
> its web page identifier via any access mechanism.
Deute ich das richtig? Verstehe ich das flasch? Hier wird gewünscht,
dass der User erkennt, was für eine Datei es ist? Also *für*
Dateiendungen?
> This is the fundamental principle for device independence from the user
> perspective. It does not say that the user experience will be the same on
> every device. But it does say that the user should be able to obtain a
> user experience and that the user experience obtained should be at least
> functional.
Das ist Gelaber. Nach dem Auseinanderfieseln liest sich das wie:
"Die Bedienbarkeit sollte dem Gerät angepasst sein."
> Example 2.1.2.1: A user enters a web page identifier for a weather
> forecasting page on different devices. On the screen of a PDA, the text
> "Tomorrow" is shown, together with a graphic of a sun. On the screen of a
> phone, the text "Tomorrow: sun" is shown. On an in-car PC, the words
> "Tomorrow will be sunny" are spoken. These are all user experiences that
> have been adapted to be functional for their specific access mechanisms.
Nett. Hat mit Dateiendungen nicht das geringste zu tun.
> Example 2.1.2.2: If on some device the same web page identifier as in the
> previous example gave either no user experience, or a user experience
> consisting of the text "Cannot display graphics", this would not be a
> functional user experience.
Ach.
> The goal is that a functional user experience should be possible via any
> access mechanism. The method by which presentation and interaction are
> provided may vary according to the different access mechanisms, but the
> possibility of a functional user experience should always exist.
Ach was. Nichts anderes predigen wir hier seit Jahren.
> In particular, it should be possible to provide a functional user
> experience even on a limited capability device - though it may be of
> reduced quality compared to that on more capable devices.
Kompliziert ausgedrückt, heißt es nichts anderes als dass Farbfernsehen
auch auf S/W-Fernsehern zu sehen sein muss, halt ohne Farbe.
> Example 2.1.2.3: Where an image would occur on an image-capable device, a
> text alternative could be displayed on a text-only device, or the text
> could be spoken when accessed by a voice-only phone.
Ja. Wo ist der Bezug zu Dateiendungen?
> DIP-2: Device independent Web page identifiers
>
> A web page identifier that provides a functional user experience via one
> access mechanism should also provide a user experience of equivalent
> functionality via any other access mechanism.
>
> In other words,
...aber nicht weniger kompliziert ausgedrückt..
> the intended function of a web page is associated with the
> web page identifier, and should apply to all user experiences obtained
> from the web page identifier, no matter what the access mechanism.
ich warte immer noch auf ein Argument.
> Example 2.1.2.4: By bookmarking a web page identifier that provides a
> functional user experience on one device it should be possible to obtain a
> corresponding user experience on another device with equivalent
> functionality. The user experiences may be different due, among other
> things, to the different capabilities of the devices, but their intended
> function is the same and they should both be at least functional.
Bis soweit alles ok.
> In order to meet this principle, it may be necessary to restrict or
> re-interpret what is acceptable as a web page identifier.
Warum, zum Teufel? Genau das hat bis jetzt niemand erklärt.
> For example, a
> URI that includes a suffix indicating its representation, such as
> "example.html", may need the suffix to be ignored when the material is
> adapted for a non-HTML device.
Tja. Wenn ich kein HTML ausliefere, dann schreib ich auch nicht .html.
Wo ist das Problem?
Wenn ich xml ausliefere, schreibe ich .xml. Wenn ich jpeg ausliefere,
gibts .jpg. Nichts könnte einfacher sein.
Wo liegt mein Denkfehler? Ich bitte nochmals um Aufklärung - aber bitte
nicht mit einem erneuten Verweis auf einen langen, in kompliziert
geschriebenen Englisch geschriebenen Text. Ich tue mir verdammt hart mit
sowas und die Gefahr von Missverständnissen ist groß. Schreib halt
einfach, *was* Du meinst.
Servus,
Konni
P.S. Nicht persönlich gemeint. Ich kann wirklich englisch nur schwer
lesen, wenn es technisch wird und es kostet mir viel Mühe.
Johannes Koch
>>DIP-1: Device independent access
>>
>>For some web content or application to be device independent, it should be
>>possible for a user to obtain a functional user experience associated with
>>its web page identifier via any access mechanism.
>
>
> Deute ich das richtig? Verstehe ich das flasch? Hier wird gewünscht,
> dass der User erkennt, was für eine Datei es ist? Also *für*
> Dateiendungen?
Falsch. Egal ob ich den URL in ein WML-Handy oder einen HTML-Browser
eingebe, bei beiden bekomme ich was sinnvolles zurück. Du kannst
natürlich auch für einen "*.html"-URL Content-Negotiation vorsehen. Aber
warum soll ein WML-Handy einen "*.html"-URL anfordern, um WML zu bekommen?
Für URLs hinter denen auf jeden Fall für immer und alle Zeit nur HTML
liegt, kannst du IMHO ".html" anhängen.
André Malo
> Falsch. Egal ob ich den URL in ein WML-Handy oder einen HTML-Browser
> eingebe, bei beiden bekomme ich was sinnvolles zurück. Du kannst
> natürlich auch für einen "*.html"-URL Content-Negotiation vorsehen. Aber
> warum soll ein WML-Handy einen "*.html"-URL anfordern, um WML zu bekommen?
Warum sollte ein WML-Handy überhaupt etwas anfordern? Das macht ja wohl
immernoch der *Nutzer*, der sein Werkzeug bedient. Und dem dürfte es
ziemlich wurst sein, was das steht. Er kann üblicherweise eh nichts damit
anfangen. Dem Handy ist das auch egal; wenn nicht, ist es kaputt.
nd
Konni Scheller
> Falsch. Egal ob ich den URL in ein WML-Handy oder einen HTML-Browser
> eingebe, bei beiden bekomme ich was sinnvolles zurück. Du kannst
> natürlich auch für einen "*.html"-URL Content-Negotiation vorsehen. Aber
> warum soll ein WML-Handy einen "*.html"-URL anfordern, um WML zu bekommen?
JETZT habe ich verstanden.
Warum schreibst Du das nicht gleich? :-)
Es geht also nicht darum, dass HTML-fähige Händis zu bedienen, sondern
unter /einer/ URI /verschiedene/ Contents zu liefern, einmal HTML und
einmal beispielsweise WML, oder PDF oder sonstwas.
Naja, inwie weit das sinnvoll beim jetzigen Stand der Technik ist, kann
man sich fragen. Allerdings ist das für die Zukunft ein denkbarer Weg.
> Für URLs hinter denen auf jeden Fall für immer und alle Zeit nur HTML
> liegt, kannst du IMHO ".html" anhängen.
Ack.
Servus,
Konni
Johannes Koch
> Johannes Koch <ko...@w3development.de> wrote:
>
>
>>Falsch. Egal ob ich den URL in ein WML-Handy oder einen HTML-Browser
>>eingebe, bei beiden bekomme ich was sinnvolles zurück. Du kannst
>>natürlich auch für einen "*.html"-URL Content-Negotiation vorsehen. Aber
>>warum soll ein WML-Handy einen "*.html"-URL anfordern, um WML zu bekommen?
>
>
> JETZT habe ich verstanden.
>
> Warum schreibst Du das nicht gleich? :-)
>
> Es geht also nicht darum, dass HTML-fähige Händis zu bedienen, sondern
> unter /einer/ URI /verschiedene/ Contents zu liefern, einmal HTML und
> einmal beispielsweise WML, oder PDF oder sonstwas.
Genau
> Naja, inwie weit das sinnvoll beim jetzigen Stand der Technik ist, kann
> man sich fragen. Allerdings ist das für die Zukunft ein denkbarer Weg.
Warum nur für die Zukunft? Es gibt durchaus Anwendungen, für die es
sinnvoll wäre, verschiedene Formate auszuliefern: HTML für HTML-Browser,
WML oder XHTML-Mobile für Handies.
Johannes Koch
> * Johannes Koch <ko...@w3development.de> wrote:
>
>
>>Falsch. Egal ob ich den URL in ein WML-Handy oder einen HTML-Browser
>>eingebe, bei beiden bekomme ich was sinnvolles zurück. Du kannst
>>natürlich auch für einen "*.html"-URL Content-Negotiation vorsehen. Aber
>>warum soll ein WML-Handy einen "*.html"-URL anfordern, um WML zu bekommen?
>
>
> Warum sollte ein WML-Handy überhaupt etwas anfordern?
Weil der Nutzer es dazu auffordert (bzw. den User-Agent im Handy).
> Das macht ja wohl
> immernoch der *Nutzer*, der sein Werkzeug bedient. Und dem dürfte es
> ziemlich wurst sein, was das steht.
Damit es ihm egal ist ("ich merke mir 'www.server.org/kinosuche' und
kann das irgendwo eingeben"), sollte der URL eben keine Auskunft über
das ausgelieferte Format geben.
> Er kann üblicherweise eh nichts damit
> anfangen. Dem Handy ist das auch egal; wenn nicht, ist es kaputt.
?
Andreas Borutta
>> Naja, inwie weit das sinnvoll beim jetzigen Stand der Technik ist, kann
>> man sich fragen. Allerdings ist das für die Zukunft ein denkbarer Weg.
>
> Warum nur für die Zukunft? Es gibt durchaus Anwendungen, für die es
> sinnvoll wäre, verschiedene Formate auszuliefern: HTML für HTML-Browser,
> WML oder XHTML-Mobile für Handies.
Und ich dachte immer ein Gutes an (X)HTML sei: einmal auszeichnen, nie
mehr kümmern als Autor - ganz egal, welches Medium das Ziel ist.
Lars Kasper
> Aber ist es wirklich Datenmüll, wenn man einem URL ansehen kann, ob
> sich dahinter ein HTML-Dokument, ein Stylesheet, ein PDF-File oder
> ein JPEG-Bild verbirgt?
Nein.
Lars Kasper
> >http://jendryschik.de/wsdev/einfuehrung/index.html
> >http://jendryschik.de/misc/disclaimer.xhtml
>
> Meine Einführung biete ich 1:1 als Download-Version an, um mir möglichst
> wenig zusätzliche Arbeit zu machen (also packen und fertig). Daher
> arbeite ich da mit relativen Verweisen
Und sonst auf der Webseite ausschließlich absolute?
> und Angabe der Dateiendungen.
Da wäre .htm noch kompatibler ;-)
Lars Kasper
> Guggen wir mal:
Danke für's Vorlesen und die bissigen Kommentare.
Michael Jendryschik
>> Meine Einführung biete ich 1:1 als Download-Version an, um mir möglichst
>> wenig zusätzliche Arbeit zu machen (also packen und fertig). Daher
>> arbeite ich da mit relativen Verweisen
>
>Und sonst auf der Webseite ausschließlich absolute?
Genauer gesagt: Ich arbeite innerhalb meiner Einführung mit Verweisen
relativ zum Dokument, auf der restlichen Website meist mit Verweisen
relativ zum Document Root.
Gruß,
>> und Angabe der Dateiendungen.
>
>Da wäre .htm noch kompatibler ;-)
Selbst wenn, ich würde es nicht über's Herz bringen.
MI
--
Einführung in XHTML, CSS und Webdesign: http://jendryschik.de/wsdev/einfuehrung/
XFrames Working Draft (Deutsche Übersetzung) : http://jendryschik.de/TR/xframes/
Disclaimer? Eine Stellungnahme zum Thema : http://jendryschik.de/misc/disclaimer
Was ist ein guter Standard? : http://jendryschik.de/wsdev/trans/designguide/
Johannes Koch
[Kommentare zu DIP]
Möchtest du diese Kommentare an die DI-Mailingliste (www...@w3.org)
schicken?
Gabriele Jesdinsky
>>Da wäre .htm noch kompatibler ;-)
>
>Selbst wenn, ich würde es nicht über's Herz bringen.
Ich schon: Wenn 3 Stellen zur Identifizierung reichen, sind 4 ja
eigentlich nur Geschwätzigkeit. ;-)
BTW für zeitknappe PHP-Anwender:
Zumindest bei 1&1 puretec kommt es bislang beim Parsen von
*.html-Dateien zu einem Problem, weil auch die Dateien im Verzeichnis
/logs darauf enden, für die man normalerweise keine Rechte besitzt
(error 500).
Gruß Gabi
Gabriele Jesdinsky
>("ich merke mir 'www.server.org/kinosuche' und
>kann das irgendwo eingeben"), sollte der URL eben keine Auskunft über
>das ausgelieferte Format geben.
ACK für den *Eingabe*-URL.
Ich will mit "berlin.de/kino" durch Redirect permanent
h++p://www.berlin.de/kultur/kino/adressen.htm
und intern/RewriteRule
h++p://www.berlin.de/script.php?feld1=kultur&feld2=kino&feld3=adressen
erhalten, bzw. eben die entsprechende WML-Datei o.ä.*)
*) jedenfalls sofern sinnvoll;
...Ich kann es kaum noch erwarten, mir dank der
Milliarden-Investitionen für UMTS endlich die neuesten Kinofilme in
Daumennagelgröße direkt reinzuziehen. ;o)
Gruß Gabi
Gabriele Jesdinsky
>Für URLs hinter denen auf jeden Fall für immer und alle Zeit nur HTML
>liegt, kannst du IMHO ".html" anhängen.
Auch sonst, mit mod_rewrite kann ich es ja jederzeit problemlos
ändern.
Gruß Gabi
Christoph Päper
>
> Tja. Wenn ich kein HTML ausliefere, dann schreib ich auch nicht .html.
> Wo ist das Problem?
Ein Problem ist, dass nicht jeder, der HTML ausliefert auch .html schreibt,
sondern z.B. .php oder .asp.
> Wenn ich xml ausliefere, schreibe ich .xml.
Und bei XHTML .html, .xhtml, .xml, .html.xml, .xml.html, .xhtml.xml,
.xml.xhtml oder was?
> Wenn ich jpeg ausliefere, gibts .jpg. Nichts könnte einfacher sein.
Ich denke, der wichtigste Grundsatz hier ist: »Don't mention the mechanics.«
Die auf dem Server verwendeten Techniken sind vollkommen uninteressant und
ändern sich i.d.R. am ehesten, ergo sollten .php, .asp etc. nie in der URL
auftauchen.
Der User erwartet, dass Links -- die Ausnahme sind wohl explizite
Downloadlinks -- sich im Browseranzeigebereich öffnen. Ein .html bringt ihm
also nichts, weil es sowieso den Normalzustand bedeutet; es schadet
allerdings auch nicht wirklich, außer dass es länger ist.
Bei <img>-Bildern ist es ebenfalls egal, weil nur die wenigsten Benutzer die
URL je sehen und wenn, dann entweder im Bildeigenschaftendialog, wo neben
der URL der Typ, die Größe etc. steht, oder im Quelltext. Wozu man beim
(Fremd-)Quelltextlesen Metainformationen über verlinkte Ressourcen brauchen
sollte, weiß ich nicht.
Links auf Bilder, PDFs, Officedokumente u.ä.: TXTs, JPEGs und GIFs dürften
so ziemlich in jeder Browserumgebung anzeigbar sein. Alles andere sollte
sowieso explizit vermerkt werden, weil eben nicht jeder weiß, wie er
entsprechende Informationen aus ein paar Buchstaben einer URL bekommen
sollte. Ein »image«, »pic« oder »bild« im Pfad ist sicher für viele auch
hilfreicher als ein .jpeg am Ende.
Daneben gibt es für Metainformationen natürlich noch das 'type'-Attribut,
theoretisch zumindest.
Aber das habe ich im Wesentlichen schon vorgestern in
<news:bpthvg$1dps$1...@ariadne.rz.tu-clausthal.de> geschrieben. Leider gingst
du in deiner Antwort darauf nur auf einen Link ein, eigentlich nicht mal
das.
Eine Sache spricht übrigens ein wenig für die Angabe von .html etc.: Google
findet nur anhand von bestimmten Strings an bestimmten Positionen in URLs
Ergebnisse bei Angabe des 'filetype'-Parameters, d.h.
http://www.example.com/ oder /example.xhtml würde bei der Suchanfrage
"example filetype:html" nicht gefunden, aber
http://www.example.com/show.php?file=jpegphoto bei "example filetype:php".
Der MIME-Typ spielt für Google zumindest in diesem Zusammenhang keine Rolle.
--
"Keep it simple, as simple as possible, but no simpler."
Albert Einstein
Christoph Päper
Du willst lieber zukünftig etwas erfahrenere Besucher durch ein
irreführendes .html am Ende der URL verwirren als es heute schon ganz
wegzulassen?
Oder verstehe ich dich miss?
--
»Prinzipien, denen man nicht in einer außergewöhnlichen Situation auch einmal
zuwiderhandeln kann, taugen nichts.«
(Unbekannt)
Falko Koepke
> Steffen Schmidt wrote:
>
>
>>h++p://www.floraundfauna.de/gartenkresse.html
>>
>>mod_rewrite machts möglich.
>
>
> Nö. Eine Website gar nicht zu strukturieren, sondern alles ins Root zu
> kippen, ist auch nicht sonderlich elegant. Weder aus der Sicht
> desjenigen, der die Site pflegen muß, noch aus der Sicht des Besuchers,
> der nicht auf Anhieb erkennen kann, in welchen Kontext die Seite
> eingebettet ist, [...]
Du scheinst das URI-rewrite Modul von Apache nicht zu kennen. Dabei hat
Steffen sich ausdrücklich darauf bezogen.
mod_rewrite: <http://httpd.apache.org/docs/mod/mod_rewrite.html> Damit
kannst du intern so viel Struktur in die Seite bringen wie du willst und
für den Besucher die Struktur vortäuschen, die du sinnvoll findest.
> [...] noch in Bezug auf Suchmaschinen, die URL-Teile als
> exponierte Keywords bevorzugt indizieren.
Schlüsselwörter für die Suchmaschine kann man übrigens auch sinnvoller
einbinden als über die URI. Sehr sinnvoll ist es IMHO, einen
aussagekräftigen kurzen Seitentitel zu verwenden. Alternativ kann man
auch mittels SSI <meta>-Tags nur für Suchmaschinenspider in die Seiten
einfügen, die gewöhnliche Webbrowser nicht zu Gesicht bekommen :-)
Gruss
--
Falko Koepke
Konni Scheller
> Möchtest du diese Kommentare an die DI-Mailingliste (www...@w3.org)
> schicken?
Ich bin ja wirklich versucht. Aber ich tue es nicht; mein Englisch ist
nicht gut genug.
Findest Du etwa nicht, dass die Sätze unnötig kompliziert sind?
Servus,
Konni
Konni Scheller
> > Tja. Wenn ich kein HTML ausliefere, dann schreib ich auch nicht .html.
> > Wo ist das Problem?
>
> Ein Problem ist, dass nicht jeder, der HTML ausliefert auch .html schreibt,
> sondern z.B. .php oder .asp.
Auf Apache ließe sich das problemlos einstellen; wie ich hörte, geht das
auf IIS mit .asp nicht.
Das finde ich schlimmer als gar keine Endung, ebenso .pl, .cgi und was
es sonst noch gibt.
> Und bei XHTML .html, .xhtml, .xml, .html.xml, .xml.html, .xhtml.xml,
> .xml.xhtml oder was?
Das ist eine offene Frage :) Im Moment liefere ich "mein" XHTML als html
aus.
> Ich denke, der wichtigste Grundsatz hier ist: »Don't mention the mechanics.«
Punkt für Dich. Reicht das?
> Die auf dem Server verwendeten Techniken sind vollkommen uninteressant und
> ändern sich i.d.R. am ehesten, ergo sollten .php, .asp etc. nie in der URL
> auftauchen.
Zustimmung.
> Der User erwartet, dass Links -- die Ausnahme sind wohl explizite
> Downloadlinks -- sich im Browseranzeigebereich öffnen. Ein .html bringt ihm
> also nichts, weil es sowieso den Normalzustand bedeutet; es schadet
> allerdings auch nicht wirklich, außer dass es länger ist.
Ja.
> Bei <img>-Bildern ist es ebenfalls egal, weil nur die wenigsten Benutzer die
> URL je sehen [..]
Ja.
> Links auf Bilder, PDFs, Officedokumente u.ä.: TXTs, JPEGs und GIFs dürften
> so ziemlich in jeder Browserumgebung anzeigbar sein.
Nein. :) Gerade bei Officedokumenten und PDF würde ich da eher
vorsichtig sein. Txt, JPEG und GIF könnte noch angehen. Aber alles
andere wird ohne Endung schnell unbrauchbar. Außer der Browser fügt beim
Download die Endung hinzu.
> Daneben gibt es für Metainformationen natürlich noch das 'type'-Attribut,
> theoretisch zumindest.
Mimetype, meinst Du wohl.
> Aber das habe ich im Wesentlichen schon vorgestern in
> <news:bpthvg$1dps$1...@ariadne.rz.tu-clausthal.de> geschrieben. Leider gingst
> du in deiner Antwort darauf nur auf einen Link ein, eigentlich nicht mal
> das.
Bei großer Übereinstimmung könnte ich nur "Ja" oder "Zustimmung"
schreiben, siehe oben. Besser so?
Irgendwie suche ich immer noch nach erkennbaren Vorteilen. Ich kann's ja
mal versuchen, aber begeistert vom weggelassenen ".html" bin ich nicht.
Ich werde die Diskussion sicher weiter beobachten und freue mich, wenn
es jemanden gelingt, mich zu überzeugen.
Servus,
Konni
Johannes Koch
> Christoph Päper <crisso...@gmx.net> wrote:
>>Links auf Bilder, PDFs, Officedokumente u.ä.: TXTs, JPEGs und GIFs dürften
>>so ziemlich in jeder Browserumgebung anzeigbar sein.
>
>
> Nein. :) Gerade bei Officedokumenten und PDF würde ich da eher
> vorsichtig sein. Txt, JPEG und GIF könnte noch angehen. Aber alles
> andere wird ohne Endung schnell unbrauchbar. Außer der Browser fügt beim
> Download die Endung hinzu.
Gab es da nicht den Content-Location Header, der dem Browser dabei
helfen könnte?
Konni Scheller
> > Nein. :) Gerade bei Officedokumenten und PDF würde ich da eher
> > vorsichtig sein. Txt, JPEG und GIF könnte noch angehen. Aber alles
> > andere wird ohne Endung schnell unbrauchbar. Außer der Browser fügt beim
> > Download die Endung hinzu.
>
> Gab es da nicht den Content-Location Header, der dem Browser dabei
> helfen könnte?
Könntest Du bitte etwas spezifischer werden?
In wie weit kann ein Content-Location Header dabei helfen, eine Endung
anzufügen? Kannst Du ein Beispiel geben, sagen wir für ein *.doc?
Servus,
Konni
Johannes Koch
URL ist bspw. http://www.server.org/foo
Content-Type: application/msword
Content-Location: http://www.server.org/foo.doc
Könnte dem Browser sagen, dass die ausgelieferte Resource eine
Miscros*ft-Word-Datei ist und eigentlich foo.doc heißt.
Das könnte des Browser dazu veranlassen, sie auch als foo.doc zu speichern.
Christoph Päper
> Christoph Päper wrote:
>
>> Ein Problem ist, dass nicht jeder, der HTML ausliefert auch .html
>> schreibt, sondern z.B. .php oder .asp.
>
Ja, aber da das nicht jeder tut, wird die Bedeutung von .html oder .htm in
der URL verwässert.
>> Der User erwartet, dass Links -- die Ausnahme sind wohl explizite
>> Downloadlinks -- sich im Browseranzeigebereich öffnen. Ein .html bringt
>> ihm also nichts, weil es sowieso den Normalzustand bedeutet; es schadet
>> allerdings auch nicht wirklich, außer dass es länger ist.
>
> URLs werden aber nicht nur als Links im Web verwendet.
Stimmt.
> Wenn mir jemand einen Link auf ein PDF-Dokument schickt, ist es doch
> unnötig zuerst den Browser zu öffnen um danach entweder das Dokument
> zu speichern oder direkt einen PDF Reader zu starten.
Ein Link auf ein PDF-Dokument kann selbstverfreilich auf .pdf enden,
deswegen muss es aber die im HTML verwendete URL noch lange nicht. Bei
Seiten, die Accept-Language für verschiedene Sprachversionen auswerten, kann
man schließlich i.d.R. auch explizit auf eine bestimmte Variante verweisen.
Wenn du weißt, dass unter dem URL eine PDF-Datei zu finden ist, kannst du
sie ja auch dem Acrobat-Reader verfüttern. Andererseits könnte es sein, dass
dem Anbieter zwischenzeitlich bewusst geworden ist, wie unpraktisch das
PDFormat im Web ist und bietet jetzt parallel eine HTML- und eine
MP3-Version an -- alle unter dem gleichen, dir bekannten URL, aber bei
Bedarf auch direkt adressierbar.
Wenn du nicht weißt, was für ein Format hinter einem URL steckt bzw. welche
Formate, zeig sie deinem Browser, er wird dir zumindest eine Variante
präsentieren.
> Leider identifizieren viele verbreitete Betriebssysteme den Datei-Typ
> immer noch anhand der Datei-Endung.
Dazu hat Johannes ja schon was geschrieben. Ob Browser 'Content-Location'
bei »Speichern unter...« etc. benutzen, weiß ich allerdings nicht. Viele
andere Programme sind zumindest intelligent genug, jeweilige
Betriebssystemkonventionen einzuhalten.
> Oder ich organisiere in Zukunft meine Festplatte mit meinem Browser.
Viele KDEler und Windowsianer machen das prinzipiell.
> Nicht alle Betriebssysteme können Metadaten zu den Dateien abspeichern.
BeOS wollte damals bei mir -- und wohl leider zu vielen anderen -- nicht so
recht.
> Gut, wenn ich dir jetzt per Mail die URL http://server/content/datei
> schicke, wo bringe ich dann das type Attribut unter?
Erwischt, da war ich etwas zu HTML-fixiert. Nichtsdestotrotz gibt es ja auch
noch zig menschliche Sprachen, von denen wir beide mindestens eine
gemeinsame sprechen, also könntest du es mir auf diesem Wege mitteilen, wenn
es denn von Bedeutung ist.
--
"Just because something doesn't do what you planned it to do
doesn't mean it's useless."
Thomas Alva Edison
Konni Scheller
> URL ist bspw. http://www.server.org/foo
>
> Content-Type: application/msword
> Content-Location: http://www.server.org/foo.doc
>
> Könnte dem Browser sagen, dass die ausgelieferte Resource eine
> Miscros*ft-Word-Datei ist und eigentlich foo.doc heißt.
>
> Das könnte des Browser dazu veranlassen, sie auch als foo.doc zu speichern.
Danke. Jetzt ist es klarer. Das RFC habe ich (wieder mal) nicht
verstanden ;-)
Du sagst aber bewusst "Könnte". Wie sieht es mit der Unterstützung durch
die Browser aus?
Grüße,
Konni
Konni Scheller
> Ein Link auf ein PDF-Dokument kann selbstverfreilich auf .pdf enden,
> deswegen muss es aber die im HTML verwendete URL noch lange nicht.
Nur, wenn man es lokal speichern will.
> Wenn du nicht weißt, was für ein Format hinter einem URL steckt bzw. welche
> Formate, zeig sie deinem Browser, er wird dir zumindest eine Variante
> präsentieren.
Das ist eben die Grundidee hinter dem Ganzen, soweit ich das verstanden
habe.
> > Leider identifizieren viele verbreitete Betriebssysteme den Datei-Typ
> > immer noch anhand der Datei-Endung.
>
> Dazu hat Johannes ja schon was geschrieben. Ob Browser 'Content-Location'
> bei »Speichern unter...« etc. benutzen, weiß ich allerdings nicht. Viele
> andere Programme sind zumindest intelligent genug, jeweilige
> Betriebssystemkonventionen einzuhalten.
Tja, das was bei Apple mal *war* (Metadaten zum File), könnte die Sache
jetzt sehr vereinfachen.
Servus,
Konni
Christoph Schneegans
> URL ist bspw. http://www.server.org/foo
>
> Content-Type: application/msword
> Content-Location: http://www.server.org/foo.doc
>
> Könnte dem Browser sagen, dass die ausgelieferte Resource eine
> Miscros*ft-Word-Datei ist und eigentlich foo.doc heißt.
>
> Das könnte des Browser dazu veranlassen, sie auch als foo.doc zu
> speichern.
Dateierweiterungen sind im "Content-Location"-Header genauso
irrelevant wie in URLs. Ein vernünftiger Browser _muß_ sich sich den
"Content-Type"-Header anschauen und die Ressource mit der Erweiterung
speichern, die auf dem betreffenden System für den MIME-Typ
registriert ist, oder den MIME-Typ sonst irgendwie mit der Datei
verknüpfen. IE und Mozilla tun das zum Glück ja auch, wie wir in
<http://groups.google.com/groups?threadm=1k3pfvkjqj10da4madur9gg5o0luo51hdk%404ax.com>
gesehen haben.
--
<http://schneegans.de/> |
Dave Kliczbor
Robert Sedlacek wrote:
> Leider identifizieren viele verbreitete Betriebssysteme den Datei-Typ
> immer noch anhand der Datei-Endung.
BeFS (oder BFS) hiess das Dateisystem glaub ich, wo der MIME-Type direkt
als Dateiattribut mit abgespeichert wird...
cya
Dave KLiczbor, mal wieder BeOS ausprobieren wollend...
--
WinError: 010 Reserved for future mistakes by our developers
Gabriele Jesdinsky
>Du willst lieber zukünftig etwas erfahrenere Besucher durch ein
>irreführendes .html am Ende der URL verwirren als es heute schon ganz
>wegzulassen?
Ich dachte eben bisher, der normale Besucher könnte durch das
Weglassen verwirrt werden:
Einen URL ohne Erweiterung halte jedenfalls ich eigentlich für ein
Verzeichnis oder allenfalls eine Index-/Menü-Seite.
Vielleicht bin ich aber auch nur allergisch gegen erweiterungslose
Namen, denn ich ärgere mich seit Jahren, dass ich nach jeder
Windows-Installation als erstes umständlich die Dateityp-Ausblendungen
für den Windows-Explorer in den Ordner-Optionen deaktivieren muss.
Ich will *vor* dem Anklicken erkennen, was ich vor mir habe, und nicht
nur durch Erraten der Bedeutung von Icons
(deren Aussehen dank des besonders intelligenten WinXP-Designers
neuerdings auch noch gerne wechselt...)
Gruß Gabi
Joachim Wiesemann
> Christoph Päper <crisso...@gmx.net> wrote:
>
>> > Tja. Wenn ich kein HTML ausliefere, dann schreib ich auch nicht .html.
>> > Wo ist das Problem?
>>
>> Ein Problem ist, dass nicht jeder, der HTML ausliefert auch .html schreibt,
>> sondern z.B. .php oder .asp.
>
> Auf Apache ließe sich das problemlos einstellen; wie ich hörte, geht das
> auf IIS mit .asp nicht.
(Auch gleich ein Beispiel, warum man URLs nicht so schreiben sollte)
Viele Grüße
Joachim
--
Dr. Joachim Wiesemann
http://www.bestviewed.de/ Seiten über Webdesign und Usability
http://jwiesemann.com/ Ingenieurdienstleistungen, Usabilityberatung
"Die schärfsten Kritiker der Elche waren früher selber welche!"
Joachim Wiesemann
Schlecht: Ich habe vor längerer Zeit meinem Win98 mal beigebogen, daß
octet-stream an den realplyaer geschickt werden soll, weil ich einige
Filmchem sonst nicht angezeigt bekam. Leider hängt er jetzt bei jedem
Download einer .exe-Datei ein .rm hinten an. Und ich weiß nicht mehr, wo
ich das abstellen kann.
Roger Schuster
Hi,
> Einen URL ohne Erweiterung halte jedenfalls ich eigentlich für ein
> Verzeichnis oder allenfalls eine Index-/Menü-Seite.
Das geht mir genauso. Ich will schon anhand des URLs erkennen können, um
welchen Typ es sich bei einer Ressource handelt, damit ich vorab sagen
kann, was beim Anklicken eines Links passieren wird. Ich bevorzuge
daher, Dateien mit Erweiterung anzugeben und Verweise auf Verzeichnisse
mit einem Slash abzuschließen.
> Namen, denn ich ärgere mich seit Jahren, dass ich nach jeder
> Windows-Installation als erstes umständlich die Dateityp-Ausblendungen
> für den Windows-Explorer in den Ordner-Optionen deaktivieren muss.
Mache ich auch immer. Zum Glück muss man das seit XP nicht mehr ganz so
oft machen wie früher. :-)
Roger
--
Bitte nur in der Newsgroup antworten! Mails landen ungelesen in der Tonne.
Christoph Päper
>
> Ich dachte eben bisher, der normale Besucher könnte durch das
> Weglassen verwirrt werden:
Die Erfahrenen und die Unerfahrenen nicht, höchstens die dazwischen -- ohne
dir jetzt zu nahe treten zu wollen.
> Einen URL ohne Erweiterung halte jedenfalls ich eigentlich für ein
> Verzeichnis oder allenfalls eine Index-/Menü-Seite.
Selbst ohne / am Ende?
> Vielleicht bin ich aber auch nur allergisch gegen erweiterungslose
> Namen, denn ich ärgere mich seit Jahren, dass ich nach jeder
> Windows-Installation als erstes umständlich die Dateityp-Ausblendungen
> für den Windows-Explorer in den Ordner-Optionen deaktivieren muss.
Guck, und ich ärgere mich, dass einige Programme ständig ungefragt die mit
den Erweiterungen assoziierten Beschreibungen anpassen, denn nach denen kann
ich, wenn sie entsprechend gewählt sind, im Explorer so sortieren, dass
ähnliche Dateien (z.B. PNG- und GIF-Bilder) beieinander stehen.
> Ich will *vor* dem Anklicken erkennen, was ich vor mir habe,
Was bei manchen URLs schon prinzipedingt nicht geht und bei manch anderen
zukünftig der Fall sein könnte.
> und nicht nur durch Erraten der Bedeutung von Icons
Ich suche schon länger immer mal wieder recht erfolglos nach einer möglichst
umfangreichen, einheitlichen, schönen und erkennbaren Iconsammlung für
Dateitypen und einem einfachen Weg sie trotz übereifriger
(Installations-)Programme fix zu halten.
--
"Problems cannot be solved at the same level of awareness that created them."
Albert Einstein
Christoph Päper
>
> Ich will schon anhand des URLs erkennen können, um
> welchen Typ es sich bei einer Ressource handelt,
Wenn explizit auf die HTML-Version einer Ressource gelinkt werden soll,
spricht auch wenig(er) gegen ein .html am Ende.
Ansonsten ist es im Browser egal, weil er i.d.R. ohnehin HTML bekommen
wird.
--
In der Theorie sind Theorie und Praxis dasselbe. In der Praxis nicht.
Alexander Clauss
> Die Erfahrenen und die Unerfahrenen nicht, höchstens die dazwischen -- ohne
Naja, "die dazwischen" dürfte eigentlich die größte Gruppe der Anwender
sein. Wenige kennen sich wirklich aus, wenige gar nicht, der Rest liegt
eben irgendwo dazwischen...
> > Einen URL ohne Erweiterung halte jedenfalls ich eigentlich für ein
> > Verzeichnis oder allenfalls eine Index-/Menü-Seite.
>
> Selbst ohne / am Ende?
Für die Leute "dazwischen" (siehe oben ;-) ist das tatsächlich ein
Problem. Zumal meist ja ein Server ein vergessenes "/" am Ende der URL
gnädigerweise dennoch ohne Murren verarbeitet.
--
Alexander
Konni Scheller
> > Einen URL ohne Erweiterung halte jedenfalls ich eigentlich für ein
> > Verzeichnis oder allenfalls eine Index-/Menü-Seite.
>
> Selbst ohne / am Ende?
ja, klar. Immerhin ergänzen die meisten Server eher ein "/" als ein
".html", wenn nix dabei steht.
> Guck, und ich ärgere mich, dass einige Programme ständig ungefragt die mit
> den Erweiterungen assoziierten Beschreibungen anpassen, denn nach denen kann
> ich, wenn sie entsprechend gewählt sind, im Explorer so sortieren, dass
> ähnliche Dateien (z.B. PNG- und GIF-Bilder) beieinander stehen.
Das ist aber ein Problem des Systems und nicht der
Dateinamenerweiterungen.
> > Ich will *vor* dem Anklicken erkennen, was ich vor mir habe,
>
> Was bei manchen URLs schon prinzipedingt nicht geht
Du meinst solche *ohne* Endung?
> und bei manch anderen
> zukünftig der Fall sein könnte.
Wenn sie doch wieder eine Endung haben?
> Ich suche schon länger immer mal wieder recht erfolglos nach einer möglichst
> umfangreichen, einheitlichen, schönen und erkennbaren Iconsammlung für
> Dateitypen und einem einfachen Weg sie trotz übereifriger
> (Installations-)Programme fix zu halten.
Nimm einen Mac :-)
Servus
Konni
Konni Scheller
> > Auf Apache ließe sich das problemlos einstellen; wie ich hörte, geht das
> > auf IIS mit .asp nicht.
>
> Doch, geht:
Warum tut's nur dann keiner, M$ eingeschlossen...?
Servus,
Konni
Joachim Wiesemann
Warum benutzt jemand IIS?
Fragen über Fragen.
Viele Grüße
Joachim, sinnend
Christoph Päper
> Christoph Päper <crisso...@gmx.net> wrote:
>
>>> Einen URL ohne Erweiterung halte jedenfalls ich eigentlich für ein
>>> Verzeichnis oder allenfalls eine Index-/Menü-Seite.
>>
>> Selbst ohne / am Ende?
>
> ja, klar. Immerhin ergänzen die meisten Server eher ein "/" als ein
> ".html", wenn nix dabei steht.
Selbst wenn, wer sagt euch denn, was für ein Format ihr unter
example.com/foo/, example.com/foo.php oder example.com/ bekommt?
>>> Ich will *vor* dem Anklicken erkennen, was ich vor mir habe,
>>
>> Was bei manchen URLs schon prinzipedingt nicht geht
>
> Du meinst solche *ohne* Endung?
Nein, ich meinte wiederum Content-Negotiation-URLs. Bei denen kannst,
brauchst und sollst du nicht erkennen, was genau du bekommst.
Wie in einem anderen Posting gesagt, könnte man bspw. allen Bilddateien
gleich welchen Typs eine gemeinsame Endung (.foto, .bild, .img, .pic, ...)
verpassen, die mehr oder weniger erkennbar macht, um was für eine Gruppe von
Typen es sich handelt. Das hat dann also wie gewünscht eine Endung, aber man
sieht noch immer nicht genau, was man vor sich hat. Auf ein bestimmtes
Format kann ich /bei Bedarf/ natürlich immer noch verweisen, z.B.
acme-logo.sxga.img.tiff.cmyk.de.2003.
(Leider können die Erweiterungen bei Apache nicht in beliebiger Reihenfolge
stehen, weswegen man sich für ein den eigenen Anforderungen am besten
gerecht werdendes Schema entscheiden muss. Mit mod_rewrite oder
vergleichbaren Lösungen ist es, entsprechende serverskriptseitige Auswertung
vorausgesetzt, egal.)
>> und bei manch anderen zukünftig der Fall sein könnte.
>
> Wenn sie doch wieder eine Endung haben?
Wenn auf einmal mehr als eine Variante oder eine neue, andersartige einzige
unter dem URL zu finden ist.
>> umfangreichen, einheitlichen, schönen und erkennbaren Iconsammlung
>
> Nimm einen Mac :-)
Habe ich seit OSX schon fast ernsthaft drüber nachgedacht. OTOH habe ich
mich an meinen PC nach 5 Jahren irgendwie gewöhnt, obwohl außer Mainboard,
CPU, Systemfestplatte und TV-Karte bereits alles wenigstens einmal
ausgetauscht oder erweitert worden ist. Wenn der IDE-Controller die zweite
Festplatte nicht bald wieder im DMA-Modus laufen lässt, wäre aber sowieso
mal wieder ein Update fällig; eigentlich war dafür der erst
anderthalbjährige Monitor geplant.
--
"Is IE committed to implementing standard X in the future?" [MS IE FAQ]
MS is committed to implementing the Internet standards that make sense
to allow our customers to build great solutions. As standards emerge, we
evaluate them to see which standards might best serve our customers' needs.
Christoph Päper
>
> Warum benutzt jemand IIS?
Aus dem gleichen Grund, aus dem er Hemd und Krawatte trägt?
--
»Lass dich nur zu keiner Zeit zum Widerspruch verleiten:
Weise verfallen in Unwissenheit, wenn sie mit Unwissenden streiten.«
Johann Wolfgang von Goethe
Konni Scheller
> Selbst wenn, wer sagt euch denn, was für ein Format ihr unter
> example.com/foo/, example.com/foo.php oder example.com/ bekommt?
Unter (1) bekommst Du einen 404er, unter (2) ebenfalls, unter (3)
bekommst Du text/html. ;-)
Im Regelfall bekommst Du sauberes, pures HTML :-) Naja. Ob es so sauber
ist, sei dahingestellt.
R.S:
> >>> Ich will *vor* dem Anklicken erkennen, was ich vor mir habe,
> Nein, ich meinte wiederum Content-Negotiation-URLs. Bei denen kannst,
> brauchst und sollst du nicht erkennen, was genau du bekommst.
Das ist aber genau das, was ich möchte. Ich möchte wissen, *was* ich
bekomme. Ich habe etwas dagegen, wenn bei mir auf meiner 300 MHz Mühle
das Adobe Acrobat Reader Plugin selbständig startet, weil das eine gute
Minute dauert. Ich mag es nicht, wenn wegen eines PNG das
Quicktime-Plugin aktiv wird. Und schon gar hasse ich es, wenn Word
gestartet wird, weil ein server meint, mir ein *.doc unterschieben zu
müssen.
> Wie in einem anderen Posting gesagt, könnte man bspw. allen Bilddateien
> gleich welchen Typs eine gemeinsame Endung (.foto, .bild, .img, .pic, ...)
> verpassen, die mehr oder weniger erkennbar macht, um was für eine Gruppe von
> Typen es sich handelt.
Nett. Aber die Zeit dafür ist IMHO noch nicht reif.
> Wenn der IDE-Controller die zweite
> Festplatte nicht bald wieder im DMA-Modus laufen lässt, wäre aber sowieso
> mal wieder ein Update fällig; eigentlich war dafür der erst
> anderthalbjährige Monitor geplant.
Ich hab ehrlich gesagt fast kein Wort verstanden. Bin wohl doch ein
typischer Mac-User. :-)
Servus,
Konni
Thomas Scholz
> Schlecht: Ich habe vor längerer Zeit meinem Win98 mal beigebogen, daß
> octet-stream an den realplyaer geschickt werden soll, weil ich einige
> Filmchem sonst nicht angezeigt bekam. Leider hängt er jetzt bei jedem
> Download einer .exe-Datei ein .rm hinten an.
"Er"? Wer? Dein Browser? Der Realplayer? Der Downloadgnom?
Thomas
Joachim Wiesemann
Der Mozilla.
Lars Kasper
> mod_rewrite: <http://httpd.apache.org/docs/mod/mod_rewrite.html> Damit
> kannst du intern so viel Struktur in die Seite bringen wie du willst und
> für den Besucher die Struktur vortäuschen, die du sinnvoll findest.
Wieso sollte man eine sinnvolle Struktur nur vortäuschen und nicht
direkt verwirklichen?
> Schlüsselwörter für die Suchmaschine kann man übrigens auch sinnvoller
> einbinden als über die URI. Sehr sinnvoll ist es IMHO, einen
> aussagekräftigen kurzen Seitentitel zu verwenden.
Der darf auch länger sein.
> Alternativ kann man
> auch mittels SSI <meta>-Tags nur für Suchmaschinenspider in die Seiten
> einfügen, die gewöhnliche Webbrowser nicht zu Gesicht bekommen :-)
Aha, ein Suchmaschinenoptimierer (vielleicht wird das mal ein ähnliches
Schimpfwort wie Webdesigner). Wieso sollten Description-Meta-Angaben nur
für Spider sein? Die kann man doch direkt in die Seite schreiben, da muß
man doch nichts verstecken. Und Keywords-Meta-Angaben werden eh
ignoriert.
Thomas Scholz
> Falko Koepke schrieb:
>
>> mod_rewrite: <http://httpd.apache.org/docs/mod/mod_rewrite.html> Damit
>> kannst du intern so viel Struktur in die Seite bringen wie du willst
>> und für den Besucher die Struktur vortäuschen, die du sinnvoll findest.
>
> Wieso sollte man eine sinnvolle Struktur nur vortäuschen und nicht
> direkt verwirklichen?
Die Struktur, die für die Besucher sinnvoll ist, muß nicht auch zugleich
für die eigene Verwaltung die beste sein.
Thomas