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

[wursel]

minhen schrieb:

Deswegen ist bei Mozilla und Opera das Einblenden der Leiste standardmäßig deaktiviert und das ist keinesfalls gut und ist im Standard auch nicht so vorgesehen.

Was fürne Leiste? Ich dachte, es wären diese lustigen blauen Pfeile? Ich hab mich bisher immer gefragt, wie die wohl funktionieren. ^^

[minhen]

Die Leiste (in dem Fall die des Operas) gibt's bereits beim allerersten Link in diesem Thread zu bewundern:
http://de.selfhtml.org/html/kopfdaten/navigationsleiste.png

Die Funktion, die du meinst ("die blauen Pfeile"), nennt sich "Fast Forward" und ist weit mächtiger als das einfache "Next" der Navigationsleiste. Die Leiste stellt einfach die aus den <link>-Tags gewonnene Informationen dar.
"Fast Forward" dagegen geht einen Schritt weiter und parst die HTML-Seiten. Dabei sucht Opera nach Links mit Beschriftungen wie "next", "nächste", ">>" usw und verwendet diese Links als "nächste Seite". Deswegen kann man in Opera mit Mausklick oder Mausgeste in z.B. diesem Thread hier von einer zur nächsten Seite wechseln, denn "Fast Forward" erkennt den "Weiter"-Link ganz unten auf der Seite. Die <link>-Angabe "next" wird natürlich auch ausgewertet und hat höchste Priorität. Ist also eine solche Angabe vorhanden, verwendet Opera diese. Ist sie nicht vorhanden, sucht Opera die wahrscheinlichste nächste Seite wie eben beschrieben.

Aber für alles andere wie Kapitelnavigation usw ist man dennoch auf die Nav-Leiste und <link>-Tags angewiesen.

[nman]

minhen schrieb:

So hat HTML 3 zum Beispiel ziemlich exakte Vorstellungen:
"Using LINK to define document specific toolbars

An important use of the LINK element is to define a toolbar of navigation buttons or an equivalent mechanism such as menu items."
http://www.w3.org/MarkUp/html3/dochead.html

HTML 4 ist dabei nicht mehr so streng, aber immerhin:
"Although LINK has no content, it conveys relationship information that may be rendered by user agents in a variety of ways (e.g., a tool-bar with a drop-down menu of links)."

Da steht nirgends etwas darüber, dass eine derartige Toolbar standardmäßig eingeblendet sein muss. Wäre ja auch Blödsinn, der Standard ist für die Auszeichnungssprache, nicht für die dazugehörigen User-Agents.

Nicht die Welt - aber die Browserhersteller. Die hocken schließlich allesamt im W3C und entscheiden über die Standards.

Das macht das W3C nicht unbedingt kompetenter, die haben schon viel Mist verabschiedet.

Und bei C++ oä ist das auch nicht anders. Da werden genauso Sachen standardisiert, die in dieser Form dann von niemandem vernünftig unterstützt werden. (Oder erst um Jahre zu spät.)

Naja, zumindest sind wir uns ja offenbar einig, dass es eine gute Idee ist.

Klar. Ich meinte nur, dass es nicht unbedingt verwerflich ist, sowas als Extension anzubieten.

Die Browserhersteller bauen ständig irgendwelche Sachen ein, die "niemand" benutzt und betreiben damit ihre Politik. Das ist ja gerade Teil der Probleme, die wir haben.

Nein, die meisten Non-Standard-Features entstanden aus einem bestimmten Bedarf oder marktpolitischen Überlegungen heraus.

Die beiden Implementierungen, die ich bisher gesehen habe (Mozilla und Opera), blenden beide die entsprechende Leiste auch nur bei Bedarf ein. D.h. wenn es keine Tags gibt, gibt's auch keine Leiste.

Da bestimmt dann aber der Webmaster, ob die Leiste angezeigt wird oder nicht. Bei Tabs macht das der User.

Damit war die Wahrscheinlichkeit größer, dass man über die Funktion stolpert als bei einer Extension, die man erst mal gezielt suchen muss. Da Firefox stellenweise 20% Marktanteil hat, hätte man damit durchaus etwas bewegen können. Auf jeden Fall mehr als wenn man es in eine Extension abschiebt ...

Das stimmt sicherlich. Aber der Firefox hat die 20% Marktanteil mit deswegen, weil er nichtmal die unbedarftesten User vor den Kopf stößt (nämlich die, die noch nie etwas anderes als den IE verwendet haben), insofern wäre standardmäßig deaktivieren ohnehin Pflicht gewesen.

Weder bin ich Informatiker noch hab ich irgendwas mit Dummheit gleichgesetzt.

Nein, Du hast mir das unterstellt. Und ich studiere (unter anderem) Informatik.

Dazu ist das ist nicht mal auf Textmengen beschränkt. Eine Fotogalerie ist zum Beispiel das selbe in Lilablassblau. Auch hier gibt es ein voriges und ein nächstes Foto, sowie Kategorien, ...

Klar, aber da fehlen die großen Vorteile der Link-Toolbar. So richtig zur Geltung kommt sowas einfach nur bei strukturierten Texten aller Art.

Opera kennt bis einschließlich Version 8 überhaupt kein XSLT. Da kann also nichts ein schlechter Witz sein - denn es ist nichts vorhanden.

Noch schlimmer.

Der Grund, weswegen sich Opera so lange geweigert hat XSLT zu implementieren, ist einfach das Gegenteil deiner Behauptung: XSLT ist schlecht für die Semantik. XSLT gehört auf den Server, da ist es in Ordnung, dafür wurde der entsprechende Standard geschaffen. Die Verlagerung von XSLT zum Browser bedeutet, dass im Netz selber pure XML-Dateien stehen. Das heißt, der Server verteilt keine semantikreichen (X)HTML-Dateien mehr sondern reines XML+XSLT. Und plain-XML trägt keinerlei semantische Information. Ein totaler Verlust der Semantik also. Erst durch Transformation zurück in (X)HTML kann man die Semantik gewinnen. Oder anders gesagt: XSLT versieht die Semantik, die früher "gratis" direkt in (X)HTML war mit einem "Preisschild". Der Client muss sie extra konstruieren. Für maschinelle Verarbeitung in Größenordnung von Suchmaschinen eine Zumutung.

Das ist furchtbarer Käse, der bereits in anderen Threads zur Genüge diskutiert wurde, weswegen ich keine Lust habe, auf diesen Schwachsinn näher einzugehen. Bei Bedarf bitte einfach in den entsprechenden alten Threads nachzulesen.

Für kleine Geräte wie Handys und alles was kein Desktop-PC ist eine Zumutung.

Auf modernen Mobiltelefonen laufen Java-VMs mit allen Schikanen, XSLT ist wesentlich weniger anspruchsvoll.

XSLT ist nicht gut, sondern schlecht für die Semantik.

Blödsinn. Ich bin wirklich kein allzugroßer XML-Fan, aber XML mit XSLT ist gut für die Semantik.

Simples Beispiel:

<thread>
  <topic>XML ist gut füer die Semantik</topic>
  <url>http://www.c-plusplus.net/forum/viewtopic-var-t-is-148413.html</url>
  <author>nman</author>
</thread>

Aber wie gesagt, das wurde bereits zur Genüge besprochen.

[minhen]

Du gehst mir langsam aber sicher auf die Nerven. Könntest du vielleicht auf dein "Blödsinn" und "Schwachsinn" verzichten? Wer hier Schwachsinn und Blödsinn von sich gibt, bin sicherlich nicht ich. Dennoch knall ich dir solche Ausdrücke nicht ständig hin. Das ist einfach eine Frage der Höflichkeit und letztlich auch der Reife. Also bitte ...

nman schrieb:

Da steht nirgends etwas darüber, dass eine derartige Toolbar standardmäßig eingeblendet sein muss.

Hast du richtig spitzfindig erkannt. Aber z.B. bei HTML 3 steht explizit dort, dass eine entsprechende Toolbar o.Ä. definiert wird - und eben nicht "simply ignore all <link>-tags".

Nein, die meisten Non-Standard-Features entstanden aus einem bestimmten Bedarf oder marktpolitischen Überlegungen heraus.

Was in keinster Weise mit meiner Aussage im Widerspruch steht. Aber Hauptsache verneint, was?

Da bestimmt dann aber der Webmaster, ob die Leiste angezeigt wird oder nicht. Bei Tabs macht das der User.

Ob eine Leiste angezeigt wird, ob sie dauerhaft angezeigt wird oder nur wenn sie sinnvoll ist, bestimmt noch immer der Anwender und nicht der Webmaster.

Weder bin ich Informatiker noch hab ich irgendwas mit Dummheit gleichgesetzt.

Nein, Du hast mir das unterstellt. Und ich studiere (unter anderem) Informatik.

Ich habe von "dumm" gesprochen. Ob ein Unterschied zwischen "dumm" und dumm existiert und was dieser sein könnte, darfst du dir gerne selbst überlegen.

Dazu ist das ist nicht mal auf Textmengen beschränkt. Eine Fotogalerie ist zum Beispiel das selbe in Lilablassblau. Auch hier gibt es ein voriges und ein nächstes Foto, sowie Kategorien, ...

Klar, aber da fehlen die großen Vorteile der Link-Toolbar. So richtig zur Geltung kommt sowas einfach nur bei strukturierten Texten aller Art.

vorher: Foto "Ich vorm Grill"
nächstes: Foto "Fleisch aufm Grill"
nächstes Kapitel: Fotos "Meine Geburtstagsparty"
voriges Kapitel: Fotos von der Uni
hoch: Überblick über die aktuelle Fotogalerie ("Grillparty")
Index: Übersicht über alle Fotogalerien
usw ...

Opera kennt bis einschließlich Version 8 überhaupt kein XSLT. Da kann also nichts ein schlechter Witz sein - denn es ist nichts vorhanden.

Noch schlimmer.

Nein. Zeigt aber abermals schön, dass du keine Ahnung hast, wovon du redest.

Das ist furchtbarer Käse, der bereits in anderen Threads zur Genüge diskutiert wurde, weswegen ich keine Lust habe, auf diesen Schwachsinn näher einzugehen. Bei Bedarf bitte einfach in den entsprechenden alten Threads nachzulesen.

Schönes Argument

Auf modernen Mobiltelefonen laufen Java-VMs mit allen Schikanen, XSLT ist wesentlich weniger anspruchsvoll.

Nein. Es laufen auf Mobiltelefonen keine normalen Java-VMs und erst recht nicht mit "allen Schikanen". Stattdessen nennt man die Dinger KVM und sie implementieren kein normales Java sondern Java Micro Edition, eine extrem stark eingeschränkte Sprachvariante. Ein Grund weswegen ein "normales" Java-Programm nicht auf einem Handy läuft. Eine normale Java-VM kann nebenebi auch nichts mit einem "Java-Handy-Programm" anfangen.
Und Handys der unteren Preisklasse haben selbst heute keine Java-Unterstützung. Und du wirst lachen, aber im Web geht es nicht darum, wer die größere Rechenleistung hat. Ich geb dir mal was vom W3C zum Lesen:
In order for the Web to reach its full potential, the most fundamental Web technologies must be compatible with one another and allow any hardware and software used to access the Web to work together. (http://www.w3.org/Consortium/)
Verstehst du jetzt endlich langsam worum es Opera ging und mir gerade geht?
Die bisherigen Web-Standards des W3Cs hatten immer maximale Kompatibiltät mit Hardware und Software zum Ziel. Man benötigt z.B. keinerlei CSS-Fähigkeiten um mit einer Webseite, die CSS einsetzt, etwas anfangen zu können. Ich muss keine Bilder oder fette Schriften rendern können, um mit HTML-Seiten, die diese Elemente einsetzen, etwas anfangen zu können. Das war der Grundgedanke des W3Cs und ist es noch immer.
XSLT auf Serverseite beeinträchtigt das nicht im geringsten. Dafür ist XSLT nebenbei auch entworfen worden. XSLT auf Clientseite ist dafür aber eine Katastrophe: mit einer XSLT-Seite kann nur etwas anfangen, der auch XSLT voll beherrscht. Eine solche Zwei-Klassen-Gesellschaft wollte das W3C eigentlich verhindern. Und DAS ist der Grund, weswegen sich Opera geweigert hat XSLT zu implementieren. Siehe auch die Sache mit der Semantik am Ende des Beitrags ...

XSLT ist nicht gut, sondern schlecht für die Semantik.

Blödsinn. Ich bin wirklich kein allzugroßer XML-Fan, aber XML mit XSLT ist gut für die Semantik.

Simples Beispiel:

<thread>
  <topic>XML ist gut füer die Semantik</topic>
  <url>http://www.c-plusplus.net/forum/viewtopic-var-t-is-148413.html</url>
  <author>nman</author>
</thread>

Aber wie gesagt, das wurde bereits zur Genüge besprochen.

Schönes Beispiel für einen der Fälle, bei denen du auf keinem Auge blickst, was ich sage, dir aber trotzdem nicht zu schade bist, mit Begriffen wie "Blödsinn" um dich zu hauen.
Wodurch zeichnet sich HTML und XHTML im Bezug auf Semantik aus? Kann irgendeine Maschine, Suchmaschine, Browser, egal was, etwas mit deinen Tags thread, topic, url, author anfangen? Wie sollte sie? Das ist der Unterschied zu (X)HTML. Bei XHTML haben die Tags eine exakt definierte Semantik - bei purem XML ist jedoch keinerlei Semantik definiert. Und mit dieser neuen Erkenntnis lies einfach noch mal das, was du eben als "Schwachsinn" und "Blödsinn" abgetan hast.

Und bitte diskutiere nur bei Dingen mit, von denen du eine Ahnung hast. Das spart vor allem mir Nerven und Zeit.

[nman]

minhen schrieb:

Das ist einfach eine Frage der Höflichkeit und letztlich auch der Reife.

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

Hast du richtig spitzfindig erkannt. Aber z.B. bei HTML 3 steht explizit dort, dass eine entsprechende Toolbar o.Ä. definiert wird - und eben nicht "simply ignore all <link>-tags".

Klar, immerhin muss ja erklärt werden, wofür ein Feature überhaupt gut sein soll.

Was in keinster Weise mit meiner Aussage im Widerspruch steht. Aber Hauptsache verneint, was?

Hauptsache, ich verneine die von Dir gewitterte Monokausalität und ergänze, ja.

Ob eine Leiste angezeigt wird, ob sie dauerhaft angezeigt wird oder nur wenn sie sinnvoll ist, bestimmt noch immer der Anwender und nicht der Webmaster.

Klar, wenn es darum geht, ob man die Toolbar verwenden will, wenn sie verfügbar ist. Wenn sie standardmäßig aktiviert ist, dann steht der User vor dem Problem, dass entweder immer ein bisschen Platz verschwendet oder nicht selbst bestimmt, wann die Toolbar da ist und wann nicht.

Ich habe von "dumm" gesprochen. Ob ein Unterschied zwischen "dumm" und dumm existiert und was dieser sein könnte, darfst du dir gerne selbst überlegen.

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.

vorher: Foto "Ich vorm Grill"
nächstes: Foto "Fleisch aufm Grill"
nächstes Kapitel: Fotos "Meine Geburtstagsparty"
voriges Kapitel: Fotos von der Uni
hoch: Überblick über die aktuelle Fotogalerie ("Grillparty")
Index: Übersicht über alle Fotogalerien
usw ...

Nett. Aber auch nicht mehr. Fotogalerien haben ohnehin Thumbnails, die sind fast immer wesentlich bequemer zum Navigieren als sowas.

Nein. Zeigt aber abermals schön, dass du keine Ahnung hast, wovon du redest.

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

Schönes Argument

Das liegt daran, dass das Thema schon so verdammt oft durchgekaut wurde und ich einfach keine Lust habe, diesen blödsinnigen Flame auch noch darauf auszuweiten, das Thema hatten wir schon einige Male in richtig langen hitzigen Debatten, darauf habe ich einfach keine Lust. Du etwa?

Nein. Es laufen auf Mobiltelefonen keine normalen Java-VMs und erst recht nicht mit "allen Schikanen".

Gemessen daran, dass die Dinger Telefone sind, haben die dortigen Java-VMs eine Menge Schikanen. Ein paar Ressourcen auch für sinnvolle Sachen wie XSLT und nicht nur für die neuesten Spielchen und Eyecandy zu opfern, wäre durchaus denkbar und ratsam.

Und Handys der unteren Preisklasse haben selbst heute keine Java-Unterstützung.

Ich muss zugeben, dass ich das nicht wusste, ich hatte bis jetzt nur Billigst-Handys; mein aktuelles ist mittlerweile knapp drei Jahre alt und selbst das hat Java.

Und du wirst lachen, aber im Web geht es nicht darum, wer die größere Rechenleistung hat. Ich geb dir mal was vom W3C zum Lesen:
In order for the Web to reach its full potential, the most fundamental Web technologies must be compatible with one another and allow any hardware and software used to access the Web to work together. (http://www.w3.org/Consortium/)

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

Verstehst du jetzt endlich langsam worum es Opera ging und mir gerade geht?

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. Nicht nachvollziehbar ist für mich lediglich Dein Unwille, einzusehen, dass fehlende XSLT-Fähigkeit ein Manko ist, keine Stärke.

XSLT auf Serverseite beeinträchtigt das nicht im geringsten. Dafür ist XSLT nebenbei auch entworfen worden. XSLT auf Clientseite ist dafür aber eine Katastrophe: mit einer XSLT-Seite kann nur etwas anfangen, der auch XSLT voll beherrscht.

Ich habe nirgends behauptet, dass man XHTML-Websites auf client-seitiges XSLT umstellen soll oä, ich weiß nicht, woher Du das jetzt schon wieder hast. Aber wenn ich mir irgendlwelche XML-Daten online ansehen möchte, dann ist XSLT richtig toll, eben deswegen, weil man ohne großen Aufwand XML hübsch lesbar machen kann, ohne dafür Bandbreite und Server-Rechenleistung zu verschenden.

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.

Schönes Beispiel für einen der Fälle, bei denen du auf keinem Auge blickst, was ich sage, dir aber trotzdem nicht zu schade bist, mit Begriffen wie "Blödsinn" um dich zu hauen.

Nein, Du verstehst nur nicht, warum ich Dir widerspreche. Das ist ein gewisser Unterschied.

Wodurch zeichnet sich HTML und XHTML im Bezug auf Semantik aus?

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

Kann irgendeine Maschine, Suchmaschine, Browser, egal was, etwas mit deinen Tags thread, topic, url, author anfangen?

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

Wie sollte sie? Das ist der Unterschied zu (X)HTML. Bei XHTML haben die Tags eine exakt definierte Semantik - bei purem XML ist jedoch keinerlei Semantik definiert.

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.

Diverse Suchmaschinen können auch sehr viel mit diversen XML-Formaten anfangen, aber natürlich nicht die, die nur auf (X)HTML getrimmt sind. Die müssen dann Blogs durchforsten und raten, ob bei

<h1>Dein Blog</h1>
<h2>Deine Kategorie</h2>
<h3>Dein Rant</h3>

die Kategorie nun "Dein Blog" ist oder doch "Dein Rant" oder vielleicht "Deine Kategorie". Wenn die Suchmaschine RSS oder Atom liest, dann fällt sowas wesentlich leichter.

Und mit dieser neuen Erkenntnis lies einfach noch mal das, was du eben als "Schwachsinn" und "Blödsinn" abgetan hast.

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".

Und bitte diskutiere nur bei Dingen mit, von denen du eine Ahnung hast. Das spart vor allem mir Nerven und Zeit.

Komm mal langsam runter und lies auch ein bisschen mit, was ich hier so schreibe, da sind einige Dinge dabei, die Du offensichtlich bis jetzt noch nicht verstanden hast.

edit: Quotes sind Teufelswerkzeug.

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