[HTML]Wäre es nicht praktisch, wenn man im Header die vorherige und die nächste Seite angeben könnte?

Walli

minhen schrieb:

nman schrieb:

Wenn Du Schwachsinn schreibst, dann lege ich keinen Wert darauf, mich in falscher Höflichkeit zu üben, indem ich damit hinterm Berg halte.

Wie gesagt, der einzige, der hier puren Schwachsinn verzapt hat bist du nicht ich.

Leute, meint ihr nicht, dass das hier langsam extrem ins Kindische abdriftet?

Walli schrieb:

minhen schrieb:

nman schrieb:

Wenn Du Schwachsinn schreibst, dann lege ich keinen Wert darauf, mich in falscher Höflichkeit zu üben, indem ich damit hinterm Berg halte.

Wie gesagt, der einzige, der hier puren Schwachsinn verzapt hat bist du nicht ich.

Leute, meint ihr nicht, dass das hier langsam extrem ins Kindische abdriftet?

Schwachsinn, Du verstehst es nur nicht!

nman

Walli schrieb:

Leute, meint ihr nicht, dass das hier langsam extrem ins Kindische abdriftet?

Langsam abdriftet? Das ist es schon lange.

minhen

Ach nman, eigentlich wollte ich ja gar nicht mehr antworten. Aber dann wiederum - es gibt leider viel zu viele, die bezüglich XSLT so (falsch) denken wie du. Was ja erst zu der unschönen Situation führt, dass Browser XSLT implementieren müssen.

Zunächst mal, du kannst mich gar nicht verunsichern. Denn ich arbeite mit allen hier genannten Techniken (Außname Atom-Feeds) schon seit einiger Zeit, kenne sie also durchaus und gerade auch in der Praxis. Desweiteren ist das Wörtchen XML das erste Mal in einem Beitrag von mir gefallen. Und dort gleich mit pures/reines/plain und "keine Semantik" versehen. Es ist also schon merkwürdig, dass du mir vorwirfst, ich könne nicht lesen. Denn alles was du zu XML sagst, ist eine Antwort auf das, was ich dazu gesagt hatte. Und das war, wie gesagt, von Anfang an immer explizit auf "plain XML" beschränkt. Aber genug der Verteidigung, ich will ja mit deinen bescheuerten Kindereien nicht weitermachen.

Aber zum Thema XSLT. Du willst dass ich unbedingt auf dein RSS-Beispiel eingehe, bitte schön. Alles was du dazu sagst (Vorschaumöglichkeit für Leute ohne Feedreader, Zucker für den Browser, ...) lässt darauf schließen, dass du den Sinn von XSLT darin siehst, XML bzw in deinem Beispiel RSS in Browsern hübsch zu machen. Dafür ist XSLT aber einfach nicht gedacht. XSLT führt eine oder mehrere XML-Strukturen in eine andere Struktur über. Zum Beispiel um aus einer XML-Quelle mit Wechselkursen und einer XML-Quelle mit Länderinformationen eine nette XHTML-Seite oder ein PDF zu erzeugen. Oder um ein RSS-Feed in eine XHTML-Seite einzubinden. Oder, das ist etwas umständlicher, um aus einer XHTML-Seite Informationen für ein RSS zu extrahieren. Oder, das ist eher der Standardfall und mit dem ersten Beispiel verwandt, um aus einfachem purem Daten-XML eine XHTML-Seite zu erzeugen. All dies kann wunderbar auf dem Server geschehen. Und wenn es auf dem Server geschieht, gibt's auch keine Nachteile für die Nutzer. Das ist wofür XSLT eigentlich vorgesehen ist - und weswegen Browser überhaupt kein XSLT verstehen müssen (leider: sollten).
Wo ist der Unterschied zu deinem Beispiel? Dir geht es überhaupt nicht darum, das RSS in eine neue Struktur überzuführen oder in eine neue einzubinden. Dir geht es ausschließlich darum, dass die Browser das RSS hübsch darstellen. Und das ist nicht der Sinn von XSLT - sondern der von CSS. XSLT ist kein Ersatz, ja nicht mal ein Konkurrent für CSS. Da ich so nett bin (und außerdem keine Lust habe, dass als Kommentar abermals ein primitives aber bequemes "Blödsinn" oder "Unsinn" von dir kommt), hab ich noch auf die Schnelle drei RSS-Feeds als Beispiel ergoogelt:
http://interglacial.com/rss/harry_shearer.rss
http://www.petefreitag.com/rss/
Und das dritte aufwändigere Beispiel:
http://www.scottandrew.com/pub/xml/index.xml
Unnötig zu erwähnen, dass diese RSS-Feeds auch in Nicht-XSLT-fähigen Browsern - wie z.B. allen Opera-Versionen vor 9.0 - wunderbar dargestellt werden.
Du kannst dir eigentlich als Faustregel merken:
Sobald eine W3C-Technologie (wie z.B. XSLT) die Welt in zwei Klassen aufteilt und eine Klasse komplett ausgeschloßen wird, kannst du dir verdammt sicher sein, dass du den Sinn der Technologie nicht verstanden hast und gerade dabei bist, sie aufs Übelste zu missbrauchen.
Wie gesagt:
Darstellung von XML -> CSS
Herumhantieren mit Struktur von XML -> XSLT

nman

minhen schrieb:

Zunächst mal, du kannst mich gar nicht verunsichern. Denn ich arbeite mit allen hier genannten Techniken (Außname Atom-Feeds) schon seit einiger Zeit, kenne sie also durchaus und gerade auch in der Praxis.

Dito. Zwar nicht hauptberuflich, aber doch. Habe aber auch schon mit Atom gearbeitet.

Desweiteren ist das Wörtchen XML das erste Mal in einem Beitrag von mir gefallen. Und dort gleich mit pures/reines/plain und "keine Semantik" versehen.

Hm, das war dann wohl ein gewaltiges Missverständnis. Mit XSLT habe nämlich ich angefangen, die plain-Einschränkung kam erst später von Dir.

Und das war, wie gesagt, von Anfang an immer explizit auf "plain XML" beschränkt. Aber genug der Verteidigung, ich will ja mit deinen bescheuerten Kindereien nicht weitermachen.

Wie gesagt, war offensichtlich einfach ein Missverständnis, ich habe im Gegensatz zu Dir nie von "plain XML" gesprochen und ich habe immerhin mit meiner XSLT-Erwähnung das Thema angefangen.

...lässt darauf schließen, dass du den Sinn von XSLT darin siehst, XML bzw in deinem Beispiel RSS in Browsern hübsch zu machen.

Zum "Behübschen" ist _natürlich_ CSS da. Nur Strukturelles kann damit nicht geändert werden.

Dafür ist XSLT aber einfach nicht gedacht. XSLT führt eine oder mehrere XML-Strukturen in eine andere Struktur über. [...] Oder, das ist etwas umständlicher, um aus einer XHTML-Seite Informationen für ein RSS zu extrahieren. Oder, das ist eher der Standardfall und mit dem ersten Beispiel verwandt, um aus einfachem purem Daten-XML eine XHTML-Seite zu erzeugen.

Oder um aus selbstgebastelten XML-Formaten RSS zu generieren. Weiß ich, das (serverside) XSL, das hier das forumseigene XML zu RSS umwandelt, stammt von mir.

All dies kann wunderbar auf dem Server geschehen. Und wenn es auf dem Server geschieht, gibt's auch keine Nachteile für die Nutzer. Das ist wofür XSLT eigentlich vorgesehen ist - und weswegen Browser überhaupt kein XSLT verstehen müssen (leider: sollten).

Dass sie XSLT unterstützen müssen, habe ich nicht behauptet, aber es ist einfach ein viel zu nettes Feature, als dass man es für nicht-überlebenswichtige, potentiell dennoch hilfreiche Features nicht verwenden dürfen sollte.

Dir geht es überhaupt nicht darum, das RSS in eine neue Struktur überzuführen oder in eine neue einzubinden. Dir geht es ausschließlich darum, dass die Browser das RSS hübsch darstellen.

Sobald die Struktur auch nur ein bisschen geändert werden soll, reicht CSS nicht mehr, weil man es eben _nur_ zum Behübschen verwenden kann. Verstehe mich nicht falsch, irgendwelche schicken Formatierungen wird man natürlich sinnvollerweise in CSS machen, das wäre in XSL weder schön, noch bandbreitenschonend, noch angenehm zu machen. Aber wenn ich zB alle neuen Einträge nach der Kategorie gruppieren möchte oä, dann stehe ich mit CSS an. Und da tut es auch nicht weh, wenn der Browser das nicht unterstützt. Wie gesagt, nice-to-have, aber nicht nötig um die Seite zu verwenden.

hab ich noch auf die Schnelle drei RSS-Feeds als Beispiel ergoogelt:

Nett, danke. Aber die ändern (natürlich) alle auch nichts an der Struktur, siehe oben.

Sobald eine W3C-Technologie (wie z.B. XSLT) die Welt in zwei Klassen aufteilt und eine Klasse komplett ausgeschloßen wird, kannst du dir verdammt sicher sein, dass du den Sinn der Technologie nicht verstanden hast und gerade dabei bist, sie aufs Übelste zu missbrauchen.

Ich habe doch schon geschrieben, dass kein halbwegs vernunftbegabter Mensch Clientside-XSLT für irgendwelche wirklich wichtigen Funktionen verwenden würde. (Als gelegentlicher emacs-w3m-User wäre ich von sowas auch nicht begeistert.
Würde ich jetzt nicht unbedingt als Richtlinie nehmen.

[zerebralonanie]Wenn Du CSS verwendest, um XML darzustellen, dann schließt Du damit immerhin sämtliche User, die Browser ohne CSS-Support (wie div. Text-Browser) verwenden, aus. (Für behinderte User mit Screenreader ist sowas natürlich auch nicht sonderlich angenehm.)[/zerebralonanie]

Bei (X)HTML stört das nicht allzusehr, da Seiten ja immernoch ansehbar bleiben, aber bei XML ist sowas bisweilen ziemlich unangenehm.

Naja, lassen wir es gut sein, offensichtlich vertreten wir einfach unterschiedliche Auffassungen. Ich finde einfach, dass auch browserspezifische Features durchaus genutzt werden dürfen, wenn das nur Zuckerguss für die Seite darstellt und nicht irgendwelche elementaren Features damit implementiert werden bzw. User anderer Browser benachteiligt werden. (Ich bin zB auch dem Gecko-spezifischen CSS moz-border-radius oä nicht abgeneigt, sehen zwar nur Mozilla-User, aber das tut niemandem weh, User anderer Browser haben dann eben keine abgerundeten Ecken, was aber der Funktionalität keinen Abbruch tut.)

Und Dir ist sowas offensichtlich nicht geheuer. Kann ich zwar nicht so recht verstehen, aber möge es Dir unbenommen bleiben.

xindon

nman schrieb:

[zerebralonanie]Wenn Du CSS verwendest, um XML darzustellen, dann schließt Du damit immerhin sämtliche User, die Browser ohne CSS-Support (wie div. Text-Browser) verwenden, aus. (Für behinderte User mit Screenreader ist sowas natürlich auch nicht sonderlich angenehm.)[/zerebralonanie]

Wie viele Prozent alle Internetnutzer sind das? 0.0001%?

nman

xindon schrieb:

Wie viele Prozent alle Internetnutzer sind das? 0.0001%?

Nein, bestimmt 0.01% oder so. (Darum auch die Zerebralonanie-Tags.)

Ging ja nur um die Argumentation, dass man mit richtig verwendeten W3C-Technologien niemanden ausschließt. Und wie gesagt - der Punkt behindertengerechte Gestaltung wurde ja bereits angesprochen - für diverse Benutzer mit Screenreadern könnte sowas richtig böse ausgehen.

minhen

(hab ich wirklich "Außname" geschrieben? )

Das Problem ist, dass sich viele nicht an das halten, was sinnvoll ist. Wenn man erst mal anfängt und Seiten als XML+XSLT (also XSLT erzwungen client-seitig) ins Netz zu stellen, hat man die selben Probleme wie bei XML+CSS. Sobald maschinell-semantikloses "plain XML" im Netz steht, fangen die Probleme an. (RSS hat eine definierte Semantik. Deswegen fällt das Beispiel RSS+CSS nicht in diese Kategorie.)
Grundsätzlich gilt, dass man die Gestaltung ohnehin mit CSS macht. Hier ist also kein Bedarf für client-seitiges XSLT.
Ich denke bis hier sind wir uns einig.

Warum sollte man aber RSS für die Ansicht im Browser strukturell modifizieren wollen? Und wenn man das will, dann hat man ja sowieso etwas "Größeres" vor und will nicht einfach "nur mal eben" das RSS für normale Browser zugänglich machen. Das schreit also durchaus nach einer server-seitigen Lösung. Der Punkt dabei ist, dass, wenn man die Struktur der RSS-Datei ohnehin nicht haben will und verändert, es auch keinen Grund gibt, diese Datei überhaupt an Browser auszuliefern. Das ist meine Ansicht und du hast eine andere.
Aber ein wichtiger Punkt, indem wir uns unterscheiden und der für XSLT im Browser wichtig ist, kommt noch:
Der einzige Grund, weswegen wir bisher von XML+XSLT-Seiten im großen Stil verschont werden, ist der, dass die Suchmaschinen und allen voran natürlich Google sich schlicht weigern, XSLT zu unterstützen. Und da das XML für gewöhnlich semantiklos ist, werden entsprechende Seiten von z.B. Google komplett ignoriert. Das ist das einzige, was uns schützt.
Du glaubst an die Vernunft. Ich dagegen habe schon viel zu viele auch große Seiten gesehen, bei denen wichtige Funktionen nur mittels JavaScript oder Flash zugänglich sind. Hätte es keine negativen Auswirkungen auf die Indexierung bei Google, würden die Leute munter XML+XSLT ins Netz hauen. So wie sie es schon mit Flash und JavaScript für wichtige Funktionen machen.
Es ist mir also nicht nicht geheuer, ich bin einfach nur Realist

Es gibt also keinen zwingenden Grund und "nur" Nachteile. Daraus folgt: kein XSLT in Browsern!

nman

Nur kurz noch als Antwort hierauf:

minhen schrieb:

Du glaubst an die Vernunft. Ich dagegen habe schon viel zu viele auch große Seiten gesehen, bei denen wichtige Funktionen nur mittels JavaScript oder Flash zugänglich sind.

JavaScript und Flash waren lange Zeit Möglichkeiten für DAUs, bunte animierte Seiten zu machen, weswegen sie sich verbreiteten und schließlich auch für andere Zwecke eingesetzt wurden. Rein gefühlsmäßig kann ich mir einfach nicht vorstellen, dass XSL die gleiche Popularität erlangen wird, denn für technisch unbedarfte Webdesigner fehlt die Motivation, es zu lernen und technisch versiertere Leute wissen, dass man sich auf Clientside-XSL nicht verlassen darf.
Kurz: Javascript und Flash hat einfach jeder gelernt, weswegen es später auch für Dinge genutzt wurde, für die es absolut ungeeignet war.

Hätte es keine negativen Auswirkungen auf die Indexierung bei Google, würden die Leute munter XML+XSLT ins Netz hauen. So wie sie es schon mit Flash und JavaScript für wichtige Funktionen machen.

Hm, das glaube ich eigentlich weniger. Wenn man mit XSLT relativ einfach irgendwas buntes blinkendes basteln könnte gäbe es DataBecker-Bücher à la "XSL in 72 Sekunden" und einen Haufen Idioten, die es verwenden würden. Weil XSL aber so verdammt unspektakulär ist, hat sich bis jetzt niemand aus diesem Klientel dafür interessiert.

Die Diskussionskultur einiger hier lässt wirklich schwer zu wünschen übrig.