Crashkurs für "Veteranen"

[ol99]

Für einen, der "HTML 4.0" kann - 1999 artig und dankbar von Herrn Münz gelernt - stellt sich heute die Frage nach wirklich notwendigen Updates, Nachschulungen u.v.a. Anpassungen.

Ich programmiere nach wie vor (erfolgreich) das möglichst so einfache wie sichere HTML, allenfalls unter Einbeziehung kleiner, bewährter Anteile von javascript.
Viel neumodischer und Trend-Kram ist in den vergangenen 8 Jahren gekommen und gegangen und funktioniert inzwischen teils-hier-nicht, teils dort-mal ...

FRAGE:
Was muss man inzwischen zwingend von Neuerungen und/oder Änderungen an den verbindlichen Standards wissen, und an der eigenen Quelltextzeile ändern?

ALSO:
Gibt es ein Dokument, das "HTML 4.0"-Getreuen übersichtlich NUR die aktuell wirklich notwendigen Updates zusammenfasst und darstellt?

Danke für den Tipp! Und lets go on sauber.

Guten Gruß,

[ChrisB]

Hi,

FRAGE:
Was muss man inzwischen zwingend von Neuerungen und/oder Änderungen an den verbindlichen Standards wissen, und an der eigenen Quelltextzeile ändern?

Auf XHTML 1.0 Strict umzusteigen, waere ueberlegenswert.

Und mit CSS musst du dich natuerlich auf jeden Fall beschaeftigen, wenn du das bisher noch nicht getan hast. Vor der Jahrtausendwende wurde ja noch viel mit HTML-Attributen zur Beeinflussung der Darstellung gearbeitet - das ist heute absolut nicht mehr zeitgemaesz.

MfG ChrisB

[Klawischnigg]

Hi there,

Auf XHTML 1.0 Strict umzusteigen, waere ueberlegenswert.

Aha. Und, was hätte er davon? Solange Du nicht dazuschreibst, was zum Beispiel die Besucher seiner Seite davon haben, ist Dein Ratschlag einfach unvollständig. Umzusteigen um des Umsteigens willen ist purer Aktionismus...

[fastix®]

Moin!

Für einen, der "HTML 4.0" kann - 1999 artig und dankbar von Herrn Münz gelernt - stellt sich heute die Frage nach wirklich notwendigen Updates, Nachschulungen u.v.a. Anpassungen.

Tja. Bei der Lernbedarfsliste ist das so eine Sache. Als Erwachsener bekommt man da kaum noch Vorschriften. Ich würde CSS auf die Liste setzen. Und xhtml. Und Grundzüge von xml. Und alles was geeignet ist mittels Logik (PHP, Perl, C++, Java, Py, ...) aus Daten beliebiger Herkunft (bel. Datenbank, XML, CSV, ...) Dokumente beliebiger aber menschen- und maschinenlesbarer Form (Text, HTML, XML, LaTex,...) zu erzeugen und/oder zu formatieren (CSS...) oder zu manipulieren (JavaScript,...).

Oder Du kümmerst Dich (teils zwangsläufig mit) um so Niedlichkeiten wie Übertragungsprotokolle http, tcp/ip, ... und die Server, welche Dein wie auch immer erzeugtes HTML ausliefern. (Apache, lightHttp...)

Oder Du gehst in die andere Richtung und schaust wofür das alles gut - oder schlecht sein kann. (Du studierst Jura und machst künftig wie die Günther oder der Günter "in  Serienbriefen": Google kannst Du fragen, bei Bedarf in Quelltexten Meta-Tags lesen und Serienbriefe drucken geht auch schon.)

Vieles davon gab es übrigens schon zu Zeiten des "guten alten" HTML 4.0....

Viel neumodischer und Trend-Kram ist in den vergangenen 8 Jahren gekommen und gegangen und funktioniert inzwischen teils-hier-nicht, teils dort-mal ...

Tja. Auch das gab es früher schon.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[Felix Riesterer]

Lieber ol99,

FRAGE:
Was muss man inzwischen zwingend von Neuerungen und/oder Änderungen an den verbindlichen Standards wissen, und an der eigenen Quelltextzeile ändern?

Dein ganz großes Forschungsziel sollte "semantisches Markup" sein, denn 1999 hat man viele Darstellungsprobleme mit "passendem" HTML-Code gelöst (z.B. Tabellen benutzt, um Inhalte im Dokument zu positionieren und auszurichten). Heute tut man das sinnvollerweise nur mit der Layoutsprache CSS. Dahinter steckt der Ansatz, dass man Inhalt und Darstellung technisch voneinander trennt. Der Vorteil davon ist eine gewisse Vereinfachung des Codes im HTML-Dokument, die auch mit einer wesentlich besseren "Weiterverarbeitbarkeit" einhergeht. Google "mag" z.B. semantisch ausgezeichnete Inhalte. Ein weiterer Vorteil ist, dass man das Aussehen einer mitunter sehr umfangreichen Webpräsenz an einer zentralen Stelle steuert, und dass man bei einem "Redesign" eben nur an dieser zentralen Stelle arbeiten muss.

Dein nächstes Forschungsziel (und vielleicht lebenslanges Streben nach Meisterschaft?) wäre dann logischerweise das Layouten von Seiten mittels besagtem CSS. Eine sehr kompetente Einführung in diese Thematik findest Du in SELFHTML8.1.2: http://de.selfhtml.org/css/intro.htm

ALSO:
Gibt es ein Dokument, das "HTML 4.0"-Getreuen übersichtlich NUR die aktuell wirklich notwendigen Updates zusammenfasst und darstellt?

Das glaube ich kaum, da die tatsächlichen Neuerungen eher konzeptioneller Art sind, die sich nicht alleine auf einen vielleicht modifizierten Sprachstandard HTML4 reduzieren lassen (demnächst vielleicht HTML5). Es ist vielmehr die "aktualisierte Denkweise", die Du verstehen und umzusetzen lernen müsstest, anstatt lediglich besondere Schreibweisen in Deinen HTML4-Dokumenten zu berücksichtigen.

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Chris©]

Hallo,

FRAGE:
Was muss man inzwischen zwingend von Neuerungen und/oder Änderungen an den verbindlichen Standards wissen, und an der eigenen Quelltextzeile ändern?

Das ist wahrlich eine interessante Frage. Ich sollte sie neulich schon mal beantworten.
Also imho musst Du CSS auf jeden Fall auf den Zettel nehmen. Und auf der JavaScript-Seite wirst Du um AJAX nicht herumkommen, denn viele Webseiten funktionieren heute nicht richtig (sie bleiben hängen), weil dort kaputte AJAX-Versuche eingebunden sind.

XHTML würde ich immer noch nicht zwingend dazu zählen.

Allerdings würde ich Dir die (schleichende) Umstellung der Codierung von ISO8859-1 auf utf-8 dringend als betrachtenswürdig ans Herz legen. Mit dem größten Vergnügen habe ich da die Dispute meines Schätzelchens mit Anderen aus diesem Forum mitgelesen ;-)
Und ich meine, dass er unter dem Strich nicht Unrecht hat. UTF-8 stellt für viele ein echtes (Denk-)Problem dar. Alleine die (unvollständige) Verbindung zu anderen Diensten (z.B. Mailformulare) verusrsacht immer wieder Falschdarstellungen (auch bei der T-Bum zu beobachten).

Ich habe mir dann noch die Neuerungen für MySQL und für PHP5 (OOP) auf den Zettel genommen, denn da hat sich wirklich sehr viel getan. Aber nach Backend und Datenbank hast Du nicht gefragt, deshalb gestatte mir dies bitte als private Zusatzanmerkung.

LG
Chris©

[ChrisB]

Hi,

Und auf der JavaScript-Seite wirst Du um AJAX nicht herumkommen, denn viele Webseiten funktionieren heute nicht richtig (sie bleiben hängen), weil dort kaputte AJAX-Versuche eingebunden sind.

XHTML würde ich immer noch nicht zwingend dazu zählen.

Ich schon, gerade wenn du vorher AJAX "empfiehlst".

Klar kann man XMLHttpRequest auch lediglich zum Text-Nachladen mit anschliessender innerHTML-Kleberei benutzen, wenn man mag - aber XML zu nutzen, bietet einem da doch flexiblere Moeglichkeiten.
Und dann ist es m.E. empfehlenswert, wenn auch das eigentliche HTML-Dokument bereits XML-Regeln folgt.

MfG ChrisB

[Chris©]

Hallo,

Und auf der JavaScript-Seite wirst Du um AJAX nicht herumkommen, denn viele Webseiten funktionieren heute nicht richtig (sie bleiben hängen), weil dort kaputte AJAX-Versuche eingebunden sind.

XHTML würde ich immer noch nicht zwingend dazu zählen.

Ich schon, gerade wenn du vorher AJAX "empfiehlst".

Klar kann man XMLHttpRequest auch lediglich zum Text-Nachladen mit anschliessender innerHTML-Kleberei benutzen, wenn man mag - aber XML zu nutzen, bietet einem da doch flexiblere Moeglichkeiten.
Und dann ist es m.E. empfehlenswert, wenn auch das eigentliche HTML-Dokument bereits XML-Regeln folgt.

Ok, sehe ich ein.
Ich meinte damit, XML / XHTML würde ich jetzt noch nicht alleine auf den Zettel nehmen, eben nur, wenn man es für AJAX nutzen will.

LG
Chris©

[molily]

Hallo,

XML / XHTML würde ich jetzt noch nicht alleine auf den Zettel nehmen, eben nur, wenn man es für AJAX nutzen will.

Häh? Was hat Ajax mit XML oder XHTML im besonderen zu tun?? Für »Ajax« brauche ich nicht notwendig XHTML oder XML, und der Einsatz von XML und XHTML ist auch ohne »Ajax« möglich und sinnvoll.

XML ist erstmal ein Austausch- und Speicherformat, das an vielen Ecken und Enden im Web und der Webentwicklung verwendet wird. Damit sollte man sich ganz klar unabhängig von »Ajax« beschäftigen. XML spielt für Client-Server-Kommunikation mit JavaScript eher eine untergeordnete Rolle.

XHTML ist bloß eine mögliche Syntax für HTML-Dokumente, HTML auf SGML-Basis ist die andere. Mit beiden Linearisierungen kann ich dasselbe DOM erzeugen und beide eignen sich gleichermaßen als Container für Client-Server-Kommunikation mit JavaScript.

Mathias

[molily]

Hallo,

Klar kann man XMLHttpRequest auch lediglich zum Text-Nachladen mit anschliessender innerHTML-Kleberei benutzen, wenn man mag - aber XML zu nutzen, bietet einem da doch flexiblere Moeglichkeiten.
Und dann ist es m.E. empfehlenswert, wenn auch das eigentliche HTML-Dokument bereits XML-Regeln folgt.

Welchen Unterschied macht es, ob ich mit XMLHttpRequest XML vom Server hole und dessen Daten dann in ein HTML-Dokument einbaue oder in ein XHTML-Dokument? - Keinen. Ich operiere auf beiden Dokumenten mit dem gleichen DOM.

Ja, man kann mit XMLHttpRequest XML vom Server holen und über DOM Core darauf zugreifen. Aber was hat das damit zu tun, ob das Dokument, in das das JavaScript eingebunden ist, HTML oder XHTML als *Linearisierung* verwendet? Nach dem Parsen habe ich, wie gesagt, das gleiche DOM.

(Zumal XHTML 1.0 üblicherweise ohnehin als HTML geparst wird.)

Mathias

[Der Martin]

n'Abend,

Also imho musst Du CSS auf jeden Fall auf den Zettel nehmen.

unbedingt! Und damit einhergehend eine Neuorientierung in HTML. Die bisher vielleicht praktizierte Technik, Layout und Darstellung mit HTML-Attributen zu regeln, aus dem Gedächtnis verbannen.

Und auf der JavaScript-Seite wirst Du um AJAX nicht herumkommen, denn viele Webseiten funktionieren heute nicht richtig (sie bleiben hängen), weil dort kaputte AJAX-Versuche eingebunden sind.

Eine andere Konsequenz wäre, auf Javascript generell zu verzichten.

XHTML würde ich immer noch nicht zwingend dazu zählen.

Nicht zwingend - aber egal ob HTML oder XHTML, auf jeden Fall die Strict-Variante. Es mag pedantisch erscheinen, aber letztendlich tut man sich selbst einen Gefallen, wenn man sich an die dazu nötige Disziplin gewöhnt.

Allerdings würde ich Dir die (schleichende) Umstellung der Codierung von ISO8859-1 auf utf-8 dringend als betrachtenswürdig ans Herz legen.

Ach ...?

UTF-8 stellt für viele ein echtes (Denk-)Problem dar. Alleine die (unvollständige) Verbindung zu anderen Diensten (z.B. Mailformulare) verusrsacht immer wieder Falschdarstellungen (auch bei der T-Bum zu beobachten).

Ich lese hierin einen Widerspruch zu deiner oben ausgesprochenen Empfehlung. Denn das ist für mich eher ein Argument, eben *wegen* dieser Probleme UTF-8 zu meiden - zumindest dann, wenn ISO-8859-x alle Zeichen enthält, die ich für meinen Webauftritt verwenden möchte.

So long,
 Martin

[Daniel Thoma]

Hallo Martin,

Ich lese hierin einen Widerspruch zu deiner oben ausgesprochenen Empfehlung. Denn das ist für mich eher ein Argument, eben *wegen* dieser Probleme UTF-8 zu meiden - zumindest dann, wenn ISO-8859-x alle Zeichen enthält, die ich für meinen Webauftritt verwenden möchte.

Unicode (ob nun mit utf8 oder utf16) konzequent zu verwenden, hat den Vorteil, dass man über Zeichensätze nicht mehr oder nur noch an den Schnittstellen seiner Anwendung nachdenken muss.
Wenn man nur statische HTML-Seiten bastelt, kann man das sicher halten, wie man will. Bei (größeren) Webanwendungen, ist es durchaus hilfreich, alle Templates, Daten, was auch immer als UTF8/16 gespeichert zu haben.
Mehrere Zeichensätze in einer Anwendung zu verwalten, ist ziemlich ätzend.
Mittlerweile gibt es eigentlich auch kein Problem mehr mit Unicode.

Grüße

Daniel

[ChrisB]

Hi,

UTF-8 stellt für viele ein echtes (Denk-)Problem dar. Alleine die (unvollständige) Verbindung zu anderen Diensten (z.B. Mailformulare) verusrsacht immer wieder Falschdarstellungen (auch bei der T-Bum zu beobachten).

Ich lese hierin einen Widerspruch zu deiner oben ausgesprochenen Empfehlung. Denn das ist für mich eher ein Argument, eben *wegen* dieser Probleme UTF-8 zu meiden - zumindest dann, wenn ISO-8859-x alle Zeichen enthält, die ich für meinen Webauftritt verwenden möchte.

*Du* fuer *deinen* vielleicht ...

Nimm nur mal Weblogs und das sog. Trackback-Feature.
Wie oft sieht man da Trackbacks, in den Kaestchen oder Fragezeichen auftauchen - weil sich beide Seiten nicht ueber die Kodierung der uebertragenen Daten einig waren.
Wenn endlich "alle" UTF-8 verwenden wuerden, waere das Problem Schnee von gestern ...

MfG ChrisB

[molily]

Hallo,

Wie oft sieht man da Trackbacks, in den Kaestchen oder Fragezeichen auftauchen - weil sich beide Seiten nicht ueber die Kodierung der uebertragenen Daten einig waren.

Das liegt eher daran, dass das Protokoll unterspezifiziert ist und die beteiligte Software oftmals von der Problematik der Zeichenkodierung bei »fremdem Content« unbeleckt ist. Das Problem gibt es bei HTTP-POST generell. Prinzipiell lässt sich die Kodierung der POST-Daten angeben, in der Praxis determiniert das HTML-Umfeld die Kodierung (Kodierung des Dokuments mit dem Formular, accept-charset). Bei einem Webservice wie Trackback gibt es keinen Kontext, daher ist die Kodierung frei - es gibt lediglich die Empfehlung, die Kodierung im Content-Type-Header anzugeben, was aber offenbar entweder keine Software tut, oder die Angabe ist falsch, oder die Gegenseite ignoriert die Angabe.

Natürlich könnte man wie etwa bei XML sagen, dass UTF-8 das Mindeste ist, was eine Implementierung verstehen muss, also quasi UTF-8 als Standardkodierung vorschreiben. Das löst das Problem aber nicht grundsätzlich, denn andere Kodierungen sind durchaus legitim in manchen Fällen. Allerdings kann man von einer Weblog-Software tatsächlich nicht erwarten, Inhalte auch noch rekodieren zu können.

Mathias

[Chris©]

Hi ChrisB,

UTF-8 stellt für viele ein echtes (Denk-)Problem dar. Alleine die (unvollständige) Verbindung zu anderen Diensten (z.B. Mailformulare) verusrsacht immer wieder Falschdarstellungen (auch bei der T-Bum zu beobachten).

Ich lese hierin einen Widerspruch zu deiner oben ausgesprochenen Empfehlung. Denn das ist für mich eher ein Argument, eben *wegen* dieser Probleme UTF-8 zu meiden - zumindest dann, wenn ISO-8859-x alle Zeichen enthält, die ich für meinen Webauftritt verwenden möchte.

Nö, man kommt doch nicht drum herum.
Und wenn ich einen anderen Thread hier anschaue, in dem von Mail-Problemen gesprochen wird, dann ist doch klar, dass man sich mit Kodierungen und deren Konvertierbarkeit und Erkennbarkeit schlechthin auseinandersetzen muss.

https://forum.selfhtml.org/?t=168235&m=1097616

Deshalb muss man es selber noch lange nicht an jeder Stelle einsetzen.

LG
Chris©

[molily]

Hallo,

Und auf der JavaScript-Seite wirst Du um AJAX nicht herumkommen, denn viele Webseiten funktionieren heute nicht richtig (sie bleiben hängen), weil dort kaputte AJAX-Versuche eingebunden sind.

Häh?
Weil irgendwer kaputte Scripte schreibt, soll man Ajax lernen?

Eine andere Konsequenz wäre, auf Javascript generell zu verzichten.

Häh?
Weil irgendwer kaputte Scripte schreibt, soll man auf JavaScript verzichten?

Ma-Häh?-thias

[Chris©]

Hallo Mathias,

Und auf der JavaScript-Seite wirst Du um AJAX nicht herumkommen, denn viele Webseiten funktionieren heute nicht richtig (sie bleiben hängen), weil dort kaputte AJAX-Versuche eingebunden sind.

Häh?
Weil irgendwer kaputte Scripte schreibt, soll man Ajax lernen?

Ja, es gibt inzwischen ziemlich viele kaputte AJAX-Applikationen im Netz. das deutet auf eine hohe Akzeptanz bei den Seitenbetreibern hin und weil eben so viele kaputt sind auf eine lukrative Einnahmequelle für diejenigen, die sich gut damit auskennen.

Warum sollte man noch etwas lernen, das niemand verwendet und was außerdem von den wenigen Anbietern der Leistung bereits in ausreichender Menge und technisch richtig implementiert wird?

LG
Chris©

[molily]

Hallo,

Warum sollte man noch etwas lernen, das niemand verwendet

Sage ich ja nicht.

und was außerdem von den wenigen Anbietern der Leistung bereits in ausreichender Menge und technisch richtig implementiert wird?

Ich repariere keine bestehenden kaputten Ajax-Anwendungen, sondern entwickle funktionierende (weiter) und bekomme das auch bezahlt. Z.B. HTML und CSS gibts auch durchaus in vernünftiger Qualität im Netz, natürlich nicht in ausreichender Menge. Das liegt aber weniger daran, dass die Leute, die vernünftige Sites wollen, keinen kompetenten Entwickler finden. Die Webseiten-Betreiber, die Müllcode ausliefern, stellen leider niemanden ein, um das HTML und CSS mal ganz grundlegend zu reparieren.

Mathias