Unterschiedliche Versionen des Skriptes "Mehrzeilige Tableiste"

Es sind zwei unterschiedliche Skripte

Und wenn ich es richtig sehe, ist Endors Version eine sehr aktuelle.
Modifizierbar sind alle Versionen!
Kommt darauf an, was Du willst.

Würde aber Endors Version empfehlen, da diese auch weiter gepflegt wird.

Skriptes "Mehrzeilige Tableiste" enthält 800-1300 Zeilen

CSS-Style "Mehrzeilige Tableiste" by Aris-t2 enthält 80 Zeilen

Zitat von Stoiker

... kann aber mangels Kenntnisse nicht einschätzen ab wann bei folgenden Updates von Firefox da wieder Probleme auftauchen könnten.

Das kann ich auch nicht, aber es wird definiv bei den allermeisten Skripten passieren, dass Mozilla etwas ändert und das Skript,
dass auf interne Funktionen zugreift oder erweitert oder, oder, wieder angepasst werden muss.
So ist es nun mal.

Zitat von Stoiker

Daher bleibe ich wohl bei der Version die Endor übersetzt hat,

Das Skript? => MultiRowTabLiteforFx.uc.js

Zitat von Stoiker

... auch wenn mir dort ein paar Feinheiten fehlen

Was wäre das denn?

Zitat von lenny2

Skriptes "Mehrzeilige Tableiste" enthält 800-1300 Zeilen

CSS-Style "Mehrzeilige Tableiste" by Aris-t2 enthält 80 Zeilen

Und was möchtest du damit aussagen? Die Anzahl von Code-Zeilen gilt schon ganz lange nicht mehr als relevante Metrik für Entwickler. Ich würde außerdem behaupten, es gibt auch entsprechende Unterschiede in Funktionalität und Optionen.

Ich hatte ja mal in den Raum geworfen, dass es eine Basis-Version gibt, die jeder für sich nachvollziehbar verändert. Wenn man eine alte und neue Basis-Version vergleicht, die Änderungen ins eigene Script überträgt, sollte doch jedem geholfen sein. Denn mal wieder zeigt diese Anfrage auf, dass es zu viele persönliche Scripte von [script] gibt, aber kaum jemand Plan hat, was er wo geklaut und eingebaut hat.

Zitat von .DeJaVu

Wenn man eine alte und neue Basis-Version vergleicht, die Änderungen ins eigene Script überträgt, sollte doch jedem geholfen sein.

Und wer ist „man“? Eine schöne Idee, aber die meisten Nutzer werden das nicht machen, sie nehmen das, was man ihnen vorsetzt und, wenn etwas Eigenes dabei sein soll, werden die Helfer nicht umhin können, das wieder hinzubiegen. Leichter ist es da, die spezielle Skript-Version lediglich so zu korrigieren, dass das Skript wieder funktioniert und doch die „Spezialitäten“ gewährleistet sind.

"man" = Endor als Basisversion, mein Verständnis.

Zitat von milupo

aber die meisten Nutzer werden das nicht machen, sie nehmen das, was man ihnen vorsetzt

Dann sollte oder muss man sich damit zufrieden geben.

Zitat von milupo

wenn etwas Eigenes dabei sein soll, werden die Helfer nicht umhin können, das wieder hinzubiegen.

Ja, aber. Mit Basis oder ohne? Bei "ohne" ist dann beim aktuellen Mischmasch Kauderwelsch, jeder sein eigener Lutscher. Mit Basis kann man eben die Änderungen der Basis mit zwei Klicks übertragen, bei NPP ist das so möglich. Aber das bedarf eben auch der maximalen Zustimmung seitens des entsprechenden Nutzers. Und als Helfer sollte man dann aber auch konkret darauf hinweisen: Basis mit persönliche Änderungen, ansonsten sieh zu. Hat einfach ökonomische Ursachen: schnellere Hilfe, ohne persönliche Animositäten abzuwimmeln. Und das hat dann auch Garantie, dass es läuft und nicht wie des Öfteren neuerdings darauf hinweisen muss, dass dann ein anderes Script stört.

Tja, da wollte ich ja hin, aber alle Ansätze dazu wurden abgeschmettert.
Somit ist es mir jetzt egal, und an bitten am Header oder ähnlichem nichts zu ändern hält sich ja auch keine Sau!
Da werden Skripte miteinander verwurschtelt, "aus zwei mach eins" obwohl in beiden Skripten gleiche Variablen genutzt werden,
Versionsnummern werden nicht übernommen oder gar gelöscht, und Quellenangaben sind ja auch nur Ballast.

Mir egal, wenn das Skript zu retten ist, helfe ich, wenn nicht, lese ich den nächsten Beitrag.

Zitat von Sören Hentzschel

Zitat von lenny2

Skriptes "Mehrzeilige Tableiste" enthält 800-1300 Zeilen

CSS-Style "Mehrzeilige Tableiste" by Aris-t2 enthält 80 Zeilen

Und was möchtest du damit aussagen? Die Anzahl von Code-Zeilen gilt schon ganz lange nicht mehr als relevante Metrik für Entwickler. Ich würde außerdem behaupten, es gibt auch entsprechende Unterschiede in Funktionalität und Optionen.

Wenn sich mal jemand hinsetzen würde, um den aufgeblähten JS Code mit den reinen CSS Versionen von Aris oder MrOtherGuy zu vergleichen, und uU via JS zu ergänzen wo nötig, dann kann man sich über Funktionalität und Optionen unterhalten.

(PS: Auf keinen Fall werde (oder könnte) ich dieser Jemand sein. )

Zitat von Horstmann

MrOtherGuy

multi-row_tabs.css Super! Funktioniert mit Tabs Groups

/* Make tab groups collapse */
tab-group[collapsed] .tabbrowser-tab[fadein]:not([pinned]){
 min-width: 0 !important;
}

Zitat von Stoiker

Bleibt die Frage wie das aufzuziehen

Ich denke, da könnte man die Scripte nehmen, die Endor anbietet. Evtl auch freiwillige Organisationsarbeit anbieten, Scripte, die er nicht hostet, bislang nicht hostet, einzupflegen, ggf zu übersetzen. Das sollte er nicht allein machen.

Und dann melden sich all die, idealerweise in einem eigenen Thema, die ein komplett anderes Script nutzen, dass man ebenfalls einpflegen könnte. Oder dem von Endor ähnlich ist, und darauf basieren können mit Nutzer-spezifischen Anpassungen.

Was ich von Sören noch im Kopf habe, meine ich jedenfalls so. Dass CSS nicht mehr intergriert wird, wenn die Basis es nicht erfüllt. Hat eh so nur Nachteile.

Aber vielleicht sollte man endlich Endor fragen, was er davon hält

Zitat von .DeJaVu

Was ich von Sören noch im Kopf habe, meine ich jedenfalls so. Dass CSS nicht mehr intergriert wird, wenn die Basis es nicht erfüllt. Hat eh so nur Nachteile.

Also bei manchen Helfern hier, habe ich den Eindruck, dass sie zwar ein Basis-Skript haben wollen, andererseits aber Unmengen von CSS-Codes ins Skript einbauen. Da kann dann m. E. nicht mehr von Basis die Rede sein.

Zitat von milupo

Also bei manchen Helfern hier, habe ich den Eindruck, dass sie zwar ein Basis-Skript haben wollen, andererseits aber Unmengen von CSS-Codes ins Skript einbauen. Da kann dann m. E. nicht mehr von Basis die Rede sein.

Einen Unterschied muss man aber machen zwischen einem reinen CSS Code Block innerhalb einem JS Script, und der Einbindung von Styles direkt via JS.

Das erstere könnte man problemlos aus einem JS Script heraustrennen, je mehr vom zweiten Fall existiert, desto komplexer die Verschachtelung, und die Problembehebung bzw. Aktualisierung.

Das Problem liegt auch nicht unbedingt an den "Helfern", sondern an vielen Usern, die nicht die Basiskenntnisse lernen wollen, und die ausdrücklich für sie maßgeschneiderte Codes erfragen und erwarten - und immer eine All-in-One Lösung.

Wenn man vor dem Hintergrund einen Code bastelt, fragt man sich irgendwann ob man 20 Code Versionen für 20 Leute schreiben will, oder lieber ein paar Optionen einbaut, die leicht anzupassen, oder wenn nötig leicht erklärbar sind bei individuellen Wünschen.

Darüber hinaus sollte man auch ein Grundwissen mitbringen - woran es mir selber mangelt - um die Komplexität eines Codes überhaupt beurteilen zu können; mehr Code kann oft auch der Effizienz, der Kompatibilität, und tatsächlich der Vereinfachung dienen.

Ich denke, es so aufgenommen zu haben, dass CSS in Scripten kann, aber eigentlich nicht optimal ist. Und dann kommt bei einigen wohl der Umstand zum Tragen, dass das genutzte CSS eh nur Kraut und Rüben ist, weshalb man es daher lieber im Script hätte. Da wird der Bock zum Gärtner gemacht.

Hey, da ist jeder hier gefragt, der Scripte nutzt. Keine Meldung sagt schlichtweg: ist mir egal bis Zustimmung. Wenn aber der überwiegende Tenor eher die Klein-Klein-Lösung bevorzugt, dann bedeutet das letztlich Nachteile.

Ich merke nur, dass immer noch Nutzer ankommen mit Problemchen, die vor 4 Wochen oder noch früher schon behoben worden sind -> "on..."-Syntax. Das kann es doch nicht sein? Will man ständig nacharbeiten müssen, oder auch mal nach vorne schauen dürfen? Bislang sind es doch die Nightly-Nutzer, die sich zeitig melden. Und leider immer noch eine ganz kleine Gruppe, die versucht, das zu beheben - hier, da und dort, und dann wieder da drüben, dort drüben, und dann noch/wieder in Posemuckeldingeskirchen.

Das ist wie die Golden-Gate-Bridge in San Francisco - wenn die Rostmaler am Ziel angekommen sind, fangen sie vorne wieder an, und haben wieder keinen Fortschritt, sondern pinseln immer am selben Symptom. So können sich Scripte nicht weiterentwickeln. Nicht immer alice or Japan, sondern Camp Firefox!

Wegen Scripte <> CSS. Eine Trennung hat erhebliche Vorteile. Die Scripte werden kleiner, übersichtlicher. Und beim CSS kann jeder wie lustig ist anpassen, ohne das funktionierende Script anpacken zu müssen, ggf darin Fehler einzubauen, weil man davon keinen Plan hat.
Das Script ändert sich, dass CSS bleibt - oder andersrum. Minimierter Aufwand.

Das ist nur eine Vision, von mir. Kann so werden, oder nicht. Es ist eure Freizeit, die Freizeit der Helfer. Ihr werdet alle nicht jünger, auch mit Rente könnte sich man einer was anderes vorstellen, als 8 Stunden am Rechner zu hocken und Scripte oder CSS zu debuggen. Wer das allerdings als Passion sieht, es gibt wirklich schönere Dinge in dieser Zeitspanne.

Als Nebenschauplatz. Sollte jemand eine Frage zu (s)einem Script stellen, könnte der aktuelle Helfer eine Antwort schreiben, ähnlich:

"hey, ich bin dran, komm in 30 Minuten wieder"

Damit wissen andere, dass sie nicht weiter investieren müssen für diesen Zeitraum, und können andere Fragen beantworten. Ist nur eine Idee, könnte Verwirrungen vorbeugen.

Zitat von .DeJaVu

..., dass CSS in Scripten kann, aber eigentlich nicht optimal ist.

Das trift auf jeden Fall beim erstellen von Pages zu!
Da wird schön getrennt zwischen HTML, JavaSkcipt und CSS!
Das sind aber dann auch meistens große Projekte, wo z.B. JavaScript und auch teilweise CSS seitenübergreifend angewendet werden.
Da würde ein File sehr bald total unübersichtlich werden, wenn alle drei Codes darin verwendet werden würden.

Bei so kleinen Anwendungen, wie wir sie für den Firefox verwenden ist es gar nicht schlimm, wenn JavaScript und CSS
in den Files Verwendung finden.

Wir müssten uns nur darauf einigen, anstatt Designvorhaben in JavaScript wirklich nur in CSS einzubinden!
Denn da hat Horstmann absolut recht, die Basis, also das JavaScript könnte immer gleich sein,
nur das CSS wäre dann individuell!

Zitat von Mira_Belle

Bei so kleinen Anwendungen, wie wir sie für den Firefox verwenden ist es gar nicht schlimm, wenn JavaScript und CSS
in den Files Verwendung finden.

Wenn sich aber die JavaScript-Datei um 80 Zeilen vergrößert und nur durch CSS kann das nicht normal sein. Wenn dann vielleicht noch mehr CSS drin steht als JavaScript-Code. Gegen kleine Codes habe ich nichts, z. B. um ein durch das Skript eingefügtes Symbol zu positionieren, z. B. mit background-position oder mit padding- oder margin-Abständen. Aber so wie ich das letztens in einem Thread gesehen hatte, wo dann harff182 kapituliert hat, der bloß wollte, dass sein Skript wieder funktioniert, darf es nicht sein.

Zitat von Mira_Belle

Denn da hat Horstmann absolut recht, die Basis, also das JavaScript könnte immer gleich sein,
nur das CSS wäre dann individuell!

Wirklich individuell ist CSS in einer eigenen Datei. Und es ist ja nun auch nicht neu, dass CSS-Dateien von Skript-Entwicklern mitgeliefert werden.

Zitat von milupo

Wirklich individuell ist CSS in einer eigenen Datei. Und es ist ja nun auch nicht neu, dass CSS-Dateien von Skript-Entwicklern mitgeliefert werden.

Gib mir ein einziges Beispiel.