Firefox ist ein !!!RIESENSCHROTT!!!

Impressum | Werbung

Geizhals » Forum » Programmierung »

Firefox ist ein !!!RIESENSCHROTT!!! (118 Beiträge, 2026 Mal gelesen)

Top-100 | Fresh-100

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi !

Habe ein Problem auf folgendes reduzieren können:

&lt;html>

&lt;script type='text/javascript'>
        function show(was)
        {
                document.write(
                        was + '=' +
                        document.getElementById('x').style[was] +
                        '&lt;br>');
        }

&lt;/script>

&lt;div id='x' style="z-index:10; background-color:yellow; border: 1px solid grey;">bubu</div>
&lt;script type='text/javascript'>
        show('border');
        show('background-color');
        show('z-index');
&lt;/script>

&lt;/html>

das Beispiel liefert

bubu
border=1px solid grey
background-color=undefined
z-index=undefined

Also kann er scheinbar keine Style-Attribute mit "-" drin auslesen...

Kann ja nicht sein, daß FF sowohl zu blöd für ein getAttribute am Style ist - als auch zu blöd für ein lesen eines Styles mit "-" drinnen... Nach langem suchen im eigenen Code (weil man sich ja denkt, daß der FF net so deppat sein kann) habe ich Google angeworfen... JA, man muß den style beim lesen von "z-index" auf "zIndex" umbenamsen... so ein Shaaaaß!

Was man mit dem ganzen Gefrickel an Zeit verliert... brrr.

Kein Wunder, daß 90% der User auf IE schwören...

EDIT:
Ach ja, wenn sich wer wundert, warum ich mit document.write rumshice...
Weil der schwule FF bei alert() auf meiner zu debuggenden Seite gerne mal mit "permissiondenied in XULElement.." oder so antwortet... Nach nachgoogeln habe ich gefunden, daß der Bug im FF mindestens seit 2004 drinnen ist... Soviel zu den traumhaften schnellen Bugfixes... ARGH.

Man sollte ja meinen, daß offene Standards, OpenSource-Entwickler und deren OpenSource-Produkte harmonieren, aber NEIN. Da zitier' ich mal Pervasive:

alles ! ! ! ! G E F R I C K E L ! ! ! !

EDIT²:
Noch blödsinniger an dem ganzen ist, daß FF kein

style='zIndex=10;'

versteht. Für dasselbe Trum will er also [zumindest] 2 verschiedene Schreibweisen. Man muß sich also einen Frickelparser basteln, der ein "-x" in "X" umwandelt.. ARGH. Wenn's wenigstens eine Funktion dafür dabei hätten a la "QuoteStyleMeta" oder so.. aber auch net...

14.04.2006, 17:39 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Korrekt...

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

hi,

rein interessehalber - hast du eigentlich nach der überschrift noch weiter gelesen?

lg,
hariw

Ein Bär, ein Löwe und ein Huhn treffen sich.
Sagt der Bär: "Wenn ich im Wald brülle, fürchtet sich der ganze Wald".
Der Löwe: "Wenn ich in der Wüste brülle, fürchtet sich die ganze Wüste".
Das Huhn darauf: "Pha, wenn ich huste, fürchtet sich die ganze Welt"!

Hmmm... wieso ?

Paßt was an meinem Inhalt net, daß du so fragst ???

hi,

nee, aber man kennt ja pervasive´s präferenz von ms-produkten

lg,
hariw

Neee, da täuscht du dich...

Ich dachte mal wie du - komme aber mehr und mehr zu dem Schluß, daß Pervasive recht hat und das ganze OS-Klumpat echt nur ein Gefrickel ist

hi,

naja, ich sehs eher distanzierter...
jede sw hat stärken und schwächen, ja sogar eindutige bug´s - mit denen man natürlich besser leben kann, umso homogener die "landschaft" ist..., für mich gibt´s gein "gut" und "böse"...

lg,
hariw

Echt, alleine um den Bug zu isolieren habe ich 1/2 Tag vershissen... das f*ckt mich extremst an... SO kann ich nicht arbeiten.

Das IST ja das Problem...

Die Zeit der ganzen OS-Frickler ist ja nichts wert...die brauchen ja nicht auf die Uhr zu schauen...

Natürlich...und bei uns fluchen die Webdesigner jeden Tag...

Wie sag ich's freundlich... als Anwender is' mir des herzlich wuascht.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Stimmt als Web-Designer fängt man beim IE zum Zluchen an - obwohl es besser geworden.

DA funktioniert ja das Meiste...aber ein Projekt "kompatibel" zu halten kostet im Moment zu viel Nerven, Zeit und Geld...

Dein Wissen in Ehren, aber was das betrifft, liegst du komplett falsch.

Ein Stück Software, welches falschen Quelltext wiederrum so falsch darstellt, dass er korrekt wirkt, kann man niemals funktionierend nennen.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Ändert nichts daran, daß es der de facto Standard ist...

Was wiederrum nichts daran ändert, dass das W3 Konsortium die Standards vorgibt, und nicht MS.
Mir ist auch klar, dass dein Erfolg von MS abhängt, und du somit parteiisch bist, da hat eine Diskussion nicht viel sinn.
Ich akzeptiere deine Meinung, teile sie jedoch nicht.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

ich weiß net wo dein problem ist, bei mir funktioniert z-index normal und ohne komisches gefrickel.
siehe meine neueste kleine css-datei:
http://stefan.wueringer.at/stefan/aluplan/design.css

und nun sieh dir diesen "rohentwurf" eines layouts mal mit firefox und dann mit IE an:
http://stefan.wueringer.at/stefan/aluplan/

und dann sieh dir noch den quelltext der index an.

du wirst bemerken: ganz normale programmierung, und ganz ohne gefrickel. und funzen tut's mit beiden browsern.

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Du setzt den z-index per css... das klappt eh.
Es geht darum, daß der zugriff auf die Style-Attribute per Javascript eben net mit "z-index" klappt... kannst eh mein File ausprobieren.

ah jetz wirds mir klar wo dein problem liegt!
hm...aber lösen kann ich's auch nicht. perfekt ist halt leider keine software...würden sich eben alle herrschaften an den geltenden standard halten, und nicht immer besondere "feature's" einbauen wollen, dann hätten wir diesbezüglich keine sorgen mehr...

Dein Beispiel funkt aber unter IE auch nicht!

Mit Hilfe von
http://www.quirksmode.org/dom/getstyles.html
habe ich dein Beispiel aber zum Laufen gebracht

siehe function getStyle()

Edith: Obwohl der Output ist unter FF auch etwas eigenwillig:

background-color=rgb(255, 255, 0)
z-index=10

14.04.2006, 16:54 Uhr - Editiert von nergal, alte Version: hier
Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

^ Forum Programmierung #3339345
	Re: Firefox ist ein !!!RIESENSCHROTT!!!

user96106

14.04.2006, 16:56:31

komisch mein internet explorer 6.0 Windows XP SP2 inkl. aller patches. kanns aber auch nicht.

der versteht auch nur:



<script type='text/javascript'>
        show('border');
        show('backgroundColor');
        show('zIndex');
</script>


zudem kennt er grau nur als gray nicht als grey.

14.04.2006, 17:04 Uhr - Editiert von user96106, alte Version: hier
Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Echt ?
Dann korrigiere ich mich... Dann ist JS ein Shice

Wobei der IE sicher kein

Error: [Exception... "'Permission denied to get property XULElement.selectedIndex' when calling method: [nsIAutoCompletePopup::selectedIndex]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: file:///home/grueni/tests/eingabe.html :: parseInput :: line 192" data: no]
Source File: file:///home/grueni/tests/eingabe.html
Line: 192

wirft, wenn man ein alert() aufruft...

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Glaub ich gern. Daß den IE irgendwelche Permissions scheren wär mir neu.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

D.h. er versteht den Variablennamen "z-index" nicht?

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Er versteht "z-index" nicht als Attribut vom Style... sondern aus JS nur "zIndex", wärend er im CSS nur "z-index" kennt. Wirr..

Zeig mir einen "fehler"freien Browser.

LYNX

Nach dem Motto "wo nix geht, kann auch nix schiefgehen"

Mfg Dogg

Leute, bitte strengt euch an!
Bei einer Differenz spricht man von - ALS
Wenn etwas ident ist - WIE
"Wie" klingt be*PIEP*er als "als".

Gschichtl... Der Lynx ist ein sauflotter Browser. Also mal angenommen, du besuchst eine Seite wie http://www.pudern.de (wird wohl so eine Kosmetikseite sein

) - dann wird 100%ig der Lynx die Seite um mindestens den Faktor 10 schneller geladen haben

Also mit Firefox ist die Geschwindigkeit der Seite tadellos, aber der Inhalt zzzz

Ich meinte beim Lynx eher dass Javascript, Css, Flash usw... nicht funktionieren. Wenn ich mich irren sollte starte ich gleich linux und werds überprüfen.

Mfg Dogg

Leute, bitte strengt euch an!
Bei einer Differenz spricht man von - ALS
Wenn etwas ident ist - WIE
"Wie" klingt be*PIEP*er als "als".

*sich selbst auf die Finger klopft* Cereal, halt dich endlich vom Programmieren Subforum fern, du weißt ja eh dass du nur Bahnhof verstehen wirst...aber NEIN...der Herr Cereal muss ja immer wieder da reinklicken nur um dann wieder nur an seine Dummheit erinnert zu werden....

In diesem Sinne: Häääääääääääääääää????

lg
Cereal

Bin seit einer Woche ohne Kaffee, wer will sich mit mir anlegen?

du bist nicht allein

Sorry, aber bei solchen Beiträgen platzt mir doch der Kragen.

Informiert dich gefälligst mal, bevor du dich mit JS & Co auseinander setzt, dann wüsstest du, dass bei den Style-Definitionen kein "-" vorkommt, sondern aus background-color ein backgroundColor wird.

Und das ist übrigens nicht nur beim FF so, sondern auch bei jedem anderen Browser.

Der FF kann für deine Probleme genau _garnix_ - es ist bei JS einfach nicht möglich, einen Bindestrich in einem Variablennamen zu verwenden, darum sieht die Style-Definition in JS eben anders aus als per CSS.

Schlußendlich geht es dir aber wie allen Browser-Jüngern, die FF, Opera & Co. verschreien: Haben selbst keine Ahnung von einem sauberen Programmierstil, und verfluchen dann Browser, die sich an Richtlinien halten, und ihren Schrott-Code nicht umsetzen.

Ich empfehle dir, mal ein paar Tage auf C/C++ umzusteigen, da wird dir der Compiler auch keine Fehler verzeihen, vielleicht lernst du daraus, in Zukunft korrekten Code zu schreiben, bevor dir wieder solche verbalen Auszucker unterlaufen.

Gruß,
Dr. Watson, der mit jedem der verbreiteten Browser klarkommt.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

14.04.2006, 18:44 Uhr - Editiert von Dr. Watson, alte Version: hier

Es geht nicht um deine Frau, sondern um einen Browser...

_______________________________________________________________________________

Dancetime V2.0

Mal langsam, Schnucki...
1.) Habe ich schon geschrieben, daß - wenn das beim IE auch so ist - ich mich korrigiere... Dann ist JS Schrott, net nur der FF

2.) Habe ich ja bei der Fehlersuche versucht, mich zu informieren.. und SELFHTML gewälzt.
Dort findet man schnell getAttribute() von all... nur steht dabei, daß das nur der IE kann.
zIndex taucht auch nicht im Quickbar auf (dann hätte ich es gefunden). Aber ich postete ja schon mal daß ich vermute, daß Selfhtml suboptimal (auch für DAU-Gschichtn wie diese) ist - wurde ja bestritten, es sei superst.
3.) Für die dauernden "permissiondenied in XULElement..."-Gschichtn, die Bugs aus dem 2004er-Jahr darstellen, kann er aber schon was... und daß debuggen halt fad ist, wenn man sich drum alles mit document.write verschandeln muß
4.) Über die ganzen anderen Sinnlosen FF-Gschichtn (zB daß man oft benötigte Funktionen anders formulieren muß als beim IE, zB setSelectionRange(), motz ich eh nicht - man ist ja eh Kummer gewohnt.

Edit:

Informiert dich gefälligst mal, bevor du dich mit JS & Co auseinander setzt,

Das mußt mir zeigen, wie man sich informiert, ohne daß man sich damit auseinander setzt... Denn man muß es nach deiner Lesart ja vorher tun

14.04.2006, 19:29 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Dann ist JS Schrott

das ist es.

aber mach dir nix draus, fuer dein 2. webprojekt hast du dann schon richtig erfahrung gesammelt!

1.) Habe ich schon geschrieben, daß - wenn das beim IE auch so ist - ich mich
korrigiere... Dann ist JS Schrott, net nur der FF

Der FF implementiert JS so, wie es sein soll - ob das nun von Vorteil ist oder nicht, sei dahin gestellt.
Ich selbst versuche jedenfalls, meine Webseiten frei von JS zu halten, viele Anwendungsfälle gibts nicht, in denen das nützlich sein kann.
Ausnahme: AJAX.

2.) Habe ich ja bei der Fehlersuche versucht, mich zu informieren.. und
SELFHTML gewälzt.
Dort findet man schnell getAttribute() von all... nur steht dabei, daß das nur
der IE kann.
zIndex taucht auch nicht im Quickbar auf (dann hätte ich es gefunden). Aber
ich postete ja schon mal daß ich vermute, daß Selfhtml suboptimal (auch für
DAU-Gschichtn wie diese) ist - wurde ja bestritten, es sei superst.

Dafür hätte auch der DOM-Inspektor gereicht, den dir der FF-Installer bei der Installation anbietet.
Dann hast du eine übersicht sämtlicher JS Klassen, und deren Variablen und Methoden.
Dann hast du eine übersicht aller Variablen, die dir z.b. durch ein #id.style.zur Verfügung stehen. 3.) Für die dauernden "permissiondenied in XULElement..."-Gschichtn, die Bugs aus dem 2004er-Jahr darstellen, kann er aber schon was... und daß debuggen halt fad ist, wenn man sich drum alles mit document.write verschandeln muß Da kann ich nur sagen: Warum verwendest du auch Dinge wie document.write? Deprecated. Normalerweise macht man sowas mit nem P-Tag mit beliebiger ID, und weist eben diesem per .innerHTML Content zu. Über die ganzen anderen Sinnlosen FF-Gschichtn (zB daß man oft benötigte Funktionen anders formulieren muß als beim IE, zB setSelectionRange(), motz ich eh nicht - man ist ja eh Kummer gewohnt. Deine Sicht der Dinge ist schlicht und einfach verdreht. Nicht der FF hat die ungewöhnlichen Eigenschaften, sondern der IE. Der IE ist es, der sich in den meisten fällen eben nicht an vordefinierte Standards hält, und eine Sonderbehandlung braucht. Was ich so lese, ist das deine zweite Web-Applikation. Da ist das verständlich, dass du so reagierst. War bei mir vor Jahren auch nicht anders. Solltest du jedoch diese Arbeit fortsetzen, wirst du über kurz oder lang draufkommen, was man nicht alles feines basteln könnte, wenn nicht der "gute" IE unzulänglichen oder gar keinen Support für diese Features bieten würde. -- DiTech postete: Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen. GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

LOOL.

Also meines Wissens nach ist setSelectionRange() noch nicht in einem Standard.. berichtige mich, falls ich falsch liege. Er macht es also bewußt anders als der IE, der es vorher konnte... /abseits/ aller Standards.

Dom-Inspektor funktioniert bei meinem FF leider auch net sauber... div's mit anderer z-order (auch die "obersten") zeigt er net an beim Anklicken des div-nodes im Tree im Inspector. Aber auch über das motzte ich ja nicht, weil es nicht lebenswichtig ist.

Warum ich document.write verwende ? Weil ich mir was beim debuggen mit einem alert() ausgeben lassen wollte um mir nix zusammenzuhauen - und beim alert() feuert der FF genau besagte XULE-Permission-Gschicht. Das kann's ja wohl net sein - und so einen Shice machen AFAIK weder IE noch Opera noch Safari...

Bisher hatte ich auch wenig JS auf meinen Seiten - nur simple Constraint-Prüfungen damit nicht erst die Datenbank zurückmotzt... Nur jetzt wird's halt ein Ajax-Teil.

LOOL.

Hiermit klinke ich mich aus der Diskussion mit dir aus, für Gespräche auf solchem Niveau ist mir meine Zeit zu schade.

Ich sag nur soviel: Interessanterweise mache ich massiven gebrauch von Ajax in meinen Projekten, und die laufen in jedem Browser einwandfrei, egal ob von IE, Gecko, Opera oder KHTML gerendert.
Liegt vielleicht daran, dass ich mich länger als 2 Tage mit der Thematik beschäftige. Aber nur vielleicht.

Over and out.

--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Wen dem so wäre wie du sagst, würdest du

net Standards bei nicht standardisierten Sachen vorschieben
auf die besagten FF-Bugs eingehen

anstatt einen Möchtegern-Pro raushängen zu lassen.

Ich bestreite nicht deine Kompetenz, ich bestreite aber die [heutige] Korrektheit deiner Vermutung, daß IE der übelste Browser sei...

1.) Mein Snippet war syntaktisch korrekt - nur semantisch falsch. Ein C-Compiler hätte den also /geschluckt/ wie jeder andere Compiler auch... Außer du zeigst mir einen Compiler, der alles (net nur printf) semantisch prüfen kann... Inzwischen hast auch Zeit um erwachsen zu werden.

2.) " Schrott-Code nicht umsetzen." - komisch, außer Dir wußte keiner diese semantische Sheiß-Eigenschaft von JS im Zusammenspiel mit CSS... Wobei mir der Hintergedanke da eh unklar ist. Wenn dem schon so ist - warum gibt's keine JS-QuoteMeta-Funktion ? Kann das dann erst der FF 12.2.1 oder wie wird das aussehen ?

3.) Ich übergebe keinen Variablennamen sondern einen String. Wenn du den Unterschied nicht kennst, wundert es mich nicht, daß du zu deiner Fehleinschätzung von C-Compilern gekommen bist

14.04.2006, 19:38 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Mein Snippet war syntaktisch korrekt - nur semantisch falsch. Ein C-Compiler
hätte den also /geschluckt/ wie jeder andere Compiler auch... Außer du zeigst
mir einen Compiler, der alles (net nur printf) semantisch prüfen kann...
Inzwischen hast auch Zeit um erwachsen zu werden.

Meine Worte bezogen sich nicht auf dein Code-Snippet, sondern auf deine Art, wie du an Probleme rangehst.
Anstatt dich zu informieren, redest du Software schlecht, obwohl du eindeutig im Unrecht liegst. Und selbst jetzt, wo dies bewiesen ist, setzt du deine herablassenden Worte fort.

Schrott-Code nicht umsetzen." - komisch, außer Dir wußte keiner diese
semantische Sheiß-Eigenschaft von JS im Zusammenspiel mit CSS... Wobei mir der
Hintergedanke da eh unklar ist. Wenn dem schon so ist - warum gibt's keine
JS-QuoteMeta-Funktion ? Kann das dann erst der FF 12.2.1 oder wie wird das
aussehen ?

Wie viele aktive HTML/CSS Profis gibts außer mir im Forum?
Und nochmals...diese "Sheiß" Eigenschaft ist eine Eigenschaft von JS, nicht vom FF. Es ist also falsch, dem die Schuld in die Schuhe zu schieben.

ch übergebe keinen Variablennamen sondern einen String. Wenn du den
Unterschied nicht kennst, wundert es mich nicht, daß du zu deiner
Fehleinschätzung von C-Compilern gekommen bist

Letztendlich versuchst du durch deinen String, auf eine nicht-existierende Variable zuzugreifen, und nur das zählt.

Als Fazit kann ich nur sagen: Ich habe deutlich genug bewiesen, dass du mit deinen Anschuldigungen dem FF gegenüber im Unrecht liegst, da kannst du dich nicht rausreden.
Schnucki.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Ad "anstatt dich zu informieren"...
Nachdem ich das Problem zIndex mal soweit reduzieren konnte, daß ich eben obiges Snippet produzieren konnte, googelte ich danach... Und siehe da, das taucht auf vielen Foren als "BUG" auf...

Im Unrecht war ich definitiv bei dieser Geschichte - sobald das aber klar war (vor deinem Großkotz-Posting) korrigierte ich meine Anschuldigung von FF ist Schrott auf JS ist Schrott

Bei nochmaliger Überlegung würde ich dazu tendieren, daß sowohl JS als auch CSS Schrott sind... Begrüdundung: Aus JS-Seite könnte man das wohl locker wie ein Synonym betrachten - bzw. es fehlt zumindest die QuoteMeta-Funktion (Oder von mir aus ein Äquivalent zu host-Order-2-Network-Order wie bei Socket-Programmierung). Aus CSS-Seite weil man dort ebenfalls die "-"-Styles als deprecated einstufen könnte (weil sie eben Probs in der Anwendung bringen) und parallel dazu zB ein style='zIndex:10' erlauben. Wäre wohl auch kein Aufwand.

Was aber bestehen bleibt sind die XULElement-Bugs... und die nerven. Wenn ein alert() statt einer Ausgabe nur soetwas triggert, ist es IMHO übelst.

Es ist also falsch, dem die Schuld in die Schuhe zu schieben.

Ich habe es schon einmal versucht klarzumachen, aber manche sind ja leseresistent. Also nochmals: Sobald mir das klar wurde - vor deinem Posting - habe ich meine Anschuldigung korrigiert...

Letztendlich versuchst du durch deinen String, auf eine nicht-existierende Variable zuzugreifen, und nur das zählt.

Leider ganz falsch - aber ja nicht das erste falsche von Dir. Du hast behauptet, daß ein C-Compiler solche Fehler abfangen könnte. Wenn du eine Funktion aufrufst, die einen char * erwartet und du ein char * lieferst - dann kann das ein C-Compiler net abfangen... Denn es ist syntaktisch korrekt. Auch wenn dann eine Variable falsch referenziert wird - bleibt's dasselbe. Vielleicht solltest mal nach der Unterscheidung Syntax/Semantik googeln und Dir dabei überlegen (oder auch nachgoogeln), was Compiler so alles prüfen...

Als Fazit kann ich nur sagen: Ich habe deutlich genug bewiesen, dass du mit deinen Anschuldigungen

Wieso Plural ? Wieso überhaupt was ?
Ein anderer Poster hat mich - vor Dir - darauf hingewiesen, daß mein Style-Vorwurf net paßt... Meine anderen Vorwürfe (zB daß FF [noch] nicht standardisierte Sachen absichtlich anders löst als der IE sowie der XULElement-Bug) hast ja nicht einmal erwähnt.

Wieso FF Funktionen, die der Marktführer entwickelt hat und die noch nicht standardisiert sind extra anders benamst, ist mir ja bis heute unklar....

Also nochmals: Sobald mir das klar wurde - vor deinem Posting - habe ich meine Anschuldigung korrigiert...

Du hast dein Eröffnungsposting mindestens 2mal editiert, aber dort ist noch immer vom "schwulen FF" die Rede - von zurückgezogener Anschuldigung kann also (dort) keine Rede sein!

Noch was: Wenn du erst mal vom JS Programmieren runter bist und dich mit CSS basiertem Design beschäftigst wirst du sehr schnell merken, dass der IE der Scheiß Browser ist und nicht der FF.

Yup, das "schwul" habe ich stehen lassen - weil es mich anf*ckt, daß nicht einmal ein alert() immer klappt... Scheinbar gibt es eine Korrelation mit per Javascript generierten Auswahlen (via setSelectionRange) - kann das sein ?

Ad Browser:
Für den IE habe ich es vor Ewigkeiten hinbekommen, daß ein JS-Teil ein XSL-Stylesheet austauscht und so die vorhandenen Daten einfach umsortiert wurden. Beim Mozilla damals (oder war es noch Netscape?!?) scheiterte ich daran (was nicht bedeuten soll, daß es unmöglich ist).

Als nur wenig-webcoder kam es mir früher so vor, als wäre IE ein rechter Schrott - und als ob es heute andersrum sei... Täusche ich mich ?

Schon mal probiert diesen "komplizierten" string-Ausdruck VOR der alert-Ausgabe in eine Variable zu speichern und dann diese rauszu-alert'en?

Oder: den Style für dieses Element in einer STYLE Deklaration zu definieren?
(Und dann evt. noch einen Stylesheet Changer/Switcher zu verwenden?)

Meiner Erfahrung nach ist - wenn - dann der IE "schwul". Es gibt bei beiden Browsern Probleme, aber die vom IE überwiegen meiner Meinung nach eindeutig!

Natürlich habe ich auch ein

var xxx = ...meinAusdruck...;
alert(xxx);

probiert - so konnte ich ja einschränken, daß es gerade am alert() hängt.
Das Ersetzen des alert() durch anderes (document.write oder createTextNode an ein debugDIV) klappten ja auch... Es war echt der alert().

Style Changen wäre jedenfalls eine Variante...

15.04.2006, 21:46 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Kannst hier vielleicht so einen Beispiel-String posten, der zu diesem (XUL) Fehler führt?

Ich werde es versuchen...
Wird aber schwierig, weil ich die genaue Ursache noch nicht identifiziert habe. Als "exotisches" verwende ich in dem Teil den XMLHttpRequest und es geht um die "Antwort"-Routine.

Die beginnt mit einer Autocompletion... Und wenn ich dann was ausgeben wollte, klappte es oft nicht.

Blöd am FF ist ja auch, daß er die ganzen asynchronen Teile net in seiner JavascriptConsole anzeigt sondern einfach mit der Ausführung abbricht.

EDIT:
Ich vermute, daß es dieser Bug ist:
https://bugzilla.mozilla.org/show_bug.cgi?id=236791 vom 2004-03-08(!) - und noch immer als NEW markiert.

Sorry, aber einen Bug über 2 Jahre net fixen... Finde ich schlimm...

15.04.2006, 22:22 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Ich vermute, daß es dieser Bug ist:
https://bugzilla.mozilla.org/show_bug.cgi?id=236791 vom 2004-03-08(!) - und
noch immer als NEW markiert.

Also mit meinem 1.5.0.1 Firefox pfunziwunzifunztatatut das einwandfrei!

Sorry, aber einen Bug über 2 Jahre net fixen... Finde ich schlimm...

HAHAHA...Sorry, aber da kann ich doch nur lachen! Der IE6 ist locker 4,5 Jahre alt, die SP2 Version, auch schon fast 2 Jahre! Und da werden nur mehr Security-Probleme gefixt, sodass es noch immer MASSIG Darstellungs-Probleme gibt beim IE6. Da brauchst dich nun wirklich nicht beschweren!

Lass ihn doch, wenn er stur bleiben will.
Gibt da nen netten Spruch:
Erwarte keinen Dank, wenn du jemanden geholfen hast - du hast seine schwächen aufgedeckt.

Als nächstes beschwert er sich dann, weil er mittels xmlHttpRequest keine Seiten anderer Domains per JS laden, und in seine Seite integrieren kann.
Da gibts schließlich auch einen NS :: PermissionDenied Error vom FF

so ein Schrott aber auch.

Für ihn wäre es das beste, gleich sämtliche sicherheits-relevanten Teile aus dem Browser raus zu kicken.
Dann funktioniert sein falscher Code so wie er will, und man braucht sich nicht mehr mit Dingen wie Berechtigungen lokaler/entfernter Websites oder der Implementierung gewisser Funktionen mit JS+CSS rumschlagen.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

16.04.2006, 09:28 Uhr - Editiert von Dr. Watson, alte Version: hier

Ok, das Problem mit dem FF wurde identifiziert:
Ein .focus() klappt in einer onblur-Methode net... Das hat genau nix mit buggy-Code meinerseits oder Sicherheitsproblemen zu tun, wie du in deiner gnadenlosen Inkompetenz behaupten willst - sondern ist schlicht klumpat im FF.

Auch die Gschichtln, daß man bei Input-Boxen durch ein setzen von "autocomplete=off" an Fehlermeldungen vorbeikommt ist ja wohl nur grotesk schlecht - außer du behauptest nun, daß mein Code buggy sei, weil ich eben nicht "autocomplete=off" angegeben habe... Dann poste aber bitte den passenden w3c-Standard dazu

Danke, jetzt ist klar dass du gar keine Ahnung hast.

Ein focus() kann niemals in einer onblur() Methode funktionieren, weil das ganze keinen Sinn ergeben würde.
onblur() wird ausgelöst, sobald ein Element seinen Fokus verliert. Wo liegt denn da der Sinn, dem Element gleich wieder den Fokus zu geben? Da würde der Benutzer nie mehr etwas anderes als *dieses* Eingabefeld selektieren können.

Der FF kann also - zum wiederholten Male - nichts dafür, es ist schlicht und einfach auf deine Inkompetenz zurückzuführen.

Bei dieser Autocomplete Geschichte ist es das selbe.
Du verwendest eine Funktion, die in keinem Standard definiert wurde - und daher _in jedem Browser anders implementiert sein kann_.

Opera, der sich noch ein Stück mehr an die Standards hält, als der FF, implementiert diese Funktion gar nicht erst, warum auch?
Damit Entwickler wie du weiterhin mit ihrem ~~Schrott~~ Code das WWW versauen?
Da muss ich dich enttäuschen, die Zeiten in denen jeder dahergelaufene Anfänger Web -Seiten und -Anwendungen entwickelt, neigen sich dem Ende.

Mit dem Web 2.0 steigt die Anzahl der Cross-Browser kompatiblen, sauber geschriebenen Seiten wieder extrem an, die Anzahl der fähigen Entwickler steigt ebenfalls.

Am Ende kann ich nur anmerken, dass du mit deinen Problemen alleine dastehen wirst, die Gründe dafür hab ich bereits mehrfach genannt.
Ändere deine Denkweise bezüglich der Web-Entwicklung - der IE hat damals den veralteten Netscape abgelöst, und heute wiederrum wird der IE, weil veraltet, abgelöst.
Sieh das ein, oder geh mit diesem sinkenden Schiff unter - du hast die Wahl.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Ein focus() kann niemals in einer onblur() Methode funktionieren, weil das ganze keinen Sinn ergeben würde.
onblur() wird ausgelöst, sobald ein Element seinen Fokus verliert. Wo liegt denn da der Sinn, dem Element gleich wieder den Fokus zu geben? Da würde der Benutzer nie mehr etwas anderes als *dieses* Eingabefeld selektieren können.

Sorry, aber nur weil du keinen Sinn erkennst bedeutet es nicht zwangsläufig, daß es ihn nicht gibt. Ich habe Fälle, wo es Sinn macht:
zB im Rahmen einer inputbox, die Werte nach einem festen Muster erwartet - zB einer SAP-Nummer. Die muß 10stellig und numerisch sein. Wenn einer so ein Feld verläßt und etwas eingegeben hat, das nicht paßt (zB Aplhas drinnen oder falsche Stellenanzahl) - dann macht eine Warnung mit alert() und ein zurückpositionieren Sinn. Das Ganze wäre auch korrekt nach SRP.

Definitiv ist es nach den Standards nicht untersagt, IE kann's auch, einen Browser, der glaubt, vermuten zu müssen was mehr Sinn macht brauche ich nicht... Übrigens ist der Bug in der Bugzilla-DB vom FF auch als BUG geführt. Anders als Du sind sich die Entwickler also bewußt, daß es ein Bug ist.

Ad Autocomplete verwenden:
Ich /will/ mich um das Autocomplete vom FF net kümmern - nur muß man es - siehe auch hier:
http://www.thescripts.com/forum/thread145213.html
Ist einfach noch ein BUG vom FF, an dem man als Workaround nur vorbeikommt, wenn man "autocomplete=off" in der Inputbox dazuschreibt (bis dato kannte ich das Attribut nicht einmal

).
Wenn du Webseiten-developer wärst, wüßtest du das sicher... oder du verwendest nie ne Inputbox

EDIT: Um es verständicher zu machen..
Ich will im Prinzip nix anderes an Funktionalität, als du in einer normalen Combo-Listbox hast, bei der du nur vorhandene Werte eingeben kannst. In der GUI-Programmierung ist es - mit gutem Grund - üblich, daß die Listbox dann selbst checkt, ob der eingegebene Wert "richtig" ist - und ansonsten eine Warnbox präsentiert und den Focus wieder auf die Listbox setzt. Das ist die äquivalente Aufgabenstellung: Beim Verlassen (onblur()) checken, ob es ein gültiger Wert ist - und notfalls eine Warnbox ausgeben und wieder den focus zurück auf das Element setzen. Sooo utopisch kommt mir mein Wunsch also net vor, in einer onblur-Methode einen focus zu setzen. Einen Workaround habe ich eh gefunden: Am Ende der onblur-methode ein "window.setTimeout(machwas(),50);" - und in machwas eben die Meldung ausgeben und den Focus setzen. Dann rennt das focus aus Browsersicht eben net im onblur und klappt. Trotz allem ist und bleibt es ein Workaround.

18.04.2006, 09:11 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Sorry, aber nur weil du keinen Sinn erkennst bedeutet es nicht zwangsläufig,
daß es ihn nicht gibt. Ich habe Fälle, wo es Sinn macht:
zB im Rahmen einer inputbox, die Werte nach einem festen Muster erwartet - zB
einer SAP-Nummer. Die muß 10stellig und numerisch sein. Wenn einer so ein Feld
verläßt und etwas eingegeben hat, das nicht paßt (zB Aplhas drinnen oder
falsche Stellenanzahl) - dann macht eine Warnung mit alert() und ein
zurückpositionieren Sinn. Das Ganze wäre auch korrekt nach SRP.

Sowas muss man ganz und gar nicht per onblur lösen, da brauchts keine 2 Minuten, bis ein Workaround geschrieben ist.

Ad Autocomplete verwenden:
Ich /will/ mich um das Autocomplete vom FF net kümmern - nur muß man es -
siehe auch hier:
http://www.thescripts.com/forum/thread145213.html
Ist einfach noch ein BUG vom FF, an dem man als Workaround nur vorbeikommt,
wenn man "autocomplete=off" in der Inputbox dazuschreibt (bis dato kannte ich
das Attribut nicht einmal ).
Wenn du W

Gut, dann nehme ich das mit dem Bug an dieser Stelle hin.
Trotzdem - was du zu erreichen versuchst, nämlich den FF schlecht zu reden, kannst du mit diesem Argument auch nicht; für jeden Bug den der FF hat, hat der IE 5 weitere Bugs, mit dem Unterschied, dass diese schon seit Jahren nicht behoben wurden, und es auch im IE7 nicht der Fall sein wird.

Aber wie gesagt - da kommt man eben erst drauf, wenn man länger als 5 Tage als (Web-) Entwickler tätig ist.

Wenn du Webseiten-developer wärst, wüßtest du das sicher... oder du verwendest
nie ne Inputbox

Interessant, dann übe ich den Beruf wohl im Traum aus.

Im Unterschied zu dir, halte ich viele Richtlinien ein, und damit ist nicht (nur) mein Coding-Stil gemeint, sondern Allgemeine Richtlinien, an die man sich bei einer modernen Webseite hält.

Und da steht unter Usability schon mal ein großer Punkt - nämlich auf JS zu verzichten, wo man nur kann, und den User keinesfalls durch Alert-Boxen zu nerven, wenn er eine Fehleingabe getätigt hat.
Dafür reicht es, das Input-Feld per CSS in einem Farbton zu hinterlegen, damit der Benutzer weiß: da stimmt was nicht.
Sollte er dann dennoch versuchen, das Formular abzusenden, kann man immer noch ne Fehlermeldung ausgeben, und das muss auch kein alert() sein.

Solche Richtlinien gibts zu hunderten, und du verstößt bereits massiv gegen einige.
Natürlich könnte ich dir nun Links zu Seiten nennen, die das pro/contra deiner Methoden ausführlich erklären, aber warum sollte ich das?
Nur weil es dir offentsichtlich an Qualifikation fehlt?

[Nachtrag]
Und wenn du schon die Funkionalität einer Listbox willst, warum nimmst du dann ein INPUT Element? Sehr seltsame Verhaltensweise.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Das mit farblich hinterlegen stimmt wirklich oft und hilft oft viel - nur net hier.

Denn abhängig von der Eingabe will ich eben einen Request an die DB auslösen, die die Detaildaten holt und den Benutzer weiterführt...

Stell dir im einfachsten Fall eine App vor, wo der Benutzer eine Rechnungsnummer eingibt. Natürlich kann ich statt dem Alert das Teil farblich anders hinterlegen - weiterarbeiten kann er trotzdem nicht. Es macht also IMHO Sinn, ihm den Cursor gleich in das falsche Feld zu positionieren...

Natürlich ist der Workaround schnell gebaut, nur ist das unter FF stressig. Alle Fehler, die in der Beantwortung des AJAX-Requests auftreten, zeigt er in seiner Javascript-Console net an - er bricht einfach ab. Das ist /mühsam/. Genauso das Workaround-Bauen.... Jeder für sich kostet Zeit.

EDIT:
Den Alert wollte ich also größtenteils zum Debuggen - weil die Javascript-Console eben bei Fehlern als Antwort auf XMLHttpRequests nix anzeigt. Öde, daß der dann auch net geht.

Das mit dem focus() ist lästig - so wie wohl noch vieles, über daß ich beim FF stolpern werde. Derzeit habe ich ein Problem, daß ein focus() auf Inputboxen zwar klappt, aber manchmal kein blinkender Cursor in der inputbox ist. Eingeben kann man trotzdem. Eine Ahnung, wie ich an dem Bug vorbeikomme ?

18.04.2006, 10:13 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Das mit farblich hinterlegen stimmt wirklich oft und hilft oft viel - nur net
hier.

Denn abhängig von der Eingabe will ich eben einen Request an die DB auslösen,
die die Detaildaten holt und den Benutzer weiterführt...

Auch da gibts weitaus benutzerfreundlichere Methoden...als Beispiel nenn ich dir mal, wie es bei einer meiner Anwendungen läuft:

Sobald der Benutzer Daten ins Feld eingibt, wird dieses mit jedem Tasten druck überprüft, und solange Daten drinstehen, die nicht korrekt sind, bleibt das Feld rot hinterlegt.
Sind jetzt genug/die richtigen Zeichen im Feld, wird es grün bzw. gar nicht hinterlegt, gesperrt, und dann der Request ausgeführt.
Sobald der Request beendet ist, wird das Feld wieder entsperrt.

Auf die Art braucht der Benutzer noch nicht mal das Formular abzusenden, geht also noch komfortabler.

Natürlich ist der Workaround schnell gebaut, nur ist das unter FF stressig.
Alle Fehler, die in der Beantwortung des AJAX-Requests auftreten, zeigt er in
seiner Javascript-Console net an - er bricht einfach ab. Das ist /mühsam/.
Genauso das Workaround-Bauen.... Jeder für sich kostet Zeit.

Aus Sicht des Entwicklers ist es mühsam, jedoch hätte es keinen sinn, diese Fehler in der Console anzuzeigen.
Die Funktion xmlHttpRequest selbst liefert genug Fehlercodes zurück, die du selbst auswerten, und dem Anwender präsentieren musst.
Oder kennst du einen Anwender, der ständig die JS-Console offen hat, um sich über seine Falscheingaben zu informieren?

Ans Workaround bauen wirst du dich wohl oder übel gewöhnen müssen.
Und das sag ich nicht als Verteidung für den FF, sondern das gilt für alle Browser - Probleme mit der Kompatibilität wirst du immer haben, egal mit welchem Browser, und das ist es, was diesen Job mühsam und zeitaufwendig macht.
Mit der Zeit lernst du die Fehler der Browser kennen und zu umgehen; ganz besonders wird dir das auffallen, wenn du intensiven gebrauch von CSS machst.

Dann musst du plötzlich gewisse Hacks einsetzen, damit die Seiten im IE überhaupt angezeigt werden - als Stichwort nenn ich dir nur mal "Peekaboo".
Sobald du 2 Ebenen hast, die verschachtelt sind und ein floating aufweisen, zeigt der IE auf der halben Website plötzlich keinen Text mehr an.
Einfach so, ohne Sinn, der Text ist einfach weg, nach einem F5 ist er plötzlich wieder da - bis zum Nächsten Klick auf der Seite.
Gibt man dann ein line-height: im CSS-Body an, wird der Text plötzlich angezeigt - aber komm da erst mal drauf.

Der Bug im Box Model des IE dürfte fast jedem bekannt sein - der IE berechnet Ebenen mit Margin/Padding/Border/Width/Height/ falsch, zeigt alles zu groß an.
Um das zu umgehen, müssen wirklich übelste Hacks verwendet werden - da muss mich absichtlich falschen CSS-Attributen im Speicher des IE herumgepfuscht werden, damit alles klappt.

Den Alert wollte ich also größtenteils zum Debuggen - weil die
Javascript-Console eben bei Fehlern als Antwort auf XMLHttpRequests nix
anzeigt. Öde, daß der dann auch net geht.

Zum Debuggen hab ich immer noch alert() verwendet, und es gab bisher keine Situation, wo das nicht funktioniert hat. Du hast da also irgendwo den "Hund drin".

Das mit dem focus() ist lästig - so wie wohl noch vieles, über daß ich beim FF
stolpern werde. Derzeit habe ich ein Problem, daß ein focus() auf Inputboxen
zwar klappt, aber manchmal kein blinkender Cursor in der inputbox ist.
Eingeben kann man trotzdem. Eine Ahnung, wie ich an dem Bug vorbeikomme ?

Wie im vorvorigen Absatz erwähnt - da wirst du noch über so manches bei jedem Browser stolpern.
Den von dir erwähnten Bug kenne ich nicht - aber nachdem du eine veraltete Version verwendest, hats nicht viel Sinn, darüber zu diskutieren.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Sobald der Benutzer Daten ins Feld eingibt, wird dieses mit jedem Tasten druck überprüft, und solange Daten drinstehen, die nicht korrekt sind, bleibt das Feld rot hinterlegt.
Sind jetzt genug/die richtigen Zeichen im Feld, wird es grün bzw. gar nicht hinterlegt, gesperrt, und dann der Request ausgeführt.
Sobald der Request beendet ist, wird das Feld wieder entsperrt.

Das klappt bei mir nicht - weil ich eben Anfangs noch nicht wissen kann, ob der Text gültig ist.
Das ganze Klumpat ist eben ein AJAX-Teil. Er befüllt eine Input-Box, und sobald er sie verläßt, löse ich einen XMLHttpRequest aus. Die Antwort kann nun eine XML-Datei mit weiterführenden Detaildaten sein (Im Beispiel mit der Rechnungsnummer wären es die Positionen) - oder eben eine Antwort a la "Diese Rechnungsnummer gibt es nicht".

In einem anderen Thread habe ich die Problemlösung diskutiert. Es geht darum, daß es ein paar 1000 Gruppen gibt - und zu jeder Gruppe bis zu 100 Mitglieder.

Der Benutzer tippt also die Gruppe ein - und bekommt eine per InputBox und einem Div mit href's zusammengebaute "Quasi-Comboselectbox". Mein erster Ansatz war, die paar 1000 Gruppen (zwischen 2k und 9k) einfach bei onLoad per AJAX zu holen. das Problem dabei ist, daß der DB-Server die Antwort in ein 8-10 msec fertig hatte, der Client aber doch recht beschäftigt war. Ich habe es nicht weiter verfolgt, aber ich habe den Verdacht, daß das durchparsen von ein paar Tausend XML-Tags Zeitintensiv unter Javascript ist (ich loopte durch den Array, den ich per o.responseXML erhalten habe und fetchte mir die Attribute raus).

Daher habe ich es eben so umgebaut, daß nichts vorher geladen wird - und jedes Verlassen eine Query auslöst. Das klappt bei ISDN in rund 1/4 sek bei ungecachten Daten - scheint mir also zumutbar. Problem war eben nur, daß ich erst nach vollständiger Eingabe die Prüfung machen kann...

Formular-absenden entfällt bei mir - jedes Verlassen der Feldes löst neue Aktionen aus und führt so den Benutzer. Dein Weg ist sicher eleganter - scheiterte aber an den Datenmengen zum Vorfetchen.

Die Funktion xmlHttpRequest selbst liefert genug Fehlercodes zurück, die du selbst auswerten, und dem Anwender präsentieren musst.

Da hast mich nicht verstanden.
Es geht darum, daß ich meine eigenen JS-Code-Fehler debuggen will.
Angenommen, ich schreibe in meiner Function versehentlich

 mach_was();
 o.setAttributte('visible','false') ;
 mach_was_anderes();

Normalerweise erhältst du einen Fehler in der JS-Console, daß o keine Methode "AtribuTTe" kennt - und du kannst debuggen.

Bei den Funktionen, die als Antwort eines XMLHttpRequests aufgerufen werden, kommt aber keine Ausgabe in der Console - stattdessen bricht er lautlos hier ab und mach_was_anderes wird nicht durchgeführt... Es geht mir also nicht um die Fehler, die man per XMLHttpRequest auswerten kann, wenn der Request selbst nicht klappte - sondern um das debuggen der aufgerufenen Funktion.

Zum Debuggen hab ich immer noch alert() verwendet, und es gab bisher keine Situation, wo das nicht funktioniert hat. Du hast da also irgendwo den "Hund drin".

Definitiv gab es auf meiner Seite das Problem. Statt der Alertbox konnte ich einen XULElement-error lesen (mit genau der alert-Zeile) und es kam eben keine Alertbox. Kein Witz.

Abschließend: Eine Website so zu designen, daß sie nur auf den allerneuesten Browsern rennt, halte ich für mutig. Ich gehe mit dir wohl eh einer Meinung, daß JS nur unobstrusive verwendet werden sollte und es nur den Behaviour-Layer darstellen soll (zumindest habe ich das aus deinen Postings rausgelesen). Bei AJAX spielt's das aber leider nicht - denn IMHO ist AJAX genau die ReferenzDesignverletzung sondern spielt genau andersrum.

Das klappt bei mir nicht - weil ich eben Anfangs noch nicht wissen kann, ob
der Text gültig ist.
Das ganze Klumpat ist eben ein AJAX-Teil. Er befüllt eine Input-Box, und
sobald er sie verläßt, löse ich einen XMLHttpRequest aus. Die Antwort kann nun
eine XML-Datei mit weiterführenden Detaildaten sein (Im Beispiel mit der
Rechnungsnummer wären es die Positionen) - oder eben eine Antwort a la "Diese
Rechnungsnummer gibt es nicht".

Dann sende den Request halt an den Server - der liefert dann einen Wert zurück.
Ist der Wert 0, war dein Request ungültig, wenn er > 0 ist, also Daten beinhaltet, lass deine Applikation weiter ausführen.

Daher habe ich es eben so umgebaut, daß nichts vorher geladen wird - und jedes
Verlassen eine Query auslöst. Das klappt bei ISDN in rund 1/4 sek bei
ungecachten Daten - scheint mir also zumutbar. Problem war eben nur, daß ich
erst nach vollständiger Eingabe die Prüfung machen kann...

Dein Problem versteh ich.
Hast du weitere Anhaltspunkte z.b. eine fixe länge aller Strings?
Notfalls erstell halt nen Button neben dem Input-Feld, der den Request genau dann ausführt, wenn der User mit seiner Eingabe fertig ist.
Oder führe den Request automatisch aus, sobald sagen wir mal 5sek nach der letzen User-Eingabe verstrichen sind.
Das läuft z.b. in der Gebrauchtwagenbörse der BMW Group Austria so, und als User finde ich das ganz praktisch, dass meine Such praktisch on-the-fly ausgeführt wird, ohne dass ich zuerst sämtliche Felder ausfüllen muss.

Bei den Funktionen, die als Antwort eines XMLHttpRequests aufgerufen werden,
kommt aber keine Ausgabe in der Console - stattdessen bricht er lautlos hier
ab und mach_was_anderes wird nicht durchgeführt... Es geht mir also nicht um
die Fehler, die man per XMLHttpRequest auswerten kann, wenn der Request selbst
nicht klappte - sondern um das debuggen der aufgerufenen Funktion.

Dann liegts wirklich an deiner Version.
Ich entwickle momentan ne Anwendung, die intensiven Gebrauch von Ajax macht, und wenn bei mir im Code, der vom Request geliefert wird ein JS-Fehler auftaucht, erscheint eine Warnung in der Console.
Eben noch mal extra für dich getestet...

Definitiv gab es auf meiner Seite das Problem. Statt der Alertbox konnte ich
einen XULElement-error lesen (mit genau der alert-Zeile) und es kam eben keine
Alertbox. Kein Witz.

Wie gesagt, den Fehler hatte ich noch nie. Hab allerdings auch Ajax-Bezogen nie was mit FF 1.0.x gemacht.
XUL-Error klingt aber insofern nicht gut, weil er mit deiner Anwendung eigentlich nix zu tun hat. XUL ist die Sprache, in der der FF selbst "geformt" ist, sofern du keinen XUL Code einsetzt, wüsste ich nicht, warum diesbezüglich bei der Fehler auftreten.

Abschließend: Eine Website so zu designen, daß sie nur auf den allerneuesten
Browsern rennt, halte ich für mutig. Ich gehe mit dir wohl eh einer Meinung,
daß JS nur unobstrusive verwendet werden sollte und es nur den Behaviour-Layer
darstellen soll (zumindest habe ich das aus deinen Postings rausgelesen). Bei
AJAX spielt's das aber leider nicht - denn IMHO ist AJAX genau die
ReferenzDesignverletzung sondern spielt genau andersrum.

Siehst du absolut richtig.
Auf einer nicht-ajax Seite sollte JS nur Optional sein - nehmen wir z.b. ein Registrierungs-Formular her.
User, die JS aktiviert haben, werden schon vor dem absenden der Form Benachrichtigt, dass ein Feld nicht ausgefüllt wurde.
User ohne JS werden erst benachrichtigt, wenn das File schon zum Server gesendet und geparst wurde.
Somit wird niemand ausgeschlossen, und User mit JS haben eben einen Komfort-Vorteil.

Bei einer Ajax-lastigen Seite setzt man JS Quasi *TRÖT*, da ist klar, dass man intensiven Gebrauch von JS macht.
Da muss man sich aber auch im vorhinein bewusst sein, dass Leute ohne JS ganz einfach Pech gehabt haben.
Was aber je nach Einsatzzweck akzeptabel sein kann.

Trotzdem gibts Dinge, die man dem User antut - wie z.b. alert()-Boxen, die den Fokus auf sich ziehen, Modal sind, und den User aus seiner Konzentration herausreißen.
Stattdessen würde ich eine schicke DIV-Box basteln, die den User freundlich darauf hinweist, das der eingegebene Text Müll ist. Sieht dann grafisch auch noch ansprechender aus, als eine alert()-Box.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Dann sende den Request halt an den Server - der liefert dann einen Wert zurück.
Ist der Wert 0, war dein Request ungültig, wenn er > 0 ist, also Daten beinhaltet, lass deine Applikation weiter ausführen.

Genau das wollte ich ja machen

Gruppen haben eine gewisse Syntax - und sie müssen vorhanden sein.
beim onblur wollte ich die Syntax checken - und ihn sofort zurückspringen lassen, wenn sie nicht paßt (weil es hier Null sinn macht, wenn er woanders weitergeht, wenn die "zentrale" Gruppe schon net paßt).

Zusätzlich wird - wenn die Gruppe syntaktisch paßt - eben der Request ausgelöst.

Zurück zum Rechnungsnummernbeispiel:
Wenn die Rechnungsnummer Buchstaben enthält oder zB weniger als 4 Stellen hat, könnte ich sofort zurückspringen lassen. Wenn sie nur Ziffern enthält, könnte ich den Request auslösen.

In jedem Fall soll eine Info an den Benutzer erfolgen, wenn sie nicht paßte (ob das ne Alertbox oder ein Div oder sonst was ist, sei mal dahingestellt) - und der Cursor zurückpositioniert werden. Ich finde also ein focus() in einem blur()-Event net zwingend falsch... Und den XULElement-Fehler definitiv einen Bug.

Mir ist auch klar, daß XUL aus dem Gecko-Eck kommt - und daher wohl /alle/ Browser davon betroffen sind, die auf Gecko setzen... Keine Ahnung, was Nautilus und andere "Exoten" so verwenden... Scheint aber blöd durchzuschlagen. Ich hoffe mal, daß es aber nur die FF-Anwendugn von Gecko ist...
Nachdem man aber auf FF net verzichten kann, muß ich da halt wohl durch. Ein setTimeout mit 50ms klappte ja als Lösung, wobei ich mir nicht sicher bin, ob 50ms eine gute Wahl war oder nur zufällig klappte... Was ist die kleinste ms-Zahl, die garantiert reicht um das Teil garantiert außerhalb der blur()-Funktion anstoßen zu lassen, wenn man von wirklich alten Rechnern (Pentium1, 128MB Ram mit Win2K) ausgehen muß ???

Gruppen haben eine gewisse Syntax - und sie müssen vorhanden sein.
beim onblur wollte ich die Syntax checken - und ihn sofort zurückspringen
lassen, wenn sie nicht paßt (weil es hier Null sinn macht, wenn er woanders
weitergeht, wenn die "zentrale" Gruppe schon net paßt).

Gut, dann erklär das mal den FF-Entwicklern.
Habs eben lokal getestet, und das verhalten is bei v1.5 wie von dir beschrieben.

und daher wohl /alle/ Browser davon betroffen sind, die auf Gecko setzen...
Keine Ahnung, was Nautilus und andere "Exoten" so verwenden... Scheint aber
blöd durchzuschlagen. Ich hoffe mal, daß es aber nur die FF-Anwendugn von
Gecko ist...

Das muss nicht sein...du kannst z.b. ne Windows-Anwendung schreiben, und den FF dort als ActiveX Control einfügen.
Die Windows-Anwendung beinhaltet dann keine Spur von XUL, der Fehler sollte also nicht auftreten - sofern er wirklich mit dem Browser selbst zu tun hat, nicht mit der Engine.

Nachdem man aber auf FF net verzichten kann, muß ich da halt wohl durch. Ein
setTimeout mit 50ms klappte ja als Lösung, wobei ich mir nicht sicher bin, ob
50ms eine gute Wahl war oder nur zufällig klappte... Was ist die kleinste
ms-Zahl, die garantiert reicht um das Teil garantiert außerhalb der
blur()-Funktion anstoßen zu lassen, wenn man von wirklich alten Rechnern
(Pentium1, 128MB Ram mit Win2K) ausgehen muß ???

Die Lösung ist zwar unsauber, aber wenn sonst nix hilft...
Und ja, 50ms werden ausreichen...glaub kaum dass der User es in 50ms schafft, das Feld zu wechseln und eine neue Eingabe zu tätigen...
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Das mit farblich hinterlegen stimmt wirklich oft und hilft oft viel - nur net
hier.

Denn abhängig von der Eingabe will ich eben einen Request an die DB auslösen,
die die Detaildaten holt und den Benutzer weiterführt...

Natürlich ist der Workaround schnell gebaut, nur ist das unter FF stressig.
Alle Fehler, die in der Beantwortung des AJAX-Requests auftreten, zeigt er in
seiner Javascript-Console net an - er bricht einfach ab. Das ist /mühsam/.
Genauso das Workaround-Bauen.... Jeder für sich kostet Zeit.

Aus Sicht des Entwicklers ist es mühsam, jedoch hätte es keinen sinn, diese Fehler in der Console anzuzeigen.
Die Funktion xmlHttpRequest selbst liefert genug Fehlercodes zurück, die du selbst auswerten, und dem Anwender präsentieren musst.
Oder kennst du einen Anwender, der ständig die JS-Console offen hat, um sich über seine Falscheingaben zu informieren?

Ans Workaround bauen wirst du dich wohl oder übel gewöhnen müssen.
Und das sag ich nicht als Verteidung für den FF, sondern das gilt für alle Browser - Probleme mit der Kompatibilität wirst du immer haben, egal mit welchem Browser, und das ist es, was diesen Job mühsam und zeitaufwendig macht.
Mit der Zeit lernst du die Fehler der Browser kennen und zu umgehen; ganz besonders wird dir das auffallen, wenn du intensiven gebrauch von CSS machst.

Dann musst du plötzlich gewisse Hacks einsetzen, damit die Seiten im IE überhaupt angezeigt werden - als Stichwort nenn ich dir nur mal "Peekaboo".
Sobald du 2 Ebenen hast, die verschachtelt sind und ein floating aufweisen, zeigt der IE auf der halben Website plötzlich keinen Text mehr an.
Einfach so, ohne Sinn, der Text ist einfach weg, nach einem F5 ist er plötzlich wieder da - bis zum Nächsten Klick auf der Seite.
Gibt man dann ein line-height: im CSS-Body an, wird der Text plötzlich angezeigt - aber komm da erst mal drauf.

Der Bug im Box Model des IE dürfte fast jedem bekannt sein - der IE berechnet Ebenen mit Margin/Padding/Border/Width/Height/ falsch, zeigt alles zu groß an.
Um das zu umgehen, müssen wirklich übelste Hacks verwendet werden - da muss mit absichtlich falschen CSS-Attributen im Speicher des IE herumgepfuscht werden, damit alles klappt.

Den Alert wollte ich also größtenteils zum Debuggen - weil die
Javascript-Console eben bei Fehlern als Antwort auf XMLHttpRequests nix
anzeigt. Öde, daß der dann auch net geht.

Zum Debuggen hab ich immer noch alert() verwendet, und es gab bisher keine Situation, wo das nicht funktioniert hat. Du hast da also irgendwo den "Hund drin".

Das mit dem focus() ist lästig - so wie wohl noch vieles, über daß ich beim FF
stolpern werde. Derzeit habe ich ein Problem, daß ein focus() auf Inputboxen
zwar klappt, aber manchmal kein blinkender Cursor in der inputbox ist.
Eingeben kann man trotzdem. Eine Ahnung, wie ich an dem Bug vorbeikomme ?

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

18.04.2006, 10:57 Uhr - Editiert von Dr. Watson, alte Version: hier

Wenn einer so ein Feld verläßt und etwas eingegeben hat, das nicht paßt (zB Aplhas drinnen oder falsche Stellenanzahl) - dann macht eine Warnung mit
alert() und ein zurückpositionieren Sinn.

Wenn dein Prüfungs-JavaScript mit "return false;" endet, brauchst ja nicht erneut zu fokusieren!? Oder hab ich da was falsch verstanden?

Ich glaube schon...
Das return false() verwendet man meines Wissens ja bei onSubmit - nur habe ich ja keinen solchen

Kann natürlich sein, daß ich was falsch verstehe

So weit ich das mitbekommen hab, verwendest Du doch "onblur".
Und dieses solltest Du doch via "return false" verhindern können - also das Verlassen des Elementes.

Oder so .. *ggg

Echt ? Kannte ich nicht - muß ich testen... danke !

Also ich verwende den 1.0.4 - und er wirft den Fehler...
Hast du deine Javascript-Console überprüft ? Bei mir findest genau dann die XULElement-Gschicht drinnen... (genau beim "Example to reproduce focus() exception on firefox 0.8"-Teil).

Dann ist dir gar nicht mehr zu helfen - entweder du verwendest die neueste Version, oder du lässt es gleich bleiben.

Da könnte ich auch hergehen, und den IE 5.5 verwenden, und mich dann aufregen, warum so mancher Bug auftritt.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Besagter FF kommt mit der Debian 3 Sarge nach dem letzten Stable-Update... Ist also - laut Debian-Typen - die letzte stabile... und bei weitem net so alt wie IE 5,5

Seit dem IE 5.5 hat sich aber bezüglich der Engine des IE nix mehr getan - viele Sicherheitstrelevante Bugfixes, aber an den Features hat sich nix geändert.

[edit]
Debian geht eben extrem auf Nummer sicher - in der Praxis ist auch v1.5.0.2 stabil, nur eben weniger erprobt.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

18.04.2006, 10:09 Uhr - Editiert von Dr. Watson, alte Version: hier

Wobei mehr als die aktuellste Debian-Updates darf man dem Benutzer auch nicht zumuten, oder ?
Außerdem bleibt die Frage, ob wirklich in der JS-Console keine Fehlermeldungen bei der 1.5er auftauchen...

Wenn ja, könnte es noch andere Seiteneffekte geben.

Ich "mute" den FF meiner Verwandschaft, und das sind allesamt nur "Benutzer", schon seit Jahren zu, und da gibts einfach keine Probleme.
Nur bei den Updates bin ich manuell dahinter, die werden erst eingespielt, sobald sie sich bei mir selbst bewärt haben.

Außerdem bleibt die Frage, ob wirklich in der JS-Console keine Fehlermeldungen
bei der 1.5er auftauchen...

Versuchs doch einfach...einerseits reitest du auf Bugs rum, andererseits verwendest du ne Version, die sicher ein Jahr auf dem Buckel hat.
Da fehlt irgendwie die Grundlage für deine Argumentationen.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Meine Argumentationsgrundlage ist die aktuellsten /stable/ Updates der Debian3 sarge.
Nachdem ich als "normaler" Benutzer nicht wissen kann, ob FF1.5 stable ist - und die Debianer, die sich mit solchen Fragen auseinandersetzen, ihn eben nicht als stable sondern erst in der testing erwähnen, gehe ich mal davon aus, daß die Leute, die sich mit solchen Themen auskennen, ihn eben als nicht-stable Beurteilen.

Nachdem ich meinen Rechner als Arbeitsgerät brauche und keine unstabile SW einsetzen will, bleibt mir vorübergehend - so wie wohl vielen - der 1.5er noch verwehrt.

Außerdem muß man ja davon ausgehen, daß viele Debianer ähnlich denken - und nur stable verwenden. Nachdem die auch meine Seiten nutzen können sollen, muß ich mich eben noch mit einem 1-jahr-alten Browser rumspielen... Wobei er AFAKIK ja damit jünger als der IE ist - und den berücksichtigt man ja auch.

Wenn du schon so viel Wert darauf legst, eine "/stable/" Software zu verwenden - welche IE Version verwendest du dann unter Windows?
Welche Version ist da "stable"? Lachhaft.

Die Software gehört in deinem Fall natürlich so entwickelt, dass sie mit älteren Browsern fehlerfrei läuft, aber die Benutzer eines aktuellen Browsers in den Genuss der Features kommen, die ihr Browser bietet.
Wird in deinem Fall nichts weltbewegendes sein, aber bei deinem focus()-cursor-gschichtl wäre das der Fall.

Was ich persönlich interessant finde, ist das es Debian User wie dich gibt, die mit den OpenSource-Prinzipien nicht klarkommen.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

stable != fehlerfrei. Stable bedeutet nix anderes als "Alle uns bekannten Fehler, die uns wichtig genug erschienen sind, haben wir gefixt".

Wenn du es mit Windows/IE/Office/... vergleichen willst:
Ich würde sagen, daß ein aktuelles Windows mit aktuellen Updates der stable entspricht.

Bei Windows gibt's ausreichend Hotfixes zu holen - die zT neue Funktionalität bieten oder versprochene Funktionalität erst erlauben - das würde ich als Äquivalent zum testing sehen. Die IE7-Beta würde ich als äquivalent zu unstable oder experimental sehen.

Nur stellst du damit den FF 1.5 hin, als wäre er der IE7, um deinen Vergleich dafür herzunehmen.

Denkst du im FF 1.5.x wurden weniger Fehler gefixt als im 1.0.x?

Von daher ist die Version 1.5 immer die "bessere" Version.

Ich fasse stable so auf, dass die Version erprobt, und weitestgehend fehlerfrei ist.
Aus der Sicht ist der 1.5er natürlich anfälliger, weil er mehr Funktionen und damit zwangsweise auch Fehler enthält.

Nur wie weit muss die Entwicklung voranschreiten, bis wieder eine Version als stable deklariert wird?
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Das sollen die Leute entscheiden, die jeweils Experten auf dem Gebiet sind (mir kann man Thema Browser echt viel erzählen, da ich nur einfachste Seiten (eben DB-Frontends)) baue - und HTML/CSS/JS/... eben nur ein winzig kleines Nebengschichtl meiner Projekte darstellt.

Und genau da treten Distris auf den Plan - bei Debian eben gut getrennt. Wenn die Maintainer vom FF meinen, daß der 1.5er nach testing und nicht stable gehört (immerhin nicht mehr unstable oder experimental) - dann muß ich ihnen vertrauen, da der schlechteste FF-Maintainer 100%ig mehr KnowHow Thema FF hat als ich.

Und genauso verfahren /echt/ viele.
Ich würde also davon ausgehen, daß viele in deinen Augen "altertümliche" Browser draußen sind - wobei aus meiner Sicht ein 1 Jahr alter Browser topmodern ist

Darin liegt ja auch der Sinn, dass User sich nicht mit der Software auskönnen müssen, um zu wissen, was stable ist, und was nicht.

Beim FF 1.5 liegts allerdings nicht an etwaigen Bugs, sondern daran, dass er sich noch nicht lange genug in der Praxis bewährt hat.

Tatsache ist, dass der Versionssprung einige Änderungen und Bugfixes gebracht hat, würde mich nicht wundern, wenn sich dadurch eines deiner Probleme erübrigen würde.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Dumme Frage: warum verwendest nicht die neueste 1.5.0.2 Version???

http://forum.geizhals.at/t412635,3345186.html#3345186

Dr. Watson, MEIN BEIFALL!!! Ob der "Gepeinigte" die Wahrheit verträgt?

LOOOL.

Dann kannst du mir sicher bei dem oben erwähnten XULElement-Bug helfen...
Aaalso: Nachdem der FF ja angeblich net ein verbuggter Schrott ist - und du dazu Beifall spendest - wo genau ist in den Standards beschrieben, daß ein Browser bei Aufruf von alert() so etwas feuern soll ?

Kein Wunder, daß 90% der User auf IE schwören...

lustig.

gerade diese woche habe ich ein paar stunden ver*PIEP*, um herauszufinden dass der IE bei

document.forms[id].bezeichnung.value

als id einen string der mit "3-" beginnt nicht erkennt. im FF kein problem.

herauszufinden ob das an der fuehrenden zahl, an der kombination zahl- (buchstabe- geht) liegt, oder ob's nur eine aversion gegen die 3 ist, hat mich dann nicht mehr interessiert.

Wie bitte, der IE soll eine Variable erkennen, die mit einer Zahl beginnt? Der war gut.

Statt

document.forms[id].bezeichnung.value

solltest du übrigens

document.getElementById("bezeichnung").value

verwenden, darauf weißt dich normalerweise auch die JS-Konsole vom FF hin.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

eine Variable erkennen, die mit einer Zahl beginnt

nein, der in der variable gespeicherte string beginnt mit einer zahl. die variable heisst "id":

id = '3-something';

document.forms[id].bezeichnung.value
document.getElementById("bezeichnung").value

das macht nicht dasselbe.

ich habe mehrere formulare auf der seite. klar, ich koennte das so umschreiben dass ich die formulare ignoriere und die ids der elemente ensprechend bezeichne, aber ich will's nicht umhacken.

ich habe mir lieber damit geholfen meinen formular-ids im template "bla" voranzustellen...

nein, der in der variable gespeicherte string beginnt mit einer zahl. die
variable heisst "id":

id = '3-something';

Aus sich des HTML-Tags: Ja.
Auf JS-Ebene würde es jedoch ein document.forms[3-something].bezeichnung.value sein.
_Kein_ document.forms['3-something'].bezeichnung.value.

Und da JS keine Bindestriche in Variablennamen unterstützt, und sicher auch keine Variablen, die mit einer Zahl beginnen, kann/darf das eigentlich gar nicht funktionieren.
Da scheint der FF gutmütig zu sein.

das macht nicht dasselbe.

ich habe mehrere formulare auf der seite. klar, ich koennte das so umschreiben
dass ich die formulare ignoriere und die ids der elemente ensprechend
bezeichne, aber ich will's nicht umhacken.

Daran hatte ich nicht gedacht, sorry.
Würde mich aber wundern, wenn es dafür keine bessere Möglichkeit gäbe...mal schaun.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Aus sich des HTML-Tags: Ja.
Auf JS-Ebene würde es jedoch ein document.forms[3-something].bezeichnung.value
sein. _Kein_ document.forms['3-something'].bezeichnung.value.

das stimmt natuerlich - gewissermassen.

bindestriche an sich sind kein problem - sie funktionieren im IE und FF. ob sie das eigentlich duerften oder nicht ist mir dann eher egal... nach mehrjaehrigem webentwickeln hat sich bei mir der grundsatz spezifikation und praktische implementation sind wie traum und wirklichkeit schon zu stark ins hirn gebrannt.

das problem ist ja auch nicht waehrend der entwicklung aufgetreten, sondern die applikation ist schon mehr als ein jahr lang problemlos bei uns in verwendung. diese woche war's dann anscheinend so weit, dass jemand das erste mal ein haendlerkuerzel mit einer zahl am beginn erfunden hat...

nach mehrjaehrigem webentwickeln hat sich bei mir der grundsatz spezifikation
und praktische implementation sind wie traum und wirklichkeit schon zu stark
ins hirn gebrannt.

Jep, davon können wir wohl beide ein Lied singen...
Wie schön könnte die Welt sein, wenn man sich sicher sein könnte, dass die Features in jedem Browser gleich implementiert sind.

Wenigstens einer hier der Versteht, mit welchen Problemen man sich als Web-Entwickler rumärgern muss...
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

blabla - anstatt hier blöd rumzumotzen und den noch dümmeren IE oder Opera zu vertreten würd ich mal mithelfen das Firefox noch besser wird !

Fehleraufzeigen hilft auch mit, oder ?

klar, aber doch in einer etwas gemässigteren Form ...

wens den BUG schon so lange gibt, gibts mindestens so lange eine lösung von jemanden dafür also was regst dich so auf

Am schönsten ist WIEN im Rückspiegel

macht spaß gell

es gibt nur 10 arten von menschen. diejenigen die das binärsystem verstehen, und die die es nicht tun.
FMD

oder was bekommt so ein Opensource-Programmierer für ein Monatsgehalt? eben. Das machen nur die, die keine Arbeit finden- warum wohl?

unsinn.

es gibt alle moeglichen arten von OSS programmierern.

auch welche, die neben einem job in ihrer freizeit OSS programmieren, und auch solche die ganz normal angestellt OSS erzeugen.

Tja, und wenn man die OpenSourceler als Hobbyprogrammierer bezeichnet, sind's auch sauer...

in so mancher selbsternannter professioneller softwareschmiede sitzen leute, auf die die bezeichnung hobbyprogrammierer zweifellos zutraefe.

andererseits programmiert so mancher wirklich hobbymaessig, und ist dabei besser als der eine oder andere "professionelle".

die art der (finanziellen) entlohnung der ersteller ist jedenfalls nur ein sehr bedingt anwendbares mass fuer die qualitaet von software.

hast du es schon mit der Firefox Extension IETab probiert? siehe Link:

https://addons.mozilla.org/firefox/1419/

möglicherweise behebt das dein Problem

einfach nach der Installation des Addons Firefox neustarten und auf der gewünschten Seite einen Rechtsklick machen und den Punkt "Seite in IE Tab anzeigen" auswählen.

Naja 1 Schwalbe macht noch keinen Sommer, so macht 1 Bug noch kein Frickelprodukt draus. Tut mir zwar leid das Du soviel Zeit verloren hast, aber thats life!

Ich könnt jetz aus meiner aktiven MFC-Zeit erzählen wieviel (wertvolle) Zeit ich verloren hab mit dem gefriquel der MFc-Fraktion, die Bugs seit 1991 in ihrem Framework drin hat, trotzdem bleibts ein recht stabiles Framework, sowie FF auch ein "anständiger" Browser ist.

"Time flies like an arrow. Fruit flies like a banana." - Groucho Marx

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung