nicht angemeldet
Struppi
Struppi
at
Struppi
at
Struppi
at
Gunnar Bittersmann
Struppi
Struppi
Struppi
Struppi
Gunnar Bittersmann
Wir hatten die Diskussion CCs vs. Hacks ja schon öfters. Für die, die CCs bevorzugen dürften diese Artikel interessant sein:
http://webforscher.wordpress.com/2010/05/20/ie-6-slowing-down-ie-8
http://www.phpied.com/conditional-comments-block-downloads
Also jetzt den HTML Quellcode entsprechend anpassen. Ich bleib' aber weiter bei den Hacks, da muss ich nichts ändern ;-)
Struppi.
Hi there,
Also jetzt den HTML Quellcode entsprechend anpassen. Ich bleib' aber weiter bei den Hacks, da muss ich nichts ändern ;-)
Das kann und wird mir aber keiner bezahlen, daß ich wegen eines Delays von 0.15s auch nur ein einziges Zeichen in einem Script ändere...;)
Also jetzt den HTML Quellcode entsprechend anpassen. Ich bleib' aber weiter bei den Hacks, da muss ich nichts ändern ;-)
Das kann und wird mir aber keiner bezahlen, daß ich wegen eines Delays von 0.15s auch nur ein einziges Zeichen in einem Script ändere...;)
Skripte wirst du ja auch weniger ändern müssen, nur den HTML Quelltext.
Letztlich bleibt als Fakt, dass CC's mehr Nachteile haben als Hacks, auch wenn es für manche User nur um 0.15s geht (je nach Rechner, ich hab keinen Hinweis gefunden, aber ich vermute solche Leute haben einen Schnellen).
Struppi.
Tungjatjeta!
Letztlich bleibt als Fakt, dass CC's mehr Nachteile haben als Hacks
Ich will gar nicht die Diskussion wieder anleiern, die schon x-mal damit endete, daß alle Argumente für und wider irgendwo im Archiv zu finden sind. Aber ich hätte gerne Eure Meinung (d.h. Hack-Vorschläge) zu zwei Fällen, die mit CCs sehr einfach gehen:
1. IE 6 und 7 gleichzeitig.
IE 6 kriege ich mit * html, IE 7 mit *+html, soweit klar. Mit Komma kombiniert wollen aber beide nicht mehr. Gibt es einen validen Hack, um beide anzusprechen? Die Fixes, die in der Mehrheit ja doch für beide gleich sind, immer doppelt schreiben zu müssen, ist doof.
2. IE 8
Gibt es einen validen Hack für IE 8? Einige Suchergebnisse empfehlen, \9 an den jeweiligen Eigenschaftswert anzuhängen, aber darauf fällt auch Opera rein.
Natürlich kann ich mit einem normalen Selektor alle Browser ansprechen und dann die IE8-Spezialitäten mit einem CSS3-Selektor rückgängig machen, z.B. mit :not(h1) Selektor. Dann schreibe ich aber wieder einen Haufen Zeugs doppelt, und es ist momentan ziemlich unklar, was dann im IE 9 passiert (der afaik alle CSS3-Selektoren kann, aber sicher nicht alle Eigenschaften).
Und nein, graceful degradation reicht nicht immer. ;-)
Viele Grüße vom Længlich
Hallo.
Letztlich bleibt als Fakt, dass CC's mehr Nachteile haben als Hacks
Es ging nie um die Quantität, sondern um die Qualität.
MfG, at
Letztlich bleibt als Fakt, dass CC's mehr Nachteile haben als Hacks
Es ging nie um die Quantität, sondern um die Qualität.
Stimmt, die Qualität der Nachteile sind meines erachtens sogar noch deutlicher, als die Quantität. Zumal i.d.R. sowieso nur ein oder zwei Hacks pro Site notwendig sind. Wenn es mehr mal werden, mach ich mir Gedanken um CCs.
Struppi.
Hallo.
Letztlich bleibt als Fakt, dass CC's mehr Nachteile haben als Hacks
Es ging nie um die Quantität, sondern um die Qualität.
Stimmt, die Qualität der Nachteile sind meines erachtens sogar noch deutlicher, als die Quantität.
Davon war ich ausgegangen, auch wenn andere das sicher mit gleichem Recht anders sehen.
MfG, at
Letztlich bleibt als Fakt, dass CC's mehr Nachteile haben als Hacks
Es ging nie um die Quantität, sondern um die Qualität.
Stimmt, die Qualität der Nachteile sind meines erachtens sogar noch deutlicher, als die Quantität.
Davon war ich ausgegangen, auch wenn andere das sicher mit gleichem Recht anders sehen.
Klar. Nur bringt in dem Fall deine Aussage nichts.
Eine vermeintlich bessere Qualität, läßt sich auch bei den vielen Nachteilen kaum erkennen.
pro Hacks
* bessere Wartbarkeit, durch die Nähe zum Problem (gerade im Team wichtig)
* bremst (manche) IEs nicht aus
* zukunftssicher
* nicht IE-only
* es läßt sich flexibel bestimmen, ob der Hack vorher oder nachher wirken soll
Das der CSS Code evtl. invalide wird, ist Qualitativ betrachtet zweitrangig und dass man u.U. die Hacks leichter entfernen kann, wenn sie nicht mehr benötigt werden, ebenfalls. Mir fällt kein pro für CCs ein, was qualitativ dafür spricht. Ausser u.U. die größere CSS Datei für alle Browser, wenn es wirklich viele Hacks sind, die man benötigt.
Der beste Hack (CCs sind ja auch welche) ist aber immer noch, keine zu benötigen.
Struppi.
pro Hacks
* bessere Wartbarkeit, durch die Nähe zum Problem (gerade im Team wichtig)
Moment. CCs setzen eine ID ins HTML, damit deine Problem genau so nahe behandelt wird wie deine anderen CSS-Selektoren.
valide Syntax sind keine CSS-Hacks
* bremst (manche) IEs nicht aus
Wir hatten das doch schon behandelt oder?
Man kann CCs richtig einsetzen.
* zukunftssicher
Via CC eingesetzte Regeln sind noch zukunftssicherer.
* nicht IE-only
OK. Brauchen wir für andere Browser Hacks?
Nein wird brauchen eine Selektoren Strategie (Stichwort media query Fähigkeit).
* es läßt sich flexibel bestimmen, ob der Hack vorher oder nachher wirken soll
Siehe mein obiges Argument.
Das der CSS Code evtl. invalide wird, ist Qualitativ betrachtet zweitrangig und dass man u.U. die Hacks leichter entfernen kann, wenn sie nicht mehr benötigt werden, ebenfalls. Mir fällt kein pro für CCs ein, was qualitativ dafür spricht. Ausser u.U. die größere CSS Datei für alle Browser, wenn es wirklich viele Hacks sind, die man benötigt.
Der beste Hack (CCs sind ja auch welche) ist aber immer noch, keine zu benötigen.
Der Nachteil von CSS hacks
oder von unkommentierten Regeln: Der User hat keine Ahnung warum das dort steht.
#msie7 selector {} spart dir jeden Kommentar
CCs sind hier weitaus freundlicher.
Dein Problem ist, dass du bei CCs immer nur an ein separat eingebundes File denkst. Gewöhn dir das ab und deine Argumente verflüchtigen sich ins nada.
mfg Beat
Dein Problem ist, dass du bei CCs immer nur an ein separat eingebundes File denkst. Gewöhn dir das ab und deine Argumente verflüchtigen sich ins nada.
Ich spreche über das was ich sehe.
Ich halte deine Strategie nicht für verkehrt (haben wir ja schon im anderen Strang), nur in der Praxis scheint niemand sie zu verwenden.
Struppi.
@@Beat:
nuqneH
Moment. CCs setzen eine ID ins HTML
Dass ich eine ID nicht für angebracht halte, sondern eher eine Klasse, hatte ich schon erwähnt.
* zukunftssicher
Via CC eingesetzte Regeln sind noch zukunftssicherer.
Ich weiß nicht, wo du die Steigerung hernimmst. Das eine ist genauso zukunftssicher wie das andere.
Brauchen wir für andere Browser Hacks?
Gelegentlich, ja. Manchmal einen für Firefox, machmal einen für Safari, manchmal einen für Opera.
Der Nachteil von CSS hacks
oder von unkommentierten Regeln: Der User hat keine Ahnung warum das dort steht.
?? Der User? Ein Nutzer liest keine Stylesheets. Meinst du einen Stylesheet-Entwickler? Wer als solcher '* html'/'*+html' nicht versteht, sollte vielleicht besser anderen Tätigkeiten nachgehen.
#msie7 selector {} spart dir jeden Kommentar
Mit geringer Expertise (die man von jedem Stylesheet-Entwickler erwarten dürfte) ist '*+html selector {}' genauso verständlich.
Qapla'
Hallo.
Letztlich bleibt als Fakt, dass CC's mehr Nachteile haben als Hacks
Es ging nie um die Quantität, sondern um die Qualität.
Stimmt, die Qualität der Nachteile sind meines erachtens sogar noch deutlicher, als die Quantität.
Davon war ich ausgegangen, auch wenn andere das sicher mit gleichem Recht anders sehen.
Klar. Nur bringt in dem Fall deine Aussage nichts.
Doch, natürlich. Mir ist egal, ob jemand CSS-Hacks oder Conditional Comments verwendet, aber bitte nicht aufgrund der Zahl der Argumente, sondern aufgrund ihres Gewichtes.
Eine vermeintlich bessere Qualität, läßt sich auch bei den vielen Nachteilen kaum erkennen.
Das ist Ansichtssache.
Der beste Hack (CCs sind ja auch welche) ist aber immer noch, keine zu benötigen.
Klar, man muss eben nur toleranter sein als die Browser.
MfG, at
@@Struppi:
nuqneH
Das der CSS Code evtl. invalide wird
Unbekannte Eigenschaften tun niemandem weh, egal ob CSS 3, was ein Browser X noch nicht versteht, oder 'filter' oder 'expression'. Und üble Hacks müssen ja nicht sein.
Mir fällt kein pro für CCs ein, was qualitativ dafür spricht. Ausser u.U. die größere CSS Datei für alle Browser, wenn es wirklich viele Hacks sind, die man benötigt.
Auch das ist kein Pluspunkt für CCs.
Qapla'
Hi,
Also jetzt den HTML Quellcode entsprechend anpassen.
Und mir fallen gleich noch ein paar mehr Dinge ein, wo man mit Verzicht auf dokumentierte Features und dafür Verwendung von Hacks bestimmt noch mehr einsparen kann, als nur 'ne Zehntelsekunde. =;->
Gruß, Cy-"LOL"-baer
Und mir fallen gleich noch ein paar mehr Dinge ein, wo man mit Verzicht auf dokumentierte Features und dafür Verwendung von Hacks bestimmt noch mehr einsparen kann, als nur 'ne Zehntelsekunde. =;->
Naja, die Hacks sind eigentlich alle gut dokumentiert.
Und die Zehntelsekunde sparst nicht du ein. Wenn ich den Browser meiner Besucher blockieren will, fallen mir aber auch noch mehr Dinge ein :-)
Struppi.
Hi,
Und die Zehntelsekunde sparst nicht du ein. Wenn ich den Browser meiner Besucher blockieren will, fallen mir aber auch noch mehr Dinge ein :-)
Also zuallererst fällt mir da ein, überhaupt einen IE zu benutzen - egal welcher. >;->
Gruß, Cybaer
Wir hatten die Diskussion CCs vs. Hacks ja schon öfters. Für die, die CCs bevorzugen dürften diese Artikel interessant sein:
http://webforscher.wordpress.com/2010/05/20/ie-6-slowing-down-ie-8
http://www.phpied.com/conditional-comments-block-downloads
Wer CCs braucht um Files runterzuladen, ist selber blöd.
Ich setze mir mit CC eine zusätzliche ID. Ein CSS-Request für alle!
mfg Beat
Wir hatten die Diskussion CCs vs. Hacks ja schon öfters. Für die, die CCs bevorzugen dürften diese Artikel interessant sein:
http://webforscher.wordpress.com/2010/05/20/ie-6-slowing-down-ie-8
http://www.phpied.com/conditional-comments-block-downloadsWer CCs braucht um Files runterzuladen, ist selber blöd.
Ich setze mir mit CC eine zusätzliche ID. Ein CSS-Request für alle!
Wenn ich das richtig verstanden habe, braucht der IE (8?) die Zeit zum ananwerfen des Parsers, die Requests an sich spielen in dem Fall eine untergeordnete Rolle.
Struppi.
Wir hatten die Diskussion CCs vs. Hacks ja schon öfters. Für die, die CCs bevorzugen dürften diese Artikel interessant sein:
http://webforscher.wordpress.com/2010/05/20/ie-6-slowing-down-ie-8
http://www.phpied.com/conditional-comments-block-downloadsWer CCs braucht um Files runterzuladen, ist selber blöd.
Ich setze mir mit CC eine zusätzliche ID. Ein CSS-Request für alle!Wenn ich das richtig verstanden habe, braucht der IE (8?) die Zeit zum ananwerfen des Parsers, die Requests an sich spielen in dem Fall eine untergeordnete Rolle.
Nein, das hast du falsch verstanden.
Denn im finalen Vorgang wurden ja gleich zwei mal CCs geschrieben, das erste leer, das zweite später für den MSIE6.
mfg Beat
Nein, das hast du falsch verstanden.
Denn im finalen Vorgang wurden ja gleich zwei mal CCs geschrieben, das erste leer, das zweite später für den MSIE6.
Ok, stimmt.
Und wenn ich das diesmal richitg verstanden habe, sieht deine Lösung in etwa so aus:
<body <!--[if IE 6]> id="ie6" <![endif]-->>
Eigentlich auch keine schlechte Lösung.
Struppi.
Und wenn ich das diesmal richitg verstanden habe, sieht deine Lösung in etwa so aus:
<body <!--[if IE 6]> id="ie6" <![endif]-->>
>
> Eigentlich auch keine schlechte Lösung.
Da ein Element nur ein id-Attribut haben darf, muss ich das machen:
<body>
<!--[if IE 6]><div id="msie6"><![endif]-->
...
<!--[if IE 6]></div><![endif]-->
</body>
Oder siehst du einen Weg, ein bestehendes Klassenattribut im body um einen Namen zu erweitern?
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
Und wenn ich das diesmal richitg verstanden habe, sieht deine Lösung in etwa so aus:
<body <!--[if IE 6]> id="ie6" <![endif]-->>
> >
> > Eigentlich auch keine schlechte Lösung.
>
> Da ein Element nur ein id-Attribut haben darf, muss ich das machen:
Naja selbst das liesse sich doch so lösen:
~~~html
<body id="<!--[if IE 6]>ie6<![endif]-->">
Wobei eine Body ID selten gebraucht wird, da das Element sowieso nur einmal vorkommt.
<body>
<!--[if IE 6]><div id="msie6"><![endif]-->
...
<!--[if IE 6]></div><![endif]-->
</body>
Was ich wieder umständlich fände.
Oder siehst du einen Weg, ein bestehendes Klassenattribut im body um einen Namen zu erweitern?
Ich bin kein Experte in Sachen CC (ich hab' das noch nie benutzt), aber funktioniert der obige Vorschlag? (mittlerweile habe ich kein Windows mehr und müßte zum ausprobieren den alten Rechner anwerfen)
Struppi.
Naja selbst das liesse sich doch so lösen:
<body id="<!--[if IE 6]>ie6<![endif]-->">
Teste im FF
<body class="red<!--[if IE 6]> blue<![endif]-->">
versus
<body class="red <!--[if IE 6]> blue<![endif]-->">
Da kommen Feinheiten ins Spiel betreffs Whitespace-Handling in Attributen.
Mir ist das zu unsicher.
> Wobei eine Body ID selten gebraucht wird, da das Element sowieso nur einmal vorkommt.
Ich habe mit User-CSS zu tun, welche CMS-CSS überschreiben sollen.
da ist <body id="body"> ein Angebot, damit der User eine höhere Spezifität im CSS selektieren kann.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
[latex]Mae govannen![/latex]
Wobei eine Body ID selten gebraucht wird, da das Element sowieso nur einmal vorkommt.
Ist aber außerordentlich praktisch. Ich habe bei meine Seiten jedem body eine eindeutige id gegeben. Dadurch brauche ich mir keinen Kopf zu machen, eine im content vorkommende ID projektweit eindeutig zu vergeben.
benutze ich nur #foo, gilt dies für alle Seiten, auf denen #foo definiert ist
<body id="index">
#index #foo
<body id="links">
#links #foo
hingegen erlaubt eine saubere Differenzierung.
Rein logisch müßte die id zwar dem html-element zugewiesen werden, aber das geht leider nicht.
Cü,
Kai
@@Kai345:
nuqneH
Rein logisch müßte die id zwar dem html-element zugewiesen werden, aber das geht leider nicht.
In HTML 4.01 nicht, in XHTML 1.0 ja.
Qapla'
@@Struppi:
nuqneH
<body <!--[if IE 6]> id="ie6" <![endif]-->>
<body id="<!--[if IE 6]>ie6<![endif]-->">
Ist das in SGML (HTML) erlaubt? In XML (XHTML) ist es jedenfalls verboten. [XML §2.5]
Und keine der beiden Varianten funktioniert. (Jedenfalls nicht im IE 8. Einen 6er hab ich gerade nicht da.)
Wenn schon, dann so:
<!--[if !(IE 6)]><!--><body><!--<![endif]-->
<!--[if IE 6]><body id="ie6"><![endif]-->
Wobei solch eine ID semantischer Unfug ist: Man identifiziert ja nicht den gesamnten Inhalt der Seite ('body'), sondern das Ausgabegerät. Eine Klasse wäre da noch vertretbarer.
Wobei eine Body ID selten gebraucht wird, da das Element sowieso nur einmal vorkommt.
Nein, es kommt bei jeder Seite einer Website vor. All diese werden sinnvollerweise mit dem selben Stylesheet gestylt. Für seitenspezifische Angaben ist eine ID des 'body' (bzw. 'html') sinnvoll.
Qapla'