Meinungen/Verbesserungsvorschläge für Website

[Valentin_]

Hallo Community,

ich würde gerne ein paar Meinungen und ggf. Verbesserungsvorschläge für meine Website einholen.

Ich möchte auf meiner Website ein paar kleine, selbstentwickelte PHP Skripte anbieten und meine bisherigen Referenzen präsentieren, da ich mir in nicht allzu ferner Zukunft mein Taschengeld ein wenig durch Webdesign aufbessern möchte.

Die Adresse zu meiner Website lautet: http://valentinbuchhold.com

Freue mich über viele konstruktive Kritiken. :-)

[Daniel unreg]

Hallo,

Ich möchte auf meiner Website ein paar kleine, selbstentwickelte PHP Skripte anbieten und meine bisherigen Referenzen präsentieren, da ich mir in nicht allzu ferner Zukunft mein Taschengeld ein wenig durch Webdesign aufbessern möchte.

Wenn ich diese Seite als Referenz nehme, bist du durchgefallen!

Zunächst kann man XHTML im Web nur utf-8 kodiert und in der Version 1.0 verwenden. Alles andere ist problematisch oder fehlerhaft. Und da man noch ein dutzend weiterer Punkte beachten muss, rate ich gänzlich zu HTML (4.01 mit den richtigen Werkzeugen).

Das meta-Element mit der Angabe zum Zeichensatz sollte außerdem das erste Kindelement des head-Elements sein.

Außerdem würde es mir gefallen, wenn die Seite in der Breite etwas flexibler wäre. Kaum skaliert man hoch werden die Zeilen sehr kurz.

Ansonnsten ganz in Ordnung, aber was spricht dagegen das body-Element als "wrapper" zu verwenden?

Gruß;

[Valentin_]

Hallo,

Hallo Daniel,

Wenn ich diese Seite als Referenz nehme, bist du durchgefallen!

Durchgefallen, weil das meta-Element zur Angabe der Zeichenkodierung nicht das erste Kindelement des head-Elements ist und weil die Website nicht ganz perfekt skaliert? Ist das nicht ein wenig übertrieben formuliert?

Zunächst kann man XHTML im Web nur utf-8 kodiert und in der Version 1.0 verwenden. Alles andere ist problematisch oder fehlerhaft. Und da man noch ein dutzend weiterer Punkte beachten muss, rate ich gänzlich zu HTML (4.01 mit den richtigen Werkzeugen).

Warum sollte man XHTML nur in UTF-8 und nicht in ISO-8859-1 kodiert verwenden können? Ich höre so etwas zum ersten Mal und wüsste nicht, was gegen in ISO-8859-1 kodiertes XHTML sprechen würde. Ich möchte jetzt nicht arrogant rüberkommen, aber dennoch muss ich zu meiner Verteidigung sagen: Ich denke oder bin sogar vielmehr davon überzeugt, dass ich XHTML gut bis sehr gut beherrsche und ich wüsste nicht, wieso ich HTML verwenden sollte. Zu den "duzend weiteren Punkten": Die Seite ist laut offiziellem Validator vollkommen valide, das Markup stimmt von der Logik her, es werden keine Elemente zweckentfremdet und so weiter. In diesem Punkt kann ich deine Kritik wirklich nicht nachvollziehen. Sehen wir von der Kodierung ab (weil ich mir in diesem Punkt nicht sicher bin, wer von uns beiden Recht hat), handelt es sich um 1A XHTML.

Das meta-Element mit der Angabe zum Zeichensatz sollte außerdem das erste Kindelement des head-Elements sein.

Davon habe ich ebenfalls noch nie etwas gehört. Auch in der SELFHTML-Dokumentation wird darauf nicht hingewiesen. Das meta-Element zur Angabe der Zeichenkodierung wird sogar erst nach vielen anderen meta-Elementen behandelt. Vielleicht hast du Recht, dennoch ist es mit Sicherheit kein Kritikpunkt, der zur Bewertung „Durchgefallen“ beitragen würde.

Ansonnsten ganz in Ordnung, aber was spricht dagegen das body-Element als "wrapper" zu verwenden?

Zuerst enthielt der Wrapper ein Hintergrundbild, welches horizontal wiederholt wurde. Damit es im Internet Explorer 7 korrekt skaliert wurde, musste es deshalb in einen div-Wrapper gesteckt werden, da der IE7 Hintergrundbilder im body-Element nicht korrekt skaliert.

Gruß;

Ebenfalls liebe Grüße.

[Daniel unreg]

Hallo,

Durchgefallen, weil das meta-Element zur Angabe der Zeichenkodierung nicht das erste Kindelement des head-Elements ist und weil die Website nicht ganz perfekt skaliert? Ist das nicht ein wenig übertrieben formuliert?

Das macht zugegeben nur den Kleineren Kritikpunkt aus. Das nachfolgende ist viel schwerwiegender!

Warum sollte man XHTML nur in UTF-8 und nicht in ISO-8859-1 kodiert verwenden können? Ich höre so etwas zum ersten Mal und wüsste nicht, was gegen in ISO-8859-1 kodiertes XHTML sprechen würde.

Wird eine andere Kodierung als utf-8 oder utf-16 verwendet muss eine XML-Deklaration angegeben werden (in XHTML 1.1 ist diese sogar - soweit ich weis - Pflicht).
Damit versetzt du aber den Internet Explorer 6 in den Quirksmode, was sich ein guter Webautor nicht leisten kann.

Ich möchte jetzt nicht arrogant rüberkommen, aber dennoch muss ich zu meiner Verteidigung sagen: Ich denke oder bin sogar vielmehr davon überzeugt, dass ich XHTML gut bis sehr gut beherrsche und ich wüsste nicht, wieso ich HTML verwenden sollte.

HTML hat nur einen Nachteil gegebüber XHTML wie du es verwendest und den kann man verkleinern (siehe Verweis) und mi etwas Verstand gegen Null gehen lassen. Darüberhinaus ist XHTML aus Sicht von XML nicht zukunftsfähig. XHTML 1.1 ist inkompatibel zu 1.0. XHTML 2.0 ist inkompatibel zu 1.x. Wie soll ein stinknormaler XML Prozessor da durchblicken? XHTML ist an der Grenze den XML Standard zu vergiften.

Zu den "duzend weiteren Punkten": Die Seite ist laut offiziellem Validator vollkommen valide, das Markup stimmt von der Logik her, es werden keine Elemente zweckentfremdet und so weiter. In diesem Punkt kann ich deine Kritik wirklich nicht nachvollziehen. Sehen wir von der Kodierung ab (weil ich mir in diesem Punkt nicht sicher bin, wer von uns beiden Recht hat), handelt es sich um 1A XHTML.

Validierung ist nur ein Punkt des ganzen, aber so wie du schreibst verstehst dud as ja :)
Mein Kritikpunkt: Du übersiehst die Warnung, die der Validator ausspricht: Das Dokument wird mit einem Medientypen versendet (text/html), der für XHTML 1.1 nicht erlaubt ist. Schneegans' <http://schneegans.de/sv/@Schema Validator> hätte dir den Fehler deutlicher gemacht.

Du musst also XHTML 1.0 verwenden, wenn du "XHTML"-Dokumente auch IE-Benutzern (sowie bestimmten anderen Browsern) zugänglich machen möchtest. Wie gesagt, nur XHTML-1.0-Dokumente dürfen als text/html versendet werden. Dann wird es schwirig, denn das verursacht zahlreiche Probleme, die der Validator nicht erkennen kann:

* Wie gesagt, die Zeichenkodierung.
* Verzicht auf alle XML-Features.
* Die Elementsprache muss mit lang und xml:lang angegeben werden.
* Man muss acht geben bei leeren Elementen und Elementen die per Definition leer sind.
* Für Zeichenmaskierungen dürfen nur &lt;, &gt;, &amp; und &quot; verwendet werden.
* Verzicht auf ein paar Elemente und Attribute (isindex, name, ismap).
* Implizierte tbody-Elemente.
* Stylesheets und Skripte müssen ausgelagert werden (gut, das sollte man auch so machen).
* Unterschiedliche Verarbeitung von Stylesheets.
* Man kann weder document.write() noch Level-1 DOM-Methoden verwenden.

Davon habe ich ebenfalls noch nie etwas gehört. Auch in der SELFHTML-Dokumentation wird darauf nicht hingewiesen. Das meta-Element zur Angabe der Zeichenkodierung wird sogar erst nach vielen anderen meta-Elementen behandelt. Vielleicht hast du Recht, dennoch ist es mit Sicherheit kein Kritikpunkt, der zur Bewertung „Durchgefallen“ beitragen würde.

In manchen Dingen kann man mit SELFHTML unzufrieden sein. Dieses meta-Element sollte das Erste Kind sein, damit der Browser die Zeichenkodierung auch tatsächlich auslesen kann. Wäre im title-Element bereits ein Sonderzeichen, der Browser müsste raten. Und HTML-Parser, so wie die, die dein Dokument verarbeiten, kennen die XML-Deklaration eben nicht.

Mir wäre noch eingefallen, dass du den Footerbereich noch als Absatz und darauf folgende Liste gestalten könntest. Sonst fehlt ein sinnvolles Element.

Lehrreiche Grüße;

[Valentin_]

Hallo,

Hallo Daniel,

Wird eine andere Kodierung als utf-8 oder utf-16 verwendet muss eine XML-Deklaration angegeben werden (in XHTML 1.1 ist diese sogar - soweit ich weis - Pflicht).
Damit versetzt du aber den Internet Explorer 6 in den Quirksmode, was sich ein guter Webautor nicht leisten kann.

Das ist mir zugegebenermaßen relativ egal, da alle meine Websites ab dem IE5.5 korrekt dargestellt werden. Im Quirks-Modus verhält sich der IE6 nun mal fast wie ein IE5.5 und da ich so oder so ein Stylesheet für den IE5.5 entwickle, kann ich es auch gleich noch dem IE6 zuweisen. Das macht mir schließlich keine zusätzliche Arbeit. Anders wäre es, wenn ich Kompatibilität nur ab dem IE6 garantieren würde. Dann würde eine XML-Deklaration natürlich unnötige zusätzliche Arbeit bedeuten. In meinem Fall ist es allerdings egal, ob der IE6 in den Quirks-Modus schaltet oder nicht. Es sei denn, du hast neben der schlechteren CSS-Unterstützung noch weitere Argumente parat. ;-)

HTML hat nur einen Nachteil gegebüber XHTML wie du es verwendest und den kann man verkleinern (siehe Verweis) und mi etwas Verstand gegen Null gehen lassen. Darüberhinaus ist XHTML aus Sicht von XML nicht zukunftsfähig. XHTML 1.1 ist inkompatibel zu 1.0. XHTML 2.0 ist inkompatibel zu 1.x. Wie soll ein stinknormaler XML Prozessor da durchblicken? XHTML ist an der Grenze den XML Standard zu vergiften.

Mir ist XHTML in erster Linie wesentlich sympathischer als HTML, weil es strikter ist. Viele "überflüssige" Elemente und Attribute haben ihren Weg aus dem Standard raus gefunden, unter anderem weil sie Funktionen hatten, für die HTML nie zuständig sein sollte. Meine Gründe sind also eher ideologisch bedingt und nicht etwa, weil XHTML einen praktischen Mehrwert für mich hätte.

Mein Kritikpunkt: Du übersiehst die Warnung, die der Validator ausspricht: Das Dokument wird mit einem Medientypen versendet (text/html), der für XHTML 1.1 nicht erlaubt ist. Schneegans' <http://schneegans.de/sv/@Schema Validator> hätte dir den Fehler deutlicher gemacht.

Du hast Recht, diese Warnung hab ich bis jetzt großzügig ignoriert. Ich denke, ich werde auf XHTML 1.0 umstellen. Zurück zu HTML konntest du mich allerdings immer noch nicht bewegen. ;-)

In manchen Dingen kann man mit SELFHTML unzufrieden sein. Dieses meta-Element sollte das Erste Kind sein, damit der Browser die Zeichenkodierung auch tatsächlich auslesen kann. Wäre im title-Element bereits ein Sonderzeichen, der Browser müsste raten. Und HTML-Parser, so wie die, die dein Dokument verarbeiten, kennen die XML-Deklaration eben nicht.

Klingt für mich logisch und nachvollziehbar, ergo werde ich es ändern. ;-)

Mir wäre noch eingefallen, dass du den Footerbereich noch als Absatz und darauf folgende Liste gestalten könntest. Sonst fehlt ein sinnvolles Element.

Ebenfalls sehr einfach zu verbessern, werde ich also machen.

Vielleicht noch eine Frage: Wir unterhalten uns hier nur über technische Aspekte, die in meinen Augen zwar sehr wichtig sind, von denen der Nutzer jedoch für gewöhnlich nichts mitbekommt. Ich würde mich freuen, auch noch eine Stellungnahme zum visuellen Erscheinungsbild der Website zu hören. Wie wirkt die Website insgesamt, harmonieren die Farben gut miteinander, sind die Proportionen der verschiedenen Elemente in Ordnung und so weiter.

Lehrreiche Grüße;

Liebe Grüße zurück und danke für deine Bereitschaft, ausführlich mit mir zu diskutieren. ;-)

[Daniel unreg]

Hallo,

Mir ist XHTML in erster Linie wesentlich sympathischer als HTML, weil es strikter ist. Viele "überflüssige" Elemente und Attribute haben ihren Weg aus dem Standard raus gefunden, unter anderem weil sie Funktionen hatten, für die HTML nie zuständig sein sollte. Meine Gründe sind also eher ideologisch bedingt und nicht etwa, weil XHTML einen praktischen Mehrwert für mich hätte.

XHTML 1.0 und HTML 4.01 sind im Sprachumfang nahezu identisch. XHTML wegen einem fehlendem name-Attribut strikter oder sonstwas zu nennen ist unsinn. XHTML 1.1 hat einen Sprachumfang für Dokumente ja. Ist aber im Web nutzlos, weil es nur als application/xhtml+xml versendet werden darf.

Geht man dem nach wirst du irgendwann bei HTML 5 landen, welches ebenfalls nur Elemente und Attribute enthält, die für ein Webdokument zu gebrauchen sind. HTML 4 wird hier sematisch erweitert :)

Du hast Recht, diese Warnung hab ich bis jetzt großzügig ignoriert. Ich denke, ich werde auf XHTML 1.0 umstellen. Zurück zu HTML konntest du mich allerdings immer noch nicht bewegen. ;-)

Das ist schade. Dann ich hoffe du beachtest alle notwendigen Punkte, wenn du mit text/html-XHTML arbeitest :)

Vielleicht noch eine Frage: Wir unterhalten uns hier nur über technische Aspekte, die in meinen Augen zwar sehr wichtig sind, von denen der Nutzer jedoch für gewöhnlich nichts mitbekommt. Ich würde mich freuen, auch noch eine Stellungnahme zum visuellen Erscheinungsbild der Website zu hören. Wie wirkt die Website insgesamt, harmonieren die Farben gut miteinander, sind die Proportionen der verschiedenen Elemente in Ordnung und so weiter.

Ich bin halt der Technik-Typ :) Und wenn man Verweise zur Validation setzt sollte da keine Warnung - sei sie auch nur gelb und nicht rot - sein.

Visuell hm. Da der Inhaltsbereich weiß ist fällt mir auf, das das Bild und die Hintergrundfarben zu dunkel sind, bzw. sich nicht gut zusammenfügen.
Auch das grau hinterlegen des aktiven Menüpunktes finde ich störend, da dadurch zu wenig Kontrast zw. Hintergrund und Schrift entsteht.

Eventuell noch ein paar andere Tipps.
In der Navigation würde ich "Weitere bald verfügbar" weg lassen, vor allem da man nicht unterscheiden kann ob es ein Link ist oder nicht.
Ich glaube "myMemopad" gehört auch zu "PHP Scripting".

Richtet sich deine Seite eher an Webseitenkunden? Dann würde ich technische Hintergründe weglassen und ein paar Bilder für sich sprechen lassen bzw. einfache Formulierungen verwenden. Beispielsweise: Die Inhalte sind vom Aussehen getrennt, also kann man beides unabhängig voneinander bearbeiten.

Liebe Grüße;

[Volker Nebelung]

XHTML 1.0 und HTML 4.01 sind im Sprachumfang nahezu identisch. XHTML wegen einem fehlendem name-Attribut strikter oder sonstwas zu nennen ist unsinn. XHTML 1.1 hat einen Sprachumfang für Dokumente ja. Ist aber im Web nutzlos, weil es nur als application/xhtml+xml versendet werden darf.

Aber stößt sich gerade deine vorherige Argumentation gegen XHTML und für HTML nicht mit diesem Artikel auf schneegans.de?
XHTML _ist_ strikter, weil es eine einheitliche Syntax erfordet, im Gegensatz zu HTML (siehe Beispiel direkt am Seitenanfang des Links) ...

Gruß, Volker

[Daniel unreg]

Hallo,

Aber stößt sich gerade deine vorherige Argumentation gegen XHTML und für HTML nicht mit diesem Artikel auf schneegans.de?
XHTML _ist_ strikter, weil es eine einheitliche Syntax erfordet, im Gegensatz zu HTML (siehe Beispiel direkt am Seitenanfang des Links) ...

Schneegans argumentiert in der Tat nicht schlecht, übersieht aber viele Feinheiten und wichtige Punkte!

Ebenso erzählt er von strengeren DTDs. Unter so einer wird HTML-Quelltext im verlinkten Werkzeug geprüft. Dadurch werden nicht alle Fehler sichtbar, aber es werden dennoch zahlreiche gefunden. Den Rest finde ich vertretbar zum Suchen.

XHTML hat ja nur den Vorteil der strengen XML-Regeln. Aber die ganzen Nachteile sind meiner Meinung nach zu viele für den Einsatz im Web.

Viel wichtiger sind mir die zukunftsfähigkeit der Sprachen. Keiner weis wie sich XHTML entwickeln wird. XHTML 2 scheint nicht passend, trotz guter ansätze. HTML 5 scheint die Zukunft und wird ebenso streng auf Fehler prüfbar werden wie XHTML.

Gruß;

[Sven Rautenberg]

Moin!

XHTML hat ja nur den Vorteil der strengen XML-Regeln. Aber die ganzen Nachteile sind meiner Meinung nach zu viele für den Einsatz im Web.

Der spannendste Aspekt ist für mich eigentlich die XML-kompatible Verpackung von Inline-Scriptcode oder Stylesheets.

In HTML ist das in Kommentaren verpackt gewesen, die Browser haben es trotzdem akzeptiert, und man mußte sich wegen eventueller HTML-Zeichen im Code keine Gedanken machen.

In XHTML darf alles, was in Kommentaren steht, ignoriert werden, also auch Skriptcode. Was nicht passiert, solange man die Seite als text/html ausliefert, aber für dumme Gesichter sorgt, sobald der eigentlich vorgesehene Mime-Typ application/xhtml+xml benutzt wird, der den XML-Parser in den Browsern aktiviert.

Der Versuch, Inline-Skriptcode vor XML (mittels CDATA-Insel) so zu verstecken, dass sich auch HTML-kompatible Parser nicht dran stören, ist nur noch als "abenteuerlich" zu bezeichnen. Einfach weil - genau wie in HTML auch - die XHTML-Struktur CDATA mit Javascript-Kommentierung vor der Interpretation als Code geschützt werden muß, und parallel die Javascript-Kommentare wieder XHTML-seitig auskommentiert werden müssen.

Resultat ist (laut http://www.hixie.ch/advocacy/xhtml):
      <script type="text/javascript"><!--//--><![CDATA[//><!--
        ...
      //--><!]]></script>

Klingt irgendwie nicht so überzeugend, oder?

- Sven Rautenberg

[Gunnar Bittersmann]

Hello out there!

Der spannendste Aspekt ist für mich eigentlich die XML-kompatible Verpackung von Inline-Scriptcode oder Stylesheets.
In HTML ist das in Kommentaren verpackt gewesen, [...]

Diese Auskommentierung ist schon seit vielen Jahren völlig überflüssig.

weil - genau wie in HTML auch - die XHTML-Struktur CDATA mit Javascript-Kommentierung vor der Interpretation als Code geschützt werden muß, und parallel die Javascript-Kommentare wieder XHTML-seitig auskommentiert werden müssen.

Nein. Wozu letzteres?

Resultat ist (laut http://www.hixie.ch/advocacy/xhtml)

Aua, schon wieder dieser Schmarrn, der „jedoch hauptsächlich dadurch besticht, dass er vor allem einseitig und irreführend ist.“ [Jendryschik]

<script type="text/javascript"><!--//--><![CDATA[//><!--
        ...
      //--><!]]></script>

Wozu der Quatsch?

<script type="text/javascript">  
[code lang=javascript]//[code lang=xml]<![CDATA[

...
//]]>[/code]
</script>[/code]

und gut ist. (Wenn das Script überhaupt CDATA und nicht PCDATA sein soll.)

Und warum der Inhalt von 'style'-Elementen laut Hickson CDATA sein sollte, leuchtet mir nicht ein. Welche Probleme macht denn bitte CSS als PCDATA?

See ya up the road,
Gunnar

[molily]

Hallo,

Der Versuch, Inline-Skriptcode vor XML (mittels CDATA-Insel) so zu verstecken, dass sich auch HTML-kompatible Parser nicht dran stören, ist nur noch als "abenteuerlich" zu bezeichnen.

Irgendwie scheinst du da etwas fundamental missverstanden zu haben, ansonsten kann mir ich deinen Einwand nicht erklären...

Warum wurde eingebetteter Script- und Style-Code überhaupt auskommentiert? - Für Scripte: Weil Netscape 1 und IE 2 kein JavaScript können und den Code einfach ausgeben würden.

(Die Versionen hatte ich mal für http://de.selfhtml.org/javascript/intro.htm#javascriptbereiche recherchiert. Für style hatte ich das auch mal mal vor Jahren herausgesucht, dürfte irgendwo im Archiv liegen.)

Conclusio: Für Browser darüber können wir auf Auskommentierung verzichten.

Was machen wir nun, wenn in einem HTML-4-Dokument HTML-Code in <script>...</script> auftaucht? - Wir schreiben ihn ganz normal hin, verändern aber End-Tags von </ zu </. Sache gegessen.

Einfach weil - genau wie in HTML auch - die XHTML-Struktur CDATA mit Javascript-Kommentierung vor der Interpretation als Code geschützt werden muß

In HTML muss man den Inhalt von script nicht vor der Interpretation schützen. Kann man eigentlich gar nicht. Denn die Browser ignorieren ihn ohnehin. Auch, wenn man vergessen hat, </ mit </ zu maskieren. Die Browser sind so fehlertolerant, dass sie alles von <script> zu </script> als Script behandeln. (Gut, »</script>« muss man natürlich immer als »</script>« maskieren.)

In XHTML gibts qua XML solche Sonder-Parsing-Regeln nicht, deshalb muss man den Code ggf. mit CDATA-Bereichen umschließen, da hast du Recht.

Das Beispiel von Hixie ist einfach absurd und aus der Luft gegriffen. Das ist ohnehin ein bloßes Denkexperiment: Es geht dabei darum, XHTML an Netscape 1 auszuliefern. Ja, sehr witzig... Das habe ich zumindest nicht vor. Und wenn, dann lagere ich Scripte aus. Was ohnehin empfohlen ist...

Das Denkexperiment sollte zeigen, dass die HTML-Kompatiblität von XHTML in der Praxis nicht wirklich gegeben ist. Das mag auf der theoretischen (absurde SGML-Deklaration von HTML) sowie der praktischen Ebene (Stand 1994) auch korrekt sein, spielt heute aber keine Rolle mehr.

Mathias

[Gunnar Bittersmann]

Hello out there!

Schneegans argumentiert in der Tat nicht schlecht, übersieht aber viele Feinheiten und wichtige Punkte!

Die da wären?

XHTML hat ja nur den Vorteil der strengen XML-Regeln.

Der schon allein ist nicht zu unterschätzen. Ist aber bei weitem nicht der einzige. XHTML kann mit XML-Werkzeugen verarbeitet werden, bspw. mit XSLT transformiert werden.

Aber die ganzen Nachteile [...]

Die da wären?

HTML 5 scheint die Zukunft

Um Himmels Willen ...

See ya up the road,
Gunnar

[Daniel unreg]

Hallo,

Schneegans argumentiert in der Tat nicht schlecht, übersieht aber viele Feinheiten und wichtige Punkte!

Die da wären?

Beispielsweise CSS- und DOM-spezifische Unterschiede! Unterschiede im geparsten Zustand.

Der schon allein ist nicht zu unterschätzen. Ist aber bei weitem nicht der einzige. XHTML kann mit XML-Werkzeugen verarbeitet werden, bspw. mit XSLT transformiert werden.

Es bleibt beim "Nur", wenn jemand Daten in XML festhalten will - nur zu. Aber für das Web ist XHTML wie du es dir erträumst nicht machbar.

Aber die ganzen Nachteile [...]

Die da wären?

XHTML das als HTML verarbeitet wird muss HTML-Ansrüchen *und* XHTML-Ansprüchen gerecht werden. Sinnloser Zeitaufwand, den ohnehin kein Autor auf sich nimmt.

HTML 5 scheint die Zukunft

Um Himmels Willen ...

Bring lieber mal Argumente dagegen. Es gibt keinen Grund sich gegen HTML 5 zu stellen. HTML 5 versucht ein bisschen Ordnung zu bringen und die Unterschiede zwischen HTML und XHTML zu vereinfachen und ist zudem großteils Rückwärtskompatibel. Das kann man von XHTML 1.1 (und höher) nicht gerade behaupten..

Gruß;

[molily]

Hallo,

Beispielsweise CSS- und DOM-spezifische Unterschiede! Unterschiede im geparsten Zustand.

Was sind denn bitte diese Unterschiede.

In CSS muss man background-Angaben auf html übertragen.
In JavaScript enthält tagName klein geschriebene Namen. Dann gabs noch einige ältere Browserfehler, die einen zwangen, die Methoden zu verwenden, die Namensräume berücksichtigen. Das dürfte aber »heute« bzw. in fehlerfreien Browsern nicht nötig sein.

XHTML das als HTML verarbeitet wird muss HTML-Ansrüchen *und* XHTML-Ansprüchen gerecht werden. Sinnloser Zeitaufwand, den ohnehin kein Autor auf sich nimmt.

Sorry, das ist dermaßen Blabla.

Die sogenannten HTML-Kompatibilitätsrichtlinien sind eigentlich Erklärungen der Unterschiede zu HTML, einfach erlernbare Selbstverständlichkeiten, die sich ergeben, wenn man die Grundlagen von XML verstanden hat.

(...) Das kann man von XHTML 1.1 (und höher) nicht gerade behaupten..

Erstens redet hier keiner von XHTML 1.1, zweitens ist XHTML 1.1 eine einfache Beispielanwendung der XHTML-Modularisierung, mehr nicht. Es ist HTML als modularisierte XML-Anwendung. Mehr will es nicht sein und ein Vergleich mit HTML 4 ist einfach nicht möglich.

Mathias

[Valentin_]

Hallo,

Hallo Daniel,

Ich bin halt der Technik-Typ :) Und wenn man Verweise zur Validation setzt sollte da keine Warnung - sei sie auch nur gelb und nicht rot - sein.

Mittlerweile gibt es weder (rote) Fehler noch (gelbe) Warnungen. ;-)

Visuell hm. Da der Inhaltsbereich weiß ist fällt mir auf, das das Bild und die Hintergrundfarben zu dunkel sind, bzw. sich nicht gut zusammenfügen.

Die Hintergrundfarbe des body-Elements ist bereits das hellste Grau unter den websicheren Farben. Um ein noch helleres zu bekommen, müsste ich eine webunsichere (Heißt das so?) Farbe nehmen und das wollte ich eigentlich vermeiden - wobei ich nicht weiß, ob das heutzutage wirklich noch ein Problem ist. Wenn es total störend wäre, könnte ich ein 1x1 Pixel großes Hintergrundbild wiederholen lassen, aber so schlimm finde ich das gar nicht. Ich bin eher der Meinung, dass die ganze Website "zu weiß" wird, wenn der Hintergrund ebenfalls sehr hell ist.

Auch das grau hinterlegen des aktiven Menüpunktes finde ich störend, da dadurch zu wenig Kontrast zw. Hintergrund und Schrift entsteht.

Kräftiges Orange auf hellgrau? Da ist meiner Meinung nach genügend Kontrast vorhanden.

In der Navigation würde ich "Weitere bald verfügbar" weg lassen, vor allem da man nicht unterscheiden kann ob es ein Link ist oder nicht.

Man kann es insofern unterschieden, da der Cursor über Links die Form von so einer netten Hand mit ausgestrecktem Zeigefinger annimmt und über "Weitere bald verfügbar" keine Hand mehr ist, sondern der ganz normale Standard-Pfeil. Aber dein Vorschlag ist sicher eine Überlegung wert.

Ich glaube "myMemopad" gehört auch zu "PHP Scripting".

Nein. Unter Webauthoring findet man meine Referenzen. Dort sind also komplette Websites aufgelistet, die ich selbst entwickelt habe. Dabei spielt es keine Rolle, ob es sich um statische oder dynamische Websites handelt. Unter PHP Scripting findet man einzelne Skripte zum Downloaden. myMemopad ist aber kein einzelnes Skript, sondern ein kompletter Webdienst und gehört somit in die Kategorie Webauthoring.

Richtet sich deine Seite eher an Webseitenkunden? Dann würde ich technische Hintergründe weglassen und ein paar Bilder für sich sprechen lassen bzw. einfache Formulierungen verwenden. Beispielsweise: Die Inhalte sind vom Aussehen getrennt, also kann man beides unabhängig voneinander bearbeiten.

Hm, Websitekunden? Das klingt so "professionell". ;-)
Ich sag es mal so: Diese Website ist nicht dafür gedacht um im Internet auf die Jagt nach neuen "anonymen" Kunden zu gehen. Sie soll vielmehr eine Hilfe für mich sein, wenn ich Menschen im "Real Life" anspreche. Wenn diese dann nach bisherigen Arbeiten fragen, kann ich sie auf meine Website aufmerksam machen, von der aus auch auf die weiteren Referenzen verlinkt wird. Wenn ein ganz neuer Interessent nur durch die Website auf mich stoßen sollte, würde mich das zwar freuen, aber das ist nicht das primäre Ziel der Seite.

Liebe Grüße;

Liebe Grüße zurück.

[Daniel unreg]

Hallo,

wobei ich nicht weiß, ob das heutzutage wirklich noch ein Problem ist.

Hm, naja, das Bild wäre schon "webunsicher". Aber ich glaube heutzutage spielt das auch wirklich keine Rolle mehr. Diese Farbpalette wurde vor über 10 jahren definiert. Das ist in der IT eine Ewigkeit und dreit Tage.

Unterschiede gibt es zwar zwischen verschiedenen Bildschirmtypen, aber die sind auch nicht auf 16 Farben limitiert.

Kräftiges Orange auf hellgrau? Da ist meiner Meinung nach genügend Kontrast vorhanden.

Ich empfinde es gar nicht kontrastreich, vielleicht liegts an der Röhre?

Man kann es insofern unterschieden, da der Cursor über Links die Form von so einer netten Hand mit ausgestrecktem Zeigefinger annimmt und über "Weitere bald verfügbar" keine Hand mehr ist, sondern der ganz normale Standard-Pfeil. Aber dein Vorschlag ist sicher eine Überlegung wert.

Man kann, aber ehrlichgesagt schaue ich nicht, ob sich plötzlich eine Hand oder ein Mauszeiger beim Überfahren hervorhebt. ich klicke eifnach. Und dann kein Ergebnis vorweisen zu können ist für den Besucher sehr unbefriedigend.

Das selbe passiert mir immer öfter mit Formularelementen die von manchen Autoren nicht mit den nützlichen label-Elementen ausgezeichnet werden. Einfach furchtbar.

Nein. myMemopad ist aber kein einzelnes Skript, sondern ein kompletter Webdienst und gehört somit in die Kategorie Webauthoring.

Dann wären villeicht einige Informationen zum Design selbst auch nicht schlecht.

Ich sag es mal so: ...

Schön und gut. Ich meine nur, dass in der Regel Leute, die eine Webseite beauftragen nicht wissen was WYSIWYG (auch ausgesprochen) bedeutet, oder was daran gut bzw. schelcht ist. Ebenso mit serverseitigen Technologien. Webseiten sollen funktionieren. Nicht (technisch) verstanden werden.

Liebe Grüße;

[Gunnar Bittersmann]

Hello out there!

XHTML 1.1 [...] ist aber im Web nutzlos, weil es nur als application/xhtml+xml versendet werden darf.

Nein, auch 'text/html' ist möglich. Nutzlos ist es dann, wenn es gegenüber XHTML 1.0 keinen Mehrwert bringt (dafür aber haufenweise Probleme).

Nützlich ist es für Ruby-Annotationen und in Verbindung mit MathML und SVG.

Ich denke, ich werde auf XHTML 1.0 umstellen. Zurück zu HTML konntest du mich allerdings immer noch nicht bewegen. ;-)

Das ist schade.

Nein, das ist gut so. [http://forum.de.selfhtml.org/archiv/2007/10/t160280/#m1042457 ff.]

See ya up the road,
Gunnar

[Daniel unreg]

Hallo,

Nein, auch 'text/html' ist möglich. Nutzlos ist es dann, wenn es gegenüber XHTML 1.0 keinen Mehrwert bringt (dafür aber haufenweise Probleme).

Probleme bringt es auch so schon. Es sollte nicht als text/html versendet werden, weil es reines XML ist, was bedeutet, wenn es keinen wirklich guten Grund dafür gibt, darf nicht.

Nützlich ist es für Ruby-Annotationen und in Verbindung mit MathML und SVG.

Meines Wissens gibt es Pläne Ruby in HTML 5 einzuführen. Ebenso integriertes SVG, wobei ich mich Frage wo dasd wirklich sinnvol sein soll. Man kann ja nicht mit allem zufrieden sein.

Das ist schade.

Nein, das ist gut so. [http://forum.de.selfhtml.org/archiv/2007/10/t160280/#m1042457 ff.]

Schon wieder? Das Verschweigen von Nachteilen hat noch nie einen Vorteil draus gemacht.

Wer sich die soppelte arbeit sinnloserweise machen will - bitte...

Gruß;

[Valentin_]

Hallo,

Und wenn man Verweise zur Validation setzt sollte da keine Warnung - sei sie auch nur gelb und nicht rot - sein.

Auch wenn es ein wenig vom eigentlichen Thema abkommt: Wie streng siehst du/seht ihr das? Gilt dies für auch für den CSS-Validator? Dem seine Warnungen finde ich nämlich teilweise relativ unsinnig und bin eigentlich auch nicht wirklich gewillt, irgendetwas zu unternehmen, das diese Warnungen nicht mehr erscheinen. Mehr oder weniger zufälligerweise findet er in meinem Stylesheet für valentinbuchhold.com keine einzige Warnung. In anderen Fällen bekomme ich allerdings häufig die folgende Warnung zu sehen: "Die gleichen Farben für den Vordergrund und den Hintergrund in den zwei Kontexten." Dies ist zum Beispiel der Fall, wenn die Hintergrundfarbe des body-Elements und die Vordergrundfarbe der a-Elemente identisch sind. Bei dieser Warnung bleibt jedoch unbeachtet, dass sich die eigentliche Website in einem Wrapper befindet, dessen Hintergrundfarbe sich sehr wohl von der Vordergrundfarbe der a-Elemente unterscheidet. Lösen könnte man dieses Problem, indem man div#wrapper a { color: ... } anstatt a { color: ... } ins Stylesheet schreibt. Jedoch ist das meiner Meinung nach eine unnötige Verkomplizierung - wenn auch bloß eine kleine. Wie seht ihr das? Sollte man auch auf die "Farbwarnungen" des CSS-Validators Rücksicht nehmen oder kann man die getrost ignorieren? (Valid ist das Stylesheet ja trotz alledem.)

Liebe Grüße.

[Gunnar Bittersmann]

Hello out there!

Mir ist XHTML in erster Linie wesentlich sympathischer als HTML, weil es strikter ist. Viele "überflüssige" Elemente und Attribute haben ihren Weg aus dem Standard raus gefunden, unter anderem weil sie Funktionen hatten, für die HTML nie zuständig sein sollte.

Du sprichst hier nicht den Unterschied zwischen HTML und XHTML, sondern den zwischen Strict und Transitional an. Beide Varianten gibt es sowohl in HTML 4.01 als auch in XHTML 1.0.

Meine Gründe sind also eher ideologisch bedingt und nicht etwa, weil XHTML einen praktischen Mehrwert für mich hätte.

Zu dem Mehrwert für dich siehe [Jendryschik] und [Schneegans].

See ya up the road,
Gunnar

[Valentin_]

Hello out there!

Hallo Gunnar,

Du sprichst hier nicht den Unterschied zwischen HTML und XHTML, sondern den zwischen Strict und Transitional an. Beide Varianten gibt es sowohl in HTML 4.01 als auch in XHTML 1.0.

So würde ich das nicht unbedingt sagen. Natürlich existiert ein gravierender Unterschied zwischen den Varianten Strict und Transitional/Frameset. Jedoch ist nicht nur Strict wesentlich strikter als Transitional/Frameset, sondern auch XHTML an sich strikter als HTML (auch in der Varianten Transitional und Frameset). Die Belege für diese Aussage liefern ja deine verlinkten Artikel. So erwähnt Michael Jendryschik unter anderem, dass die Syntax in XHTML eindeutiger als in HTML ist und dass XHTML nicht in einem so hohen Maße wie HTML vom Kontext abhängig ist.

Liebe Grüße.

[Gunnar Bittersmann]

Hello out there!

Du sprichst hier nicht den Unterschied zwischen HTML und XHTML, sondern den zwischen Strict und Transitional an.

Jedoch ist nicht nur Strict wesentlich strikter als Transitional/Frameset, sondern auch XHTML an sich strikter als HTML

Das sind zwei völlig verschiedene Aspekte. Der eine ist die Syntax - da ist XHTML strikter als HTML. Diesen Aspekt sprechen [Jendryschik] und [Schneegans] an.

Der andere ist der Sprachumfang - da ist Strict strikter als Transitional. Diesen Aspekt hattest du aber angesprochen, als du von "'überflüssigen' Elementen und Attributen" sprachst.

See ya up the road,
Gunnar

[Valentin_]

Hallo,

Hallo Daniel,

Mein Kritikpunkt: Du übersiehst die Warnung, die der Validator ausspricht: Das Dokument wird mit einem Medientypen versendet (text/html), der für XHTML 1.1 nicht erlaubt ist. Schneegans' <http://schneegans.de/sv/@Schema Validator> hätte dir den Fehler deutlicher gemacht.

Wie bereits an anderer Stelle gesagt, habe ich alle Seiten auf XHTML 1.0 Strict umgestellt und der offizielle Validator spuckt nun weder "gelbe" Warnungen noch "rote" Fehler aus. Ich habe nun aber doch noch eine Frage zu deinen verlinkten Validatoren - genauer gesagt nur zu einem der beiden. Der Validator auf schneegans.de gibt mir sowohl ein "Valid: Yes" als auch ein "Well-formed: Yes" zurück. Soweit, so gut. Der HTML good practice checker kreidet mir jedoch einige Sachen an, die ich so nicht hinnehmen möchte. Nach seinem Verständnis ist meine Website nicht valid, weil ich mich wage, deutsche Umlaute "einfach so" auszuschreiben anstatt ihre entsprechenden HTML-Entities zu verwenden. Vor vielleicht einem Jahr hat mich ein fortgeschrittener Webentwickler darauf hingewiesen, dass ich deutsche Umlaute ausschreiben solle anstatt ihre Entities zu verwenden. Er begründete dies damit, dass deutsche Umlaute heutzutage für Browser kein Problem mehr wären, wenn man die korrekte Kodierung in der HTML-Datei angeben würde. Da ich dies sowieso immer mache, bin ich seinem Rat gefolgt und hatte bis jetzt auch nie Probleme mit der Darstellung von deutschen Umlauten bekommen. Wieso mault der HTML good practice checker nun? Schlägt er ein wenig über die Strenge hinaus oder ist es wirklich fahrlässig, deutsche Umlaute auszuschreiben anstatt ihre Entities zu verwenden?

Lehrreiche Grüße;

Liebe Grüße zurück.

[Sven Rautenberg]

Moin!

Wieso mault der HTML good practice checker nun? Schlägt er ein wenig über die Strenge hinaus oder ist es wirklich fahrlässig, deutsche Umlaute auszuschreiben anstatt ihre Entities zu verwenden?

Ein Validator ist nur so gut, wie sein Autor. Und wenn der spezielle Ansichten zu besonderen Themen hat (und "best practice" ist nunmal ausschließlich Ansichtssache), dann kommt halt sowas dabei raus.

Browser müssen zwingend den gesamten in Unicode enthaltenen Zeichenvorrat verstehen können. Und es erscheint auch ratsam, dass sie in der Lage sind, die diversen Codierungsmöglichkeiten zu verstehen, die heutzutage im Internet genutzt werden, darunter die gesamte ISO-Palette (8859-1 bis -15, Windows-1252 etc.), UTF-8, und die osteuropäischen und asiatischen Codierungen.

Von diesem Standpunkt aus gesehen sind Entities überflüssig. Man wird sie nur noch dann einsetzen, wenn besondere technische Gegebenheiten z.B. der internen Datenverarbeitung einer Website das erfordern sollten. Oder weil es komplizierter wäre, z.B. dem CMS oder dem benutzen HTML-Editor die Umwandlung in Entities abzugewöhnen. Sie sind ja nicht böse oder verboten. Nur als "best practice" würde ich sie aus heutiger Sicht nicht bezeichnen, da würde ich vielmehr die Verwendung von UTF-8 propagieren.

- Sven Rautenberg

[Daniel unreg]

Hallo,

Ein Validator ist nur so gut, wie sein Autor. Und wenn der spezielle Ansichten zu besonderen Themen hat (und "best practice" ist nunmal ausschließlich Ansichtssache), dann kommt halt sowas dabei raus.

Wie gesagt, Hammonds Validatorzusatz prüft nur HTML und XHTML ist halt mal fehlerhaftes HTML.

Wenn er aber tatsächlich Umlaute ankreidet, weil sie nicht maskiert sind ist das ein Fehler, den ich mal melden sollte.

Nur als "best practice" würde ich sie aus heutiger Sicht nicht bezeichnen, da würde ich vielmehr die Verwendung von UTF-8 propagieren.

Ja, utf-8 ist heute mE Pflicht.

Gruß;

[Gunnar Bittersmann]

Hello out there!

Wieso mault der HTML good practice checker nun? Schlägt er ein wenig über die Strenge hinaus

Ich würde sogar weitergehen und sagen: er erzählt Unsinn.

oder ist es wirklich fahrlässig, deutsche Umlaute auszuschreiben anstatt ihre Entities zu verwenden?

Nein, im Gegenteil: “It is almost always preferable to use an encoding that allows you to represent the characters in their normal form, rather than using character entities or NCRs.” [QA-ESCAPES]

See ya up the road,
Gunnar

[Daniel unreg]

Hallo,

Ich würde sogar weitergehen und sagen: er erzählt Unsinn.

Das macht ein XML programm auch wenn es HTML verarbweiten müsste.

Nein, im Gegenteil: “It is almost always preferable to use an encoding that allows you to represent the characters in their normal form, rather than using character entities or NCRs.” [QA-ESCAPES]

Da hast du meine volle Zustimmung. Dankie für die Quellenangabe. Notiert.

Gruß;

[Daniel unreg]

Hallo,

Der Validator auf schneegans.de gibt mir sowohl ein "Valid: Yes" als auch ein "Well-formed: Yes" zurück. Soweit, so gut. Der HTML good practice checker kreidet mir jedoch einige Sachen an, die ich so nicht hinnehmen möchte.

Nun, der Validator hier prüft unter einer speziellen HTML-Syntax, daher werden einige XHTML-Konstrukte natürlich als Fehler gesehen.

Nach seinem Verständnis ist meine Website nicht valid, weil ich mich wage, deutsche Umlaute "einfach so" auszuschreiben anstatt ihre entsprechenden HTML-Entities zu verwenden.

Hm, das kann ich gerade nicht nachvollziehen. Bist du eventuell auf einen Kodierungsfehler gestoßen? Es ist tatsächlich besser, Zeichen als Rohzeichen einzugeben. Das stimme ich Gunnar und seinem Zitat voll zu.

Werde ich mal genauer prüfen.

Liebe grüße;

[Gunnar Bittersmann]

Hello out there!

wüsste nicht, was gegen in ISO-8859-1 kodiertes XHTML sprechen würde.
Wird eine andere Kodierung als utf-8 oder utf-16 verwendet muss eine XML-Deklaration angegeben werden

Nein, muss sie nicht, wenn die Codierung auf andere Weise (HTTP-Header) angegeben wird. [XML §F.1]

(in XHTML 1.1 ist diese sogar - soweit ich weis - Pflicht).

Nein, ist sie nicht. Für XHTML 1.1 gelten selbstverständlich dieselben XML-Regeln wie für XHTML 1.0.

Darüberhinaus ist XHTML aus Sicht von XML nicht zukunftsfähig.

?? So'n Unsinn.

Das Dokument wird mit einem Medientypen versendet (text/html), der für XHTML 1.1 nicht erlaubt ist.

Ist er doch. Unter Beachtung der Probleme mit XHTML 1.1 kann man solches durchaus als 'text/html' ausliefern.

* Für Zeichenmaskierungen dürfen nur &lt;, &gt;, &amp; und &quot; verwendet werden.

Auch '&auml;' darf verwendet werden. '&apos;' hingegen ist problematisch.

* Verzicht auf ein paar Elemente und Attribute (isindex, name, ismap).

?? HTML 4.01 und XHTML 1.0 sind hinsichtlich ihrer Elemente und Attribute deckungsgleich - natürlich in ihren jeweiligen Varianten. Du darst nicht HTML 4.01 Transitional mit XHTML 1.0 Strict vergleichen.

* Implizierte tbody-Elemente.

Eben das spricht gegen HTML 4.01.

* Stylesheets und Skripte müssen ausgelagert werden (gut, das sollte man auch so machen).

?? Nein, müssen sie nicht.

* Unterschiedliche Verarbeitung von Stylesheets.

?? Welcher Unterschied sollte da bestehen?

* Man kann weder document.write() noch Level-1 DOM-Methoden verwenden.

Selbstverständlich kann man das doch, wenn als 'text/html' verarbeitet wird; eben das war deine Prämisse für die aufgezählten Punkte.

See ya up the road,
Gunnar

[Daniel unreg]

Hallo

Nein, muss sie nicht, wenn die Codierung auf andere Weise (HTTP-Header) angegeben wird. [XML §F.1]

Ein HTTP-Header ist aber nicht mit dem Dokument verknüpft und kann daher schnell abhanden kommen.

Nein, ist sie nicht. Für XHTML 1.1 gelten selbstverständlich dieselben XML-Regeln wie für XHTML 1.0.

Nun, das W3C sagt, XHTML 1.1 sei reines XML. Ist in XML die Deklaration optional?

Darüberhinaus ist XHTML aus Sicht von XML nicht zukunftsfähig.

?? So'n Unsinn.

Zur verdeutlichung: Ich spreche aus der Sicht des Webs. XHTML wird die Qualität der HTML-Werkzeuge nice erreichen können.

Ist er doch. Unter Beachtung der Probleme mit XHTML 1.1 kann man solches durchaus als 'text/html' ausliefern.

Er sollte nicht verwendet werden. D.h. nach der entsprechenden RFC "MUST NOT", außer es ist zwingend notwendig, was es aber nie ist.

* Für Zeichenmaskierungen dürfen nur &lt;, &gt;, &amp; und &quot; verwendet werden.

Auch '&auml;' darf verwendet werden. '&apos;' hingegen ist problematisch.

Bitte Quelle, das ist mir nicht bekannt.

?? HTML 4.01 und XHTML 1.0 sind hinsichtlich ihrer Elemente und Attribute deckungsgleich - natürlich in ihren jeweiligen Varianten. Du darst nicht HTML 4.01 Transitional mit XHTML 1.0 Strict vergleichen.

Tue ich nicht, aber wenn du mir nicht glaubst, prüfe die Verarbeitung dieser Elemente selbst und lese die DTDs. Ich verwechsle hier nichts.

* Implizierte tbody-Elemente.

Eben das spricht gegen HTML 4.01.

Wieso sollte es? Die Autoren haben mehr Erfahrung mit HTML als mit XHTML-spezifischen Spielereien.

* Stylesheets und Skripte müssen ausgelagert werden (gut, das sollte man auch so machen).

?? Nein, müssen sie nicht.

Stimmt, aber wenn Sie im Dokument bleiben erfordert das wieder vermehrten Aufwand. Sinnlosen aufwand. Außerdem ist es schlechte Praxis.

* Unterschiedliche Verarbeitung von Stylesheets.

?? Welcher Unterschied sollte da bestehen?

Die Eigenschaften overflow, background-color und -image werden auf das HTML-Element übertragen. Jedoch nur in HTML.

* Man kann weder document.write() noch Level-1 DOM-Methoden verwenden.

Selbstverständlich kann man das doch, wenn als 'text/html' verarbeitet wird; eben das war deine Prämisse für die aufgezählten Punkte.

Ja. Aber meine Vorgabe lautet eigentlich: Ein Dokument muss identusch funktionieren, unabhängig von der Verarbeitungsweise. Das kann man mit doc.wrt() und L1-Methoden nicht machen.

HTML 5 will hier nebenbei eine Vereinheitlichung schaffen. Aber ist ja böse...

Gruß;

[Gunnar Bittersmann]

Hello out there!

Nein, muss sie nicht, wenn die Codierung auf andere Weise (HTTP-Header) angegeben wird. [XML §F.1]
[…]
Nun, das W3C sagt, XHTML 1.1 sei reines XML. Ist in XML die Deklaration optional?

Ja:

[22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? [XML  §2.8]

Wann die XML-Deklaration entfallen kann, geht doch aus dem bereits anführten Abschnitt [XML §F.1] hervor. Ein kurzer Blick dahinein hätte deine Nachfrage evtl. überflüssig gemacht.

Zur verdeutlichung: Ich spreche aus der Sicht des Webs. XHTML wird die Qualität der HTML-Werkzeuge nice erreichen können.

Und zwar very nice.

Was können HTML-Werkzeuge für HTML 4.01, was sie für XHTML 1.0 nicht könnten?

Ist er doch. Unter Beachtung der Probleme mit XHTML 1.1 kann man solches durchaus als 'text/html' ausliefern.

Er sollte nicht verwendet werden. D.h. nach der entsprechenden RFC "MUST NOT",

Hapert’s an deinen Engischkenntnissen? „Sollte nicht“ heißt „SHOULD NOT“.

Und so steht es auch in [XHTMLMIME §3.5].

Der aktuelle Working Draft [XHTML11 §2.1.1] stellt gar 'application/xhtml+xml' und 'text/html' gleichberechtigt nebeneinander.

außer es ist zwingend notwendig, was es aber nie ist.

Sag niemals nie.

IE versteht kein 'application/xhtml+xml'; versteht aber durchaus Simple Ryby Annotations (und zwar ab 5.0!).

(Ich warte auf den Tag, wo das auch in Firefox endlich mal implementiert wird.)

* Für Zeichenmaskierungen dürfen nur &lt;, &gt;, &amp; und &quot; verwendet werden.

Auch '&auml;' darf verwendet werden. '&apos;' hingegen ist problematisch.

Bitte Quelle, das ist mir nicht bekannt.

Was ist dir nicht bekannt? Dass '&auml;' in XHTML 1.0 verwendet werden darf? In der DTD [XHTML1-DTD] steht:

<!ENTITY % HTMLlat1 PUBLIC
   "-//W3C//ENTITIES Latin 1 for XHTML//EN"
   "xhtml-lat1.ent">
%HTMLlat1;

In [XHTML1-LAT1]:

<!ENTITY auml   "&#228;" ><!-- latin small a with diaeresis, U+00E4 ISOlat1 -->

Oder dass '&apos;' in XHTML als 'text/html' problematisch ist? Das Dokument wird ja dann als HTML verarbeitet; in HTML 4.01 gibt es die Entität 'apos' nicht. [XHTML1], §C.16

XHTML-1.0-Dokumente […] als text/html […]
* Verzicht auf ein paar Elemente und Attribute (isindex, name, ismap).

?? HTML 4.01 und XHTML 1.0 sind hinsichtlich ihrer Elemente und Attribute deckungsgleich - natürlich in ihren jeweiligen Varianten. Du darst nicht HTML 4.01 Transitional mit XHTML 1.0 Strict vergleichen.

Tue ich nicht, aber wenn du mir nicht glaubst, prüfe die Verarbeitung dieser Elemente selbst und lese die DTDs.

Na, da lesen wir doch mal in [XHTML1-TRANSITIONAL-DTD] nach:

<!ELEMENT isindex EMPTY>

<!ATTLIST img
  […]
  name        NMTOKEN        #IMPLIED
  […]
  ismap       (ismap)        #IMPLIED

Bevor du anderen empfielst, DTDs zu lesen, solltest du erst mal selbst einen Blick hineinwerfen.

Ich verwechsle hier nichts.

Offensichtlich doch so einiges. Evtl. XHTML 1.0 und 1.1.

* Implizierte tbody-Elemente.

Eben das spricht gegen HTML 4.01.

Wieso sollte es? Die Autoren haben mehr Erfahrung mit HTML als mit XHTML-spezifischen Spielereien.

Webautoren haben Erfahrung damit, dass bei '<table><tr><td>Lorem ipsum</td></tr></table>' implizit ein 'tbody'-Element vorhanden ist? Die vielen Fragen diesbezüglich hier im Forum (Suche nach "Nostradamus") sagen das Gegenteil.

See ya up the road,
Gunnar

[molily]

Hallo,

* Man kann weder document.write() noch Level-1 DOM-Methoden verwenden.

Offenbar meinst du DOM HTML, mit dem Level hat das nichts zu tun.

DOM 1 Core kann man natürlich verwenden, obwohl es von Namespaces keine Ahnung hat. Wenn nicht, ist es ein Browserproblem, keine allgemein geltende, Implementations-unabhängige Vorschrift des W3C-DOM.

DOM HTML ist in XHTML-Dokumenten ebenfalls nutzbar. Das ist so ausdrücklich im DOM-HTML-Standard definiert. Wenn es in der Praxis nicht so ist, siehe oben.

document.write() ist soweit ich weiß die einzige Ausnahme, andere kannst du mir gerne aufzeigen: http://www.w3.org/TR/DOM-Level-2-HTML/html.html
Selbst Gruselsachen wie innerHTML, die man zunächst gar nicht mit XML in Verbindung bringen würde, funktionieren m.W. mittlerweile in echten XHTML-Dokumenten in den aktuellen Browsern.

Im Übrigen setze ich persönlich nicht application/xhtml+xml u.ä. ein, sondern immer text/html. Vorteile von XHTML liegen für mich auf der Server- und Autorenseite. Meine Scripte teste ich nicht auf Funktionsfähigkeit mit XHTML als XML. Das hat weniger mit dem Aufwand als mit den fehlenden Vorteilen des Ausliefern als XML zu tun.

Mathias

[Schuer]

Wenn ich diese Seite als Referenz nehme, bist du durchgefallen!

Unter uns Drill-Instruktoren: war das nicht ein bisschen harmlos, beinahe verniedlicht? Wenn man Motivation dämpft, sollte man das richtig machen, und dazu gehören zumindest ein paar gezielte Interjektionen vors Schienbein.

Ansonnsten ganz in Ordnung, aber was spricht dagegen das body-Element als "wrapper" zu verwenden?

Der body macht sich im IE nicht allzu gut in seiner Wrapper-Rolle, wenn z.B. Mindest- oder Maximalbreiten verwendet werden, die man mittels Expressions abfangen möchte.

Meiner Meinung nach sollte der body nur die Umgebung bilden, aber niemals ein (agierendes) Element sein.

Viele Grüße!
_ds

[Schuer]

Freue mich über viele konstruktive Kritiken. :-)

Reduziert und schlicht, dabei nicht langweilig.. gefällt mir prima.

Inhaltlich würde ich mir noch zumindest ein paar Basisinfos zum Autor wünschen, denn das gehört für mich zu einer persönlichen Website zwingend dazu.

Viele Grüße!
_ds

[Valentin_]

Hallo,

Reduziert und schlicht, dabei nicht langweilig.. gefällt mir prima.

Vielen Dank für das Kompliment. ;-)

Inhaltlich würde ich mir noch zumindest ein paar Basisinfos zum Autor wünschen, denn das gehört für mich zu einer persönlichen Website zwingend dazu.

Guter Vorschlag, werde in der nächsten Zeit mal ein bisschen was zusammenschreiben.

Viele Grüße!

Liebe Grüße zurück.

[Valentin_]

Hallo,

Inhaltlich würde ich mir noch zumindest ein paar Basisinfos zum Autor wünschen, denn das gehört für mich zu einer persönlichen Website zwingend dazu.

Ich habe mich nun mal an solch einer Seite versucht. Das Ergebnis kann hier begutachtet werden. Ist es in etwas das, was du dir vorgestellt hast oder wolltest du noch mehr persönliche/private Informationen?

Viele Grüße!

Liebe Grüße.

[Gunnar Bittersmann]

Hello out there!

http://valentinbuchhold.com/aboutme.html

Da liest man als Überschrift "Uber mich."
                              ▲
Nicht, dass es so im Quelltext stünde; aber durch die im Stylesheet zu gering angegebene Zeilenhöhe gehen die Punkte auf dem 'Ü' verloren.

See ya up the road,
Gunnar

[Valentin_]

Hello out there!

Hallo Gunnar,

Da liest man als Überschrift "Uber mich."

Vielen Dank für den Hinweis. Ich habe den Zeilenabstand ein wenig erhöht.

Liebe Grüße.

[Schuer]

Ich habe mich nun mal an solch einer Seite versucht. Das Ergebnis kann hier begutachtet werden. Ist es in etwas das, was du dir vorgestellt hast oder wolltest du noch mehr persönliche/private Informationen?

Klasse, genau richtig! Jetzt noch ein interessantes Foto rein, und die Seite gibt eine prima Visitenkarte ab.

Viele Grüße!
_ds

[Der Martin]

Hallo,

ich würde gerne ein paar Meinungen und ggf. Verbesserungsvorschläge für meine Website einholen.

aus der Diskussion um technische Einzelheiten halte ich mich heute mal raus, obwohl ich mich im ersten Moment auch gefragt habe, warum du wohl explizit auf XHTML 1.1 anstatt 1.0 setzt.

Die Optik gefällt mir recht gut und sieht für mein Auge harmonisch und gefällig aus, die Farben sind gut gewählt. Nur deine Standardschrift für den Fließtext finde ich viel zu klein gewählt. Okay, sie ist noch ohne Schwierigkeiten lesbar, aber einfach winzig.

Ich möchte auf meiner Website ein paar kleine, selbstentwickelte PHP Skripte anbieten und meine bisherigen Referenzen präsentieren, da ich mir in nicht allzu ferner Zukunft mein Taschengeld ein wenig durch Webdesign aufbessern möchte.

Die bisher angebotenen PHP-Scripte (ein Formmailer und eine Slideshow) finde ich nicht gerade originell gewählt. Mag sein, dass sie sich durch bestimmte Details aus der Masse abheben, aber hättest du als Beispiel nicht etwas, das weniger "typisch" ist?
In den Referenzen fällt mir mymemopad.de auf; ich erinnere mich dunkel, dass du das Konzept vor einiger Zeit mal hier zur Diskussion gestellt hast, und ich hatte kritisiert, dass mir eine solche web-basierte Applikation suspekt wäre, sie stieß aber allgemein auf recht positive Resonanz.

Deine Devise, (X)HTML als das zu verwenden, wofür es ursprünglich gedacht ist, und Inhalt und Layout konsequent zu trennen, finde ich gut, genauso wie ich als Sonderling und überzeugter IE5.5-Nutzer anerkenne, dass du diesen alten Browser noch ausdrücklich mit unterstützt.

Insgesamt denke ich, du bist auf einem guten Weg. Es ist normal, dass mir nciht alles gefällt, das ist zum großen Teil auch Geschmackssache. Vielleicht kannst du ja mit meinen Anregungen trotzdem irgendwas anfangen ...

So long,
 Martin

[Valentin_]

Hallo,

Hallo Martin,

aus der Diskussion um technische Einzelheiten halte ich mich heute mal raus, obwohl ich mich im ersten Moment auch gefragt habe, warum du wohl explizit auf XHTML 1.1 anstatt 1.0 setzt.

Mittlerweile habe ich sämtliche Seiten auf XHTML 1.0 Strict umgestellt. ;-)

Die Optik gefällt mir recht gut und sieht für mein Auge harmonisch und gefällig aus, die Farben sind gut gewählt. Nur deine Standardschrift für den Fließtext finde ich viel zu klein gewählt. Okay, sie ist noch ohne Schwierigkeiten lesbar, aber einfach winzig.

Vor dir hatte schon jemand anderes gesagt, dass er die Schriftgröße winzig finde. Mich überrascht das ehrlich gesagt. Es handelt sich nämlich um eine "Standardgröße", die auf sehr vielen (großen) Websites verwendet wird. Schriftgröße 12 Pixel, Zeilenabstand 20 Pixel. Die Schriftgröße hier im Forum sieht mir ebenfalls stark nach 12 Pixeln aus. Findest du demnach die Schriftgrößen im Web allgemein zu klein oder ist es dir nur speziell auf meiner Website aufgefallen?

In den Referenzen fällt mir mymemopad.de auf; ich erinnere mich dunkel, dass du das Konzept vor einiger Zeit mal hier zur Diskussion gestellt hast, und ich hatte kritisiert, dass mir eine solche web-basierte Applikation suspekt wäre, sie stieß aber allgemein auf recht positive Resonanz.

Ja, da hast du Recht. Über myMemopad wurde hier schon mal diskutiert. Aber ob einem solche Webapplikationen suspekt erscheinen oder nicht, man kann sich anhand ihr trotz alledem ein Bild von meinen Fähigkeiten machen - sogar ein besseres, als mit der aktuell zur Diskussion stehenden Website, da auf myMemopad wesentlich mehr verschiedene Webtechnologien verwendet werden.

Deine Devise, (X)HTML als das zu verwenden, wofür es ursprünglich gedacht ist, und Inhalt und Layout konsequent zu trennen, finde ich gut, genauso wie ich als Sonderling und überzeugter IE5.5-Nutzer anerkenne, dass du diesen alten Browser noch ausdrücklich mit unterstützt.

Ehrlich gesagt bin ich jetzt doch überrascht, dass ich mit meiner Website einem IE5.5-Nutzer begegne. Da hat sich die IE5.5-Untersützung ja richtig gelohnt. ;-)

Martin

Liebe Grüße zurück.

[Daniel unreg]

Hallo,

Die Optik gefällt mir recht gut und sieht für mein Auge harmonisch und gefällig aus, die Farben sind gut gewählt. Nur deine Standardschrift für den Fließtext finde ich viel zu klein gewählt. Okay, sie ist noch ohne Schwierigkeiten lesbar, aber einfach winzig.

Vor dir hatte schon jemand anderes gesagt, dass er die Schriftgröße winzig finde. Mich überrascht das ehrlich gesagt. Es handelt sich nämlich um eine "Standardgröße", die auf sehr vielen (großen) Websites verwendet wird. Schriftgröße 12 Pixel, Zeilenabstand 20 Pixel. Die Schriftgröße hier im Forum sieht mir ebenfalls stark nach 12 Pixeln aus. Findest du demnach die Schriftgrößen im Web allgemein zu klein oder ist es dir nur speziell auf meiner Website aufgefallen?

Ich mische mich hier mal ein. JA. Die Schriftgröße bei Webseiten sind viel zu klein. Und wer Sie in Pixel angiebt ist böse! em oder % eignen sich viel besser: Hier kann man auch die ideale Zeilenlänge von 70-80 Buchstaben erreichen.

Deswegen habe ich dich auch wegen der Skalibarkeit kritisiert. Wenn ich eine Webseite zoome möchte ich keine 10-Zeichen-Zeilen sehen, sonder den Text immernoch gut lesbar haben.

Deine Devise, (X)HTML als das zu verwenden, wofür es ursprünglich gedacht ist, und Inhalt und Layout konsequent zu trennen, finde ich gut, genauso wie ich als Sonderling und überzeugter IE5.5-Nutzer anerkenne, dass du diesen alten Browser noch ausdrücklich mit unterstützt.

Ehrlich gesagt bin ich jetzt doch überrascht, dass ich mit meiner Website einem IE5.5-Nutzer begegne. Da hat sich die IE5.5-Untersützung ja richtig gelohnt. ;-)

Hm, ob HTML oder XHTML spielt bei der Trennung von Design und Inhalt keine Rolle ;)

Ich persönlich finde der Dino IE 5.5 sollte sich langsam zur Ruhe setzen. Vielleicht gefällt dir ja der IE8.

Gruß;

[Sven Rautenberg]

Moin!

Ich mische mich hier mal ein. JA. Die Schriftgröße bei Webseiten sind viel zu klein. Und wer Sie in Pixel angiebt ist böse! em oder % eignen sich viel besser: Hier kann man auch die ideale Zeilenlänge von 70-80 Buchstaben erreichen.

Die Diskussion hatten wir ja schon mal. Man kann Schrift sowohl in px als auch in em zu klein machen.

In em hat man den vermeintlichen "Vorteil", dass der Benutzer des IE 6 die Schrift dann immerhin noch in zwei Stufen wieder größer schrauben kann - was ihm eventuell immer noch zu klein ist.

Im Firefox zoomt man sowohl px als auch em. Aber nur bezogen auf Schriftgrößen. Breiten- und Höhenangaben in px bleiben unbeeinflußt.

In Opera zoomt man alles größer. Auch Breiten, Höhen und alle Grafiken.

Die Anzeigebasis für Webseiten ist also schon mal grundsätzlich sehr unterschiedlich. Wenn da jetzt der CSS-Autor noch versucht, irgendwie sinnvoll durch Auswahl von eigenen Werten und Maßeinheiten zurückzukoppeln, kann das unter dem Strich eigentlich nur schiefgehen.

Deswegen habe ich dich auch wegen der Skalibarkeit kritisiert. Wenn ich eine Webseite zoome möchte ich keine 10-Zeichen-Zeilen sehen, sonder den Text immernoch gut lesbar haben.

Klarer Fall von "falschen Browser zum Zoomen verwendet". ;->

- Sven Rautenberg

[Daniel unreg]

Hallo,

Die Diskussion hatten wir ja schon mal. Man kann Schrift sowohl in px als auch in em zu klein machen.

Ja, insgesamt muss das Design dafür gemacht werden, nur die Schrift in einem bestimmten Maß anzugeben bringt nicht viel.

In Opera zoomt man alles größer. Auch Breiten, Höhen und alle Grafiken.

Ab Firefox 3 auch, obwohl mann dann auch noch den alten text-Zoom einstellen kann. Es wird aber dafür sicher auch eine Erweiterung geben^^

Gruß;

[Der Martin]

Hallo Valentin,

Nur deine Standardschrift für den Fließtext finde ich [...] einfach winzig.

Vor dir hatte schon jemand anderes gesagt, dass er die Schriftgröße winzig finde. Mich überrascht das ehrlich gesagt. Es handelt sich nämlich um eine "Standardgröße", die auf sehr vielen (großen) Websites verwendet wird. Schriftgröße 12 Pixel, Zeilenabstand 20 Pixel. Die Schriftgröße hier im Forum sieht mir ebenfalls stark nach 12 Pixeln aus. Findest du demnach die Schriftgrößen im Web allgemein zu klein oder ist es dir nur speziell auf meiner Website aufgefallen?

Sagen wir's so: Es ist mir bei deiner Seite besonders aufgefallen - vielleicht deshalb, weil du die Schriftgröße in px angibst und sie sich deshalb nicht meinen persönlichen Defaulteinstellungen im IE anpassen kann. Aber generell: Ja, mir ist die Schrift auf den meisten Websites zu klein. Ich persönlich halte eine Größe von 15..16px als Standardschrift für gerade richtig, deine 12px würde ich höchstens noch "fürs Kleingedruckte" nehmen.
Allerdings wurde hier auch schon oft thematisiert, dass man Schriftgrößen doch besser in em oder % angeben solle, weil dann die Defaulteinstellung des Anwenders auch zum Tragen kommt.

In den Referenzen fällt mir mymemopad.de auf; ich erinnere mich dunkel, dass du das Konzept vor einiger Zeit mal hier zur Diskussion gestellt hast, und ich hatte kritisiert, dass mir eine solche web-basierte Applikation suspekt wäre, sie stieß aber allgemein auf recht positive Resonanz.

Ja, da hast du Recht. Über myMemopad wurde hier schon mal diskutiert. Aber ob einem solche Webapplikationen suspekt erscheinen oder nicht, man kann sich anhand ihr trotz alledem ein Bild von meinen Fähigkeiten machen

Logisch, das wollte ich auch gar nicht abstreiten. Vom technischen Standpunkt her finde ich diese Webapplikation auch recht gelungen und überzeugend. Ich meinte damit nur: *Ich* würde so etwas nicht benutzen wollen.

Deine Devise, (X)HTML als das zu verwenden, wofür es ursprünglich gedacht ist, und Inhalt und Layout konsequent zu trennen, finde ich gut, genauso wie ich als Sonderling und überzeugter IE5.5-Nutzer anerkenne, dass du diesen alten Browser noch ausdrücklich mit unterstützt.

Ehrlich gesagt bin ich jetzt doch überrascht, dass ich mit meiner Website einem IE5.5-Nutzer begegne. Da hat sich die IE5.5-Untersützung ja richtig gelohnt. ;-)

Aber gern doch. :-)
Ich bin es allerdings schon gewöhnt und akzeptiere es, dass dieser Dinosaurier unter den Browsern hier und da ignoriert wird und manche Seiten fehlerhaft dargestellt werden. Damit habe ich auch kein Problem, solange die *Information* an sich zugänglich bleibt.

Schönen Sonntag noch,
 Martin

[Daniel unreg]

Hallo,

Aber gern doch. :-)
Ich bin es allerdings schon gewöhnt und akzeptiere es, dass dieser Dinosaurier unter den Browsern hier und da ignoriert wird und manche Seiten fehlerhaft dargestellt werden. Damit habe ich auch kein Problem, solange die *Information* an sich zugänglich bleibt.

Darf man denn Fragen, aus welchen gründen du noch IE 5.5 verwendest und keine neuere Version bzw. einen alternativen Browser?

Gruß;

[Der Martin]

Hi,

Darf man denn Fragen, aus welchen gründen du noch IE 5.5 verwendest und keine neuere Version bzw. einen alternativen Browser?

natürlich darf man - auch wenn ich das schon ein paarmal dargelegt habe.

1. Warum IE?
Weil mich die komfortable und nahtlose Integration in die Windows-Shell überzeugt, z.B. die Bookmarks (aka "Favoriten") direkt im Startmenü, oder die Einstellungen an zentraler Stelle direkt in der Systemsteuerung.

2. Warum Version 5.5?
Weil der IE6 im Vergleich zum 5.5er ziemlich buggy ist - die meisten derzeit vom IE6 bekannten IE-Bugs treten im IE5.5 nicht auf. Und der 7er schließt sich automatisch dadurch aus, dass er unter Win2k nicht läuft.

3. Alternativen
Ab und zu, wenn eine Seite mit IE5.5 wirklich deutliche Probleme macht, benutze ich auch den Opera; wenn's unbedingt sein muss (beispielsweise für Testzwecke) auch den Firefox. Leider gibt es für den IE5.5 und den Opera nichts Vergleichbares wie die LiveHTTP-Extension des Firefox, also muss er gelegentlich mal ran.

So long,
 Martin

[Kai345]

Grütze .. äh ... Grüße!

2. Warum Version 5.5?
   Weil der IE6 im Vergleich zum 5.5er ziemlich buggy ist - die meisten derzeit vom IE6 bekannten IE-Bugs treten im IE5.5 nicht auf.

Stimmt. Ich war sehr überrascht, wie wenig (mal vom Javascript abgesehen) Anpassungen ich auf meiner Site für der IE5.5 machen mußte.

3. Alternativen
   Ab und zu, wenn eine Seite mit IE5.5 wirklich deutliche Probleme macht, benutze ich auch den Opera; wenn's unbedingt sein muss (beispielsweise für Testzwecke) auch den Firefox. Leider gibt es für den IE5.5 und den Opera nichts Vergleichbares wie die LiveHTTP-Extension des Firefox, also muss er gelegentlich mal ran.

Ich kenne jetzt den Funktions-Umfang von LiveHTTP nicht, aber zumindest die wichtigsten Headerdaten kann man mit Operas Developer Console auch anzeigen.

Cü
Kai

[Daniel unreg]

Hallo,

1. Warum IE?
   Weil mich die komfortable und nahtlose Integration in die Windows-Shell überzeugt, z.B. die Bookmarks (aka "Favoriten") direkt im Startmenü, oder die Einstellungen an zentraler Stelle direkt in der Systemsteuerung.

Hm, na warte bis die EU das verbietet^^ Man kann auch die Adressleiste in der Task Bar auf Firefox einstellen ;)

Und zumindest Firefox 3 wird sich besser ins System einfügen, da mit Windows-Komponenten gerendert wird. Darüberhinaus ist ja die Favoritenverwaltung im IE selbst schon ein Dino, also mir wäre das zu kompliziert erst im Starmenü nen eintrag suchen, wenn ich es für mich selbst auch einfacher haben kann.

Insgesamt finde ich aber Opera auch wegend er Lesezeichen recht gut.

Da haben wir wohl deutliche Meinungsunterschiede.

2. Warum Version 5.5?
   Weil der IE6 im Vergleich zum 5.5er ziemlich buggy ist - die meisten derzeit vom IE6 bekannten IE-Bugs treten im IE5.5 nicht auf. Und der 7er schließt sich automatisch dadurch aus, dass er unter Win2k nicht läuft.

Naja, aber als Anwender bekommst von den bugs ja eh nichts mit. Oder welche Bugs meinst du?

Gruß;

[Der Martin]

Hi,

1. Warum IE?
   Weil mich die komfortable und nahtlose Integration in die Windows-Shell überzeugt, z.B. die Bookmarks (aka "Favoriten") direkt im Startmenü, oder die Einstellungen an zentraler Stelle direkt in der Systemsteuerung.
   Hm, na warte bis die EU das verbietet^^ Man kann auch die Adressleiste in der Task Bar auf Firefox einstellen ;)

natürlich, die Eingabe einer URL in einer beliebig angeordneten Adressleiste in der Windows-Shell öffnet eben diese URL im Standardbrowser. Wenn das dann der Firefox ist ...

Darüberhinaus ist ja die Favoritenverwaltung im IE selbst schon ein Dino, also mir wäre das zu kompliziert erst im Starmenü nen eintrag suchen, wenn ich es für mich selbst auch einfacher haben kann.

Einfacher?? Im Gegenteil. Nutze ich *nicht* den IE, dann brauche ich einen Schritt mehr: Ich muss erst den Browser starten, und dann innerhalb des Browsers einen Bookmark-Eintrag abrufen. Suche ich mir den Eintrag direkt aus dem Startmenü, entfällt der separate Aufruf des Browsers, das macht Windows für mich.

Da haben wir wohl deutliche Meinungsunterschiede.

Offensichtlich. :-)

die meisten derzeit vom IE6 bekannten IE-Bugs treten im IE5.5 nicht auf.
Naja, aber als Anwender bekommst von den bugs ja eh nichts mit. Oder welche Bugs meinst du?

Doch, gerade als Anwender kriege ich die Bugs ja brühwarm mit, wenn Seiten nicht korrekt dargestellt werden. Ganz abgesehen von denjenigen Bugs, die nicht die Rendering Engine betreffen, sondern die Bedienoberfläche. So kann ich im IE6, solange die Seite noch nicht fertig geladen ist, zwar schon das Kontextmenü aufrufen, die Auswahl eines Befehls wird aber ignoriert. Da komme ich mir dann veräppelt vor. Und so praktische Sachen wie die Eingabe von Benutzername und Passwort in der URL bei HTTP-AUTH-gesicherten Seiten muss man sich auch erst wieder über einen Registry-Eintrag freischalten.
Deswegen habe ich seinerzeit, als der IE6 neu war, keinen Vorteil gegenüber seinem Vorgänger gefunden.

So long,
 Martin

[Daniel unreg]

Hallo,

Einfacher?? Im Gegenteil. Nutze ich *nicht* den IE, dann brauche ich einen Schritt mehr: Ich muss erst den Browser starten, und dann innerhalb des Browsers einen Bookmark-Eintrag abrufen. Suche ich mir den Eintrag direkt aus dem Startmenü, entfällt der separate Aufruf des Browsers, das macht Windows für mich.

Naja, ob ich jetzt das startmenü öffne oder den browser macht nicht so viel aus. Ich bin mit meinem Browser (Firefox) getestet schneller dran als mit IEs Favoriten.

Doch, gerade als Anwender kriege ich die Bugs ja brühwarm mit, wenn Seiten nicht korrekt dargestellt werden. Ganz abgesehen von denjenigen Bugs, die nicht die Rendering Engine betreffen, sondern die Bedienoberfläche. So kann ich im IE6, solange die Seite noch nicht fertig geladen ist, zwar schon das Kontextmenü aufrufen, die Auswahl eines Befehls wird aber ignoriert. Da komme ich mir dann veräppelt vor. Und so praktische Sachen wie die Eingabe von Benutzername und Passwort in der URL bei HTTP-AUTH-gesicherten Seiten muss man sich auch erst wieder über einen Registry-Eintrag freischalten.

Seitenfehler kann man aber nicht zählen, die wären Im IE 5.5 nicht weniger als im IE6.

Gut, Firefox macht auch ein paar Kontext-Probleme, aber Opera müsste das nicht haben. Egal.

Das mit dem HTTP-Auth machen die anderen beiden eigentlich auch oder? Bin zu sehr Autofill-verwöhnt^^

Gruß;

[Der Martin]

Hi,

Naja, ob ich jetzt das startmenü öffne oder den browser macht nicht so viel aus.

nee, aber du musst ja den Browser öffnen *und* dann noch einen Bookmark-Eintrag auswählen. Ich hab nur einen Klick.

Das mit dem HTTP-Auth machen die anderen beiden eigentlich auch oder?

Nein, die akzeptieren die (nicht standardkonforme) URL-Notation http://user:[e-mail]/, fragen aber nochmal nach: "Sie sind im Begriff, sich ... anzumelden.", und dann muss ich das nochmal bestätigen. Das ist auch lästig und müsste IMHO nicht sein, aber der IE6 macht ja in der Defaultkonfiguration nicht einmal das.

Bin zu sehr Autofill-verwöhnt^^

Das mag ich nun wieder gar nicht ... ;-)

Ciao,
 Martin

[Daniel unreg]

Hallo,

nee, aber du musst ja den Browser öffnen *und* dann noch einen Bookmark-Eintrag auswählen. Ich hab nur einen Klick.

Und du muss *zuvor* das Startmenü öffnen und den Eintrag wählen. Das ist nicht mehr arbeit.

Nein, die akzeptieren die (nicht standardkonforme) URL-Notation http://user:[e-mail]/, fragen aber nochmal nach: "Sie sind im Begriff, sich ... anzumelden.", und dann muss ich das nochmal bestätigen. Das ist auch lästig und müsste IMHO nicht sein, aber der IE6 macht ja in der Defaultkonfiguration nicht einmal das.

Ob das konform ist weis ich nicht, ich arbeite auch nicht genug damit um da ein Urteil bilden zu können. Ich bleibe ein IE-5.5-Gegner.

Gruß;

[Maik W. aus E.]

Tach auch Valentin,

Du hast Dir ein Statement zur Erscheinung Deiner Website gewünscht, dann bekommst Du es auch...
Der erste Eindruck ist "solide". Der zweite ist schon "eher dröge"... Dieses "Kasten in der Mitte" hab' ich einfach schon zu oft gesehen, schade auch, daß er seine größte Stärke, das Skalieren nicht ausspielt.
Ich selbst bin einer, der Texte liest, wenn sie irgendwo stehen, Du hast viel Text auf den Seiten, der gut und lesenswert ist, gehe aber  davon aus, daß der Normal-Nutzer das aber nicht tut. (Ich weiß, wovon ich rede und rege mich regelmäßig über Leute auf, die Hinweistexte nicht lesen und sich dann beklagen.)
Versuch einfach die Texte zusammenzufassen oder Kurz-Lang-Versionen anzubieten, damit man einen Überblick bekommt und/oder Genaueres lesen kann.

da ich mir in nicht allzu ferner Zukunft mein Taschengeld ein wenig durch Webdesign aufbessern möchte.

Nimm "Webentwicklung" und Du wärst direkt ein Kandidat...

Die Adresse zu meiner Website lautet: http://valentinbuchhold.com

Kleiner Tip am Rande: Links gehen so

http://www.gruss-aus-essen.de

Maik

[Patrick Andrieu]

Hallo Maik!

Du hast viel Text auf den Seiten, der gut und lesenswert ist, gehe aber  davon aus, daß der Normal-Nutzer das aber nicht tut. (Ich weiß, wovon ich rede und rege mich regelmäßig über Leute auf, die Hinweistexte nicht lesen und sich dann beklagen.)

Wie wahr. Wie oft kam unter den selten Feedback gebenden Besuchern: »Muss ich das alles lesen?« - und wenn da noch bunte, anklikcbare Grafiken sind, werden sie so lange angeklickt, bis der User vergessen hat, warum er die Seite(n) aufgesucht hat ;)

@Valentin: Die Seiten gefallen mir, die Schrift ist allerdings im IE über Ansicht/Schriftgrad nicht skalierbar, für mich aber noch lesbar, für andere User vielleicht nicht (eine px vs. em-Diskussion möchte ich hier allerdings nicht auslösen - ich selbst nutze auch px).

Noch eine Anmerkung: Ich nehme an, dass Du mit Deiner Arbeit Geld verdienen willst. Abgesehen davon, dass Du Deine Skripte kostenlos anbietest (was sehr schön ist), kommt auf den Seiten die »Dienstleistung« nicht genug zum Vorschein. Später, wenn Deine Seiten bei Google ein gutes Ranking erreichen, werden vielleicht Besucher kommen, die Deine Arbeit in Anspruch nehmen wollen. Das müsste auch irgendwie vermittelt werden. Wenn es nicht der Fall ist (also, wenn Du Dich nicht als Dienstleister anbietest oder anbieten willst), müsste es auch klar hervorkommen (meine Meinung).

Viele Grüße aus Frankfurt/Main,
Patrick

[Valentin_]

Tach auch Valentin,

Hallo Maik,

Der erste Eindruck ist "solide". Der zweite ist schon "eher dröge"... Dieses "Kasten in der Mitte" hab' ich einfach schon zu oft gesehen, schade auch, daß er seine größte Stärke, das Skalieren nicht ausspielt.

Die Frage ist doch, was die Alternativen zum "Kasten in der Mitte" sind. Ein Kasten am linken oder rechten Rand wirkt wesentlich "schlimmer". Den Hauptpreis gewinnt außerdem derjenige, der sich solch eine links- oder rechtbündige Website auch noch mit einem Breitbildmonitor anschaut. Des Weiteren gäbe es noch die Möglichkeit, gar keinen "Kasten" zu verwenden, sondern einfach die komplette Monitorfläche zu nutzen. Dafür haben aber die wenigsten Websites genügend Inhalte. Außerdem ist hier ebenfalls wieder das Problem Breitbildmonitor. Die Lesbarkeit der Texte geht auf solchen Monitoren stark gegen Null, wenn die volle Breite genutzt wird. Ich finde deshalb für die meisten Websites einen zentrierten "Kasten" noch am besten.

Ich selbst bin einer, der Texte liest, wenn sie irgendwo stehen, Du hast viel Text auf den Seiten, der gut und lesenswert ist, gehe aber  davon aus, daß der Normal-Nutzer das aber nicht tut. (Ich weiß, wovon ich rede und rege mich regelmäßig über Leute auf, die Hinweistexte nicht lesen und sich dann beklagen.)

Hm, ich dachte eigentlich, dass ich nicht soo viel Text hätte - zumindest nicht zu viel. Aber wenn du meinst, werde ich mir mal Gedanken darüber machen.

Nimm "Webentwicklung" und Du wärst direkt ein Kandidat...

Danke für das Kompliment. ;-)

Maik

Liebe Grüße zurück.

[Maik W. aus E.]

Tach auch Valentin,

Die Frage ist doch, was die Alternativen zum "Kasten in der Mitte" sind.

[...]
Das stimmt, allerdings auf technischer Seite. Hier gibt es nicht wirklich Alternativen, hier ist der Kasten in der Mitte status quo.
Es ging eigentlich auch in die gestalterische Richtung, nämlich einen "Kasten in der Mitte" zu bauen, der nicht aussieht, wie dem nächstbesten Template-System entsprungen, sondern einen, der etwas Eigenes, etwas Besonderes hat.

Hm, ich dachte eigentlich, dass ich nicht soo viel Text hätte - zumindest nicht zu viel. Aber wenn du meinst, werde ich mir mal Gedanken darüber machen.

Ich finde es sehr charmant, daß Du konsequent auf "Buzz-Words" verzichtest, fürchte aber, daß Deine Texte den Normal-Nutzer schnell langweilen. Patrick schrieb schon ganz richtig, daß Du mehr Wert auf den Dienstleitstungsaspekt legen solltest, die große Kunst dabei ist mMn, komplexe technische Sachverhalte massen-kompatibel zu verkaufen.

http://www.gruss-aus-essen.de

Maik

[ottogal]

Hallo Valentin,

ich würde nach einem spannenderen Hintergrundbild für den header suchen: Der blaue Himmel mit Wölkchen erinnert so an die Windows-Desktops von anno dunnemals - das reißt nicht vom Hocker...

Gruß
ottogal

[Gunnar Bittersmann]

Hello out there!

ich würde gerne ein paar Meinungen und ggf. Verbesserungsvorschläge für meine Website einholen.

„Verlinke niemals auf die aktuelle Seite.“ (Punkt 10 der zehn meist-missachteten Homepage-Design-Richtlinien [Nielsen])

See ya up the road,
Gunnar

[Valentin_]

Hello out there!

Hallo Gunnar,

"Verlinke niemals auf die aktuelle Seite." (Punkt 10 der zehn meist-missachteten Homepage-Design-Richtlinien [Nielsen])

Hm, der Artikel argumentiert für mich nicht überzeugend genug. Dort wird scheinbar von dem dümmsten anzunehmenden Nutzer ausgegangen. Wenn ich als Nutzer auf eine Schaltfläche mit dem Namen News klicke und es öffnet sich daraufhin eine Seite mit der dicken Überschrift News, dann bin ich doch nicht verwirrt und frage mich, ob ich wirklich auf der Seite News bin, nur weil die Schaltfläche News (die sich obendrein wohlgemerkt in der Navigation befindet) immer noch anklickbar ist. Ich halte es durchaus für vertretbar, von meinen Nutzern ein Minimum an Intellekt zu erwarten.

Ich könnte nämlich auch gerade gegen den Artikel argumentieren. Der entsprechende Text würde dann nämlich wie ein Link aussehen und sich wie ein Link verhalten, aber keiner sein. Sorgt das nicht für noch viel mehr Verwirrung bei den Nutzern?

Liebe Grüße.

[Gunnar Bittersmann]

Hello out there!

"Verlinke niemals auf die aktuelle Seite." (Punkt 10 der zehn meist-missachteten Homepage-Design-Richtlinien [Nielsen])

Hm, der Artikel argumentiert für mich nicht überzeugend genug. Dort wird scheinbar von dem dümmsten anzunehmenden Nutzer ausgegangen.

Das schadet in den seltensten Fällen, sondern kommt meist allen Nutzern zugute.

Ich könnte nämlich auch gerade gegen den Artikel argumentieren. Der entsprechende Text würde dann nämlich wie ein Link aussehen und sich wie ein Link verhalten

Nein, eben nicht. Andere Farbe als die verlinkten Menüpunkte, der Cursor ändert sich nicht beim Überfahren mit der Maus.

See ya up the road,
Gunnar