nicht angemeldet
wie will Microsoft das aufholen?
hi
ich stelle immer wieder auf's neue fest, dass Abstand des MSIE bei CSS zu Mozilla hier gigantisch ist und frage mich, ob und wie man das aufholen will - oder erklärt man HTML in der nächsten Version gleich komplett für "depricated" und denkt sich irgendwas sinnloses und primär inkompatibles neues aus? Das ganze Problem einfach totzuschweigen geht wohl nur so lange, wie Mozilla keine größere Verbreitung hat und keine Websites oder Zeitschriften anfangen auf diese Features hinzuweisen.
Insbesondere die Möglichkeiten, die sich durch :hover ergeben können, haben die meisten Browserhersteller noch gar nicht erkannt - schon ein "a:hover span{color:red;} um nur einen Teil des Links umzufärben scheitert oftmals, während Mozilla auf diese Art sogar komplette DHTML-Menüs ermöglicht (ich hab' das mal auf mozilla.linuxfaqs.de umgesetzt). Auch ist Mozilla (neben der 3er Generation von Konqueror), der die mit CSS3 eingeführten (allerdings noch nicht 100%ig abgesegneten) Konstruktionen, mit denen man beispielsweise alle Links, die eine marlto-Addresse haben speziell gestalten kann: "a[href^="mailto"]:before{content:"E-Mail: "}". Selbst das :before verstehen schon nur Mozilla und Opera...
Ob und wie Microsoft diesen Rückstand aufholen kann, weiß ich nicht - und Mozilla ist mit dem Implementieren noch nicht am Ende, die CSS2-Spezifikation hat mit counter: (in Opera schon umgesetzt) und text-shadow: noch zwei sehr nette Features, ebenso ist der Selector-teil von CSS3 fast fertig und bietet vieles, was die Gestaltung von Websites deutlich vereinfacht - td:nth-child(2n){background-color:green;}, wenn jede zweite Tabellenspalte grün sein soll sei hier einmal exemplarisch genannt und das W3C steht nicht still, es sind viele weitere Funktionen in den Working Drafts zu finden, die in Mozilla oftmals schon mit -moz-<name> implementiert sind (box-sizing, border-radius, opacity, key-equivalent um nur einige zu nennen).
Bekanntlich ist auch PNG im MSIE weit hinter dem zurück, was Opera und Mozilla ermöglichen, auch hier scheint Microsoft den Standard _komplett_ verschlafen zu haben! Offensichtlich hat man sich auf dem gewonnen geglaubten "Browserkrieg" ausgerüht und so die durchaus innovativen Versionen 3 (erste CSS-Ansätze), 4 (DHTML, position:absolute) und 5 (DOM, XML) nicht mehr konsequent weitergedacht.
Grüße aus Bleckede
Kai
-
Hallo Kai,
wieso denn aufholen? Mozilla wird doch eh der künftige Standardbrowser mit 95% Marktanteil (die anderen 5% werden sich Opera und Konquerer teilen). Warum sollte also MS für seinen Minderheitsbrowser dann noch die Einhaltung irgendwelche Standards erzwingen???
Grüße aus Würzburg
Julian -
Hallo Kai,
ich stelle immer wieder auf's neue fest, dass Abstand des MSIE bei CSS zu Mozilla hier gigantisch ist und frage mich, ob und wie man das aufholen will
Wenn man den MS IE 1.0 gekannt hat und weiss, wie weit Netscape damals schon war, dann weiss man, dass Microsoft noch ganz andere Strecken in kuerzester Zeit aufholen kann. Das sollte nicht das Problem sein. Das Problem ist eher:
- inwieweit ist MS an den neuesten Details der W3C-Standards ueberhaupt interessiert?
- und inwieweit ist das Gros der Web-Entwickler und der Web-User ausserhalb solcher feinen Kreise wie hier an solchen Details interessiert?
Beispiel DHTML: macht eigentlich erst mit DOM-Standard richtig Sinn und Spass. Aber lernen die Leute das ueberhaupt noch? Oder greifen sie nicht vielmehr laengst alle zu Flash, wenn sie irgendein animiertes Menue brauchen? So jedenfalls kommt es mir vor, wenn ich mal viel auf kommerziellen Websites unterwegs bin.
Das ganze Problem einfach totzuschweigen geht wohl nur so lange, wie Mozilla keine größere Verbreitung hat und keine Websites oder Zeitschriften anfangen auf diese Features hinzuweisen.
Serioese Zeitschriften weisen durchaus darauf hin, dass Mozilla und auch Opera naeher an den Standards sind. Aber "Standard" ist nicht alles. Mozilla verbratet auch in der 1.0 final immer noch bis zu 50 MB RAM und hat Probleme mit diversen Plugins. Opera hat einen halben statt einen ganzen JavaScript-Interpreter - was nicht gerade sehr professionell ist. Die muessen also durchaus auch noch "aufholen".
es sind viele weitere Funktionen in den Working Drafts zu finden, die in Mozilla oftmals schon mit -moz-<name> implementiert sind (box-sizing, border-radius, opacity, key-equivalent um nur einige zu nennen).
Wenn du so geil bist auf neueste Eigenschaften, Befehle usw., dann guck dich mal auf msdn.microsoft.com um. 970 CSS-Eigenschaften, 200 Event-Handler, Ausverkauf total. Mit dem MS IE kannst du Dinge treiben, davon ahnst du noch nicht mal was. Aber kommt es denn darauf an? Eine Tabelle, bei der jede zweite Zeile gruen ist, ist eine Sache, die man prima auch mit DOM/JavaScript loesen kann, dafuer braucht man kein CSS 3.0 - man sollte einfach auch mal sehen, dass dieser ganze Feature-ismus in den Sprachen allmaehlich an die millionen Knoepfchen japanischer Hifi-Geraete der 80er Jahre erinnert.
Bekanntlich ist auch PNG im MSIE weit hinter dem zurück, was Opera und Mozilla ermöglichen, auch hier scheint Microsoft den Standard _komplett_ verschlafen zu haben! Offensichtlich hat man sich auf dem gewonnen geglaubten "Browserkrieg" ausgerüht und so die durchaus innovativen Versionen 3 (erste CSS-Ansätze), 4 (DHTML, position:absolute) und 5 (DOM, XML) nicht mehr konsequent weitergedacht.
Etwas schlaefrig geworden ist der MS IE in er 6er-Version auf jeden Fall, da gebe ich dir vollkommen Recht. Aber ich glaube, du unterliegst einem Trugschluss, wenn du glaubst, die Masse der Normaluser wuerde massenhaft auf Mozilla umsteigen, wenn man in den Knuddelbrabbelboards nur penetrant genug darauf hinweist, dass sich der Mozilla viel besser an die W3C-Standards haelt. Es interessiert die Leute einfach nicht. Es interessiert nur eine sehr kleine Minderheit - naemlich jene Klientel, die tiefer ins Web Publishing eintaucht und im Grunde richtig mit "Datenverarbeitung" zu tun hat. Dort lernt man die W3C-Standards schnell zu schaetzen. Aber dort braucht man dann nicht unbedingt "latest features". Jedenfalls nicht unbedingt CSS 3.0.
viele Gruesse
Stefan Muenz-
Hallo Stefan,
... wenn du glaubst, die Masse der Normaluser wuerde massenhaft auf Mozilla umsteigen
Vielleicht steigen sie nicht von selbst so einfach um, aber man kann es als Ziel anstreben und versuchen. Klar, es wird kaum einer auf mozilla.org gehen, sich die 10 MB saugen und installieren. Was aber, wenn man langsam aber sicher die Entscheidungsträger dazu bringt in ihrem Bereich Mozilla zu installieren? Was, wenn AOL und t-offline ihre Software mit Mozilla statt IE ausliefern, wenn in Firmen Mozilla als Standard installiert wird (kenne ich auch welche) und auch die lieben Leute der Uni-Rechenzentren den kleinen Drachen lieber sehen als das komische E?
Ich denke, er hat Chancen. Nicht kurzfristig, aber mittel- bis langfristig auf jeden Fall.Grüße aus Würzburg
Julian -
hi
Serioese Zeitschriften weisen durchaus darauf hin, dass Mozilla und auch Opera naeher an den Standards sind. Aber "Standard" ist nicht alles.
es geht aber nicht um das "näher an den Standard", darunbter verstehen die Herren mit dem "kompetenten Halbwissen", dass er weniger eigene Erweiterungen hat (was dann eher noch negativ gesehen wird) und dass er das eine oder andere anders errechnet. Es muss einfach mehr darauf hingewiesen werden, dass mit Mozilla Dinge einfach möglich sind, die in anderen Browsern schwer bis gar nicht unzusetzen sind.
Wenn du so geil bist auf neueste Eigenschaften, Befehle usw., dann guck dich mal auf msdn.microsoft.com um. 970 CSS-Eigenschaften, 200 Event-Handler, Ausverkauf total. Mit dem MS IE kannst du Dinge treiben, davon ahnst du noch nicht mal was.
och, das hält sich eigentlich zumindest bei den CSS-Eigenschaften in Grenzen, die wenigen interessanteren sind übrigens alle für CSS3 vorgesehen (so z.B. writing-mode, nach dem hier ja öfter mal gefragt wird - nur tatsächlich eingesetzt wird es wohl nie, oder?)
Aber ich glaube, du unterliegst einem Trugschluss, wenn du glaubst, die Masse der Normaluser wuerde massenhaft auf Mozilla umsteigen, wenn man in den Knuddelbrabbelboards nur penetrant genug darauf hinweist, dass sich der Mozilla viel besser an die W3C-Standards haelt.
sie werden in dem Moment anfangen zu wandern, wo es Seiten gibt, in denen mit Mozilla mehr blinkt und flackert. Dazu werden Seitengestalter anfangen den in ihren Augen völlig rückständigen MSIE zu verfluchen, wenn er von dem, was man baut kaum etwas auf die Reihe bringt.
Grüße aus Bleckede
Kai
-
Hallo Kai,
sie werden in dem Moment anfangen zu wandern, wo es Seiten gibt, in denen mit Mozilla mehr blinkt und flackert. Dazu werden Seitengestalter anfangen den in ihren Augen völlig rückständigen MSIE zu verfluchen, wenn er von dem, was man baut kaum etwas auf die Reihe bringt.
Das ist sicher richtig. Aber falls es mal so weit kommt: waere es denn wirklich noch ehrenwert, einen blinkenden und flackernden Mozilla zu preisen? *g*
Immerhin ist er ja auf dem richtigen Weg damit, "Features" einzeln ein- ausschaltbar zu machen in den Einstellungen.
Ach - und ein paar Plugins, so wie Java oder Flash - sollte er wirklich schon gleich bei der Installation mitbringen, sonst sind da eher haessliche Flecken an den Stellen, wo es im IE blinkt und flackert. Und ausserdem ein funktionierendes SVG-Plugin, damit sich das endlich auch mal mehr durchsetzt.viele Gruesse
Stefan Muenz-
hi
Das ist sicher richtig. Aber falls es mal so weit kommt: waere es denn wirklich noch ehrenwert, einen blinkenden und flackernden Mozilla zu preisen? *g*
Immerhin ist er ja auf dem richtigen Weg damit, "Features" einzeln ein- ausschaltbar zu machen in den Einstellungen.ja, weil es sehr wichtig ist, den Webfuschern da draußen klar zu machen, dass valide Websites und tolle Effekte eben _kein_ wiederstruch sind, sondern dass HTML-Fehler einzig und allein schlecht sind.
Ach - und ein paar Plugins, so wie Java oder Flash - sollte er wirklich schon gleich bei der Installation mitbringen, sonst sind da eher haessliche Flecken an den Stellen, wo es im IE blinkt und flackert. Und ausserdem ein funktionierendes SVG-Plugin, damit sich das endlich auch mal mehr durchsetzt.
SVG wird er irgendwann native können, ich hoffe allerdings, dass Adobe vorher das Plugin debuggt. Mitgeliefert werden wird bei Mozilla selbst nie ein Plugin - dafür ist Netscape 7 (oder eine beliebige andere Mozilla-Distribution) da.
Grüße aus Bleckede
Kai
-
Hallo,
SVG wird er irgendwann native können, ich hoffe allerdings, dass Adobe vorher das Plugin debuggt.
Bis dahin kann man sich (wie hier schon angedeutet) so behelfen:
http://www.styleassistant.de/tips/tip91.htm.MfG, Thomas
-
Hallo Kai,
ja, weil es sehr wichtig ist, den Webfuschern da draußen klar zu machen, dass valide Websites und tolle Effekte eben _kein_ wiederstruch sind, sondern dass HTML-Fehler einzig und allein schlecht sind.
Ich bin ja selber ein Verfechter davon, dass man lieber DOM-basiertes DHTML und "DXML", z.B. "DSVG" und SMIL benutzen sollte, um all die tollen Sachen zu machen, die man mit Flash macht. Es ist allerdings nicht einfach, diejenigen Leute, die solche kreativen Aufgaben uebernehmen, davon zu ueberzeugen, sich in XML- und Programmiercodes rumzuwaelzen, anstatt auf der Timeline der Flash-Autorensoftware irgendwas zusammenzuklicken. Leute, die solche Seiten ueblicherweise erstellen, sind welche mit der Ausbildung "Screen Designer". Und die lernen dort meist kein oder nur wenig Coding. Die hocken lieber an ihrem 24-Zoll-Bildschirm vor ihrem Mac und arbeiten mit "coolen" Tools. Vom W3C haben die meist noch nie was gehoert.
Was noch dazu kommt ist, dass viele Effekthaschereien kein langes Leben fuehren, weshalb bei denen das wichtigste Argument standardkonformen Arbeitens nicht zieht. Denn waehrend es sich bei grossen, inhaltsorientierten Datenmengen usw. auf die Dauer einfach als Vorteil erweist, den anfaenglichen Mehraufwand standardkonformen Arbeitens auf sich zu nehmen, wird bei mal-eben-Effekten niemand einsehen, doppelt oder viermal so viel Arbeitszeit zu investieren, wie es mit Flash & Co. noetig ist.
Gegen diese Praxisargumente ist leider nur schwer anzukommen. Und wenn, dann nicht mit besseren Browsern, sondern mit Autorensoftware, die noch viel einfacher ist als Flash und als Output lauter sauberes DOM und XML erzeugt ;-)
Mitgeliefert werden wird bei Mozilla selbst nie ein Plugin - dafür ist Netscape 7 (oder eine beliebige andere Mozilla-Distribution) da.
Das mag zwar aus Sicht der "Reinheit" edel sein, verhilft dem Browser aber nicht gerade zu mehr Reputation. Auf jeder zweiten Kommerz-Seite klebt doch heute irgendein Applet. Was aber sollen Normaluser denken, wenn sie statt des Tickers oder der Navigation oder des Chats nur eine dummbloede Leerflaeche mit dem Inhalt "get the plugin" sehen?
viele Gruesse
Stefan Muenz-
Hallo Stefan,
Mitgeliefert werden wird bei Mozilla selbst nie
ein Plugin - dafür ist Netscape 7 (oder eine
beliebige andere Mozilla-Distribution) da.
Das mag zwar aus Sicht der "Reinheit" edel sein,
verhilft dem Browser aber nicht gerade zu mehr
Reputation. Auf jeder zweiten Kommerz-Seite klebt
doch heute irgendein Applet. Was aber sollen
Normaluser denken, wenn sie statt des Tickers oder
der Navigation oder des Chats nur eine dummbloede
Leerflaeche mit dem Inhalt "get the plugin" sehen?ich möchte mich an dieser Stelle der Argumentation von
Kai anschließen.
Die Masse der Normaluser wird "Netscape 7 von der Welt-
firma AOL Time Warner" benutzen (oder überhaupt "den
AOL-Browser 8.0"), nicht aber den "Hackerbrowser
Mozilla", der ja noch dazu "offensichtlich eine Test-
version (1.0)" ist und "womöglich nur unter Linux läuft
und ja ohnehin nicht mit einem kommerziellen Produkt
mithalten kann" und was auch immer. ;-)Ich finde es völlig ausreichend, wenn Netscape 7 die
wesentlichen Plugins mitliefert. Wenn _ich_ auf eine
Seite will, die das braucht, dann nehme ich halt den
Browser mit den vielen Plugins - wenn ich nur lokal
etwas testen will, nehme ich den schlanken Mozilla.Ich sehe keinen Grund dafür, unsere Kunden davon zu
überzeugen, Mozilla zu verwenden. Wenn sie von Netscape
4 auf Netscape 7 umsteigen, bin ich schon zufrieden.Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael
-
-
-
-
-
Wenn du so geil bist auf neueste Eigenschaften, Befehle usw., dann guck dich mal auf msdn.microsoft.com um. 970 CSS-Eigenschaften, 200 Event-Handler, Ausverkauf total.
Das ist ja gerade das, was die IE-Kritiker hier im Forum kritisieren. M$ setzt nach wie vor auf haufenweise proprietäre tags und CSS-Eigenschaften, statt mal die Resourcen dafür einzusetzen, endlich mal so elementare Dinge wie position:fixed zu implementieren.
Eine Tabelle, bei der jede zweite Zeile gruen ist, ist eine Sache, die man prima auch mit DOM/JavaScript loesen kann, dafuer braucht man kein CSS 3.0
Warum 10 Zeilen DOM/JS, wenn ich das in einer Zeile CSS 3 haben kann?
Stefan
-
Hallo Stefan,
Das ist ja gerade das, was die IE-Kritiker hier im Forum kritisieren. M$ setzt nach wie vor auf haufenweise proprietäre tags und CSS-Eigenschaften, statt mal die Resourcen dafür einzusetzen, endlich mal so elementare Dinge wie position:fixed zu implementieren.
Ich hab die 970 CSS-Eigenschaften und die 200 Event-Handler ja nicht als besonders lobenswert erwaehnt, sondern wollte Kai nur mal ein bischen sticheln, weil er so wild auf Features war ;-)
Das mit dem position:fixed beim MS IE ist allerdings wirklich ein Aergernis. Wer einmal damit gearbeitet hat, weiss, wie bedeutend das ist. Koennte fast der Tod der Frames-Technik sein. Umso bloeder, dass es im MS IE bis heute nicht funktioniert.Warum 10 Zeilen DOM/JS, wenn ich das in einer Zeile CSS 3 haben kann?
Ein guter Progger macht das sicherlich in einer einzigen Zeile - ist ja nur eine einfache Style-Zuweisung in Abhaengigkeit einer for-Schleife ;-)
Es ist halt immer so eine Frage, wo man die Grenzen ziehen soll zwischen fertigen Formateigenschaften, die semi-intelligente Funktionen uebernehmen, und Programmierung, die von Haus aus die Boardmittel hat, Inhalte mit intelligenter Funktionalitaet zu versehen. Meiner Ansicht nach wird es einer Sprache wie CSS nicht gut tun, wenn sie mit Features ueberladen wird, die allzuweit ueber reine Formatierung hinausgehen. Ein bischen was davon ist ok, aber wenn es zu viel wird, wird die Sprache irgendwann zur Geheimwissenschaft, was nicht unbedingt im Sinne ihrer Verbreitung ist. Am Beispiel der automatischen Nummerierung sieht man das finde ich recht gut. Die CSS-Syntax dafuer ist wirklich gruselig. Ploetzlich werden da Variablen fuer Counter, Inkrmentierungs- und Reset-Funktionalitaet usw. eingefuehrt, Dinge also, die es sonst in CSS gar nicht gibt, und die typische Programmiersprachenfunktionen sind. Mit DOM-basiertem JavaScript waere eine automatische Nummerierung genauso moeglich, mit dem Unterschied, dass man dort nicht die Syntax erweitern muss.
viele Gruesse
Stefan Muenz-
Moin, Stefan!
Es ist halt immer so eine Frage, wo man die Grenzen ziehen soll zwischen fertigen Formateigenschaften, die semi-intelligente Funktionen uebernehmen, und Programmierung, die von Haus aus die Boardmittel hat, Inhalte mit intelligenter Funktionalitaet zu versehen. Meiner Ansicht nach wird es einer Sprache wie CSS nicht gut tun, wenn sie mit Features ueberladen wird, die allzuweit ueber reine Formatierung hinausgehen.
Was ist an "formatiere jedes zweite Vorkommen von <td> mit xyz" so furchtbar anders als an "formatiere jedes Vorkommen von <td> mit xyz"? Das ist doch wirklich absolut das gleiche Schema.
Ein bischen was davon ist ok, aber wenn es zu viel wird, wird die Sprache irgendwann zur Geheimwissenschaft, was nicht unbedingt im Sinne ihrer Verbreitung ist.
Am Beispiel der automatischen Nummerierung sieht man das finde ich recht gut. Die CSS-Syntax dafuer ist wirklich gruselig. Ploetzlich werden da Variablen fuer Counter, Inkrmentierungs- und Reset-Funktionalitaet usw. eingefuehrt, Dinge also, die es sonst in CSS gar nicht gibt, und die typische Programmiersprachenfunktionen sind.
Nein, das simple Zählen ist keine Programmiersprachenfunktion. Programmiersprachen können Werte vergleichen und in Schleifen springen. Das zeichnet sie aus. Das simple Zählen ist kein Merkmal einer Programmiersprache.
Wenn ich die CSS-Counter mal mit den Möglichkeiten von TeX/LaTeX vergleiche, dann sind diese ziemlich identisch von den Möglichkeiten her. Und TeX steht ebenfalls nicht im Verdacht, eine Programmiersprache zu sein.
Es ist auch von der Aufgabe von CSS her absolut logisch, eine etwas flexiblere Numerierung dort anzusiedeln. Numerierungen bei <ol> sind browsergeneriert. Komplexere Ideen ließen sich dort aber nicht verwirklichen. Und das Konzept der Numerierung jetzt auf alle Elemente auszuweiten ist durchaus erfreulich.
Mit DOM-basiertem JavaScript waere eine automatische Nummerierung genauso moeglich, mit dem Unterschied, dass man dort nicht die Syntax erweitern muss.
Es hat aber den Nachteil, daß Javascript eingeschaltet sein muß. Und der Browser die Javascript-Varianten unterstützen muß. Andernfalls würde der Anzeige etwas fehlen.
Dumm natürlich, daß genau dieses Argument auch für nicht ganz fähige CSS-Browser gilt, die dann ebenfalls einfach die Numerierung weglassen, wenn sie keine Counter kennen - das ist ja aber nicht der anzustrebende Normalfall der Browserhersteller. :)
- Sven Rautenberg
-
Hallo Sven,
Was ist an "formatiere jedes zweite Vorkommen von <td> mit xyz" so furchtbar anders als an "formatiere jedes Vorkommen von <td> mit xyz"? Das ist doch wirklich absolut das gleiche Schema.
Das vielleicht noch. Aber es koennte ja auch ein Rhythmus von vier Farben gewuenscht sein, oder irgendein anderer, komplexerer Algorithmus. Und da muss CSS dann im naechsten Schritt passen, weil man eben nur einen typischen Algorithmus fest implementiert hat, statt die gesamte Ebene algorithmischer Aufgaben auf eine Sprache zu verlagern, die dafuer besser geeignet ist.
Es ist auch von der Aufgabe von CSS her absolut logisch, eine etwas flexiblere Numerierung dort anzusiedeln. Numerierungen bei <ol> sind browsergeneriert. Komplexere Ideen ließen sich dort aber nicht verwirklichen. Und das Konzept der Numerierung jetzt auf alle Elemente auszuweiten ist durchaus erfreulich.
Wobei ich die Funktionalitaet der Nummerierung generell - wenn es ueberhaupt auf die Ebene der Beschreibungssprachen gelegt werden soll - eher in HTML-Attributen implementiert sehen wuerde als in CSS. Denn Nummerierung ist fuer mich eine logische Eigenschaft eines Elements, keine Formateigenschaft. Und logische Eigenschaften gehoeren in Attribute der Markupsprachen. In CSS sollte man dann hoechstens angeben koennen, wie die Nummerierung in Abweichung zum Text dahinter formatiert werden soll.
Sicher kann man LaTeX und andere Sprachen zum Vergleich heranziehen - auch kommerzielle Dateiformate (Word, FrameMaker ...). Aber wenn man nun schon mal so eine schoene saubere Dreiteilung zwischen Strukturierung, Formatierung und Programmierung hat wie bei HTML, CSS und JavaScript - warum sollte man sich da nicht mal mehr Gedanken darueber machen duerfen, welche Funktionalitaet wohin gehoert, und nicht einfach jede Vorgabe von W3C diesbezueglich kritiklos uebernehmen, nur weil es das W3C nun mal so spezifiziert hat?
Es hat aber den Nachteil, daß Javascript eingeschaltet sein muß. Und der Browser die Javascript-Varianten unterstützen muß. Andernfalls würde der Anzeige etwas fehlen.
Lynx schert sich auch um CSS nicht. Irgendwas muss immer verfuegbar sein, um komplexere Funktionalitaeten zu nutzen. Und Kapitelnummerierung mit JS bekommt man fuer alle derzeitigen Browser bereits locker hin, mit CSS hingegen noch lange nicht. Das kann also kein Argument sein.
das ist ja aber nicht der anzustrebende Normalfall der Browserhersteller. :)
OK ;-)
viele Gruesse
Stefan Muenz-
hi
Das vielleicht noch. Aber es koennte ja auch ein Rhythmus von vier Farben gewuenscht sein, oder irgendein anderer, komplexerer Algorithmus.
nein, dass wäre dann td:nth-child(4n)
Grüße aus Bleckede
Kai
-
Hallo Kai
nein, dass wäre dann td:nth-child(4n)
Und wenn ich immer zwei gruene und dann jeweils drei gelbe Zeilen will? Und jede sechste nach diesem Wechsel ausserdem noch himmelblau? Oder wenn ich eine Tabelle mit 10 Zeilen habe, bei der ich bei jeder Spalte eine kontinuierliche Farbabstufung von dunkel links bis hell rechts haben will? Naja, kommt sicher mit CSS 4.0 ;-)
viele Gruesse
Stefan Muenz-
hi
Und wenn ich immer zwei gruene und dann jeweils drei gelbe Zeilen will? Und jede sechste nach diesem Wechsel ausserdem noch himmelblau?
td:nth-child(6n-5){background-color:green;}
td:nth-child(6n-4){background-color:green;}
td:nth-child(6n-3){background-color:yellow;}
td:nth-child(6n-2){background-color:yellow;}
td:nth-child(6n-1){background-color:yellow;}
td:nth-child(6n){background-color:lightblue;} << ich hoffe das jetzt richtig verstanden zu haben ;)Oder wenn ich eine Tabelle mit 10 Zeilen habe, bei der ich bei jeder Spalte eine kontinuierliche Farbabstufung von dunkel links bis hell rechts haben will?
dann eben das ganze da mit 10 und eben 10 abgestuften Farbwerte - nur die Farben zu automatiesierten, wäre eine JS-Aufgabe.
Naja, kommt sicher mit CSS 4.0 ;-)
nö, geht schon
Grüße aus Bleckede
Kai
-
Moin, auch!
Und wenn ich immer zwei gruene und dann jeweils drei gelbe Zeilen will? Und jede sechste nach diesem Wechsel ausserdem noch himmelblau?
td:nth-child(6n-5){background-color:green;}
td:nth-child(6n-4){background-color:green;}
td:nth-child(6n-3){background-color:yellow;}
td:nth-child(6n-2){background-color:yellow;}
td:nth-child(6n-1){background-color:yellow;}
td:nth-child(6n){background-color:lightblue;} << ich hoffe das jetzt richtig verstanden zu haben ;)Beliebig komplexe (und somit praxisfern unrealistische) optische Resultate lassen sich ganz sicher durch serverseitige dynamische Generierung wesentlich besser herstellen, als dazu Javascript und DOM zu bemühen. Hat auch den Vorteil, daß es ohne ebendieses funktioniert. :)
dann eben das ganze da mit 10 und eben 10 abgestuften Farbwerte - nur die Farben zu automatiesierten, wäre eine JS-Aufgabe.
Serverseitig auch kein großes Problem. Die Frage ist ja "nur", was man zu einem gewissen Zeitpunkt an Informationen hat und wie die Ausgabe realisiert sein soll.
Um eine definierte Spanne an Farbe in variabel viele Farbabstufungen zu teilen, ist es sicherlich besser, dieses durch lokale style-Attribute zu realisieren, anstatt sich mit irgendwelchen nth-childs oder konfusen Klassen und ID herumzuschlagen.
- Sven Rautenberg
-
-
Hallo Stefan,
Und wenn ich immer zwei gruene und dann jeweils drei gelbe Zeilen will? Und jede sechste nach diesem Wechsel ausserdem noch himmelblau? Oder wenn ich eine Tabelle mit 10 Zeilen habe, bei der ich bei jeder Spalte eine kontinuierliche Farbabstufung von dunkel links bis hell rechts haben will?
kurze Zwischenfrage, Dein richtiger Name ist nicht zufällig Karl
Fritsch? Wenn ja, dann würde mich auch nicht wundern, warum Du
solch tolle Farbkombination haben willst [1] ;-)Viele Grüße,
Stefan
-
-
-
Hallo Sven,
Hm, das bin ja gar nicht ich. Ich hoffe ich darf trotzdem was zum Thema schreiben. :)
Moin!
Lynx schert sich auch um CSS nicht. Irgendwas muss immer verfuegbar sein, um komplexere Funktionalitaeten zu nutzen.
Das ist IMHO gerade das Tolle an CSS. Da es nur für Formatierung dient können formatlose Browser (also welche, die nur die Struktur wiedergeben (können)) CSS ruhig komplett ignorieren.
Bei Javascript ist das anders - dort sind eine Menge Funktionen implentiert und es kann mitunter schwierig sein einzelne sinnvolle davon zu implentieren ohne Scriptbrocken aus dem Kontext zu reissen und dadurch unvorhersehbare Ergebnise zu verursachen.viele Gruesse
Stefan MuenzGruß zurück,
flgr
-
-
-
-
-
hallo Kai,
ich stelle immer wieder auf's neue fest, dass Abstand des MSIE bei CSS zu Mozilla hier gigantisch ist und frage mich, ob und wie man das aufholen will -
http://www.meta-text.net/test/ruby.html
Ich frage mich wann Opera 6.01 und Mozilla 1.0 das aufholen will, was der IE schon mit der Version 5 (vor mehr als einem Jahr!!) beherrscht hat? Und ruby ist bitte Standard.
Sorry, aber dein Posting beweist wiedereinmal mehr, wie entsetzlich sinnlos und langweilig solche "Welcher Browser ist besser" Threads sind, denn es gibt für jeden Browser genau so viele pro wie kontra Argumente.
Grüße
Thomasps: für alle die ein standard-inkompatiblen browser benutzen (also Opera, Mozilla etc.) ; so sollte die html Seite aussehen:
<img src="http://www.meta-text.net/test/ruby.gif" border=0 alt="">-
Hallo Thomas,
tja, da wäre nur das Problem, dass Deine Seite zu keinem W3C-Standard
kompatibel ist:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.meta-text.net%2Ftest%2Fruby.html*SCNR*
Ruby ist in der Tat ein W3C-Standard, allerdings weder Bestandteil
von HTML noch von CSS. Ruby ist auch eher für die Verwendung im
asiatischen Sprachraum gedacht, also für Non-Latin Schriftarten.http://www.mozilla.org/docs/refList/i18n/i18n-guidelines.html#ideas
zeigt, dass die Mozilla-Entwickler sehr wohl bemüht sind, diesen
W3C-Standard auch in ihren Browser zu implemetieren.Nenne uns doch mal einige relevante [1] Beispiele aus dem HTML- oder
CSS-Bereich, wo der MSIE derzeit die Nase vorn hat.Viele Grüße,
StefanPS: position:fixed; oder thead/tbody/tfoot sind solche Beispiele.
-
hi
tja, da wäre nur das Problem, dass Deine Seite zu keinem W3C-Standard
kompatibel ist:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.meta-text.net%2Ftest%2Fruby.htmlXHTML 1.1 ;)
Dazu ist zu sagen, dass für Mozilla ein "dirty hack" existiert, der witzigerweise sogar weniger danebengeht als die MSIE-Version. Haken bei Microsoft ist, dass ein sogenantes komplex ruby wie es in der Spec genannt wird vom IE völlig ignoriert wird, der Mozilla-Hack hat den Nachteil, dass er bei einem rbspan="" immer davon ausgeht, dass es über die volle Breite geht.
Grüße aus Bleckede
Kai
-
Hallo Stefan,
tja, da wäre nur das Problem, dass Deine Seite zu keinem W3C-Standard
kompatibel ist:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.meta-text.net%2Ftest%2Fruby.htmlah ja... ist es jetzt besser?
Jetzt stürtz Opera 6.0 einfach ab. Ist ja Herrlich! Halleluja!*SCNR*
das war _die_ gelegenheit wo du es doch hättest lassen sollen.
Ruby ist in der Tat ein W3C-Standard, allerdings weder Bestandteil
von HTML noch von CSS. Ruby ist auch eher für die Verwendung im
asiatischen Sprachraum gedacht, also für Non-Latin Schriftarten.http://www.mozilla.org/docs/refList/i18n/i18n-guidelines.html#ideas
zeigt, dass die Mozilla-Entwickler sehr wohl bemüht sind, diesen
W3C-Standard auch in ihren Browser zu implemetieren.*mega LOL*
Sorry, dort werveisen sie auf einen draft vom Martin Dürt aus 1997!! der schon am 31. August 1997 abgelaufen ist. und das willst du als "Ideas for the Future" akzeptieren?? Wer hat was bitte verschalfen!?Nenne uns doch mal einige relevante [1] Beispiele aus dem HTML- oder CSS-Bereich, wo der MSIE derzeit die Nase vorn hat.
iteressiert mich nicht die bohne!
genau so wenig wie wie und wo mozilla oder opera seine nase vorne hat.mir ging es nicht darum zu beweisen dass dieser oder jener brwoser besser ist. sondern nur darum wie anödernd solche threads wie diese sind. (sorry Kai!)
Grüße
Thomas
-
-