Mozilla/Firefox

[Ingo Turski]

Hi,
freundliche Grüße
Ingo

[Maddin]

Hi,

Hi Ingo!

freundliche Grüße
Ingo

Freundlichen Gruß zurück,
Maddin

[Ingo Turski]

Hi,

Freundlichen Gruß zurück,
Maddin

Mist, ich hatte gehofft, schneller mit meiner Ergänzung zu sein. ;-)

freundliche Grüße
Ingo

[Ingo Turski]

Hi,

sorry, da hatte ich irgendwie die falsche Tastenkombination aus Versehen erwischt...

Ich hätte da zwei Fragen:

1. Hat der Mozilla und Firefox einen Bug bei der Umsetzung von a:active, wenn ein Hintergrundbild verwendet wird? Hierzu eine Beispielseite.

2. Ich bräuchte eine abfragbare Javascript-Methode, die ausschließlich Mozilla und Firefox bzw. Browser, die die -moz CSS-Eigenschaften interpretieren (gibt's da eigentlich noch andere Geckos?).

freundliche Grüße
Ingo

[MudGuard]

Hi,

1. Hat der Mozilla und Firefox einen Bug bei der Umsetzung von a:active, wenn ein Hintergrundbild verwendet wird? Hierzu eine Beispielseite.

Bist Du sicher, daß die Beispielseite zum Problem gehört? Dort gibt es kein einziges Hintergrundbild.

cu,
Andreas

[Ingo Turski]

Hi,

Bist Du sicher, daß die Beispielseite zum Problem gehört? Dort gibt es kein einziges Hintergrundbild.

Sorry, Du hast natürlich recht. Ich meine natürlich die über IMG in den Link gesetzte Grafik.
Warum funktioniert im Mozilla und Firefox a:hover aber nicht a:active?

freundliche Grüße
Ingo

[Detlef G.]

Hallo Ingo

Warum funktioniert im Mozilla und Firefox a:hover aber nicht a:active?

Frage die Entwickler ;).
Und freue dich, dass a:hover funktioniert, sonst müssten wohl alle dynamischen
CSS-Infoboxen und CSS-Menüs angepasst werden.

Auf Wiederlesen
Detlef

[MudGuard]

Hi,

Sorry, Du hast natürlich recht. Ich meine natürlich die über IMG in den Link gesetzte Grafik.
Warum funktioniert im Mozilla und Firefox a:hover aber nicht a:active?

:active ist für alle Elemente definiert, nicht nur für Links.

:hover kann m.E. auf mehrere Elemente gleichzeitig zutreffen, nämlich auf alle, deren erzeugte Box(en) unter dem Mauszeiger liegen, sofern sie nicht durch Elemente mit höherem z-index überlagert werden.
:active und :focus sind dagegen wie der Highlander: es kann nur einen geben.

Die Geckos werden das vermutlich so sehen, daß in diesem Fall eben das Bild :active ist, aber nicht dessen Vorfahren-Elemente :active sind.

Ein kurzer Test mit
a:active { color:red; }
und
<a href="#">test <span>span</span> test</a>
scheint das zu bestätigen - Mausdrücken auf "test" färbt den gesamten Link (dank Vererbung von color auf den span) - Mausdrücken auf "span" färbt jedoch nichts.

cu,
Andreas

[MudGuard]

Hi,

:active und :focus sind dagegen wie der Highlander: es kann nur einen geben.

Nachtrag: der IE hat ja bekanntermaßen Probleme mit der Anwendung der Pseudoklassen auf beliebige Elemente, daher dürfte im IE das einzige aktivierte Element das a-Element sein ...

cu,
Andreas

[Ingo Turski]

Hi,

:active und :focus sind dagegen wie der Highlander: es kann nur einen geben.

Das scheint eine plausible Erklärung zu sein. Wobei ich mich allerdings frage, ob man wirklich sagen kann, daß nach einem Klick auf das Bild (oder andere Element in A)wirklich das Bild den focus hat oder nicht doch eher der Link.

In den specs habe ich gerade gefunden:
"CSS 2.1 doesn't define if the parent of an element that is ':active' or ':hover' is also in that state."

Es wäre demnach Mozilla freigestellt, auch :hover nur auf das innere Element anzuwenden. Ich fände aber die Berücksichtigung beider Elemente in beiden Fällen sinnvoller.

Nachtrag: der IE hat ja bekanntermaßen Probleme mit der Anwendung der Pseudoklassen auf beliebige Elemente, daher dürfte im IE das einzige aktivierte Element das a-Element sein ...

schon klar. ;-)
Allerdings verhält sich auch Opera hier so. Und in diesem Fall finde ich das auch praxisgerechter. Warum sollte z.B. bei:

<a href="#">Linktext mit <strong>Hervorhebung</strong>.</a>

die Hervorhebung sich per Default anders verhalten als der übrige Linktext?
Bzw. warum erfordert Mozilla in diesem Fall eine solch umständliche Definition:
  a:active, a strong:active {}

freundliche Grüße
Ingo

[MudGuard]

Hi,

Hi,

:active und :focus sind dagegen wie der Highlander: es kann nur einen geben.
Das scheint eine plausible Erklärung zu sein. Wobei ich mich allerdings frage, ob man wirklich sagen kann, daß nach einem Klick auf das Bild (oder andere Element in A)wirklich das Bild den focus hat oder nicht doch eher der Link.

In den specs habe ich gerade gefunden:
"CSS 2.1 doesn't define if the parent of an element that is ':active' or ':hover' is also in that state."
Es wäre demnach Mozilla freigestellt, auch :hover nur auf das innere Element anzuwenden. Ich fände aber die Berücksichtigung beider Elemente in beiden Fällen sinnvoller.

Wieso beider? Warum sollte beim Elternelement Schluß sein?
Wenn bei <a href="#">Linktext mit <strong>Hervorhebung</strong>.</a> und Mausdrücken auf Hervorhebung das strong :active ist, könnte nach der Spec 2.1 auch das parent-Element des :active-Elements :active sein. Damit wäre also ggf. das a-Element :active. Nach derselben Spec 2.1 dürfte dann auch dessen Elternelement :active sein, dann dessen Elternelement usw.
Das zieht sich dann über body rauf bis zum html-Element.

Allerdings verhält sich auch Opera hier so.

Naja, ich hab das Gefühl, der Opera verkommt immer mehr zu einem IE-Abklatsch statt sich an Spezifikationen zu halten.

cu,
Andreas

[Ingo Turski]

Hi,

Nach derselben Spec 2.1 dürfte dann auch dessen Elternelement :active sein, dann dessen Elternelement usw.
Das zieht sich dann über body rauf bis zum html-Element.

Korrekt. Aber hätte das irgend eine Auswirkung bzw. einen Nachteil? Ich sehe keinen.
Wenn ich a:active formatiere, werden dessen Elternelemente doch nicht beeinflußt.

Aber mal anders herum: wenn ich body:active formatiere, hätte dies im Mozilla dann vermutlich nur Auswirkung auf direkt im Body stehenden Text (bei entsprechendem Doctype also nirgends). Macht das denn Sinn?

Naja, ich hab das Gefühl, der Opera verkommt immer mehr zu einem IE-Abklatsch statt sich an Spezifikationen zu halten.

Grundsätzlich würde ich Dir zustimmen, aber in diesem Fall finde ich die Auslegung des Opera sinnvoller.

freundliche Grüße
Ingo

[MudGuard]

Hi,

Aber mal anders herum: wenn ich body:active formatiere, hätte dies im Mozilla dann vermutlich nur Auswirkung auf direkt im Body stehenden Text

Nö. Vererbung findet statt.

Siehe a:active { color:red; } mit <a href="#">bla <span>blubb</span></a>

cu,
Andreas

[Ingo Turski]

Hi,

Aber mal anders herum: wenn ich body:active formatiere, hätte dies im Mozilla dann vermutlich nur Auswirkung auf direkt im Body stehenden Text

Nö. Vererbung findet statt.

Siehe a:active { color:red; } mit <a href="#">bla <span>blubb</span></a>

Vererbung schon, aber was nütz das, wenn der active-Zustand für body nirgends ausgelöst werden kann?

freundliche Grüße
Ingo

[Tobias Müller]

Hallo Ingo,

1. Hat der Mozilla und Firefox einen Bug bei der Umsetzung von a:active, wenn ein Hintergrundbild verwendet wird?

Keine Ahnung ehrlich gesagt. Aber wo ist da ein Hintergrundbild? ;)

2. Ich bräuchte eine abfragbare Javascript-Methode, die ausschließlich Mozilla und Firefox bzw. Browser, die die -moz CSS-Eigenschaften interpretieren.

Meine "Gecko-Erkennung" sieht so aus:

isGECKO = (document.getElementsById && !document.all && !window.opera && (window.pkcs11 || window.updateCommands)) ? true : false;

(gibt's da eigentlich noch andere Geckos?)

Netscape 6+ z.B. ;-)

MfG, Mülli

[Tobias Müller]

Hallo Tobias,

isGECKO = (document.getElementsById && !document.all && !window.opera && (window.pkcs11 || window.updateCommands)) ? true : false;

document.getElementById soll es heissen. ;(

MfG, Mülli

[Ingo Turski]

Hi,

Meine "Gecko-Erkennung" sieht so aus:

isGECKO = (document.getElementsById && !document.all && !window.opera && (window.pkcs11 || window.updateCommands)) ? true : false;

Danke. was sind denn die letzten beiden Eigenschaften und sind diese vielleicht schon Mozilla-spezifisch?

freundliche Grüße
Ingo

[Tobias Müller]

Hallo Ingo,

isGECKO = (document.getElementsById && !document.all && !window.opera && (window.pkcs11 || window.updateCommands)) ? true : false;
Danke. was sind denn die letzten beiden Eigenschaften und sind diese vielleicht schon Mozilla-spezifisch?

Wofür die letzten beiden Methoden gut sind, habe ich nicht den Hauch einer Ahnung. Tatsache ist aber, dass nur die Geckos bzw. Netscape sie kennen.

MfG, Mülli

[Alexander Brock]

Hallo,

isGECKO = (document.getElementsById && !document.all && !window.opera && (window.pkcs11 || window.updateCommands)) ? true : false;
Danke. was sind denn die letzten beiden Eigenschaften und sind diese vielleicht schon Mozilla-spezifisch?

Wofür die letzten beiden Methoden gut sind, habe ich nicht den Hauch einer Ahnung. Tatsache ist aber, dass nur die Geckos bzw. Netscape sie kennen.

Ich hab mal danach gegoogelt und folgendes gefunden:

window.pkcs11:
Returns the pkcs11 object , which can be used to install drivers other software associated with the pkcs11 protocol.

Die Beschreibung von window.updateCommands() ist leider sehr unnütz.

Gruß
Alexander Brock

[Ingo Turski]

Hi,

Die Beschreibung von window.updateCommands() ist leider sehr unnütz.

jo - bzw. nicht vorhanden. Hatte ich gerade auch schon entdeckt.

freundliche Grüße
Ingo

[Ingo Turski]

Hi,

Wofür die letzten beiden Methoden gut sind, habe ich nicht den Hauch einer Ahnung. Tatsache ist aber, dass nur die Geckos bzw. Netscape sie kennen.

ich hsbe gerade mal etwas gesucht und window.updateCommands() gibt's zwar, scheint aber gar nicht verwendet zu werden: http://www.mozilla.org/docs/dom/domref/dom_window_ref124.html. Scheint mir ein unsicherer Kandidat zu sein.

Aber dabei habe ich dann noch window.controllers gefunden und diese Abfrage nach den XUL Controllern scheint mir doch sehr sinnvoll zu sein - trennt jedenfalls Mozilla und Firefox vom IE und Opera (und auch Netscape 4.7).

Wenn vielleicht auch mal User von Konquerer, Safari u.a. auf meine Testseite gehen könnten, wäre nett...
Ganz unten sollte in der roten Box entweder false stehen und der Rahmen normal eckig oder true stehen und der Rahmen abgerundet sein. Wenn nicht, bitte Bescheid geben.

freundliche Grüße
Ingo

[Alexander Brock]

Hallo Ingo,

Wenn vielleicht auch mal User von Konquerer, Safari u.a. auf meine Testseite gehen könnten, wäre nett...

Der IE macht die Graphik bei Klick prompt rot, mein FF 1
jetzt komischerweise auch (frag mich nicht, wie ich das gemacht habe).

Ganz unten sollte in der roten Box entweder false stehen und der Rahmen normal eckig oder true stehen und der Rahmen abgerundet sein. Wenn nicht, bitte Bescheid geben.

Im FF ist die Box oval und "ergibt: true"
Im IE 6 ist die Box eckig (große Überraschung ;-)) und "ergibt: false"

Gruß
Alexander Brock

[Ingo Turski]

Hi,

Der IE macht die Graphik bei Klick prompt rot, mein FF 1
jetzt komischerweise auch (frag mich nicht, wie ich das gemacht habe).

doch. ;-) Du hast nicht zufällig in den freien Bereich neben der Grafik geklickt? Ansonsten wäre das schon sehr mysteriös.

freundliche Grüße
Ingo

[Alexander Brock]

Hallo Ingo,

Der IE macht die Graphik bei Klick prompt rot, mein FF 1
jetzt komischerweise auch (frag mich nicht, wie ich das gemacht habe).
doch. ;-) Du hast nicht zufällig in den freien Bereich neben der Grafik geklickt?

Genau.

Gruß
Alexander Brock

[molily]

Hallo,

Wenn vielleicht auch mal User von Konquerer, Safari u.a. auf meine Testseite gehen könnten, wäre nett...

Mein Konqueror 3.3.2 kennt kein window.controllers und die Abfrage ergibt also false.

Mathias

[Ingo Turski]

Hi,

Mein Konqueror 3.3.2 kennt kein window.controllers und die Abfrage ergibt also false.

danke. Und interpretiert Dein Konqueror -moz CSS-Eigenschaften, zeigt also den roten Rahmen mit abgerundeten Ecken an?

freundliche Grüße
Ingo

[molily]

Hallo,

danke. Und interpretiert Dein Konqueror -moz CSS-Eigenschaften, zeigt also den roten Rahmen mit abgerundeten Ecken an?

Nein. (Hielt ich für selbstverständlich, deshalb dachte ich, du wollest nur auf die JavaScript-Abfrage hinaus.)

Mathias

[Ingo Turski]

Hi,

Und interpretiert Dein Konqueror -moz CSS-Eigenschaften, zeigt also den roten Rahmen mit abgerundeten Ecken an?

Nein. (Hielt ich für selbstverständlich, deshalb dachte ich, du wollest nur auf die JavaScript-Abfrage hinaus.)

Da ich den Konqueror nicht kenne, ist das für mich halt nicht selbstverständlich. Aber gut zu wissen. Ich kann dann wohl über window.controllers ausschließlich die Browser ansprechen, die die -moz CSS-Eigenschaften unterstützen und darauf wollte ich hinaus.

freundliche Grüße
Ingo

[Thomas J.S.]

Hallo,

Aber dabei habe ich dann noch window.controllers gefunden und diese Abfrage nach den XUL Controllern scheint mir doch sehr sinnvoll zu sein - trennt jedenfalls Mozilla und Firefox vom IE und Opera (und auch Netscape 4.7).

Einfacher wäre da: if (window.ChromeWindow).

Grüße
Thomas

[Ingo Turski]

Hi,

Einfacher wäre da: if (window.ChromeWindow).

wieso einfacher? Oder meinst Du damit, daß die -moz CSS-Eigenschaften eher mit dieser Methode in Zusammenhang stehen?

freundliche Grüße
Ingo

[Thomas J.S.]

Hallo,

Einfacher wäre da: if (window.ChromeWindow).
wieso einfacher? Oder meinst Du damit, daß die -moz CSS-Eigenschaften eher mit dieser Methode in Zusammenhang stehen?

Weil darauf reagieren nur Geckos. Kein Netscape 4.x etc. und weil einige der -moz Eigenschaften zwar "existieren", sind aber nicht implemtiert und weil andere Objekte - wie die erwähnten - zu "suspekt" d.h. zu spezifisch sind (imho) und u.U. gar nicht greifen.

Grüße
Thomas

[Ingo Turski]

Hi,

Einfacher wäre da: if (window.ChromeWindow).
wieso einfacher? Oder meinst Du damit, daß die -moz CSS-Eigenschaften eher mit dieser Methode in Zusammenhang stehen?

Weil darauf reagieren nur Geckos.

Nunja, alle Geckos will ich ja gar nicht, nur die, die die -moz CSS-Eigenschaften unterstützen. Und könnte ich mit window.ChromeWindow nicht auch andere erwischen?

und weil einige der -moz Eigenschaften zwar "existieren", sind aber nicht implemtiert

Das wiederum stört mich in meinem Fall überhaupt nicht.

und weil andere Objekte - wie die erwähnten - zu "suspekt" d.h. zu spezifisch sind (imho) und u.U. gar nicht greifen.

window.controllers sollte doch aber auf jeden Fall greifen, da XUL ja zentraler Bestandteil von Mozillas ist, oder?

freundliche Grüße
Ingo

[Thomas J.S.]

Hallo,

Einfacher wäre da: if (window.ChromeWindow).
wieso einfacher? Oder meinst Du damit, daß die -moz CSS-Eigenschaften eher mit dieser Methode in Zusammenhang stehen?

Weil darauf reagieren nur Geckos.

Nunja, alle Geckos will ich ja gar nicht, nur die, die die -moz CSS-Eigenschaften unterstützen. Und könnte ich mit window.ChromeWindow nicht auch andere erwischen?

Hmm... ich habe das jetzt ausprobiert: z.B. k-meleon (extra installiert [0.8.2, basiert auf Mozilla 1.5, Gecko/20031016]) unterstützt -moz-border-radius, ein

if (window.ChromeWindow)
    alert('window.ChromeWindow');

bringt auch die Meldung, bei

if (window.controllers)
    alert('window.controllers');

passiert aber nichts.

Grüße
Thomas

[Ingo Turski]

Hi,

Hmm... ich habe das jetzt ausprobiert: z.B. k-meleon (extra installiert [0.8.2, basiert auf Mozilla 1.5, Gecko/20031016]) unterstützt -moz-border-radius, ein

if (window.ChromeWindow)
    alert('window.ChromeWindow');

bringt auch die Meldung, bei

vielen Dank für die Mühe.
Dann scheint dieses Objekt wirklich näher an den -moz CSS-Eigenschaften zu liegen und ich verwende es jetzt.

Vielleicht noch zum Hintergrund: Bei meinen privaten Seiten habe ich damit begonnen, die erweiterten Fähigkeiten des Mozilla zu nutzen; vorerst nur Kleinigkeiten wie abgerundete Ecken und die Farbe von selektiertem Text. Damit das CSS valide bleibt, aber auch, um evtl. für andere Browser Alternativen einzubauen, die Mozilla nicht belasten sollen, möchte ich das Ganze über eine Javascript-Weiche gezielt den verschiedenen Browsern zukommen lassen.
Dem IE werde ich Alternativen allerdings eher über Conditional Comment zukommen lassen, da hier am ehesten Javasscript deaktiviert ist.

freundliche Grüße
Ingo

[Cybaer]

Hi,

Dem IE werde ich Alternativen allerdings eher über Conditional Comment zukommen lassen, da hier am ehesten Javasscript deaktiviert ist.

Eher "sein sollten", oder?

IMHO surfen die "Ahnungslosen" mit dem IE und Scripting, die "Bewußten" mit Mozilla & Co. und Scripting, die "Paranoiden" und "Verunsicherten" mit Mozilla & Co. ohne Scripting (weil es sich da leichter abschalten läßt und man mal "was davon gehört" hat) und die "Technikgläubigen" mit dem IE, Scripting, Updates und Firewall & Co. ;-)

Ich meine: Welcher User, der sich der Gefahr bewußt ist, surft denn überhaupt mit dem IE? Und wenn er sich der Gefahr nicht bewußt ist, warum sollte er dann Scripting ausschalten - falls er es jemals schaffen sollte/wollte, seinen IE zu konfigurieren?! :)

Gruß, Cybaer

[Ingo Turski]

Hi,

Dem IE werde ich Alternativen allerdings eher über Conditional Comment zukommen lassen, da hier am ehesten Javasscript deaktiviert ist.

Eher "sein sollten", oder?

beides. Unbestritten sollte JS im IE deaktiviert werden, was ja von Zeit zu Zeit auch bei neuen Sicherheitslöchern sogar von Microsoft selbst empfohlen wird.
Wenn ich mir aber meine Logs ansehe, stelle ich fest, daß die ca. 1% meiner Besucher ohne Javascript fast ausschließlich den IE verwenden.

freundliche Grüße
Ingo

[Cybaer]

Hi,

Wenn ich mir aber meine Logs ansehe, stelle ich fest, daß die ca. 1% meiner Besucher ohne Javascript fast ausschließlich den IE verwenden.

Oder dies zumindest vorgeben. ;-)

Aber 1% ist echt ein harter Wert. :)

Gruß, Cybaer

[Ingo Turski]

Hi,

Wenn ich mir aber meine Logs ansehe, stelle ich fest, daß die ca. 1% meiner Besucher ohne Javascript fast ausschließlich den IE verwenden.

Oder dies zumindest vorgeben. ;-)

nein, dies sind höchstwahrscheinlich echte IEs. Ich hatte das mal anhand eines Wochenlogs verifiziert, bei dem viele dieser User eine Seite bei sich gespeichert hatten. Nur IEs fordern URLs wie
        /tanz/Tanzfiguren-Beschreibungen Salsa-Dateien/1ngoxtra.css
an. ;-)

Aber 1% ist echt ein harter Wert. :)

ja, und egal wie man's betrachtet...

freundliche Grüße
Ingo

[Cybaer]

Hi,

Nur IEs fordern URLs wie
        /tanz/Tanzfiguren-Beschreibungen Salsa-Dateien/1ngoxtra.css
an. ;-)

:))

Man könnte ja mal mit Conditional Comments ... (aua, nicht schlagen! ;-))

Gruß, Cybaer

[Ingo Turski]

Hi,

Nur IEs fordern URLs wie
        /tanz/Tanzfiguren-Beschreibungen Salsa-Dateien/1ngoxtra.css
an. ;-)

:))

Man könnte ja mal mit Conditional Comments ... (aua, nicht schlagen! ;-))

hehe... nicht wirklich; müßte ja wohl serverseitig laufen.

Und übrigens, auch Firefox ist da wohl manchmal etwas blöd:

"GET /tanz/tango_dateien/tango.gif HTTP/1.1" 404 9974 www.1ngo.de "http://www.1ngo.de/tanz/tango.html" "Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0" "-"

Aber dem fehlen nur ein paar Grafiken im Gegensatz zum IE, der die gespeicherten Seiten mit Minimal-CSS nicht besonders schön darstellen wird.

freundliche Grüße
Ingo

[Cybaer]

Hi,

Man könnte ja mal mit Conditional Comments ... (aua, nicht schlagen! ;-))
hehe... nicht wirklich; müßte ja wohl serverseitig laufen.

Warum denn? Der IE bekommt Resource X, der Rest Resource Y.

Mir ist zumindest nicht bekannt, daß irgendein Browserhersteller hier faked.

Und übrigens, auch Firefox ist da wohl manchmal etwas blöd:
"GET /tanz/tango_dateien/tango.gif HTTP/1.1"

LOL

Gruß, Cybaer

[Ingo Turski]

Hi,

Man könnte ja mal mit Conditional Comments ... (aua, nicht schlagen! ;-))
hehe... nicht wirklich; müßte ja wohl serverseitig laufen.

Warum denn? Der IE bekommt Resource X, der Rest Resource Y.

och nö.. ;-)
Der IE hat ja beim Speichern nur Probleme mit @import. Ich könnte ihm die Datei zwar valide über CSS per LINK zusätzlich liefern, aber die ggfls. doppelten Requests müssen ja nicht sein. Und wer weiß - vielleicht überlegt ja der ein oder andere Besucher beim Betrachten seiner gespeicherten Seite, doch mal den Browser zu wechseln?

freundliche Grüße
Ingo

[Candid Dauth]

Hallo du da draußen,

Der IE hat ja beim Speichern nur Probleme mit @import.

Nur beim Speichern? Ich habe gerade die Erfahrung gemacht, dass selbst Version Sechs es in der Anzeige nicht angenommen hat. Oder lag das an dem Medium, dass ich dahinter notiert habe?

@import style.css all

Grüße von hier drinnen, aus Biberach an der Riss,
Candid Dauth (Dogfish)

[Ingo Turski]

Hi,

Der IE hat ja beim Speichern nur Probleme mit @import.

Nur beim Speichern? Ich habe gerade die Erfahrung gemacht, dass selbst Version Sechs es in der Anzeige nicht angenommen hat. Oder lag das an dem Medium, dass ich dahinter notiert habe?

@import style.css all

Ja. Aber diese Angabe macht ohnehin wenig Sinn.

freundliche Grüße
Ingo

[Candid Dauth]

Hallo du da draußen,

@import style.css all
Ja. Aber diese Angabe macht ohnehin wenig Sinn.

Hmm... warum? Wegen des »all«? Oder wäre es mit einem anderen Medium auch sinnlos?

Wie sieht es da eigentlich mit der Unterstützung von @import mit Medium in anderen Borwsern aus?

Grüße von hier drinnen, aus Biberach an der Riss,
Candid Dauth (Dogfish)

[Ingo Turski]

Hi,

Ja. Aber diese Angabe macht ohnehin wenig Sinn.

Hmm... warum? Wegen des »all«?

Ja. Mit all schließt Du doch keine Medien aus - genausowenig wie ohne Media-Angabe.

Wie sieht es da eigentlich mit der Unterstützung von @import mit Medium in anderen Borwsern aus?

Ältere Browser wie der NN4 kennen das nicht, weshalb ich "fortgeschritteneres" CSS immer so einbinde.

freundliche Grüße
Ingo

[MudGuard]

Hi,

Ja. Aber diese Angabe macht ohnehin wenig Sinn.

Hm. Hier sagst Du, diese Angabe sei sinnlos.

Ältere Browser wie der NN4 kennen das nicht, weshalb ich "fortgeschritteneres" CSS immer so einbinde.

Hier gibst Du demselben den Sinn, als Browserweiche fungieren zu dürfen ...

cu,
Andreas

[Ingo Turski]

Hi,

Ja. Aber diese Angabe macht ohnehin wenig Sinn.

Hm. Hier sagst Du, diese Angabe sei sinnlos.

Ja, bezogen auf die media-Angabe 'all' bei @import.

Ältere Browser wie der NN4 kennen das nicht, weshalb ich "fortgeschritteneres" CSS immer so einbinde.

Hier gibst Du demselben den Sinn, als Browserweiche fungieren zu dürfen ...

Ja, bezogen auf @import.

Ältere Browser verstehen @import grundsätzlich nicht. Der IE versteht zwar @import, aber nur ohne Media-Angabe. Aufgrund der Verbreitung dieses Browsers leiste ich mir, diesem älteren Browser fortschrittliches CSS zu liefern inkl. evtl. Korrekturen. ;-)

freundliche Grüße
Ingo

[MudGuard]

Hi,

Ältere Browser verstehen @import grundsätzlich nicht. Der IE versteht zwar @import, aber nur ohne Media-Angabe.

Eben. Und genau das läßt sich doch als Weiche nutzen, um modernen Browsern das importierte Stylesheet zu geben und es dem IE sowie anderen alten Browsern vorzuenthalten.
Also eine schöne Weiche. Und wenn das importierte Stylesheet nunmal für alle Medien gelten soll, ist natürlich "all" die richtige Angabe bei media.

cu,
Andreas

[Ingo Turski]

Hi,

Also eine schöne Weiche.

zugegeben. Aber wie gesagt nutze ich keine CSS-Weiche zur Ausgrenzung des IEs, sondern nur (z.B. auch conditional comments) für evtl. notwendige Korrekturen.

freundliche Grüße
Ingo

[saltun]

Hallo!

Wenn vielleicht auch mal User von Konquerer, Safari u.a. auf meine Testseite gehen könnten, wäre nett...
Ganz unten sollte in der roten Box entweder false stehen und der Rahmen normal eckig oder true stehen und der Rahmen abgerundet sein. Wenn nicht, bitte Bescheid geben.

Konqeror 3.2.1 zeigt eckigen Rahmen und false.

Grüße
saltun

[Detlef G.]

Hallo Ingo

1. Hat der Mozilla und Firefox einen Bug bei der Umsetzung von a:active, wenn ein Hintergrundbild verwendet wird? Hierzu eine Beispielseite.

Nein, bei Hintergrundbildern nicht, eher bei Elementen im Link.

Du verwendest in deinem Beispiel kein Hintergrundbild, sondern ein img,
welches sich im Link befindet.

Wenn der Link durch ein anderes Element verdeckt wird, auch wenn sich dieses
innerhalb des Links befindet, bleibt active beim Klick auf dieses Element
wirkungslos.

Aber, bitte frag mich nicht, ob dies ein Bug oder Absicht ist oder, wenn es
Absicht wäre, warum es so sein sollte.

Auf Wiederlesen
Detlef

[Ingo Turski]

Hi,

Wenn der Link durch ein anderes Element verdeckt wird, auch wenn sich dieses
innerhalb des Links befindet, bleibt active beim Klick auf dieses Element
wirkungslos.

wieso verdeckt? Das IMG ist _in_ dem Link - genauso wie der Text in dem Beispiel darüber.
Und immerhin funktioniert es bei :hover.

Aber, bitte frag mich nicht, ob dies ein Bug oder Absicht ist oder, wenn es
Absicht wäre, warum es so sein sollte.

nö. Ich frage eher, ob bzw. wie es richtig wäre.

freundliche Grüße
Ingo

[Detlef G.]

Hallo Ingo

wieso verdeckt? Das IMG ist _in_ dem Link - genauso wie der Text in dem Beispiel darüber.

Ich wollte lediglich darauf hinweisen, dass dieser Effekt nicht nur bei
Bildern, sondern auch bei anderen Elementen im Link auftritt.

Auf Wiederlesen
Detlef

[Ingo Turski]

Hi,

Ich wollte lediglich darauf hinweisen, dass dieser Effekt nicht nur bei
Bildern, sondern auch bei anderen Elementen im Link auftritt.

stimmt; ich hab's gerade mal mit einem einfachen SPAN probiert. Schon seltsam...

freundliche Grüße
Ingo

[MudGuard]

Hi,

Wenn der Link durch ein anderes Element verdeckt wird, auch wenn sich dieses
innerhalb des Links befindet, bleibt active beim Klick auf dieses Element
wirkungslos.

Meine Vermutung: Der Highlander-Effekt

cu,
Andreas

[Tim Tepaße]

Hallo Ingo,

(gibt's da eigentlich noch andere Geckos?).

Es gibt massig andere Browser, die Gecko benutzen, aber die einzelnen Geckos
unterscheiden sich nur in der Versionsnummer.

Irgendwelche fleissigen Heinzelmännchen in der Wikipedia haben einige auf
Gecko basierende Browser zu einer Liste zusammengestellt, vieles davon sind
aber Exoten und/oder aufgegebene Projekte:
http://en.wikipedia.org/wiki/Gecko_(layout_engine)

Die meisten der aktiven Browserentwicklungen dürften meist einen aktuellen
stabilen Geckos benutzen, d.h. den, der auch in der Mozilla Suite gerade
benutzt wird. Obacht: Manche dagegen nehmen einen älteren, stabilen Gecko
und nehmen den jahrelang mit. Camino, mein aktueller Browser, hat bis zur
Version 0.7 den Gecko von Mozilla 1.0 benutzt, erst mit der Version 0.7
sind sie auf Gecko 1.7irgendwas umgestiegen. Der Grund darin liegt, daß
Mozilla längere Zeit ein Konzept von »noch stabileren« Geckos pflegte, mit
eingefroreren APIs und Qualitätskontrolle und sowas. Lange Zeit war das dann
der Gecko von Mozilla 1.0, der, glaube ich noch zu wissen, von der 1.5 oder
1.6 abgelöst werden. Allerdings findet sich in der aktuellen Mozilla-Roadmap
nicht mehr von dem Konzept. Angesichts der wirren Mozilla-Webseite und deren
etwas undurchsichtigen Strukturen zur Entscheidungsfindung will ich aber
nicht ausschließen, daß so etwas noch exisistiert.

So kommt es dann, daß ich, der ich noch aus anderen Gründen Camino 0.7
benutze, »nur« die Layoutengine von Mozilla 1.0 zur Verfügung habe. Meistens
ist das wurst, manchmal an ganz kleinen Kleinigkeiten [1] merkt man es dann
doch. Nicht jeder benutzt unbedingt einen aktuellen Mozilla Browser oder hat
nur irgendwelche komischen Spinoffs zur Verfügung (Netscape Communicator fällt
einem da ein), bei manchen grafischen Spielereien, die in aktuellen Mozillas
oder im Firefox problemlos funktionieren, sind in älteren Gecko-Versionen
noch problembehaftet und können einem da in die Quere kommen.

[1] Ich erinnere mich nur an einige Probleme mit float und Formularfeldern,
    es gibt aber auch noch anderes, das mir über die Zeit aufgefallen, aber
    jetzt natürlich nicht eingefallen ist.

Tim

[Ingo Turski]

Hi,

Irgendwelche fleissigen Heinzelmännchen in der Wikipedia haben einige auf
Gecko basierende Browser zu einer Liste zusammengestellt, vieles davon sind
aber Exoten und/oder aufgegebene Projekte:
http://en.wikipedia.org/wiki/Gecko_(layout_engine)

interessante Auflistung.
Wäre nur schön, wenn ich die alle mal testen könnte..;-)

freundliche Grüße
Ingo

[Speedy]

Hi,
freundliche Grüße
Ingo