nicht angemeldet Beat
Gunnar Bittersmann
Beat
Gunnar Bittersmann
Auge
Auge
Gunnar Bittersmann
Auge
Gunnar Bittersmann
Gunnar Bittersmann
suit
Hallo,
auf twitter gehört http://www.catswhocode.com/blog/top-10-best-practices-for-front-end-web-developers - manches kannt ich schon, anderes nicht (z.b. css-reset und smush).
Gruß
jobo
Bei "Place Javascript file at the bottom" sollte man aber Ausnahmen machen. Spontan fällt mir da focus ein, was ja schon oft genug ungünstigerweise mit onload im body realisiert wird.
Bei "Place Javascript file at the bottom" sollte man aber Ausnahmen machen. Spontan fällt mir da focus ein, was ja schon oft genug ungünstigerweise mit onload im body realisiert wird.
Typisch kopfloser Mashup-Artikel.
Das Tolle ist, dass der Artikel gegen sich selbst verstösst.
Die Regel "Don’t mix CSS with HTML" verstösst gegen den Beispielcode zur Regel "Explain which div you’re closing"
Was ich von CSS-Reset halte, brauche ich nicht zu erläutern.
Insbesondere vermisse ich die folgenden primären Best-Practices.
-Validiere deinen Code.
-Liefere HTML im Standardsmode aus.
mfg Beat
@@Beat:
nuqneH
Typisch kopfloser Mashup-Artikel.
Naja, die Mehrheit der Hinweise ist schon nicht von der Hand zu weisen.
Das Tolle ist, dass der Artikel gegen sich selbst verstösst.
Die Regel "Don’t mix CSS with HTML" verstösst gegen den Beispielcode zur Regel "Explain which div you’re closing"
"Use conditional comments" verstößt gegen "Don’t mix CSS with HTML".
Was ich von CSS-Reset halte, brauche ich nicht zu erläutern.
Was ich von Extra-IE-Stylesheets halte, brauche ich nicht zu erläutern.
Insbesondere vermisse ich die folgenden primären Best-Practices.
-Validiere deinen Code.
-Liefere HTML im Standardsmode aus.
Die Hinweise von RussellUresti sind auch nicht zu verachten, besonders der erste und der letzte. Der zweite erübrigt sich, wenn man seine Ressourcen komprimiert ausliefert, was wohl die vorzuziehende Variante wäre.
Qapla'
"Use conditional comments" verstößt gegen "Don’t mix CSS with HTML".
Was ich von CSS-Reset halte, brauche ich nicht zu erläutern.
Was ich von Extra-IE-Stylesheets halte, brauche ich nicht zu erläutern.
CCs für @import finde ich tatsächlich schlecht.
Ich bevorzuge es CCs, für eine eigene #msid zu setzen.
Für weniger Gelernte ist es klarer zu schreiben
#msie7 someselector {}
mfg Beat
Ich bevorzuge es CCs, für eine eigene #msid zu setzen.
Für weniger Gelernte ist es klarer zu schreiben
#msie7 someselector {}
Verstehe ich dich richtig du machst:
Struppi
apsel(...)
<body>
<!--IF IE>
<div id="msie">
<![endif]-->
<normaler HTML-Code />
<!--IF IE>
</div>
<![endif]-->
</body>
Egal wie deine Antwort lautet: Ich find' den Gedanken erst mal ziemlich cool! Hab mir jetzt aber noch keine näheren Gedanken dazu gemacht, aber erste Reaktion: "tolle Idee!".
@@Deus Figendi:
nuqneH
Verstehe ich dich richtig du machst:
(...)
<body>
<!--IF IE>
<div id="msie">
<![endif]-->
<normaler HTML-Code />
<!--IF IE>
</div>
<![endif]-->
</body>
Vermutlich eher
~~~html
<!--[if IE lt 6]><body id="msie5"><![endif]-->
<!--[if IE 6]><body id="msie6"><![endif]-->
<!--[if IE 7]><body id="msie7"><![endif]-->
<!--[if IE 8]><body id="msie8"><![endif]-->
<!--[if !IE]><!--><body><!--<![endif]-->
Wobei ich hier eine Klasse passendender fände als eine ID.
Qapla'
@@Beat:
nuqneH
Ich bevorzuge es CCs, für eine eigene #msid zu setzen.
Für weniger Gelernte ist es klarer zu schreiben
#msie7 someselector {}
*+html someselector /* für IE 7 */ {}
ist genauso klar. Und man spart sich die CCs.
Qapla'
Hi,
*+html someselector /* für IE 7 */ {}
ist genauso klar. Und man spart sich die CCs.
woher weisst Du, wie künftige Browsergenerationen solche Hacks interpretieren. Imho evil.
Gruesse, Joachim
@@Joachim:
nuqneH
woher weisst Du, wie künftige Browsergenerationen solche Hacks interpretieren.
Standardkonform: 'html' hat kein Elternelement, also selektiert '*+hmtl foo' nichts.
„Sollte irgendein hypothetischer Browser den Fehler begehen […]“ [icke, 2009-08
„Klar könnten Browserimplementatoren den Fehler begehen […]“ [icke, 2009-06]
Imho evil.
Nein.
Qapla'
Hi,
also selektiert '*+hmtl foo' nichts.
Glaub ich gerne, dass 'hmtl' nix selektiert;-)
„Klar könnten Browserimplementatoren den Fehler begehen […]“ [icke, 2009-06]
Nun, vermutlich wird eher der Nutzer eines solchen - möglicherweise auf seinem Handy vorinstallierten - Browsers einfach nicht mehr die fragliche Seite nutzen. Warum also Hacks nutzen, wenn es eine Alternativen mit sauberer Trennung gibt? Man kann es kaum noch übersichtlich nennen, wenn das Stylesheet mit solchen Sonderangaben für verschiedene IE-Versionen zugemüllt wird.
Nein.
Doch! Immer 2x mehr als Du!
;-)
Gruesse, Joachim
Die Hinweise von RussellUresti sind auch nicht zu verachten, besonders der erste und der letzte. Der zweite erübrigt sich, wenn man seine Ressourcen komprimiert ausliefert, was wohl die vorzuziehende Variante wäre.
Naja, Minification (zumindest "Minify") legt Dateien auf Wunsch auch zusammen, also bspw. alle CSS- oder alle JS-Dateien zu je einer einzigen. Das hilft mir enorm beim Ordnung halten. Und diese Datei dann komprimieren, macht natuerlich Sinn. Darum ist mir der zweite Punkt auch wichtig :-)
Eddie
hallo
Die Hinweise von RussellUresti sind auch nicht zu verachten, besonders der erste und der letzte.
Den letzten kapier ich nicht so ganz.
"3. Don’t use JS to modify styles (like using the .css() function in jQuery), but rather append class names that have those styles attached."
Was ist das Ausgangsproblem, was ist die nicht so tolle Lösung und was empfielt er stattdessen? Ein kl. Bsp wäre super :)
ciao karl
Hallo
Die Hinweise von RussellUresti sind auch nicht zu verachten, besonders der erste und der letzte.
Den letzten kapier ich nicht so ganz.
"3. Don’t use JS to modify styles (like using the .css() function in jQuery), but rather append class names that have those styles attached."Was ist das Ausgangsproblem, was ist die nicht so tolle Lösung und was empfielt er stattdessen? Ein kl. Bsp wäre super :)
Anstatt mit JavaScript CSS-Eigenschaften zu setzen, was in Inlinestyles resultiert, soll man dem betreffenden Element eine Klasse oder eine ID zuweisen, für die in der externen Stylesheet-Datei die gewünschten Eigenschaften schon definiert sind.
Tschö, Auge
[latex]Mae govannen![/latex]
Den letzten kapier ich nicht so ganz.
"3. Don’t use JS to modify styles (like using the .css() function in jQuery), but rather append class names that have those styles attached."Was ist das Ausgangsproblem, was ist die nicht so tolle Lösung und was empfielt er stattdessen? Ein kl. Bsp wäre super :)
Styleänderungen per JS sind (relativ) langsam. Wenn man dahingegen dem Element nur eine Klasse hinzufügt/entzieht, werden alle betroffenen Stles auf einmal geändet.
Als Beispiel ein Wechsel einiger Eigenschaften:
var f = document.getElementByID('foo');
f.style.backgroundColor = 'red';
f.style.color = 'white';
f.style.fontWeight = 'bolder';
und vllt später
var f = document.getElementByID('foo');
f.style.backgroundColor = 'green';
f.style.color = 'yellow';
f.style.fontWeight = 'normal';
einfach
var f = document.getElementByID('foo');
f.className += 'foojs'
bzw.
f.className.replace(/(^|\s)foojs($|\s)/i, '')
und als css
#foo {
background-color: green;
color: yellow;
font-weight: normal;
}
#foo.foojs {
background-color: red;
color: white;
font-weight: bolder;
}
Cü,
Kai
Hallo
Styleänderungen per JS sind (relativ) langsam. Wenn man dahingegen dem Element nur eine Klasse hinzufügt/entzieht, werden alle betroffenen Stles auf einmal geändet.
Achso, also man "darf" schon per JS den style ändern, sollte aber nicht jedes Attribut einzeln ändern sondern "auf einen Rutsch" durch Zuweisung einer anderen Klasse. Habe ich das so richtig verstanden?
Vielen Dank :)
Hallo
Styleänderungen per JS sind (relativ) langsam. Wenn man dahingegen dem Element nur eine Klasse hinzufügt/entzieht, werden alle betroffenen Stles auf einmal geändet.
Achso, also man "darf" schon per JS den style ändern, sollte aber nicht jedes Attribut einzeln ändern sondern "auf einen Rutsch" durch Zuweisung einer anderen Klasse. Habe ich das so richtig verstanden?
Jein, also nicht ganz. Du änderst keine Styles (nach Möglichkeit nie und nimmer nicht) sondern Klassen oder IDs, denen CSS-Eigenschaften zugewiesen sind.
Tschö, Auge
@@Auge:
nuqneH
Jein, also nicht ganz. Du änderst keine Styles (nach Möglichkeit nie und nimmer nicht) sondern Klassen oder IDs, denen CSS-Eigenschaften zugewiesen sind.
Jein, also nicht ganz. Ich kann mir gerade keinen Anwendungsfall vorstellen, wo ein Element seine Identität ändern sollte.
Qapla'
Hallo
Jein, also nicht ganz. Du änderst keine Styles (nach Möglichkeit nie und nimmer nicht) sondern Klassen oder IDs, denen CSS-Eigenschaften zugewiesen sind.
Jein, also nicht ganz. Ich kann mir gerade keinen Anwendungsfall vorstellen, wo ein Element seine Identität ändern sollte.
Nun ja, es könnte eine bekommen, so es vorher noch keine hatte, aber ja, der Fall ist recht unwahrscheinlich (wenn auch nicht unmöglich, daher die Erwähnung).
Tschö, Auge
Jein, also nicht ganz. Du änderst keine Styles (nach Möglichkeit nie und nimmer nicht) sondern Klassen oder IDs, denen CSS-Eigenschaften zugewiesen sind.
super, danke für die Erklärung :-)
@@Texter mit x:
nuqneH
Bei "Place Javascript file at the bottom" sollte man aber Ausnahmen machen. Spontan fällt mir da focus ein, was ja schon oft genug ungünstigerweise mit onload im body realisiert wird.
Wie meinen? Ich kann dir nicht folgen.
Bei JavaScript am Ende des 'body' kann man auf einige Eventhandler verzichten; das DOM ist ready.
Qapla'
Bei "Place Javascript file at the bottom" sollte man aber Ausnahmen machen. Spontan fällt mir da focus ein, was ja schon oft genug ungünstigerweise mit onload im body realisiert wird.
Wie meinen? Ich kann dir nicht folgen.
Bei JavaScript am Ende des 'body' kann man auf einige Eventhandler verzichten; das DOM ist ready.
Ebenfalls. (Ich kenne mich mit javascript immer noch nicht aus (aber denken kann ich).)
Ein focus auf ein Eingabefeld wird häufig mit onload in <body> realisiert. Das ist Mist, weil man, während die Seite noch lädt, schon woanders hinklicken könnte und das focus einem dann den Cursor wieder klaut. Also sollte das focus möglichst früh gesetzt werden, gleich nach dem entsprechenden Eingabefeld.
Daraus ergibt sich für mich _unausweichlich_, daß unter Umständen javascript am Ende Mist ist, denn es kann nicht ausgeführt werden wenn es noch nicht geladen ist. Lösuchg: Ausnahme von der Regel.
@@Texter mit x:
nuqneH
Ein focus auf ein Eingabefeld wird häufig mit onload in <body> realisiert. Das ist Mist, weil man, während die Seite noch lädt, schon woanders hinklicken könnte und das focus einem dann den Cursor wieder klaut. Also sollte das focus möglichst früh gesetzt werden, gleich nach dem entsprechenden Eingabefeld.
Du meinst das so?
<input id="foo"/>
<script type="text/javascript">[code lang=javascript]document.getElementById("foo").focus()
~~~</script>
<input id="bar"/>[/code]
Da sei die generelle Überlegung in den Raum geworfen, ob das Setzen des Fokus in die Verhaltensschicht oder nicht doch in die Markupschicht gehört. HTML5 [[HTML5 §4.10.19.4](http://dev.w3.org/html5/spec/forms.html#autofocusing-a-form-control)]:
~~~html
<input id="foo" autofocus="autofocus"/>
<input id="bar"/>
(Webkits und Opera können’s schon.)
Daraus ergibt sich für mich _unausweichlich_, daß unter Umständen javascript am Ende Mist ist
Ja. Ein solcher Umstand ist das Setzen einer Klasse fürs 'html'-Element. [PERFORMANCE-BP2]
Qapla'
Du meinst das so?
<input id="foo"/>
<script type="text/javascript">[code lang=javascript]document.getElementById("foo").focus()
> <input id="bar"/>[/code]
Ich habe es vorsichtshalber erst hinter </form> eingefügt und die Zeile sieht anderes aus auch nutze ich keine ID, sondern name aber ja, im Prinzip so.
~~~html
<form action="./" name="foo" ...
<input name="bar" ...
...
</form>
<script language="JavaScript" type="text/JavaScript">[code lang=javascript]window.onload = document.foo.bar.focus();
~~~</script>[/code]
Ist daran was schlecht?
> (Webkits und Opera können’s schon.)
Schön für die Beiden. :-)
Hallo,
Bei "Place Javascript file at the bottom" sollte man aber Ausnahmen machen. Spontan fällt mir da focus ein, was ja schon oft genug ungünstigerweise mit onload im body realisiert wird.
http://www.slideshare.net/douglascrockford/crockford-on-javascript-episode-iv-the-metamorphosis-of-ajax (douglas crockford platziert seine javascripts auch am ende).
Gruß
jobo
@@jobo:
nuqneH
auf twitter gehört http://www.catswhocode.com/blog/top-10-best-practices-for-front-end-web-developers
Die Überschrift des Artikels hätte heißen müssen: Top 10 best and worst practices for front-end web developers. Und dumm auch, dass die best practices und worst practices weder nach solchen geordnet noch als solche gekennzeichnet sind.
Use a CSS reset? Nein. [Meiert]
Use conditional comments? Nein. [Meiert]
Allerdings auch nicht solche Hacks wie
foo
{
height: 200px; /* normal browsers */
_height: 300px; /* IE6 */
.height: 250px; /* IE7 */
*height: 350px; /* All IEs */
}
sondern
foo
{
height: 200px; /* normal browsers */
}
* html foo
{
height: 300px; /* IE6 */
}
*+html foo
{
height: 250px; /* IE7 */
}
Qapla'
Hallo,
Use a CSS reset? Nein. [Meiert]
"Modifizieren Sie Reset-Stylesheets: ... Um Reset-Stylesheets richtig zu verwenden, müssen sie modifiziert und vernünftig integriert werden." ???
Und Eric Meyer himself sagte in dem verlinkten Artikel dazu:
"In other words, this is a starting point, not a self-contained black box of no-touchiness." (http://meyerweb.com/eric/tools/css/reset/index.html).
Use conditional comments? Nein. [Meiert]
Der best-practice-Artikel sagt: "You know it, IE sucks, and some clients suck even more by requiring you to create webpages which are compatible with this obsolete browser. To target specific versions of IE, you can use the well known IE hacks, as shown below:"
Allerdings auch nicht solche Hacks wie
foo
{
height: 200px; /* normal browsers /
_height: 300px; / IE6 /
.height: 250px; / IE7 */
height: 350px; / All IEs */
}
>
> sondern
>
> ~~~css
foo
> {
> height: 200px; /* normal browsers */
> }
>
> * html foo
> {
> height: 300px; /* IE6 */
> }
>
> *+html foo
> {
> height: 250px; /* IE7 */
> }
Ich check den Unterschied und die Wartbarkeitsproblematik nicht.
Gruß
jobo
Allerdings auch nicht solche Hacks wie
foo
{
height: 200px; /* normal browsers /
_height: 300px; / IE6 /
.height: 250px; / IE7 */
height: 350px; / All IEs */
}
und ich frag mich, wann solche Angaben nötig sind?
Das letzte Mal als ich über dieses Thema mitdiskutiert hatte, konnte niemand darauf eine Antwort geben. Aber wir können ja mal gucken, was so tolles in den CC Dateien steht. z.b.
last.fm benutzt eine Datei für den ie6:
http://cdn.last.fm/css/release-i18n/151594/ie/ie6.css
Darin enthalten zwei! Angaben, einmal ein png Workaround und die andere Angabe wäre nicht mal nötig, da dieses Formular auch mit block statt inline-block formatiert werden könnte.
Dann hab ich gesucht und gesucht, aber nirgendwo eine separate IE Datei gefunden:
stackoverflow: -
twitter: -
youtube:-
smashing magazine:-
a list apart:-
Ich verstehe nicht, wer, warum wirklich eine (oder gar mehrere) separate CSS Dateien erzeugen will.
Struppi.
Das letzte Mal als ich über dieses Thema mitdiskutiert hatte, konnte niemand darauf eine Antwort geben.
Psst: Vermutlich weil niemand Lust hat, auf diese Weise darüber zu diskutieren. So lässt sich natürlich auch ein Konsens herstellen.
Mathias
Das letzte Mal als ich über dieses Thema mitdiskutiert hatte, konnte niemand darauf eine Antwort geben.
Psst: Vermutlich weil niemand Lust hat, auf diese Weise darüber zu diskutieren. So lässt sich natürlich auch ein Konsens herstellen.
Wieso? Meine Frage nach typischen Beispielen, warum es mehrere CSS Dateien braucht, ist keine Diskussion, sondern ein Versuch zu verstehen wozu diese nötig sind.
Da ich selten mehr als ein oder zwei Hacks brauche, halte ich separate Dateien für überflüssig. Was zumindest meine Nachforschungen bestätigt haben. Du hast doch auch deiner Seite auch kein IE Stylesheet?
Struppi.
Hallo,
ich bezog mich vielmehr darauf, warum sich allgemein zu dem Thema niemand mehr zu Wort melden will.
Zu deinem Posting konkret: Ich verstehe dein Argument nicht. Du listest einige große Sites auf, die kein oder nur ein kleines separates IE-Stylesheet haben. Okay. Aber schaue in die regulären Stylesheets rein, finde ich dort (sogar zusätzlich zu einem separaten IE-Stylesheet) dutzende Inline-Hacks, von _eigenschaft über *eigenschaft zu * html und *+html. Aus eigener Erfahrung weiß ich, dass es viele Bugs gibt, die man ohne sichtbare Hacks (also Weichen), sondern mit Standard-CSS umschiffen kann (z.B. padding statt margin oder umgekehrt, feste Breiten/Höhen, eine harmlose Eigenschaft, die als Nebeneffekt hasLayout auslöst usw.). Daher gehe ich davon aus, dass die großen Sites zudem massig dieser unsichtbaren Fixes einsetzen bzw. Browserbugs erst gar nicht auszulösen versuchen. Oder wie MySpace derartig anachronistisches Tabellenlayout verwenden, dass sie auf CSS-Fixes verzichten können.
Und ehrlich gesagt rate ich jedem, der eine große Site baut, IE-Kram möglichst separat einzubinden und auch keinesfalls »unsichtbare« Hacks einzubauen. Schau dir Youtube an, die wollen den IE6-Support beenden. Das geht nur, wenn der IE-spezifische Code lokalisierbar ist und problemlos herausgezogen werden kann. Klar, das kann man mit Regeln, die mit »* html« beginnen, auch, aber per separatem IE6-Stylesheet ist das noch einfacher.
Hinter Xing steht übrigens Ingo Chao als Frontend-Architekt und dessen Philosophie bezüglich IE kann man im seinem m.M.n. hervorragenden Buch nachlesen; eines der besten deutschsprachigen CSS-Bücher, welches einem viel über robustes und wartbares CSS vermittelt. Chao ist lediglich nicht so »laut« wie Meiert.
Was ich hier schon einmal vor geraumer Zeit verlinkt habe, sind die Stylesheets von InterNations.org, einer größeren Site, die unter meiner Federführung zur Jahreswende 2008/2009 redesigned wurde. (Man sieht davon nicht viel, es ist ein invite-only Social Network.)
http://www.internations.org/static/css/ie/ie.css
http://www.internations.org/static/css/ie/ie6.css
http://www.internations.org/static/css/ie/ie7.css
Richtig, das ist aufs Ganze gesehen ziemlich wenig - das geminifyte Master-Stylesheet ist 156KB groß. Dagegen sind diese paar Regeln nichts. Und sicher hätte man es noch reduzieren können. (Die obigen Dateien sind noch nicht einmal minified und daher sehr redundant - was bei der Auslieferung dank GZip allerdings nicht stark ins Gewicht fällt.) Aber diese Hacks auf ein Minimum zu reduzieren, um diese Dateien letztendlich abzuschaffen, war für mich als »Architekt« des HTML und CSS dieser Site kein entscheidender Punkt. Natürlich habe ich »defensiv« CSS geschrieben, um das Auslösen und Fixen von IE-Bugs von vornherein zu vermeiden. Diese Arbeit sieht man wie gesagt nicht im End-Stylesheet. Sie ist aber da, auch ohne explizite hasLayout-Trigger udgl.
In der Umgebung, in der ich arbeite, bin ich derjenige, der sich am besten mit IE-Bugfixing auskennt (zumal IE6). Ehrlich gesagt kenne ich außer Leuten wie Ingo Chao sehr wenige - geschweige denn in diesem Forum -, die IE-Probleme korrekt beschreiben und zielgenau korrigieren können. Das nicht als Eitelkeit, sondern nur zu den Umständen solcher Arbeit. Es war bei der besagten Site einfach eine von vielen weiteren Konventionen, auf CCs zu setzen. Wie es als Coding-Guideline auch bei den meisten anderen Sites der Firma, in der ich arbeite, Konvention ist. Und wir fahren in den meisten Fällen sehr gut damit, auch bei hoch frequentierten Sites. Wir wissen um die Nachteile. Vieles davon, was Kritiker wie Meiert nur als Vermutung theoretisch geäußert haben, kann ich - im positiven wie im negativen - in der Praxis bestätigen. Wir wissen daher auch um die Vor- und Nachteile der Alternativen. Im Hauptstylesheet (wo ca. 25 Module zusammenkommen) finden sich aus Bequemlichkeit sicher auch einige zoom:1.
In einem Team Konventionen aufzustellen, zu vermitteln und durchzusetzen (welche Probleme, welche Fixes, wohin mit den Fixes, wie erkenntlich machen und kommentieren) halte ich für viel wichtiger und schwieriger als die Frage nach der konkreten Umsetzung. Da geben sich die Ansätze nicht viel. Und messbare Performanceoptimierung setzt, das hat obige Site gezeigt, noch einmal ganz woanders an. Aber das habe ich hier glaube ich schon vor zwei Jahren geschrieben. Insofern stinkt mir immer noch die Art und Weise, wie dogmatisch oder einfach nur übertrieben skeptisch hier manche reagieren.
Die wenigsten hier haben vermutlich Sites in der Größe von Twitter, Youtube oder SmashingMag umgesetzt und können von konkreten Erfahrungen berichten. Klar, für mickrige Sites wie meine private Homepage brauche ich kein IE-Stylesheet. Da leiste ich mir einfach den Luxus, auf IE-Optimierung komplett zu verzichten. Das ist aber kein Argument für irgendetwas, denn bei kommerziellen Sites oder Sites für IE-Intranets ist das nicht praktikabel. Wenn ich solche Sites baue, selbst kleine, dann erfinde ich jedoch die Coding-Guidelines und die wiederverwendbare Frontend-Struktur, die wir einmal gebaut, getestet, dokumentiert und im Team etabliert haben, nicht neu, nur weil die spezifischen Anforderungen der Site ein Fitzelchen anders sind. Das sind halt menschengemachte Konventionen. Manchmal ist es besser oder zumindest nicht nennenswert nachteilig, ihnen zu folgen, manchmal gehören sie über den Haufen geworfen, weil sie nicht zu den Anforderungen passen. Dass es Ermessensspielräume gibt und geben muss, verstehen auch (fast) alle, wie etwa jobos Posting zeigt.
Mathias
Zu deinem Posting konkret: Ich verstehe dein Argument nicht. Du listest einige große Sites auf, die kein oder nur ein kleines separates IE-Stylesheet haben. Okay. Aber schaue in die regulären Stylesheets rein, finde ich dort (sogar zusätzlich zu einem separaten IE-Stylesheet) dutzende Inline-Hacks, von _eigenschaft über *eigenschaft zu * html und *+html.
Naja, das dürfte in etwa mein Argument gewesen sein. Es ist sinnvoller die Hacks dort zu platzieren wo ein Kontext zum konkreten Element besteht und das, wenn man sich konkret Seiten anschaut, auch viele Beispiele findet wo das so gemacht wird.
Aber letztlich, das sagte ich ja bereits, war das gar kein Argument, sondern eine Frage.
Ich wollte Wissen, welchen Umfang solche Browserworkarounds in einem größeren Projekt annehmen und warum ihr denkt, es ist sinnvoller diese mit einer separaten css Datei zu lösen.
Und ehrlich gesagt rate ich jedem, der eine große Site baut, IE-Kram möglichst separat einzubinden und auch keinesfalls »unsichtbare« Hacks einzubauen.
Die Realität scheint aber eine andere zu sein. Aber du hast Recht mit deinen Anspielungen, ich persönlich baue keine grossen Seiten im Team. Mein größte hat ca. ein Dutzend Stylesheets und ich arbeite ohne Team. In der Größenordnung finde ich es angenehmer keine Extrawurst für die verschiedenen IE Versionen machen zu müssen.
Wenn ich die obige Aussage von dir richtig deute, würdest du mir auch zu genau diesem Vorgehen raten, denn es ist ja keine grosse Seite.
Schau dir Youtube an, die wollen den IE6-Support beenden. Das geht nur, wenn der IE-spezifische Code lokalisierbar ist und problemlos herausgezogen werden kann. Klar, das kann man mit Regeln, die mit »* html« beginnen, auch, aber per separatem IE6-Stylesheet ist das noch einfacher.
Wenn es so ist wie suit sagt, dass bei größeren Projekten das automatisiert stattfindet, dann ist das kein Argument weder dafür noch dagegen.
http://www.internations.org/static/css/ie/ie.css
http://www.internations.org/static/css/ie/ie6.css
http://www.internations.org/static/css/ie/ie7.css
So kann ich das nachvollziehen. Wie gesagt, bei mir waren bisher selten mehr als ein oder zwei Hacks (plus nochmal soviele "unsichtbare" wie du es weiter oben genannt hast) notwendig, daher Bestand bisher noch nicht das dringende Bedürfnis unbedingt ein Extra Stylesheet einzubauen.
Es war bei der besagten Site einfach eine von vielen weiteren Konventionen, auf CCs zu setzen. Wie es als Coding-Guideline auch bei den meisten anderen Sites der Firma, in der ich arbeite, Konvention ist. Und wir fahren in den meisten Fällen sehr gut damit, auch bei hoch frequentierten Sites. Wir wissen um die Nachteile. Vieles davon, was Kritiker wie Meiert nur als Vermutung theoretisch geäußert haben, kann ich - im positiven wie im negativen - in der Praxis bestätigen. Wir wissen daher auch um die Vor- und Nachteile der Alternativen. Im Hauptstylesheet (wo ca. 25 Module zusammenkommen) finden sich aus Bequemlichkeit sicher auch einige zoom:1.
Argument 1: Code Guidlines
Die wenigsten hier haben vermutlich Sites in der Größe von Twitter, Youtube oder SmashingMag umgesetzt und können von konkreten Erfahrungen berichten. Klar, für mickrige Sites wie meine private Homepage brauche ich kein IE-Stylesheet. Da leiste ich mir einfach den Luxus, auf IE-Optimierung komplett zu verzichten. Das ist aber kein Argument für irgendetwas, denn bei kommerziellen Sites oder Sites für IE-Intranets ist das nicht praktikabel.
Da sind jetzt drei Aussgen enthalten:
1. es fehlen konkrete Erfahrungen für grosse Seiten
2. für mickrige Seiten braucht man keine IE Optimierung
3. kommerzielle Seiten müssen eine IE-Optimierung betreiben
Welche konkreten Auswirkungen hat die Größe einer Seite darauf, ob man IE Stylesheets benutzt oder IE Hacks? Du meinst die Anzahl der Leute die daran arbeiten? Wenn die CSS Angaben nicht automatisch erzeugt werden, weiß ich nicht ob das wirklich ein Argument für IE Stylesheets ist. Denn wie findet jemand anderes einen Hack, wenn er nicht mal weiß (wie du ja selber sagst, bist du der einzige der sich mit dem IE auskennt) das es ihn gibt?
Doch nur wenn er ihn sieht.
Aber du hast Recht, ich habe damit noch keine konkreten Erfahrungen mit einem Team gemacht, deshalb frage ich auch nach.
Aber im grossen ganzen gibt mir dein Posting insofern recht, dass wenn hier im Forum jemand fragt kann man i.d.R. davon ausgehen, es "mickrige" Seiten. Allerdings wollen die Leute trotzdem IE Optimerung betreiben und die sind besser beraten Hacks zu verwenden. Zumindest habe ich bisher kein Argument dagegen gehört und aus dem was du schreibst meine ich das herauszulesen.
Es ist also von Bedeutung, einzuschätzen, welche Größenordnung die Seite im konkreten Fall hat und ob und welchen Guidlines der Fragenden unterliegt.
Ich persönlich, werde Hacks weiterhin bevorzugen, da mir die Nähe wichtig ist und mir im Zweifelsfall aber auch den Luxus leiste, IEs nicht zu unterstützen. Was ich heute bereits machen, da ich oft Selektoren verwende, die kein IE kennt. Workarounds für fehlende Selektoren, die dann über zusätzliches Markup gelöst werden müßten, sind in meinen Augen der Horror, genau wie HTML Code varieren per CC
Struppi.
Dann hab ich gesucht und gesucht, aber nirgendwo eine separate IE Datei gefunden:
stackoverflow: -
twitter: -
youtube:-
smashing magazine:-
a list apart:-
Ich finde einfach keine IE Stylesheets:
-Peter Kröner:-
-praegnanz: nein (er schliesst mit einem CC den IE 6 einfach komplett aus)
-technikwürze:-
... und endlich bin ich fündig geworden.
xing nutzt massiv CC für IE Stylesheets. Das meiste für die Transparenz, ein paar wegen hasLayout und ansonsten werden Pixel geschoben. Aber da sieht es schonmal so aus, als ob es sinnvoll sein könnte um diese Angaben als Hack in den anderen Dateien zu pflegen.
Aber im grossen ganzen, zeigt das doch, dass diese Diksussion im Grunde nicht relevant ist. Die meisten brauchen keine separaten Dateien für den IE, viele haben nur ein zwei Zeilen Hacks im Stylesheet und bei ganz wenigen Seiten sind die Anforderungen an den IE so groß, dass es Sinn macht diesen mit CC extra zu bedienen.
Struppi.
Place Javascript file at the bottom...
Cool. Mach ich (demnext).
Images issue: Tja, da gäbs wohl auch noch andere Lösungen, die jedoch daran scheitern, dass die Browser das nicht oder nicht einheitlich können (Preload: Besucher liest Text, im Hintergrund werden die Bilder geladen, als binary in einem object gespeichert und auf Abruf gezeigt).
Hotti
@@hotti:
nuqneH
Place Javascript file at the bottom...
Cool. Mach ich (demnext).
?? Du bist eigentlich schon zu lange hier, um das noch nicht gewusst zu haben. Oft genug verlinkt: [PERFORMANCE-BP2]
Qapla'
moin,
?? Du bist eigentlich schon zu lange hier, um das noch nicht gewusst zu haben. Oft genug verlinkt: [PERFORMANCE-BP2]
"Eine noch relativ junge Erkenntnis ist..."
^ ;-)
Meine Meinung: Wer hunderte k und mehr JS auf jeder Seite braucht, sollte sich darüber Gedanken machen.
Mein Tipp: Lade ein Minimal JS und lade weitere Bibliotheken bei Bedarf nach. Wie das geht, hab ich neulich auf meiner Seite beschrieben:
http://rolfrost.de/jsreload.html
Viele Grüße,
Horst Java
@@hotti:
nuqneH
?? Du bist eigentlich schon zu lange hier, um das noch nicht gewusst zu haben. Oft genug verlinkt: [PERFORMANCE-BP2]
"Eine noch relativ junge Erkenntnis ist..."
^ ;-)
Dass dies das 14. Türchen des Adventskalenders 200_8_ ist, hast du bemerkt?
Viele Grüße,
Horst Java
Tu nicht noch so, als würdest du den Unterschied zwischen JavaScript und Java nicht kennen!
Qapla'
WTF? Syntaxhighlighting, ordentliche Einrückung oder Codefolding reichen.
Hell, no! Auch wenn Eric Meyer das sagt, damit halst man sich unnötig Arbeit auf.
Dem atimme ich zu - aber die genannte alternative ist mindestens genauso dämlich, wenn dann gleich Serverseitig zusammenbauen und komprimieren.
Warum nicht-
Ja.
Ja.
Das kommt auf die Dimension an - bei einer Hand voll korrekturen sind Hacks (aber die sauberen) sicher ok, bei umfangreichen korrekturen sind Conditional Comments wesentlich einfacher handhabbar.
Wozu? Wie der Client die das Dokument bearbeitet bleibt ihm überlassen - unten einbinden garantiert keineswegs, dass die Sache auch tatsächlich später geladen wird.
Frameworks auf ein CDN auslagern und "oben" einbinden ist da wesentlich Zielführender.
"As an example, a navigation menu should always be an unordered list:"
Eigentlich sollte eine Navigation mit dem <menu />-Element ausgezeichnet werden, aber das wurde seltsamerweise als deprecated geflaggt nur um jetzt wieder ein nav-Element mit HTML5 einzuführen um dazu zusätzlich die List einzukasteln.
Warum sollte das Testen wärend des Bauens Fehler vermeiden? Man erkennt Fehler Früher, vermeiden tut man sie dadurch noch lange nicht.
"If you test your documents on Firefox/IE/Chrome while your writing it, cross-browser rendering problems will be much easier to fix."
Ich würde vorschlagen, zum Testen immer einen möglichst Standardnahen Browser zu verwenden - das ist aktuell Opera - dicht gefolgt von Safari und Chrome. Gelegentlichens zwischendurch testen mit etwas einfacheren Browsern wie eben Firefox und antiken Browsern wie z.B. dem Internet Explorer können dann folgen.
Om nah hoo pez nyeetz, suit!
- Explain which div you’re closing
WTF? Syntaxhighlighting, ordentliche Einrückung oder Codefolding reichen.
auch hier kommts auf die Dimension an und manche wären bestimmt froh, wenn NetFusion oder Dreamweaver dies täten.
Matthias
WTF? Syntaxhighlighting, ordentliche Einrückung oder Codefolding reichen.
auch hier kommts auf die Dimension an und manche wären bestimmt froh, wenn NetFusion oder Dreamweaver dies täten.
Nein, da kommt es niemals auf die Dimension an - ob ich einen Bereich mit 5.000 Zeilen falten ist dasselbe wie 10 Zeilen zu Falten.
Ein zudem kann man in einem ordentlichen Editor Zeilennummern oder Markierungen bookmarken - im schlimmsten Fall faltet man und setzt sich am Ende einen benannten Bookmark.
Ich halte es für unklug, den Client mit unnötigen Kommentaren vollzumüllen.
@@suit:
nuqneH
bei umfangreichen korrekturen sind Conditional Comments wesentlich einfacher handhabbar.
Nein. Ein Stylesheet ist wesentlich einfacher handhabbar als zwei oder gar drei. Je umfangreicher die Korrekturen, desto mehr gilt das.
- Place Javascript file at the bottom
Wozu? Wie der Client die das Dokument bearbeitet bleibt ihm überlassen - unten einbinden garantiert keineswegs, dass die Sache auch tatsächlich später geladen wird.
Sollte es Clients geben, die externe Ressourcen von „unten nach oben“ laden?
"As an example, a navigation menu should always be an unordered list:"
Das stimmt so schonmal nicht. Die Navigation
1. foo
2. bar
3. baz
ist eine geordnete Liste.
Ich würde vorschlagen, zum Testen immer einen möglichst Standardnahen Browser zu verwenden - das ist aktuell Opera
CSS 3 kannst du mit Standard nicht meinen, da hinkt Opera wohl derzeit mächtig gewaltig hinterher.
Qapla'
Nein. Ein Stylesheet ist wesentlich einfacher handhabbar als zwei oder gar drei. Je umfangreicher die Korrekturen, desto mehr gilt das.
Wenn man seine Files per hand verwaltet, kann das unter umständen Stimmen - aber wer macht sowas in größeren Dimensionen noch ernsthaft?
- Place Javascript file at the bottom
Wozu? Wie der Client die das Dokument bearbeitet bleibt ihm überlassen - unten einbinden garantiert keineswegs, dass die Sache auch tatsächlich später geladen wird.Sollte es Clients geben, die externe Ressourcen von „unten nach oben“ laden?
Nein, aber beim Parsen von XML bzw. XHTML als XML gibt es kein "unten und oben" - ich wage zu behaupten, dass XHTML als application/xml oder application/xhtml+xml noch nicht tot ist und somit durchaus noch im Hinterkopf zu behalten ist.
Ob ich dann ein CSS-File und dann ein JavaScript-File einbinde oder umgekehrt dürfte egal sein, da der Client entscheidet, was er zuerst abholt, da ohnehin das komplette Dokument gelesen werden muss, bevor es geparst werden kann und nicht linear von oben nach unten gelesen wird.
Das stimmt so schonmal nicht. Die Navigation
- foo
- bar
- baz
ist eine geordnete Liste.
Sehe ich nicht so - eine nummerierte Liste impliziert, dass es sinnvoll ist, sie in einer gewissen Reihenfolge zu besuchen. Das mag z.B. bei einem Navigation in Form einer TOC sein, aber imho sehr unpassend für eine Hauptnavigation.
Das sind also einzelfallentscheidungen - aber die Pauschalaussage "Navigation = ul" oder "Navigation = ol" halte ich für falsch. Wie gesagt - ich hätte "Navigation = menu" bevorzugt, ob da dann Nummern oder Punkte davorstehen, ist eine CSS-Sache.
CSS 3 kannst du mit Standard nicht meinen, da hinkt Opera wohl derzeit mächtig gewaltig hinterher.
Acid3 ist das was Hixie und Google für das Internet "brauchen" - wer das kann, ist möglichst "Standardnah" - unabhängig davon, wie man das jetzt definiert - so war das gemeint.
Zum Testen wird man wohl künftig Chrome als Referenz verwenden.
Nein. Ein Stylesheet ist wesentlich einfacher handhabbar als zwei oder gar drei. Je umfangreicher die Korrekturen, desto mehr gilt das.
Wenn man seine Files per hand verwaltet,
Wie machst du das sonst mit CSS Dateien? Was wäre da das gegenteil von "von Hand bearbeiten"?
Struppi.
Wie machst du das sonst mit CSS Dateien? Was wäre da das gegenteil von "von Hand bearbeiten"?
Ich lasse für mich arbeiten :)
Nein Spaß beiseite - wir verwenden hier ein modulares System (Eigenentwicklung) welches die getrennte Verwaltung von Stylesheets erlaubt und diese dann auf Knopfdruck in der definierten Reihenfolge zusammenbaut.
Stell dir eine Tabelle vor mit 4 Feldern:
common, ie6, ie7, ie8
Da schreibst du die Selektoren und Eigenschaft/Wert-Paare rein - je selektor 1 Datensatz und erhältst danach 4 fix fertige separate Dateien.
Mit einer Art Baukasten kann man sich damit recht schnell ein fertiges Set an Stylesheets zusammenbauen.
Man sagt nur was man grade braucht.
Nein Spaß beiseite - wir verwenden hier ein modulares System (Eigenentwicklung) welches die getrennte Verwaltung von Stylesheets erlaubt und diese dann auf Knopfdruck in der definierten Reihenfolge zusammenbaut.
Wie kann man denn ein Stylesheet per Knopfdruck zusammenbauen? Woher stammen denn die CSS Angaben? Das läßt sich doch gar nicht automatisieren - zumindest kann ich mir nicht vorstellen, wie.
Stell dir eine Tabelle vor mit 4 Feldern:
common, ie6, ie7, ie8
Da schreibst du die Selektoren und Eigenschaft/Wert-Paare rein - je selektor 1 Datensatz und erhältst danach 4 fix fertige separate Dateien.
d.h. ihr benutzt eine Art Verwaltungsoberfläche/software für CSS Eigenschaften, um daraus dann CSS Dateien zu erzeugen?
Klingt für mich reichlich kompliziert. Ich teile manchmal auch meine CSS Dateien auf, dann aber danach ob die Eigenschaften zu einer bestimmten funktionalität gehören.
Mit einer Art Baukasten kann man sich damit recht schnell ein fertiges Set an Stylesheets zusammenbauen.
Wobei mir nicht unbedingt der Sinn eines solchen Systems klar wird. Geht es nur darum die vielen verschiedenen IE Dateien zu verwalten?
Und was mir auch nicht klar ist, wie das automatisiert gehen soll? Das Programm kennt alle Bugs/Hacks? Oder sind das einfach dopppelte Eigenschaften, die ihr dann dem Browser von Hand zuordnen müßt?
Struppi.
Nein Spaß beiseite - wir verwenden hier ein modulares System (Eigenentwicklung) welches die getrennte Verwaltung von Stylesheets erlaubt und diese dann auf Knopfdruck in der definierten Reihenfolge zusammenbaut.
Wie kann man denn ein Stylesheet per Knopfdruck zusammenbauen? Woher stammen denn die CSS Angaben? Das läßt sich doch gar nicht automatisieren - zumindest kann ich mir nicht vorstellen, wie.
Für allgemeine Formatierungen die man sowieso immer braucht schon - z.B. Fließtext, Formulare, Tabellen usw.
Da werden nur die Farben, Schriftgröße, Zeilenabstände usw. eingestellt und man bekommt ein fix fertiges Stylesheet-Set ausgespuckt. Das System verlässt sich halt drauf, dass das HTML bestimmten Regeln folgt, die entsprechend eingehalten werden müssen.
Die Seitenstruktur selbst wird nicht per Knöpfchen gebaut - mit einem Framework wie YAML, YUI oder 960gs ist das aber sicher auch kein Problem.
d.h. ihr benutzt eine Art Verwaltungsoberfläche/software für CSS Eigenschaften, um daraus dann CSS Dateien zu erzeugen?
Richtig.
Klingt für mich reichlich kompliziert. Ich teile manchmal auch meine CSS Dateien auf, dann aber danach ob die Eigenschaften zu einer bestimmten funktionalität gehören.
Privat mache ich das auch so ;)
Wobei mir nicht unbedingt der Sinn eines solchen Systems klar wird. Geht es nur darum die vielen verschiedenen IE Dateien zu verwalten?
Nein, es geht darum Formatierung für den Seiteninhalt möglichst schnell anpassen bzw. erzeugen zu können.
Und was mir auch nicht klar ist, wie das automatisiert gehen soll? Das Programm kennt alle Bugs/Hacks? Oder sind das einfach dopppelte Eigenschaften, die ihr dann dem Browser von Hand zuordnen müßt?
Abweichungen müssen per Hand zugewiesen werden, das System kennt natürlich nicht alle Bugs/Hacks.
Hi there,
Acid3 ist das was Hixie und Google für das Internet "brauchen" - wer das kann, ist möglichst "Standardnah" - unabhängig davon, wie man das jetzt definiert - so war das gemeint.
Ich hab' noch keine Seite gesehen oder erstellt, die den Acid3-Test bestehen musste, ausser Acid3 selbst.
Zum Testen wird man wohl künftig Chrome als Referenz verwenden.
HTML vielleicht, bei Javascript führt an den Geckos imho kein Weg vorbei...
... beim Parsen von XML bzw. XHTML als XML gibt es kein "unten und oben" - ich wage zu behaupten, dass XHTML als application/xml oder application/xhtml+xml noch nicht tot ist und somit durchaus noch im Hinterkopf zu behalten ist.
Ob ich dann ein CSS-File und dann ein JavaScript-File einbinde oder umgekehrt dürfte egal sein, da der Client entscheidet, was er zuerst abholt, da ohnehin das komplette Dokument gelesen werden muss, bevor es geparst werden kann und nicht linear von oben nach unten gelesen wird.
Sorry, das ist Humbug!
Erst einmal ist Tag Soup Standard im Web. Das sind vermutlich 99,8% aller Anwendungsfälle. Scripts nach unten zu packen ist eine Performance-Empfehlung, die genau in diesen Fällen sinnvoll ist.
Auch ein XML-Parser hat einen Tokenizer, der Tokens ausspuckt, die bereits SAX-mäßig verarbeitet werden können. Parsing und XHTML-Verarbeitung erfolgt nicht erst, wenn das gesamte Dokument eingelesen ist! Eine solche Notwendigkeit besteht nicht, XML kann sequentiell eingelesen und verarbeitet werden. Sobald der Tokenizer ein <link rel="stylesheet" /> (im XHTML-Namensraum) emittiert, schickt der Browser einen Request, um das Stylesheet zu holen. Das wird er zumindest tun, wenn er sich für Performance und incremental rendering interessiert. Dasselbe gilt für <img />, </object>, </iframe>, </video>, </audio> und sonstige End-Tags, nach denen der Browser schon Requests senden kann, ohne wissen zu müssen, wie der XML-Input-Stream danach aussieht.
Das ist m.W. kein hartes Erfordernis irgendeines Standards. Aber es ist möglich, sinnvoll und offenbar Common Practise in allen Browsern. Bei HTML-Tag-Soup wie bei XHTML-als-XML. Ich sehe auch kein Grund, warum sich das ändern sollte.
Scripte sind übrigens noch einmal eine Besonderheit. Diese blocken gemäß XHTML5 den XML-Parser. Dies ist wiederum ein hartes Erfordernis des Standards - und ebenfalls Common Practise. Alle XHTML-fähigen Browser führen Scripte sofort aus und halten den XML-Parser an: Webkit, Opera, Gecko und sogar die heute erschienene IE9-Preview. Diese Scripte haben Zugriff auf ein unvollständiges DOM. Das DOM, was aus dem XML-Stream geparst wurde, der vor ihnen liegt. Auch das ist bei XML möglich.
Weil Scripte nicht nur den Tag-Soup- bzw. den HTML5-Parser, sondern auch den XML-Parser anhalten, macht »Place Javascript file at the bottom« durchaus auch für XHTML Sinn.
Mathias
Hallo,
Scripte sind übrigens noch einmal eine Besonderheit. Diese blocken gemäß XHTML5 den XML-Parser. Dies ist wiederum ein hartes Erfordernis des Standards - und ebenfalls Common Practise. Alle XHTML-fähigen Browser führen Scripte sofort aus und halten den XML-Parser an: Webkit, Opera, Gecko und sogar die heute erschienene IE9-Preview. Diese Scripte haben Zugriff auf ein unvollständiges DOM. Das DOM, was aus dem XML-Stream geparst wurde, der vor ihnen liegt. Auch das ist bei XML möglich.
Weil Scripte nicht nur den Tag-Soup- bzw. den HTML5-Parser, sondern auch den XML-Parser anhalten, macht »Place Javascript file at the bottom« durchaus auch für XHTML Sinn.
Das ma ne fundiert Erklärung (;-).
Gruß
jobo
Manao ahoana tompoko!
bei umfangreichen korrekturen sind Conditional Comments wesentlich einfacher handhabbar.
Nein. Ein Stylesheet ist wesentlich einfacher handhabbar als zwei oder gar drei. Je umfangreicher die Korrekturen, desto mehr gilt das.
Doch. Die meisten Korrekturen, die ich verwende, sind für IE 6 _und_ 7. Das bedeutet, daß ich sie bei Verzicht auf CCs zweimal notieren müßte, weil
* html whatever, *+html whatever
von beiden nicht gefressen wird. Dazu kommt, daß so manche Korrektur invalide ist, was zwar (bei CSS!) meistens keine sichtbaren Folgen hat, aber z.B. ulkiger filter-Syntax mit Klammern wird nachgesagt, Safari zu verwirren.
Meine Lieblingsmethode ist ein Extra-IE-Stylesheet, das mit CC für IE < 8 eingebunden wird. Darin kann ich dann normale Selektoren für IE 6 und 7, * html für IE 6 und *+html für IE 7 verwenden.
- Place Javascript file at the bottom
Wozu? Wie der Client die das Dokument bearbeitet bleibt ihm überlassen - unten einbinden garantiert keineswegs, dass die Sache auch tatsächlich später geladen wird.Sollte es Clients geben, die externe Ressourcen von „unten nach oben“ laden?
Meines Wissens nicht. Das Dokument wird von oben nach unten geparst, und Scripte werden sofort geladen und ausgeführt. Wenn also viele und/oder große Scripte im Head eingebunden werden, bleibt die Seite weiß, bis die alle fertiggerödelt haben. Also wirklich lieber am Ende vom Body einbinden, dann kann der User schon mit dem Lesen anfangen, während die noch arbeiten. Außerdem ist dann der DOM schon fertig, auf den man ja doch manchmal zugreifen möchte.
CSS 3 kannst du mit Standard nicht meinen, da hinkt Opera wohl derzeit mächtig gewaltig hinterher.
Außerdem ist Firebug IMHO immer noch besser als Dragonfly, auch wenn in der Hinsicht alle Browser erfreuliche Fortschritte machen. :)
Viele Grüße vom Længlich
Außerdem ist Firebug IMHO immer noch besser als Dragonfly, auch wenn in der Hinsicht alle Browser erfreuliche Fortschritte machen. :)
Dragonfly hat ein paar Dinge die Firebug nicht hat und umgekehrt - Dragonfly ist aber schneller :p
Hi,
- Don’t mix Javascript with HTML
imho jein. Ich gebe jetzt mal den Troll, denn ich bearbeite reichlich Seiten, in die verschiedene Entwickler an die unterschiedlichsten Stellen irgendeines Includes oder externen JS irgendwohin ein document.ready mit $().click() reingeschrieben haben, und empfinde es oft als sehr mühsam, die dazugehörigen Eventhandler zu finden - ohne grep geht meist nix. Bei solchen Strukturen liebe ich das gute alte "onclick".
Gruesse, Joachim
- Don’t mix Javascript with HTML
imho jein. Ich gebe jetzt mal den Troll, denn ich bearbeite reichlich Seiten, in die verschiedene Entwickler an die unterschiedlichsten Stellen irgendeines Includes oder externen JS irgendwohin ein document.ready mit $().click() reingeschrieben haben, und empfinde es oft als sehr mühsam, die dazugehörigen Eventhandler zu finden - ohne grep geht meist nix. Bei solchen Strukturen liebe ich das gute alte "onclick".
Ich bevorzuge da eher die Lösung mit Konventionen, es gibt ein File mit dem namen functions.js und da darf jeder seine document-ready-Funktionen reinpacken, wer's anderswo reinbaut, bekommt eine gepaddelt.
Hi,
wer's anderswo reinbaut, bekommt eine gepaddelt.
Das würde ich desöfteren gerne tun... aber die Unholde sind längst in Deckung oder über alle Berge gegangen ;-)
Gruesse, Joachim