nicht angemeldet
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
Gunnar Bittersmann
molily
molily
molily
molily
molily
Gunnar Bittersmann
Hallo,
habe ein kleines Problem bei meinem Script. Muss gleich dazu sagen, dass ich noch Anfänger bin.
Hier erstmal mein Script:
<script language=JavaScript>
<!--
function rechner(){
if(document.Formular.a[0].checked == true){
var Benzin = (document.Formular.wert.value)*23.7;
document.getElementById("ausgabe").innerHTML = "Dies entspricht einem Ausstoß von "+Benzin+" g Co2/km"}
if(document.Formular.a[1].checked == true){
var E85 = (document.Formular.wert.value)*3.555;
document.getElementById("ausgabe").innerHTML = "Dies entspricht einem Ausstoß von "+E85+" g Co2/km"}
}
//-->
</script>
<form name=Formular>
<table align=center cellpadding=0 cellspacing=0><tr><td>
Verbrauch: <input type="text" size=12 name="wert" maxlength="3" class="inp4">l/100km<br>
<input type="radio" name="a">Benzin<br>
<input type="radio" name="a">E85<br>
<input type="button" value="berechnen" onClick="rechner()" class="button"><br><br>
<div id="ausgabe"></div>
</td></tr></table>
</form>
Funktioniert auch so weit, nur wenn ein Kommawert eingegeben wird, kommt als Ausgabe nur NaN. Dies sollte ja mit dem replace wohl gehen. Die Fraeg ist, nur wie geht das ?
Für eure Hilfe wäre ich sehr dankbar!
@@Beto:
<script language=JavaScript>
Millionenfacher Unsinn. Wie JavaScript richtig in HTML eingebunden wird.
<!--
Die Auskommentierung ist völlig überflüssig.
Funktioniert auch so weit, nur wenn ein Kommawert eingegeben wird, kommt als Ausgabe nur NaN. Dies sollte ja mit dem replace wohl gehen. Die Fraeg ist, nur wie geht das ?
Wie in SELFHTML beschrieben:
var Benzin = document.Formular.wert.value.replace(/,/, ".") * 23.7;
Wobei ich zumindest noch ein parseFloat() spendieren würde:
var Benzin = parseFloat(document.Formular.wert.value.replace(/,/, ".")) * 23.7;
Oder falsche Eingaben (wie "a42") anders abfangen.
Live long and prosper,
Gunnar
Millionenfacher Unsinn. Wie JavaScript richtig in HTML eingebunden wird.
Google:
Ergebnisse [...] ungefähr 14.200.000 für <script language="javascript">.
Hi,
Ergebnisse [...] ungefähr 14.200.000 für <script language="javascript">.
Ach, stör dich nicht dran. Gunnar predigt hier seine persönlichen Auffassungen so gnadenlos, wie Osama bin Laden den Koran: Nur die heilige Schrift zählt, und wie man sie zu interpretieren hat, bestimmt im Zweifel er ... >;->
... was man dann auch jedem mitteilen muß, der es hören/lesen will (oder auch nicht). :)
Gruß, Cybaer
... was man dann auch jedem mitteilen muß, der es hören/lesen will (oder auch nicht). :)
aber er hat doch recht ;)
Hi,
aber er hat doch recht ;)
Also einer der bekanntesten JS-Gurus (Crockford?) schwört darauf, überhaupt keine Angabe zu machen (weder type noch language) - und weiß es sogar noch öffentlich zu begründen (Skandal).
Aber Gottseidank postet der nicht auch noch hier im Forum. Wir müssen uns mit Gunnar begnügen ... ;)
Gruß, Cybaer
Hi,
aber er hat doch recht ;)
Also einer der bekanntesten JS-Gurus (Crockford?) schwört darauf, überhaupt keine Angabe zu machen (weder type noch language) - und weiß es sogar noch öffentlich zu begründen (Skandal).
naja, er verlässt sich darauf dass ein browser standardmäßig den mime type text/javascript für <script /> und text/css für <style /> verwendet - das sollte per defintion auch so sein, aber es ist nicht falsch sonder nur etwas redundant den typ anzugeben - im übrigen ist die redundante angabe des mime type seit html 4.0 pflicht, ein entsprechender validator wird das nicht toll finden, funktionieren wirds ohne zweifel trotzdem
[latex]Mae govannen![/latex]
naja, er verlässt sich darauf dass ein browser standardmäßig den mime type text/javascript für <script /> und text/css für <style /> verwendet - das sollte per defintion auch so sein, aber es ist nicht falsch sonder nur etwas redundant den typ anzugeben - im übrigen ist die redundante angabe des mime type seit html 4.0 pflicht, ein entsprechender validator wird das nicht toll finden, funktionieren wirds ohne zweifel trotzdem
Wahrscheinlich hat Crockford einfach nur keine Lust, den unsinnigen Hickhack mitzumachen und setzt daher auf die pragmatische Lösung ;)
Cü,
Kai
Hi,
Wahrscheinlich hat Crockford einfach nur keine Lust, den unsinnigen Hickhack mitzumachen und setzt daher auf die pragmatische Lösung ;)
Wen interessieren denn hier "pragmatische Lösungen", wenn es "Vorschriften" gibt, an die man sich gefälligst zu halten hat? >;->
Gruß, Cybaer
Hi,
im übrigen ist die redundante angabe des mime type seit html 4.0 pflicht, ein entsprechender validator wird das nicht toll finden, funktionieren wirds ohne zweifel trotzdem
Nebst der Möglichkeit, entsprechendes für Scripts und Styles im HEAD als META-Element zu definieren (gibt ja schließlich auch Inlune-Scripts & -Styles). Wird zwar (immer noch) von keinem Browser genutzt, aber schön, daß es das gibt! >;->
Gruß, Cybaer
PS: Ich verwende übrigens TYPE, LANGUAGE *und* META. So hat halt jeder seine persönliche Note ... >;->
Hallo,
Also einer der bekanntesten JS-Gurus (Crockford?) schwört darauf, überhaupt keine Angabe zu machen (weder type noch language) - und weiß es sogar noch öffentlich zu begründen (Skandal).
Ja, es ist Crockford, Zitat:
"'language="javascript'
This attribute has been deprecated. It was used to select other programming languages and specific versions of JavaScript. You don't need it. Don't use it.
type='text/javascript'
This attribute is optional. Since Netscape 2, the default programming language in all browsers has been JavaScript. In XHTML, this attribute is required and unnecessary. In HTML, it is better to leave it out. The browser knows what to do. "
Gruß, Don P
Hi,
This attribute has been deprecated. It was used to select other programming languages and specific versions of JavaScript.
Ja, die JS-Engine sollte ggf. den JS-Code in Abhängigkeit einer möglichen Versionsangabe interpretieren (sowohl im Prinzip, als auch im Detail).
Aber das hat browserübergreifend eh nie fehlerfrei geklappt ...
In XHTML, this attribute is required and unnecessary. In HTML, it is better to leave it out. The browser knows what to do. "
... weswegen man diese tolle Idee der versionsabhängigen Interpretation jüngst beim TYPE-Attribut eingeführt hat ...
... wo sich diesmal aber auch wirklich und ganz bestimmt alle Browser dran halten werden (isch schwör!). >;->
Gruß, Cybaer
@@Don P:
Also einer der bekanntesten JS-Gurus (Crockford?) schwört darauf, überhaupt keine Angabe zu machen
Als JavaScript-Guru kennt er sich mit dem aus, was zwischen dem '>' von '<script.*>' und dem '<' von '</script> steht; nicht notwendigerweise auch mit dem, was links und rechts davon steht.
Anders gesagt: Man kann durchaus JavaScript-Guru sein, ohne Ahnung von HTML zu haben.
Ja, es ist Crockford, Zitat:
"'language="javascript'
This attribute has been deprecated. It was used to select other programming languages and specific versions of JavaScript. You don't need it. Don't use it.
Hierin hat er recht.
type='text/javascript'
This attribute is optional.
Hierin nicht. Es war noch nie optional. In HTML 3.2 gab es dies überhaupt nicht [HTML32]; ab HTML 4.0 ist es Pflicht [HTML40].
In XHTML, this attribute is required and unnecessary.
Das ist doppelter Unsinn. Zum einen schließen "required" und "unnecessary" einander aus. Zum anderen scheint sich Crockford der Unterschiede zwischen HTML 4.01 und XHTML 1.0 nicht im Klaren zu sein.
Live long and prosper,
Gunnar
Hi,
Zum anderen scheint sich Crockford der Unterschiede zwischen HTML 4.01 und XHTML 1.0 nicht im Klaren zu sein.
Auch wenn ich Crockfords Auffassungen selbst nicht alle teile: Er macht weder einen dementen Eindruck, noch den Anschein, als ob er sich so wenig mit (X)HTML auskennen würde.
Ich tippe eher darauf, daß (ja nicht nur) ihm dieses "Vorschrifts-Geseiere" irgendwo total vorbeigeht. Vielleicht ist er ja, wie auch ich, einfach durch die langjährigen Umgang mit der Praxis für sowas nachhaltig versaut ... >:->
Gruß, Cybaer
Hallo,
Anders gesagt: Man kann durchaus JavaScript-Guru sein, ohne Ahnung von HTML zu haben.
Scheint so...
This attribute has been deprecated. It was used to select other programming languages and specific versions of JavaScript. You don't need it. Don't use it.
Hierin hat er recht.
Ja, das ist unumstritten.
type='text/javascript'
This attribute is optional.
Hierin nicht. Es war noch nie optional.
In der Tat, das einzige Attribut, das benötigt wird, ist "type", Auszug aus der HTML 4.0 DTD:
<!ATTLIST SCRIPT
charset %Charset; #IMPLIED -- char encoding of linked resource --
type %ContentType; #REQUIRED -- content type of script language --
language CDATA #IMPLIED -- predefined script language name --
src %URI; #IMPLIED -- URI for an external script --
defer (defer) #IMPLIED -- UA may defer execution of script --
event CDATA #IMPLIED -- reserved for possible future use --
for %URI; #IMPLIED -- reserved for possible future use --
>
In XHTML, this attribute is required and unnecessary.
Das ist doppelter Unsinn. Zum einen schließen "required" und "unnecessary" einander aus.
Kann man so sehen. Er meint wohl, es ist unnötigerweise "required".
Zum anderen scheint sich Crockford der Unterschiede zwischen HTML 4.01 und XHTML 1.0 nicht im Klaren zu sein.
Warum das denn?
Gruß, Don P
@@Don P:
Zum anderen scheint sich Crockford der Unterschiede zwischen HTML 4.01 und XHTML 1.0 nicht im Klaren zu sein.
Warum das denn?
Weil sich HTML 4.01 und XHTML 1.0 in der durch SGML bzw. XML bedingten Syntax unterscheiden; nicht aber in verfügbaren Elementen oder deren Attributen.*
Live long and prosper,
Gunnar
* Dass da nur jeweils die entsprechenden Varianten verglichen werden, sollte klar sein.
Hi,
Weil sich HTML 4.01 und XHTML 1.0 in der durch SGML bzw. XML bedingten Syntax unterscheiden; nicht aber in verfügbaren Elementen oder deren Attributen.*
Also ich kann aus dem Zitierten diesbezügl. "Probleme", die Du Crockford unterstellt hast, nicht nachvollziehen. =:-)
"In XHTML, this attribute is required and unnecessary. In HTML, it is better to leave it out." lese ich so:
In XHTML ist dieses Attribut vorgeschrieben und unnötig. Vorgeschrieben, weil man bei XHTML sich tunlichst an die DTD halten sollte, unnötig, weil es trotzdem nur einen rein theoretischen Wert hat. HTML hingegen ist bewußt "fehlertolerant" an- & ausgelegt worden. Das Hecheln nach einem 100%igen Einhalten eines "Standards" ist bei HTML also per se nicht notwendig. Und wenn es auch sonst keine Gründe gibt ...
Ich interpretiere es so, weil ich selbst so denke. Und die von den Webentwicklern/Browserprogrammierern dem W3C aufgezwungene Abkehr vom X-Standard-Fetisch hin zum Oldstyle-HTML (mit dem das Web so groß und erfolgreich wurde - mit XHTML 1, geschweige denn XHTML 2, wäre das wohl nicht so gelaufen) in Form von HTML 5, hat wohl gezeigt, daß sich Crockford & Co. letztlich gegen die Theoretiker im Genfer Elfenbeinturm durchgesetzt haben.
Gruß, Cy-"auf die offizielle Ankündigung von HTML 5 habe ich nicht nur eine Flasche Schampus geköpft %-)"-baer
@@Cybaer:
Weil sich HTML 4.01 und XHTML 1.0 in der durch SGML bzw. XML bedingten Syntax unterscheiden; nicht aber in verfügbaren Elementen oder deren Attributen.*
Also ich kann aus dem Zitierten diesbezügl. "Probleme", die Du Crockford unterstellt hast, nicht nachvollziehen. =:-)
“This attribute is optional [in HTML]. […] In XHTML, this attribute is required and unnecessary.”
Crockford sieht Unterschiede in HTML und XHTML, wo keine sind.
In XHTML ist dieses Attribut vorgeschrieben und unnötig. Vorgeschrieben, weil man bei XHTML sich tunlichst an die DTD halten sollte, unnötig, weil es trotzdem nur einen rein theoretischen Wert hat. HTML hingegen ist bewußt "fehlertolerant" an- & ausgelegt worden. Das Hecheln nach einem 100%igen Einhalten eines "Standards" ist bei HTML also per se nicht notwendig.
Oh, Crockford ist damit nicht alleine. Du siehst auch Unterschiede in HTML und XHTML, wo keine sind.
Wenn es denn in HTML (deiner Meinung nach) nicht notwendig sein sollte, warum dann in XHTML (HTML-kompibel nach [XHTML10 §C] als 'text/html')?
[…] hin zum Oldstyle-HTML (mit dem das Web so groß und erfolgreich wurde - mit XHTML 1, geschweige denn XHTML 2, wäre das wohl nicht so gelaufen)
Das war einmal. Die Zeiten, in denen das Web groß und erfolgreich wird, weil Autoren ihre Seiten in HTML schreiben, sind vorbei. Heute wird das Web groß und erfolgreich durch CMSe u.dgl.
Und es gibt keinen Grund, dass ein CMS nicht „semantisches“ Markup in validem XHTML 1.0 Strict erzeugen könnte. Außer der Unfähigkeit/Unwilligkeit der CMS-Entwickler.
in Form von HTML 5, hat wohl gezeigt, daß sich Crockford & Co. letztlich gegen die Theoretiker im Genfer Elfenbeinturm durchgesetzt haben.
Bedauerlich. Das wirft die Weiterentwicklung des Webs um Jahre zurück.
Je strenger die Auszeichnungssprache ist, desto einfacher hat es ein UA (Anwendungsprogramm), d.h. desto kleiner ist dessen Programmcode. Je mehr die Auszeichnungssprache zulässt, desto aufgeblähter ein UA, um das alles zu verstehen. Blöd für mobile Endgeräte.
XML (XHTML 1, 2) wäre IMHO der bessere Weg. Nicht den Autoren (CMS-Entwicklern) alle Freiräume lassen, sondern die UAs entlasten.
Gruß, Cy-"auf die offizielle Ankündigung von HTML 5 habe ich nicht nur eine Flasche Schampus geköpft %-)"-baer
Schampus? Ich brauch da härteres Zeug, um den Ärger über HTML 5 runterzuspülen.
Live long and prosper,
Gunnar
Hi,
Wenn es denn in HTML (deiner Meinung nach) nicht notwendig sein sollte, warum dann in XHTML (HTML-kompibel nach [XHTML10 §C] als 'text/html')?
Wenn man "X"HTML als text/html ausliefert, ist es kein XHTML, sondern (defektes) HTML. Ich dachte, das wäre (zumal hier) allgemein bekannt, sowie daß man im Web nach dem Mime-Type entscheidet, nicht nach dem, was in den Daten selbst steht ... =:-o
Das war einmal. Die Zeiten, in denen das Web groß und erfolgreich wird, weil Autoren ihre Seiten in HTML schreiben, sind vorbei. Heute wird das Web groß und erfolgreich durch CMSe u.dgl.
So so ... :-o
Also ich persönlich habe mit einem CMS angefangen, und programmiere heute noch CMS. Schön, daß du die Bedeutung von CMS' würdigst. Aber der Erfolg des Webs spiegelt sich IMHO keineswegs in den Anwendern wieder, die ein CMS einsetzen. Es sind vielmehr die viiiieeeelen kleinen Sites und Seiten (inkl. der Klicki-Bunti-Seiten auf MySpace, Beep-World, ...), deren aufstrebende Code-Anfänger in Foren wie diesen nachfragen und auf Hilfe im Code-Dschungel hoffen ...
... und das sage ich bewußt als jemand, der mit HTML & Co. schon länger seinen Lebensunterhalt verdient (also von den Leuten bezahlt werde, die selber bei weitem nicht so extrem coden wollen und/oder können), als dieses Forum existiert.
Und es gibt keinen Grund, dass ein CMS nicht „semantisches“ Markup in validem XHTML 1.0 Strict erzeugen könnte. Außer der Unfähigkeit/Unwilligkeit der CMS-Entwickler.
Richtig. Natürlich könnte ich Webseiten XHTML 1.0 Strict schreiben. Ich sage ja immer: Jeder trainierte Affe kann das - solange zufällig Tasten drücken, solange die Validator-Lampe grün leuchtet ... >:->
Aber wir wollen hier ja wohl kaum mal wieder eine Diskussion starten, über das "richtige" Markup.
Das gibt's, als Wertigkeit an sich, ja eh nicht (IMHO). Und der Threads und Zeitschriften-Artikel sind gar zahlreich ...
in Form von HTML 5, hat wohl gezeigt, daß sich Crockford & Co. letztlich gegen die Theoretiker im Genfer Elfenbeinturm durchgesetzt haben.
Bedauerlich. Das wirft die Weiterentwicklung des Webs um Jahre zurück.
Natürlich um Jahre. Ist ja auch jahrelang nichts wirklich praktisch relevantes entwickelt/umgesetzt worden. >:-/ Kein Wunder, daß da irgendwann die Reißleine gezogen wurde ...
... dafür kann man aber auch endlich davon ausgehen, daß es wieder weitergeht. :)
Je strenger die Auszeichnungssprache ist, desto einfacher hat es ein UA (Anwendungsprogramm), d.h. desto kleiner ist dessen Programmcode. Je mehr die Auszeichnungssprache zulässt, desto aufgeblähter ein UA, um das alles zu verstehen. Blöd für mobile Endgeräte.
Ja, zu blöd, daß der Mensch sich einfach nicht nach der Technik richtet, sondern partout erwartet, daß die Technik sich gefälligst nach dem Menschen zu richten hat. :->
XML (XHTML 1, 2) wäre IMHO der bessere Weg. Nicht den Autoren (CMS-Entwicklern) alle Freiräume lassen, sondern die UAs entlasten.
Ich stimme dir absolut zu. Und: Ich *liebe* SGML (da kam der Mathematiker in mir durch :-))). Von mir aus hätte ich schon damals am liebsten "stricter" gecodet. Damit verglichen habe ich HTML immer als ein grausames Dahingewurschtel empfunden.
Aber, hey, die Welt besteht nicht nur aus Mathe- & Informatikern, die in Formen, Algorithmen & Gesetze verliebt, und mit Hilbert per Du sind.
Und genau deswegen bleibe ich dabei: Die Nicht-Strenge von HTML war ein Segen, ist ein Segen, und wird, bei allen Ärgernissen, auch weiterhin ein Segen bleiben ... :-)
Die Strenge und Komplexität von XHTML (insbesondere 2) halte ich für fatal. Und übrigens: Ich teile auch explizit Crockfords diesbezügl. Meinung zu CSS (insbesondere 3). Ihm wäre es am Liebsten, CSS wegzuschmeißen, und komplett neu anzufangen ...
Gruß, Cy-"auf die offizielle Ankündigung von HTML 5 habe ich nicht nur eine Flasche Schampus geköpft %-)"-baer
Schampus? Ich brauch da härteres Zeug, um den Ärger über HTML 5 runterzuspülen.
Tja, ich glaube, nicht nur diese Schlacht, der ganze Krieg ist jetzt vorbei ... :-)
Gruß, Cybaer
@@Cybaer:
Ich dachte, das wäre (zumal hier) allgemein bekannt, sowie daß man im Web nach dem Mime-Type entscheidet, nicht nach dem, was in den Daten selbst steht ... =:-o
Das war jetzt dein Plädoyer, beim 'script'-Element niemals das 'type'-Attribut zu vergessen? ;-)
Je strenger die Auszeichnungssprache ist, desto einfacher hat es ein UA (Anwendungsprogramm), d.h. desto kleiner ist dessen Programmcode. Je mehr die Auszeichnungssprache zulässt, desto aufgeblähter ein UA, um das alles zu verstehen. Blöd für mobile Endgeräte.
Ja, zu blöd, daß der Mensch sich einfach nicht nach der Technik richtet, sondern partout erwartet, daß die Technik sich gefälligst nach dem Menschen zu richten hat. :->
Naja, es geht ja nicht um _den_ Menschen (der mal eben was im Web publizieren will), sondern um die paar, damit ihre Brötchen verdienen, ebendies _den_ anderen zu ermöglichen, ohne HTML lernen zu müssen.
Und ja, die paar sollten die Technik so gestalten, dass was Vernünftiges[tm] (Effizientes) dabei herauskommt.
Und genau deswegen bleibe ich dabei: Die Nicht-Strenge von HTML war ein Segen,
ACK.
ist ein Segen, und wird, bei allen Ärgernissen, auch weiterhin ein Segen bleiben ... :-)
Von mir aus sollen diejenigen, die Tagsoup schreiben wollen, weiterhin HTML 4 verwenden. Von mir aus auch 3.2. Aber für _die_ muss man doch HTML nicht weiterentwickeln.
Für die anderen wird der Segen eher zum Fluch.
Und übrigens: Ich teile auch explizit Crockfords diesbezügl. Meinung zu CSS (insbesondere 3).
Die da wäre? Ich bin nicht im Bilde.
Ihm wäre es am Liebsten, CSS wegzuschmeißen, und komplett neu anzufangen ...
Unterschiedliche Syntax für ähnliches Zeugs ist wahrhaftig unschön. Von mir aus sollen CSS4-Selektoren dieselbe Syntax wie XPath verwenden.
Tja, ich glaube, nicht nur diese Schlacht, der ganze Krieg ist jetzt vorbei ... :-)
Live long and prosper,
Gunnar
Hi,
Ich dachte, das wäre (zumal hier) allgemein bekannt, sowie daß man im Web nach dem Mime-Type entscheidet, nicht nach dem, was in den Daten selbst steht ... =:-o
Das war jetzt dein Plädoyer, beim 'script'-Element niemals das 'type'-Attribut zu vergessen? ;-)
Nein, *das* war mein Plädoyer, darauf zu achten, daß der Server statt "text/javascript" den Mime-Type "application/javascript" verwendet. ;-)
Ja, zu blöd, daß der Mensch sich einfach nicht nach der Technik richtet, sondern partout erwartet, daß die Technik sich gefälligst nach dem Menschen zu richten hat. :->
Naja, es geht ja nicht um _den_ Menschen (der mal eben was im Web publizieren will), sondern um die paar, damit ihre Brötchen verdienen, ebendies _den_ anderen zu ermöglichen, ohne HTML lernen zu müssen.
Tja, das sehe ich halt *ganz* anders! Wer dafür bezahlt wird, der muß Lernen und hat sich entsprechend Mühe zu geben. Und ob das Ergebnis dann in HTML 4, 5, XHTML x, Flash, JavaScript, VB-Script, oder sonstwas ist, ist grad egal - solang der Kunde ein gutes Ergebnis bekommt.
HTML hat sich von Herkunft und Zielsetzung explizit an den nicht-berufstätigen Coder gewandt. Und es ist IMHO gut, daß man auch heute noch als normalsterblicher Freizeitcoder (einigermaßen) damit klarkommen kann.
Coding for the masses - sozusagen.
ist ein Segen, und wird, bei allen Ärgernissen, auch weiterhin ein Segen bleiben ... :-)
Von mir aus sollen diejenigen, die Tagsoup schreiben wollen, weiterhin HTML 4 verwenden. Von mir aus auch 3.2. Aber für _die_ muss man doch HTML nicht weiterentwickeln.
Du unterscheidest halt nach HTML-Versionen. Wie gesagt: Das habe ich nie gemacht. Selbst ohne Tagsoup ...
Für die anderen wird der Segen eher zum Fluch.
Ich denke, das Web ist groß genug für alle ... ;-)
Und übrigens: Ich teile auch explizit Crockfords diesbezügl. Meinung zu CSS (insbesondere 3).
Die da wäre?
CSS wegschmeißen, und komplett neu anzufangen ... ;-)
Tja, ich glaube, nicht nur diese Schlacht, der ganze Krieg ist jetzt vorbei ... :-)
XHTML 2 lebt.
XHTML 2 wird *absolut* seine Berechtigung haben. Als Nischenanwendung für die, die es brauchen - sofern es irgendwann mal fertig wird und es auch Clients dafür gibt. Als Format für die Masse (und damit das Web allgemein), hat es sich wohl endgültig erledigt ... (bewußt kein lachender Smiley)
Gruß, Cybaer
Hallo,
Naja, es geht ja nicht um _den_ Menschen (der mal eben was im Web publizieren will), sondern um die paar, damit ihre Brötchen verdienen, ebendies _den_ anderen zu ermöglichen, ohne HTML lernen zu müssen.
HTML hat sich von Herkunft und Zielsetzung explizit an den nicht-berufstätigen Coder gewandt. Und es ist IMHO gut, daß man auch heute noch als normalsterblicher Freizeitcoder (einigermaßen) damit klarkommen kann.
»HTML wird von Laien geschrieben, deshalb ist Fehlertoleranz die Zukunft« - so einfach würde ich das nicht formulieren und die oppositionelle Gegenüberstellung zur XML geht auch nicht auf. Dazu zwei Gedanken:
Nachdem man nicht mehr so einfach mit font und Tabellenlayout herumschmieren kann, schreibt man möglichst effizienten CSS-Code. Das heißt: Wenig CSS-Regeln, Vererbung/Kaskade nutzen, passende Selektoren und soviele »Anker« im HTML, wie gerade nötig. Dazu braucht man, will man sich nicht soviel Arbeit machen wie in font-Zeiten, notwendigerweise »einigermaßen aufgeräumtes« HTML, das einen absehbaren DOM-Baum erzeugt. Also auch nicht willkürlich Fehler enthalten kann, weil nicht alle Browser die gleiche Fehlertoleranz mitbringen.
Wenn man nur ein wenig mit JavaScript/DOM operiert, gilt das noch vielmehr. Wenn DOM-Abfragen ins Leere laufen oder Objekteigenschaften/-Methoden nicht das gewünschte zurückliefern, ist das Script nicht funktionsfähig und kann höchstens geordnet abbrechen.
Deshalb ist es immer sinnvoll, brauchbares Markup zu schreiben - das ist auch für Anfänger und Freizeitcoder die Grundvoraussetzung. Als wäre das eine bloße Methodik für Profis - nein, insbesondere für Amateure ist eine einfache und klare Vorgehensweise hilfreich, um Problemen auf die Spur zu kommen. Will ich zu einer funktionierenden Site kommen, kann ich mir viele grobe Fehler einfach nicht leisten. Wie tolerant das Parsing ist, ist in dieser Hinsicht weniger wichtig, eher dass es *ein* definiertes Parsing gibt - was derzeit noch nicht der Fall ist, insofern kann man nur ungefähr wissen, welche Abweichungen praktisch harmlos sind - es sind nicht viele.
Doch die von Gunnar angesprochene Dimension ist nicht auszublenden, sondern die andere Seite der Medaille. Auch wenn es hier SELFHTML heißt, muss man einsehen, dass »der« Mensch nicht HTML kennen muss und HTML deshalb nicht diese klare Ausrichtung hat. Einerseits werden die Tools besser, HTML zu produzieren - ohnehin bestand schon immer die Möglichkeit, dass Tools tiptop-validen Code ausspucken, weil Validität erst einmal wenig bedeutet. Andererseits wird HTML, für den Anwender verborgen, durch unzählige Desktop- und Web-Anwendungen erzeugt, die das Veröffentlichen von Inhalten ohne technische Kenntnisse ermöglichen. Das ist heute sogar viel wichtiger als das Modell »Homepage« mit HTML.
Der HTML5-Impuls - insbesondere die Standardisierung des Parsing des existierenden Web-Contents, der eben nicht XML ist -, ist vor diesem Hintergrund keineswegs bloß ein »demokratischer« (»Coding for the masses«). Sondern vor allem aus Sicht derjenigen gedacht, die den entstehenden HTML-Code verarbeiten müssen. Die HTML5-Autoren sind keine Hypertext-Visionäre, sondern Angestellte von Browserherstellern und Techniker, die das Web als Plattform ernst nehmen und interoperable Rich Internet Applications bauen wollen. Dazu brauchen sie präzise technische Standards. Die HTML5-Spezifikation ist tausendmal schwerer lesbar als HTML4, weil es unzählige kleinliche Definitionen enthält, die für die normalen Anwender uninteressant sind, aber für die User-Agent-Programmierer essentiell. Was für die HTML-Amateure dabei wirklich auf der Nutzenseite übrig bleibt, muss man m.M.n. erst einmal sehen, das liegt für mich nicht so offen.
Mathias
Hi,
»HTML wird von Laien geschrieben, deshalb ist Fehlertoleranz die Zukunft« - so einfach würde ich das nicht formulieren
Ist ja auch nur ein Teil. Fehlertoleranz ist IMHO ja nicht an sich erstrebenswert (und bei HTML ursprünglich auch auch nicht "geplant"). Sie existiert halt, hat sich so ergeben, und ist quasi empirisch begründet. >;->
Es ist aber auch die vergleichsweise Simplizität, der überschaubare Umfang, der den Laien auch zukünftig eher HTML verwenden lassen wird (sofern nicht "WYSIWYG"-Editoren zum Einsatz kommen).
BTW: Ich bin mir übrigens nicht so sicher, daß zukünftige Authoring-Tools dramatisch besser sein werden, als der verbreitete heutige Scheiß (auch wenn der mittlerweile besser geworden ist). Klar, viele "Probleme" wo diese Tools früher mit Tabellen arbeite "mußten", werden schon heute über CSS angegangen. Die Frage ist IMHO aber auch: Wenn es selbst heute immer noch, nach so vielen Web-Jahren und noch überschaubaren offiziellen Standards und proprietären Regeln, keine wirklich guten Tools gibt, werden die Programmierer in den nächsten Jahren mit viel umfangreicheren, wenn auch modularisierten Standards deutlich bessere Tools schreiben?
Deshalb ist es immer sinnvoll, brauchbares Markup zu schreiben - das ist auch für Anfänger und Freizeitcoder die Grundvoraussetzung.
:) Jaaaa, sinnvoll ist es *natürlich*! =:-) Nur *offensichtlich* nicht ganz *realistisch*! ;)
Andererseits wird HTML, für den Anwender verborgen, durch unzählige Desktop- und Web-Anwendungen erzeugt, die das Veröffentlichen von Inhalten ohne technische Kenntnisse ermöglichen. Das ist heute sogar viel wichtiger als das Modell »Homepage« mit HTML.
ACK! Ein sehr wichtiges Beispiel sind IMHO hierfür die Blogs! Und auch "Homepage-Editoren" bei den Communities fallen darunter. Aber das ist für mich "nur" ein Zeichen, daß das Web insgesamt halt an Leistungskraft und Anwendungsmöglichkeiten gewinnt, sprich: schlicht älter und größer wird. Ich denke nicht, daß hier eine "Sparte" zugunsten einer anderen "aufgegeben" oder verkleinert wird. Ich denke vielmehr, daß damit neue Zielgruppen entstanden sind bzw. auch noch entstehen werden, die *hinzukommen*. Die "Klassiker" über die wir hier reden, wird es IMHO auch in Zukunft, und auch vermehrt in Zukunft geben - halt als ein wachsendes Teilchen, in einem insgesamt wachsenden Puzzle ...
Der HTML5-Impuls - insbesondere die Standardisierung des Parsing des existierenden Web-Contents, der eben nicht XML ist -, ist vor diesem Hintergrund keineswegs bloß ein »demokratischer« (»Coding for the masses«). Sondern vor allem aus Sicht derjenigen gedacht, die den entstehenden HTML-Code verarbeiten müssen.
Eine IMHO sehr "egoistische" Sichtweise. Ich teile diese Einschätzung nicht! Sicher gibt es nicht nur einen "demokratischer Hintergrund", aber IMHO zu einem Großteil eben auch! Natürlich:
Die HTML5-Autoren sind keine Hypertext-Visionäre, sondern Angestellte von Browserherstellern und Techniker, die das Web als Plattform ernst nehmen und interoperable Rich Internet Applications bauen wollen.
Aber es waren auch exakt *diese* Leute, die mit *ihren* Entwicklungen das Web so gepusht haben (erst Netscape, dann MS, auch Opera, und jetzt auch Apple, hervorgegangen aus KHTML). Ich denke, daß man sie (mindestens zum Teil) durchaus auch als Hypertext-Visionäre bezeichnen darf, wie man Berners-Lee & Co. IMHO durchaus auch als Praktiker sehen sollte.
Und die Stimmen aus diesen Kreisen, die hier Rücksicht auf die Realitäten der Gegenwart einfordern, sind IMHO absolut glaubhaft.
Dazu brauchen sie präzise technische Standards.
Können sie mit XML/XHTML 2 haben.
Die HTML5-Spezifikation ist tausendmal schwerer lesbar als HTML4, weil es unzählige kleinliche Definitionen enthält, die für die normalen Anwender uninteressant sind, aber für die User-Agent-Programmierer essentiell.
Jo: Fortschreitende Entwicklung ergibt meistens eine steigende Komplexität. So ist das halt. Die Frage ist aber: Wie ist die Komplexität von HTML 5 verglichen mit XHTML 2?!
Was für die HTML-Amateure dabei wirklich auf der Nutzenseite übrig bleibt, muss man m.M.n. erst einmal sehen, das liegt für mich nicht so offen.
Ein "weiter so, wie bisher", erweitert um einige neue Features. So, wie es halt bisher auch war, daß peu a peu neue Features hinzukamen, zu einem ansonsten bekannt gebliebenem System, mit immer noch guter Lernkurve für Laien ...
Gruß, Cybaer
Aber, hey, die Welt besteht nicht nur aus Mathe- & Informatikern, die in Formen, Algorithmen & Gesetze verliebt, und mit Hilbert per Du sind.
man muss ja nicht gleich in david hilbert verliebt sein oder in seinem hotel wohnen - dilbert ist doch viel cooler :p
Hi,
man muss ja nicht gleich in david hilbert verliebt sein oder in seinem hotel wohnen - dilbert ist doch viel cooler :p
:) Lustiger vielleicht, aber cooler? ;->
Gruß, Cybaer
Hallo,
Je strenger die Auszeichnungssprache ist, desto einfacher hat es ein UA (Anwendungsprogramm), d.h. desto kleiner ist dessen Programmcode. Je mehr die Auszeichnungssprache zulässt, desto aufgeblähter ein UA, um das alles zu verstehen. Blöd für mobile Endgeräte.
Das ist doch verkürzt. Der Sinn von HTML 5 ist nicht, alles zuzulassen, sondern eben auf Basis eines vergleichsweise minimalen Parsers Müllcode zu verwerfen und ansonsten aus Code aufgrund »strenger« definierter Regeln in brauchbare Token zu parsen. Ob dieser Algorithmus wirklich komplexer als ein XML-Parser umzusetzen ist, weiß ich gar nicht, halte ich erstmal für eine These, denn bei XML kommen z.B. noch viele weitere Features hinzu, die ein billiger HTML5-Parser alle nicht kennen muss.
Da gibts schon einige Ansätze:
http://code.google.com/p/html5lib/
http://about.validator.nu/htmlparser/
Jetzt einfach zu sagen: Die sind im Vergleich zu XML per se bloated und können nicht performant auf kleinen Geräten umgesetzt werden, halte ich für unbelegt. Mal eben eine hinreichend konforme XML-Implementation für ein Winzigrechner hinzulegen ist vermutlich auch nicht so einfach. (Aber ich bin kein Informatiker, sodass ich das nicht »aus der Ferne« theoretisch beurteilen könnte.)
XML (XHTML 1, 2) wäre IMHO der bessere Weg. Nicht den Autoren (CMS-Entwicklern) alle Freiräume lassen, sondern die UAs entlasten.
Als ob HTML 5 *nicht* die UAs entlasten soll!? Was meinst du, wieviel Parsing-Code z.B. der IE herauswerfen wird, wenn er auf HTML5-Parsing umsteigt. Mindestens 90%! ;)
Mathias
Hi,
Mal eben eine hinreichend konforme XML-Implementation für ein Winzigrechner hinzulegen ist vermutlich auch nicht so einfach.
Auch wenn ich ebenfalls kein Informatiker bin: Mein erfahrungsgeschwängertes Bauchgefühl (;)) sagt mir, daß ein halbwegs brauchbarer*) XML-Client resourcenfressender ist, als ein üblicher "Tag-Soup"-(X)HTML-Client.
Aber wer glaubhaft anderer Meinung ist, von dem lasse ich mich gerne belehren. :)
*) Wobei natürlich immer die Frage existiert: Wenn schon XML, dann will/soll der Kunde auch etwas von haben (SVG, MathML, ...). Fragt sich halt: Was?!
Gruß, Cybaer
Hallo,
Mein erfahrungsgeschwängertes Bauchgefühl (;)) sagt mir, daß ein halbwegs brauchbarer*) XML-Client resourcenfressender ist, als ein üblicher "Tag-Soup"-(X)HTML-Client.
Ein Parser parst, sodass am Ende ein DOM herauskommt. (Nicht bei allem Parsern, aber bei denen, über die wir hier reden.) Das ist erstmal alles.
Ressourcenschonende XML-Parser z.B. für das Embedded-Umfeld gibts offenbar einige, schließlich ist XML ziemlich verbreitet.
Mathias
[latex]Mae govannen![/latex]
Gruß, Cy-"auf die offizielle Ankündigung von HTML 5 habe ich nicht nur eine Flasche Schampus geköpft %-)"-baer
Ich möchte gerne an dem Tag, an dem ich HTML5 benutze, ohne dazu mit Waffengewalt gezwungen worden zu sein, unmittelbar und ohne Vorwarnung erschossen werden. Danke.
Cü,
Kai
Hi,
Ich möchte gerne an dem Tag, an dem ich HTML5 benutze, ohne dazu mit Waffengewalt gezwungen worden zu sein, unmittelbar und ohne Vorwarnung erschossen werden. Danke.
:) Ich sehe, Du kannst nunmehr nachempfinden, wie ich mich in all den HTML-4/XHTML-Jahren gefühlt habe ... %-)
Gruß, Cybaer
Hallo,
"In XHTML, this attribute is required and unnecessary. In HTML, it is better to leave it out."
Das ist einfach Unsinn.
In XHTML ist dieses Attribut vorgeschrieben und unnötig.
Ja. Nicht anders als in HTML 4!
Vorgeschrieben, weil man bei XHTML sich tunlichst an die DTD halten sollte
Man muss sich in XHTML überhaupt nicht an die DTD halten - bzw. sollte es aus denselben Gründen tun, wie man es beim Schreiben von HTML-Dokumenten tun sollte. Wenn man es nicht selbst tut, wird ein XHTML-Dokument nirgendwo im normalen Web-Betrieb standardmäßig DTD-validierend geparst.
unnötig, weil es trotzdem nur einen rein theoretischen Wert hat.
Ja, aus dem Grund ist es sowohl in HTML und XHTML praktisch unnötig. Hier zwischen HTML und XHTML zu unterscheiden ist genauso unnötg. ;)
HTML hingegen ist bewußt "fehlertolerant" an- & ausgelegt worden.
HTML definiert das type-Attribut genauso für REQUIRED wie XHTML es tut, in dem Punkt gibts überhaupt kein Unterschied in der »Fehlertoleranz«.
Das Hecheln nach einem 100%igen Einhalten eines "Standards" ist bei HTML also per se nicht notwendig.
Ich kann nicht-valides XHTML genauso schreiben wie nicht-valides XHTML. Das 100%ige Einhalten eines Standards ist bei HTML genauso »notwendig« wie bei XHTML: im Zweifelsfall gar nicht! Ich kann tausende eigene Elemente und Attribute hinzufügen und dutzende vorgeschriebene weglassen, der Browser wird das draus machen, was er kann.
Der einzige Unterschied ist, dass bei XHTML das Vorgehen von XML-Parsern im Fehlerfall definiert ist, insbesondere im Falle eines groben Syntaxfehlers (Wohlgeformtheitsfehler). Dann soll der Parser abbrechen. Das betrifft aber nur XML-Parser, die bei abwärtskompatiblem XHTML 1.0 nicht browserseitig eingesetzt werden.
Wohlgeformtheit ist bei der Verarbeitung als XML, dann und nur dann, ein strenges Erfordernis, ja - aber was hat das mit DTD-Validität zu tun? Gar nichts. Ich kann ein Dokument als (X)HTML an Browser senden, das nicht ein (X)HTML-Element enthält - wen juckt das denn? Nichts und niemand zwingt mich zu etwas anderem. Solange es wohlgeformt ist, kann es selbst ein XML-Parser lesen.
Ich interpretiere es so, weil ich selbst so denke.
Ja, klarer Zirkelschluss.
Mit solchen Spekulationen, Befindlichkeiten, »Interpretationen« und eingestreutem technischen Halbwissen vernebelst und mythologisierst du die Sache bloß, anstatt sie aufzuklären.
Mathias
Hi,
Ich interpretiere es so, weil ich selbst so denke.
Ja, klarer Zirkelschluss.
Mit solchen Spekulationen, Befindlichkeiten, »Interpretationen« und eingestreutem technischen Halbwissen vernebelst und mythologisierst du die Sache bloß, anstatt sie aufzuklären.
Klar, darüber kann man reden. :) Aber die Position des Advocatus Diaboli ist mir durchaus bekannt ... =;-)
Und natürlich kann man HTML & XHTML gleich "schlecht" coden. Nur: anders als das von Anfang an "lasch" angelegte HTML, hat man die Philosophie von XHTML (XML) ja *explizit* von Anfang so "strict" gewollt! Schon das die Anforderung auf dem "niedrigeren" Level der Wohlgeformtheit gelandet ist, ist ja ein arg umstrittener Kompromiß gewesen, den viele Hardcore-XMLer nach wie vor ablehnen.
Wer entscheidet übrigens, wieviel Abweichung von der reinen Lehre "tolerabel" ist? Eigentlich darf, wenn schon eine andere Philosophie, diese dann auch nicht verwässert werden.
Nun mag man sich aber über Gründungsphilosophien ja auch einfach hinwegsetzen. Nur was hilft's, wenn es halt keinen/kaum einen HTML-like fehlertoleranten und praktikablen XHTML/XML-Client gibt? Und was die Fehlertoleranz angeht: Es soll ihn IMHO auch nicht geben. Nur wird das dann halt zu nach wie vor 2 parallel gebräuchlichen MLs führen. Mitunter auch "lasches" HTML für die Masse, und systembedingt "feines" XHTML für Spezialfälle.
Gruß, Cybaer
Hallo,
Und natürlich kann man HTML & XHTML gleich "schlecht" coden. Nur: anders als das von Anfang an "lasch" angelegte HTML, hat man die Philosophie von XHTML (XML) ja *explizit* von Anfang so "strict" gewollt!
Das ist erstmal eine allgemeine und zusammenfassende Aussage über den Willen eines »man«. Wenn man sich konkret ansieht, was dieses »Strikte« einerseits und das »Lasche« andererseits bedeutet, so wird man sehen, dass es recht begrenzt ist - vor allem in der Theorie der Spezifikationen.
Schon das die Anforderung auf dem "niedrigeren" Level der Wohlgeformtheit gelandet ist, ist ja ein arg umstrittener Kompromiß gewesen, den viele Hardcore-XMLer nach wie vor ablehnen.
Quelle?
Es ist einfach unnötig, ein XML-Dokument validierend zu parsen.
Genauer gesagt, das W3C hat schon lange von DTD-Validierung Abschied genommen. Daher glaube ich das eher nicht.
Nun mag man sich aber über Gründungsphilosophien ja auch einfach hinwegsetzen.
Du unterstellst HTML eine »Gründungsphilosophie«, die ich als nachträglich hineininterpretiert sehen würde. Nirgendwo wurde HTML als ausdrückllich fehlertolerant spezifiziert - das ist lediglich historisch so gewachsen, weil fehlertolerante UAs die Herrschaft übernahmen. HTML hatte es einfach vermieden und auch verpasst, Parsing und Umgang mit Fehlern (wie auch immer) zu definieren. Vor diesem Hintergrund entstand XML und in letzter Konsequenz auch HTML 5.
Nur was hilft's, wenn es halt keinen/kaum einen HTML-like fehlertoleranten und praktikablen XHTML/XML-Client gibt?
XML ist nicht HTML, ja. Wohlgeformtheit ist das Minimum für XML-Verarbeitung. Und? Das ist der Sinn von XML.
Mathias
Hi,
Schon das die Anforderung auf dem "niedrigeren" Level der Wohlgeformtheit gelandet ist, ist ja ein arg umstrittener Kompromiß gewesen, den viele Hardcore-XMLer nach wie vor ablehnen.
Quelle?
Oh je, ich such bestimmt nicht danach! =;-)
War mir nur seinerzeit aufgefallen, daß es da einige lautstarke Diskussionen im Web geführt wurden.
Verstehen konnte ich die Hardcore-Haltung nicht so ganz, denn ...
Es ist einfach unnötig, ein XML-Dokument validierend zu parsen.
... das sehe ich ja eh genau so.
Du unterstellst HTML eine »Gründungsphilosophie«, die ich als nachträglich hineininterpretiert sehen würde.
IMHO nein.
Nirgendwo wurde HTML als ausdrückllich fehlertolerant spezifiziert
*Das* habe ich auch nicht gemeint. Mit der "lockeren Philosophie" war gemeint, daß man bei HTML (im Gegensatz zum eingeführten SGML, aus dem es entstanden ist) bewußt die formalen Hürden niedrig gestaltet hat.
Denn mit SGML sind solche Scherze wie "unbekannte" oder fehlende End- oder Start-Tags überhaupt nicth möglich. Ein Dokument, was nicht *valide* zur angegebenen (Pflicht-)DTD ist, wird nicht verarbeitet. Punkt.
Dagegen ist sogar "nur" wohlgeformtes XML "lasch" - und erklärt wohl auch die diesbezügl. Streitigkeiten.
Gruß, Cybaer
Hi,
In der Tat, das einzige Attribut, das benötigt wird, ist "type", Auszug aus der HTML 4.0 DTD:
Ja, wenn man eine konkrete DTD angibt, dann sollte man sich auch an sie halten (persönliche Meinung). Aber dazu wird man ja nicht gezwungen. Und: gut, daß diese "kurzzeitige" Verirrung mit HTML 5 und dem damit eingeführten allg., versionslosen Doctype endlich auch offiziell wieder ein Ende hat ... =:-)))))
Gruß, Cybaer
@@Cybaer:
Ach, stör dich nicht dran. Gunnar predigt hier seine persönlichen Auffassungen so gnadenlos,
Ach, und die Fehlermeldung
required attribute "type" not specified. […] The attribute given above is required for an element that you've used, but you have omitted it. For instance, in most HTML and XHTML document types the "type" attribute is required on the "script" element and the "alt" attribute is required for the "img" element.
des Validators ist meine persönliche Auffassung? Tut mir leid, so groß ist mein Einfluss auf die Welt nun wirklich nicht.
Da ich dir nicht abkaufe, dass du nicht weißt, was hier richtig und was falsch ist, die Frage: Warum betätigst du dich hier als Dummschwätzer?
Live long and prosper,
Gunnar
Hi,
Ach, stör dich nicht dran. Gunnar predigt hier seine persönlichen Auffassungen so gnadenlos,
Ach, und die Fehlermeldung
Ach, das bezog sich auch mehr auf deinen "Auskommentierungs-Fimmel". :)
Da ich dir nicht abkaufe, dass du nicht weißt, was hier richtig und was falsch ist, die Frage: Warum betätigst du dich hier als Dummschwätzer?
Weil es 2 Gründe gibt, warum ich in Foren bin: Um Leuten zu helfen, und um Spaß zu haben.
Bei dir habe ich letzteres ... :)
... und da ich unter Freunden als humorvoller Mensch gelte, kann ich mich bei dir auch nicht immer beherrschen. ;)
Gruß, Cybaer
@@Cybaer:
Ach, das bezog sich auch mehr auf deinen "Auskommentierungs-Fimmel". :)
Hm, du meinst meinen _Anti-_Auskommentierungs-Fimmel? _Ich_ bin es nicht, der hier den Fimmel hat, JavaScript- und CSS-Bereiche auszukommentieren.
Weil es 2 Gründe gibt, warum ich in Foren bin: Um Leuten zu helfen, und um Spaß zu haben.
ACK.
Bei dir habe ich letzteres ... :)
Zu helfen ist mir auch nicht mehr ;-)
Live long and prosper,
Gunnar
Hi,
Hm, du meinst meinen _Anti-_Auskommentierungs-Fimmel?
Oder so. :)
_Ich_ bin es nicht, der hier den Fimmel hat, JavaScript- und CSS-Bereiche auszukommentieren.
Die "Abnormen" sind aber immer die, die es anders als die Mehrheit machen. ;->
Die "Perversen" sind dann die "Abnormen", deren Tun und Ratschläge Probleme bereiten können. >;->
Du "Perverser", Du! ;)
Zu helfen ist mir auch nicht mehr ;-)
Dann bestell ich die Ambulanz halt wieder ab! ;-)
Gruß, Cybaer
Google:
Ergebnisse [...] ungefähr 14.200.000 für <script language="javascript">.
Scheisse muss geil schmecken. Millionen Fliegen können nicht irren ...
Hi,
replace() ist eine String-Methode, und kann also, wie üblich, auf jeden String angewendet werden. Das sieht dann z.B. so aus:
var Benzin = document.Formular.wert.value.replace(",",".")*23.7;
Gruß, Cybaer
Hi Beto!
Zunächst ein paar Kleinigkeiten:
<script language=JavaScript>
<table align=center cellpadding=0 cellspacing=0><tr><td>
Funktioniert auch so weit, nur wenn ein Kommawert eingegeben wird, kommt als Ausgabe nur NaN. Dies sollte ja mit dem replace wohl gehen. Die Fraeg ist, nur wie geht das ?
Grüsse,
Richard
