Code-Beispiele im Wiki
Felix Riesterer
Code-Beispiele im Wiki
Felix Riesterer
Matthias Scharwies
Matthias Apsel
Tabellenkalk
Camping_RIDER
JürgenBLiebe Mitlesende,
dem Konsens der MV entsprechend lasse ich nun die Beispiel-Links dynamisch in direkte Frickl-Links umwandeln. Hat ein User kein JS verfügbar, gibt es auch keinen Frickl-Link für das Beispiel. Das spart einen "seltsamen Zusatzlink" (manchmal "ausprobieren", manchmal "frickln!") und ist trotzdem benutzbar und zugänglich.
Kritik / Verbesserungsvorschläge / Feedback?
Liebe Grüße,
Felix Riesterer.
-
Servus!
...entsprechend lasse ich nun die Beispiel-Links dynamisch in direkte Frickl-Links umwandeln.
Sieht übersichtlicher aus.
Bei mir im FF42 (und nur da) erscheinen immer nur die ersten 2 Zeilen Code; erst wennn ich auch JavaScript anklicke (obwohl z.B. in border-radius keins drin ist), werden die restlichen sichtbar - sonst muss ich scrollen.
Herzliche Grüße
Matthias Scharwies
-
Hallo Matthias Scharwies,
Bei mir im FF42 (und nur da) erscheinen immer nur die ersten 2 Zeilen Code; erst wennn ich auch JavaScript anklicke (obwohl z.B. in border-radius keins drin ist), werden die restlichen sichtbar - sonst muss ich scrollen.
Den Bug hatten wir schon mal, @Felix Riesterer wird sich erinnern.
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Lieber Matthias,
Den Bug hatten wir schon mal, @Felix Riesterer wird sich erinnern.
ich erinnere mich nicht wirklich... :-( Und mich wundert's, denn ich habe alle Dateien vorher frisch vom Wiki gezogen, um dann die Änderungen vorzunehmen. Das, was den Bug auslöst, müsste ja vorher schon gefixt gewesen sein.
Hättest Du mir ein Stichwort, woran es das letzte Mal lag?
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix Riesterer,
ich erinnere mich nicht wirklich... :-( Und mich wundert's, denn ich habe alle Dateien vorher frisch vom Wiki gezogen, um dann die Änderungen vorzunehmen. Das, was den Bug auslöst, müsste ja vorher schon gefixt gewesen sein.
Hättest Du mir ein Stichwort, woran es das letzte Mal lag?
Nein, wir haben das damals auf XP geschoben und ignoriert.
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)
-
-
-
Lieber Matthias,
Bei mir im FF42 (und nur da) erscheinen immer nur die ersten 2 Zeilen Code; erst wennn ich auch JavaScript anklicke (obwohl z.B. in border-radius keins drin ist), werden die restlichen sichtbar - sonst muss ich scrollen.
das kann ich hier (ff42/ubuntu) nicht nachvollziehen. Hmm...
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix Riesterer,
Lieber Matthias,
Bei mir im FF42 (und nur da) erscheinen immer nur die ersten 2 Zeilen Code; erst wennn ich auch JavaScript anklicke (obwohl z.B. in border-radius keins drin ist), werden die restlichen sichtbar - sonst muss ich scrollen.
das kann ich hier (ff42/ubuntu) nicht nachvollziehen. Hmm...
Ich hingegen kann das genau so bestätigen FF42/XP. Ich schau gleich noch mal unter Win10.
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Hallo Matthias Apsel,
Ich hingegen kann das genau so bestätigen FF42/XP. Ich schau gleich noch mal unter Win10.
FF42/Win10 ist alles wie gewünscht.
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Hallo,
FF42/Win10 ist alles wie gewünscht.
hier unter FF42/Win7 habe ich den angeprangerten Effekt.
zusätzlich meine ich mich an Folgendes zu erinnern: ich hatte den Effekt auch, obwohl bereits der JS-Editor sichtbar war, weitere Zeilen erschienen dann nach Klick in das JS-Feld. Und ich meine das war noch vor der Umstellung, also als es noch den Frickln-Link gab.
Gruß
Kalk
-
-
-
-
Lieber Matthias,
Bei mir im FF42 (und nur da) erscheinen immer nur die ersten 2 Zeilen Code;
das Problem liegt sicherlich darin, dass das Resize-Event der Editoren zu früh oder überhaupt nicht feuert. Möglicherweise ist das ein Timing-Problem.
Ich habe nun den "Timer" von 100 auf 500 Millisekunden erhöht, um hoffentlich allen Browsern genügend Zeit zum Rendern zu geben, damit die Editoren den vollen zur Verfügung stehenden Platz für ihre Code-Zeilen nutzen.
Bitte testen!
Liebe Grüße,
Felix Riesterer.
-
Lieber Felix,
Bitte testen!
+1
alles gefixt (Komisch, dass das nur auf den Firefox und nur bei manchen Betriebssystmenen gewirkt hat.)
Herzliche Grüße
Matthias Scharwies
-
Lieber Matthias,
+1
sehr schön!
(Komisch, dass das nur auf den Firefox und nur bei manchen Betriebssystmenen gewirkt hat.)
Der FF ist wohl nicht der schnellste Renderer unter den Browsern. Aber das ist schon OK. Leider kann ich im Script nicht testen, wie schnell ein Browser jeweils ist, weswegen ich einen "konservativen" Wert an Wartezeit verwenden muss.
Liebe Grüße,
Felix Riesterer.
-
-
Hallo,
Ich habe nun den "Timer" von 100 auf 500 Millisekunden erhöht,
Bitte testen!sieht zwar komisch aus, wenn erst nur 2 Zeilen sichtbar sind und dann eine halbe Sekunde später alles erscheint, aber wenigstens ist keine mysteriöse Useraktion mehr nötig.
Gruß
Kalk-
Lieber Tabellenkalk,
sieht zwar komisch aus, wenn erst nur 2 Zeilen sichtbar sind und dann eine halbe Sekunde später alles erscheint, aber wenigstens ist keine mysteriöse Useraktion mehr nötig.
sollen wir jetzt im Bereich 100 (war zuerst der Wert) - 500 (ist es jetzt) "herumspielen"? Vielleicht genügen ja schon 300ms... oder 200ms? Womit möchtest Du anfangen?
Es ist sehr wahrscheinlich eine Frage der Leistungsfähigkeit des Systems, wie schnell der jeweilige Browser die Seite und auch den jeweiligen Editor rendert. Da habe ich kaum Möglichkeiten auf die langsamste Kiste hin zu optimieren.
Also ernsthaft: Welche Werte möchtest Du ausprobieren?
Liebe Grüße,
Felix Riesterer.
-
Hallo,
ich glaub, ich hatte vergessen, danke zu sagen: Danke, dass du dich drum kümmerst.
sollen wir jetzt im Bereich 100 (war zuerst der Wert) - 500 (ist es jetzt) "herumspielen"? Vielleicht genügen ja schon 300ms... oder 200ms? Womit möchtest Du anfangen?
366 ist vermutlich ein guter Anfangswert. Aber s.u.
Es ist sehr wahrscheinlich eine Frage der Leistungsfähigkeit des Systems, wie schnell der jeweilige Browser die Seite und auch den jeweiligen Editor rendert. Da habe ich kaum Möglichkeiten auf die langsamste Kiste hin zu optimieren.
hm, muss ich mir doch mal was neueres besorgen?
Also ernsthaft: Welche Werte möchtest Du ausprobieren?
von mir aus kanns auch so bleiben.
Gruß
Kalk-
Lieber Tabellenkalk,
ich glaub, ich hatte vergessen, danke zu sagen: Danke, dass du dich drum kümmerst.
geht auf's Haus. Wenn wer etwas verbockt hat, dann finde ich es immer praktisch, wenn sich dann auch derjenige bei Bedarf darum kümmert.
366 ist vermutlich ein guter Anfangswert. Aber s.u.
Sollte ich doch noch ein geeignetes Event finden, ist kein Timeout mehr notwendig.
hm, muss ich mir doch mal was neueres besorgen?
Wozu? Passt doch!
Liebe Grüße,
Felix Riesterer.
-
-
Es ist sehr wahrscheinlich eine Frage der Leistungsfähigkeit des Systems, wie schnell der jeweilige Browser die Seite und auch den jeweiligen Editor rendert.
Vermutlich. Hier tritt das Problem ebenfalls auf. Älterer Rechner mit Win7 / aktuellem FF.
Da habe ich kaum Möglichkeiten auf die langsamste Kiste hin zu optimieren.
Das wäre sicher nicht so gut / kaum machbar. Aber so wie es jetzt ist, scheint es mir extrem schädlich, weil einfach viele eine kaputte Seite sehen.
Ohne den Code / die Problematik genau gesehen zu haben: es muss doch irgendeine Eigenschaft im DOM geben, mit der Du eine Fallunterscheidung treffen kannst: Browsert ist bereit für "magische Aktion" / Browser ist noch nicht bereit. Irgendeine berechnete Breite / Höhe, was auch immer... auf sowas könnte mit mittels Interval alle 50ms lauschen und reagieren. Schnelle Systeme bekommen es schneller, langsame eben langsamer... BTW: Auch schnelle Systeme können langsam sein, wenn Sie unter entsprechender Last stehen.
Bevor ihr das so umgebaut habt, würde ich lieber den Extralink ansehen drinlassen... IMHO.
-
Lieber Mitleser,
verstehe ich Dich richtig, dass Du selbst nach 500ms Verzögerung nur eine oder zwei Code-Zeilen im jeweiligen Code-Editor siehst, obwohl da mehr als nur diese (zwei) stehen sollte(n)?
Hier tritt das Problem ebenfalls auf. Älterer Rechner mit Win7 / aktuellem FF.
Anscheinend bräuchtest Du sogar mehr als 500ms...
Aber so wie es jetzt ist, scheint es mir extrem schädlich, weil einfach viele eine kaputte Seite sehen.
Kannst Du "viele" in Prozent umrechnen? Da hätte ich gerne eine genauere Aussage (und keine Prognose!).
Ohne den Code / die Problematik genau gesehen zu haben: es muss doch irgendeine Eigenschaft im DOM geben, mit der Du eine Fallunterscheidung treffen kannst:
Ja? Welche sollte das sein? "Habe das Bild jetzt komplett gerendert"? Wie lautet dieses Event?
auf sowas könnte mit mittels Interval alle 50ms lauschen und reagieren.
50ms? Bei Dir braucht es doch offenichtlich länger als das zehnfache, bis die Seite fertig redendert ist! Was soll ich Deinen Browser dann alle 50ms noch mehr belasten? Das schafft der doch dann garnicht!
BTW: Auch schnelle Systeme können langsam sein, wenn Sie unter entsprechender Last stehen.
Ja, und weil es heute regnet, ist der Rasen nass. Schon klar.
Deine Äußerungen helfen mir gerade nicht wirklich weiter... Dabei hattest Du es gut gemeint.
Bevor ihr das so umgebaut habt, würde ich lieber den Extralink ansehen drinlassen... IMHO.
Der ist doch nach wie vor da! Du könntest "Link in neuem Fenster/Tab öffnen" benutzen, dann siehst Du das frickl-freie Beispiel.
Liebe Grüße,
Felix Riesterer.
-
verstehe ich Dich richtig, dass Du selbst nach 500ms Verzögerung nur eine oder zwei Code-Zeilen im jeweiligen Code-Editor siehst, obwohl da mehr als nur diese (zwei) stehen sollte(n)?
Ja.
Anscheinend bräuchtest Du sogar mehr als 500ms...
Ja, scheint so. Die Strategie des festen Timeouts ist defekt.
Aber so wie es jetzt ist, scheint es mir extrem schädlich, weil einfach viele eine kaputte Seite sehen.
Kannst Du "viele" in Prozent umrechnen?
Nein, unmöglich. Siehe z.B. das Argument unten: Top Rechner unter hoher Last.
Da hätte ich gerne eine genauere Aussage (und keine Prognose!).
Ich hätte gerne ein Bonbon!
Ohne den Code / die Problematik genau gesehen zu haben: es muss doch irgendeine Eigenschaft im DOM geben, mit der Du eine Fallunterscheidung treffen kannst:
Ja? Welche sollte das sein? "Habe das Bild jetzt komplett gerendert"? Wie lautet dieses Event?
Wenn Du tatsächlich mit Events arbeiten möchtest, müsstet Du Dir wohl selbst eines bauen. Jetzt kommen wir langsam zum Punkt...
auf sowas könnte mit mittels Interval alle 50ms lauschen und reagieren.
50ms? Bei Dir braucht es doch offenichtlich länger als das zehnfache, bis die Seite fertig redendert ist! Was soll ich Deinen Browser dann alle 50ms noch mehr belasten? Das schafft der doch dann garnicht!
Ich fasse nochmal zusammen, korrigiere mich bitte: Dein Script geht von irgendeinem Zustand "X" aus, der aber erst zum Zeitpunkt "Y" gegeben ist. Also geht es doch eigentlich um die Frage: wie identifiziere ich Zustand "X"? Das sollte doch lösbar sein. Irgendein Element im DOM wird Dir vor "X" z.B. einen anderen (vermutlich sehr kleinen) Wert seiner berechneten(!) Höhe/Breite liefern, als nach "X". Das packst Du in ein Interval und prüfst das. Sobald das Kriterium (du wirst schnell eines finden, bestimmt) erfüllt ist, beendest Du das Interval rufst Deine eigentliche Funktion auf. Oder feuerst wg. mir auch ein eigenes Event, auf das du horchst, wenn es denn ganz hübsch werden soll.
BTW: Auch schnelle Systeme können langsam sein, wenn Sie unter entsprechender Last stehen. Ja, und weil es heute regnet, ist der Rasen nass. Schon klar.
WTF?! Wie schon gesagt, setTimeout ist hier schlicht der falsche Ansatz. Dauerhaft kaputt. Für flotte Systeme verzögerst Du zu lange, für langsame zu kurz.
Deine Äußerungen helfen mir gerade nicht wirklich weiter... Dabei hattest Du es gut gemeint.
Wo ist mein Bonbon?
Bevor ihr das so umgebaut habt, würde ich lieber den Extralink ansehen drinlassen... IMHO. Der ist doch nach wie vor da! Du könntest "Link in neuem Fenster/Tab öffnen" benutzen, dann siehst Du das frickl-freie Beispiel.
Klar. Wird intuitiv jeder so machen. LOL.
-
Lieber Mitleser,
verstehe ich Dich richtig, dass Du selbst nach 500ms Verzögerung nur eine oder zwei Code-Zeilen im jeweiligen Code-Editor siehst, obwohl da mehr als nur diese (zwei) stehen sollte(n)?
Ja.
autsch! Dann verstehe ich besser, warum Du die Idee mit dem Timeout so verurteilst.
Da hätte ich gerne eine genauere Aussage (und keine Prognose!).
Ich hätte gerne ein Bonbon!
:-) bittesehr: ><><
Wenn Du tatsächlich mit Events arbeiten möchtest, müsstet Du Dir wohl selbst eines bauen.
Das würde ich sofort, wenn ich wüsste wie. Bieten denn alle Browser etwas in der Art "renderComplete"?
Ich fasse nochmal zusammen, korrigiere mich bitte: Dein Script geht von irgendeinem Zustand "X" aus, der aber erst zum Zeitpunkt "Y" gegeben ist. Also geht es doch eigentlich um die Frage: wie identifiziere ich Zustand "X"? Das sollte doch lösbar sein. Irgendein Element im DOM wird Dir vor "X" z.B. einen anderen (vermutlich sehr kleinen) Wert seiner berechneten(!) Höhe/Breite liefern, als nach "X". Das packst Du in ein Interval und prüfst das. Sobald das Kriterium (du wirst schnell eines finden, bestimmt) erfüllt ist, beendest Du das Interval rufst Deine eigentliche Funktion auf. Oder feuerst wg. mir auch ein eigenes Event, auf das du horchst, wenn es denn ganz hübsch werden soll.
Ich werde einmal schauen, ob ich den Zeitpunkt ermitteln kann, zu dem alle Editoren fertig eingerichtet sind. Vielleicht hilft mir das weiter.
WTF?! Wie schon gesagt, setTimeout ist hier schlicht der falsche Ansatz. Dauerhaft kaputt. Für flotte Systeme verzögerst Du zu lange, für langsame zu kurz.
Sollte ich kein geeignetes Event finden oder erzeugen können, bleibt das der letzte Ausweg! Natürlich kann ich nachvollziehen, dass ein Timeout ein stunpfes Messer ist, aber wenn sonst kein gemeinsamer Nenner zwischen den Browsern auf ihren Systemen bleibt... was soll ich da tun?
Wo ist mein Bonbon?
s.o. - kriegst aber gleich noch eins: ><><
Du könntest "Link in neuem Fenster/Tab öffnen" benutzen, dann siehst Du das frickl-freie Beispiel.
Klar. Wird intuitiv jeder so machen. LOL.
Und genau da war ein anderes Problem versteckt, auf das mich JürgenB hingewiesen hat. Aber das habe ich nun behoben.
Mal sehen, ob beim Studium der API zum verwendeten Editor ein passendes Event zu finden ist. Dann melde ich mich wieder.
Liebe Grüße,
Felix Riesterer.
-
Hallo Ingrid,
Ich werde einmal schauen, ob ich den Zeitpunkt ermitteln kann, zu dem alle Editoren fertig eingerichtet sind. Vielleicht hilft mir das weiter.
nö, in der API-Dokumentation zum Editor finde ich kein passendes Event. Auch in der zugehörigen EditSession-Klasse gibt es nichts dahin gehendes.
Habe den Timeout auf 50ms zurück gesetzt. Dafür werden nun aber alle Layout-Optionen (es gibt "Editoren unter dem Beispiel" und "Editoren seitlich") mit einem Resize-Aufruf versehen. Nicht nur, wenn die Editoren seitlich sind. Hilft das?
Wer weiß Rat?
Liebe Grüße,
Felix Riesterer.
-
Hallo,
Hilft das?
leider nicht.
Gruß
Kalk-
Lieber Tabellenkalk,
Hilft das?
leider nicht.
also Timeout wieder auf 500ms. Was Besseres finde ich derzeit leider nicht.
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix Riesterer,
also Timeout wieder auf 500ms. Was Besseres finde ich derzeit leider nicht.
Da hier nur FF in Win < 10 betroffen scheinen, wäre UA-BS-Sniffing hier vielleicht besser. Es ist nicht davon auszugehen, dass die Beispiellesenden ihren UA-String absichtlich verändern, und wenn doch - Pech gehabt.
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Lieber Matthias,
Da hier nur FF in Win < 10 betroffen scheinen, wäre UA-BS-Sniffing hier vielleicht besser.
das ist nicht abschließend geklärt! Möglicherweise spielt einfach die Leistungsfähigkeit des verwendeten Rechners eine Rolle?
Es ist nicht davon auszugehen, dass die Beispiellesenden ihren UA-String absichtlich verändern, und wenn doch - Pech gehabt.
Mir wäre eine "richtige" Lösung eigentlich schon lieber (siehe Diskussion mit dem Mitleser)...
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix Riesterer,
Mir wäre eine "richtige" Lösung eigentlich schon lieber (siehe Diskussion mit dem Mitleser)...
Wäre es denkbar, alle Beispiele nach dem Laden der Seite schon vorzubereiten? Dann brauchen sie per Klick nur noch eingeblendet werden.
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Lieber Matthias,
Wäre es denkbar, alle Beispiele nach dem Laden der Seite schon vorzubereiten? Dann brauchen sie per Klick nur noch eingeblendet werden.
es ist das "Einblenden" selbst, das hier verschiedene Zeitdauern hat, ungeachtet der Wartezeit auf die anzuzeigenden Daten. Der Browser muss für jeden Editor eine sehr erhebliche Anzahl an <div> generieren, in denen z.T. mehrere <span> mit passenden class-Attributen liegen. Die Erstellung eines Editors braucht nun einmal Zeit, bis die notwendigen Elementknoten erzeugt sind. Dazu kommen noch die Eventhandler für die Schaltflächen, mit denen man den Code zusammenfalten kann (z.B. bei function- oder if-Blöcken). Das Darstellen anhand der vergebenen class-Attribute kann dann auch noch bis zu ein paar Schrecksekunden dauern, je nach Aufwand der visuellen Eigenschaften (ich sah da einen Schatten-Effekt neben der Spalte mit den Zeilennummern, wenn man bei langen Zeilen nach rechts scrollt).
Um einen Editor zu erzeugen, ruft man window.ace.edit(<Elementknoten>) auf. Ob man direkt im Anschluss daran schon fertige Editoren gerendert bekommt, oder ob man dem Browser jetzt Zeit geben muss, diese auch wirklich zu "paint"en - da verstehe ich zu wenig von der Sache. Jedenfalls habe ich in den Docs keinen Hinweis auf ein passendes Event gefunden, das man abwarten könnte, um dann die resize-Funktion eines jeden sichtbaren Editors auszulösen. Und diese sorgt dafür, dass der ganze zur Verfügung stehende Platz für die Code-Zeilen benutzt wird.
Das im Hintergrund schon Vorbereiten scheitert daran, dass das Overlay selbst in einem Iframe läuft. Das bedeutet, dass ich alle im Iframe benötigten Elemente auch dort erzeugen (lassen) muss. Mir ist es mit IE schon passiert, dass ein im Elterndokument erzeugter Elementknoten beim Einfügen in das document-Objekt des Iframes zu Fehlern geführt hat, da der erzeugte Knoten in ein fremdes document-Objekt eingefügt werden sollte. Auch bei PHP kenne ich das Problem, dass man Knoten fremder Document-Instanzen erst importieren muss, bevor man sie im aktuellen Document einhängen kann. Der FF ist da anscheinend so freundlich, den Import still im Hintergrund automatisch vorzunehmen - und verstößt vielleicht sogar gegen irgendwelche Spezifikationen...
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix Riesterer,
Hm. Vielleicht denke ich ja auch zu blauäugig.
- Derzeit
- "click" -> frickl wird erzeugt.
- Mein Plan
- "onload" -> alle frickls werden erzeugt, aber mit
display: noneversehen - "click" -> das "richtige" frickl bekommt
display: block
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Aloha ;)
Hm. Vielleicht denke ich ja auch zu blauäugig.
- Derzeit
- "click" -> frickl wird erzeugt.
- Mein Plan
- "onload" -> alle frickls werden erzeugt, aber mit
display: noneversehen - "click" -> das "richtige" frickl bekommt
display: block
Ohne den genauen Code von @Felix Riesterer zu kennen würde ich jetzt auch davon ausgehen, dass das funktionieren könnte. Zumindest das erwähnte span/div-Erzeugen sollte damit abzupassen sein; und wenn das Problem wirklich darin begraben liegt sollte es sich so beheben lassen.
Grüße,
RIDER
--
Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller Erreichbar manchmal im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem eigenen TeamSpeak-Server (fritz.campingrider.de) oder unter: # Facebook # Twitter # Steam # YouTube # Self-Wiki # ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[-
Lieber Camping_RIDER,
Ohne den genauen Code von @Felix Riesterer zu kennen
schade, er ist doch frei zugänglich... und ab 310 steht der Code, der die Editoren erstellt.
würde ich jetzt auch davon ausgehen, dass das funktionieren könnte.
Du gehst von einem anderen Konzept aus. Daher passt Deine Prognose leider nicht. Das Overlay wird nur einmal erzeugt (sollte ich von einem Overlay absehen und einen Back-Link stattdessen auf der Frickl-Seite bauen?), und auch nur dann, wenn ein Klick ausgelöst wird. Oder warum wollen wir künstlich Bandbreite beim Besucher verbrauchen, nur damit ein kleines visuelles Problem vielleicht(!) damit gelöst wird?
Zumindest das erwähnte span/div-Erzeugen sollte damit abzupassen sein;
Das ist nicht allein das Problem!
und wenn das Problem wirklich darin begraben liegt sollte es sich so beheben lassen.
Leider nein.
Liebe Grüße,
Felix Riesterer.
-
Aloha ;)
Ohne den genauen Code von @Felix Riesterer zu kennen
schade, er ist doch frei zugänglich... und ab 310 steht der Code, der die Editoren erstellt.
Ich weiß! Mir fehlen aber Zeit und Muße mich einzulesen, tut mir leid :/
Du gehst von einem anderen Konzept aus. Daher passt Deine Prognose leider nicht. Das Overlay wird nur einmal erzeugt [...], und auch nur dann, wenn ein Klick ausgelöst wird.
Eben darum ging es doch. Statt das Overlay einmal bei Klick zu laden, so der Vorschlag von @Matthias Apsel, könnte man das bzw. dann wahrscheinlich eher die Overlays schon beim Laden der Seite fertig machen und dann bei Klick auf den Link nur noch sichtbar schalten.
Oder warum wollen wir künstlich Bandbreite beim Besucher verbrauchen, nur damit ein kleines visuelles Problem vielleicht(!) damit gelöst wird?
Naja, von welchem Umfang an Bandbreitenverbrauch sprechen wir? Die Beispiele sind ja grundsätzlich als Minimalbeispiel gehalten, d.h. wir sprechen von einigen hundert KB, wenns hoch kommt. Wenn dann noch Browsercaching dazu kommt (die Beispiele sind ja quasi statisch) sollte das tatsächlich vernachlässigbar sein. Außerdem ist es schon eine berechtigte Sichtweise, dass das Beispiel ein integraler Bestandteil des Artikels ist, und somit auch mitgeladen gehört - nichts anderes als diese Sichtweise ist ja der Grund, sich dafür auszusprechen, dass die Livebeispiele direkt eingebunden werden sollten statt (wie bisher mit "ansehen") auf einer extra Seite liegen.
Außerdem sprechen wir ja, so wie ich die Schilderungen verstanden habe, eben nicht von einem "kleinen visuellen Problem", sondern eher von einem Problem, das, wenn man nicht weiß, wie man es beheben soll, die Benutzbarkeit stark einschränkt. Klar ist es vielleicht ein Randgruppenproblem, trotzdem ist diese Bezeichnung etwas zu optimistisch an der Stelle.
Ich sehe natürlich ein, dass so ein Paradigmenwechsel von "ein Overlay bei Klick" zu "alle Overlays onload" in der Implementierung teuer sein kann und habe vollstes Verständnis dafür, wenn du vor dieser (potenziell weitreichenden) Änderung zurückschreckst, zumal der Erfolg nicht direkt garantiert ist.
Ich kann auch nicht garantieren, dass das die einfachste/billigste Lösung des Problems ist (wahrscheinlich nicht), aber ich denke schon, dass das funktionieren könnte, wenn alle Stricke reißen.
Grüße,
RIDER
--
Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller Erreichbar manchmal im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem eigenen TeamSpeak-Server (fritz.campingrider.de) oder unter: # Facebook # Twitter # Steam # YouTube # Self-Wiki # ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
-
-
-
-
-
-
-
-
Wer weiß Rat?
setInterval, alle 20 ms:
- console.log innerHTML von X und beobachten, ob irgendein Element "auf einmal" dazukommt, was als Kriterium in Frage kommt
- Wenn nicht: console.log auf berechnet Maße von X, Y, Z und beobachten ob und wann die sich stabiliseren. Könnte ebenfalls als Kriterium in Frage kommen.
Etwas in der Richtung wird sich zügig finden lassen, schon hast Du dein "Event".
-
-
-
-
-
-
-
-
Hallo Felix,
Bitte testen!
bei mir (Win7, IE10 oder aktueller FF) sieht es sehr komisch aus:
https://wiki.selfhtml.org/extensions/Selfhtml/frickl.php/Beispiel:JS-Anw-sortierbare-Tabellen-3.html
Kein CSS, Inhalt in einem kleinem Kasten, kein Quelltext, Steuerelemente ganz weit unten:
Gruß Jürgen
-
Hallo,
ich habe mir das gerade noch an einem schnelleren Rechner, und da auch unter Chrome angesehen, immer das gleiche Aussehen. Die Beispiele sind im Wiki z.Zt. (für mich?) nicht nutzbar.
Gruß Jürgen
-
Lieber JürgenB,
Bitte testen!
bei mir (Win7, IE10 oder aktueller FF) sieht es sehr komisch aus:
das lag an einem anderen Fehler (Debug-Version), den ich nun korrigiert habe. Vielen Dank für diesen wertvollen Hinweis.
Liebe Grüße,
Felix Riesterer.
-
-
-
-
Liebe Mitlesende,
aktuell sehe ich im Wiki jetzt wieder drei Links, was bedeuten muss, dass jemand meine Änderungen in der Wiki-Extension rückgängig gemacht hat. Leider ist die Rückgängigmachung nicht auch in der Datei js/frickl-overlay.js erfolgt, sodass nun der erste Link weiterhin das frickl-Verhalten zeigt, anstatt dass dieser ungeschminkt auf das statische Beispiel zeigt und der frickl-Link das Overlay bekommt.
Findet ihr den jetzigen Zustand wirklich besser?
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix Riesterer,
aktuell sehe ich im Wiki jetzt wieder drei Links
Das kann ich nicht bestätigen. Möglicherweise eine Caching-Frage?
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Lieber Matthias,
Möglicherweise eine Caching-Frage?
ja, stimmt, und das, obwohl ich im Firebug den Cache deaktiviert habe. Gilt wohl nicht für bereits besuchte Seiten... grrr
Liebe Grüße,
Felix Riesterer.
-
-