Hallo,

gibt es entscheidende Argumente von XHTML ggü. HTML? Wenn ja, welche?

Danke

Chris Seidel schrieb:

> gibt es entscheidende Argumente von XHTML ggü. HTML?

<http://schneegans.de/web/xhtml/#xhtml-oder-html>

-- 
<http://schneegans.de/usenet/mids/> · Postings verlinken

Hallo

Chris Seidel schrieb:
> 
> gibt es entscheidende Argumente von XHTML ggü. HTML?

Die entscheidende Frage lautet: "strict oder transitional?"

Gruß
Irmgard

On Fri, 26 Mar 2010 08:58:39 +0100, Irmgard Schwenteck   
wrote:

> Die entscheidende Frage lautet: "strict oder transitional?"

Wo ist da bei XHTML der entscheidene Unterschied?

Chris Seidel schrieb:
> On Fri, 26 Mar 2010 08:58:39 +0100, Irmgard Schwenteck 
>  wrote:
> 
>> Die entscheidende Frage lautet: "strict oder transitional?"
> 
> Wo ist da bei XHTML der entscheidene Unterschied?

Bei XHTML 1.0 ist da im wesentlichen der gleiche Unterschied wie bei 
HTML 4.01.

-- 
Johannes Koch
In te domine speravi; non confundar in aeternum.
                             (Te Deum, 4th cent.)

On Fri, 26 Mar 2010 09:27:17 +0100, Johannes Koch   
wrote:

>>> Die entscheidende Frage lautet: "strict oder transitional?"
>>  Wo ist da bei XHTML der entscheidene Unterschied?
>
> Bei XHTML 1.0 ist da im wesentlichen der gleiche Unterschied wie bei  
> HTML 4.01.

OK, bei HTML benutze ich immer strict.

Irmgard Schwenteck schrieb:

> Die entscheidende Frage lautet: "strict oder transitional?"

Das ist nicht die entscheidende Frage, sondern überhaupt keine
Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
XHTML 1.0 Transitional.

-- 
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML

Christoph Schneegans wrote:

> Irmgard Schwenteck schrieb:
>> Die entscheidende Frage lautet: "strict oder transitional?"
> 
> Das ist nicht die entscheidende Frage, sondern überhaupt keine
> Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
> XHTML 1.0 Transitional.

Das möchtest Du belegen.


PointedEars

Thomas 'PointedEars' Lahn schrieb:

>> (...) es gibt keine Gründe für HTML 4.01 Transitional oder
>> XHTML 1.0 Transitional.
>
> Das möchtest Du belegen.

Ich soll eine Existenzaussage falsifizieren, schon klar.

-- 
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML

Christoph Schneegans schrieb:
> 
>> Die entscheidende Frage lautet: "strict oder transitional?"
> 
> Das ist nicht die entscheidende Frage, sondern überhaupt keine
> Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
> XHTML 1.0 Transitional.

Du meinst, die Welt ist schon soweit, daß es selbstverständlich ist, bei 
(X)HTML immer "strict" vorauszusetzen, so daß sich die Frage eigentlich 
überhaupt nicht stellt?

BTW: Gibt es bei anderen auch schon die Anforderung, Webseiten mit 
Sharepoint erstellen zu wollen?
Ich finde den entstehenden Verhau ziemlich gruselig, aber es soll 
angeblich Zukunft sein.

Gruß
Irmgard

Am 26.03.2010 10:33, schrieb Christoph Schneegans:

> Das ist nicht die entscheidende Frage, sondern überhaupt keine
> Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
> XHTML 1.0 Transitional.

Wenn es keine Gründe gäbe, hätte man es nicht spezifiziert. :P

In der Realität gibt es nun einmal eine grosse Zahl von Dokumenten, die 
nach älteren Spezifikationen erstellt wurden, und die man weder über 
Nacht wegwerfen, noch (aus Kosten- und Zeitgründen) sofort vollständig 
überarbeiten kann.

Hergen Lehmann schrieb:

>> Das ist nicht die entscheidende Frage, sondern überhaupt keine
>> Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
>> XHTML 1.0 Transitional.
>
> Wenn es keine Gründe gäbe, hätte man es nicht spezifiziert. :P

Spezifiziert wurde es vor über zehn Jahren. Inzwischen haben die
Browser CSS gelernt.

> In der Realität gibt es nun einmal eine grosse Zahl von
> Dokumenten, die nach älteren Spezifikationen erstellt wurden,
> und die man weder über Nacht wegwerfen, noch (aus Kosten- und
> Zeitgründen) sofort vollständig überarbeiten kann.

Das hat auch niemand gefordert.

-- 
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML

Es schrieb Christoph Schneegans:

>>> (...) es gibt keine Gründe für HTML 4.01 Transitional oder
>>> XHTML 1.0 Transitional.
>>
>> Das möchtest Du belegen.
>
> Ich soll eine Existenzaussage falsifizieren, schon klar.

Einfach mal so zum Thema:

http://de.wikipedia.org/wiki/Falsifikationismus

Grüße, Matthias

On 26.03.2010 10:33, Christoph Schneegans wrote:
> Irmgard Schwenteck schrieb:
> 
>> Die entscheidende Frage lautet: "strict oder transitional?"
> 
> Das ist nicht die entscheidende Frage, sondern überhaupt keine
> Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
> XHTML 1.0 Transitional.

es kann leider unter bestimmten Umständen einen geben. :-( Leider hat
man beim Entfernen des ganzen darstellungsrelevanten Mülls auch das
start-Attribut bei <ol> mit entsorgt und in manchen Szenarien braucht es
das. Auch dann tendiere ich aber dazu strict zu verwenden und den
begründbaren Validierungsfehler in Kauf zu nehmen.

Gruß
Susanne

On 26.03.2010 11:02, Irmgard Schwenteck wrote:
> Christoph Schneegans schrieb:

>> Das ist nicht die entscheidende Frage, sondern überhaupt keine
>> Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
>> XHTML 1.0 Transitional.
> 
> Du meinst, die Welt ist schon soweit, daß es selbstverständlich ist, bei 
> (X)HTML immer "strict" vorauszusetzen, so daß sich die Frage eigentlich 
> überhaupt nicht stellt?

Für *neue* Dokumente bin ich ausser dem genannten ol-Start Problem nicht
geneigt etwas anderes zu akzeptieren. Entwicklungswerkzeuge die den
alten Mist einbauen sollte man tunlichst nicht mehr verwenden.
Im Zweifelsfall entscheidet selbstverständlich der Kunde und ich habe
auch schon unter Protest target eingebaut, aber die Frage was man
verwenden *sollte* stellt sich IMHO wirklich schon lange nicht mehr.

Gruß
Susanne

On Fri, 26 Mar 2010, Christoph Schneegans wrote:

> es gibt keine Gründe für HTML 4.01 Transitional oder XHTML 1.0 Transitional.

<ol start="2">

-- 
In memoriam Alan J. Flavell
http://www.alanflavell.org.uk/charset/

Andreas Prilop schrieb:

>> es gibt keine Gründe für HTML 4.01 Transitional oder XHTML 1.0
>> Transitional.
>
> <ol start="2">

Wenn die Zahlen wichtig sind, dann gehören sie ohnehin fix ins
Dokument:

  <h1>2. Foobar</h1>

-- 
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML

Christoph Schneegans wrote:

> Thomas 'PointedEars' Lahn schrieb:
>>> (...) es gibt keine Gründe für HTML 4.01 Transitional oder
>>> XHTML 1.0 Transitional.
>> Das möchtest Du belegen.
> 
> Ich soll eine Existenzaussage falsifizieren, schon klar.

Du solltest Deine Meinung/Behauptung mit einer Argumentation untermauern.  
Andernfalls müsste man sie zwar tolerieren, bräucht sie aber nicht 
ernstzunehmen.  Denn nur weil jemand etwas meint/behauptet, ist es noch 
lange nicht wahr.

<http://de.wikipedia.org/wiki/Diskussion#Diskussionsstile>
<http://en.wikipedia.org/wiki/Bare_assertion_fallacy>

-- 
PointedEars

Hergen Lehmann wrote:

> Am 26.03.2010 10:33, schrieb Christoph Schneegans:
>> Das ist nicht die entscheidende Frage, sondern überhaupt keine
>> Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
>> XHTML 1.0 Transitional.
> 
> Wenn es keine Gründe gäbe, hätte man es nicht spezifiziert. :P
> 
> In der Realität gibt es nun einmal eine grosse Zahl von Dokumenten, die
> nach älteren Spezifikationen erstellt wurden, und die man weder über
> Nacht wegwerfen, noch (aus Kosten- und Zeitgründen) sofort vollständig
> überarbeiten kann.

Auch neue Dokumente benötigen mitunter die Transitional-Variante, um gültig 
zu sein.  Transitional ist nicht nur eine Frage der Rückwärtskompatibilität.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

Thomas 'PointedEars' Lahn wrote:

> Auch neue Dokumente benötigen mitunter die Transitional-Variante, um
> gültig zu sein.

Stellt sich die Frage, ob es möglich wäre, äquivalente Dokumente in strict
zu erstellen. Wenn ja, ist das genannte Argument nicht schlüssig, denn es
begründet nicht, daß transitional existieren /muß/. 


vG

-- 
      It takes a village to raise a child. (Afrikanisches Sprichwort)

-- <http://einklich.net> -- Ein Pinguin für jeden: <http://debian.org/> --

"Christoph Schneegans"  writes:

> Andreas Prilop schrieb:
>
>>> es gibt keine Gründe für HTML 4.01 Transitional oder XHTML 1.0
>>> Transitional.
>>
>> <ol start="2">
>
> Wenn die Zahlen wichtig sind, dann gehören sie ohnehin fix ins
> Dokument:
>
>   <h1>2. Foobar</h1>

Das kann die Wartung aufwändig und fehleranfällig machen.


   Florian
-- 
<http://www.florian-diesch.de/grundgesetz.html>

On Fri, 26 Mar 2010 11:33:24 퍭, Christoph Schneegans   wrote:

> Irmgard Schwenteck schrieb:
>
>> Die entscheidende Frage lautet: "strict oder transitional?"
>
> Das ist nicht die entscheidende Frage, sondern überhaupt keine
> Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
> XHTML 1.0 Transitional.


Ich habe jetzt dieses XHTML:


<?xml version="1.0" encoding="UTF-8"?>
<html>
	<head>
		<meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
		<link href="/static/images/favicon.ico" rel="SHORTCUT ICON"/>
		<link href="/static/styles/cs.css" type="text/css" rel="stylesheet"/>
		<script src="/static/scripts/cs.js" type="text/javascript"/>
	</head>
	<body>

...



Opera 10.51 und Chrome 4 zeigen das an, FF 3 und IE 7 zeigen nur eine  leere Seite an.
Ist hier bei der Deklaration was falsch?

Danke

Chris Seidel wrote:

> Ich habe jetzt dieses XHTML:
> 
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <html>

XHTML-Elemente sind im Namensraum http://www.w3.org/1999/xhtml, du 
solltest also
   <html xmlns="http://www.w3.org/1999/xhtml">
verwenden, wenn das XHTML sein soll.

>     <head>
>         <meta content="text/html; charset=UTF-8" 
> http-equiv="Content-Type"/>
>         <link href="/static/images/favicon.ico" rel="SHORTCUT ICON"/>
>         <link href="/static/styles/cs.css" type="text/css" 
> rel="stylesheet"/>
>         <script src="/static/scripts/cs.js" type="text/javascript"/>

So du XHTML als text/html ausliefern willst, was das meta-Element 
suggeriert, solltest du dich an die Regeln in 
http://www.w3.org/TR/xhtml1/#guidelines halten, also die leeren Elemente 
wie meta und link mit
   <meta />
bzw.
   <link />
schliessen und das script-Element per
   <script src="/static/scripts/cs.js" type="text/javascript"></script>
Nur wenn du ein XHTML per XML-Parser parsen lässt, spielt es keine 
Rolle, ob man
   <meta/>
oder
   <meta />
oder
   <meta></meta>
nimmt oder
   <script/>
oder
   <script />
oder
   <script></script>


> Opera 10.51 und Chrome 4 zeigen das an, FF 3 und IE 7 zeigen nur eine 
> leere Seite an.
> Ist hier bei der Deklaration was falsch?

Poste mal eine URL.


-- 

	Martin Honnen
	http://msmvps.com/blogs/martin_honnen/

On 28.03.2010 11:31, Chris Seidel wrote:

> Ich habe jetzt dieses XHTML:
> 
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <html>
> 	<head>
> 		<meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
> 		<link href="/static/images/favicon.ico" rel="SHORTCUT ICON"/>
> 		<link href="/static/styles/cs.css" type="text/css" rel="stylesheet"/>
> 		<script src="/static/scripts/cs.js" type="text/javascript"/>
> 	</head>
> 	<body>
> 
> ...

du solltest den verwendeten Doctype angeben.[1] Sofern du das Dokument
als text/html auslieferst kannst du dir dafür den XML-Prolog auch
sparen, der wird sowieso ignoriert.

> Opera 10.51 und Chrome 4 zeigen das an, FF 3 und IE 7 zeigen nur eine  
> leere Seite an.

URL? Der Schnipsel alleine sagt nicht genug.

Gruß
Susanne

[1] DOCTYPE-Switch und seine Auswirkungen
<http://carsten-protsch.de/zwischennetz/doctype/>

Volker Gringmuth wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Auch neue Dokumente benötigen mitunter die Transitional-Variante, um
>> gültig zu sein.
> 
> Stellt sich die Frage, ob es möglich wäre, äquivalente Dokumente in strict
> zu erstellen. Wenn ja, ist das genannte Argument nicht schlüssig, denn es
> begründet nicht, daß transitional existieren /muß/.

1. Diese Aussage ist richtig.
2. [dsf 6.5]


PointedEars
-- 
xOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)   // Plone, register_function.js:16

Am Sun, 28 Mar 2010 12:31:59 +0300 schrieb Chris Seidel:

> 		<script src="/static/scripts/cs.js" type="text/javascript"/>

Ohne es ausprobiert zu haben, würde ich hier Probleme vermuten. Würde ich
lieber in <script *></script> auflösen.

Generell wird oft empfohlen, niemals nicht <abc/>, sondern <abc /> zu
schreiben, also mit Leerzeichen; Hintergrund soll die verbesserte
Kompatibilität sein.

Am Fri, 26 Mar 2010 10:33:24 +0100 schrieb Christoph Schneegans:

> Das ist nicht die entscheidende Frage, sondern überhaupt keine
> Frage, denn es gibt keine Gründe für HTML 4.01 Transitional oder
> XHTML 1.0 Transitional.

Wie baue ich denn in ein Strict-Dokument sowas wie
<a href="xxx" target="_blank">
ein, sodass es validiert?

On 28.03.2010 13:34, Alex Prahl wrote:

> Wie baue ich denn in ein Strict-Dokument sowas wie
> <a href="xxx" target="_blank">
> ein, sodass es validiert?

Am besten gar nicht. Das Öffnen neuer Fenster sollte dem Nutzer
vorbehalten bleiben - erst recht im Zeitalter von tabbed browsing.
Abgesehen davon ist es nicht Inhalt - Markup sondern Verhalten -
Scripting, gehört also auch theoretisch nicht ins (X)HTML.

Gruß
Susanne

Chris Seidel schrieb:

> <?xml version="1.0" encoding="UTF-8"?>
> <html>
>     <head>
>         <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
>         <link href="/static/images/favicon.ico" rel="SHORTCUT ICON"/>
>         <link href="/static/styles/cs.css" type="text/css" rel="stylesheet"/>
>         <script src="/static/scripts/cs.js" type="text/javascript"/>
>     </head>
>     <body>

Da sind gleich drei Fehler, die dir <http://schneegans.de/sv/>
unmittelbar angezeigt hätte:

• Die Namensraumdeklaration xmlns="http://www.w3.org/1999/xhtml"
  fehlt.
• Das "title"-Element fehlt.
• Das Inhaltsmodell des "script"-Elements ist nicht leer, also darf
  es gemäß den HTML-Kompatibilitätsrichtlinien nicht mit einem
  Leerelement-Tag notiert werden.

-- 
<http://schneegans.de/usenet/mids/> · Postings verlinken

Am Sun, 28 Mar 2010 14:27:58 +0200 schrieb Susanne Jäger:

> On 28.03.2010 13:34, Alex Prahl wrote:
> 
>> Wie baue ich denn in ein Strict-Dokument sowas wie
>> <a href="xxx" target="_blank">
>> ein, sodass es validiert?
> 
> Am besten gar nicht. Das Öffnen neuer Fenster sollte dem Nutzer
> vorbehalten bleiben -

Soweit die Theorie. Die Praxis sieht ganz anders aus. Und damit meine ich
nicht nur, dass oft gewünscht wird, dass externe Seiten nicht das eigene
Angebot schließt, sondern auch rein praktische Dinge. Denn die Erfahrung
lehrt, dass viele User (wenn nicht sogar die Mehrheit) die
"Zurück"-Funktion des Browsers nicht kennen, und somit aus dem gerade
geöffneten PDF-Dokument nicht mehr auf die Webseite zurückfinden :-(

> Abgesehen davon ist es nicht Inhalt - Markup sondern Verhalten -
> Scripting, gehört also auch theoretisch nicht ins (X)HTML.

Praktisch aber schon. Und das geht standardkonform im Strict eben nicht,
weswegen man Transitional oder Javascript benötigt, wobei letzteres auch
nur getrickst ist und nicht zwangsläufig funktioniert.

Thomas 'PointedEars' Lahn schrieb:

> Du solltest Deine Meinung/Behauptung mit einer Argumentation
> untermauern.  Andernfalls müsste man sie zwar tolerieren, bräucht
> sie aber nicht ernstzunehmen.

Das typische Gefasel mal wieder. Wenn du Argumente hättest, würdest
du sie einfach nennen.

-- 
<http://schneegans.de/usenet/gold-posting/> · Wie man falsch postet

Alex Prahl schrieb:

> Denn die Erfahrung lehrt, dass viele User (wenn nicht sogar die
> Mehrheit) die "Zurück"-Funktion des Browsers nicht kennen,

Lächerlich. "The Back button is ... the second-most used navigation
feature", schrieb Nielsen schon vor 10 Jahren.

> und somit aus dem gerade geöffneten PDF-Dokument nicht mehr auf
> die Webseite zurückfinden :-(

Man zeigt PDF-Dokumente ja auch nicht im Browser an.

-- 
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML

On 28.03.2010 14:34, Alex Prahl wrote:
> Am Sun, 28 Mar 2010 14:27:58 +0200 schrieb Susanne Jäger:

> Soweit die Theorie. Die Praxis sieht ganz anders aus. Und damit meine ich
> nicht nur, dass oft gewünscht wird, dass externe Seiten nicht das eigene
> Angebot schließt, sondern auch rein praktische Dinge. Denn die Erfahrung
> lehrt, dass viele User (wenn nicht sogar die Mehrheit) die
> "Zurück"-Funktion des Browsers nicht kennen, 

was zu beweisen wäre. Und ob der Focuswechsel und die hundert geöffneten
Fenster für den gemeinen Websurfer wirklich besser erfassbar sind, wage
ich immer noch zu bezweifeln.

> und somit aus dem gerade
> geöffneten PDF-Dokument nicht mehr auf die Webseite zurückfinden :-(

PDFs können in der Tat ein Problem sein, für die empfiehlt sogar Nielsen
die target-Angabe. Hast du denn massenhaft PDFs in deinem Angebot?
Schade ein webtaugliches Format ist im Browser besser aufgehoben. ;-)

>> Abgesehen davon ist es nicht Inhalt - Markup sondern Verhalten -
>> Scripting, gehört also auch theoretisch nicht ins (X)HTML.
> 
> Praktisch aber schon. Und das geht standardkonform im Strict eben nicht,
> weswegen man Transitional oder Javascript benötigt, wobei letzteres auch
> nur getrickst ist und nicht zwangsläufig funktioniert.

zwangsläufig *funktioniert* auch target nicht. Firefox lenkt IMHO in der
Defaulteinstellung blank auf neues Tab um. Ich habe meinem Seamonkey
beigebracht target zu ignorieren und das Linkziel im aktuellen Tab zu
öffnen, insofern sehe ich das Problem heute etwas entspannter.
Mit Javascript könnte man z.B. userspezifizische Vorlieben (neues
Fenster oder nicht) abfragen und speichern und damit auch gleich noch
ein bisschen Kundenbindung treiben.

Gruß
Susanne

On Sun, 28 Mar 2010 14:45:08 Christoph Schneegans wrote:
> > und somit aus dem gerade geöffneten PDF-Dokument nicht mehr auf
> > die Webseite zurückfinden :-(
 
> Man zeigt PDF-Dokumente ja auch nicht im Browser an.

Dann bekomme ich bei vielen Plattformen eine leere Seite im Browser,
sowie ein weiteres Fenster mit dem PDF-Dokument. Auch nicht das
Gelbe vom Ei.

Bloederweise ist eines der ganz wenigen Systeme, wo ich
ab und zu versehentlich PDF-Dokumente und damit auch gleich den
Browser schliesse _mein_ _eigenes_, weil ich mich offenbar an das
sonst uebliche Verhalten gewoehnt habe. Das gibt schon zu denken...

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - irrsinnig, mehr als man wünscht.
(Sloganizer)

Am Sun, 28 Mar 2010 14:40:56 +0200 schrieb Christoph Schneegans:

> Das typische Gefasel mal wieder. Wenn du Argumente hättest, würdest
> du sie einfach nennen.

Moment: Du warst es doch, der hier wilde Thesen postulierte. *Du* bist es
also, der seine Argumente vorbringen sollte.

On Sun, 28 Mar 2010 14:53:43 +0300, Martin Honnen   
wrote:

>    <html xmlns="http://www.w3.org/1999/xhtml">
>    <meta />
>    <link />
>    <script src="/static/scripts/cs.js" type="text/javascript"></script>

Danke, das war's.

Susanne Jäger wrote:

> On 28.03.2010 14:34, Alex Prahl wrote:
>> Am Sun, 28 Mar 2010 14:27:58 +0200 schrieb Susanne Jäger:
>> Soweit die Theorie. Die Praxis sieht ganz anders aus. Und damit meine
>> ich nicht nur, dass oft gewünscht wird, dass externe Seiten nicht das
>> eigene Angebot schließt, sondern auch rein praktische Dinge. Denn die
>> Erfahrung lehrt, dass viele User (wenn nicht sogar die Mehrheit) die
>> "Zurück"-Funktion des Browsers nicht kennen,
> 
> was zu beweisen wäre.

Ja, verschiedene Usability-Studien sagen das Gegenteil dessen aus.

> Und ob der Focuswechsel und die hundert geöffneten Fenster für den
> gemeinen Websurfer wirklich besser erfassbar sind, wage ich immer
> noch zu bezweifeln.

Zu Recht.
 
>> und somit aus dem gerade geöffneten PDF-Dokument nicht mehr auf die
>> Webseite zurückfinden :-(
> 
> PDFs können in der Tat ein Problem sein, für die empfiehlt sogar Nielsen
> die target-Angabe.

Auch Nielsen kann irren.

> Hast du denn massenhaft PDFs in deinem Angebot?

Was spielt das für eine Rolle?

> Schade ein webtaugliches Format ist im Browser besser aufgehoben. ;-)

PDFs sind nicht nicht-webtauglich, und HTML hat zwar in gewissen Bereichen 
gewisse Vorzüge, es lässt sich damit aber trotzdem nicht alles machen.
 
>>> Abgesehen davon ist es nicht Inhalt - Markup sondern Verhalten -
>>> Scripting, gehört also auch theoretisch nicht ins (X)HTML.
>> 
>> Praktisch aber schon. Und das geht standardkonform im Strict eben nicht,
>> weswegen man Transitional oder Javascript benötigt, wobei letzteres auch
>> nur getrickst ist und nicht zwangsläufig funktioniert.
> 
> zwangsläufig *funktioniert* auch target nicht. Firefox lenkt IMHO in der
> Defaulteinstellung blank auf neues Tab um.

Das wäre ein Beweis für die *Funktionalität* von target="_blank".

> Ich habe meinem Seamonkey beigebracht target zu ignorieren

Kaputtgespielte Konfigurationen sind kein Beweis für Nichtfunktionalität.

Darüberhinaus ging es hier gar nicht um Funktionalität von target="_blank", 
sondern die Frage nach der Notwendigkeit von Transitional-Varianten.  Das 
sind gleich drei Paar verschiedene Schuhe.


PointedEars

Alex Prahl wrote:

> Chris Seidel schrieb:
>> <script src="/static/scripts/cs.js" type="text/javascript"/>
> 
> Ohne es ausprobiert zu haben, würde ich hier Probleme vermuten. Würde ich
> lieber in <script *></script> auflösen.

Natürlich.
 
> Generell wird oft empfohlen, niemals nicht <abc/>, sondern <abc /> zu
> schreiben, also mit Leerzeichen; Hintergrund soll die verbesserte
> Kompatibilität sein.

Wobei diese Argumentation natürlich höchst fragwürdig ist, denn in HTML ist

  <abc />

streng genommen gleichbedeutend mit

  <abc>>

wird aber von verbreiteten *Tagsoup*-Parsern wie

  <abc>

interpretiert.

Hier wird also ein *Mangel* bzw. *Bug* ausgenutzt und die Tatsache, dass 
`Content-Type: text/html' diese Parser statt eines XML-Parsers triggert; 
nichts also, auf das man sich verlassen sollte.


-- 
PointedEars

Susanne Jäger schrieb:

> PDFs können in der Tat ein Problem sein, für die empfiehlt sogar
> Nielsen die target-Angabe.

Tut er nicht. Er hatte bloß am Anfang keine Ahnung, daß es
"Content-Disposition: attachment" gibt, und war dann zu stolz,
seinen Fehler einzugestehen und den blödsinnigen Artikel
<http://www.useit.com/alertbox/open_new_windows.html>
zurückzuziehen.

-- 
<http://schneegans.de/web/kanonische-adressen/> · Gute URLs

Stefan Froehlich schrieb:

>> Man zeigt PDF-Dokumente ja auch nicht im Browser an.
>
> Dann bekomme ich bei vielen Plattformen eine leere Seite im
> Browser, sowie ein weiteres Fenster mit dem PDF-Dokument.

Was für Plattformen sollen das sein? Ich habe noch nie gesehen, daß
"Content-Disposition: attachment" ein neues Browser-Fenster öffnet.

-- 
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML

Thomas 'PointedEars' Lahn schrieb:

> (...) in HTML ist <abc /> streng genommen gleichbedeutend mit
> <abc>> wird aber von verbreiteten *Tagsoup*-Parsern wie <abc>
> interpretiert.
>
> Hier wird also ein *Mangel* bzw. *Bug* ausgenutzt und die
> Tatsache, dass `Content-Type: text/html' diese Parser statt eines
> XML-Parsers triggert; nichts also, auf das man sich verlassen
> sollte.

Das funktioniert seit zehn Jahren auf Millionen von Websites in
allen wichtigen Browsern absolut zuverlässig. Klar, im Lahn'schen
Universum kann man sich auf derartige Tatsachen nicht verlassen.

-- 
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML

On 28.03.2010 17:05, Christoph Schneegans wrote:
> Susanne Jäger schrieb:
> 
>> PDFs können in der Tat ein Problem sein, für die empfiehlt sogar
>> Nielsen die target-Angabe.
> 
> Tut er nicht. Er hatte bloß am Anfang keine Ahnung, daß es
> "Content-Disposition: attachment" gibt, und war dann zu stolz,
> seinen Fehler einzugestehen und den blödsinnigen Artikel
> <http://www.useit.com/alertbox/open_new_windows.html>
> zurückzuziehen.

Ok, stimmt eigentlich. Wenn man auf den Unsinn verzichtet, PDFs im
Browser öffnen zu wollen, braucht man auch kein target mehr.

Gruß
Susanne

On Sun, 28 Mar 2010, Susanne Jäger wrote:

> was zu beweisen wäre. Und ob der Focuswechsel und die hundert geöffneten
> Fenster für den gemeinen Websurfer wirklich besser erfassbar sind, wage
> ich immer noch zu bezweifeln.

Es war ja nicht die Rede von hundert Fenstern, sondern davon, dass es 
*auch mal* sinnvoll sein kann, ein neues Fenster oder einen neuen Tab zu 
eröffnen. Beispiel: Die alte Seite enthält viel Information, vielleicht 
aus einer Datenbank zusammengesucht, und die neue erklärt ein Detail dazu. 
Wer jetzt die neue anklickt und vergisst, dass er dabei dem Browser das 
Target angeben muss (etwa durch Wahl der Maustaste), der kann damit nichts 
anfangen, weil er etwas erklärt bekommt, was er nicht mehr sieht. Also 
*muss* er auf den Back-Button gehen, und dann geht erstmal die 
Datenbanksuche ein zweites Mal los. In solchen Fällen wäre es nicht 
vermessen, anzunehmen, dass der Nutzer die alte Seite weiterhin 
griffbereit haben will. Und geklickt ist eben manchmal schneller als 
nachgedacht.

-- 
Helmut Richter

On 28.03.2010 17:26, Helmut Richter wrote:
> On Sun, 28 Mar 2010, Susanne Jäger wrote:

> sondern davon, dass es 
> *auch mal* sinnvoll sein kann, ein neues Fenster oder einen neuen Tab zu 
> eröffnen. Beispiel: Die alte Seite enthält viel Information, vielleicht 
> aus einer Datenbank zusammengesucht, und die neue erklärt ein Detail dazu. 
> Wer jetzt die neue anklickt und vergisst, dass er dabei dem Browser das 
> Target angeben muss (etwa durch Wahl der Maustaste), der kann damit nichts 
> anfangen, weil er etwas erklärt bekommt, was er nicht mehr sieht. Also 
> *muss* er auf den Back-Button gehen, und dann geht erstmal die 
> Datenbanksuche ein zweites Mal los. In solchen Fällen wäre es nicht 
> vermessen, anzunehmen, dass der Nutzer die alte Seite weiterhin 
> griffbereit haben will. Und geklickt ist eben manchmal schneller als 
> nachgedacht.

In genau diesen Fällen ist es aber meistens auch sinnvoll das erklärende
Fenster in der Größe zu beschränken und sinnvoll zu platzieren was habe
ich von einem erklärenden Fenster, das sich über die Erklärung legt?

Gruß
Susanne

On 28.03.2010 16:31, Thomas 'PointedEars' Lahn wrote:
> Susanne Jäger wrote:

>>> Praktisch aber schon. Und das geht standardkonform im Strict eben nicht,
>>> weswegen man Transitional oder Javascript benötigt, wobei letzteres auch
>>> nur getrickst ist und nicht zwangsläufig funktioniert.
>>
>> zwangsläufig *funktioniert* auch target nicht. Firefox lenkt IMHO in der
>> Defaulteinstellung blank auf neues Tab um.
> 
> Das wäre ein Beweis für die *Funktionalität* von target="_blank".

????? Aus wessen Sicht. Der Anbieter ist ja der Meinung ein neues
Fenster erzwingen zu wollen, das funktioniert aber nicht.

>> Ich habe meinem Seamonkey beigebracht target zu ignorieren
> 
> Kaputtgespielte Konfigurationen sind kein Beweis für Nichtfunktionalität.

Was ist bitte an der Anpassung eines Browsers an die Bedürfnisse seines
Benutzers kaputtgespielt? Ich habe darauf hingewiesen, dass target=blank
ebenso gut oder schlecht "funktioniert" wie eine entsprechende
JS-Lösung, das wars auch schon.

> Darüberhinaus ging es hier gar nicht um Funktionalität von target="_blank", 

wenn du lesen würdest, auf was ich geantwortet habe, könntest du sehen,
dass es hier sehr wohl um genau diese Frage ging.

> sondern die Frage nach der Notwendigkeit von Transitional-Varianten.  Das 
> sind gleich drei Paar verschiedene Schuhe.

Wenn man einen Standard so gründlich entmistet wie das von HTML 3.02 auf
4.01 passiert ist, ist/war es sicher sinnvoll eine Variante anzubieten,
die für eine *Übergangs*zeit weiterhin den Einsatz von veralteten
Elementen und Attributen erlaubt. Über 10 Jahren nach der Einführung
dieses Standards sehe ich aber keine echte Berechtigung mehr für die
weitere Verwendung dieses Zeugs. Schlimm genug, dass immer noch
zahlreiche Editoren und Tools davon nix gemerkt haben, da muss man das
nicht auch noch als erstrebenswert verkaufen.


Gruß
Susanne

Christoph Schneegans meinte:
> Stefan Froehlich schrieb:
> 
>>> Man zeigt PDF-Dokumente ja auch nicht im Browser an.
>> Dann bekomme ich bei vielen Plattformen eine leere Seite im
>> Browser, sowie ein weiteres Fenster mit dem PDF-Dokument.
> 
> Was für Plattformen sollen das sein? Ich habe noch nie gesehen, daß
> "Content-Disposition: attachment" ein neues Browser-Fenster öffnet.

Aber ich hab genügend Kunden gesehen, die das PDF "gleich im Browser" 
sehen wollen und keinen Download-Dialog. Weil "bei allen anderen Seiten 
ist das auch so".

Zudem: Man verlinkt auf das PDF. Mit welchem Header das ausgeliefert 
wird, ist dann gerne Sache des Shared Host und "deine" 
Content-Disposition kannst du dir in die Haare schmieren.

Gregor



-- 
http://www.gregorkofler.com

On Sun, 28 Mar 2010 17:07:39 Christoph Schneegans wrote:
> >> Man zeigt PDF-Dokumente ja auch nicht im Browser an.

> > Dann bekomme ich bei vielen Plattformen eine leere Seite im
> > Browser, sowie ein weiteres Fenster mit dem PDF-Dokument.
 
> Was für Plattformen sollen das sein? Ich habe noch nie gesehen, daß
> "Content-Disposition: attachment" ein neues Browser-Fenster öffnet.

Oehm, keine Ahnung, aber vermutlich war ein target="_blank" mit im
Spiel. Das war zu einer Zeit, als ich Mozilla ohne PDF-Plugin
betrieben habe - ich habe mich ueber das Verhalten zwar geaergert,
bin der Ursache aber nicht weiter nachgegangen. Inzwischen oeffne
ich PDF-Dokumente wieder im Browser, daher gibt es den Effekt auch
nicht mehr.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Zerspülte Hemmungen, oder warum Stefan so imponierend flucht!
(Sloganizer)

Susanne Jäger schrieb:

> Und ob der Focuswechsel und die hundert geöffneten
> Fenster für den gemeinen Websurfer wirklich besser erfassbar sind, wage
> ich immer noch zu bezweifeln.

Er ist definitiv leichter erfaßbar als die nicht sichtbare History von
100 Domains im selben Fenster. Außerdem haben diese Fenster oder Tabs
einen Schließknopf. Nicht mehr benötigte kann man verschwinden lassen,
ohne dabei den Hauptnavigationszweig zu verlieren.

Tschüß

	Dietmar
-- 
Lesbar quoten kann so einfach sein:
http://www.learn.to/quote
http://www.volker-gringmuth.de/usenet/zitier.htm

Dietmar Hollenberg meinte:
> Susanne Jäger schrieb:
> 
>> Und ob der Focuswechsel und die hundert geöffneten
>> Fenster für den gemeinen Websurfer wirklich besser erfassbar sind, wage
>> ich immer noch zu bezweifeln.
> 
> Er ist definitiv leichter erfaßbar als die nicht sichtbare History von
> 100 Domains im selben Fenster. Außerdem haben diese Fenster oder Tabs
> einen Schließknopf. Nicht mehr benötigte kann man verschwinden lassen,
> ohne dabei den Hauptnavigationszweig zu verlieren.

Das Problem ist die Einbahnstraße. "Normale" Links *kann* ich im neuen 
Tab/Fenster öffnen lassen. Links mit spezifiziertem Target aber nicht im 
gleichen Browserfenster.

Mitunter ein anderes Problem: Links öffnen ein neues Fenster welches 
wiederverwendet wird. Spätestens beim zweiten mal ist das Fenster 
irgendwo im Hintergrund - es passiert gefühlt "nichts", und die Sucherei 
nach offenen Fenstern in irgendwelchen Taskleisten fängt an.

target-Attribute gibt es auf meinen Webseiten nicht. Wenn vom Kinden 
unbedingt gewünscht wird diese Eigenschaft per JS gesetzt.

Gregor


-- 
http://www.gregorkofler.com

Christoph Schneegans wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> (...) in HTML ist <abc /> streng genommen gleichbedeutend mit
>> <abc>> wird aber von verbreiteten *Tagsoup*-Parsern wie <abc>
>> interpretiert.
>>
>> Hier wird also ein *Mangel* bzw. *Bug* ausgenutzt und die
>> Tatsache, dass `Content-Type: text/html' diese Parser statt eines
>> XML-Parsers triggert; nichts also, auf das man sich verlassen
>> sollte.
> 
> Das funktioniert seit zehn Jahren auf Millionen von Websites in
> allen wichtigen Browsern absolut zuverlässig. Klar, im Lahn'schen
> Universum kann man sich auf derartige Tatsachen nicht verlassen.

Tatsachen aus der Vergangenheit sind für die Zukunft irrelevant.

Darüberhinaus: <http://www.dodabo.de/html+css/tests/shorttag.html>


PointedEars

Susanne Jäger wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Susanne Jäger wrote:
>>>> Praktisch aber schon. Und das geht standardkonform im Strict eben
>>>> nicht, weswegen man Transitional oder Javascript benötigt, wobei
>>>> letzteres auch nur getrickst ist und nicht zwangsläufig funktioniert.
>>> zwangsläufig *funktioniert* auch target nicht. Firefox lenkt IMHO in
>>> der Defaulteinstellung blank auf neues Tab um.
>> Das wäre ein Beweis für die *Funktionalität* von target="_blank".
> 
> ????? Aus wessen Sicht. Der Anbieter ist ja der Meinung ein neues
> Fenster erzwingen zu wollen, das funktioniert aber nicht.

Das kann man so sehen, wenn man geflissentlich ignoriert, dass Tabbed 
Browsing als HTML 4.01 und XHTML 1.0 veröffentlicht wurden noch nicht sehr 
verbreitet war (obwohl es das Feature wohl schon seit 1994 gibt¹) und daher 
der Begriff "browser tab" dort nicht vorkommen kann (W3C-Spezifikationen 
müssen interoperable Implementationen vorweisen).

Der Sinn der Sache ist aber, das im aktuellen Viewport angezeigte Dokument 
nicht zu wechseln, stattdessen die per URI(-Referenz) referenzierte 
Ressource in einem neuen Viewport anzuzeigen, und das hätte in obigem Fall 
sehr wohl funktioniert.

¹  <http://de.wikipedia.org/wiki/Tabbed_Browsing#Entwicklung>

>>> Ich habe meinem Seamonkey beigebracht target zu ignorieren
>> 
>> Kaputtgespielte Konfigurationen sind kein Beweis für
>> Nichtfunktionalität.
> 
> Was ist bitte an der Anpassung eines Browsers an die Bedürfnisse seines
> Benutzers kaputtgespielt?

"Kaputtgespielt" war eine umgangssprachliche Formulierung für "Du hast die 
Funktionsfähigkeit des HTML-Attributs absichtlich ausser Kraft gesetzt".
Diese Massnahme ändert an der grundlegenden Funktionalität des Attributs 
aber nichts.

> Ich habe darauf hingewiesen, dass target=blank ebenso gut oder schlecht
> "funktioniert" wie eine entsprechende JS-Lösung, das wars auch schon.

Und liegst damit in mehrfacher Hinsicht falshc (selbst wenn ich mal "blank" 
als "_blank" lese).

>> Darüberhinaus ging es hier gar nicht um Funktionalität von
>> target="_blank",
> 
> wenn du lesen würdest, auf was ich geantwortet habe, könntest du sehen,
> dass es hier sehr wohl um genau diese Frage ging.

Nein, das war nur ein (unnötiges und taktisch unkluges) Gegenbeispiel von 
Alex (Prahl) für die nach wie vor unbelegte Behauptung von Christoph 
(Schneegans), es gäbe keine Gründe für die Transitional-Varianten (lies: 
sie seien grundsätzlich überflüssig).
 
>> sondern die Frage nach der Notwendigkeit von Transitional-Varianten. 
>> Das sind gleich drei Paar verschiedene Schuhe.
> 
> Wenn man einen Standard so gründlich entmistet wie das von HTML 3.02 auf
> 4.01 passiert ist, ist/war es sicher sinnvoll eine Variante anzubieten,
> die für eine *Übergangs*zeit weiterhin den Einsatz von veralteten
> Elementen und Attributen erlaubt. Über 10 Jahren nach der Einführung
> dieses Standards sehe ich aber keine echte Berechtigung mehr für die
> weitere Verwendung dieses Zeugs. Schlimm genug, dass immer noch
> zahlreiche Editoren und Tools davon nix gemerkt haben, da muss man das
> nicht auch noch als erstrebenswert verkaufen.

Dass *alle* Elemente und Attribute, die in HTML 4.01 Strict/XHTML 1.0 
Strict aber nicht in HTML 4.01 Transitional/XHTML 1.0 Transitional 
enthalten sind, "Mist" sind, wäre noch zu zeigen.  Und zwar genau von 
denen, die behaupten, dass sie es sind.  Nicht umgekehrt.


PointedEars

Gregor Kofler schrieb:

> Das Problem ist die Einbahnstraße. "Normale" Links *kann* ich im neuen 
> Tab/Fenster öffnen lassen. Links mit spezifiziertem Target aber nicht im 
> gleichen Browserfenster.

Das ist kein Problem des Attributs, sondern des Browserverhaltens. Das
Attribut darf sowohl ignoriert als auch den Nutzerwünschen entsprechend
anders interpretiert werden. Deshalb wäre es weitaus sinnvoller, dem
Nutzer eine entsprechende Einstellung im Browser zur Verfügung zu
stellen. Dazu gehört auch die Möglichkeit, die Zielempfehlung temporär
nicht zu beachten.

Dem Nutzer in jedem Einzelfall beim Klick auf einen Link die
Entscheidung zwangsweise aufzuerlegen, wie der Link geöffnet werden
soll, ist jedenfalls definitiv *keine* optimale Usability, zumal der
Nutzer in vielen Fällen vor dem Klick gar nicht entscheiden kann, ob er
den Inhalt in einem neuen Fenster sehen möchte oder nicht, weil er den
Inhalt logischerweise noch gar nicht kennt. Der Webdesigner, der den
Link setzt, kennt den Inhalt aber normalerweise und kann deshalb eine
entsprechende Empfehlung setzen, die der Nutzer beachten kann, aber
nicht muß.

Tschüß

	Dietmar
-- 
Lesbar quoten kann so einfach sein:
http://www.learn.to/quote
http://www.volker-gringmuth.de/usenet/zitier.htm

Thomas 'PointedEars' Lahn wrote:

> Dass *alle* Elemente und Attribute, die in HTML 4.01 Strict/XHTML 1.0
> Strict aber nicht in HTML 4.01 Transitional/XHTML 1.0 Transitional
> enthalten sind, "Mist" sind, wäre noch zu zeigen.  Und zwar genau von
> denen, die behaupten, dass sie es sind.  Nicht umgekehrt.

Gemeint war:

Dass *alle* Elemente und Attribute, die in HTML 4.01 Transitional/XHTML 1.0
Transitional aber nicht in HTML 4.01 Strict/XHTML 1.0 Strict enthalten sind, 
"Mist" sind, wäre noch zu zeigen.  Und zwar genau von denen, die behaupten, 
dass sie es sind.  Nicht umgekehrt.


-- 
PointedEars

Christoph Schneegans wrote:

> Lächerlich. "The Back button is ... the second-most used navigation
> feature", schrieb Nielsen schon vor 10 Jahren.

Und in diesem Zeitraum hat sich die Struktur von Webseiten und 
das Verhalten von Nutzern ja praktisch nicht verändert ... 


vG

-- 
      It takes a village to raise a child. (Afrikanisches Sprichwort)

-- <http://einklich.net> -- Ein Pinguin für jeden: <http://debian.org/> --

Dietmar Hollenberg meinte:
> Gregor Kofler schrieb:
> 
>> Das Problem ist die Einbahnstraße. "Normale" Links *kann* ich im neuen 
>> Tab/Fenster öffnen lassen. Links mit spezifiziertem Target aber nicht im 
>> gleichen Browserfenster.
> 
> Das ist kein Problem des Attributs, sondern des Browserverhaltens. Das
> Attribut darf sowohl ignoriert als auch den Nutzerwünschen entsprechend
> anders interpretiert werden. Deshalb wäre es weitaus sinnvoller, dem
> Nutzer eine entsprechende Einstellung im Browser zur Verfügung zu
> stellen. Dazu gehört auch die Möglichkeit, die Zielempfehlung temporär
> nicht zu beachten.

Markup soll die Struktur eines Dokumentes definieren, nicht das 
Verhalten bei Interaktion. Eine entsprechende Browsereinstellung ist nur 
das Bekämpfen von Symptomen.

> Dem Nutzer in jedem Einzelfall beim Klick auf einen Link die
> Entscheidung zwangsweise aufzuerlegen, wie der Link geöffnet werden
> soll, ist jedenfalls definitiv *keine* optimale Usability, zumal der
> Nutzer in vielen Fällen vor dem Klick gar nicht entscheiden kann, ob er
> den Inhalt in einem neuen Fenster sehen möchte oder nicht,

Warum nicht? Weil der Link womöglich wieder mit einem idiotischen 
Linktext unterlegt wurde?

> weil er den
> Inhalt logischerweise noch gar nicht kennt.

"Details zu den Tickets" - was soll man da etwa erwarten?
Eine Kennzeichnung von Links zu anderen Websites ist ja kein Problem. 
Auch die Wikipedia schafft das.

> Der Webdesigner, der den
> Link setzt, kennt den Inhalt aber normalerweise und kann deshalb eine
> entsprechende Empfehlung setzen, die der Nutzer beachten kann, aber
> nicht muß.

Auf die "Empfehlungen" von Webdesigner bzw. deren Auftraggebern kann ich 
regelmäßig verzichten. Spätestens dann, wenn ich nach meinem 
abgeschlossenen Bezahlvorgang plötzlich 2 Fenster offen habe, die mir 
dieselbe Seite zeigen, aber mit einer unterschiedlichen Historie geht 
mir das Geimpfte wieder mal auf.

Gregor


-- 
http://www.gregorkofler.com

Volker Gringmuth meinte:
> Christoph Schneegans wrote:
> 
>> Lächerlich. "The Back button is ... the second-most used navigation
>> feature", schrieb Nielsen schon vor 10 Jahren.
> 
> Und in diesem Zeitraum hat sich die Struktur von Webseiten und 
> das Verhalten von Nutzern ja praktisch nicht verändert ... 

Es liegt der Schluss nahe, dass mittlerweile mehr Leute vom Back-Button 
gehört haben.

Gregor


-- 
http://www.gregorkofler.com

Gregor Kofler schrieb:

> Auf die "Empfehlungen" von Webdesigner bzw. deren Auftraggebern kann ich 
> regelmäßig verzichten.

Daran sollst du auch nicht gehindert werden. Aber es ist nicht deine
Aufgabe, den Rest der Welt ebenfalls daran zu hindern. Dogmatiker sollen
in die katholische Kirche eintreten, aber den Rest der Welt in Ruhe
lassen.

Tschüß

	Dietmar
-- 
Lesbar quoten kann so einfach sein:
http://www.learn.to/quote
http://www.volker-gringmuth.de/usenet/zitier.htm

Gregor Kofler wrote:

>> Und in diesem Zeitraum hat sich die Struktur von Webseiten und
>> das Verhalten von Nutzern ja praktisch nicht verändert ...
> 
> Es liegt der Schluss nahe, dass mittlerweile mehr Leute vom Back-Button
> gehört haben.

Kürzlich wurde ja hier thematisiert, daß manche Benutzer einen URL überhaupt
nicht in die Adreßzeile eintippen oder einwasauchimmer, sondern bei Google
danach suchen (aktuell ging es um die Kundenbeschwerde, eine neu
hochgeladene Seite sei noch nicht erreichbar - Google hatte sie noch nicht
indiziert). 

Dann halte ich /alles/ für möglich ... 

Ich bekam mal eine Mail (ist schon etwas her), in der bedauert wurde, daß
man meine privaten Seiten nicht drucken könne. Erst nach einigem
Mailwechsel begriff ich, daß der Besucher vergeblich nach einem "Diese
Seite drucken"-Link auf der Seite selbst gefahndet hatte. Im "Datei"-Menü
seines Browsers machte er dann eine verblüffende Entdeckung. 


vG

-- 
               "Du weisst, daß du eine Sprache nicht kennst,
            wenn sie nach ROT13 immer noch aussieht wie ROT13."
                    (Christian Wetzel in de.alt.arnooo)
-- <http://einklich.net> -- Ein Pinguin für jeden: <http://debian.org/> --

Volker Gringmuth meinte:
> Gregor Kofler wrote:
> 
>>> Und in diesem Zeitraum hat sich die Struktur von Webseiten und
>>> das Verhalten von Nutzern ja praktisch nicht verändert ...

Um diese sarkastisch gemeinte Aussage ging es.

>> Es liegt der Schluss nahe, dass mittlerweile mehr Leute vom Back-Button
>> gehört haben.
> 
> Kürzlich wurde ja hier thematisiert, daß manche Benutzer einen URL überhaupt
> nicht in die Adreßzeile eintippen oder einwasauchimmer, sondern bei Google
> danach suchen (aktuell ging es um die Kundenbeschwerde, eine neu
> hochgeladene Seite sei noch nicht erreichbar - Google hatte sie noch nicht
> indiziert). 
> 
> Dann halte ich /alles/ für möglich ... 

Eben. Es hat sich *nichts* geändert. (Vergleichbare Hardcorefälle hatte 
ich bislang nur am Desktop.)

Gregor


-- 
http://www.gregorkofler.com

* Alex Prahl wrote:

> Am Sun, 28 Mar 2010 14:40:56 퍭 schrieb Christoph Schneegans:
> 
>> Das typische Gefasel mal wieder. Wenn du Argumente hättest, würdest
>> du sie einfach nennen.
> 
> Moment: Du warst es doch, der hier wilde Thesen postulierte. *Du* bist es
> also, der seine Argumente vorbringen sollte.

<http://schneegans.de/web/xhtml/> schon gelesen?

-- 
Jo

Alex Prahl schrieb:

> Am Sun, 28 Mar 2010 14:27:58 +0200 schrieb Susanne Jäger:
> 
>> On 28.03.2010 13:34, Alex Prahl wrote:
>>
>>> Wie baue ich denn in ein Strict-Dokument sowas wie
>>> <a href="xxx" target="_blank">
>>> ein, sodass es validiert?
>> Am besten gar nicht. Das Öffnen neuer Fenster sollte dem Nutzer
>> vorbehalten bleiben -
> 
> Soweit die Theorie. Die Praxis sieht ganz anders aus. Und damit meine ich
> nicht nur, dass oft gewünscht wird, dass externe Seiten nicht das eigene
> Angebot schließt, sondern auch rein praktische Dinge. Denn die Erfahrung
> lehrt, dass viele User (wenn nicht sogar die Mehrheit) die
> "Zurück"-Funktion des Browsers nicht kennen, und somit aus dem gerade
> geöffneten PDF-Dokument nicht mehr auf die Webseite zurückfinden :-(

Aber den "Schließen"-Knopf finden sie besser?

Das halte ich für eine sehr gewagte These.

>> Abgesehen davon ist es nicht Inhalt - Markup sondern Verhalten -
>> Scripting, gehört also auch theoretisch nicht ins (X)HTML.
> 
> Praktisch aber schon. Und das geht standardkonform im Strict eben nicht,
> weswegen man Transitional oder Javascript benötigt, wobei letzteres auch
> nur getrickst ist und nicht zwangsläufig funktioniert.

Eben - und deswegen lässt man es einfach sein. Jeder mir bekannte
Web-Browser hat einen "Zurück"-Knopf an sehr prominenter Stelle und
optisch auch recht auffällig. Auch existiert schon sehr lange in fast
allen Browsern die Möglichkeit, Links über das Kontextmenü explizit in
neuen Fenster zu öffnen.

Bei Windows findet man den selben Knopf auch im Explorer für
Dateiverzeichnisse, um eben wieder an die vorher dargestellten Orte
zurückzukehren.

Die These, man könne nicht erwarten, daß die *Mehrheit* der Besucher
nicht weiß, daß man mit "Zurück" wieder zur ursprünglichen Seite
zurückkommt, halte ich für reine Spekulation.

Man muss die Unwissenheit der Benutzer nicht absichtlich auch noch
fördern. Sinnvolle und leicht nachvollziehbare Angebote ja - aber ein
bisschen Minimalkenntnis der Technik, die man nutzt, darf man schon
erwarten.


-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

Helmut Richter schrieb:

> On Sun, 28 Mar 2010, Susanne Jäger wrote:
> 
>> was zu beweisen wäre. Und ob der Focuswechsel und die hundert geöffneten
>> Fenster für den gemeinen Websurfer wirklich besser erfassbar sind, wage
>> ich immer noch zu bezweifeln.
> 
> Es war ja nicht die Rede von hundert Fenstern, sondern davon, dass es 
> *auch mal* sinnvoll sein kann, ein neues Fenster oder einen neuen Tab zu 
> eröffnen. Beispiel: Die alte Seite enthält viel Information, vielleicht 
> aus einer Datenbank zusammengesucht, und die neue erklärt ein Detail dazu. 
> Wer jetzt die neue anklickt und vergisst, dass er dabei dem Browser das 
> Target angeben muss (etwa durch Wahl der Maustaste), der kann damit nichts 
> anfangen, weil er etwas erklärt bekommt, was er nicht mehr sieht. Also 
> *muss* er auf den Back-Button gehen, und dann geht erstmal die 
> Datenbanksuche ein zweites Mal los. In solchen Fällen wäre es nicht 
> vermessen, anzunehmen, dass der Nutzer die alte Seite weiterhin 
> griffbereit haben will. Und geklickt ist eben manchmal schneller als 
> nachgedacht.

In dieser konkreten Anwendung wäre ein DIV-Element, daß entsprechend
plaziert wird - ganz ohne neues Fenster - vermutlich zielführender.


-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

Arno Welzel  wrote:
> Alex Prahl schrieb:
> 
>> Am Sun, 28 Mar 2010 14:27:58 +0200 schrieb Susanne Jäger:
>> 
>>> On 28.03.2010 13:34, Alex Prahl wrote:
>>>
>>>> Wie baue ich denn in ein Strict-Dokument sowas wie
>>>> <a href="xxx" target="_blank">
>>>> ein, sodass es validiert?
>>> Am besten gar nicht. Das Öffnen neuer Fenster sollte dem Nutzer
>>> vorbehalten bleiben -
>> 
>> Soweit die Theorie. Die Praxis sieht ganz anders aus. Und damit meine ich
>> nicht nur, dass oft gewünscht wird, dass externe Seiten nicht das eigene
>> Angebot schließt, sondern auch rein praktische Dinge. Denn die Erfahrung
>> lehrt, dass viele User (wenn nicht sogar die Mehrheit) die
>> "Zurück"-Funktion des Browsers nicht kennen, und somit aus dem gerade
>> geöffneten PDF-Dokument nicht mehr auf die Webseite zurückfinden :-(
> 
> Aber den "Schließen"-Knopf finden sie besser?
> 
> Das halte ich für eine sehr gewagte These.

Jakob Nielsen schlägt auch ein neues Fenster für PDF vor:
http://www.useit.com/alertbox/open_new_windows.html



-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

Stefan Scholl meinte:

> Jakob Nielsen schlägt auch ein neues Fenster für PDF vor:
> http://www.useit.com/alertbox/open_new_windows.html

Passt. Ein PDF ist keine Webseite. Und wird bei mir auch ganz korrekt 
*nicht* in einem Browserfenster angezeigt.

Gregor


-- 
http://www.gregorkofler.com

Gregor Kofler  wrote:
> Stefan Scholl meinte:
>> Jakob Nielsen schlägt auch ein neues Fenster für PDF vor:
>> http://www.useit.com/alertbox/open_new_windows.html
> 
> Passt. Ein PDF ist keine Webseite. Und wird bei mir auch ganz korrekt 
> *nicht* in einem Browserfenster angezeigt.

Redest Du von Deiner persönlichen Browser-Einstellung, oder
benutzt Du "Content-Disposition: Attachment" auf Webseiten?


Letzteres habe ich noch nicht für statische Files gemacht, nur
generierte Dokumente. Aber Apaches mod_headers könnte das sicher
gut erledigen. ("HTTP Headers"-Modul in Nginx und was sonst so in
anderen Servern gibt.)



-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

Christoph Schneegans  wrote:
> Susanne Jäger schrieb:
> 
>> PDFs können in der Tat ein Problem sein, für die empfiehlt sogar
>> Nielsen die target-Angabe.
> 
> Tut er nicht. Er hatte bloß am Anfang keine Ahnung, daß es
> "Content-Disposition: attachment" gibt, und war dann zu stolz,
> seinen Fehler einzugestehen und den blödsinnigen Artikel
> <http://www.useit.com/alertbox/open_new_windows.html>
> zurückzuziehen.

Wie würde ein Normalbürger diese Header-Zeile einfügen, wenn er
nur statische Seiten hat und keinen Zugriff auf die
Server-Config?

Nielsen sollte die Reihenfolge/Gewichtung ändern, aber nicht den
Artikel zurückziehen.




-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

Stefan Scholl  wrote:
>>> http://www.useit.com/alertbox/open_new_windows.html
> 
> Letzteres habe ich noch nicht für statische Files gemacht, nur
> generierte Dokumente. Aber Apaches mod_headers könnte das sicher
> gut erledigen. ("HTTP Headers"-Modul in Nginx und was sonst so in
> anderen Servern gibt.)

Oops, ist ja auf der verlinkten Seite
http://stuvel.eu/pdfdownload erklärt.

Chris Seidel  schrieb/wrote:
> gibt es entscheidende Argumente von XHTML ggü. HTML? Wenn ja, welche?

Wenn du XHTML brauchst, weißt du es. (Das ist u.a. der Fall, wenn du ein
XML-System zur Verwaltung verwendest und/oder du Sachen aus anderen XML-
Namespaces einfügen willst.)

Ansonsten nimm HTML. Am besten gleich HTML 5, wobei du die neuen  
Elemente vorerst noch vermeidest.

Claus

Claus Färber wrote:

> Chris Seidel  schrieb/wrote:
>> gibt es entscheidende Argumente von XHTML ggü. HTML? Wenn ja, welche?
> 
> Wenn du XHTML brauchst, weißt du es. (Das ist u.a. der Fall, wenn du ein
> XML-System zur Verwaltung verwendest und/oder du Sachen aus anderen XML-
> Namespaces einfügen willst.)

ACK
 
> Ansonsten nimm HTML. Am besten gleich HTML 5, wobei du die neuen
> Elemente vorerst noch vermeidest.

Welche Vorteile hat Deiner Meinung nach HTML 5 (Working Draft) ohne 
Verwendung neuer Elemente gegenüber HTML 4.01 (Recommendation)?


PointedEars

Stefan Scholl wrote:

> Jakob Nielsen schlägt auch ein neues Fenster für PDF vor:
> http://www.useit.com/alertbox/open_new_windows.html

Dieses Argument wurde bereits widerlegt.

-- 
PointedEars

Gregor Kofler wrote:

> Stefan Scholl meinte:
>> Jakob Nielsen schlägt auch ein neues Fenster für PDF vor:
>> http://www.useit.com/alertbox/open_new_windows.html
> 
> Passt. Ein PDF ist keine Webseite. Und wird bei mir auch ganz korrekt
> *nicht* in einem Browserfenster angezeigt.

Und deshalb sind leere Browserfenster/-Tabs gut[tm]?  Seltsame Logik.

-- 
PointedEars

Arno Welzel wrote:

> Helmut Richter schrieb:
>> On Sun, 28 Mar 2010, Susanne Jäger wrote:
>>> was zu beweisen wäre. Und ob der Focuswechsel und die hundert
>>> geöffneten Fenster für den gemeinen Websurfer wirklich besser erfassbar
>>> sind, wage ich immer noch zu bezweifeln.
>> 
>> Es war ja nicht die Rede von hundert Fenstern, sondern davon, dass es
>> *auch mal* sinnvoll sein kann, ein neues Fenster oder einen neuen Tab zu
>> eröffnen. Beispiel: Die alte Seite enthält viel Information, vielleicht
>> aus einer Datenbank zusammengesucht, und die neue erklärt ein Detail
>> dazu. Wer jetzt die neue anklickt und vergisst, dass er dabei dem
>> Browser das Target angeben muss (etwa durch Wahl der Maustaste), der
>> kann damit nichts anfangen, weil er etwas erklärt bekommt, was er nicht
>> mehr sieht. Also *muss* er auf den Back-Button gehen, und dann geht
>> erstmal die Datenbanksuche ein zweites Mal los. In solchen Fällen wäre
>> es nicht vermessen, anzunehmen, dass der Nutzer die alte Seite weiterhin
>> griffbereit haben will. Und geklickt ist eben manchmal schneller als
>> nachgedacht.
> 
> In dieser konkreten Anwendung wäre ein DIV-Element, daß entsprechend
> plaziert wird - ganz ohne neues Fenster - vermutlich zielführender.

Ohne CSS/Scripting?

-- 
PointedEars

Am 2010-03-30 11:39, schrieb Stefan Scholl:

> Christoph Schneegans  wrote:
>> Susanne Jäger schrieb:
>>
>>> PDFs können in der Tat ein Problem sein, für die empfiehlt sogar
>>> Nielsen die target-Angabe.
>>
>> Tut er nicht. Er hatte bloß am Anfang keine Ahnung, daß es
>> "Content-Disposition: attachment" gibt, und war dann zu stolz,
>> seinen Fehler einzugestehen und den blödsinnigen Artikel
>> <http://www.useit.com/alertbox/open_new_windows.html>
>> zurückzuziehen.
>
> Wie würde ein Normalbürger diese Header-Zeile einfügen, wenn er
> nur statische Seiten hat und keinen Zugriff auf die
> Server-Config?

Welche Web-Hosting-Angebote erlauben nur statische Seiten?

Sobald PHP geht, was wohl auf die Mehrzahl der aktuellen 
Web-Hosting-Angebote zutreffen dürfte, kann man den Header auch per 
header()-Anweisugn in einem entsprechenden PHP-Script einfügen, daß für 
die Auslieferung von PDF-Dateien verwendet wird.


-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

Arno Welzel  wrote:
> Am 2010-03-30 11:39, schrieb Stefan Scholl:
>> Wie würde ein Normalbürger diese Header-Zeile einfügen, wenn er
>> nur statische Seiten hat und keinen Zugriff auf die
>> Server-Config?
> 
> Welche Web-Hosting-Angebote erlauben nur statische Seiten?
> 
> Sobald PHP geht, was wohl auf die Mehrzahl der aktuellen 
> Web-Hosting-Angebote zutreffen dürfte, kann man den Header auch per 
> header()-Anweisugn in einem entsprechenden PHP-Script einfügen, daß für 
> die Auslieferung von PDF-Dateien verwendet wird.

Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
programmieren?


Und was ist mit denen, die es nicht können? Viele sind froh, wenn
sie überhaupt die Inhalte mit Dreamweaver aktualisieren können.



-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

Thomas 'PointedEars' Lahn  schrieb/wrote:
> Und deshalb sind leere Browserfenster/-Tabs gut[tm]?  Seltsame Logik.

Man kann das Fenster auch per Javascript automatisch zu machen. Kommt  
besonders gut, wenn der Benutzer ein Plugin für den Dateityp hat.

Claus

Stefan Scholl  schrieb/wrote:
> Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
> programmieren?

Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere  
Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück  
ignorieren dich sogar noch Suchmaschinen.

Claus

Stefan Scholl wrote:

> Arno Welzel  wrote:
>> Am 2010-03-30 11:39, schrieb Stefan Scholl:
>>> Wie würde ein Normalbürger diese Header-Zeile einfügen, wenn er
>>> nur statische Seiten hat und keinen Zugriff auf die
>>> Server-Config?
>> 
>> Welche Web-Hosting-Angebote erlauben nur statische Seiten?
>> 
>> Sobald PHP geht, was wohl auf die Mehrzahl der aktuellen
>> Web-Hosting-Angebote zutreffen dürfte, kann man den Header auch per
>> header()-Anweisugn in einem entsprechenden PHP-Script einfügen, daß für
>> die Auslieferung von PDF-Dateien verwendet wird.
> 
> Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
> programmieren?

Nein, Du kannst auch .htaccess & friends verwenden um das "Content-Type"-
Headerfeld geeignet zu setzen.  Falls auch das bei Dir nicht geht und der 
Provider seine Serverkonfiguration vorsätzlich versaut hat (etwa PDFs mit 
text/plain ausliefert), beschwer' Dich beim jetzigen oder such Dir einen 
besseren Provider.  (Am Preis-Leistung-Verhältnis kann's ja dann nicht 
liegen.)

> Und was ist mit denen, die es nicht können? Viele sind froh, wenn
> sie überhaupt die Inhalte mit Dreamweaver aktualisieren können.

Die sollen mindestens eins davon machen oder die Finger von so fürchterbar 
komplizierten Sachen wie PDF im Web lassen.  Zwar kann im Web jeder ein 
Autor, aber nicht jeder muss ein $BERUEHMTER_SCHRIFTSTELLER sein.

Was übrigens Content-Disposition betrifft: Als Nielsen den Artikel schrieb 
(2005) war IE 5.5 noch relativ verbreitet, und der hat da einen Bug:

<http://support.microsoft.com/?scid=kb%3Ben-us%3B279667&x=8&y=8>


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Claus Färber wrote:

> Thomas 'PointedEars' Lahn  schrieb/wrote:
>> Und deshalb sind leere Browserfenster/-Tabs gut[tm]?  Seltsame Logik.

<ironie> 
> Man kann das Fenster auch per Javascript automatisch zu machen. Kommt
> besonders gut, wenn der Benutzer ein Plugin für den Dateityp hat.

Eben.  Genau deshalb installiert und konfiguriert man sich doch sowas.
</ironie>


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Claus Färber wrote:

> Stefan Scholl  schrieb/wrote:
>> Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
>> programmieren?
> 
> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere
> Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück
> ignorieren dich sogar noch Suchmaschinen.

FUD


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Claus Färber  wrote:
> Stefan Scholl  schrieb/wrote:
>> Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
>> programmieren?
> 
> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere  
> Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück  
> ignorieren dich sogar noch Suchmaschinen.

Suchmaschinen klauen eh nur Firmengeheimnisse. :-)



-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

Claus Färber schrieb:

> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere  
> Auslieferung deiner Seiten, 

Das trifft nur dann zu, wenn man _jede_ Seite durch den PHP-Interpreter 
dreht. Das ist im konkreten Fall aber überhaupt nicht notwendig.

Tatsächlich ist eine webserverseitige Lösung tatsächlich vorzuziehen.

 > schlechteres Caching

Das magst du bitte belegen.

 > und mit etwas Glück ignorieren dich sogar noch Suchmaschinen.

Das auch.

Gruß
Christoph

Stefan Scholl schrieb:

> Arno Welzel  wrote:
>> Am 2010-03-30 11:39, schrieb Stefan Scholl:
>>> Wie würde ein Normalbürger diese Header-Zeile einfügen, wenn er
>>> nur statische Seiten hat und keinen Zugriff auf die
>>> Server-Config?
>> Welche Web-Hosting-Angebote erlauben nur statische Seiten?
>>
>> Sobald PHP geht, was wohl auf die Mehrzahl der aktuellen 
>> Web-Hosting-Angebote zutreffen dürfte, kann man den Header auch per 
>> header()-Anweisugn in einem entsprechenden PHP-Script einfügen, daß für 
>> die Auslieferung von PDF-Dateien verwendet wird.
> 
> Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
> programmieren?

Das sind zwei Befehle in PHP. Die kann man notfalls leicht
recherchieren, wenn man nach "Content-Disposition in PHP" sucht.

> Und was ist mit denen, die es nicht können? Viele sind froh, wenn
> sie überhaupt die Inhalte mit Dreamweaver aktualisieren können.

Dann sollen sie eben jemanden fragen, der sich auskennt oder es lernen.

Unkenntnis über ein Thema bei Laien ist keine gute Begründung,
technische Standards zu ignorieren oder davon abzuraten.


-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

Claus Färber schrieb:

> Stefan Scholl  schrieb/wrote:
>> Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
>> programmieren?
> 
> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere  
> Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück  
> ignorieren dich sogar noch Suchmaschinen.

Das ist schlicht Unsinn.


-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

On Tue, 30 Mar 2010 21:30:59 퍽, Arno Welzel   wrote:

> Claus Färber schrieb:
>> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere
>> Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück
>> ignorieren dich sogar noch Suchmaschinen.
>
> Das ist schlicht Unsinn.

Wieso?

PHP-genertieres HTML dürfte immer langsamer ausgeliefert werden, als  statisches, falls es dasselbe HTML ist.
Beim Caching weiß ich nicht, was PHP da für Header setzt.

Stefan Scholl  schrieb:
> Christoph Schneegans  wrote:
>> Susanne Jäger schrieb:
>> 
>>> PDFs können in der Tat ein Problem sein, für die empfiehlt sogar
>>> Nielsen die target-Angabe.
>> 
>> Tut er nicht. Er hatte bloß am Anfang keine Ahnung, daß es
>> "Content-Disposition: attachment" gibt, und war dann zu stolz,
>> seinen Fehler einzugestehen und den blödsinnigen Artikel
>> <http://www.useit.com/alertbox/open_new_windows.html>
>> zurückzuziehen.
> 
> Wie würde ein Normalbürger diese Header-Zeile einfügen, wenn er
> nur statische Seiten hat und keinen Zugriff auf die
> Server-Config?

Wenn der Server geeignet konfiguriert wurde (bei Apache ab 1.1:
mod_cern_meta), dann muß er er ihn nur in das zum PDF gehörige
(optionale) Metadatenfile einfügen.

Ralf
-- 
Ralf Döblitz   *   Schapenstraße 6   *   38104 Braunschweig   *   Germany
Phone: +49-531-2361223   Fax: +49-531-2361224  mailto:doeblitz@doeblitz.net
Homepage: http://www.escape.de/users/selene/
Mit UTF-8 kann man gleichzeitig äöüßÄÖÜæœłø‱¼½¾¤¹²³¢€£¥¶§¬÷×±©®™¡¿ verwenden…

Chris Seidel wrote:

> On Tue, 30 Mar 2010 21:30:59 +0300, Arno Welzel   
> wrote:
> 
>> Claus Färber schrieb:
>>> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere
>>> Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück
>>> ignorieren dich sogar noch Suchmaschinen.
>>
>> Das ist schlicht Unsinn.
> 
> Wieso?
> 
> PHP-genertieres HTML dürfte immer langsamer ausgeliefert werden

Das ist so pauschal falsch! Wenn man PHP serverseitig dynamische Inhalte
Cachen läst kommt man bis auf die jeweils einmal notwendige
Cacheerzeugung auf dem Server auch nich langsamer ans Ziel. Es sei den Du
willst jetzt über ein paar Milisekunden streiten, die aber im
Webserverumfeld nicht von relevanz sind

> Beim Caching weiß ich nicht, was PHP da für Header setzt.

Die die der Entwickler in seinem Code definiert.

MfG, Ulf

Chris Seidel schrieb:

> On Tue, 30 Mar 2010 21:30:59 +0300, Arno Welzel   
> wrote:
> 
>> Claus Färber schrieb:
>>> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere
>>> Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück
>>> ignorieren dich sogar noch Suchmaschinen.
>> Das ist schlicht Unsinn.
> 
> Wieso?
> 
> PHP-genertieres HTML dürfte immer langsamer ausgeliefert werden, als  
> statisches, falls es dasselbe HTML ist.

Der Unterschied dürfte bestenfalls messbar sein - und bei so simplen
aktionen, wie dem Hinzufügen eines Headers und anschließendem senden
eines Dateiinhaltes wird der Unterschied so gering ausfallen, daß es
kaum praxisrelevant ist.

> Beim Caching weiß ich nicht, was PHP da für Header setzt.

Keine, die explizit das Caching "verschlechtern" würden. Auch kann man,
wenn man Wert darauf legt, selbstverständlich auch das caching
entsprechend beeinflussen.

Die Aussage "Seiten, die über PHP ausgeliefert werden, werden schlechter
gecached" ist so pauschal einfach falsch.

Auch die Behauptung, Suchmaschinen würde PHP-Seiten ignorieren, ist
ebenso falsch.


-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

Stefan Scholl meinte:
> Gregor Kofler  wrote:
>> Stefan Scholl meinte:
>>> Jakob Nielsen schlägt auch ein neues Fenster für PDF vor:
>>> http://www.useit.com/alertbox/open_new_windows.html
>> Passt. Ein PDF ist keine Webseite. Und wird bei mir auch ganz korrekt 
>> *nicht* in einem Browserfenster angezeigt.
> 
> Redest Du von Deiner persönlichen Browser-Einstellung, oder
> benutzt Du "Content-Disposition: Attachment" auf Webseiten?

Meine Einstellungen (die Linux Distro stellt auch kein Browser-Plugin 
für PDFs zur Verfügung).

> 
> Letzteres habe ich noch nicht für statische Files gemacht, nur
> generierte Dokumente. Aber Apaches mod_headers könnte das sicher
> gut erledigen. ("HTTP Headers"-Modul in Nginx und was sonst so in
> anderen Servern gibt.)

Hast du ohnedies schon gefunden. Aber das Ganze finde ich blödsinnig: 
Ich biete PDFs an, und umschiffe die (mM unglücklichen) Präferenzen des 
Users wieder, in dem ich den PDF-Download erzwinge.

Gregor


-- 
http://www.gregorkofler.com

Gregor Kofler  wrote:

> Ich biete PDFs an, und umschiffe die (mM unglücklichen) Präferenzen des
> Users wieder, in dem ich den PDF-Download erzwinge.

Gibt's irgendwo ein Beispiel für dieses "erzwingen"?

Ich wüsste gerne, wie du das machst und ob sich mein Browser fügt oder
erfolgreich dagegen wehrt.

Mit besten Grüßen, 
Mike Nolte

-- 
E-Mail an news.0902@mikenolte.de wird nur zugestellt, wenn die
Betreffzeile "Usenetartikel" ohne Anführungszeichen lautet.
<mailto:news.0902@mikenolte.de?subject=Usenetartikel>

Mike Nolte meinte:

> Gregor Kofler  wrote:
> 
>> Ich biete PDFs an, und umschiffe die (mM unglücklichen) Präferenzen des
>> Users wieder, in dem ich den PDF-Download erzwinge.
> 
> Gibt's irgendwo ein Beispiel für dieses "erzwingen"?
> 
> Ich wüsste gerne, wie du das machst und ob sich mein Browser fügt oder
> erfolgreich dagegen wehrt.

Etwa per PHP, indem man per header() einen ebensolchen setzt und dann 
das PDF-File an Client weiterreicht. Oder per .htaccess mit sowas (untestet)

<Files *.pdf>
   ForceType application/octet-stream
   Header set Content-Disposition attachment
</Files>

Die meisten aktuellen Browser werden sich dem wohl fügen.

Gregor


-- 
http://www.gregorkofler.com

Am 2010-03-30 13:48, schrieb Thomas 'PointedEars' Lahn:

> Arno Welzel wrote:
>
>> Helmut Richter schrieb:
>>> On Sun, 28 Mar 2010, Susanne Jäger wrote:
>>>> was zu beweisen wäre. Und ob der Focuswechsel und die hundert
>>>> geöffneten Fenster für den gemeinen Websurfer wirklich besser erfassbar
>>>> sind, wage ich immer noch zu bezweifeln.
>>>
>>> Es war ja nicht die Rede von hundert Fenstern, sondern davon, dass es
>>> *auch mal* sinnvoll sein kann, ein neues Fenster oder einen neuen Tab zu
>>> eröffnen. Beispiel: Die alte Seite enthält viel Information, vielleicht
>>> aus einer Datenbank zusammengesucht, und die neue erklärt ein Detail
>>> dazu. Wer jetzt die neue anklickt und vergisst, dass er dabei dem
>>> Browser das Target angeben muss (etwa durch Wahl der Maustaste), der
>>> kann damit nichts anfangen, weil er etwas erklärt bekommt, was er nicht
>>> mehr sieht. Also *muss* er auf den Back-Button gehen, und dann geht
>>> erstmal die Datenbanksuche ein zweites Mal los. In solchen Fällen wäre
>>> es nicht vermessen, anzunehmen, dass der Nutzer die alte Seite weiterhin
>>> griffbereit haben will. Und geklickt ist eben manchmal schneller als
>>> nachgedacht.
>>
>> In dieser konkreten Anwendung wäre ein DIV-Element, daß entsprechend
>> plaziert wird - ganz ohne neues Fenster - vermutlich zielführender.
>
> Ohne CSS/Scripting?

Ja.

Als "Fallback" kann man ja eine Variante einbauen, bei der die Seite neu 
geladen wird, aber für den ausgewählten Datensatz zusätzlich die 
Detailinformationen anzeigt - das dann als Anker, auf den verwiesen 
wird, so daß der Datensatz auch direkt sichtbar ist und der Benutzer 
nicht scrollen muss.

Etwa mit:

<a href="abfrage?showdetail&id=463#id463" 
onClick="showDetail(463);return false;">Detailinformationen</a>

Und in der dadurch erzeugten Ergebnisseite:

<a name="id463"></a> ...

Wer es komfortabler haben will, kann immer noch JavaScript aktivieren, 
wodurch dann eben die Details ohne Neuladen der Seite erscheinen - 
worauf man in einer einleitenden Erklärung zur Anwendung ja hinweisen kann.



-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

Claus Färber  wrote:
> Stefan Scholl  schrieb/wrote:
> > Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
> > programmieren?
> 
> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere  
> Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück  
> ignorieren dich sogar noch Suchmaschinen.

Damit die Suchmaschinen die Seiten (möglicherweise) ignorieren müssten diese
auch als dynamisch erkennbar sein. Aber man muss ja nicht mit URLs arbeiten
die auf /dynamicpage.php?bla=blubb&foo=bar enden sondern kann ja auch
/bla/blubb/foo/bar.html verwenden.

cu,
Manfred

-- 
| Manfred Schenk              | born between RFC638 and RFC640
| PGP-Keys unter              |
| http://www.ZEROByte.de/pgp/ | WWW: http://www.ZEROByte.de/

Gregor Kofler schrieb:

> Aber das Ganze finde ich blödsinnig: Ich biete PDFs an, und
> umschiffe die (mM unglücklichen) Präferenzen des Users wieder,
> in dem ich den PDF-Download erzwinge.
    ^
Na, der "Download" läßt sich wohl auch schlecht vermeiden. Aber
erzwingen tut "Content-Disposition: attachment" typischerweise gar
nichts; der Browser zeigt typischerweise "Öffnen" und "Speichern"
zur Auswahl an. Bequemer geht es doch gar nicht!

-- 
<http://schneegans.de/web/xhtml/> · Klare Antworten zu XHTML

Arno Welzel wrote:

> Thomas 'PointedEars' Lahn [wrote:]
>> Arno Welzel wrote:
>>> Helmut Richter schrieb:
>>>> On Sun, 28 Mar 2010, Susanne Jäger wrote:
>>>>> was zu beweisen wäre. Und ob der Focuswechsel und die hundert
>>>>> geöffneten Fenster für den gemeinen Websurfer wirklich besser
>>>>> erfassbar sind, wage ich immer noch zu bezweifeln.
>>>>
>>>> Es war ja nicht die Rede von hundert Fenstern, sondern davon, dass es
>>>> *auch mal* sinnvoll sein kann, ein neues Fenster oder einen neuen Tab
>>>> zu eröffnen. Beispiel: Die alte Seite enthält viel Information,
>>>> vielleicht aus einer Datenbank zusammengesucht, und die neue erklärt
>>>> ein Detail dazu. Wer jetzt die neue anklickt und vergisst, dass er
>>>> dabei dem Browser das Target angeben muss (etwa durch Wahl der
>>>> Maustaste), der kann damit nichts anfangen, weil er etwas erklärt
>>>> bekommt, was er nicht mehr sieht. Also *muss* er auf den Back-Button
>>>> gehen, und dann geht erstmal die Datenbanksuche ein zweites Mal los.
>>>> In solchen Fällen wäre es nicht vermessen, anzunehmen, dass der Nutzer
>>>> die alte Seite weiterhin griffbereit haben will. Und geklickt ist eben
>>>> manchmal schneller als nachgedacht.
>>>
>>> In dieser konkreten Anwendung wäre ein DIV-Element, daß entsprechend
>>> plaziert wird - ganz ohne neues Fenster - vermutlich zielführender.
>>
>> Ohne CSS/Scripting?
> 
> Ja.

Das denke ich nicht, Tim^WArno.

> Als "Fallback" kann man ja eine Variante einbauen, bei der die Seite neu
> geladen wird, aber für den ausgewählten Datensatz zusätzlich die
> Detailinformationen anzeigt - das dann als Anker, auf den verwiesen
> wird, so daß der Datensatz auch direkt sichtbar ist und der Benutzer
> nicht scrollen muss.
> 
> Etwa mit:
> 
> <a href="abfrage?showdetail&id=463#id463"
> onClick="showDetail(463);return false;">Detailinformationen</a>

Der Punkt hier war, dass *in keinem Fall* die bisherige Anzeige 
unzugänglich wird.  Deine Lösung leistet das nicht.
 
> Und in der dadurch erzeugten Ergebnisseite:
> 
> <a name="id463"></a> ...

Leere Anker sind böse[tm].
 
> Wer es komfortabler haben will, kann immer noch JavaScript aktivieren,

Du meinst: Script-Support nicht deaktivieren.  Der Benutzer hat diese Wahl 
aber nicht immer.  Konkret kann ein Benutzer hinter einem filternden Proxy 
im Browser einstellen was er will, sein Browser bekommt vom Script im 
Originalquelltext gar nicht erst etwas mit.  Ähnlich bei administrativ 
verordneten Systemrichtlinien, wo er gar nicht erst den entsprechenden 
Einstellungsdialog aufrufen kann.


PointedEars

Ulf Kadner  schrieb/wrote:
> Chris Seidel wrote:
>> PHP-genertieres HTML dürfte immer langsamer ausgeliefert werden
> Das ist so pauschal falsch! Wenn man PHP serverseitig dynamische
> Inhalte Cachen läst kommt man bis auf die jeweils einmal notwendige
> Cacheerzeugung auf dem Server auch nich langsamer ans Ziel. Es sei den
> Du willst jetzt über ein paar Milisekunden streiten, die aber im
> Webserverumfeld nicht von relevanz sind

Gemessen in Rechenzeit ist es immer langsamer. Ein einzelner Benutzer
merkt es vielleicht nicht, aber das auch nur, solange der Server kaum
Last hat.

Caching nutzt da auch nichts, ein PHP-Skript läuft immer langsamer als
sendfile(3).

>> Beim Caching weiß ich nicht, was PHP da für Header setzt.
> Die die der Entwickler in seinem Code definiert.

Und du siehst das Problem daran nicht?

Mal abgesehen davon, dass nicht nur die gesendeten Header das Problem  
sind, sondern auch die fehlende Interpretation der empfangenen.

Claus

Claus Färber schrieb:

> Ulf Kadner  schrieb/wrote:
>> Chris Seidel wrote:
>>> PHP-genertieres HTML dürfte immer langsamer ausgeliefert werden
>> Das ist so pauschal falsch! Wenn man PHP serverseitig dynamische
>> Inhalte Cachen läst kommt man bis auf die jeweils einmal notwendige
>> Cacheerzeugung auf dem Server auch nich langsamer ans Ziel. Es sei den
>> Du willst jetzt über ein paar Milisekunden streiten, die aber im
>> Webserverumfeld nicht von relevanz sind
> 
> Gemessen in Rechenzeit ist es immer langsamer. Ein einzelner Benutzer
> merkt es vielleicht nicht, aber das auch nur, solange der Server kaum
> Last hat.
> 
> Caching nutzt da auch nichts, ein PHP-Skript läuft immer langsamer als
> sendfile(3).

Das ist richtig. Der Unterschied ist aber trotzdem immer noch ein einem
Bereich, der erst bei etlichen Millionen Zugriffen pro Monat spürbar
wird. BTDT.

>>> Beim Caching weiß ich nicht, was PHP da für Header setzt.
>> Die die der Entwickler in seinem Code definiert.
> 
> Und du siehst das Problem daran nicht?

Welches Problem? Dass der Entwickler Mist baut? ;-)

> Mal abgesehen davon, dass nicht nur die gesendeten Header das Problem  
> sind, sondern auch die fehlende Interpretation der empfangenen.

Auch das ist nur eine Frage der Umsetzung. Man kann in PHP sehr wohl
If-Not-Modified-Since überprüfen und entsprechende Antworten erzeugen.


-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

Manfred Schenk schrieb:

> Claus Färber  wrote:
>> Stefan Scholl  schrieb/wrote:
>>> Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
>>> programmieren?
>> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere  
>> Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück  
>> ignorieren dich sogar noch Suchmaschinen.
> 
> Damit die Suchmaschinen die Seiten (möglicherweise) ignorieren müssten diese
> auch als dynamisch erkennbar sein. Aber man muss ja nicht mit URLs arbeiten
> die auf /dynamicpage.php?bla=blubb&foo=bar enden sondern kann ja auch
> /bla/blubb/foo/bar.html verwenden.

Ja - z.B. mit Apache-Rewrite-Regeln, die auch in einer .htaccess-Datei
stehen können. Meine Domains arbeiten nur so - von aussen ist praktisch
nicht erkennbar, daß sämtliche Seiten dynamisch erzeugt sind.


-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

Thomas 'PointedEars' Lahn schrieb:

> Arno Welzel wrote:
> 
>> Thomas 'PointedEars' Lahn [wrote:]
>>> Arno Welzel wrote:
>>>> Helmut Richter schrieb:
>>>>> On Sun, 28 Mar 2010, Susanne Jäger wrote:
>>>>>> was zu beweisen wäre. Und ob der Focuswechsel und die hundert
>>>>>> geöffneten Fenster für den gemeinen Websurfer wirklich besser
>>>>>> erfassbar sind, wage ich immer noch zu bezweifeln.
>>>>> Es war ja nicht die Rede von hundert Fenstern, sondern davon, dass es
>>>>> *auch mal* sinnvoll sein kann, ein neues Fenster oder einen neuen Tab
>>>>> zu eröffnen. Beispiel: Die alte Seite enthält viel Information,
>>>>> vielleicht aus einer Datenbank zusammengesucht, und die neue erklärt
>>>>> ein Detail dazu. Wer jetzt die neue anklickt und vergisst, dass er
>>>>> dabei dem Browser das Target angeben muss (etwa durch Wahl der
>>>>> Maustaste), der kann damit nichts anfangen, weil er etwas erklärt
>>>>> bekommt, was er nicht mehr sieht. Also *muss* er auf den Back-Button
>>>>> gehen, und dann geht erstmal die Datenbanksuche ein zweites Mal los.
>>>>> In solchen Fällen wäre es nicht vermessen, anzunehmen, dass der Nutzer
>>>>> die alte Seite weiterhin griffbereit haben will. Und geklickt ist eben
>>>>> manchmal schneller als nachgedacht.
>>>> In dieser konkreten Anwendung wäre ein DIV-Element, daß entsprechend
>>>> plaziert wird - ganz ohne neues Fenster - vermutlich zielführender.
>>> Ohne CSS/Scripting?
>> Ja.
> 
> Das denke ich nicht, Tim^WArno.
> 
>> Als "Fallback" kann man ja eine Variante einbauen, bei der die Seite neu
>> geladen wird, aber für den ausgewählten Datensatz zusätzlich die
>> Detailinformationen anzeigt - das dann als Anker, auf den verwiesen
>> wird, so daß der Datensatz auch direkt sichtbar ist und der Benutzer
>> nicht scrollen muss.
>>
>> Etwa mit:
>>
>> <a href="abfrage?showdetail&id=463#id463"
>> onClick="showDetail(463);return false;">Detailinformationen</a>
> 
> Der Punkt hier war, dass *in keinem Fall* die bisherige Anzeige 
> unzugänglich wird.  Deine Lösung leistet das nicht.

Nur, wenn man das verschieben des angezeigten Inhalts aufgrund als
"unzugänglich werden" ansieht.

>> Und in der dadurch erzeugten Ergebnisseite:
>>
>> <a name="id463"></a> ...
> 
> Leere Anker sind böse[tm].

Dann eben den Anker entsprechend erweitern auf den Detailbereich, der
angezeigt wird.

>> Wer es komfortabler haben will, kann immer noch JavaScript aktivieren,
> 
> Du meinst: Script-Support nicht deaktivieren.  Der Benutzer hat diese Wahl 
> aber nicht immer.  Konkret kann ein Benutzer hinter einem filternden Proxy 
> im Browser einstellen was er will, sein Browser bekommt vom Script im 
> Originalquelltext gar nicht erst etwas mit.  Ähnlich bei administrativ 
> verordneten Systemrichtlinien, wo er gar nicht erst den entsprechenden 
> Einstellungsdialog aufrufen kann.

Dann also zurück zu plain HTML ohne CSS und Bilder, weil ja potentiell
alles abschaltbar und filterbar ist und ein Angebot dann trotzdem 100%
funktionieren muss?


-- 
http://arnowelzel.de
http://de-rec-fahrrad.de

On Thu, 01 Apr 2010 08:58:13 Arno Welzel wrote:
> > Mal abgesehen davon, dass nicht nur die gesendeten Header das Problem  
> > sind, sondern auch die fehlende Interpretation der empfangenen.
> 
> Auch das ist nur eine Frage der Umsetzung. Man kann in PHP sehr wohl
> If-Not-Modified-Since überprüfen und entsprechende Antworten erzeugen.
 
Das wuerde ich dann allerdings nicht mehr mit:

| Das sind zwei Befehle in PHP. Die kann man notfalls leicht
| recherchieren, wenn man nach "Content-Disposition in PHP" sucht.

...beschreiben.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

(Sloganizer)

Stefan Froehlich <Stefan+Usenet@froehlich.priv.at> wrote:
> On Thu, 01 Apr 2010 08:58:13 Arno Welzel wrote:
>> > Mal abgesehen davon, dass nicht nur die gesendeten Header das Problem  
>> > sind, sondern auch die fehlende Interpretation der empfangenen.
>> 
>> Auch das ist nur eine Frage der Umsetzung. Man kann in PHP sehr wohl
>> If-Not-Modified-Since überprüfen und entsprechende Antworten erzeugen.
> 
> Das wuerde ich dann allerdings nicht mehr mit:
> 
> | Das sind zwei Befehle in PHP. Die kann man notfalls leicht
> | recherchieren, wenn man nach "Content-Disposition in PHP" sucht.
> 
> ...beschreiben.

Sind mehr als 2, aber weniger als erwartet. Laut RFC 2616 reicht
es den String-Wert zu vergleichen. Man muss also nur den
gelieferten Wert von If-Not-Modified-Since mit dem Datum
vergleichen, welches man selbst ausgibt. Keine Parserei nötig.



-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
<!--[if IE 6]><script>for(x in document.open);</script><![endif]-->

On Wed, 31 Mar 2010 20:08:00 +0200, Claus Färber wrote:

> Ulf Kadner  schrieb/wrote:
>> Chris Seidel wrote:
>>> PHP-genertieres HTML dürfte immer langsamer ausgeliefert werden
>> Das ist so pauschal falsch! Wenn man PHP serverseitig dynamische
>> Inhalte Cachen läst kommt man bis auf die jeweils einmal notwendige
>> Cacheerzeugung auf dem Server auch nich langsamer ans Ziel. Es sei den
>> Du willst jetzt über ein paar Milisekunden streiten, die aber im
>> Webserverumfeld nicht von relevanz sind
> 
> Gemessen in Rechenzeit ist es immer langsamer. Ein einzelner Benutzer
> merkt es vielleicht nicht, aber das auch nur, solange der Server kaum
> Last hat.

Ach herrje :-)
Schon mal was von der Auswahl eines Servers gehört der dem notwendigen
Datendurchsatz angemessen ist? Ist doch ganz einfach. Wenn Dein server
bereits deswegen die Krätsche macht, nur weil starker verkehr auf diesem
herscht und ein paar *Millisekunden* relevant werden sagt Dir jeder
vernünftige Admin das es Zeit wird sich nach was neuem umzusehen.

Ist reichlich sinnfrei mit solchen Argumenten eine Technik verteufeln zu
wollen die keine schlechte ist.

> Caching nutzt da auch nichts, ein PHP-Skript läuft immer langsamer als
> sendfile(3).

Natürlich nutzt Caching was. Sowas kann man sogar vollkommen unanhängig
von PHP aufs Dateisystem aufsetzen.

>>> Beim Caching weiß ich nicht, was PHP da für Header setzt.
>> Die die der Entwickler in seinem Code definiert.
> 
> Und du siehst das Problem daran nicht?

Und Du meinst das schlechte Entwickler mit suboptimalen bis schlechten
Code wären relevant und eine Technik zu bewerten?

Dann wirf einfach Deinen Rechner und alles was dazugehört weg. Könnte ja
suboptimal entwickelt sein.

> Mal abgesehen davon, dass nicht nur die gesendeten Header das Problem  
> sind

welches Problem sind die gesendeten Header? Jeder der sich durch eine
fehlende Implementierung in irgend einer beliebigen Programmiersprache
nicht wohlfühlt ist frei genug um diese zu implementieren oder was
anderweitig bereits fertiges zu nutzen.

MfG

Arno Welzel wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Arno Welzel wrote:
>>> Thomas 'PointedEars' Lahn [wrote:]
>>>> Arno Welzel wrote:
>>>>> Helmut Richter schrieb:
>>>>>> On Sun, 28 Mar 2010, Susanne Jäger wrote:
>>>>>>> was zu beweisen wäre. Und ob der Focuswechsel und die hundert
>>>>>>> geöffneten Fenster für den gemeinen Websurfer wirklich besser
>>>>>>> erfassbar sind, wage ich immer noch zu bezweifeln.
>>>>>> Es war ja nicht die Rede von hundert Fenstern, sondern davon, dass
>>>>>> es *auch mal* sinnvoll sein kann, ein neues Fenster oder einen neuen
>>>>>> Tab zu eröffnen. Beispiel: Die alte Seite enthält viel Information,
>>>>>> vielleicht aus einer Datenbank zusammengesucht, und die neue erklärt
>>>>>> ein Detail dazu. Wer jetzt die neue anklickt und vergisst, dass er
>>>>>> dabei dem Browser das Target angeben muss (etwa durch Wahl der
>>>>>> Maustaste), der kann damit nichts anfangen, weil er etwas erklärt
>>>>>> bekommt, was er nicht mehr sieht. Also *muss* er auf den Back-Button
>>>>>> gehen, und dann geht erstmal die Datenbanksuche ein zweites Mal los.
>>>>>> In solchen Fällen wäre es nicht vermessen, anzunehmen, dass der
>>>>>> Nutzer die alte Seite weiterhin griffbereit haben will. Und geklickt
>>>>>> ist eben manchmal schneller als nachgedacht.
>>>>> In dieser konkreten Anwendung wäre ein DIV-Element, daß entsprechend
>>>>> plaziert wird - ganz ohne neues Fenster - vermutlich zielführender.
>>>> Ohne CSS/Scripting?
>>> Ja.
>> 
>> Das denke ich nicht, Tim^WArno.
>> 
>>> Als "Fallback" kann man ja eine Variante einbauen, bei der die Seite
>>> neu geladen wird, aber für den ausgewählten Datensatz zusätzlich die
>>> Detailinformationen anzeigt - das dann als Anker, auf den verwiesen
>>> wird, so daß der Datensatz auch direkt sichtbar ist und der Benutzer
>>> nicht scrollen muss.
>>>
>>> Etwa mit:
>>>
>>> <a href="abfrage?showdetail&id=463#id463"
>>> onClick="showDetail(463);return false;">Detailinformationen</a>
>> 
>> Der Punkt hier war, dass *in keinem Fall* die bisherige Anzeige
>> unzugänglich wird.  Deine Lösung leistet das nicht.
> 
> Nur, wenn man das verschieben des angezeigten Inhalts aufgrund als
> "unzugänglich werden" ansieht.

Parse error.  In jedem Fall solltest Du Dir die Voraussetzungen nochmal in 
Ruhe durchlesen, siehe oben.

>>> Wer es komfortabler haben will, kann immer noch JavaScript aktivieren,
>> 
>> Du meinst: Script-Support nicht deaktivieren.  Der Benutzer hat diese
>> Wahl aber nicht immer.  Konkret kann ein Benutzer hinter einem
>> filternden Proxy im Browser einstellen was er will, sein Browser bekommt
>> vom Script im Originalquelltext gar nicht erst etwas mit.  Ähnlich bei
>> administrativ verordneten Systemrichtlinien, wo er gar nicht erst den
>> entsprechenden Einstellungsdialog aufrufen kann.
> 
> Dann also zurück zu plain HTML ohne CSS und Bilder, weil ja potentiell
> alles abschaltbar und filterbar ist und ein Angebot dann trotzdem 100%
> funktionieren muss?

Nein, Du missverstehst.


PointedEars
-- 
Dann mußt Du aber eine andere DTD in den Dogtype eintragen,
weil Dich sonst das W3C beißt.

(Georg Maaß in dcljs <an4mm7$aur11$2@ID-3551.news.dfncis.de>)

Gregor Kofler wrote:

> Stefan Scholl meinte:
>> Gregor Kofler  wrote:
>>> Stefan Scholl meinte:
>>>> Jakob Nielsen schlägt auch ein neues Fenster für PDF vor:
>>>> http://www.useit.com/alertbox/open_new_windows.html
>>> Passt. Ein PDF ist keine Webseite. Und wird bei mir auch ganz korrekt
>>> *nicht* in einem Browserfenster angezeigt.
>> Redest Du von Deiner persönlichen Browser-Einstellung, oder
>> benutzt Du "Content-Disposition: Attachment" auf Webseiten?
> 
> Meine Einstellungen (die Linux Distro stellt auch kein Browser-Plugin
> für PDFs zur Verfügung).

Letzteres glaub' ich nicht so ganz.  Mozplugger+Evince funktioniert in 
Iceweasel recht gut.

>> Letzteres habe ich noch nicht für statische Files gemacht, nur
>> generierte Dokumente. Aber Apaches mod_headers könnte das sicher
>> gut erledigen. ("HTTP Headers"-Modul in Nginx und was sonst so in
>> anderen Servern gibt.)
> 
> Hast du ohnedies schon gefunden. Aber das Ganze finde ich blödsinnig:
> Ich biete PDFs an, und umschiffe die (mM unglücklichen) Präferenzen des
> Users wieder, in dem ich den PDF-Download erzwinge.

Sofern ich Dich da richtig verstehe, dass Du den PDF-Dateidownload 
erzwingen willst:

Ich finde es als Benutzer reichlich anmassend von Dir, meine Präferenzen 
ohne Not umgehen zu wollen.  Ob meine Präferenzen für mich sinnvoll sind 
oder nicht, darfst Du schon mir überlassen.  Ich habe jedenfalls keinen 
Bock, jedes PDF-Dokument, das im Web verlinkt ist und ich ansehen will, 
erst komplett auf meine Platte herunterladen zu müssen.  Wenn ich es als 
Datei speichern will, dann sag ich das dem Programm schon.


HTH

PointedEars

Stefan Scholl  schrieb/wrote:
> Sind mehr als 2, aber weniger als erwartet. Laut RFC 2616 reicht es
> den String-Wert zu vergleichen. Man muss also nur den gelieferten Wert
> von If-Not-Modified-Since mit dem Datum vergleichen, welches man
> selbst ausgibt. Keine Parserei nötig.

Klar, man kann natürlich die Funktionen des Webservers in PHP  
nachprogrammieren.

Claus

Ulf Kadner  schrieb/wrote:
> On Wed, 31 Mar 2010 20:08:00 +0200, Claus Färber wrote:
>> Mal abgesehen davon, dass nicht nur die gesendeten Header das Problem
>> sind

> welches Problem sind die gesendeten Header?

Es sind weniger als der Server generieren würde. Da fehlen dann so
lustige Header wie "ETag" oder "Last-Modified".

Dass dann die Auswertung von "If-Modified-Since", "Accept-Range" & Co.
fehlt, wurde ja schon angesprochen.

<sarkasmus>
Schon klar, das braucht man doch alles nicht. Was interessiert mich denn
schon die Server-Belastung bei Traffic oder CPU-Zeit? Ich habe
schließlich "Unlimited Traffic". Modem-Nutzer oder GPRS-Yuppies können
mich außerdem mal.
</sarkasmus>

Claus

Ulf Kadner  schrieb/wrote:
> On Wed, 31 Mar 2010 20:08:00 +0200, Claus Färber wrote:
>> Gemessen in Rechenzeit ist es immer langsamer. Ein einzelner Benutzer
>> merkt es vielleicht nicht, aber das auch nur, solange der Server kaum
>> Last hat.

> Ach herrje :-) Schon mal was von der Auswahl eines Servers gehört der
> dem notwendigen Datendurchsatz angemessen ist? Ist doch ganz einfach.
> Wenn Dein server bereits deswegen die Krätsche macht, nur weil starker
> verkehr auf diesem herscht und ein paar *Millisekunden* relevant
> werden sagt Dir jeder vernünftige Admin das es Zeit wird sich nach was
> neuem umzusehen.

Neue Hardware kostet aber Geld. Das sind Kosten, die man vermeiden kann,
wenn man von Anfang an auf die ressourcensparendste Lösung setzt.

Wenn man allerdings erst einmal ein großes System mit PHP aufgebaut hat,
ist es zu spät. Da wäre die Umstellung dann zu aufwändig.

>> Caching nutzt da auch nichts, ein PHP-Skript läuft immer langsamer
>> als sendfile(3).

> Natürlich nutzt Caching was. Sowas kann man sogar vollkommen
> unanhängig von PHP aufs Dateisystem aufsetzen.

*sigh* Caching in PHP hat nur den Namen und eine Grundidee damit
gemeinsam. Vergleiche bitte keine Äpfel und Birnen.

Es ist einfach um Größenordnungen ineffizienter, ein Programm laufen zu
lassen (egal ob PHP, compiliertes CGI, oder ähnlich) und dieses die
Daten ausgeben zu lassen, als einfach sendfile oder eine vergleichbare
Funktion aufzurufen.

Selbst wenn das Programm sendfile benutzt, hat es immer noch keine
direkte Verbindung zum Netzwerk.

Claus

Thomas 'PointedEars' Lahn meinte:
> Gregor Kofler wrote:
> 
>> Stefan Scholl meinte:
>>> Gregor Kofler  wrote:
>>>> Stefan Scholl meinte:
>>>>> Jakob Nielsen schlägt auch ein neues Fenster für PDF vor:
>>>>> http://www.useit.com/alertbox/open_new_windows.html
>>>> Passt. Ein PDF ist keine Webseite. Und wird bei mir auch ganz korrekt
>>>> *nicht* in einem Browserfenster angezeigt.
>>> Redest Du von Deiner persönlichen Browser-Einstellung, oder
>>> benutzt Du "Content-Disposition: Attachment" auf Webseiten?
>> Meine Einstellungen (die Linux Distro stellt auch kein Browser-Plugin
>> für PDFs zur Verfügung).
> 
> Letzteres glaub' ich nicht so ganz.  Mozplugger+Evince funktioniert in 
> Iceweasel recht gut.

Habe ich nie probiert. Ich habe eigentlich auf die automatisch mit dem 
Acrobat Reader installierten Plugins Bezug genommen.

>>> Letzteres habe ich noch nicht für statische Files gemacht, nur
>>> generierte Dokumente. Aber Apaches mod_headers könnte das sicher
>>> gut erledigen. ("HTTP Headers"-Modul in Nginx und was sonst so in
>>> anderen Servern gibt.)
>> Hast du ohnedies schon gefunden. Aber das Ganze finde ich blödsinnig:
>> Ich biete PDFs an, und umschiffe die (mM unglücklichen) Präferenzen des
>> Users wieder, in dem ich den PDF-Download erzwinge.
> 
> Sofern ich Dich da richtig verstehe, dass Du den PDF-Dateidownload 
> erzwingen willst:
> 
> Ich finde es als Benutzer reichlich anmassend von Dir, meine Präferenzen 
> ohne Not umgehen zu wollen.  Ob meine Präferenzen für mich sinnvoll sind 
> oder nicht, darfst Du schon mir überlassen.  Ich habe jedenfalls keinen 
> Bock, jedes PDF-Dokument, das im Web verlinkt ist und ich ansehen will, 
> erst komplett auf meine Platte herunterladen zu müssen.  Wenn ich es als 
> Datei speichern will, dann sag ich das dem Programm schon.

Nein, will ich nicht. Im Vorposting wurde mM "angeregt", dass man den 
Download ja immer noch erzwingen kann. PDFs biete ich einfach über 
"normale" Links an. (Ich mag aber PDFs im Browser-Fenster nicht - 
deshalb habe ich mich auch nie um eine "Plugin-Lösung" auf meinem OS 
bemüht.)

> HTH

Hmmm...

Gregor



-- 
http://www.gregorkofler.com

Gregor Kofler wrote:

> Thomas 'PointedEars' Lahn meinte:
>> Gregor Kofler wrote:
>>> [...] (die Linux Distro stellt auch kein Browser-Plugin für PDFs zur
>>> Verfügung).
>> Letzteres glaub' ich nicht so ganz.  Mozplugger+Evince funktioniert in
>> Iceweasel recht gut.
> 
> Habe ich nie probiert. Ich habe eigentlich auf die automatisch mit dem
> Acrobat Reader installierten Plugins Bezug genommen.

IIRC gibt es jedoch auch ein Adobe-Reader-Plugin für Linux-Systeme.
 
>>>> Letzteres habe ich noch nicht für statische Files gemacht, nur
>>>> generierte Dokumente. Aber Apaches mod_headers könnte das sicher
>>>> gut erledigen. ("HTTP Headers"-Modul in Nginx und was sonst so in
>>>> anderen Servern gibt.)
>>> Hast du ohnedies schon gefunden. Aber das Ganze finde ich blödsinnig:
>>> Ich biete PDFs an, und umschiffe die (mM unglücklichen) Präferenzen des
>>> Users wieder, in dem ich den PDF-Download erzwinge.
>> Sofern ich Dich da richtig verstehe, dass Du den PDF-Dateidownload
>> erzwingen willst:
>> [...]
> 
> Nein, will ich nicht. Im Vorposting wurde mM "angeregt", dass man den
> Download ja immer noch erzwingen kann. PDFs biete ich einfach über
> "normale" Links an.

ACK, dann sind wir uns da ja doch einig :)

> (Ich mag aber PDFs im Browser-Fenster nicht - deshalb habe ich mich auch
> nie um eine "Plugin-Lösung" auf meinem OS bemüht.)

Sofern man nicht Adobe Reader verwendet (welcher auch nach Schliessen des 
Fensters/Tabs mit dem PDF im Hintergrund bleibt und Speicher frisst) kann 
das recht praktisch sein, insbesondere bei grossen PDF-Dokumenten (die man 
dann je nach PDF-Reader nur soweit herunterladen muss, wie man sie liest).

-- 
PointedEars

Christoph Schneegans  wrote:
> Alex Prahl schrieb:
>> Denn die Erfahrung lehrt, dass viele User (wenn nicht sogar die
>> Mehrheit) die "Zurück"-Funktion des Browsers nicht kennen,
> 
> Lächerlich. "The Back button is ... the second-most used navigation
> feature", schrieb Nielsen schon vor 10 Jahren.

In der Zwischenzeit haben User schon die Adress-Leiste vergessen
und geben jede URL in die Suchmaschine ein.



-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
<!--[if IE 6]><script>for(x in document.open);</script><![endif]-->

* Stefan Scholl wrote:

> Christoph Schneegans  wrote:
>> Alex Prahl schrieb:
>>> Denn die Erfahrung lehrt, dass viele User (wenn nicht sogar die
>>> Mehrheit) die "Zurück"-Funktion des Browsers nicht kennen,
>> 
>> Lächerlich. "The Back button is ... the second-most used navigation
>> feature", schrieb Nielsen schon vor 10 Jahren.
> 
> In der Zwischenzeit haben User schon die Adress-Leiste vergessen und
> geben jede URL in die Suchmaschine ein.

Das ist mir in den letzten Jahren auch vermehrt aufgefallen; es gibt 
immer mehr Idioten, die „über Google ins Internet gehen“.

Die von der Bildzeitung eingeleitete und vom Deppen-TV (RTL u. Sat1/Pro7) 
fortgeführte Verblödungskampagne zeigt Wirkung. Offensichtlich taugt die 
Masse wirklich nur zum Sklaven, konditioniert auf Arbeit und Konsum.
Selbständiges Denken ist unerwünscht und wird auch von der Politik mit 
allen Mitteln verhindert. Langsam halten US-amerikanische Zustände in 
Europa Einkehr.

-- 
Jo

Josef M. Werner schrieb:

>> In der Zwischenzeit haben User schon die Adress-Leiste vergessen und
>> geben jede URL in die Suchmaschine ein.
>
> Das ist mir in den letzten Jahren auch vermehrt aufgefallen; es gibt
> immer mehr Idioten, die „über Google ins Internet gehen“.

nee, das verstehst du flasch: Google ist *das Internet*

zumindest bei einem Großteil meiner Klientel ;-(


bis die tage
   jochen

-- 
PS: bitte melden Sie sich, wenn Sie diese Nachricht NICHT erhalten haben!

Am 02.04.2010 14:19, schrieb Claus Färber:
> [...] auf die ressourcensparendste Lösung setzt.
> [...] ein großes System mit PHP aufgebaut hat

Klingt für mich nach einem Wiederspruch... :)

-- 
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann  wrote:
> Am 02.04.2010 14:19, schrieb Claus Färber:
>> [...] auf die ressourcensparendste Lösung setzt.
>> [...] ein großes System mit PHP aufgebaut hat
> 
> Klingt für mich nach einem Wiederspruch... :)

Also, in Hello-World-Benchmarks ist PHP immer sehr schnell ...

:-)


-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
<!--[if IE 6]><script>for(x in document.open);</script><![endif]-->

Christoph Herrmann  schrieb/wrote:
> Am 02.04.2010 14:19, schrieb Claus Färber:
>> [...] auf die ressourcensparendste Lösung setzt.
>> [...] ein großes System mit PHP aufgebaut hat

> Klingt für mich nach einem Wiederspruch... :)

Soll das eine Zustimmung sein?

Oder ein Widerspruch, basierend auf einer dreisten sinnentstellenden  
Zitierung?

Claus

Am 06.04.2010 11:14, schrieb Claus Färber:
> Oder ein Widerspruch, basierend auf einer dreisten sinnentstellenden
> Zitierung?

Wieso Sinnentstellt? Man will die ressourcensparendste Lösung und hat 
dabei ein großes System mit PHP aufgesetzt? Ich finde das ist ein 
Wiederspruch weil denke ich recht bekannt ist dass PHP nicht zu den 
schnellsten und Speicherschonensten Sprachen gehört.

-- 
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:

> Am 06.04.2010 11:14, schrieb Claus Färber:
>
>> Oder ein Widerspruch, basierend auf einer dreisten sinnentstellenden
            ¯¯¯¯¯¯¯¯¯¯¯
> dabei ein großes System mit PHP aufgesetzt? Ich finde das ist ein 
> Wiederspruch weil denke ich recht bekannt ist dass PHP nicht zu den
  ¯¯¯¯¯¯¯¯¯¯¯¯

Wenn ich meinen Namensvetter richtig verstanden habe, wollte er Dich auf
den Unterschied zwischen diesen beiden Begriffen hinweisen ;-)

Gruß. Claus

Am 06.04.2010 12:25, schrieb Claus Reibenstein:
> Wenn ich meinen Namensvetter richtig verstanden habe, wollte er Dich auf
> den Unterschied zwischen diesen beiden Begriffen hinweisen ;-)

Achso, noch schlimmer, Rechtschreibfreaks. :D
Aber klar, man sollte es natürlich richtig schreiben.

-- 
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann  schrieb/wrote:
> Am 06.04.2010 11:14, schrieb Claus Färber:
>> Oder ein Widerspruch, basierend auf einer dreisten sinnentstellenden
>> Zitierung?

> Wieso Sinnentstellt? Man will die ressourcensparendste Lösung und hat
> dabei ein großes System mit PHP aufgesetzt?

Das habe ich nicht geschrieben.

Zur Erinnerung:

| Neue Hardware kostet aber Geld. Das sind Kosten, die man vermeiden
| kann, wenn man von Anfang an auf die ressourcensparendste Lösung
| setzt.
|
| Wenn man allerdings erst einmal ein großes System mit PHP aufgebaut
| hat, ist es zu spät. Da wäre die Umstellung dann zu aufwändig.

Das sind klar zwei Alternativen: ENTWEDER man setzt auf die  
ressourcensparendste Lösung, ODER man baut ein System mit PHP auf.

Claus

Claus Reibenstein  schrieb/wrote:
> Wenn ich meinen Namensvetter richtig verstanden habe, wollte er Dich
> auf den Unterschied zwischen diesen beiden Begriffen hinweisen ;-)

Ähm, nein.

Claus

Am 06.04.2010 15:39, schrieb Claus Färber:
> Das sind klar zwei Alternativen: ENTWEDER man setzt auf die
> ressourcensparendste Lösung, ODER man baut ein System mit PHP auf.

gebe ich dir recht, sry, da habe ich doch etwas zu voreilig und viel 
geschnippelt. :)

-- 
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Claus Färber schrieb:

> Claus Reibenstein  schrieb/wrote:
>
>> Wenn ich meinen Namensvetter richtig verstanden habe, wollte er Dich
>> auf den Unterschied zwischen diesen beiden Begriffen hinweisen ;-)
> 
> Ähm, nein.

Dann verstehe ich Dein Posting nicht.

Gruß. Claus

"Josef M. Werner"  writes:
> * Stefan Scholl wrote:

>> In der Zwischenzeit haben User schon die Adress-Leiste vergessen und
>> geben jede URL in die Suchmaschine ein.
>
> Das ist mir in den letzten Jahren auch vermehrt aufgefallen; es gibt 
> immer mehr Idioten, die „über Google ins Internet gehen“.

Falls du diese Zunahme nicht über direkte Beobachtung sondern durch
Logfile-Analyse wahrnimmst, könnte sie auch darauf zurückzuführen
sein, dass viele Browser ein Feld zur Google-Suche integriert haben.
Da ist es auch möglich, dass das Feld einfach mit dem Adressfeld
verwechselt wurde, obwohl der Bentuzer es ansich besser weiß.

Ich habe auch schon ein g für die Google-Suche getippt, dann ist mir
die URL eingefallen und ich habe vergessen das g wieder zu löschen, ja
und dann auf den ersten Google Treffer geklickt.

Grundsätzlich wurde das Phänomän, dass Leute die komplette URL in eine
Suchmaschiene tippten, schon vor Jahren beobachtet. Stand das nicht in
Steve Krugs "Don't make me think" am Beispiel von Yahoo?

-- 
http://www.clef.at/yagpmfaq/ - Yet Another German Pegasus Mail FAQ

Arno Welzel wrote:

> Manfred Schenk schrieb:
>> Claus Färber  wrote:
>>> Stefan Scholl  schrieb/wrote:
>>>> Nur wegen ein paar statischer Dateien (HTML + PDF) soll ich PHP
>>>> programmieren?
>>> Klar! Als zusätzlicher Bonus für den Aufwand winkt eine langsamere
>>> Auslieferung deiner Seiten, schlechteres Caching und mit etwas Glück
>>> ignorieren dich sogar noch Suchmaschinen.
>> 
>> Damit die Suchmaschinen die Seiten (möglicherweise) ignorieren müssten
>> diese auch als dynamisch erkennbar sein. Aber man muss ja nicht mit URLs
>> arbeiten die auf /dynamicpage.php?bla=blubb&foo=bar enden sondern kann
>> ja auch /bla/blubb/foo/bar.html verwenden.
> 
> Ja - z.B. mit Apache-Rewrite-Regeln, die auch in einer .htaccess-Datei
> stehen können. Meine Domains arbeiten nur so - von aussen ist praktisch
> nicht erkennbar, daß sämtliche Seiten dynamisch erzeugt sind.

Udiags.  <http://www.w3.org/QA/Tips/uri-choose>


PointedEars
-- 
Dann mußt Du aber eine andere DTD in den Dogtype eintragen,
weil Dich sonst das W3C beißt.

(Georg Maaß in dcljs <an4mm7$aur11$2@ID-3551.news.dfncis.de>)

* Harald Muehlboeck wrote:

> "Josef M. Werner"  writes:

>> Das ist mir in den letzten Jahren auch vermehrt aufgefallen; es gibt 
>> immer mehr Idioten, die „über Google ins Internet gehen“.
> 
> Falls du diese Zunahme nicht über direkte Beobachtung sondern durch
> Logfile-Analyse wahrnimmst, könnte sie auch darauf zurückzuführen
> sein, dass viele Browser ein Feld zur Google-Suche integriert haben.
> Da ist es auch möglich, dass das Feld einfach mit dem Adressfeld
> verwechselt wurde, obwohl der Bentuzer es ansich besser weiß.

Ich seh' das in natura; Adressen werden ins Suchfeld eingegeben und das
Adressfeld wird als Lesezeichenersatz verwendet. Nach dem Grund für
dieses seltsame Verhalten befragt, zeigt sich praktisch immer völliges
Desinteresse an der verwendeten Software: „Funktioniert doch!“
Verständnislosigkeit gepaart mit Lernunwilligkeit scheint ein weit
verbreitetes Phänomen des „IT-Zeitalters“ zu sein.
Wahrscheinlich führt das Überangebot an Möglichkeiten bei vielen
Menschen zu besagtem Desinteresse und zu einer Art Verweigerungshaltung.

> Grundsätzlich wurde das Phänomän, dass Leute die komplette URL in eine
> Suchmaschiene tippten, schon vor Jahren beobachtet. Stand das nicht in
> Steve Krugs "Don't make me think" am Beispiel von Yahoo?

Hab' ich nicht gelesen.

-- 
Jo

"Josef M. Werner"  schrub:

>* Harald Muehlboeck wrote:
>
>> "Josef M. Werner"  writes:
>
>>> Das ist mir in den letzten Jahren auch vermehrt aufgefallen; es gibt 
>>> immer mehr Idioten, die „über Google ins Internet gehen“.
>> 
>> Falls du diese Zunahme nicht über direkte Beobachtung 
>
>Ich seh' das in natura; Adressen werden ins Suchfeld eingegeben 

Ich hab das gestern auch bei einem (potentiellen) Kunden gesehen.
Die hat als Startseite im Browser Google und tippt in Google dann die
Adresse ein. Hab mir aber verkniffen, was zu sagen und mir...

>Adressfeld wird als Lesezeichenersatz verwendet. Nach dem Grund für
>dieses seltsame Verhalten befragt, zeigt sich praktisch immer völliges
>Desinteresse an der verwendeten Software: „Funktioniert doch!“

...das erspart.

lg
Wolfgang
-- 
http://www.webautor.at
[freundliche Problemlösungen im Usenet...] "Die gibt es aber nicht immer 
umsonst. Die hier erwartete Gegenleistung heißt bemerkbare Eigeninitiative. 
Höflich, korrekt, kosten-/mühelos -- Wähle zwei." [Lutz Donnerhacke in dcsf]

Am Fri, 09 Apr 2010 10:52:40 +0200 schrieb Josef M. Werner:

> Wahrscheinlich führt das Überangebot an Möglichkeiten bei vielen
> Menschen zu besagtem Desinteresse und zu einer Art Verweigerungshaltung.

Durchaus möglich, aber das ist nicht zwingend ein schlechtes Zeichen.

Sich intensiv mit Internet und anhängiger Software auseinander setzen
können sich die Leute, die nichts anderes haben. Für andere ist es
lediglich ein Hilfsmittel am Rande in das sie sie schlauerweiwse möglichst
wenig Zeit investieren. Schließlich ist es duoch nr Internet, also nichts
wichtiges. Ich verdiene damit auch kein Geld, alse schätze ich es gering.
Nur sowiel wie nötig und so wenig wie möglich. Was die Internetfreakks
darüber denken ist unedeutend. Die sollen die Computer und Software am
Laufen halten und mehr nicht.

On Fri, 9 Apr 2010, Wolfgang Decker wrote:

> Ich hab das gestern auch bei einem (potentiellen) Kunden gesehen.
> Die hat als Startseite im Browser Google und tippt in Google dann die
> Adresse ein. Hab mir aber verkniffen, was zu sagen und mir...

Wie soll sonst die Fa. Google mitbekommen, wo er entlangsurft? Das ist 
notwending für die Hilfestellung bei der Auswahl der zu lesenden Inhalte, 
für die Versorgung mit relevanter Information per E-Mail und für die 
korrekte Interpretation der Geodaten, die er mit seinem Handy beim 
Herumlaufen ständig produziert.

-- 
Helmut Richter

* Olaf D. wrote:

> Am Fri, 09 Apr 2010 10:52:40 +0200 schrieb Josef M. Werner:
> 
>> Wahrscheinlich führt das Überangebot an Möglichkeiten bei vielen
>> Menschen zu besagtem Desinteresse und zu einer Art Verweigerungshaltung.
> 
> Durchaus möglich, aber das ist nicht zwingend ein schlechtes Zeichen.
> 
> Sich intensiv mit Internet und anhängiger Software auseinander setzen
> können sich die Leute, die nichts anderes haben. Für andere ist es
> lediglich ein Hilfsmittel am Rande in das sie sie schlauerweiwse möglichst
> wenig Zeit investieren. Schließlich ist es duoch nr Internet, also nichts
> wichtiges. Ich verdiene damit auch kein Geld, alse schätze ich es gering.
> Nur sowiel wie nötig und so wenig wie möglich. Was die Internetfreakks
> darüber denken ist unedeutend. Die sollen die Computer und Software am
> Laufen halten und mehr nicht.

Die Einstellung der Pragmatiker. :-)
(Kann ich aber gut verstehen, noch dazu, wo wir in der gleichen Branche
tätig sind. Ich bin vllt. nur etwas mehr an der IT-Spielerei
interessiert, weil der Beruf nach rd. 4 Jahrzehnten nicht mehr allzuviel
Neues bringt.)

-- 
Jo

"Olaf D."  schrub:

>Sich intensiv mit Internet und anhängiger Software auseinander setzen

Also dass man die URL gleich in den Browser eingeben kann und nicht den
Umweg über Google machen muss, hat ja nix mit "intensiv
auseinandersetzen" zu tun...

Da muss man ja bei *jedem* Aufruf einer Seite doppelte Arbeit
verrichten, einmal in Google eingeben, Enter drücken, dann nochmal auf
das erste Suchergebnis klicken, damit man auf die gewünschte Seite
kommt...

Da sollten doch bei jedem, der irgendwie mit strukturierten
Arbeitsabläufen zu tun hat, die Alarmglocken schrillen, oder?

lg
Wolfgang
-- 
http://www.webautor.at
[freundliche Problemlösungen im Usenet...] "Die gibt es aber nicht immer 
umsonst. Die hier erwartete Gegenleistung heißt bemerkbare Eigeninitiative. 
Höflich, korrekt, kosten-/mühelos -- Wähle zwei." [Lutz Donnerhacke in dcsf]

Am 09.04.2010 11:36, schrieb Helmut Richter:
> On Fri, 9 Apr 2010, Wolfgang Decker wrote:
>
>> Ich hab das gestern auch bei einem (potentiellen) Kunden gesehen.
>> Die hat als Startseite im Browser Google und tippt in Google dann die
>> Adresse ein. Hab mir aber verkniffen, was zu sagen und mir...

Ich nutze Google (konkret das Eingabefeld der Suchleiste im Firefox, 
nicht die Homepage selbst) sehr exzessiv beim surfen einfach weil ich 
keine Lust habe rumzuprobieren wie die Adresse richtig geschrieben ist.

Ich will zum Beispiel auf die Homepage von Wordpress. Also gebe ich im 
Suchfeld Wordpress ein und schlage mich nicht rum mit Fragen "war da 
nicht nen Bindestrich im Namen?" oder "war das jetzt .com oder .de?".

> Wie soll sonst die Fa. Google mitbekommen, wo er entlangsurft? Das ist
> notwending für die Hilfestellung bei der Auswahl der zu lesenden Inhalte,
> für die Versorgung mit relevanter Information per E-Mail und für die
> korrekte Interpretation der Geodaten, die er mit seinem Handy beim
> Herumlaufen ständig produziert.

Ach das kriegt Google auch ohne ihre Suchmaschine zu genüge hin wenn ich 
als mal die Statuszeile beachte und nachdenke ob es auch Webseiten gibt 
ohne Google Analystics.

-- 
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Wolfgang Decker  wrote:
> Da muss man ja bei *jedem* Aufruf einer Seite doppelte Arbeit
> verrichten, einmal in Google eingeben, Enter drücken, dann nochmal auf
> das erste Suchergebnis klicken, damit man auf die gewünschte Seite
> kommt...
> 
> Da sollten doch bei jedem, der irgendwie mit strukturierten
> Arbeitsabläufen zu tun hat, die Alarmglocken schrillen, oder?

Computer sind doof. Die machen mehr Arbeit als nötig. :-)



-- 
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
<!--[if IE 6]><script>for(x in document.open);</script><![endif]-->

Am Fri, 09 Apr 2010 13:41:06 +0200 schrieb Wolfgang Decker:

> Also dass man die URL gleich in den Browser eingeben kann und nicht den
> Umweg über Google machen muss, hat ja nix mit "intensiv
> auseinandersetzen" zu tun...

Könnte man denken, ja.
 
> Da sollten doch bei jedem, der irgendwie mit strukturierten
> Arbeitsabläufen zu tun hat, die Alarmglocken schrillen, oder?

Oder auch nicht. Ich erlebe es in vielen Programmen, dass manches irgendwie
merkwürdig ist.

.oO(Wolfgang Decker)

>"Josef M. Werner"  schrub:
>
>>* Harald Muehlboeck wrote:
>>
>>> "Josef M. Werner"  writes:
>>
>>>> Das ist mir in den letzten Jahren auch vermehrt aufgefallen; es gibt 
>>>> immer mehr Idioten, die „über Google ins Internet gehen“.
>>> 
>>> Falls du diese Zunahme nicht über direkte Beobachtung 
>>
>>Ich seh' das in natura; Adressen werden ins Suchfeld eingegeben 
>
>Ich hab das gestern auch bei einem (potentiellen) Kunden gesehen.
>Die hat als Startseite im Browser Google und tippt in Google dann die
>Adresse ein. Hab mir aber verkniffen, was zu sagen und mir...

Man müßte solche Leute glatt mal fragen, ob sie auch, obwohl sie die
Telefonnummer des Gesprächspartners kennen, grundsätzlich die Auskunft
anrufen, um sich dann weiterverbinden zu lassen.

Sowas taugt doch höchstens noch als Organspender. SCNR

Micha

.oO(Olaf D.)

>Am Fri, 09 Apr 2010 10:52:40 +0200 schrieb Josef M. Werner:
>
>> Wahrscheinlich führt das Überangebot an Möglichkeiten bei vielen
>> Menschen zu besagtem Desinteresse und zu einer Art Verweigerungshaltung.
>
>Durchaus möglich, aber das ist nicht zwingend ein schlechtes Zeichen.
>
>Sich intensiv mit Internet und anhängiger Software auseinander setzen
>können sich die Leute, die nichts anderes haben. Für andere ist es
>lediglich ein Hilfsmittel am Rande in das sie sie schlauerweiwse möglichst
>wenig Zeit investieren.

Auch ein Hilfsmittel, sprich Werkzeug, will halbwegs gekonnt benutzt
werden, sonst gibt's blaue Flecke oder schlimmeres.

>Schließlich ist es duoch nr Internet, also nichts
>wichtiges. Ich verdiene damit auch kein Geld, alse schätze ich es gering.
>Nur sowiel wie nötig und so wenig wie möglich. Was die Internetfreakks
>darüber denken ist unedeutend. Die sollen die Computer und Software am
>Laufen halten und mehr nicht.

Von mir aus. Dann sollen die "DAUs" sich aber nicht über verseuchte
Rechner und ähnliche Probleme beschwerden. Wer sich mit 'nem Pressluft-
hammer aufgrund völliger Unerfahrenheit den Fuß zermatscht, sollte vom
Arzt auch keine verständnisvollen Blicke erwarten.

Micha

Am Sat, 10 Apr 2010 03:40:29 +0200 schrieb Michael Fesser:

> Auch ein Hilfsmittel, sprich Werkzeug, will halbwegs gekonnt benutzt
> werden, sonst gibt's blaue Flecke oder schlimmeres.

nicht zwangsläufig. Entscheidend ist doch das man zum Ziel, also zu der
gwünschten Seite kommt. Wie ist unerheblich. 

Daran zu optimieren ist verdächtig, denn der Zeitaufwand dafür ist häufig
größer als die Zeitersparnis selbst. 

> Von mir aus. Dann sollen die "DAUs" sich aber nicht über verseuchte
> Rechner und ähnliche Probleme beschwerden. Wer sich mit 'nem Pressluft-
> hammer aufgrund völliger Unerfahrenheit den Fuß zermatscht, sollte vom
> Arzt auch keine verständnisvollen Blicke erwarten.

Was soll denn der abstruse Vergleich bringen?