XSLT ist gestorben

[j.j.]

Hallo,
weil's wahrscheinlich noch nicht jeder mitbekommen hat:

Bei den drei führenden Browser-Engines ist man sich einig, daß XSLT von der Platform verschwinden soll.

WHATWG HTML Issue 11523
blink.dev – Intent to Deprecate and remove XSLT
bugzilla.mozilla.org – Investigate deprecation and removal of XSLT (deprecate and remove XSLT)

Viele werden garnicht wissen, daß es neben CSS eine zweite Methode für Stylesheets gab. Ich persönlich weine dem keine Träne nach!
(In diesem Forum gibt's XSLT nichtmal als Schlagwort)

j.j.

[Gunnar Bittersmann]

@@j.j.

Viele werden garnicht wissen, daß es neben CSS eine zweite Methode für Stylesheets gab.

Du bist wohl einer von den Vielen. XSLT tut etwas anderes als CSS – wie schon das T erkennen lässt.

Ich persönlich weine dem keine Träne nach!

Wer nicht weiß, was XSLT überhaupt ist, wird das auch nicht vermissen.

(In diesem Forum gibt's XSLT nichtmal als Schlagwort)

Es gibt das Tag „xsl“.

🖖 Live long and prosper

[j.j.]

Hallo Gunnar!

Viele werden garnicht wissen, daß es neben CSS eine zweite Methode für Stylesheets gab.

Du bist wohl einer von den Vielen. XSLT tut etwas anderes als CSS – wie schon das T erkennen lässt.

Ich persönlich weine dem keine Träne nach!

Wer nicht weiß, was XSLT überhaupt ist, wird das auch nicht vermissen.

In einer (meiner) kleinen Frontend-Welt von Browsern, HTML, CSS, Javascript/DOM/CSSOM/XPath, etc. ist XSLT allerdings wenig nützlich (auch wenn ich es tatsächlich schon verwendet habe).

Und nur diese kleine Welt ist hier Thema.

In den verlinkten Diskussionen beschweren sich Leute, daß sie RSS-Feeds (oft auch noch ausgeliefert als text/html) nicht mehr lesbar gestalten können.
Ist da nicht die Vermutung naheliegend, daß da jemand 25 Jahre CSS-Weiterentwicklung verschlafen hat?

Das XSLT dürfte hier vor allem das anclickbar machen von URLs sein – ist auch mit drei Zeilen DOM-Scripting zu erledigen.
Da mag Manchem unwohl werden, mir persönlich nicht.

[Rolf B]

Hallo j.j.,

In den verlinkten Diskussionen beschweren sich Leute, daß sie RSS-Feeds (oft auch noch ausgeliefert als text/html) nicht mehr lesbar gestalten können.

So einfach ist es auch nicht. RSS ist ein XML Format. Um die Feed-Inhalte als HTML aufbereitet anzuzeigen, genügt es nicht, wenn der Server es mit diesem MIME-Typ ausliefert. Selbst dann nicht, wenn man es wie die Wikipedia macht, deren RSS-Feeds HTML Blobs als Einträge enthalten.

XSLT ist eine Möglichkeit, einen solchen Feed in mehr oder weniger brauchbares HTML zu konvertieren. Man kann aber auch den Feed per JavaScript in ein Document-Objekt einlesen, dieses traversieren und die Inhalte als HTML rendern. Setzt natürlich Kenntnis des Schemas voraus, aber das ist ja bei XML immer so.

Ob XSLT oder JavaScript - programmieren ist beides.

Rolf

[j.j.]

Hallo Rolf!

In den verlinkten Diskussionen beschweren sich Leute, daß sie RSS-Feeds (oft auch noch ausgeliefert als text/html) nicht mehr lesbar gestalten können.

So einfach ist es auch nicht. RSS ist ein XML Format. Um die Feed-Inhalte als HTML aufbereitet anzuzeigen, genügt es nicht, wenn der Server es mit diesem MIME-Typ ausliefert. Selbst dann nicht, wenn man es wie die Wikipedia macht, deren RSS-Feeds HTML Blobs als Einträge enthalten.

Um die Feeds lesbar anzuzeigen, muß ich die Datei gestalten mit CSS oder XSLT. Das is unabhängig davon, ob sie als XML oder HTML ausgeliefert wird.
Um URLs klickbar zu machen, brauche ich nur XSLT oder CSS + Javascript, auch das ist halbwegs unabhängig vom Media-Type.

Ich weiß nicht, was diese Leute mit Ihren RSS-Feeds machen.
Ich entnehme den Diskussionen lediglich, daß sie sich über das Ableben von XSLT im Browser (legitimerweise) beschweren, weil es dann nicht mehr funktioniert wie vorher.

Ich entnehme dem auch, das das meistens als text/html an den Browser ausgeliefert wird, mglw. weil es zu Zeiten entstanden ist, als IE kein XML akzeptiert hat (kann ich nicht beurteilen).

Von Lösungen sprechen diese Leute kaum.

Von Lösungen spricht Mason Freed (Google). Er hat ein Polyfill entwickelt mfreed7/xslt_polyfill (ein eingeschleustes <script>), das offenbar in praktisch allen getesteten Fällen funktionieren soll (kann ich nicht beurteilen).

j.j.

[Rolf B]

Hallo j.j.,

Um die Feeds lesbar anzuzeigen, muß ich die Datei gestalten mit CSS oder XSLT.

CSS - hm, ja, da war was. CSS ist nicht nur für HTML gedacht, ich kann auch XML damit stylen.

Aber wie? Ein XML Dokument kann, meine ich, irgendwie deklarieren, dass es mit einem bestimmten CSS formatiert werden möchte. Das müsste der RSS-Spender erstmal tun.

Alternativ: Für XML hat der Browser kein Default-Stylesheet, und wie ich meinen Browser dazu bewege, externes XML mit CSS zu stylen, da müsste ich jetzt erstmal recherchieren. Geht das überhaupt, ohne dass ich den Kram mit JavaScript zusammenkleistere?

Rolf

[ThomasM]

Hallo Rolf,

als Processing Instruction im XML-Dokument:
<?xml-stylesheet href="name.css" type="text/css"?>

Aber wie? Ein XML Dokument kann, meine ich, irgendwie deklarieren, dass es mit einem bestimmten CSS formatiert werden möchte. Das müsste der RSS-Spender erstmal tun.

In einem Online-Kurs von 2020 gezeigt.

Grüße,
Thomas

[j.j.]

Hallo R&T!

Hallo Rolf,

als Processing Instruction im XML-Dokument:
<?xml-stylesheet href="name.css" type="text/css"?>

Aber wie? Ein XML Dokument kann, meine ich, irgendwie deklarieren, dass es mit einem bestimmten CSS formatiert werden möchte. Das müsste der RSS-Spender erstmal tun.

In einem Online-Kurs von 2020 gezeigt.

Grüße,
Thomas

Je nach Fall kann man evtl. auch einfach

<style xmlns="http://www.w3.org/1999/xhtml"> ... </style>
<script xmlns="html="http://www.w3.org/1999/xhtml"> ... </script>

reinschreiben.

Für XML Sitemaps mache ich es oft so (oder Script und Style zusammen in eine externen JS-Datei, damit die Suchmaschinen nicht ständig für sie irrelevantes Zeug mit laden müssen)

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1"
        xmlns:html="http://www.w3.org/1999/xhtml">

<html:meta name="viewport" content="width=device-width"></html:meta>
<html:title> ... </html:title>

<url>... </url>
...
<html:style> ... </html:style>
<html:script> ... </html:script>
...

Wenn Du es genau machen willst, beachte sitemaps.org/schemas/sitemap/0.9/sitemap.xsd. Fremde Elemente sind glaub ich nur am Anfang nach <urlset> erlaubt oder als letztes Element in <url>, ist der Praxis ist das wurscht.

j.j.

[Robert B.]

Moin,

man sollte immer seinen persönlichen Standpunkt verallgemeinern und den Nutzen dessen, was man selbst nicht braucht, auch für andere verneinen. Lass Dir da bloß nichts Anderes einreden.

Viele Grüße
Robert

[j.j.]

Grüß Gott!

@@j.j.

Viele werden garnicht wissen, daß es neben CSS eine zweite Methode für Stylesheets gab.

Du bist wohl einer von den Vielen. XSLT tut etwas anderes als CSS – wie schon das T erkennen lässt.

Thema verfehlt. Ich habe nichts Gegenteiliges behauptet.

Ich persönlich weine dem keine Träne nach!

Wer nicht weiß, was XSLT überhaupt ist, wird das auch nicht vermissen.

Wow! Richtige Folgerung bei falscher Voraussetzung – das schafft kein Sterblicher!

Auch logisch, daß für die Gottähnlichen keine irdischen Regeln gelten.

• Formulieren Sie bitte höflich und wertschätzend.

j.j.

[Gunnar Bittersmann]

@@j.j.

Viele werden garnicht wissen, daß es neben CSS eine zweite Methode für Stylesheets gab.

Du bist wohl einer von den Vielen. XSLT tut etwas anderes als CSS – wie schon das T erkennen lässt.

Thema verfehlt. Ich habe nichts Gegenteiliges behauptet.

„Neben CSS eine zweite Methode für Stylesheets“ klang nicht nur für mich anders.

Wow! Richtige Folgerung bei falscher Voraussetzung – das schafft kein Sterblicher!

Doch, das schafft jeder:

A	B	A ⇒ B
W	W	W
W	F	F
F	W	W
F	F	W

🖖 Live long and prosper

[ThomasM]

Hallo j.j.,

Bei den drei führenden Browser-Engines ist man sich einig, daß XSLT von der Platform verschwinden soll.

Das ist traurig und zeugt nicht gerade von Weitsicht. Es sagt doch bereits alles, wenn Firmen Milliarden in KI-Rechenzentren pumpen können, aber nicht mal in der Lage zur Modernisierung von Browser-Implementierungen sind.

Viele werden garnicht wissen, daß es neben CSS eine zweite Methode für Stylesheets gab. Ich persönlich weine dem keine Träne nach!

Das ist natürlich Unsinn, denn XSLT formatiert nicht, sondern transformiert XML, aber auch andere textbasierte Formate wie JSON, in vielfältige Ausgaben. Die Formatierungssprache für PDF ist XSL-FO und diese läuft außerhalb von Browsern.

Wer XSLT clientseitig nutzt, wird Alternativen finden, etwa SaxonJS oder anderes JS-getriebenes Parsing.

Ansonsten sind die XSLT-Versionen 2.0, 3.0 und demnächst 4.0 in Verbindung mit dem ebenfalls stark weiterentwickelten XPath sehr mächtig und spielen überwiegend abseits von Browsern in bestimmten Branchen wie Technische Kommunikation, Verlagswesen usw. weiterhin eine wichtige Rolle. Ich habe über viele Jahre damit und darüber gearbeitet. Da ist es mir auch ziemlich egal, was die XML-Hater von sich geben.

Grüße,
Thomas

[Rolf B]

Hallo Thomas,

ich bin kein XML-Hater, eher ein XML-Ignorant. Ich musste mich im Rahmen von .net Konfigurationsdateien mit XML-Basics beschäftigen und hatte nie Bedarf an großen XML-basierenden Projekten.

Vermutlich geht es vielen anderen auch so. XML ist verbös, wer Daten in großem Stil austauschen muss (so wie es mein Brötchengeber tut), verwendet sparsamere Formate.

Wenn ich meine Daten nicht als XML vorliegen habe und erstmal XML generieren müsste, um damit im Browser eine XSLT-Transformation vorzunehmen, dann spare ich vermutlich 80% des Aufwands, wenn ich das gewünschte Ergebnis direkt aus den Ausgangsdaten generiere, anstatt ein aufwändiges XSLT-Stylesheet zu verfassen und zu pflegen.

Die Browserhersteller würden XSLT nicht einstampfen, wenn ihre Telemetrie signifikante Nutzungszahlen dafür belegen würde.

Rolf

[ThomasM]

Hallo Rolf,

Vermutlich geht es vielen anderen auch so. XML ist verbös, wer Daten in großem Stil austauschen muss (so wie es mein Brötchengeber tut), verwendet sparsamere Formate.

Mir geht es ja weniger um Austausch von Daten, sondern um ihre Verarbeitung.

XML ist halt weiterhin der Ansatz für strukturiertes Dokumentieren. Niemand möchte Handbücher mittels JSON verfassen. XML-Architekturen wie DITA, DocBook, TEI und andere werden weiterhin ihre Nische finden oder behaupten.

IT'ler sollten auch eher die Finger von XML lassen. ;)

Grüße,
Thomas

[Gunnar Bittersmann]

@@Rolf B

XML ist verbös

Oder vergut, je nach Sichtweise.

Bei JSON sucht man sich einen Wolf, welche Klammer da jeweils geschlossen wird. End-Tags in XML sind selbsterklärend. Die Geschwätzigkeit von XML hat durchaus auch ihre Vorteile.

🖖 Live long and prosper

[ThomasM]

Hallo Gunnar,

Bei JSON sucht man sich einen Wolf, welche Klammer da jeweils geschlossen wird. End-Tags in XML sind selbsterklärend. Die Geschwätzigkeit von XML hat durchaus auch ihre Vorteile.

Wenn ich einen neuen XML-Kurs starte, dann kommen auch die zehn ursprünglichen Entwurfsziele zur Sprache, u. a. »Knappheit von XML-Markup ist von minimaler Bedeutung«.

Grüße,
Thomas

[Rolf B]

Hallo,

Oder vergut, je nach Sichtweise.

🤣 - ich habe doch nur versucht, verbose zu übersetzen.

Bei JSON sucht man sich einen Wolf, welche Klammer da jeweils geschlossen wird

Mit dem passenden Editor ist's ein braves Lämmlein. Aber ich würde JSON auch nicht manuell erstellen wollen. Datenbestände in XML auch nicht (nur für die sehe ich einen Sinn in XSLT).

XML ist halt weiterhin der Ansatz für strukturiertes Dokumentieren. Niemand möchte Handbücher mittels JSON verfassen.

Handbücher in JSON? Brrrr.
Strukturieres Dokumentieren? Dokumentieren? 😱

Ich bestreite ja nicht, dass XML seinen Anwendungsbereich hat. Für die Browserhersteller ist die Frage, ob dieser Anwendungsbereich sich auf XSLT im Browser erstreckt. Das scheint jemand mit "kaum bis gar nicht" beantwortet zu haben.

Diejenigen, die das brauchen, finden bestimmt irgendein Browserplugin, das ihnen dabei weiterhilft. Oder transformieren am Server. Ich nehme an, das ist die Argumentation bei den Herstellern.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Mit dem passenden Editor ist's ein braves Lämmlein.

Der müsste geteilten Bildschirm unterstützen. Klammernpaare zu finden ist das eine, Anfang und Ende gleichzeitig auf dem Schirm zu haben das andere.

Aber ich würde JSON auch nicht manuell erstellen wollen.

Ich tu das für meine Star-Trek-Daten. Das TNG-JSON-LD ist auf über ein halbes Megabyte angewachsen.

🖖 Live long and prosper

[j.j.]

Hallo Rolf,

Die Browserhersteller würden XSLT nicht einstampfen, wenn ihre Telemetrie signifikante Nutzungszahlen dafür belegen würde.

Die extrem niedrigen Nutzungszahlen werden erst richtig relevant in Verbindung mit völlig unverhältnimäßigem Wartungsaufwand und wiederkehrenden Sicherheitsproblemen für alle Nutzer.

In einer der Disskussionen schrieb wörtlich, der einzige Grund für das Ende von XSLT wäre die Faulheit der Browserentwickler.

Bei solchen Kommentaren fallen mir immer die Alternative Facts des Donald T. ein, oder Dieter Nuhr.

j.j.

[ThomasM]

Hallo zusammen,

In einer der Disskussionen schrieb wörtlich, der einzige Grund für das Ende von XSLT wäre die Faulheit der Browserentwickler.

Nicht der einzige, aber ein Grund ist das schon, da es eben keine Anstrengungen für Implementierungen > 1.0 gab. Acht Jahre nach 1.0 hätte ab 2007 die Möglichkeit bestanden, die mächtigen Erweiterungen von XSLT und XPath 2.0 zu integrieren. Das hätte aus meiner Sicht die clientseitige Nutzung von XSLT viel attraktiver machen können. 2017 kam dann mit XSLT 3.0 / XPath 3.1 noch eine Schippe drauf.

Grüße,
Thomas

[j.j.]

Hallo zusammen,

In einer der Disskussionen schrieb wörtlich, der einzige Grund für das Ende von XSLT wäre die Faulheit der Browserentwickler.

Nicht der einzige, aber ein Grund ist das schon, da es eben keine Anstrengungen für Implementierungen > 1.0 gab. Acht Jahre nach 1.0 hätte ab 2007 die Möglichkeit bestanden, die mächtigen Erweiterungen von XSLT und XPath 2.0 zu integrieren. Das hätte aus meiner Sicht die clientseitige Nutzung von XSLT viel attraktiver machen können. 2017 kam dann mit XSLT 3.0 / XPath 3.1 noch eine Schippe drauf.

Grüße,
Thomas

Hallo Thomas!

Hier ein Kommentar von berufenem Munde (Henri Sivonen, Mozilla):
whatwg/html/issues/11578#issuecomment-3213412959

Was Du sagst ist wohl nicht falsch. Ich will hier nichts und Niemanden vereidigen (Google zahlt zuwenig pro überzeugten Webentwickler 🙁️),

aber versuch doch mal eine Perspektivwechsel:
Ein Webbrowser ist heute - davon kann man halten was man will - eine gigantische Maschine. Ich kann mich noch an Zeiten erinnern, da hatte Opera 3Mb Downloadvolumen, Firefox war bei über 5Mb. Daraufhin hat man bei Mozilla große Anstengungen unternommen, um unter 5 zu kommen. Und heute?

Die Dinge sind komplex, alles hängt mit allen zusammen. AFICT hat keine Engine einen Spezialisten speziell für XSLT. Und die Nutzungszahlen sind gering. Ungefähr einmal jährich ist eine Sicherheitslücke zu stopfen.

Laß den Leuten ihre wohlüberlege Entscheidung, von XSLT Abschied zu nehmen. Sie wissen warum und sie vesuchen ihr bestes, negative Folgen zu minimieren. Und diese Leute tun das völlig unabhängig vom jeweilen Arbeitgeber.

j.j.

[ThomasM]

Hallo j.j.,

Hier ein Kommentar von berufenem Munde (Henri Sivonen, Mozilla):
whatwg/html/issues/11578#issuecomment-3213412959

Naja, das Thema war ja von Anfang an durch, da braucht nun niemad mehr über 3.0-Unterstützung zu fabulieren.

Laß den Leuten ihre wohlüberlege Entscheidung, von XSLT Abschied zu nehmen. Sie wissen warum und sie vesuchen ihr bestes, negative Folgen zu minimieren. Und diese Leute tun das völlig unabhängig vom jeweilen Arbeitgeber.

Natürlich lasse ich ihnen diese Entscheidung. Mir geht es gar nicht um meine XSLT-Anwendungen, welche entweder lokal oder serverseitig laufen. Mir geht es um die Bewahrung eines Ökosystems, welches ich nun bereits 30 Jahre begleite.

Dein reißerischer Posting-Titel ist eben genau nicht geeignet, um das Thema zu befrieden.

Ich merke aber gerade, dass ich mich hier schon wieder viel zu lange aufhalte und mich letztlich nur provozieren lasse. Da warte ich lieber auf eine XSLT-relevante Frage.

Grüße,
Thomas

[j.j.]

Hallo Thomas!

Dein reißerischer Posting-Titel ist eben genau nicht geeignet, um das Thema zu befrieden.

Mir war/ist nicht kar, daß das Thema XSLT hier ein zu befriedender Kriegsschauplatz ist.

Naja, „XSLT im Browser ist gestorben“ wäre richtiger gewesen. Weniger widerspräche meinem Stil.

Ich merke aber gerade, dass ich mich hier schon wieder viel zu lange aufhalte und mich letztlich nur provozieren lasse.

Schade, daß ich provokativ rüber gekommen bin, war (bei Dir) absolut nicht beabsichtigt, ich weiß auch nicht wo.

Gute Nacht!
j.j.

[Robert B.]

Moin Rolf,

Wenn ich meine Daten nicht als XML vorliegen habe und erstmal XML generieren müsste, um damit im Browser eine XSLT-Transformation vorzunehmen, dann spare ich vermutlich 80% des Aufwands, wenn ich das gewünschte Ergebnis direkt aus den Ausgangsdaten generiere, anstatt ein aufwändiges XSLT-Stylesheet zu verfassen und zu pflegen.

Die Browserhersteller würden XSLT nicht einstampfen, wenn ihre Telemetrie signifikante Nutzungszahlen dafür belegen würde.

XSLT hatte schon seine Vorteile in der Handhabung, als die Browser noch Feeds direkt unterstützt haben. So konnte man aus einem Newsfeed oder einem RSS-Podcast-Feed mit XSLT direkt eine schön lesbare Seite erstellen – bei dem Podcast-Feed z.B. für die Links zu den Musik-Dateien direkt die audio-Elemente erzeugen.

Viele Grüße
Robert

[j.j.]

Hallo Thomas!

Viele werden garnicht wissen, daß es neben CSS eine zweite Methode für Stylesheets gab. Ich persönlich weine dem keine Träne nach!

Das ist natürlich Unsinn, denn XSLT formatiert nicht, sondern transformiert XML, aber auch andere textbasierte Formate wie JSON, in vielfältige Ausgaben.

Den Unsinn hast Du hineininterpretiert.
Meine Bemerkung galt dem Wort Stylesheet, das für Viele ausschließlich mit CSS verbunden ist.
Ich habe nicht behauptet, daß CSS- und XSLT-Stylesheets dasselbe leisten oder ähnlich funktionieren.

j.j.

[Robert B.]

Moin,

Das ist natürlich Unsinn, denn XSLT formatiert nicht, sondern transformiert XML, aber auch andere textbasierte Formate wie JSON, in vielfältige Ausgaben.

Den Unsinn hast Du hineininterpretiert.
Meine Bemerkung galt dem Wort Stylesheet, das für Viele ausschließlich mit CSS verbunden ist.
Ich habe nicht behauptet, daß CSS- und XSLT-Stylesheets dasselbe leisten oder ähnlich funktionieren.

XSLT sind aber keine Stylesheets, sondern immer noch eine Transformation. Insofern ist die Aussage XSLT als Stylesheet zu bezeichnen, Unsinn.

Viele Grüße
Robert

[Rolf B]

Hallo Robert,

🕵️‍♂️

Hmmm.

XSLT ⊂ XSL

Wofür steht XSL?

Genau: eXtended Stylesheet Language.

Womit beginnt eine XSLT-Datei?

<xsl:stylesheet
    version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns="http://www.w3.org/1999/xhtml">

(D)ie Aussage XSLT als Stylesheet zu bezeichnen, (ist) Unsinn.

Kombiniere: Nicht unbedingt.

Rolf

[j.j.]

Hallo!

XSLT sind aber keine Stylesheets, sondern immer noch eine Transformation. Insofern ist die Aussage XSLT als Stylesheet zu bezeichnen, Unsinn.

Viele Grüße
Robert

Also schlimmer geht's nimmer?

A transformation expressed in XSLT is called a stylesheet.

https://www.w3.org/TR/xslt-10/#section-Introduction

j.j.

[Rolf B]

Hallo j.j.,

Also schlimmer geht's nimmer?

Doch. Wenn man sachliche Entgegnungen durch persönliche Angriffe ersetzt. Bitte bleibt entspannt!

Rolf

[j.j.]

Hallo j.j.,

Also schlimmer geht's nimmer?

Doch. Wenn man sachliche Entgegnungen durch persönliche Angriffe ersetzt. Bitte bleibt entspannt!

Rolf

Ach Rolf, Du meinst es ja gut, aber ich kann Dir nicht folgen.
An einem ähnlichen Punkt waren wir vor einiger Zeit schon mal. Diesmal eine Antwort:

Da meine Aussage fälschlich als „Unsinn“ bezeichnet wurde, finde ich als Fortsetzung „noch unsinniger“ oder „schlimmer“ recht treffend und moderat.

R. B. schrieb:

XSLT sind aber keine Stylesheets, sondern immer noch eine Transformation […] Unsinn

Warum nicht so, im Sinne von Diskussion, Austausch, Erkenntnisgewinn?

Sind XSLT überhaupt Stylesheets? Ist es nicht eine Transformation?

Weil Diskussion, Austausch, Erkenntnisgewinn nicht beabsichtigt war. Formale Sachlichkeit ändert nichts (darin ist Gunnar übrigens Vollprofi).

Das ist kein Einzelfall, im Gegenteil. Und ich habe hier wirklich nicht oft gepostet (oft war das in den 1990ern und danach, da gab es einzelne Aggroschlaumeier, die gingen in der Masse unter).
Einigen hier geht es scheinbar eher um Machtspiel statt Austausch, um Besserwisser- und Wichtigtuerei.

Während Du das alles normal findest, bin ich sowas in einem hochklassigen technischen Forum nicht gewohnt (in keinem meiner zwei Berufsfelder). Es regt mich auf, es hallt zurück.

Und wenn man schon über schlechtes Sozialverhalten einzelner (Hochaktiver) reden muß, sollte man gleich einpacken. Sozusagen eine Win-win-Situation.

Soweit meine unmaßgebliche Einzelmeinung.
Ich wünsch Euch noch viel Spaß und viele neue Erkenntnisse und bin dann mal weg.
j.j.

[Hans85]

gut, das hat für mich schon immer in die Sparte "Sachen, die die Welt nicht braucht" gehört.