Diskussion:Hypertext Markup Language/Archiv/1

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Einordnung gegenüber anderen Sprachen

Nach lesen des Artikels hatte ich den Eindruck, dass HTML damals etwas völlig Neuartiges war. Das war es aber nicht. HTML wurde mit SGML definiert -- gehört also einfach zu der Gruppe Sprachen, die durch die Meta-Sprache SGML definiert werden (deshalb auch der Verwendung des Begriffes "DTD" im 'Überblick' und "SGML" in 'Zusatztechniken und Weiterentwicklungen'). Ich finde man sollte versuchen HTML auch im Kontext seiner Meta-Sprache SGML einordnen. Evtl. sogar bzgl. der Sprachhistorie im Allgemeinen. Was haltet ihr davon? --217.224.122.237 00:49, 4. Dez 2006 (CEST)

WYSIWYG-Editor Code

Diese Editoren produzieren einen HTML-Code, der die optischen Vorstellungen weitestgehend widerspiegelt. Allerdings wird die strukturelle und logische Auszeichnung, die dem Text erst einen echten Mehrwert gibt, dabei vernachlässigt. Diese erfordert ein gutes Verständnis von HTML, das ein WYSIWYG-Editor nicht ersetzen kann.

Das stimmt doch nicht. Ein guter WYSIWYG-Editor könnte selbstverständlich strukturellen und logischen Code erzeugen --~~16:23, 16. Sep 2006 (CEST)

Er könnte, wenn er entsprechend Programmiert ist und die Leute ihn dann so benutzen, wie sie das sollten. Leider fehlt es bei den meißten an Wissen, wie man den WYSIWYG-Editor richtig benutzt. Heißt, man muss zum erstellen einer Überschrift diese über Formatierungen angeben, dass das eine Überschrift ist ("Das ist eine Überschrift" = "<h1>") und das Aussehen (Größe, Schriftart, ...) an einer anderen Stelle ändern, wo man die Formatvorlagen ändern kann.
Wahrscheinlich geben die Leute eher an: Dieser Satz soll entsprechend groß und Fett sein, so dass er wie eine Überschrift aussieht, dass ist dann aber kein struktureller Code (<span style="font-size:2em;" >). Heißt, die Benutzer brauchen das Verständnis und Wissen darüber.
Wenn man hingegen direkt in HTML schreibt ist man automatisch dazu verleitet in strukturellem und logischem Code zu schreiben, da man das normalerweise von anfang an so lernt. --Nico Düsing (Diskussion) 12:22, 17. Sep 2006 (CEST)

Diskussion zur Umstellung von Myr:

In meinem Benutzer-Diskussionsbereich: "Bin etwas sauer. Hallo Nephelin, was soll die Wiederherstellung der mistigen HTML-Seite ohne Diskussion?? Die Diskuss.-Seite ist doch ziemlich eindeutig?! Wenig konstruktiv" Myr

Ich habe die Umstellung auf die Version vom 11:50, 14. Dez 2003 (Limasign) vorgenommen, da das komplette Umschreiben mehr Informationen vernichtet hat, als dem geneigten Wikipedia-Benutzer gebracht hätte. Der Artikel ist seit Juni 2002 (!) gewachsen... und Wikipedia lebt davon, das man Teile eines Artikels verbessert und erweitert - sowie formale als auch grammatische Fehler beseitigt. Sinn ist es aber nicht, Informationen zu vernichten oder 2/3 eines Artikels opfert, um eine einem Wörterbuch entsprechende Information zu geben.

"Mistig" war der alte, über ein Jahr gewachsene Artikel nicht - vielleicht in Deinen Augen?

Zum Kritikpunkt der zu fachlichen Auslegung des Artikels: Fachlich würde ich diesen Artikel bezeichnen, wenn er die Grammatik (definiert in der DTD) behandelt oder eine Referenz zu einzelnen HTML-Befehlen wiedergeben würde. Auch eine Einführung in HTML ist in dem Artikel nicht enthalten. Durch die lange Entwicklung des Artikels kann aber sowohl einem Neuling, als auch einem fortgeschrittenen HTML-Entwickler Hintergrundinformation geboten werden (und wofür sonst ist eine Enzyklopädie da?). Die Einleitung ist sicher überarbeitungswürdig - aber 2/3 an Informationen zu vernichten, um in nach der eigenen Facon umzuformulieren, bis er wirklich nur noch eine Grunddefinition darstellt, ist (nach meinem Empfinden) nicht der Sinn der Wikipedia. Man muss nur einmal die Artikel in der Versionkontrolle vergleichen und sieht, was für einen Informationsverlust die "Überarbeitung" letzlich gebracht hat.

Leider ist die Verknappung von Informationen gerade in der öffentl. Diskussion: Viele Dozenten gehen dazu über, Informationen nur noch in Stichworten (im PowerPoint-Stil) zu vermitteln, entsprechend erschreckend gering ist der Lerneffekt und Informationsgehalt...

Zum Kritikpunkt 2: Das ich nicht binnen weniger Stunden geantwortet habe ist ganz einfach... dies ist ein öffentliches "Freizeitprojekt" und es gibt mehr als die Wikipedia im Leben - speziell in der Vorweihnachtszeit.

TG 03:26, 20. Dez 2003 (CET)

Hallo Nephelin, der letzte Punkt ist akzeptiert, sorry. Der Artikel gefällt mir zwar immer noch nicht, aber es sind jetzt einige Infos enthalten, die mir wichtig waren. Ich finde es immer unglücklich, wenn Infos für fortgeschrittene und Neulinge auf einer Seite verquickt werden - die einen müssen viel lesen, was ihnen bekannt ist, die anderen verstehen die Hälfte (noch) nicht. Die Relevanz der Informationen ist also zielgruppenabhängig, der Informationsverlust daher relativ. Wie auch immer, wir müssen weiterkommen. Vorschlag: die DTD-Varianten auslagern, Handbuch-Infos (was kann im Head stehen, ...) ebenfalls oder löschen. Oder wollen wir Stefan Münz Konkurrenz machen? SelfHTML ist viel zu gut und komplett. Ich werde dann noch einige mir wichtige Details und wiki-links (moderat) überarbeiten. --Myr 15:11, 20. Dez 2003 (CET)
Gegen moderates Optimieren (z. B. Grundlegendes in einen einführenden Absatz, danach die vertiefenden Informationen) und Erweitern spricht nichts... nur das pauschale Löschen bringt nichts. Lieber eine Information, die nur Fortgeschrittene verstehen, als eine Information zu vernichten. Natürlich sollte man keine HTML-Tagreferenz oder ein Tutorial hier erstellen, grundlegene Informationen zur Struktur, zur Entwicklungsgeschichte, den DTDs sind aber integraler Bestandteil (wenn auch nur für Fortgeschrittene). Daher kann man ja auch eine Gliederung mit Überschriften (oder Tabellen) schaffen. Und eine Enzyklopädie ist nun mal kein zielgruppenorientiertes Medium, sondern eine Wissensbasis für viele. Wikipedia bietet darüber hinaus die Möglichkeit, ohne Beschränkungen im Umfang Informationen (aufbereitet) bereitstellen zu können. Mit dem Entfernen der Informationen zum Head-Tag kann ich auch sehr gut leben, die Schema-Varianten sind aber schon ein wichtiger Bestandteil. Welche Browserhersteller es gibt oder welche Editoren finde ich schon viel weniger von Belang... aber da es sicher auch Menschen gibt, die nur grundlegende Einstiegsinformationen benötigen, würde ich auch diese Daten nicht löschen - auch wenn ich sie obsolet finde. Und nebenbei... "HTML sei eine Sprache für Webseiten" wie es in ähnlicher Form zuvor im Artikel stand ist alles andere als richtig. HTML wird inzwischen auch bei der Gestaltung von Benutzeroberflächen, POIs, MHP usw. genutzt. Und das man im Artikel auch dafür plädieren sollte, dass man sich an Konventionen (W3C.org) hält, und Standards einhalten sollte (strict variant, Wohlgeformtheit, etc.) ist didaktisch wichtig... wehret den Anfängen. Und Aublicke zu XHTML, XML/XSLT etc. sind auch wichtig, wenn auch nicht für Einsteiger. Nur sollte man jede Information (auch beim Umschreiben) bewahen und evtl. später wieder einfügen. TG 15:30, 20. Dez 2003 (CET)



HTML und Wikipedia: Wie mache ich es, dass in einem Beitrag Wikipedia alle Tags so durchkopiert, wie sie sind? -- Fgb

Ich bin mir nicht ganz sicher, was Du mit "durchkopiert" meinst. Wenn es um die Darstellung geht benutze am besten (wie im Artikel) < code > und < /code >.
Wenn es ums ausführen geht: Die Software lässt nur bestimmte Tags zu, was wohl vor allem aus Sicherheits- (JavaScript) und Kompatiblitätsgründen so ist. Ich weiß nicht, ob wir dazu eine komplette Liste haben, konnte in der internationalen WP auf die schnelle nichts finden (was nichts heißt).
Generell bitte mit HTML-Tags sparsam umgehen. Sie sind ein Notbehelf für die Dinge, die mit den Wiki-Tags nicht zu realisieren sind, aber leider machen sie den Quelltext auch schnell unleserlich, v.a. für Nicht-HTML-Kundige. --Kurt Jansson
Mit "durchkopiert" meine ich, dass Wikipedia das, was ich als HTML-Schreibe, auch als HTML dem Browser dargestellt wird. Und selbst JavaScript zu erlauben wäre nicht schlecht, könnte man den Leuten doch kleine, interaktive Beispiele geben. Das mit der Sicherheit halte ich nicht für ein Problem, schließlich kann eine Seite ja wieder abgeändert werden, wenn sie Probleme bereitet. -- Fgb
Musste dich an die Programmierer wenden, Lee Crocker ist der, von dem die zukünftige Version stammt. Kannst dich ja in die Wikipedia Mailinglisten eintragen und dort den Vorschlag machen. -- Ben-Zin
versuche mal &_lt_; für "<" und &_gt_; für ">", die Untenstriche weglassen. Dann dürfte das nicht als Tag interpretiert werden.

Bis auf genau welche Ausnahmen ist XHTML 1.0 semantisch gleich mit HTML 4.01? -- Memowe 11:36, 29. Okt 2003 (CET)

In den Strict-Varianten unterscheiden sich einzelne Tags bei der Unterstützung diverser (obsoleter) Attribute, die in XHTML/XML über CSS 2.0 abgebildet werden.TG 12:24, 29. Okt 2003 (CET)
Aber das ist doch IMO in HTML 4.01 Strict genauso. -- Memowe 09:41, 30. Okt 2003 (CET)
Aber nur in der "srict" Variante und nicht in der "transitional" Variante. Und die meisten Seiten im Web (inklusive Wikipedia) sind von HTML 4.01 strict/XHTML 1.0 weit entfernt. Eventuell sollte man die Varianten "frameset", "strict" und "transitional" sowie deren Bedeutung (Sinn und Zweck) erklären und den Leser für XHTML sensibilisieren (Wohlgeformtheit von Dokumenten). TG 11:25, 30. Okt 2003 (CET)
XHTML 1.0 hat genau wie HTML 4.01 drei DTDs Strict, Transitional und Frameset. Es ging nicht um XHTML 1.1, das nur noch mit einer Variante daherkommt. -- Memowe 02:51, 2. Nov 2003 (CET)
Habe ein paar Sätzchen zu den drei DTDs geschrieben. Was meinst Du mit "sensibilisieren"? Welchen Zustand einige Mio. Webseiten haben, sollte aber weder Diskussionsargument, noch für den eigentlichen Artikel relevant sein. ;-) -- Memowe 03:38, 2. Nov 2003 (CET)

Meistens meint man HTML-Elemente statt HTML-Tags, wenn man HTML-Tags sagt. Beachtet das bitte. Während p ein HTML-Element ist, ist <p> das Start-Tag und </p> das End-Tag des HTML-Elements p.

Danke, das ist mir bekannt. :-) An welchen Stellen wurde es falsch gemacht? Ändere es bitte einfach, wenn Du meinst, dass es falsch sei. Sei mutig! ;-) -- Memowe 11:45, 29. Okt 2003 (CET)

Das Petersen-Problem

  • (Aktuell) (Letzte) . . 18:37, 17. Nov 2003 . . Akl (langsam macht es kein Spaß mehr!)
  • (Aktuell) (Letzte) . . 18:32, 17. Nov 2003 . . 62.104.214.78
  • (Aktuell) (Letzte) . . 16:31, 17. Nov 2003 . . Akl (und wieder zurück. KANN HIER MAL BITTE EIN ADMIN EINSCHREITEN? (IP 62.104.214.78))
  • (Aktuell) (Letzte) . . 16:29, 17. Nov 2003 . . 62.104.214.78
  • (Aktuell) (Letzte) . . 16:23, 17. Nov 2003 . . Akl (zurück zur Version vom 02:03, 15. Nov 2003 (wiederholter Link-Spam))
  • (Aktuell) (Letzte) . . 16:14, 17. Nov 2003 . . 62.104.214.78

krieg? -- Horst Frank 18:33, 17. Nov 2003 (CET)

Würde ich mich nie dran beteiligen - ich bin Pazifist ;-) -- akl 18:40, 17. Nov 2003 (CET)
scheint ja auch jetzt vorbei zusein. Puh, gück gehabt. -- Horst Frank 18:43, 17. Nov 2003 (CET)
Tastaturen zu Pflugscharen! -- akl 18:52, 17. Nov 2003 (CET)
[62.104.214.78] nach Brüssel -- Horst Frank 18:57, 17. Nov 2003 (CET)
Ich hab dem ganzen Mal einen Namen gegeben, zumindest sagt die Denic das ein Christian Petersen die Domains besitzt.
Für's erste hab ich nur eine mail an die Abuse-Abteilung von freenet (mit denen surft der anscheinend) geschickt. Wenn's nochmal vorkommt ruf ich ihn direkt an. -- TomK32 06:52, 18. Nov 2003 (CET)

Unleserlich

Ich finde den Einführungstext für einen Unkundigen komplett unleserlich. Das versteht keine Sau. Mir juckt es eigentlich in den Fingern zumindest den ersten Absatz komplett zu entfernen und durch eine einfache Erklärung zu ersetzen.

Eigentlich ist erst einmal wichtig, dass es sich um ein Datenformat handelt, in dem Webseiten gespeichert sind. Zur weiteren Erklärung würde ich noch etwas von einer Sprach zum Markieren von Texten schreiben und einen Vergleich mit einer Textverarbeitung heranziehen. Das ist eigentlich alles was ein informierter Laie wissen sollte.

Der jetzige Artikel überfällt einen direkt mit syntaktischen XML in Verbindung mit SGML und einer priese DTD, aus der XHTML in der Version 1.0 mit viel Semantik wird ... ach, was weis ich denn was für Krankheiten man sich damit einhandelt :-)

Nun, dann überarbeite die Einführung, aber bitte so, dass keine Informationen verloren gehen. PS HTML ist eine Markup Language für Hypertexte (inzwischen ja fast Hypermedia) - aber kein "Datenformat in dem Webseiten gespeichert sind". Wenn überhaupt ist es eine Meta-Beschreibungssprache. Und zu den Begriffen... dafür handelt es sich um einen Hypertext... TG 03:44, 20. Dez 2003 (CET)
Zu der Textverarbeitung ist zu sagen, dass ja gerade das das Missverständnis ist. HTML ist mit einer Textverarbeitung im allgemeinen eben NICHT zu vergleichen! Mirko 21:22, 8. Dez 2003 (CET)
Der Begriff Semantik ist in HTML überaus wichtig, da es sich ja um eine Textauszeichnungssprache handelt, kein Designwerkzeug (auch wenn das viele Laien noch so sehen, aber dafür gibt's ja nunmal CSS!). Dass es in SGML bzw. XML (XHTML) definiert ist, ist für den Laien aber in der Tat verwirrend. Und DTDs sollten sehr viel weiter hinten erwähnt werden! 82.82.127.116 21:28, 8. Dez 2003 (CET)
Der Begriff Semantik wird von meiner Oma nicht verstanden. Ich würde den Begriff eher umschreiben und in Klammern es als Samantik bezeichnen. Ansonsten hat die ganze Diskussion Layout vs. Semanik für jemanden, der nur wissen will, was HTML den eigentlich darstellt, einen eher esoterischen Karakter. Das sind alles unwichtige technische Einzelheiten, die man in eine Lehrbuch findet, aber doch nicht in einer Enzyklopädie! Und schon gar nicht in den ersten Sätzen!
Nun, wenn Deine Oma so wißbegierig ist, dann schlägt sie auch "Semantik" nach (bzw. klickt das Wort an). Ein Artikel sollte sowohl einem Neuling (der nur eine Definition in einem Satz braucht bzw. die ihm reicht), als auch einem fortgeschrittenen Leser Informationen bieten... wer mehr wissen möchte liest den gesamten Artikel, wer nur kompakte Informationen möchte, liest die Einleitung. PS Unterschreiben kann man einen Diskussionsbeitrag mit vier Tilde-Zeichen (~). TG 03:57, 20. Dez 2003 (CET)
Zur Textverarbeitung: Kann ich nicht bestätigen. Man muss ja bei Textverarbeitung nicht direkt an WYSIWYG denken. Auch in einer Textverarbeitung werden die Texte markiert, um Layout und/oder Semantik festzulegen. CSS ist nix anderes als eine Formatvorlage. Die verschiedenen Dokumentenverarbeitungssysteme haben ja alle mehr oder weniger die selbe Geschichte hinter sich. Da klaut einer vom anderen und am Ende kommt überall das Gleiche 'raus. Die Unterschiede halte ich eher für technischen Einzelkram, den niemand interessiert. Noch was zum Wording: In einer Textverarbeitung markiere ich einen Text und weise ihm dann ein Format zu (bzw. setze es). Ich habe noch nie jemanden sagen hören, dass er einen Text als Überschrift "Auszeichnet". Es heißt ja auch Markup Language.
Nun, dann weißt Du es ja jetzt, dass man von "auszeichnen" spricht... dank der Wikipedia lernt man immer dazu. ;-) TG 04:04, 20. Dez 2003 (CET)
Einwurf: Ich tue das! (Wobei man auch von "markieren" reden kann) :D Mirko 12:33, 13. Dez 2003 (CET)

Ansonsten habe ich eher den Eindruck, als ob man mit dem Text die abtrünnigen HTML-Coder der Neuzeit auf den Pfad der Tugend zurückführen möchte. Die heilige Inquisition der HTML-Esoterik, oder so ähnlich. Das kann aber doch gar nicht die Aufgabe sein. Eigentlich möchte der Besucher doch nur wissen, wozu man HTML überhaupt brauch und nutzt. Den ganzen technischen Schnickschnack kann er besser in Lehrbüchern wie z.B. SelfHTML nachlesen.

Es wird niemand gezwungen, vom W3C spezifizierten browserunabhängigen Standard-Code zu erzeugen. Und etwas zur Esoterik... SelfHTML ist didaktisch wertvoll, denn das Buch versucht ebenfalls, "abtrünnige HTML-Coder" auf den Pfad der Tugend zu bringen... die "Vergewaltigung" des Internet durch Frontpage-Webseiten (entspricht nicht HTML) sollte endlich beendet werden. Begriffe wie Wohlgeformtheit haben nichts mit Körpermaßen zu tun! PS Unterschreiben kann man mit vier Tilde-Zeichen (~) TG 04:04, 20. Dez 2003 (CET)

HTML ist keine Variante von SGML, sondern eine, mit Hilfe von SGML definierte Dokumentenstruktur. Die entsprechenden DTDs sind beim W3C zu finden. RolfS 10:30, 19. Dez 2003 (CET)

XHTML-Absatz herausnehmen?

Ich schlage vor, den Absatz beginnend mit »In XHTML wurden einige Elemente geändert, damit sie der XML-Syntax entsprechen. ...« am Ende des Abschnitts »Überblick« zu entfernen bzw. auf einen kurzen Satz zusammenzustauchen. Diese Zusammenhänge werden im Artikel zu XHTML ausführlich diskutiert, ein Hyperlink wäre angebrachter. Sie sind in einem Artikel über HTML im Abschnitt namens Überblick (allgemein über HTML) nicht relevant. --molily 01:10, 12. Nov 2004 (CET)

HTML ist nicht nur für den Bildschirm gedacht ...

Ihr schreibt richtig, dass HMTL nicht zur physichen Auszeichnung dienen soll. Ich habe aber einen deutlichen Hinweis vermisst, dass die Ausgabe einer HTML-Datei nicht zwingend auf den Bildschirm oder überhaupt "optisch" erfolgen muss, somit die (missbraeuchliche) Verwendung von Auszeichnungen zur Steuerung der graphischen Darstellung bei akustischer Ausgabe nicht nur unsinnig, sondern u.U. kontraproduktiv sein kann. --62.214.177.176 22:37, 18. Jun 2005 (CEST)

In der aktuellen Version steht zumindest: »Denn obwohl HTML-Dokumente in der Regel auf Computerbildschirmen dargestellt werden, können sie auch auf anderen Medien ausgeben werden, etwa auf Papier oder mittels Sprachausgabe.« Ich habe Hinweise darauf in den letzten Edits zusammengeführt, also wenn möglich bitte zentral und einheitlich ergänzen. -- molily 22:41, 18. Jun 2005 (CEST)

Im Grunde genommen ist HTML eine Sprache zur Strukturierung von Dokumenten; die Darstellung übernimmt ein geeignetes Programm (Browser, Lesegeräte, etc) --87.234.148.76 13:51, 25. Jan. 2007 (CET)

aus der beendeten "Lesenswert"-Diskussion November 2005

Hypertext Markup Language verlängert bis 26.11.

Ein anonymer Benutzer hat die Vorlage eingebaut, ich trage hier mal nach. --Robot Monk 20:41, 19. Nov 2005 (CET)

  • Pro - Ein wirklich gelungener Artikel über die Möglichkeiten HTMLs und auch Allgemein eine gute Einführung in die Grundsätze von HTML. Deswegen Pro! --Florian24 15:17, 20. Nov 2005 (CET)
  • Pro --Philipp Lensing 20:02, 20. Nov 2005 (CET)
  • Neutral Ich habe zwar, aufgrund der Tatsache dass ein Hautpautor scheinbar fehlt, die dumpfe Vermutung, dass meine Kritikpunkte nicht abgearbeitet werden werden, aber versuchen will ich es trotzdem mal: Die Beispiele im Überblick bringen nichts wenn sie nicht auch entsprechend in HTML Formattiert werden. Vielleicht ein Screenshot des Quelltextes der Wikipedia Startseite? Stellenweise stören mich die Formulierungen noch ein bisschen: Die Lektüre einer modernen linearen Einführung (siehe Weblinks) und die Handarbeit direkt in einem Texteditor ist empfehlenswert, um HTML richtig zu verstehen und voll auszunutzen. oder Diese erfordert ein gutes Verständnis von HTML, das ein WYSIWYG-Editor nicht ersetzen kann. Wir schreiben hier eine Enzyklopädie und kein HowTo... Weiterhin könnte der Geschichtliche Teil etwas aufgepumpt werden. Wie entwickelte sich HTML, wozu wurde es entwickelt, wie verbreitete es sich, etc. Hierzu gehört auch dass man die alten HTML Versionen nicht nur als Liste nennt, sondern als FließtextGeschichtlich in den Kontext eibaut. Zuletzt könnte man die Weblinks noch etwas straffen. Regnaron 21:22, 20. Nov 2005 (CET)
  • Zur Adressierung anderer Dokumente im Internet werden innerhalb des Dokumentes Hyperlinks verwendet. Dies ist die Grundlage für das World Wide Web. Eine stramme Behauptung, die mich richtig neugierig gemacht hat. Und was ist? Im Folgenden verliert sich der Artikel im Klein-Klein der Texterstellung. Das ist langweilig und überhaupt nicht lesenswert. Kontra--Bordeaux 14:50, 25. Nov 2005 (CET)
  • Pro: Gute Übersicht des Themas, jedoch fehlt imho noch die referenz zu http, und die Tags sind teilweise fast zu detailliert beschrieben Hoagman 20:50, 25. Nov 2005 (CET)
  • Kontra: Ziemlich durchschnittlicher Artikel, ein bissle zusammengewürfelt.--Richardigel 14:18, 16. Feb 2006 (CET)

Seite sperren?

Vielleicht sollte man die Seite vorübergehend sperren, bis sich dieser Langweiler, der die Seite in letzter Zeit heimsucht, ein anderes Opfer gesucht hat? --Manuel<small> - </small>[[Benutzer Diskussion:Manuel Strehl|<small>(Diskussion)</small>]] 16:30, 1. Dez 2005 (CET)

Acid2

Die Kompatibilität zum Standard kann man sehr einfach mit dem Acid2 Test testen, den neben dem konqueror (Khtml-Engine) auch Safari besteht.

Der Satz ist nicht nur widersinnig, sondern hat im Artikel HTML auch wenig verloren.

  • Kompatibilität zum CSS-Standard kann man nicht einfach testen. Acid2 ist auch alles andere als ein Lackmustest für praxisrelevante CSS-Unterstützung, denn:
  • Der Acid2-Test ist ein akademischer Test. Im Absatz geht es um »Falsche Interpretation von Webdokumenten«. Zitat: Dies zwingt Webautoren dazu, ihre Dokumente in verschiedenen Browsern zu testen und gegebenenfalls anzupassen. Die vom Acid2-Test aufgezeigten Browserfehler haben mit den damit gemeinten praktischen Problemen wenig zu tun (man kann etwa ziemlich problemlos für Firefox 1.5 entwickeln - obwohl er Acid2 verhaut).
  • CSS 2.1 ist übrigens ein kommender Standard, der momentan noch ein Working Draft ist.

Ich nehme den Satz heraus. -- molily 01:01, 19. Feb 2006 (CET)

Ha! Du willst mich überzeugen! Aber du hättest eine Alternative gehabt. Du hättest einen Blick auf meine Beiträge werfen können, und hättest gesehen, dass ich den CSS-Artikel radikal umgeschrieben habe. In der Diskussion zum CSS-Artikel nehme ich bezug auf den acid-test, behaupte gar, er befände sich im Hauptartikel zu CSS. Daraus hättest du folgern können, dass ich den Abschnitt hier eingefügt habe, obwohl ich vorhatte, ihn bei CSS einzufügen.
Und damit hättest du dann recht gehabt, er gehört hier nicht hin. --Richardigel 22:03, 20. Feb 2006 (CET)

Oma-Test?

Ähhh, der Artikel ist zwar inhaltlich absolut okay - alles da, alles enzyklopädisch, alles sprachlich gelungen. Nur leider, leider, leider besteht der Artikel in weiten Strecken den Oma-Test nicht. Für Omis und Laien ist das hier ein Buch mit sieben Siegeln. Kann man da was machen, liebe Informatiker/Computer-Freaks??? Nicht alle haben das studiert, was Ihr studiert habt. --Englandfan 02:46, 30. Apr 2006 (CEST)

Liste der Sprachelemente

Hallo, Matze6587!

Ich habe den von Dir eingesetzten Link im Sinne von WP:WEB wieder entfernt. Die verlinkte Seite ist inhaltlich veraltet und mangelhaft. Da HTML keine imperative Sprache ist, gibt es außerdem keine HTML-Befehle – höchstens Sprachelemente o. ä.

Die von dir gewünschte Auflistung wird bereits durch den enthaltenen SELFHTML-Link und die fünf W3C-Links geliefert. Grüße -- Sypholux Bar 19:38, 16. Aug 2006 (CEST)

Ok, sorry, werde mir das mal anschauen. Wenn ich manchmal etwas suche und nicht finde und dann endlich gefunden habe will ich dass es andere auch finden können. Das war die einzige Motivation den Weblink hinzuzufügen. Mir hat diese Seite mehr als alle anderen verlinkten weitergeholfen. MfG--Matthias Pester Disk. (Matze6587) 12:16, 17. Aug 2006 (CEST)
Für eine vernünftige Referenz schau dir die SelfHTML-HTML-Referenz an. Alternativ bietet natürlich die W3C-Spezifikation hier einen schönen Überblick. Du siehst: kein Bedarf für eine weitere Auflistung! --Manuel - (Diskussion) 14:02, 17. Aug 2006 (CEST)

New German HTML tutorial

Please consider this new German HTML tutorial to be listed under Weblink / Tutorials:

http://de.html.net/tutorials/html/introduction.asp

It will give you an easy, yet thorough and correct introduction to HTML.

Regards,

Andreas Astrup, HTML.net (nicht signierter Beitrag von 194.255.144.229 (Diskussion | Beiträge) 11:28, 18. Dez. 2006 (CET))

Web 2.0 und Ajax

Dadurch wird die Änderung einer Webseite möglich, ohne sie vollständig neu zu schreiben.

Das Verb "schreiben" finde ich in diesem Zusammenhang unpassend. Durch die asynchronen Anfragen wird doch im Grunde nur verhindert, dass nicht für jede vom Benutzer ausgeführte Aktion die komplette Seite (inklusive des Layouts) neu übermittelt und aufgebaut werden muss. Demnach trifft der Satz den Kern des Ganzen nicht.

Auf die soziale Komponente des Web 2.0 wird darüber hinaus gar nicht eingegangen. (nicht signierter Beitrag von 84.136.101.245 (Diskussion | Beiträge) 21:49, 19. Dez. 2006 (CET))

HTML lernen

Für das schnelle Erstellen von Webseiten ohne tiefere HTML-Kenntnis mag der Gebrauch eines so genannten WYSIWYG-Editors zunächst genügen.

Das klingt wenig enzyklopädisch und ist, mit Einschränkung, für meinen Geschmack zu subjektiv. Den Satz sollte man am Besten ersatzlos streichen, der Abschnitt als solches trifft das Thema gut. (nicht signierter Beitrag von 84.136.101.245 (Diskussion | Beiträge) 21:54, 19. Dez. 2006 (CET))

HTML als Hypertext bezeichnet

Es mag schon sein, dass HTML-Dokumente eine Ausprägung von Hypertext darstellen, aber die Sprache HTML wird doch nicht als Hypertext bezeichnet? Wäre mir noch nie aufgefallen. Was ist gemeint? 83.65.242.218 20:07, 7. Jan. 2007 (CET)

Aulassen von Tags

In der aktuellen Version (11.01.2007, 10:08) meint der Wikipedia-Eintrag folgendes:

"Ohne Attribute können einige Tags auch ausgelassen werden (z. B. <html>/</html>, <head>/</head>, <body>/</body>), bei manchen nur der schließende Tag (

)."

Ich würde diese Zeile gerne löschen, da sie meines Erachtens nicht unbedingt richtig ist. Vor allem das Weglassen von <html></html> würde zur Folge haben, dass das Root-Tag fehlt. Weiters würde ich als "Attribute" nur Werte bezeichnen die innerhalb eines Tags stehen und nicht Werte die zwischen Tag-Anfang und Tag-Ende stehen. Das Weglassen der im Beispiel genannten Tags wird zwar von den meisten Browsern toleriert, aber Garantie würde ich darauf keine geben (vor allem bei <html></html> nicht). Falls ich doch sehr daneben liege bitte ich um Korrektur. Andernfalls würde ich wie gesagt die Änderung gerne durchführen.(nicht signierter Beitrag von Worufu (Diskussion | Beiträge) )

Hör mal ... wir beschreiben hier Html so, wie es im Standard steht. igel+- 10:48, 11. Jan. 2007 (CET)
Ja, du liegst daneben, wie du hier nachlesen kannst: „The HTML element … Start tag: optional, End tag: optional. -- net 12:04, 11. Jan. 2007 (CET)
Du verwechselst HTML mit XHTML, dass ist ein bedeutender Unterschied. Zwar ist es unwahrscheinlich, dass alle Browser das auslassen von Tags (oder die verwendung von z. B. sgml-shorttags) einfach tolerieren, da sie leider sehr eklige parser für html haben. Dennoch entspricht es dem Standard und sollte im Artikel bleiben. – d0k 16:17, 11. Jan. 2007 (CET)
Ich muss mich der Kritik von Worufu teilweise anschließen. Grundsätzlich stimmt es zwar, dass diese Tags weggelassen werden können, aber ich finde, dass diese Information nicht unbedingt in den Artikel gehört. Zumal dies die erste Stelle ist, an der diese Tags erwähnt werden. An dieser Stelle geht es eher darum den Grundaufbau eines Tags zu erläutern. Wobei ich leider auch sagen muss, dass dieser Abschnitt allgemein nicht besonders gelungen ist. Es wird zweimal von Attributen gesprochen, ohne das geklärt wurde, was das ist. Es ist außerdem schwierig den Text zu verstehen, selbst, wenn man sich mit HTML gut auskennt, da er einfach kompliziert geschrieben ist. Aber das wurde ja schon an anderer stelle diskutiert. --JMK4189 01:04, 10. Apr. 2007 (CEST)

HTML5

Sollte nicht vielleicht erwähnt werden, dass angestrebt wird, HTML5 parallel zu xHTML2 herauszubringen?

Quelle: Heise online ([1])

Es ist zwar (noch) nichts offizieles von W3C, aber ich denke auch es sollte erwähnt werden, dass das klassische HTML weiterentwickelt wird. Weitere Quellen: [2] --JMK4189 00:25, 10. Apr. 2007 (CEST)
Html5 wird sicherlich noch wichtiger werden, kann aber bereits erwähnt werden. Insbesondere die Empfehlungen zum Content Type und die Selbstbeschränkung sind erheblich viel näher an den tatsächlichen Browserimplementierungen als das weit hergeholte html4.01. igel+- 00:27, 10. Apr. 2007 (CEST)
HTML5 ist seit dem 9. Mai die offizielle nächste Version von HTML (en:HTML#New development). de.wikipedia hat das verschlafen, und dieser Artikel ist praktischerweise gesperrt. Naja, wie ihr wollt.--87.162.25.185 04:40, 17. Mai 2007 (CEST)
Ich habe den deutschen Artikel zu HTML5 mal etwas aufgestockt, vielleicht bietet das ja eine etwas bessere Diskussions- und Bearbeitungsbasis. --84.152.74.141 20:29, 1. Dez. 2007 (CET)

Begriff: Frame

Hallo, kann mir jemand mal FRAME erklären? Quelle: ichselbst

Hidi ho, die beste Quelle, um HTML zu lernen, ist die Spezifikation auf http://w3.org . Da wirst du die Warnung finden, dass Frames eine schlechte Technik sind. Stattdessen benutzt man heutzutage iframes und Cascading Style Sheets. igel+- 11:17, 19. Feb. 2007 (CET)
Iframes sind nicht minder schlecht. --Grüße, Auke Creutz um 18:39, 24. Feb. 2007 (CET)
Ein Frame (oder Iframe) ist ein Bereich auf einer Homepage, in den eine Andere Seite geladen wird. Wenn man eine Webseite mit tausenden Unterseiten hatte, war das ganz praktisch, da man, um das Menü zu änder, nicht jede Seite ändern musste. Heutzutage wird sowas jedoch von PHP oder anderen Serverseitigen Scripten erledigt. --Nico Düsing (Diskussion) 15:20, 28. Feb. 2007 (CET)

Schreibung von HyperText

Laut Spezifikation des W3C und der engl. Wikipedia schreibt man (zumindest im Titel der Sprache) HyperText so - und nicht Hypertext. Der Artikel sollte entsprechend geändert und verschoben werden. --89.49.214.122 18:27, 24. Feb. 2007 (CET)

WP:NK. --Grüße, Auke Creutz um 18:39, 24. Feb. 2007 (CET)
Du meinst Wikipedia:Namenskonventionen/Englisch? Dann widersprechen sich doch der englische (HyperText) und der deutsche Artikel (Hypertext)? Namenskonventionen hin oder her, das ist ein Eigenname und den schreibt man so, wie er festgelegt wurde - JavaScript könnte bei der Gelegenheit auch gleich nach Javascript verschoben werden. Zumindest einheitliche Schreibweisen in der gesamten Wikipedia - egal, ob groß oder klein - wären doch nicht schlecht. --89.49.213.71 11:43, 25. Feb. 2007 (CET)
Die verschiedensprachigen Wikipediaversionen müssen und können nicht untereinander genormt werden. Hypertext ist ein Neologismus in Form eines zusammengesetzten Substantivs; sowas schreibt man im Deutschen klein, im Englischen oftmals groß, damit die Separation der Wörter deutlich ist, da die englische Sprache eigentlich über so etwas wie zusammengesetzte Substantive nicht verfügt. Man könnte es durchaus auch − deiner Argumentation folgend − als Eigennamen auffasen, aber das tu' ich aufgrund der Zusammensetzung aus vorhandenen Wörtern nicht; und wenn doch, wäre die Begutachtung von WP:NK#Markennamen interessant. Der Verschiebung von JavaScript zu Javascript kann ich nur beipflichten. Feste Konventionen fehlen hier aber entgegen meiner ersten Auffassung anscheinend doch. --Grüße, Auke Creutz um 20:06, 25. Feb. 2007 (CET)

Intension des Absatzes "Überblick"?

Was soll der Absatz "Überblick" bezwecken? Im Moment enthält er zuerst eine verwirrende Wiederholungen des Anfangsabschnittes, versucht anschließend die Struktur eines HTML-Tags zu erklären, um schließlich das Thema Trennung von Layout und Dokumentstruktur anzureißen.

Da liegt tatsächlich etwas im Argen. igel+- 00:48, 1. Jul. 2007 (CEST)

Vorschlag: Index aller HTML-Elemente

Anregung, Index aller HTML-Elemente (HTML 3.2, HTML 4.01, XHTML 1.0, XHTML 1.1, HTML 5, XHTML 2.0) als Referenz aufzunehmen. (Deutsch (HTML 4.01 - XHTML 2.0).) (nicht signierter Beitrag von 84.189.249.153 (Diskussion | Beiträge) 16:06, 1. Jul. 2007 (CEST))

HTML soll eine "Programmiersprache" sein?!

Also ich weiß ja nicht, wer den Artikel hier geändert hat, aber dass HTML Programmiersprache sein soll, muss definitiv 'raus. Es ist eine Auszeichnungssprache, die beschreibt, aber in keine Fall dynamisch ist. Bitte korrigier' das mal jemand, danke. (nicht signierter Beitrag von XraYSoLo (Diskussion | Beiträge) )

Wo bitte hast du das im Artikel gelesen? -- net 18:22, 25. Dez. 2007 (CET)
Der Kommentar bezieht sich offenbar auf die Liste der Programmiersprachen, wo HTML tatsächlich vertreten ist (und man über die Sinnhaftigkeit dieses Eintrags streiten kann). Allerdings steht dort immerhin ausdrücklich dabei, dass es sich eigentlich um eine Auszeichnungssprache handelt. --YMS 20:55, 25. Dez. 2007 (CET)
Mit dem Zusatz (den ich noch etwas geändert habe) ist es IMO ok, dass HTML dort in der Liste mit auftaucht. -- net 09:41, 27. Dez. 2007 (CET)

Muss wohl einer vor euch gemerkt und korrigiert haben. Ich erinner' mich noch an den Anfang des Satzes: "Als Programmiersprache ist HTML [...]" - Das war der Auslöser, aber jetzt solls ja OK sein. (nicht signierter Beitrag von XraYSoLo (Diskussion | Beiträge) )

Wenn ich mir die Versionsgeschichte des Artikels ansehe, steht da seit wenigstens zwei Jahren nichts mehr von einer Programmiersprache. Keine Ahnung, was für eine uralte Version du da gelesen hast. BTW: Bitte halte dich an die Regeln von WP und signiere deine Beiträge! -- net 09:41, 27. Dez. 2007 (CET)

"Hyper"

Ich hätte einmal gerne gewusst, was dieses "Hyper" bei Hypertext Markup Language bedeuten soll. Vielleicht weiß ja jemand weiter. Auf jeden Fall kann ich mit dem Begriff nur was bei den Begriffen "Hyperaktivität" oder "Hyperschallgeschwindigkeit anfangen. Danke!

--84.57.183.143 19:39, 7. Jan. 2008 (CET)

Hypertext ist ein verlinkter Text (mit Hyperlinks). Ein Wikipedia-Artikel ist z.B. ein Hypertext, der Text ist mit assoziativen Links versehen und nicht linear, wie ein gedrucktes Dokument.--Placebo111 20:24, 7. Jan. 2008 (CET)
Aus Webster:
Hyper- Hy"per- [Gr. "ype`r over, above; akin to L. super, E.
   over. See Over, and cf. Super-.]
   1. A prefix signifying over, above; as, hyperphysical,
      hyperthyrion; also, above measure, abnormally great,
      excessive; as, hyper[ae]mia, hyperbola, hypercritical,
      hypersecretion.
Das spielt (wie Placebo111 schon schreibt) auf die Hyperlinks an. -- net 21:27, 7. Jan. 2008 (CET)

Tabelle für Zeichen

Es könnte noch eine vollständige HTML-Tabelle über die Sonderzeichen angegeben werden. Z.B. &#960; für , die entsprechende Alternative zu finden scheint fast unmöglich. --Skraemer 15:39, 26. Okt. 2008 (CET)

Eine Sonderzeichen-Tabelle hat eher weniger etwas in einer Enzyklopädie zu suchen ;) Wir sind kein HTML-Tutorial. --Vanger !!? 20:34, 26. Okt. 2008 (CET)

Aso, ich habe vergessen zu sagen worum es geht. Schau Dir mal den Artikel Pi (Buchstabe) an. Da fehlte bisher die Variante . Dies führt dazu, daß dieses Zeichen fast immer irrtümlich als wiedergegeben wird. Die Tabelle soll also nicht explizit hier hinein, sondern ein Link als Quelle! Schau Dir mal den Zeichensatz "Altgriechisch" in der unteren Leiste an: auch da fehlt das ! Das gehört direkt hinter das ! Wikipedia sollte zumindest die Hilfsmittel bereitstellen einen Artikel fehlerfrei zu schreiben und nicht ständig auf irgendwelchen Regeln als Selbstzweck rumtingeln. In diesem Fall geht es nämlich nicht darum was Wikipedia ist oder nicht, sondern um fachliche Korrektheit und den Anspruch sollte Wikipedia schon haben! Auch soll der geneigte Leser auf die Vielfalt hingewiesen werden und sein Auge geschult werden. --Skraemer 21:00, 26. Okt. 2008 (CET)

"Hilfsmittel" um "einen Artikel fehlerfrei zu schreiben" haben aber nichts im ANR zu suchen, wenn dann im HNR ;)
Darüber hinaus sehe ich nicht weshalb im Artikel über HTML etwas von mathematischen Sonderzeichen und/oder altgriechischen Buchstaben stehen sollte. Eine Aufstellung von mit HTML-Repräsentationen versehenen Sonderzeichen gibt es im Artikel als externen Link übrigens schon: Selfhtml. --Vanger !!? 13:45, 27. Okt. 2008 (CET)

Die Abkürzungen ANR und HNR kenne ich nicht. Im gesamten Artikel wird bislang noch gar nichts über Zeichencodierung gesagt. Zeichen stellen jedoch den substantiellen Kern jeder Sprache dar. Der Link auf Selfhtml wird zwar genannt, jedoch nicht im Zusammenhang mit Zeichencodierung. Die englische Wikipedia berichtet: en:HTML#Character_and_entity_references. Es gibt im Internet sowas wie die 3 min Suchgrenze. Was bis dahin nicht gefunden wird improvisiert. Jeder mit nur rudimentären HTML-Kenntnissen muß deutlich darauf hingewiesen werden, das die Welt mehr Zeichen kennt als die Tastatur und wo man eine entsprechende HTML-Codierung finden kann. --Skraemer 16:32, 27. Okt. 2008 (CET)

ANR = Artikelnamensraum (z. B. Hypertext Markup Language); HNR = Hilfenamensraum (z. B. Hilfe:Namensräume; Seiten die mit "Hilfe:" beginnen)
Was die englische Wikipedia tut ist für die deutsche Wikipedia eher zweitrangig, die deutsche Wikipedia möchte definitiv nicht wie die englische Wikipedia sein. Die Wikipedia ist eine Enzyklopädie und kein Tutorial, die von dir genannte „3 min Suchgrenze“ ist für uns nicht relevant, wir erklären was und wofür HTML ist, nicht wie man HTML schreibt. Besagte Zeichentabellen findet man, inklusive Hinweis dass es sich um ein Tutorial handelt, auf einer von der Wikipedia verlinkten Webseite: Selfhtml. --Vanger !!? 16:49, 27. Okt. 2008 (CET)

Ja: HTML ist in der Lage codierte Zeichen darzustellen, also muß dies auch gesagt werden. HTML könnte ja auch eine schwache Sprache sein, also nur die lat. Buchstaben und Ziffern darstellen können. Mathematische Formeln wie Brüche, Summen und Integrale kann HTML dagegen nicht darstellen. Die Hilfe-Seite Hilfe:Sonderzeichenreferenz sollte erwähnt werden, da aus ihrem Namen nicht hervorgeht, das es sich um HTML-codierte Sonderzeichen handelt. Die HTML-Codierung der Seite Hilfe:TeX#Griechische_Buchstaben in Spalte HTML ist übrigens komplett falsch, weil der Schreiber wohl die HTML-Codierung nicht gefunden hat und deshalb die leicher auffindbare TeX-Codierung benutzte (beim varpi hab ich die falsche durch die in die korrekte Codierung ϖ ersetzt. Die Fälle wo es nicht funktioniert sind durch einen weißen Hintergrund erkennbar: in diesen Fällen ist die Darstellung mit der TeX-Darstellung identisch). Ich denke wir sollten die Tatsache der Codierung erwähnen und auf die Seite http://de.selfhtml.org/inter/unicode.htm verweisen, weil falsches Wissen darf auf Wikipedia NICHT verbreitet werden! Falsches Wissen kann auch durch Unterdrückung von Wissen entstehen. --Skraemer 17:36, 27. Okt. 2008 (CET)

HTML kann überhaupt nichts darstellen. Dargestellt wird das vom Browser oder was auch immer das HTML-Dokument verarbeitet. Welche Zeichen dabei mit Zeichenreferenzen umschrieben werden müssen, hängt (bis auf ganz wenige Ausnahmen) von der verwendeten Zeichensatzkodierung ab. In Zeiten, wo Unicode von so ziemlich jedem Browser vernünftig unterstützt wird, braucht man eigentlich nur noch in den seltensten Fällen Zeichenreferenzen. Da schreibt mal lieber gleiche π oder ϖ und sollte damit kaum Probleme haben. -- net 18:49, 27. Okt. 2008 (CET)

Ihr habt den springenden Punkt noch nicht erfasst: es geht um den Unterschied zwischen ϱ und (der deutlich erkennbar ist!) Dies liegt nicht am Browser, sondern an der falschen Kodierung (TeX statt HTML). Natürlich, es wird nur durchgereicht, aber das WIE muß korrekt angegeben sein! Die Angabe der Durchreichung in HTML-Syntax ist: &piv; oder &#982; Bei sehr ausgefallenen griechischen Buchstaben wie das Stigma sollte man besser mit &# kodieren.

Die Durchreichung ist in der Tabelle Hilfe:TeX#Griechische_Buchstaben völlig falsch angegeben, nämlich in TeX-Syntax. Der Unterschied zwischen ϱ und ist ja deutlich erkennbar!

Fazit. Dadurch das hier der Hinweis auf die HTML Zeichen-Codierung #& und der entsprechende Verweis auf Hilfe:Sonderzeichenreferenz fehlt, werden viele HTML-Seiten (und somit auch Wikipedia-Seiten) falsch kodiert. Ich sehe nicht, warum diese einfache Tatsache der Zeichenkodierung und ihre HTML-Syntax nicht angegeben werden sollte. --Skraemer 19:38, 27. Okt. 2008 (CET)

Was irgend welche Webseiten im Internet falsch machen ist für eine Enzyklopädie aber irrelevant, die Wikipedia erklärt was und wofür HTML ist und eben nicht das wie. Wenn das wie das Artikelschreiben in der Wikipedia beeinflusst, was es deiner Ansicht nach tut, dann hat das nichts im ANR zu suchen sondern gehört, wenn überhaupt, in den HNR oder WNR (Wikipedia-Namensraum; Alles was mit Wikipedia: anfängt; z. B. Wikipedia:Statistik). --Vanger !!? 20:14, 27. Okt. 2008 (CET)
Was ist denn bitte an dieser Tabelle völlig falsch? Dass die Zeichen ein wenig unterschiedlich aussehen, liegt einzig und allein daran, dass TeX als Grafik mit einer serverseitigen Schriftart erzeugt wird und das HTML-Zeichen mit einer Schrift auf deinem Rechner. Da ist es absolut klar, dass die Zeichen nicht 100%ig übereinstimmen. -- net 21:44, 27. Okt. 2008 (CET)
Genau, die Zeichen müssen verschieden aussehen wegen der TeX-Grafik, nur das tun nicht alle weil sie beide in TeX kodiert sind und nicht wie der Tabellenkopf ausweist: "Gerendert (html/tex)". Drin steht nämlich tex/tex. Beim ϖ habe ich das korrigiert, ϱ ist noch falsch. Kannst du mir folgen? Zugegeben es ist schwierig zu erfassen, worum es überhaupt geht. Um es mal als Gleichnis mathematisch auszudrücken: und 3,1415 sind zwei völlig verschiedene Zahlen. --Skraemer 22:01, 27. Okt. 2008 (CET)
Das ist dann aber ein Problem, welches du in der Disk zu der Tabelle ansprechen musst. Mit diesem Artikel hier hat das genau nichts zu tun. -- net 22:34, 27. Okt. 2008 (CET)

Die genaue Angabe wie Überschriften formatiert werden oder Hyperlink angegeben werden scheint mir aber eher auch ein Wie zu sein. Dann muß ich wohl selber die vielen Fehler auf unzähligen Wikipedia-Seiten verbessern. --Skraemer 20:49, 27. Okt. 2008 (CET)

Es hat ja auch nie jemand behauptet dass der Artikel in seiner jetzigen Form optimal wäre, nur weil er es zur Zeit nicht ist, ist das kein Grund den Artikel noch weiter vom Optimum wegzuführen (Nicht dass ich damit sagen will dass die Arbeit die du leisten möchtest schlecht oder nicht gut genug wäre, sie gehört nur eben nicht in diesen Artikel) ;) --Vanger !!? 21:22, 27. Okt. 2008 (CET)

Die Syntax &#[code position]; steht in SGML für eine numerische Zeichenreferenz und verweist auf die Code-Position eines Zeichens im verwendeten Dokumentzeichensatz. Bei HTML ist der Dokumentzeichensatz UCS, spezifiziert in ISO 10646. Außer der Syntax für diese Referenz, hat das nichts mit HTML zu tun und die geforderte Zeichensatztabelle sollte, wenn überhaupt, im Artikel über den entsprechenden Zeichensatz stehen also bei UCS. Schließlich ändert gegebenenfalls nicht das W3C den Inhalt des Zeichensatzes, sondern ISO. Nur die Zeichen-Entity-Referenz, also z.B. &lt; oder &amp; etc., ist Bestandteil der HTML-Spezifikation. Alauda 23:48, 29. Okt. 2008 (CET)

NOPV/Quellen

hier wird verschiedenen Browsern unterstellt, sie könnten HTML nicht richtig darstellen - das wäre mir neu

viele Browser haben bei der darstellung von HTML, welches mit CSS formatiert wird, probleme - nicht aber mit dem rendern von html

ebenso sind viele augenscheinliche fehlverhalten diverser browser das resultat von entweder fehlerhaftem code oder von standardkonformer sgml-features wie etwas omittag oder shorttag --suit Benutzer Diskussion:Suit 16:07, 27. Okt. 2008 (CET)

"Halb" Richtig... Der Internet Explorer hat auch Defizite bei der Behandlung von HTML, diese sind aber zugegebenermaßen nicht derart "extrem" wie dargestellt (bspw. hat der IE auch weiterhin Probleme mit dem <object>-Element). In das Thema fließen aber noch andere allgemeine Aspekte ein, beispielsweise die Behandlung von MIME-Types, diese gehören nicht direkt zum Thema, tangieren es aber - demnach "Wo sonst unterbringen?". Allgemein stimme ich dir aber zu dass die Neutralität doch ziemlich zu Wünschen übrig lässt ;) --Vanger !!? 16:20, 27. Okt. 2008 (CET)
Ich habe mal versucht die Textpassage ein bisschen zu überarbeiten. --Nico Düsing (Diskussion) 20:32, 27. Okt. 2008 (CET)
Noch ein kleiner Hinweis bzgl. fehlerhafter Darstellung von HTML an sich: IE unterstützt z.B. das <abbr>-Element nicht, sprich er zeigt einfach nüscht an, was darauf hinweist, dass hier ein zusätzlicher Tag verwendet wurde. So was gibt's schon. Is halt selten. --Manuel - (Diskussion) 09:16, 27. Nov. 2008 (CET)
Das mit dem zusätzlichen Tag habe ich nicht verstanden. Es kann sein, dass der IE den nicht unterstützt, aber das ist ein ganz normaler vom W3C-Standardisierter Tag. Was ist daran „zusätzlich“? --Nico Düsing (Diskussion) 09:55, 28. Nov. 2008 (CET)
Das ABBR-Element soll ja meist irgendwie dem Nutzer kenntlich gemacht werden, bspw. mit einem gestrichelten Unterstrich. Wenn man mit der Maus darüber geht, sollte dann das TITLE-Attribut als Tooltip angezeigt werden. Der IE (mindestens bis Version 6) kennt das ABBR-Element nicht und ignoriert daher alle Styles und Attribute eines so ausgezeichneten Textabschnitts. Ein durch das ABBR-Element ausgezeichneter Text ist im IE also nicht als solcher erkennbar. -- net 18:36, 28. Nov. 2008 (CET)
Auch wenn das unten bereits behandelt wurde, hier nochmal fürs Protokoll.
Das abbr-Element funktioniert auch im Internet Explorer 6 einwandfrei, wenn es nachträglich per JavaScript ins DOM eingehängt wird. Die Sache ist eine Unzulänglichkeit des IE6 der nicht vollumfänglich mit HTML 4.01 kompatibel ist: unbekannte Elemente zu ignorieren und deren Inhalt inline darzustellen ist völlig ok und historisch begründet - diese Regel wird hier einfach konsequent während des Reflow-Prozess angewandt --suit 19:21, 15. Dez. 2009 (CET)
Wenn du das so siehst, warum streichst du das – denn nichts anderes stand im Artikel – dann raus? Die Darstellungsunterschiede einer Webseite kommt in dem Fall nicht durch Unzulänglichkeiten bei CSS oder andere von HTML unabhängige Einflüsse, sondern durch die unterschiedliche Interpretation und Verarbeitung des Markups. Aber egal, wenn solche dogmatischen Ansätze jetzt allgemein gewünscht sind, dann klinke ich mich hier lieber aus. --net 11:46, 18. Dez. 2009 (CET)
Ich hab den Absatz doch entsprechend verständlicher gemacht "Die Darstellung ist kein Teil der entsprechenden Spezifikationen und ist somit willkürlich vom Browseranbieter bestimmbar." --suit 11:51, 18. Dez. 2009 (CET)
Nein, nur weil du korrekte Informationen entfernt hast, wurde der Abschnitt nicht verständlicher. Es stand schließlich auch vorher nirgendwo, dass HTML für die Darstellung verantwortlich ist, sondern nur, dass die Verarbeitung von HTML die Darstellung beeinflussen kann. Darüber muss man keine dreiseitige Abhandlung schreiben, man muss es aber auch nicht verschweigen und zum Lemma passt es auf jeden Fall. Aber wie schon gesagt, mir ist das jetzt echt egal. Schreib doch was du willst und ignoriere andere Meinungen. --net 12:40, 18. Dez. 2009 (CET)
Die "dritte Meinung" stimmt mir doch zu, ich verstehe nicht, was du willst --suit 12:45, 18. Dez. 2009 (CET)
Und wo ist die dritte Meinung?? Nico Düsing hat bis dato jeglich Verständnisfragen gestellt.--Kgfleischmann 21:37, 18. Dez. 2009 (CET)
Bezieht sich auf die Kommentare von Fritzbruno im Abschnitt weiter unten --suit 12:10, 21. Dez. 2009 (CET)

Verlinkung in Allgemeine Struktur

Im Unterpunkt Allgemeine Struktur steht:

der Dokumenttypdeklaration (Doctype) ganz am Anfang der Datei, die die verwendete Dokumenttypdefinition (DTD) angibt, z. B. HTML 4.01 Strict,.

Dabei wird Dokumenttypdeklaration und Dokumenttypdefinition auf den selben Artikel verlinkt. Sollte man da vielleicht mal was ändern? --Jobu0101 11:27, 9. Mai 2009 (CEST)

Siehe dazu auch: Diskussion:Hypertext_Markup_Language#NOPV.2FQuellen

Die einzige im Abschnitt genannte Quelle belegt nachhaltig, dass sich die Darstellungsunterschiede auf CSS beziehen. HTML selbst definiert in keinster Weise, wie die Darstellung zu erfolgen hat. Es ist unsinnig in diesem Artikel entsprechend darauf hinzuweisen da es dem Leser suggeriert, die Darstellung habe etwas mit HTML zu tun. HTML ist und bleibt eine Strutkurbeschreibungssprache - es existieren zwar ein paar präsentationsbezogene Elemente, diese sind aber durchgängig deprecated.

Wie die Darstellung erfolgt bestimmt in erster Linie das Browser-Default-Stylesheet (von antiken Browsern abgesehen in denen diverse Modelle "fest verdrahtet" sind. In zweiter Linie durch das Autoren-Stylesheet und in letzter Instanz durch das Benutzer-Stylesheet. Es ist faktisch unmöglich (und auch Wunschdenken) dass alles in jedem Browser gleich aussehen muss oder es irgendwelche Regeln dafür gäbe. Jegliche Darstellungsunterschiede liegen in der Natur der Sache und sind von vielen Faktoren (nicht aber von HTML) abhängig.

Sonderfälle, wie etwa der Doctype-Switch, die zufällig aus dem HTML entnommen werden, zählen hier nicht. Ansonsten könnte man auch das fehlerhafte SGML-Parsing moderner Browser ankreiden, auch das führt zu "Darstellungsunterschieden", wenn man darauf verzichten, ist die Darstellung aber weitgehend ident.

Diese Mängel ziehen sich wie erwähnt durch den kompletten Artikel - wenn es in absehbarer Zeit keine Belege gibt, dass HTML tätsächlich etwas mit der Darstellung zu tun hat - werde ich den Abschnitt wieder ersatzlos entfernen. Ich hierbei ausdrücklich auf WP:OR. --suit 17:24, 15. Dez. 2009 (CET)

Darstellungsunterschiede beziehen sich keinesfalls nur auf CSS. Ein Beispiel: Der IE (mindestens bis Version 6) kannte das Element ABBR nicht und hat es (bis auf den Inhalt) komplett ignoriert. Er hat weder das TITLE-Attribut angezeigt, noch per CSS gesetzte Formatierungen angewendet. Der Grund für die daraus folgende unterschiedliche Darstellung der Webseite war aber eben nicht CSS, sondern die unterschiedliche Verarbeitung von HTML. Insofern ist der Abschnitt durchaus grundsätzlich korrekt, sollte jedoch IMO ein wenig überarbeitet werden, damit das nicht missverstanden werden kann. --net 17:47, 15. Dez. 2009 (CET)
Wie bereits erwähnt: HTML regelt in keinsterweise die Darstellung, ergo kann es keine Darstellungsunterschiede geben.
Es ist nicht definiert, wie das abbr-Element auszusehen hat: http://www.w3.org/TR/html401/struct/text.html#h-9.2.1
The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.
Und wie das title-Attribut dargestellt werden soll: http://www.w3.org/TR/html401/struct/global.html#h-7.4.3
Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object).
Ich lese da in keinem Wort, dass es falsch wäre, ein title-Attribut überhaupt nicht anzuzeigen.
Woher nimmst also du deine Information?
Weiteres Beispiel: ältere Internet-Explorer-Versionen vermischen auch teilweise die Bedeutung von "alt" und "title" - aber auch das ist kein Argument. Das ist ein Browserfehler, aber hat nichts mit HTML zu tun.
Noch eins: Lynx interpretiert das abbr-Element auch nicht - nein, noch schlimmer: das title-Attribut ist für Lynx idR. auch nichtig, aber das ist noch lange kein Darstellungsunterschied der auf HTML begründet ist (siehe oben, das ist völlig OK).
Beide Abstätze gehören vollumfänglich entfernt - es muss lediglich ein Hinweis angebracht werden, der aufzeigt, dass die Darstellung in HTML nicht definiert ist und somit die Darstellung im Browser (ohne CSS) völlig willkürlich ist. --suit 19:11, 15. Dez. 2009 (CET)
im Fall <abbr> von "Darstellungsunterschieden" zu sprechen ist denn doch etwas ungewöhnlich. Das Problem des IE ist kein Darstellungsproblem sondern fehlende Standardunterstützung. Dies könnte auf der Browserseite vermerkt werden, hat aber mit HTML an sich nichts zu tun. Aber da die Seite hier sowieso sich nicht scharf abgrenzen lässt gegen verwandte Themen (AJAX zB hat mit HTML gar nichts zu tun) ist das zu erwähnen vergebliche Liebesmüh.--Fritzbruno 19:18, 15. Dez. 2009 (CET)
Siehe weiter oben: bei abbr _nur_ den Inhalt darzustellen ist völlig Standardkonform, wenn man davon ausgeht, dass der IE6 zu HTML 4.01 nicht kompatibel ist macht er es sogar völlig richtig. --suit 19:23, 15. Dez. 2009 (CET)
um meinen Beitrag zusammenzufassen: der Umgang des IE mit irgendwelchen HTML-Elementen gehört auf die Browserseite und ist keine HTML-Angelegenheit.--Fritzbruno 19:27, 15. Dez. 2009 (CET)
Es geht nicht direkt darum, wie das TITLE-Attribut dargestellt wird oder nicht. Der Internet-Explorer kennt ein Standardelement von HTML nicht und ignoriert aus diesem Grund dieses Element komplett - inkl. der typischen Darstellung des TITLE-Attributs und der Formatierung mittels CSS. In dem betreffendem Absatz steht das genauso geschrieben:
„Aber selbst valide (fehlerfreie) Seiten können unterschiedlich dargestellt werden, da nicht alle Standards von allen Browsern gleichermaßen erfüllt werden.“
Das ist meiner Meinung nach kein Thema, was man unbedingt verschweigen muss und es ist sehr wohl eine HTML-Angelegenheit. Schließlich dürfen UAs unbekannte Elemente ignorieren und dadurch kann sich eben auch die Darstellung der Webseite ändern, da CSS-Regeln nicht auf ignorierte Elemente angewendet werden müssen. Somit ist die unterschiedliche Verarbeitung von HTML in Browsern indirekt eben doch für Darstellungsunterschiede verantwortlich. Das sollte man eben halt nur etwas unmissverständlicher formulieren. --net 19:54, 15. Dez. 2009 (CET)
unmissverständlich formuliert: "Was die Webbrowser daraus machen ist ihre Sache". Mehr gibt's dazu aus HTML-Sicht nicht zu sagen!--Fritzbruno 22:19, 15. Dez. 2009 (CET)

XHTML2 ist tot

Man sollte den dementsprechenden absatz ändern: http://www.golem.de/0907/68142.html -- 213.236.208.22 11:46, 20. Jul. 2010 (CEST)

Bitte unverständliches Fachsprech vermeiden, wenn die Zusammenhänge auch in allgemeinverständlichem Deutsch geschrieben werden können.
--Konrad15:20, 2. Nov. 2010 (CET)

Definiere das - deine Versuche das selbst zu korrigieren scheitern jedenfalls kläglich. Du kannst nicht einfach deprecated durch hinfällig ersetzen bzw. übersetzen. Zudem sehe ich es nicht ein, dass du das einfügen redundanter Informationen als "Verbesserung" des Artikels betrachtest. deprecated ist und bleibt ein englischsprachiger Begriff der in der Softwareentwicklung verwandt wird. "Kein Mensch" sagt ernsthaft "missbilligt" - das ist zwar die exakte Übersetzung aus dem englischen, erklärt den Begriff aber nicht - deprecation in der Softwareentwicklung ist eben nicht einfach nur die Missbilligung - darum bin ich immer noch der Meinung, den Begriff deprecated so wie zuvor einzusetzen.
Du hast mit deiner Änderung den Bestand verändert - quasi kommentarlos und ohne Quellen - es ist eine Bringschuld deinerseits, dafür eine Rechtfertigung zu finden. Dass mir auf meiner Diskussionsseite ein Editwar vorgeworfen wird halte ich im Kontext deiner offensichtlich mangelnden Kompetenz in diesem Themenbereich für sehr fragwürdig.
Es ist ein Wiki - wenn du einen englischsprachigen Fachbegriff (für den es imho keine sinnvolle übersetzung in die deutsche Sprache gibt) nicht verstehst, spricht nichts dagegen, dass du einfach dem Link folgst und deine Wissenslücke füllst.
Wenn irgendwelche Abschnitte oder Zusammenhänge aufgrund der Fachsprache nicht klar werden und diese auf nicht durch Querverweise geklärt werden können, solltest du entsprechende Stellen aufzeigen damit diese korrigiert werden können - dein aktueller wunsch "mach mal allgemeinverständlicher" ist jedenfalls utopischer.
Ich habe mich in letzter Zeit bemüht den Artikel fachlich korrekter zu machen - dass dabei die Allgemeinverständlichkeit etwas auf der Stecke bleibt ist aber absicht gewesen, besonders wenn es um die exakte Unterscheidung von Tags, Elementen und Attributen geht. Wenn man im Artikel überall von "HTML-Tags" schreiben würde, könnte den Artikel zwar jeder "Hobby-Webdesigner" verstehen, fachlich wäre er aber katastrophal falsch. In Artikel über Chemie wird auch explizit zwischen Molekülen, Elementen oder Verbindungen unterschieden - und das ist gut so, auch wenn der unwissende diese Begriffe erstmal nachschlagen muss.
Wenn es also keinen triftigen Grund gibt, stelle ich die version von vor ein paar Tagen wieder her - deine korrekturen von engl. zu englisch sind nämlich auch nicht so wie in WP:FWF vorgesehen --suit 17:00, 3. Nov. 2010 (CET)

Literatur und Weblinks

Die drei Bucher, die angegeben sind sollten alle drei geloescht werden. Gruende: Stefan Muntz: Das Buch ist in Wirklichkeit eine HardCopy der Seite SelfHTML.org. Die Frage ist, wieso man ueberhaupt ein Buch kaufen soll, wenn man den gleichen Inhalt, sogar aktualisiert, kostenlos aus dem Internet herunderladen kann. Zudem ist der Copy&Paste Inhalt von SelfHTML sehr oberflaechlich bearbeitet: an etlichen Stellen findet man Fragmente, die auf der WebSeite Links waren: z.B. 'Anzeigenbeispiele hier' oder die 'Farbtabelle in Schwarz-Weis'. Im Buch sind diese Fragmente einfach Unfug und demonstrieren die oberflaechliche Bearbeitung. Stefan Mintert: Das Buch ist gar nicht mehr im Handel. Vom Anfang an war das Buch nur fuer ausgesucht Spezialisten z.B. fuer Doktoranten oder fuer eine Hochschulbibliothek. Dieses Buch richtet sich nicht an ein breiteres Publikum und haette niemals in den Artikel aufgenommen werden sollen. Mark Lubkowitz: Dieses Buch ist in Wirklichkeit nicht ueber HTML sondern ueber Webprogrammierung im Allgemeinen. HTML ist nur ein kleiner Anteil des Buchs – vielleicht 10%. Zudem war die Technologie, die in dem Buch beschrieben ist schon 2004, als das Buch erschienen ist, etwas veraltet. Das war 2004, nicht erst 2011. Stattdessen sollten die beiden folgenden Buecher aufgenommen werden. Eric Freeman, Elisabeth Freeman: HTML mit CSS und XHTML von Kopf bis Fuß, O'Reilly 2006, ISBN: 978-3897214538 Elizabeth Castro: HTML, XHTML & CSS - Der Meisterkurs: Lernen Sie HTML, XHTML & CSS auf dem schnellsten und einfachsten Weg!, Markt und Technik, 2009, ISBN: 978-3827244666

Die Weblinks: Wikiversity: Kurs zum Thema HTML und Webdesign: Das Tutorial ist eigentlich nicht schlecht. Der Nachteil ist dass es an etlichen Stellen Technologie verwendet, die inzwischen veraltet ist: beispielsweise das veraltetet <i>–Tag anstatt des <em>. Zudem geht das Tutorial nicht auf moderne Software Architektur ein (Stichwort: Trennung von Inhalt und Praesentation). Wenn man das macht, was in diesem Tutorial steht, entstehen Webseiten, wie man Sie irgendwann Ende der 90er Jahre gebaut hat.

Wikibooks: Websiteentwicklung Fuer dieses Tutorial gelten aehnliche Anmerkungen wie fuer „Wikiversity: Kurs zum Thema HTML und Webdesign“: Das Buch beruht auf veralteter Software Architektur. Beispielsweise werden Groessen von Bildern in Pixeln angegeben. Das Resultat ist, dass das Bild auf manchen Devices (z.B. Bildschirmen, Displays) gut aussieht, auf anderen Devices mit anderer Bildschirmgroesse/Aufloesung aber furchtbar. Inzwischen sind empfohlen relative Masseinheiten zu verwenden.

Das Buch ueber Webdesign ueberlappt sich inhaltlich mit dem Buch ueber Websiteentwicklung deswegen gelten aehnliche Kritikpunkte


SelfHTML ist eine super Seite. Der Link sollte auf jeden Fall im Artikel verbleiben. SelfHTML ist vollstaendig und detailliert. Tatsaechlich ist SelfHTML eher ein Nachschlagwerk als eine Einfuehrung fur Anfaenger. Deswegen bin ich mir nicht sicher, ob SelfHTML im Abschnitt Tutorial eingeordnet werden sollte. Zudem hat die Tatsache dass SelfHTML relativ vollstaendig ist, Nachteile fuer Anfaenger. Der Grund erfordert eine etwas laengere Erklaerung: Seit seiner Einführung in den 90er Jahren konnte HTML der stürmischen Entwicklung des Internets und des World-Wide-Webs nur mühsam folgen. In dieser Zeit wurde HTML über mehrere Versionen sehr verändert und erweitert. In Wirklichkeit waren diese Erweiterungen nicht nur neue Kommandos, die dazugekommen sind, sondern man hat heute eine ganz andere Herangehensweise, wie man Webseiten aufbaut, als vielleicht in den 90er Jahren. Aus Kompatibilitätsgründen sind die alten Kommandos noch immer im Sprachumfang – wenngleich von ihre Benutzung inzwischen abgeraten wird (im Jargon spricht man von "deprecated Tags") Wenn nun ein Anfänger die große Anzahl von Kommandos in SelfHTML studiert, ist er verwirrt von der Vielzahl der Lösungsmöglichkeiten, die es für bestimmtes Problem gibt. Sind alle die Möglichkeiten gleichwertig? Solle man eine davon bevorzugen? Nach welchen Kriterien solle man in einer gegebenen Situation die in irgendeinem Sinn "optimale" Lösungsmöglichkeiten auswähle? In dieser Situation fällt es vielen Personen gar nicht so leicht zu beurteilen, wie denn nun eine moderne Webseite aufgebaut sein sollte. Die älteren Kommandos suggerieren eine ganz andere Software Architektur. Wenn nun ein Anfänger in die Programmierung von HTML und CSS einsteigt, sollte er am besten gar nichts von diesen alten Kommandos wissen. Zumindest nicht in diesem allerersten Schritt.

jendryschik.de: Einführung in XHTML, CSS und Webdesign Das Buch von Jendryschik ist ebenfalls gut. In Wirklichkeit ist es ein eBook – kein Tutorial. Deswegen waere es wohl besser im Abschnitt Literatur aufgehoben – anstatt im Abschnitt Tutorials. Aber man kann es auch hier lassen. Ein weiterer Aspekt des Buchs von Jendryschik: Das Buch durchzuarbeiten und Uebungen dazu zu machen, wird wohl zwei Wochen Vollzeit brauchen. Viele Leser werden diese Zeit nicht investieren wollen.

Mein vorgeschlagener Link http://www.bluehorse.ro/html vom Zeitaufwand fuer das Tutorial ist etwa 2 Tage. Bezueglich des Matrialumfangs und der Detaillierung entspricht es in etwa dem Wikiversity Tutorial. Es beruht aber auf wesentlich modernerer Technologie, behandelt moderne Software Architektur and das Problem von veralteten Kommandos.

W3C Validator Zudem schlage ich noch vor dass wir einen Link auf das Validator Plugin fuer Firefox aufnehemn. Der Link steht zwar in gewissem Sinn in Konkurenz mit dem Original W3C link. Mit dem Fiefox Plugin kann man aber sehr viel bequemer arbeiten: Immer wenn man eine HTML Seite in Firefox laed werden die Fehler automatisch angezeigt. Fuer den Original W3C Validator muss man die Seite erst hochladen. Und meiner Erfahrung nach vergisst man das oft. Wenn man die Fehler sofort in Firefox sieht, kann man die Seite gleich korrigieren. Trotzdem wuerde ich eher den Link zum W3C auch im Aufsatz lassen – der Vollstaendigkeit halber und weil es quasi die „Ur“-Quelle ist.(--Truswalu 09:47, 30. Jan. 2011 (CET))

Truswalu (14:00, 29. Jan. 2011 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

den meisten Angaben kann ich folgen, allerdings ist ein Verweis auf irgendein Plugin definitiv der Bruch mit dem Anspruch auf Enzyklopädischen Wert des Artikels. Sowas gehört hier nicht rein!--Fritzbruno 17:47, 29. Jan. 2011 (CET)
Das Plugin ist offiziell von Mozilla. Es ist also nicht "irgendein Plugin". Trozdem, mit dem Plugin magst du recht haben... Das war mir nicht bewusst.(--Truswalu 09:47, 30. Jan. 2011 (CET))
Den bluehorse.ro Link kann ich nicht befürworten. Neben der lieblosen und unübersichtlichen Aufmachung sind die Inhalte teilweise fehlerhaft oder zumindest veraltet. Aussagen wie „HTML Dateien sind ASCII Dateien“ oder, dass deutsche Umlaute als Zeichen Entities einzugeben sind, sind in Zeiten von Unicode nicht mehr aktuell. Auch ist diese Seite viel zu oberflächlich und erklärt nur die Auswirkungen bestimmter Elemente und Strukturen ohne darauf einzugehen, wie das bewirkt wird. Zeichen Entities werden bspw. gar nicht als solche erwähnt und als „Kommandos“ bezeichnet. Mit solchen Mägeln ist der Link in meinen Augen absolut unbrauchbar. --net 10:41, 30. Jan. 2011 (CET)
Auf was bezieht sich die Bemerkung, dass die Seite bluehorse.ro "lieblos und unuebersichtlich" waere? (-- Truswalu 11:47, 30. Jan. 2011 (CET))
Schrieb ich doch, auf die Aufmachung. Keine Absatzabstände, keine Auszeichnung von Tags oder anderen Elementen im Fließtext, etc. pp. --net 11:59, 30. Jan. 2011 (CET)
Ah so. Mich hat das nicht gestoert; aber du hast wahrscheinlich recht.
Zu der Sache mit den Umlauten. In meinem eigenen HTML Code verwende ich auch Zeichen Entities. Der Grund: wenn jemand anders die Seite aendert und der Editor auf dem anderen Computer speichert die Datei mit einem anderen Zeichensatz entstehen Fehler, die auch womoeglich gar nicht sofort entdeckt werden.
Bist du denn der Ansicht, dass man die Zeichen Entities grundsaetzlich nicht verwenden soll - also als "deprecated" markiert werden sollten? (-- Truswalu 12:42, 30. Jan. 2011 (CET))
Zeichen-Entities können nicht grundsätzlich veraltet sein, da bestimmte Entities wie bspw. &amp; gebraucht werden. Allerdings braucht man sie bei Umlauten oder anderen Sonderzeichen nicht mehr, wenn man den Text UTF-8 kodiert. Beim Bearbeiten fallen dann Probleme auch eher auf, als wenn durch falsch Entities bspw. solche W&oumlrter entstehen. --net 21:45, 30. Jan. 2011 (CET)
Numerische und benannte Zeichenreferenzen sind nötig um zumindest die für die Sprache notwenigen Zeichen maskieren zu können - das sind <, >, ", ' und & - mehr nicht.
Prinzipiell sind alle weiteren benannten Referenzen nicht notwendig, da mit UTF-8 wie schon gesagt ohnehin alles entsprechend codiert werden kann - ein Fließtext in deutscher Sprache ist noch OK, da stört ein gelegentlich vorkommendes ü nicht sonderlich - aber bei einem chinesischen oder russischen Text sieht die Sache schon anders aus, das kann niemand mehr lesen. Darum - eine entsprechende Zeichenkodierung verwenden (UTF-8) und auf Referenzen verzichten. Alles andere ist schlechter Stil bzw. zeugt von wenig Ahnung (bzw. das genannte "wenn jemand anders die Seite ändert" ist absurd, wenn jemand anderer dran herumfingert soll er gefälligst über den nötigen Fachverstand verfügen - bei der Hausinstallation beschriftet der Elektriker auch nicht Außenleiter, Neutrallleiter und Erdung mit einem Aufkleber, damit ein anderer dann weiß, was gemeint ist).
Es gibt allerdings eine Ausnahme: bei schwer unterscheidbaren oder unsichtbaren Zeichen sind Zeichenreferenzen (ob nun benannt oder nummerisch) essentiell. U+00A0 (geschütztes Leerzeichen) ist z.B. ein solcher Kandidat. Das W3C hat hier einen entsprechenden Artikel: http://www.w3.org/International/questions/qa-escapes - jegliche weitere Diskussion darüber erübrigt sich somit, da dieser Artikel alles sauber abklärt. --suit 23:42, 30. Jan. 2011 (CET)

Änderungen vom 29.01.2011

Sprachlich wie inhaltlich gefallen mir die Änderungen unter "XML und XHTML" gar nicht; zum Beispie "hören sich gewaltiger an als sie sind" passt imho nicht in eine Enzyklopädie; der Hinweis mit "dem neueren Standard arbeiten" gehört überhaupt nicht in den Abschnitt. Komplett streichen? -- Hgulf Diskussion 09:12, 30. Jan. 2011 (CET)

Die sprachlichen Punkte, die du angesprochen hast, habe ich geaendert.
Zum Inhaltlichen: XML ist fuer HTML nur wichtig, weil es die Basis fuer XHTML ist. Die fruehere Version des Absatzes hat diese Beziehung nicht klar gemacht. In der frueheren Version stand XML in gewisser Weise "isoliert" neben HTML. Zudem sollte der Absatz deutlich machen, dass die formalen Aenderungen in der HTML Sprachdefinition (von HTML -> XHTML) eher Details waren. Diese Aenderungen haben aber enorme praktische Implikationen fuer Webentwickler. Erfahrene Webentwickler wissen das schon. Aber Anfaenger nicht. Beispielsweise die drei Buecher im WebLinks Abschnitt (WikiBooks & WikiVersity) beruhen durchwegs auf veralteten Standard und sind folglich als contraproduktiv anzusehen. (--Truswalu 10:22, 30. Jan. 2011 (CET))
Ich hab' sämtliche Änderungen grade revertiert. Kurze Begründung: "unqualifizierter Mist" - lange Begründung: XHTML 1.0 ist eine Neuformulierung von HTML 4.01 - nicht mehr und nicht weniger. Es kann nicht mehr und es kann nicht weniger. Period. XHTML 1.1 ist eine modularisierter Form von XHTML 1.0 Strict mit einigen winzigen Änderungen die das W3C in ein paar Zeilen fasst. Sämtliche Modulkomponenten wie etwa SVG oder MathML sind eigenständige XML-Dialekte die mit XHTML bzw. HTML selbst nichts zu tun haben.
XHTML5 hingegen ist eine Serialisierung von HTML5 - es ist exakt dasselbe, ebenfalls nichts besonders.
  • "XML wurde ursprünglich zur Definition und zum Austausch von Daten definiert "
    • Nein, XML wurde als Beschreibungssprache für Daten konzipiert - ob man damit Daten austauscht oder nur einseitig überträgt ist nicht relevant - dafür steht das "M" in XML.
  • "Anders als HTML hat XML deswegen keine Elemente, die die Präsentation der Daten auf dem Bildschirm betreffen." sowie "Auf diese Weise unterstützt XML die im Software Design empfohlene Trennung von Inhalt und Präsentation: [...]"
    • Das ist unsinn, XHTML 1.0 ist dasselbe wie HTML 4.01 - und zwar bis ins kleinste Detail
  • "Im Hinblick auf die geänderte Definitionssprache erscheinen die Unterschiede zwischen HTML und XHTML tiefgreifender als sie sind.
    • Sie unterscheiden sich syntaktisch nicht voneinander - XHTML 1.0 ist formal gültiges SGML, genau darum kann es auch von einem Tagsoup-Parser als HTML verarbeitet werden.
  • "Zudem werden eine Reihe von alten HTML Tags jetzt nicht mehr benutzt - z.B. das FONT Tag."
    • Das ist schlichtweg falsch.
Der Rest ist übrigens auch Unsinn - ich will aber jetzt nicht jeden einzelnen Satz zerlegen, dafür fehlt mir die Zeit.
Zusammenfassend: Ich bitte dich, künftige Änderungen vorher auf der Diskussionsseite abzusprechen. Dir fehlt offenbar der nötige Fachverstand für Änderungen bei diesem Thema.
Sollte die bluehorse.ro-Seite von dir stammen. Sei so nett und nimm sie vom Netz. Das Tutorial ist (ich hab' es nur grob überflogen) stellenweise gemeingefährlich. Der Autor kennt den Unterschied zwischen Tags und Elementen nicht. Ebenso empfiehlt der Autor für Einsteiger die Verwendung von XHTML 1.1 - das ist ein GANZ böser Fehler den ich jetzt nicht näher erläutern möchte (Zeitmangel). Weiters wird behauptet, im body würde alles notiert, was im Browserfenster erscheint - auch das ist falsch. Ein simples head { display: block; } und body { display: none; } in einem ordentlichen Browser dreht die Sachlage ins Gegenteil. Weiters wird empfohlen, dass man mit   zusätzliche Leerzeichen erzwingt - für so eine Aussage wird man von jedem Typographen mit dem nassen Fetzen erschlagen. Es wird zur Verwendung von benannten Zeichenreferenzen geraten obwohl diese unter Angabe der korrekten Zeichenkodierung nicht notwendigt sind. Die Seiten des Tutorials sind zudem nicht valide - mit drakonischer Fehlerbehandlung, die unter XHTML 1.1 zwingend erforderlich wäre, weil es gemäß den Regeln als XML verarbeitet werden muss, würde die Seite garnicht dargestellt werden.
Jede einzelne Seite dieses Tutorials enthält _massive_ fachliche Fehler - wenn das Tutorial also von dir stammt, bitte ich dich erneut _inständig_ dich möglichst aus Änderungen an Artikeln zu diesem Thema rauszuhalten, da das dafür nötige Wissen ganz einfach fehlt. --suit 00:14, 31. Jan. 2011 (CET)

"Ajax" Absatz im Abschnitt "Zusatztechniken und Weiterentwicklungen"

Ajax beruht technologisch auf JavaScript. JavaScript hat eine gewisse Beziehung zu HTML, weil es die Basis fuer Client Side Scripting ist. Insofern hat auch Ajax eine entfernte Beziehung zu HTML. Wenn man nun aber alle Technologien aufnehmen will, die irgendwie eine entfernte Beziehung zu HTML haben, kommt eine ganz erhebliche Liste zusammen. Deswegen sollte der Absatz mit Ajax entweder komplett geloescht werden oder mit dem Absatz ueber dynamisches HTML zusammengefuehrt werden. Ich bin mir auch nicht sicher, ob der Titel "Dynamisches HTML" gluecklich gewaehlt ist. Inzwischen sprich man seltener von "Dynamischen HTML". Einer der Gruende dafuer mag sein, dass JavaScrit eigentlich wenig mit HTML zu tun hat. Es braucht natuerlich eine Moeglichkeit, um JavaScript in HTML einzubinden. HTML selbst ist aber statisch - und das script Tag ist nichts als eine Bruecke um JavaScript irgendwie aktivieren zu koennen. Haeufiger sagt man "Client Side Scripting" oder "Dynamische Webseiten". ("Dynamische Webseite" koennte aber mit "Server Side Scripting" verwechselt werden).(-- Truswalu 10:39, 30. Jan. 2011 (CET))

"Technologisch auf JavaScript" beruhen auch Techniken wie JSONP oder Comet die mittlerweile Ajax teilweise den Rang ablaufen, weil die same-origin Policy nicht im Weg ist.
Es ist daher sicher sinnvoll, die Zusatztechniken auf die Kernthemen zusammenzustreichen: CSS und JavaScript.
Dynamisches HTML ist eine fürchterlich schlechte Bezeichnung und hat zu viele Altlast-Begrifflichkeiten aus der Zeit des ersten Browserkrieges anhaften und keiner weiß eigentlich so genau was es ist. Manchmal ist damit die layer-Sache aus der Netscape-Zeit gemeint, manchmal werden die proprietären "CSS"-Filter des Internet Explorers darin eingereiht. Heutzutage spricht man eher von DOM-Manipulation mit JavaScript und nicht mehr von dynamischem HTML oder gar DHTML. Einige geschichten wie Animation usw können mittlerweile mit CSS erledigt werden ohne JavaScript anzuwerfen. Im Artikel gehts primär um HTML und nicht darum, was man denn nicht alles tolles im Web-Bereich machen kann.
Wie gesagt: raus damit.
Fürs Protokoll: es heisst nicht script-Tag sondern script-Element. --suit 23:52, 30. Jan. 2011 (CET)

Revert vom 27.12. / HTML = DTD

Ich halte es für falsch, dass HTML = DTD ist.

-- Matthias 13:36, 27. Dez. 2011 (CET) --

das kann man unterstreichen - besonders für HTML5 gilt: es ist nichtmal mehr ein SGML-Dialekt und eine DTD gibt es erst recht nicht -- suit 11:58, 28. Dez. 2011 (CET)

Dokumentenart

1. Abschnitt: "Strukturierung von Inhalten wie Texten, Bildern und Hyperlinks in Dokumenten"

Dokumente müsste Verbunddokumente heißen mit verlinkung auf den Artikel Verbunddokumente -- 217.85.15.1 02:51, 4. Mär. 2012 (CET)

Inhalt, Struktur, Layout, Präsentation

Die Formulierung "Trennung von Inhalt und Layout" ist imho unpräzise und nicht mehr zeitgemäß:

1. 'Inhalt' umfasst nach BITV 2.0 zwar auch das Markup, aber ich finde es präziser, wenn man die Struktur hervorhebt. Artikel dazu: http://toscho.de/2009/trennung-inhalt-layout/

2. In der BITV 2.0 ist der Begriff Layout durch Präsentation ersetzt worden, um auch visuelle und Audio-Ausgaben mit zu erfassen. --Andreas Lippold (Diskussion) 10:51, 9. Nov. 2012 (CET)

HTML5 Datum

Es gibt von HTML5 ein neueres Datum

http://www.w3.org/TR/html5/ W3C Candidate Recommendation 17 December 2012


HTML5 (Working Draft,[10] 23. April 2009) kann damit aktualisiert werden (nicht signierter Beitrag von 212.185.176.178 (Diskussion) 13:23, 15. Mär. 2013 (CET))

HTML- und XHTML-Elemente Referenz mit Beispielen Online

Auf der Seite hier: http://www.data2type.de/xml-xslt-xslfo/html-und-xhtml/alphabetische-liste-der-elemente/ wurde eine komplette Referenz mit Beispielen online gestellt. Würde gut zu Weblinks passen. (nicht signierter Beitrag von 217.88.193.50 (Diskussion) 16:33, 22. Apr. 2014 (CEST))

"Versionen" - Verständlichkeit

HTML 3.0: Die Version erscheint nicht, weil sie mit der Einführung des Netscape-Browsers in der 
Version 3 bereits vor der Veröffentlichung veraltet ist.

Dieser Satz ist nicht verständlich. Was hat Netscape Version 3 damit zu tun? --StYxXx 04:58, 6. Aug. 2014 (CEST)

In der englischen Version des Artikels wird das ausführlicher erläutert, aber mit dem entscheidenden Unterschied, dass da auch andere Browser und ganz besonders der Internet Explorer eine Rolle spielten. Tatsächlich begann zu der Zeit gerade der erste Browserkrieg, und gerade Netscape und Microsoft haben sich da in relativ rasantem Tempo gegenseitig mit Features und eben HTML-Erweiterungen überboten. Da kam das behäbige W3C einfach nicht mehr hinterher mit der Spezifikation, und der Entwurf zu HTML 3.0 war schon bald weit hinter dem zurück was die Browser tatsächlich schon konnten. --YMS (Diskussion) 10:06, 6. Aug. 2014 (CEST)

Version - HTML5

Laut Kommentar in der Infobox ist "HTML5 keine eigene Version, sondern eine eigene Sprache". Das W3C hat jedoch am 28.10.2014 HTML5 als Recommendation herausgegeben.

Die englische Wikipedia führt als Version von HTML ebenfalls 5.0 an. (nicht signierter Beitrag von Julianpollmann (Diskussion | Beiträge) 20:25, 28. Okt. 2014 (CET))

Das W3C sieht HTML5 als eigene Version von HTML (z.B. gibt es hier einen „Editor's Draft“ für HTML5.1), die WHATWG hingegen sieht HTML5 als „lebenden Standard“ und hat eine Versionierung aufgegeben: http://www.golem.de/news/w3c-html5-offiziell-fertiggestellt-1410-110177.html --Phantomias308 (Diskussion) 12:38, 31. Okt. 2014 (CET)

Uebersicht

Um Verdacht des Interessenskonflikts zu umgehen, hier: Es ist vielleicht hilfreich, auf alle HTML-Elemente zu verweisen oder diese vorzustellen. Ein vollstaendiger Ueberblick ist auf meiert.com zu finden (der naechstvollstaendige, ohne HTML 1 und auch auf ersterem basierend, auf GitHub). Nur als Idee, da ich aus Erfahrung weiss, dass solche Uebersichten dem Verstaendnis sehr nuetzen koennen. – j9t (Diskussion) 13:54, 24. Jan. 2015 (CET)

Sprachtyp

"HTML ist eine Auszeichnungssprache und wird als solche auch nicht programmiert, sondern schlicht geschrieben."

Dieser Satz ist meiner Meinung nach nicht ganz korrekt. Keine Programmiersprache wird programmiert, man programmiert "mit" oder "in" einer Sprache. Alle Programmiersprachen werden "schlicht" geschrieben. Ob und in wie fern mit einer Sprache programmiert wird hängt lediglich vom Gerät ab das programmiert wird. --Holger Wil (Diskussion) 11:39, 13. Okt. 2016 (CEST)

(HTML #Sprachtyp ist auch der fragliche Abschnitt)
Inhaltlich ist die Aussage erstmal okay.
Sprachlich ist es in der Tat nachbesserungsbedürtig.
Wie würdest du es denn gleichwohl laienverständlcih formulieren?
Ich würde das erstmal in zwei Sätze spalten; ungefähr so:
HTML ist eine Auszeichnungssprache.
Wie bei allen diesen Sprachen wird nicht in ihr programmiert, sondern ein (vorhandener) Text wird in bestimmten Teilen mit Eigenschaften versehen.
LG --PerfektesChaos 12:28, 13. Okt. 2016 (CEST)
Ich denke nicht, dass die Aussage Inhaltlich korrekt ist. Ob in einer Sprache programmiert wird,
oder programmiert werden kann hängt nur davon ab ob es ein Gerät (möglicherweise auch virtuell) gibt das mit dieser Sprache programmiert werden kann.
Klar ist, das HTML eine Auszeichnungssprache ist. Ob Auszeichnungssprachen zu den Programmiersprachen zählen oder nicht, ist selbst unter Experten stark umstritten.
https://www.youtube.com/watch?v=4A2mWqLUpzw
http://stackoverflow.com/questions/145176/is-html-considered-a-programming-language
Ich denke, dass eine solche Klassifizierung, sofern sie nicht eindeutig ist, nicht in den Artikel gehört.
Ich bin ein Vertreter der These, dass es sich bei HTML sehr wohl um eine Programmiersprache handelt.
Ich denke, dass die Zuordnung ganz weggelassen werden sollte. Alternativ könnte man auf die Kontroverse hinweisen, und Argumente für beide Seiten anführen.
--Holger Wil (Diskussion) 13:41, 13. Okt. 2016 (CEST)
gudn tach Holger Wil, PerfektesChaos, user:H7!
ich bin auch gerade ueber diesen kleinen absatz gestossen und stimme unter anderem der kritik zu, die PerfektesChaos aeussert.
zu der kritik von Holger Wil: es gibt einen abschnitt ueber die angesprochene kontroverse, und zwar Auszeichnungssprache#Äußere Systematik: Einordnung als Programmiersprache oder Datenformat. darauf sollte man meiner ansicht nach nur verweisen und dafuer hier im artikel das thema nicht so sehr auswalzen.
mittlerweile wurde noch etwas ergaenzt, das zusammengenommen nun den anschein erweckt, als wuerden source-codes von programmiersprachen nicht mit jedem beliebigen texteditor editiert werden koennen. tatsaechlich gilt das jedoch nur fuer ausnahmesprachen, z.b. einige graphische programmiersprachen. die source-codes der meisten grossen bekannten programmiersprachen sind dagegen plaintext.
deshalb schlage ich einer ueberarbeitung des kompletten absatzes vor:
HTML ist eine Auszeichnungssprache und wird als solche meist von Programmiersprachen abgegrenzt (siehe dazu Abschnitt Äußere Systematik: Einordnung als Programmiersprache oder Datenformat im Artikel über Auszeichnungssprachen). Wie auch bei den meisten Programmiersprachen ist für die Bearbeitung der Quelldokumente keine spezielle Software (siehe auch Liste von HTML-Editoren) nötig, sondern es reicht ein beliebiger Texteditor.
Ein ähnliches Konzept (logische Beschreibung) wie hinter HTML steht hinter dem Satzsystem TeX/LaTeX, das im Unterschied zu HTML jedoch auf die Ausgabe per Drucker auf Papier zielt.
was meint ihr? -- seth 12:54, 23. Apr. 2017 (CEST)
Solange niemandem etwas noch besseres einfällt, würde ich diese Formulierung zu 100 % unterstützen. Also, von mir aus OK! --H7 (Diskussion) 13:03, 23. Apr. 2017 (CEST)
Komme grad etwas aus dem Mustopf.
Der Textvorschalg ist einwandfrei und auf jeden Fall eine Verbesserung.
Um die Verwirrung noch zu vergrößern:
  • Jedes Programm ist eine Datei (nämlich ihr Quellcode wie auch die maschinennäheren Übersetzungsstufen).
  • Alle (formal angeordneten) Daten lassen sich als ein Programm in einer willkürlichen Sprache auffassen (nämlich der jeweiligen formalen Sprache, notfalls der puren Zeichenfolge). Jeder Text programmiert die akustische Ausgabe eines Screenreaders.
  • Heißt: Es ist ein uralter Streit, der niemals endgültig zu entscheiden ist, weil immer eine Doppelnatur vorliegt.
  • Bloß spricht man vom „Programmieren“ nur, wenn prozedurale Aspekte wesentlich sind.
  • JSON ist in der Programmiersprache JavaScript notiert, aber nicht ausführbar, tatsächlich ein Datenformat. So what?
LG --PerfektesChaos 13:24, 23. Apr. 2017 (CEST)
gudn tach!
ok, hab jetzt erstmal meine umformulierung umgesetzt. weiteren verbesserungen steht ja die tuer offen.
zu den punkten von PerfektesChaos kann ich vielleicht noch etwas mehr verwirrung beitragen: json ist ein daten(austausch)format, aber gewollt auch als javascript-code interpretierbar. laut wikipedia ist json null deklarativ und kann somit weniger als die auszeichnungssprache xml. und dennoch lassen sich xml und json verlustfrei ineinander konvertieren. xml braucht eigentlich nicht mal einen computer und ist somit keine programmiersprache. die grafische programmiersprache scratch speichert seit version 2 ihre programme als *trommelwirbel* (zip-komprimierten) xml-files ab. da sind die xml-files also programme, wenn auch nicht standalone ausfuehrbar. somit ist es moeglich, in xml zu programmieren. -- seth 16:10, 23. Apr. 2017 (CEST)

Den mittleren Satz würde ich noch umformulieren und kürzen: „Für die Bearbeitung der Quelldokumente ist keine spezielle Software (siehe auch Liste von HTML-Editoren) nötig und es reicht ein beliebiger Texteditor.“ Es klingt nämlich komisch, wenn HTML im Satz davor ausdrücklich von Programmiersprachen abgegrenzt wird, danach aber die Quelltextbearbeitung gleichgesetzt wird. --net (Diskussion) 16:55, 23. Apr. 2017 (CEST)

gudn tach!
nee, wenn man das tun wuerde, dann klaenge es so, als waere das bei programmiersprachen nicht der fall. das ist ja gerade ein grund fuer die aenderung gewesen. eine abgrenzung zu programmiersprachen kann kaum in aller kuerze erfolgen, deswegen wird auf den anderen artikel verwiesen. ich formuliere es mal so um, dass klar ist, dass es um eine gemeinsamkeit geht. -- seth 13:35, 24. Apr. 2017 (CEST)
Den Rückschluss, dass man bei Programmiersprachen nicht auch einen Texteditor nehmen könnte, kann ich so nicht nachvollziehen. Mir sind das einfach zu viele unnötige Information, die gar nichts mit HTML zu tun haben und das verwirrt Leser eher. Auch der nachfolgende Satz mit TeX/LaTeX bringt dem Leser keinen Informationsgewinn. Wer TeX/LaTeX nicht kennt, der kann damit auch nichts anfangen und wer es kennt, weiß auch um die Grundlagen von HTML. Deine letzte Änderung ist aber zumindest eine Verbesserung und macht die Sache klarer. --net (Diskussion) 14:10, 24. Apr. 2017 (CEST)
Hallo,
Ich habe nicht wirklich eine Idee wie man das besser formulieren kann, aber bitte nochmals darum, das Video, dass ich weiter oben verlinkt habe anzuschauen. (vielleicht könnte man das irgendwo verlinken, z.B. "Die Einordnung von HTML wird kontrovers diskutiert [video]".
Prof. Brailsford erklärt es so: HTML kann als deklarative funktionale Hochsprache beschreiben werden. Schreibe ich ein <b> tag, mache ich nichts weiter als einen Funktionsaufruf, der in einer anderen Syntax vielleicht so aussähe: printBold("something"). Wenn ich z.B. in Node.js eine C-Bibliothek nutze, interessieren mich die Implementierungsdetails auch nicht, ich rufe nur Funktionen auf.
Ich habe mir mal die Mühe gemacht, und eine Taschenrechner in reinem HTML "programmiert" (https://cdn.rawgit.com/Holger-Will/htmlcalc/master/htmlcalc.html). Kurz gesagt: Wenn ich einem Computer sagen kann "Wenn diese, dann das" dann ist das ein Programm. In dem Taschnerechner nutze ich Hyperlinks als Input und Flowcontroll. Donals Knuth hat mal gesagt "Write dumb code, but clever data structures". Datenstrukturen sind wichtiger Bestandteil der Programmierung, nicht nur die Algorithmen. Und als Auszeichnungsprache ist HTML eine Sprache die eben auch zur Datenstrukturierung und begrenzt zur Programmierung benutzt werden kann.
Mit der Standardisierung von HTML-Imports, wird dieser Punkt noch wichtiger, da ich mit HTLM-Imports ganze funktionale Bibliotheken importieren und nutzen kann.
Ähnlich wie bei dem Beispiel oben mit Node.js und C interessiet ja nicht in welcher Sprache die Tags implementiert sind, sonder das ich die so implementierten Funktionen aufrufen kann um in HTML zu programmieren.
IMHO ist mit der Einführung von HTML-Imports die ganze Einordnung von HTML wie hier im Artikel hinfällig, denn dadurch ist HTML "turing-complete"...

--Holger Wil (Diskussion) 06:24, 28. Apr. 2017 (CEST)


Hallo seth, PerfektesChaos, user:H7

Sorry, dass ich das Thema nochmal aufgreife.

IMHO ist hier der gesamte Artikel mittlerweile veraltet.

Aus der Einleitung: "HTML dient als Auszeichnungssprache dazu, einen Text semantisch zu strukturieren"

Diese Darstellung widerspricht der aktuell gültigen html Spezifikation https://www.w3.org/TR/html5/introduction.html#introduction . Dort heißt es:

"The World Wide Web's markup language has always been HTML. HTML was primarily designed as a language for semantically describing scientific documents, although its general design and adaptations over the years have enabled it to be used to describe a number of other types of documents.
The main area that has not been adequately addressed by HTML is a vague subject referred to as Web Applications. This specification attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years."

historisch war HTML eine Auszeichnungsprache um Text semantisch zu strukturieren. Heute sind jedoch weitere Aufgaben hinzu gekommen. HTML wird heute immer mehr auch zur Entwicklung von "Web Anwendungen" genutzt. die aktuelle Spezifikation trägt dem Rechnung.

Denn was ist eigentlich mit dem DOM? Die DOM Spezifikation ist Teil von HTML und gehört definitiv nicht zur Javascript Spezifikation! Und Hier geht es nur um prozeduralen Code.

auch in den letzten Absätzen unter Syntax gibt es einige Unzulänglichkeiten.

Es geht in HTML um beschreibende (englisch descriptive), nicht um verfahrens- (englisch procedural) und darstellungsorientierte (englisch presentational) Textauszeichnung...

Der Author geht im folgenden nur auf die Trennung von Beschreibung und Darstellung ein. Über die verfahrensorientiert Trennung verliert er kein Wort. Aber genau hier wäre es wichtig um eine deutliche Abgrenzung zu Programmiersprachen auf zu zeigen. Und genau diese Trennung gibt es imho eben überhaupt nicht mehr.

HTML unterstütz eine ganze Reihe verfahrensorientierter Auszeichnungen(!). Angefangen bei Hyperlinks und Anchors über Formulare (das form Element hat ein action attribute. wenn das keine prozedurale Anweisung, was denn dann?) bis hin zu Custom Elements. Hieran erkennt man, das prozeduraler Code und Auszeichnung sich nicht widersprechen.

siehe auch

https://www.w3.org/TR/html5/dom.html#interactive-content

Certain elements in HTML have an activation behavior, which means that the user can activate them

https://www.w3.org/TR/html5/editing.html#the-accesskey-attribute

Accesskeys gehen weit über reine Semantik hinaus. Hier geht es um reine Funktionsanweisungen.

Damit kann programmiert(!) werden was passiert, wenn der Nutzer eine bestimmte Taste drückt.

Wenn ich eine programmierbare(!) Fernbedienung programmiere(1) mache ich nichts anderes, als einem Knopf eine Funktion zuzuweisen. Niemand würde jemals behaupten, dass es sich hierbei lediglich um eine sematische Auszeichnung handelt...

https://www.w3.org/TR/html5/dom.html#script-supporting-elements

HTML5 ist eine vollwertige Programmiersprache. Nicht abstarkt, oder philosophisch betrachtet, sondern als solche entwickelt, und praktisch genutzt.

Ein Beispiel das ich oben bereits erwähnt habe sind Custom Elements. Dieses Feature ermöglicht es HTML-Elemente mit beliebiger Funktionalität zu implementieren und zu nutzen. Ich versuche es nochmal mit einer weiteren Analogie:

Wenn ich ein Bash Script schreibe, wird niemand bezweifeln, dass es sich hierbei um Programmieren handelt. Dabei rufe ich Programme auf, die ihrerseits in z.B. C geschrieben sind. Niemand würde jedoch behaupten wenn ich ein Bash Script schreibe, dass ich in C programmiere.

Doch genau so verhält es sich mit HTML und Custom Elements. Wenn ich eine Funktionsbibliothek in JS schreibe, und diese als Custom Elements zur Verfügung stelle, kann jeder diese Bibliothek zum Programmieren in HTML nutzen, ohne dass derjenige Javascript Kenntnisse benötig. Er programmiert dann in reinem HTML. Hier ist ein Prove of Concept das die Sache verdeutlicht. https://rawgit.com/Holger-Will/html-custom-elements/master/prog.html

  • Der Einleitungsatz „Text semantisch zu strukturieren“ ist nach wie vor relevant.
    • Er ist zeitlos elegant und beschreibt immer noch den Kern der Angelegenheit.
    • Wenn du dir anguckst, welche Syntaxelemente mit HTML5 alles neu hinzugekommen waren, dann wirst du sehen, dass zurzeit in HTML der Trend ist, die semantische Strukturierung immer weiter auszubuen.
    • Diese Schwerpunktsetzung mag sich zukünftig mal wieder ändern; weiter verschärft oder wieder relaxed werden. Das Gegenstück zur semantischen Fokussierung ist die typografische Unterstützung. Mit HTML4, den Diskussionen im Jahrzehnt dazwischen und HTML5 ist ein gewisser Schlingerkurs feststellbar, bis hin zur kompletten Pirouette. Momentan gibt es eine seit langer Zeit starke Strömung, die Dekoration (Typografie) komplett an CSS zu delegieren; dafür kommt XML vielleicht mal wieder in Mode.
  • Der Gegensatz, den du da zwischen ursprünglich scientific und jetzt irgendwie Web Applications aufmachst, ist keiner.
    • Es haben sich lediglich die Inhalte ausgeweitet; semantische Strukturierung eines Textes ist es nach wie vor.
  • Die ursprüngliche Zielgruppe, also 1992, 1995, bis 1998, waren Wissenschaftler gewesen, die mit ein klein wenig Markup (Überschrift, Fett- und Kursivschrift, Exponenten) plattformunabhängig austauschbare und an Netz-Endgeräten darstellbare Texte haben wollten; plus Softwareleute, die für ihre manpages Tastatureingabe, Kommandozeilen und Antwortzeilen auf dem Bildschirm beschreiben wollten.
    • Logisch, dass sich das im neuen Jahrtausend inflationär ausgeweitet hatte.
    • Bildeinbindungen, Hyperlinks (absolutes Kernthema der Webseiten) und bald Applets mit Java hatte es aber schon in der Anfangszeit gegeben.
  • Deine Argumentation, HTML sei früher eine Textdarstellungssprache gewesen und wäre nunmehr eine Programmiersprache für Web-Applikationen, oder worauf immer du abzielen möchtest, greift deshalb nicht.
    • Es liegt in den technischen Möglichkeiten des Endgerätes, die im Text hinterlegten Hinweise auf dynamische Effekte im Zusammenwirken mit den Aktivitäten des Benutzers umzusetzen.
    • Die „Möglichkeiten“ kann die URL einer anderen Seite sein, auf die verlinkt wird; die URL einer Grafikdatei, die dargestellt werden soll, die URL von Audio/Video, das abgespielt werden soll, oder ein interaktives Formular, das editorisch bearbeitet (navigiert, ausgefüllt) werden kann.
    • Aktivitäten der Benutzer sind Tastendrücke, Mausbewegungen, Mausklicks oder sonst was.
    • HTML ist dessen ungeachtet immer noch nur ein Text, in den diese Angebote eingebettet sind.
    • HTML selbst programmiert nichts; es gibt Hinweise, wie das darstellende Programm bestimmte mitgelieferte Informationen für interaktive Effekte ausnutzen kann; oder auch nicht. Es beschreibt nur, wie ein Formular aussehen und ggf. reagieren würde.
  • Zitat: „Wenn ich eine Funktionsbibliothek in JS schreibe“ – dann schreibst (von mir aus: programmierst) du in JavaScript.
    • Du schreibst (programmierst) nicht in HTML.
    • Das hast du mit der zitierten Stelle mit deinen eigenen Worten nunmehr selbst festgestellt.
    • In HTML machst du nur ein Angebot, diese Sequenz in JavaScript-Code verfügbar zu machen; wenn es dem Anwender gefällt und wenn das JavaScript keine verbotenen Sachen anstellt, dann wird das ausgeführt – oder auch nicht. Wohlgemerkt: der JavaScript-Code wird ausgeführt.
    • bash ist eine üblicherweise in C geschriebene Interpretersprache, die ihrerseits Executables im Betriebssystem (deren Quelltext in C oder sonstwie geschrieben sein mag) unbedingt ausführt.
VG --PerfektesChaos 10:37, 2. Jun. 2017 (CEST)

Anzahl der Bereiche eines HTML-Dokuments

Im Abschnitt "Bereiche" steht, dass ein HTML-Dokument aus drei Bereichen besteht. Hier steht etwas von einem "Stammelement", wobei z.B. die Sprache des HTML-Dokuments angegeben wird, z.B.: lang="de". Hier wird das als Sprachkürzel bezeichnet.
Ist das Stammelement / Sprachkürzel überflüssig (weil vielleicht veraltet) oder müsste man nicht von insgesamt 4 und nicht nur von 3 Bereichen sprechen? --217.224.3.116 13:33, 24. Jul. 2017 (CEST)

die Angaben zur verwendeten Sprache steht im lang-Attribut, das dem html-Element mitgegeben werden sollte, aber auch bei jedem anderen Element stehen kann (wenn z.B. ein Absatz in einer anderen Sprache ist). Das hat also mit den 3 Bereichen nichts zu tun. --Fritzbruno (Diskussion) 16:08, 24. Jul. 2017 (CEST)
Ok, verstanden. Das Language-Attribut war nur ein Beispiel und ist ja auch nicht zwingend notwendig. Dennoch bin ich der Meinung, dass ein HTML-Dokument entweder aus 2 Bereichen (doctype und html mit den 2 inneren Bereichen head und body) besteht oder aus 4 (doctype, html, head und body).--Exilsaarländer (Diskussion) 12:13, 25. Jul. 2017 (CEST)
HTML-Bereiche
Das wird leicht haarspaltend.
Ja, es sind im obersten Level zwei Bereiche (vollständiges konformes Dokument unterstellt):
  • Dokument
    1. DOCTYPE
    2. <html>
      1. <head>
      2. <body>
Bringt jetzt was? --PerfektesChaos 12:20, 25. Jul. 2017 (CEST)
Moment mal: Ich versuche hier Klarheit und Eindeutigkeit herzustellen und Widersprüche zwischen erstzunehmenden Quellen (A vs. B) auszuräumen oder wenigstens zu verstehen. Das ist nicht ha(a)rspaltend, sondern zielt auf QS. Vlt. kann ein Experte (ich bin HTML-Anfänger) in diesem Sinne den Abschnitt überarbeiten. Das bringt mindestens eine Qualitätsverbesserung, denn immhin erheben ja einige Wikipedianer den Anspruch, in der Brockhaus- und BE-Liga mitzuspielen. --Exilsaarländer (Diskussion) 13:23, 25. Jul. 2017 (CEST)
Das Missverständnis rührt von einer zu scharfen Interpretation des Textes her.
Er lautet derzeit: „Ein HTML-Dokument besteht aus drei Bereichen“.
  • Das sagt, dass es im HTML-Dokument drei Bereiche gibt.
  • Ein Haus besteht aus Fundament bzw. Keller, Etagen und einem Dach.
  • Ein Auto besteht aus Fahrgestell, Fahrgastzelle, Laderaum und Motorraum.
Das sagt nicht, dass es daneben nicht auch noch andere Komponenten geben kann; es mag einen Schornstein geben, und Veranda oder Wintergarten mögen mit bei sein; auf dem Autodach mag ein Dachgepäckträger sein, und die Feuerwehr hat Leitern oben. In welchen internen Beziehungen Fahrgestell einerseits und die Aufbauten dazu stehen mögen, ist überhaupt nicht thematisiert.
Das sagt also nicht: Ein HTML-Dokument ist hierarchisch gegliedert in zwei Komponenten, <DOCTYPE> und <html> – letzteres ist wiederum gegliedert in zwei Komponenten, <head> und <body>.
Es meint nur, dass es bei HTML-Dokumenten drei besonders interessante/wichtige/fundamentale Bereiche gibt, sagt aber nichts über irgendwelche hierarchischen Beziehungen aus.
VG --PerfektesChaos 14:56, 25. Jul. 2017 (CEST)
Die Aufzählung zu den Bestandteilen eines HTML-Dokuments im Artikeltext ist abschließend, d.h., es kann daneben nicht noch andere Komponenten geben. Da gibt es kein Missverständnis und nichts zu interpretieren. Wie man auch zählt, es kommt nie die Zahl 3 dabei raus. Da helfen auch holprige Erklärungsversuche nichts.
Am Artikel, wie an WP im Allgemeinen hängt bei mir kein Herzblut. Daher ist es mir ist es langsam wurscht, ob der Text so bleibt oder richtig gestellt wird. --Exilsaarländer (Diskussion) 22:13, 25. Jul. 2017 (CEST)