Standart bei Web-Sprachen?

Mister Knister

Mister Knister

Aktives Mitglied
Thread Starter
Dabei seit
27.04.2005
Beiträge
570
Reaktionspunkte
2
Hi MacUser !

Wenn ich im Internet eine Seite finde die mir gefällt schaue ich auch sofort immer in den Quelltext um den Editor herauszufinden. Auch die Sprache in der die Seite geschrieben ist interessiert mich. Doch welche der Sprachen ist eurer Meinung inzwischen Standart? XML, xHTML, ....
Ich kann selbst nur HTML und möchte trotzdem up to date bleiben und deswegen würde ich gern wissen was ich lernen soll.
Und auch welche Editoren welche Sprache schreiben.

Gruß Mister knister
 
Ich glaube "Standard" hat sich längst als Standard etabliert ...
 
Für Webseiten dürte, mit Blick auf Technologien wie AJAX, XML resp. XHTML
die Zukunft darstellen. "Einfaches" HTML mag für die eine oder andere Seite
noch reichen, wird aber mangels Fähigkeiten selbiger immer weniger eingesetzt.

Siehe dazu: http://www.exine.de/xml/xml_einfuehrung_1.htm
 
Zuletzt bearbeitet von einem Moderator:
Würde ich auch sagen. Neue Projekte versuche ich wenn möglich immer mit xHTML umzusetzen. Wobei sich xHTML und HTML vom Aufbau her sehr ähnlich sind.
 
sikomat schrieb:
Für Webseiten dürte, mit Blick auf Technologien wie AJAX, XML resp. XHTML die Zukunft darstellen

Für den Einsatz von AJAX ist es unerheblich, ob das zugrundeliegende Markup XHTML oder HTML ist. XML hat damit gar nichts zu tun, außer das XHTML mittels XML definiert wird, was wiederum eine Teilmenge von SGML ist, mit dem HTML definiert wurde.

"Einfaches" HTML mag für die eine oder andere Seite
noch reichen, wird aber mangels Fähigkeiten selbiger immer weniger eingesetzt.

Welche Fähigkeiten hat XHTML 1.1, die HTML 4.01 nicht hat? Und was ist "einfaches" HTML?

Zur eigentlichen Frage: Es gibt unzählige Abhandlungen darüber, ob man sich seine Seiten eher in HTML oder XHTML erstellen sollte. Diese beziehen sich vornehmlich darauf, das XHTML-Dokumente in 99,9% der Fälle eben nicht als solche (nämlich mit dem MIME-Type application/xhtml+xml), sondern als text/html ausgeliefert werden. Die Meinungen gehen stark auseinander, allerdings ist das ganze eine extrem theoretische Denkweise. Vom praktischen Ansatz her lohnt es sich schon heute, Dokumente XHTML-konform zu schreiben, da dadurch der Aufwand für zukünftige Anpassungen stark minimiert wird. Allerdings ist es dafür auch unerläßlich, validierenden Code zu schreiben.

Von daher: Finger weg von WYSIWYMG-Editoren, die produzieren (fast) alle Code, der nur mit erheblichem zusätzlichem Aufwand vernünftig verwandbar ist. Jeder Texteditor ist besser geeignet, SubEthaEdit z.B. kann alle Sprachen. :D

Matt
 
HTML schreib ich auch ohne WYSIWYG-Editoren, Quelltext ! Aber ich werde demnächst auf Mac umsteigen und die Frage ist ob es dort editoren die zumindest einigermaßen richtigen code schreiben, ausbessern kann ich ja immer noch.
 
Mister Knister schrieb:
HTML schreib ich auch ohne WYSIWYG-Editoren, Quelltext ! Aber ich werde demnächst auf Mac umsteigen und die Frage ist ob es dort editoren die zumindest einigermaßen richtigen code schreiben, ausbessern kann ich ja immer noch.
ich habe gute erfahrungen mit Dreamweaver von Macromedia gemacht...
ich verwende meist den Editor modus... wenn ich jedoch komplexe tabellen oder verschachtelte layouts umsetze, schalte ich meistens in den vorschau modus. dann hab ich das ergebnis immer vor augen... ich finde das komfortabler als einen reinen texteditor... kostet aber dementsprechend auch sein geld...
 
Wie siehts mit RapidViewer aus, ich denke zwischen dem und Dreamweaver wird es sich entscheiden
 
Mister Knister schrieb:
Wie siehts mit RapidViewer aus, ich denke zwischen dem und Dreamweaver wird es sich entscheiden

Ich vermute, Du meinst »Rapidweaver«. Du vergleichst hier zwei Anwendungen, die nur eine gemeinsame Zielgruppe haben, aber grundsätzlich so verschieden sind wie Sonne und Mond, OS X und Windows XP, sikomat und HAL oder gar Äpfel und Birnen. Nur, um einige Beispiele zu nennen...

Schau Dir beide Dinge doch einmal genauer an.
RapidWeaver
DreamWeaver
 
at msslovi0:

Zur eigentlichen Frage: Es gibt unzählige Abhandlungen darüber, ob man sich seine Seiten eher in HTML oder XHTML erstellen sollte. Diese beziehen sich vornehmlich darauf, das XHTML-Dokumente in 99,9% der Fälle eben nicht als solche (nämlich mit dem MIME-Type application/xhtml+xml), sondern als text/html ausgeliefert werden. Die Meinungen gehen stark auseinander, allerdings ist das ganze eine extrem theoretische Denkweise. Vom praktischen Ansatz her lohnt es sich schon heute, Dokumente XHTML-konform zu schreiben, da dadurch der Aufwand für zukünftige Anpassungen stark minimiert wird. Allerdings ist es dafür auch unerläßlich, validierenden Code zu schreiben.

Es ist das Gegenteil von "extrem theoretischen Denkweisen" - es geht um die Richtigkeit der Praxis und die Unterschiede zwischen Theorie und Praxis.

Wenn es also mal in der Praxis theoretisch wird, dann nur weil es darum geht einen best-practices-Ansatz zu bekommen.

Schreibt mal also tollen validen XHTML-Code und liefert diesen dann als Text/HTML aus, dann ist dies eben kein valider Code mehr sondern code-soup!

Der Hintergrund dazu ist dass der UA (=UserAgent) IE (=InternetExplorer) kein XHTML und kein XML versteht. In Wirklichkeit versteht der IE noch nicht einmal HTML richtig.

Wenn man nun Code an einen UA ausliefert (HTTP-Header/MIME-Code) muss dieser erkennen nach welchen Regeln er diesen parsen soll, also, ob er nach HTML (transitional, strict, frameset) oder nach XHTML (transitional, strict) validieren soll.

Sobald man XHTML als HTML ausliefert und dabei den UA in den Quirks-Modus schickt, macht man sich zunutze, dass hier mit extremer Fehlertoleranz dargestellt wird - das ist also das Gegenteil von Validität/Regelkonformheit.

Es geht somit darum wie man es richtig machen soll, und wie man mit Standard-Konformität versus Abwärtskompatibilität (= nicht Standardkonform) umgehen soll. In der Realität besteht da das Problem mit dem IE.

Ein Ansatz ist daher HTML strict mit Stylesheets zu nehmen, was hinsichtlich Barrierefreiheit ein paar Benefits hat.

Der andere Ansatz ist validen XHTML Code als XHTML auszuliefern plus weiterhin eine Weiche einzubauen, dass UAs, wie der IE, die kein XHTML verstehen, den XHTML Code als HTML/Text bekommen. Das heisst die guten UAs werden belohnt und die schlechten bekommen code-soup.

In dem Kontext wird man es dann auch oft mit dem IE-Box-Model-Bug zu tun bekommen, aber auch hier gibt es seit langem ein Framework, was völlig ohne die bekannten Hacks auskommt.

Der Ansatz XHTML zu schreiben und als HTML auszuliefern stellt somit keinen best-practices-ansatz dar, auch wenn er aus reiner Unwissenheit oft praktiziert wird. Diese Leute meinen sich Validität auf die Fahnen schreiben zu können, aber das Gegenteil ist leider wahr.
 
Zuletzt bearbeitet:
Sehr schön zusammengefasst, naomi_watts!
 
naomi_watts schrieb:
Der Hintergrund dazu ist dass der UA (=UserAgent) IE (=InternetExplorer) [...] kein XML versteht.
Das halte ich aber für ein böses Gerücht(zumindest der Win-IE kann es).
 
at Darii:

Wenn du Standard-Konform die XML-Deklaration angibst, wie man es machen sollte, schickst du den WIN-IE in den Quirks-Modus.

at Darii:

Und wenn du mich noch einmal zitierst, dann doch bitte so, dass meine Hauptaussage nicht völlig verfälscht wird, es ging schließlich darum, dass der IE mit dem MIME-Kodierung XHTML nichts anfangen kann.
 
naomi_watts schrieb:
Der Hintergrund dazu ist dass der UA (=UserAgent) IE (=InternetExplorer)
kein XHTML und kein XML versteht. In Wirklichkeit versteht der IE noch
nicht einmal HTML richtig.

Das ist so nicht ganz korrekt.

Internet Explorer 6

Internet Explorer 6 has full XML support, including Namespaces, Style
sheets in CSS, and XSLT 1.0. The built-in XML Parser 3.0 in Internet
Explorer 6.0 and Windows XP is based on both the W3C XSLT 1.0 and
the W3C XPath 1.0 Recommendations. Style sheets in CSS and as well
as XSLT 1.0 are supported.

Internet Explorer has the following XML support:

Viewing of XML documents
Full support for W3C DTD standards
XML embedded in HTML as Data Islands
Binding XML data to HTML elements
Transforming and displaying XML with XSL
Displaying XML with CSS
Access to the XML DOM


Internet Explorer 5

Internet Explorer 5 also has XML support, but the XSL part is NOT
compatible with the official W3C XSL Recommendation.

Siehe http://www.w3schools.com/xml/xml_browsers.asp
 
at sikomat:

Wenn du ordnungsgemäß die XML-Deklaration angibst, dann springt dein IE 6.0 in den Quirks-Modus und rendert gemäß IE 5.0 !!!!

Wenn du ordnungsgemäß XHTML als MIME-Kodierungs angibst, dann kennt der IE 6.0 das nicht und fragt dich, wohin er die Datei speichern soll, anstatt dir die Seite anzuzeigen.

Wenn du alternativ die MIME-Kodierung XML angibst, dann zeigt dir der IE 6.0 einen XML-Dateibau und wirft dein Stylesheet weg.

In der "w3cschool" gibt's vielleicht Theorie, hier geht's um das, was in der Praxis abgeht. Und wenn die schon ihre Seiten mit ASP bauen, dann haben die nicht wirklich Ahnung was sie tun.
 
naomi_watts schrieb:
Und wenn die schon ihre Seiten mit ASP bauen, dann haben die nicht wirklich Ahnung was sie tun.

Das Killerargument der Woche. :p
 
at sikomat:

bist du bzgl. ASP anderer Meinung?
 
Sagen wir es so: Wenn eines der erfolgreichsten Portale
Europas für Autos mit ASP läuft, kann es nicht so schlecht sein.

Siehe http://www.autoscout24.de/

Aber ich bin mir sicher, dass Du konstruktiv begründen kannst,
warum man ASP nicht einsetzen sollte.

;)
 
Zurück
Oben Unten