Statistik Webdesign
gepostet vor 17 Jahre, 7 Monate von kudi
Bitte nicht ernst nehmen
gepostet vor 17 Jahre, 7 Monate von Drezil
komm was für einen bart hat das bild schon ..
gepostet vor 17 Jahre, 7 Monate von Störti
Das Schlimme ist aber, dass dieses Bild Recht hat. Ich weiss nicht, wie das jetzt mit dem neuen IE wird, hab mir den noch nich installiert, aber programmiert mal ne Website (inkl. Javascript) nach den normalen Standards und nutzt während der Entwicklung nur den FF. Und wenn die Seite im FF fehlerfrei läuft, DANN startet sie mal im IE. Die nächsten Wochen sind gelaufen und du wirst so frustriert sein, dass du alle Freunde vergrauelst...
Ich schiebe den Zeitpunkt, wo ich meine neue Beta-Version zum ersten Mal im IE starte auch schon seit Wochen vor mir her, weil ich meine Motivation dann schon förmlich in Sekunden davon fliegen sehe...
Ich hoffe ehrlich, dass der IE7 Final diesen Monat das ändert...
Ich schiebe den Zeitpunkt, wo ich meine neue Beta-Version zum ersten Mal im IE starte auch schon seit Wochen vor mir her, weil ich meine Motivation dann schon förmlich in Sekunden davon fliegen sehe...
Ich hoffe ehrlich, dass der IE7 Final diesen Monat das ändert...
gepostet vor 17 Jahre, 7 Monate von exe
Deswegen habe ich immer parallel einen IE, und wenns nur auf dem Zweitrechner ist, offen während ich das Layout schreibe. Wenn ich es nur im Firefox mache und es danach im IE anschau ist das Layout in selbigem vollkommen zerschossen. Was im Klartext bedeutet das ich nochmal ganz von vorne anfangen kann alle Bugs zu identifizieren und auszumerzen.
Deswegen begleite ich die Entwicklung immer mit dem IE. So ist sichergestellt das inkompatibilitäten sofort erkannt werden und nicht, wenn das Layout im Firefox in seinem vollen Glanz erstrahlt, die große Depression kommt wenn man es im IE anschaut ...
Und wenn man sich einmal die Probleme merkt ist es irgendwann auch kein Hexenwerk mehr die Anzahl der großen Probleme von vornerein gegen Null zu trimmen. Letzendlich sind es immer die gleichen Probleme die die verhauenen Darstellungen im IE verursachen.
Deswegen begleite ich die Entwicklung immer mit dem IE. So ist sichergestellt das inkompatibilitäten sofort erkannt werden und nicht, wenn das Layout im Firefox in seinem vollen Glanz erstrahlt, die große Depression kommt wenn man es im IE anschaut ...
Und wenn man sich einmal die Probleme merkt ist es irgendwann auch kein Hexenwerk mehr die Anzahl der großen Probleme von vornerein gegen Null zu trimmen. Letzendlich sind es immer die gleichen Probleme die die verhauenen Darstellungen im IE verursachen.
gepostet vor 17 Jahre, 7 Monate von Klaus
Editiert, weil das Diagramm vorher aufgrund von Hotlinking geblockt wurde.
> Bitte nicht ernst nehmen
Ich kann der Statistik aufgrund von eigenen Erfahrungen nur zustimmen. Zwar habe ich die Zeit nicht genau gemessen und die relationen sind etwas unrealistitsch, aber es werden alle Bereiche beim Designen und auch entwickeln mit JS abgedeckt.
> Bitte nicht ernst nehmen
Ich kann der Statistik aufgrund von eigenen Erfahrungen nur zustimmen. Zwar habe ich die Zeit nicht genau gemessen und die relationen sind etwas unrealistitsch, aber es werden alle Bereiche beim Designen und auch entwickeln mit JS abgedeckt.
gepostet vor 17 Jahre, 7 Monate von Drezil
also der ie ist standardkompatibel .. seit der version 5 ist sogar das box-layout korrekt ..
das problem ist eher, WENN er in den quirks-mode springt, die ie4-zicken als fallback benutzt.
ich habe selbst mir JS keine probleme. weder beim ie6 - noch beim ff1.5
nur css interpretiert der ie6 nicht so gut. aber das ändert sich nun mit dem ie7 - sofern man ihn in den "standard mode" bekommt ..
das problem ist eher, WENN er in den quirks-mode springt, die ie4-zicken als fallback benutzt.
ich habe selbst mir JS keine probleme. weder beim ie6 - noch beim ff1.5
nur css interpretiert der ie6 nicht so gut. aber das ändert sich nun mit dem ie7 - sofern man ihn in den "standard mode" bekommt ..
gepostet vor 17 Jahre, 7 Monate von Agmemon
Original von Drezil
also der ie ist standardkompatibel..
Mutige Aussage. MS wird nach eigenen Aussagen den ACID2 Test mit IE7 nicht bestehen und legt scheinbar auch keinen hohe Priorität drauf. Und mit der JavaScript Unterstützung sieht es ja auch schlecht aus. Ich bin mal so frei aus einem Artikel über Ajax im aktuellen Linux Magazin zu zitieren:
Die nicht standardkonforme Javascript-Engine des Internet Explorer zwingt Entwickler oft dazu, einen guten Teil des Javascript-Code zweimal zu schreiben
Und wenn man sich anguckt, wie viele CSS-Hacks man für den Internet-Explorer braucht, die zumindest in der IE7 Beta noch nicht behoben waren, würde ich nicht von Standardkompatibilität sprechen.
gepostet vor 17 Jahre, 7 Monate von blum
Original von Agmemon
Die nicht standardkonforme Javascript-Engine des Internet Explorer zwingt Entwickler oft dazu, einen guten Teil des Javascript-Code zweimal zu schreiben
also ich weiss ja nicht, nach welchem standard der verfasser des artikels sein javascript schreibt, aber bis auf die 3 zeilen im ajax-aufruf muss ich keinen code zweimal schreiben.
gepostet vor 17 Jahre, 7 Monate von knalli
Strenggenommen ist der Acid2 auch nicht das Einzig und Wahre.. denn was sagt er bitte tatsächlich aus? Und mal abgesehen davon: Ist der Firefox in Version 2 ein "per se" schlechter Browser? Nein, aber..?!
Die Statistik ist für mich ein bisschen zu.. hm.. polemisch, halt witzig gemeint. Wenn man heute w3c einhält, muss man für den IE6 verschiedenes umbauen, ja das stimmt. Hätte man das vor Jahren gemacht (wo zeitgleich IE6 "moderner" war), dann hätte man mit w3c in bestimmten Dingen alt ausgesehen. Die Unterschiede waren damals im Browserbattle WIRKLICH gravierend.. heute kann ich darüber echt nur lachen..
Echte Probleme kriegt man eigentlich doch nur noch in verschiedenen Versionen von XHTML-Support (fast nix), CSS-Versionen (nur gravierend, wenn man auf die absurde Idee kommt, Level 2 in IE6 verwenden will), oder verschiedene DOM-Versionen (schon mal Level 2, auch nicht so verbreitet bei speziellen Speizien). Entweder man baut sein Framework (Größenordnung bei Javascript, wo das nennenswert unterschiedlich wird) für verschiedene JS-Versionen (IE, Ecma) oder lässt es halt.
Die Statistik ist für mich ein bisschen zu.. hm.. polemisch, halt witzig gemeint. Wenn man heute w3c einhält, muss man für den IE6 verschiedenes umbauen, ja das stimmt. Hätte man das vor Jahren gemacht (wo zeitgleich IE6 "moderner" war), dann hätte man mit w3c in bestimmten Dingen alt ausgesehen. Die Unterschiede waren damals im Browserbattle WIRKLICH gravierend.. heute kann ich darüber echt nur lachen..
Echte Probleme kriegt man eigentlich doch nur noch in verschiedenen Versionen von XHTML-Support (fast nix), CSS-Versionen (nur gravierend, wenn man auf die absurde Idee kommt, Level 2 in IE6 verwenden will), oder verschiedene DOM-Versionen (schon mal Level 2, auch nicht so verbreitet bei speziellen Speizien). Entweder man baut sein Framework (Größenordnung bei Javascript, wo das nennenswert unterschiedlich wird) für verschiedene JS-Versionen (IE, Ecma) oder lässt es halt.
gepostet vor 17 Jahre, 7 Monate von Progralixx
Also ich habe extreme Probleme, wenn ich JavaScript für den FF und den IE kompatibel machen will.
Ich arbeite oft mit Containern die als Tooltipps, Baumenü oder Kartennavigation "aufpoppen" und sich dort befinden, wo der Spieler hinklickt. Da ist es schon eine wahre Tortour die Container so anzuordnen, dass sie sich beim IE auch dort befinden, wo der FF sie hinsetzt. Vorallem bei meinem flexiblen Layout ist das keine so einfache Sache.
Im Moment schreibe ich ein Skript, welches dem Spieler erlaubt seine Waffen aus seinem Lager per "drag 'n drop" seinen Soldaten zuweisen zu können. Da gibts dann natürlich auch wieder unterschiede zwischen den Browsern, da hat man manchmal gar kein Bock mehr, weiterzumachen
Ich arbeite oft mit Containern die als Tooltipps, Baumenü oder Kartennavigation "aufpoppen" und sich dort befinden, wo der Spieler hinklickt. Da ist es schon eine wahre Tortour die Container so anzuordnen, dass sie sich beim IE auch dort befinden, wo der FF sie hinsetzt. Vorallem bei meinem flexiblen Layout ist das keine so einfache Sache.
Im Moment schreibe ich ein Skript, welches dem Spieler erlaubt seine Waffen aus seinem Lager per "drag 'n drop" seinen Soldaten zuweisen zu können. Da gibts dann natürlich auch wieder unterschiede zwischen den Browsern, da hat man manchmal gar kein Bock mehr, weiterzumachen
gepostet vor 17 Jahre, 7 Monate von knalli
leicht ot: Erfindest du das Rad neu, oder funktioniert script.aculo.us' Drag-and-Drop mit deiner Sache nicht?
gepostet vor 17 Jahre, 7 Monate von Kampfhoernchen
Hehe, lustige Rekation
gepostet vor 17 Jahre, 7 Monate von Progralixx
[ot]
Hmm script.aculo.us ist nicht so das, was ich suche. Mein Skript soll ein bisschen spezieller sein. Während man die Waffe dragt, sollen auch die Felder markiert sein, in die man die Waffe droppen kann (droppen?), ich will auch infos über die aktuelle Waffe in anderen Containern anzeigen lassen usw. Das eigentliche Drag 'n Drop ist da nicht so das Problem.
[/ot]
Hmm script.aculo.us ist nicht so das, was ich suche. Mein Skript soll ein bisschen spezieller sein. Während man die Waffe dragt, sollen auch die Felder markiert sein, in die man die Waffe droppen kann (droppen?), ich will auch infos über die aktuelle Waffe in anderen Containern anzeigen lassen usw. Das eigentliche Drag 'n Drop ist da nicht so das Problem.
[/ot]
gepostet vor 17 Jahre, 7 Monate von exe
Original von Progralixx
[ot]
Hmm script.aculo.us ist nicht so das, was ich suche. Mein Skript soll ein bisschen spezieller sein. Während man die Waffe dragt, sollen auch die Felder markiert sein, in die man die Waffe droppen kann (droppen?), ich will auch infos über die aktuelle Waffe in anderen Containern anzeigen lassen usw. Das eigentliche Drag 'n Drop ist da nicht so das Problem.
[/ot]
Kann script.aculo.us schon. Nicht per default aber du kannst die Draggables mit Observern erweitern um eigene Aktion onDrag, onDrop usw. auszuführen (wie das aktivieren anderer Elemente). script.aculo.us ist imho weniger eine ready-to-run Lösung als ein großer Baukasten um eigene Effekte zusammenzustellen.
gepostet vor 17 Jahre, 7 Monate von Klaus
Das ist richtig, jetzt sind wir aber wieder dem Abschweifen verfallen.
Also ich fasse mal zusammen. Das JS-Programmieren ist einfacher geworden, da weniger Fallbacks für verschiedene Browser benötigt werden als früher. Es gibt einfach eine große Überschneidung der Befehle.
Webdesign mit CSS hat aber das Problem, dass die Browser die meisten Befehle kennen, aber im Detail leicht unterschiedlich interpretieren. Die Arbeit wird dadurch frickeliger als es früher mit verschachtelten verschachtelten verschachtelten Tabellen üblich war.
Also ich fasse mal zusammen. Das JS-Programmieren ist einfacher geworden, da weniger Fallbacks für verschiedene Browser benötigt werden als früher. Es gibt einfach eine große Überschneidung der Befehle.
Webdesign mit CSS hat aber das Problem, dass die Browser die meisten Befehle kennen, aber im Detail leicht unterschiedlich interpretieren. Die Arbeit wird dadurch frickeliger als es früher mit verschachtelten verschachtelten verschachtelten Tabellen üblich war.
gepostet vor 17 Jahre, 7 Monate von knalli
Ja.. aus dem Grund verwenden viele auch noch *** Tabellen (das ist ein so böses Wort, das darf man gar nicht zusammenschreiben ), dass sie damit "keine Probleme" haben. Sieht man zuhauf, kurzer Klick auf Outline bestätigt mich dann immer. Interessanterweise sind vor allem die großen Seiten, also diejenigen mit großem Nutzerspektrum so aufgebaut.
Klar, gibt immer wieder nette Ausnahmen - aber das Leben einfach machen ist eben immer noch am einfachsten.
Klar, gibt immer wieder nette Ausnahmen - aber das Leben einfach machen ist eben immer noch am einfachsten.