nicht angemeldet cartun
molily
molily
molily
molily
Der Martin
Der Martin
molily
Gunnar Bittersmann
Gunnar Bittersmann
Tim Tepaße
molily
rfb
ich bitte euch um eure meinung:
ich soll für ein relativ umfangreiches webprojekt (inkl. cms, in dem eigene scriptteile redaktionell eingebunden werden können, also nicht 0815-lösung).
ich bekam mehrere anbieter zur auswahl, die behaupteten, meinen anforderungen nach w3c-validem code und barrierefreiheit nachkommen zu können.
nur: keiner von denen hat in seinen bisherigen referenzen wirklich valide seiten.
jetzt frage ich mich: wird das allgemein in der branche so wenig ernst genommen? kümmern sich da wirklich nur (selfhtml-) freaks darum?
und, es kommt noch besser: zwecks spass havb ich mir mal die goldene-biene-gewinner unter die lupe genommen. und, siehe da: kaum etwas ist (mehr) valide!
meine ffragen daher:
1. sollte man das etwa nicht so eng sehen?
2. wenn doch, wo sind die designer, die sowas können? meldet euch!
Rob
Hi,
- sollte man das etwa nicht so eng sehen?
- wenn doch, wo sind die designer, die sowas können? meldet euch!
doch, also ich halte mich bei der erstellung von Webseiten generell an Valides XHTML Strict.
Anfangs war mir das egal doch nun geht ohne meiner prüfen "auf Valides" XHTML nichts mehr....
Anfangs war mir das egal doch nun geht ohne meiner prüfen "auf Valides" XHTML nichts mehr....
auch bei großen projekten mit cms?
Hallo,
auch bei großen projekten mit cms?
Gerade hierbei, denn ein CMS, das beim einen oder anderen Benutzer irgendwelche "Nebenerscheinungen" in der Darstellung hervorruft, kann wohl kaum Sinn der Sache sein.
Markus
Moin!
Anfangs war mir das egal doch nun geht ohne meiner prüfen "auf Valides" XHTML nichts mehr....
auch bei großen projekten mit cms?
Gerade da ist es doch recht einfach, validen Code für das ganze Projekt zu erzeugen.
Schönen Sonntag,
Robert
Hallo,
nur: keiner von denen hat in seinen bisherigen referenzen wirklich valide seiten.
kann ja u.a. auch an den Vorgaben des Auftraggebers liegen.
jetzt frage ich mich: wird das allgemein in der branche so wenig ernst genommen?
Vermutlich wird es, wenn überhaupt, von der Gesellschaft "wenig
ernst" genommen und wenig nachgefragt.
Grüsse
Cyx23
Hi there,
jetzt frage ich mich: wird das allgemein in der branche so wenig ernst genommen? kümmern sich da wirklich nur (selfhtml-) freaks darum?
Imho ja. Denn wo liegt denn der eigentliche Vorteil von validen Seiten? Nicht dort, wo der Kunde oder gar der "Webdesigner" einen Mehrwert sieht oder auch wirklich hat, wobei der Mehrwert für den Ersteller der Seite noch eher gegeben wäre; wenn es wegen Darstellungsfehlern zu Differenzen mit dem Kunden kommt, kann der Ersteller der Seite sich immerhin noch darauf ausreden, sich an Standards gehalten zu haben. Nur - das wiederum ist dem Kunden in 99% der Fälle sowas von egal. Der will, daß die Seite in _seinem_ Browser gut aussieht, alles andere interessiert ihn herzlich wenig...
Hallo,
Imho ja. Denn wo liegt denn der eigentliche Vorteil von validen Seiten?
Validität stellt sich als Folge von verschiedenen Vorkehrungen ein, die sehrwohl einen Mehrwert bringen. Wenn ich eine technisch solide Site entwickle, deren Informationen gut strukturiert, deren Texte sinnvoll ausgezeichnet sind, deren Aufbau für Styles und Scripte voraussehbar ist, kommt (auch notwendig) weitesgehend fehlerfreier Code heraus. Wenn Fehler verbleiben, so müssen diese gegebenenfalls ausgeräumt werden, damit die Funktionsfähigkeit gewährleistet ist.
wenn es wegen Darstellungsfehlern zu Differenzen mit dem Kunden kommt, kann der Ersteller der Seite sich immerhin noch darauf ausreden, sich an Standards gehalten zu haben.
Validität ist syntaktische Fehlerfreiheit hinsichtlich einer maschinenlesbaren Grammatik - mehr nicht. Sinnvolle und korrekte Anwendung der Webstandards ist etwas anderes. Genauso die Frage, ob die Site in verschiedenen Browsern ein gebrauchstaugliches, vorhersehbares Resultat erzeugt. Um beides muss man sich gesondert kümmern.
Mathias
Hi there,
Imho ja. Denn wo liegt denn der eigentliche Vorteil von validen Seiten?
Validität stellt sich als Folge von verschiedenen Vorkehrungen ein, die sehrwohl einen Mehrwert bringen. [...]
_Ich_ kenne den Mehrwert valider Seiten. Es ging um die Frage, ob Validität in der Praxis eine Rolle spielt, und das ist aus meiner Sicht einfach zu verneinen. Wie anders wäre es sonst zu erklären, daß die meistbesuchten Seiten komplett invalide Seiten beherbergen?
Egal was Du Dir ansiehst, ob es der "Spiegel" ist, in der Schweiz die NZZ, in Österreich der "Standard", die sind offenbar an Validität sowas von nicht interessiert und vermutlich auch nicht deren Besucher. (Wobei mir klar ist, daß das vermutlich an den CMS und Redaktionssystemen liegt, die die verwenden, was aber nicht bedeutet, daß die nicht auch valide Seiten produzieren könnten, nur, wie gesagt, es ist ihnen offenbar egal und sie leben gut damit...)
Hallo,
Wie anders wäre es sonst zu erklären, daß die meistbesuchten Seiten komplett invalide Seiten beherbergen?
Natürlich scheren sich auch die meistbesuchten Sites darum, denn fehlerhafter Code kann nicht funktionsfähiger Code sein. Es hat schon seinen Grund, warum die meisten Fehler, die man auf solchen Sites findet, in der Praxis vergleichsweise harmlos sind.
Der Code von Spiegel Online z.B. ist durchaus valide, in den Punkten, wo es unbedingt praxisrelevant ist. Wäre er es nicht, würde Spiegel das schnell ändern. Die Fehler beschränken sich allesamt auf Punkte, wo der Browsertoleranz vertraut werden kann. Das sind dann so Fehler wie kleine Portionen XHTML-Syntax in HTML 4 oder umgekehrt, fehlende &-Maskierung, fehlende alt-Attribute und ein paar proprietäre Attribute.
Bei diesen dummen kleinen Fehlern können sich die Autoren ziemlich sicher sein, dass sie, wenn überhaupt, nichts großes kaputtmachen. Schwerwiegend wären grobe Syntaxfehler, die zu einem unerwünschten DOM-Baum führen. Auf so etwas wird durchaus geachtet, denn früher oder später geht das nach hinten los.
Mathias
Hi there,
Natürlich scheren sich auch die meistbesuchten Sites darum, denn fehlerhafter Code kann nicht funktionsfähiger Code sein. Es hat schon seinen Grund, warum die meisten Fehler, die man auf solchen Sites findet, in der Praxis vergleichsweise harmlos sind.
Natürlich. Sonst wären diese Seiten auch allesamt nur eingeschränkt oder im Extremfall gar nicht zu betrachten. Trotzdem reduzieren wir die Validität auf Interpretationsfragen, wenn wir zwischen harmlosen, vergleichsweise harmlosen und nicht harmlosen Validitätsfehlern unterscheiden. Genau das aber führt Validitätsansprüche ad absurdum...
Hallo,
Trotzdem reduzieren wir die Validität auf Interpretationsfragen, wenn wir zwischen harmlosen, vergleichsweise harmlosen und nicht harmlosen Validitätsfehlern unterscheiden. Genau das aber führt Validitätsansprüche ad absurdum...
Find ich gar nicht schlimm, ein »harter« Validitätsanspruch ist m.M.n. sowieso absurd und Interpretation immer nötig. »Wir produzieren validen Code« oder »Site X hat (keinen) validen Code« sagt in meinen Augen tendenziell nichts über die Qualität von Websites aus.
Aber man kann diese Aussagen auch nicht wörtlich nehmen. Wenn eine Agentur oder ein Webworker behauptet, sie produzierten validen Code, dann ist damit meist wohl etwas gemeint, was nicht durch kleine Codefehler diskreditiert oder widerlegt werden kann: Nämlich dass allgemein auf aufgeräumten und fehlerfreien Code Wert gelegt wird, selbst wenn das CMS, fremder Code o.ä. hier und da harmlose Fehler bringen. Dann sollte man ehrlicherweise gegenüber Kunden nicht groß mit maschinell prüfbarer hunderprozentiger W3C-Validator-DTD-Validität werben... Aber »Barrierefreiheit« ist heutzutage ja auch vor allem ein Werbeversprechen. ;)
Mathias
Hi,
Trotzdem reduzieren wir die Validität auf Interpretationsfragen, wenn wir zwischen harmlosen, vergleichsweise harmlosen und nicht harmlosen Validitätsfehlern unterscheiden. Genau das aber führt Validitätsansprüche ad absurdum...
Wenn etwas nicht in ein Korsett paßt, vielleicht ist dann auch einfach das Korsett nicht so sinnvoll?!
Wenn jemand nur anhand eines Korsetts erkennen kannst, ob eine Seite taugt oder nicht, dann hat *er* ein Problem. Nicht die Seite und auch nicht das Korsett ...
Gruß, Cybaer
Hallo,
Egal was Du Dir ansiehst, ob es der "Spiegel" ist,
hab ich gerade mal angeschaut und fand den Code schon recht gut.
Eine merkwürdige Konstruktion ist mir zwar aufgefallen:
<a href="/spiegel/" style="color:black;">
<p style="margin:0 8px 6px 98px;">10/2007</p>
<p style="margin:0 8px 6px 98px; font-weight:bold;">Der Staat Gasprom</p>
<p style="margin:0 8px 6px 98px;">Putins Energie Imperium</p>
</a>
aber sonst schaut das m.E. schon ganz gut aus.
Problematischer wird es, wenn die Schriftgrösse erhöht wird, dann
zerlegt es irgendwann die Seite, ohne den ganzen Bildschirm zu
nutzen. Allerdings würde ich auch bei Barrierefreiheit nicht unbedingt
den Schwerpunkt darauf legen, dass sich die Schrift beliebig weit
vergrößern läßt. Zumal bei solchen Anforderungen an Flexibilität
gerade auch verpönte Konstrukte wie "Layout"-Tabellen u.U. derzeit
immer noch einige Vorteile bei der Zugänglichkeit gegenüber CSS
aufweisen können.
Grüsse
Cyx23
Hallo,
Eine merkwürdige Konstruktion ist mir zwar aufgefallen:
<a href="/spiegel/" style="color:black;">
<p style="margin:0 8px 6px 98px;">10/2007</p>
<p style="margin:0 8px 6px 98px; font-weight:bold;">Der Staat Gasprom</p>
<p style="margin:0 8px 6px 98px;">Putins Energie Imperium</p>
</a>
Du meinst das »Deppenleerzeichen«? ;)
Mathias
n'Abend!
Eine merkwürdige Konstruktion ist mir zwar aufgefallen:
<a href="/spiegel/" style="color:black;">
<p style="margin:0 8px 6px 98px;">10/2007</p>
<p style="margin:0 8px 6px 98px; font-weight:bold;">Der Staat Gasprom</p>
<p style="margin:0 8px 6px 98px;">Putins Energie Imperium</p>
</a>
> Du meinst das »Deppenleerzeichen«? ;)
Das vielleicht auch. Ich sehe da aber auch die drei p-Elemente als nicht erlaubte Blockelemente in einem Link.
So long,
Martin
--
F: Was sagt die kleine Kerze zur großen Kerze?
A: Ich gehe heute nacht aus!
Hi,
Eine merkwürdige Konstruktion ist mir zwar aufgefallen:
<a href="/spiegel/" style="color:black;">
<p style="margin:0 8px 6px 98px;">10/2007</p>
<p style="margin:0 8px 6px 98px; font-weight:bold;">Der Staat Gasprom</p>
<p style="margin:0 8px 6px 98px;">Putins Energie Imperium</p>
</a>
>
> Du meinst das »Deppenleerzeichen«? ;)
Was ist denn das??
Gruß!
Hallo!
Eine merkwürdige Konstruktion ist mir zwar aufgefallen:
<a href="/spiegel/" style="color:black;">
<p style="margin:0 8px 6px 98px;">10/2007</p>
<p style="margin:0 8px 6px 98px; font-weight:bold;">Der Staat Gasprom</p>
<p style="margin:0 8px 6px 98px;">Putins Energie Imperium</p>
</a> ^^^das hier
Du meinst das »Deppenleerzeichen«? ;)
Was ist denn das??
ciao, ww
Moin,
Du meinst das »Deppenleerzeichen«? ;)
Was ist denn das??
Ein Leerzeichen, wo keins hingehört. Stattdessen entweder ein Bindestrich oder überhaupt keine Trennung (Zusammenschreibung).
Ciao,
Martin
Hi there,
Imho ja. Denn wo liegt denn der eigentliche Vorteil von validen Seiten?
Validität stellt sich als Folge von verschiedenen Vorkehrungen ein, die sehrwohl einen Mehrwert bringen. [...]
_Ich_ kenne den Mehrwert valider Seiten. Es ging um die Frage, ob Validität in der Praxis eine Rolle spielt, und das ist aus meiner Sicht einfach zu verneinen. Wie anders wäre es sonst zu erklären, daß die meistbesuchten Seiten komplett invalide Seiten beherbergen?
Nun, ich sehe den Sinn von Validität auch in erster Linie darin, dass es maschienenlesbar wird. Bots können es sicherer durchsuchen, die Seiten lassen sich unkomplizierter in andere Formen (z.B. Buchform) konvertieren...
Egal was Du Dir ansiehst, ob es der "Spiegel" ist, in der Schweiz die NZZ, in Österreich der "Standard", die sind offenbar an Validität sowas von nicht interessiert und vermutlich auch nicht deren Besucher.
Das ist mir auch schon aufgefallen, Beispiele gewünscht?
Google (nicht mal ein DOCTYPE)
ebay international (auch keiner)
[http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.heise.de%2F@title=heise.de (schon besser, aber auch nicht gut)]
woran das liegt weiß ich auch nicht, die Google-Startseite kann jeder völlig valide und problemlos nachbauen, da ist ja nicht wirklich viel. Bei ebay kann ich es nachvollziehen, ein auch optisch so schlecht (mal im Ernst, wer mag denn die ebay-Startseite?), dass es vorstellbar ist, dass das valide nicht reproduzierbar ist. Bei heise.de sind zwar _bedeutend_ weniger Fehler, aber von einer technisch orientierten Seite hätte ich mir erhofft.
Nun aber zu _dem_ Positiv-Beispiel: Wikimedia! Das ist im Grunde ein großes CMS (nur halt für alle offen) und wie gesagt valide. Ok kleinere Abstriche... wikisource hat z.B. einen Fehler und einen Folgefehler, das trifft auch auf die Startseiten einiger anderer Wikimedia-Projekte zu (absoluter Verlierer ist Wikiquotes mit sehr "billigen" Fehlern, dass ich nicht weiß wie die da hin kommen).
Tja, der Punkt ist aber wie erwähnt, dass es sich hier ja um ein CMS (im weitesten Sinne) handelt und hier kommt auch der oben genannte Punkt zum Tragen, es ist hier durchaus wichtig, dass diese Seiten maschienenlesbar sind, denn gegebenenfalls will man das mal in eine Hilfedatei umsetzen...
Ich habe das mal mit eine _nicht_valieden_ Seite machen müssen, ich wollte nur das Design ändern, tja ich konnte da zwar vieles automatisieren (weil alle Seiten sehr ähnlich aufgebaut waren), aber mit validem Code wäre es einfacher gewesen, so waren noch viele nachträgliche Eingeriffe nötig.
Hallo,
ich bekam mehrere anbieter zur auswahl, die behaupteten, meinen anforderungen nach w3c-validem code und barrierefreiheit nachkommen zu können.
nur: keiner von denen hat in seinen bisherigen referenzen wirklich valide seiten.
Verwundert mich nicht sonderlich.
Zwischen nicht valide und nicht valide gibt es riesige Unterschiede, auf die es ankommt. Du kannst die Codequalität nicht über ein solches Ja/Nein-Kriterium beurteilen. Ein Validator kann dir höchstens dabei helfen, zu beurteilen, wie technisch solide die Arbeit eines Anbieters ist, indem du über die Fehlermeldungen Einsicht in die Machart des Codes bekommst. Wenn man sich den manuell anschaut, merkt man ziemlich schnell, ob der Autor Ahnung von Design nach dem Webstandards-Konzept und Barrierefreiheit hat. Der Validator kann nur syntaktische Fehler prüfen - solche passieren auch denjenigen, die auf korrekten Code Wert legen. Aber sie können genauso dafür stehen, dass sich der Autor einfach gar nicht mit sinnhaftem Code auseinandergesetzt hat. Was davon zutrifft, sagt dir nicht der Validator, sondern dein Verstand.
Mathias
Hi,
nur: keiner von denen hat in seinen bisherigen referenzen wirklich valide seiten.
Entweder Schludrigkeit oder mit Absicht. Invalide Webseiten sind (s. molily) nicht per se schlecht, genaosuwenig wie valide per se gut sind.
Es ist auch kein Problem, invalide Seiten zu schreiben, die überall funktionieren, wie es kein Problem ist, valide Seiten zu schreiben, die nirgends funktionieren.
jetzt frage ich mich: wird das allgemein in der branche so wenig ernst genommen? kümmern sich da wirklich nur (selfhtml-) freaks darum?
Es gibt tatsächlich auch SELFHTML-Freaks, die Validität nicht so ernst nehmen (wie anscheinend Du).
- sollte man das etwa nicht so eng sehen?
Das kommt auf die Gründe des Validätsverstoßes an.
- wenn doch, wo sind die designer, die sowas können? meldet euch!
Von einem Designer, der "fehlerlos" "nur" voll valide Seiten hinbekommt, würde ich nicht trauen. Ihm fehlt vermutlich die Erfahrung, während auch ein gut trainierter Affe solange aufs Knöpfchen drücken kann, bis (zufällig) der Vaidator mal "grün" anzeigt ... >:->
Mit anderen Worten: Erfahrung und Verstand kann immer noch nicht durch eine Maschine ersetzt werden!
Hello out there!
Das kommt auf die Gründe des Validätsverstoßes an.
Die da wären?
Was lässt sich nur mit Tag-Soup, nicht aber mit validem (X)HTML erreichen? (Wobei mit „Was“ nur für den Nutzer sinnvolle Dinge gemeint sind.)
See ya up the road,
Gunnar
Hi,
Das kommt auf die Gründe des Validätsverstoßes an.
Die da wären?
Proprietäre Tags & Attribute stören niemanden und nutzen nur.
Was lässt sich nur mit Tag-Soup, nicht aber mit validem (X)HTML erreichen?
Wie kommst Du auf die Idee, nur "Tag-Soup" würde zu invalidem Code führen? Da gibt es schon noch andere Dinge (s.o.) ...
Gruß, Cybaer
Hello out there!
Das kommt auf die Gründe des Validätsverstoßes an.
Die da wären?
Proprietäre Tags & Attribute stören niemanden und nutzen nur.
Die da wären?
Wie kommst Du auf die Idee, nur "Tag-Soup" würde zu invalidem Code führen? Da gibt es schon noch andere Dinge (s.o.) ...
Genau diese meinte ich mit Tag-Soup. Denn (X)HTML ist das ja nicht.
See ya up the road,
Gunnar
Hallo Gunnar, Cybaer,
Das kommt auf die Gründe des Validätsverstoßes an.
Die da wären?
Proprietäre Tags & Attribute stören niemanden und nutzen nur.
Die da wären?
Als die Diskussion das letzte Mal groß statt fand und molily und ich nachhakten, nannte Cybaer ein paar proprietäre, nicht valide Elemente, die er gerne nutzt. Ich war davon nicht wirklich überzeugt, aber nun gut, wir denken alle unterschiedlich.
Cybaer: Sieh es nicht als Angriff, sondern nur als neugierige Nachfrage. ;) Ich bin immer noch interessiert, was es für proprietäre Elemente gibt, die man nicht nutzen kann, wenn man dem Konzept Validität folgt. Ich finde da immer noch kaum Anwendungsfälle. Du redest gerne von Nutzen, bringst aber extrem selten Beispiele, die einen überzeugen können. Und ich bin wirklich kein eifriger Verfechter von DTD-Validität mehr.
(Wie damals stelle ich die Frage unter Ausschluss der Zukunftplanungen der WHAT WG und allein auf HTML bezogen)
Tim
Hi,
Cybaer: Sieh es nicht als Angriff, sondern nur als neugierige Nachfrage. ;)
Und wenn schon! Ich kann austeilen - ich kann auch einstecken! >;-)
Ich bin immer noch interessiert, was es für proprietäre Elemente gibt, die man nicht nutzen kann, wenn man dem Konzept Validität folgt.
? Du hast auf eine Liste verlinkt. Was denn noch? =;-)
Ich finde da immer noch kaum Anwendungsfälle.
Zumindest WBR nutze ich sehr oft.
Und da ich meistens so code, daß auch in älteren Browser noch "was hübsches" bei rauskommt, gilt das generell auch für deprecated Elemente. Wer da "valide" bleibt, wird sich seinen Teil dabei denken, und beim Kompromiß zw. "Fallback" und "Scheiß auf alte Browser - da reicht 'strukturiertes, nacktes HTML'" eben zu letzterem tendieren.
Das mag jeder halten, wie er mag (und bei meinem Code wird so mancher mit dem Kopfschütteln, wie ich es auch bei Web-Autoren tue, wenn z.B. der IE 5.x nicht mehr unterstützt wird), ist aber ja nicht die Frage. Die Frage war: Schadet es?
Und ich bin wirklich kein eifriger Verfechter von DTD-Validität mehr.
Ich bin ein *sehr großer* Verfechter der DTD-Validität! Und viele Fehler, die molily als "nicht so wild" aufgelistet hat, stoßen bei mir auch nicht auf das geringste Verständnis.
Der Unterschied: Die "Öffentlichkeit" (auch "ihr" hier) definiert "Validität" als Einhaltung der 3WC-DTD (und fälschlicherweise tun ja auch die üblichen Validatoren so, als wenn sie nur diese beachten würden, anstatt eine reale DTD zu verwenden, die dann auch nicht vom 3WC sein muß). Diese Begrenzung möchte ich nicht mitmachen.
Allerdings, und hier kommt dann die Erfahrung wieder ins Spiel: Egal ob Standard- oder Quirksmodus: man kann nicht in den aktuellen Browsern beliebig mit "eigenen" DTDs "rumsauen". ;-> Aber jeder Browser hat eben auch seine eigenen DTDs.
Man muß halt wissen, was geht, und was nicht. Und das von mir genannte geht halt - zumal es ja (sinnvollerweise) als Grund-Mantra (schon wg. Ab- & Aufwärtskompatibilität) den HTML-Browsern in die Wiege gelegt wurde ...
(Wie damals stelle ich die Frage unter Ausschluss der Zukunftplanungen der WHAT WG und allein auf HTML bezogen)
Warum sollte man da was ausschließen? Es ist die Stärke, daß *nicht* unterschieden werden muß zw. z.B. alt-proprietären Elementen (wie BLINK), 3WC-Elementen, neu-proprietären Elementen (wie CANVAS) oder Elementen, die irgendwann mal proprietär waren, später aber vom 3WC standardisiert wurden (wie TABLE). Standardkonformität ist doch immer eine sehr wechselnde Angelegenheit (und abhängig vom Zeitpunkt der Betrachtung), auf die man sich technisch nicht verlassen sollte und kann. Deswegen ist HTML auch so, wie es ist, und alle sind zufrieden: Die Browser, die nicht-standardkonforme Elemente ignorieren, und die, die sie interpretieren ...
Gruß, Cybaer
Hallo,
Der Unterschied: Die "Öffentlichkeit" (auch "ihr" hier) definiert "Validität" als Einhaltung der 3WC-DTD (und fälschlicherweise tun ja auch die üblichen Validatoren so, als wenn sie nur diese beachten würden, anstatt eine reale DTD zu verwenden, die dann auch nicht vom 3WC sein muß). Diese Begrenzung möchte ich nicht mitmachen.
Genau, lieber erfindest du deine eigene Terminologie, die niemand teilt, die die Sachlage sprachlich völlig verwirrt und überhaupt keine Einsichten bringt...
Standardkonformität ist doch immer eine sehr wechselnde Angelegenheit (und abhängig vom Zeitpunkt der Betrachtung), auf die man sich technisch nicht verlassen sollte und kann.
Schön formuliert. Ich würde allerdings das Subjekt des Satzes austauschen, damit ein Schuh draus wird:
Die Nutzung von nicht-standardisierten, veralteten, proprietären und experimentellen Techniken ist immer eine sehr wechselnde Angelegenheit (und abhängig vom Zeitpunkt der Betrachtung), auf die man sich technisch nicht verlassen sollte und kann.
Mathias
Hi,
Der Unterschied: Die "Öffentlichkeit" (auch "ihr" hier) definiert "Validität" als Einhaltung der 3WC-DTD (und fälschlicherweise tun ja auch die üblichen Validatoren so, als wenn sie nur diese beachten würden, anstatt eine reale DTD zu verwenden, die dann auch nicht vom 3WC sein muß). Diese Begrenzung möchte ich nicht mitmachen.
Genau, lieber erfindest du deine eigene Terminologie, die niemand teilt, die die Sachlage sprachlich völlig verwirrt und überhaupt keine Einsichten bringt...
So so, meine Erfindung. Ich fühle mich geschmeichelt! :-))
OK, ich vertrete diese Auffassung schon seit geraumer Zeit, aber nach mir kam z.B. der Autor von quirksmode - einer ja nicht ganz unbedeutenden Website - auch auf dieses Thema.
(Ich gehe allerdings nicht davon aus, daß er von mir inspiriert wurde - auch wenn er als Niederländer der deutschen Sprache nicht ganz unwahrscheinlicherweise ein wenig mächtig ist: "indoktriniert" wurde er jedenfalls definitiv nicht von mir ... >;->)
Aus A LIST apart: JavaScript Triggers, wo es um, auch von mir in diesem Forum und auf meiner Coding-Website mehrfach beschrieben und genutzte "eigene", nicht W3C-valide Attribute geht, unter der Überschrift "Custom DTDs":
"The solution is to make these attributes valid; to create a custom Document Type Definition (DTD) that extends XHTML a bit to include our trigger attributes. This custom DTD defines our special attributes and their proper place in the document, and the validator obeys by checking the document structure against our special flavor of XHTML. If the DTD says the attributes are valid, they're valid.")
A LIST apart: Validating a Custom DTD beschäftigt sich mit der praktischen Umsetzung einer eigenen DTD und der Validierung der "nicht W3C-validen Dokumente", was ja mein "Hirngespinst" sein soll:
"When you try to use the W3C validator on custom.html, it rejects the document because you aren't using one of the validator's approved DTDs.
The solution is to use a different validator which will actually go out to the URL that you have specified and use it to check whether your document is valid or not."
Aber es gibt auch eine "Gegenrede" des W3C in A LIST apart: More About Custom DTDs. Dort heißt es aber auch:
"A document written by using such a custom DTD may be validated against this DTD, but it will not be valid (X)HTML1.0 Strict, HTML 4.01 Transitional, or any other version of the HTML standard. It will be valid... something else.
Custom DTDs can be a very useful tool to enrich the existing markup languages or create entirely new ones."
Will heißen: Diese "Hirngespinste" sorgen für validen Code. Der Code validiert (natürlich) dann nicht gegen die W3C-HTML-Standards, aber die "Hirngespinste" können HTML bereichern, wie sogar das W3C meint.
Soviel also dazu ...
Schön formuliert. Ich würde allerdings das Subjekt des Satzes austauschen, damit ein Schuh draus wird:
Die Nutzung von nicht-standardisierten, veralteten, proprietären und experimentellen Techniken ist immer eine sehr wechselnde Angelegenheit (und abhängig vom Zeitpunkt der Betrachtung), auf die man sich technisch nicht verlassen sollte und kann.
D.h., wenn ich Elemente & Attribute verwende, die nicht jeder Browser kennt und nutzt, kann ich mich für die Zukunft nicht darauf verlassen, daß sie jeder Browser kennt und nutzt?
Eine fürwahr weise Erkenntnis, die ich sofort in meine Überlegungen mit einschließen werde (sofern dies noch nicht geschehen ist). >;->
Gruß, Cybaer
PS: Google findet unter HTML ("custom DTD" OR "eigene DTD") immerhin "ungefähr 24.800" Ergebnisse. Und wenn u.a. der Autor von quirksmode oder das W3C auch unter "niemand" firmiert, dann bin ich sehr gerne auch ein "niemand". Denn bei allem zurecht gebotenem Respekt dir gegenüber und "gesundem Selbstbewußtsein" meinerseits: Es handelt sich hier IMHO dann doch um eine Gattung Web-Experten, die in einer anderen Liga spielen, als wir hier ...
Hallo,
Bei »Validität gegen eine eigene DTD« muss man eben differenzieren. Bedenklich finde ich, wenn damit der Sinn von W3C-Validität und Standardkonformität, wie er landläufig diskutiert wird, ad absurdum geführt wird. Denn valide hinsichtlich meiner eigenen DTD arbeite ich immer, egal, wie sinnreich diese ist, egal, ob diese DTD nun ausformuliert ist oder nur in meinem Kopf existiert als Summe aller Elemente und Attribute, die ich auf einer Site verwende. So kann »Validität« zu einer sinnentleerten Nullaussage werden, anstatt ein positives Feature einer Site auszudrücken.
»Eigene DTD« heißt bei Peter-Paul Kochs Modell die W3C-DTD plus wirklich individuelle Zusätze, die nur Site-weit existieren und keine allgemeine Bedeutung haben. Dagegen ist nichts einzuwenden, denn dieses Modell weicht nicht von allgemeiner Standardkonformität ab und es setzt voraus, dass Browser die individuellen Zusätze komplett ignorieren. Einwände habe ich aber, wenn »eigene DTD« bedeutet, dass man sich bei allen proprietären und obsoleten Erfindungen der Weltgeschichte bedient, das in eine (und sei es nur gedachte) DTD packt und schließlich das ganze mit einem positiv besetzten »valide« lobt, verbunden mit Dissen des W3Cs.
Die eigenen Attribute fürs DOM Scripting habe ich auch selbst als u.U. gewinnbringenden Fall der Abweichung vom Standard bezeichnet. Was ich dabei nicht verstehe, ist der Validitätsfetischismus. Eigene Attribute für DOM Scripting machen Markup ungültig hinsichtlich W3C-DTDs, das ist halt so, aber nicht schlimm. Dann aber unbedingt eine eigene DTD schreiben zu wollen, halte ich für unnötig. Schließlich diskreditieren diese eigenen Attribute nicht die Vorzüge des an sich standardkonformen Dokuments. Insbesondere bei XHTML ist DTD-Validität Killefick - im Sinne des Erfinders wäre eher ein eigener Namespace mit eigenem XML-Schema. Das ist genau mein Punkt: Validität gegenüber irgendeiner DTD bedeutet gar keinen Vorteil, also ist es sinnlos, über sie zu diskutieren oder schlicht das Wort in dieser Bedeutung zu verwenden. Validität ist für mich höchstens im Sinne von angestrebter Standardkonformität interessant.
Im Übrigen meinte ich mit »valide gemäß Browser-DTD«-Hirngespinst etwas anderes, nämlich die »Validität« gegenüber den (nirgendwo als solche niedergeschriebenen) DTD von Browsern, die als Summe aller unterstützte Auszeichnungsmöglichkeiten gedacht werden. Diese »Validität« nimmst du immer wieder in Anspruch oder erklärst sie sogar als Maßstab, und das führt eben zu einer sprachlichen Verwirrung hinsichtlich (W3C-)Validität im Sinne von Standardkonformität.
Mathias
Hi,
Bei »Validität gegen eine eigene DTD« muss man eben differenzieren.
"Differenzieren" ist nie verkehrt. ;)
Bedenklich finde ich, wenn damit der Sinn von W3C-Validität und Standardkonformität, wie er landläufig diskutiert wird, ad absurdum geführt wird.
Nun ja, am Sinn zweifele ich ja auch nicht, nur an der Standardkonformität als solcher! =:-)
Wenn ein Anfänger im boolschen Sinne auf die Standardkonformität schaut, dann ist das IMHO sehr sinnvoll, da er i.d.R. nicht die Grundlage hat, Abweichungen davon als positiv oder negativ beurteilen zu können. Aber hier ist die Standardkonformität doch eher ein Hilfskonstrukt für die Autoren, die die Sinnhaftigkeit eines Quelltextes anders (noch) nicht erschließen können.
Denn valide hinsichtlich meiner eigenen DTD arbeite ich immer,
Ja, Du vielleicht. Ich auch. Aber offensichtlich gibt es "da draußen" ja hinreichend genügend Beispiele, wo der Autor anders dachte (bzw. eher nicht dachte und/oder prüfte). Sonst würden die Fehler, außer vielleicht Flüchtigkeitsfehler oder Fehler durch den Markup-unkundigen Content-Redakteur, ja nicht so zahlreich sein.
Und das war doch Problem, das sich aus Robs Frage halt gestellt hat. Und die Antwort lautet eben: Wenn man seine Seiten gegen eine eigene (sinnvolle) DTD validieren kann, dann ist das kein prinzipieller Mangel, auch wenn der W3C-Validator beim Prüfen gegen W3C-DTDs Fehler meldet.
So kann »Validität« zu einer sinnentleerten Nullaussage werden, anstatt ein positives Feature einer Site auszudrücken.
Das sehe ich anders. Und damit meine ich nicht (nur), daß die Validität als solche ja ohnehin kein Qualitäts-Kriterium sein kann, sondern allenfalls ein Indiz. Nur ein Beispiel: Eine Dokument mit ineinander verzahnten Elementen wirst Du auch mit einer eigenen DTD keineswegs validieren können. SO krude kann eine DTD gar nicht sein, weil über allem immer die Basis von SGML schwebt.
Aber ohnehin meine ich ja (s. "sinnvoll"), daß man eben nicht in kompletter Unerfahrenheit solange an einer DTD schraubt, bis das Dokument, was ich mir zusammengeflickt habe mal endlich valide ist. ;->
Dagegen ist nichts einzuwenden, denn dieses Modell weicht nicht von allgemeiner Standardkonformität ab und es setzt voraus, dass Browser die individuellen Zusätze komplett ignorieren.
Schön, daß wir uns dann doch in wenigstens einem Punkt einig sind. :-)
Einwände habe ich aber, wenn »eigene DTD« bedeutet, dass man sich bei allen proprietären und obsoleten Erfindungen der Weltgeschichte bedient, das in eine (und sei es nur gedachte) DTD packt und schließlich das ganze mit einem positiv besetzten »valide« lobt, verbunden mit Dissen des W3Cs.
Ach, die können das ab, die sind das gewohnt! ;->
Im Ernst: Der Punkt ist (weswegen ich in diesem Thread auch auf erneutes Auflisten von Beispielen verzichtet habe - OK, neben der Bequemlichkeit >;-)), daß beide Möglichkeiten (nutzen von proprietären wie eigenen Erfindungen) technisch auf dem gleichen Prinzip fußen. Oder anders gesagt (bitte nur als praktisch sinnfreies Beispiel verstehen): Für den IE ist BLINK auch nur eine Erfindung, die er nicht kennt - genau wie BLUNK. ;-) Mozilla kann halt nur mit BLUNK nichts anfangen. Und wer weiß, vielleicht auch irgendwann mit BLINK nichts mehr (also egal ob Quirks- oder Standard-Modus). Und egal ob ich BLUNK oder BLINK verwende: Wenn ich "meine" DTD um dieses Element erweitere, dann ist es gut, wenn ich prüfen kann, daß mein Dokument (zu meiner DTD) valide ist. Die Frage war: Kann BLINK oder BLUNK schaden? Und da sage ich : Nö. ;-) Das schlimmste was passieren kann, ist, daß neuere Browserversionen nicht mehr blinken, wo ältere Versionen noch geblinkt haben. (Eher ist das Problem, daß es tatsächlich mal BLUNK geben könnte, und die Browser dann etwas machen, was ich gar nicht möchte!)
Dann aber unbedingt eine eigene DTD schreiben zu wollen, halte ich für unnötig.
Ich (prinzipiell) auch. Ich schrieb deswegen ja früher auch schon mal von "virtueller DTD".
Allerdings ist es natürlich sehr sinnvoll, wenn es nicht um eine handvoll Seiten oder Templates geht, sondern um sehr viele Dokumente. Da kann es natürlich aus Gründen der Qualitätskontrolle extrem sinnvoll (und ggf. sogar zwingend) sein, sie *automatisch* gegen eine (auch eigene) DTD validieren zu lassen!
Insbesondere bei XHTML ist DTD-Validität Killefick - im Sinne des Erfinders wäre eher ein eigener Namespace mit eigenem XML-Schema.
Zustimmung. Aber es ging ja auch nicht darum, was *wir* so alles tun oder lassen würden, sondern zu erklären, warum und unter welchen Bedingungen existierende Websites (und üblich ist nach wie vor HTML - ja sogar wenn man XHTML schreibt) nicht durch mangelnde W3C-Validität per se schlechten Code haben.
Das ist genau mein Punkt: Validität gegenüber irgendeiner DTD bedeutet gar keinen Vorteil,
Ich will jetzt nicht darauf rumreiten, daß selbst mit Validierung gegen "irgendeine" DTD Fehler gefunden werden können, die ohne Validierung unentdeckt geblieben wären (s.o. "Verzahnung" etc.). Ich halte aber durchaus für vorteilhaft, gegen irgendeine *gute* DTD zu validieren. Daß an eine DTD qualitativ höhere Ansprüche zu stellen sind, als z.B. an einen Blogeintrag über die Gürtelrose von Oma Klara, versteht sich ja wohl (hoffentlich) von selbst, oder?! =:-)
Im Übrigen meinte ich mit »valide gemäß Browser-DTD«-Hirngespinst etwas anderes, nämlich die »Validität« gegenüber den (nirgendwo als solche niedergeschriebenen) DTD von Browsern, die als Summe aller unterstützte Auszeichnungsmöglichkeiten gedacht werden.
Nein, das ist wohl ein Mißverständnis. Nicht, daß ich mir das nicht vorstellen kann (ich hätte eigentlich aus oben genannten Erwägungen auch nichts dagegen!), aber für mich ist diese "Hirngespinst-DTD" ein Hilfskonstrukt (also ein echtes Hirngespinst ;-)), um meine Meinung zu verdeutlichen.
(Zumindest was eine "All in One"-DTD angeht - daß die einzelnen Browserhersteller jeweils real browsereigene DTDs, und sei es unveröffentlicht im Schrank, haben, davon würde ich schon ausgehen. Alter SGML-Grundsatz: Zuerst macht man sich Gedanken, dann die DTD, dann an die Nutzung.)
Und insofern ...
Diese »Validität« nimmst du immer wieder in Anspruch oder erklärst sie sogar als Maßstab,
... bitte ich, dieses Hilfskonstrukt auch als solches zu verstehen, aber ganz bestimmt nicht als "Maßstab" für irgendwas! =:-o
Womöglich noch ein Maßstab, nach dem man sich ernsthaft auch noch zu richten hätte? Ne, als wirklich ...
Gruß, Cybaer
Moin!
Für den IE ist BLINK auch nur eine Erfindung, die er nicht kennt - genau wie BLUNK. ;-) Mozilla kann halt nur mit BLUNK nichts anfangen. Und wer weiß, vielleicht auch irgendwann mit BLINK nichts mehr (also egal ob Quirks- oder Standard-Modus).
Dem Mozilla kann man jetzt schon <blink> abgewöhnen: In seinem Stylesheet res/html.css steht:
blink {
text-decoration: blink;
}
Entfernt man das, blinkt er auch nicht mehr.
Viele Grüße,
Robert
Hi,
Proprietäre Tags & Attribute stören niemanden und nutzen nur.
Die da wären?
Die, die der Autor nutzen möchte. Wenn Du keines nutzen möchtest, dann kannst Du ja auch zur 3WC-DTD valide bleiben ...
... andere Web-Autoren mögen das anders sehen. Denn: Du zäumst das Pferd von der falschen Seite auf. Die Frage war nicht, was mir/dir/sonstwem an sinnvoll nutzbaren proprietären Tags & Attributen einfällt (mir fallen jedenfalls welche ein - und ich nutze auch welche), sondern wen solche proprietären Tags & Attribute stören (außer einem Validator, der nicht wirklich gegen eine DTD prüft, sondern nur so tut als ob).
Wie kommst Du auf die Idee, nur "Tag-Soup" würde zu invalidem Code führen? Da gibt es schon noch andere Dinge (s.o.) ...
Genau diese meinte ich mit Tag-Soup. Denn (X)HTML ist das ja nicht.
Sagt wer? Ach ja, das 3WC. Nun, da kann man halt anderer Meinung sein (z.B. alle Browserhersteller sind da anderer Meinung - sonst hätten sie keine Nicht-3WC-Tags & -Attribute eingebaut >:->).
Gruß, Cybaer
Hello out there!
Die Frage war nicht, was mir/dir/sonstwem an sinnvoll nutzbaren proprietären Tags & Attributen einfällt
Doch, das war die Frage: Der Effekt welcher sinnvoll nutzbaren proprietären _Elemente_ und Attribute lässt sich nicht auch mit (X)HTML umsetzen?
(mir fallen jedenfalls welche ein - und ich nutze auch welche)
Schade, dass du auch nach zweiter Nachfrage dazu schweigst, welche „welche“ sind.
Da gibt es schon noch andere Dinge (s.o.) ...
Genau diese meinte ich mit Tag-Soup. Denn (X)HTML ist das ja nicht.
Sagt wer?
Mein Verständnis, was eine Sprache ist.
(X)HTML ist die Menge aller Dokumente, die den in der (X)HTML-DTD festgelegten Regeln entsprechen. Alles andere ist Tag-Soup. (Wobei da keine Wertung drinsteckt, dass sich Tag-Soup u.U. nicht sinnvoll einsetzen ließe.)
See ya up the road,
Gunnar
Hi,
Doch, das war die Frage: Der Effekt welcher sinnvoll nutzbaren proprietären _Elemente_ und Attribute lässt sich nicht auch mit (X)HTML umsetzen?
Es geht um das technische Prinzip, ob eine bestimmte Vorgehensweise ein Problem darstellen kann. Ich beziehe mich also auch nur auf die Technik (und überlasse die Praxis der Phantasie des jeweiligen Web-Autors - in deren Köpfe ich weder hineinschauen möchte noch kann), während Du der Beantwortung dieser technischen Frage ausweichst.
(mir fallen jedenfalls welche ein - und ich nutze auch welche)
Schade, dass du auch nach zweiter Nachfrage dazu schweigst, welche „welche“ sind.
Wenn dir keine einfallen/Du keine nutzen möchtest: Dein Problem - aber das war ja auch eben *nicht* die Frage.
Genau diese meinte ich mit Tag-Soup. Denn (X)HTML ist das ja nicht.
Sagt wer?
Mein Verständnis, was eine Sprache ist.
(X)HTML ist die Menge aller Dokumente, die den in der (X)HTML-DTD festgelegten Regeln entsprechen. Alles andere ist Tag-Soup.
Ach, da sagt irgendeine Organisation (deren Regeln weder alle befolgen, noch befolgen müssen - geschweige denn, daß deren Regeln allesamt sinnvoll wären): Wir definieren die aktuelle englische Grammatik als einzig gültige Sprache. Wer US-Englisch/Französisch/Plattdeutsch/... spricht, der spricht gar keine Sprache, sondern irgendein ominöses Kauderwelsch?
Klar, so kann man alles so definieren, wie es einem in den Kram paßt ... >;->
Und da ich in der Lage bin, meine eigene DTD zu schreiben, kann ich auch einen eigenen HTML-Dialekt schreiben (mit gegen diese DTD voll valide Seiten). Diese DTD kann durchaus eine Mischung aus 3WC-, MS-, Mozilla-, ...-DTDs sein. Ob ein Dokument HTML ist oder nicht, obliegt nicht der Angabe oder Einhaltung einer 3WC-DTD - auch wenn das 3WC das gerne behauptet (dürfen sie ja auch - schließlich haben sie diese Regel auch selbst eingeführt - *nachträglich*).
Gruß, Cybaer
Hallo,
mal ein metakommunikativer, selbstverständlich subjektiver Kommentar als Ich-Botschaft:
Diese DTD kann durchaus eine Mischung aus 3WC-, MS-, Mozilla-, ...-DTDs sein. Ob ein Dokument HTML ist oder nicht, obliegt nicht der Angabe oder Einhaltung einer 3WC-DTD - auch wenn das 3WC das gerne behauptet
Ach... Du bewegst dich auch in mehreren Jahren keinen Millimeter und rückst nicht von deinem »valide gemäß Browser-DTD«-Hirngespinst ab.
HTML ist ein vom W3C herausgegebener Internetstandards. Dem können Dokumente entsprechen oder auch nicht. Alles andere sind proprietäre oder anderswo spezifizierte Erweiterungen, die im Laufe der Standardisierung aufgenommen wurden oder (noch) nicht. Usw.
Ich sehe keinen vernünftigen Grund, wieso man diese Grundbegriffe bis zum völligen Bedeutungsverlust umdefinieren sollte (»›HTML‹ ist alles was irgendwo zwischen <html> und </html> steht und von irgendeinem Client wie auch immer umgesetzt wird, deshalb ist ›HTML‹-Validität offen für jede beliebige Bedeutung«).
Die unendlichen Wortklaubereien, die dadurch entstehen (siehe dieser Thread), wirken auf mich gänzlich überflüssig. Angebracht wäre hier begriffliche Klärung statt Verwischung und Beliebigkeit.
Was die ewige, selten konkrete Kritik am Streben nach W3C-validen Sites angeht: Es ist echt anstrengend und wirkt auf mich - sorry - zusehend bloß als stures Sabotageverhalten. In den seltensten Fällen redest du Klartext, sondern fabulierst. Sorry - das ist meine Wahrnehmung.
Aus der letzen Diskussion habe ich das Fazit gezogen, dass es im Regelfall keinen praktischen Grund gibt, von validem Code abzuweichen. In den Diskussionen wurde bisher nie ein entsprechender objektiver Nutzen gefunden. Selbst wenn man jemandem die Meinung zugestünde, keinen Vorteil in validem Code zu sehen, so halte ich die immer wieder vorgebrachten Einwände gegen die allgemeine Empfehlung, W3C-validen Code zu schreiben, für erwiesenermaßen substanzlos.
Polemischen Lächerlichkeiten wie »3WC« sprechen ferner für sich. Ich empfinde die Validitätsdiskussionen leider alles andere als von Humor erfüllt. Heraus kommen nur noch Grabenkämpfe mit kommunikativen Tiefpunkten wie »Wenn dir keine einfallen/Du keine nutzen möchtest: Dein Problem«. Wenn man nur auf seinem Standpunkt beharren will, äußert man sich besser gar nicht.
Mathias
Hi,
Diese DTD kann durchaus eine Mischung aus 3WC-, MS-, Mozilla-, ...-DTDs sein. Ob ein Dokument HTML ist oder nicht, obliegt nicht der Angabe oder Einhaltung einer 3WC-DTD - auch wenn das 3WC das gerne behauptet Ach... Du bewegst dich auch in mehreren Jahren keinen Millimeter ...
Ach, ach was. Hat sich denn in den letzten Jahren irgendwas an den Rahmenbedingungen geändert, daß man sich bewegen müßte? =:-o
Mal sehen: Die Browser unterstützen immer noch nicht vollständig die W3C-Standards. Die Browser unterstützen nach wie vor proprietäre Elemente - und es kommen neue hinzu (seien es nun mehr oder weniger sinnvolle zukunftsträchtige Elemente wie WHATWGs CANVAS, sei es MS' äußerst sinnvolles MARQUEE, das ja mittlerweile auch seinen Weg in die Operas und Mozillas gefunden hat).
Halt, doch, eine Veränderung: Tim Berners-Lee hat erkannt, daß XHTML als Ziel zwar nach wie vor richtig ist, aber gesteht ein, daß es a) nicht gelungen ist, die Browserhersteller zu überzeugen, b) die Webautoren zu überzeugen und c) über all der schönen XTheorie sich um die Praxis, sprich: HTML (also daß, was Hersteller und Webautoren anscheinend eher interessiert), zu kümmern, so daß das 3WC schlicht an praktischer Relevanz verlor - und verspricht, jetzt auch HTML weiterzuentwickeln.
Also wenn sich jemand bewegt hat, dann unwillig und gezwungenermaßen das W3C.
... und rückst nicht von deinem »valide gemäß Browser-DTD«-Hirngespinst ab.
Als wenn ich der einzige wäre, der diese Meinung vertritt (s. ). :)
HTML ist ein vom W3C herausgegebener Internetstandards. Dem können Dokumente entsprechen oder auch nicht. Alles andere sind proprietäre oder anderswo spezifizierte Erweiterungen, die im Laufe der Standardisierung aufgenommen wurden oder (noch) nicht. Usw.
Für mich ist HTML eine in SGML definierte Markup-Language, die definierten formalen Kriterien folgt und "typische HTML-Elemente" enthält. Der konkrete Umfang der Sprache orientiert sich an der jeweiligen DTD. Von verschiedenen Herstellern wurden verschiedene DTDs spezifiziert, die mehr oder weniger von den standardisierten DTDs abweichen. Alle gebräuchlichen Browser richten sich nicht nach den standardisierten DTDs, sondern verwenden, wie Du schreibst, "spezifizierte Erweiterungen".
Dennoch sind all diese Derivate HTML.
Die Akzeptanz (Ab- & Aufwärtskompatibilität) der Erweiterungen sind im Kern von HTML selbst bereits definiert.
Die unendlichen Wortklaubereien, die dadurch entstehen (siehe dieser Thread), wirken auf mich gänzlich überflüssig.
Na, und auf mich erst. Du hast deine Meinung, ich habe meine Meinung. Dabei können wir es ruhig belassen! Mag der interessierte Leser diese beiden Meinungen parallel sehen und verstehen oder nicht verstehen: Er wird sich dann seine eigene Meinung bilden.
Er kann ja ggf. auch nachfragen oder in bisherigen Threads oder an anderen Stellen im Web nachlesen.
Substanzloses Geschwafel von "Hirngespinsten" und Verdrehungen (s.u.) als plumpes Mittel der Meinungsmache ist da wirklich überflüssig wie ein Kropf ... :-)
Angebracht wäre hier begriffliche Klärung statt Verwischung und Beliebigkeit.
Ich denke, meine Meinung ist deutlich umrissen.
Was die ewige, selten konkrete Kritik am Streben nach W3C-validen Sites angeht:
Wen meinst Du? Mich ja wohl nicht, da ich nicht diejenigen kritisiere, die nach W3C-Validität streben. Ich mache mich höchstens lustig über die, die diese W3C-Validität als IMHO zu wichtig (als Selbstzweck) betrachten.
Aber da weiß ich mich ja auch in guter Gesellschaft. Denn das W3C selbst meint unter der Überschrift "Web standards? That's precisely why I want to validate!":
"And you are right, of course! Unless, of course, you treat both validation and web standards as some sort of sacred cow, practically forgetting the meaning behind their importance.
This is probably the worst mistake that the advocates of web standards can ever make: to fight for an abstract, arcane concept of standards and consider validation for the sake of validity a goal in itself."
Und nochmal: Es geht hier nicht um die Frage, ob es "toll" ist, W3C-valide zu coden. Es geht hier um die Frage, ob es problematisch ist, nicht W3C-valide zu coden - wenn man weiß, was man tut! Es wundert mich ernsthaft, wie man diese beiden Positionen "unabsichtlich" verwechseln kann ... %-)
Und die Antwort auf diese Frage war: Ein bißchen W3C-valide gibt es nicht. Aber ob ein W3C-Validitäts-Verstoß problematisch ist bzw. sein kann oder nicht, kommt drauf an. Pauschal kann man das nicht sagen. Und ein Hilfsmittel für "Anfänger" diese Frage zu klären, kann das Validieren gegen eine eigene (aber sinnvolle, d.h. nicht von einem Anfänger erstellt ;-)) DTD sein.
Damit läßt sich die Frage relativ leicht beantworten, ob ein nicht-(W3C-)valides HTML-Dokument problematisch ist, oder nicht.
Und ich bin eben generell der Meinung, daß alle HTML-Dokumente validieren sollten - gegen welche DTD auch immer.
Es ist echt anstrengend und wirkt auf mich - sorry - zusehend bloß als stures Sabotageverhalten.
Du kennst meine Meinung. Wenn Du sie nicht verstehst (durchaus im gemäßigten Sinne des "nicht nachvollziehen könnens/wollens" >;->) oder akzeptierst, dann ist das dein Problem. Ich kann damit gut leben. Du wirst auch nicht gezwungen, sie zu kommentieren oder gar zu lesen. Postulier einfach deine Meinung in einem parallelen Posting, und laß den Leser sich seine eigene Meinung bilden. So einfach kann das sein ... =8-))
In den seltensten Fällen redest du Klartext, sondern fabulierst. Sorry - das ist meine Wahrnehmung.
Wenn Du (oder sonst wer) für dich keinen (irgendwie gearteten) Nutzen aus meinen Gedanken ziehen kannst oder willst, dann habe ich damit kein Problem. (Für mich relevante) Beispiele habe ich bereits (auszugsweise) an anderer Stelle genannt (ist ja nicht der erste Thread zu diesem Thema - und auf meiner Coding-Website mache ich es ja sowieso). Hier geht es mir um das Grundprinzip - was sich daraus ergibt, kann man sich dann ja mal selber zusammenreimen - oder es lassen - oder sich hier im Forum oder sonstwo im Web mal schlau machen, was das bedeutet und wie man es nutzen kann. Beispiele gibt es ja von mir und anderen im Web durchaus zu finden ... 8-))
Aus der letzen Diskussion habe ich das Fazit gezogen, dass es im Regelfall keinen praktischen Grund gibt, von validem Code abzuweichen.
Hat das denn irgendjemand "verlangt", man solle als Regelfall von validem Code abweichen? Was für eine Verdrehung! =:-o
Ich habe Gründe genannt, die mal auf einer kompletten Site zum Tragen kommen können, mal nur auf einzelnen Seiten, mal auch gar nicht. Es kommt halt drauf an. Aber wenn man denn gegen die "geheiligte" W3C-Validität verstößt, ist es eben auch nicht schlimm - sofern man dafür seine Gründe hat und weiß, was man tut.
Soweit, so bekannt!
In den Diskussionen wurde bisher nie ein entsprechender objektiver Nutzen gefunden.
Du wolltest ihn vielleicht nicht sehen, oder ihn als Nutzen anerkennen. Aber das ist dein Problem/deine Meinung. Andere sehen das halt durchaus anders (erneut: s. ).
Selbst wenn man jemandem die Meinung zugestünde, keinen Vorteil in validem Code zu sehen, ...
Wobei ich da eben durchaus Vorteile sehe: Sowohl in "echt" validem Code (validiert gegen eine W3C-DTD) als auch in "unecht" validem Code (validiert gegen eine eigene DTD).
... so halte ich die immer wieder vorgebrachten Einwände gegen die allgemeine Empfehlung, W3C-validen Code zu schreiben, für erwiesenermaßen substanzlos.
Thema erneut verfehlt. Niemand (zumindest ich nicht) ist dagegen W3C-validen Code zu schreiben. Ich bin nur nicht dafür, W3C-validen Code als Selbstzweck zu sehen, der auf jeden Fall (auch gegen praktische Vorteile) zu sein hat.
Polemischen Lächerlichkeiten wie »3WC« sprechen ferner für sich. Ich empfinde die Validitätsdiskussionen leider alles andere als von Humor erfüllt.
Oh, das "3WC" ist gar nicht humorvoll gemeint! :-))
Meine Meinung zu diesem Verein ist nunmal ziemlich negativ.
Nein, nicht, daß ich nicht der Meinung wäre, eine Organisation, die Web-Techniken (weiter-)entwickelt und standardisiert wäre schlecht (ganz im Gegenteil).
Auch halte ich nicht alles, was die Browserhersteller so an eigenen Süppchen kochen für der Weisheit letzten Schluß (auch hier: ganz im Gegenteil).
Aber das 3WC ist für mich (leider!) keine Institution, vor der ich wirklich Achtung haben kann.
Sie bräuchten ein Brand, eine Marke, ein geschütztes Logo, daß als Gütesiegel gut sichtbar auf jedem "guten" Browser prangen darf - oder gar prangen muß. Überspitzt formuliert: Wenn ein 12-jähriger Junge von seiner Mutter gefragt wird: "Na mein Spatz, was wünscht Du dir denn zum Geburtstag? Einen IPod? Eine Pump-Gun? Eine Kettensäge?" >;->, dann sollte er mit strahlenden Augen sagen können sollen: "Nein Mama, einen echten HTML-Browser!" ;-)
Und die Wirklichkeit?
Schon in "HTML 1" gab es Elemente, die nie den Weg in die Browserrealität gefunden haben. Nicht von sich aus, sondern getrieben von der Industrie (zuerst Netscape, dann MS, später auch Opera als CSS-Schrittmacher, und mom. eher Apple, Mozilla & der Rest der WHATWG) wurden proprietäre Elemente nachträglich zum Standard gemacht. Diverse Standards mußten überarbeitet werden (HTML 2 & 4, CSS 2), weil die Browserhersteller, die allesamt im W3C vertreten sind, gar nicht daran dachten, es so umzusetzen, wie verabschiedet.
Der größte Browserhersteller pfeift auf die Standards ohnehin, während die aktivsten "guten" Hersteller sich, letzlich ja wohl aus Kritik am W3C, in der WHATWG organisierten. Denn das W3C hat nichts mehr an HTML gemacht, und voll auf XHTML gesetzt - ohne eine Marktdurchdringung schon des ersten Schrittes dieser Technik zu erreichen. Wie die Goggle-Statistik ja zeigt, ist den Web-Autoren offensichtlich a) Validität nicht so wichtig, und b) die striktere Formalität (echten) XHTMLs geht ihnen auch am Arsch vorbei.
Ja herrjeh: Keine deutsche Mittelstandsklitsche noch DAX-Unternehmen würde es überleben, wenn sie so am Markt agieren würden, wie es das W3C macht.
Nicht, daß ich diesen Zustand toll finde. Aber er existiert. Gut gemacht, W3C! Wirklich exzellent!
Wenn man nur auf seinem Standpunkt beharren will, äußert man sich besser gar nicht.
Wir reden ja nicht zum erstenmal drüber. Und es ist auch nicht das erste Mal, daß Gunnar an einer solchen Diskussion beteiligt war. Ich bin nicht der "ich schreibe alles zum x-ten Mal"-Neger für User, die entweder Probleme mit ihrem Gedächtnis haben, oder erneut ein Faß aufmachen möchten, obwohl das Thema bereits "durch" ist.
Im letzten Thread zu diesem Thema, meldet sich jedenfalls auch Gunnar zu Wort ...
Gruß, Cybaer
PS: Auszüge aus einer Meldung von gestern zu einer Yahoo-Diskussionsrunde mit den großen Browser-Herstellern:
Nach Auffassung des IE-Vertreters "sollten die Browser-Hersteller zusammenarbeiten, um die Standards für eine gemeinsame Webzukunft zu entwickeln. Er bemängelt, dass jede Browser-Verbesserung dazu führe, dass damit automatisch Webstandards gebrochen würden. Unklar bleibt aber, warum Microsoft hier nicht auf das W3C setzt, das für die Etablierung einheitlicher Webstandards verantwortlich ist."
Und der Mozilla-Vertreter "appellierte daran, für die Zukunft nicht auf das W3C zu schielen."
Soviel also noch ergänzend zum Thema 3WC ...
Hallo,
Hat sich denn in den letzten Jahren *irgendwas* an den Rahmenbedingungen geändert, daß man sich bewegen müßte? =:-o
Ja. Es gibt keinen Netscape 4 mehr und es gibt im Ganzen keine Hindernisse mehr, die standardkonformen Webdesign verhinderten. Wenn du manchmal noch mit IE-5-Kompatibilität argumentierst, fühle ich mich ganz nostalgisch und vergesse, dass wir im Jahr 2007 angekommen sind. ;)
Mal sehen: Die Browser unterstützen immer noch nicht vollständig die W3C-Standards.
Das wird höchstwahrscheinlich auch immer so bleiben (neue Standards entstehen, unter welcher Aufsicht auch immer, und Browser müssen wieder aufholen usw.). Ein ewiger Einwand gegen Standardorientierung ist das nicht.
Die Browser unterstützen nach wie vor proprietäre Elemente - und es kommen neue hinzu (seien es nun mehr oder weniger sinnvolle zukunftsträchtige Elemente wie WHATWGs CANVAS, sei es MS' äußerst sinnvolles MARQUEE, das ja mittlerweile auch seinen Weg in die Operas und Mozillas gefunden hat).
Man sollte die WHATWG nicht mit proprietären Entwicklungen der Browserkriege in einen Topf werfen. Dort wird ganz im Gegenteil zu unilateralen Erfindungen ein Standard entwickelt. Das läuft zwar ohne entscheidende Beteiligung des W3Cs, aber eine dogmatische Setzung eines Browserherstellers ist es auch nicht. Mittlerweile ist eigentlich bei allen Browserherstellern angekommen, wenn sie ihre Innovationen öffentlich in Zusammenarbeit mit den anderen Riesen entwickeln.
Also wenn sich jemand bewegt hat, dann unwillig und gezwungenermaßen das W3C.
Sicher. Alles aber kein Grund, sich nicht an den bestehenden Standards zu orientieren. Die sind in der Praxis die einzige Alternative. Es gibt bis dato nichts neben dem W3C, zu dem man hin gewinnbringend flüchten könnte.
Dennoch sind all diese Derivate HTML.
HTML-Derivate sind HTML-Derivate, nicht HTML. Ansonsten läge ein logischer Fehler vor, schließlich kann etwas nicht von etwas deriviert sein und gleichzeitig noch es selbst sein. ;) Entweder HTML bezeichnet *das* (W3C-)HTML oder die informelle »Gruppe« an HTML-Derivaten, aber nicht beides gleichzeitig.
Die Akzeptanz (Ab- & Aufwärtskompatibilität) der Erweiterungen sind im Kern von HTML selbst bereits definiert.
Kompatibilität zu älteren und neueren Versionen eines Standards sind beileibe ein Ding, was nichts mit Offenheit für proprietäre Erweiterungen zu tun hat und diese auch nicht legitimiert.
Und nochmal: Es geht hier *nicht* um die Frage, ob es "toll" ist, W3C-valide zu coden.
Nicht? Für mich sind die Vorteile von Standardkonformität der Grund, warum W3C-Validität überhaupt Sinn ergibt.
Es geht hier um die Frage, ob es problematisch ist, nicht W3C-valide zu coden - wenn man weiß, was man tut!
Vor allem, ob und wann es überhaupt in der Praxis nötig und vorteilhaft ist, abzuweichen.
Und die Antwort auf diese Frage war: Ein bißchen W3C-valide gibt es nicht. Aber ob ein W3C-Validitäts-Verstoß problematisch ist bzw. sein kann oder nicht, kommt drauf an. Pauschal kann man das nicht sagen.
Es ist nichts falsch daran, einem Standardverstoß zuerst einmal pauschal zu unterstellen, dass er problematisch ist - weil man damit den sicheren Bereich der kodifizierten, normativen Technik verlässt, auf die hin tausende User-Agents programmiert wurden. »Funktioniert in beiden Browsern«, wie man so schön vor einigen Jahren sagte, ist eben nicht mehr der heutige Maßstab.
Und ein Hilfsmittel für "Anfänger" diese Frage zu klären, kann das Validieren gegen eine eigene (aber *sinnvolle*, d.h. nicht von einem Anfänger erstellt ;-)) DTD sein.
Ich weiß, du hast schon oft Beispiele dafür genannt, was du persönlich u.U. sinnvoll findest... aber werde mal konkret: Wo siehst du Beispiele für solche vermeintlich sinnvollen, vom W3C abweichenden DTDs, die man gar Anfängern statt der offiziellen DTDs empfehlen sollte?
Damit läßt sich die Frage relativ leicht beantworten, ob ein nicht-(W3C-)valides HTML-Dokument problematisch ist, oder nicht.
Was sollte eine solche »eigene DTD« denn erlauben, was die W3C-DTDs nicht erlauben und was zudem unproblematisch ist? Schlaftabletten wie marquee? Ist marquee wirklich unproblematisch? Sollte man marquee Anfängern empfehlen? Ich weiß wirklich nicht, was in einer solchen »unproblematischen Anfänger-DTD« zusätzlich drinstehen sollte.
Und ich bin eben generell der Meinung, daß alle HTML-Dokumente validieren sollten - gegen welche DTD auch immer.
Genau das ist für mich der traurige Tiefpunkt der »Validitäts«-Diskussion. ;)
Niemand (zumindest ich nicht) ist *dagegen* W3C-validen Code zu schreiben.
Wieso sind dir dann »eigene DTDs« so wichtig, die sich Erfahrene selbst zusammenstellen soll, und denen gemäß Anfänger coden sollen?
Meine Meinung zu diesem Verein ist nunmal ziemlich negativ.
Mag alles sein - diese Frage gilt es m.M.n. aber aus der Validitätsdiskussion auszuklammern, anstatt sich darauf zu kaprizieren und die Standardkonformitätsfrage zu einem »Finde ich das W3C toll oder doof?« umzudeuten.
Zum W3C sollte man selbstverständlich ein instrumentelles Verhältnis haben, schließlich legitimiert sich dieser Laden auch nur durch seine Leistungen, die tatsächlich schwinden. Die Diskussion um den praktischen Sinn des Gebrauchs gewisser W3C-Standards beinhaltet keineswegs die Frage, welche Meinung man zu diesem Verein als solchen hat.
Aber das 3WC ist für mich (leider!) keine Institution, vor der ich wirklich Achtung haben kann.
Muss man auch nicht - daran, dass ihre Standards in der Praxis immer noch als faktisch einzige systematische Maßgaben wirken, rüttelt das nunmal nicht.
Dass das W3C an Einfluss verliert, ist eigentlich eine zukünftige Entwicklung. Die Situation wird m.E. erst dann spannend, wenn Webautoren überhaupt die Möglichkeit haben, nicht auf das W3C als die Institution zu setzen, die maßgeblich die Entwicklung von Webtechniken moderiert.
Ich bin nicht der "ich schreibe alles zum x-ten Mal"-Neger für User, die entweder Probleme mit ihrem Gedächtnis haben, oder erneut ein Faß aufmachen möchten, obwohl das Thema bereits "durch" ist.
Nein, aber gegen Links auf zusammenfassende Postings im Archiv ist ja nichts einzuwenden - also, wenn man solche Postings erstmal geschrieben hat. ;)
Mathias
Hi,
es gibt im Ganzen keine Hindernisse mehr, die standardkonformen Webdesign verhinderten.
Wie gesagt: Es geht *nicht* um Verhinderung im Sinne der Total-Verweigerung, sondern *ggf.* um Ergänzung. Aus welchem (natürlich subjektiv) guten Grund auch immer, solange es keinen Schaden hervorrufen kann.
Wenn du manchmal noch mit IE-5-Kompatibilität argumentierst, fühle ich mich ganz nostalgisch und vergesse, dass wir im Jahr 2007 angekommen sind. ;)
:) Also das ist eine andere Baustelle!
Zum einen weil ich qua Geburt Kaufmann bin (Kunde ist König - auch wenn er Socken trägt, die mir nicht gefallen ;-)), zum anderen habe ich von Anfang an in Bereichen Seiten entwickelt, wo ich mich nicht darauf verlassen konnte, daß die Zielgruppe wirklich die Software nutzt, die ich gerne hätte (also bei mir sind diesbezügl. der IE 5.x und PHP 4.1.x mom. die jeweiligen Untergrenzen). Letztlich kommt es halt auf die Zielgruppe an, aber auch so entscheide ich mich prinzipiell für eine abwärts-tauglichere Variante, wenn ich die Wahl habe (und ggf. die Zeit dafür).
Das wird höchstwahrscheinlich auch immer so bleiben (neue Standards entstehen, unter welcher Aufsicht auch immer, und Browser müssen wieder aufholen usw.). Ein ewiger Einwand gegen Standardorientierung ist das nicht.
Also wenn es so läuft, wie z.B. bei CSS 2/2.1 (und viele weitere Beispiele wären da noch möglich), dann muß man sich IMHO schon fragen, was da falsch lief und/oder läuft.
Man sollte die WHATWG nicht mit proprietären Entwicklungen der Browserkriege in einen Topf werfen.
Wie im Parallelposting geschrieben: Ich sehe dies vor dem technischen Hintergrund, der nicht gute oder schlechte unbekannte Elemente kennt, sondern einfach nur unbekannte Elemente.
Es gibt bis dato nichts neben dem W3C, zu dem man hin gewinnbringend flüchten könnte.
Dacor. Ich schrieb ja auch, daß ich auch keine Ecke kenne, wo man sich wirklich geborgen fühlen könnte. Aber ich muß nicht etwas gut finden, nur weil es nichts besseres gibt. >:->
Zumal wenn ich sehe, wie das in anderen Bereichen (trotz aller Probleme dort) funktioniert. (Gemeint ist hier die "konventionelle Industriepolitik.)
HTML-Derivate sind HTML-Derivate, nicht HTML. Ansonsten läge ein logischer Fehler vor, schließlich kann etwas nicht von etwas deriviert sein und gleichzeitig noch es selbst sein. ;)
Wenn Du "magst", dann ersetze "Derivat" durch "Version". >;->
Kompatibilität zu älteren und neueren Versionen eines Standards sind beileibe ein Ding, was nichts mit Offenheit für proprietäre Erweiterungen zu tun hat und diese auch nicht legitimiert.
Du *kennst* den Grund, *warum* HTML seit Anbeginn an vorschreibt, daß unbekannte Elemente ignoriert werden sollen?
Ich kenne ihn nicht, sehe aber, daß die (Aus-)Nutzung dieser Offenheit das Web enorm gepusht hat (und dies immer noch tut).
Und nochmal: Es geht hier *nicht* um die Frage, ob es "toll" ist, W3C-valide zu coden.
Nicht?
Nein, denn IMHO ist es - Überraschung - toll! :-))
Zumindest solange bis man genug Erfahrung hat, zu wissen, daß man es noch toller machen kann. O;->
Es geht hier um die Frage, ob es problematisch ist, nicht W3C-valide zu coden - wenn man weiß, was man tut!
Vor allem, ob und wann es überhaupt in der Praxis nötig und vorteilhaft ist, abzuweichen.
IMHO nein. Denn das ist eher subjektiv. Das will/kann ich ggf. gar nicht beurteilen.
Für mich ist es wichtig, den (subjektiven) Vorteil mit dem (validen) Nutzen zu verbinden - also *beides*.
Es ist nichts falsch daran, einem Standardverstoß zuerst einmal pauschal zu unterstellen, dass er problematisch ist ...
Ein unbekanntes oder proprietäres Element zu ignorieren, *ist* Teil des Standards von Anbeginn an. Sie zu nutzen ist also ein Verstoß gegen eine bestimmte DTD, nicht aber gegen den Standard als solchen!
Und damit ...
- weil man damit den sicheren Bereich der kodifizierten, normativen Technik verlässt,
... verläßt man eben auch keineswegs den sicheren Bereich der normativen Technik.
Ich weiß, du hast schon oft Beispiele dafür genannt, was du persönlich u.U. sinnvoll findest... aber werde mal konkret: Wo siehst du Beispiele für solche vermeintlich sinnvollen, vom W3C abweichenden DTDs, die man gar Anfängern statt der offiziellen DTDs empfehlen sollte?
Anfängern empfehle ich prinzipiell die offiziellen DTDs (sowie eine Validierung gegen selbige)! Habe ich auch schon mehrfach geschrieben (hier im Forum, wie auf meiner Website).
Was sollte eine solche »eigene DTD« denn erlauben, was die W3C-DTDs nicht erlauben und was zudem unproblematisch ist?
Hier wiederum verweise ich auf die bereits geposteten Beispiel - die nicht unbedingt vollständig sein müssen.
Schlaftabletten wie marquee?
IMHO: Nein.
Ist marquee wirklich unproblematisch?
*Definitv* nicht!
Sollte man marquee Anfängern empfehlen?
Um Himmelswillen! :-))
Ich weiß wirklich nicht, was in einer solchen »unproblematischen Anfänger-DTD« zusätzlich drinstehen sollte.
Es ist *nicht* gemeint: Mach mal irgendwas, wir basteln das schon hin. Es ist gemeint: Hier hat ein "Profi" eine DTD gebaut, und auch wenn der W3C-Validator "Fehler" meldet, so könnte sogar ein Anfänger mittels SGML- oder XML-Validator feststellen: Das Dokument ist trotzdem gut.
Beispiele hatte ich ja genannt.
Und ich bin eben generell der Meinung, daß alle HTML-Dokumente validieren sollten - gegen welche DTD auch immer.
Genau das ist für mich der traurige Tiefpunkt der »Validitäts«-Diskussion. ;)
Ja, OK! Da fehlte das "sinnvolle" oder "gute" vor "DTD" (was ich aber sonst im Thread auch immer dazugeschrieben habe! :)
(Andernfalls wäre vielleicht "DDT" passender?! ;->)
Niemand (zumindest ich nicht) ist *dagegen* W3C-validen Code zu schreiben.
Wieso sind dir dann »eigene DTDs« so wichtig, die sich Erfahrene selbst zusammenstellen soll, und denen gemäß Anfänger coden sollen?
Nicht sollen, können! Rob hat sich gewundert, warum Profis nicht-W3C-valide Seiten schreiben, und ob das nicht ein absolutes Ausschlußkriterium wäre. Die Antwort lautet halt: Kommt drauf an. Und um "echte Fehler" von "gewollten Abweichungen" zu trennen, braucht's halt ein wenig Wissen, *oder* eine Validierung gegen eine eigene DTD (die mit diesem Wissen entstanden ist).
Meine Meinung zu diesem Verein ist nunmal ziemlich negativ.
Mag alles sein - diese Frage gilt es m.M.n. aber aus der Validitätsdiskussion auszuklammern,
Ja, kann ich nachvollziehen. ;-)
Denn ...
anstatt sich darauf zu kaprizieren und die Standardkonformitätsfrage zu einem »Finde ich das W3C toll oder doof?« umzudeuten.
... auch wenn das in etwa meine Meinung widerspiegelt: Diese "Umdeutung" ist nicht beabsichtigt.
Das eine hat mit dem anderen IMHO/in der Tat nichts zu tun.
Nein, aber gegen Links auf zusammenfassende Postings im Archiv ist ja nichts einzuwenden - also, wenn man solche Postings erstmal geschrieben hat. ;)
Wie gesagt: Auch wenn es bereits geschrieben wurde: In diesem Thread ging es mir nur um das Prinzipielle der Technik. Nicht um (konkrete wie subjektive) Unterscheidungen, was nun noch (konkret aber doch nur beispielsweise) tolerabel ist, und was nicht ...
Gruß, Cybaer
Moin,
Ob ein Dokument HTML ist oder nicht, obliegt nicht der Angabe oder Einhaltung einer 3WC-DTD
so viele Klos brauchst Du dafür? *g*
Viele Grüße
Jörg
Hallo.
Ach, da sagt irgendeine Organisation (deren Regeln weder alle befolgen, noch befolgen müssen - geschweige denn, daß deren Regeln allesamt sinnvoll wären): Wir definieren die aktuelle englische Grammatik als einzig gültige Sprache. Wer US-Englisch/Französisch/Plattdeutsch/... spricht, der spricht gar keine Sprache, sondern irgendein ominöses Kauderwelsch?
"Jeder gebildete Mitteleuropäer sollte mindestens zwei Fremdsprachen beherrschen, eine afrikanische und eine asiatische. Und die paar europäischen Dialekte spricht er sowieso."
MfG, at
Moin
Proprietäre Tags & Attribute stören niemanden und nutzen nur.
insbesondere marquee und blink
Gruß
rfb
Moin!
[…] stören niemanden und nutzen nur.
insbesondere marquee und blink
Ist das nicht ein Widerspruch in sich?
Viele Grüße,
Robert
Hello out there!
[…] stören niemanden und nutzen nur.
insbesondere marquee und blink
Ist das nicht ein Widerspruch in sich?
Du erkennst versteckte Smileys?
See ya up the road,
Gunnar
Hi,
Proprietäre Tags & Attribute stören niemanden und nutzen nur.
insbesondere marquee und blink
Wenn der Autor zum 3WC valide bleiben möchte, dann nimmt er halt einen JS-Ticker und CSS (text-decoration: blink;). Ich sehe nicht, wo die Verwendung von MARQUEE und BLINK, über den schlechten Geschmack des Web-Autors hinaus (und über Geschmack läßt sich ja nicht streiten >;->) hier einen negativen Effekt durch Nutzung proprietärer Elemente erzielt. Der positive Effekt: Es funktioniert in mehr Browsern.
Aber man kann halt auch standard-konform jede Webseite verhunzen (q.e.d.).
Gruß, Cybaer
Hello out there!
Wenn der Autor zum 3WC valide bleiben möchte, dann nimmt er halt einen JS-Ticker
Bitte nicht, denn ...
Ich sehe nicht, wo die Verwendung von MARQUEE und BLINK, über den schlechten Geschmack des Web-Autors hinaus […] hier einen negativen Effekt durch Nutzung proprietärer Elemente erzielt. Der positive Effekt: Es funktioniert in mehr Browsern.
... der positive Effekt: 'marquee' kann durch CSS-Angaben im Nutzerstylesheet zum Stillstand gebracht werden ('blink' ebenso). Bei JavaScript-Tickern hilft wohl nur die Deaktivierung von JavaScript.
See ya up the road,
Gunnar
Hi,
... der positive Effekt: 'marquee' kann durch CSS-Angaben im Nutzerstylesheet zum Stillstand gebracht werden ('blink' ebenso). Bei JavaScript-Tickern hilft wohl nur die Deaktivierung von JavaScript.
Womit dann wohl Ruhe ist.
Die wichtigste Maßnahme hast Du IMHO aber vergessen: move url,/dev/nul/
Kann *jeder* Surfer problemlos (und browserunabhängig) machen, wenn ihm eine Seite nicht gefällt! 8-))
Gruß, Cybaer
Hallo,
Kann *jeder* Surfer problemlos (und browserunabhängig) machen, wenn ihm eine Seite nicht gefällt! 8-))
bis auf die Situation wenn du irgendwie auf eine Seite angewiesen bist.
Wobei halt bei einigen Seiten wohl inzwischen ein Rechtsanspruch auf
"barrierefreie" Ausführung besteht.
Aus Gründen der Überprüfbarkeit und der Rechtssicherheit mag dann
erstmal auch Validität gefordert sein.
Damit könnten natürlich valide und nach bestimmten Kriterien
"barrierefreie", aber vielleicht zugleich schlechter zugängliche
Seiten entstehen.
Und halbwegs zugängliche Seiten sind u.U. doch noch auf CSS-Hacks
angewiesen, wobei gerade der Abschied von z.B. Layouttabellen und der
Einsatz von CSS die Situation ja eigentlich verbessern sollte...
Grüsse
Cyx23
