Cybaer: Preis für Homepage und Überzeugungsarbeit für Validität

Beitrag lesen

Hi,

<FONT> & Co. mögen da zwar auch drunter fallen (gleichwohl: "unerwünscht" heißt ja nicht "ungültig"!),
Der entscheidende Punkt ist, dass unfähig gegenüber neueren Techniken sind, schlichtweg ineffizient.

Da wirst Du von mir auch keinen Widerspruch hören. =:-)

Das betrifft höchstens Browser aus 1993, das ist wirklich zu krass.

Stört aber auch keinen.

»Erkennung von Tabellen abgeschaltet« - alle Browser, die meines Wissens dazu fähig sind, linearisieren problemlos ohne br-Elemente am Zellenende.

Vielleicht, vielleicht auch nicht. Und bei den "Gurken", die z.B. die Opera-Programmierer in schöner Endlosigkeit in ihre Software basteln, gehe ich lieber sicher (prinzipiell stimme ich Dir aber zu: Ich würde auch nie sagen, daß jemand schlecht codet, nur weil er solche "Alt-Petitessen" nicht macht =;-)).

  • WBR nach Trennungsstrich im Wort ("unvalide" da proprietär: Beliebte Browser brechen den Text besser um)
    Dazu gibt es kompatiblere CSS-Möglichkeiten.

Für CSS-Browser. Aber egal: Gibt es? Cool, habe ich übersehen. Wonach muß ich suchen?

Was ist am Umbruch so schlimm?

Nix. Aber der Nicht-Umbruch geht mir auf den Senkel, da ein entsprechend häufigerer Umbruch im Blocksatz harmonischer wirkt, und ansonsten der Rand nicht so ausgefranst ist (aber war ja nur ein Beispiel).

  • H1-H6 statt der insbesondere von "WYSIWYG"-Editoren gerne genutzten FONT- und CSS-Elementen (*mächtig* "valide ;-) - dieSuchmaschnenen freut es zudem)
    Was ist an dieser Technik alt?

Aus deiner und meiner Sicht: Nichts.

Aus der Sicht vieler heutiger, unerfahrenerer Web-Autoren, sieht das mitunter leider, leider ganz anders aus. :-((

Es ist irreführend, zu verbreiten, dass jeder proprietäre HTML-Dialekt einer Firma gleichwertig mit den öffentlichen, herstellerübergreifenden HTML-Standards ist und es ganz gleich ist, ob man sich daran orientiert oder nicht.

Ich denke nicht, daß ich das verbreite. Ich denke vielmehr, daß ich verbreite, daß öfentliches, herstellerübergreifendes HTML die Regel ist, der es nicht "wehtut", wenn man auch proprietäre Elemente mit Bedacht verwendet.

Sicherlich kann sich jeder eine eigene DTD schreiben (bei jder SGML-Sprache, wie gesagt) und Dokumente schreiben, die gegen diese validieren. Doch das ist gar nicht die Frage.

Nicht deine Frage, aber meine "Frage".

Das sollte dir zeigen, dass sie davon ausgehen, dass die Browser Dokumente erwarten, die öffentlichen und den Browsern bekannten Standards folgen und sich als solche Dokumente ausweisen.

Und das in Verbindung mit einem Microschrott-Produkt - ich fall gleich hintenüber ... =;-)

Streiche "Standards folgen", setze "herumdilettieren". ;->

Und im Bezug auf HTML ist das W3C federführend und vereinigt die Interessen verschiedener namhafter Firmen und Organisationen in den HTML-Standards.

... die nachwievor diese Standards (CSS inklusive) fleissig proprietär erweitern (zumal das W3C doch ohnehin kein bindendes Normierungs-Institut a la ISO oder DIN ist, oder?)

Jaja, ein rhetorischer Trick, kein sachliches Argument. Wenn ein Dokument sich proprietären Markups bedient und dies hier angezweifelt wird, hat nichts mit Theorie und Bürokratie zu tun, sondern in der Regel mit tatsächlich fehlender Kompatibilität und mangelnder Nachhaltigkeit.

Über einen bestimmten Fall läßt sich reden, mit der Schrotflinte auf alles schießen, was sich bewegt, ist IMHO seltenst eine adäquate Handlung ... =:-o

Das hat wie gesagt wenig damit zu tun, ob effiziente, zukunftssichere und über den Tellerrand hinaus funktionsfähige Techniken eingesetzt werden.

Maxime 1: Stört es irgendeinen HTML-Browser?
Maxime 2: Könnte es einen zukünftigen HTML-Browser stören?
Maxime 3: Bringt es mir/dem Surfer einen Nutzen?

Wenn ich Webseiten für die Theorie machen müßte, sähen siegewiß anders aus. Müßiges Diskussionsobjekt ...
Nein, ganz und gar nicht. Zwischen Theorie und Praxis bestehen nicht nur einseitige Wirkungszusammenhänge.

Nun denn, die Standpunkte dürften hinreichend theoretisiert sein. :-)

Zeige mir doch einfach an Beispielen, wo ich proprietären/invaliden Code verwende, der sich nicht nur in d(ein)er Theorie, sondern in der Praxis negativ auswirkt (bzw. ggf. zukünftig negativ auswirken könnte). Bei einem Code, der prinzipiell darauf ausgelegt ist, auf "1993er-Browsern" nutzbar zu sein, und alle (D)HTML/CSS/Script-Neuerungen nur optional nutzt, aber nicht zwingend darauf angewiesen ist, würde mich das echt interessieren ... :-o

Gruß & schönes WE, Cybaer