Diskussion:Computerkurs: HTML, CSS und Javascript

uiuiui ;o)

Kann es sein, daß hier die Unterschiede zwischen XHTML und HTML nicht klar sind? Warum wird sonst die ganze Zeit von HTML gesprochen, aber etwa ein Grundgerüst für XHTML 1.1 angegeben? HTML und XHTML sind ganz andere Sprachkonzepte, was sich auch etwa beim Element br äußert - bei HTML gibt es da eben nur eine Anfangsmarkierung, bei XHTML nicht, da muß man es explizit schließen, daher auch der zusätzliche Schrägstrich, der beim aktuellen HTML4.01 übrigens falsch ist. HTML und XHTML werden auch von ganz unterschiedlichen Programmen interpretiert (anderen Teilen eines browsers). Und von wegen Elemente - so heißen die eben und nicht 'Container' (englisch: elements). Ansonsten in XHTML1.1, also bei dem angegebenen Grundgerüst, gibt es gar kein Attribut target für das Element a.

Wenn man übrigens die Kodierung des Dokumentes richtig angibt, braucht man die Entitäten nicht - bei einigen XHTML-Varianten ist sogar dringend davon abzuraten, diese zu verwenden (mal abgesehen von den wenigen, die in XML generell verwendet werden müssen), weil die browser-Anbieter mehr und mehr dazu neigen, diese HTML-Entitäten bei den aktuellen XHTML-Varianten nicht mehr zu interpretieren - sondern unter Umständen nur eine Fehlermeldung anzuzeigen.

Ergibt es irgendeinen Sinn, solche Wörter wie Doctype, Block-Element, Inline-Tag (gibt es dann auch eine Auspoint-Nacht?), Link (deutsch: Verweis, Referenzierung?) zu verwenden, ohne sie überhaupt oder ordentlich zu erklären? Ist eigentlich klar, was der Unterschied zwischen einem Element und einer Markierung (wird wohl Tag im Gegensatz zu Nacht genannt) ist? Und der Unterschied zwischen Blockelementen und Phrasenelementen (inzeiligen, englisch: inline) beinhaltet ja auch wichtige Informationen darüber, welche Elemente in welchen notiert werden dürfen...

Zu "Doch der Browser bekommt, keine fertige Seite, sondern einen Code, den er zusammenfügen muss.": Unter Code, also auf hochdeutsch Quelltext, kann sich der Leser ja noch was vorstellen, aber wie sollte man sich vorstellen, daß ein browser eine 'fertige Seite' bekommen kann? Pixelgraphik? Oder in welchem Sinne fertig? Bei digitalen Formaten ist doch alles irgendwie kodiert und muß erstmal dekodiert und interpretiert werden - 'fertig' in dem Sinne gibt es da doch gar nicht, so wie man etwa ein Buch oder eine Zeit kaufen kann, um sie in Händen zu halten, um etwas darin zu lesen...

Insgesamt denke ich schon, daß man (X)HTML auch recht kurz halbwegs sinnvoll erklären kann. Je kürzer allerdings umso schwerer, wenn der Leser dem dann auch noch irgendeine sinnvolle und korrekte Information entnehmen soll ;o)

Doktorchen 20:25, 4. Mär. 2012 (CET)

Mir sind die meisten dieser Details durchaus bekannt. Als ich mit dem Kapitel begonnen hatte, hatte ich aber noch kein Detailwissen. Es wird problematisch, wenn man alle Feinheiten am Anfang erklären will, weil es 1. zu viel Platz braucht und den Rahmen sprengen würde und 2. schnell verwirrend sein könnte, da dieses Buch eigentlich für Schüler gedacht ist (über den 2. Punkt könnte man noch hinwegsehen, schliesslich handelt es sich um 7. bis 10. Klasse).

Mein Gedanke war, dass das Kapitel eine kleine Einführung und ein paar Beispiele bietet, sodass man sich zum Beispiel in einem Quelltext besser zurecht findet, aber nicht ein komplettes Tutorial. Man sollte nach diesem Kapitel nicht eine eigene professionelle statische Homepage aufsetzen können. Darüber gibt es eigene Bücher. Deshalb war ich der Meinung, dass man Grundsätzliches definiert (was ist HTML?), feinere Abgrenzungen beispielsweise zu XHTML grob anreisst aber dann auf das Buch verweist. Wer sich dafür interessiert, soll oben genannte Unterschiede und Erläuterungen dort finden. Es kann auch nicht sein, dass man alle Unterschiede zwischen HTML und XHTML erklärt (HTML basiert auf SGML, XHTML auf XML; XHTML ist strikter...). Womöglich muss man auch besser abgrenzen, was man nun vom Detailgehalt her schreiben möchte.

Was Formulierungen wie "Fertigstellung" betrifft, muss ich gestehen, dass mir auf die schnelle kein besserer Begriff eingefallen ist. Vor diesem Problem stand ich schon öfters, aber wie soll man kurz erklären, dass der Browser den Quelltext interpretiert? Inline und Block könnte man noch genauer erläutern, wobei klar sein sollte, dass man kein Block-Element in einem Inline-Element schreibt. Was das Deutsch-Englisch-Problem angeht, bin ich dafür, alles auf Englisch zu schreiben, weil man viel mehr Probleme hat, wenn man mit einem "Phrasenelement" etwas nachfragt und ausserdem, weil W3C alles auf Englisch spezifiziert. Dann muss man das aber auch am Anfang schreiben, damit niemand auf die Idee kommt nach einer Nacht zu suchen.

Eine Überarbeitung ist sicher nötig, ich werde mich beizeiten daran machen. Falls jemand Zeit und Lust hat, bitte ich ausdrücklich um Mitarbeit am Text. --raf-dat 22:47, 5. Mär. 2012 (CET)

Ich meine, man muß weder alles von (X)HTML erklären noch den Leser direkt in die Lage versetzen, nach dem Lesen einer Einführung schöne Dokumente zu verfassen. Letzteres kann man natürlich gleich von vorne herein als Motivation für die Einführung klarstellen. Ersteres ist mehr eine Frage, worauf man überhaupt eingeht - das sollte dann schon über die Einführung hinweg richtig und in sich konsistent sein. Es ist zum Beispiel sehr verwirrend, über HTML zu schreiben, aber XHTML zu verwenden - entscheiden muß man sich da schon, ob man nun HTML-Markierungssuppe erläutern will (schwierig bis unmöglich, wie die derzeitigen Versuche und Arbeitsentwürfe für HTML5 zeigen ;o) oder wie XHTML etwas verglichen damit relativ einfaches erläutern, was zugegebenenermaßen allerdings weniger oft verwendet wird. Dann würde ich auch sagen, daß es nicht hilft, Begriffe wie 'container' einzuführen, die in Spezifikationen keine Bedeutung haben. Deutsch oder englisch - gut, im letzteren Falle sollte man den Artikel vielleicht dann besser in einem englischen wikibook veröffentlichen - im ersteren Falle ist es natürlich hilfreich, die in den Spezifikationen verwendeten Begriffe, die ja den deutschen meist recht ähnlich sind oder übersetzt sind (Markierung, englisch: tag), zusätzlich anzugeben. Interpretieren lernt doch das Kind in der Schule, warum sollten Programme nicht auch interpretieren? Wie der Name schon sagt, stellt das Darststellungsprogramm dann ja auch die Interpretation dar. Das kann man gut zusammenfassen, indem man erläutert, daß solch ein Programm den (X)HTML-Quelltext darstellt, oft visuell, aber für einige Leute auch akustisch, taktil etc. Gerade die Möglichkeit, unabhängig vom verwendeten Gerät eine Darstellung zu realisieren, ist ja einer der Kernpunkte von (X)HTML. Wenn es ohnehin nicht der Anspruch ist, daß der Leser mit dem Text selbst Dokumente erstellen soll, kann man ja auch gut darauf verzichten, einzelne Elemente zu erklären und kann sich dann mehr auf die generelle Struktur und den Zweck konzentrieren, das bringt dem Leser mehr als aus dem Zusammenhang gerissene Details, die dann nachher beim Versuch der praktischen Anwendung doch irgendwie falsch sind - wo der Leser dann eben feststellen muß, daß er letztlich aus dieser Einführung gar nichts gelernt hat. Doktorchen 10:45, 6. Mär. 2012 (CET)