warum HTML pervers ist und XHTML nicht...

[Kai Lahmann]

hi

ich hab' mir mal überlegt, was passiert, wenn ein ganz sturer Parser auf eine gültige HTML- oder XHTML-Datei stößt. Da kommt bei HTML sicherlich als erstes die Frage, ob das eine oder andere Attribut nun Anführungszeichen haben muss, oder nicht. Wer ist eigentlich beim W3C auf den Bolzen gekommen, dass man die Dinger manchmal weglassen kann? Imho wird's dadruch wahnsinnig chaotisch...
Noch schöner sind die optionalen oder ganz fehlenden End-Tags - woher soll der Parser (der ja noch nichts von der Bedeutung der Tags weiß!) wissen, ob ein nicht vorhandenes Endtag nun ein Fehler ist oder so ok..? Sicher kann er in der DTD nachsehen, aber dafür muss er erstmal die komplette Dateio gelesen haben - es könnte ja sein, dass das Tag (z.B. ein <li>) doch noch irgendwo geschlossen wird... Somit kann also ein stur nach HTML arbeitender Browser auch erst etwas anzeigen, wenn alles geladen ist - vorher weiß er ja nichtnur nicht, ob die Datei gültigt, noch wo nun das eine oder andere Tag nun zu Ende ist. Insbesondere bei einem <li> stellt sich dann auch noch auf der Darstellungs-Ebene die Frage, wo man das Ding nun als "zu Ende" annehmen kann (oder muss).
Bei XHTML ist dagegen eindeutig geregelt, wo ein Tag zu Ende ist - wenn es mit /> endet sofort, sonst eben erst, wenn ein </li> kommt (um mal bei dem Beispiel zu bleiben.
Was ich damit sagen will, ist, dass HTML nicht wirklich logisch ist, es ist eine Aneinanderreihung von Ausnahmen von Ausnahmen, die man kaum verstehen kann, soetwas muss man als Browser eigentlich falsch interpretieren.

Wie haltet ihr das, benutzt ihr alle "normales" HTML oder wird lieber in XHTML geschrieben?
Ich persönlcih versuch' immer XHTML1.1 zu schreiben, wenn das - warum auch immer - nicht geht zumindest innerhalb der XHTML-Syntax zu bleiben.

Grüße aus Bleckede

Kai

[Sven Rautenberg]

Moin!

ich hab' mir mal überlegt, was passiert, wenn ein ganz sturer Parser auf eine gültige HTML- oder XHTML-Datei stößt. Da kommt bei HTML sicherlich als erstes die Frage, ob das eine oder andere Attribut nun Anführungszeichen haben muss, oder nicht. Wer ist eigentlich beim W3C auf den Bolzen gekommen, dass man die Dinger manchmal weglassen kann? Imho wird's dadruch wahnsinnig chaotisch...

Naja, viel schlimmer als die Tatsache, daß man die Anführungszeichen bei Zahlen weglassen darf ist die Tatsache, daß real existierende Parser in Browsern es sogar erlauben, sie bei eigentlich allen Situationen wegzulassen. Trennzeichen der Attribute ist das Leerzeichen, und Trennzeichen zwischen Attribut und Wert ist das Gleichheitszeichen. Anführungsstriche optional (auch wenn der Standard das anders sagt). Sehe ich nicht also chaotisch an. Man muß nur wissen, daß dann Leerzeichen ein Problem machen.

Noch schöner sind die optionalen oder ganz fehlenden End-Tags - woher soll der Parser (der ja noch nichts von der Bedeutung der Tags weiß!) wissen, ob ein nicht vorhandenes Endtag nun ein Fehler ist oder so ok..? Sicher kann er in der DTD nachsehen, aber dafür muss er erstmal die komplette Dateio gelesen haben - es könnte ja sein, dass das Tag (z.B. ein <li>) doch noch irgendwo geschlossen wird... Somit kann also ein stur nach HTML arbeitender Browser auch erst etwas anzeigen, wenn alles geladen ist - vorher weiß er ja nichtnur nicht, ob die Datei gültigt, noch wo nun das eine oder andere Tag nun zu Ende ist. Insbesondere bei einem <li> stellt sich dann auch noch auf der Darstellungs-Ebene die Frage, wo man das Ding nun als "zu Ende" annehmen kann (oder muss).

Tja, die Frage ist doch: Wenn man sich als Parser in einer Liste befindet, was kann man erwarten?

Zwingend zu erwarten ist das erste <li>. Dann kann allerhand Stoff kommen, welcher zwingend in Tags einzuschließen ist wie z.B. <b>. Dinge wie <p> haben innerhalb von <li> nicht unbedingt etwas verloren. Aber egal: Wenn ein weiteres <li> kommt, ist genau vorher ein </li> anzunehmen und der <li>-Block somit geschlossen. Es gibt keine weitere Möglichkeit, denn <li> kann nicht geschachtelt werden - dazu müßte eine neue Liste eröffnet werden.

<p> ist genauso ein Kandidat: Wenn eines kommt, ist vorher einfach </p> anzunehmen.

Ok, es vereinfacht die Sache natürlich nicht, und die Browser geraten schonmal darüber in Streit, wie denn eine nicht abgeschlossene Tabellenstruktur auszusehen hat. Ich schließe alle schließbaren Tags immer.

Bei XHTML ist dagegen eindeutig geregelt, wo ein Tag zu Ende ist - wenn es mit /> endet sofort, sonst eben erst, wenn ein </li> kommt (um mal bei dem Beispiel zu bleiben.

Ja, es macht die Parserarbeit einfacher. HTML ist da etwas interpretationsfähiger. Umso mehr sollte man sich Tag-Schließen angewöhnen. :)

Was ich damit sagen will, ist, dass HTML nicht wirklich logisch ist, es ist eine Aneinanderreihung von Ausnahmen von Ausnahmen, die man kaum verstehen kann, soetwas muss man als Browser eigentlich falsch interpretieren.

HTML ist logisch. Wäre es nicht logisch, könnte es von einer Programmlogik ja nicht ausgewertet werden. Abgesehen davon ist HTML, wenn man es schön schreibt, genauso toll oder untoll wie XHTML. Mit Dem Unterschied, daß in XHTML noch ein paar zusätzliche Bedingungen für die Schreibweise gelten, die von XML hereingekommen sind.

Wie haltet ihr das, benutzt ihr alle "normales" HTML oder wird lieber in XHTML geschrieben?

HTML ist vollkommen ausreichend. Von meiner eigenen Homepage gibts irgendwo auf der Platte sogar eine Strict-Version, für Kunden schreibe ich transitional wegen Netscape 4 (der macht sonst z.B. Rahmen um verlinkte Bilder, die man mit CSS nicht abstellen kann), aber möglichst strict.

Ich persönlcih versuch' immer XHTML1.1 zu schreiben, wenn das - warum auch immer - nicht geht zumindest innerhalb der XHTML-Syntax zu bleiben.

Mir ist XHTML 1.1 noch ziemlich schnuppe. Ich hab noch nicht mit XML/XSLT/etc zu tun gehabt, und mein Lieblingseditor Phase 5 unterstützt bei seinen klugen Hilfsfunktionen nur HTML, aber kein XHTML. Das ist IMO ein guter Grund, erstmal bei HTML zu bleiben.

Abgesehen davon denke ich, daß XHTML überschätzt wird. Natürlich ist es gut, wenn das W3C an der Entwicklungsfront etwas Druck macht, um neue Standards zu etablieren. Riesige Sprünge wird es im HTML-Bereich dort aber IMO demnächst nicht geben. Viel wichtiger hingegen ist, daß die Browserunterstützung hinterherkommt. Bei Mozilla sehe ich da keine Probleme, Opera bleibt auch am Ball - viel schlimmer ist der IE. Bin gespannt, was Microsoft da in der nächsten Version einbaut - und was wieder einmal ignoriert wird.

- Sven Rautenberg

[Kai Lahmann]

hi

Tja, die Frage ist doch: Wenn man sich als Parser in einer Liste befindet, was kann man erwarten?

der Parser weiß ja *eigentlich* noch gar nicht, was ein <li> ist! Und genau das ist auch der Grund, weshalb man HTML/SGML ohne DTD überhaupt nicht gebrauchen kann, es ist nichteinmal möglich das ganze auf Syntaktische Richtigkeit zu prüfen. Bei XML ist auch ohne die DTD zu erkennen, ob die Datei gültig ist, hier  bleibt später nur noch die Frage, ob alle angegebenen Attribute ihre Richtigkeit haben.

<p> ist genauso ein Kandidat: Wenn eines kommt, ist vorher einfach </p> anzunehmen.

Da hat sich wohl ein "sobald etwas auftaucht, was nicht in einem <p> sein darf" eingebürgert - also bei dem nächsten Block-Element.

Ja, es macht die Parserarbeit einfacher. HTML ist da etwas interpretationsfähiger. Umso mehr sollte man sich Tag-Schließen angewöhnen. :)

Solange es die Browser dann wenigsten verstehen - mich würde da bei 2 "üblichen Verdächtigen" nicht wundern, wenn die ein </p> oder </li> einfach komplett ignorieren.

HTML ist logisch. Wäre es nicht logisch, könnte es von einer Programmlogik ja nicht ausgewertet werden.

wie du schon sagtest, wird die volle Logik gar nicht erfasst, ein Browser nimmt die "" hin, wenn sie da sind, wenn nicht, dann ist das nächste Leerzeichen der Trenner - dieses "wenn, dann aber sondern außer" ist aber nicht so vom W3C gedacht!
Imho ist auch eine der wichtigen Neuerungen an XHTML, dass es klare Regeln gibt, wie mit ungültigem Code umzugehen ist. Ich bin auch der Meinung, dass sämtliche "depend on Useragent" aus den W3C-Standards verschwinden müssen, es wird einfach immer irgendeine Inkompatibilität geben, wo Annahmen durch die Seitengestalter mal ganz abgesehen.

Abgesehen davon denke ich, daß XHTML überschätzt wird. Natürlich ist es gut, wenn das W3C an der Entwicklungsfront etwas Druck macht, um neue Standards zu etablieren. Riesige Sprünge wird es im HTML-Bereich dort aber IMO demnächst nicht geben. Viel wichtiger hingegen ist, daß die Browserunterstützung hinterherkommt. Bei Mozilla sehe ich da keine Probleme, Opera bleibt auch am Ball - viel schlimmer ist der IE. Bin gespannt, was Microsoft da in der nächsten Version einbaut - und was wieder einmal ignoriert wird.

Da bin ich auch gespannt und meine Wunschliste ist nicht eben kurz, als da wären:
-> position:fixed;
-> voller PNG + MNG-Suport
-> im Standards-mode nochmal strenger werden mit Fehlern.
-> erste Quirks rauskicken, speziell das "=" in CSS
-> alle Berechnungsfehler bei CSS versenken
-> :hover für alle Tags
-> in der JS-Konsole bei nach W3C invalidem code ein warning ausgeben
-> komplettes W3C-DOM
-> Favicons schon mit rel="icon" erkennen und auch andere Formate zuzulassen
-> Selectors auf CSS2, besser noch CSS3 Stand - aber auch nicht nur halben Kram
-> 'text-shadow:' rein und die dadurch obsoleten filter zumindest im Standards mode raus.

..ups, ich wollte mich doch auf 10 Punkte beschränken...

Grüße aus Bleckede

Kai

[Kai Lahmann]

hi

Da bin ich auch gespannt und meine Wunschliste ist nicht eben kurz, als da wären:
-> position:fixed;
-> voller PNG + MNG-Suport
-> im Standards-mode nochmal strenger werden mit Fehlern.
-> erste Quirks rauskicken, speziell das "=" in CSS
-> alle Berechnungsfehler bei CSS versenken
-> :hover für alle Tags
-> in der JS-Konsole bei nach W3C invalidem code ein warning ausgeben
-> komplettes W3C-DOM
-> Favicons schon mit rel="icon" erkennen und auch andere Formate zuzulassen
-> Selectors auf CSS2, besser noch CSS3 Stand - aber auch nicht nur halben Kram
-> 'text-shadow:' rein und die dadurch obsoleten filter zumindest im Standards mode raus.

einen hab' ich noch:
alt="" NICHT mehr als Tooltipp!

Grüße aus Bleckede

Kai

[Jonas Hartmann]

hi

Da bin ich auch gespannt und meine Wunschliste ist nicht eben kurz, als da wären:
-> position:fixed;
-> voller PNG + MNG-Suport
-> im Standards-mode nochmal strenger werden mit Fehlern.
-> erste Quirks rauskicken, speziell das "=" in CSS
-> alle Berechnungsfehler bei CSS versenken
-> :hover für alle Tags
-> in der JS-Konsole bei nach W3C invalidem code ein warning ausgeben
-> komplettes W3C-DOM
-> Favicons schon mit rel="icon" erkennen und auch andere Formate zuzulassen
-> Selectors auf CSS2, besser noch CSS3 Stand - aber auch nicht nur halben Kram
-> 'text-shadow:' rein und die dadurch obsoleten filter zumindest im Standards mode raus.

einen hab' ich noch:
alt="" NICHT mehr als Tooltipp!

• Support für Audiosstandards OGG und irgendein guter offener XM/MOD Standard
• Styles Menu (css styles) wie im mozilla1.0/nn7

[Orlando]

Hi ihr Weltverbesserer ;)

-> position:fixed;
-> voller PNG + MNG-Suport
-> im Standards-mode nochmal strenger werden mit Fehlern.
-> erste Quirks rauskicken, speziell das "=" in CSS
-> alle Berechnungsfehler bei CSS versenken
-> :hover für alle Tags
-> in der JS-Konsole bei nach W3C invalidem code ein warning ausgeben
-> komplettes W3C-DOM
-> Favicons schon mit rel="icon" erkennen und auch andere Formate zuzulassen
-> Selectors auf CSS2, besser noch CSS3 Stand - aber auch nicht nur halben Kram
-> 'text-shadow:' rein und die dadurch obsoleten filter zumindest im Standards mode raus.

alt="" NICHT mehr als Tooltipp!

• Support für Audiosstandards OGG und irgendein guter offener XM/MOD Standard
• Styles Menu (css styles) wie im mozilla1.0/nn7

• MDI (Multiple Document Interface)
• native Unterstützung von SVG
• annehmbare Sicherheit (inkludiert intuitive Einstellungsmöglichkeiten)
• Teilweise Deaktivierung von JS
• Fullscreen (Kiosk) fliegt raus
• Geschwindigkeitssteigerung um Faktor >= 2

Aber eigentlich wünsche ich mir, dass dies alles _nicht_ passiert, die Seitenbastler sich einen Dreck um die Bugs kümmern und viel mehr Leute auf Alternativen ausweichen.

• Der IE soll nicht mehr im Lieferumfang von Windows enthalten sein.

Und wer schreibt jetzt an's Christkind?

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[ich]

Hi ihr Weltverbesserer ;)

Jo...

-> position:fixed;
-> voller PNG + MNG-Suport
-> im Standards-mode nochmal strenger werden mit Fehlern.
-> erste Quirks rauskicken, speziell das "=" in CSS
-> alle Berechnungsfehler bei CSS versenken
-> :hover für alle Tags
-> in der JS-Konsole bei nach W3C invalidem code ein warning ausgeben
-> komplettes W3C-DOM
-> Favicons schon mit rel="icon" erkennen und auch andere Formate zuzulassen
-> Selectors auf CSS2, besser noch CSS3 Stand - aber auch nicht nur halben Kram
-> 'text-shadow:' rein und die dadurch obsoleten filter zumindest im Standards mode raus.

alt="" NICHT mehr als Tooltipp!

• Support für Audiosstandards OGG und irgendein guter offener XM/MOD Standard
• Styles Menu (css styles) wie im mozilla1.0/nn7

• MDI (Multiple Document Interface)
• native Unterstützung von SVG
• annehmbare Sicherheit (inkludiert intuitive Einstellungsmöglichkeiten)
• Teilweise Deaktivierung von JS
• Fullscreen (Kiosk) fliegt raus
• Geschwindigkeitssteigerung um Faktor >= 2

Ich hab noch was:

MIME-Type soll Vorrang vor Extension (z.B. *.DOC, *.XLS, usw.) haben... Damit man dieses nervige Word/Excel/sonstwas gestarte anstelle von runterladen mal unterbinden kann, wenn man es denn möchte.

• Der IE soll nicht mehr im Lieferumfang von Windows enthalten sein.

Und wer schreibt jetzt an's Christkind?

ICH!
Adresse?!?

LG Orlando

Bye
Ich

[Kai Lahmann]

hi

• native Unterstützung von SVG

stimmt! Oder ein brauchbares Plugin immer dabei.

MIME-Type soll Vorrang vor Extension (z.B. *.DOC, *.XLS, usw.) haben... Damit man dieses nervige Word/Excel/sonstwas gestarte anstelle von runterladen mal unterbinden kann, wenn man es denn möchte.

auch keine schlechte Idee - vielleicht sogar eine _ausschließliche_ Beachtung des Mime-Type, wie es der HTTP-Standard vorscheibt?

@Orlando:
es geht mir vor allem um Dinge um Inkompatibilitäten zum Standard abzubauen.

Grüße aus Bleckede

Kai

[molily]

Hallo.

• native Unterstützung von SVG
  stimmt! Oder ein brauchbares Plugin immer dabei.

Plugins sind scheiße[tm]. Ich will SVG, aber kein Flash. Den SVG-Plugin habe ich natürlich installiert, aber man kann Plugins nicht ungestraft aktiviert lassen, ohne dass man auf jeder zweiten Seite mit Flash genervt wird. Eine native Unterstützung sollte schon sein. Für "normale" Bitmapgrafiken muss man  schließlich auch nicht die Sicherheit vernachlässigen.
Ich glaube, das alles meintest du mit "brauchbar". ;)

auch keine schlechte Idee - vielleicht sogar eine _ausschließliche_ Beachtung des Mime-Type, wie es der HTTP-Standard vorscheibt?

Ich glaube, diese verbreitete Praxis soll eine Sicherheit gegen das Fälschen des Mime-Typs geben. Ich dagegen hatte nie Probleme damit, also dass ich eine ausführbare Datei nicht als solche erkannt hatte o.ä.

Mathias

[Orlando]

Hi Kai,

es geht mir vor allem um Dinge um Inkompatibilitäten zum Standard abzubauen.

dein Ziel in allen Ehren, aber ob ein Thread im SELFFORUM Micro$oft dazu bewegt, den IE standardtreu zu machen, bezweifle ich. Oder weißt du da mehr als ich? Bis du etwa überglaufen? *fg*

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Kai Lahmann]

hi

dein Ziel in allen Ehren, aber ob ein Thread im SELFFORUM Micro$oft dazu bewegt, den IE standardtreu zu machen, bezweifle ich. Oder weißt du da mehr als ich? Bis du etwa überglaufen? *fg*

nun, wenn ich tatsächlich die Möglichkeit hätte da was zu sagen, würde ich schon die Marktmacht als Druckmittel in Richtung Standards einsetzen und dem Ding sogar eine geringere Tolleranz als Mozilla in Standards mode verpassen - zumindest kann Microsoft aber relativ bald die Sachen rausschmeißen, die sich nichtmal Mozilla/Netscape 7 im Quirks mode gafallen läßt und eben document.all _offiziell_ für depricated erklären, dann wird sich was (oder besser sehr viel) bewegen. Ich weise darauf hin, dass _kein_ noch vom Hersteller supporteter Browser weltweit auf document.all angewiesen ist!

Grüße aus Bleckede

kai

[emu]

Hallo!

Und wer schreibt jetzt an's Christkind?

ICH!
Adresse?!?

Das Christkind
Christkindlweg 6
4411 Christkindl
Österreich

Innerhalb Österreichs wirst du vermutlich nur "An das Christkind" draufschreiben müssen.

Das Sonderpostamt öffnet erst am 1. Dezember wieder seine Pforten, davor wird das Christkind den Brief kaum bekommen. Man kann über das Postamt auch Briefe schicken - es wäre vielleicht interessant, mit Sonderbriefmarke und Sonderstempel eine Wunschliste zum amerikanischen Partnerunternehmen (mit einer schleichenden feindlichen Übernahme) Weihnachtsmann zu schicken.

emu
[scnr]

[molily]

Hallo zusammen.

Hi ihr Weltverbesserer ;)

Genau, nicht nur schwafeln, "machen machen machen" sollten wir, bspw. IE-Viren schreiben (Aufruf zur Straftat). Und zwar möglichst noch vor Ende der Legislaturperiode. *fg*

-> voller PNG + MNG-Suport

Ich möchte behaupten, dass 95 von 100 Webseiten GIF-Grafiken statt PNG benutzen. Und nichts spricht dafür, dass sich dies plötzlich ändern wird, die Alternative PNG ist nicht neu und bis jetzt hat sie sich nicht durchgesetzt - obwohl die überwältigende Mehrheit der verwendeten Browser bereits lange grundlegende PNG unterstützt, das ist also kein Hindernis.
MNG sind mir noch nie im Web begegnet; werden die überhaupt unterstützt (von Mozilla)?
(Sollte nicht deine Forderung ablehnen... obwohl, auf animierte GIFs kann ich gerne verzichten. Ich fordere, dass man GIF/MNG-Animationen deaktivieren kann, siehe Opera.)

-> :hover für alle Tags

Ich wünsche der Welt eher ein Button im IE, um per Mausklick/Knopfdruck das Autorenstylesheet zugunstendes Benutzerstylesheets deaktivieren zu können. Im Mozilla ist es genauso, ohne title-Attribut im link-Element kann man den Autorenstyle nur schwer "mal eben" deaktivieren. Wenn man schon vom Opera abschaut, dann bitte die coolsten Features wie u.a. das F12-Menü, die den Opera zum benutzerfreundlichsten Browser machen (imho).

-> Favicons schon mit rel="icon" erkennen und auch andere Formate zuzulassen

Ich fordere, dass der Benutzer Favicons-Request wie im Mozilla abschalten kann. IMHO ist das völlig unnütz und verschwendet nur Bandbreite (sorry, Stefan Einspender :)).

-> Selectors auf CSS2, besser noch CSS3 Stand - aber auch nicht nur halben Kram

CSS3-Selektoren im Internet Explorer? Utopisch, sage ich nur... :) - zumindest in der nächsten Zeit. Aber ich lasse mich allzu gerne vom Gegenteil überzeugen.

alt="" NICHT mehr als Tooltipp!

Einspruch! Im Falle des Vorhandenseins eines alt-Attributes werden die enthaltenen Metainformationen angezeigt; wenn ein title gesetzt ist, wird der Inhalt dieses Attributs im Tooltip angezeigt. Das kann ich nur begrüßen, denn: Einerseits benutzen 99,9% aller Seiten das alt- anstatt das title-Attribut (oder weder noch), somit stecken oft (wenn überhaupt) Informationen im alt-Atribut, welche eigentlich in ein title-Attribut gehörten. Andererseits finde ich den Alternativtext, selbst wenn er nur als Alternativtext für diejenigen gedacht ist, welche die Grafik nicht sehen können/wollen, informativ, sodass ich ich richtig finde, dass er bei fehlendem title-Attribut angezeigt wird. Natürlich sagt der W3C-Standard etwas anderes, aber in diesem Punkt finde ich die "Zuwiderhandlung" richtig, wenn man die reale Verbreitung von alt und title in Erwägung zieht.
Mir würde eine Visualisierung des longdesc-Attributs gefallen. Gibt es nicht im Internet Explorer ein Menü, welches bei jeder Grafik angezeigt wird, wenn man sie mit der Maus überfährt? (Ich habe das direkt nach der Installtion abgeschaltet. :)) So könnte man den longdesc-Hyperlink visualisieren. Umständliches Kontextmenü-Geklicke (siehe Mozilla) finde ich kontraproduktiv. Da erfasse ich die Attributwerte ja schneller, wenn ich den Quelltext lese.

• native Unterstützung von SVG

Ist der Farbverfälschungs-Bug (alles war mehr oder weniger blau-grün) bei SVG in Mozilla eigentlich mittlerweile gefixt? Dann könnte ich mir mal wieder einen neuen nightly build herunterladen.

• annehmbare Sicherheit (inkludiert intuitive Einstellungsmöglichkeiten)

ActiveX rausschmeißen. :)

• Geschwindigkeitssteigerung um Faktor >= 2

*confused* Redest du vom IE oder Mozilla...? :) Der Internet Explorer 6 ist auf meinem betagten Pentium 133 im Vergleich zum ungeschlagenen Opera 6.03 relativ schnell. Über den Daumen gepeilt braucht er (geschätzt) 1,2 bis 1,5mal solange, um eine Seite zu rendern. Bestimmte Seiten (>200KB) rendert der IE sogar schneller, während Opera schlichtweg crasht und Mozilla... *lach* der belegt im Leerlauf 25 MB RAM und rendert bei mir nahezu alle Seiten doppelt oder dreimal solange. Einige Performance-Tests:

Foren-Hauptdatei, lokal gespeichert, ohne Grafiken, mit CSS, Ladezeitpunkt: Montag, 01. Juli 2002, 14:39:23 Uhr, Größe 195 KB.
  Opera: 5-6 Sekunden
  Internet Explorer: 7-8 Sekunden
  Mozilla: 16-17 Sekunden (präzise reproduzierbar, da Mozilla die schöne Zeitanzeige hat)

Soweit ich mich an Opera 5 erinnere würde ich auf 4-5 Sekunden tippen.

Ein mit icqhr extrahierter Chatlog im HTML-Format, meist nur p- und font-Elemente und viel Text, Größe 4,7 MB (!).
  Mozilla 285 Sekunden (Rendervorgang schluckt 36 MB Arbeitsspeicher und 18 MB Auslagerungsdatei) *hihi* ;)
  IE 78 Sekunden (Rendervorgang schluckt 28 MB RAM und 0 MB Auslagerungsdatei)
  Opera 88 Sekunden (Rendervorgang schluckt 5 MB RAM und 7 MB Auslagerungsdatei[*])

[*] Nach Schließen der Datei waren jedoch von 0 auf 24 MB RAM frei, die Belegung der Auslagerungsdatei bliebt in etwa gleich groß. Was nun in der Auslagerungsdatei wirklich vom Browser/für das Renderung der Datei eingenommen wurde, ist nicht feststellbar.

(Je nachdem, wieviel RAM - von 64 MB Gesamt - gerade frei war, wurde erst der RAM benutzt und dann die Auslagerungsdatei. Die angegebenen Zahlen für RAM und Auslagerungsdatei stellen jeweils die Differenz zwischen den Werten kurz vor und kurz nach dem Rendervorgang dar bzw. nach Schließen der Datei.)

Nach diesen Tests solltest du dich vielleicht fragen, *wer* hier eine Geschwindigkeitssteigerung am dringendsten nötig hat. :) Ich denke, man kann auch *ungefähr* herauslesen, welchen der drei Browser ich bevorzuge... :)

Aber eigentlich wünsche ich mir, dass dies alles _nicht_ passiert, die Seitenbastler sich einen Dreck um die Bugs kümmern und viel mehr Leute auf Alternativen ausweichen.

Die *Seitenbastler* kümmern sich ein Dreck um die Alternativen; die Masse setzt still den Internet Explorer voraus, ohne sich dessen Bugs bewusst zu sein - wenn man grottig programmiert, stößt man auf diese Probleme gar nicht.
Mit zwanghaft nonkonformem "Best viewed with any browser != Internet Explorer" kann man den IE nicht ausrotten. Wer den Internet Explorer benutzt, dem kann man keine Emanzipation durch Aufklärung aufzwingen, "er will doch einfach nur surfen". (Sage mir deinen Browser und ich sage dir, wer du bist... *pfeif*) Keiner der Menschen, die das Internet als Medium konsumieren, interessiert sich für XHTML, CSS, DTD, W3C, HTTP, (...) oder hat tiefen Einblick in die Vor- und Nachteile verschiedener Browser, speziell den IE-Unzulänglichkeiten. Selbst wenn sie das Web mitgestalten und interaktiv daran teilnehmen, werden sie die hier im Thread angesprochenen Verbesserungen größtenteils nur marginal tangieren. Bis bspw. position:fixed Frames abgelöst hat, bis das DOM-Modell über proprietäre DHTML-Implementationen herrscht und bis man mit CSS voll interoperable Netzseiten basteln kann, dürften noch eine handvoll Jahre vergehen.

• Der IE soll nicht mehr im Lieferumfang von Windows enthalten sein.

Eher wird IE Open Source. ;-) Es hört sich leider zu schön an, um wahr zu sein.

<img src="http://www.modernhumorist.com/propaganda/bundle.jpg" border=0 alt="">

Mathias ("man darf ja 'mal träumen")

[Kai Lahmann]

hi

Ich möchte behaupten, dass 95 von 100 Webseiten GIF-Grafiken statt PNG benutzen. Und nichts spricht dafür, dass sich dies plötzlich ändern wird, die Alternative PNG ist nicht neu und bis jetzt hat sie sich nicht durchgesetzt - obwohl die überwältigende Mehrheit der verwendeten Browser bereits lange grundlegende PNG unterstützt, das ist also kein Hindernis.

Es wird kaum genutzt, weil der Hauptvorteil eben nicht funktioniert und es sich somit nicht lohnt.

MNG sind mir noch nie im Web begegnet; werden die überhaupt unterstützt (von Mozilla)?

jo.

(Sollte nicht deine Forderung ablehnen... obwohl, auf animierte GIFs kann ich gerne verzichten. Ich fordere, dass man GIF/MNG-Animationen deaktivieren kann, siehe Opera.)

das ist ja ein vorteil für die User - iih ne, die sollen da ja von weg..:)

alt="" NICHT mehr als Tooltipp!

Einspruch! Im Falle des Vorhandenseins eines alt-Attributes werden die enthaltenen Metainformationen angezeigt; wenn ein title gesetzt ist, wird der Inhalt dieses Attributs im Tooltip angezeigt. Das kann ich nur begrüßen, denn: Einerseits benutzen 99,9% aller Seiten das alt- anstatt das title-Attribut (oder weder noch), somit stecken oft (wenn überhaupt) Informationen im alt-Atribut, welche eigentlich in ein title-Attribut gehörten. Andererseits finde ich den Alternativtext, selbst wenn er nur als Alternativtext für diejenigen gedacht ist, welche die Grafik nicht sehen können/wollen, informativ, sodass ich ich richtig finde, dass er bei fehlendem title-Attribut angezeigt wird. Natürlich sagt der W3C-Standard etwas anderes, aber in diesem Punkt finde ich die "Zuwiderhandlung" richtig, wenn man die reale Verbreitung von alt und title in Erwägung zieht.

Es MUSS genau deshalb geändert werden.

• native Unterstützung von SVG

Ist der Farbverfälschungs-Bug (alles war mehr oder weniger blau-grün) bei SVG in Mozilla eigentlich mittlerweile gefixt? Dann könnte ich mir mal wieder einen neuen nightly build herunterladen.

keine Ahnung, ist aber eh "nur" bei eienr Farbtiefe...

Die *Seitenbastler* kümmern sich ein Dreck um die Alternativen; die Masse setzt still den Internet Explorer voraus, ohne sich dessen Bugs bewusst zu sein - wenn man grottig programmiert, stößt man auf diese Probleme gar nicht.

jo, genau daher sollte MS evtl. sogar _verpflichtet_ werden, dass diese Probleme auch damit auftauchen.

allgemein fällt auf, dass du Uhrsache und Wirkung vertauschst - eine Feature wird nicht in den Browser eingebaut, weil es genutzt wird, sondern damit es genutzt werden kann. Genau daher sind all die oben genannten Änderungen an der Engine so wichtig. Das GUI drumherum ist mir egal, aus sicht eienr großen Vielfalt wünsche ich es mir unkompfortabel und unbenutzbar.

Grüße aus Bleckede

Kai

[molily]

Hallo, Kai.

Und nichts spricht dafür, dass sich dies plötzlich ändern wird, die Alternative PNG ist nicht neu und bis jetzt hat sie sich nicht durchgesetzt - obwohl die überwältigende Mehrheit der verwendeten Browser bereits lange grundlegende PNG unterstützt, das ist also kein Hindernis.

Es wird kaum genutzt, weil der Hauptvorteil eben nicht funktioniert und es sich somit nicht lohnt.

Ich denke, dass PNG auch ohne dass der meistverwendete Browser Transparenz, Alpha-Layer etc. unterstützt einen genügend großen Reiz für Seitenprogrammierer darstellen (nicht zuletzt die bessere Komprimierung). Demnach verstehe ich nicht, wieso sich PNG noch nicht durchgesetzt hat.
Aber für mich ist es selbstverständlich, dass ich PNG nutze; du hast wohl recht, wenn es darum geht jemanden zu überzeugen, PNGs zu benutzen, wenn doch der Internet Explorer und damit die Mehrheit der Benutzer die Verbesserung überhaupt bemerkt bzw. eine Verschlechterung eintritt.

Genauso denke ich über die neuen JPEG-Standards. IMHO ist das Web recht träge, wenn es neue Standards setzen sich langsam durch.
Aber du hast vollkommen recht, wenn es Benutzeragenten gibt, die die Features unterstützen, benutzen sie Seitenautoren auch (manchmal "leider"). Wenn es dann noch WYSIWYG-Editoren gibt, mit denen jeder Unbegabte das Feature auf einer Netzseite einbauen kann und es im Falle von JPEG/PNG/MNG auch dementsprechende Grafikprogramme gibt,
dann ist die Verbreitung sicher.

(Fullquote beabsichtigt:)

alt="" NICHT mehr als Tooltipp!
Einspruch! Im Falle des Vorhandenseins eines alt-Attributes werden die enthaltenen Metainformationen angezeigt; wenn ein title gesetzt ist, wird der Inhalt dieses Attributs im Tooltip angezeigt. Das kann ich nur begrüßen, denn: Einerseits benutzen 99,9% aller Seiten das alt- anstatt das title-Attribut (oder weder noch), somit stecken oft (wenn überhaupt) Informationen im alt-Atribut, welche eigentlich in ein title-Attribut gehörten. Andererseits finde ich den Alternativtext, selbst wenn er nur als Alternativtext für diejenigen gedacht ist, welche die Grafik nicht sehen können/wollen, informativ, sodass ich ich richtig finde, dass er bei fehlendem title-Attribut angezeigt wird. Natürlich sagt der W3C-Standard etwas anderes, aber in diesem Punkt finde ich die "Zuwiderhandlung" richtig, wenn man die reale Verbreitung von alt und title in Erwägung zieht.
Es MUSS genau deshalb geändert werden.

Sorry, aber die Argumentation verstehe ich nicht. :) Nur weil es der W3C-Standard es vorschreibt, ist es nicht in jedem Fall richtig. Die Realität ist leider anders, es gibt nirgendwo title-Attribute, Informationen werden wenn überhaupt nur im alt-Attribut abgelegt (ich wiederhole mich). Wenn ich nur als Nutzer denke, dann will ich die Nachteile von schlechter Programmierung möglichst umgehen. Wenn ein Browser meint, gegen schlechte Programmierung vorgehen zu wollen, dann ist es erst einmal (zum Glück nur vorübergehend) ein Nachteil für den Benutzer.

Recht hast du, wenn du mit der Forderung auf den "pädagogischen Effekt" abzielst - denn wenn die Seitenautoren merken, dass das alt-Attribut wirklich nur noch als Alternativtext und nicht als Tooltip funktioniert, werden sie sich wohl besinnen, title anstatt alt zu benutzen.
Ich denke mal, das meintest du mit dem Ursache-Wirkung-Prinzip; da stimme ich dir vollends zu, frage mich aber, ob es denn wirklich so wirkungsvoll ist; weiterhin würde sich Microsoft nie trauen, plötzlich einen "idealistisch" geprägten Browser zu veröffentlichen. Der IE hat es schwer, die von ihm gerufenen Geister zu bändigen. Soll er plötzlich document.all und alle anderen eigensinnigen proprietären Erweiterungen streichen? Schön wäre es, aber nicht sehr realistisch. Microsoft hat sein eigenes Süpüchen gekocht und wird dies auch leider fortsetzen.

allgemein fällt auf, dass du Uhrsache und Wirkung vertauschst - eine Feature wird nicht in den Browser eingebaut, weil es genutzt wird, sondern damit es genutzt werden kann. Genau daher sind all die oben genannten Änderungen an der Engine so wichtig.

Im Falle von PNG habe ich o.g. Erfahrung gemacht, da nützt m.E. die volle Unterstützung der ganzen Features wenig, um die Seitenautoren zu missionieren. Es wird, wie ich denke, keine PNG-Revolution geben wird, wenn der IE PNG voll implementiert. Das wird aber nur die Zeit zeigen, da lohnt es sich nicht darüber zu streiten. Natürlich hoffe ich, dass GIFs verdrängt werden, das hätte m.E. schon vor Jahren passieren sollen, aus verschiedenen dir sicher bekannten Gründen.

Als Beispiel: Es herrscht hier wohl der Konsens, dass der Internet Explorer ganz objektiv betrachtet im Vergleich zu den anderen großen Browsern weit zurückliegt. Jeder der sich ernsthaft und ausführlich mit "Webdesign" beschäftigt, ist zu dieser Erkenntnis gekommen. Auch speziell für die Benutzer bieten andere Browser mehr - trotzdem benutzt die Mehrheit den Internet Explorer. Genauso ist es mit GIFs, und Frames, font, und und und. Das kann ich mir auch nicht erklären - deswegen kann ich nicht ohne Zweifel daran glauben, dass bessere Browser zu besseren Netzseiten führen. Es gibt auch jetzt schon unendlich tolle Features, die selbst der IE 6 unterstützt und die niemand nutzt. Wer bspw. bis jetzt nicht die Probleme von Frames begriffen hat (und das ist die Mehrheit), wird sicher nicht jauchzend auf position:fixed etc. umsteigen, wenn der IE es denn unterstützt. Mit Tabellenlayout ist es genauso, da gäbe es dutzende Beispiele.
(Alles imho natürlich... Mutmaßungen halt, ich kann nicht in die Zukunft schauen.)

Dagegen kann man einwenden, dass die Vergangenheit prächtig gezeigt hat, wie die Browserhersteller die Wirklichkeit des Webs verändern können. Wenn der Internet Explorer seine Marktmacht intelligent nutzen würde, könnte er das Web tatsächlich revolutionieren (bewusst Konjunktiv).

Das GUI drumherum ist mir egal, aus sicht eienr großen Vielfalt wünsche ich es mir unkompfortabel und unbenutzbar.

Auf was beziehst du das konkret? Ich habe beileibe keine Vereinfachungen gefordert, so habe ich das nicht gemeint. Komfortabel und benutzbar heißt für mich keinesfalls simpel und "klickibunti". Obwohl ich finde, dass man Komplexität und einfache Bedienung stimmig vereinen kann.

Grundlegende Dinge, wie bspw. dass man per Mausklick/Taste die Styles oder JavaScript abschalten kann, finde ich essentiell. In meiner Rolle als Nutzer und gleichzeitig Seitenautor, der die Belange der Nutzer im Auge hat, interessiert mich schon für so etwas. Was nützt mir die Unterstützung von tollen neuen CSS-Attributen, wenn sie dazu gebraucht werden, um den Nutzer zu gängeln und ihm ein bestimmtes Design aufzwingen, ohne dass er sich "dagegen wehren" kann. Es sollte sich beides parallel entwickeln (Standardkonformität und Benutzbarkeit/Benutzerfreundlichkeit), und wenn man sich Mozilla und Opera anschaut, dann funktioniert das auch.
Oder habe ich dich jetzt vollkommen falsch verstanden? :)

Mathias

[Orlando]

Hi Mathias,

Genau, nicht nur schwafeln, "machen machen machen" sollten wir, bspw. IE-Viren schreiben (Aufruf zur Straftat).

du sprichst von einem ActiveX-Registry-Hack oder ähnlichem? Liegt alles bei mir auf der Platte...

Ich möchte behaupten, dass 95 von 100 Webseiten GIF-Grafiken statt PNG benutzen.

Ich verwende selbst auch GIFs, allerdings nur, wenn sie _bedeutend_ kleiner als PNGs sind.

Und nichts spricht dafür, dass sich dies plötzlich ändern wird, die Alternative PNG ist nicht neu und bis jetzt hat sie sich nicht durchgesetzt - obwohl die überwältigende Mehrheit der verwendeten Browser bereits lange grundlegende PNG unterstützt, das ist also kein Hindernis.

Die überwältigende Menge der verwendeten Browser ist der M$IE und der versteht von PNG ziemlich Bahnhof. Schonmal mit (eventuell gar verlaufenden) Transparenzen gearbeitet? Ich habe gestern eine _reinweiße_ Grafik erstellt, die eine verlaufende Transparenz enthält - im M$IE wird sie _grau_ dargestellt. Das muss ich erst recht wieder mit Attribut-Selektoren arbeiten, um ihn vor der Grafik 'zu schützen'. Was soll das? Muss ich das wirklich? Ich bin noch am überlegen.

(Sollte nicht deine Forderung ablehnen... obwohl, auf animierte GIFs kann ich gerne verzichten. Ich fordere, dass man GIF/MNG-Animationen deaktivieren kann, siehe Opera.)

Dazu müsste Opera aber MNG erst unterstützen ;)

-> :hover für alle Tags

Eine gute Idee.

Ich wünsche der Welt eher ein Button im IE, um per Mausklick/Knopfdruck das Autorenstylesheet zugunstendes Benutzerstylesheets deaktivieren zu können.

Da wäre noch das Problem, dass er mit CSS auch so schon gewaltige Probleme hat.

Im Mozilla ist es genauso, ohne title-Attribut im link-Element kann man den Autorenstyle nur schwer "mal eben" deaktivieren.

Das ist einer der Gründe, warum Mozilla nicht mein Standardbrowser ist. Symphatisch ist er mir durchaus.

Wenn man schon vom Opera abschaut, dann bitte die coolsten Features wie u.a. das F12-Menü, die den Opera zum benutzerfreundlichsten Browser machen (imho).

ACK

CSS3-Selektoren im Internet Explorer? Utopisch, sage ich nur... :)

Warum nicht nach den Sternen greifen? Wo dies doch ein Weihnachts-Thread ist ;)

alt="" NICHT mehr als Tooltipp!

Einspruch! [...] in diesem Punkt finde ich die "Zuwiderhandlung" richtig, wenn man die reale Verbreitung von alt und title in Erwägung zieht.

Das sehe ich anders - du verwechselst Symptom mit Ursache. Würde der M$IE richtig handeln, wären nicht (fast) alle Seiten falsch geschrieben. BTW, was sagst du dazu, dass Opera den Inhalt des title-Attributs in die Statuszeile knallt? Das ist ein ziemliches Ärgernis und absolut unverständlich.

• Geschwindigkeitssteigerung um Faktor >= 2

*confused* Redest du vom IE oder Mozilla...? :)

Von beiden. Ich nutze Opera :D

Der Internet Explorer 6 ist auf meinem betagten Pentium 133 im Vergleich zum ungeschlagenen Opera 6.03 relativ schnell.

Definiere 'relativ' ;)

Über den Daumen gepeilt braucht er (geschätzt) 1,2 bis 1,5mal solange, um eine Seite zu rendern. Bestimmte Seiten (>200KB) rendert der IE sogar schneller, während Opera schlichtweg crasht

Das ist meinem Norwegerchen kaum jemals passiert. Bei mir ist allerdings alles, was auch nur im Ansatz nach klickibunti riecht, deaktiviert.

und Mozilla... *lach* der belegt im Leerlauf 25 MB RAM und rendert bei mir nahezu alle Seiten doppelt oder dreimal solange.

Der zweite Grund, der aus meiner Sicht gegen ihn spricht. Bei überlappenden, fixierten und teiltransparenten PNGs geht er so arg in die Knie, dass Seiten teilweise unbenutzbar werden (getestet auf einem Duron 800).

[...]Nach diesen Tests solltest du dich vielleicht fragen, *wer* hier eine Geschwindigkeitssteigerung am dringendsten nötig hat. :) Ich denke, man kann auch *ungefähr* herauslesen, welchen der drei Browser ich bevorzuge... :)

Das zeugt von gutem Geschmack ;)

Aber eigentlich wünsche ich mir, dass dies alles _nicht_ passiert, die Seitenbastler sich einen Dreck um die Bugs kümmern und viel mehr Leute auf Alternativen ausweichen.

Die *Seitenbastler* kümmern sich ein Dreck um die Alternativen; die Masse setzt still den Internet Explorer voraus, ohne sich dessen Bugs bewusst zu sein - wenn man grottig programmiert, stößt man auf diese Probleme gar nicht.

Stimmt, dafür versagt er bei validen und CSS-geladenen (= guten) Seiten kläglich. Da M$ offenbar die Nähe zu den Standards sucht, werden IMHO viele Meister des Netzes in Zukunft ein Problem haben - vorausgesetzt, dieser unsägliche Interpretations-Mechanismus verschwindet aus der Rendering-Engine und es wird das dargestellt, was sich auch tatsächlich im Quelltext befindet. Aber ich prophezeie, dass dies nicht der Fall sein wird.

Mit zwanghaft nonkonformem "Best viewed with any browser != Internet Explorer" kann man den IE nicht ausrotten.

Nein, aber aufklären - sagte er blauäugig...

(Sage mir deinen Browser und ich sage dir, wer du bist... *pfeif*)

Wer bin ich? *flöt*

Keiner der Menschen, die das Internet als Medium konsumieren, interessiert sich für XHTML, CSS, DTD, W3C, HTTP, (...) oder hat tiefen Einblick in die Vor- und Nachteile verschiedener Browser, speziell den IE-Unzulänglichkeiten.

Und genau aus diesem Grund muss man die Meute darauf hinweisen wo immer man kann.

• Der IE soll nicht mehr im Lieferumfang von Windows enthalten sein.

Eher wird IE Open Source. ;-) Es hört sich leider zu schön an, um wahr zu sein.

Es wurde auch nach Wünschen gefragt, nicht nach dem, was man sich kaufen kann ;)

LG Orlando

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[molily]

Hallo, Roland,

Und nichts spricht dafür, dass sich dies plötzlich ändern wird, die Alternative PNG ist nicht neu und bis jetzt hat sie sich nicht durchgesetzt - obwohl die überwältigende Mehrheit der verwendeten Browser bereits lange grundlegende PNG unterstützt, das ist also kein Hindernis.

Die überwältigende Menge der verwendeten Browser ist der M$IE und der versteht von PNG ziemlich Bahnhof. Schonmal mit (eventuell gar verlaufenden) Transparenzen gearbeitet?

Ja, ich kenne (und hasse) das. Deswegen sagte ich "grundlegende PNG" - mir ging es nur darum, dass sie einen Großteil der "normalen" unkomplizierten GIFs ersetzen könnten und der Internet Explorer sogar mitspielen würde. Die (...die Benutzung...) entscheidenen Features von PNG bleiben natürlich, wie gesagt, auf der Strecke.

Ich habe gestern eine _reinweiße_ Grafik erstellt, die eine verlaufende Transparenz enthält - im M$IE wird sie _grau_ dargestellt. Das muss ich erst recht wieder mit Attribut-Selektoren arbeiten, um ihn vor der Grafik 'zu schützen'. Was soll das? Muss ich das wirklich? Ich bin noch am überlegen.

Entweder man erstellt serverseitig je nach Benutzeragent verschiedene Versionen oder man verzichtet auf transparente PNG, bis IE sie unterstützt. Oder man bindet sie so ein, dass es nicht stört, wenn sie nur grau angezeigt werden. Eine andere Möglichkeit gibt es wohl momentan nicht. Wie sieht es eigentlich beim Mac-IE mit PNG-Support aus?

Ich wünsche der Welt eher ein Button im IE, um per Mausklick/Knopfdruck das Autorenstylesheet zugunstendes Benutzerstylesheets deaktivieren zu können.

Da wäre noch das Problem, dass er mit CSS auch so schon gewaltige Probleme hat.

Klar - ich fordere auch einfache Oberfläche der Browser, mit der der Benutzer *ohne CSS-Kenntnisse* Autorenstyles teilweise oder auch komplett aushebeln kann. Wieso gibt es keinen "Wizard" mit dem sich jeder Unwissende sein persönliches Stylesheet nach seinen Präferenzen erstellen kann - oder vorgegebene Benutzerstylesheets, welche man auswählen kann? Wenn mehr und mehr Seiten auf CSS umsteigen, sehe ich darin die Zukunft für ein voll anpassbares und nach Belieben skalierbares Web.

alt="" NICHT mehr als Tooltipp!

Einspruch! [...] in diesem Punkt finde ich die "Zuwiderhandlung" richtig, wenn man die reale Verbreitung von alt und title in Erwägung zieht.

Das sehe ich anders - du verwechselst Symptom mit Ursache. Würde der M$IE richtig handeln, wären nicht (fast) alle Seiten falsch geschrieben.

Dazu habe ich in <?m=88671&t=15727> auch etwas gesagt. Zusammengefasst: ich bin skeptisch, ob ein besserer Internet Explorer sofort zu einer merkbaren Verbesserung führt, da gibt es noch viele andere dafür notwendigen Faktoren. Außerdem gibt es imho jetzt schon genügend Alternativtechniken, die jedoch niemand nutzt. Wenn der Internet Explorer die Seitenautoren zwingen würde, ist das natürlich etwas anderes.

BTW, was sagst du dazu, dass Opera den Inhalt des title-Attributs in die Statuszeile knallt? Das ist ein ziemliches Ärgernis und absolut unverständlich.

Das finde ich "super"! Weil ich nie zwei Sekunden auf das "Aufpoppen" des Tooltips warten will und eben schnell das Element mit dem Mauszeiger überfahre. Das finde ich sehr praktisch, deshalb gefallen mir auch "sofortige" CSS-Tooltips mit :hover und position:relative. Sicher kann ich die Aufpoppzeit in der Registry ändern, aber ob das auf alle Browser - also die komplette GUI - Auswirkungen hat, weiß ich nicht; außerdem weiß ich nicht, wo ich in der Registrierung suchen soll.

Meine Einstellungen im Opera sind wie folgt:
Preferences -> Accessibility -> Tool tips
 [X] Show tool tip for buttons
 [X] Show tool tip for links
 [X] Show tool tip for element titles

Letzteres kann man ausschalten, dann hat man keinen title in der Statuszeile, aber auch keine Tooltips mehr. :( Das nenne ich einen Reinfall.

Manchmal ärgere ich mich schrecklich darüber, denn wenn man sich folgendes Beispiel anschaut, welches direkt aus dem Leben/Web gegriffen ist:
  <a href="murks.html" title="foobar" ...>
Daran erkennt man, wie problematisch Operas Umgang mit title sein kann. (Ich denke mal, darauf spieltest du an.) In diesem Falle möchte ich den Inhalt des href-Attributes *und* dem title-Attribut schnell einsehen können - aber in der Statuszeile wird *nur* der title angezeigt, es ist also unmöglich, das Linkziel in Erfahrung zu bringen, ohne dass man obige Option abschaltet. Hier würde ich mir wünschen, dass die Statusleiste beide Attributwerte enthält (-> Chaos bei langen Attributwerten) oder der Tooltip "sofort" angezeigt wird - was aber auch problematisch ist.

IMHO ist es auch enorm wichtig, dass Browser in ihren "base stylesheets" title-Attribute etc. grafisch darstellt, Mozilla hat das schon an abbr/acronym vorgemacht. Man kann schließlich nicht auf jedes Element/jeden DOM-Node im Dokument zwei Sekunden den Mauszeiger halten. title hat IMHO nichts mit Tooltips zu tun; es ist ein Attribut, dass grafische Benutzeragenten als Tooltip anzeigen *können*, andere Möglichkeiten finde ich aber genauso sinnvoll, Hauptsache, der Benutzer kann auf die Informationen des title-Attributs zugreifen.

<werbung>http://home.t-online.de/home/dj5nu/css-attributvisualisierung.html</werbung>

• Geschwindigkeitssteigerung um Faktor >= 2

*confused* Redest du vom IE oder Mozilla...? :)

Von beiden. Ich nutze Opera :D

Nun gut, ich zwar auch, aber ich würde Mozilla bedeutend öfter "nebenbei" benutzen, wenn er nicht außerhalb der Konkurrenz in Sachen Geschwindigkeit stehen würde. Man muss sich ja nicht festlegen, denn beide Browser haben Vor- und Nachteile.

Der Internet Explorer 6 ist auf meinem betagten Pentium 133 im Vergleich zum ungeschlagenen Opera 6.03 relativ schnell.
Definiere 'relativ' ;)

Mit den Tests habe ich diese subjektive Empfindung mehr oder weniger pseudowissenschaftlich empirisch belegt. :)

Über den Daumen gepeilt braucht er (geschätzt) 1,2 bis 1,5mal solange, um eine Seite zu rendern. Bestimmte Seiten (>200KB) rendert der IE sogar schneller, während Opera schlichtweg crasht

Das ist meinem Norwegerchen kaum jemals passiert. Bei mir ist allerdings alles, was auch nur im Ansatz nach klickibunti riecht, deaktiviert.

"Bei mir auch" - aber die Tests habe ich mit reinen HTML-Dokumenten ohne Grafiken, aufwendigen Styles oder gar ausführbaren Inhalten gemacht. Anscheinend ist die Speicherverwaltung von Opera nicht so gut wie die des Internet Explorers. Der Mozilla enttäuscht in dem Punkt völlig, das finde ich sehr schade. Normalerweise ist man von Open Source-Software gewohnt, dass sie schlanker und schneller ist als kommerzielle Software mit gleicher Funktion.

und Mozilla... *lach* der belegt im Leerlauf 25 MB RAM und rendert bei mir nahezu alle Seiten doppelt oder dreimal solange.

Der zweite Grund, der aus meiner Sicht gegen ihn spricht. Bei überlappenden, fixierten und teiltransparenten PNGs geht er so arg in die Knie, dass Seiten teilweise unbenutzbar werden (getestet auf einem Duron 800).

*hehe* Dann kannst du dir sicher ausmalen, wie sich das auf einem P133 verhält. Bei SVG, "runden Ecken" oder -moz-opacity kann man Kaffeepausen einlegen. Und wenn der Adobe SVG Plugin schneller ist als eine native SVG-Unterstützung, dann läuft da doch irgendetwas mächtig schief.

[...]Nach diesen Tests solltest du dich vielleicht fragen, *wer* hier eine Geschwindigkeitssteigerung am dringendsten nötig hat. :) Ich denke, man kann auch *ungefähr* herauslesen, welchen der drei Browser ich bevorzuge... :)

Das zeugt von gutem Geschmack ;)

Ich sehe das eher ganz pragmatisch, ich belege ja meine Affinität zu Opera mit eindeutigen Argumenten. Im Grunde genommen "wäre ich gerne für Mozilla", allein schon weil er Open Source ist und damit die verkrusteten Microsoft-Monopolstrukturen kreativ unterwandert (Dekonstruktion!!! ;)).
Obwohl mir der unbekannte norwegische queer fellow, der den etablierten Browsern durch seine bahnbrechenden Innovationen das Fürchten lehrt, auch gefällt. Er ist zwar kommerziell, Ad-Ware und closed source, aber Opera Software hat im Gegensatz zu Microsoft noch nicht das Vertrauen der Benutzer verspielt.

(Sage mir deinen Browser und ich sage dir, wer du bist... *pfeif*)

Wer bin ich? *flöt*

Ich gebe zu, man kann Menschen nicht pauschal nach ihrem favorisierten Browser bewerten. Das debile Pfeifen sollte auch eine Art Ironie andeuten. ;)
Aber es gibt unzweifelhaft eine "Kategorie Seitenautoren", welcher Individuuen (*fg*) angehören, deren Horizont gerade einmal die bunte Win XP-Oberfläche, den IE 6 samt "k3wlen Features" und ein Frontpage-Klckibunti-Tabellenlayout beinhaltet. Flashintro und de.vu-Adresse dürfen auf keiner Seite fehlen. Seltsamerweise sind diese Menschen meist jung (zwischen 15 und 25 Jahre), dynamisch (wie man das auch immer verstehen mag - *fg* zum zweiten) und ersetzen im virtuellen Gespräch oft den Buchstaben 's' an Wortenden durch 'z'. "Alles am eigenen Leib erlebt (erleidet)."

Keiner der Menschen, die das Internet als Medium konsumieren, interessiert sich für XHTML, CSS, DTD, W3C, HTTP, (...) oder hat tiefen Einblick in die Vor- und Nachteile verschiedener Browser, speziell den IE-Unzulänglichkeiten.

Und genau aus diesem Grund muss man die Meute darauf hinweisen wo immer man kann.

Ich finde aggressive Hinweise wie "Sie haben JavaScript aktiviert! Pfui! <strong style="color:red; font-size:5em">Ausschalten, sofort! Dies ist ein Befehl!</strong>" einfach nur albern. (Okay, meine Netzseite beginnt mit einem ähnlichen, aber eher persiflierenden Hinweis. :)) Man kann und sollte m.E. dem Benutzer die Problematik auch differenzierter und damit verständlicher erläutern. Bei einer Aufforderung zum Browserwechsel/-update verhält sich das sicher ähnlich.

Grüße,
Mathias
(Fehler bitte ich zu entschuldigen, der gestern verschüttete Sekt "dampft" mir vom Teppich ins Hirn. ;))

[Kai Lahmann]

hi

Entweder man erstellt serverseitig je nach Benutzeragent verschiedene Versionen oder man verzichtet auf transparente PNG, bis IE sie unterstützt. Oder man bindet sie so ein, dass es nicht stört, wenn sie nur grau angezeigt werden. Eine andere Möglichkeit gibt es wohl momentan nicht. Wie sieht es eigentlich beim Mac-IE mit PNG-Support aus?

1. kann man dann wohl bis zum Sankt Nimmerleinstag warten
2. kann der Mac-IE PNGs _komplett_
3. ist es noch glück, wenn sie grau sind -> guck mal auf mozilla.linuxfaqs.de

Dazu habe ich in <?m=88671&t=15727> auch etwas gesagt. Zusammengefasst: ich bin skeptisch, ob ein besserer Internet Explorer sofort zu einer merkbaren Verbesserung führt, da gibt es noch viele andere dafür notwendigen Faktoren. Außerdem gibt es imho jetzt schon genügend Alternativtechniken, die jedoch niemand nutzt. Wenn der Internet Explorer die Seitenautoren zwingen würde, ist das natürlich etwas anderes.

korrekt. der MSIE6 läßt sich ja auch einige HTML-Fehler nicht mehr gefallen - und siehe da, sie werden korrigiert (übrigens geht das deutlich schneller, als einen Patch einzuspielen, der eine Seite mit einem anderen Browser _überhaupt_ benutzbar macht, selbst wenn dieser ein Einzeiler ist)
Grundsätzlich ist für viele Betonköpfe da draußen der MSIE das einzige Maß, wenn MS jetzt einen IE bringen würde, der nur validierte Dateien frisst, würde wohl der Vali zugefloodet werden und es würde auf einmal möglich sein ganze Seiten neu zu schreiben, wo man eben nichtmal bereit war in einer Datei ein "=" durch ":" zu ersetzen, weil es alle anderen Browser so brauchen.

Grüße aus Bleckede

Kai

[Orlando]

Hi Mathias,

eine Frage nebenbei, wofür steht denn 'molily'? Meinen Assoziationen will ich nicht so recht glauben ;)

Entweder man erstellt serverseitig je nach Benutzeragent verschiedene Versionen oder man verzichtet auf transparente PNG, bis IE sie unterstützt. Oder man bindet sie so ein, dass es nicht stört, wenn sie nur grau angezeigt werden. Eine andere Möglichkeit gibt es wohl momentan nicht. [...]

Doch, Attribut-Selektoren, durch die nur gute welche Gutes zu Gesicht bekommen und böse welche nicht böse werden ;) Das ist die einzig sichere Methode, wenn man an lügende Browser, Firewalls o.ä. denkt.

Klar - ich fordere auch einfache Oberfläche der Browser, mit der der Benutzer *ohne CSS-Kenntnisse* Autorenstyles teilweise oder auch komplett aushebeln kann. [...] Wenn mehr und mehr Seiten auf CSS umsteigen, sehe ich darin die Zukunft für ein voll anpassbares und nach Belieben skalierbares Web.

Dazu müsstest du den "Webdesignern" aber erst mal einprügeln, dass Tabellen der falsche Weg sind, eine Seite aufzuteilen. Was hab' ich denn von einer Seite, die durchaus CSS verwendet, wenn bei [Strg][G] nur die Farben wegfallen? *röchel* Ich denke, der Durchbruch für CSS kommt erst, wenn man mit mobilen User-Agents zu einem vernünftigen Preis surfen kann, also irgendwann. Dann werden sich nämlich viele Tabellen in Wohlgefallen auflösen - müssen.

BTW, was sagst du dazu, dass Opera den Inhalt des title-Attributs in die Statuszeile knallt? Das ist ein ziemliches Ärgernis und absolut unverständlich.

Das finde ich "super"!

Ich auch, abgesehen von...

<a href="murks.html" title="foobar" ...>

...diesem Ärgernis. Da frage ich mich schon, was sich die Programmierer dabei gedacht haben.

In diesem Falle möchte ich den Inhalt des href-Attributes *und* dem title-Attribut schnell einsehen können - aber in der Statuszeile wird *nur* der title angezeigt, es ist also unmöglich, das Linkziel in Erfahrung zu bringen, ohne dass man obige Option abschaltet. Hier würde ich mir wünschen, dass die Statusleiste beide Attributwerte enthält (-> Chaos bei langen Attributwerten)

Ich denke, dafür sollte genug Platz vorhanden sein, zumal man bei wirklich langen Beschreibungen ja auch auf das Tooltip warten kann.

[...] title hat IMHO nichts mit Tooltips zu tun; es ist ein Attribut, dass grafische Benutzeragenten als Tooltip anzeigen *können*, andere Möglichkeiten finde ich aber genauso sinnvoll, Hauptsache, der Benutzer kann auf die Informationen des title-Attributs zugreifen.

Da hast du wohl recht, allerdings bin ich mit dem Gebrauch als Tooltip durchaus einverstanden - wenn das Linkziel ersichtlich bleibt.

<werbung>http://home.t-online.de/home/dj5nu/css-attributvisualisierung.html</werbung>

Nette Seite, gibt's die auch für Opera? ;P

Nun gut, ich zwar auch, aber ich würde Mozilla bedeutend öfter "nebenbei" benutzen, wenn er nicht außerhalb der Konkurrenz in Sachen Geschwindigkeit stehen würde.

Sehe ich genauso, speziell, weil Opera mein Default-Browser ist und ich nebenbei immer zahlreiche Anwendungen laufen habe.

Man muss sich ja nicht festlegen, denn beide Browser haben Vor- und Nachteile.

Richtig. Opera ist schneller und IMHO auch viel besser zu bedienen, dafür ist Mozilla bei CSS ein wenig, bei DOM um Längen voraus. Aber wer braucht schon Javascript... Die einzelne Deaktivierung von Nerv-Scripts vermisse ich in Opera, dagegen ist [F12] schier genial.

Der Internet Explorer 6 ist auf meinem betagten Pentium 133 im Vergleich zum ungeschlagenen Opera 6.03 relativ schnell.
Definiere 'relativ' ;)
Mit den Tests habe ich diese subjektive Empfindung mehr oder weniger pseudowissenschaftlich empirisch belegt. :)

Schätze ich auch ;)

[...] während Opera schlichtweg crasht
[...] Anscheinend ist die Speicherverwaltung von Opera nicht so gut wie die des Internet Explorers.

Da hat sich mit 6.04 wieder etwas getan, siehe auch http://www.opera.com/windows/changelog/log604.html.

Der Mozilla enttäuscht in dem Punkt völlig, das finde ich sehr schade. Normalerweise ist man von Open Source-Software gewohnt, dass sie schlanker und schneller ist als kommerzielle Software mit gleicher Funktion.

Korrekt, wenn man 'mit gleicher Funktion' unter Einschluß des M$IE nicht _allzu_ eng auslegt *g*

[...] Bei SVG, "runden Ecken" oder -moz-opacity kann man Kaffeepausen einlegen. Und wenn der Adobe SVG Plugin schneller ist als eine native SVG-Unterstützung, dann läuft da doch irgendetwas mächtig schief.

Scheinbar hat man sich zunächst darauf konzentriert, alles abzudecken, was den Beinamen "Standard" trägt. Jetzt sollte man schleunigst an der Geschwindigkeit arbeiten, bevor der Drache von mir noch ein "optimised for P4"-Stirnband verpasst bekommt ;)

Ich sehe das eher ganz pragmatisch, ich belege ja meine Affinität zu Opera mit eindeutigen Argumenten. Im Grunde genommen "wäre ich gerne für Mozilla", allein schon weil er Open Source ist und damit die verkrusteten Microsoft-Monopolstrukturen kreativ unterwandert (Dekonstruktion!!! ;)).

Da bin ich vielleicht noch pragmatischer, ich halte auch kommerzielle (Closed Source) Software für vertretbar, wenn sie denn gut ist.

Aber es gibt unzweifelhaft eine "Kategorie Seitenautoren", welcher Individuuen (*fg*) angehören, deren Horizont gerade einmal die bunte Win XP-Oberfläche, den IE 6 samt "k3wlen Features" und ein Frontpage-Klckibunti-Tabellenlayout beinhaltet. Flashintro und de.vu-Adresse dürfen auf keiner Seite fehlen.

Du sprichst vom typischen Meister des Netzes[tm], der hier im Forum zum ersten Mal mit sachlicher Kritik konfrontiert wird und daraufhin schmollend den SelfRaum verlässt, um sich seinen Frames zu widmen.

Seltsamerweise sind diese Menschen meist jung (zwischen 15 und 25 Jahre), dynamisch (wie man das auch immer verstehen mag - *fg* zum zweiten) und ersetzen im virtuellen Gespräch oft den Buchstaben 's' an Wortenden durch 'z'.

Wenn du da mithalten willst: http://www.ibiblio.org/dbarberi/lame/ ;)

Ich finde aggressive Hinweise wie "Sie haben JavaScript aktiviert! Pfui! <strong style="color:red; font-size:5em">Ausschalten, sofort! Dies ist ein Befehl!</strong>" einfach nur albern.

Richtig, das macht man besser mit alert(), window.open() und status(), damit es auch garantiert ankommt.

LG Ro||lando ;)

--
SELF-TREFFEN 2002
http://www.rtbg.de/selftreffen/
http://www.megpalffy.org/temp/penneninhh.html

[Mathias Bigge]

Hallo Namensvetter,

alt="" NICHT mehr als Tooltipp!

Einspruch! Im Falle des Vorhandenseins eines alt-Attributes werden die enthaltenen Metainformationen angezeigt; wenn ein title gesetzt ist, wird der Inhalt dieses Attributs im Tooltip angezeigt. Das kann ich nur begrüßen, denn: Einerseits benutzen 99,9% aller Seiten das alt- anstatt das title-Attribut (oder weder noch), somit stecken oft (wenn überhaupt) Informationen im alt-Atribut, welche eigentlich in ein title-Attribut gehörten. Andererseits finde ich den Alternativtext, selbst wenn er nur als Alternativtext für diejenigen gedacht ist, welche die Grafik nicht sehen können/wollen, informativ, sodass ich ich richtig finde, dass er bei fehlendem title-Attribut angezeigt wird. Natürlich sagt der W3C-Standard etwas anderes, aber in diesem Punkt finde ich die "Zuwiderhandlung" richtig, wenn man die reale Verbreitung von alt und title in Erwägung zieht.

Sehe ich genauso, vor allem, weil ich in den Tooltipp normalerweise genau das Gleiche reinschreibe wie in das Alt-Tag. Warum soll man sich da wunde Finger holen? Vielleicht wäre ein kombiniertes Tag eine Lösung?

• annehmbare Sicherheit (inkludiert intuitive Einstellungsmöglichkeiten)
  ActiveX rausschmeißen. :)

yes, wird aber nicht passieren, da es so viele Möglichkeiten eröffnet, die etwa im Intranet auch sinnvoll sind. Vielleicht müsste man mal ehrlich zugeben, dass die Wünsche nach Sicherheit und nach Features oft gegenseitig ausschließen.

*confused* Redest du vom IE oder Mozilla...? :) Der Internet Explorer 6 ist auf meinem betagten Pentium 133 im Vergleich zum ungeschlagenen Opera 6.03 relativ schnell. Über den Daumen gepeilt braucht er (geschätzt) 1,2 bis 1,5mal solange, um eine Seite zu rendern. Bestimmte Seiten (>200KB) rendert der IE sogar schneller, während Opera schlichtweg crasht und Mozilla... *lach* der belegt im Leerlauf 25 MB RAM und rendert bei mir nahezu alle Seiten doppelt oder dreimal solange. Einige Performance-Tests:

Ich finde den Mozilla sehr nützlich, wenn man sich durch große Mengen von Suchergebnissen kämpft, da kommen bestimmte Features voll zur Geltung, aber ansonsten ist das Ding immer noch zu lahm. Leider!!!

Mit zwanghaft nonkonformem "Best viewed with any browser != Internet Explorer" kann man den IE nicht ausrotten. [ ... ]Bis bspw. position:fixed Frames abgelöst hat, bis das DOM-Modell über proprietäre DHTML-Implementationen herrscht und bis man mit CSS voll interoperable Netzseiten basteln kann, dürften noch eine handvoll Jahre vergehen.

Ja, die Predigten helfen wenig, werden aber trotzdem immer wieder gern gehalten, in Foren (Spitze to whom it may concern), Kirchen, Familien ;-)
Ich glaube auch, dass position:fixed ein ganz entscheidender Fortschritt für uns Seitenbastler sein würde, und habe, in Bezug auf die Dauer bis zur allgemeinen Umsetzung ähnliche Befürchtungen.

• Der IE soll nicht mehr im Lieferumfang von Windows enthalten sein.
  Eher wird IE Open Source. ;-) Es hört sich leider zu schön an, um wahr zu sein.

Nur durch gerichtlichen Beschluss in den USA zu erreichen. Angesichts der Rolle von Microsoft für die US-Wirschaft eher unwahrscheinlich. EIn Verfahren nach dem anderen scheint folgenlos zu bleiben.
Schade auch, dass die AOL-Leute ihre Chance verschlafen und nicht mal eine Hundertschaft guter Programmierer an die Unterstützung des Mozilla-Teams setzen - oder haben die am Ende keine guten Programmierer ;-)

Mathias (Skeptiker)

[petra]

Hallo,

Mit zwanghaft nonkonformem "Best viewed with any browser != Internet Explorer" kann man den IE nicht ausrotten. [ ... ]Bis bspw. position:fixed Frames abgelöst hat, bis das DOM-Modell über proprietäre DHTML-Implementationen herrscht und bis man mit CSS voll interoperable Netzseiten basteln kann, dürften noch eine handvoll Jahre vergehen.

Ich glaube auch, dass position:fixed ein ganz entscheidender Fortschritt für uns Seitenbastler sein würde, und habe, in Bezug auf die Dauer bis zur allgemeinen Umsetzung ähnliche Befürchtungen.

Wo ist denn jetzt der große Unterschied zwischen position:fixed und Frames? Ich denke dass viele mit statischen Seiten arbeiten und da bringt ein position:fixed nichts. Versteh mich nicht falsch, ich denke da an Low-Budget Seiten wie "mein Chef macht einen Seite für seinen Verein, Internet-Präzens Packet für was was weiß ich wieviel Cents"... wenn er also sich "richtig" mit den ganzen Sachen beschäftigen müßte, dann wäre dass so als wenn ich KFZ-Mechaniker Handbücher lesen muß um tanken zu können. Das kann so auch nicht richtig sein. Frames bzw. deren Handhabung ist einfacher zu erlernen als sich mit dynamischer Seitengenerierung zu befassen, finde ich jedenfalls.

petra

[Mathias Bigge]

Hallo Petra,

Frames bzw. deren Handhabung ist einfacher zu erlernen als sich mit dynamischer Seitengenerierung zu befassen, finde ich jedenfalls.

Ich habe genau gar nichts gegen Frames, aber das Schöne ist, dass der Schein trügt, das wäre eine besonders leicht zu beherrschende Technik. Wenn man als Anfänger eine Seite im Wysiwig-Editor anfängt, dann leuchtet das Frame-Konzept sofort ein: Aus dem Nichts ein klar strukturierter Bildschirm mit festen und beweglichen Bereichen für Titel, Menü, Inhalt.  Und es geht so leicht. Klicks, schon ist ein neuer Bereich eingerichtet, schieb, schon kann man ihn kleiner und größer machen, bis alles genau passt.

Dann passiert folgendes.

1. Das 1-Frame-Problem

Fragestellung: Ich will im Menü etwas anklicken, aber der andere Frame soll sich ändern -> nach mehrstündiger Suche wird selbständig "target" entdeckt und seine Funktion erlernt.

2. Das mehrere Dateien-Problem

Die Fensterchen im Frame-Bildschirm sind gar nicht Bereiche einer Datei, sondern eigene Dokumente. Ach Du Scheiße, wie solll ich mir die ganzen Namen merken? Wie soll ich jetzt die Unterdokumente bearbeiten, wenn ich meine Frame-Bereiche gar nicht sehe. Wie soll ich jetzt wissen, ob's jetzt pixelgenau passt?

3. Das verschiedene-Computer-Problem

Originalbeschreibung des Programmierers Alfons Framelein aus Krefeld:
"Bei mir zu Hause passt alles genau, aber auf dem Computer meines besten Freundes, der auch Webdesigner ist, überlagern sich die Frames. Wir haben alles noch einmal pixelgenau nachgerechnet, aber jetzt passt alles nur beim Computer des anderen Webmasters in die Kästchen, bei mir zu Hause überlappen sich jetzt die Frames. Hiiiillllfeeee!!!!!!"

4. Das 2-Frames auf einmal ändern-Problem.

siehe Forumsarchiv

5. Das Suchmaschinenproblem

ebd.

.......

Da Du ernsthaft an der Sache interessiert zu sein scheinst, will ich an dieser Stelle auch einmal offen über etwas sprechen, dass in Insiderkreisen längst bekannt ist: Als Stefan Münz und einige Getreue die Idee hatten, dieses Forum ins Leben zu rufen, haben sie sich überlegt, wie man dauerhaft und ohne große Mühe Traffic erzeugen könnte. Zu diesem Zweck haben sie damals der wc2.org das Frames-Konzept untergeschoben. Das Verfahren, durch einen leichten Einstieg Anfänger anzulocken, die dann schnell in Schwierigkeiten geraten, ist übrigens patentiert, und wurde für verschiedene Industriezweige lizensiert, unter anderem an die Hersteller von Tintenstrahldruckern. Im Internetbereich haben einige Konkurrenten versucht, ähnliche Fallen auszulegen, etwa in Form von Countern, Java-Applets, sogenannten Disclaimern usw., niemals aber mit einem vergleichbaren Erfolg.

Viele Grüße,
ich hoffe, ich habe nicht zu viel ausgeplaudert
Mathias Bigge

[petra]

Hallo,

2. Das mehrere Dateien-Problem

Die Fensterchen im Frame-Bildschirm sind gar nicht Bereiche einer Datei, sondern eigene Dokumente. Ach Du Scheiße, wie solll ich mir die ganzen Namen merken? Wie soll ich jetzt die Unterdokumente bearbeiten, wenn ich meine Frame-Bereiche gar nicht sehe. Wie soll ich jetzt wissen, ob's jetzt pixelgenau passt?

Das sehe ich anders, denn genau dass es sich um mehrere Dokumente handelt ist leicht zu vermitteln sowie dessen Handhabung/Beziehung zueinander und mein Chef ist froh dass er gewisse Bereiche wie z.B. das Menü nur einmal zu erstellen braucht. Ein glücklicher Mensch;) Und pixelgenau, naja Du hast die Seite von meinem Chef noch nicht gesehen *g*, der ist kein Webdesigner. Ihm geht es in erster Linie um das Angebot bzw. die Information. Finde ich besser als hochgestylte inhaltslose Seiten.

5. Das Suchmaschinenproblem

Das leuchtet ein aber (ich hab immer was zu meckern;) ich würde es vorziehen, wenn zu diesem Zwecke spezielle Metatags erfunden werden würden, sofern es diese nicht schon gibt, welche die Beziehung der gefunden Seite zum eigentlichen Kontext bestimmen. Ich meine damit nicht die Metatags für nächste Seite oder nächstes Kapitel sondern ein Tag, was aussagt ob es sich um die Hauptseite handelt, und wenn nicht worin das Frame eingebettet ist. Und schon gibt es kein Suchmaschinenproblem *juhu* oder was denkst Du?

Da Du ernsthaft an der Sache interessiert zu sein scheinst, will ich an dieser Stelle auch einmal offen über etwas sprechen, dass in Insiderkreisen längst bekannt ist: Als Stefan Münz und einige Getreue die Idee hatten, dieses Forum ins Leben zu rufen, haben sie sich überlegt, wie man dauerhaft und ohne große Mühe Traffic erzeugen könnte. Zu diesem Zweck haben sie damals der wc2.org das Frames-Konzept untergeschoben.

Steck mal die Zunge raus, ist bestimmt schon tiefschwarz ;)
Ich habe so das Gefühl, dass Frames weniger Traffic zur Folge haben.
Meiner Meinung nach ist der große Vorteil von Frames, dass deren Inhalte nicht immer wieder neu über die Leitung gehen müssen. Warum gibt es eigentlich für DIV's keine Src-Angaben? Wäre das nicht geschickt? Suchmaschinen würden immer die komplette Seite kriegen und der Browser kann entscheiden, ob er die Quelle noch einmal lädt oder nicht. Ich meine mit Bildern geht das doch auch.

petra

[molily]

Hallo, petra,

2. Das mehrere Dateien-Problem
   Das sehe ich anders, denn genau dass es sich um mehrere Dokumente handelt ist leicht zu vermitteln sowie dessen Handhabung/Beziehung zueinander und mein Chef ist froh dass er gewisse Bereiche wie z.B. das Menü nur einmal zu erstellen braucht.

Das kann ich vollkommen nachvollziehen. Bei statischen Seiten, wo ich die Navigation und das Inhaltsverzeichnis nicht dynamisch automatisch erzeugen lasse, ist das Ändern von Kleinigkeiten auf allen Seiten äußerst mühselig. (Aber Frames verwende ich dennoch trotzdem nicht. :) Ich nutze kleine Skripte dafür, was ich aber von einem "gemeinen" Netzautor nicht erwarten kann.)

Ihm geht es in erster Linie um das Angebot bzw. die Information. Finde ich besser als hochgestylte inhaltslose Seiten.

ACK. Wer sich mit einem WYSIYG-Editor eine kleine Seite zusammenklickt, weil er nicht HTML lernen möchte, "darf" auch die verhassten Frames benutzen, solange es der Editor nicht erlaubt, dass man Navigationen auf den Einzelseiten automatisch einfügen und zentral aktualisieren kann. Es muss möglich sein, mit gängigen WYSIWYGs technisch valide und fehlerfrei sowie zugängliche Seiten zu verfassen.

5. Das Suchmaschinenproblem

Das kann man durch Links zum Frameset, mit Javascript und link-Elementen zumindest "abmildern". Aber wenn man sich eine solche Mühe macht, kann man gleich auf Frames verzichten und mit ein wenig Mehrarbeit auf absolut/fest positionierte Navigationen umsteigen.

Ich habe so das Gefühl, dass Frames weniger Traffic zur Folge haben.

ACK, das ist imho vielleicht der einzige (allgemeingültige) Vorteil.

Meiner Meinung nach ist der große Vorteil von Frames, dass deren Inhalte nicht immer wieder neu über die Leitung gehen müssen. Warum gibt es eigentlich für DIV's keine Src-Angaben?

Nun, das ist in (X)HTML gar nicht vorgesehen - selbst mit iframe und object[*] kann man nur komplette Seiten einbinden, wobei man jedoch nur einen Haufen Code auf jeder Seite wiederholt, kein Dokument im Dokument schaffen will.
Es müsste ein "Master"-Vorlage für jede Seite geben - sollte man vielleicht CSS mit dieser Aufgabe betrauen? Ansonsten gibt es nur die Alternative, das Problem mit externen JavaScripts anzugehen - da im noscript-Bereich jedoch sowieso die komplette ausgelagerte Navigation erscheinen müsste, ist das sinnlos.
Mir fällt auch keine Lösung ein... Man könnte eine Flash-Navigation benutzen. ;-) Oder zumindest eine, welche mit (externen) Grafiken (SVG) arbeitet.

[*] Da bin ich mir nicht sicher, ob man nicht einfach eine externe HTML-Datei, welche ein paar Codezeilen, also ein unvollständiges HTML-Dokument, enthält, über das object-Element mit text/html als Datentyp einfügen kann.

Mathias

[Sven Rautenberg]

Moin, Leute!

alt="" NICHT mehr als Tooltipp!

Einspruch! Im Falle des Vorhandenseins eines alt-Attributes werden die enthaltenen Metainformationen angezeigt; wenn ein title gesetzt ist, wird der Inhalt dieses Attributs im Tooltip angezeigt.

Sehe ich genauso, vor allem, weil ich in den Tooltipp normalerweise genau das Gleiche reinschreibe wie in das Alt-Tag. Warum soll man sich da wunde Finger holen? Vielleicht wäre ein kombiniertes Tag eine Lösung?

Tja, am dem ALT-Attribut werden wir uns noch festbeißen. :)

Ich frage dich einfach mal, was du so in deine alt- und title-Attribute reinschreibst, wenn du deren Inhalt einfach nur kopierst.

Denn ich finde, es gibt eigentlich nur drei Szenarien der Bildanwendung:

1. Die Textgrafik.
Da ist es eigentlich logisch, wenn man den in der Grafik enthaltenen Text als alt="Enthaltener Text" einbaut. Und es wäre total unlogisch, wenn man ihn in title="Enthaltener Text" einbaut - denn wer Grafiken sehen kann, braucht nicht noch einen Tooltipp mit der identischen Information - Redundanz läßt grüßen.

2. Die Schmuckgrafik.
Diese Grafik trägt inhaltlich nichts bei, im Textbrowser muß sie deshalb garnicht erst angezeigt werden - klarer Fall: alt="". Da Schmuckgrafiken in der Regel dann auch keine Tooltipps brauchen (ansonsten sind sie keine Schmuckgrafiken im Sinne dieses Punktes), entfällt title.

3. Inhaltsgrafiken.
Eine Inhaltsgrafik ist beispielsweise ein Foto. Und es ist hierbei durchaus sinnvoll, alt und title unterschiedlich zu gestalten. Denn alt richtet sich an das Publikum, welches die Grafik nicht sehen kann, während title als Ergänzungsinformation zusätzlich zur Grafik zu verstehen ist. Unterschiedliches Publikum in unterschiedlichem Kontext bedingt unterschiedliche Informationen. Beispielsweise wäre in einem Reisebericht ein Foto mit folgendem title-Attribut für die Grafik-sehenden Besucher interessant: "Blende 2,5, 1/100 sec, 16 mm". Der Text-only-Besucher wird diesen Text aber nicht unbedingt verstehen, bzw. man könnte zur Überzeugung gelangen, daß folgender Alternativ-Text besser geeignet ist, um den Menschen davon zu überzeugen, daß er was verpaßt: "Foto: Wunderschönes Panorama über die Deutschen Alpen von der Zugspitze". Je nach Seitengestaltung ist diese Info vielleicht auch als Fußzeile unter dem Foto zu finden und wäre dann redundant -> alt-Attribut bleibt leer oder enthält als Platzhaltertext einfach nur "(Foto)", weil es _inhaltlich_ relevant ist, daß der Bericht auch Fotos hat.

In jedem der drei Fälle ist es absolut nervig, wenn ein Browser die alt-Texte als Tooltipp anzeigt, weil alt dafür nicht gedacht ist und bei den meisten Browsern auch nicht mehr so verwendet wird. Das ist es nur zu verständlich, wenn man dem Spielchen endlich ein Ende bereitet.

Und da ich gerne mal in Opera nur geladene Grafiken anzeigen lasse (es surft sich einfach schneller, wenn nur neue _Seiten_ angefordert werden, nicht auch immer dieselben Grafiken), ist es auch für mich unerläßlich, daß alt-Texte definiert sind, damit ich sehe, daß ich eine Grafik verpasse. Wird das alt-Attribut nämlich einfach weggelassen, gibt Opera keinen Hinweis mehr auf die nicht angezeigte Grafik. Da ist es besser, die wichtigen Grafiken mit Text und die unwichtigen mit alt="" zu versehen.

- Sven Rautenberg

[molily]

Hallo Sven, Hallo Mathias,

vor allem, weil ich in den Tooltipp normalerweise genau das Gleiche reinschreibe wie in das Alt-Tag. Warum soll man sich da wunde Finger holen? Vielleicht wäre ein kombiniertes Tag eine Lösung?

Meines Erachtens haben die drei Attribute alt, title und longdesc ihre volle Berechtigung und je nach Kontext (wie Sven erläutert hat) ist es unklug, alt- und title-Attributwerte schlichtweg zu kopieren.

Da ist es eigentlich logisch, wenn man den in der Grafik enthaltenen Text als alt="Enthaltener Text" einbaut. Und es wäre total unlogisch, wenn man ihn in title="Enthaltener Text" einbaut - denn wer Grafiken sehen kann, braucht nicht noch einen Tooltipp mit der identischen Information - Redundanz läßt grüßen.

Aus "Sicherheit" verwende ich trotzdem den Alternativtext meist nur leicht variiert/ergänzt erneut als Wert für title, denn es gibt imho auch Situationen, in denen die Grafik angezeigt wird, aber die Textinformation aus welchen Gründen auch immer nicht problemlos vom Benutzer aufgenommen werden kann.
Bis voll skalierbare SVG-Grafiken breite Verbreitung finden, auf die der Benutzer eigene Styles anwenden kann, würde ich auch für Schriftzüge in Pixelgrafiken ein title anbieten. Die redundanten paar Bytes machen das Dokument auch nicht entscheidend größer.
Außerdem, wenn man erst einmal anfängt mit Redundanz zu argumentieren, dann würden wohl viele Bilder erst gar nicht auftauchen und die Frage nach den alt- und title-Attributen stellte sich gar nicht. Ich persönlich erwische mich immer dabei, weder Inhalts- noch Schmuckgrafiken zu verwenden und textdominierte Seiten zu publizieren. Zugegeben sehen die Seiten dann oft sogar öde und kahl aus, aber ich will in erster Linie nicht durch bunte Bildchen unterhalten.

Eine Inhaltsgrafik ist beispielsweise ein Foto. Und es ist hierbei durchaus sinnvoll, alt und title unterschiedlich zu gestalten. Denn alt richtet sich an das Publikum, welches die Grafik nicht sehen kann, während title als Ergänzungsinformation zusätzlich zur Grafik zu verstehen ist.

Volle Zustimmung.

Der Text-only-Besucher wird diesen Text aber nicht unbedingt verstehen, bzw. man könnte zur Überzeugung gelangen, daß folgender Alternativ-Text besser geeignet ist, um den Menschen davon zu überzeugen, daß er was verpaßt: "Foto: Wunderschönes Panorama über die Deutschen Alpen von der Zugspitze".

Bei Urlaubsfotos wie auch bei anderen Bildern bedarf es wohl einer ausgeprägten Wahrnehmungsgabe und sprachlichen Talenten, um einen Alternativtext zu verfassen, der die Gesamtheit der optischen Eindrücke wiedergibt.

Den Text, den du beispielhaft genannt hast, finde ich persönlich
*nur* dazu gut, "um den Menschen davon zu überzeugen, daß er was verpaßt", also den Benutzer dazu zu veranlassen, einen grafischen Benutzeragent zu verwenden und Grafiken zu aktivieren, ggf. Bildschirmauflösung und Farbtiefe anzupassen.
Aber der Alternativtext richtet sich in erster Linie an diejenigen, die dies nicht können/wollen. Ebenso denke ich, dass wenn das alt-Attribut angezeigt/ausgegeben wird, m.E. vorausgesetzt ist, dass der Benutzer die Grafik nicht sehen kann oder will.

Es nützt wohl wenig, einem blinden Mensch klarzumachen, dass er etwas verpasst, wenn er das Bild nicht sehen kann. Das meine ich nicht vorwurfsvoll, ich störe mich nur so an dem Adjektiv "wunderschön", das imho irgendwie völlig unpassend ist - rein subjektives Empfinden. ;) Wenn ich nicht sehen könnte, würde ich eine solche Beschreibung, so gut sie gemeint ist, wohl als Enttäuschung oder gar Beileidigung auffassen.
Passend wäre wohl eine longdesc, welche darlegt, was der Fotograf bei dem Anblick gefühlt hat und welche Erinnerungen er daran hat und in welcher er die Bildelemente beschreibt und ihrer Wirkung (meinetwegen metaphorisch) sprachlich beizukommen versucht.
Unter einem Textäquivalent verstehe ich, dass der Text die Grafik ersetzen könnte, unter Umständen, das heißt im optimalsten Falle, müssten alle möglichen Konnotationen ausformuliert werden.
Wobei ich im dem speziellen Falle das Bild sogar herausnehmen würde und auch den sehenden Lesern eine sprachliche Beschreibung bieten würde, welche in der Phantasie jedes Lesers eine individuell "wunderschöne" Vorstellung erzeugt. Ein plump abbildendes Foto kann so etwas sowieso nicht leisten. :)
(Ich hoffe das war jetzt nicht zu OT.)

Je nach Seitengestaltung ist diese Info vielleicht auch als Fußzeile unter dem Foto zu finden und wäre dann redundant -> alt-Attribut bleibt leer oder enthält als Platzhaltertext einfach nur "(Foto)", weil es _inhaltlich_ relevant ist, daß der Bericht auch Fotos hat.

Genau, die Fußzeile versieht man am besten mit einem Anker und verlinkt ihn mit londesc. In dem Fall sollte das alt-Attribut dennoch eine kurze individuelle, zusammenfassende Beschreibung enthalten ("This description [longdesc] should *supplement* the short description provided using the alt attribute"[*] - also ergänzen, nicht ersetzen).

[*] http://www.w3.org/TR/html401/struct/objects.html#adef-longdesc-IMG

In jedem der drei Fälle ist es absolut nervig, wenn ein Browser die alt-Texte als Tooltipp anzeigt, weil alt dafür nicht gedacht ist...

Das ist für mich kein Argument. Weswegen findest du es nervig? Weil du das alt-Attribut siehst, obwohl du es nicht sehen willst?
Ich merke so etwas nur, wenn ich *bewusst* den Mauszeiger über ein Element bewege, um einen title anzeigen zu lassen, falls er vorhanden ist. Wie kann also ein alt-Attribut, vom IE arglistig als Tooltip dargestellt, nervig werden?
Wenn mir dann das alt-Attribut angezeigt wird, weil der Seitenautor zu blöd ist, alt und title richtig zusetzen, dann finde ich das besser als nichts; denn wenn mir das alt-Attribut nicht mehr sagt, als ich optisch wahrnehmen kann, dann ist es mir egal, denn dann ist der Versuch nicht weniger gescheitert als wenn ich gar kein Tooltip sehen würde. :) Da es im Web faktisch nur title-lose Grafiken gibt und ich ein fehlenden title nicht schnuppern kann, bin ich der Seite so oder so ausgeliefert, wenn ich den Wunsch nach zusätzlichen Informationen über die Grafik wünsche.
(Ich drehe mich im Kreis. Ich sollte mich der Meinung der Mehrheit hier beugen, wenn ich je erreichen will, dass Seitenautoren zur Einsicht kommen.)

...und bei den meisten Browsern auch nicht mehr so verwendet wird.

Das ist nicht zwingend ein Argument. Damit könnte man auch das Gegenteil belegen: der in der Praxis absolut herrschende Browser - 'le Web, c'est moi' - hat die Fäden in der Hand und fühlt sich gegenüber dem W3C und deren Standards autonom.

Das ist es nur zu verständlich, wenn man dem Spielchen endlich ein Ende bereitet.

Setze dem Spielchen von Millionen von Netzautoren ein Ende. ("Nur strengere Browser führen zu besseren Netzseiten" - dazu habe ich mich hier im Thread schon geäußert. Im Grunde genommen stimme ich dem sogar zu.)

Und da ich gerne mal in Opera nur geladene Grafiken anzeigen lasse (es surft sich einfach schneller, wenn nur neue _Seiten_ angefordert werden, nicht auch immer dieselben Grafiken)...

Das ist eventuell auch ein Problem des Caches. Ich persönlich habe i.d.R. "Check modified" für alle Dokumenttypen auf "Never", wobei ich aber "Empty disk cache on exit" eingestellt habe. Im Zweifelsfall benutze ich den manuellen Reload. Meine Bandbreite ist recht groß, aber das Rendern grafiküberladener Seiten dauert ewig. Ich kann leider nicht einstellen, welche Seiten und Bilder im Cache verbleiben sollen, wobei andere nur einmal besuchte Seiten schon nach dem Beenden der Browserinstanz aus dem Cache fliegen sollten, anstatt dass sie auf meiner Festplatte verschimmeln und die vielen kleinen gecachten Seiten und Styles je einen Cluster belegen (auch bei FAT32 wächst der Cache bis auf 40 MB an).

...ist es auch für mich unerläßlich, daß alt-Texte definiert sind, damit ich sehe, daß ich eine Grafik verpasse. Wird das alt-Attribut nämlich einfach weggelassen, gibt Opera keinen Hinweis mehr auf die nicht angezeigte Grafik.

Das finde ich eine Frechheit. Ich möchte einen Fehler angezeigt bekommen anstatt einem nicht-sichtbaren Platzhalter, wenn ein Bild 404 ist oder ein alt-Attribut fehlt und die Anzeige der Grafiken deaktiviert ist. Wenn alt, width und title fehlen, weiß ich nicht einmal, wieso das Layout kollabiert.

Mathias

[Michael Schröpl]

Hi Leute,

Meines Erachtens haben die drei Attribute alt, title und longdesc
ihre volle Berechtigung und je nach Kontext (wie Sven erläutert hat)
ist es unklug, alt- und title-Attributwerte schlichtweg zu kopieren.

Yep - dazu siehe aber gleich eine Anmerkung.

Der Text-only-Besucher wird diesen Text aber nicht unbedingt
verstehen, bzw. man könnte zur Überzeugung gelangen, daß
folgender Alternativ-Text besser geeignet ist, um den Menschen
davon zu überzeugen, daß er was verpaßt: "Foto: Wunderschönes
Panorama über die Deutschen Alpen von der Zugspitze".

_Das_ würde ich nun genau _nicht_ in ALT= eintragen wollen.
(Eher in LONGDESC.)

Was ich von den Browser bisher mitbekomme, ist nämlich, daß sie
diesen Text innerhalb des Rechtecks darzustellen versuchen, der
eigentlich von der Bildanzeige hätte gefüllt werden sollen.

Und wenn man mal von bildschirmfüllenden Panoramafotos absieht und
gleichzeitig eine lesbare Schriftgröße voraussetzt, dann bleiben
nur noch total kurze Textfetzen übrig - bei Buttons beispielsweise
paßt oftmals nicht einmal der auf dem Button angezeigte Text in
diese ALT-Anzeige hinein.
(Ich habe gestern mal meine sämtlichen Buttons von GIF nach PNG
umgesetzt und während des Tests alle ALT-Texte bewundern dürfen ...
und als Ergebnis diese Texte ziemlich radikal zusammengestrichen.)

Und da ich gerne mal in Opera nur geladene Grafiken anzeigen
lasse (es surft sich einfach schneller, wenn nur neue _Seiten_
angefordert werden, nicht auch immer dieselben Grafiken)...
Das ist eventuell auch ein Problem des Caches.

Netscape (4, 6 und 7) und M$IE glauben im Modus "automatic" den
via "Expires:" bzw. "Cache-Control" übertragenen Aufbewahrungs-
fristen und senden während dieser nicht einmal mehr "conditional
GET"-requests. Kann man das auch dem Opera irgendwie klar machen?

Viele Grüße
      Michael

[Sven Rautenberg]

Moin!

Der Text-only-Besucher wird diesen Text aber nicht unbedingt
verstehen, bzw. man könnte zur Überzeugung gelangen, daß
folgender Alternativ-Text besser geeignet ist, um den Menschen
davon zu überzeugen, daß er was verpaßt: "Foto: Wunderschönes
Panorama über die Deutschen Alpen von der Zugspitze".

_Das_ würde ich nun genau _nicht_ in ALT= eintragen wollen.
(Eher in LONGDESC.)

Tja, aber ein Attribut ohne jegliche Unterstützung in den Browsern ist nun leider noch flüssiger als flüssig in Webseiten. Finde ich jedenfalls.

Was ich von den Browser bisher mitbekomme, ist nämlich, daß sie
diesen Text innerhalb des Rechtecks darzustellen versuchen, der
eigentlich von der Bildanzeige hätte gefüllt werden sollen.

Da hast du in der Tat Recht.

Und da ich gerne mal in Opera nur geladene Grafiken anzeigen
lasse (es surft sich einfach schneller, wenn nur neue _Seiten_
angefordert werden, nicht auch immer dieselben Grafiken)...
Das ist eventuell auch ein Problem des Caches.

Netscape (4, 6 und 7) und M$IE glauben im Modus "automatic" den
via "Expires:" bzw. "Cache-Control" übertragenen Aufbewahrungs-
fristen und senden während dieser nicht einmal mehr "conditional
GET"-requests. Kann man das auch dem Opera irgendwie klar machen?

Da ich Webseiten entwickle, haben alle meine Browser die Einstellung erhalten, immer nach neueren Elementen beim Server nachzufragen. Sonst müßte ich immer manuell aktualisieren (wobei außer Netscape kein Browser den Shift-Reload kennt, sondern immer irgendwie neu geladen wird - sehr nervig auf die Dauer).

Insofern kenne ich die Cachemöglichkeiten des Opera nicht sonderlich gut.

- Sven Rautenberg

[Michael Schröpl]

Hi Sven,

Sonst müßte ich immer manuell aktualisieren (wobei
außer Netscape kein Browser den Shift-Reload kennt,
sondern immer irgendwie neu geladen wird - sehr
nervig auf die Dauer).

M$IE macht "Strg F5" IMHO absolut zuverlässig.
Das ist halt nicht wirklich gut dokumentiert ... ;-)

Viele Grüße
      Michael

[Mathias Bigge]

Hallo Sven,

die Frage ist tasächlich, wie man Bilder einsetzt, und aus welcher Motivation man alt oder title tags hinzusetzt.

Ich frage dich einfach mal, was du so in deine alt- und title-Attribute reinschreibst, wenn du deren Inhalt einfach nur kopierst.
Denn ich finde, es gibt eigentlich nur drei Szenarien der Bildanwendung:

<OT>Ganz ohne Ironie: Deine Argumentation erinnert mich stark an die klassische Philosophie, vor allem an den guten alten Kant und dessen Strategie, jeden Inhaltsbereich in Kategorien zu erfassen, von denen er behauptet, dieser sei damit vollständig erfasst. Oder auch an den guten alten Cäsar: "Gallia est omnes divisa in partes tres." Solche Kategoriensysteme haben mich immer schon interessiert, vor allem, wenn sie duale oder ternäre Strategien verfolgen, so wie Du in Deinem Beispiel. Es ist eine Form analytischen Denkens, die häufig erfolgreich Dinge erfasst und handlebar macht, etwa beim Programmieren, manchmal aber auch an Überzeugungskraft verliert,wenn man sie mit der Wirklichkeit konfrontiert, d.h. auf reale Beispiele anzuwenden versucht. Ich nehme einmal bewusst ein Beispiel aus der Programmmierung: Wenn Du Kategoriensysteme für Datenbanksysteme entwickelst, und nach heißem Bemühen glaubst, die Realität jetzt erfasst zu haben, beginnt der Denkprozess oft noch einmal neu, wenn man die ersten Datensätze von einem Mitarbeiter erfassen lässt und zusieht, wie dieser das Kategoriensystem einsetzt.</OT>

Ich habe begonnen, Informationen in den alt-tag zu schreiben, weil Du und andere mich darauf aufmerksam gemacht haben, welche Bedeutung das für Sehbehinderte hat. <schäm>Ich weiß immer noch nicht genau, wie die entsprechenden Medien funktionieren</schäm>, und nutze die Alt-Tags oft in diesem Sinne, nicht als Zusatzinformation für Nutzer. Wenn man Deinem Kategoriensystem folgt, ist Deine Argumentation sehr stringent, aber ich habe das Gefühl, dass meine Verwendung von Bildern nicht so ganz in Dein Schema passt.

1. Die Textgrafik.
   Da ist es eigentlich logisch, wenn man den in der Grafik enthaltenen Text als alt="Enthaltener Text" einbaut. Und es wäre total unlogisch, wenn man ihn in title="Enthaltener Text" einbaut - denn wer Grafiken sehen kann, braucht nicht noch einen Tooltipp mit der identischen Information - Redundanz läßt grüßen.

Verwende ich praktisch nicht, außer vielleicht selten bei Buttons, wenn dies ausdrücklich und eindringlich gewünscht wird und füge dann
die Beschriftung in das Alt-Tag ein und lasse Title weg. Hier sind wir also einer Meinung.

2. Die Schmuckgrafik.
   Diese Grafik trägt inhaltlich nichts bei, im Textbrowser muß sie deshalb garnicht erst angezeigt werden - klarer Fall: alt="". Da Schmuckgrafiken in der Regel dann auch keine Tooltipps brauchen (ansonsten sind sie keine Schmuckgrafiken im Sinne dieses Punktes), entfällt title.

richtig

3. Inhaltsgrafiken.
   Eine Inhaltsgrafik ist beispielsweise ein Foto. Und es ist hierbei durchaus sinnvoll, alt und title unterschiedlich zu gestalten. Denn alt richtet sich an das Publikum, welches die Grafik nicht sehen kann, während title als Ergänzungsinformation zusätzlich zur Grafik zu verstehen ist. Unterschiedliches Publikum in unterschiedlichem Kontext bedingt unterschiedliche Informationen. Beispielsweise wäre in einem Reisebericht ein Foto mit folgendem title-Attribut für die Grafik-sehenden Besucher interessant: "Blende 2,5, 1/100 sec, 16 mm". Der Text-only-Besucher wird diesen Text aber nicht unbedingt verstehen, bzw. man könnte zur Überzeugung gelangen, daß folgender Alternativ-Text besser geeignet ist, um den Menschen davon zu überzeugen, daß er was verpaßt: "Foto: Wunderschönes Panorama über die Deutschen Alpen von der Zugspitze". Je nach Seitengestaltung ist diese Info vielleicht auch als Fußzeile unter dem Foto zu finden und wäre dann redundant -> alt-Attribut bleibt leer oder enthält als Platzhaltertext einfach nur "(Foto)", weil es _inhaltlich_ relevant ist, daß der Bericht auch Fotos hat.

Ok, hier sind wir am entscheidenden Punkt, denn fast alle Bilder, die ich veröffentliche, entstammen dieser Kategorie:

1. Bilder von Personen
Name im Alt und Title Tag (!)

2. Grafiken
meist didaktische Schemata, um einen Vorgang, eine Strategie oder eine Entscheidungsstruktur abzubilden; die entscheidenden Informationen sind meist auch im Text enthalten und werden hier sozusagen nur in einem anderen Medium dargestellt
Alttag für Sehbehinderte, kein Tooltip

3. Bilder aus Filmen
Häufig begleite ich Videoprojekte für den Kunden im Internet, und zwar in verschiedener Absicht:
a) zusätzliche Promotion
b) Arbeitsdokumentation
c) als Projektdokumentation; wird häufig später als CD oder DVD ausgeliefert, ergänzt um Filmausschnitte, die ich meist nicht ins Internet stelle
Die Bilder sind hier textlich sehr schwer zu erfassen, auch wenn es oft kurze Texte auf der Site gibt, die die Vorgänge inhaltlich auf den Punkt bringen. Hier bringe ich seit einigen Hinweisen stets alt-Texte für Sehbehinderte an, obwohl ich befürchte, dass diese Seite nur in wenigen Fällen überhaupt interessant sind.
Aber auch bei anderen Bildern, etwa von Veranstaltungen scheint mir Dein Schema (alt: inhaltliche Beschreibung; tooltip: technische Daten) künstlich zu sein scheint. Beispiel: Bilder von der Preisverleihung am Ende eines Theaterfestivals, hatte ich neulich. Ich würde hier im im Alttag und im Tooltip schreiben: Minister XY überreicht 1. Preis an Ensemble XY. Die technischen Informationen interessieren in diesem Kontext niemanden, außer vielleicht unsere Konkurrenz  und die soll lieber weiter darben *g*

In jedem der drei Fälle ist es absolut nervig, wenn ein Browser die alt-Texte als Tooltipp anzeigt, weil alt dafür nicht gedacht ist und bei den meisten Browsern auch nicht mehr so verwendet wird. Das ist es nur zu verständlich, wenn man dem Spielchen endlich ein Ende bereitet.

Um meine Meinung auf den Punkt zu bringen: Eigentlich brauche ich in der Praxis selten zwei verschiedene Hinweise.

Und da ich gerne mal in Opera nur geladene Grafiken anzeigen lasse (es surft sich einfach schneller, wenn nur neue _Seiten_ angefordert werden, nicht auch immer dieselben Grafiken), ist es auch für mich unerläßlich, daß alt-Texte definiert sind, damit ich sehe, daß ich eine Grafik verpasse. Wird das alt-Attribut nämlich einfach weggelassen, gibt Opera keinen Hinweis mehr auf die nicht angezeigte Grafik. Da ist es besser, die wichtigen Grafiken mit Text und die unwichtigen mit alt="" zu versehen.

Also wenn's nicht extrem bildlastige Seiten mit schlecht komprimierten Bildern sind, überzeugt mich auch dieses Argument nicht ganz. Selbst mein altes Möhrchen zu Hause stellt einmal geladene Seiten in Sekundenbruchteilen dar, ob mit Bildern oder ohne. Auf einem Videorechner in der Firma ist der Unterschied kaum merkbar, wenn die Bilder von der Platte kommen, und dass tun sie meist, denn eigentlich ist das Surfen mit den Videorechnern in unserem Laden nur in Notfällen erlaubt.....

Viele Grüße und Bitte um Korrektur oder weitere Hinweise
Mathias Bigge

[Björn Höhrmann]

der Parser weiß ja *eigentlich* noch gar nicht, was ein <li> ist! Und genau das ist auch der Grund, weshalb man HTML/SGML ohne DTD überhaupt nicht gebrauchen kann, es ist nichteinmal möglich das ganze auf Syntaktische Richtigkeit zu prüfen. Bei XML ist auch ohne die DTD zu erkennen, ob die Datei gültig ist, hier  bleibt später nur noch die Frage, ob alle angegebenen Attribute ihre Richtigkeit haben.

Ganz und gar nicht, man kann noch nicht einmal mit Kenntnis der DTD endgültig bestimmen, ob das Dokument gültig ist, es gibt viele Einschränkungen, die dort nicht ausgesprochen werden können. Ohne DTD kann man nur Wohlgeformtheit feststellen, das geht bei SGML nicht, aber Wohlgeformtheit bringt dir nichts.

<p> ist genauso ein Kandidat: Wenn eines kommt, ist vorher einfach </p> anzunehmen.

Da hat sich wohl ein "sobald etwas auftaucht, was nicht in einem <p> sein darf" eingebürgert - also bei dem nächsten Block-Element.

Was sich "eingebürgert" hat, ist irrelevant, es ist fest vorgeschrieben, wie der Parser sich zu verhalten hat.

Imho ist auch eine der wichtigen Neuerungen an XHTML, dass es klare Regeln gibt, wie mit ungültigem Code umzugehen ist.

Und das war bei HTML nicht so?

Ich bin auch der Meinung, dass sämtliche "depend on Useragent" aus den W3C-Standards verschwinden müssen, es wird einfach immer irgendeine Inkompatibilität geben, wo Annahmen durch die Seitengestalter mal ganz abgesehen.

Das ist nicht durchsetzbar und manchmal auch nicht sinnvoll.

[Ich]

hi

Tag!

-> Favicons schon mit rel="icon" erkennen und auch andere Formate zuzulassen

Ach Ja *Träum*: Wenn favicon im Dokument nicht angegeben, dann garnicht erst versuchen eins zu finden. Zweck: Eleminieren von "[httpd]... File does not exist: .../favicon.ico"

Oder war das mit "erkennen" gemeint? war mir nicht ganz klar...

bye
ich

[Kai Lahmann]

hi

Ach Ja *Träum*: Wenn favicon im Dokument nicht angegeben, dann garnicht erst versuchen eins zu finden. Zweck: Eleminieren von "[httpd]... File does not exist: .../favicon.ico"

Oder war das mit "erkennen" gemeint? war mir nicht ganz klar...

er sucht das bisher entweder selbst oder benötigt eine Abgabe mit 2 (!) Keywords als rel="" (rel="shortcut icon"), was ich etwas unbpraktisch finde (=ich vergess es dauernd ;)

Grüße aus Bleckede

Kai

[Björn Höhrmann]

ich hab' mir mal überlegt, was passiert, wenn ein ganz sturer Parser auf eine gültige HTML- oder XHTML-Datei stößt. Da kommt bei HTML sicherlich als erstes die Frage, ob das eine oder andere Attribut nun Anführungszeichen haben muss, oder nicht.

Nicht für den Parser, dafür gibt es klare Regeln die in der Tat sehr leicht zu implmentieren sind (und auch für Autoren zu merken).

Wer ist eigentlich beim W3C auf den Bolzen gekommen, dass man die Dinger manchmal weglassen kann? Imho wird's dadruch wahnsinnig chaotisch...

Auf die Idee ist niemand beim W3C gekommen, die gab es schon lange bevor überhaupt jemand an das World Wide Web gedacht hat.

Noch schöner sind die optionalen oder ganz fehlenden End-Tags - woher soll der Parser (der ja noch nichts von der Bedeutung der Tags weiß!) wissen, ob ein nicht vorhandenes Endtag nun ein Fehler ist oder so ok..?

Das steht in der Dokumenttyp-Definition...

Sicher kann er in der DTD nachsehen, aber dafür muss er erstmal die komplette Dateio gelesen haben

Die DTD? Ja, alternativ kann er sich auch nur so verhalten, als hätte er es getan, aber das ist nebensächlich. Falls du das Quelldokument meinst, muss ich widersprechen.

• es könnte ja sein, dass das Tag (z.B. ein <li>) doch noch irgendwo geschlossen wird...

Nein, der Parser zerlegt das Quelldokument in syntaktische Einheiten. Eine solche wäre das Start-Tag <li>. Danach findet er z.B. Zeichendaten oder andere Elemenente. In dem Moment, wo er ein Start-Tag für ein Element findet, das nicht zum Inhaltsmodell des <li>-Elements gehört (also z.B. <li> selber) schliesst er intern das vorhergehende <li>.

Somit kann also ein stur nach HTML arbeitender Browser auch erst etwas anzeigen, wenn alles geladen ist - vorher weiß er ja nichtnur nicht, ob die Datei gültigt, noch wo nun das eine oder andere Tag nun zu Ende ist. Insbesondere bei einem <li> stellt sich dann auch noch auf der Darstellungs-Ebene die Frage, wo man das Ding nun als "zu Ende" annehmen kann (oder muss).

Das ist einfach nicht richtig. Es gibt sogar sehr genaue Beschreibungen von progressiven Wiedergabemodellen für HTML-Dokumente, ebenso für Dokumente, die CSS nutzen. Der Parser kann doch problemlos

<li>... ... ...

gelesen haben, dann auf ein

<strong>

treffen und den folgenden Text entsprechend unterschiedlich wiedergeben, *während* er liesst. Wo siehst du da ein Problem? Aussenränder sind bei sowas natürlich ein Problem, ein

ul { border: thin solid red }

welches beides oben umschliesst ist natürlich beim laden nicht unebdingt zufriedenstellend anzzeigen, weil u.a. die Dimensionen der Boxen noch nicht geklärt sein müssen, aber das ist nebensächlich. Mit einem langsamen Rechner oder auch nur einer langsamen Verbindung sollte man aktuelle Browser sehr schön beobachten können, wie ihr progressives Wiedergabemodell funktioniert.

Bei XHTML ist dagegen eindeutig geregelt, wo ein Tag zu Ende ist - wenn es mit /> endet sofort, sonst eben erst, wenn ein </li> kommt (um mal bei dem Beispiel zu bleiben.

Die Regeln sind bei HTML genauso klar, der einzige Unterschied ist, dass der Parser die DTD kennen muss und ggf. auf diese Daten zurückgreifen muss, bevor er etwas entscheided, aber der Unterschied ist sehr marginal.

Was ich damit sagen will, ist, dass HTML nicht wirklich logisch ist, es ist eine Aneinanderreihung von Ausnahmen von Ausnahmen, die man kaum verstehen kann, soetwas muss man als Browser eigentlich falsch interpretieren.

Man muss es als Browser nicht einmal selber interpretieren, es gibt frei verfügbare SGML-Parser, die zu nutzen wäre kein Problem. Ein Problem wird die Verarbeitung von HTML-Dokumenten erst dann, wenn sich das Dokument eben *nicht* an die Regeln enthält. Für einen konformen Parser ist es an sich unmöglich, ein nicht-konformes Dokument zu verarbeiten.

Davon abgesehen, ja, syntaktisch gibt es für HTML viele Sonderregeln, aber was kümmert dich das, du kannst praktisch alles in XHTML-Syntax schreiben, nur bei z.B. leeren Elementen funktioniert das nicht. Ich selber finde es angenehmer, wenn ich ein <li> oder <p> nicht schliessen muss, wenn ich den Quellcode von Hand eingebe.

Wie haltet ihr das, benutzt ihr alle "normales" HTML oder wird lieber in XHTML geschrieben?

Beides, der Unterschied kümmert mich nicht, bzw. er besteht eigentlich nur darin, mit welchen Parametern ich HTML-Tidy denn nun aufrufe.

[Chräcker Heller]

Hallo,

mal abgesehen davon, daß ich keine Ahnung von xhtml habe (insoweit kann ich die beiden nicht vergleichen) führst Du technische Gründe an, weswegen die interpretation einer html-Seite für einen Parser ein Ding der unmöglich sein sollte. Streng genommen. Von der logik her. Wenn man es mal genau betrachtet. Nun bin ich richtig froh, daß ich offensichtlich bisher nur an nichtstrenge, unlogische Browser geraten bin, die es nicht so genau mit den konzeptionelen Schwächen nehmen. und darf feststellen: et jeht doch. Ob mit oder ohne Anführungsstriche, mit offenen und geschlossenen Tags. Die Technik kanns, was manchem Theoretiker schwer fällt. Auch mal was "umgangssprachliches" (htm) zu verstehen und sich am Ergebnis zu erfreuen. Auch wenn er das eigendlich nicht verstehen dürfte. Streng genommen.

Chräcker

[Michael Schröpl]

Hi Chräcker,

führst Du technische Gründe an, weswegen die interpretation einer
html-Seite für einen Parser ein Ding der unmöglich sein sollte.

so habe ich Kais Posting nicht aufgefaßt.
Eher so: "Um ein (fehlerhaftes) HTML-Dokument zu interpretieren, muß
ein Parser viel mehr arbeiten und kann das Ergebnis viel später an-zeigen, als um ein (fehlerhaftes) XHTML-Dokument zu interpretieren."

Und da muß ich ihm recht geben.

Erfreulicherweise ist allerdings in den letzten Jahren die Client-
Hardware derartig schnell geworden, daß sie heute schon mit derjenigen
vieler Server mehr als nur mithalten kann - insofern ist eine
entsprechend aufwändige Interpretation heute machbar.
Allerdings auch nur, wenn man sich dabei keinen Knoten ins Hirn denkt,
wie Netscape 4 bei tief verschachtelten Tabellen ...

Ich formuliere die Aussage mal so:
Gerade _weil_ es dem Seitenkleber letzten Endes egal ist, ob da ein
schließendes Tag mehr oder weniger anzugeben ist (der lernt die Sprache
einfach, bzw. validiert eben seine Seiten), sollte bei der Definition
einer solchen Sprache technische Belange (wie etwa die zuverlässige und
performante Interpretation) eine bedeutende Rolle spielen.

Viele Grüße
      Michael

[Mathias Bigge]

Hallo Michael,

Eher so: "Um ein (fehlerhaftes) HTML-Dokument zu interpretieren, muß
ein Parser viel mehr arbeiten und kann das Ergebnis viel später an-zeigen, als um ein (fehlerhaftes) XHTML-Dokument zu interpretieren."
Und da muß ich ihm recht geben.

Prinzipiell gebe ich Dir Recht, dass es schneller sein müsste, wenn _alle_ Websites standardkonform wären. Aber so bin ich mir nicht ganz sicher, ob es stimmt, denn dann müsste es ja ein eigenes Rendering für valide Seiten geben. Ich vermute aber, dass die Browser bei jeder Seite nicht mit optimaler Performance vorgehen, sondern mit einem System, dass auch gewisse Fehler/Ungenauigkeiten auffängt, auch wenn das für eine valide Seite nicht nötig wäre. Ein Nebenaspekt ist, dass, vom Selfforum und dergleichen "Bleiwüsten" mal abgesehen, das Rendering der HTML-Tags der geringste Zeitanteil beim Darstellen von Websites sein dürfte. Korrigier mich, wenn ich da falsch liege.

Natürlich gibt es performance-relevante Aspekte im Bereich HTML, etwa die Größenangabe für Bilder oder dergl. Ich bin mir aber nicht sicher, ob diese Kriterien mit der Validierungsproblematik deckungsgleich sind.

Viele Grüße
Mathias Bigge

[Michael Schröpl]

Hi Mathias,

Eher so: "Um ein (fehlerhaftes) HTML-Dokument zu interpretieren, muß
ein Parser viel mehr arbeiten und kann das Ergebnis viel später
anzeigen, als um ein (fehlerhaftes) XHTML-Dokument zu interpretieren."
Prinzipiell gebe ich Dir Recht, dass es schneller sein müsste, wenn
_alle_ Websites standardkonform wären. Aber so bin ich mir nicht ganz
sicher, ob es stimmt, denn dann müsste es ja ein eigenes Rendering für
valide Seiten geben.

Genau.

Zunächst einmal ist es ja eine Strategiefrage der Browser-Implementation,
wie man den Parser schreibt - ob der beispielsweise so optimiert ist,
daß er korrekt aufgebaute Dokumente in einem Rutsch parsen und für
fehlerhaft aufgebaute den Parsing-Versuch abbrechen und mit einem
fehlertoleranteren Parser ein zweites Mal von vorne anfangen muß oder
ob von vorn herein der fehlertolerantere, aber langsamere Parser ein-
gesetzt wird, der ggf. mehr Verwaltungsinformationen mitschleppen muß.
Ich kann mir durchaus vorstellen, einen Browser so zu schreiben, daß
er korrekte Dokumente schneller parsen kann als fehlerhafte.
(Ob das in der aktuellen WWW-Umwelt schon eine gute Idee wäre, sei
dahingestellt; es wäre aber eine großartige didaktische Idee, genau
wie die Ausgabe von Fehlermeldungen bei invaliden Dokumenten. Würde
Amaya beispielsweise Frames und JavaScript unterstützen und damit
im vollen Umfang markttauglich sein, dann könnte der W3C auf diese
Weise durchaus Seitenautoren dazu animieren, validen Code zu produ-
zieren; bei Mozilla bezweifele ich die Deckungsgleichheit der Moti-
vation mit derjenigen des W3C.)

Ich vermute aber, dass die Browser bei jeder Seite nicht mit optimaler
Performance vorgehen, sondern mit einem System, dass auch gewisse
Fehler/Ungenauigkeiten auffängt, auch wenn das für eine valide Seite
nicht nötig wäre.

Eben das ist eine Strategiefrage. Und die könnte beispielsweise _auch_
davon abhängig gemacht werden, ob (und welcher!) DOCTYPE in einem
Dokument drin steht (nach dem Motto: HTML 4.01 schreiben auch die DAUs
rein, da parsen wir mal defensiv und langsam; wer XHTML 1.1 macht,
weiß schon eher, was er tut, und wird dann auch die Strafe des zwei-
maligen Parsens in Kauf nehmen, falls das Dokument eben doch nicht
valide ist). Irgendwie in diese Richtung müssen die M$IE-Programmierer
bei Quirks-Mode und Compliant Mode ja auch gedacht haben.

Ein Nebenaspekt ist, dass, vom Selfforum und dergleichen "Bleiwüsten"
mal abgesehen, das Rendering der HTML-Tags der geringste Zeitanteil
beim Darstellen von Websites sein dürfte. Korrigier mich, wenn ich
da falsch liege.

Geschachtelte Tabellen ohne Breitenangabe zu rendern kann ein furcht-
bar teures rekursives Backtracking-Verfahren erzwingen.
Mich wundert gar nicht, daß Netscape 4 an dieser Stelle in die Knie geht
... eher schon, daß die modernen Browser das alle wirklich gut können
(zumal das mit CSS ja nicht unbedingt einfacher geworden ist).

Natürlich gibt es performance-relevante Aspekte im Bereich HTML,
etwa die Größenangabe für Bilder oder dergl.

Eben.

Ich bin mir aber nicht sicher, ob diese Kriterien mit der
Validierungsproblematik deckungsgleich sind.

Immerhin sind "height" und "width" für Bilder Pflichtangaben in gewissen
HTML-Dialekten - während sie das für Tabelle nicht sind (und auch nicht
sein dürfen). Dies halte ich für eine explizite Performance-Optimierung
des Sprachstandards, der an dieser Stelle die Angabe einer wahrschein-
lich (!) konstanten Information erzwingt, um das Rendering zu beschleu-
nigen - und dabei in Kauf nimmt, daß man nicht mehr per CGI etc. Bilder
dynamischer (Anzeige-)Größe in valide HTML-Seiten einsetzen kann.

Viele Grüße
      Michael

[Mathias Bigge]

Hallo Michael,

danke für Deine ausführliche Antwort.

Eben das ist eine Strategiefrage. Und die könnte beispielsweise _auch_
davon abhängig gemacht werden, ob (und welcher!) DOCTYPE in einem
Dokument drin steht (nach dem Motto: HTML 4.01 schreiben auch die DAUs
rein, da parsen wir mal defensiv und langsam; wer XHTML 1.1 macht,
weiß schon eher, was er tut, und wird dann auch die Strafe des zwei-
maligen Parsens in Kauf nehmen, falls das Dokument eben doch nicht
valide ist). Irgendwie in diese Richtung müssen die M$IE-Programmierer
bei Quirks-Mode und Compliant Mode ja auch gedacht haben.

Ich befürchte auch, dass die Microsoft-Leute wieder einmal früh die Zeichen der Zeit erkannt haben, und dass ihr Eiertanz bezüglich der Normen nicht auf Unfähigkeit beruht, sondern erfolgsorientierte Machtstrategie ist.

Natürlich gibt es performance-relevante Aspekte im Bereich HTML,
etwa die Größenangabe für Bilder oder dergl.
Eben.

Ich denke, wir sind einer Meinung, dass die wichtigsten Performance-Aspekte bei HTML für viele Sites die Größenangaben bei Bildern und Tabellen sind, vielleicht noch die unnötige Komplexität mancher Tabellenkonstruktionen selbst. Eine interessante Frage ist für mich, welche Beschleunigung man durch Verbesserung des übrigen HTML-Codes erreichen kann. Ich wundere mich oft, in welchem Tempo die Standardbrowser selbst den absurdesten Befehlswust verarbeiten, etwa von Frontpage, Word, oder GoLive generierte Seiten. Selbst die fast schon epischen JS-Konstrukte von Adobe werden meist in 0,Nix gefressen. Natürlich gibt es Ausnahmen, etwa die Textmassen in SELFHTML oder anderen Tutorien, wo man vielleicht durch eine Formatierung jedes einzelnen Tags Performanceprobleme hinkriegen könnte ;-)

Ich bin mir aber nicht sicher, ob diese Kriterien mit der
Validierungsproblematik deckungsgleich sind.

Immerhin sind "height" und "width" für Bilder Pflichtangaben in gewissen
HTML-Dialekten - während sie das für Tabelle nicht sind (und auch nicht
sein dürfen). Dies halte ich für eine explizite Performance-Optimierung
des Sprachstandards, der an dieser Stelle die Angabe einer wahrschein-
lich (!) konstanten Information erzwingt, um das Rendering zu beschleu-
nigen - und dabei in Kauf nimmt, daß man nicht mehr per CGI etc. Bilder
dynamischer (Anzeige-)Größe in valide HTML-Seiten einsetzen kann.

Stimmt, hier läuft die Entwicklung der Standards in die richtige Richtung. Die Sache mit den dynamischen Bildern habe ich noch nicht ganz verstanden. Bei der Ausgabe sind sie doch dann schon statisch, wenn man die Tags mitanpasst, oder verstehe ich Dich da falsch?

Viele Grüße
Mathias Bigge

[Michael Schröpl]

Hi Mathias,

Die Sache mit den dynamischen Bildern habe ich noch nicht ganz
verstanden. Bei der Ausgabe sind sie doch dann schon statisch,
wenn man die Tags mitanpasst, oder verstehe ich Dich da falsch?

der <img>-tag selbst könnte auf einen URL zeigen, der als CGI-Skript
ein Bild zurückliefert, dessen Inhalt und Größe erst zur Laufzeit
feststeht (beispielsweise ein zufälliges aus einer Sammlung).

Wenn Du dann vorher im statischen HTML-Text die Größe festnagelst,
schränkst Du die optimale Darstellung des Bildes erheblich ein.

Viele Grüße
      Michael