Browserweiche
mbartelt
- html
0 ChrisB0 Cheatah3 suit0 molily
1 Cyx230 Manfred Bartelt0 Cybaer0 Jens Holzkämper0 Cyx23
Hi,
folgender Script ist aus dem PHP-minishowcase (http://minishowcase.net):
<!-- START SCRIPTS/STYLESHEETS FOR IE PC -->
<!--[if IE]>
<link href="styles/gallery_ie.css" rel="stylesheet" type="text/css" media="screen" />
<!--[if gte IE 5.5]>
<style type="text/css">
div#msc_image {
/* IE5.5+/Win - this is more specific
than the IE 5.0 version */
left: expression( ( ignoreMe2 = document.documentElement.scrollLeft ? document.documentElement.scrollLeft : document.body.scrollLeft ) + 'px' );
top: expression( ( ignoreMe = document.documentElement.scrollTop ? document.documentElement.scrollTop : document.body.scrollTop ) + 'px' );
right: auto;
bottom: auto;
}
</style>
<![endif]-->
<![endif]-->
<!-- END SCRIPTS/STYLESHEETS FOR IE PC -->
Wenn ich das ganze validieren lasse, bekomme ich einen Fehler. Ich vermute mal, es liegt an der Verschachtelung.
Wie müßte es denn richtig sein ? Danke für Eure Hilfe.
Grüße
Manfred
Hi,
Wenn ich das ganze validieren lasse, bekomme ich einen Fehler.
Schön, dass du ein Geheimnis für dich behalten kannst.
MfG ChrisB
Grundlage für Zitat #1439.
Hier die Fehlermeldungen:
Validation Output: 7 Errors
Line 39, Column 7: invalid comment declaration: found delimiter "[" outside comment but inside comment declaration
<!--[if gte IE 5.5]>✉
Line 37, Column 1: comment declaration started here
<!--[if IE]> Line 39, Column 8: character data is not allowed here
<!--[if gte IE 5.5]>✉
You have used character data somewhere it is not permitted to appear. Mistakes that can cause this error include:
•putting text directly in the body of the document without wrapping it in a container element (such as a <p>aragraph</p>), or
•forgetting to quote an attribute value (where characters such as "%" and "/" are common, but cannot appear without surrounding quotes), or
•using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML.
Line 50, Column 6: "endif" is not a reserved name
<![endif]-->✉
Line 50, Column 11: character data is not allowed here
<![endif]-->✉
You have used character data somewhere it is not permitted to appear. Mistakes that can cause this error include:
•putting text directly in the body of the document without wrapping it in a container element (such as a <p>aragraph</p>), or
•forgetting to quote an attribute value (where characters such as "%" and "/" are common, but cannot appear without surrounding quotes), or
•using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML.
Line 51, Column 5: "endif" is not a reserved name
<![endif]-->✉
Line 39, Column 4: XML Parsing Error: Comment not terminated
<!--[if gte IE 5.5]>✉
Line 51, Column 2: XML Parsing Error: StartTag: invalid element name
<![endif]-->
Hier die Fehlermeldungen:
Du solltest dich schlau machen, welchen Zeichenketten innerhalb eines HTML-Kommentars nicht vorkommen sollen.
Hi,
Wenn ich das ganze validieren lasse, bekomme ich einen Fehler. Ich vermute mal, es liegt an der Verschachtelung.
es gibt keine Verschachtelung. Die ersten "--" innerhalb des Kommentars beenden diesen.
Wie müßte es denn richtig sein ?
Gar nicht. Benutze CSS-Hacks.
Cheatah
»» Wie müßte es denn richtig sein ?
Gar nicht. Benutze CSS-Hacks.
Wozu? Warum nicht einfach die Verschachtelung auflösen?
if ie
ie-css einbinden
end if
if gte ie 5.5
anderes zeug für ie >= 5.5
end if
Wobei:
Ich kann mir nicht vorstellen, dass es sinnvoll ist, einen IE 8 mit demselben CSS zu füttern, welches auch ein IE 5.5 erhält.
Ebenso ist der IE 5 mittlerweile so ausgestorben, dass man den nun wirklich nicht mehr beachten muss.
Hi,
»» Benutze CSS-Hacks.
Wozu?
um Conditional Comments zur Einbindung von CSS-Code zu vermeiden. Das ist Grund genug.
Cheatah
um Conditional Comments zur Einbindung von CSS-Code zu vermeiden. Das ist Grund genug.
Das hatten wir doch schon öfter - du bist äußerst militant und versuchst deine Meinung durchzusetzen, indem du Fakten verschweigst. Ob nun Conditional Comments oder Hacks die bessere Lösung sind, sei dahingestellt.
Deine Antwort "Gar nicht." suggeriert jedenfalls, dass es mit Conditional Comments nicht möglich sei, das Vorhaben des OP durchzusetzen.
Hi,
»» um Conditional Comments zur Einbindung von CSS-Code zu vermeiden. Das ist Grund genug.
Das hatten wir doch schon öfter - du bist äußerst militant und versuchst deine Meinung durchzusetzen, indem du Fakten verschweigst.
ich halte es nicht für zielführend, unter Zuhilfenahme von Lügen zu argumentieren. Fakten verschweige ich nicht. Die meisten Argumente pro Conditional Comments zur Einbindung von CSS halten einer näheren Betrachtung lediglich nicht stand - und einige davon sind schlichtweg bescheuert.
Ob nun Conditional Comments oder Hacks die bessere Lösung sind, sei dahingestellt.
Es gibt ziemlich genau ein Argument, das für CC spricht: wenn andere Mittel nicht zur Verfügung stehen. Andernfalls haben sie in aller Regel erst dann Vorteile, wenn ihre Nachteile über alle Maßen gewachsen sind.
Deine Antwort "Gar nicht." suggeriert jedenfalls, dass es mit Conditional Comments nicht möglich sei, das Vorhaben des OP durchzusetzen.
Jeder versteht das, was er verstehen will. Der OP "müsste" es gar nicht machen, weil ein sehr viel besseres Mittel zur Verfügung steht.
Cheatah
Ich kann mir nicht vorstellen, dass es sinnvoll ist, einen IE 8 mit demselben CSS zu füttern, welches auch ein IE 5.5 erhält.
Im Prinzip richtig. Allerdings ignoriert IE 8 die Expressions im standardkonformen Modus. Im Quirksmodus verhält er sich wie IE 5.5. Haarig wirds nur bei X-UA-Compatible: IE=7, da setzt er die Expressions *und* position:fixed um. IE7 hat mit der Demo aber keine Probleme, da im JavaScript offenbar noch eine weitere Browserweiche drin ist, die position:fixed nicht für den IE7 vergibt, sodass IE7 mit position:absolute und den top- und left-Expressions bedient wird.
Mathias
Wie müßte es denn richtig sein ?
Gar nicht. Benutze CSS-Hacks.
Lasst die Leute doch einfach mal in Frieden, anstatt sie aggressiv belehren zu wollen. Das wäre schon ein riesiger Fortschritt.
Aber Recht darf natürlich nur einer haben, der hat die Weisheit mit Löffeln gefressen und kann anderen davon einschenken. Nachdem man hier den Bock zum Gärtner gemacht hat, gibt es auch niemanden mehr, der daran Anstoß nehmen könnte.
Man kann dem Forum eigentlich nur wünschen, dass es an dieser Borniertheit zugrunde geht.
Mathias
@@molily:
nuqneH
»» Gar nicht. Benutze CSS-Hacks.
Lasst die Leute doch einfach mal in Frieden, anstatt sie aggressiv belehren zu wollen.
Welcher Teil von „Gar nicht. Benutze CSS-Hacks“ war denn nun aggressiv?
*Kopfschüttel*
Aber Recht […] zugrunde geht.
*Kopfschüttel*
Qapla'
Jemand fragt nach einer Lösung mit Conditional Comments und anstatt eine solche zu geben (siehe suit), versucht man dem Fragesteller seine bevorzugte Alternativtechnik aufzuschwatzen.
Wie heißt es so schön: Kommunikation fail.
Mathias
@@molily:
nuqneH
Jemand fragt nach einer Lösung mit Conditional Comments und anstatt eine solche zu geben (siehe suit), versucht man dem Fragesteller seine bevorzugte Alternativtechnik aufzuschwatzen.
Wie heißt es so schön: Kommunikation fail.
YMMV, aber klares Nö IMHO.
Anderes Beispiel:
Jemand fragt nach einer Lösung mit Frames und anstatt eine solche zu geben, versucht man dem Fragesteller seine bevorzugte Alternativtechnik aufzuschwatzen. Kommt dir bekannt vor?
Oder:
Jemand fragt nach einer Lösung mit eval() und anstatt eine solche zu geben, versucht man dem Fragesteller seine bevorzugte Alternativtechnik aufzuschwatzen. Das würdest du doch tun, oder?
Qapla'
Anderes Beispiel:
Frames [...]
Oder:
eval() [...]
Zu deinen Beispielen - "Gar nicht." wäre in beiden Fällen eine schlechte Antwort.
Natürlich ist es unklug, jemandem (wo es unsinnig ist) weiterhin Frames zu empfehlen - aber so quasi "Vergiss es, das geht überhaupt nicht." zu schreiben, ist kontraproduktiv.
Eine Meinung durchzudrücken oder Hilfe anzubieten, indem man Tatsachen verschweigt, ist einerseits link und andererseits, wenn es rauskommt, besteht die Gefahr, dass es erstrecht gemacht wird.
Eine sinnvolle Antwort bez. der Frame-Frage wäre zu sagen, dass es mit Frames zwar geht aber aus Grund 1, Grund 2 und Grund 2 schlauer ist, die Sache anders zu machen.
Der Fragesteller soll selbst entscheiden, wie er es machen möchte - wenn er dennoch der Meinung ist, Frames sind das Mittel der Wahl: nochmal drauf Hinweisen aber Hilfe anbieten (oder aber aber die Hilfe komplett verweigern - dh garnicht angworten). Jemanden auf eine falsche Fährte bringen ist aber sehr uncool.
Kommunikation ist, wenn zwei Menschen aufeinander eingehen. Wenn ich mit Kopfschmerzen zum Arzt gehe, will ich kein Fußbalsam verschrieben bekommen, nur weil der Arzt meine High-Heels untragbar findest.
Du nimmst hier einen Gegenstandswechsel vor: Es geht nicht darum, dass Fragesteller auf die Vorteile von Alternativtechniken hingewiesen werden. Würde das in angemessenem Kontext getan, ist nichts dagegen einzuwenden.
Jemand fragt nach einer Lösung mit Frames und anstatt eine solche zu geben, versucht man dem Fragesteller seine bevorzugte Alternativtechnik aufzuschwatzen.
Du verwechselst da wohl etwas. In dem genannten anderen Thread wurde dem Fragesteller sehr wohl weitergeholfen und eine Lösung mit Iframes gegeben. Und zusätzlich wurde diese Lösung problematisiert, was zu weiteren Fragen und Antworten geführt hat. Soweit alles cool. Der Kontext war ganz offenbar passend, weil sich der Fragesteller dieser Probleme noch nicht bewusst gewesen ist und noch am Anfang des Aufbaus der Seite steht. Alles in allen haben die zusätzlichen Hinweise dem Fragesteller offenbar weitergeholfen.
Ganz anders hier. Jemand verwendet ein fremdes Fertigscript für eine Bildergalerie und hat gemerkt, dass dessen Code nicht valide ist. Anstatt einfach mal direkt zu antworten »Setz den zweiten CC außerhalb des ersten«, empfiehlt man tatsächlich, das ganze völlig anders umzusetzen. Gründe dafür nennt man nicht (= »die Pro-Argumente halten einer Betrachtung nicht stand«), aber schlägt einen Befehlston an (»Benutze CSS-Hacks«). Genau, der Fragesteller hat sicher Bock, den gesamten PHP-, CSS- und JavaScript-Code der Fertigbibliothek zu überarbeiten! So eine Antwort hat er sich sicher gewünscht!
Jemand fragt nach einer Lösung mit eval() und anstatt eine solche zu geben, versucht man dem Fragesteller seine bevorzugte Alternativtechnik aufzuschwatzen. Das würdest du doch tun, oder?
Ja, unter der Voraussetzung, dass die Alternativlösung
Wenn das nicht gegeben ist, dann würde ich nicht antworten: »eval ist doof. Bau alles von Grund auf neu ohne eval. Ich weiß eine Lösung mit eval, sage sie dir aber nicht. Ätsch!«
Ich denke nicht, dass eines der Kriterien auf das Szenario dieses Threads zutrifft: Es gibt ein funktionsfähiges Script mit funktionsfähigen browserübergreifenden Stylesheets, das einzige Problem ist, dass die CCs dumm verwendet wurden. Was hilft da der argumentfreie Hinweis auf eine konzeptionell völlig andere Umsetzung, wo der Fragesteller doch nur den Validierungsfehler beseitigen will?
Wie gesagt, »gut gemeinte« Ratschläge, nach denen nicht gefragt wurde und die mit der Lösung des Problems nur sekundär zu tun haben, kann man gerne *zusätzlich* geben. Samt Begründungen, warum das die Sache des Fragestellers signifikant vereinfachen würde.
Die CC- vs. Hacks-Diskussion ist schlicht eine andere als Frames vs. Nicht-Frames oder eval vs. Nicht-eval. Es sind zwei im in ihrem Funktionsumfang ähnliche, weit verbreitete und etablierte Techniken, die letztlich beide zum Ziel führen. Sie geben sich vergleichsweise wenig im Vergleich zu den genannten anderen Oppositionen, wo einfach massive Unterschiede bestehen. Die Probleme von Frames und eval liegen in einer anderen Kategorie als die von CCs bzw. eingebetteten Hacks. Da gehts eher um effiziente Projektverwaltung, aber nicht um massive Zugänglichkeits-, Performance- oder Sicherheitsprobleme.
Mathias
Hi,
Welcher Teil von „Gar nicht. Benutze CSS-Hacks“ war denn nun aggressiv?
Kein Teil. Alles! :-/
Gleiche Antwort, nicht aggressiv: "Baue so um, daß kein '--' innerhalb eines Kommentares vorkommt. Ich persönlich ziehe allerdings CSS-Hacks den CCs vor."
Bei Cheatahs Formulierung stört auch mich nicht nur die Aggressivität, sondern sie stellt auch außer Frage, daß seine Vorstellung die "richtige" sei. Ob CSS-Hacks (= Ausnutzung von Browserfehlern, deren Auswirkungen so unbekannt sind, daß man meint, sie generell verwenden zu können) nun wirklich das "richtige" Mittel sind, ist allerdings ziemlich umstritten.
AFAIR auch in diesem Forum.
Das einzige, was wirklich sicher ist, ist, daß Cheatah *nicht* immer "Recht" hat.
*Kopfschüttel*
Dito.
Gruß, Cybaer
@@Cybaer:
nuqneH
»» Welcher Teil von „Gar nicht. Benutze CSS-Hacks“ war denn nun aggressiv?
Kein Teil. Alles! :-/
Jetzt wo du’s sagst, spüre ich ganz deutlich das Messer zwischen meinen Rippen. ;->
Bei Cheatahs Formulierung stört auch mich nicht nur die Aggressivität, sondern sie stellt auch außer Frage, daß seine Vorstellung die "richtige" sei.
Ach komm, wenn du deine Spatzenkanone auffährst, klingt das auch nicht anders. Das mag nicht übertrieben freundlich sein, aber Aggressivität kann ich darin nicht finden.
Ob CSS-Hacks (= Ausnutzung von Browserfehlern, deren Auswirkungen so unbekannt sind, daß man meint, sie generell verwenden zu können)
Du meinst, jemand könnte in ferner Zukunft auf die Idee kommen, einen Browser so zu implementieren, dass er bei '* html p
' alle 'p'-Elemente selektiert, obwohl html nicht Nachfahre eines anderen Elements ist? Nein, davon ist nicht auszugehen.
Das macht ja den '* html
'-Hack spezifisch für IE < 7 – für alle Zeiten.
Qapla'
Du meinst, jemand könnte in ferner Zukunft auf die Idee kommen, einen Browser so zu implementieren, dass er bei '
* html p
' alle 'p'-Elemente selektiert, obwohl html nicht Nachfahre eines anderen Elements ist? Nein, davon ist nicht auszugehen.Das macht ja den '
* html
'-Hack spezifisch für IE < 7 – für alle Zeiten.
Nein, macht es nicht - es gibt genügend "junge" Browser die CSS teilweise sehr mangelhaft umsetzen - Dillo, um nur ein Beispiel zu nennen. Es ist auf keinen Fall auszuschließen, dass irgend ein künftiger Browser denselben Fehler "implementiert". Das ist zwar äußerst unwahrscheinlich, aber es ist eben NICHT auszuschließen.
@@suit:
nuqneH
Nein, macht es nicht - es gibt genügend "junge" Browser die CSS teilweise sehr mangelhaft umsetzen - Dillo, um nur ein Beispiel zu nennen.
Wie verbreitet sind die? Wie werden sich fehlerhafte Browser am Markt durchsezten?
Es ist auf keinen Fall auszuschließen, dass irgend ein künftiger Browser denselben Fehler "implementiert". Das ist zwar äußerst unwahrscheinlich, aber es ist eben NICHT auszuschließen.
Mit demselben Argument könnte man auch sagen, dass es nicht auszuschließen ist, dass irgendwelche hypothetischen Browser auf conditional comments ansprechen.
Qapla'
Wie verbreitet sind die? Wie werden sich fehlerhafte Browser am Markt durchsezten?
Der Verbreitungsgrad spielt keine Rolle:
Web Content Accessibility Guidelines (WCAG) 2.0
Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Besonders neue Geräte - wie etwa Handhelds oder Mobiltelefone mit diversen Exotenbrowsern fallen hier rein.
Mit demselben Argument könnte man auch sagen, dass es nicht auszuschließen ist, dass irgendwelche hypothetischen Browser auf conditional comments ansprechen.
Nein, das Argument ist schon sehr weit hergeholt - Conditional Comments stellen gewöhnliche HTML Kommentare dar - erst eine ausdrücklich eingebaute Logik wertet sie aus.
Bei Hacks verhält sich das genau umgekehrt: die funktionieren nicht durch ausdrücklich eingebaute Funktionen sondern durch Mängel.
Yerf!
» Nein, macht es nicht - es gibt genügend "junge" Browser die CSS teilweise sehr mangelhaft umsetzen - Dillo, um nur ein Beispiel zu nennen.
Wie verbreitet sind die? Wie werden sich fehlerhafte Browser am Markt durchsezten?
Wie kann ich den Browser auf meiner PS3 durch Opera (oder einen anderen) ersetzen?
Mit demselben Argument könnte man auch sagen, dass es nicht auszuschließen ist, dass irgendwelche hypothetischen Browser auf conditional comments ansprechen.
Hier ist es aber *extrem* unwahrscheinlich, dass sie dabei auch das Schlüsselwort "IE" mit übernehmen und kein eigenes verwenden... CCs sind ein absichtlich implementiertes Feature, Hacks beruhen auf Implementierungsfehlern, die sich an anderer Stelle wiederholen könnten.
Der Hauptgrund für mich CCs zu bevorzugen ist aber, dass ich damit den propritären Code für den IE vor anderen Browsern komplett verstecken kann und somit keine Wewchselwirkungen auftreten können (z.B. die Problematik mit manchen Expressions und Safari)
Gruß,
Harlequin
Tach,
Du meinst, jemand könnte in ferner Zukunft auf die Idee kommen, einen Browser so zu implementieren, dass er bei '
* html p
' alle 'p'-Elemente selektiert, obwohl html nicht Nachfahre eines anderen Elements ist? Nein, davon ist nicht auszugehen.
Fehler passieren; da dieser Fehler bereits einmal passiert ist, denke ich dass auch später mal ein Programmierer diesen Fehler machen kann.
mfg
Woodfighter
Hi,
»» »» Welcher Teil von „Gar nicht. Benutze CSS-Hacks“ war denn nun aggressiv?
»» Kein Teil. Alles! :-/
Jetzt wo du’s sagst, spüre ich ganz deutlich das Messer zwischen meinen Rippen. ;->
Gut, dann dreh ich nochmal um! ;->
Ach komm, wenn du deine Spatzenkanone auffährst, klingt das auch nicht anders.
Hmm, ich denke einfach, daß man *alle* Alternativen aufzeigen sollte. Mit Stärken und Schwächen.
Der Fragesteller kann dann die für ihn passende Alternative wählen, und gut ist. Zudem hat er vielleicht was hinzu gelernt, hat und bei der nächsten Gelegenheit eine Möglichkeit, dieses neues Wissen einzusetzen.
Aber ich wiederhole mich.
Und was die CSS-Hacks & CCs angeht: Darüber kann IMHO streiten. Worüber man *nicht* streiten kann, ist, daß *ich* mich *niemals* auf "unspezifizierte Fehler" verlassen werde!
Aber: Jeder wie er's mag! Echt, und ohne Groll. :)
Gruß, Cybaer
Hallo,
Wenn ich das ganze validieren lasse, bekomme ich einen Fehler. Ich vermute mal, es liegt an der Verschachtelung.
Oder entspr. Cheatah an der doch nicht erfolgten Verschachtelung.
Also würde ich es mal so versuchen:
<!--[if IE]>
<link href="styles/gallery_ie.css" rel="stylesheet" type="text/css" media="screen" />
<![if gte IE 5.5]>
und
<![endif]>
<![endif]-->
Grüsse
Cyx23
Hi,
Also würde ich es mal so versuchen:
<!--[if IE]>
<link href="styles/gallery_ie.css" rel="stylesheet" type="text/css" media="screen" />
<![if gte IE 5.5]>
>
> und
>
> ~~~html
<![endif]>
> <![endif]-->
Grüsse
Cyx23
»»
und genau der geht nicht:
[code lang=html]
<!--[if IE]>
<link href="styles/gallery_ie.css" rel="stylesheet" type="text/css" media="screen" />
<!--[if gte IE 5.5]>
<style type="text/css">
div#msc\_image {
/\* IE5.5+/Win - this is more specific
than the IE 5.0 version \*/
left: expression( ( ignoreMe2 = document.documentElement.scrollLeft ? document.documentElement.scrollLeft : document.body.scrollLeft ) + 'px' );
top: expression( ( ignoreMe = document.documentElement.scrollTop ? document.documentElement.scrollTop : document.body.scrollTop ) + 'px' );
right: auto;
bottom: auto;
}
</style>
<![endif]-->
<![endif]-->
[code lang=html]
Hi,
und genau der geht nicht:
Warum verschachtelst Du überhaupt?
Ansonsten: Dir ist bewußt, daß der IE 8 einen großen Schritt in Sachen CSS gemacht hat? Auch unterstützt er keine CSS-Expressions mehr. (beides, sofern nicht alte IEs emuliert werden.) Insofern wundere ich mich über CSS für alle IEs >=5.5, der "normales" CSS enthält und geleichzeitig Expressions.
Gruß, Cybaer
Tach,
und genau der geht nicht:
könnte es an der mangelnden Genauigkeit liegen?
<![if gte IE 5.5]>
vs.
<!--[if gte IE 5.5]>
mfg
Woodfighter
Hallo,
und genau der geht nicht:
Genau deswegen von mir der andere Code.
Grüsse
Cyx23