nicht angemeldet
Meine Programmiertechnik auf einen Standard bringen, aber wie?
Hallo Leute!
Da es ja für die Umsetzung einer "Programmieraussage" häufig mehrere Möglichkeiten gibt, will ich nun meine Programmiertechnik weitgehendst auf einen Standard bringen. Vielleicht könnt ihr mir ein paar Tipps und Ratschläge dafür geben.
Folgende Beispiele fallen mir ein:
-Der Tag font fällt z.B. nicht unter die Kategorie "strict", man kann auf diesen auch mit CSS verzichten. (Frage nebenbei: Die CSS-Befehle font-size, font-color etc. bleiben aber erhalten, oder?)
Soll ich jetzt auf ältere Browser Rücksicht nehmen, z.B. durch Angaben wie "alink, vlink, text, etc." im Body-Tag oder die Verwendung von Layers, oder soll ich nur noch CSS und z.B. bei DHTML das DOM verwenden, sodass die alten Browser möglichst schnell "rausgedrängt" werden?
-Das Zeichen " kann man durch den Code " ersetzen, allerdings geht es doch auch so ". Wie sollte ich hier vorgehen?
-document.write("<a href='link.html'>Link</a>")
oder
document.write("<a href="link.html">Link</a>")
?
-window.alert / window.document. / window.location / etc.
oder
alert / document / location / etc.
?
-DOM: Sollte ich bei diesem Modell eher divs, etc. verwenden, oder ist dieses Modell auch in Zukunft für alle Tags (font, img, a, usw.) gedacht?
-Type-Angaben: Kann ich drauf verzichten, oder sollte ich sie verwenden?
Z.B.: script type="text/javascript"
-Language-Angabe: Sinnlos? Häufig weiß man ja noch nicht einmal die JS-Version.
Z.B.: script language="....."
-IF, THEN, ELSE: Diese Anweisung kann man in JavaScript auf zwei Arten umsetzen:
Beispiel:
i > z ? i = 1 : i = 0
oder
if (i > z)
{
i = 1;
}
else
{
i = 0;
}
Was ist sinnvoller?
Ich würde mich sehr über eure Meinungen und Antworten dazu freuen!
Grüße,
Klaus
-
hi
-Der Tag font fällt z.B. nicht unter die Kategorie "strict", man kann auf diesen auch mit CSS verzichten. (Frage nebenbei: Die CSS-Befehle font-size, font-color etc. bleiben aber erhalten, oder?)
klar, es geht ja ferade darum NUR noch über CSS zu formatieren.
Soll ich jetzt auf ältere Browser Rücksicht nehmen, z.B. durch Angaben wie "alink, vlink, text, etc." im Body-Tag oder die Verwendung von Layers, oder soll ich nur noch CSS und z.B. bei DHTML das DOM verwenden, sodass die alten Browser möglichst schnell "rausgedrängt" werden?
Es gibt praktisch keine nicht-CSS-Fähigen Browser mehr.
-Das Zeichen " kann man durch den Code " ersetzen, allerdings geht es doch auch so ". Wie sollte ich hier vorgehen?
in HTML kannste auch " lassen.
-document.write("<a href='link.html'>Link</a>")
oder
document.write("<a href="link.html">Link</a>")
?geschmackssache
-window.alert / window.document. / window.location / etc.
oder
alert / document / location / etc.würd lieber mit window schreiben.
-DOM: Sollte ich bei diesem Modell eher divs, etc. verwenden, oder ist dieses Modell auch in Zukunft für alle Tags (font, img, a, usw.) gedacht?
<font> gibt's nimma. Geht aber für alle.
-Type-Angaben: Kann ich drauf verzichten, oder sollte ich sie verwenden?
NEIN! Immer setzen.
-Language-Angabe: Sinnlos? Häufig weiß man ja noch nicht einmal die JS-Version.
Z.B.: script language="....."einfach "JavaScript" rein - will Opera so
-IF, THEN, ELSE: Diese Anweisung kann man in JavaScript auf zwei Arten umsetzen:
geschmackssache
-
Hallo
-Das Zeichen " kann man durch den Code " ersetzen, allerdings geht es doch auch so ". Wie sollte ich hier vorgehen?
in HTML kannste auch " lassen.
Aber nur innerhalb der tags zur Abgrenzung der Attributwerte,
da darf auch garnicht maskiert werden.
Im anzuzeigenden Fließtext muß es schon " sein.Tschüß, Auge
-
hi
Aber nur innerhalb der tags zur Abgrenzung der Attributwerte,
da darf auch garnicht maskiert werden.
Im anzuzeigenden Fließtext muß es schon " sein.eh - nö. Storen sich weder W3C noch Browser dran.
gruss Kai
-
-
-
Hi,
Da es ja für die Umsetzung einer "Programmieraussage" [...]
kurz vorweg: Weder HTML noch CSS haben auch nur im Ansatz etwas mit Programmierung zu tun.
-Der Tag font fällt z.B. nicht unter die Kategorie "strict", man kann auf diesen auch mit CSS verzichten.
Und sollte es auch tun.
(Frage nebenbei: Die CSS-Befehle font-size, font-color etc. bleiben aber erhalten, oder?)
Da verstehe ich nicht, was Du meinst. Es gibt CSS-Angaben (_keine_ Befehle), die definiert sind und je nach Browser mehr oder weniger gut verstanden werden. Warum sollte da etwas wegfallen?
Soll ich jetzt auf ältere Browser Rücksicht nehmen, z.B. durch Angaben wie "alink, vlink, text, etc." im Body-Tag
_Willst_ Du auf Browser ohne (oder mit deaktiviertem) CSS Rücksicht nehmen?
IMHO ist es relativ unkritisch, den <body>-Tag mit ein paar Basis-Angaben zu schmücken. Viel wichtiger ist die Entscheidung, ob man auf <font> verzichtet oder nicht.
oder die Verwendung von Layers,
Willst Du DHTML einsetzen?
oder soll ich nur noch CSS und z.B. bei DHTML das DOM verwenden, sodass die alten Browser möglichst schnell "rausgedrängt" werden?
Durch Dich wird garantiert nichts rausgedrängt - allerhöchstens verlierst Du Besucher. Da gute JavaScript-Programmierung auch beinhaltet, dass ohne JavaScript trotzdem die Funktionalität nicht eingeschränkt ist, kannst Du gerne entscheiden, nur DOM-kompatibel zu schreiben. Willst Du zusätzlich für document.layers und/oder document.all programmieren, darfst Du das natürlich auch - die User werden nicht undankbar sein, vorausgesetzt Du programmierst gut.
-Das Zeichen " kann man durch den Code " ersetzen,
In HTML, nicht in JavaScript.
allerdings geht es doch auch so ".
In JavaScript, nicht in HTML.
-document.write("<a href='link.html'>Link</a>")
document.write("<a href="link.html">Link</a>")document.write('<a href="link.html">Link</a>');
Überlege Dir, wie das Ergebnis aussehen soll, also der HTML-Code. Diesen musst Du dann für document.write() quoten - es ist sinnvoll, Single- und Doublequotes im Wechsel zu verwenden (und ab dem dritten innen zu escapen).
-window.alert / window.document. / window.location / etc.
oder
alert / document / location / etc.Hauptobjekte wie document, location usw. sowie Methoden unter window kannst Du getrost ohne das übergeordnete Objekt angeben. Alles andere, wie z.B. window.screen, muss zumindest eindeutig sein: if (window.screen) alert(screen.height);
-DOM: Sollte ich bei diesem Modell eher divs, etc. verwenden, oder ist dieses Modell auch in Zukunft für alle Tags (font, img, a, usw.) gedacht?
Ich habe mich mangels umfassender Unterstützung noch nicht wesentlich mit DOM beschäftigt. Eins solltest Du aber bedenken: <div> nur dort, wo es _nötig_ ist, nicht einfach pauschal in den Quellcode geknallt. Einige Leute verzapfen solchen Unsinn wie <td><div align="right">...</div></td>, was tunlichst vermieden werden sollte.
-Type-Angaben: Kann ich drauf verzichten, oder sollte ich sie verwenden?
Z.B.: script type="text/javascript"In <script> ist das type-Attribut required. In diesem Punkt kannst Du Dich ganz an die Spezifikationen des W3C halten.
-Language-Angabe: Sinnlos?
Nein, zusätzliche Information insbesondere für ältere Browser.
-IF, THEN, ELSE: Diese Anweisung kann man in JavaScript auf zwei Arten umsetzen:
Was ist sinnvoller?Diejenige, die den Code am übersichtlichsten macht.
Ich würde mich sehr über eure Meinungen und Antworten dazu freuen!
Jupp - und obiges ist im großen und ganzen auch nur eine Meinung :-)
Cheatah
-
Moin!
-Der Tag font fällt z.B. nicht unter die Kategorie "strict", man kann auf diesen auch mit CSS verzichten. (Frage nebenbei: Die CSS-Befehle font-size, font-color etc. bleiben aber erhalten, oder?)
Soll ich jetzt auf ältere Browser Rücksicht nehmen, z.B. durch Angaben wie "alink, vlink, text, etc." im Body-Tag oder die Verwendung von Layers, oder soll ich nur noch CSS und z.B. bei DHTML das DOM verwenden, sodass die alten Browser möglichst schnell "rausgedrängt" werden?Keine Rücksicht, was die Verwendung von alten, bösen Tags angeht, aber je nach Seite und Kundenwunsch volle Rücksicht auf die Belange des alten Netscape 4. Ist manchmal etwas Fummelkram, aber meist kriegt man mit dem identisches Aussehen einigermaßen hin. Oder man setzt auf verschiedene Stylesheets: Eins vor NS4, und ein weiteres für die CSS-verständigen Browser.
-Das Zeichen " kann man durch den Code " ersetzen, allerdings geht es doch auch so ". Wie sollte ich hier vorgehen?
Das Zeichen " hat immer einen Verwendungszweck. Entweder begrenzt es Attributwerte (wie in <a href="link.html" onclick="aufrufderfunktion(); return false;">). Da muß selbstverständlich " geschrieben werden. " _kannst_ du schreiben, wenn du ein " im Text haben willst, genauso wie Umlaute auch zu ersetzen sind. Und " schreibst du, wenn du in Javascript oder einer serverseitigen Sprache das Zeichen " ausgeben willst, es selbst aber in einem String drinsteht, der mit " abgegrenzt ist - sonst würde der String ja an der falschen Stelle aufhören! :)
-document.write("<a href='link.html'>Link</a>")
oder
document.write("<a href="link.html">Link</a>")
?Vollkommen egal. Hängt vom Anwendungsfall ab. Wenn du '...' als Stringbegrenzer wählst, mußt du " nicht escapen, aber natürlich '. Wenn du "..." als Stringbegrenzer wählst, mußt du ' nicht escapen, aber ".
-window.alert / window.document. / window.location / etc.
oder
alert / document / location / etc.
?window wird implizit davorgesetzt. Wenn du also das eigene Fenster meinst, kannst du window explizit angeben, oder es lassen. Wenn du im Frameset agierst, mußt du irgendeine Angabe machen, wenn nicht das eigene Fenster gemeint ist.
-DOM: Sollte ich bei diesem Modell eher divs, etc. verwenden, oder ist dieses Modell auch in Zukunft für alle Tags (font, img, a, usw.) gedacht?
DOM ist für alles, was sich im Dokument befindet. Da <font> aussterben soll, ist es eher unwahrscheinlich, das noch vorzufinden.
-Type-Angaben: Kann ich drauf verzichten, oder sollte ich sie verwenden?
Z.B.: script type="text/javascript"Ist unverzichtbar, da das sonst kein valider Code ist. Du kannst auf die language-Angabe verzichten.
-Language-Angabe: Sinnlos? Häufig weiß man ja noch nicht einmal die JS-Version.
Z.B.: script language="....."Normalerweise ist bei type="text/javascript" der Javascript-Interpreter zuständig. Mit der _zusätzlichen_ language-Angabe _kann_ man die Ausführung auf gewisse JS-Versionen begrenzen.
-IF, THEN, ELSE: Diese Anweisung kann man in JavaScript auf zwei Arten umsetzen:
Beispiel:
i > z ? i = 1 : i = 0
oder
if (i > z)
{
i = 1;
}
else
{
i = 0;
}Was ist sinnvoller?
Das eine ist kurz, das andere lang. Das eine ist eher kryptisch und deshalb prima für eher einfache Konstrukte geeignet, das andere ist für die ausführliche Programmierung (wenn beispielsweise mehrere Befehlsschritte ausgeführt werden sollen).
- Sven Rautenberg
-
Hi!
Soll ich jetzt auf ältere Browser Rücksicht nehmen, z.B. durch Angaben wie "alink, vlink, text, etc." im Body-Tag oder die Verwendung von Layers
Netscape-Layers sind ungültig, Verwendung von solchem HTML3-Gestrüpp in strict-Dokumenten geht auch nicht mehr. Nimm keine Rücksicht auf unvollständige Browser, die nicht einmal CSS1 können. Auf dieser Schiene fährst du besser - vorwärtskompatibel ist wichtiger als rückwärtskompatibel.
document.write("<a href="link.html">Link</a>")
Ja, so. Der Attributdelimiter ist seit eh und jeh das Anführungszeichen, nicht das Apostroph.
-IF, THEN, ELSE
Im Sinne der Lesbarkeit nimm die lange Variante. Die ist auch für nicht JS-Kundige, die aber andere Sprachen (Basic, Pascal, Perl) können, sofort verständlich.
K.
-
Hi Klaus,
Soll ich jetzt auf ältere Browser Rücksicht nehmen,
das ist keine Stilfrage, sondern Teil der Aufgabenstellung für Deine Seiten.
-DOM: Sollte ich bei diesem Modell eher divs, etc.
verwenden, oder ist dieses Modell auch in Zukunft
für alle Tags (font, img, a, usw.) gedacht?DOM ist die Zukunft. (Leider noch nicht wirklich die Gegenwart.)
-Language-Angabe: Sinnlos?
Z.B.: script language="....."Relativ viel, was Du verwendest, ist mit hoher Wahrscheinlichkeit mindestens JavaScript 1.2 (bei dieser Version sind etliche Funktionen dazu gekommen).
Wenn Du dies im <script>-Tag angibst, verhinderst Du, daß Netscape 3 (der nur JavaScript 1.1 kann) in ein Inferno von Skript-Fehlern rauscht.Darüber hinaus unterstützen die Browser buchstäblich "irgendwas": M$IE kann offiziell 1.3, unterstützt allerdings teilweise schon DOM-Funktionen aus 1.5; Opera kann offiziell 1.4, aber tendentiell weniger DOM als M$IE (nach meiner Erfahrung).
Oberhalb von 1.2 zu unterscheiden ist inhaltlich schwierig, weil die von den Browsern angegebenen beherrschten Versionen über die tatsächlich verfügbare Funktionalität wenig aussagen.Deshalb würde ich sagen: JavaScript 1.2 zu fordern dürfte eher nützen als schaden.
Und mit der Forderung nach noch höheren Versionen läßt sich möglicherweise eine elegante Browserweiche bauen.Häufig weiß man ja noch nicht einmal die JS-Version.
Ein Blick in SelfHTML hat mir in diese Hinsicht schon oft geholfen.
Viele Grüße
Michael-
hi
-DOM: Sollte ich bei diesem Modell eher divs, etc.
verwenden, oder ist dieses Modell auch in Zukunft
für alle Tags (font, img, a, usw.) gedacht?DOM ist die Zukunft. (Leider noch nicht wirklich die Gegenwart.)
DA irrst du.
IE 5 kann DOM
Netscape 6 kann DOM
Mozilla kann DOM
konqueror kann DOM
Opera kann DOM (aber nicht alle Properties ändern)gruss Kai
-
Hi Kai,
DOM ist die Zukunft. (Leider noch nicht wirklich die Gegenwart.)
DA irrst du.
IE 5 kann DOM
Netscape 6 kann DOM
Mozilla kann DOM
konqueror kann DOM
Opera kann DOM (aber nicht alle Properties ändern)Die Gegenwarz ist Netscape 4 (die "Kröte"), und was Opera an DOM kann, ist leider nicht der Rede wert. (Vor allem in Sachen getElementByID.)
Mozilla existiert noch nicht wirklich - jedenfalls nicht für Firmenkunden.
Sobald Netscape 6.5 auf dem Markt ist, reden wir nochmal darüber.Viele Grüße
Michael-
hi
DOM ist die Zukunft. (Leider noch nicht wirklich die Gegenwart.)
DA irrst du.
IE 5 kann DOM
Netscape 6 kann DOM
Mozilla kann DOM
konqueror kann DOM
Opera kann DOM (aber nicht alle Properties ändern)Die Gegenwarz ist Netscape 4 (die "Kröte"), und was Opera an DOM kann, ist leider nicht der Rede wert. (Vor allem in Sachen getElementByID.)
das wird sich wohl auch erst mit der Version 7 ändern :(
Mozilla existiert noch nicht wirklich - jedenfalls nicht für Firmenkunden.
Sobald Netscape 6.5 auf dem Markt ist, reden wir nochmal darüber.hm.. bei meiner Page schon. ca. 35% Mozilla, 5% Netscape 4, je 22% IE5 und 6, 8% Opera, 3% konq. Das einzige JS, das vorkommt ist mit Netscape 4 grundsätzlich nicht lösbar (dynamisch erstellte <iframe>s), also hab' ich das ausschließlich über DOM gelöst. Zumal die Navigation natürlich auch komplett ohne JS funzt, es gibt nur zusätzlich die Möglichkeit sich mehrere FAQs auf einer Seite anzeigen zu lassen. Ich will damit sagen, wenn man irgendwelche JS-Gimmiks baut, die nicht lebensnotwendig sind, nur eben ein paar zusatz-Features bringen ist es absolut sinnlos diese proprietären Erweiterungen noch zu nutzen, insbesondere Microsoft's document.all ist Geschichte.
gruss Kai
-
Hi Kai,
Ich will damit sagen, wenn man irgendwelche JS-Gimmiks baut,
die nicht lebensnotwendig sind, nur eben ein paar zusatz-Features
bringen ist es absolut sinnlos diese proprietären Erweiterungen
noch zu nutzen, insbesondere Microsoft's document.all ist Geschichte.Alles, was der Vertrieb fordert und bei der Geschäftsleitung durchgesetzt hat, ist "lebenswichtig" - und die Kompatibilität zu existierenden Kunden mit langfristigen Verträgen und Garantien, daß es in Netscape 4 läuft, natürlich auch.
That's real life ...
Viele Grüße
Michael
-
-
-
-
Hi Michael!
Relativ viel, was Du verwendest, ist mit hoher Wahrscheinlichkeit mindestens JavaScript 1.2 (bei dieser Version sind etliche Funktionen dazu gekommen).
Wenn Du dies im <script>-Tag angibst, verhinderst Du, daß Netscape 3 (der nur JavaScript 1.1 kann) in ein Inferno von Skript-Fehlern rauscht.Ich halte es nicht fuer sinnvoll, dem language-Attribut irgendeine Bedeutung beizumessen, insbesondere nicht bzgl. der JS-Version. Da haelt sich doch sowieso jeder Browser fuer irgendwas geeignet, was mit der Realitaet in keinem Zusammenhang steht. Schon IE3 war dafuer bekannt, munter die JS1.1-Abschnitte zu interpretieren, die er aber leider nicht verstand (ich glaube, es ging damals um document.images). Nicht umsonst hat das W3C dann dieses Attribut auch als deprecated erklaert.
Auch wenn es nicht besonders schoen ist, in JS muss man jede Funktionalitaet, die man braucht, erst entsprechend abpruefen, selbst wenn man ein Language-Attribut hat.
if (document.images) ...
if (document.getElementById) ...
Falls das an einer bestimmten Stelle nicht geht (vermutlich werden z.B. die neuen try/catch Bloecke solche Stellen sein), hilft evtl. window.onerror weiter.So long
--
Whoever cares, calocybe is now @web.de
-
-
Hallo!
Erstmal danke an alle, die auf meinen Beitrag geantwortet haben.
An den Antworten merke ich aber wie schwer es ist, einen Standard zu finden, wie wichtig es allerdings wäre. (Die ganzen Browser-Probleme gehen mir so langsam auf die Nerven)
Einige meinen lieber auf ältere Browser keine Rücksicht mehr nehmen, andere meinen dagegen, man sollte seine HP möglichst für alle Browser kompatibel machen. Ich fände es eigentlich schon sinnvoll, alte Browser rauszudrängen (jaja ich weiß, allein bin ich machtlos), was spricht dagegen? Wenn z.B. Netscape4-User merken, dass es beim Surfen nur noch Probleme gibt, werden sie wohl irgendwann merken, dass es nicht an den einzelnen HP´s liegt.
Die language-Angabe im SCRIPT-Tag: Einige sagen sinnlos, andere halten sie für dringend notwendig. Ich habe mich dazu entschieden, immer die Angabe language="JavaScript" reinzusetzen, sinnvoll? Desweiteren frage ich mich, wieso das beim IE auch ohne kein Problem ist, dann sollte man doch die anderen Browser auch so entwickeln. Es spart Programieraufwand und Bytes, also Ladezeit. Genauso ist es bei den type-Angaben.Nun zu CSS: Ich habe mal versucht, auf den Font-Tag zu verzichten und habe ihn durch den Span-Tag ersetzt, welcher jeweils CSS-Angaben beinhaltet. Dabei ist mir aufgefallen, dass es völlig schwachsinnig ist, diesen Tag (font) rauszunehmen. Nehmen wir mal an, ich wollte folgende zwei Zeilen schreiben:
<font color="#FF0000">Dieser Text ist rot</font><br>
<font color="#0000FF">Dieser Text ist blau</font>Nun will ich auf den Font-Tag verzichten:
<span style="font-color: #FF0000">Dieser Text ist rot</span><br>
<span style="font-color: #0000FF">Dieser Text ist blau</span>Das ist viel umständlicher.
Außerdem habe ich mal versucht, auf den center-tag zu verzichten:
<center>Dieser Text ist mittig</center>CSS:
<span style="text-align: center">Dieser Text ist mittig</center> <-- Das geht nicht!Was nun? Der Div-Tag erzeugt automatisch einen Absatz, außerdem ist er laut SELFHTML weder in strict noch in transitional noch in frameset.
Noch was anderes:
Nach W3 sollte sich in jedem Form-Tag eine action-Angabe befinden. Was, wenn ich gar keine action-Angabe brauche. Wieso soll ich dann action="" reinschreiben?Ich bitte euch außerdem noch um eure Meinung hierzu:
var text = "....."
oder
text = "....."
???Desweiteren meine ich rausgehört zu haben, dass, wenn der User JavaScript deaktiviert hat, DOM trotzdem funktioniert. Ich dachte bisher, dass DOM wie auch die anderen DHTML-Modelle immer in Verbindung mit JavaScript stehen, schließlich werden deren Befehle doch zwischen <script> und </script> geschrieben?!
Ich bedanke mich schon mal für eure Antworten und möchte noch darauf hinweisen, dass ich mit dem vielleicht teilweise unfreundlichen oder vorwurfsvollen Ton in diesem Beitrag niemanden von euch dafür verantwortlich machen will, dass es so ein Durcheinander und so viele Probleme mit den verschiedenen Browsern gibt. Bin eben ein bisschen genervt davon.
Viele Grüße,
Klaus-
Moin!
Ich fände es eigentlich schon sinnvoll, alte Browser rauszudrängen (jaja ich weiß, allein bin ich machtlos), was spricht dagegen?
Nichts spricht dagegen. Wenn du es dir leisten kannst und willst, daß deine Seite nur noch von aktuellen Browsern besuchbar ist, dann nimm keine Rücksicht mehr. Wenn du vielleicht doch noch ein Herz für alte Browser hast, dann nutze die Chance von CSS, und laß den alten Browsern (auch Netscape 4) zumindest die Inhalte, und mache in einem Eingangsabsatz klar, daß es nur deswegen so billig aussieht, weil der Browser scheiße ist.
Ich habe mich dazu entschieden, immer die Angabe language="JavaScript" reinzusetzen, sinnvoll?
Das kannst du im Prinzip auch lassen, weil es absolut nichts hilft. Entweder kommt da eine Versionsnummer dazu, um unfähigere Browser auszuschließen, oder du kannst die Angabe komplett knicken.
Nun zu CSS: Ich habe mal versucht, auf den Font-Tag zu verzichten und habe ihn durch den Span-Tag ersetzt, welcher jeweils CSS-Angaben beinhaltet. Dabei ist mir aufgefallen, dass es völlig schwachsinnig ist, diesen Tag (font) rauszunehmen. Nehmen wir mal an, ich wollte folgende zwei Zeilen schreiben:
<font color="#FF0000">Dieser Text ist rot</font><br>
<font color="#0000FF">Dieser Text ist blau</font>Nun will ich auf den Font-Tag verzichten:
<span style="font-color: #FF0000">Dieser Text ist rot</span><br>
<span style="font-color: #0000FF">Dieser Text ist blau</span>Das ist viel umständlicher.
Richtig, so wie du es verwendest, ist es umständlicher. Aber deine Anwendung geht weit an den Möglichkeiten von CSS vorbei.
Grundlage ist, daß HTML die logische Textauszeichnung vornimmt, und CSS dann die Formatierung.
Logische Textauszeichnung ist:
<h1>Ich bin die Überschrift</h1>
<p>Ich bin der Textabsatz darunter</p>
<p>Und ich bin Text, der noch etwas <strong>ganz wichtiges</strong> hinzuzufügen hat</p>Sieht ohne CSS in einem Browser ziemlich langweilig aus. Das <strong> dürfte gewöhnlich als Fettschrift dargestellt werden.
Wenn du nun aber in einer externen CSS-Datei oder auch im <style>-Abschnitt dieser Datei folgende Formatierungsangaben machst:
h1 { font-family:Verdana,Arial,sans-serif; font-size:20px; font-color:red; background-color:black; }
p { font-family:"Courier New",Courier,monospace; font-size:12px; font-color:#FF8855; background-color:#444; }
strong { font-weight:normal; text-decoration:underline overline; font-color:#0066FF; }Dann sieht der Absatz plötzlich ganz anders aus.
Und dir sollte klar sein, daß man auf diese Weise die Angaben alle in einer Datei halten kann, und eben zum Ändern der Schriftart nicht mehr in tausend <font>-Tags rumfummeln muß, sondern nur noch einmal in der zentralen Datei:
p {font-family:Tahoma, sans-serif; ... }
Schon ist alles umformatiert.
Außerdem habe ich mal versucht, auf den center-tag zu verzichten:
<center>Dieser Text ist mittig</center>CSS:
<span style="text-align: center">Dieser Text ist mittig</center> <-- Das geht nicht!Klar, denn das hier geht ja auch nicht:
texttexttext<center>Das ist zentriert</center>texttexttextDu kannst nur komplette Absätze zentrieren. Also mußt du
<div style="text-align:center;">Das ist zentriert</div> nehmen.
Was nun? Der Div-Tag erzeugt automatisch einen Absatz, außerdem ist er laut SELFHTML weder in strict noch in transitional noch in frameset.
Stimmt, in der Elementreferenz sind da keine Angaben gemacht aber in der Beschreibung http://selfhtml.teamone.de/html/text/bereiche.htm#block sind deutlich die Standards HTML 3.2 und XHTML 1.0 als Icons genannt. Ist vermutlich ein Fehler, der noch nicht korrigiert wurde.
Laut W3C gehört DIV sowohl zu strict als auch zu transitional, und vermutlich darf es selbst in frameset innerhalb des noframes-Bereichs benutzt werden.
Noch was anderes:
Nach W3 sollte sich in jedem Form-Tag eine action-Angabe befinden. Was, wenn ich gar keine action-Angabe brauche. Wieso soll ich dann action="" reinschreiben?Formulare sind per Definition dazu da, abgeschickt zu werden. Und dieses Abschicken geht irgendwo hin. Folglich muß eine Adresse angegeben werden.
Wenn du nichts abschicken willst: Laß <form> weg und probiere, ob es trotzdem geht. Obwohl ich mir da fast sicher bin, daß irgendwelche Browser das garnicht gut finden werden.
Ich bitte euch außerdem noch um eure Meinung hierzu:
var text = "....."
oder
text = "....."
???Hängt vom gewünschten Programm ab.
var text=".." erzeugt eine in diesem Moment lokale Variable, die für Programmcode außerhalb z.B. der Funktion unbekannt ist.
text=".." erzeugt in jedem Fall eine globale Variable, sofern sie nicht schon als lokal definiert ist.
Es ist guter Stil, alle benötigten Variablen mit var name zu definieren, und auch möglichst wenige als global anzulegen.
Desweiteren meine ich rausgehört zu haben, dass, wenn der User JavaScript deaktiviert hat, DOM trotzdem funktioniert. Ich dachte bisher, dass DOM wie auch die anderen DHTML-Modelle immer in Verbindung mit JavaScript stehen, schließlich werden deren Befehle doch zwischen <script> und </script> geschrieben?!
DOM ist der Baum, der durch die Definitionen der HTML-Tags entsteht. Nur bringt der eigentlich ohne Javascript garnichts, weil er sonst ziemlich allein in der Gegend rumsteht. Wenn Javascript aus ist, kann nichts programmiertes ablaufen.
- Sven Rautenberg
-
Hallo Sven!
Ich fände es eigentlich schon sinnvoll, alte Browser rauszudrängen (jaja ich weiß, allein bin ich machtlos), was spricht dagegen?
Nichts spricht dagegen. Wenn du es dir leisten kannst und willst, daß deine Seite nur noch von aktuellen Browsern besuchbar ist, dann nimm keine Rücksicht mehr. Wenn du vielleicht doch noch ein Herz für alte Browser hast, dann nutze die Chance von CSS, und laß den alten Browsern (auch Netscape 4) zumindest die Inhalte, und mache in einem Eingangsabsatz klar, daß es nur deswegen so billig aussieht, weil der Browser scheiße ist.
Ich habe mich dazu entschieden, immer die Angabe language="JavaScript" reinzusetzen, sinnvoll?
Das kannst du im Prinzip auch lassen, weil es absolut nichts hilft. Entweder kommt da eine Versionsnummer dazu, um unfähigere Browser auszuschließen, oder du kannst die Angabe komplett knicken.
OK, dann lass ich die language-Angabe komplett weg!
Nun zu CSS: Ich habe mal versucht, auf den Font-Tag zu verzichten und habe ihn durch den Span-Tag ersetzt, welcher jeweils CSS-Angaben beinhaltet. Dabei ist mir aufgefallen, dass es völlig schwachsinnig ist, diesen Tag (font) rauszunehmen. Nehmen wir mal an, ich wollte folgende zwei Zeilen schreiben:
<font color="#FF0000">Dieser Text ist rot</font><br>
<font color="#0000FF">Dieser Text ist blau</font>Nun will ich auf den Font-Tag verzichten:
<span style="font-color: #FF0000">Dieser Text ist rot</span><br>
<span style="font-color: #0000FF">Dieser Text ist blau</span>Das ist viel umständlicher.
Richtig, so wie du es verwendest, ist es umständlicher. Aber deine Anwendung geht weit an den Möglichkeiten von CSS vorbei.
Grundlage ist, daß HTML die logische Textauszeichnung vornimmt, und CSS dann die Formatierung.
Logische Textauszeichnung ist:
<h1>Ich bin die Überschrift</h1>
<p>Ich bin der Textabsatz darunter</p>
<p>Und ich bin Text, der noch etwas <strong>ganz wichtiges</strong> hinzuzufügen hat</p>Sieht ohne CSS in einem Browser ziemlich langweilig aus. Das <strong> dürfte gewöhnlich als Fettschrift dargestellt werden.
Wenn du nun aber in einer externen CSS-Datei oder auch im <style>-Abschnitt dieser Datei folgende Formatierungsangaben machst:
h1 { font-family:Verdana,Arial,sans-serif; font-size:20px; font-color:red; background-color:black; }
p { font-family:"Courier New",Courier,monospace; font-size:12px; font-color:#FF8855; background-color:#444; }
strong { font-weight:normal; text-decoration:underline overline; font-color:#0066FF; }Dann sieht der Absatz plötzlich ganz anders aus.
Und dir sollte klar sein, daß man auf diese Weise die Angaben alle in einer Datei halten kann, und eben zum Ändern der Schriftart nicht mehr in tausend <font>-Tags rumfummeln muß, sondern nur noch einmal in der zentralen Datei:
p {font-family:Tahoma, sans-serif; ... }
Schon ist alles umformatiert.
Das ist mir schon klar, aber wenn die Farben nun mal immer anders sind (ich gebe zu, kommt nicht häufig vor), dann ist es viel umständlicher alles in eine CSS-Datei reinzuschreiben.
Außerdem habe ich mal versucht, auf den center-tag zu verzichten:
<center>Dieser Text ist mittig</center>CSS:
<span style="text-align: center">Dieser Text ist mittig</center> <-- Das geht nicht!Ist mir grad aufgefallen: Es sollte </span> heißen.
Klar, denn das hier geht ja auch nicht:
texttexttext<center>Das ist zentriert</center>texttexttextDu kannst nur komplette Absätze zentrieren. Also mußt du
<div style="text-align:center;">Das ist zentriert</div> nehmen.
Was nun? Der Div-Tag erzeugt automatisch einen Absatz, außerdem ist er laut SELFHTML weder in strict noch in transitional noch in frameset.
Stimmt, in der Elementreferenz sind da keine Angaben gemacht aber in der Beschreibung http://selfhtml.teamone.de/html/text/bereiche.htm#block sind deutlich die Standards HTML 3.2 und XHTML 1.0 als Icons genannt. Ist vermutlich ein Fehler, der noch nicht korrigiert wurde.
Laut W3C gehört DIV sowohl zu strict als auch zu transitional, und vermutlich darf es selbst in frameset innerhalb des noframes-Bereichs benutzt werden.
Gut zu wissen, das glaube ich mal so, dann wäre das Problem gelöst und ich kann auch alle center-Tags ersetzen.
Noch was anderes:
Nach W3 sollte sich in jedem Form-Tag eine action-Angabe befinden. Was, wenn ich gar keine action-Angabe brauche. Wieso soll ich dann action="" reinschreiben?Formulare sind per Definition dazu da, abgeschickt zu werden. Und dieses Abschicken geht irgendwo hin. Folglich muß eine Adresse angegeben werden.
Wenn du nichts abschicken willst: Laß <form> weg und probiere, ob es trotzdem geht. Obwohl ich mir da fast sicher bin, daß irgendwelche Browser das garnicht gut finden werden.
Geht nicht, wenn ich z.B. in einem JavaScript darauf zugreifen möchte.
Desweiteren meine ich rausgehört zu haben, dass, wenn der User JavaScript deaktiviert hat, DOM trotzdem funktioniert. Ich dachte bisher, dass DOM wie auch die anderen DHTML-Modelle immer in Verbindung mit JavaScript stehen, schließlich werden deren Befehle doch zwischen <script> und </script> geschrieben?!
DOM ist der Baum, der durch die Definitionen der HTML-Tags entsteht. Nur bringt der eigentlich ohne Javascript garnichts, weil er sonst ziemlich allein in der Gegend rumsteht. Wenn Javascript aus ist, kann nichts programmiertes ablaufen.
Danke für deine Antworten,
Klaus -
Guten Tag.
Ich bitte euch außerdem noch um eure Meinung hierzu:
var text = "....."
oder
text = "....."
???Hängt vom gewünschten Programm ab.
var text=".." erzeugt eine in diesem Moment lokale Variable, die für Programmcode außerhalb z.B. der Funktion unbekannt ist.
text=".." erzeugt in jedem Fall eine globale Variable, sofern sie nicht schon als lokal definiert ist.
Kann es sein, dass es dem IE egal ist, ob var davorsteht oder nicht und er alle Variablen als global ansieht?
Grüße,
Klaus-
Moin!
Kann es sein, dass es dem IE egal ist, ob var davorsteht oder nicht und er alle Variablen als global ansieht?
Grundsätzlich ist alles möglich, aber da es sich hierbei um ein ziemlich grundlegendes Feature von Javascript handelt, würde ich eher deine Programmierung als fehlerhaft bezeichnen wollen.
- Sven Rautenberg
-
Hallo!
Kann es sein, dass es dem IE egal ist, ob var davorsteht oder nicht und er alle Variablen als global ansieht?
Grundsätzlich ist alles möglich, aber da es sich hierbei um ein ziemlich grundlegendes Feature von Javascript handelt, würde ich eher deine Programmierung als fehlerhaft bezeichnen wollen.
Was soll ich denn da für einen Fehler gemacht haben? Ich habe var davor geschrieben (innerhalb einer Funktion) und die Variable ist trotzdem global. Vielleicht mal austesten ;-)
Grüße,
Klaus
-
-
-
-
Moin auch!
Einige meinen lieber auf ältere Browser keine Rücksicht mehr nehmen, andere meinen dagegen, man sollte seine HP möglichst für alle Browser kompatibel machen. Ich fände es eigentlich schon sinnvoll, alte Browser rauszudrängen (jaja ich weiß, allein bin ich machtlos), was spricht dagegen? Wenn z.B. Netscape4-User merken, dass es beim Surfen nur noch Probleme gibt, werden sie wohl irgendwann merken, dass es nicht an den einzelnen HP´s liegt.
Ich bin der Meinung, jeder Browser (der wirklich ein Browser ist, also HTML und HTTP kann) soll problemlosen Zugriff auf alle gebotenen Informationen bekommen. Gimmicks wie huebsches Layout oder JavaScript-gestuetzte Vereinfachungen (z.B. der Navigation) koennen zusaetzlich fuer Browser angeboten werden, die das unterstuetzen, aber so, dass Benutzer anderer Browser davon nicht allzuviel mitkriegen. Insbesondere sollen die nicht mit Fehlermeldungen bombardiert werden.
<font color="#FF0000">Dieser Text ist rot</font><br>
<font color="#0000FF">Dieser Text ist blau</font>
Nun will ich auf den Font-Tag verzichten:
<span style="font-color: #FF0000">Dieser Text ist rot</span><br>
<span style="font-color: #0000FF">Dieser Text ist blau</span>
Das ist viel umständlicher.Wenn das Deine Aufgabenstellung ist, ja, dann ist das umstaendlicher. Aber das ist auch nicht der Sinn von CSS. Der Vorteil wird schon da sichtbar, wenn Du mit Klassen arbeitest:
im Head:
<STYLE TYPE="text/css"> .warning { font-weight:bold; } </STYLE>
spaeter im Dokument:
<SPAN CLASS="warning">ACHTUNG! ... </SPAN>Wenn Du jetzt viele solche Warnungen im Dokument untergebracht hast, und Dir auf einmal einfaellt, Du haettest die Warnungen jetzt gern alle noch in rot, musst Du nur im Head die kleine Aenderung machen:
<STYLE TYPE="text/css"> .warning { font-weight:bold; color:#FF0000; } </STYLE>
Das war's.CSS kann aber noch viel mehr, das findest Du aber alles in Selfhtml. Um es nochmal klarzustellen, Deine Aufgabenstellung mit dem beliebigen Textfarben aendern halte ich nicht fuer besonders sinnvoll.
Außerdem habe ich mal versucht, auf den center-tag zu verzichten:
<center>Dieser Text ist mittig</center>
CSS:
<span style="text-align: center">Dieser Text ist mittig</center> <-- Das geht nicht!^^^^^^^^
Das sind ja auch zwei grundverschiedene Dinge. Hat irgendjemand behauptet, dass diese CSS-Angabe das <center>-Tag ersetzt? Dann hat der aber gelogen.text-align bezieht sich *nur* auf Blockelemente. <span> ist aber ein inline-Element, d.h. einfach gesagt, es erzeugt keinen eigenen Absatz. Du siehst den Effekt bei
<DIV style="text-align: center">Dieser Text ist mittig</DIV>
<div> ist naemlich ein Blockelement, da klappt das auch.Was nun? Der Div-Tag erzeugt automatisch einen Absatz, außerdem ist er laut SELFHTML weder in strict noch in transitional noch in frameset.
Haeh? Da sagt mein Selfhtml aber etwas anderes, und ich kann Dir versprechen, dass ich meine Version nicht selbst veraendert hab. ;-) <DIV> ist seit HTML 3.2 in saemtlichen Versionen und Ausfuehrungen enthalten.
Noch was anderes:
Nach W3 sollte sich in jedem Form-Tag eine action-Angabe befinden. Was, wenn ich gar keine action-Angabe brauche. Wieso soll ich dann action="" reinschreiben?Weiss nicht, vielleicht gehen die davon aus, dass FORMs zum Abschicken da sind. Schreib's halt einfach hin, wo ist das Problem?
Ich bitte euch außerdem noch um eure Meinung hierzu:
var text = "....."
oder
text = "....."
???Das sind ebenfalls zwei ganz verschiedene Dinge, und es kommt auf den Kontext an, was von beiden sinnvoll ist und was nicht.
Desweiteren meine ich rausgehört zu haben, dass, wenn der User JavaScript deaktiviert hat, DOM trotzdem funktioniert.
Der Sinn dieser Aussage erschliesst sich mir nicht.
So long
--
Whoever cares, calocybe is now @web.de -
Hallo.
Noch ein paar Fragen:
Wie setze ich die Befehl colspan, rowspan, cellpadding und cellspacing in CSS um?
Außerdem merke ich immer mehr, wie schwachsinnig es ist, alle Formatierungen, etc. nur noch mit CSS durchzuführen.
Habe ich z.B. so eine Tabelle:
<table bgcolor="#000000" border="0">
<tr>
<td width="60%" rowspan="2" bgcolor="#0000FF">
<td width="40%" bgcolor="#0000FF">
</tr>
<td width="40%" bgcolor="#FF0000">
</tr>
</table>Wie setze ich das in CSS um? Jetzt muss ich für jeden einzelnen TD-Tag sowie den TABLE-Tag eine eigene Klasse definieren und diese in eine CSS-Datei schreiben. Das ist doch viel umständlicher, als die ganzen Befehl direkt in die Tags zu schreiben!
Darf man vielleicht zwei class-Anweisungen in einen Tag schreiben, das wäre manchmal hilfreich.
Grüße,
Klaus-
Re!
<table bgcolor="#000000" border="0">
<tr>
<td width="60%" rowspan="2" bgcolor="#0000FF">
<td width="40%" bgcolor="#0000FF">
</tr>
<td width="40%" bgcolor="#FF0000">
</tr>
</table>Wie setze ich das in CSS um? Jetzt muss ich für jeden einzelnen TD-Tag sowie den TABLE-Tag eine eigene Klasse definieren und diese in eine CSS-Datei schreiben. Das ist doch viel umständlicher, als die ganzen Befehl direkt in die Tags zu schreiben!
Also nochmal: Wenn es Dir nur darum geht, Deine Seite irgendwie *bunt* zu machen, dann ist CSS sicherlich nicht das richtige fuer Dich. CSS spielt seine Staerken da aus, wo es darum geht, logisch strukturierte Informationen optisch (bzw. auch akustisch) hervorzuheben. Dafuer muss Deine Seite aber erstmal eine logische Struktur haben. Fuer "Guck-mal-ich-kann-Schriftfarben-aendern-Seiten-anno-1995" ist CSS nicht gemacht.
Darf man vielleicht zwei class-Anweisungen in einen Tag schreiben, das wäre manchmal hilfreich.
Du kannst class="klasse1 klasse2" schreiben.
So long
--
Perhaps the designers of CSS1 thought that the "visualists" should be given toys to play with so that they will stop playing with adults' tools (HTML).
-- http://www.cs.tut.fi/~jkorpela/styles/harmful.html -
Hi,
Darf man vielleicht zwei class-Anweisungen in einen
Tag schreiben, das wäre manchmal hilfreich.Darf man. Aber die Menge der Browser, die das versteht, ist wohl noch nicht arg groß.
Allerdings kannst Du auch an der Architektur Deines HTML-Codes arbeiten:
<tr>
<td width="60%" rowspan="2" bgcolor="#0000FF">
<td width="40%" bgcolor="#0000FF">
</tr>
<td width="40%" bgcolor="#FF0000">In diesem Falle würde ich die bgcolor nämlich nicht im <td>, sondern im <tr> setzen. Das spart Code (sowohl in HTML als auch in CSS).
Beispiel (in CSS):
td {vertical-align:top; text-align:center;}
tr.blau {background-color:#0000ff;}
td.text {text-align:left;}
td.zahl {text-align:right;}Damit kannst Du nun eine Tabelle der Art
<table>
<tr class="blau">
<td class="text">Anzahl der Besucher:</td>
<td class="zahl">42</td>
</tr>
</table>formulieren.
Und Du hättest die Bedeutung von td.text sogar im Kontext setzen können, also etwa
tr.blau td {color:#ffffff;}
um mit weißer Schrift zu schreiben, _falls_ der Hintergrund blau ist.
Viele Grüße
Michael-
Hallo!
Danke euch beiden für die Antworten, ich habe meine Seite jetzt fast zu einem strict-Dokument umgebastelt!
Leider zeigt der Validator leider noch ein paar mir unerklärliche Fehler an, wie z.B. folgende Zeile direkt nach dem Body-Tag:
<a name="anfang"> </a>Possible cause as an inline-element containing a block-element oder so ähnlich. Diese Meldung zeigt er auch bei anderen Zeilen an, wisst ihr woran es liegt?
Außerdem zeigt er merkwürdigerweise eine Zeile an, die ausschließlich einen select-Tag enthält, welcher sich zwischen zwei Form-Tags befindet.
Naja, wann werden der font- und der div-Tag eigentlich endgültig Geschichte sein und wann wird wohl nur noch mit CSS gearbeitet?(Bezüglich Formatierungen (Farbangabe, Ausrichtung, usw.) natürlich)
Bisher sind ja fast alle Dokumente im WWW transitional, wenn überhaupt. Ist ja auch kein Wunder bei den Browsern, die es zur Zeit gibt und den teilweise sehr alten, aber trotzdem verwendeten. Die Seite vom W3C sieht ja auch nicht besonders gut aus!
Ach ja: Hat jemand eine Idee, wie ich die Befehle cellpadding, cellspacing, colspan und rowspan in CSS umsetze, oder geht das gar nicht. Im Gegensatz zur width-Angabe im table-Tag zeigt der Validator mir diese Befehle selbst unter strict nämlich nicht als fehlerhaft an.
Grüße,
Klaus-
Moin!
Leider zeigt der Validator leider noch ein paar mir unerklärliche Fehler an, wie z.B. folgende Zeile direkt nach dem Body-Tag:
<a name="anfang"> </a>Possible cause as an inline-element containing a block-element oder so ähnlich. Diese Meldung zeigt er auch bei anderen Zeilen an, wisst ihr woran es liegt?
Ist aus dem angebotenen Quelltext für mich nicht ersichtlich (vielleicht bin ich auch blind). Gib mal eine URL an.
Außerdem zeigt er merkwürdigerweise eine Zeile an, die ausschließlich einen select-Tag enthält, welcher sich zwischen zwei Form-Tags befindet.
Und? Befindet sich die Zeile nicht im Quelltext? Oder fehlt da was?
Naja, wann werden der font- und der div-Tag eigentlich endgültig Geschichte sein und wann wird wohl nur noch mit CSS gearbeitet?(Bezüglich Formatierungen (Farbangabe, Ausrichtung, usw.) natürlich)
FONT ist schon Geschichte (jedenfalls bei mir, Schriftformatierung mit CSS geht ja viel besser), und DIV wird niemals Geschichte, denn das ist elementares Grundelement für die CSS-Formatierung! ;)
Bisher sind ja fast alle Dokumente im WWW transitional, wenn überhaupt. Ist ja auch kein Wunder bei den Browsern, die es zur Zeit gibt und den teilweise sehr alten, aber trotzdem verwendeten. Die Seite vom W3C sieht ja auch nicht besonders gut aus!
Du benutzt den IE? Da sehen die Seiten wirklich bescheiden aus - hängt natürlich auch von den Seiten ab, die du ansiehst. Die Spezifikationen sind langweilig formatiert, aber die CSS-Seiten sind durchaus bunt.
Ach ja: Hat jemand eine Idee, wie ich die Befehle cellpadding, cellspacing, colspan und rowspan in CSS umsetze, oder geht das gar nicht. Im Gegensatz zur width-Angabe im table-Tag zeigt der Validator mir diese Befehle selbst unter strict nämlich nicht als fehlerhaft an.
Cellpadding ist (was sollte auch anderes in Frage kommen) in CSS die Angabe padding.
Cellspacing ist derzeit noch etwas problematisch: http://forum.de.selfhtml.org/archiv/2002/3/7991/#m44276
Colspan und Rowspan können nicht in CSS umgesetzt werden, weil sie sie logische Struktur der Tabelle beschreiben. Und für die Beschreibung von logischen Strukturen ist HTML zuständig.
- Sven Rautenberg
-
Hi Sven,
Colspan und Rowspan können nicht in CSS umgesetzt
werden, weil sie sie logische Struktur der Tabelle
beschreiben. Und für die Beschreibung von logischen
Strukturen ist HTML zuständig.wobei SelfHTML 7.0 noch auf einem CSS-Draft aufsetzte, der anderer Meinung war,
http://aktuell.de.selfhtml.org/archiv/doku/7.0/tdcf.htm#a6
sich aber nicht durchgesetzt hat.
Viele Grüße
Michael -
Hallo!
Leider zeigt der Validator leider noch ein paar mir unerklärliche Fehler an, wie z.B. folgende Zeile direkt nach dem Body-Tag:
<a name="anfang"> </a>Possible cause as an inline-element containing a block-element oder so ähnlich. Diese Meldung zeigt er auch bei anderen Zeilen an, wisst ihr woran es liegt?
Ist aus dem angebotenen Quelltext für mich nicht ersichtlich (vielleicht bin ich auch blind). Gib mal eine URL an.
Habe den Fehler mit Hilfe von Michael gefunden. Es lag daran, dass man den a-tag erst in einen div-Bereich setzen musste.
Außerdem zeigt er merkwürdigerweise eine Zeile an, die ausschließlich einen select-Tag enthält, welcher sich zwischen zwei Form-Tags befindet.
Und? Befindet sich die Zeile nicht im Quelltext? Oder fehlt da was?
Nein, es befindet sich eine Auswahlliste innerhalb eines Formulars. In der Auswahlliste gibt es natürlich mehrere Optionen, der select-Tag wird trotzdem als "fehl am Platz" angezeigt.
Naja, wann werden der font- und der div-Tag eigentlich endgültig Geschichte sein und wann wird wohl nur noch mit CSS gearbeitet?(Bezüglich Formatierungen (Farbangabe, Ausrichtung, usw.) natürlich)
FONT ist schon Geschichte (jedenfalls bei mir, Schriftformatierung mit CSS geht ja viel besser), und DIV wird niemals Geschichte, denn das ist elementares Grundelement für die CSS-Formatierung! ;)
Tschuldigung, habe mich vertan. :-) Ich meinte natürlich den center-tag!
Ach ja: Hat jemand eine Idee, wie ich die Befehle cellpadding, cellspacing, colspan und rowspan in CSS umsetze, oder geht das gar nicht. Im Gegensatz zur width-Angabe im table-Tag zeigt der Validator mir diese Befehle selbst unter strict nämlich nicht als fehlerhaft an.
Cellpadding ist (was sollte auch anderes in Frage kommen) in CSS die Angabe padding.
Cellspacing ist derzeit noch etwas problematisch: http://forum.de.selfhtml.org/archiv/2002/3/7991/#m44276
Colspan und Rowspan können nicht in CSS umgesetzt werden, weil sie sie logische Struktur der Tabelle beschreiben. Und für die Beschreibung von logischen Strukturen ist HTML zuständig.
Werde ich mir gleich mal ansehen, danke für den Link, usw.
Ach ja, wieso findet das W3C eigentlich HR nicht gut, da spricht doch nun wirklich nichts gegen!Danke für deine Antwort,
Klaus-
Hi,
Ach ja, wieso findet das W3C eigentlich HR nicht gut,
da spricht doch nun wirklich nichts gegen!was genau meinst Du damit?
Du weißt, daß <hr> ein singulärer tag ist, der in XHTML geschlossen werden muß?
Viele Grüße
Michael-
Hallo!
Du weißt, daß <hr> ein singulärer tag ist, der in XHTML geschlossen werden muß?
Ja, das weiß ich schon :-)
Aber guck mal hier:
http://selfhtml.teamone.de/html/referenz/attribute.htmAuf der Seite bin ich übrigens auf andere merkwürdige Dinge gestoßen:
Der br-Tag ist angeblich unter strict verboten. Zeigt der Validator mir aber nicht an, wüsste auch nicht wieso das so sein sollte.Allerdings hat der Validator mir auch angezeigt, dass der Befehl target im a-tag unter strict verboten wäre. Wie soll ich den in CSS umsetzen?
Der html-Tag soll auch unter strict verboten sein!?
Der p-Tag ebenfalls, was nicht so schlimm wäre, da man ihn durch div ersetzen kann.
Grüße,
Klaus-
hi
Bei <hr /> steht da nur, dass die ganzen Atribute Müll sind.
Auf der Seite bin ich übrigens auf andere merkwürdige Dinge gestoßen:
Der br-Tag ist angeblich unter strict verboten. Zeigt der Validator mir aber nicht an, wüsste auch nicht wieso das so sein sollte.aghr! Kommt mir das nur so vor, oder ist die Seite ziemlich fehlerverseucht..?
Allerdings hat der Validator mir auch angezeigt, dass der Befehl target im a-tag unter strict verboten wäre. Wie soll ich den in CSS umsetzen?
gar nicht.
Der html-Tag soll auch unter strict verboten sein!?
nur das Attribut "version" (hat das je wer benutzt?). Dafür sollte man jetzt xmlns="http://www.w3.org/1999/xhtml" ranschreiben.
Der p-Tag ebenfalls, was nicht so schlimm wäre, da man ihn durch div ersetzen kann.
nur dessen align-Attribut.
-
Hallo!
Bei <hr /> steht da nur, dass die ganzen Atribute Müll sind.
Stimmt, zum einen habe ich bei Attributreferenz geschaut, zum anderen habe ich auf dieser Seite http://selfhtml.teamone.de/html/text/trennlinien.htm auch beim Lesen gepennt: Dort steht ebenfalls, dass die Attribute unter strict rausfallen, aber nicht der Tag selbst.
Dort steht außerdem, dass das Attribut color nur beim IE geht, mit CSS ist es aber geplant, dass es überall geht, oder? Also gerade der Vorteil an CSS, dass man alle Tags frei formatieren kann.Auf der Seite bin ich übrigens auf andere merkwürdige Dinge gestoßen:
Der br-Tag ist angeblich unter strict verboten. Zeigt der Validator mir aber nicht an, wüsste auch nicht wieso das so sein sollte.aghr! Kommt mir das nur so vor, oder ist die Seite ziemlich fehlerverseucht..?
Wieso? Dort habe ICH mich ebenfalls wieder geirrt, ich war auf der Attribut-Seite!
Allerdings hat der Validator mir auch angezeigt, dass der Befehl target im a-tag unter strict verboten wäre. Wie soll ich den in CSS umsetzen?
gar nicht.
Also ein Fehler des Validators?
Der html-Tag soll auch unter strict verboten sein!?
nur das Attribut "version" (hat das je wer benutzt?). Dafür sollte man jetzt xmlns="http://www.w3.org/1999/xhtml" ranschreiben.
Jaja, Attribut-Referenz.
Der p-Tag ebenfalls, was nicht so schlimm wäre, da man ihn durch div ersetzen kann.
nur dessen align-Attribut.
Und schon wieder... Man, da hätte ich auch mal genauer gucken sollen, dann hätte ich gemerkt, dass ich mich auf der Attributreferenz-, nicht auf der Elementreferenzseite befinde!
Danke für deine Antwort,
Klaus-
hi
Dort steht außerdem, dass das Attribut color nur beim IE geht, mit CSS ist es aber geplant, dass es überall geht, oder? Also gerade der Vorteil an CSS, dass man alle Tags frei formatieren kann.
soweit die Theorie.. in der Praxis nimmt der IE aber nur color:, konqueror nur background-color: und Mozilla nur border-color: (oder andersrum). Opera, Amaya und NN4 peilen gar nix
Wieso? Dort habe ICH mich ebenfalls wieder geirrt, ich war auf der Attribut-Seite!
DAS war jetzt mal ausnahmsweise die Elementseite - oder...?!
Also ein Fehler des Validators?
ne, in 'Strict' sind Fensterspielchen nicht erlaubt.
gruss Kai
-
Hallo!
Dort steht außerdem, dass das Attribut color nur beim IE geht, mit CSS ist es aber geplant, dass es überall geht, oder? Also gerade der Vorteil an CSS, dass man alle Tags frei formatieren kann.
soweit die Theorie.. in der Praxis nimmt der IE aber nur color:, konqueror nur background-color: und Mozilla nur border-color: (oder andersrum). Opera, Amaya und NN4 peilen gar nix
Jaja, die nervigen Browserprobleme eben...
Wieso? Dort habe ICH mich ebenfalls wieder geirrt, ich war auf der Attribut-Seite!
DAS war jetzt mal ausnahmsweise die Elementseite - oder...?!
Nö, war auch die Attributreferenzseite.
Also ein Fehler des Validators?
ne, in 'Strict' sind Fensterspielchen nicht erlaubt.
Naja, was heißt Fensterspielchen? Darf ich jetzt die Links nur noch im selben Fenster öffnen, oder was?
Grüße,
Klaus-
hi
Naja, was heißt Fensterspielchen? Darf ich jetzt die Links nur noch im selben Fenster öffnen, oder was?
jau... Das W3C enkt eben bei den Standards immer noch Ausschließlich daran damit Informationen zu strukturieren.. und dafür ist ein Sich öffnendes Fenster nur hinderlich.
gruss Kai
-
-
-
-
-
-
-
-
-
Hi Klaus,
Bisher sind ja fast alle Dokumente im WWW
transitional, wenn überhaupt. Ist ja auch
kein Wunder bei den Browsern, die es zur Zeit
gibt und den teilweise sehr alten, aber trotzdem
verwendeten.das ist eben eine Frage der Aufgabenstellung.
So gnadenlos, wie ich in unserer Firma Netscape 4 mit DHTML versorgen muß, so gnadenlos ignoriere ich ihn auf meiner Homepage und strebe in der Tat XHTML 1.0 Strict an. (Im nächsten Urlaub wird das durchgezogen, für etwas über 1000 Seiten - XHTML 1.0 Transitional sind sie schon.)
Leider zeigt der Validator leider noch ein paar mir
unerklärliche Fehler an, wie z.B. folgende Zeile
direkt nach dem Body-Tag:
<a name="anfang"> </a>
Possible cause as an inline-element containing a
block-element oder so ähnlich.
Diese Meldung zeigt er auch bei anderen Zeilen an,
wisst ihr woran es liegt?Block-Level-Elemente sind die 'äußeren', die nicht innerhalb der 'inneren' inline-Elemente verwendet werden dürfen - nur umgekehrt.
Aber bei "Strict" könnte es auch verboten sein, ein <a...> direkt in ein <body> zu schreiben, ohne wenigstens ein <p> oder ein <div> drum herum ...
Außerdem zeigt er merkwürdigerweise eine Zeile an,
die ausschließlich einen select-Tag enthält,
welcher sich zwischen zwei Form-Tags befindet.Zwischen zwei <form>s?
Was hat ein <select> außerhalb eines Formulars verloren?Viele Grüße
Michael-
Hallo.
So gnadenlos, wie ich in unserer Firma Netscape 4 mit DHTML versorgen muß, so gnadenlos ignoriere ich ihn auf meiner Homepage und strebe in der Tat XHTML 1.0 Strict an. (Im nächsten Urlaub wird das durchgezogen, für etwas über 1000 Seiten - XHTML 1.0 Transitional sind sie schon.)
So werde ich es bei meinen zukünftigen Projekten auch machen, wieso alte Browser verwenden, wenns schon neue, bessere gibt?!
Aber es reicht doch hoffentlich auch HTML 4.01, oder? Was würde für XHTML 1.0 sprechen?Leider zeigt der Validator leider noch ein paar mir
unerklärliche Fehler an, wie z.B. folgende Zeile
direkt nach dem Body-Tag:
<a name="anfang"> </a>
Possible cause as an inline-element containing a
block-element oder so ähnlich.
Diese Meldung zeigt er auch bei anderen Zeilen an,
wisst ihr woran es liegt?Block-Level-Elemente sind die 'äußeren', die nicht innerhalb der 'inneren' inline-Elemente verwendet werden dürfen - nur umgekehrt.
Aber bei "Strict" könnte es auch verboten sein, ein <a...> direkt in ein <body> zu schreiben, ohne wenigstens ein <p> oder ein <div> drum herum ...
Stimmt, das war der Fehler!!! Woher weiß man sowas denn?
Außerdem zeigt er merkwürdigerweise eine Zeile an,
die ausschließlich einen select-Tag enthält,
welcher sich zwischen zwei Form-Tags befindet.Zwischen zwei <form>s?
Was hat ein <select> außerhalb eines Formulars verloren?Nein, select befindet sich innerhalb des Formulars und wird trotzdem angezeigt.
Danke für deine Antworten,
Klaus-
Hi Klaus,
So werde ich es bei meinen zukünftigen Projekten
auch machen, wieso alte Browser verwenden, wenns
schon neue, bessere gibt?!wie erwähnt - bei Surfern im Web darf ich eher auf den automatischen Upgrade-Mechanismus setzen (weil die wenigstens die _Chance_ haben, neuere Browser zu installieren oder bei irgendwelchen Upgrades wie "AOL 8.0" automatisch installiert zu bekommen - meine erste Provider-Installations-CD hat mir das halbe Betriebssystem revolutioniert, damals mit M$IE 5.0 für Windows 95) als bei Firmenkunden mit Flottenpolitik.
Aber es reicht doch hoffentlich auch HTML 4.01,
oder? Was würde für XHTML 1.0 sprechen?Ich denke, das ist gar nicht so sehr die Frage.
Ich nehme XHTML 1.0, weil ich es für 'besser' halte als HTML 4.01, in einem ganz abstrakten und für den Anwender völlig irrelevanten Sinne.
Und der Umstieg zwischen HTML 4.01 Transitional und XHTML 1.0 Transitional ist auch wirklich nicht schwer.Sehr viel relevanter (und aufwändiger) ist m. E. der Umstieg zwischen "Transitional" und "Strict" - egal, in welcher Version. Denn das bedeutet, die Brücken zur Vergangenheit abzubrechen, also die Abwärtskompatibilität zu opfern. So etwas tut man nur, wenn man sich fest darauf verlassen kann, es sich leisten zu können - entweder für eine closed user group (das könnte dann tatsächlich ein Vorteil sein, nur für bestimmte Firmenkunden programmieren zu müssen) oder weil man eben einen einheitlichen, modernen Programmierstil pflegen will.
Die Massen-Portale werden m. E. die letzten sein, die noch auf Jahre hinaus abwärtskompatibel zu allem möglichen Zeug sein müssen.
Es gibt übrigens einen echten Grund für XHTML: Klein geschriebene Tags sind besser komprimierbar ...
Aber bei "Strict" könnte es auch verboten sein,
ein <a...> direkt in ein <body> zu schreiben,
ohne wenigstens ein <p> oder ein <div> drum herum
...
Stimmt, das war der Fehler!!! Woher weiß man sowas
denn?Indem man es irgendwo gelesen hat (ich beispielsweise bestimmt hier im Forum, denn komplette DTDs lesen ist derzeit noch nicht mein Ding) und es sich dann irgendwie merkt ...
Viele Grüße
Michael
-
-
-
-
-
hi
Wie setze ich die Befehl colspan, rowspan, cellpadding und cellspacing in CSS um?
cellspan, rowspan bleibt erhalten (vorerst)
cellpadding ist das padding der zellen.. also td{padding:0px;} oder so
cellspacing heißt in CSS border-spacing.Außerdem merke ich immer mehr, wie schwachsinnig es ist, alle Formatierungen, etc. nur noch mit CSS durchzuführen.
Habe ich z.B. so eine Tabelle:
<table bgcolor="#000000" border="0">
<tr>
<td width="60%" rowspan="2" bgcolor="#0000FF">
<td width="40%" bgcolor="#0000FF">
</tr>
<td width="40%" bgcolor="#FF0000">
</tr>
</table>Wie setze ich das in CSS um? Jetzt muss ich für jeden einzelnen TD-Tag sowie den TABLE-Tag eine eigene Klasse definieren und diese in eine CSS-Datei schreiben. Das ist doch viel umständlicher, als die ganzen Befehl direkt in die Tags zu schreiben!
DAS geht jetzt sau einfach. Geben wir der Tabelle mal die id="tab" (wirklich nichts sonst!!)
#tab{background-color:#000;border-width:0px;}
#tab tr td{background-color:#F00;width:40%;}
#tab tr:first-child td{background-color:#00F;width:60%;}
#tab tr:first-child td:first-child{background-color:#00F;width:40%;}ok, für den IE wird das schwerer... Aber, wenn du hunderte solcher Tabellen in deinen projekt hast, ist das in einiges einfacher!
Darf man vielleicht zwei class-Anweisungen in einen Tag schreiben, das wäre manchmal hilfreich.
class="kl1 kl2 kl3" so viele, wie du willst
gruss Kai
-
Hallo Kai!
Danke für deine Antworten!
Gruß,
Klaus
-
-
-
hi
Die language-Angabe im SCRIPT-Tag: Einige sagen sinnlos, andere halten sie für dringend notwendig. Ich habe mich dazu entschieden, immer die Angabe language="JavaScript" reinzusetzen, sinnvoll? Desweiteren frage ich mich, wieso das beim IE auch ohne kein Problem ist, dann sollte man doch die anderen Browser auch so entwickeln. Es spart Programieraufwand und Bytes, also Ladezeit. Genauso ist es bei den type-Angaben.
Opera besteht auf language - warum auch immer.
Type: das ist dazu da, um auch schon vor dem Laden der datei zu erkennen, ob der Browser das intern verarbeiten kann, Downloaden muss oder Plugin anwirft.Nun will ich auf den Font-Tag verzichten:
<span style="font-color: #FF0000">Dieser Text ist rot</span><br>
<span style="font-color: #0000FF">Dieser Text ist blau</span>Das ist viel umständlicher.
schlechtes Beispiel. Man kann ja JEDES Element formatieren, und meistens reicht die Formatierung tatsächlich über ein komplettes Element. Auch kann man über class="", id="" und verschachtelte Dateistruktur vie erreichen.
CSS:
<span style="text-align: center">Dieser Text ist mittig</center> <-- Das geht nicht!<div style="text-align: center">Dieser Text ist mittig</div>
<span> ist ein inline-Element, die haben keine text-align.Was nun? Der Div-Tag erzeugt automatisch einen Absatz, außerdem ist er laut SELFHTML weder in strict noch in transitional noch in frameset.
ups.. den Fehler sollte mal wer melden
Nach W3 sollte sich in jedem Form-Tag eine action-Angabe befinden. Was, wenn ich gar keine action-Angabe brauche. Wieso soll ich dann action="" reinschreiben?
wenn du sie nicht brauchst, ist es zu 99% ein Missbrauch von <form>
var text = "....."
oder
text = "....."var text = "..." - ist einfach übersichtlicher.
Desweiteren meine ich rausgehört zu haben, dass, wenn der User JavaScript deaktiviert hat, DOM trotzdem funktioniert. Ich dachte bisher, dass DOM wie auch die anderen DHTML-Modelle immer in Verbindung mit JavaScript stehen, schließlich werden deren Befehle doch zwischen <script> und </script> geschrieben?!
Quark, DOM ist JS und wird damit dabei abgeschaltet.
gruss Kai
-
Moin,
var text = "..." - ist einfach übersichtlicher.
Und bedeutet auch etwas anderes als einfach nur text = "...", und ist daher, wenn keine globalen Variablen benötigt werden, vorzuziehen.
Quark, DOM ist JS und wird damit dabei abgeschaltet.
Quark, DOM hat mit JS fast nichts zu tun, ausser dass es für das Document Object Model eben auch eine ECMA Script Anbindung gibt, wie beispielsweise für Java auch. http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001 ist eine recht aufschlußreiche Bettlektüre.
Zwei Sachen noch die bisher glaube ich nicht deutlich genug rausgekommen sind:
-document.write("<a href='link.html'>Link</a>")
^ ^
Das da ist falsch, in HTML dürfen Attributwerte nicht in einfache Anführungszeichen eingeschlossen werden.-IF, THEN, ELSE: Diese Anweisung kann man in JavaScript auf zwei Arten umsetzen:
Nein, die beiden Beispiel die du gebracht hast, sind zwei unterschiedliche Sachen:
Beispiel: i > z ? i = 1 : i = 0
Das ist ein Ausdruck und kann überall verwendet werden wo ein Ausdruck stehen darf. Dafür darf vor, zwischen und nach den ? und : auch nur ein Ausdruck stehen.
oder if (i > z) { i = 1; } else { i = 0; }
Das da ist kein Ausdruck sondern einige Anweisungen umgeben von einer Kontrollstruktur. Das darf nicht überall stehen, dafür können die einzelnen Teile aber auch beliebige Anweisungen sein.
Was ist sinnvoller?
Es geht weniger darum was sinnvoller ist, sondern zunächst darum was an der entsprechenden Stelle erlaubt ist. Wenn denn beides erlaubt ist, kommt es drauf an was den Code einfacher zu lesen macht.
Bei i = (i>z) ? 1 : 0; würde ich mich wohl jederzeit für den trinären Operator (das ?:-Dings) entscheiden da hier ersichtlich wird, dass in jedem Fall eine Zuweisung an i erfolgt. (i>z) ? (i=1) : (z=1); stellt hingegen klar einen Missbrauch dieses Operators dar und sollte mit if geschrieben werden (abgesehen davon dass Seiteneffekte wie die Zuweisung an Stelle eines Ausdrucks bei diversen Leuten ungern gesehen werden).
--
Henryk Plötz
Grüße von der Ostsee-
Hallo!
Zwei Sachen noch die bisher glaube ich nicht deutlich genug rausgekommen sind:
-document.write("<a href='link.html'>Link</a>")
^ ^
Das da ist falsch, in HTML dürfen Attributwerte nicht in einfache Anführungszeichen eingeschlossen werden.Gut zu wissen, bestätigt mich zudem in meiner Entscheidung folgende Variante zu verwenden:
-document.write('<a href="link.html">Link</a>')
Hoffentlich ist diese auch offiziell erlaubt und nicht nur diese:
-document.write("<a href="link.html">Link</a>")
Bei der von mir gewählten ist nämlich ein entscheidender Vorteil, dass der Schreibfluss nicht unterbrochen wird, da man (ich schätze über 90%) in HTML auch "..." verwendet und man sich dann nicht umstellen muss.Bei i = (i>z) ? 1 : 0; würde ich mich wohl jederzeit für den trinären Operator (das ?:-Dings) entscheiden da hier ersichtlich wird, dass in jedem Fall eine Zuweisung an i erfolgt. (i>z) ? (i=1) : (z=1); stellt hingegen klar einen Missbrauch dieses Operators dar und sollte mit if geschrieben werden (abgesehen davon dass Seiteneffekte wie die Zuweisung an Stelle eines Ausdrucks bei diversen Leuten ungern gesehen werden).
Was heißt Missbrauch? Ist das offiziell nicht erlaubt (wie z.B. in HTML offiziell nur "..." und nicht '...' erlaubt ist)?
Grüße,
Klaus -
hi
Zwei Sachen noch die bisher glaube ich nicht deutlich genug rausgekommen sind:
-document.write("<a href='link.html'>Link</a>")
^ ^
Das da ist falsch, in HTML dürfen Attributwerte nicht in einfache Anführungszeichen eingeschlossen werden.Zum briblen wird's nur, wenn man den IE5.0 hat...
onmouseover="this.style.color='red';" mag der inho nicht
onmouseover='this.style.color="red";' aber schongruss Kai
-
-
Hallo!
Nach W3 sollte sich in jedem Form-Tag eine action-Angabe befinden. Was, wenn ich gar keine action-Angabe brauche. Wieso soll ich dann action="" reinschreiben?
wenn du sie nicht brauchst, ist es zu 99% ein Missbrauch von <form>
Also ist die SELFHTML-Quickbar ein Missbrauch von <form> ?
Grüße,
Klaus
-
-