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

[minhen]

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.

Erklär mir den Unterschied. Wenn Du "dumm" schreibst, dann unterstellst Du offensichtlich entweder, dass ich jemanden für 'dumm' halte, Du diese Meinung aber nicht teilst, oder Du würdest gerne 'dumm' schreiben, findest es aber nicht ganz passend und schwächst zu "dumm" ab oder Du meinst irgendetwas ganz anderes, was ich gerne erklärt hätte.

Na, warum nicht gleich so. Bricht dir wirklich ein Zacken aus der Krone, wenn nachfrägst, wenn du etwas nicht verstehst? "Wort" bedeutet in dem Fall, dass ich nicht Wort meinte, aber keine Lust hatte, mir ein passenden Begriff zu überlegen und mein Gegenüber für intelligent genug gehalten habe, zu begreifen, dass "wort" lediglich die Richtung vorgeben sollte. Diese Annahme hat sich zwar als falsch herausgestellt, aber zumindest bist du ja jetzt schon mal über deinen Schatten gesprungen und hast statt deinem üblichen "Schwachsinn" und "Blödsinn"-Geplärre einfach mal nachgefragt. Ist doch gar nicht so schlimm, oder?

Nein, zeigt sehr schön, dass Du Opera nicht objektiv siehst und ihm jeden Mist durchgehen lässt.

Oh, ich denke ich sehe Browser deutlich objektiver als du. Sieht man ja auch an dem Thread hier. (Lies dir einfach noch mal den Thread durch - einer von uns hat Softwarehersteller aufgrund einer Ideologie munter in "Gut" und "Böse" eingeteilt. Tipp: Ich war's nicht. Erzähl du mir also bitte nichts von Objektivität. Belügen kannst du höchstens dich selbst)

Stimmt, das W3C ist natürlich gegen XSLT, darum gab es auch Ende 2005 eine Candidate Recommendation.

Ich sage es jetzt bestimmt zum dritten oder vierten Mal - ich werde es aber ganz sicher kein zweites Mal mehr sagen - es macht einen riesen Unterschied ob XSLT serverseitig oder clientseitig ausgeführt wird. Versteh es oder nicht. Mir egal, ich werde mich nach diesem Beitrag nicht mehr wiederholen (was wohl bedeutet, ich werde überhaupt nichts mehr in diesem Thread zu dir sagen ).

Opera ging es darum, keine Entwickler an etwas zu setzen, wovon sie nicht sicher wussten, ob es sich durchsetzen würde, ist geschäftspolitisch durchaus nachvollziehbar.

Nein. Nur weil du dir irgendwas zusammenfantasiert, ist es noch lange nicht so. Ich diskutiere eigentlich - im krassen Gegensatz zu dir - nur bei Dingen mit, von denen ich ne Ahnung habe. Wenn ich sage, dass Opera etwas aus diesen und jengen Gründen getan hat, dann, weil ich mit Leuten von Opera darüber gesprochen habe.
Das ist ein kleiner aber feiner Unterschied zu deiner Vorgehensweise dir irgendwas hinzufantasieren (sei es eine XSLT-Unterstützung bei Opera 8 oder wie eben warum sie es angeblich nicht unterstützt haben).

Für RSS-Feeds oä ist sowas wunderbar geeignet. Die will man gar nicht als XHTML oä ausliefern, weil die User ohnehin entsprechende Feed-Reader verwenden. Andererseits wäre es auch nett, eine gewisse Vorschaumöglichkeit zu haben, bzw. auch technisch weniger interessierte User ohne Feed-Reader nicht komplett auszuschließen, also verpasst man dem XML eben eine entsprechende XSLT.

Nichts davon verlangt, dass der Client die XSL-Transformation durchführen muss. All diese Vorteile gibt's auch bei serverseitiger Verarbeitung. Der einzige Vorteil ist, dass der Server ein paar Kilobyte Traffic einspart. Nachteile hab ich schon genannt: wer kein XSLT beherrscht, wird ausgeschloßen. Das alles kann man aber eben auch ohne diesen Nachteil haben: wenn man's auf dem Server macht.

Schonmal auf die Idee gekommen, dass strukturierte Daten uU eine andere Semantik als XHTML haben könnten?

Bei Formaten, die ich aus dem Ärmel schüttle natürlich nicht. Bei standardisierten Formaten natürlich schon.

Ach bitte. Welche Semantik eine XML-Anwendung hat, ist doch nur Definitionssache. Und bei XHTML hat diese Definition eben bereits das W3C übernommen. Dein Feedreader kann bereits RSS2.0- und Atom-XML-Dokumente lesen, eben weil sie eine klar definierte Semantik haben.

Ja, jaaa! Endlich! Kaum sagt man es dir zum dritten oder vierten Mal fängst du an es zu verstehen. Dass ich das noch miterleben darf! Das wäre doch auch viel einfacher möglich gewesen, oder? Zum Beispiel indem du meine permanenten Hinweise auf die maschinelle Verarbeitung einfach mal gelesen hättest ...

Habe ich. Ich bleibe dabei, dass Deine Sichtweise von Semantik etwas eingeschränkt ist, wenn Semantik für Dich nur bedeutet "Kann mein Browser ohne clientside XSLT darstellen".

Für mich ist Semantik nicht einfach irgendein Wischi-Waschi-Begriff sondern bezeichnet ontologisch die Bedeutung von Begriffen. Im konkreten Zusammenhang mit maschineller Verarbeitung (und ich habe den Begriff hier nie in anderem Zusammenhang gebraucht) ist damit gemeint, dass eine Maschine, ein Stück Software, die Bedeutung eines Begriffs kennt. Das erfordert zwingend, dass die Begriffe zusammen mit ihrer Semantik irgendwo explizit definiert sind. Etwas was bei (X)HTML der Fall ist und bei deinem "plain XML" eben nicht. Aber das hast du mittlerweile endlich auch kapiert.
Das einzige Verständnisproblem, das du jetzt noch hast, ist, dass die Ausgangsdaten (siehe auch dein "Simples Beispiel") im Normalfall für Maschinen immer semantisch leer sind und erst mittels XSLT in semantisch angereicherte, d.h. standardisierte, Formate wie z.B. RSS oder XHTML überführt werden. Etwas was ich vor gefühlten 100 Seiten als "Semantik mit Preisschild" bezeichnet hatte.

Vielleicht magst du mit deiner jetzt neu gewonnen Erkenntnis diesen Thread noch einmal durchlesen. Ich werde auf jeden Fall jetzt nichts mehr zum x-ten Mal wiederholen. Genug ist genug.

[nman]

minhen schrieb:

"Wort" bedeutet in dem Fall, dass ich nicht Wort meinte, aber keine Lust hatte, mir ein passenden Begriff zu überlegen und mein Gegenüber für intelligent genug gehalten habe, zu begreifen, dass "wort" lediglich die Richtung vorgeben sollte.

Also hast Du gemeint, es soll in die Richtung von "dumm" gehen? Gratuliere, das ist genau die Einstellung, die ich gemeint habe.

Oh, ich denke ich sehe Browser deutlich objektiver als du. Sieht man ja auch an dem Thread hier. (Lies dir einfach noch mal den Thread durch - einer von uns hat Softwarehersteller aufgrund einer Ideologie munter in "Gut" und "Böse" eingeteilt. Tipp: Ich war's nicht. Erzähl du mir also bitte nichts von Objektivität. Belügen kannst du höchstens dich selbst)

Tatsächlich verwende ich gar keinen Firefox - ich mag den Browser nicht sonderlich. Ich kann lediglich Deiner unbegründeten Kritik nichts abgewinnen.

Ich sage es jetzt bestimmt zum dritten oder vierten Mal - ich werde es aber ganz sicher kein zweites Mal mehr sagen - es macht einen riesen Unterschied ob XSLT serverseitig oder clientseitig ausgeführt wird. Versteh es oder nicht.

Darum bin ich darauf auch weiter unten noch eingegangen.

Mir egal, ich werde mich nach diesem Beitrag nicht mehr wiederholen (was wohl bedeutet, ich werde überhaupt nichts mehr in diesem Thread zu dir sagen ).

Ich merke, dass Du Deine Argumente wiederholst, leider werden sie dadurch nicht besser.

Nein. Nur weil du dir irgendwas zusammenfantasiert, ist es noch lange nicht so. Ich diskutiere eigentlich - im krassen Gegensatz zu dir - nur bei Dingen mit, von denen ich ne Ahnung habe. Wenn ich sage, dass Opera etwas aus diesen und jengen Gründen getan hat, dann, weil ich mit Leuten von Opera darüber gesprochen habe.

Natürlich, offizielle Firmenstellungnahme dazu wird natürlich nicht sein "Wir wollen das jetzt noch nicht umsetzen, weil es uns zuviel Entwicklungszeit kostet", das kann sich kein Unternehmen leisten.

Das ist ein kleiner aber feiner Unterschied zu deiner Vorgehensweise dir irgendwas hinzufantasieren (sei es eine XSLT-Unterstützung bei Opera 8 oder wie eben warum sie es angeblich nicht unterstützt haben).

Die XSLT-Unterstützung in Opera 8 habe ich nicht zusammenfantasiert, die hast Du mir mit viel Gespür für I-Punkt-Reiterei untergeschoben.
Und um nicht jedes Statement eines Firmenangehörigen zur Geschäftspolitik des Arbeitgebers vollzunehmen, musst Du nur ein bisschen mitdenken können, nicht unbedingt sonderlich viel Fantasie haben.

Nichts davon verlangt, dass der Client die XSL-Transformation durchführen muss.

Doch, RSS-Feedreader verstehen kein HTML, sondern nur XML, daher ist es praktisch, einfach XSL für die Transformation verwenden zu können.

Der einzige Vorteil ist, dass der Server ein paar Kilobyte Traffic einspart.

Ein paar Kilobyte pro Übertragung und auch (je nach Komplexität des Dokuments) ein bisschen Ressourcen - das summiert sich.

Nachteile hab ich schon genannt: wer kein XSLT beherrscht, wird ausgeschloßen. Das alles kann man aber eben auch ohne diesen Nachteil haben: wenn man's auf dem Server macht.

Du gehst überhaupt nicht auf das Feedreader-Beispiel ein.
Du wirst nicht ausgeschlossen, weil Dein Feedreader gerne XML frisst, auch ohne XSL. Das client-seitige XSL ist nur ein bisschen Zucker für Deinen Browser.
Und natürlich kannst Du die Transformation nicht serverseitig machen, eben weil der Feedreader kein XHTML schluckt.

Ja, jaaa! Endlich! Kaum sagt man es dir zum dritten oder vierten Mal fängst du an es zu verstehen. Dass ich das noch miterleben darf! Das wäre doch auch viel einfacher möglich gewesen, oder? Zum Beispiel indem du meine permanenten Hinweise auf die maschinelle Verarbeitung einfach mal gelesen hättest ...

Setzen, fünf.
Beispiel von oben (damit Du Dich beim Mitdenken nicht überfordert fühlst): RSS ist ein XML-Format, das natürlich eine wohldefinierte Semantik hat und wunderbar maschinell verarbeitbar ist. Und mit client-seitigem XSL verwurstet _nur_ Dein Webbrowser das XML zu XHTML, jede auf RSS ausgerichtete Suchmaschine freut sich über perfekt lesbares XML und kann dieses wunderbar weiterverarbeiten.

Für mich ist Semantik nicht einfach irgendein Wischi-Waschi-Begriff sondern bezeichnet ontologisch die Bedeutung von Begriffen. Im konkreten Zusammenhang mit maschineller Verarbeitung (und ich habe den Begriff hier nie in anderem Zusammenhang gebraucht) ist damit gemeint, dass eine Maschine, ein Stück Software, die Bedeutung eines Begriffs kennt. Das erfordert zwingend, dass die Begriffe zusammen mit ihrer Semantik irgendwo explizit definiert sind.

Und das sind sie durchaus nicht nur bei XHTML, sondern bei einer Menge von Formaten aus der XML-Familie.

Etwas was bei (X)HTML der Fall ist und bei deinem "plain XML" eben nicht. Aber das hast du mittlerweile endlich auch kapiert.

Du hast aber schon mitbekommen, dass man XSL für jede Art von XML verwenden kann? Und dass in meinen Posts nirgends von "plain XML" die Rede war auch? Nein? Macht nichts, wir haben ja noch Zeit, das mit dem Lesen zu üben, stimmt's?

Das einzige Verständnisproblem, das du jetzt noch hast, ist, dass die Ausgangsdaten (siehe auch dein "Simples Beispiel") im Normalfall für Maschinen immer semantisch leer sind und erst mittels XSLT in semantisch angereicherte, d.h. standardisierte, Formate wie z.B. RSS oder XHTML überführt werden.

Mein simples Beispiel ist genau das gewesen, ein simples Beispiel.
RSS2.0 zB ist ein XML-Format und bereits standardisiert und "semantisch angereichert". Das kann man wunderbar mittels XSLT in ein anderes standardisiertes Format - wie eben zB XHTML - überführen, für mehr wird Client-side XSLT auch nicht verwendet.

Vielleicht magst du mit deiner jetzt neu gewonnen Erkenntnis diesen Thread noch einmal durchlesen. Ich werde auf jeden Fall jetzt nichts mehr zum x-ten Mal wiederholen. Genug ist genug.

Du willst offensichtlich gar nicht verstehen, wofür client-seitiges XSLT gut sein kann, oder?

Die Diskussion kommt mir vor wie eine klassische Diskussion über JavaScript, ich erkläre Dir, dass die Javascript-Elemente von phpmyadmin eine feine Sache sind, Du sagst mir, dass Javascript böse ist, weil Du irgendwo mal gelernt hast, dass man seine Navigationsleisten nicht in Javascript machen darf. Ich erkläre Dir, dass bei phpmyadmin Java-Script für viel praktischere und richtig sinnvolle Sachen verwendet wird, Du fühlst Dich verunsichert, weil Du Dich nicht mehr auskennst und pochst darauf, dass Du Dich nicht wiederholen möchtest, weil Java-Script ja immerhin böse ist und nicht zur Navigation verwendet werden darf etc.pp.

[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?

[wursel]

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.

1. 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.
2. 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.

[dirtbag]

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