[nicht nur] für Struppi!
Patrick Andrieu
- javascript
Hallo alle!
Den Beitragstitel begründe ich damit, dass ich vor einigen Tagen Struppi mit einer JavaScript-Frage gedroht hatte ;) Der Grund ist, dass ich mich eines seiner Scripts bedient habe. Natürlich sind aber alle, die das Folgende interessiert, eingeladen, Vorschläge, Ratschläge, Meinungen zu äußern.
Das Problem ist aber jetzt, dass ich gar kein JavaScript-Problem und somit keine JavaScript-Frage mehr habe ;) Meine "Eiboxen", die mit Hilfe von Struppis Drag&Drop-Beispiel das Laufen gelernt haben, bereiten mir fast nur Freude.
Übrig geblieben sind leichte Darstellungsfehler in den Opera-Browsern, die vielleicht mit anderen CSS-Anweisungen zu korrigieren wären. Ich habe aber mittlerweile Tomaten vor den Augen und/oder keine Idee mehr.
Ich habe eine Testseite online gestellt, poste hier also keinen Code. CSS-Anweisungen und JavaScript-Code sind ausgelagert und ebenfalls hier verlinkt:
Eibox
Darstellungsfehler in Opera
eibox.css
eibox_3.js
Wer Zeit und Lust hat, sich die ganze Literatur reinzuziehen:
http://www.atomic-eggs.com/z_testdir/sf_ebt.html
Gäbe es eine einfache (und rucklose) Möglichkeit, eine minimierte Eibox am unteren Ende des Viewports zu "fixieren", so dass sie nicht mehr mitscrollt? Den Wert "fixed" lässt sich anscheinend nicht dynamisch setzen, Versuche führten dazu, dass die Boxen ins Nirvana verschwanden ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Re!
Dass ich hier im Thread-Titel einen aktiven Forumer beim Namen genannt habe, sollte nicht als irgendeine Absicht verstanden werden, die anderen (aktiven und weniger aktiven) fernzuhalten!
Im Gegenteil kann jeder etwas dazu sagen, wenn Bedarf dazu besteht - und sei es nur den Hinweis auf den berühmten Sack Reis ;)
Ich bin sicher, dass bezüglich Optimierbarkeit/Übersichtlichkeit des Codes vieles schlanker gestaltet werden kann, so dass Ideen willkommen sind.
Viele Grüße aus Frankfurt/Main,
Patrick
Dass ich hier im Thread-Titel einen aktiven Forumer beim Namen genannt habe, sollte nicht als irgendeine Absicht verstanden werden, die anderen (aktiven und weniger aktiven) fernzuhalten!
Gibt halt nicht viel dazu zu sagen ;-)
Zwei drei Dinge, würde ich vielleicht anders machen (es gibt von dem einfachen Beispiel auch schon eine neue Version - hier lokal), aber ansonsten finde ich für die Funktionalität den Code übersichtlich und relativ kurz.
Was die Probleme mit Opera angeht (ich kann das ruckeln von Mathias nicht nachvollziehen mit OP 7 und 8) du kannst mal mit onselectstart experimentieren, für mich sieht das so aus, also ob das dazwischen funkt.
Ach doch - beim "fokusieren" (also beim mehrmaligen klick auf einen Link) verschiebt sich das "Fenster" immer wieder zum Ausganspunkt, würde ich nicht machen.
Struppi.
Hallo Struppi!
Gibt halt nicht viel dazu zu sagen ;-)
Klingt gut, danke!
Code übersichtlich und relativ kurz.
Danke, ich versuche den immer zu kürzen, wo ich kann, gelingt aber nicht immer ;)
Ich werde mir das genauer anschauen. Aber da es auf einer M$-Seite beschrieben ist, ist es ein proprietäres Event-Handler?
Ach doch - beim "fokusieren" (also beim mehrmaligen klick auf einen Link) verschiebt sich das "Fenster" immer wieder zum Ausganspunkt, würde ich nicht machen.
Wenn man eine Box bewegt hat, und wieder den auflösenden Link anklickt, ja. Du meinst, die Box sollte dann da bleiben, wohin sie bewegt wurde? Ich dachte mir dabei, so wie es jetzt ist, kann, wenn jemand gescrollt hat, die Box wieder in der Nähe vom Link (also bei den unter setOpeningPos definierten Werten) erscheinen...
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Struppi!
Ich habe vorhin auch mit onselectstart herumprobiert. Im Element notiert macht es das Dokument unültig (no attribute onselecstart) und innerhalb des JavaScript-Codes wüßte ich nicht, was ich damit verbinden könnte... null oder false, oder gar eine Funktion?
Was war denn Deine Idee, als Du mir das vorgeschlagen hast?
Viele Grüße aus Frankfurt/Main,
Patrick
Ich habe vorhin auch mit onselectstart herumprobiert. Im Element notiert macht es das Dokument unültig (no attribute onselecstart) und innerhalb des JavaScript-Codes wüßte ich nicht, was ich damit verbinden könnte... null oder false, oder gar eine Funktion?
Was war denn Deine Idee, als Du mir das vorgeschlagen hast?
Vielleicht so:
window.onselectstart = null;
oder
window.onselectstart = function() { return false;}
Struppi.
Hallo Struppi!
window.onselectstart = null;
oder
window.onselectstart = function() { return false;}
Solele, eben mal wieder etwas rumexperimentiert.
Zunächst habe ich den von wahsaga verlinkten Script in meine haupt.js (lokal, ist noch nicht online) hinzugefügt, IE _mit JavaScript_ lässt jetzt das Selektieren von Text zu.
document.onselectstart = null; --> Keine Änderung
document.onselectstart = function() { return false;} --> Kein Text selektierbar im ganzen Dokument _im Internet Explorer_ (wird von den anderen ignoriert)
Speziell für die Box (für den Inhalt-DIV):
function open_eibox(name,picname) {
obs = dc.getElementById(name).style;
ct = dc.getElementById(name+'_ct') ? dc.getElementById(name+'_ct') : 0;
ct.onselectstart = function() { return false;};
.
.
.
Text im Dokument selektierbar, in der Eibox nicht (wiederum nur IE). onselecstart wird also nur vom IE interpretiert.
Operas: Der beschriebene Bug mit dem Mitselektierem von Text, der sich unterhalb der Eibox befindet, wenn man in der Box selektieren will, tritt nur dann auf, wenn der Mauszeiger beim Selektieren über eine Leerzeile kommt (ob durch <p> oder <br><br> entstanden), auch wenn der Zeiger neben dem Text (textlose Stelle) gelangt. Dies hat anscheinend nicht mit den Formatierungen dieser Eiboxen zu tun, das Problem tritt auch auf den "Old Atomic Eggs"-Seiten auf: Diese blenden einen Hinweis auf die neuen Seite, wenn ein Besucher von extern kommt - und da ist es genauso.
Um zu wissen, ob es wirklich ein Fehlverhalten oder ein Bug ist, müsste man fragen, wer noch DIV-Bereiche mit Text über Teile einer Webseite anzeigen lässt, welche ebenfalls Text enthalten - und ob das Selektieren von Text im DIV-Bereich auch zu solchem Fehlverhalten führt.
Mal was ganz anderes: Seit dem Relaunch Deiner Seiten (neuer Look, gefällt mir besser) kann ich mir mit dem IE den Quelltext nicht mehr anzeigen lassen, weder über Rechtsklick -> Quelltext anzeigen noch über Ansicht/Quelltext...
Viele Grüße aus Frankfurt/Main,
Patrick
Re!
Um zu wissen, ob es wirklich ein Fehlverhalten oder ein Bug ist, müsste man fragen, wer noch DIV-Bereiche mit Text über Teile einer Webseite anzeigen lässt, welche ebenfalls Text enthalten - und ob das Selektieren von Text im DIV-Bereich auch zu solchem Fehlverhalten führt.
Tut es: http://css.fractatulum.net/sample/css_spec2.htm (den zweiten Kasten oben links mausovern und Text selektieren: der Text im großen Kasten wird bei jeder Leerzeile mitselektiert, was ein Flackern erzeugt).
Eindeutig BUG! Warum melden sich die Operafreunde nicht zu Wort? D.R.? bleicher? Huhu? ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick.
Tut es: http://css.fractatulum.net/sample/css_spec2.htm (den zweiten Kasten oben links mausovern und Text selektieren: der Text im großen Kasten wird bei jeder Leerzeile mitselektiert, was ein Flackern erzeugt).
Eindeutig BUG!
Ich bin mal so frei, den zu melden. (Schade, dass Opera keinen öffentlich einsehbaren Bugtracker wie Mozilla hat.)
Einen schönen Montag noch.
Gruß, Mathias
Hallo Mathias!
Eindeutig BUG!
Ich bin mal so frei, den zu melden. (Schade, dass Opera keinen öffentlich einsehbaren Bugtracker wie Mozilla hat.)
Oh ja, danke, das ist für mich manchmal schon schwer, solche Beschreibung einigermaßen verständlich 'rüberzubringen... auf Englisch habe ich noch mehr Probleme! Deswegen freue ich mich, wenn jemand, der besseres Englisch kann, sowas übernimmt!
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick.
Eindeutig BUG!
Ich bin mal so frei, den zu melden. (Schade, dass Opera keinen öffentlich einsehbaren Bugtracker wie Mozilla hat.)
Oh ja, danke, das ist für mich manchmal schon schwer, solche Beschreibung einigermaßen verständlich 'rüberzubringen... auf Englisch habe ich noch mehr Probleme! Deswegen freue ich mich, wenn jemand, der besseres Englisch kann, sowas übernimmt!
So gut bin ich nun bei weitem nicht. Doch was ich mache, kannst du eigentlich auch: wenn dir etwas nicht einfällt, umschreibe es einfach. Verstanden wird es dennoch. (Außerdem spricht in diesem speziellen Fall die von dir angegebene Seite bereits Bände. Es bedarf nur einer Beschreibung, was man denn da machen soll.)
Einen schönen Montag noch.
Gruß, Mathias
Hallo Mathias!
Ich bin mal so frei, den zu melden. (Schade, dass Opera keinen öffentlich einsehbaren Bugtracker wie Mozilla hat.)
Hälst Du uns auf den Laufenden, was die darauf antworten? Bei dem von mir gemeldeten Bug hieß es lapidar: "Thanks for your report 'justify-problem with ordered lists in a div with width in px'. The issue appears to be fixed in Opera 9.01"...
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick.
Momentan stören mich daran nur noch zwei Dinge:
Im Opera ruckelt die Box beim Verschieben. Bei DOM-Drag ist dies nicht der Fall.
Beim Klick auf den „Maximieren“-Button passiert nichts, obwohl ich erwartet hatte, dass die Box infolgedessen den gesamten Viewport für sich beansprucht. (Und beim erneuten Klick natürlich auf die ursprüngliche Größe zurückkehrt.)
Einen schönen Freitag noch.
Gruß, Mathias
Hallo Mathias!
- Im Opera ruckelt die Box beim Verschieben.
Das kann ich hier bei meiner Maschine nicht bestätigen (3 GHz Dual-CPU, 1 GHz RAM). In jedem meiner Browser lässt sich ruckelfrei "draggen". Ein leichtes Zittern der Schrift in der simulierten Titelleiste ist allerdings zu beobachten. Einzige Fehler ansonsten sind die genannten Darstellungsfehler mit den Strichen beim Verschieben der Box nach oben) und das mit dem Markieren von Text.
Ich denke, dass diese Gimmicks wie bewegliche Elemente sehr stark von der Rechenleistung des Usercomputers abhängen.
Bei DOM-Drag ist dies nicht der Fall.
Das hatte ich mir auch schon angeschaut. Leichtes Schriftzittern ist da aber auch: DOMdrag-Box
- Beim Klick auf den „Maximieren“-Button passiert nichts, obwohl ich erwartet hatte, dass die Box infolgedessen den gesamten Viewport für sich beansprucht. (Und beim erneuten Klick natürlich auf die ursprüngliche Größe zurückkehrt.)
Ja, das wurmt meinen perfektionistischen Empfinden auch, denn das weckt Erwartungen, welche die Eibox als simuliertes Fenster nicht erfüllt. Es gibt aber auch diese andere Schaltfläche, die zwei Fenster übereinander zeigt, und erst zum Vorschein kommt, wenn man ein Fenster maximiert hat. Diese könnte ich bei geöffneter Box ausgegraut anzeigen und erst bei geclippter Box wäre sie aktiv. Das würde m.E. eher dem entsprechen, was die Eibox für ein Verhalten hat.
Einen schönen Freitag* noch.
Dir auch und schönes Wochenende!
*Hast Du irgendein Automatismus, oder guckst Du jedes Mal auf den Kalender? ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick.
- Im Opera ruckelt die Box beim Verschieben.
Das kann ich hier bei meiner Maschine nicht bestätigen (3 GHz Dual-CPU, 1 GHz RAM).
Du hast ja auch ein Monstrum von einem Rechner. Hier rechnet ein 1.8GHz Athlon XP.
Einzige Fehler ansonsten sind die genannten Darstellungsfehler mit den Strichen beim Verschieben der Box nach oben)
Kann ich nachvollziehen.
und das mit dem Markieren von Text.
Kann ich hin und wieder nachvollziehen. Der Text in der Eibox lässt sich jedoch normalerweise problemlos markieren. (Egal, aus welcher Richtung.)
Ich denke, dass diese Gimmicks wie bewegliche Elemente sehr stark von der Rechenleistung des Usercomputers abhängen.
Umso mehr muss die Implementierung so performant wie möglich sein. (Ja, ich habe gut reden, schließlich habe ich mir nicht eine solche Mühe wie du gemacht.)
Bei DOM-Drag ist dies nicht der Fall.
Das hatte ich mir auch schon angeschaut. Leichtes Schriftzittern ist da aber auch: DOMdrag-Box
Bei mir nicht. Bei den DOM-Drag-Boxen läuft alles sanft und ohne jegliche Ruckler.
Es gibt aber auch diese andere Schaltfläche, die zwei Fenster übereinander zeigt, und erst zum Vorschein kommt, wenn man ein Fenster maximiert hat. Diese könnte ich bei geöffneter Box ausgegraut anzeigen und erst bei geclippter Box wäre sie aktiv. Das würde m.E. eher dem entsprechen, was die Eibox für ein Verhalten hat.
Ja, klingt gut.
Einen schönen Freitag* noch.
Dir auch und schönes Wochenende!
Dankeschön.
*Hast Du irgendein Automatismus, oder guckst Du jedes Mal auf den Kalender? ;)
Es ist ein Automatismus, doch die Grußformel ist praktisch immer auch so gemeint, wie sie dort steht. Wenn ich einmal nicht dieser Ansicht bin, entferne ich sie auch.
Einen schönen Freitag noch.
Gruß, Mathias
Hallo Mathias!
Du hast ja auch ein Monstrum von einem Rechner. Hier rechnet ein 1.8GHz Athlon XP.
Ich stehe zu meiner Aldi-Kiste vom letzten November (deren Platte ich aber gleich nach dem Entpacken aus dem Karton formatiere, um das ganze überflüssige Zeugs loszuwerden und das Betriebssystem nach meinen Wünschen neu aufzusetzen)... ;)
Kann ich nachvollziehen.
Hast aber auch keine rettende Idee? Die "Stripes" treten nur bei dem Konstrukt "Bild-Eibox" auf. Vielleicht gebe ich dieses generell auf und benutze nur das andere, das Text-Eibox-Konstrukt, werde mal schauen, was sich da machen lässt.
und das mit dem Markieren von Text.
Kann ich hin und wieder nachvollziehen. Der Text in der Eibox lässt sich jedoch normalerweise problemlos markieren. (Egal, aus welcher Richtung.)
Ja, der "Bug" tritt nur dann auf, wenn die Eibox bereits oberhalb des restlichen Textes der Webseite steht, bzw. dort gedraggt wurde. Wenn sie am rechten oder linken Rand steht, und es ist kein Text darunter, tritt das Problem nicht auf. Ich dachte, das hätte ich in der Problembeschreibung notiert, habe es aber wie es aussieht vergessen.
schließlich habe ich mir nicht eine solche Mühe wie du gemacht
Danke, war schon ein paar Stunden Arbeit, wobei die Meisten darauf gingen, überhaupt die Boxen zu bauen ;)
Das würde m.E. eher dem entsprechen, was die Eibox für ein Verhalten hat.
Ja, klingt gut.
Gut, dann habe ich am Wochenende etwas zu tun ;)
Wenn ich einmal nicht dieser Ansicht bin, entferne ich sie auch.
Dann werde ich mal drauf achten, wann (hoffentlich kommt es in einer Antwort auf einen meiner Beiträge nie vor - werde mich vorsehen *g*).
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick.
[Streifen beim Verschieben der Eibox]
Kann ich nachvollziehen.
Hast aber auch keine rettende Idee?
Nein, bedaure. Dass solche Effekte auch im Opera unter Windows auftreten, verwundert mich allerdings etwas. So wie es aussieht, ist es einfach ein Rendering-Fehler Operas, wogegen du nichts unternehmen kannst. (Allerhöchstens einen aufs Minimum reduzierten Testfall und hiermit einen Bugreport erstellen.)
Einen schönen Freitag noch.
Gruß, Mathias
Hallo Mathias!
So wie es aussieht, ist es einfach ein Rendering-Fehler Operas, wogegen du nichts unternehmen kannst.
Ich habe sowas schon befürchtet... Naja, danke trotzdem!
Viele Grüße aus Frankfurt/Main,
Patrick (geht jetzt in die Autofahrer-Jungle namens "Offebach", um Jacqueline zu ihrer Mama zu bringen)
Hallo Mathias
Das kann ich hier bei meiner Maschine nicht bestätigen (3 GHz Dual-CPU, 1 GHz RAM).
Du hast ja auch ein Monstrum von einem Rechner. Hier rechnet ein 1.8GHz Athlon XP.
Bei mir (550er Pentium) ruckelt es in jedem Browser, aber nicht zu schlimm.
Bei mir nicht. Bei den DOM-Drag-Boxen läuft alles sanft und ohne jegliche Ruckler.
Auch bei mir, allerdings muss das nicht an einem besseren Script liegen. Die DOM-Drag-Boxen in den Beispielen sind wesentlich kleiner und wesentlich einfacher aufgebaut, als die Eiboxen.
Je größer ein Element ist, und je aufwendiger zu rendern, um so problematischer wird eine gleichmäßige Bewegung.
Auf Wiederlesen
Detlef
Hallo Patrick
Gäbe es eine einfache (und rucklose) Möglichkeit, eine minimierte Eibox am unteren Ende des Viewports zu "fixieren", so dass sie nicht mehr mitscrollt? Den Wert "fixed" lässt sich anscheinend nicht dynamisch setzen, Versuche führten dazu, dass die Boxen ins Nirvana verschwanden ;)
Das ist mir nicht bekannt.
Also eine kleine Testseite mit folgendem Javascript:
MyStyle=document.getElementById("setzer").style;
MyStyle.position="fixed";
MyStyle.left="0";
MyStyle.bottom="0";
Funktioniert wunderbar, "setzer" wird sauber am unteren Rand im Viewport positioniert.
OK, vielleicht funktionierts nicht mit "top", nächster Test, tauschen wir mal die letzte Zeile aus:
MyStyle.top=self.innerHeight-50+"px";
Funktioniert wunderbar, "setzer" wird mit seiner Oberkante sauber 50px über dem unteren Viewportrand positioniert.
Also mal nachsehen, warum es bei dir nicht geklappt hat:
obs.top = dcde.scrollTop+self.innerHeight-29+"px";
dc.getElementById(name).style.position = "fixed";
Damit dürfte es um die Scrollposition zu weit nach unten geschossen werden.
Eine einfache Möglichkeit für den IE wäre:
dcde.onscroll= function () {
obs.top=dcde.scrollTop+dcde.clientHeight-29+"px";
}
Das geht aber nicht ganz ohne Ruckeln ab.
Eine etwas kompliziertere Möglichkeit wäre, die Eibox auszublenden, wenn gescrollt wird, und danach wieder einzublenden.
Noch ein paar kleine Anmerkungen:
Wenn der Eibox-Link zu weit oben im Browserfenster steht, erscheint diese oben abgeschnitten. Ich fände es besser, wenn die Titelleiste der Eibox beim Einblenden immer innerhalb des Fensters wäre.
Bein Draggen nach unten wird das Dokument immer länger, mir fällt allerdings keine gute Möglichkeit ein, wie dies unterbunden werden könnte.
Das Markieren im Opera spinnt bei mir (Opera 8.54 unter W98) total. Wenn ich versuche den Text in der Box zu markieren, sprigt die Markierung wild zwichen dem Text in der Box und dem auf der Seite hin und her.
Auf Wiederlesen
Detlef
Hallo Detlef!
obs.top = dcde.scrollTop+self.innerHeight-29+"px";
dc.getElementById(name).style.position = "fixed";
> Damit dürfte es um die Scrollposition zu weit nach unten geschossen werden.
Ja, ich schrieb deswegen, dass die Boxen ins Nirvana verschwanden (außer IE, der kennt kein "fixed"), weil sie einfach nicht mehr zu sehen waren. Kein Scrollbalken, der evtl. hätte vermuten lassen können, dass sie einfach nur "janz weit unten" gelangt sind, es war einfach nichts mehr zu sehen. Vielleicht lasse ich mir mit diesem Verhalten irgendeine "Gemeinheit\*" einfallen.
Demnach wäre hier also "scrollTop" plus Viewport-Höhe zu viel für "fixed"? Werde mir morgen das alles noch mal genauer anschauen, auch die Vorschläge von Struppi und Mathias genauer studieren und ggfs. verwirklichen, genauso wie:
> ~~~javascript
> dcde.onscroll= function () {
> obs.top=dcde.scrollTop+dcde.clientHeight-29+"px";
> }
>
Das geht aber nicht ganz ohne Ruckeln ab.
Eine etwas kompliziertere Möglichkeit wäre, die Eibox auszublenden, wenn gescrollt wird, und danach wieder einzublenden.
und:
Ich fände es besser, wenn die Titelleiste der Eibox beim Einblenden immer innerhalb des Fensters wäre.
Auf jeden Fall vielen Dank für die Anregungen!
Bein Draggen nach unten wird das Dokument immer länger, mir fällt allerdings keine gute Möglichkeit ein, wie dies unterbunden werden könnte.
Ja, habe es auch gesehen. Genauso, wenn man zu weit rechts draggt, dann kommt ein horizontaler Scollbalken. Aber die Scrollbalken verschwinden auch sofort, wenn man die Box wieder schließt. Lassen wir mal den User mit den Boxen spielen, da werde ich wohl nichts unternehmen, auch wenn es sicher möglich wäre, das Draggen aufs Viewport zu limitieren (DOMdrag macht es auch in irgendeinem Beispiel mit einem DIV-Bereich). Schließlich kann man ein Windowsfenster auch unter die Taskleiste schieben, auch weit rechts.
Das Markieren im Opera spinnt bei mir (Opera 8.54 unter W98) total. Wenn ich versuche den Text in der Box zu markieren, sprigt die Markierung wild zwichen dem Text in der Box und dem auf der Seite hin und her.
Wie gesagt, dieser "Bug" tritt nur auf, wenn die Box oberhalb des Textbereichs der Seite steht. Ist sie ganz links oder ganz rechts, tritt es nicht auf.
*Gemeinheiten: Die alten, total überholten Gemeinheiten der "Halle der Gemeinheiten" auf Old Atomic Eggs wollte ich ins "neue Atomic Eggs" nicht herüber retten. Ich behalte mir jedoch vor, diesmal aber im Sinne der Startseitenwarnung "Never click red buttons", unter manchem roten Knopf der "Zurück-Navigation" doch noch eine Gemeinheit zu verstecken. Die erste ist auch schon da... in der Hilfe (wae_3.shtml). Da mal auf den roten Knopf klicken!
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick
Ja, ich schrieb deswegen, dass die Boxen ins Nirvana verschwanden (außer IE, der kennt kein "fixed"),
Du hattest das "fixed" auch bereits im else-Zweig, damit der IE position:absolute behält.
weil sie einfach nicht mehr zu sehen waren. Kein Scrollbalken, der evtl. hätte vermuten lassen können, dass sie einfach nur "janz weit unten" gelangt sind, es war einfach nichts mehr zu sehen.
Warum sollten auch Scrollbalken erscheinen?
Fixierte Elemente werden am Viewport ausgerichtet, der lässt sich sowieso nicht scrollen (nur sein Inhalt). Scrollbalken, die erscheinen, obwohl der Inhalt auch mit ihrer Hilfe unerreichbar bleibt, würde ich eher als Fehler betrachten.
Auf Wiederlesen
Detlef
Hallo Detlef!
Du hattest das "fixed" auch bereits im else-Zweig, damit der IE position:absolute behält.
Kennst meinen Code besser als ich :) - hatte ich vergessen!
Warum sollten auch Scrollbalken erscheinen?
Fixierte Elemente werden am Viewport ausgerichtet, der lässt sich sowieso nicht scrollen (nur sein Inhalt). Scrollbalken, die erscheinen, obwohl der Inhalt auch mit ihrer Hilfe unerreichbar bleibt, würde ich eher als Fehler betrachten.
War mir auch schon mal klar, jedoch mache ich immer wieder diesen Denkfehler... vielleicht sollte ich so spät nicht mehr posten ;)
So, ich habe vorhin etwas gebastelt, hier die neue Dateien:
Wenn der Eibox-Link zu weit oben im Browserfenster steht, erscheint diese oben abgeschnitten. Ich fände es besser, wenn die Titelleiste der Eibox beim Einblenden immer innerhalb des Fensters wäre.
Das ist jetzt geregelt:
eiboxposy = (ypos - 300) < body.scrollTop ? body.scrollTop+"px" : ypos - 300+"px";
und wurde mit IE, Mozilla, Firefox und meinen drei Operas (7.54, 8.54 und 9.01) erfolgreich getestet. Du hattest recht, ist viel besser so, da nicht gescrollt werden muss, um die Titelleiste "anfassen" zu können.
Nur das mit dem Fixieren bereitet mir noch Kopfzerbrechen. Fangen wir mit den "modernen" Browsern an... so sehen die else-Zweige der clip_eibox respektive restore_eibox aus:
else {
obs.position = "fixed";
obs.top = self.innerHeight-29+"px";
alert(obs.top);
}
else {
obs.position = "absolute";
if (cth != 0) {
obs.top = dcde.scrollTop+self.innerHeight-cth-88+"px";
}
else {
obs.top = dcde.scrollTop+self.innerHeight-pic_h-88+"px";
}
}
Geckos und Opera 9.01: null problemo.
Opera 7.54 und 8.54: die Eibox ist beim Clippen nicht mehr zu sehen. Ich lasse mir obs.top in einer Alertbox ausgeben, und m.E. müsste die Höhe korrekt sein, damit sie zu sehen ist. Warum die älteren Versionen da nicht mitmachen, kann ich mir im Moment nicht erklären.
Simuliertes Fixieren für den IE mittels "onscroll":
Im Moment bin ich nicht in der Lage, die einmal angesprochene Funktion nur für die jeweilige Box zu deaktivieren. Das sieht dann so aus:
Hat man zwei Boxen geclippt, bleiben beide beim Scrollen am unteren Rand des Viewports, soweit also gut, ruckelt tut es bei meinem Rechner ja relativ wenig. Sobald man aber eine der beiden Boxen wiederherstellt, scrollt wieder die übriggebliebene, noch geclippte Box mit. Hier meine bisherige Implementierung Deines Vorschlags, die für den IE relevanten if-Zweige beider Funktionen clip_eibox und restore_eibox:
if (dc.all && !window.opera) {
obs.top=dcde.scrollTop+dcde.clientHeight-29+"px";
dcde.onscroll = function () {
obs.top=dcde.scrollTop+dcde.clientHeight-29+"px";
}
}
if (dc.all && !window.opera) {
if (cth != 0) {
dcde.onscroll = null;
obs.top = dcde.scrollTop+dcde.clientHeight-cth-30+"px";
}
else {
dcde.onscroll = null;
obs.top = dcde.scrollTop+dcde.clientHeight-pic_h-88+"px";
}
}
Um die Anpassung der Schaltflächen kümmere ich mich ein anderes Mal, ebenso um Struppis Vorschlag mit onselectstart.
Viele Grüße aus Frankfurt/Main,
Patrick
Nachtrag!
Hat man zwei Boxen geclippt, bleiben beide beim Scrollen am unteren Rand des Viewports
Das war falsch beobachtet. Immer nur die zuletzt geclippte.
Viele Grüße aus Frankfurt/Main,
Patrick
Re!
Zum position:fixed-Problem bei den älteren Operas habe ich eben nochmals etwas herumprobiert. Ich schrieb gestern:
Opera 7.54 und 8.54: die Eibox ist beim Clippen nicht mehr zu sehen.
Die Box ist aber da, nur unsichtbar ;) Habe mal spasseshalber in der function clip_eibox die Eigenschaft overflow auf visible gelassen, und die top-Position auf 0 gesetzt. Die Box ist schön "fixed" (oder ist sie "stoned"?)... denn dabei kam das raus:
Wenn man auf die Minimieren-Schaltfläche klickt, wandert die Box nach oben (top = 0), soweit so gut. Jetzt versucht mal, die Box über die Titelleiste zu draggen... Für solche Spiele stelle ich mein Gesicht aber nicht zur Verfügung ;)
Hier zwei Screenshots für diejenigen, die kein Opera 7.x oder 8.x haben:
^7.54
^8.54
Bug oder Feature? Eindeutig Bug*! Für die Opera-ist-doch-nicht-so-toll-Sammlung (falls jemand so was hat) ;)
*Oder doch Feature: wo sonst gibt's denn ein implementiertes Karikatur-Programm?
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick
Kennst meinen Code besser als ich :) - hatte ich vergessen!
Nein, nur das kleine Stück, wo ich den Fehler suchte.
Nur das mit dem Fixieren bereitet mir noch Kopfzerbrechen. ...
Das habe ich mir angesehen. Verändere mal die Browserfensterhöhe ;).
Deshalb würde ich das etwas ändern.
> else {
> obs.position = "fixed";
> obs.top = "";
obs.bottom = "0";
> }
>
>
> else {
> obs.position = "absolute";
obs.bottom = "";
> if (cth != 0) {
> obs.top = dcde.scrollTop+self.innerHeight-cth-88+"px";
> }
> else {
> obs.top = dcde.scrollTop+self.innerHeight-pic_h-88+"px";
> }
> }
>
Dazu dann noch in eibox.css für .eibox top : 0;
streichen, left : 0;
kann auch weg, wenn ich das richtig sehe. Die dürften unnötig sein, weil die Positionierung beim Einblenden mittels Javascript erfolgt und das top im Stylesheet die bottom-Positionierung unnötig verkomplizieren würde.
Also:
.eibox {
position : absolute;
width : 360px;
height : 29px;
...
Geckos und Opera 9.01: null problemo.
Opera 7.54 und 8.54: die Eibox ist beim Clippen nicht mehr zu sehen.
Die haben wohl einen Bug bei position:fixed, der mir auch noch nicht bekannt war.
Ich lasse mir obs.top in einer Alertbox ausgeben, und m.E. müsste die Höhe korrekt sein, damit sie zu sehen ist.
Das kannst du dir sparen, der Wert stimmt und würde mit der bottom-Positionierung auch überflüssig.
Warum die älteren Versionen da nicht mitmachen, kann ich mir im Moment nicht erklären.
Das liegt an deiner eibox.css. Gib .eibox mal einen sichtbaren Rahmen oder eine Hintergrundfarbe, dann siehst du, was passiert.
Simuliertes Fixieren für den IE mittels "onscroll":
Im Moment bin ich nicht in der Lage, die einmal angesprochene Funktion nur für die jeweilige Box zu deaktivieren. Das sieht dann so aus: ...
Sorry, ich habe beim posten der einfachen Variante nicht daran gedacht, dass mehrere Eiboxen gleichzeitig minimiert sein könnten.
Damit wird die Sache dann etwas komplizierter. Es müsste eine Funktion geschrieben werden, die alle Eiboxen durchläuft und diese auf die entsprechende Position setzt, wenn sie minimiert sind.
Diese Funktion müsste dann dcde.onscroll _und_ window.onresize (hatte ich vergessen) zugwiesen werden.
Auf Wiederlesen
Detlef
Hallo Detlef!
Zunächst nochmals vielen Dank für die Unterstützung!
Das habe ich mir angesehen. Verändere mal die Browserfensterhöhe ;).
Hm ja... ;)
Deshalb würde ich das etwas ändern.
else {
obs.position = "fixed";
obs.top = "";
obs.bottom = "0";
}else {
obs.position = "absolute";
obs.bottom = "";
if (cth != 0) {
obs.top = dcde.scrollTop+self.innerHeight-cth-88+"px";
}
else {
obs.top = dcde.scrollTop+self.innerHeight-pic_h-88+"px";
}
}
~~~css
.eibox {
position : absolute;
width : 360px;
height : 29px;
OK. Die geclippte Box "haftet" jetzt auch beim Resizen des Fensters. Dafür spinnt nun Opera 9.01: Wenn man die geclippte Box versucht zu draggen, hüpft diese Richtung Oberkante Viewport, von dort aus kann man sie zwar auch draggen, jedoch mit Darstellungsfehlern (haftet nicht am Mauszeiger).
Ich habe das jetzt allerdings noch nicht online. Eine Idee wäre, geclippte Boxen nicht mehr dragbar zu machen. Schließlich sind minimierte Fenster von der Taskleiste auch nicht mit Drag&Drop wieder heraus zu holen, sondern nur durch Wiederherstellen.
Die haben wohl einen Bug bei position:fixed, der mir auch noch nicht bekannt war.
Scheint so... abgesehen davon haben 8.x und 7.x andere Bugs (siehe: http://www.atomic-eggs.com/z_testdir/_optest.html, dort vor allem die numerierte Liste).
<meinung>Mich wundert nur, dass sich viele ereifern, überall auf der Welt die IE-Bugs aufzulisten, und davon hat er wahrlich viele, das gebe ich zu, aber Bugs anderer Browser werden relativ selten dokumentiert bzw. das vielleicht schon, nur man bekommt es nie mit</meinung>
Warum die älteren Versionen da nicht mitmachen, kann ich mir im Moment nicht erklären.
Das liegt an deiner eibox.css. Gib .eibox mal einen sichtbaren Rahmen oder eine Hintergrundfarbe, dann siehst du, was passiert.
Ja, das sieht man schon mit der Bild-Box mit gekennzeichten Elementen (3. Eibox-Link). Am unteren Fensterrand sieht man den roten Border, aber die alle Hintergrundgrafiken werden nicht angezeigt.
Sorry, ich habe beim posten der einfachen Variante nicht daran gedacht, dass mehrere Eiboxen gleichzeitig minimiert sein könnten.
Besucher versuchen oft alles ;)
Damit wird die Sache dann etwas komplizierter. Es müsste eine Funktion geschrieben werden, die alle Eiboxen durchläuft und diese auf die entsprechende Position setzt, wenn sie minimiert sind.
Diese Funktion müsste dann dcde.onscroll _und_ window.onresize (hatte ich vergessen) zugwiesen werden.
Dann habe ich etwas zu tun. Da ich aber z.Z. diesen Code nicht mehr sehen kann, mache ich nur sporadisch etwas dran. Zwischendurch erledige ich andere Aufgaben. Aber ein Versuch wird es wert sein!
Schönen Restsonntagabend und
viele Grüße aus Frankfurt/Main,
Patrick
Hallo geduldige JS-Helfer!
Ich habe jetzt bewußt das Script ein paar Tage sein lassen, um heute mittag frisch wieder einzusteigen...
Dafür spinnt nun Opera 9.01: Wenn man die geclippte Box versucht zu draggen, hüpft diese Richtung Oberkante Viewport, von dort aus kann man sie zwar auch draggen, jedoch mit Darstellungsfehlern (haftet nicht am Mauszeiger).
Eine Idee wäre, geclippte Boxen nicht mehr dragbar zu machen.
Das ist jetzt geklärt: Minimierte Eiboxen sind jetzt nicht mehr zu bewegen. Man muss sie erst wiederherstellen, um sie draggen zu können.
Die [alten Opera-Versionen 7.x und 8.x] haben wohl einen Bug bei position:fixed, der mir auch noch nicht bekannt war.
Deswegen nehme ich sie jetzt im if-Zweig für den IE mit: Die minimierte Box bleibt jetzt auch beim Ändern der Fenstergröße unten links am Viewport. Leider - neue Änderungen, neue Probleme - verhält sich hier der IE 6 beim onresize-Event etwas komisch:
Hat man in einem Fenster normaler Größe bis ganz unten gescrollt, eine Eibox geöffnet und "geclippt", und maximiert das Fenster jetzt über die entsprechende Schaltfläche der Titelleiste, wird die Höhe des Bodys verlängert, die minimierte Box ist zwar am unteren Ende des Viewports, aber zu weit unten (ausprobieren wird hier besser sein als meine Beschreibungsversuche *g*). Das hat nicht anscheinend nicht mit den paar Zeilen Code zu tun, die ich zur Vermeidung des IE-Textselection-Bug eingefügt habe, da das Beschriebene auch ohne dieses Scripts vorkommt.
Damit wird die Sache dann etwas komplizierter. Es müsste eine Funktion geschrieben werden, die alle Eiboxen durchläuft und diese auf die entsprechende Position setzt, wenn sie minimiert sind.
Diese Funktion müsste dann dcde.onscroll _und_ window.onresize (hatte ich vergessen) zugwiesen werden.
Da habe ich im Moment allerdings wenig Ideen und freue mich über jeden Denkschubs in die richtige Richtung. So wie es aussieht befürchte ich, dass der bisherige Ansatz in der Funktion clip_eibox komplett überdacht werden müsste, sprich die Funktion komplett anders schreiben. Liege ich damit richtig oder ließe sich das Vorhandene doch ergänzen?
Neue Testseite:
http://www.atomic-eggs.com/z_testdir/sf_ebt_6.html#a4
http://www.atomic-eggs.com/z_testdir/eibox_6.js
Viele Grüße aus Frankfurt/Main,
Patrick
Falls es überhaupt noch jemand interessiert ;)
Da habe ich im Moment allerdings wenig Ideen und freue mich über jeden Denkschubs in die richtige Richtung.
Den Schubs konnte ich mir selbst geben (ich sollte immer morgens an solche Sachen arbeiten *g*).
http://www.atomic-eggs.com/z_testdir/sf_ebt_7.html#a4
http://www.atomic-eggs.com/z_testdir/eibox_7.js
So wie es aussieht befürchte ich, dass der bisherige Ansatz in der Funktion clip_eibox komplett überdacht werden müsste, sprich die Funktion komplett anders schreiben. Liege ich damit richtig oder ließe sich das Vorhandene doch ergänzen?
Ging ohne Neuschreiben. So sieht die Funktion jetzt aus:
function clip_eibox(name) {
obs = dc.getElementById(name).style;
obs.overflow='hidden';
if (dc.all && !is_opera9up) {
obs.top= window.opera ? dcde.scrollTop+self.innerHeight-29+"px" : dcde.scrollTop+dcde.clientHeight-29+"px";
boxen = dc.getElementsByTagName('div');
window.onresize = function () {
for (i=0;i<boxen.length;i++) {
if ((boxen[i].className == 'eibox') && (boxen[i].style.left == "0px")) {
boxen[i].style.top= window.opera ? dcde.scrollTop+self.innerHeight-29+"px" : dcde.scrollTop+dcde.clientHeight-29+"px";
}
}
}
dcde.onscroll = function () {
for (i=0;i<boxen.length;i++) {
if ((boxen[i].className == 'eibox') && (boxen[i].style.left == "0px")) {
boxen[i].style.top= window.opera ? dcde.scrollTop+self.innerHeight-29+"px" : dcde.scrollTop+dcde.clientHeight-29+"px";
}
}
}
}
else {
obs.position = "fixed";
obs.top = "";
obs.bottom = "0px";
}
obs.left = "0px";
}
Jetzt scrollen nur geclippte Boxen - und dadurch wird in etwa das bei Opera 9.01 und den Geckos einwandfrei dargestellten "fixed" simuliert. Allerdings besteht das IE-Problem mit dem verlängerten Body in dieser Situation nach wie vor:
Hat man in einem Fenster normaler Größe bis ganz unten gescrollt, eine Eibox geöffnet und "geclippt", und maximiert das Fenster jetzt über die entsprechende Schaltfläche der Titelleiste, wird die Höhe des Bodys verlängert, die minimierte Box ist zwar am unteren Ende des Viewports, aber zu weit unten (ausprobieren wird hier besser sein als meine Beschreibungsversuche *g*). Das hat nicht anscheinend nicht mit den paar Zeilen Code zu tun, die ich zur Vermeidung des IE-Textselection-Bug eingefügt habe, da das Beschriebene auch ohne dieses Scripts vorkommt.
und die Opera 7.x scrollt ins Unendliche, was bei der gestrigen Version:
http://www.atomic-eggs.com/z_testdir/sf_ebt_6.html#a4
http://www.atomic-eggs.com/z_testdir/eibox_6.js
nicht der Fall war (damit könnte ich leben, der wird wohl nicht mehr so verbreitet sein, denke ich mal).
Vielleicht fällt jemandem was ein, was das IE-Probleme behebt.
Viele Grüße aus Frankfurt/Main,
Patrick
Lesen vorm Senden hilft!
Jetzt scrollen nur geclippte Boxen _nicht mit_
^^^^^^^^^^
- Viele Grüße aus Frankfurt/Main,
Patrick
Re!
Falls es überhaupt noch jemand interessiert ;)
Sieht leider nicht danach aus :(
Trotzdem lasse ich nicht locker ;)
http://www.atomic-eggs.com/z_testdir/sf_ebt_7.html#a4
http://www.atomic-eggs.com/z_testdir/eibox_7.js
Allerdings besteht das IE-Problem mit dem verlängerten Body in dieser Situation nach wie vor.
Ich lasse mir jetzt drei Werte in einem Alert ausgeben, und zwar den Top-Wert der Box, document.documentElement.scrollTop (im Script: dcde.scrollTop) und document.documentElement.clientHeight.
Jetzt versuche ich in Worte zu fassen, was ich jemandem, der mit mir am Bildschirm säße mit einem einfachen "schau mal!" klar machen könnte...
Klar, dass Opera und IE unterschiedliche Werte zeigen, da die Seite im Opera etwas kompakter ist. Das ist nicht das, worauf ich hinweisen will. Sondern darauf (hier die Werte bei meiner Auflösung):
Neu laden, nach unten scrollen, erste Box aufrufen und minimieren:
299px Unterschied im IE, das ist genau der Wert, um welchen die Box zu weit nach unten kommt.
Wie kommt sowas zustande und was kann ich dagegen machen, bzw. dies umgehen?
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick
Es ist nicht unbedingt hilfreich, wenn du das Script änderst, wärend gerade jemand dabei ist, die Probleme nachzuvollziehen.
Wie kommt sowas zustande und was kann ich dagegen machen, bzw. dies umgehen?
Wenn die Seite ganz nach unten gescrollt ist, wird nach dem vergrößern des Browserfensters diese so weit nach oben gescrollt, bis das Seitenende wieder am unteren Fensterrand ist. Beim IE feuert onresize sofort, noch vor dem Anpassen der Scrollposition, dadurch erhältst du als neue Position die Summe aus neuer Fensterhöhe und alter Scrollposition.
Eine Lösung dafür habe ich noch nicht.
Eventuell könnte es helfen, die Funktion mit einer kleinen Zeitverzögerung aufzurufen.
Auf Wiederlesen
Detlef
Hallo Patrick
... was kann ich dagegen machen, bzw. dies umgehen?
Eventuell so:
function pos_clip_eibox () {
var boxen = dc.getElementsByTagName('div');
for (var i=0;i<boxen.length;i++) {
if ((boxen[i].className == 'eibox') && (boxen[i].style.overflow == "hidden")) {
boxen[i].style.top= window.opera ? dcde.scrollTop+self.innerHeight-29+"px" : dcde.scrollTop+dcde.clientHeight-29+"px";
// alert('ALERT 2\n\nBoxposbyResize= '+boxen[i].style.top+'\ndocument.documentElement.scrollTop= '+dcde.scrollTop+'\ndocument.documentElement.clientHeight= '+dcde.clientHeight);
}
}
}
function clip_eibox(name) {
obs = dc.getElementById(name).style;
obs.overflow='hidden';
if (dc.all && !is_opera9up) {
obs.top= window.opera ? dcde.scrollTop+self.innerHeight-29+"px" : dcde.scrollTop+dcde.clientHeight-29+"px";
dcde.onscroll = pos_clip_eibox;
if (window.opera)
window.onresize = pos_clip_eibox
else
window.onresize = function () {
window.setTimeout("pos_clip_eibox()", 100);
}
}
else {
obs.position = "fixed";
obs.top = "";
obs.bottom = "0px";
}
obs.left = "0px";
}
Auf Wiederlesen
Detlef
Hallo Detlef!
Es ist nicht unbedingt hilfreich, wenn du das Script änderst, wärend gerade jemand dabei ist, die Probleme nachzuvollziehen.
Hm, sorry. Eigentlich hatte ich am 7.10. in der eibox_7.js vom 6.10. lediglich das Alert eingefügt, weil ich wissen wollte, was diese Body-Verlängerung auf sich hatte, bzw. welcher Wert da verfälscht wird.
... was kann ich dagegen machen, bzw. dies umgehen?
Eventuell so:
function pos_clip_eibox () {
var boxen = dc.getElementsByTagName('div');
for (var i=0;i<boxen.length;i++) {
if ((boxen[i].className == 'eibox') && (boxen[i].style.overflow == "hidden")) {
boxen[i].style.top= window.opera ? dcde.scrollTop+self.innerHeight-29+"px" : dcde.scrollTop+dcde.clientHeight-29+"px";
// alert('ALERT 2\n\nBoxposbyResize= '+boxen[i].style.top+'\ndocument.documentElement.scrollTop= '+dcde.scrollTop+'\ndocument.documentElement.clientHeight= '+dcde.clientHeight);
}
}
}
function clip_eibox(name) {
obs = dc.getElementById(name).style;
obs.overflow='hidden';
if (dc.all && !is_opera9up) {
obs.top= window.opera ? dcde.scrollTop+self.innerHeight-29+"px" : dcde.scrollTop+dcde.clientHeight-29+"px";
dcde.onscroll = pos_clip_eibox;
if (window.opera)
window.onresize = pos_clip_eibox
else
window.onresize = function () {
window.setTimeout("pos_clip_eibox()", 100);
}
}
else {
obs.position = "fixed";
obs.top = "";
obs.bottom = "0px";
}
obs.left = "0px";
}
Danke, das war's ;) Eine Zeitverzögerung...! Nicht das erste Mal, dass IE Laufzeitprobleme hat, und eigentlich hätte ich dadurch selbst drauf kommen sollen. Ich habe überhaupt nicht daran gedacht, mich haben die gefälschten Werte nur irritiert. Also, nochmals danke und hier die neue Version (mittlerweile ist das Script auch auf allen Seiten mit Eiboxen):
<http://www.atomic-eggs.com/z_testdir/sf_ebt_8.html#a4>
<http://www.atomic-eggs.com/z_testdir/eibox_8.js>
Viele Grüße aus Frankfurt/Main,
Patrick
--
![](http://www.atomic-eggs.com/clubsig.gif)
\_ - jenseits vom delirium - \_
<hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash>
Hallo Patrick
Hm, sorry. Eigentlich hatte ich am 7.10. in der eibox_7.js vom 6.10. lediglich das Alert eingefügt, weil ich wissen wollte, was diese Body-Verlängerung auf sich hatte, bzw. welcher Wert da verfälscht wird.
Seltsam, als ich es heute getestet habe, konnte ich dein Problem nachvollziehen, als ich dann genauer testen wollte, ging es nach einem Reload überhaupt nicht mehr.
Als ich es dann bei mir lokal gespeichert hatte (zwischen meinen Postings) funktionierte wieder alles, bis auf dein genanntes Problem und die Probleme bzw. Anmerkungen, die ich weiter unten erwähne.
function pos_clip_eibox () {
var boxen = dc.getElementsByTagName('div');
for (var i=0;i<boxen.length;i++) {
if ((boxen[i].className == 'eibox') && (boxen[i].style.overflow == "hidden")) {
...
Dies habe ich so eingefügt, weil ich nicht weiter in deinem Code rumrühren wollte. Es ist aber ineffektiv, sich bei jedem Aufruf alle Divs der Seite zu holen, um sie dann alle einzeln abzuklappern, ob sie eine Eibox sind. Besser wäre es, global ein "Eiboxarray" zu erzeugen, und bei load() einmalig alle Divs durchzugehen und dabei die Referenzen auf die Eiboxen zu darin speichern.
Nun noch Fehler bzw. Anmerkungen:
Die Eibox kann zumindest im Firefox nach links oder oben aus dem Browserfenster herausgedragt werden. Damit wird sie unerreichbar. Da sollte vielleicht noch eine Prüfung eingebaut werden, die das verhindert.
Beim IE werde ich die Eibox nicht wieder los, wenn ich bei gedrückter Maustaste das Browserfenster verlasse, sie bleibt am Mauszeiger kleben. Erst ein weiterer Tastendruck legt die Eibox ab.
Mein Opera verhält sich in dieser Hinsicht mal wie Firefox und mal wie IE. Wann genau er sich wie verhält konnte ich nicht eindeutig nachvollziehen.
Sollten nicht alle Variablen innerhalb der Funktionen, die nicht global gültig sein sollen, auch wirklich local sein?
Der Inhalt der Eiboxen befindet sich einmal im Dokument und wird nur bei aktiviertem Javascript (in Form der Eibox) angezeigt oder wenn kein CSS unterstützt wird. Ohne Javascript öffnet sich eine extra Seite. Ich halte nicht für doppelt gemoppelt. Warum lässt du du die Eiboxen bei deaktivierem Javascript nicht einfach sichtbar, als Anker verlinkt oder unverlinkt (Link zur Eibox nur wenn Javascript verfügbar ist)?
Auf Wiederlesen
Detlef
--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin!
Hallo Detlef!
Erst mal ist es an der Zeit, dass ich mich bei Dir ganz persönlich und herzlich bedanke dafür, dass Du Dich für dieses Problem interessiert (wo es doch im Grunde nur ein Gimmick ist *g*) und Dir der "Eibox-Sache" derart annimmst.
Seltsam, als ich es heute getestet habe
Nein ;) Nichts ist hier seltsam. Seit mehreren Wochen schon habe ich die Eiboxen "entwickelt" und mich wundert mittlerweile nichts mehr. Sachen, die ich für abgehakt hatte, treten auf einmal wieder auf. Warum? Es kommt wirklich darauf an, alles zu testen. Mit IE, mit allen Operas, die man hat, mit den Geckos (für mich die fähigsten Browser, die machen die wenigsten Problemen - nicht nur bei den Eiboxen). Alle Situationen probieren, sich in ein User reinversetzen, der alles anklickt und dies und jenes macht etc... Auch jetzt, abgesehen von den Fehlern, die Du notierst hast, und auf die ich gleich eingehen werde, ist das "System" bei weitem nicht ausgereift.
Dies habe ich so eingefügt, weil ich nicht weiter in deinem Code rumrühren wollte.
Danke, aber es hat gewirkt ;)
Es ist aber ineffektiv, sich bei jedem Aufruf alle Divs der Seite zu holen, um sie dann alle einzeln abzuklappern, ob sie eine Eibox sind. Besser wäre es, global ein "Eiboxarray" zu erzeugen, und bei load() einmalig alle Divs durchzugehen und dabei die Referenzen auf die Eiboxen zu darin speichern.
Mag sein. Ich glaube aber nicht, dass es so viel Performance kostet. Obwohl getElementsByTagName('div').length bei der/den verlinkten Testseiten 61 DIV-Elemente auflistet (und das bei nur 4 Eiboxen), geht alles ziemlich flott. Sicher, vom Aspekt "sauberer Programmierung" wäre ein reiner Eibox-Array wirkungsvoller.
Nun noch Fehler bzw. Anmerkungen:
Die Eibox kann zumindest im Firefox nach links oder oben aus dem Browserfenster herausgedragt werden.
Stimmt. Bei Opera 9.01 bleit ein Teil der "Titelleiste" im Viewport, auch wenn Maus losgelassen...
Damit wird sie unerreichbar. Da sollte vielleicht noch eine Prüfung eingebaut werden, die das verhindert.
Ich schau mal die Tage bei DOM-Drag, wie die es in dem einem Beispiel gelöst haben (wo die Drag-Bilder schön innerhalb des einen DIV bleiben).
Beim IE werde ich die Eibox nicht wieder los, wenn ich bei gedrückter Maustaste das Browserfenster verlasse, sie bleibt am Mauszeiger kleben. Erst ein weiterer Tastendruck legt die Eibox ab.
Damit ich Dich verstehe: Du meinst, wenn ich eine Eibox nach z.B. rechtsaußen dragge, die Maustaste aber gedrückt lasse (dann bleibt die Box halb sichtbar am rechten Rand), zurück ins Fenster gehe, dann klebt die Box noch am Mauszeiger? Wäre es als Fehler oder Fehlverhalten anzusehen?
Mein Opera verhält sich in dieser Hinsicht mal wie Firefox und mal wie IE. Wann genau er sich wie verhält konnte ich nicht eindeutig nachvollziehen.
Hm.. beim 9er ist es nicht möglich, nach oben die Boxen soweit heraus zu bekommen wie beim Firefox. Dafür kann man sie (nur manchmal, ja) unsichtbar nach rechts oder links herausdraggen. Sie "kleben" bei gedrücktgelassener Maustasten allerdings immer noch.
Sollten nicht alle Variablen innerhalb der Funktionen, die nicht global gültig sein sollen, auch wirklich local sein?
Das verstehe ich nicht ganz. Ich habe mittlerweile in Perl eine intuitivere Art, vielleicht weil es mit Perl doch einfacher ist, mit local/global umzugehen, entwickelt (und zwar ohne use strict).
Es gibt noch einige Probleme mit der restore_eibox-Funktion, die einfach die daher rühren, dass der Wert der zuletzt geclippten Eibox gespeichert bleibt. Danach gehen alle restored Eiboxen an der gleichen top-Stelle auf, wie die zuletzt geclippte. Sowas wüßte ich mit Perl in wenig Zeit umzugehen.
Struppis Signatur (hoffenltich liest er noch mit) "JavaScript ist toll - Perl auch" würde ich eher in "Perl ist toll - JavaScript, wenn's sein muss" umdichten *g*. Irgendwie habe ich eine intuitivere Art als absoluter Programmierlaie entwickelt, mit Perl umzugehen. Ich muss mich nicht mit Browserbesonderheiten, Laufzeitprobleme beim IE usw. herumschlagen. Was ich mache, das läuft, und wenn nicht, läuft es beim nächsten Versuch. Für meine makenav.pl habe ich drei bis vier Tage gebraucht. An den Eiboxen bin ich (OK, mit vielen Pausen dazwischen) schon drei Wochen dran. Für mich sagt das schon alles *g*.
Der Inhalt der Eiboxen befindet sich einmal im Dokument und wird nur bei aktiviertem Javascript (in Form der Eibox) angezeigt oder wenn kein CSS unterstützt wird.
Ich hatte auch überlegt, die Eiboxen generell dynamisch zu generieren, aber irgendwo muss ohnehin ja der Text oder das Bild eh notiert werden. Da es von Seite zu Seite unterschiedlich ist, ist es einfacher, bei jeder Seite, die Eibox(en) zeigen soll, die DIVs im Dokument zu notieren, die Text-Inhalten werden eh mittels SSI inkludiert.
Ohne Javascript öffnet sich eine extra Seite. Ich halte nicht (ANMERKUNG: du meinst: ich halte das) für doppelt gemoppelt. Warum lässt du du die Eiboxen bei deaktivierem Javascript nicht einfach sichtbar, als Anker verlinkt oder unverlinkt (Link zur Eibox nur wenn Javascript verfügbar ist)?
Das würde doch nach nichts aussehen. Einfach, am Ende des blauen Textrahmens, würden die Eiboxen wie faule Trauben noch darunter hängen? Unformatiert und so? Nein, ich wollte das so *g*. Ich glaube auch nicht, dass es Userfeindlich ist, den Inahlt dieser Zusatzinformationen in einer Extra-Seite zu liefern. Den Inahlt bekommen sie, zurück kommen sie ja auch. Das muss man JavaScript-Verweigerer einfach zumuten, dass sie sich eins-zwei Klicks mehr Mühe geben, als andere... Hauptsache, sie werden vom Inhalt nicht ausgeschlossen, was bei mir nicht der Fall ist *g*
Viele Grüße aus Frankfurt/Main,
Patrick
Nein ;) Nichts ist hier seltsam. Seit mehreren Wochen schon habe ich die Eiboxen "entwickelt" und mich wundert mittlerweile nichts mehr. Sachen, die ich für abgehakt hatte, treten auf einmal wieder auf. Warum? Es kommt wirklich darauf an, alles zu testen. Mit IE, mit allen Operas, die man hat, mit den Geckos (für mich die fähigsten Browser, die machen die wenigsten Problemen - nicht nur bei den Eiboxen). Alle Situationen probieren, sich in ein User reinversetzen, der alles anklickt und dies und jenes macht etc... Auch jetzt, abgesehen von den Fehlern, die Du notierst hast, und auf die ich gleich eingehen werde, ist das "System" bei weitem nicht ausgereift.
Das ist der Grund warum ich mich gar nicht erst versucht habe auf deine freundliche Einladung einzulassen. Bei komplexeren Sachen tauchen diese Probleme immer wieder auf und ich bewundere alle die fertige, funktionierende JS Bibliotheken hinkriegen.
Sollten nicht alle Variablen innerhalb der Funktionen, die nicht global gültig sein sollen, auch wirklich local sein?
Das verstehe ich nicht ganz. Ich habe mittlerweile in Perl eine intuitivere Art, vielleicht weil es mit Perl doch einfacher ist, mit local/global umzugehen, entwickelt (und zwar ohne use strict).
ui, local?
Du nutzt noch local?
You really probably want to be using my instead, because local isn't what most people think of as ``local''. See Private Variables via my() in the perlsub manpage for details.
A local modifies the listed variables to be local to the enclosing block, file, or eval. If more than one value is listed, the list must be placed in parentheses. See Temporary Values via local() in the perlsub manpage for details, including issues with tied arrays and hashes.
und ohne strict?
Naja, egal.
Struppis Signatur (hoffenltich liest er noch mit) "JavaScript ist toll - Perl auch" würde ich eher in "Perl ist toll - JavaScript, wenn's sein muss" umdichten *g*. Irgendwie habe ich eine intuitivere Art als absoluter Programmierlaie entwickelt, mit Perl umzugehen.
So gesehen hat Perl, soweit ich das beurteilen kann, aber auch wesentlich mehr Möglichkeiten als andere Programmiersprachen. Deshalb auch ...
An den Eiboxen bin ich (OK, mit vielen Pausen dazwischen) schon drei Wochen dran. Für mich sagt das schon alles *g*.
Das kenn ich, zumal ich ja auch noch immer wieder, nicht ungern (man ist ja Masochist), mich mit dem IE 4 rumschlage.
Struppi.
Hallo Struppi!
Bei komplexeren Sachen tauchen diese Probleme immer wieder auf und ich bewundere alle die fertige, funktionierende JS Bibliotheken hinkriegen.
Ich auch. Wobei Du in JavaScript schon fit bist, oder?
Du nutzt noch local?
und ohne strict?
Ich habe nur wenig Scripte, wo ich strict benutze. Bin bisher immer klar gekommen.
Das kenn ich, zumal ich ja auch noch immer wieder, nicht ungern (man ist ja Masochist), mich mit dem IE 4 rumschlage.
Ach nee, der kriegt bei mir die "oldies.pl" ;)
Der dürfte genauso "tot" sein wie Netscape 4.x, oder?
Viele Grüße aus Frankfurt/Main,
Patrick
Bei komplexeren Sachen tauchen diese Probleme immer wieder auf und ich bewundere alle die fertige, funktionierende JS Bibliotheken hinkriegen.
Ich auch. Wobei Du in JavaScript schon fit bist, oder?
Ja, aber nicht in komplexität ;-)
Du nutzt noch local?
und ohne strict?Ich habe nur wenig Scripte, wo ich strict benutze. Bin bisher immer klar gekommen.
Klar kommen tut man, aber ich bin froh über die Meldungen von use strict, da mir das viel Fehlersuche erspart hat.
Das kenn ich, zumal ich ja auch noch immer wieder, nicht ungern (man ist ja Masochist), mich mit dem IE 4 rumschlage.
Ach nee, der kriegt bei mir die "oldies.pl" ;)
Der dürfte genauso "tot" sein wie Netscape 4.x, oder?
Vermutlich mehr tot, es gibt wahrscheinlich nur noch zwei Menschen auf der Welt die den IE 4 nutzen, ich und irgendjemand anderes ;-)
Struppi.
Re!
Es gibt noch einige Probleme mit der restore_eibox-Funktion, die einfach die daher rühren, dass der Wert der zuletzt geclippten Eibox gespeichert bleibt. Danach gehen alle restored Eiboxen an der gleichen top-Stelle auf, wie die zuletzt geclippte. Sowas wüßte ich mit Perl in wenig Zeit umzugehen.
[X] fixed!
Es betraff nur Bildboxen, jetzt mache ich das auch wie bei den Textboxen über offsetHeight. Problem gelöst.
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick
Damit ich Dich verstehe: Du meinst, wenn ich eine Eibox nach z.B. rechtsaußen dragge, die Maustaste aber gedrückt lasse (dann bleibt die Box halb sichtbar am rechten Rand),
außerhalb des Browserfensters die Maustaste loslasse und dann
zurück ins Fenster gehe, dann klebt die Box noch am Mauszeiger? Wäre es als Fehler oder Fehlverhalten anzusehen?
Meiner Meinung nach ja. Als ich das erste Mal deine Eiboxen ausprobierte, habe ich ein Weilchen gebraucht, bis ich darauf kam, dass ich das depperte magnetische Ding mit einem weiteren Maustastendruck wieder loswerde. Wie lange wird da wohl ein wenig versierter Nutzer brauchen, bis er darauf kommt?
Hm.. beim 9er ist es nicht möglich, nach oben die Boxen soweit heraus zu bekommen wie beim Firefox. Dafür kann man sie (nur manchmal, ja) unsichtbar nach rechts oder links herausdraggen. Sie "kleben" bei gedrücktgelassener Maustasten allerdings immer noch.
Wie oben eingefügt, wäre das kein Problem, wenn die Maustaste niemals losgelassen würde. ;)
Das verstehe ich nicht ganz. Ich habe mittlerweile in Perl eine intuitivere Art, vielleicht weil es mit Perl doch einfacher ist, mit local/global umzugehen, entwickelt (und zwar ohne use strict).
Ich meinte Folgendes:
»» function pos_clip_eibox () {
> var boxen = dc.getElementsByTagName('div');
> for (var i=0;i<boxen.length;i++) {
Damit kann es nicht passieren, dass die eventuell bestehenden gobalen Variablen boxen oder i durch die Funktion geändert werden.
Wenn so etwas passiert, vielleicht noch mit Variablen eines ganz anderen in die selbe Seite eingebundenen Scripts, kann die Fehlersuche etwas länger dauern.
Über die Variablen, die bewusst und absichtlich global definiert sind, behält man noch den Überblick, nicht unbedingt über alle Variablen aller Funktionen, die nur innerhalb dieser gebraucht werden.
Deshalb ist es von Vorteil alle lokalen Variablen auch wirklich lokal anzulegen und benötigte globale Variablen in einem extra Block zu deklarieren, auch wenn die Sprache das nicht unbedingt verlangt.
Struppis Signatur (hoffenltich liest er noch mit) "JavaScript ist toll - Perl auch" würde ich eher in "Perl ist toll - JavaScript, wenn's sein muss" umdichten *g*.
Dazu kann ich mich überhaupt nicht äußern, ich kenne Perl nicht.
Das würde doch nach nichts aussehen. Einfach, am Ende des blauen Textrahmens, würden die Eiboxen wie faule Trauben noch darunter hängen? Unformatiert und so?
Wieso, du kannst sie doch mittels CSS ansprechend und passend formatieren und/oder auch innerhalb des blauen Rahmens mit anzeigen. Und bei verfügbarem Javascript bekommen sie dann das spezielle Eibox-Style.
Nein, ich wollte das so *g*. Ich glaube auch nicht, dass es Userfeindlich ist, den Inahlt dieser Zusatzinformationen in einer Extra-Seite zu liefern.
Nicht unbedingt, mich würde es eher stören, dass ohne CSS (z.B. Textbrowser) der Inhalt auf der Seite selbst und noch einmal per Link auf einer extra Seite steht.
Hauptsache, sie werden vom Inhalt nicht ausgeschlossen, was bei mir nicht der Fall ist *g*
OK, oppelt hält besser.
Auf Wiederlesen
Detlef
Hallo Detlef!
Damit ich Dich verstehe: Du meinst, wenn ich eine Eibox nach z.B. rechtsaußen dragge, die Maustaste aber gedrückt lasse (dann bleibt die Box halb sichtbar am rechten Rand),
außerhalb des Browserfensters die Maustaste loslasse und dann
zurück ins Fenster gehe, dann klebt die Box noch am Mauszeiger? Wäre es als Fehler oder Fehlverhalten anzusehen?
Dieses Verhalten kann ich aber mit jedem Browser reproduzieren (bei den Gekcos manchmal aber nicht udn manchmal doch, seltsam). Ich kann mir das so erklären, dass onmouseup außerhalb des Dokumentfensters eben nicht feuert. Daher ist eben "nichts passiert", bewegt man die Maus wieder ins Fenster, hat man den gleichen Zustand, als wenn man die Maus nie losgelassen hätte.
Wie lange wird da wohl ein wenig versierter Nutzer brauchen, bis er darauf kommt?
Na, so lange die Eibox nicht an dessen Fingern pappt und der sie überall mitschleppt... ;) Spaß beiseite, ich suche mal nach einer Lösung (heute allerdings nicht mehr, wieder zu viel Code gesehen *g*).
Deshalb ist es von Vorteil alle lokalen Variablen auch wirklich lokal anzulegen und benötigte globale Variablen in einem extra Block zu deklarieren, auch wenn die Sprache das nicht unbedingt verlangt.
Verstehe. Muss nun überlegen, wie so ein Eibox-Array aussehen könnte ;)
Hauptsache, sie werden vom Inhalt nicht ausgeschlossen, was bei mir nicht der Fall ist *g*
OK, oppelt hält besser.
Genau ;) Gibt es eigentlich viele User mir reinen Textbrowsern?
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick
Ich kann mir das so erklären, dass onmouseup außerhalb des Dokumentfensters eben nicht feuert. Daher ist eben "nichts passiert", bewegt man die Maus wieder ins Fenster, hat man den gleichen Zustand, als wenn man die Maus nie losgelassen hätte.
Davon gehe ich auch aus. Eine Möglichkeit, das zu verhindern fällt mir im Moment auch nicht ein.
Na, so lange die Eibox nicht an dessen Fingern pappt und der sie überall mitschleppt... ;)
Dieweil die Finger nichts auf dem Monitor zu suchen haben, ist der Mauszeiger dort mein Finger. So gesehen klebt sie doch am Finger.;)
Deshalb ist es von Vorteil alle lokalen Variablen auch wirklich lokal anzulegen und benötigte globale Variablen in einem extra Block zu deklarieren, auch wenn die Sprache das nicht unbedingt verlangt.
Verstehe. Muss nun überlegen, wie so ein Eibox-Array aussehen könnte ;)
Mit dem Eibox-Array hat das erstmal nichts zu tun, dieses wäre dann global. Es geht eher darum, konsequent alles, was nicht global sein muss innerhalb der Funktionen mit var zu deklarieren.
Genau ;) Gibt es eigentlich viele User mir reinen Textbrowsern?
Persönlich kenne ich einen, der einen Textbrowser verwendet, wenn er nach Informationen sucht.
Selbst verwende ich keinen Textbrowser zum surfen. Allerdings ist Javascript normalerweise deaktiviert und wird nur eingeschaltet, wenns unbedingt nötig ist. Und wenn mich ein Seitendesign nervt, ist es auch ganz schnell deaktiviert.
Auf Wiederlesen
Detlef
Hallo Eibox-Fans!
Ich habe eben eine Version hochgeladen, bei welcher das Drag&Drop auf den Viewport limitiert ist. Ich stelle sie hiermit zur Diskussion, da ich selbst nicht weiß, ob ich diese Version behalten will (denn richtige OS-Fenster lassen sich nämlich auch außerhalb des Bildschirms ziehen, wenn auch nur so viel man sie noch "anfassen" kann).
Dazu musste ich in Struppis do_drag-Funktion reinpfuschen ;)
function st_do_drag(we) {
obsw = parseInt(obs.width);
maxright = dc.all ? dcde.clientWidth - obsw : self.innerWidth - obsw;
var o = this.dragObject;
if(!o) return;
var pos = st_getEvtPos(we); // Position des Ereignisses
var dTop = o.evt_top - pos[0];
var dLeft = o.evt_left - pos[1];
if ((o.start_top - dTop) > body.scrollTop) o.style.top = (o.start_top - dTop) + 'px';
if ((o.start_left - dLeft) > 0 && (o.start_left - dLeft) < maxright) o.style.left = (o.start_left - dLeft) + 'px';
return false;
}
Das funktioniert in allen Browsern, ich habe aber den Eindruck, dass es das Draggen etwas langsamer macht (gerade bei den Operas). Life zu sehen hier:
http://www.atomic-eggs.com/z_testdir/sf_ebt_9.html#a4
http://www.atomic-eggs.com/z_testdir/eibox_9.js
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick
Das funktioniert in allen Browsern,
Nö, nicht wirklich.
Wenn ich die Eibox zügig bewege, bleibt sie oft ein ganzes Stück vom Fensterrand entfernt hängen.
ich habe aber den Eindruck, dass es das Draggen etwas langsamer macht (gerade bei den Operas).
Schmeiß das wieder raus, das ist viel zu aufwendig.
Wenn die Eibox mit der Seite mitscrollt, dann interessiert dabei nicht die Browserfenster- sondern eher die Dokumentgröße.
Und auch die interessiert nicht wirklich, weil die Eibox das Dokument einfach nach rechts oder unten erweitert, so dass sie durch scrollen immer erreichbar bleibt (ist zwar ein lustiger Effekt, aber nicht wirklich schlimm). Das Problem besteht nur oben und links.
Eventuell so:
function st_do_drag(we) {
var o = this.dragObject;
if(!o) return;
var minLeft = 90 - o.offsetWidth;
var pos = st_getEvtPos(we); // Position des Ereignisses
var dTop = o.start_top - o.evt_top + pos[0];
var dLeft = o.start_left - o.evt_left + pos[1];
o.style.top = (dTop > 0 ? dTop : 0 ) + 'px';
o.style.left = (dLeft > minLeft ? dLeft : minLeft) + 'px';
return false;
}
Auf Wiederlesen
Detlef
Hallo Detlef!
Das funktioniert in allen Browsern,
Nö, nicht wirklich. Wenn ich die Eibox zügig bewege, bleibt sie oft ein ganzes Stück vom Fensterrand entfernt hängen.
Wie gesagt, mir hat es auch nicht gefallen - auch aus diesem Grund.
Schmeiß das wieder raus
Jein. ;) In der eibox_9.js (sf_etb_9.html), die hier in meinem letzten Post verlinkt ist, bleibt es so :) - Alle bisher verlinkten Dateien lasse ich eine Weile im Test-Verzeichnis, vielleicht interessiert sich mal jemand für die Eibox-Entwicklung!
Aber für die "echten" Eiboxen ist Dein Vorschlag:
function st_do_drag(we) {
var o = this.dragObject;
if(!o) return;
var minLeft = 90 - o.offsetWidth;
var pos = st_getEvtPos(we); // Position des Ereignisses
var dTop = o.start_top - o.evt_top + pos[0];
var dLeft = o.start_left - o.evt_left + pos[1];
o.style.top = (dTop > 0 ? dTop : 0 ) + 'px';
o.style.left = (dLeft > minLeft ? dLeft : minLeft) + 'px';
return false;
}
ein guter Kompromiss zwischen dem Verhalten eines "richtigen" OS-Fensters und der Tatsache, dass die Eibox ja auch nicht "verloren" gehen sollte, weil zu weit oben oder zu weit links. Ich habe ihn eingebaut.
Mittlerweile habe ich die vorerst letzte Fassung hochgeladen, dabei endlich Mathias' Einwand berücksichtigt: Die Boxen haben jetzt nur noch zwei Schaltflächen, da man sie ja nicht ganz auf Bildschirmgröße maximieren kann und soll, und daher wurde der entsprechende Button entfernt. Zu sehen ist nur noch, neben dem Schließen-Button, die Schaltfläche für's Minimieren. Hat man drauf geklickt und die Box ist minimiert, erscheint an deren Stelle die Schaltfläche für's Wiederherstellen. Habe ein bisschen bei PaintShopPro nachgeschaut, das Programm handelt das mit seinen internen Fenstern ähnlich.
http://www.atomic-eggs.com/z_testdir/sf_ebt_10.html#a4
http://www.atomic-eggs.com/z_testdir/eibox_10.js
Nochmals zum Problem des "Maus-außerhalb-des-Browserfensters-loslassens". Ich habe hier zwei DOM-Drag-Beispiele verlinkt, man kann folgendes feststellen:
DOM-Drag-Box
^ Box klebt am Mauzeiger, wenn man außerhalb des Browserfensters die Maus loslässt und wieder ins Fenter zieht.
DOM-Drag-Bilder
^ Hier nicht: Hat man die Maus losgelassen, ist man auch das Bild los (green or grey, purple bliebt ja im Kasten)
In beiden Dateien ist das Script dom-drag.js eingebunden..., onmouseup wir nur im Script notiert (nicht noch mal an zusätzlicher Stelle in der HTML-Datei, was vielleicht hätte ein Grund sein können):
In der Funtkion start:
document.onmousemove = Drag.drag;
document.onmouseup = Drag.end;
und hier:
end : function()
{
document.onmousemove = null;
document.onmouseup = null;
Drag.obj.root.onDragEnd( parseInt(Drag.obj.root.style[Drag.obj.hmode ? "left" : "right"]),
parseInt(Drag.obj.root.style[Drag.obj.vmode ? "top" : "bottom"]));
Drag.obj = null;
},
Von daher ist es mir unverständlich (ohne mich jetzt mit dem Script näher befaßt zu haben), warum bei dem einem Beispiel die Box "klebt" und in dem anderen Beispiel die Bilder nicht.
@Struppi: in Deinem Drag&Drop-Beispiel ist mir heute mit Opera 9.01 ein ähnlicher Darstellungsfehler aufgefallen, wie bei den Bild-Eiboxen. Zwar sind da keine sich wiederholenden Streifen beim Nach-Oben-Draggen, jedoch bleibt beim ersten Draggen des unteren Bildes ein Stück davon an der Stelle "haften". Ein Bild sagt mehr als meine Erklärungsversuche, daher Screenshot:
Scheint also klipp und klar ein Opera-Darstellungsfehler zu sein.
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick
ein guter Kompromiss zwischen dem Verhalten eines "richtigen" OS-Fensters ...
Dieses würde allerdings wohl kaum mit der Seite mitscrollen.
Mittlerweile habe ich die vorerst letzte Fassung hochgeladen,
Hoffentlich nicht.
http://www.atomic-eggs.com/z_testdir/sf_ebt_10.html#a4
http://www.atomic-eggs.com/z_testdir/eibox_10.js
Eine Kleinigkeit noch:
Wenn ich die Eibox zufällig oder absichtlich genau am linken Fensterrand ablege, dann kann ich sie nicht mehr greifen.
function drag_me(name) {
if(name) {
obs = dc.getElementById(name).style;
// if (obs.bottom != "0px") {
if ((obs.left != "0px")) {
...
Die letzte Zeile dürfte der Übeltäter sein. Damit das nicht passieren kann, sieht das in pos_clip_eibox () etwas anders aus.
if ((boxen[i].className == 'eibox') && (boxen[i].style.overflow == "hidden")) {
Auf Wiederlesen
Detlef
Hallo Detlef!
ein "richtiges" OS-Fensters ...
würde allerdings wohl kaum mit der Seite mitscrollen.
Stimmt, aber der Desktop ist auch kein Dokument ;) Zwar könnte man die Boxen generell fixieren, wäre es aber nicht zu viel für eine "nur Simulation" eines Fensterchens?
letzte Fassung hochgeladen,
Hoffentlich nicht.
Entweder Du findest Gefallen am 'rumprobieren/'rumändern oder... die Boxen gefallen Dir noch nicht ;)
Oder beides?
Wenn ich die Eibox zufällig oder absichtlich genau am linken Fensterrand ablege, dann kann ich sie nicht mehr greifen.
Aargh, hatte ich übersehen. Jetzt steht:
function drag_me(name) {
if(name) {
obs = dc.getElementById(name).style;
if (obs.overflow != 'hidden') {
Danke und
viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick
Aus dem Text der Seite:
"Für das Konstrukt mit runden Ecken sollte ursprünglich die bei ^AListApart und bei ^Andreas Kalt vorgestellte Technik der Sliding Doors angewendet werden, ... In anderen Worten: Mit transparenten Bereichen wie die abgerundeten Ecken der oberen Box-Graphiken lässt sich die Technik nicht anwenden, da von der rechten Schiebetür eine Ecke durch die transparente Ecke der linken Schiebetür » immer zum Vorschein kommt."
Kennst du "Vergilbtes Papier mit angebranntem Rand"?
Auf Wiederlesen
Detlef
Hallo Detlef!
Kennst du "Vergilbtes Papier mit angebranntem Rand"?
Wie kann ich etwas kennen, wenn Du es erst jetzt verlinkst*? ;)
Hut ab, gute Arbeit! Mit etwas Pixelgeschubse konnte ich quick&dirty sogar fast eine Eibox daraus machen, die unten jedoch noch ein bissi durchsiebt ist...: http://www.atomic-eggs.com/z_testdir/dg_box.html ;)
Werde mir bei Gelegenheit was überlegen.
Im moment bin ich jedoch wieder bei Perl... und will wieder mal die perlssi vom Xitami bearbeiten, damit include virtual = "datei.cgi(oder .pl)?argumente" genauso interpretiert wird wie beim Apache.
Ach ja, und bei den Eiboxen habe ich eine close_all-Funktion über die Taste ESC eingebaut (noch nicht online).
*Du könntest Deine Beispiele generell hier bei URL immer verlinken, da wird sich der eine oder andere Leser hier sicher dafür interessieren und daraus lernen können.
Viele Grüße aus Frankfurt/Main,
Patrick