UserJS zum sortieren
bleicher
- zu diesem forum
0 LX
Grüße,
hab die alte UserJS etwas aufgepeppt - aber nciht optimiert, vllt kann das ja einer der gurus übernehmen :)
zusätzlich zum farbigen markieren der neusten posts, sortiert es jetzt alle eigene posts (sofern in den forumoptionen markeirt) auf die geantwortet wurde aus und sammelt oben in eigener liste die man ausblenden kann
// ==UserScript==
// @include http://forum.de.selfhtml.org/*
// ==/UserScript==
function selfhtmldatumsleser(){
var antworten=[]
var host=window.location.host;
var datum,zeit,temp, timestamp,diff,color;
var now=new Date();
now=now.getTime();
var spans=document.querySelectorAll("span.date");
for(var q=0;q<spans.length;q++){
//alert(spans[i].className);
//jetzt datum rausfiltern
datum=spans[q].innerHTML.split(",");
zeit=datum[1].split(":");
datum=datum[0].split(".");
timestamp=new Date(datum[2],(datum[1]-1),datum[0],zeit[0],zeit[1]);
diff=(now-timestamp.getTime())/60000;
if(diff<1){
spans[q].style.color="#f1630c";
spans[q].style.fontSize="150%";
}else if(diff>=1 && diff <4){
spans[q].style.color="#d96117";
spans[q].style.fontSize="130%";
}else if(diff>=4 && diff <10){
spans[q].style.color="#fa670c";
spans[q].style.fontSize="120%";
}else if(diff>10 && diff<15){
spans[q].style.color="#eb6513";
spans[q].style.fontSize="110%";
}
}
}
function selfhtmlmypostschieber(){
var myP=document.querySelectorAll("li.own-posting");
var thread;
var root=document.getElementById("root");
var myLi=document.createElement("li");
root.insertBefore(myLi, root.firstChild);
//myLi.innerHTML="boo!";
myLi.style.backgroundColor="#eee";
var uList=document.createElement("ul");
uList.id="listeMitMeinenPostings";
var button=document.createElement("li");
button.innerHTML="hide/show";
button.onclick=function(){
var u=document.getElementById("listeMitMeinenPostings");
var uv=document.getElementById("listeMitMeinenPostings").style.display;
if(uv=="none"){
document.getElementById("listeMitMeinenPostings").style.display="inline";
}else{
document.getElementById("listeMitMeinenPostings").style.display="none";
}
}
myLi.appendChild(button);
myLi.appendChild(uList);
for(i=0;i<myP.length;i++){
thread=myP[i];
//hat man eine antwort?
if(thread.childElementCount>1){
do{
thread=thread.parentNode;
}while(thread.className!="thread-start");
//nach oebn verschieben
uList.appendChild(thread);
}
}
}
document.addEventListener("DOMContentLoaded", selfhtmldatumsleser, false);
document.addEventListener("DOMContentLoaded", selfhtmlmypostschieber, false);
MFG
bleicher
Ich bin vielleicht nicht der Super-Guru, habe aber schon mal ein paar Kleinigkeiten optimiert, unnütze Variablen rausgeworfen, naja, das Übliche halt:
// ==UserScript==
// @include http://forum.de.selfhtml.org/*
// ==/UserScript==
function selfhtmldatumsleser(){
var now=new Date()*1,
spans=document.querySelectorAll("span.date"),
q=spans.length;
while (q--) {
spans[q].innerHTML.replace(/(\d+)\.(\d+)\.(\d+), (\d+):(\d+)/, function(all, day, month, year, hour, min) {
var diff=(now-new Date(day, month-1, year, hour, min)*1)/6E4;
if (diff<1) {
spans[q].style.color="#f1630c";
spans[q].style.fontSize="150%";
} else if (diff<4) {
spans[q].style.color="#d96117";
spans[q].style.fontSize="130%";
} else if (diff<10) {
spans[q].style.color="#fa670c";
spans[q].style.fontSize="120%";
} else if (diff<15) {
spans[q].style.color="#eb6513";
spans[q].style.fontSize="110%";
}
});
}
}
function selfhtmlmypostschieber(){
var myP=document.querySelectorAll("li.own-posting"),
thread,
root=document.getElementById("root"), myLi, uList, button;
(myLi=document.createElement("li")).style.backgroundColor="#eee";
root.insertBefore(myLi, root.firstChild);
(uList=document.createElement("ul")).id="listeMitMeinenPostings";
(button=document.createElement("li")).innerHTML="hide/show";
button.onclick=function(){
var u=document.getElementById('listeMitMeinenPostings');
u.style.display = (u.style.display || 'inline') == 'none' ? 'inline' : 'none';
}
myLi.appendChild(button);
myLi.appendChild(uList);
for(i=0;i<myP.length;i++){
thread=myP[i];
// hat man eine antwort?
if (thread.childElementCount>1) {
do {
thread=thread.parentNode;
} while (thread.className!="thread-start");
// nach oebn verschieben
uList.appendChild(thread);
}
}
}
document.addEventListener("DOMContentLoaded", selfhtmldatumsleser, false);
document.addEventListener("DOMContentLoaded", selfhtmlmypostschieber, false);
Gruß, LX
Grüße,
(myLi=document.createElement("li")).style.backgroundColor="#eee";
root.insertBefore(myLi, root.firstChild);
was sind es denn für klammer O_o?
MFG
bleicher
Grüße,
sorry, ist shcon spät^^
MFG
bleicher
function selfhtmldatumsleser(){
Globale Funktionen, sind wir denn im 20. Jahrhundert?
Dafür nimmt man Namespaces oder besser anonyme selbstausführende Funktionen, wenn keine öffentliche API benötigt wird.
var now=new Date()*1,
Warum hier die Umwandlung in Number?
Date-Objekte werden im Zusammenhang mit dem Substraktions-Operator automatisch in Number umgewandelt.
Sämtliche mathematische Operatoren rufen ToNumber auf den Operanden auf. Diese wandeln Objects mittels ToPrimitive und [[DefaultValue]](Number) in Number-Werte um. Dies ruft die Methoden valueOf bzw. toString auf dem Objekt auf.
Wenn man weiß, wie automatische Typumwandlung in ECMAScript funktioniert, kann man sich viel unnötiges Typecasting sparen und es dort explizit einsetzen, wo Mehrdeutigkeiten geben kann.
spans=document.querySelectorAll("span.date"),
q=spans.length;
q als Laufvariablenname? Wo sind i und j?
var diff=(now-new Date(day, month-1, year, hour, min)*1)/6E4;
*1 ist hier auch unnötig. Wenn man das schon ausführlich machen will, dann bitte verständlich mit einem expliziten getTime.
if (diff<1) {
spans[q].style.color="#f1630c";
spans[q].style.fontSize="150%";
} else if (diff<4) {
spans[q].style.color="#d96117";
spans[q].style.fontSize="130%";
} else if (diff<10) {
spans[q].style.color="#fa670c";
spans[q].style.fontSize="120%";
} else if (diff<15) {
spans[q].style.color="#eb6513";
spans[q].style.fontSize="110%";
}
Don't repeat yourself:
var color, fontSize;
if (diff < 1) { color = 0xF1630C; fontSize = 150; }
else if (...) ...
var style = spans[q].style;
style.color = '#' + color.toString(16);
style.fontSize = fontSize + %'
(uList=document.createElement("ul")).id="listeMitMeinenPostings";
...
button.onclick=function(){
var u=document.getElementById('listeMitMeinenPostings');
Die Zeile ist überflüssig. uList ist in der Closure verfügbar.
}
Expression Statements sollten wie alle Statements mit einem Semikolon abgeschlossen werden. Eine darin vorkommende Function Expression macht da keinen Unterschied, vielmehr ist das Semikolon noch wichtiger, um es von einer Function Declaration zu unterscheiden (Stichwort Hoisting).
root.insertBefore(myLi, root.firstChild);
...
myLi.appendChild(button);
myLi.appendChild(uList);
Man baut aus Performancegründen erst ein Element mit seinen Inhalten zusammen und hängt es dann ins DOM ein, nicht umgekehrt.
for(i=0;i<myP.length;i++){
Wo ist i deklariert? Wieso die length nicht zwischenspeichern?
Mathias
Globale Funktionen, sind wir denn im 20. Jahrhundert?
Den Part hatte ich einfach übernommen. Wie gesagt, habe ich nur kurz etwas optimiert.
Dafür nimmt man Namespaces oder besser anonyme selbstausführende Funktionen, wenn keine öffentliche API benötigt wird.
Warum hier die Umwandlung in Number?
Das war nur die ersetzung von .getTime(), weil ich in dieser Zeile noch unsicher war, was mit dem Timestamp geschehen sollte.
spans=document.querySelectorAll("span.date"),
q=spans.length;q als Laufvariablenname? Wo sind i und j?
Auch diesen habe ich aus dem vorherigen Code einfach übernommen. i kommt später, j habe ich unterschlagen ;-)
if (diff<1) {
spans[q].style.color="#f1630c";
spans[q].style.fontSize="150%";
} else if (diff<4) { ...Don't repeat yourself:
Auch diesen Code habe ich schlicht übernommen und lediglich jene zusätzlichen Bedingungen entfernt, die durch das else ohnehin gegeben waren.
(uList=document.createElement("ul")).id="listeMitMeinenPostings";
...
button.onclick=function(){
var u=document.getElementById('listeMitMeinenPostings');Die Zeile ist überflüssig. uList ist in der Closure verfügbar.
Auch hier habe ich nicht fertig optimiert.
Expression Statements sollten wie alle Statements mit einem Semikolon abgeschlossen werden. Eine darin vorkommende Function Expression macht da keinen Unterschied, vielmehr ist das Semikolon noch wichtiger, um es von einer Function Declaration zu unterscheiden (Stichwort Hoisting).
root.insertBefore(myLi, root.firstChild);
...
myLi.appendChild(button);
myLi.appendChild(uList);Man baut aus Performancegründen erst ein Element mit seinen Inhalten zusammen und hängt es dann ins DOM ein, nicht umgekehrt.
Auch diesen Aufbau habe ich übernommen. Wahrscheinlich hätte ich im Normalfall direkt innerHTML verwendet und dem Button eine ID gegeben, um das Event nachträglich zu setzen.
Wie gesagt, das waren 5 Minuten erste Optimierung. Dass da noch einiges an Verbesserungspotential vorhanden ist, ist mir auch klar.
Gruß, LX
Grüße,
function selfhtmldatumsleser(){
Globale Funktionen, sind wir denn im 20. Jahrhundert?
mir ist es nicht gelungen dem addEventListener eine anonymefunktion statt funktionsnahmen unterzuschieben. ich wollte es wirklich.
Wenn man weiß, wie automatische Typumwandlung in ECMAScript funktioniert, kann man sich viel unnötiges Typecasting sparen
danke, ich lese es mal durch^^
q als Laufvariablenname? Wo sind i und j?
ah komm - wir sind doch nicht bei fortran^^ oder was war das damals?
Don't repeat yourself:
var color, fontSize;
if (diff < 1) { color = 0xF1630C; fontSize = 150; }
else if (...) ...
var style = spans[q].style;
style.color = '#' + color.toString(16);
style.fontSize = fontSize + %'
habs^^
> Die Zeile ist überflüssig. uList ist in der Closure verfügbar.
das sind debuggleichen^^
> Expression Statements sollten wie alle Statements mit einem Semikolon abgeschlossen werden. Eine darin vorkommende Function Expression macht da keinen Unterschied, vielmehr ist das Semikolon noch wichtiger, um es von einer Function Declaration zu unterscheiden (Stichwort Hoisting).
ein link zum artikel? ich weiss ncith mal was expressions statements sind
> Man baut aus Performancegründen erst ein Element mit seinen Inhalten zusammen und hängt es dann ins DOM ein, nicht umgekehrt.
nicht gewusst^^
> Wo ist i deklariert? Wieso die length nicht zwischenspeichern?
fixed, thx
MFG
bleicher
--
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_-
![](http://img296.imageshack.us/img296/9641/minibannerso7.jpg)
[FirefoxMyth](http://www.firefoxmyths.com)
Expression Statements sollten wie alle Statements mit einem Semikolon abgeschlossen werden. Eine darin vorkommende Function Expression macht da keinen Unterschied, vielmehr ist das Semikolon noch wichtiger, um es von einer Function Declaration zu unterscheiden (Stichwort Hoisting).
ein link zum artikel? ich weiss ncith mal was expressions statements sind
http://aktuell.de.selfhtml.org/weblog/javascript-syntax
Expression (Ausdruck):
i + 1
Expressions kommen nahezu überall in der Sprache vor. Sie bestehen meist aus Identifiers (Bezeichnern) wie »i«, Literalen wie »1« und Operanden wie »+«.
Expression Statement (Anweisung, die aus einem Ausdruck besteht):
i + 1;
i = 1;
Function Expression (Funktionsausdruck):
function () {}
Es gibt aber auch Named Function Expressions (benannte Funktionsausdrücke):
function foo () {}
Ein Funktionsausdruck macht nichts anderes als eine Funktion (ein Funktionsobjekt) zu erzeugen und (als Wert) zu ergeben. Man muss also irgendetwas damit machen, um die erzeugte Funktion zu nutzen. Beispielsweise sie in einer Variable oder Objekteigenschaft speichern.
Über den Namen kann der Code der Funktion auf die Funktion selbst zugreifen.
Function Declaration (Funktionsdeklaration):
function foo () {}
Eine Funktionsdeklaration erzeugt ein Funktionsobjekt und speichert e im aktuellen Scope in eine Variable mit dem angegebenen Namen.
Funktionsausdruck und Funktionsdeklaration können also identisch aussehen. Welche Funktionen welche sind, hängt vom Kontext ab, in dem man function foo )( {}
notiert: Es ist ein Funktionsausdruck, wenn die Funktion innerhalb eines Ausdrucks notiert wird. Es ist eine Funktionsdeklaration, wenn sie als eigenständiges Statement notiert wird (und zwingend einen Namen besitzt).
Beispiel (benannter) Funktionsausdruck:
element.onclick = function foo () {};
Da die ganze Zeile ein Expression Statement ist, sollte es mit einem Semikolon abgeschlossen werden.
Beispiel Funktionsdeklaration:
function foo () {}
Hier wäre ein Semikolon nicht angebracht.
Eine Funktionsdeklaration ist vom Effekt her vergleichbar mit folgender Variablendeklaration samt Funktionsausdruck:
var foo = function () {};
Allerdings unterliegen Funktionsdeklarationen einem Hoisting (Hochziehen) an den Anfang eines Ausführungskontextes, sodass man notieren kann:
foo();
function foo () {}
Variablendeklarationen unterliegen zwar ebenfalls einem Hoisting. Sie werden aber nur deklariert und haben dann den Wert undefined
. Der Zuweisungspart wird erst ausgeführt, wenn der Interpreter diese Zeile abarbeitet.
Mathias
Om nah hoo pez nyeetz, molily!
q als Laufvariablenname? Wo sind i und j?
Diskussion: http://forum.de.selfhtml.org/archiv/2010/11/t201719/#m1361259 ff
Für die Ausführlichkeit gabs ein fachlich hilfreich.
Matthias
@@molily:
nuqneH
var color, fontSize;
if (diff < 1) { color = 0xF1630C; fontSize = 150; }
else if (...) ...
var style = spans[q].style;
style.color = '#' + color.toString(16);
style.fontSize = fontSize + %'
Wozu color und fontSize erst als Zahlen und dann in Strings umwandeln? Dann doch gleich
`if (diff < 1) { color = '#F1630C'; fontSize = '150%' }`{:.language-javascript}
Als Datenmodell für RGB ist eine Zahl untauglich; es sind ja drei. Also wenn schon, denn schon:
`if (diff < 1) { color_r = 0xF1; color_g = 0x63; color_b = 0x0C; … }`{:.language-javascript}
oder
`if (diff < 1) { color = [0xF1, 0x63, 0x0C]; … }`{:.language-javascript}
und daraus den String '#F1630C' oder den String 'rgb(241, 99, 12)' generieren.
Ein Integer ist auch nicht das richtige Datenmodell für die relative Angabe der Schriftgröße:
`if (diff < 1) { … fontSize = 1.5; }`{:.language-javascript}
und daraus den String '150%' generieren.
Aber nichts von alledem sollte man wirklich tun. Wo blieb denn deine Predigt für die Trennung von Verhaltens- und Präsentationsschicht?
Im Script sollte lediglich stehen:
~~~javascript
if (diff<1) spans[q].className = 'diffrange_0_1';
else if (diff<4) spans[q].className = 'diffrange_1_4';
else if (diff<10) spans[q].className = 'diffrange_4_10';
else if (diff<15) spans[q].className = 'diffrange_10_15';
Die Darstellungsangaben stehen dort, wo sie hingehören – im Stylesheet:
.diffrange_0_1 { color: #f1630c; font-size: 150% }
.diffrange_1_4 { color: #d96117; font-size: 130% }
.diffrange_4_10 { color: #fa670c; font-size: 120% }
.diffrange_10_15 { color: #eb6513; font-size: 110% }
Qapla'
@@Gunnar Bittersmann:
nuqneH
Aber nichts von alledem sollte man wirklich tun. Wo blieb denn deine Predigt für die Trennung von Verhaltens- und Präsentationsschicht?
Im Script sollte lediglich stehen:
if (diff<1) spans[q].className = 'diffrange_0_1';
else if (diff<4) spans[q].className = 'diffrange_1_4';
else if (diff<10) spans[q].className = 'diffrange_4_10';
else if (diff<15) spans[q].className = 'diffrange_10_15';
Ach, was red ich da?
Die Grenzen der Intervalle, die verschieden dargestellt werden, gehören vielleicht auch eher ins Stylesheet. Wenn sich diese später ändern sollen (bspw. nicht mehr [0, 1[, [1, 4[, [4, 10[, [10, 15[ und [15, ∞[, sondern [0, 5[,[5, 10[, [10, ∞[), möchte man ja nicht Script UND Stylesheet anpassen müssen.
Das Script sollte vielleicht gar nicht wissen, dass es solche Intervalle gibt: Einfach nur
`spans[q].className = 'diff' + Math.floor(diff);`{:.language-javascript}
Aber auch das nicht, denn eventuell bestehende Klassenzugehörigkeiten der betreffenden 'span'-Elemente sollten nicht überschrieben, sondern ergänzt werden:
`spans[q].className += ' diff' + Math.floor(diff);`{:.language-javascript}
Im Stylesheet:
~~~css
.diff0 { color: #f1630c; font-size: 150% }
.diff1,
.diff2,
.diff3 { color: #d96117; font-size: 130% }
.diff4,
.diff5,
.diff6,
.diff7,
.diff8,
.diff9 { color: #fa670c; font-size: 120% }
.diff10,
.diff11,
.diff12,
.diff13,
.diff14 { color: #eb6513; font-size: 110% }
In HTML5 ist nicht @class das Attribut der Wahl, sondern @data-*:
if (spans[q].dataset) spans[q].dataset.diff = Math.floor(diff);
else spans[q].setAttribute('data-diff', Math.floor(diff));
Zur Abfrage der Browserunterstützung von @data-* muss man freilich nicht in jedem Schleifendurchlauf spans[q].dataset
abfragen. Vor der Schleife:
var datasetSupported = !!document.documentElement.dataset;
In der Schleife:
if (datasetSupported) spans[q].dataset.diff = Math.floor(diff);
else spans[q].setAttribute('data-diff', Math.floor(diff));
Im Stylesheet dann mit Attributselektoren
[data-diff='0'] { color: #f1630c; font-size: 150% }
usw.
Qapla'
Die Grenzen der Intervalle, die verschieden dargestellt werden, gehören vielleicht auch eher ins Stylesheet.
Trennung von Verhalten und Präsentation macht man nicht zum Selbstzweck, es soll immer ein konkret sichtbarer Flexibilitäts- und Wartbarkeitsgewinn herauskommen.
Im Prinzip ist das, was hier getan wird, eine Aufgabe des Stylesheets. Allerdings bietet CSS bis dato keine Logik, die so ausgereift wie die einer Programmiersprache ist. Wenn ich eine Formatierung anhand einer Regel vornehme, die ich nicht direkt mit CSS-Selektoren ausdrücken kann, dann ergibt es praktisch nicht zwangsläufig Sinn, Regel und Formatierung über das JavaScript und das Stylesheet zu verteilen. Das macht es nicht unbedingt wartbarer, sondern erst einmal unübersichtlicher.
Wenn sich diese später ändern sollen (bspw. nicht mehr [0, 1[, [1, 4[, [4, 10[, [10, 15[ und [15, ∞[, sondern [0, 5[,[5, 10[, [10, ∞[), möchte man ja nicht Script UND Stylesheet anpassen müssen.
Eben. Deshalb ist es Quatsch, mit JavaScript mittels unzähliger Klassen ins Blaue zu feuern, um dann im Stylesheet mit obskuren, ellenlangen Regeln darauf zu reagieren.
Im Stylesheet:
.diff0 { color: #f1630c; font-size: 150% }
.diff1,
.diff2,
.diff3 { color: #d96117; font-size: 130% }.diff4,
.diff5,
.diff6,
.diff7,
.diff8,
.diff9 { color: #fa670c; font-size: 120% }.diff10,
.diff11,
.diff12,
.diff13,
.diff14 { color: #eb6513; font-size: 110% }
Das halte ich nicht für besser wartbar bzw. einfach ausbaubar. Außerdem besteht hier nicht die Möglichkeit, die Intervalle als das zu notieren, was sie sind. Die Aneinanderreihung von Klassen drückt das eher implizit aus. Im JavaScript hingegen könnte ich die Intervalle deklarativ notieren sowie diesen direkt Formatierungen oder indirekt Klassen zuordnen. Für mich ist es wichtig, eine Logik konzis, verständlich, menschen- und maschinenlesbar auszudrücken. Aus obigem Code wird man nicht schlau, er ist wenig sprechend und sehr umständlich. Unendlich viele Klassen zu erzeugen, mag in dem Beispiel hinhauen, ist aber redundant und skaliert nicht.
Eine allgemeine Lösung dieses Problems liegt m.E. nicht in einer reinen JavaScript-Lösung oder einer ineffektiven Zusammenarbeit zwischen verallgemeinerter JS-Logik und redundanten CSS-Regeln. Es ist vielmehr die Frage, wie man die beides zentral und deklarativ notiert. Dazu ist weder JavaScript noch CSS genuin geeignet. Wenn man so etwas wirklich ausbaubar und wartbar machen will, wäre ein drittes Format sinnvoll, aus dem dann die passende JavaScript-Intervall-Deklaration sowie die nötigen CSS-Klassen automatisch generiert werden - die können dann »diffrange\_0\_1« usw. lauten.
Solange es sich bloß um vier ganzzahlige Intervalle von 0 bis 15 handelt, kann man eine Lösung m.M.n. problemlos hartkodieren. Dann würde ich deine Variante aus dem vorigen Posting wählen. Alles andere wäre bei diesem Umfang schon Premature Optimization.
Mathias
@@molily:
nuqneH
Im Prinzip ist das, was hier getan wird, eine Aufgabe des Stylesheets.
ACK. Und in diesem möglich in IE < 8 mit Expressions. So dumm finde ich Microsofts Einbettung von JavaScript in CSS nicht.
.diff0 { color: #f1630c; font-size: 150% }
.diff1,
.diff2,
.diff3 { color: #d96117; font-size: 130% }.diff4,
.diff5,
.diff6,
.diff7,
.diff8,
.diff9 { color: #fa670c; font-size: 120% }.diff10,
.diff11,
.diff12,
.diff13,
.diff14 { color: #eb6513; font-size: 110% }
>
> Das halte ich nicht für besser wartbar bzw. einfach ausbaubar.
Ich schon. Daraus lässt sich im Editor schnell machen:
~~~css
.diff0,
.diff1,
.diff2,
.diff3,
.diff4 { color: #d96117; font-size: 130% }
.diff5,
.diff6,
.diff7,
.diff8,
.diff9 { color: #fa670c; font-size: 120% }
.diff10,
.diff11,
.diff12,
.diff13,
.diff14 { color: #eb6513; font-size: 110% }
Unendlich viele Klassen zu erzeugen, mag in dem Beispiel hinhauen, ist aber redundant und skaliert nicht.
Ich hatte ja schon angedeutet, dass @class nur ein Ersatz für @data-* ist. Und der Wertebereich des @data-*-Attributs ist natürlich unbeschränkt.
Wenn man so etwas wirklich ausbaubar und wartbar machen will, wäre ein drittes Format sinnvoll
XSLT?
Qapla'
Grüße,
es ist AFAIK mehr als umständlich per JS den CSS zu ergänzen (hat jemand selfmade paket für sowas?)
und ein UserJs darf nun mal keine CSS "einfach so" mitbringen. wäre nett wenn man einfach nur den pfad auf die css reinpressen könnte, ich kenne aber kein Opera der sowas einfach ermöglicht.
MFG
bleicher
Wozu color und fontSize erst als Zahlen und dann in Strings umwandeln?
Weil es sich in erster Linie um Zahlen handelt. Erst bei der »Übergabe« an CSS muss ich diese in das richtige Format bringen. Dieses spezifische Format sollte von der Notation getrennt sein. Die Grundinformation ist nicht '150%', sondern nur 150, nicht '#F1630C', sondern 0xF1630C bzw. 15.819.532.
Ein JavaScript-Komprimierer bspw. kann mit Zahlen auch besser umgehen als mit Strings.
Als Datenmodell für RGB ist eine Zahl untauglich
Huch? Wieso wird RGB dann allerorten als Zahl notiert? Was ist denn F1630C - doch eine hexadezimale Zahl. In sämtlichen mir bekannten Programmiersprachen notiert man RGB(A)-Farbwerte als hexadezimale Zahlen. Klar, strenggenommen ist das ein Tripel aus drei bzw. vier Werten, in der üblichen Notation aber eine einzelne Zahl.
es sind ja drei. Also wenn schon, denn schon:
if (diff < 1) { color_r = 0xF1; color_g = 0x63; color_b = 0x0C; … }
if (diff < 1) { color = [0xF1, 0x63, 0x0C]; … }
Eine Trennung nach R, G und B ist zwar semantisch richtig, aber nicht nötig. Ich brauche das Tripel letztlich als zusammenhängende Zahl, also kann ich den Wert auch so notieren.
Aber nichts von alledem sollte man wirklich tun. Wo blieb denn deine Predigt für die Trennung von Verhaltens- und Präsentationsschicht?
Ich habe darauf verzichtet, weil es um JavaScript-Stil ging.
Im Script sollte lediglich stehen:
if (diff<1) spans[q].className = 'diffrange_0_1';
else if (diff<4) spans[q].className = 'diffrange_1_4';
else if (diff<10) spans[q].className = 'diffrange_4_10';
else if (diff<15) spans[q].className = 'diffrange_10_15';
Dass man »spans[q].className =« eben nicht x-mal wiederholen sollte, darum ging es mir.
Mathias
Die Grundinformation ist nicht '150%', sondern nur 150
Bzw. besser 1.5, wie du richtig angemerkt hast.
@@molily:
nuqneH
Die Grundinformation ist […] nicht '#F1630C', sondern 0xF1630C bzw. 15.819.532.
Die _Grund_information ist [R, G, B] = [0xF1, 0x63, 0xC].
Sicher kannst du 256² · R + 256 · G + B berechnen und sagen: Es werde Zahl. Und es ward Zahl. Es ist aber genauso wenig eine Zahl, wie eine Bitmaske eine Zahl ist. Oder genauso viel, das liegt im Auge des Betrachters.
Und die Berechnung von 0x10000 · R + 0x100 · G + B erfolgt per: _String_konkatenation.
Ein JavaScript-Komprimierer bspw. kann mit Zahlen auch besser umgehen als mit Strings.
Kannst du das näher ausführen?
Eine Trennung nach R, G und B ist zwar semantisch richtig, aber nicht nötig. Ich brauche das Tripel letztlich als zusammenhängende Zahl, also kann ich den Wert auch so notieren.
Nö, letztendlich brauchst du das als String, also kannst du den Wert auch so notieren. Die Notwendigkeit, das als eine Zahl zu notierieren, erschließt sich mir nicht. Und wenn es um die semantische Richtigkeit geht, ist es eben ein Array [R, G, B (,A)].
Die Notation von 0x10000 · R + 0x100 · G + B als Zahl ist für mich nichts Halbes und nichts Ganzes.
if (diff<1) spans[q].className = 'diffrange_0_1';
else if (diff<4) spans[q].className = 'diffrange_1_4';
else if (diff<10) spans[q].className = 'diffrange_4_10';
else if (diff<15) spans[q].className = 'diffrange_10_15';
>
> Dass man »spans[q].className =« eben nicht x-mal wiederholen sollte, darum ging es mir.
Du hattest »color =« und »fontSize =« x-mal wiederholt. Wo ist der Unterschied?
Hätte ich schreiben sollen
~~~javascript
var className;
if (diff<1) className = 'diffrange_0_1';
else if (diff<4) className = 'diffrange_1_4';
else if (diff<10) className = 'diffrange_4_10';
else if (diff<15) className = 'diffrange_10_15';
spans[q].className = className;
und wenn ja, warum? Optimierung der Codelänge zu Lasten der Ausführungszeit?
Qapla'
Grundlage für Zitat #1839.
Die _Grund_information ist [R, G, B] = [0xF1, 0x63, 0xC]. ... letztendlich brauchst du das als String, also kannst du den Wert auch so notieren. ... Die Notation von 0x10000 · R + 0x100 · G + B als Zahl ist für mich nichts Halbes und nichts Ganzes.
Das stimmt. Das ist mir nach Absenden meines Postings auch aufgefallen, dass ich da nicht konsequent argumentiert habe. Aus semantischer Sicht ist das Tripel korrekt, aus praktischer Sicht der String. Dass ich etwas dazwischen vertreten habe, war mir schon klar.
Ob ich nun '#XXXXXX' oder 0xXXXXXX notiere, bringt auch erstmal keine nennenswerte Verkürzung. Allerdings kann ein Komprimierer manche Zahlen verkürzen, so wird aus 0x00FF00 automatisch 65280, aus 0x000000 einfach 0. Bei Strings bin ich auf '#000000' oder 'black' festgelegt.
Hätte ich schreiben sollen
var className;
if (diff<1) className = 'diffrange_0_1';
else if (diff<4) className = 'diffrange_1_4';
else if (diff<10) className = 'diffrange_4_10';
else if (diff<15) className = 'diffrange_10_15';
spans[q].className = className;
>
> und wenn ja, warum? Optimierung der Codelänge zu Lasten der Ausführungszeit?
Die Bestimmung des Klassennamens anhand von diff ist eine Aufgabe. Eine andere ist es, mit dieser Klasse etwas zu tun. Sowohl jene Logik als auch diese Verarbeitung können sich unabhängig voneinander ändern. Wenn ich letzteres ändern will, z.B. eine addClass-Helferfunktion oder die HTML5 classList verwende, muss ich es bei der Wiederholung von »spans[q].className =« x-mal ändern. Gleichen Code sollte man nicht wiederholen, sondern zentralisieren (»Don't repeat yourself«).
Was die Ausführungszeit angeht, so vermute ich, dass diese Variante von JIT-Compilern besser optimiert werden kann, weil in den if-Anweisungsblöcken nur eine Variablenzuweisung steht. So fällt die Deklaration der Variable vermutlich nicht ins Gewicht.
Mathias
@@molily:
nuqneH
In sämtlichen mir bekannten Programmiersprachen notiert man RGB(A)-Farbwerte als hexadezimale Zahlen.
BTW: #rrggbbaa? Nicht in CSS.
Qapla'