Eine Lanze brechen für Frames

[fireeye]

Hi @all

Ich habe das Forum aufmerksam verfolgt, welche Aussagen über Frames gemacht werden. Für mich hat es den Anschein, als wenn die Ablehnung dogmatisiert ist. Bei der Nachlese auf anderen Seiten, die sich mit dem Thema befassen, sieht es auch nicht viel besser aus. Teilweise steht von Nachteilen zu lesen, die IMHO wirklich an den Haaren herbeigezogen sind.

Gut, das Thema "Barrierefreiheit" ist sicher sehr ernst zu nehmen. Doch die puristische Behandlung des Themas führt IMHO auch zu Stilblüten, um es mal in dieser Form zu persiflieren.

Ich habe sehr viel Verständnis für Menschen, die mit ihren körperlichen Gebrechen in ihrem Leben zurechtkommen müssen.
Doch niemand würde allen Ernstes behaupten wollen, es sollte i.e. für Blinde die Barriere zum Autofahren demontiert werden, zumindest jetzt noch nicht, da entsprechender technischer Ersatz für die menschliche Sehfähigkeit noch nicht in ausreichender Qualität zur Verfügung steht.

Bei allen Statements zu diesem Thema fällt mir auf, daß Webpages angeblich ausschließlich nur zu einem Zweck gemacht wären. Ich für meinen Teil empfinde das als eine sehr eingeschränkte Sichtweise. So empfinde ich den Tadel, daß Webpages nicht nur für eine Zielgruppe gemacht werden sollten, als nicht gerechtfertigt. Ich habe für meine Bedürfnisse die Technik der Webpages als Ersatz für Dokumentation auf Papier entdeckt, somit richtet sich das sehr wohl an bestimmte Zielgruppen. Der Ausschluß anderer, die nicht zu diesen Zielgruppen gehören, liegt oft in der Natur der Sache und bedeutet dabei keineswegs eine Diskriminerung.

In zurückliegenden Zeiten wurden für technische Dokumente tonnenweise das Papier verwendet, mit dem Nachteil aufwendigster Suche nach bestimmten Details. Die Technik der Webpages ermöglicht es heute, eine Dokumentation zu erstellen, wo das Auffinden von Details in kürzester Zeit ermöglicht wird. Technische Dokumentationen sind IMHO zum Teil aufwendiger als manche Webpages, die als freies Angebot für jedermann errichtet werden. Der oft von den Frame-Gegnern angeführte Hinweis, Navigation wäre zur Vermeidung von Frames ohne weitere Probleme über CSS in die Seite einzubauen, ist IMHO zu kurz gesehen. Ich habe in meinen Projekt derzeit an die 300 Seiten eingebaut, die Navigation enthält z.Zt. etwas mehr als 1300 Einträge, diese Navigation mit jeder Seite laden zu wollen, würde jedes mal etwa zusätzliche 60 KB erfordern.

Auch der Hinweis darauf, Javascript zu vermeiden, weil es gute Gründe gegen die Verwendung von Javascript geben würde, wobei die Kritiker jedes mal die Begründung der angeblich gute Gründe schuldig bleiben, ist für mich sehr weit hergeholt. Niemand würde eine Axt verdammen wollen, nur weil es gute Gründe gibt, die Axt als gefährliches Instrument einzustufen. Der Mißbrauch ist stets nicht ausgeschlossen und mißliebige Zeitgenossen, die eine Sache zu mißbrauchen versuchen, gibt immer wieder. So kann denn die Absicht, eine Navigation mit einem Frame bei Verwendung von Javascript aufzubauen, nicht immer mit dem Hinweis auf fehlende Barrierefreiheit mißbilligt werden.

Das WWW mit seiner Technik ist IMHO keine ausschließliche Spielwiese für WWW-Designer, sondern es muß zugelassen werden, die Technik auch in anderen Kontexten einzusetzen. Es gibt für das WWW nicht nur einen Kontext. Die Gestaltung einer technischen Dokumentation mit der Webtechnik ist ein ernst zunehmendes Thema und es wäre schade, wenn wegen einseitiger Sichtweisen die Elemente, die bisher ihre guten Dienste tun, aus dem Standard verschwinden würden. Das Framesets bisher nur als transitional eingestuft sind, halte ich für bedenklich. Die angeblichen Probleme mit Frames beruhen IMHO auf nicht ausgereifter Umsetzung bei den Browsern. Das Kind mit dem Bade ausschütten zu wollen, so wie es auf verschiedenen Sites zu lesen ist, mit der Maßgabe Frames ganz abschaffen zu wollen, zeugt IMHO von einem viel zu kleinen Horizont. Die angeblichen Probleme mit Frames lassen sich heute alle mit Bordmitteln lösen, da bedarf es keines Hacks, es kommt dabei auf die Kenntnisse an, die aber offenbar bei einigen Frame-Gegnern nicht ausreichend vorhanden sind.

Der Fortentwicklung der Technik kann nur dann sinnvoll sein, wenn sie die mögliche Vielfalt nicht ausschließt. Es wird IMHO aber nie möglich sein, eine Webpages im Sinne eine eierlegenden Wollmilchsau für alle Plattformen erstellen zu können. Man wird sich Gedanken machen müssen, wie man Minderheiten besser versorgt und technische Möglichkeiten errichtet, die diesen speziellen Zwecken dienen. Das ist IMHO besser, als den kleinsten gemeinsamen Nenner zu suchen, wobei andere sinnvolle Techniken aufgegeben werden.

Ich habe hier meine Gedanken zum Thema niedergeschrieben, eben aus einer anderen Sicht, die nicht den Mainstream vertritt. Die von mir vorgetragene Sichtweise behandelt hier nur einen Aspekt. Aber ich wüßte auf Anhieb mindestens noch weitere Anwendungen, die das WWW nicht nur auf den Mainstream reduzieren.

Gruß f

[Schuer]

Für mich hat es den Anschein, als wenn die Ablehnung dogmatisiert ist.

Oft tritt die Abneigung gegenüber Frames sicherlich dogmatisiert auf, aber grundsätzlich hat sie ihre Basis in einer Vielzahl von Nachteilen, die durch den Einsatz von Framesets entstehen. Ganz schlicht also.

Gut, das Thema "Barrierefreiheit" ist sicher sehr ernst zu nehmen.

Natürlich, aber gerade dieser Punkt ist einer derjenigen, der bei den Nachteilen von Frames weit nach hinten tritt. Framesets bilden technisch keine besonderen Barrieren, wenn sie richtig eingesetzt werden.

Doch niemand würde allen Ernstes behaupten wollen, es sollte i.e. für Blinde die Barriere zum Autofahren demontiert werden, zumindest jetzt noch nicht, da entsprechender technischer Ersatz für die menschliche Sehfähigkeit noch nicht in ausreichender Qualität zur Verfügung steht.

Der Vergleich hinkt, denn dabei wird das Thema Barrierefreiheit leider von der falschen Seite angegangen. Eigentlich ist es ganz einfach: eine Webseite ist erstmal grundsätzlich barrierefrei, solange man sie als Webautor/-entwickler nicht aktiv (meist unbewusst und/oder aus technischem Unverständnis heraus) einschränkt, indem man z.B. eine unverständliche Navigation verwendet, ungünstige Farben ohne ausreichenden Kontrast verwendet, Bilder ohne Alternativinhalte einfügt oder die Schriftgröße festzementiert.

Dementsprechend ist Barrierefreiheit also kein besonderes Merkmal, sondern ganz einfach die Grundvoraussetzung einer jeden Website. Kritik an nicht barrierefreien Seiten beruht darauf, dass dort Barrieren bewusst eingesetzt werden, obwohl man sie doch recht einfach entfernen könnte bzw gar nicht erst hätte einsetzen müssen.

Man wird sich Gedanken machen müssen, wie man Minderheiten besser versorgt

Das ist ganz einfach, siehe oben. Die Frage - und damit die Kritik - ist nur: warum macht man es nicht, wo es doch so einfach ist?

Viele Grüße!
_Dirk
DECAF°

[fireeye]

Hi @ all

Nach einer viel zu kurzen Nacht, die eigentlich schon keine mehr war :) habe ich jetzt die in der Zwischenzeit eingelangten Diskussionsbeiträge mit großem Interesse gelesen. Ich finde es schon beachtlich, was ich MIR (ich betone das ausdrücklich auf mich bezogen) als Resumee, wenn auch nicht repräsentativ, zusammenreimen darf. Gleichwohl wie in der katholischen Kirche das dogmatische Zölibat gehandelt wird, gehen auch einige HTML-Puristen mit den FRAMES um. Der katholische Priester darf keinen Sex haben, aber einige haben ihn offensichtlich genauso gerne wie andere Menschen auch, die nicht von dem Dogma betroffen sind. (Achtung: schon wieder ein Beispiel, das sicher hinken wird, dessen Hinwies darauf ich somit vorsorglich meinen Kritikern vorweg nehmen möchte...könnt ihr ihn euch somit ersparen...) Und bei näherem Hinsehen kann man auch eine überraschende Entdeckung machen. So befinden sich die angekündigten XFRAMES erst noch in Arbeit und es darf auch jederzeit damit gerechnet werden, daß die XFRAMES sang und klanglos verschwinden könnten. "Todos es possible" würde meine Frau jetzt sagen oder in der doppelten Verneinung mit Toyota: Nichts ist unmöglich..... Also führen wir hier eine Diskussion um des Kaisers Bart, dessen Träger von Schweizern mit Helebarden und Laserpointern bewacht wird. ROFL sag ich nur. XFRAMES hat seine Beschreibung in einem W3C Working Draft, das über den Stand vom 06.08.2002 noch nicht hinausgekommen ist. Schon wieder ein Vergleich, der hinkt: Es fühlt sich an, wie ein Nierenkranker, der sehnsüchtig auf eine Spenderniere wartet, dessen Leben aber weiterhin von der Blutwäsche abhängig bleibt, weil man ihm die Spenderniere nicht einpflanzt sondern nur vor seinen Augen im Plastiksackerl baumeln läßt.

Der Mainstream dogmatisiert sich unnötig selbst und manche Verfechter dessen führen Belehrungen in dem Stil eines Oberlehrers aus, der sich wohl die Zeiten mit der Rute zurück wünscht. Teilweise laufen die Beiträge aus dem Kontext des Diskussionsbeginns heraus mit dem Verweis auf einen Tunnelblick, wobei sich der Schreiber um den Splitter in den Augen anderer sorgt, dabei aber offensichtlich den Balken im eigenen Auge glatt übersieht. Ich will es daher noch einmal deutlich machen, daß ich die Diskussion nicht gestartet habe, weil ich den generellen Gebrauch von FRAMES unterstützen möchte, sondern weil ich den Gebrauch in bestimmten Zusammenhänge für sinnvoll erachte.

Rätselhaft erscheinen mir manche Diskussionführer, die FRAMES am liebsten aus dem HTML mit dem Hinweis auf den möglichen Ersatz durch XFRAMES verbannen würden. FRAMES gefährden Suchmaschinen, XFRAMES machen das nicht anders. FRAMES bauen Barrieren auf, XFRAMES machen das nicht anders. FRAMES haben, machen... XFRAMES haben, machen es kaum anders... Mancher Beitrag klingt wie ein Urschrei, doch was ist mit der Auseinandersetzung um vorgebrachte Argumente? Es ergibt keinen Sinn, wenn ich ein technisches Diagramm darstelle und für blinde Nutzer ein seitenlanger Alternativtext erforderlich wäre. Ein in der Technik oft verwendetes Wort würde somit ad absurdum geführt: "Eine Skizze sagt mehr als tausend Worte." Das Dogma von der Barrierefreiheit läuft sich somit tot, dessen puristischen Verfechter sich in meinen Augen oftmals päpstlicher als der Papst verhalten. Die gebetsmühlenartige Wiederholung bringt damit NATÜRLICHE Barrieren auch nicht vom Tisch. Es gibt im wirklichen Leben immer natürliche Grenzen, die auch durch Diskussionen nicht aufgelöst werden können. Dieses muß auch in der Scheinwelt des WWW, die oft nur auf sich selbst reflektiert, akzeptiert werden. Ich halte meine Entscheidung, deren Hintergründe ich deutlich gemacht habe, für richtig, mein Projekt nur für EINE Zielgruppe gemacht zu haben, eine Zielgruppe, die sich klar und deutlich von dem Einheitsbrei aller möglichen Nutzer abgrenzt. Das puristische Verlangen, nicht so zu handeln, ist blanker Unsinn. Das Wort vom "Zielgruppenwahn" ist gleichsam dogmatisch. Ich habe darum mit Genugtuung vernommen, daß nicht alle Beteiligten dieser Diskussion mit diesem Tunnelblick ausgestattet sind.

Mein Text soll keine flammende Rede gegen Barrierefreiheit sein, gegen das Dogma aber schon. Der Designer einer Webpage soll sich Gedanken darum machen, wo es angebracht ist. Ist fasse das als Leitgedanken auf, mehr aber auch nicht. Es wäre unsinnig, einen Oldtimer partout mit einem Katalysator ausrüsten zu wollen, wenn dafür die technischen Voraussetzungen fehlen (ACHTUNG: schon wieder ein Vergleich der hinkt...Hinweise darauf bleiben euch somit erspart...). Javascript hat sich nach meiner Ansicht etabliert, die Verneinung dessen klingt für mich absurd. Es ist ein schöner Gedanke ein Webpage zu bauen, die mit und ohne Javascript funktioniert. Aber wofür ist dann Javascript überhaupt existent? Ein Sündenfall in der Entwicklung des WWW? Die von Javascript ausgehende Gefahr? In dem Sumpf der Argumente gerät aber auch plötzlich i.e. PHP in den Verdacht! Oh je. Und jetzt kommt Rudi Ratlos oder der schlaue Spruch, sich auf pures HTML ohne jeden Schnickschnack zu besinnen? Pur läßt im Englischen die Nähe zu POOR zu! It's pretty poor.....Was ist mit dem Gedanken, Struktur und Inhalt strikt zu trennen? Ist HTML-CSS in der Lage, das auch mit aller Konsequenz auch zu realisieren? Die Frage kann schlicht und ergreifend mit einem NEIN beantwortet werden! Leider!

Mein Selbstwertgefühl bestärkt sich zunehmend mit der Feststellung, daß es in dem HTML-CSS-Jvascript-Dickicht keine heile Welt gibt, die mit Patentlösungen aufwarten kann. Es bleibt was es ist, es ist Menschenwerk, das sich ständig im Wandel befindet. Somit hat die Diskussion für mich ein positives Ergebnis gebracht, auch wenn manche Hardliner es nicht wahrhaben wollen. So ist es schön die Erfahrung anderer zu lesen, daß i.e. CSS doch nicht in allen Fällen den Einsatz von TABLE überflüssig machen kann. Das läuft runter wie Öl, Balsam für meine Seele. Das bricht hoffentlich ein paar Zacken aus der Krone der "Experten" und so mancher User ist nicht mehr genötigt, sich das Makel eines DAU anzuheften.

In dem Sinne wünsche allen ein schönes WE

Gruß f

[wahsaga]

hi,

(Achtung: schon wieder ein Beispiel, das sicher hinken wird, dessen Hinwies darauf ich somit vorsorglich meinen Kritikern vorweg nehmen möchte...könnt ihr ihn euch somit ersparen...)

warum ersparst du uns allen dann nicht gleich solche halbgaren beispiele?

Also führen wir hier eine Diskussion um des Kaisers Bart, dessen Träger von Schweizern mit Helebarden und Laserpointern bewacht wird.

und der bart wird immer länger, wenn leute wie du zu faul sind, sich mal mit den schon zahlreich im archiv vorhandenen diskussionen zu beschäftigen, und stattdessen meinen, das thema noch mal "neu" diskutieren zu müssen.
"neu" in anführunszeichen, weil es dazu nun wirklich nicht mehr viel neues gibt für die meisten beteiligten - von dir mal abgesehen.

Es fühlt sich an, wie ein Nierenkranker, der sehnsüchtig auf eine Spenderniere wartet, dessen Leben aber weiterhin von der Blutwäsche abhängig bleibt, weil man ihm die Spenderniere nicht einpflanzt sondern nur vor seinen Augen im Plastiksackerl baumeln läßt.

wenn wir bei den pathologischen vergleichen bleiben wollen - dann wärst du vermutlich ein demenzkranker, der alles gesagte spätestens fünf minuten später wieder vergessen hat, und dann schon wieder mit längst argumentativ widerlegten thesen auf der matte steht - ohne selber viel argumentatives zu bringen.

Ich will es daher noch einmal deutlich machen, daß ich die Diskussion nicht gestartet habe, weil ich den generellen Gebrauch von FRAMES unterstützen möchte, sondern weil ich den Gebrauch in bestimmten Zusammenhänge für sinnvoll erachte.

na wunderbar.
das wird hier auch niemand ernsthaft bestreiten wollen, noch dürfte das in den zahlreichen im archiv auffindbaren diskussionen zum thema der fall sein.
fazit: du hast absolut nichts neues in die diskussion einbringen können, sondern wärmst nur kalten kaffee zum x-ten male neu auf.

Mancher Beitrag klingt wie ein Urschrei, doch was ist mit der Auseinandersetzung um vorgebrachte Argumente?

das solltest du _dich_ fragen, scherzkeks.
argumente _kontra_ frames wurden mehrfach _fundiert_ vorgebracht.
auf diese argumente gehst du aber so gut wie gar nicht ein, sondern kommst stattdessen wieder mit deinen allgemeinplätzen.
wenn es jemanden gibt, der in dieser diskussion dringend ein wenig mehr differenzierungsfähigkeit an den tag legen sollte, bist vermutlich du das.

Ich habe darum mit Genugtuung vernommen, daß nicht alle Beteiligten dieser Diskussion mit diesem Tunnelblick ausgestattet sind.

rede du bitte nicht von tunnelblick, damit kannst du dich nur lächerlich machen - wenn hier jemand einen solchen aufgesetzt hat, dann sicher du.

noch einmal, damit auch du es jetzt hoffentlich verstehst:

niemand bestreitet ernsthaft, dass es gute anwendungsfälle für frames gibt, auch heute noch.
aber warum zum henker versteifst du dich so auf diese spezialfälle?
dadurch wirst du offenbar vollkommen blind für die sachlichen argumente, die _oftmals_ gegen den einsatz von frames sprechen.

anstatt dich mit diesen argumenten zu beschäftigen oder gar auf sie einzugehen, kanzelst du sie als "oberlehrergeschwätz" ab - einfach nur dumm.

(ACHTUNG: schon wieder ein Vergleich der hinkt...Hinweise darauf bleiben euch somit erspart...).

Javascript hat sich nach meiner Ansicht etabliert, die Verneinung dessen klingt für mich absurd.

der einzige, der sich hier in mehr und mehr absurditäten versteigt, bist du.
niemand verneint ernsthaft den zusatznutzen, den javascript mit sich bringen kann.
du interpretierst hier sachen in die aussagen der anderen teilnehmer hinein, die so überhaupt nicht gemeint waren. _das_ ist ein tunnelblick ...

Mein Selbstwertgefühl bestärkt sich zunehmend mit der Feststellung, daß es in dem HTML-CSS-Jvascript-Dickicht keine heile Welt gibt, die mit Patentlösungen aufwarten kann. [...] So ist es schön die Erfahrung anderer zu lesen, daß i.e. CSS doch nicht in allen Fällen den Einsatz von TABLE überflüssig machen kann. Das läuft runter wie Öl, Balsam für meine Seele.

ach, darum ging's in dieser diskussion also nur?
was andere ebenfalls schon wussten und womit sie sich ziemlich sicher waren, musst du extra noch mal bestätigt bekommen, damit du es auch zu vertreten wagst? komische definition von "selbstbewusstsein".

wenn du das thema noch weiter diskutieren willst, oder andere in ähnlicher form, dann tu das auch bitte - _diskutiere_!

bisher ist das allenfalls im ansatz zu erkennen - sachlicher argumentation verschließt du dich weitgehend bzw. ignorierst sie.

statt gegenargumente zu bringen, versteckst du dich hinter deinem "spezialfall" - und hinter deiner arroganten polemik, die sachliches nur als oberlehrergeschwätz abtut. das sieht nach einem armutszeugnis aus, weil du argumentativ wenig dagegenzusetzen hast.

gruß,
wahsaga

[Schuer]

[..] Barrierefreiheit [..] Der Designer einer Webpage soll sich Gedanken darum machen, wo es angebracht ist.

Nochmal: eine Website ist solange barrierefrei, bis sie bewusst/aktiv eingeschränkt wird. Der Designer muss sich also nicht überlegen, wo Barrierefreiheit "angebracht" ist, sondern muss sich ganz im Gegenteil dafür rechtfertigen, warum auftretende Barrieren nicht vermieden werden.

Somit hat die Diskussion für mich ein positives Ergebnis gebracht,

Ich habe den Eindruck, du hast da noch einige wesentliche Dinge nicht verstanden.

Das bricht hoffentlich ein paar Zacken aus der Krone der "Experten"

Nope. Experten haben sich bereits intensiv mit den Themen, die du hier aufgeriffen hast, beschäftigt. Sollten ihnen Zacken abbrechen, dann allein aufgrund des zu heftigen Kopfschüttelns.

Viele Grüße!
_Dirk
DECAF°

[Struppi]

Nach einer viel zu kurzen Nacht, die eigentlich schon keine mehr war :) ...

Dass allein muss der Grund sein, um zum wiederholten Male das Gleiche runterzuleiern.

Um dir wenigstens ein bisschen die Möglichkeit zu geben zu verstehen:

DU hast behauptet Frames würden mit dem Bade ausgeschüttet.
Aber keiner hat bisher bestritten dass Frames durchaus Anwendungsgebiete haben können und dass es Entwicklungen gibt, die versuchen manche Nachteile von ihnen zu beseitigen.

Keiner hier hat Frames verdammt und auf XFRAMES verwiesen, sondern dass war lediglich ein Antwort auf deine haltlose Behauptungen Frames würden von irgendjemand verteufelt und deshalb von Dogmatikern oder Mainstream oder wie immer du es nannest abgeschafft.

Das Gegenteil ist der Fall sondern die bekannten Nachteile:
Zitat:
*  The [back] button works unintuitively in many cases.
* You cannot bookmark a collection of documents in a frameset.
* If you do a [reload], the result may be different to what you had.
* [page up] and [page down] are often hard to do.
* You can get trapped in a frameset.
* Searching finds HTML pages, not Framed pages, so search results usually give you pages without the navigation context that they were intended to be in.
* Since you can't content negotiatiate, noframes markup is necessary for user agents that don't support frames. However, almost no one produces noframes content, and so it ruins Web searches, since search engines are examples of user agents that do not support frames.
* There are security problems caused by the fact that it is not visible to the user when different frames come from different sources.

sollen wenn möglich durch XFrames beseitigt werden. Wenn dies nicht funktioniert oder wenn kein Browserhersteller diese so umsetzten will, wird es weiterhin Frames geben. Da kannst du noch so oft etwas anderes behaupten.

Auch hat dir hier niemand die Entscheidung für gewisse Techniken für dein Projekt angezweifelt, aber das ist wohl deine Paranoia. Wenn du Frames für richtig hältst, gut. Es gäbe sicher andere Möglichkeiten die vielleicht auch sinnvoller wären (z.b. um Seiten auch Bookmarken zu können), z.b. der Einsatz von JS.

Und hier sind wir beim nächsten Punkt den du wiederholst bis zum umfallen. Niemand sagt du sollst auf JS verzichten, nur sollst du dir überlegen ob du die Funktionalität der Seite für manche User einschränken willst. Kommst du für dein Projekt zum Schluss ja du kannst, dann spricht nichts gegen den Einsatz. Nur musst du dir darüber im klaren sein, dass du damit den Nutzen der Seite einschränkst. Ob du es wahr haben willst oder nicht.

Genau das gleiche betrifft Barrierefreiheit. Es ist deine Entscheidung (solange du keine Seite machst die per Gesetz Barrierefrei sein müssen). Und wir die Dogmatiker oder Mainstream oder wie du uns nennen möchtest, fragen dich ob du sicher bist das du es willst, weil es oftmals Wege gibt die Barrieren nicht einzubauen. Und ob du diesen Lernprozess nicht mitmachen willst. Und hier steht deine Antwort, nein ich will nicht als letztes Wort.

Ist doch ok, wir wollen dir Möglichkeiten zeigen, wenn du sie nicht nutzen willst, wird dich niemand daran hindern können.

Als letztes noch
Doch es geht! Du kannst sehr gut mit CSS Inhalt und Layout trennen. Der Klassiker der dir das zeigt ist http://www.csszengarden.com/.
Aber wenn du ein Layout hast, dass eine Tabellenstruktur hat, wirst du eine Tabelle nicht ersetzen können das stimmt.

Struppi.

[fireeye]

Hi Struppi

Nach einer viel zu kurzen Nacht, die eigentlich schon keine mehr war :) ...
Dass allein muss der Grund sein, um zum wiederholten Male das Gleiche runterzuleiern.

:) He he, man wird sich doch einmal mit was anderem beschäftigen dürfen als mit diskutieren, zumindest an schönen warmen Sommerabenden?

Um dir wenigstens ein bisschen die Möglichkeit zu geben zu verstehen:

Ich bin immer ein verständiger Mensch, auch wenn's bei anderen manchmal nicht so ankommt...

DU hast behauptet Frames würden mit dem Bade ausgeschüttet.

Das ist wie mit der Stillen Post aus Kindertagen...was ich behauptet habe (oder auch nicht) und das was bei andern ankommt....
Zumindest ist BEI MIR in Bezug auf Frames, die Nachricht von einer anderen Site so angekommen, wäre es nicht so angekommen, hätte es die Diskussion darum nicht gegeben.

Auch hat dir hier niemand die Entscheidung für gewisse Techniken für dein Projekt angezweifelt, aber das ist wohl deine Paranoia.

He he, so weit ist es bei mir noch nicht, ich glaube bei dir auch nicht, aber bei anderen wäre ich mir nicht so sicher...

Wenn du Frames für richtig hältst, gut. Es gäbe sicher andere Möglichkeiten die vielleicht auch sinnvoller wären (z.b. um Seiten auch Bookmarken zu können), z.b. der Einsatz von JS.

Bookmarken, das wäre zumindest ein Thema, was ich bisher nicht so gesehen habe...leider. position:fixed funktioniert aber leider auf dem IE nicht. Das dafür vorhandene Workaround geht hier auf meine Mac-IE nicht (die Beispiele bei Self... auch nicht), wenn position:fixed auf allen Browsern funktionieren würde, wäre ich sofort von meinen Frames weg, aber leider... :-((

Und hier sind wir beim nächsten Punkt den du wiederholst bis zum umfallen. Niemand sagt du sollst auf JS verzichten...

Und jeder versteht die Predigt auf der Kanzel anders....

Genau das gleiche betrifft Barrierefreiheit. Es ist deine Entscheidung (solange du keine Seite machst die per Gesetz Barrierefrei sein müssen).

Da steht's, die Einschränkung...was immer auch bei einer Fallunterscheidung heranzuziehen ist, was aber hier in der Diskussion leider allzu oft untergegangen ist.

Ist doch ok, wir wollen dir Möglichkeiten zeigen, wenn du sie nicht nutzen willst, wird dich niemand daran hindern können.

Jeder (hoffentlich) nimmt das für sich in Anspruch, was sich ihm gegenüber als vorteilhaft erweist und er der Meinung ist, daß es auch für den User von Vorteil ist.

Aber wenn du ein Layout hast, dass eine Tabellenstruktur hat, wirst du eine Tabelle nicht ersetzen können das stimmt.

Nö, das mit der Tabelle war ich nicht, ich verwende <table> für das, was der ursprüngliche Wortsinn hergibt und nicht für Strukturlayout.

Ansonsten full ack, schönen Tag auch

Gruß f

[Cyx23]

Hallo,

Bookmarken, das wäre zumindest ein Thema, was ich bisher nicht so gesehen habe...leider. position:fixed funktioniert aber leider auf dem IE nicht. Das dafür vorhandene Workaround geht hier auf meine Mac-IE nicht (die Beispiele bei Self... auch nicht), wenn position:fixed auf allen Browsern funktionieren würde, wäre ich sofort von meinen Frames weg, aber leider... :-((

einige mir bekannte Beispiele für position:fixed leiden darunter dass das Scrollrad bei
einigen weit verbeiteten Browsern nicht mehr nutzbar ist, weshalb ich diese Lösungen für
problematisch halte, und bei Barrierefreiheit mag position fixed auch sowieso ein potentielles
Risiko darstellen.

Wem es aber wichtig ist der kann per JavaScript für Netscape 4 position:fixed als dynamisch
erzeugtes Frameset ersetzen, damit wären webhits.de 2% Besucher zusätzlich mit position fixed
versorgt. Wenn ich weiter webhits.de anschaue sollen wohl rund 0,5% einen Mac-IE nutzen, also nur
wenig mehr als es IE 4 Nutzer gibt.
Auch für den IE 4 läßt sich fixed gut per CSS realisieren, was angesichts der relativ geringen
Verbreitung jedoch unüblich zu sein scheint. Aber nutzen denn soviele deiner Kunden oder
Entscheidungsträger tatsächlich noch einen IE 5.2, und erwarten sie eine perfekte Layoutumsetzung
bei dem Browser?

Grüsse

Cyx23

[Cybaer]

Hi,

Das Gegenteil ist der Fall sondern die bekannten Nachteile:

... die auftreten, wenn der HTML-Autor sich an Techniken wagt, die er nicht beherrscht. :->

Gruß, Cybaer

[Struppi]

... die auftreten, wenn der HTML-Autor sich an Techniken wagt, die er nicht beherrscht. :->

Wobei du keine der Nachteile mit HTML beseitigen kannst, da hilft dir auch keine Beherrschung.

und diesen Punkt:
* There are security problems caused by the fact that it is not visible to the user when different frames come from different sources.

wirst du auch nicht mit irgendeiner Technik beseitigen können.

Struppi.

[Cybaer]

Hi,

Wobei du keine der Nachteile mit HTML beseitigen kannst, da hilft dir auch keine Beherrschung.

Doch, natürlich auch das - wenn auch nicht alle.

Aber das hatten wir ja alles schon ... :-)

Außerdem wüßte ich auch nicht, wieso man sich auf HTML beschränken sollte. Ich beschränke mich auch sonst eher selten auf HTML. Ich schränke den User allerdings auch nicht ein. Vielleicht verwechselst Du da was? O;->

und diesen Punkt:
* There are security problems caused by the fact that it is not visible to the user when different frames come from different sources.
wirst du auch nicht mit irgendeiner Technik beseitigen können.

Och, man kann doch mit einem Link anbieten, jeden Frame in einem eigenen Fenster anzeigen zu lassen - falls der User nicht in der Lage ist, dies selbst zu machen (oder einfach mal nachzusehen). ;->

IMHO ist das "Argument" "neben der Kapp". Wenn ich mißtrauisch bin, dann schaue ich einfach mal nach. Wer sich dadurch besser fühlt ... =:->

... bevor er irgendwas macht, was man online sowieso besser nicht macht. >;->

Gruß, Cybaer

[Struppi]

und diesen Punkt:
* There are security problems caused by the fact that it is not visible to the user when different frames come from different sources.
wirst du auch nicht mit irgendeiner Technik beseitigen können.

Och, man kann doch mit einem Link anbieten, jeden Frame in einem eigenen Fenster anzeigen zu lassen - falls der User nicht in der Lage ist, dies selbst zu machen (oder einfach mal nachzusehen). ;->

IMHO ist das "Argument" "neben der Kapp". Wenn ich mißtrauisch bin, dann schaue ich einfach mal nach. Wer sich dadurch besser fühlt ... =:->

Es ja geht nicht darum was du machst, sondern das es durchaus auch Menschen im Internet sich rumtreiben die ihre kriminelle Energie nutzen um anderen ihr Geld aus der Tasche zu ziehen und dass es Menschen gibt die weder Wissen was Frames sind noch nach irgendwas sehen können, was sie nicht kennen - die also nicht mißtrauisch sind - und denen läßt sich mit Hilfe von Frames durchaus etwas anderes unterjubeln als sie glauben zu sehen.

Struppi.

[Cybaer]

Hi,

und denen läßt sich mit Hilfe von Frames durchaus etwas anderes unterjubeln als sie glauben zu sehen.

Stimmt. Es ist ja auch sehr wahrscheinlich, daß z.B. die Postbank in einem Frameset mit ihrem seriösen URL einen Frame von irgendeinem obskuren Phisher versteckt. >;-> Wie gut, daß man so pöses Tun gleich durch Verzicht auf Frames unterbindet! :)

Sollte hingegen ein obskurer Phisher (immer noch mit unseriösem URL) in seinem Frameset eine offizielle Postbank-Seite "verstecken": Warum nicht? Dafür braucht er allerdings auch keine Frames ...

... genausowenig wie z.B. beim Überschreiben der hosts-Datei.

Habe ich das jetzt so treffend wiedergegeben? >;->

Gruß, Cybaer

[Struppi]

Habe ich das jetzt so treffend wiedergegeben? >;->

Nein, wir reden von 2 völlig verschiedenen Dingen.

Aber ist schon gut, du glaubst an das was du möchtest und ich an das was ich möchte.

Struppi.

[Cybaer]

Hi,

Aber ist schon gut, du glaubst an das was du möchtest und ich an das was ich möchte.

Solange Du, anders als z.B. Wahsaga, nur Wischi-waschi vermeldest, wird sich daran unter Garantie auch nichts ändern (können).

Gruß, Cybaer

[Struppi]

Aber ist schon gut, du glaubst an das was du möchtest und ich an das was ich möchte.

Solange Du, anders als z.B. Wahsaga, nur Wischi-waschi vermeldest, wird sich daran unter Garantie auch nichts ändern (können).

Ich bin einfach davon ausgegangen dass du in der Lage bist zu recherchieren oder dir wenigstens vorzustellen wie dieser Nachteil auszunutzen ist, aber offensichtlich reichte dazu dein Wissen nicht aus. Tut mir leid ich bin davon ausgegangen mit jemanden zu diskutieren der Ahnung hat und auch mal um die Ecke denken kann. Insofern bin ich wahsaga auch dankbar da er das gesehen hat und veruscht hat dich mit der Nase drauf zu stoßen.

Nur - die Antwort darauf zeigt einfach, dass man dir deinen Glauben nicht nehmen kann. Keine Ahnung was da in deiner Jugend passiert ist, du bist dermaßen verbohrt, dass es gar keinen Sinn macht irgendetwas zu recherchieren, weil du weißt es sowieso besser und wenn du es besser weißt, heißt das dass alle anderen, egal ob Anwender oder Browserhersteller oder Webseitenmacher, eben dumm sind.

Mir ist doch egal ob du der Meinung bist das die Nachteile von Frames für dich keine sind, ich brauch schon seit Jahren keine mehr, selbst wenn sie die Nachteile nicht hätten oder wie du es suggerierst alle Nachteile durch irgendwelche anderen Techniken zu beheben seien, wäre das für mich zuviel Aufwand, weil ich keine Vorteile darin sehe.

Struppi.

[Cybaer]

Hi,

Ich bin einfach davon ausgegangen dass du in der Lage bist zu recherchieren oder dir wenigstens vorzustellen wie dieser Nachteil auszunutzen ist, aber offensichtlich reichte dazu dein Wissen nicht aus.

Oh, daß Bugs im Scripting Sicherheitslöcher bieten, ist mir durchaus bewußt. Deswegen wird ja auch oft empfohlen das Scripting zu deaktivieren. :-)

Tut mir leid ich bin davon ausgegangen mit jemanden zu diskutieren der Ahnung hat und auch mal um die Ecke denken kann.

Stimmt. Alles mögliche sein zu lassen, anstatt einfach die Quelle des Übels (hier, wie des öfteren, das Scripting) anzupacken, ist in der Tat um die Ecke gedacht. Vielleicht ist es besser, auf das Web ganz zu verzichten, anstatt ggf. Scripting in sicherheitsrelevanten Bereichen zu deaktivieren. Ist das für dich hinreichend um die Ecke gedacht? >:->

Insofern bin ich wahsaga auch dankbar da er das gesehen hat und veruscht hat dich mit der Nase drauf zu stoßen.

Sicher. Nur: Was nutzt dir der Verzicht auf Frames, wenn das Scripting unsicher ist? Cross-Border-Scripting ist kein Problem exklusiv von Frames ...

Keine Ahnung was da in deiner Jugend passiert ist, du bist dermaßen verbohrt, dass es gar keinen Sinn macht irgendetwas zu recherchieren, weil du weißt es sowieso besser

Was "schief" gegangen ist kann ich dir sagen: Ich lasse mich nicht von "Dummen-Jungen-Argumenten" beeindrucken wie so leicht widerlegbaren Blödsinn à la "Wobei du keine der Nachteile mit HTML beseitigen kannst, da hilft dir auch keine Beherrschung."

Wenn man mich überzeugen will, dann bitteschön fundiert und mit (wenigstens) ein wenig mehr Niveau. :-o

Ich hinterfrage *prinzipiell* alle Dinge (ja, auch Frames) und klopfe Argumente auf Stichhaltigkeit ab. Auch schalte ich *prinzipiell* lieber meinen eigenen Verstand ein, als daß ich mich von "vorgefertigen Weisheiten" in irgendeiner Form beeindrucken lasse.

Nun kann man sagen: Schön und gut, dann reicht dein Verstand nicht aus, die Materie zu begreifen. Nun, das mag sein (wenngleich mein bisheriger Lebensweg eigentlich nicht für diese These spricht). Selbst dann aber greift IMHO der Grundsatz, der stets bei der Wissensvermittlung gilt (auch, wenn ich selbst Schulungen mache): Wenn der Lernende nicht begreift, dann hat (auch) der Lehrende versagt.

und wenn du es besser weißt, heißt das dass alle anderen, egal ob Anwender oder Browserhersteller oder Webseitenmacher, eben dumm sind.

Ich weiß es nicht (immer ;-)) besser, aber dummes Gewäsch läßt mich per se kalt. :-))

BTW: Was haben jetzt die armen Anwender, Webseitenmacher und Browserhersteller damit zu tun? Ob Anwender mit oder ohne Frames surfen, kann ich den Logs entnehmen. Ihre Entscheidung. Hat IMHO nichts mit "dumm" zu tun. Ob Webseitenmacher Frames einsetzen oder nicht, hat auch nichts mit "dumm" zu tun. Eher so, *wie* sie ihre Website machen (und das IMHO). Und die Browserhersteller? Die könnten ja am ehesten einfach sagen: Frames werden nicht mehr unterstützt. Punkt. Ist jetzt deiner Meinung nach "dumm", daß sie dies nicht tun, oder "dumm", wenn sie es täten? Du siehst mich verwirrt ... ;->

Mir ist doch egal ob du der Meinung bist das die Nachteile von Frames für dich keine sind, ich brauch schon seit Jahren keine mehr, selbst wenn sie die Nachteile nicht hätten oder wie du es suggerierst alle Nachteile durch irgendwelche anderen Techniken zu beheben seien, wäre das für mich zuviel Aufwand, weil ich keine Vorteile darin sehe.

Und mir ist *das* wiederum egal. Aber wer öffentlich Blödsinn postet, der muß auch damit rechnen, Kontra zu bekommen (oder wenigstens, sich eine spitze Bemerkung einzufangen). Das gilt für mich genauso wie für dich. :) Aber das schrieb ich dir ja schon bei früheren Gelegenheiten ... 8-)

Daß Du nicht anders kannst, als stets die schon lange durchgenudelten Dumm-"Argumente" aufzuzählen (wenn auch diesmal in englischer Sprache), macht das ganze eben so unterhaltsam. Und ohne Amüsement macht das Posten ja auch mir keinen Spaß ... :-)

Gruß, Cybaer

[Struppi]

Ich bin einfach davon ausgegangen dass du in der Lage bist zu recherchieren oder dir wenigstens vorzustellen wie dieser Nachteil auszunutzen ist, aber offensichtlich reichte dazu dein Wissen nicht aus.

Oh, daß Bugs im Scripting Sicherheitslöcher bieten, ist mir durchaus bewußt. Deswegen wird ja auch oft empfohlen das Scripting zu deaktivieren. :-)

Und wieder eines deiner tollen Argumente.

Tut mir leid ich bin davon ausgegangen mit jemanden zu diskutieren der Ahnung hat und auch mal um die Ecke denken kann.

Stimmt. Alles mögliche sein zu lassen, anstatt einfach die Quelle des Übels (hier, wie des öfteren, das Scripting) anzupacken, ist in der Tat um die Ecke gedacht. Vielleicht ist es besser, auf das Web ganz zu verzichten, anstatt ggf. Scripting in sicherheitsrelevanten Bereichen zu deaktivieren. Ist das für dich hinreichend um die Ecke gedacht? >:->

Es ging darum einen von mehreren Nachteilen zu erfassen, du wolltest das nicht bzw. dann kommt so eine Aussage wie oben. Das ist nicht um die Ecke gedacht sondern - um deine Worte zu benutzen - dumme Jungen Argumente.

Insofern bin ich wahsaga auch dankbar da er das gesehen hat und veruscht hat dich mit der Nase drauf zu stoßen.

Sicher. Nur: Was nutzt dir der Verzicht auf Frames, wenn das Scripting unsicher ist? Cross-Border-Scripting ist kein Problem exklusiv von Frames ...

Nochmals: es ging lediglich um einen Nachteil.

Außerdem hast du nicht die ganze Zeit behauptet, das man die anderen Nachteile mit u.a. JS beseitigen kann? Nur wie soll das Funktioneren wenn ich es deaktieren muss?

Was "schief" gegangen ist kann ich dir sagen: Ich lasse mich nicht von "Dummen-Jungen-Argumenten" beeindrucken wie so leicht widerlegbaren Blödsinn à la "Wobei du keine der Nachteile mit HTML beseitigen kannst, da hilft dir auch keine Beherrschung."

Naja, das war lediglich eine Antwort auf deine etwas lapidar dahin geschmissene Aussage die so klang als ob der HTML Autor alle Nachteile beseitigen könnte.

Wenn man mich überzeugen will, dann bitteschön fundiert und mit (wenigstens) ein wenig mehr Niveau. :-o

Du willst dich gar nicht überzeugen lassen, weil - das hatten wir ja bereits - du auf jeden Punkt mit einer allgemeinen Aussage behauptest du könntest sie mit deiner Ahnung von der Technik lösen, wobei ich bis jetzt noch nichts gesehen habe.

Wobei sich mir aber die Frage stellt, wenn es Nachteile gibt, die mit viel Ahnung der Technik behoben werden können, aber gleichzeitig einfach durch den Verzicht von Frames gelöst werden können, warum dann der Einsatz dieser Technik dir so wichtig erscheint?

Ich hinterfrage *prinzipiell* alle Dinge (ja, auch Frames) und klopfe Argumente auf Stichhaltigkeit ab. Auch schalte ich *prinzipiell* lieber meinen eigenen Verstand ein, als daß ich mich von "vorgefertigen Weisheiten" in irgendeiner Form beeindrucken lasse.

Es geht nicht um beeindrucken, sondern darum das diese Technik gegenüber einer anderen einfach Nachteile hat.

Die Technik haben viele schon hinterfragt und natürlich habe ich auch lange Zeit Frames verwendet, Meine Erfahrung zeigt mir das es nur Vorteile bringt darauf zu verzichten, wenn es für dich persönlich anders ist meinetwegen, dann hast du vieleicht noch nicht oft genug Seiten ohne Frames gemacht, ansonsten wären dir die Nachteile mit Sicherheit auch schon aufgefallen
Wie übrigens vielen anderen auch, gerade Portal Seiten waren vor 6/7 Jahren noch überwiegend als Frameset konzipiert und du glaubst die machen das alle nur wegen Dumm Argumenten?

Daß Du nicht anders kannst, als stets die schon lange durchgenudelten Dumm-"Argumente" aufzuzählen (wenn auch diesmal in englischer Sprache), macht das ganze eben so unterhaltsam. Und ohne Amüsement macht das Posten ja auch mir keinen Spaß ... :-)

Na dann.
Nur, hast du bisher nicht einziges Argument gebracht. Du behauptest die ganze Zeit dieses oder jenes durch den geschickten Einsatz der Technik zu beheben. Nur ist dies weder auf deiner Seite irgendwo eingebaut noch hast du dies hier gezeigt. Ich gehe also davon aus dass du lediglich irgendwas aufzählst wovon du vermutest das es geht.

Struppi.

[Cybaer]

Hi,

Oh, daß Bugs im Scripting Sicherheitslöcher bieten, ist mir durchaus bewußt. Deswegen wird ja auch oft empfohlen das Scripting zu deaktivieren. :-)
Und wieder eines deiner tollen Argumente.

Ja, nicht wahr?

Vermutlich stand deswegen in "deiner" Liste auch "* There are security problems caused by the fact that it is not visible to the user when different frames come from different sources." (man beachte das "visible" und *nicht* "* JavaScript my be dangerous - also within frames". :->

Nochmals: es ging lediglich um einen Nachteil.

Nochmals: Wenn dein Browser Bugs beim Cross-Site-Scripting hat, mußt Du updaten oder Scripting deaktivieren. Der Verzicht auf Frames ist Augenwischerei - eine solche Empfehlung bestenfalls fahrlässig.

Außerdem hast du nicht die ganze Zeit behauptet, das man die anderen Nachteile mit u.a. JS beseitigen kann? Nur wie soll das Funktioneren wenn ich es deaktieren muss?

Nein. *Du* hast behauptet, man könne die "Nachteile" die in "deiner" Liste aufgeführt waren nicht mit HTML beheben. Ich habe gesagt, daß das im in fast allen Fällen sehr wohl nur mit HTML ginge - ich aber ohnehin auch andere Techniken nehme, egal ob bei Frames oder nicht.

Konkret: Aus "deiner" Liste ist exakt nur *ein* "Nachteil" nur mit JavaScript zu "beheben":

* [page up] and [page down] are often hard to do.

Nämlich indem man den Content-Frame fokussiert.

Dies ist aber (wenn überhaupt) eine Sache des Komforts (mithin verzichtbar)! Ohne dies, bleibt ja nicht nur die Maussteuerung, es bleibt dem User auch nach wie vor die Option, den Content-Frame mittels TAB zu fokussieren - jedenfalls wenn man seinen Browser überhaupt (mit Tastatur) bedienen kann ...

Was wir haben ist also, daß Du Dinge als gesagt behauptest, die dir in den Kram passen, obwohl ein paar Beiträge vorher dies nicht so gesagt wurde.

Cool, das ist nun IIRC das dritte Mal, daß Du auf diese Art rumtrollst. Ich muß mal zukünftig wirklich sehen, daß ich dich abwatsche, ohne daß das so epische Züge annimmt ... :->

Wobei sich mir aber die Frage stellt, wenn es Nachteile gibt, die mit viel Ahnung der Technik behoben werden können, aber gleichzeitig einfach durch den Verzicht von Frames gelöst werden können, warum dann der Einsatz dieser Technik dir so wichtig erscheint?

Du hast in diesen "Diskussionen" u.a. einen schwerwiegenden Fehler:

*Du* möchtest Leute "bekehren", in dem Du Pseudoargumente aus der Mottenkiste hervorholst, die zu zerpflücken ein Leichtes ist. Ich hingegen "bekehre" hier niemanden, laufe nicht rum und versuche alle zur Verwendung von Frames zu überreden, indem ich die wahnwitzigsten Argumente an den Haaren herbeiziehe! :-))

Wie übrigens vielen anderen auch, gerade Portal Seiten waren vor 6/7 Jahren noch überwiegend als Frameset konzipiert und du glaubst die machen das alle nur wegen Dumm Argumenten?

Es ist mir egal, was warum andere machen. Es ist mir auch egal, wenn andere Techniken nicht hinreichend beherrschen (es veranlaßt mich höchstens zum Schmunzeln). Was mir weniger egal ist, ist die Angewohnheit mancher, dummes Zeug zu posten, in der Hoffnung, es würde sicherlich geglaubt. >:->

Ich gehe also davon aus dass du lediglich irgendwas aufzählst wovon du vermutest das es geht.

Ob Du was vermutes, oder in China fällt 'n Sack Reis um, hat so ziemlich die gleiche Relevanz. :-))

Wenn Du aus meinen Aufzählungen (die ja bereits hinlänglich bekannt sind: http://forum.de.selfhtml.org/archiv/2004/8/88076/#m526351) schließt, daß das alles so wahnsinnig kompliziert ist und nur in meinen theoretischen Phantastereien existiert, dann ist das echt und einzig *dein* ureigenes "Problem". Aber man lernt ja nie aus - gib die Hoffnung also nicht auf! ;->

Gruß, Cybaer (EOT - mal wieder :))

[wahsaga]

hi,

und denen läßt sich mit Hilfe von Frames durchaus etwas anderes unterjubeln als sie glauben zu sehen.

Stimmt. Es ist ja auch sehr wahrscheinlich, daß z.B. die Postbank in einem Frameset mit ihrem seriösen URL einen Frame von irgendeinem obskuren Phisher versteckt.

du kennst bspw. http://www.heise.de/security/news/meldung/60297?

gruß,
wahsaga

[Cybaer]

Hi,

du kennst bspw. http://www.heise.de/security/news/meldung/60297?

Du meinst vor allen Dingen "Eigentlich sollte der Browser sicherstellen, dass parallel angezeigte Web-Seiten sich nicht gegenseitig manipulieren können, wenn sie aus unterschiedlichen Domains stammen"?

Was auch ohne Frames gegeben ist, wenn das Scripting unsicher ist?

Gruß, Cybaer

[CurtB]

Hi,

Doch es geht! Du kannst sehr gut mit CSS Inhalt und Layout trennen. Der Klassiker der dir das zeigt ist http://www.csszengarden.com/.
Aber wenn du ein Layout hast, dass eine Tabellenstruktur hat, wirst du eine Tabelle nicht ersetzen können das stimmt.

Beide Beispiele belegen doch wie wenig leistungsfähig CSS ist! Csszengarden zeigt nicht nur einige Möglichkeiten von CSS, es ist zugleich auch ein Armutszeugnis für das zugrundeliegende Konzept von CSS:

<div id="r">
<div id="i">
  <div id="pageHeader">
   <h1><span>..</span></h1>
   </div>
<div id="quickSummary">
   <p class="p1"><span>..

Ein funktionsfähiges und mächtiges CSS hätte es wohl kaum nötig den Quellcode derartig mit Hilfscontainern div und span aufzublähen.

Gruß
CurtB

[Ashura]

puts "Hallo " + gets.chomp + "."

?> CurtB
=> Hallo CurtB.

Beide Beispiele belegen doch wie wenig leistungsfähig CSS ist!

Du hast es nicht verstanden...

Csszengarden zeigt nicht nur einige Möglichkeiten von CSS, es ist zugleich auch ein Armutszeugnis für das zugrundeliegende Konzept von CSS:
[...]

Ein funktionsfähiges und mächtiges CSS hätte es wohl kaum nötig den Quellcode derartig mit Hilfscontainern div und span aufzublähen.

Es geht beim CSSZenGarden nicht um sinnvolle Struktur, sondern um die Präsentation möglichst vieler Möglichkeiten, die CSS bietet. Ob und inwieweit sich diese dann auf sinnvoll strukturierten Seiten umsetzen lassen, obliegt dem Autor.

Einen schönen Samstag noch.

Gruß, Ashura

[CurtB]

Hi,

Es geht beim CSSZenGarden nicht um sinnvolle Struktur, sondern um die Präsentation möglichst vieler Möglichkeiten, die CSS bietet. Ob und inwieweit sich diese dann auf sinnvoll strukturierten Seiten umsetzen lassen, obliegt dem Autor.

Darum ging es gar nicht, zumal Div und Span kaum Struktur darstellen. Es ging im Posting nicht um die Spielereien bei csszengarden sondern um die Trennung von Layout und Inhalt, die angeblich von csszengarden vorgeführt wurde.
Ein funktionsfähiges und mächtiges CSS hätte es aber wohl kaum nötig den Quellcode derartig mit Hilfscontainern div und span aufzublähen. Also erfordert das nicht so leistungsfähige CSS die Vorgehensweise jedes Blockelement in mindestens zwei Container zu stecken und jeden Inhalt mit einem span zu umgeben, eine einfache flexibel ansprechbare Lösung, aber unschön mit hohem Verwaltungsaufwand und ein Beleg für die Mängel bei CSS.

Gruß
CurtB

[at]

Hallo.

Ein funktionsfähiges und mächtiges CSS hätte es aber wohl kaum nötig den Quellcode derartig mit Hilfscontainern div und span aufzublähen.

Du verstehst es leider noch immer nicht.

Also erfordert das nicht so leistungsfähige CSS die Vorgehensweise jedes Blockelement in mindestens zwei Container zu stecken und jeden Inhalt mit einem span zu umgeben, eine einfache flexibel ansprechbare Lösung, aber unschön mit hohem Verwaltungsaufwand und ein Beleg für die Mängel bei CSS.

Wir haben mittlerweile verstanden, dass du das Konzept des CSS Zen Garden nicht verstehst. Möchtest du auch darüber hinaus etwas aussagen?
MfG, at

[Ingo Turski]

Hi,

Es ging im Posting nicht um die Spielereien bei csszengarden sondern um die Trennung von Layout und Inhalt, die angeblich von csszengarden vorgeführt wurde.

nicht nur angeblich. Deaktiviere mal CSS und sieh' Dir die Seite an - purer Inhalt mit sinnvoller Struktur. Die ganzen DIVs und SPANs ändern daran ja wie schon von Dir gesagt nichts.

Ein funktionsfähiges und mächtiges CSS hätte es aber wohl kaum nötig den Quellcode derartig mit Hilfscontainern div und span aufzublähen.

Da gebe ich Dir zumindest teilweise Recht. Die meisten SPANs wären überflüssig, wenn man auch Textknoten mit CSS ansprechen könnte. Auch wenn das nicht in das Konzept von CSS paßt, fände ich ein Pseudoelement 'text' recht sinnvoll.

Bei den DIVs sieht es etwas anders aus. Sie dienen größtenteils der Gruppierung von Elementen und sind - um eben größtmögliche Flexibilität zu erreichen - in dieser Beziehung nötig. Natürlich wird nicht jeder Autor jedes DIV benötigen und im Normalfall müssen auch längst nicht alle Elemente gruppiert werden.
Einige DIVs sind aber in der Tat überflüssig, z.B. das von Dir zitierte:

<div id="pageHeader">
   <h1><span>..</span></h1>
</div>

h1 dürfte nur einmal vorkommen und gruppiert wird hier absolut nichts. Und nur für extreme Sonderwünsche wie z.B. dreifache border oder backgrounds finde ich dieses DIV reichlich übertrieben.

Abschließend sei noch erwähnt, daß nicht wenige DIVs entbehrlich wären, wenn von einer vollständigen Unterstützung von CSS 2.1 oder gar CSS 3 ausgegangen werden könnte.

freundliche Grüße
Ingo

[Cybaer]

Hi,

Ein funktionsfähiges und mächtiges CSS hätte es aber wohl kaum nötig den Quellcode derartig mit Hilfscontainern div und span aufzublähen.

In der realen Anwendung ist das auch kaum notwendig (*nicht* "gar nicht notwendig" ;-)).

Aber so ist es halt bei strukturierten Sprachen: Oft setzt man klammernde Tags, die eigentlich nicht gebraucht werden - außer eben zum Klammern. Daß HTML da lockerer rangeht, liegt an HTML, seiner Entstehung, seinem ursprünglichen Zweck.

Bei der "Mutter" XML wie auch der "Großmutter" SGML bzw. ist das deswegen deutlicher zu sehen - und ganz normal. Jeder mit einem Faible für Mathematik, liebt das - zurecht. ;-))

aber unschön mit hohem Verwaltungsaufwand und ein Beleg für die Mängel bei CSS.

Man kann CSS ja einiges vorwerfen - in Theorie und Praxis -, dies jedoch IMHO keineswegs.

Gruß, Cybaer

[Auge]

Hallo

Bei der "Mutter" XML wie auch der "Großmutter" SGML

Wohl eher Mutter SGML und Tante XML :-)

Tschö, Auge

[Ashura]

puts "Hallo " + gets.chomp + "."

?> Auge
=> Hallo Auge.

Bei der "Mutter" XML wie auch der "Großmutter" SGML

Wohl eher Mutter SGML und Tante XML :-)

Hm... Ich tendiere eher zu Mutter SGML und Halbschwester XML.

Einen schönen Montag noch.

Gruß, Ashura

[Auge]

Hallo

Bei der "Mutter" XML wie auch der "Großmutter" SGML

Wohl eher Mutter SGML und Tante XML :-)

Hm... Ich tendiere eher zu Mutter SGML und Halbschwester XML.

Davon ausgehend, dass XML die vereinfachte/entschlackte "Version" von SGML ist [1], halte ich XML für die kleine Schwester von SGML, die somit die Tante von HTML wäre. Nach der Logik wäre XHTML die Cousine (der Cousin?) von HTML. :-)

[1] man möge mich bei Irrtum korrigieren

Tschö, Auge

PS: Liegt es im Bereich des Möglichen, dass wir abschweifen? ;-)

[at]

Hallo.

PS: Liegt es im Bereich des Möglichen, dass wir abschweifen? ;-)

Im Hinblick auf "entfernte Verwandtschaft" ist vielleicht "abtreiben" das besser passende Wort.
MfG, at

[Cybaer]

Hi,

Im Hinblick auf "entfernte Verwandtschaft" ist vielleicht "abtreiben" das besser passende Wort.

<fluch typ="derb">Heilige Inzucht!</fluch>

Gruß, Cybaer

[Ashura]

puts "Hallo " + gets.chomp + "."

?> Auge
=> Hallo Auge.

Davon ausgehend, dass XML die vereinfachte/entschlackte "Version" von SGML ist [1], halte ich XML für die kleine Schwester von SGML, die somit die Tante von HTML wäre. Nach der Logik wäre XHTML die Cousine (der Cousin?) von HTML. :-)

[1] man möge mich bei Irrtum korrigieren

Ich habe da mal den Familienstammbaum ausgegraben:

Quelle: XML in der Praxis - Einführung

XML als die kleine Schwester von SGML zu bezeichnen, empfinde ich nicht als treffend, da XML eine Teilmenge von SGML ist.

Den Rest sieht man ja selbst. ;-)

PS: Liegt es im Bereich des Möglichen, dass wir abschweifen? ;-)

Ach was.

Einen schönen Dienstag noch.

Gruß, Ashura

[MudGuard]

Hi,

Bei der "Mutter" XML wie auch der "Großmutter" SGML

Wohl eher Mutter SGML und Tante XML :-)

Hm... Ich tendiere eher zu Mutter SGML und Halbschwester XML.

XML ist eine SGML-Sprache. XML ist Kind von SGML.
XHTML ist eine XML-Sprache. XHTML ist Kind von XML und Enkel von SGML.
HTML ist eine SGML-Sprache, HTML ist Kind von SGML.

Der m.E. hier relevante Teil des Stammbaums:

SGML
           |
+---------+-------+--...
|         |       |
HTML      XML      ...
           |
      +----+---...
      |    |
    XHTML  ...

HTML ist demnach Tante/Onkel von XHTML. Vermutlich hat XHTML als kleines Kind bei Tante/Onkel HTML gelebt, denn XHTML ist stark von HTML beeinflußt ;-)

cu,
Andreas

[Ashura]

puts "Hallo " + gets.chomp + "."

?> MudGuard
=> Hallo MudGuard.

HTML ist demnach Tante/Onkel von XHTML. Vermutlich hat XHTML als kleines Kind bei Tante/Onkel HTML gelebt, denn XHTML ist stark von HTML beeinflußt ;-)

Großmutter / -vater SGML ist aber immer leider viel zu groß gewesen, weshalb sie / er bis heute nicht aus dem Hause gekommen ist. Sie / er lässt nur immer mehr Kinder / Enkel auf die Welt los. ;-)

Einen schönen Dienstag noch.

Gruß, Ashura

[Cybaer]

Hi,

Großmutter / -vater SGML ist aber immer leider viel zu groß gewesen, weshalb sie / er bis heute nicht aus dem Hause gekommen ist.

Das erscheint dir nur so. Vermutlich treibst Du dich nur in irgendwelchen Amüsiervierteln rum, die von der anständigen SGML-Großmutter gemieden werden, wo dir aber leichte HTML-Mädchen unanständige Sachen ins Ohr flüstern ("Ich mach's auch ohne DTD!", "Hast Du Lust auf'n Quickie? Brauchst auch deine Tags nicht zu schließen!", "Bock auf 'n echtes <b></i></b>-Sandwich?"). ;-)

Gruß, Cybaer

[Auge]

Hallo

Großmutter / -vater SGML ist aber immer leider viel zu groß gewesen, weshalb sie / er bis heute nicht aus dem Hause gekommen ist. Sie / er lässt nur immer mehr Kinder / Enkel auf die Welt los. ;-)

Tja, manche Leute haben halt keine Hobbies. ;-)

Tschö, Auge

[Auge]

Hallo

Bei der "Mutter" XML wie auch der "Großmutter" SGML

Wohl eher Mutter SGML und Tante XML :-)

Hm... Ich tendiere eher zu Mutter SGML und Halbschwester XML.

XML ist eine SGML-Sprache. XML ist Kind von SGML.

Da XML aber sowohl direkte Teilmenge von SGML, als auch funktionell vergleichbar ist, _könnte_ man das auch so auslegen[1]:

Wie das Klonschaf namens Dolly ist auch XML ein Klon, und zwar der von SGML. Mit all den (hier gewollt) verlorenen Informationen[2].

[1] Ich mach das mal, um irgendwelche Argumente für meine Theorie zu postulieren, auch wenn sie noch so krude sind. ;-)

[2] Nach der großen Euphorie, "Hurra, wir sind Gott!", stellte sich heraus, dass das Erbmaterial des Klonschafes alle Fehler seiner "Mutter" enthielt. Jedes Lebewesen verliert bei Zellteilungen kleine Teile seiner DNS. Dolly war also schon bei seiner Geburt biologisch so alt wie seine "Mutter".

Irgendwie (positiv betrachtet) trifft dies auch auf XML zu, da heir überflüssiger Ballast über Bord geworfen wurde.

Tschö, Auge

[CurtB]

Hi.

Aber so ist es halt bei strukturierten Sprachen: Oft setzt man klammernde Tags, die eigentlich nicht gebraucht werden - außer eben zum Klammern. Daß HTML da lockerer rangeht, liegt an HTML, seiner Entstehung, seinem ursprünglichen Zweck.

Wenn CSS als Zusatz die Trennung von Form und Inhalt ermöglichen soll kommen wir wieder bei CSS an ausser diese Trennung würde rein statisch verstanden und sowieso nicht als Trennung der Verwaltungen. Oder CSS würde darauf reduziert Layouttabellen zu ersetzen statt Layoutwerkzeug zu sein.

aber unschön mit hohem Verwaltungsaufwand und ein Beleg für die Mängel bei CSS.

Man kann CSS ja einiges vorwerfen - in Theorie und Praxis -, dies jedoch IMHO keineswegs.

Die Unfähigkeiten und Bugs älterer Browser können allerdings kaum CSS angelastet werden. Die Behauptung hier im Thread "Du kannst sehr gut mit CSS Inhalt und Layout trennen. Der Klassiker der dir das zeigt ist http://www.csszengarden.com/." meint aber auch schon mit das Gesamptpaket CSS, HTML und Browser und schränkt auch bereits ein "Aber wenn du ein Layout hast, dass eine Tabellenstruktur hat, wirst du eine Tabelle nicht ersetzen können das stimmt."

Gruß
CurtB

[at]

Hallo.

Wenn CSS als Zusatz die Trennung von Form und Inhalt ermöglichen soll kommen wir wieder bei CSS an ausser diese Trennung würde rein statisch verstanden und sowieso nicht als Trennung der Verwaltungen. Oder CSS würde darauf reduziert Layouttabellen zu ersetzen statt Layoutwerkzeug zu sein.

Könntest du das näher erläutern -- gern auch mit ein paar Kommata?

aber unschön mit hohem Verwaltungsaufwand und ein Beleg für die Mängel bei CSS.

Man kann CSS ja einiges vorwerfen - in Theorie und Praxis -, dies jedoch IMHO keineswegs.

Die Unfähigkeiten und Bugs älterer Browser können allerdings kaum CSS angelastet werden.

Eben, darum ging es ja bei den Einwänden auf deine Pauschalkritik an CSS.

Die Behauptung hier im Thread "Du kannst sehr gut mit CSS Inhalt und Layout trennen. Der Klassiker der dir das zeigt ist http://www.csszengarden.com/." meint aber auch schon mit das Gesamptpaket CSS, HTML und Browser und schränkt auch bereits ein "Aber wenn du ein Layout hast, dass eine Tabellenstruktur hat, wirst du eine Tabelle nicht ersetzen können das stimmt."

Eine Tabellen_struktur_ zu ersetzen, ist mittels CSS prinzipbedingt nicht möglich und wird es wohl niemals werden, denn die Struktur wird ja in HTML beschrieben. Wenn es aber darum geht, das Aussehen einer Tabelle zu imitieren, so stellt CSS hierzu weitreichende Techniken zur Verfügung, die lediglich von einigen Browsern noch nicht korrekt angewandt werden.
MfG, at

[Orlando]

Hallo CurtB,

http://www.csszengarden.com/.

Beide Beispiele belegen doch wie wenig leistungsfähig CSS ist!

Das einerseits (CSS 2/2.1) und andererseits, wie wenig leistungsfähig aktuelle Browser sind.

<div id="r">
<div id="i">
  <div id="pageHeader">
   <h1><span>..</span></h1>
   </div>
<div id="quickSummary">
   <p class="p1"><span>..

Ja, das *ist* ein miserabler Quelltext. Alleine, er ist miserablen Browsern und noch nicht weit genug gediehenen Standards geschuldet.

Ein funktionsfähiges und mächtiges CSS hätte es wohl kaum nötig den Quellcode derartig mit Hilfscontainern div und span aufzublähen.

Korrekt, siehe CSS3-Selektoren.

Grüße
Roland

[Ashura]

puts "Hallo " + gets.chomp + "."

?> Orlando
=> Hallo Orlando.

Ein funktionsfähiges und mächtiges CSS hätte es wohl kaum nötig den Quellcode derartig mit Hilfscontainern div und span aufzublähen.

Korrekt, siehe CSS3-Selektoren.

Die CSS2-Selektoren würden ja auch jetzt schon (zumeist) völlig reichen, wenn da nicht so ein blauer e-Klotz am Bein des Webfortschrittes hängen würde...

Einen schönen Mittwoch noch.

Gruß, Ashura

[Cyx23]

Hallo Roland,

Ja, das *ist* ein miserabler Quelltext. Alleine, er ist miserablen Browsern und noch nicht weit genug gediehenen Standards geschuldet.

es ist doch schon ein Mangel der ganzen Geschichte wenn es erst mit der Ablösung von IE 6, womöglich
auch IE 7, real anwendbar sein mag.

Ansonsten ist die Frage was die von dir erwähnten CSS3-Selektoren bei überhaupt geeigneten
Browsern leisten; führt die Ansprechbarkeit von Textknoten usw. dazu dass ich wirklich einer
Textspalte direkt komplexe Eigenschaften zuweisen kann, Eigenschaften wie Abstände,
Hintergründe unabhängig von Abständen oder mit eigenen Abständen usw., und wann wäre es soweit,
2010, 2015?

Grüsse

Cyx23

[at]

Hallo.
Dann bastle doch einen eigenen Standard und den Browser gleich dazu und bringe beides unter die Leute. Ich befasse mich derweil mit CSS.
MfG, at

[Orlando]

Hallo Kristof,

Ja, das *ist* ein miserabler Quelltext. Alleine, er ist miserablen Browsern und noch nicht weit genug gediehenen Standards geschuldet.

es ist doch schon ein Mangel der ganzen Geschichte wenn es erst mit der Ablösung von IE 6, womöglich
auch IE 7, real anwendbar sein mag.

Das ist kein Mangel, den CSS bzw. das W3C selbst verschuldet hat. Schließlich wäre CSS3 (bzw. das meiste davon) schon Standard, gäbe es zwei funktionierende Implementierungen.

Ansonsten ist die Frage was die von dir erwähnten CSS3-Selektoren bei überhaupt geeigneten
Browsern leisten;

nth-child und Konsorten sparen bestimmt eine Menge überflüssige Klassen und divs. Schade, dass man damit noch nicht basteln kann.

und wann wäre es soweit, 2010, 2015?

Immerhin. Ob wir dann wohl immer noch über veraltete Browser diskutieren werden? ;-)

Grüße
Roland

[Struppi]

In zurückliegenden Zeiten wurden für technische Dokumente ....

Das ist z.b. ein guter Grund um Frames zu verwenden. Bei Diskussionen um das Thema wird immer wieder gesagt, das es durchaus sinnvolle Anwendungen für Frames gibt und du hast eine.

Auch der Hinweis darauf, Javascript zu vermeiden, weil es gute Gründe gegen die Verwendung von Javascript geben würde, wobei die Kritiker jedes mal die Begründung der angeblich gute Gründe schuldig bleiben, ist für mich sehr weit hergeholt. ....

Es gibt gute Gründe die nicht weit hergeholt sind. Aber natürlich nicht bei dem von dir beschriebenen Projekt, aber ansonsten schon:

* jeder der mit einem IE surft sollte sich zumindest Gedanken machen ob er die Ausführung von JS (aktiven Inahlten) nicht einschränken sollte. Durch die Verzahnung von IE und System sind die Löcher (die es z.T. noch gibt) so gravierend, dass du nie sicher bist.
* Suchmaschinen können kein JS - dies betrifft dich aber natürlich nur, wenn deine Seite gefunden werden soll
* viele gut gemeinte Skripte sind so lästig (z.b. "Fenstergrößenoptimierung") dass viele Browser von Haus aus JS mittlerweile einschränken.
* JS ist definitiv mehrarbeit oftmals mit zweifelhaften nutzen.
* wenn ohne JS die Benutzbarkeit nicht mehr vorhanden ist, sperrt man Besucher aus. Ob man sich das leisten mag muss jeder selber entscheiden.

Dies Gründe sprechen nicht gegen den generellen Einsatz von JS, aber man sollte sich sehr genau überlegen was man tut und für wen.

Das WWW mit seiner Technik ist IMHO keine ausschließliche Spielwiese für WWW-Designer, sondern es muß zugelassen werden, die Technik auch in anderen Kontexten einzusetzen. Es gibt für das WWW nicht nur einen Kontext. Die Gestaltung einer technischen Dokumentation mit der Webtechnik ist ein ernst zunehmendes Thema und es wäre schade, wenn wegen einseitiger Sichtweisen die Elemente, die bisher ihre guten Dienste tun, aus dem Standard verschwinden würden. Das Framesets bisher nur als transitional eingestuft sind, halte ich für bedenklich. ...

Ich bin kein w3c Fachmann aber es gibt durchaus Überlegungen und Entwicklungen mit Frames (ich hab grad mal kurz gegoogled http://www.w3.org/TR/xframes/) . Es ist in keinster weise so dogmatisch wie du es empfindest. Die Diskussionen betreffen lediglich 08/15 Seiten, wo tatsächlich der Einsatz von Frames stark abgenommen hat - es gibt mittlerweile kaum noch grosse Portale oder stark besuchte Seiten die auf Frames aufbauen.

Der Fortentwicklung der Technik kann nur dann sinnvoll sein, wenn sie die mögliche Vielfalt nicht ausschließt. Es wird IMHO aber nie möglich sein, eine Webpages im Sinne eine eierlegenden Wollmilchsau für alle Plattformen erstellen zu können. Man wird sich Gedanken machen müssen, wie man Minderheiten besser versorgt und technische Möglichkeiten errichtet, die diesen speziellen Zwecken dienen. Das ist IMHO besser, als den kleinsten gemeinsamen Nenner zu suchen, wobei andere sinnvolle Techniken aufgegeben werden.

Das Internet muss immer der kleinste gemeinsame Nenner sein, da die Vielfalt sowohl an Browser, als auch Betriebsystemen oder z.b. auch Sprachen, eine einseitige Fortentwicklung von propietären Techniken sowieso verhindert. Ohne Standards wäre der Fortschritt gar nicht möglich. (was man ja z.b. auch in der Browserentwicklung sieht, der Browser, der lange Zeit auf propietäre Techniken setzte ist mittlerweile der Rückständigste)

Struppi.

[pixxma]

Hallo,
guter Beitrag. Nicht nur Frames, sondern auch Tabellen als Layoutmittel werden im Forum gerne niedergemacht. Neben den erwähnten Aspekten sollte man es doch auch dem "Seitenmacher" selbst überlassen, welche Mittel er benutzt. Anders formuliert: welchen Stil er pflegt. Ob man Webseitengestaltung als "Kunst" oder 'nur' als "Handwerk" betrachtet, ist ja egal, aber auf jeden Fall ist es eine kreative Tätigkeit, bei der jeder, der die Tätigkeit ausübt, seine eigene Methode entwickeln muß.
Obwohl ich Frames auch nicht besonders mag (ich arbeite gerne & gut mit Tabellenlayouting), sehe ich Frames, Tabellen und CSS-Ebenen als drei gleichwertige Methoden an.
pixxma

[Struppi]

guter Beitrag. Nicht nur Frames, sondern auch Tabellen als Layoutmittel werden im Forum gerne niedergemacht. ...

Niedergemacht?
Tabellen als Layoutmittel haben gegenüber CSS fast nur Nachteile. Wer das nicht erkennt mag gerne weiter Künstler sein, ist aber techn. auf einem niedrigen Niveau und da wir ihr uns in einem Technik Forum bewegen ist die Kritik daran nicht verwunderlich.

Es spricht ja nichts dagegen, dass sich derjenige, dem sich die Vorteile von CSS nicht erschliessen, Tabellen nutzt um Inhalte anzuordnen, aber deshalb sind sie nicht gleichwertig.

Obwohl ich Frames auch nicht besonders mag (ich arbeite gerne & gut mit Tabellenlayouting), sehe ich Frames, Tabellen und CSS-Ebenen als drei gleichwertige Methoden an.

Die drei Techniken haben nichts miteinander zu tun, jede hat ihr Einsaztgebiet und ihren Sinn, aber wer sie mit einander vermischt kann mit Ihnen nicht umgehen.

Struppi.

[fireeye]

Hi Struppi

Tabellen als Layoutmittel haben gegenüber CSS fast nur Nachteile. Wer das nicht erkennt mag gerne weiter Künstler sein, ist aber techn. auf einem niedrigen Niveau und da wir ihr uns in einem Technik Forum bewegen ist die Kritik daran nicht verwunderlich.

<table> sollte wirklich nur zum Zweck der Darstellung einer Tabelle verwendet werden, CSS ist zur Gestaltung des Layouts weitaus flexibler. Gelegentlich verwende ich aber <table> als Workaround, weil FF auf dem Mac keine Liste neben einem float:left richtig darstellen kann, das ist aber bei mir die einzige Zweckentfremdung...

Mit meinem Beitrag wollte ich auf die verschiedensten Anwendungsmöglichkeiten einer Webpage hinweisen, eben Webpages die nicht spezifisch für Websurfer gemacht werden, sondern die sich an eine Zielgruppe richten, die sich per Definition von dem "gemeinem" Websurfer abhebt und hier die angebliche Barrierefreiheit nicht so sehr im Vordergrund steht. Ich habe soeben eine Webseite besucht ein gutes Beispiel für Barrieren, das würde ich meiner Zielgruppe nicht zumuten wollen...

Gruß f

[Struppi]

Mit meinem Beitrag wollte ich auf die verschiedensten Anwendungsmöglichkeiten einer Webpage hinweisen, eben Webpages die nicht spezifisch für Websurfer gemacht werden, sondern die sich an eine Zielgruppe richten, die sich per Definition von dem "gemeinem" Websurfer abhebt und hier die angebliche Barrierefreiheit nicht so sehr im Vordergrund steht. ...

Naja, dann ist der Titel deines Threads unglücklich gewählt. Wie gesagt, in den Diskussionen um Frames geht es eben genau um Wepage für Websurfer, aber es wird i.d.R. immer darauf hingewiesen dass Frames durchaus Sinn machen können (wobei ich die Bemerkung, von molily, das 1300 Links nicht unbedingt sinnvoll und eine durchdachte Struktur (ohne Frames) wahrscheinlich der bessere Weg ist).

Zumal deine Argumente (sofern es welche gab) ja teilweise nicht mal stimmen, z.b. werden Frames eben nicht abgeschafft.

Struppi.

[fireeye]

Hi Struppi

...wobei ich die Bemerkung, von molily, das 1300 Links nicht unbedingt sinnvoll und eine durchdachte Struktur (ohne Frames) wahrscheinlich der bessere Weg ist).

»»
Das hatte ich ja hier auch nicht näher ausgeführt. Ohne Hierachie wäre das sicher ein Chaos. Stimme ich zu. Mein Navigation ist hierachisch aufgebaut und kommt bei den Usern gut an.

Zumal deine Argumente (sofern es welche gab) ja teilweise nicht mal stimmen, z.b. werden Frames eben nicht abgeschafft.

»»
Ich bin auf diese Seite, die so argumentiert über Wikipedia dort hingeraten, stammt nicht von mir. Aber eben drum, mir hat das, was ich dort zu lesen bekam, doch nachdenklich gestimmt.

Gruß f

[Struppi]

...wobei ich die Bemerkung, von molily, das 1300 Links nicht unbedingt sinnvoll und eine durchdachte Struktur (ohne Frames) wahrscheinlich der bessere Weg ist).
»»
Das hatte ich ja hier auch nicht näher ausgeführt. Ohne Hierachie wäre das sicher ein Chaos. Stimme ich zu. Mein Navigation ist hierachisch aufgebaut und kommt bei den Usern gut an.

und also durchaus auch ohne Frames machbar?

Zumal deine Argumente (sofern es welche gab) ja teilweise nicht mal stimmen, z.b. werden Frames eben nicht abgeschafft.
»»
Ich bin auf diese Seite, die so argumentiert über Wikipedia dort hingeraten, stammt nicht von mir. Aber eben drum, mir hat das, was ich dort zu lesen bekam, doch nachdenklich gestimmt.

Ich hab eben mir die Links vom Wickpedia Artikel angeschaut und ich kann keine Hinweis finden das Frames abgeschafft werden, im gegenteil in dem einen werden ausdrücklich xFrames erwähnt.

Struppi.

[fireeye]

Hi Struppi

Ich hab eben mir die Links vom Wickpedia Artikel angeschaut und ich kann keine Hinweis finden das Frames abgeschafft werden, im gegenteil in dem einen werden ausdrücklich xFrames erwähnt.

Zitat: Quelle
Frames verletzen Grundsätze des World Wide Web

Ein Dokument - Eine Adresse. Jedes Dokument sollte unter einer eindeutigen Adresse zu finden sein. Der Sinn ist klar: Informationen sollen leicht und eindeutig zu finden sein. Bei Frames sind die Inhalte meistens über mehrere Frames verteilt. Dazu kommt, dass man nur auf die Startseite des Framesets verlinken kann, aber nicht auf die Unterseiten. Lediglich auf ein einzelnes Frame kann verlinkt werden; dadurch wird aber nicht die gesamte Webseite angezeigt.

Alleine wegen dieser beiden Gründe sollten Frames schon aus dem Web verschwinden. Ein solch komplexes System wie das World Wide Web kann nur funktionieren, wenn bestimmte Regeln eingehalten werden. Frames sind nur noch im HTML Standard "Transitional" enthalten, in den strikten Versionen sind Frames gar nicht mehr vorhanden.
In neueren Standards sind sie bereits ersetzt, worauf hier später eingegangen wird.

Zitatende.

So liest es sich, daß es Befürworte gibt, die Frames nicht mögen....

Gruß f

[Struppi]

Alleine wegen dieser beiden Gründe sollten Frames schon aus dem Web verschwinden. Ein solch komplexes System wie das World Wide Web kann nur funktionieren, wenn bestimmte Regeln eingehalten werden. Frames sind nur noch im HTML Standard "Transitional" enthalten, in den strikten Versionen sind Frames gar nicht mehr vorhanden.
In neueren Standards sind sie bereits ersetzt, worauf hier später eingegangen wird.

Zitatende.

So liest es sich, daß es Befürworte gibt, die Frames nicht mögen....

Ja und?
Da steht genau das Gegenteil von dem was du die ganze Zeit behauptest.
das es für Frames Ersatz gibt und nicht dass sie abgeschafft werden.

Struppi.

[fireeye]

Hi Struppi

So liest es sich, daß es Befürworte gibt, die Frames nicht mögen....

Ja und?
Da steht genau das Gegenteil von dem was du die ganze Zeit behauptest.
das es für Frames Ersatz gibt und nicht dass sie abgeschafft werden.

Ich laß das mal so stehen. Ich melde dazu wieder, wenn ich XFRAMES studiert habe, aber nicht jetzt. Ich geh vorher zum Sommerfest bei herrlichem Sonnenschein.

Schönes WE

Gruß f

[molily]

Hallo,

Neben den erwähnten Aspekten sollte man es doch auch dem "Seitenmacher" selbst überlassen, welche Mittel er benutzt. Anders formuliert: welchen Stil er pflegt. Ob man Webseitengestaltung als "Kunst" oder 'nur' als "Handwerk" betrachtet, ist ja egal, aber auf jeden Fall ist es eine kreative Tätigkeit, bei der jeder, der die Tätigkeit ausübt, seine eigene Methode entwickeln muß.

Den Künstler möchte ich sehen, der in der Wahl seiner Gestaltungsmittel volllkommen zweckfrei vorgeht. Auch der Künstler wird, vielleicht noch hochgeistiger als der Handwerker, seine Mittel so wählen, dass sie seiner Intention am besten zuträglich sind. Sind denn Tabellen ästhetischer und individueller, oder was meinst du mit »eigene Methode«?

Mathias

[Daniel]

Hi,

Den Künstler möchte ich sehen, der in der Wahl seiner Gestaltungsmittel volllkommen zweckfrei vorgeht. Auch der Künstler wird, vielleicht noch hochgeistiger als der Handwerker, seine Mittel so wählen, dass sie seiner Intention am besten zuträglich sind. Sind denn Tabellen ästhetischer und individueller, oder was meinst du mit »eigene Methode«?

wie zum beispiel manch ein künstler der nur die farbe schwarz für ein
bild verwendet und die ganze leinwand vollmalt? weist du wieviel geld
das bringt? aber ein bild ist das auch nicht wirklich. und das
gestalltungsmittel ist auch zweckfrei.

MfG

[at]

Hallo.

Den Künstler möchte ich sehen, der in der Wahl seiner Gestaltungsmittel volllkommen zweckfrei vorgeht.

Vermutlich wirst du schon längst welche gesehen haben, auf die dies zutrifft, denn viele Künstler wählen ihre Mittel intuitiv und verschließen sich dabei bewusst oder unbewusst jeder intellektuellen Herangehensweise. So hat die Wahl der Mittel zwar immer (mindestens) einen Grund, aber eben nicht immer auch einen Zweck.
MfG, at

[molily]

Hallo,

Den Künstler möchte ich sehen, der in der Wahl seiner Gestaltungsmittel volllkommen zweckfrei vorgeht.

Vermutlich wirst du schon längst welche gesehen haben, auf die dies zutrifft, denn viele Künstler wählen ihre Mittel intuitiv und verschließen sich dabei bewusst oder unbewusst jeder intellektuellen Herangehensweise. So hat die Wahl der Mittel zwar immer (mindestens) einen Grund, aber eben nicht immer auch einen Zweck.

Dass manche Künstler dieses Selbstverständnis bzw. diesen Anspruch haben, glaube ich gerne (die écriture automatique des Surrealismus würde mir spontan einfallen).
Solange man unter Zweck nur als in einem Willensakt gesetzte Ziele versteht, stimme ich zu, dass ein Künstler nicht notwendigerweise rational reflektiert hat, welches das jeweils geeignete Gestaltungsmittel ist. So sehr ein Künstler sich auch von der Reflexion lösen will und auf Intution setzt, so sehe ich dahinter ebenso einen in diesem Falle unbewussten, aber existierenden Grund, also setze eine Kausalität voraus.

Mathias

[at]

Hallo.

So sehr ein Künstler sich auch von der Reflexion lösen will und auf Intution setzt, so sehe ich dahinter ebenso einen in diesem Falle unbewussten, aber existierenden Grund, also setze eine Kausalität voraus.

"Zweck" setzt eine Absicht oder zumindest eine Ahnung voraus, und Absicht oder Ahnung wiederum Bewusstsein. Unbewusstes, aber zweckgerichtetes Handeln funktioniert also nicht. -- Aber ich wollte mich jetzt eigentlich nicht mit diesen Kleinigkeiten aufhalten; zumal dann nicht, wenn ich wie hier deinen weiteren Darlegungen fast vorbehaltlos zustimme.
MfG, at

[wahsaga]

hi,

Auch der Hinweis darauf, Javascript zu vermeiden, weil es gute Gründe gegen die Verwendung von Javascript geben würde, wobei die Kritiker jedes mal die Begründung der angeblich gute Gründe schuldig bleiben, ist für mich sehr weit hergeholt. Niemand würde eine Axt verdammen wollen, nur weil es gute Gründe gibt, die Axt als gefährliches Instrument einzustufen.

der vergleich hinkt.

eine webseite, die zur erfüllung ihrer funktionalität auf javascript setzt, setzt einfach eine axt _vorraus_.
_warum_ die axt im zweifelsfalle nicht vorhanden ist, ist nebensächlich - entscheidend ist nur die tatsache, _dass_ sie es manchmal nicht ist.

Der Mißbrauch ist stets nicht ausgeschlossen und mißliebige Zeitgenossen, die eine Sache zu mißbrauchen versuchen, gibt immer wieder.

eben - und deshalb sorgen manche eltern (z.b. administratoren) dafür, dass ihre kinder (user im netzwerk) gar keine axt (javascript-ausführenden client) in die finger bekommen.

So kann denn die Absicht, eine Navigation mit einem Frame bei Verwendung von Javascript aufzubauen, nicht immer mit dem Hinweis auf fehlende Barrierefreiheit mißbilligt werden.

dass eine (ausschließlich) auf javascript basiernde navigation eine barriere darstellt, wirst du nicht wegdiskutieren können.
ob das für deine "zielgruppe" relevant ist - und ob du deshalb darauf rücksicht nehmen willst oder nicht - ist ein ganz anderer punkt.

allerdings begehen viele seitenersteller an dieser stelle den fehler, "potentielle zielgruppe" gleichzusetzen mit "menge der leute, die die nötigen vorrausetzungen mitbringen, um die seite so wie ich sie gestaltet habe nutzen zu können".
das halte ich aber für ziemlichen unfug.

gruß,
wahsaga

[Klawischnigg]

Hi there,

Ich habe hier meine Gedanken zum Thema niedergeschrieben, eben aus einer anderen Sicht, die nicht den Mainstream vertritt. Die von mir vorgetragene Sichtweise behandelt hier nur einen Aspekt. Aber ich wüßte auf Anhieb mindestens noch weitere Anwendungen, die das WWW nicht nur auf den Mainstream reduzieren.

Dafür sei Dir von mir gedankt, auch wenn ich hier wenig Zustimmung erwarte...

[molily]

Hallo,

Ich habe hier meine Gedanken zum Thema niedergeschrieben, eben aus einer anderen Sicht, die nicht den Mainstream vertritt. Die von mir vorgetragene Sichtweise behandelt hier nur einen Aspekt. Aber ich wüßte auf Anhieb mindestens noch weitere Anwendungen, die das WWW nicht nur auf den Mainstream reduzieren.

Dafür sei Dir von mir gedankt, auch wenn ich hier wenig Zustimmung erwarte...

Verzeihung, aber: Wie arrogant ist das eigentlich, gar nicht inhaltlich zu diskutieren, sondern sich selbstgerecht darauf zurückzuziehen, dass man einer der wenigen ist, der die Wahrheit gefunden hat, und deshalb vom »Mainstream« verachtet wird? Das ist mindestens soviel Starrsinn, wie hier dem sogenannten Mainstream vorgeworfen wird.

Mathias

[Richard Rüfenacht]

Hallo Klawischnigg,

Ich habe hier meine Gedanken zum Thema niedergeschrieben, eben aus einer anderen Sicht, die nicht den Mainstream vertritt.
Dafür sei Dir von mir gedankt, auch wenn ich hier wenig Zustimmung erwarte...

diese Diskussion um Frames und Tabellen kommt mir vor, als würden wir in der Schweiz darüber streiten, ob die Armee wieder mit Hellebarden bewaffnet werden sollte, nur weil wir einst damit gegen die Habsburger erfolgreich waren.

Was ist denn ideologisch daran, wenn Leute darauf hingewiesen werden, dass es eine sinnvolle Weiterentwicklung gibt? Argumente,  statt Instrumente zum Kopfabschlagen sind gefragt.

Beste Grüsse
Richard

[Cyx23]

Hallo Richard,

diese Diskussion um Frames und Tabellen kommt mir vor, als würden wir in der Schweiz darüber streiten, ob die Armee wieder mit Hellebarden bewaffnet werden sollte, nur weil wir einst damit gegen die Habsburger erfolgreich waren.

Was ist denn ideologisch daran, wenn Leute darauf hingewiesen werden, dass es eine sinnvolle Weiterentwicklung gibt? Argumente,  statt Instrumente zum Kopfabschlagen sind gefragt.

Eine Vergleichbarkeit mit den Hellebarden und die "sinnvolle
Weiterentwicklung" gibt es eben in der von dir unterstellten
Eindeutigkeit nicht.

Oder um es erstmal am Beispiel Tabellen zu konkretisieren, Tabellen
werden von nahezu allen Browsern richtig dargestellt, als
Layoutwerkzeug ist die Tabelle einem CSS-Layout in vielen
Punkten derzeit noch weit überlegen.

Es ist eher so als wenn die Schweizer im Modernisierungsfieber oder
nach zuviel Comic-Konsum, Flash Gordon oder sowas, billige Laserpointer
gegen ihre Hellbarden oder Sturmgewehre in ihren Schränken
eintauschen würden weil die Verwendung von Laserstrahlenwaffen
ja mittlerweile der Stand der Entwicklung wäre.
Natürlich gibt es gute Gründe für den Laserpointer, er nimmt
weniger Platz im Kleiderschrank weg, riecht nicht nach Öl und
ist vielseitiger einsetzbar.

Grüsse

Cyx23

[Christian Kruse]

你好 Cyx23,

Es ist eher so als wenn die Schweizer im Modernisierungsfieber oder
nach zuviel Comic-Konsum, Flash Gordon oder sowas, billige Laserpointer
gegen ihre Hellbarden oder Sturmgewehre in ihren Schränken
eintauschen würden weil die Verwendung von Laserstrahlenwaffen
ja mittlerweile der Stand der Entwicklung wäre.

Laser-Pointer sind total veraltet, die werden nur noch von den Ammies
eingesetzt ;-)) Top of the edge ist das Reflex-Visier: der rote Zielpunkt
wird über Sonnenlicht bzw. eine kleine LED + Batterie auf das Auge des
Schützen gespiegelt; der Zielpunkt ist also nur für den Schützen
sichtbar ;-) Dagegen ist ein Laserpointer-Visier der letzte Dreck *g*

再见,
克里斯蒂安

[Schuer]

als
Layoutwerkzeug ist die Tabelle einem CSS-Layout in vielen
Punkten derzeit noch weit überlegen.

Ich würde es so sagen, dass die Layout-Tabelle der tabellenlosen Struktur zwar in einigen Punkten überlegen ist (etwa dadurch, dass sich die Zellen in ihren Ausmaßen besser angleichen als tabellenlose Inhaltsbereiche), dass es jedoch weitaus mehr Nachteile als Vorteile gibt, die zu bedenken sind. Dazu zitiere ich mich einfach mal selbst:

"Tabellen, die zur Anordnung von Inhaltsbereichen genutzt werden,
    erschweren oder verhindern oft eine sinnvolle Abfolge der Inhalte.
    Das liegt schlicht daran, dass Tabellen immer von links nach rechts
    und von oben nach unten beschrieben werden. Es ist nicht möglich,
    von rechts nach links zu schreiben, so dass der rechts stehende
    Inhalt inhaltlich vor dem links stehenden Inhalt aufgeführt wird
    (entspricht float:right).

Hinzu kommt, dass keine zwei Tabellen nebeneinander stehen können,
    so dass oft Verschachtelungen nötig sind, um ein komplexes und/oder
    mehrspaltiges Layout abzubilden.
    Gegen die Verwendung in verschiedenen Ausgabemedien spricht außerdem
    die starre Konstruktion einer Tabelle, dessen Struktur sich nicht
    ändern lässt: zwei Zellen innerhalb einer Zeile brechen etwa niemals
    um, sondern behalten jederzeit ihre Position nebeneinander."

(http://aktuell.de.selfhtml.org/artikel/design/reihenfolge/)

Viele Grüße!
_Dirk
DECAF°

[MudGuard]

Hi,

Hinzu kommt, dass keine zwei Tabellen nebeneinander stehen können,

Aha. Wie kommst Du darauf?
Auch Tabellen können per float oder position:absolute (oder anderes?) nebeneinander gesetzt werden.
(was aber noch lange kein Grund ist, Tabellen fürs Layout zu benutzen)

cu,
Andreas

[Schuer]

Hinzu kommt, dass keine zwei Tabellen nebeneinander stehen können,

Aha. Wie kommst Du darauf?

Ich weiß nicht. Irgendeine unwichtige Meinung, die ich mir im Vorbeigehen (oder während damaliger Frontpage-Zeiten) gebildet habe ;-) Wen kümmern schon Tabellen..

Viele Grüße!
_Dirk
DECAF°

[Vinzenz Mai]

Hallo Schuer

Hinzu kommt, dass keine zwei Tabellen nebeneinander stehen können,

Ich weiß nicht. Irgendeine unwichtige Meinung, die ich mir im Vorbeigehen (oder während damaliger Frontpage-Zeiten) gebildet habe ;-) Wen kümmern schon Tabellen..

Denjenigen, der tabellarische Daten darstellen will, z.B. die Abschlusstabellen zweier Vorrundengruppen eines Turniers, die nach Möglichkeit nebeneinander erscheinen sollen, sofern der Platz für diese Art der Anzeige ausreicht.

Freundliche Grüße

Vinzenz

[Richard Rüfenacht]

Hallo Cyx23,

Eine Vergleichbarkeit mit den Hellebarden und die "sinnvolle
Weiterentwicklung" gibt es eben in der von dir unterstellten
Eindeutigkeit nicht.

Warum? Bei unserer Söldnertruppe im Vatikan sind Hellebarden doch auch zu Layoutzwecken im Einsatz ;-)

als Layoutwerkzeug ist die Tabelle einem CSS-Layout in vielen
Punkten derzeit noch weit überlegen.

Das sage ich mir auch immer, wenn ich wieder mal zu blöd bin, eine andere Lösung zu finden. Nur gehe ich damit nicht missionieren. Der Punkt war doch, dass die Empfehlungen in diesem Forum, auf Tabellen und Frames möglichst zu verzichten, als Ideologie verurteilt wurden. Das ist aber keine Ideologie, sondern ein besserer Weg. Du kannst ja ruhig bei deiner Meinung bleiben.

Natürlich gibt es gute Gründe für den Laserpointer, er nimmt
weniger Platz im Kleiderschrank weg, riecht nicht nach Öl und
ist vielseitiger einsetzbar.

Bei mir im Schrank steht neben den diversen Sturm- und sonstigen Gewehren auch der Laserpointer, den brauchte ich bis vor zwei, drei Jahren noch zum Üben, ist mittlerweile aber wirklich nicht mehr Stand der Technik, wie Christian treffend bemerkte.

Beste Grüsse
Richard

[Cyx23]

Hallo Richard,

als Layoutwerkzeug ist die Tabelle einem CSS-Layout in vielen
Punkten derzeit noch weit überlegen.
Das sage ich mir auch immer, wenn ich wieder mal zu blöd bin, eine andere Lösung zu finden. Nur gehe ich damit nicht missionieren. Der Punkt war doch, dass die Empfehlungen in diesem Forum, auf Tabellen und Frames möglichst zu verzichten, als Ideologie verurteilt wurden. Das ist aber keine Ideologie, sondern ein besserer Weg. Du kannst ja ruhig bei deiner Meinung bleiben.

gerade deine Äusserung geht doch in Richtung Ideologie.

Meinung mag die Gewichtung sein, etwa was in meiner Aussage "in
vielen" bedeutet. Da Abwärtskompatibilität als sehr wichtiger Punkt
zu den verschiedenen Vorteilen bei Positionierungen hinzukommt ist
"in vielen" m.E. neutral genug, dir mag "viele" zu viel sein,
Konsens sollte aber sein dass da keine Aussage zugunsten einer
einseitigen Entscheidung für die Tabelle getroffen wird.

Missionarisch könnte doch wohl gerade die von dir angesprochene
(oft unnötige) Entscheidung zwischen Wegen zu sein.

Einiges zu dem Thema kommt mir vor wie eine Weigerung die Mängel von
vielen CSS-Lösungen einzugestehen; auch die Behauptung dass es
gewissermassen immer doch eine bessere CSS-Lösung gäbe wie du
unterstellst halte ich für problemtisch.

Damit will ich mich nicht dagegen aussprechen diese Lösung ggf. zu
finden, wie ich hier ja auch nicht für Tabellenlayout plädiere.

Nur sollte hier im Forum auch Anfängern ggf. zugemutet werden, dass
es mehrere Möglichkeiten gibt statt schwarz-weiss Malerei zu
betreiben, und dass CSS -ob nun wegen fehlendem Leistungsumfang
oder schlechter Browser- vieles gar nicht leistet, eben leider auch
nicht die Trennung von Layout und Inhalt (was wieder einen der
Kritikpunkte an Layouttabellen abschwächt).

Und was die von dir erwähnten Empfehlungen betrifft halte ich z.B.
eine Präferenz von tableless layout zwar für richtig, nicht aber
den Ton und den Anspruch in bzw. mit dem solche Empfehlungen oder
entspr. Kritiken mitunter abgelassen werden, abgesehen von den
wünschenswerten Umgansformen hier im Forum ist auch dafür CSS
einfach nicht leistungsfähig genug.

Grüsse

Cyx23

[Richard Rüfenacht]

Hallo Cyx23,

gerade deine Äusserung geht doch in Richtung Ideologie.

ursprünglich habe ich auf ein völlig inhaltsleeres Posting geantwortet, dem jegliche sachliche Argumentation, wie du sie jetzt führst, fehlte.

Missionarisch könnte doch wohl gerade die von dir angesprochene
(oft unnötige) Entscheidung zwischen Wegen zu sein.

Es gehört zu meiner Arbeitsweise, jede Lösung stets kritisch zu hinterfragen. Entscheidungen sollten zumindest sachlich begründbar sein.

Einiges zu dem Thema kommt mir vor wie eine Weigerung die Mängel von
vielen CSS-Lösungen einzugestehen; auch die Behauptung dass es
gewissermassen immer doch eine bessere CSS-Lösung gäbe wie du
unterstellst halte ich für problemtisch.

Unterstellt habe ich das nicht, das hast du hinein interpretiert. Es gibt schlicht keine perfekte Lösung. Allerdings machen Mängel in CSS Tabellenlayouts nicht automatisch besser. Der entscheidende Punkt ist doch, wie mit den momentan zur Verfügung stehenden Möglichkeiten umgegangen wird. Wenn ich bei gewohnten Tabellenlayouts bleibe, weil mir dies im Moment die arbeitssparendere Lösung zu sein scheint, halte ich dies für vertretbar. Dann sollte es aber auch so begründet werden und nicht mit dem Hinweis auf tatsächliche oder vermeintliche Mängel von CSS. Wenn du Probleme hast, deine Gestaltungsideen mit CSS umzusetzen, solltest du deine Vorstellungen von Design überprüfen, es könne sein, dass du dich viel zu sehr an Printmedien orientierst.

Nur sollte hier im Forum auch Anfängern ggf. zugemutet werden, dass
es mehrere Möglichkeiten gibt statt schwarz-weiss Malerei zu
betreiben, und dass CSS -ob nun wegen fehlendem Leistungsumfang
oder schlechter Browser- vieles gar nicht leistet, ...

Anfängern ist nun wirklich nicht damit geholfen, wenn ihnen der veraltete und völlig unzweckmässige Umweg über Frames und Tabellen empfohlen wird. Die Erfahrung zeigt doch, dass man sich sich mitunter sehr schwer tut, einmal erstellte Tabellenlayouts und Framesets zu überarbeiten. Warum sollten Anfänger sich sowas antun?

... eben leider auch
nicht die Trennung von Layout und Inhalt (was wieder einen der
Kritikpunkte an Layouttabellen abschwächt).

Die Verwendung von CSS ermöglicht die Trennung von Form und Inhalt. Für die Trennung musst du aber schon selbst sorgen.

Und was die von dir erwähnten Empfehlungen betrifft halte ich z.B.
eine Präferenz von tableless layout zwar für richtig, nicht aber
den Ton und den Anspruch in bzw. mit dem solche Empfehlungen oder
entspr. Kritiken mitunter abgelassen werden, abgesehen von den
wünschenswerten Umgansformen hier im Forum ist auch dafür CSS
einfach nicht leistungsfähig genug.

Du meinst, die Leute sollten zu den Tabellenfetischisten freundlicher sein, weil du den Leistunsgsumfang von CSS für zu gering hälst? ;-)

Bist du eigentlich sicher, dass du CSS so gut beherrscht, um darüber abschliessend urteilen zu können?

Beste Grüsse
Richard

[Cyx23]

Hallo,

bei der Umsetzung der gewünschten "Barrierfreiheit" geht es meist um zwei
Vorgehensweisen, nämlich hinderliche Dinge zu unterlassen und zusätzliche
Unterstützung anzubieten. Die Verwendung von richtigem HTML ist der einfachste
und wohl nützlichste Punkt, wenn auch da die Frage bleibt ob ältere Software
immer damit klarkommt.
Bei solcher Software kann es sich auch um Screenreader handeln, die pikanterweise
auch assistive Massnahmen aushebeln bzw. zu CSS-Hacks nötigen.

Dass aber eine Aufteilung in Frames, einen Navigationsframe und einen Frame mit
Seiten bzw. Inhalt, immer die Barrierfreiheit deutlich verschlechtert halte ich
für fragwürdig, übrigens auch bei Tabellen kommen ja solche übertriebenen
Einschätzungen, zumal es im HTML keine vernünftige Auszeichnung für Navigationen
gibt, wie es auch keine geeigneten strukturellen Gliederungswerkzeuge gibt.
Ansonsten sind natürlich einige Vorteile von Frames angesichts der Verbreitung
von PHP (CMS) und schnelleren DSL-Zugängen geringer geworden.

Und erst Recht dürfte JavaScript die Barrierefreiheit und Usability deutlich
erhöhen, allerdings ist die Forderung nach geeigneten Ersatzstrategien richtig.
Es geht da letztlich auch nicht um die Frage ob JavaScript gefährlich ist
sondern einfach um den Punkt ob beim Besucher JavaScript deaktiviert sein mag.

Bei deinen Ausführungen zu "WWW-Designern" und Mainstream usw. wäre erstmal
zu schauen welcher Mainstream beispielsweise tatsächlich (und wenn warum) auf
Frames verzichtet, und ob die von dir erwähnte Dogmatisierung eine Modeerscheinung
ist oder welche Funktionen sie darüber hinaus haben könnte, interessant finde
ich da den Vergleich zur sehr problematischen Netscape 4 Hysterie einiger
selbsternannter Webverbesserer vor einiger Zeit, die auch noch der ersten
Grundforderung des W3C widerspricht: Universelle Zugangsmöglichkeiten.

Grüsse

Cyx23

[Sven Rautenberg]

Moin!

Und erst Recht dürfte JavaScript die Barrierefreiheit und Usability deutlich
erhöhen, allerdings ist die Forderung nach geeigneten Ersatzstrategien richtig.
Es geht da letztlich auch nicht um die Frage ob JavaScript gefährlich ist
sondern einfach um den Punkt ob beim Besucher JavaScript deaktiviert sein mag.

Und gerade an diesem Punkt kann man eigentlich zwei Dinge festhalten:
1. Javascript kann die Bedienbarkeit einer Website erheblich steigern, bzw. Annehmlichkeiten schaffen, die anders nicht erreichbar sind. Insofern spricht nichts grundsätzlich gegen einen Einsatz von Javascript.
2. Suchmaschinen können kein Javascript. Und werden daher prinzipbedingt nie in der Lage sein, menschliche Interaktion mit einer Webseite zu simulieren, um dessen Navigationsverhalten nachzuahmen (denn den Suchmaschinen geht es ja primär nur um die Inhalte der Seiten).

Aus diesen zwei Feststellungen folgt ganz klar, dass Javascript niemals der einzige Weg zu einer aufzurufenden Seite sein darf, sondern es immer auch eine javascriptfreie Alternative geben sollte - jedenfalls allgemein gesprochen. Dass man für Intranets, in denen nie eine Suchmaschine per HTTP spidern muß, sowohl eine hohe Benutzbarkeit, also folglich Javascript, wünscht, und gleichzeitig den eventuellen Extra-Aufwand (sei er auch noch so gering) für eine javascriptlose Bedienung einspart, ist dabei keine Einschränkung der allgemeinen Bedeutung der obigen Forderung.

• Sven Rautenberg

[Cyx23]

Hallo,

Und gerade an diesem Punkt kann man eigentlich zwei Dinge festhalten:

einen gibt es wohl noch zu den Vorteilen von JavaScript:
Clientseitges JavaScript belastet nicht nur den Server nicht,
es mag auch dort ein geringeres Sicherheitsrisiko darstellen
als Techniken wie PHP und ist kostengünstiger als Java.

Grüsse

Cyx23

[xwolf]

Hi,

einen gibt es wohl noch zu den Vorteilen von JavaScript:
Clientseitges JavaScript belastet nicht nur den Server nicht,
es mag auch dort ein geringeres Sicherheitsrisiko darstellen
als Techniken wie PHP und ist kostengünstiger als Java.

Interessiert den User wo eine Dynamik ausgeführt wird?

IMHO würde eine größere JavaScript-Applikation sicherlich für den User von
Nachteil sein gegenüber einer Lösung die serverseitig arbeitet (und die natürlich schnell genug ist {also meist kein Java, sondern wirklich Perl, PHP oder anderes}), weil der übertragende Code für den Benutzer zu mehr Traffik führt.
Benutzer mit langsamen Rechnern sind danna uch noch doppelt gearscht.

Ciao,
  Wolfgang

[Cyx23]

Hallo,

Interessiert den User wo eine Dynamik ausgeführt wird?

dann interessierts den Anbieter, und die Konsequenzen vielleicht auch
doch den User, schliesslich geht es ja nicht nur um den User, bzw.
der User könnte ja auch für Content usw. mehr oder weniger bezahlen
müssen, da schätze ich serverseitige Javaapplikationen als teurer
ein was ja ggf. vom Nutzer bezahlt werden muß, ob direkt oder über
die verbundenen Produkte.

IMHO würde eine größere JavaScript-Applikation sicherlich für den User von
Nachteil sein gegenüber einer Lösung die serverseitig arbeitet (und die natürlich schnell genug ist {also meist kein Java, sondern wirklich Perl, PHP oder anderes}), weil der übertragende Code für den Benutzer zu mehr Traffik führt.

PHP usw. habe ich ja gerade wegen der angenommenen höheren Sicherheitsanforderungen
ausgeschlossen, ansonsten haut es ja u.U. auch nicht ganz so
elegant hin wenn irgendwann der Server etwas träger reagiert,
auch letztlich mit ähnlichen wie von dir beschriebenen Nachteilen,
ob nun Traffic oder online-Zeit.

Allerdings liessen sich Sicherheitsanforderungen vielleicht auch
durch einen zusätzlichen getrennten Server umsetzen, kostet aber
auch etwas mehr und ist in einigen größeren Firmen vielleicht schwer
entscheidbar.

Grüsse

Cyx23

[peter]

Hi,

einen gibt es wohl noch zu den Vorteilen von JavaScript:
Clientseitges JavaScript belastet nicht nur den Server nicht,
es mag auch dort ein geringeres Sicherheitsrisiko darstellen
als Techniken wie PHP und ist kostengünstiger als Java.

Interessiert den User wo eine Dynamik ausgeführt wird?

IMHO würde eine größere JavaScript-Applikation sicherlich für den User von
Nachteil sein gegenüber einer Lösung die serverseitig arbeitet (und die natürlich schnell genug ist {also meist kein Java, sondern wirklich Perl, PHP oder anderes}), weil der übertragende Code für den Benutzer zu mehr Traffik führt.

Schonmal was von Schleifen gehört ?

Lass PHP mal in ner Schleife bis 10.000 zählen und für jeden Durchlauf ein entsprechendes Stück HTML erzeugen und liefer dem User dann mal die entstandene HTML-Seite aus.

Vergleich den Traffic dann mal mit dem, was ein Stückchen Java-Script erzeugt, welches das Gleiche clientseitig bewältigt.

Und bis DSL mal wirklich flächendeckend verfügbar ist, vergeht wohl noch einige Zeit.
Abgesehen davon könnte man bei Verfügbarkeit den User genausowenig zwingen, sich einen DSL-Anschluß zuzulegen wie man ihn zwingen kann, sein Javascript einzuschalten.

Diese immer wieder angeführte Argumentation "... in Zeiten von DSL und PHP ..." entbehrt meiner Meinung nach also auch jeder Grundlage und Stichhaltigkeit.

gruß
ptr

[Struppi]

Schonmal was von Schleifen gehört ?

Lass PHP mal in ner Schleife bis 10.000 zählen und für jeden Durchlauf ein entsprechendes Stück HTML erzeugen und liefer dem User dann mal die entstandene HTML-Seite aus.

Vergleich den Traffic dann mal mit dem, was ein Stückchen Java-Script erzeugt, welches das Gleiche clientseitig bewältigt.

Der Traffic der JS Seite kann u.U. kleiner sein, aber die JS Seite wird - wenn überhaupt - nur schwerfällig bedienbar sein, sich extrem langsam aufbauen und viele Systeme bis zum Anschlag belasten. Insofern ist die erste Lösung besser.

Nur ist Vorgehensweise solche Menge an Code zu liefern nie sinnvoll aus den geannnten Gründen, sondern hier ist eine serverseitige Logik unabdingbar, die es ermöglicht zu z.b. zu blättern.

Struppi.

[HaThoV]

Nur ist Vorgehensweise solche Menge an Code zu liefern nie sinnvoll aus den geannnten Gründen, sondern hier ist eine serverseitige Logik unabdingbar, die es ermöglicht zu z.b. zu blättern.

Da träumst Du aber irgendwas. Ich arbeite nach einem clientseitig organisierten System, wo die "Homepage" eigentlich nur die Sitemap mit den ausgezeichneten Layout-Elementen ist, nachgeordnete Daten per XML zugeladen und ins Layout montiert werden. Mit ECMA-Script - wie sonst?

"serverseitige Logik" ist dafür entbehrlich und zu langsam. Der Server soll "serven" und nichts anderes.

mfg
T.

[Struppi]

Nur ist Vorgehensweise solche Menge an Code zu liefern nie sinnvoll aus den geannnten Gründen, sondern hier ist eine serverseitige Logik unabdingbar, die es ermöglicht zu z.b. zu blättern.

Da träumst Du aber irgendwas. Ich arbeite nach einem clientseitig organisierten System, wo die "Homepage" eigentlich nur die Sitemap mit den ausgezeichneten Layout-Elementen ist, nachgeordnete Daten per XML zugeladen und ins Layout montiert werden. Mit ECMA-Script - wie sonst?

Du hast gelesen worum es ging?
Wir sprachen von z.b. 10,000 Listeneinträge, diese Anzahl lädst du per XML nach und baust sie dann in die Seite ein?

"serverseitige Logik" ist dafür entbehrlich und zu langsam. Der Server soll "serven" und nichts anderes.

Sind die XML Dateien statische Dateien?

Struppi.

[HaThoV]

Wir sprachen von z.b. 10,000 Listeneinträge, diese Anzahl lädst du per XML nach und baust sie dann in die Seite ein?

Ja. bzw. ich lade als erstes die komplette Sitemap. Die Daten lade ich auf Request per XML nach und halte sie anschließend vor.

Sind die XML Dateien statische Dateien?

Nicht unbedingt.

Struppi.

mfg
T.

[Struppi]

Wir sprachen von z.b. 10,000 Listeneinträge, diese Anzahl lädst du per XML nach und baust sie dann in die Seite ein?

Ja. bzw. ich lade als erstes die komplette Sitemap. Die Daten lade ich auf Request per XML nach und halte sie anschließend vor.

Ich hab mit dieser Technik noch nicht soviel Erfahrung und hab eben mal ein bisschen rumgespielt und bin erstaunt wie fix das alles tatsächlich geht.

Nur, so wie du es schilderst klingt es, als ob du eine Navigation komplett über JS realisierst?
Was natürlich auch nicht sinnvoll wäre.

Sind die XML Dateien statische Dateien?

Nicht unbedingt.

Wobei mir der Unterschied zu dem von mir gesagten nicht klar ist, da du ja offensichtlich ebenfalls mit einer serverseitigen Logik die Daten zu Verfügung stellst. Davon wie die Daten dann abgerufen werden hab ich ja nicht gesprochen.

Und das mit einer Kombination von clientsetigen und servseitigen Techniken Optimierungen möglich sind, würd ich auch nicht bestreiten, aber hier gilt natürlich dann auch das hier schon zu JS gesagten - man sollte sich auf jeden Fall Gedanken machen ob man wirklich Clients ausperren oder ob man sich die Arbeit von Alternativen machen möchte.

Trotz allem finde ich die Technik ebenfalls sehr interessant und bin gerade dabei für mich passende Anwednungen dafür zu finden.

Struppi.

[Detlef G.]

Hallo Struppi

Trotz allem finde ich die Technik ebenfalls sehr interessant und bin gerade dabei für mich passende Anwednungen dafür zu finden.

Ich könnte mir gut vorstellen, zweigleisig zu arbeiten.
Die Navigation enthält Links, die komplette serverseitig generierte Seiten
aufrufen, wenn Javascript nicht verfügbar ist.
Bei aktiviertem Javascript hingegen werden nur die neuen Inhalte abgerufen
und in die Seite eingebaut.
So könnte Traffik eingespart und der Server entlastet werden, wärend Nutzer
ohne Javascript kaum einen Unterschied bemerken.

Auf Wiederlesen
Detlef

[at]

Hallo.

Ich könnte mir gut vorstellen, zweigleisig zu arbeiten.

Das konnte der Entwickler dieses Forums auch. Das Ergebnis verwendest du.
MfG, at

[HaThoV]

Die Navigation enthält Links, die komplette serverseitig generierte Seiten
aufrufen, wenn Javascript nicht verfügbar ist.
Bei aktiviertem Javascript hingegen werden nur die neuen Inhalte abgerufen
und in die Seite eingebaut.
So könnte Traffik eingespart und der Server entlastet werden, wärend Nutzer
ohne Javascript kaum einen Unterschied bemerken.

So isset. Meine LowTec-Variante erzeugt "flache" HTML-Seiten (Phase 5 Includes), die zwangsläufig sich wiederholdende Elemente nachladen müssen. Die 4HTML-Variante läßt das Basis-Layout mit allen Elementen stehen und lädt nur noch HTML-Fragmente als XML nach. Traffic- und Ladezeitersparnis ca. 80%.

Auf Wiederlesen
Detlef

dito
T.

[HaThoV]

Wobei mir der Unterschied zu dem von mir gesagten nicht klar ist, da du ja offensichtlich ebenfalls mit einer serverseitigen Logik die Daten zu Verfügung stellst. Davon wie die Daten dann abgerufen werden hab ich ja nicht gesprochen.

Die Daten können wahlweise statisch vorgehalten oder serverseitig (SQL z.B.) generiert werden. Macht keinen Unterschied.

mfg
T.

[molily]

Hallo,

Ich habe sehr viel Verständnis für Menschen, die mit ihren körperlichen Gebrechen in ihrem Leben zurechtkommen müssen.
Doch niemand würde allen Ernstes behaupten wollen, es sollte i.e. für Blinde die Barriere zum Autofahren demontiert werden

Unpassender Vergleich. Das WWW ist im Gegensatz zum Straßenverkehr prinzipiell für Blinde zugänglich und es bedarf keiner entsprechenden Hochtechnologie (»technischer Ersatz für die menschliche Sehfähigkeit«) wie beim Straßenverkehr.

Bei allen Statements zu diesem Thema fällt mir auf, daß Webpages angeblich ausschließlich nur zu einem Zweck gemacht wären. Ich für meinen Teil empfinde das als eine sehr eingeschränkte Sichtweise. So empfinde ich den Tadel, daß Webpages nicht nur für eine Zielgruppe gemacht werden sollten, als nicht gerechtfertigt.

Der Begriff der »Zielgruppe« ist ein Konstrukt von Seiten des Autors zur Analyse der Bedürfnisse der Besucher und somit der Anforderungen an die Seite. Sofern sich die Seite nicht mit Technik selbst beschäftigt (z.B. Seiten zur Flashentwicklung können das Flash-Plugin beim Besucher mit hoher Wahrscheinlichkeit voraussetzen), ist der Schluss von der Zielgruppe (idealer Benutzer) auf eine ideale technische Zugangsweise höchstgradig spekulativ.

Ich habe für meine Bedürfnisse die Technik der Webpages als Ersatz für Dokumentation auf Papier entdeckt, somit richtet sich das sehr wohl an bestimmte Zielgruppen.

Das hat niemand der Kritiker des Zielgruppenwahns bezweifelt.

Der Ausschluß anderer, die nicht zu diesen Zielgruppen gehören, liegt oft in der Natur der Sache und bedeutet dabei keineswegs eine Diskriminerung.

Ja. Aber nur selten liegt es in der Natur der Sache. Leider meinen viele, die Zusammenhänge zwischen Thema der Seite, Zielgruppe und deren technischen Zugangsweisen sei mehr als ein Erklärungsmodell, um die Seite den Bedürfnissen anzupassen, sondern sei natürlich und faktisch vorhanden, genauso, wie man es im Kopf hat. Das ist gefährlich, weil man den Sinn für reale Bedürfnisse verliert.

Technische Dokumentationen sind IMHO zum Teil aufwendiger als manche Webpages, die als freies Angebot für jedermann errichtet werden. Der oft von den Frame-Gegnern angeführte Hinweis, Navigation wäre zur Vermeidung von Frames ohne weitere Probleme über CSS in die Seite einzubauen, ist IMHO zu kurz gesehen. Ich habe in meinen Projekt derzeit an die 300 Seiten eingebaut, die Navigation enthält z.Zt. etwas mehr als 1300 Einträge, diese Navigation mit jeder Seite laden zu wollen, würde jedes mal etwa zusätzliche 60 KB erfordern.

1. Technische Dokumentation ist, wie du eben sagst, in dieser Hinsicht ein Sonderfall. Der Frame-Gegner, der bei einem solchen Ausmaß zu Includes von ellenlangen Navigationen rät, legt noch ganz andere Defizite an den Tag, als nur Frames plump abzulehnen.
2. Eine Navigation mit 1.300 Einträgen in einen Frame zu laden, ist allgemein gesehen wenig benutzerfreundlich (glaube auch nicht, dass du das genau meinst). Der Aufbau einer hierarchischen Navigation oder einer anderweitig Metadaten-basierten Navigation (etwa Stichwörtern) ist in so einem Fall allgemein gesprochen sinnvoller. Hinzu kommen andere Mechanismen, um in diese Einträge Ordnung hineinzubringen (Suchfunktionen).
3. Wenn man erst einmal die Inhaltsstruktur rekonstruiert hat, kann man sich Gedanken über eine sinnvolle Ordnung machen, das heißt, wie diese Struktur dem Leser präsentiert wird. Wenn man guten Hypertext schreibt, greifen die genannten Mechanismen auch und erlauben eine schnelle und klare Navigation durch die Fülle an Inhalt. Dazu können Frames punktuell ein brauchbares Mittel sein, um ein übersichtliche Schnittstelle zum Inhalt zu schaffen. Nichtsdestoweniger müssen nach wie vor die gängigen Nachteile von Frames beachtet werden. Es muss also auch eine Navigation möglich sein, die ohne dieses Hilfsmittel weiterhin funktioniert.

Auch der Hinweis darauf, Javascript zu vermeiden, weil es gute Gründe gegen die Verwendung von Javascript geben würde, wobei die Kritiker jedes mal die Begründung der angeblich gute Gründe schuldig bleiben, ist für mich sehr weit hergeholt.

Du bleibst wunderbar allgemein. So kannst du darauf verzichten, irgendetwas spezielles, argumentativ untermauertes zu sagen. Du stellst ganz allgemein fest, dass alle diejenigen, die nicht deiner Meinung sind, keine Belege anführen. Selbst bringst du ebensowenig welche, denn du steigst gar nicht in die sachliche Diskussion ein.
Polemik, Polemik.

So kann denn die Absicht, eine Navigation mit einem Frame bei Verwendung von Javascript aufzubauen, nicht immer mit dem Hinweis auf fehlende Barrierefreiheit mißbilligt werden.

Natürlich. Wenn ich eine Technik ihrer Vorteile wegen einsetze, muss ich ebenso die Nachteile in Betracht ziehen. Mangelnde Barrierefreiheit von Frames wird immer ein Thema sein.

Die Gestaltung einer technischen Dokumentation mit der Webtechnik ist ein ernst zunehmendes Thema und es wäre schade, wenn wegen einseitiger Sichtweisen die Elemente, die bisher ihre guten Dienste tun, aus dem Standard verschwinden würden.

Wieso sollten sie auch?

Das Framesets bisher nur als transitional eingestuft sind, halte ich für bedenklich.

Frames sind nicht Transitional. Frames sind Frames. Frames sind Markup, um eine Mehrdokumenten-Präsentation festzulegen. In diesem Sinne sind sie nicht »Strict«, weil sie eben die Ausgabe beeinflussen. Daher ist etwa das target-Attribut nicht in Strict.

Die angeblichen Probleme mit Frames beruhen IMHO auf nicht ausgereifter Umsetzung bei den Browsern.

Nicht die grundlegenden Probleme. Diese beruhen vor allem darauf, dass die Frametechnik konzeptionelle Schwächen hat.

Das Kind mit dem Bade ausschütten zu wollen, so wie es auf verschiedenen Sites zu lesen ist, mit der Maßgabe Frames ganz abschaffen zu wollen

Du hast dich nicht wirklich in die Frames-Diskussion eingelesen, oder?
Mit XFrames werden Frames weiterentwickelt.

Die angeblichen Probleme mit Frames lassen sich heute alle mit Bordmitteln lösen, da bedarf es keines Hacks

Das ist wirklich falsch, weil XFrames gerade die Probleme aus der Welt schaffen will, die bei HTML-Frames eben nur durch umständliche Hacks gelöst werden konnten.

Es wird IMHO aber nie möglich sein, eine Webpages im Sinne eine eierlegenden Wollmilchsau für alle Plattformen erstellen zu können.

»Man kann nicht alle unterstützen, ein bisschen Schwund ist immer« - toller Spruch, den man immer wieder von Leuten zu hören bekommt, die im Grunde genommen keine Lust haben, sich mit Accessibility zu beschäftigen. Nichts gegen eine Scheißegal-Haltung, meinetwegen, aber diese Binsenweisheit taugt nicht zu einer Rechtfertigung der unbekümmerten Technikverwendung.

Man wird sich Gedanken machen müssen, wie man Minderheiten besser versorgt und technische Möglichkeiten errichtet, die diesen speziellen Zwecken dienen.

Nichts anderes ist die Beschäftigung mit der Frage, wie man eine Seite alternativ auch für diejenigen zugänglich macht, die mit der Frames-Technik weniger effzient arbeiten können (aufgrund welcher Voraussetzungen auch immer, nicht nur technischer).

Das ist IMHO besser, als den kleinsten gemeinsamen Nenner zu suchen, wobei andere sinnvolle Techniken aufgegeben werden.

Wieso kramst du diesen Mythos vom kleinsten gemeinsamen Nenner heraus? Abwärtskompatibilität (»graceful degradation«) ist das Stichwort. Das bedeutet jedem das Seine, nicht allen dasselbe.

Im Großen und Ganzen scheinst du dich nicht besonders tief mit der Debatte rund um den Frameeinsatz beschäftigt zu haben, besteht dein Beitrag doch weitesgehend aus alten Phrasen und keinen handfesten Argumenten oder Widerlegungen. Im Forumsarchiv gab es dazu einige aufschlussreiche Diskussionen. Vielleicht beschäftigst du dich erst einmal damit, was Frame-Kritiker und JavaScript-Kritiker überhaupt für Positionen vertreten, bevor du sie mal eben im vorbeigehen mit den üblichen Klischeevorwürfen niederbügelst.

Mathias

[Christian Kruse]

你好 fireeye,

Doch niemand würde allen Ernstes behaupten wollen, es sollte i.e. für
Blinde die Barriere zum Autofahren demontiert werden, zumindest jetzt
noch nicht, da entsprechender technischer Ersatz für die menschliche
Sehfähigkeit noch nicht in ausreichender Qualität zur Verfügung steht.

Das ist der berühmte hinkende Vergleich ;-) Die technischen
Vorraussetzungen für Blinde existieren, anders als im Strassenverkehr.

Der Ausschluß anderer, die nicht zu diesen Zielgruppen gehören, liegt
oft in der Natur der Sache und bedeutet dabei keineswegs eine
Diskriminerung.

Der Zusammenhang zwischen technischen Gegebenheiten und Zielgruppe ist
aber idR nicht gegeben ;-) Natürlich gibt es Ausnahmen, aber es bleiben
Ausnahmen. Bestes Beispiel: ich schaue mir gerne die Seiten von Bands an,
die fast immer “Zielgruppenoptimiert” im negativen Sinn des Wortes sind.
Insofern gehöre ich offensichtlich zur Zielgruppe ;-) Ich habe allerdings
nischte mit den technischen Vorraussetzungen eines 0-8-15-Users gemeinsam.
Ich nutze einen anderen Browser und ein anderes Betriebssystem. Der
Zusammenhang zwischen technischen Vorraussetzungen und Zielgruppe ist
schlicht nicht vorhanden ;-) Die Welt ist bunter, als du denkst!

Auch der Hinweis darauf, Javascript zu vermeiden, weil es gute Gründe
gegen die Verwendung von Javascript geben würde, wobei die Kritiker
jedes mal die Begründung der angeblich gute Gründe schuldig bleiben, ist
für mich sehr weit hergeholt.

Ich habe hier noch keinen getroffen, der gesagt hat, man solle auf JS
verzichten ;-) Ich tus ja selber nicht, das Forum nutzt an einigen Stellen
ziemlich exzessiv JS. Es sollte nur auch ohne JS laufen.

Die Gestaltung einer technischen Dokumentation mit der Webtechnik ist ein
ernst zunehmendes Thema und es wäre schade, wenn wegen einseitiger
Sichtweisen die Elemente, die bisher ihre guten Dienste tun, aus dem
Standard verschwinden würden. Das Framesets bisher nur als transitional
eingestuft sind, halte ich für bedenklich.

Dass du dich nicht sonderlich viel mit der Diskussion beschäftigt hast,
wurde dir ja schon mehrfach eröffnet ;-)

Die angeblichen Probleme mit Frames lassen sich heute alle mit Bordmitteln
lösen, [...]

Ganz ehrlich: das bezweifle ich ernsthaft. Das erstbeste Beispiel ist die
Zwei-Frames-Frage; ohne JS nicht zu lösen. Dass etwas auch ohne JS
funktionieren sollte, hatten wir ja schon... ;-) Warum? Weil es durchaus
Nutzer gibt, die gezwungen sind, JS-lose Clients einzusetzen. Man betrachte
die diversen Sicherheitsprobleme, die bei gewissen UAs durch JS entstehen,
und man hat auch ein Verständnis dafür ;-) Andere wollen JS nicht nutzen,
weil es viele Leute gibt, die JS missbrauchen.

Es wird IMHO aber nie möglich sein, eine Webpages im Sinne eine
eierlegenden Wollmilchsau für alle Plattformen erstellen zu können.

Des ist Humbug. Für genau diesen Zweck wurde HTML entwickelt, und es
erfüllt diesen Zweck sehr gut ;-) Man muss sich schon krampfhaft anstrengen,
um eine HTML-Seite plattformabhängig zu machen -- ich habe das noch nicht
geschafft, erklär mir doch mal, wie das gehen soll.

Das ist IMHO besser, als den kleinsten gemeinsamen Nenner zu suchen,
wobei andere sinnvolle Techniken aufgegeben werden.

Hehe, typisches Null-Argument. Der kleinste gemeinsame Nenner heisst nicht,
auf Techniken zu verzichten, sondern sie so einzusetzen, dass die
Funktionalität nicht von ihr abhängt ;-)

再见,
克里斯蒂安

[Sven Rautenberg]

Moin!

Die angeblichen Probleme mit Frames lassen sich heute alle mit Bordmitteln
lösen, [...]

Ganz ehrlich: das bezweifle ich ernsthaft. Das erstbeste Beispiel ist die
Zwei-Frames-Frage; ohne JS nicht zu lösen.

Das ist ohne JS lösbar, einfach ein neues Frameset laden mit target="_top". Dann entstünde in der URL-Zeile sogar eine neue, bookmarkbare Adresse, welche direkt zur gewünschten Information führt. Trotzdem hat man die Problematik, dass Suchmaschinen nur die enthaltenen Seiten auffinden und in ihren Ergebnissen anzeigen, also muß man noch "Frameset nachladen" einbauen - auch wieder nur per JS lösbar, oder man setzt in die Inhaltsseite einen meist überflüssigen HTML-Link auf das Frameset rein.

Aber sowas will dann ja auch wieder niemand machen von den Seitenerstellern, weil der administrative Aufwand für diese vernünftige Ausgestaltung der Nutzung von Framesets dann doch extrem hoch ist. Ohne Framesets ist er jedenfalls nennenswert geringer.

Jedenfalls wurden Framesets nicht erfunden, damit Seitenersteller, welche auf ihrem Webspace keinerlei Skriptmöglichkeiten haben, und deren HTML-Editor auch keine entsprechende Funktionalität hat, es sich sparen können, ihre Navigation manuell in jede ihrer Seiten ändern zu müssen. Aber genau so werden sie in der überwiegenden Zahl der Anwendungen genutzt.

• Sven Rautenberg

[fireeye]

Hi 再见,
克里斯蒂安

Es wird IMHO aber nie möglich sein, eine Webpages im Sinne eine
eierlegenden Wollmilchsau für alle Plattformen erstellen zu können.

Des ist Humbug. Für genau diesen Zweck wurde HTML entwickelt, und es
erfüllt diesen Zweck sehr gut ;-) Man muss sich schon krampfhaft anstrengen,
um eine HTML-Seite plattformabhängig zu machen -- ich habe das noch nicht
geschafft, erklär mir doch mal, wie das gehen soll.

»»
Das steht aber im krassen Gegensatz zu der Aussage auf einer Seite, die Argumente vorbringt, i.e Frames wären nicht für PDA geeignet, was ich auch einzusehen vermag. Die Frames dann aber deswegen gleich aus dem Verkehr ziehen wollen??? Meine Einwendungen beziehen sich aber auf Webpages, die nicht für PDAs gemacht sind, ich kann mir die sinnvolle Darstellung meines Projektes auf dem PDA nicht vorstellen. Deswegen ist für mich die Diskussion um die Portabilität an dieser Stelle schlicht eine Nonsensdiskussion. Der ideale Gedanke um HTML bleibt auch nur ein IDEAL, solange nicht alle Hersteller von Useragent auch nur ein akzeptables Maß bei der Umsetzung des Webstandarts erreichen. Ich habe in den letzten Tagen i.e. <colgroup> aus meinen Seiten herausgenommen, weil es bei einigen Useragents eine unsichere Implementierung vorliegt.

»»

Das ist IMHO besser, als den kleinsten gemeinsamen Nenner zu suchen,
wobei andere sinnvolle Techniken aufgegeben werden.

Hehe, typisches Null-Argument. Der kleinste gemeinsame Nenner heisst nicht,
auf Techniken zu verzichten, sondern sie so einzusetzen, dass die
Funktionalität nicht von ihr abhängt ;-)

»»
Kommt darauf an, wie jeder den kleinsten Nenner für sich definiert. Eine Technik ist immer mit einer Funktionalität verbunden.. aber der Rest siehe oben.

Gruß f

[Struppi]

.... Die Frames dann aber deswegen gleich aus dem Verkehr ziehen wollen??? Meine Einwendungen beziehen sich aber auf Webpages, die nicht für PDAs gemacht sind, ich kann mir die sinnvolle Darstellung meines Projektes auf dem PDA nicht vorstellen. Deswegen ist für mich die Diskussion um die Portabilität an dieser Stelle schlicht eine Nonsensdiskussion. ....

1. Frames werden nicht abgeschaftt, durch ständiges wiederholen dieser falschen Information wird sie nicht richtiger?
2. Du bist 100% sicher dass in der Firma für die du die Doku erstellst nächstes oder übernächstes Jahr nicht jeder Mitarbeiter einen PDA bekommt?

Struppi.

[fireeye]

Hi Struppi

1. Frames werden nicht abgeschaftt, durch ständiges wiederholen dieser falschen Information wird sie nicht richtiger?

Hierzu siehe

2. Du bist 100% sicher dass in der Firma für die du die Doku erstellst nächstes oder übernächstes Jahr nicht jeder Mitarbeiter einen PDA bekommt?

Ganz sicher kann ich mir da nicht sein, aber ich habe teilweise eingescannte Zeichnungen im A2- oder A3-Format, da wird man auf einem PDA wenig mit anfangen können!

Gruß f

[Struppi]

2. Du bist 100% sicher dass in der Firma für die du die Doku erstellst nächstes oder übernächstes Jahr nicht jeder Mitarbeiter einen PDA bekommt?
   Ganz sicher kann ich mir da nicht sein, aber ich habe teilweise eingescannte Zeichnungen im A2- oder A3-Format, da wird man auf einem PDA wenig mit anfangen können!

Damit schränkst du den Nutzerkreis ein, das ist doch völlig normal. Wenn ich Filme auf meiner Seite anbiete kann die jemand ohne Plugin nicht sehen.

D.h. wenn du Inhalte hast, die gewisse Technische Vorraussetzungen benötigen (z.b. bei dir einen entsprechend grossen Monitor) dann ist die Zielgruppe per Definition eingeschränkt. Wenn du aber eine Technik benutzt die nur unter bestimmten Vorrausetzungen funktioniert, obwohl es Möglichkeiten gäbe dies anders umzusetzen, dann ist dies deine Entscheidung die Zielgruppe einzuschränken. Und diese Einschränkung wird hier gerne Hinterfragt.

Aber es gibt schon einen Grund warum du HTML nutzt und nicht z.b. word Dokumente mit denen du Inhalte oft wesentlich besser präsentieren kannst. Warum brichst du keine Lanze für Word Dokumente?

Struppi.

[fireeye]

Hi Struppi

Aber es gibt schon einen Grund warum du HTML nutzt und nicht z.b. word Dokumente mit denen du Inhalte oft wesentlich besser präsentieren kannst. Warum brichst du keine Lanze für Word Dokumente?

»»

Hab ich jahrelang mit Word&Co gemacht. Word bietet auch Verlinkungen an,  aber das ist nichts gegen die Möglichkeiten, die sich mit der HTML-Technik bieten.

Gruß f

[Struppi]

Hab ich jahrelang mit Word&Co gemacht. Word bietet auch Verlinkungen an,  aber das ist nichts gegen die Möglichkeiten, die sich mit der HTML-Technik bieten.

Eben, und diese Vorteile werden teilweise durch die Framestechnik zunichte gemacht. Deshalb sind sie nur bedingt zu empfehlen.

Struppi.

[xwolf]

Hi,

Ich glaub, wenn ich mal ein paar Sätze zusammenfasse, treffen wir eher auf das Problem:

Es wird IMHO aber nie möglich sein, eine Webpages im Sinne eine
eierlegenden Wollmilchsau für alle Plattformen erstellen zu können.

erfüllt diesen Zweck sehr gut ;-) Man muss sich schon krampfhaft anstrengen,
um eine HTML-Seite plattformabhängig zu machen

...ich kann mir die sinnvolle Darstellung meines Projektes auf dem PDA nicht vorstellen.

Gemerkt?
Das Problem ist *NICHT* die Technik.
Jede Technik hat seine Berechtigung und richtig eingesetzt leistet sie was sie soll und meist noch mehr.

Das Problem liegt eher im Selbstverständnis und der Sichtweise der Macher und Auftraggeber.

Nur weil *du* dir *jetzt* keinen Nutzen vorstellen kannst, warum es gut ist, eine Website Plattform und Browserunabhängig zu bauen, heisst das nicht, daß andere es genauso sehen. Und erst recht nicht entspricht die subjektive Meinung eines Webmasters und dessen Auftraggebers der vollen Wahrheit.

Wie oben richtig gesagt, ist richtig angewendetes HTML, oder noch besser XHTML strict, sowohl plattform, als auch browserunabhängig.
Das solltest du dir mal durchdenken, was dies bedeutet!

Es ist schlichtweg wurscht, was kommt. Ob jemand mit dem IE6, IE5, Opera, Palm, Nokia Webbrowser oder Lynx auf die Seiten kommt - für alle sind die Inhalte lesbar.
Ob sinnvoll oder nicht? Weisst du wirklich was die Zukunft bringt?
Möchtest du im Sommer, wenn der IE7 rauskommt und der Support für Win95 eingestellt wird, gezwungen sein, den Webauftritt schon wieder anzupassen?

Aber auch ein anderen Aspekt solltest du nicht ausser Acht lassen: Du und dein Auftraggeber habt den Tunnelblick! Oder um es anders zu sagen (so hab ich es auch  meinen Kollegen gesagt wo wir unsere Site neu gebaut haben):
"Wir vom RRZE sind etwa 60 Mitarbeiter. Unsere Website wird jedoch täglich von ein paar Hundert verschiedenen externen Leuten abgerufen. Das sind unsere Kunden. Was ist also die Meinung und die Vorstellung von 60 Leuten wert, dem die Bedürfnisse von ein paar Tausend (bei uns 34000) Kunden gegenüber stehen?"

Valides HTML, die strenge Umsetzung von Barrierefreiheit und die Nutzung geeigneter Verwaltungssysteme ist eigentlich was für Faule.
Ich hab einen Webauftritt nach diesen Prinzipien gebaut und darf mich jetzt auf die faule Haut liegen, komme was da wolle.
Soll der IE7 doch ruhig ein neues properitäres Format für die Umsetzung runder Ecken einführen, soll er doch die RSS/RDF-Syntax verschandeln - mich braucht es nicht mehr zu jucken.

Wer dagegen auf die "traditionellen" Weg des HTML-Bastelns wert legt und auf spezielle Browser und spezielle Betriebsumgebungen optimiert, darf sich auch freuen - es gibt immer was zu tun >:))

(Hey wow - das ist ein Konzept um Arbeitsplatzsicherheit ohne nervige Gewerkschaften einzuführen: Baue eine Website, die so mies ist, daß sie bei jedem Browserupdate angepasst wreden muss)

Ciao,
  Wolfgang

[Klawischnigg]

Hi there,

Wie oben richtig gesagt, ist richtig angewendetes HTML, oder noch besser XHTML strict, sowohl plattform, als auch browserunabhängig.

wirklich schade, daß das die Browserhersteller noch nicht wissen. Aber Du darfst Dir ja trotzdem einen "wc3 geprüft" oder "valide" Button auf alle Deine Seite nageln...

[Struppi]

Wie oben richtig gesagt, ist richtig angewendetes HTML, oder noch besser XHTML strict, sowohl plattform, als auch browserunabhängig.

wirklich schade, daß das die Browserhersteller noch nicht wissen. Aber Du darfst Dir ja trotzdem einen "wc3 geprüft" oder "valide" Button auf alle Deine Seite nageln...

Deine Argumente sind sehr überzegend.

(ich wüßte noch nicht mal wofür du hier argumentierst: Dafür möglichst unvalide Seiten zu bauen und HTML möglichst falsch anzuwenden und altmodische Techniken zu verwenden, weil du mit den anderen Techniken nicht zurecht kommst?)

Struppi.

[Klawischnigg]

Hi there,

Deine Argumente sind sehr überzegend.

Ich würde sagen, im Falle von "Browserunabhängigkeit" ist eine nicht von allen Browser gleich umgesetzte Funktionalität ein ziemlich gutes Argument.

(ich wüßte noch nicht mal wofür du hier argumentierst: Dafür möglichst unvalide Seiten zu bauen und HTML möglichst falsch anzuwenden und altmodische Techniken zu verwenden, weil du mit den anderen Techniken nicht zurecht kommst?)

Fein, bleiben wir persönlich. Auch wenn es Dich nichts angeht, kann ich Dir versichern, daß meine Fähigkeit, gegenständliche Techniken richtig anzuwenden, mit meiner Kritik am religionsähnlichen Herbeten irgendwelcher Validitätsempfehlungen nichts zu tun hat. Eine Seite muß in möglichst vielen Browsern funktionieren und den Kunden soweit zufriedenstellen, daß er die dafür ausgemachte Summe auch bezahlt. Alles andere mag vielleicht als theorethische Erörterung des reinen, wahren und guten Webseiteerstellens sendungsbewusste Heimseitenbastler ergötzen, für alle anderen scheint es mir ziemlich uninteressant.

Aber Du kannst in diesem Sinne ja gerne vorangehen und einen neuen Button kreiern; sowas von in der Art "Valide und Tabellenfrei", "strict neumodisch" oder besser noch "valide und nur neumodische Technik". Der Dank der interessierten Heimseitenbastlergemeinde wird Dir gewiß sein...

[Struppi]

Deine Argumente sind sehr überzegend.

Ich würde sagen, im Falle von "Browserunabhängigkeit" ist eine nicht von allen Browser gleich umgesetzte Funktionalität ein ziemlich gutes Argument.

Der Einsatz von CSS schränkt ja nicht die Funktionalität ein. Was du meinst, dass ein bestimmtes Layoutkonzept nur mit Tabellen in allen Browsern umgesetzt wird. Doch letztlich hat das nichts mit Funktionalität zu tun.

(ich wüßte noch nicht mal wofür du hier argumentierst: Dafür möglichst unvalide Seiten zu bauen und HTML möglichst falsch anzuwenden und altmodische Techniken zu verwenden, weil du mit den anderen Techniken nicht zurecht kommst?)

.... kann ich Dir versichern, daß meine Fähigkeit, gegenständliche Techniken richtig anzuwenden, mit meiner Kritik am religionsähnlichen Herbeten irgendwelcher Validitätsempfehlungen nichts zu tun hat

Du bist auf dem falschen Dampfer, keiner beten irgendwas daher. Aber jemanden der mit Problemen hier ankommt zu empfehlen erstmal grobe Fehler zu beseitigen ist der erste Schritt einen Mangel zu beheben helfen.

»Eine Seite muß in möglichst vielen Browsern funktionieren und den Kunden soweit zufriedenstellen, daß er die dafür ausgemachte Summe auch bezahlt. Alles andere mag vielleicht als theorethische Erörterung des reinen, wahren und guten Webseiteerstellens sendungsbewusste Heimseitenbastler ergötzen, für alle anderen scheint es mir ziemlich uninteressant.

Ja stimmt, aber wenn ein Layoutkonzept schon derart mangelhaft ist, dass es sich mit CSS nur mit Krampf umsetzen läßt, sollte man sich zumindest Gedanken machen ob es nicht sinnvoller ist ein Layout zu entwickeln, mit denen sich die Vorteile dieser Technik nutzen lassen. Wenn man das nicht mag, ist dein Weg sicher der einzig Richtige.

Aber Du kannst in diesem Sinne ja gerne vorangehen und einen neuen Button kreiern; sowas von in der Art "Valide und Tabellenfrei", "strict neumodisch" oder besser noch "valide und nur neumodische Technik". Der Dank der interessierten Heimseitenbastlergemeinde wird Dir gewiß sein...

Danke.
Aber ich fahre durchaus aber zweigleisig, was bei geschicktem Einsatz der Technik auch so gut wie kein Aufwand ist. Dort ist CSS die Standardseite, die dadurch sehr flexibel gesteuert werden kann, jedes Element kann an einem x- beliebig platziert werden. Gleichzeitig ist aber möglich mit einem Parameter eine Tabelle zu generieren, die Browser der Netscape 4 und IE 4 Generation die volle Funktionalität erhalten.

Was mir aber nicht einleuchtet bei deiner Argumentation - bzw. fast schon Hetze - ist, was an validen Seiten so furchtbar schlimm sein soll. Du hast keinerlei Nachteile dadurch. Ich nehme an dass du auch programmierst - dort bedeutet nicht Validität einen Syntaxfehler, warum soll es also irgendein Nachteil sein in HTML ebenfalls gewisse Regeln einzuhalten? Zumal dies eine Entwicklung ist die ja noch verschärft wird durch XHTML, du also früher oder später gar nicht mehr drumherum kommen wirst Strukturregeln genau einzuhalten.

Es ist nicht so dass hier irgendjemand, wie von dir behauptet, religionsähnlich den Einsatz von CSS propagiert, sondern er ist zu empfehlen da sich damit wesentlich leichter und flexibler Arbeiten läßt.

Mein Eindruck ist eher dass die Tabellenverfechter eine gewissen Dogmatismus entwickelt haben, der jedes Argument für den Einsatz von CSS und den Verzicht von Tabellen als Layoutmittel, Teufelswerk deklariert.

Trotzdem wirst du hier immer wieder die Aussage hören, dass wenn jemand sich von seinen Tabellen Layoutvorstellungen nicht lösen mag, er lieber Tabellen einsetzen soll, als mit CSS rumzumurksen. Denn wer nicht in der Lage ist seine Vorstellungen an die Möglichkeiten einer Technik anzupassen ist auch nicht in der Lage sie richtig zu nutzen.

Struppi.

[Klawischnigg]

Hi there,

Der Einsatz von CSS schränkt ja nicht die Funktionalität ein. Was du meinst, dass ein bestimmtes Layoutkonzept nur mit Tabellen in allen Browsern umgesetzt wird. Doch letztlich hat das nichts mit Funktionalität zu tun.

Es ging aber nicht um CSS, sondern xwolf hat behauptet, daß die Verwendung von "Xhtml strict" Plattform- und Browserunabhängigkeit bedeutet und das ist einfach nicht wahr, das wird auch mit IE8 oder IE irgendwas nicht wahrer werden.

Du bist auf dem falschen Dampfer, keiner beten irgendwas daher. Aber jemanden der mit Problemen hier ankommt zu empfehlen erstmal grobe Fehler zu beseitigen ist der erste Schritt einen Mangel zu beheben helfen.

Es geht aber nicht darum, was hier passiert oder wer mit Problemen hier ankommt, sondern darum, ob Validität einen Wert an sich darstellt.

Aber ich fahre durchaus aber zweigleisig, was bei geschicktem Einsatz der Technik auch so gut wie kein Aufwand ist. Dort ist CSS die Standardseite, die dadurch sehr flexibel gesteuert werden kann, jedes Element kann an einem x- beliebig platziert werden. Gleichzeitig ist aber möglich mit einem Parameter eine Tabelle zu generieren, die Browser der Netscape 4 und IE 4 Generation die volle Funktionalität erhalten.

Ja, und? Wenn's jemand bezahlt, für Browser der 4. Generation Tabellen zu generieren, warum nicht?

Was mir aber nicht einleuchtet bei deiner Argumentation - bzw. fast schon Hetze - ist, was an validen Seiten so furchtbar schlimm sein soll.

Gar nichts, und ich hetze nicht. Eine Seite muß funktionieren. Tut sie das, kann sie auch valide sein, interessiert doch niemanden. Was ich, und das fern jeder Hetze, kritisiere, ist der Umstand, daß der Validität ein Wert an sich zugemessen wird. Und das ist lächerlich. Ich lese hier immer wieder Postings von "verzweifelten" Pageerstellern, die viel Zeit damit verbraten, irgendwelche Seiten valide zu gestalten, die an sich ohnehin funktionieren; Leute, die sich haareraufend daran stören, daß ein </p> Tag in html soundso anders validiert als in xhtml. Dem die Spitze aufgesetzt hat die Nachfrage eines Posters, wie er denn seine Kunden dazu bringen könnte, ihn dafür zu bezahlen, daß er alle ihre Seite auf strict xhtml bringt. Das kritisiere ich, wie gesagt, mitnichten hetzenderweise.

Du hast keinerlei Nachteile dadurch. Ich nehme an dass du auch programmierst - dort bedeutet nicht Validität einen Syntaxfehler, warum soll es also irgendein Nachteil sein in HTML ebenfalls gewisse Regeln einzuhalten?

Nein, Validität ist nicht die Absenz von Syntaxfehlern sondern das Anwenden eines schöneren, von mir aus besseren Programierstils. Nur manchmal gehts auch beim Programmieren nur quick and dirty.
Und es ist kein Nachteil. Regeln muß man am Rechner immer einhalten. Ich habe interessenshalber einige meiner Seiten durch den Validator gejagt; bei sicher mehr als 90% gab es keine "Beanstandungen". Nur, wie gesagt, daß ist mir sch***egal solange es rennt.

Zumal dies eine Entwicklung ist die ja noch verschärft wird durch XHTML, du also früher oder später gar nicht mehr drumherum kommen wirst Strukturregeln genau einzuhalten.

Und? Dagegen spricht ja nix.

Mein Eindruck ist eher dass die Tabellenverfechter eine gewissen Dogmatismus entwickelt haben, der jedes Argument für den Einsatz von CSS und den Verzicht von Tabellen als Layoutmittel, Teufelswerk deklariert.

Kann ja sein, aber was hat das mit mir zu tun? Mir sind Tabellen genauso wurscht wie Validität. Wichtig ist, wie lange die Erstellung einer Seite benötigt. Das kann mal so, mal so schneller sein. Ich mach auch keine Seiten speziell für jene, die sich unbedingt den Quelltext anschauen müssen, um eine Seite beurteilen zu können. Sollen sie ruhig, aber dafür werd' ich keine Zeile Code ändern.

Trotzdem wirst du hier immer wieder die Aussage hören, dass wenn jemand sich von seinen Tabellen Layoutvorstellungen nicht lösen mag, er lieber Tabellen einsetzen soll, als mit CSS rumzumurksen. Denn wer nicht in der Lage ist seine Vorstellungen an die Möglichkeiten einer Technik anzupassen ist auch nicht in der Lage sie richtig zu nutzen.

Das ist ein Pragmatismus, den ich durchaus verstehe...

[at]

Hallo.

Nein, Validität ist nicht die Absenz von Syntaxfehlern sondern das Anwenden eines schöneren, von mir aus besseren Programierstils.

Dieses Missverständnis, auf dem vermutlich deine gesamte krude Argumentation beruht, kannst du sehr einfach ausräumen, indem du wie deine Vorgänger daran scheiterst, einen Validator für Stilfragen zu entwickeln.
MfG, at

[Klawischnigg]

Hi there,

Nein, Validität ist nicht die Absenz von Syntaxfehlern sondern das Anwenden eines schöneren, von mir aus besseren Programierstils.

Dieses Missverständnis, auf dem vermutlich deine gesamte krude Argumentation beruht, kannst du sehr einfach ausräumen, indem du wie deine Vorgänger daran scheiterst, einen Validator für Stilfragen zu entwickeln.

Sehr witzig. Vielleicht hab ich mich nicht klar genug ausgedrückt, aber das war in Analogie zur Programmierung gemeint. Desweiteren nehm ich an, daß Du mein Posting insoferne nicht gelesen hast, als Du dann hättest verstehen können, daß mir mitnichten etwas an der Entwicklung eines Validators für Stilfragen liegt. Ob Deine Kenntnis meines Postings soweit ausreicht, mir eine krude Argumentation zu bescheinigen, bleibt Dir überlassen...

[at]

Hallo.

Ob Deine Kenntnis meines Postings soweit ausreicht, mir eine krude Argumentation zu bescheinigen, bleibt Dir überlassen...

Natürlich, wem auch sonst?
MfG, at

[Cybaer]

Hi,

Eine Seite muß funktionieren. Tut sie das, kann sie auch valide sein, interessiert doch niemanden. Was ich, und das fern jeder Hetze, kritisiere, ist der Umstand, daß der Validität ein Wert an sich zugemessen wird. Und das ist lächerlich. Ich lese hier immer wieder Postings von "verzweifelten" Pageerstellern, die viel Zeit damit verbraten, irgendwelche Seiten valide zu gestalten, die an sich ohnehin funktionieren; Leute, die sich haareraufend daran stören, daß ein </p> Tag in html soundso anders validiert als in xhtml. Dem die Spitze aufgesetzt hat die Nachfrage eines Posters, wie er denn seine Kunden dazu bringen könnte, ihn dafür zu bezahlen, daß er alle ihre Seite auf strict xhtml bringt. Das kritisiere ich, wie gesagt, mitnichten hetzenderweise.

Und auch sonst: Full ACK. ;-)

Gruß, Cybaer

[molily]

Hallo,

Was mir aber nicht einleuchtet bei deiner Argumentation - bzw. fast schon Hetze - ist, was an validen Seiten so furchtbar schlimm sein soll.

Gar nichts, und ich hetze nicht. Eine Seite muß funktionieren. Tut sie das, kann sie auch valide sein, interessiert doch niemanden. Was ich, und das fern jeder Hetze, kritisiere, ist der Umstand, daß der Validität ein Wert an sich zugemessen wird.

Ich verstehe nicht, in welchen Fällen eine nicht-valide Seite äquivalent funktioniert. Wenn ich mir so die gängigen Markupfehler vorstelle, fällt mir zu jedem eine Einschränkung der Funktionalität ein - und sei sie auch potenziell, weil man arg auf Fehlertoleranz baut und die zwei, drei Testbrowser es schlucken. Natürlich gibt es eine Reihe harmloser Abweichungen, die mitunter sogar die Kompatibilität verbessern können, aber da fallen mir nur wenige Beispiele ein. Ebensowenig fällt mir kein gängiger Markupfehler ein, aus dem man sonderliche Vorteile zieht und der einfacher ist als valider Code und gleichsam kompatibel.

Ich lese hier immer wieder Postings von "verzweifelten" Pageerstellern, die viel Zeit damit verbraten, irgendwelche Seiten valide zu gestalten, die an sich ohnehin funktionieren; Leute, die sich haareraufend daran stören, daß ein </p> Tag in html soundso anders validiert als in xhtml.

</p>-Tag anders validiert?

Dem die Spitze aufgesetzt hat die Nachfrage eines Posters, wie er denn seine Kunden dazu bringen könnte, ihn dafür zu bezahlen, daß er alle ihre Seite auf strict xhtml bringt.

Die Frage habe ich wohl nicht mitbekommen, was kritisierst du daran? Vielleicht sieht der Poster Vorteile für sich und das Projekt, Strict-Markup (also Präsentationslogik auszulagern) und XHTML (Verarbeitung durch XML-Werkzeuge) zu verwenden. Das müsste man näher untersuchen, bevor man urteilt.

Nein, Validität ist nicht die Absenz von Syntaxfehlern sondern das Anwenden eines schöneren, von mir aus besseren Programierstils. Nur manchmal gehts auch beim Programmieren nur quick and dirty.

Was genau bedeutet es denn, keinen guten Programmierstil einzuhalten und quick and dirty zu schreiben? Ich kann mir darunter nichts konkretes vorstellen. Logischerweise bedeutet es nicht, dass trotzdem alles optimal funktioniert? (Sonst wäre »besserer Programmierstil« zumindest eine Worthülse.)

Und es ist kein Nachteil. Regeln muß man am Rechner immer einhalten. Ich habe interessenshalber einige meiner Seiten durch den Validator gejagt; bei sicher mehr als 90% gab es keine "Beanstandungen". Nur, wie gesagt, daß ist mir sch***egal solange es rennt.

Was waren die restlichen 10% Beanstandungen?

Mathias

[Cybaer]

Hi,

Ich verstehe nicht, in welchen Fällen eine nicht-valide Seite äquivalent funktioniert.

Eine HTML-Tag mit einem nicht W3C-konformen Attribut funktioniert ebenso wie eine Seite mit einem nicht W3C-konformen HTML-Tag ggf. äquivalent (sofern es nicht einen Browser gibt, der das Tag/Attribut als valide gemäß seiner DTD ansieht - aber dann drügte das wohl auch gewollt sein).

Das ist ja nicht neu, dir schon gar nicht, und ...

Wenn ich mir so die gängigen Markupfehler vorstelle,

... nicht alles was, nach Meinung des W3C, nicht valide ist, ist ein Markupfehler.

Gruß, Cybaer

[molily]

Hallo,

Ich verstehe nicht, in welchen Fällen eine nicht-valide Seite äquivalent funktioniert.

Eine HTML-Tag mit einem nicht W3C-konformen Attribut funktioniert ebenso wie eine Seite mit einem nicht W3C-konformen HTML-Tag ggf. äquivalent (sofern es nicht einen Browser gibt, der das Tag/Attribut als valide gemäß seiner DTD ansieht - aber dann drügte das wohl auch gewollt sein).

Schon klar.
Solche Fälle habe ich mit »Natürlich gibt es eine Reihe harmloser Abweichungen, die mitunter sogar die Kompatibilität verbessern können« beschrieben. Wie gesagt fallen mir keine gewichtigen allgemeinen Beispiele ein. Allzu viele nicht-standardisierte, aber nützliche und kompatible Elemente gibt es nicht (vielleicht embed), an Attributen würden mir auf die Schnelle border bei frameset einfallen, autocomplete und dergleichen, height bei table zur Abwärtskompatibilität.
Ob Klawischnigg diese absichtlichen Abweichungen mit den 10% Beanstandungen meinte, die ihm egal sind, glaube ich eher nicht.

Das ist ja nicht neu, dir schon gar nicht, und ...

Wenn ich mir so die gängigen Markupfehler vorstelle,

... nicht alles was, nach Meinung des W3C, nicht valide ist, ist ein Markupfehler.

Ich rede von Validität als Konformität zum (X)HTML-Standard des W3Cs, im Speziellen heißt das DTD-Konformität. Demnach beinhaltet eine nicht-valide Seite Markupfehler. Ich weiß, »Validität gemäß der browsereigenen DTD« ist eine Lieblingsphantasie von dir.

Mathias

[Cybaer]

Hi,

Ich rede von Validität als Konformität zum (X)HTML-Standard des W3Cs, im Speziellen heißt das DTD-Konformität.

Im Speziellen heißt das wohl eher "Konformität zu den DTDs des W3C".

Demnach beinhaltet eine nicht-valide Seite Markupfehler. Ich weiß, »Validität gemäß der browsereigenen DTD« ist eine Lieblingsphantasie von dir.

Nein, *das* ist "Validität zu einer eigenen DTD"! :-))

Denn die "Browser-DTDs" unterscheiden sich ja halt von Browser zu Browser, von Hersteller zu Hersteller.

Gruß, Cybaer

[xwolf]

Hi,

Wie oben richtig gesagt, ist richtig angewendetes HTML, oder noch besser XHTML strict, sowohl plattform, als auch browserunabhängig.

wirklich schade, daß das die Browserhersteller noch nicht wissen. Aber Du darfst Dir ja trotzdem einen "wc3 geprüft" oder "valide" Button auf alle Deine Seite nageln...

Könnte ich, aber mit den Papperln auf jeder Seite macht man sich nur lächerlich.
Das folgende jedoch ist schon nicht so leicht zu kriegen:
"Nominiert für den Deutschen Multimedia Award 2005"
(Du darfst selbst rausbekommen, welche Site, die von mir betreut und aufgebaut wurde, da gemeint ist. Tipp: Es ist nicht der Preis um die skurrielste Site)

Wer ist hier der Bastler? :)

Ciao,
  Wolfgang

[at]

Hallo.

"Nominiert für den Deutschen Multimedia Award 2005"

Ist das der Preis, dessen Gewinner hier alljährlich oft völlig zu Recht der Lächerlichkeit preisgegeben werden?
MfG, at

[xwolf]

Hi,

"Nominiert für den Deutschen Multimedia Award 2005"

Ist das der Preis, dessen Gewinner hier alljährlich oft völlig zu Recht der

Weder das eine, noch das andere würe ich bestätigen wollen :=)

Aber ich gebe dir recht, daß es sich oft um Preisträger a la "Branche feiert sich selbst" handelt. In meinen Fall gehören wir nicht der Branche an und die Vorauswahl wurde nach einen harten Vortest nach jedem nachvollziebaren Kriterien gemacht. (BITVTest).

Ciao,
  Wolfgang

[at]

Hallo.
Schön, dass du erkannt hast, dass die Aussage nicht gegen dich gerichtet war. Im Gegenteil: Gratulation zur Nominierung!
MfG, at

[fireeye]

Hi

Aber ich gebe dir recht, daß es sich oft um Preisträger a la "Branche feiert sich selbst" handelt. ....

Sicher lustig....schön, daß die Seiten auch alle valide sind und ansonsten barrierefrei???? alles Seiten mit dem Anspruch auf einen Award???? :-((
Frames vor ever, aber auch Contentseiten sind nicht ohne Fehler, wie man leicht herausfinden kann.....
Und hier
Frames zur Weiterleitung noch nicht mal valide, aber das gleiche
nochmal in Reinstkultur und auch nicht besser....
Es gibt aber auch valide Seiten.
Ich habe nicht alles getestet, das ist mir die Mühe nicht wert. Mir bestätigt aber dieser kurze Ausflug die Kluft zwischen Anspruch und Wirklichtkeit, die alle Dogmatiker in ihren Kellern als Leiche vergraben haben.

Na ja, ich glaub eben halt nicht alles, was mir zu predigen versucht.

Gruß f

[Biesterfeld]

Hej,

Es gibt aber auch valide Seiten.

Lieber unvalide aber dafür zieht sich die Maus in der rechten Bildhälfte auf Kommando aus, als eine biedere valide Seite mit noch biederer Maus.

*g*

Beste Grüße
Biesterfeld

[fireeye]

Hej

biederer Maus hast du gesagt....

ansonsten full ack und *g*

Gruß f

[Marc Reichelt]

Hallo CK,

Hehe, typisches Null-Argument. Der kleinste gemeinsame Nenner heisst nicht,
auf Techniken zu verzichten, sondern sie so einzusetzen, dass die
Funktionalität nicht von ihr abhängt ;-)

Kann es sein, dass du soeben den Rekord in diesem Forum gebrochen hast, möglichst viele Zwinker-Smilies zu setzen?

Der Inhalt deines Posts war ansonsten inhaltlich sehr gut, so wie ich es von dir gewohnt bin. Aber nur als kleiner Tipp:
Weniger (an Smilies) ist manchmal mehr!

;-)

Gute Nacht

Marc *SCNR* Reichelt || http://www.marcreichelt.de/

[Ashura]

puts "Hallo " + gets.chomp + "."

?> Marc
=> Hallo Marc.

Kann es sein, dass du soeben den Rekord in diesem Forum gebrochen hast, möglichst viele Zwinker-Smilies zu setzen?

Ich wollte dir hier ein schönes Suchergebnis der Archivsuche präsentieren, doch leider tut sich mit folgender RegEx nichts:

/((.*)?;-\)(.*)?){10,}/
-> Suche nach „Irgendwas, ;-), irgendwas“, , mindestens 10 Treffer

Steckt hier ein Fehler?

Gruß, Ashura

[Alexander Brock]

Hallo Freunde des gehobenen Forumsgenußes,

Kann es sein, dass du soeben den Rekord in diesem Forum gebrochen hast, möglichst viele Zwinker-Smilies zu setzen?

Auszug aus einer Häufigkeits-Analyse:

[die]   => 10
[;-)]   => 10
[nicht] => 9
[ich]   => 8
[js]    => 8
[es]    => 6
[das]   => 6
[ist]   => 6
[der]   => 6
[und]   => 5

;-)

function html_indexer($html) {
while ($html != strip_tags($html)) {
  $html = strip_tags($html);
}
$html = strtolower($html);
$entities = array(
'&lt;','&gt;','&amp;','&auml;','&Auml;','&ouml;','&Ouml;','&uuml;','&Uuml;','&nbsp;','&quot;');
$chars    = array(
'<'   ,'>'   ,'&'    ,'ä'     ,'Ä'     ,'ö'     ,'Ö'     ,'ü'     ,'Ü'     ,' '     ,'"');
$html = str_replace($entities, $chars, $html);
#$html = preg_replace('#[^a-zA-ZäöüÄÖÜß]#', ' ', $html);
$badwords = array (
'der','die','das','wer','wie','was','und','man','den','zu','an','ich','ist','des','bei',
'auf','für','in','von','einen','nicht','mit','um','eigene','aber','über','bzw','auf','unter',
'ein','hier'

);
#foreach ($badwords as $badword) {

$html = str_replace(' '.$badword.'',' ',$html);

#}
$html = preg_replace('#\s+#', ' ', $html);
$html = preg_replace('#^\s|\s$#', '', $html);
$html = preg_replace('#[.:,;!"?]\s#', ' ', $html);
$array = array_count_values(explode(' ', $html));
arsort($array, SORT_NUMERIC);
return $array;
}

Gruß
Alexander Brock

[Cybaer]

Hi,

Ganz ehrlich: das bezweifle ich ernsthaft. Das erstbeste Beispiel ist die
Zwei-Frames-Frage; ohne JS nicht zu lösen.

Oh, ich mache dann einfach einen Link auf ein FS, welches die beiden gewünschten Frames enthält. Funktioniert garantiert auch ohne JS ... =:-)

Gruß, Cybaer

[Struppi]

Ganz ehrlich: das bezweifle ich ernsthaft. Das erstbeste Beispiel ist die
Zwei-Frames-Frage; ohne JS nicht zu lösen.

Oh, ich mache dann einfach einen Link auf ein FS, welches die beiden gewünschten Frames enthält. Funktioniert garantiert auch ohne JS ... =:-)

Womit du aber nicht die Inhalte zweier Frames änderst, sondern nur eines.

Inklusive eines Mehraufwandes durch die zusätzliche Erzeugung einer Inhaltsleeren Seite.
(ich weiß, ich weiß, die Beseitigung von Nachteilen ist für dich kein Mehraufwand, sondern lediglich eine technische Erforderlichkeit, um eine Technik richtig zu benutzen wodurch sie dann auch - folgerichtig - keine Nachteile mehr hat)

Struppi.

[Cybaer]

Hi,

Womit du aber nicht die Inhalte zweier Frames änderst, sondern nur eines ...

... Framesets mit den beiden zu ändernden Frames. Sach ich doch. :)

Inklusive eines Mehraufwandes durch die zusätzliche Erzeugung einer Inhaltsleeren Seite.

Was interessiert es mich, was mein mod_rewrite-PHP an Seiten "erzeugt" (bzw. dem Browser vorgaukelt, sie wäre vorhanden)? Hauptsache, ich werde damit nicht persönlich belastet! =:->

(ich weiß, ich weiß, die Beseitigung von Nachteilen ist für dich kein Mehraufwand, sondern lediglich eine technische Erforderlichkeit, um eine Technik richtig zu benutzen wodurch sie dann auch - folgerichtig - keine Nachteile mehr hat)

Das siehst Du richtig. Wer JavaScript nutzen will, der sollte eben auch NOSCRIPT verwenden. Wer das nicht macht, schließt eben ein paar Nutzer aus. Es gehört eben zu einer *korrekten* Umsetzung IMHO dazu. Wer trotzdem drauf verzichtet, verzichtet eben drauf - und darf sich nicht beschweren, falls vereinzelte User fluchen.

Gruß, Cybaer

[Martin Hölter]

Hi!

Es hindert dich niemand daran, die Techniken einzusetzen, die du willst. Wir raten nur von einigen Techniken, eben u.a. Frames und Javascript ohne entsprechende "<noscript>-Workarounds" (weiß grade kein besseres Wort) ab.

Und wunder dich nciht, wenn es dann zu manchen Fragen wenige oder keine Antworten gibt, weil viele von uns, die diese Technik "verdammen", sie ben selbst auch nciht ensetzen, also keine Erfahrung damit haben und eben nicht helfen können.

Gruß

Martin

[Ludger]

Hi,

Das ist IMHO besser, als den kleinsten gemeinsamen Nenner zu suchen, wobei andere sinnvolle Techniken aufgegeben werden.

das mit dem kleinsten gemeinsamen Nenner ist schon OK. So wie man bspw. bei der Addition der Brueche 1/2 und 1/3 den gemeinsamen Nenner 6 finden muss um das Ergebnis kurz aufschreiben zu koennen (dieses ist uebrigens 5/6), so kann man sich vorstellen, dass es einfacher ist Daten zu handeln, die Teil nur eines HTML-Dokuments sind. Und das ist m.E. auch das Hauptargument gegen frames: diese braucht man nicht und machen alles somit nur komplizierter

Gruss,
Ludger