W3C Richtlinien

[Cybaer]

Hi,

Der Nutzer als Nutzer. Meine Erfahrung als solcher im Austausch mit anderen hat mir gezeigt, dass es wenige proprietäre Zusatztechniken breite Anwendung finden.

Kommt halt drauf an. XMLHttpRequest war auch mal eine proprietäre Zusatztechnik, innerHTML im gewissen Sinne auch.

Beide sind nach wie vor proprietär, sind aber Quasi-Standard und werden mittlerweile weithin genutzt.

Wir (Du, ich & viele andere hier im Forum) sind uns doch einig, daß man mit der eingesetzten Technik nicht User von der Website ausschließen sollte. Wir sind uns aber wohl auch einig, daß nicht jedes *Zusatz*-Feature für jeden Browser nutzbar zu sein braucht. Ich denke nicht, daß es sinnvoll ist, einem Nutzer ein Zusatzfeature zu verwehren, nur weil die anderen Surfer das mit ihrem Browser nicht nutzen können.

Wäre es so, hätte sicher niemand Probleme damit, diese auch zu nutzen und in diesem Punkten von den üblichen Standards abzuweichen.

Dann ist ja gut. Bisher hatte ich das "Validität muß sein" so gedeutet, daß Validität sein muß, nicht, daß es sein sollte, man aber davon abweichen kann, wenn es einem sinnvoll erscheint. ;)

Darauf kann man sich einigen. :)

Die opacity-Eigenschaft ist vielleicht eine, die momentan durch den Ajax-Hype mit den ganzen lahmen Bling-Bling-Effekten hochgekocht wird. Aber ob das eine essentielle Erweiterung ist, möchte ich in Frage stellen.

Es ist zumindest eines der Layout-Effekte, dich ich z.Zt. sehr gerne benutze. Ich habe auch schon Code mit gut getricksten Transparenzeffekten (aus der Vor-Opacity-Ära) mit dem Opacity-CSS (ganz im Sinne semantischen Markups) wunderbar säubern können. :)

Trotzdem stellt sich die Lage für den Webautoren vielschichtiger dar. Eine Erfindung für sich genommen unabhängig von den realen Umständen der Benutzung als sinnvoll zu erachten, ist nicht der Punkt. Er muss die mögliche Nützlichkeit damit abwägen, dass die Technik nur bei manchen Besuchern funktioniert und eventuell Alternativen nötig sind. Wenn man das mit hineinnimmt, schwindet der vermeintliche Sinn meist schnell.

Du solltest meinen Standpunkt aus vielen Threads gut genug kennen, daß Du abschätzen kannst, daß meine Priorität dem Anwender gilt, nicht dem Autor.

Es gibt wenig gute Gründe, nicht Validator-validen Code zu schreiben. Du wirst sicher welche nennen können, nicht?
Muß man das wirklich zum 50000stden Mal machen?
Ja, und sei es auch durch Verweise auf vorige Diskussionen. Schließlich kommen immer wieder welche, die diese Frage stellen.

• Das FRAME-Problem hat ja Christian bereits angesprochen
• Ich nutze WBR sehr gerne, für das es nach wie vor keinen validen Ersatz ohne Nachteile gibt (wie ja im Archiv auch nachzulesen ist)
• Ich habe kein Problem damit, einer Tabelle, der ich mit CSS' height eine Höhe zugewiesen habe, dies als Fallback für ältere Non-CSS-Browser mit dem HEIGHT-Attribut ebenfalls zu tun.
• generell habe ich überhaupt kein Problem damit, veraltete Tags & Attribute als Fallback zu verwenden. Selbst wenn meine Quelltexte auf Browser träfen, die sie nicht mehr unterstützen würden: Egal - sie sind auch nicht für diese Browser gedacht.
• Ich habe auch kein Problem damit, eigene Tags und Attribute zu "erfinden", die ich aus irgendwelchen *internen* organisatorischen Gründen brauche. Ich nutze das nicht intensiv, und so extensiv wie es manche Editoren und CMS-System nutzen, ist es mir ggf. auch ein Greuel, aber die Möglichkeit als solche nutze ich durchaus.
• Ich habe auch kein Problem damit, proprietäre Tags zu nutzen, die ich als sinnvoll erachte. Das muß nicht unbedingt MARQUEE sein (Laufschriften mag ich persönlich nicht, aber ich bin auch kein "blindwütiger Laufschrifthasser", sondern erkenne durchaus an, daß es gute Gründe für Laufschriften geben kann - sowohl aus wahrnehmungspsychologischer, als auch philosophischer Sicht). Auch CANVAS würde ich jederzeit nutzen - zumal das ja eine Alternative für CANVAS-lose Browser nicht ausschließt.

etc.

Gruß, Cybaer