« »

Verfasst am 04.04.2005 16:27:39 Uhr
Ob auch die Bilder noch tanzen lernen? - Teil2
Fortsetzung v.heute

Vielleicht? Vielleicht auch nicht? Leider gelingt zur Zeit noch nicht die Abfrage der DIV-Elementpositionen beim Internet Explorer. Ein Versuch zählt nicht. Es zählt nur das Ergebnis. Dieser Teil2 ist also leider noch ergebnisoffen:

---

Und hier noch eine Spielerei ohne Marquee-Technik (F): nachfolgender javascript-gesteuerte Bildstreifen sollte sich an der rechten (freenet-)Tagebuchgrenze von 500pixel respektive Browserfensterbreite selbst ausbremsen! (noch fehlerhaft) Doch zuvor muss er manuell gestartet werden. Wegen anwenderbezogener Fensterbreiten und Schriftgrößen kann der Bilderstreifen höher oder tiefer als der nachfolgend reservierte Freiraum ablaufen (evtl. ist Scrollen notwendig). Die Größe Layertop, welche die Obergrenze des Bildstreifens einer absoluten Browserfensterhöhe zuordnet, sollte über javascript automatisch ermittelt werden.

Ausgabe von DIV- und Bildlayer-Koordinaten

Zwecks Startwerteberechnung des Pseudomarquees "bewegliche Bildschicht" oder "bewegliche Bildebene" kann man folgende Werte auslesen:

Koordinatenursprung (x0|y0) (browserabhängig) von der (linken|oberen) Ecke ...
   • der Netscape-Browserfensteraussenkante (Firefox3.0.2) ...
   • der Microsoft-Browserfensterinnenkante (I.E.7.0) ...
... relativ zur (linken|oberen) Ecke der Desktopfläche:
x0: y0: [Pixel]

Koordinatenpaare (x1|y1), (dx1|y1), (x1|dy1), (dx1|dy1) == (linke|obere), (rechte|obere), (linke|untere), (rechte|untere) Ecke des Fensters eines Browsers:
x1: y1: dx1: dy1: [Pixel]

Koordinatenoffset (graues Feld):
x2: y2: dx2: dy2: [Pixel]

Koordinaten (Bilderstreifen) relativ zur (linken|unteren) Grenze des grauen Feldes; einheitsabhängig):
x3: y3: y3_kalku./px:

Koordinatenoffset (Bilderstreifen):
x4: y4: dx4: dy4: [Pixel]

Je nach Browsertyp setzt mich zunächst ein unterschiedliches Pixeloffset "y_korr." in Erstaunen, mit: y_korr. = { 1 (I.E.) ; 2 (Firefox) } (noch etwas unklar) in:

Firefox:

y4 = 2 + y2 + dy2 + y3/px
x4 = 2 + x2 + x3/px

I.Explorer:

y4 = 1 + y2 + dy2 + y3/px
x4 = 1 + x2 + x3/px

Nach Analyse durch ein Bildbearbeitungsprogrammes ergibt sich:

• die Zahl 2 beim Firefox rührt vom Bildrahmen (border=2) her.
• das mit 77px hohe Bildlayer wird bei Firefox nur mit 76px dargestellt (inkl. 2px=Tabellenrahmenoberkante(mitte), 2px=Tabellenrahmenunterkante(mitte), 1px=Tabellenrahmenoberkante(innen), 1px=Tabellenrahmenunterkante(innen)), ergänzt um 2px =Bildrahmenoberkante und 2px=Bildrahmenunterkante; dies ergibt einen Ordinatenplatzbedarf = 80px
• das 77px hohe Bildlayer wird beim I.E. mit 92px Ordinatenplatzbedarf dargestellt (inkl. 2px=Bildrahmenoberkante(außen), 2px=Bildrahmenunterkante(außen); inkl. 2px=Tabellenrahmenoberkante(mitte), 2px=Tabellenrahmenunterkante(mitte), 1px=Tabellenrahmenoberkante(innen), 1px=Tabellenrahmenunterkante(innen))
• das 160px hohe ungerahmte DIV-Layer wird beim I.E. mit 168px Ordinatenbedarf dargestellt (mir reicht's!)
• das 160px hohe ungerahmte DIV-Layer wird beim Firefox mit 196px Ordinatenbedarf dargestellt (aufhören!!)
• auch beim Firefox lassen sich Situation erzeugen, in denen die Bildlayer nicht in gleicher Ordinate liegen. Also ist auch noch ein Vergrößerungsfaktor und evtl. ein Rundungsfehler zu berücksichtigen. (Es ist alles gaaaanz 1fach!!!)

Wegen unterschiedlicher Pixeloffsets bei Firefox und I.E. kommt nur beim Firefox das JKL-Layer mit dem GHI-Layer zur Ordinaten-Deckung (noch unklar)

DIV-Streifenmitte (horizontal) =^= Bildlayermitte (horizontal):

y = y2 + (dy2)/2 + y_korr.

Bildlayer-Startordinate (horizontal): für

• "position:absolute": y4_kalku. = y - (dy4)/2 + y_korr.
• "position:relative": y3_kalku./px = y4_kalku. - (y2 + dy2 + y_korr.) =(?)= (-1/2) · (dy2 + dy4) (durch Einsetzen)

••• Historie:
Ein hartnäckiger I.E.-javascript-Fehler "screenX", der eigentlich hier nur vom Firefox verwendet werden sollte, wird durch ein alert erzeugt, welches in einer Javascript-Datei steht, darum...
MERKE: Als Fehlerquelle wird im I.E. immer das Dokument *.html und nicht wie beim Firefox die Datei *.js genannt, falls der Fehler in einer solchen externen Javascriptdatei liegt.

Letzter Stand(15.2.2009, 19Uhr): endlich weiß ich die richtige Startkoordinate.

(unfertig !)

Folgende (Test-)Parameter werden übergeben (ob benötigt, ist noch unklar):

• Delaytime [sek] = 10
• LayerTop [px] = y3/px (siehe obiges Formularfeld; =hier z.B.: -125 oder für das nächste Layer -(125+77)=-202 )
• Figurenweite [px] = 968
• Rechter Rand [px] = 500

Ideal wäre es, falls es gelänge, über die automatische Layertop-Bestimmung das Bilderlaufband (Pseudo-Marquee) zu starten. Bis dahin bitte zur Koordinatenausgabe im Formular (und zum Start) hier klicken:

Dieser mit GHI markierte, unbewegliche meinBild-Bilderstreifen folgt im HTML-Code einem vorangestellten grauen DIV-Bereich, durch den nach dem Start der Bildstreifen horizontal laufen soll. Dieses graues Feld liegt je nach Browsertyp und Fensterbreite

• alte Werte vor der Dokumentzerlegung (bis 11.2.2009):
  • von ca. (von 1805 bis 1965)px bis (von 2632 bis 2803)px (beim Firefox3.0.2)
  • von ca. (2253 bis 2424)px bis (2456 bis 2626)px (beim I.E.7.0)
• neue Werte (nur für Beitrag2): ca. 1700px sind von den alten Werten abzuziehen

, wobei das jeweils erste Zahlenpaar für maximale Fensterbreite gilt. Das graue DIV-Element (= DIV-Tag) sollte zu dem meinBild-DIV-Element ein Vorfahrenelement unter Normaleinstellungen sein, d.h. das css-Style-Attribut laute voreingestellt "position:static". Der Bildstreifen wird über die css-Style-Attribute von z.B. "position:relative; top:-125px; left:25px;" in die Startposition gebracht (bei Style-Angaben das "px" nicht vergessen!). An seine ursprüngliche Stelle ist nun ein Freiraum getreten, den man schließen könnte, würde man alle übrigen Texte und HTML-Elemente ebenfalls in DIV-Elemente packen und relativ im gleichen Maße wie den Bildstreifen nach oben verschieben.

Durch die Anlage eines zusätzlichen Testbildstreifens "JKL" hat sich der Freiraum vor "Dieser mit GHI markierte" entsprechend des neuen Platzbedarfes vergrößert.

Zur Orientierung sind die absoluten Browser-Ordinaten am linken Fensterrand eingeblendet.
unerledigt; später mehr

---

Endlich eine endlose Spielerei (G). Den nachfolgenden absolut-positionierten Film kann man leider auch nicht bremsen (evtl. ist Scrollen notwendig). Sollen beide Bilderserien als endlos-Film ablaufen, bitte hier klicken:















Aufgrund der unterschiedlichen Länge der Fotoserien kann es zu Überschneidungen kommen. Beim letzten endlos-Scroll braucht man in diesem Fall nur 2Bilderserien, das Programm funktioniert aber nur mit 3Bilderserien. Aber für heute ist genug ge-javascript-elt.

Ich schreibe später noch mehr zur Veranstaltung... (dp) (+1,5h), (+6h(8.2.2009)), (+7,5h (+Skala(9.2.2009))), (+6h (+Formular (10.2.2009)), 11.2.2009 (+3h ( +SkalenKorr. +ifLogik-Korr. +javascript-Probieren)), 12.2.2009 (+3h ( +javascript-Korr.)), 15.2.2009 (+2h ( +Bildbearb.-Tests))

Nachtrag_1 am 07.6.2005, und 27.11.2008 um 05.33Uhr:
Auf dieser Veranstaltung habe ich zufällig die aus meinen alten KHG-Gießen-Zeiten bekannte Julia wiedergetroffen. Da ich erst nachmittags auf der Veranstaltung erschien und sie ihre Tanzvorführung schon am Vormittag gehabt hatte, konnte ich ihre Tanzkünste leider nicht mehr bewundern. Aber ich stehe mit meiner Meinung nicht allein, wenn ich behaupte, ihre Homepage hat sie ganz ordentlich und übersichtlich und daher kundenfreundlich gestaltet. (dp) (+0,25h)

Fortsetzung» am 29.4.2008 (Problemthema "marquee")

ANMERKUNG:

• siehe auch Teil1

archiviert (tbid130.12): (dp) 24.11.2008 (+0,85h (+Keywordsort. +flagcounter +emoticon +home.icon)), 31.1.2009 (+0,5h (+Link-korr.) +0,1h (+4navi +w3c_LiCh)), 07.2.2009 (+1,5h (+html-korr. +style-korr.)), 08.2.2009 (+6h (+marqueehtml-korr. +tablehtml-korr. +TDSL-Störung)), 11.2.2009(+7h (+JavaScript-Tests +Dokument2TeileZerlegung +HTML-Valid. +LinkTest)), 21.7.2010(+0,03h(-validome.org+w3c_HTMLch))