Funktionstüchtigkeit, Handhabung, Darstellung

[Jan]

Hallo,
ich möchte heute mal eine seite begutachten lassen.
Ich habe die seite für den studiengang molekulare biotechnologie
überarbeitet und konnte die verantwortlichen dazu übereden,
das ganze mit einem css-layout zu tun.

Also habe ich das getan, ich würde mich freuen wenn ihr mir eure kommentare zu kommen lasst.
Besonders interesiert mich wie die seiten in diversen browsern
dargestellt werden und ob sie nutzbar sind, wer ausgefallene
browserversionen hat kann die seite mal damit besuchen, uni-seiten
haben ja immer einen breiten querschnitt an browsertypen und da
mitunter recht ausgefallene.

Dann würde mich noch interesieren wie ihr die seite von der handhabung/bedienung findet.
und natürlich auch vom optischen her, zu viel blau?,
(blau finde ich essentiell am liebsten würde ich ja noch blaue leuchtdioden an den monitoren der user montieren, geht das vieleicht mit java?)
nur blau->zu eintönig?,  oder passt das ganze vielleicht uberhaupt nicht zu einer uniseite.
Naja, sagt was.

http://www.fractatulum.de/neu/botanik.htm
Es sind nicht alle seiten online, die unter science,einige unter materialien, die praktikaseite und unter studium/info sind online.

Gruss, Jan aus Dresden

[Olaf Schneider]

Hallo,

auf dem Mac ist ein Link nur zu sehen, wenn die Maus ueber ihm ist. Das ist wahrscheinlich nicht beabsichtigt.

Gruss Olaf Schneider

[Jan]

Hallo,

auf dem Mac ist ein Link nur zu sehen, wenn die Maus ueber ihm ist. Das ist wahrscheinlich nicht beabsichtigt.

Oh, nein, dass ist nicht beabsichtigt.

Jetzt immer noch?

Gruss, Jan aus Dresden

[Olaf Schneider]

Hallo,

wenn Du Dich auf http://www.fractatulum.de/neu/botanik.htm beziehst, ja, die Links sind immer noch unsichtbar. Scheint mir aber auch logisch, denn in der zugewiesenen CSS-Klasse blink steht display:none

Gruss Olaf Schneider

[Jan]

Hallo,

wenn Du Dich auf http://www.fractatulum.de/neu/botanik.htm beziehst, ja, die Links sind immer noch unsichtbar. Scheint mir aber auch logisch, denn in der zugewiesenen CSS-Klasse blink steht display:none

Nein, das ist nicht logisch, die klasse "blink" formatiert nur das zeichen vor dem linktext, dass display:none; steht in der .css für alte browser, ich habe es trotzdem in "inline" geändert wobei ich nict wüsste was das bringen soll, ehrlich gesagt weis ich nicht so recht woran es hängt. Ich habe jetzt überall die farbe angegeben.
hier mal die entscheidenden Teile:
CSS:

#navi {
color: #ffffff;
background-color : transparent;
font-size : 12px;
padding-top:30px;
margin-left:6px;
font-size : 12px;
float:left;
width: 150px;
}
#navi ul {
list-style: none;
margin: 0px;
padding-left: 0px;
text-align: left;
margin-bottom:4px;
color: #ffffff;
background-color: transparent;
border: 1px solid #dfdfdf;
line-height:15px;
}
#navi li {
color: #ffffff;
background-color: transparent;
margin:0px;
}
#navi a {
color: #ffffff;background-color : transparent;text-decoration: none; display:block;padding:0px;width: 148px;
}

HTML:
<div id="navi">
<h4>text</h4>
<ul>
<li><a href="index.htm"><span class="blink">::</span>linktext</a></li>
</ul>
</div>

Um was für einen browser handelt es sich?
Weis jemand rat was da im mac los ist?

Gruss, Jan aus Dresden

[Mathias Bigge]

Hi Jan,

ich finde die große leere Kopffläche etwas irritierend. Kommt da noch ein Logo hin? Sonst würde auch das gesamte Menü ohne Scrollen auf meinen Bildschirm passen.

Die Kontraste im Menübereich finde ich auch etwas schwach. Ich finde auch, die Kästchen mit den Rubriküberschriften im Menü sollten genauso breit sein wie das Menü selbst, so wirkt es etwas unruhig.

Du hast auch etwas viele Menüpunkte. Vielleicht könntest Du zum Teil reduzieren. Es müssen ja nicht alle Unterpunkte auf der Startseite sichtbar sein.

Viele Grüße
Mathias Bigge

[Jan]

Hallo,

ich finde die große leere Kopffläche etwas irritierend. Kommt da noch ein Logo hin?

Eigentlich ist oben eine grafik zu sehen, bei dir gar keine, es ist ein hintergrundbild, hat dein browser schwirigkeiten das anzuzeigen, sollte ich den absoluten pfad zur grafik in der .css angeben?

Die Kontraste im Menübereich finde ich auch etwas schwach. Ich finde auch, die Kästchen mit den Rubriküberschriften im Menü sollten genauso breit sein wie das Menü selbst, so wirkt es etwas unruhig.

In meinen browsern ist alles gleich breit, ich habe es noch etwas geändert, jetzt sollte es passen?

Du hast auch etwas viele Menüpunkte. Vielleicht könntest Du zum Teil reduzieren. Es müssen ja nicht alle Unterpunkte auf der Startseite sichtbar sein.

Mir kommt es auch etwas viel vor aber man wollte es so, ich werden sehen.

Danke.
Gruss, Jan aus Dresden

[Mathias Bigge]

Hi Jan,

Eigentlich ist oben eine grafik zu sehen

Jetzt zeigen es IE 5.5 und Mozilla.

In meinen browsern ist alles gleich breit, ich habe es noch etwas geändert, jetzt sollte es passen?

Passt.

Viele Grüße
Mathias Bigge

[emu]

Hallo!

Wissenschaftliche Texte neigen dazu, lange Wörter zu produzieren und
lange Wörter wiederum neigen dazu, lange Zwischenräume bei Blocksatz
zu produzieren, mit anderen Worten: Mach den Fließtext linksbündig.

Wissenschaftliche Seiten sind ja normalerweise auch Gebrauchsseiten,
die oft und lange benutzt werden, etwas besserer Kontrast, vor allem
bei der Navigationsleiste, kann da nicht verkehrt sein.

Diese Kreise würde ich, wenn es nicht das Logo des Studienganges ist,
streichen. Sie sind leider ziemlich nichtssagend und störend.

Die Farben sind Geschmackssache, du solltest allerdings die grünen
Pfeile und die Überschriften in einem Blauton, der sich mit dem Rest
der Seite nicht verträgt, überdenken.

Ich habe im Moment keine ausgefallenen Browser zur Verfügung.

Ingesamt gelungen, so sollten viel mehr Seiten gebaut werden :-)

emu
[...]

[Jan]

Hallo,

lange Wörter wiederum neigen dazu, lange Zwischenräume bei Blocksatz
zu produzieren, mit anderen Worten: Mach den Fließtext linksbündig.

stimmt wohl, habe ich geändert.

etwas besserer Kontrast, vor allem
bei der Navigationsleiste, kann da nicht verkehrt sein.

Ja, das mit dem kontrast, ich weis nicht so recht was ich da machen soll wenn ich den listen eine dunklere hintergrundfarbe gebe wirkt die navigation so aufgesetzt und einen andere linkfarbe als weiß passt auch nicht. Ich habe mal die buchstaben etwas auseinander gezogen, dass macht die sache etwas besser lesbar, denke ich.

Diese Kreise würde ich, wenn es nicht das Logo des Studienganges ist,
streichen. Sie sind leider ziemlich nichtssagend und störend.

Naja, so siehts in etwa aus wenn man lipidtröpfchen in einer zelle  mit etwas farbstoff unter einem mikroskop mit polarisationsfilter hat.
Also nicht ganz am thema vorbei, ich werde versuchen das ganze noch etwas aussagekräftiger zu gestalten.

Die Farben sind Geschmackssache, du solltest allerdings die grünen
Pfeile und die Überschriften in einem Blauton, der sich mit dem Rest
der Seite nicht verträgt, überdenken.

Das hat system, es wird noch eine zeichenerklärung eingebaut, blaue pfeile = eine seite weiter, grün = link zu externen seite, rot = pdf-datei, usw.

Vielen dank für deinen beitrag.

Gruss, Jan aus Dresden

[Christian Seiler]

Hallo Jan,

Besonders interesiert mich wie die seiten in diversen browsern
dargestellt werden und ob sie nutzbar sind, wer ausgefallene
browserversionen hat kann die seite mal damit besuchen, uni-seiten
haben ja immer einen breiten querschnitt an browsertypen und da
mitunter recht ausgefallene.

Vorab: Mozilla 1.0 und Konqueror 3.0.3 (unter Debian woody+testing) zeigen die Seite vmtl. so an, wie Du sie haben willst. Ich hab' das ganze dann auch noch im Amaya 5.1 und 6.4 (auch Debian) getestet und beide lassen den Content-Bereich unter das Menü rutschen, so dass das ganze in etwa so aussieht (die Linien musst Du Dir wegdenken):

+---------------------------------------------------+
| Titel                                             |
+-----------+---------------------------------------+
| Menü      | Frei                                  |
|           |                                       |
|           |                                       |
|           |                                       |
|           |                                       |
|           |                                       |
+-----------+---------------------------------------+
| Frei      | Content                               |
|           |                                       |
|           |                                       |
|           |                                       |
|           |                                       |
|           |                                       |
+-----------+---------------------------------------+

Desweiteren kapiert der Amaya 5.1 die Styles beim Menü nicht so richtig, der 6.4er ist besser, aber auch noch nicht das wahre. Das liegt aber an der CSS-Interpretation von Amaya, da kannst Du nichts machen. Benutzbar ist die Seite aber dennoch, sieht halt nur nicht so schön aus. Erfeulich: Netscape 4.77 zeigt das Layout so an, wie es sein soll (schlägt sogar Amaya...), nur einige Styles (list-style-type) ignoriert er. In den drei Textbrowsern lynx, links und w3m wird die Seite ordentlich dargestellt, die Bedienung ist sehr komfortabel, vor allem, wenn ich an andere Webseiten denke...

Insgesamt: Die Browserunterstützung extrem positiv, benutzbar ist sie unter allen Browsern und bis auf Amaya sieht sie unter fast jedem Graphikbrowser annähernd gleich aus...

Können wir die als Referenz für CSS-Layouts verwenden, um andere Menschen davon zu überzeugen?

Grüße,

Christian

[Jan]

Hallo,

Vorab: Mozilla 1.0 und Konqueror 3.0.3 (unter Debian woody+testing) zeigen die Seite vmtl. so an, wie Du sie haben willst.

Das hört sich ja schon mal gut an.

Desweiteren kapiert der Amaya 5.1 die Styles beim Menü nicht so richtig, der 6.4er ist besser, aber auch noch nicht das wahre.

Das ist ok solange die links da sind und funktionieren.

Das liegt aber an der CSS-Interpretation von Amaya, da kannst Du nichts machen. Benutzbar ist die Seite aber dennoch, sieht halt nur nicht so schön aus.

Naja, das kann man verschmerzen, ich ja erst doch eine tabelle mit zwei spalten genommen um das menu und den inhalt sicher nebeneinander zu bringen aber dann war mir das auch wieder zu doof da doch die meisten browser etwas mit float: anfangen können.

Erfeulich: Netscape 4.77 zeigt das Layout so an, wie es sein soll (schlägt sogar Amaya...), nur einige Styles (list-style-type) ignoriert er.

Die list-style angabe versteht er schon sogar den typ, ich habe ihn aber in der old.css gar nicht angegeben, kann ich ja noch machen um die listenzeichen im alten NN verschwinden zu lassen.

In den drei Textbrowsern lynx, links und w3m wird die Seite ordentlich dargestellt, die Bedienung ist sehr komfortabel, vor allem, wenn ich an andere Webseiten denke...

Das freut mich. ich hatte schon mal auf http://www.delorie.com/web/lynxview.html getestet und wenn das in den anderen textbrowsern auch so rüberkommt ist das schön.

Jetzt würde ich nur noch gern wissen wollen wie es nun auf Olaf Schneiders mac aussieht, ich hoffe er meldet sich nochmal.

Können wir die als Referenz für CSS-Layouts verwenden, um andere Menschen davon zu überzeugen?

Ja wenn du meinst, kannst du das gern tun, in absehbarer zeit werden die seiten aber auf dem uniserver liegen.

Gruss, Jan aus Dresden

[Calocybe]

Hi!

Also die Schrift ist mir zu klein. Kein Wunder, Du hast sie mit einer Groesse von 0.8em angegeben. Das heisst, du laesst nur 80% der Schriftgroesse zu, die vom Besucher als angenehm lesbar empfunden wird. Noch dazu schaltest Du auf Tahoma um, welche wiederum bei gleicher Schriftgroesse schlechter lesbar ist als meine Standard-Schriftart Verdana. Also das mit der Schrift solltest Du nochmal ueberdenken. Falls Dir vor allem daran liegt, dass nicht das haessliche Times New Roman angezeigt wird, das bei unkonfigurierten Browsern voreingestellt ist, solltest Du es vielleicht einfach bei font-family:sans-serif; belassen, womit dem Besucher ueberlassen ist, *welche* sans-serif-Schriftart er haben will.

Weisser Hintergrund eignet sich fuer laengere Texte nicht, da er die Augen ueber Gebuehr belastet. Noch dazu, macht er es schwieriger, die Farben der Pfeile zu unterscheiden (weisser Hintergrund blendet --> weniger Empfindlichkeit fuer die im Vergleich dunkleren Farben), und das wo Du doch mit den Farben bestimmte Informationen rueberbringen willst (externe/interne Seite/PDF-Datei). Wenn der Besucher dann noch zu den 8% rot-gruen-blinden Maennern gehoert, ist es nicht nur schwer, sondern so gut wie unmoeglich, diese Farben zu erkennen. Wenn Du aber den Text-Hintergrund dunkler machst, koennen auch jene die Farben unterscheiden (wenn vielleicht auch nicht korrekt benennen). Vielleicht empfiehlt sich, einfach das Weiss in Richtung der anderen Body-Hintergrundfarbe zu bewegen, also die letztere einfach in einer helleren Variante als Texthintergrund zu nehmen.

Von der HTML-Struktur her waere zu sagen, dass es nicht sinnvoll ist, mit <h3> als hoechster Ueberschrift anzufangen und dann sowas wie <p style="font-weight: bold"> statt einer untergeordneten Ueberschrift zu verwenden (siehe z.B. auch http://www.w3.org/2001/06tips/Use_h1_for_Title). Besser waere dieser Ansatz:
  * body { font-size:1em }   /* also praktisch keine font-size definieren */
  * Fuer die Seitenueberschrift h1 verwenden und mit h1 { font-size:1.25em } die Schriftgroesse in die selbe Relation bringen, die jetzt durch (body:0.8em, h3:1em) gegeben ist. Statt dem <p> fuer die Subueberschrift ein h2 oder h3 verwenden und mit { font-size:1em; font-weight:bold } formatieren.

HTH && So long

[Jan]

Hallo,

Das heisst, du laesst nur 80% der Schriftgroesse zu, die vom Besucher als angenehm lesbar empfunden wird.

Ich denke,das ist subjektiv, es wird zwar oft gesagt, "mach die schrift grösser, aber gerade bei langen texten finde ich grosse schrift eher schlecht lesbar und weil es subjektiv ist, ist da auch eine relative grössenangabe und es steht dem nutzer frei (und so auch im ie) diese selbst mittels zoom zu vergrössern, ich denke auch hier im selfraum hat man sich etwas dabei gedacht diese schriftgrösse zu verwenden die da ist und die ist im endeffekt so ziehmlich genauso gross. Ich verkleiner die schrift ganz bewusst. gut es gibt den umkehrschluss, lass die schrift bei 100%, man kann ja auch verkleinern, aber es ist ein umkehrschluss mit dem selben ergebnis, der user kann entscheiden und somit ist es egal, und ich möchte die schrift so lassen.

Noch dazu schaltest Du auf Tahoma um, welche wiederum bei gleicher Schriftgroesse schlechter lesbar ist als meine Standard-Schriftart Verdana.

auch das kann der user wenn er unbedingt _seine_ lieblings schrift haben will, im browser so einstellen, ein anderer findet verdana total schrecklicklich, wie wache ich es ihm recht und ein wenig möchte ich ja schon gestalten und ob tahome unbedingt schlecht lesbar ist, ist auch subjektiv da ich sie als gut lesbar empfinde.
wenn ich nur sans-serif angebe, dann wird bei dir verdana angezeigt, bei anderen vielleicht dann doch tahoma, dass weis man nicht wer so speziell _immer_ seine schriftart sehen will, sollte sich das im browser so einrichten.

summa sumarum, sehe ich bei den zwei punkten kein zwingenden handlungsbedarf da in beiden fällen der user das auch für sich selbst ändern kann wenn er es für nötig hält.

Weisser Hintergrund eignet sich fuer laengere Texte nicht, da er die Augen ueber Gebuehr belastet.

Naja, genau darum ist es kein weisser hintergrund sondern ein zartes grau im vergleich wird es sichtbar nur ohne vergleich schlecht, selbst wenn man ein #fafafa nimmt wirkt es ohne den weiss vergleich als weiss ist aber grau und schon besser für die augen.

Wenn der Besucher dann noch zu den 8% rot-gruen-blinden Maennern gehoert, ist es nicht nur schwer, sondern so gut wie unmoeglich, diese Farben zu erkennen.

Das ist ein argument, ich werde mir da gedanken wachen, eventuell mit form statt mit farbe arbeiten, an farbmöglichkeiten ist die auswahl ja begrenzt wenn rot-grün quasi entfällt.

Wenn Du aber den Text-Hintergrund dunkler machst, koennen auch jene die Farben unterscheiden (wenn vielleicht auch nicht korrekt benennen). Vielleicht empfiehlt sich, einfach das Weiss in Richtung der anderen Body-Hintergrundfarbe zu bewegen, also die letztere einfach in einer helleren Variante als Texthintergrund zu nehmen.

Das finde ich keine gut idee, ich persönlich und ich denke auch viele andere bevorzugen als text hintergrund ein weissderivat und dabei wird es auch bleiben.

Von der HTML-Struktur her waere zu sagen, dass es nicht sinnvoll ist, mit <h3> als hoechster Ueberschrift anzufangen.

Warum, es geht darum, dem inhalt eine strucktur zu vergeben und es ist nicht zwingend dabei mit <h1> anfangen zu müssen meine erste überschrifft hat h3 und steht am dokumenten anfang und ist auch ohne h1 als erste headline zweifelsfrei zu idendifizieren die navigatin h4 und teil überschriften bekommen h5, dass ist so gewollt und macht sinn.
Was für andere _wichtige_ gründe könnten von bedeutung sein doch mit h1 zu beginnen ,nich weil w3c sagt das ist falsch und das ohne begründung, damit ich es änder. ich seh es nicht ein und bin nicht immer w3c gläubig (infamie).

und dann sowas wie <p style="font-weight: bold"> statt einer untergeordneten Ueberschrift zu verwenden. Besser waere dieser Ansatz:
  * body { font-size:1em }   /* also praktisch keine font-size definieren */

Ja, da gebe ich dir recht für diese überschriften würe ein h angebrachter.

Ich denke ich werde die überschriftensache überarbeiten.
Was die sache mit schrift art und grösse angeht sehe ich nicht wirklich handlungsbedarf da der user diese punkte auch selbst ändern kann wen er es für nötig hält.

Vielen dank für deinen beitrag.
Gruss, Jan aus Dresden

[Michael Schröpl]

Hi Jan,

Das heisst, du laesst nur 80% der Schriftgroesse zu, die vom Besucher als angenehm lesbar empfunden wird.
Ich denke,das ist subjektiv

Genau. Es ist subjektiv. Und warum verweigest Du dem Anwender diejenige Schriftgröße, die _er_ für _seinen_ Browser konfiguriert hat, und zwingst ihn dazu, eine 20% kleinere Schrift zu ertragen?

Zum Glück hat mein Browser eine konfigurierbare Schrift-Mindestgröße, die alles overruled ...

Viele Grüße
      Michael

[Jan]

Hallo,

Genau. Es ist subjektiv. Und warum verweigest Du dem Anwender diejenige Schriftgröße, die _er_ für _seinen_ Browser konfiguriert hat, und zwingst ihn dazu, eine 20% kleinere Schrift zu ertragen?

Ich hatte einen kleinen denkfehler, ich habe es jetzt in 13px geändert, die variante, die schriftgrösse gar nicht erst anzugeben oder mit 100% will ich nicht nehmen da dann doch bei den meisten die nun mal nicht die standard werte ändern un ddann die (meist) 16px angezeigt bekommen, mir ist auch noch nicht wirklich eine seite untergekommen die das macht, bei mir sind die 16px auch noch eingestellt und die habe ich noch nicht gesehen.

Was mich bei der px angabe stört, dass die schrift dann im ie nicht vergrössert werden kann.
Ich denke mal das die 13 px akzeptabel sind, wird hier ja auch genutzt.

Was den überschriften kram angeht, den habe ich nun auch noch geändert nun sind noch die rot-grünblinden dran, so sollte doch dann alles gut werden oder?

Gruss, Jan aus Dresden

[Michael Schröpl]

Hi Jan,

die variante, die schriftgrösse gar nicht erst anzugeben oder mit 100% will ich nicht nehmen da dann doch bei den meisten die nun mal nicht die standard werte ändern un ddann die (meist) 16px angezeigt bekommen

Du bestrafst also diejenigen, die mit ihrem Browser umgehen können, weil Du versuchst, für die anderen, von denen Du nicht mal weißt, was sie wirklich wollen, deren Lieblingsgröße zu erraten ... sehr ambitioniert.

Was mich bei der px angabe stört, dass die schrift dann im ie nicht vergrössert werden kann.

Um so eher solltest Du überhaupt keine Schriftgröße angeben.

Nein, ich mache das auch nicht 'richtig' - ich führe hier nur aus, worauf Calocybe hinaus will:
_Wenn_ Du schon in "em" denkst, also bereit bist, auf die Einstellungen des Benutzers zu reagieren, dann halte Dich doch am besten gleich ganz raus und vertraue Deinem Besucher: Entweder der weiß selber, was er will, oder er fühlt jedenfalls nicht genügend Schmerz, um seinen Browser bedienen lernen zu wollen - dann hilft es auch nichts, wenn Du eine Schriftgröße 'auswürfelst'.

Ich denke mal das die 13 px akzeptabel sind, wird hier ja auch genutzt.

... und von mir in den Einstellungen meiner Registrierung auf 18 px overruled. Mein Browser ist mein Blindenhund ...

Viele Grüße
      Michael

[Jan]

Hallo,

Du bestrafst also diejenigen, die mit ihrem Browser umgehen können, weil Du versuchst, für die anderen, von denen Du nicht mal weißt, was sie wirklich wollen, deren Lieblingsgröße zu erraten ... sehr ambitioniert.

bestraft werden mit der px angabe die ie user da bei denen die schriftgrösse nicht verstellbar ist wenn px im spiel ist, dass ist das einzige manko an der px sache welches ich gern umgehen möchte ohne die 100% angabe,in anderen browsern (moz nn opera) ist es möglich und ich denke leute mit sehschwächen und diesen browsern werden prinzipiell den zoom eingestellt haben (ja, ist auch eine mutmaßung) da es so gut wie keine seite gibt die keine schriftgrösse vorgibt, zu mindest hab ich noch keine gesehen, die 16px, sagte ich ja schon.

Was also machen, man kann nur mutmaßen und einen mittelweg finden und wenn ich weiter wie oben mutmaße, werden sehbehinderte eh nicht den ie nutzen da das px-zoom problem auf so ziehmlich allen seiten auftritt.

Zumal, muss ich sagen, die seite soll nicht ein muster an gebrauchsfreundlichkeit werden, natürlich soll die hanhabung einfach sein aber wenn es an ein zwei stellen etwas hackt, eben die schriftgrösse dann sehe ich das als nicht so gravierend an.

ich wünschte nur, eine schriftgrösse vorzugeben, auch schrift gehört zum layout, sollte man nicht vergessen, es geht ja nun auch um gestaltung, die aber bei bedarf angepasst werden kann und das ist scheinbar nicht möglich im ie.

Was mich bei der px angabe stört, dass die schrift dann im ie nicht vergrössert werden kann.

Um so eher solltest Du überhaupt keine Schriftgröße angeben.

Will ich aber, siehe oben.

Nein, ich mache das auch nicht 'richtig' - ich führe hier nur aus, worauf Calocybe hinaus will:

ich versteh das schon aber ich habe wünsche.

.....dann hilft es auch nichts, wenn Du eine Schriftgröße 'auswürfelst'.

hier wird nichts ausgewürfelt, es wird ein akzeptabler mittelweg gesucht und 100% ist kein mittel weg sondern der gegensatz zu 10px, ein extrem.

... und von mir in den Einstellungen meiner Registrierung auf 18 px overruled. Mein Browser ist mein Blindenhund ...

siehst du, das meine ich, leute die mit den gängigen schriftgrössen im web, eben den 11, 12, 13px probleme haben, haben eine umgebung, die die seite ihren speziellen bedürfnissen anpasst.

Gruss, Jan aus Dresden

[Michael Schröpl]

Hi Jan,

siehst du, das meine ich, leute die mit den gängigen schriftgrössen im web, eben den 11, 12, 13px probleme haben, haben eine umgebung, die die seite ihren speziellen bedürfnissen anpasst.

Nicht notwendigerweise. Bei den meisten unserer Kunden wäre das am Arbeitsplatz gar nicht möglich.

Viele Grüße
      Michael

[Jan]

Hallo,

Nicht notwendigerweise. Bei den meisten unserer Kunden wäre das am Arbeitsplatz gar nicht möglich.

naja, ich denke wenn der arbeitnehmer solch ein problem hat und er darauf angewiesen ist im netz zu arbeiten ist es sogar einklagbar, das es möglich gemacht wird da die betreffende person diese möglichkeit benötigt um seine arbeit auch machen zu können, das ist kein wirkliches argument.

Gruss, Jan aus Dresden

[Michael Schröpl]

Hi Jan,

naja, ich denke wenn der arbeitnehmer solch ein problem hat und er darauf angewiesen ist im netz zu arbeiten ist es sogar einklagbar, das es möglich gemacht wird da die betreffende person diese möglichkeit benötigt um seine arbeit auch machen zu können, das ist kein wirkliches argument.

was diese Person benötigt, um ihre Arbeit zumachen, bestimmt ihr Arbeitgeber. Und der entscheidet nicht zuletzt nach Kostenaspekten.
Die Vorstellung, die Installation eines bestimmten Browsers einklagen zu können, finde ich reichlich albern.

Viele Grüße
      Michael

[Jan]

Hallo,

was diese Person benötigt, um ihre Arbeit zumachen, bestimmt ihr Arbeitgeber. Und der entscheidet nicht zuletzt nach Kostenaspekten.
Die Vorstellung, die Installation eines bestimmten Browsers einklagen zu können, finde ich reichlich albern.

das ist keines wegs albern oder kann der arbeitgeber auch sagen, sie hatten einen unfall, sitzen im rollstuhl, nein, sie bekommen keinen schreibtisch an dem sie mit dem rolli rankommen, ich denke nicht und wenn jemand durch augenprobleme "behindert" ist, ist das genau das selbe und das ist mit sicherheit nicht albern. sondern eine pflicht des arbeitgeber.

kostenaspekte, dass ist dan schon eher albern.

Gruss, Jan aus Dresden

[Michael Schröpl]

Hi Jan,

das ist keines wegs albern oder kann der arbeitgeber auch sagen, sie hatten einen unfall, sitzen im rollstuhl, nein, sie bekommen keinen schreibtisch an dem sie mit dem rolli rankommen, ich denke nicht und wenn jemand durch augenprobleme "behindert" ist, ist das genau das selbe und das ist mit sicherheit nicht albern. sondern eine pflicht des arbeitgeber.
kostenaspekte, dass ist dan schon eher albern.

ich bin überzeugt davon, daß Du Deinen Arbeitgeber zwingen kannst, Dir einen ergonomischen Bildschirm hinzustellen. Aber einen bestimmten Browser? Bestimmt nicht - weil nicht definiert ist, was ein "Browser" überhaupt ist und welche Eigenschaften er haben muß, damit Du damit arbeiten kannst. Außer natürlich durch die Aufgaben, die Dein Arbeitgeber Dich damit bearbeiten läßt ...

Viele Grüße
      Michael

[Jan]

Hallo,

ich bin überzeugt davon, daß Du Deinen Arbeitgeber zwingen kannst, Dir einen ergonomischen Bildschirm hinzustellen. Aber einen bestimmten Browser?

Natürlich einen bestimmten browser, wenn der sehbehinderte nicht mit der "normalen" anwendung arbeiten kann eben weil er nichts erkennt ist das wohl logisch und da gibt es nichts daran zu deuteln.
Ich möcht echt wissen wo du hier ein problm siehst, die gründe die du hier anführst, das ein sehbehinderter arbeitnehmer auf keinen fall anspruch auf eine für ihn funktionstüchtige arbeitsumgebung hat sind an den haaren herbeigezogen und realitätsfern und dienen scheinbar nur deinen einmal eingeschlagen weg auf teufel komm raus weiter zu verfolgen nur ist es jetzt, mit verlaub, blödsinn.

Gruss, Jan aus Dresden

[Tim Tepaße]

Hallo Jan,

Was für andere _wichtige_ gründe könnten von bedeutung sein doch mit h1 zu beginnen ,nich weil w3c sagt das ist falsch und das ohne begründung, damit ich es änder. ich seh es nicht ein und bin nicht immer w3c gläubig (infamie).

Ich finde es irgendwie logischer, oben zu beginnen und sich dann runterzuarbeiten, ähnlich wie die Nummerierung in wissenschaftlichen Texten (Kapitel 1.2.3.4.5). Aber letztendlich isses wohl wurst. :-)

• Tim

[Jan]

Hallo,

Ich finde es irgendwie logischer, oben zu beginnen und sich dann runterzuarbeiten, ähnlich wie die Nummerierung in wissenschaftlichen Texten (Kapitel 1.2.3.4.5). Aber letztendlich isses wohl wurst. :-)

Ja, irgend einen grund hat es bestimmt, dass man mit h1 anfangen soll.
Aber ein wirklich schlüssiger ist mir noch nicht bekannt, nichts destotrotz habe ich es aber geändert, dank des dateiübergreifenden ersetzens war das schnell getan und ein kritikpunkt weniger.

Gruss, Jan aus Dresden

[Michael Schröpl]

Hi Jan,

Ja, irgend einen grund hat es bestimmt, dass man mit h1 anfangen soll.

reicht Dir als Grund, daß andere Leute es als wichtig ansehen und _ihre_ Software danach ausrichten?

Suchmaschinen tun das beispielsweise, wenn sie Dokumente 'verstehen' wollen - für die kann es ein Unterschied (bezüglich ihrer Ranking-Funktion) sein, ob ein Begriff innerhalb von <h1>...</h1> oder von <p><b>...</b></p> steht.

Viele Grüße
      Michael

[Jan]

Hallo,

Suchmaschinen tun das beispielsweise, wenn sie Dokumente 'verstehen' wollen - für die kann es ein Unterschied (bezüglich ihrer Ranking-Funktion) sein, ob ein Begriff innerhalb von <h1>...</h1> oder von <p><b>...</b></p> steht.

Es ging nicht darum _ob_ eine überschrift mit h ausgezeichnet wird sondern warum mit h1 angefangen werden soll, also h1, h2, h3, und warum nicht h3, h4, h5.
Das w3c sagt, fang mit h1 an, liefert aber keine begründung.
Der strucktur der seite tut es keinen abbruch zumal die einmal definierte/formatierte überschrift h1 nicht zwingend auf jeder seite als erstets stehen muss/kann und es muss mit zb h2 oder h3 angefangen werden.
Zum beispiel habe ich eine seite, die erste überschrift ist h1 die teilüberschriften der einzelnen textpassagen ist h2, nun wird auf die zweite sich _anschliessende_ und im zusammenhang stehende seite weiter gelingt und auf der kann von der strucktur die h1 nicht verwendet werden also geht es mit h2 weiter, h1 fehlt.
Man kan zwar sagen dann schreibe in die zweite wieder die erste überschrift aber da die zwei seiten im engen zusammenhang stehen wäre es nicht logisch nochmals die überschrift anzu bringen.
Das beispiel ist sicherlich nicht das beste aber was ich sagen will, die  überschrift h1 kann nicht immer als erstes in einer seite stehen aber andere schon.

Einen mir verständlichen grund lieferte Calocybe mit dem beispiel textbrowser, in denen die h-tags durch einrückung sichtbar werden und das in abhängigkeit der ziffer hinter dem h.

Ich habe keinen textbrowser installiert und habe nur mit http://www.delorie.com/web/lynxview.html getestet und da gibt es keine unterschiede in der darstellung der h-inhalte.

Was die suchmaschienen angeht, ist es auch nicht relevant ob nun mit h1 oder h2 in der seite begonnen wird, zumindest google "stürzt" sich auch auf h3 wenn das das kleinste h ist und nutzt es mitunter in der vorschau.

Wenn du noch was weist, warum unbedingt mit h1 abwärts beginnen und nicht mit h3 abwärts würde mich das sehr interesieren.

Gruss, Jan aus Dresden

[Michael Schröpl]

Hi Jan,

Was die suchmaschienen angeht, ist es auch nicht relevant ob nun mit h1 oder h2 in der seite begonnen wird, zumindest google "stürzt" sich auch auf h3 wenn das das kleinste h ist und nutzt es mitunter in der vorschau.
Wenn du noch was weist, warum unbedingt mit h1 abwärts beginnen und nicht mit h3 abwärts würde mich das sehr interesieren.

mir reicht eine einzige Suchmaschine, die sich _nicht_ auf <h3> "stürzt" (sondern beispielsweise nur <h1> und <h2> auswertet).

Es gibt einfach keinen Grund, etwas falsch[tm] zu machen, wenn man es genauso gut auch richtig machen kann.

Viele Grüße
      Michael

[Jan]

Hallo,

mir reicht eine einzige Suchmaschine, die sich _nicht_ auf <h3> "stürzt" (sondern beispielsweise nur <h1> und <h2> auswertet).

Das mag _dir_ reichen, mir wäre das ziemlich wurscht wenn die suchmaschiene nr 2947 nicht für h3 interesiert, ehrlich gesagt interesiert mich keine andere suchmaschiene als google und da ist es egal.

Es gibt einfach keinen Grund, etwas falsch[tm] zu machen, wenn man es genauso gut auch richtig machen kann.

Tolle antwort, echt, sie befasst sich in aller ausführlichkeit mit der frage und ist in ihrer aussage auf den punkt formuliert, so dass sie nahezu absolute gültigkeit hat.
Stellt sich nur immer noch die frage warum und ohne einem warum gibt es werder ein richtig noch ein falsch.

Gruss, Jan aus Dresden

[Michael Schröpl]

Hi Jan,

Es gibt einfach keinen Grund, etwas falsch[tm] zu machen, wenn man es genauso gut auch richtig machen kann.
Tolle antwort, echt, sie befasst sich in aller ausführlichkeit mit der frage und ist in ihrer aussage auf den punkt formuliert, so dass sie nahezu absolute gültigkeit hat.
Stellt sich nur immer noch die frage warum und ohne einem warum gibt es werder ein richtig noch ein falsch.

Das "Warum" lautet: Damit es alle einheitlich machen und nicht jeder anders. Nur dann macht es nämlich Sinn, basierend auf dieser einheitlichen Vorgehensweise wiederum Auswertungsverfahren zu entwickeln (beispielsweise eben den Inhalt von <h1> für das "automatische Verstehen" höher zu bewerten als den Inhalt des <h3>).

Deshalb ist das, was der Standard vorgibt, richtiger als das, was Du auswürfelst - es ist der Sinn des Standards, das Würfeln überflüssig zu machen. Das gilt für HTML genauso wie für die Größe von Schraubgewinden.

Natürlich könntest Du einen abweichenden Standard vorschlagen. Da dieser aber weniger gut für automatische Auswertungsverfahren geeignet wäre, würde er sich m. E. nicht durchsetzen.

Viele Grüße
      Michael

[Jan]

Hallo,

Deshalb ist das, was der Standard vorgibt, richtiger als das, was Du auswürfelst - es ist der Sinn des Standards, das Würfeln überflüssig zu machen.

Hier wird nirgends gewürfelt sondern es geht darum, dass mitunter das format h1 nicht in die strucktur einer seite hinein gehört und somit nicht mit h1 sondern mit h2 begonnen innerhalb der seite begonnen wird, werden muss also fehlt auf dieser seite h1, es wird mit h2 als kleinstes h begonnen (warum habe ich das gefühl ein selbstgespräch zu führen?), da wird nichts gewürfelt, wie kommst du darauf, liest du eigentlich was ich schreibe, scheinbar nicht, vieleicht wäre es aber besser für die darauf folgende antwort.

Das gilt für HTML genauso wie für die Größe von Schraubgewinden.

Ah, wenn ich etwas montiere, muss ich mit M1 beginnen, nur blöd wenn M1 nicht vorhanden ist also nicht benötigt wird oder soll ich beim gewindeschneiden mit M12 anfangen, runterdrehen M11 schneiden, ....
Was ist das für ein vergleich?

Natürlich könntest Du einen abweichenden Standard vorschlagen.

Vieleicht solltest du wirklich mal lesen was ich schreibe um zu verstehen um was es geht wenn du das aber nicht willst brauchst du auch nicht zu antworten da es nichts bringt und nur überflüssiges blabla ist.

Gruss, Jan aus Dresden

[Calocybe]

Re!

Zum beispiel habe ich eine seite, die erste überschrift ist h1 die teilüberschriften der einzelnen textpassagen ist h2, nun wird auf die zweite sich _anschliessende_ und im zusammenhang stehende seite weiter gelingt und auf der kann von der strucktur die h1 nicht verwendet werden also geht es mit h2 weiter, h1 fehlt.

Das stimmt, stellt man z.B. ein ganzes Buch online, wo man h1 wohl fuer den Buchtitel verwenden wuerde, waere es nicht gerade logisch, die Kapitelueberschriften auf h1 "upzugraden", nur weil man es praktischerweise auf mehrere Seiten aufteilt. Wenn man dann aber h1 weglaesst, halte ich dafuer ein <link rel="start"> fuer zwingend notwendig, um den Kontext der untergeordneten Ueberschrift zu dokumentieren. Das wuerde dann auch einer Suchmaschine ermoeglichen, schnell die zugehorige h1 aufzufinden. Je nach Art der Seiten bietet es sich vielleicht auch an, die h1 einfach auf jeder Seite zu wiederholen. Wie auch immer - *irgendwo* in einem Dokument (welches moeglicherweise aus vielen einzelnen Seiten besteht) sollte auf jeden Fall eine h1 zu finden sein. Sie ist die Hauptueberschrift, die sagt, worum es in diesem Komplex geht.

Ich habe keinen textbrowser installiert und habe nur mit http://www.delorie.com/web/lynxview.html getestet und da gibt es keine unterschiede in der darstellung der h-inhalte.

Naja, die h3 wird nicht eingerueckt, hatte ich ja gesagt, aber immerhin wird die h1 schoen zentriert. Allerdings wird das Title-Element nicht dargestellt, und die Tabelle ist keine Tabelle. (Lynx kann zwar nicht wirklich mit Tabellen umgehen, aber ein paar Spalten nebeneinander schreiben kann es dann schon.) Insgesamt sieht mir das nicht wie eine wirkliche Lynx View aus.

So long

[Jan]

Hallo,

Das stimmt, stellt man z.B. ein ganzes Buch online, wo man h1 wohl fuer den Buchtitel verwenden wuerde, waere es nicht gerade logisch, die Kapitelueberschriften auf h1 "upzugraden",

Ja, das ist ein gutes beispiel für das was ich meinte.

nur weil man es praktischerweise auf mehrere Seiten aufteilt. Wenn man dann aber h1 weglaesst, halte ich dafuer ein <link rel="start"> fuer zwingend notwendig, um den Kontext der untergeordneten Ueberschrift zu dokumentieren.

Das ist natürlich eine sehr gute lösung für eben das problem, dass h1 nicht immer vorhanden sein kann.

Je nach Art der Seiten bietet es sich vielleicht auch an, die h1 einfach auf jeder Seite zu wiederholen.

Ja sicher, es ging mir aber um den speziellen fall, wo man der w3c aussage "fange mit h1 im dokument(?) an" nicht folgen kann und der fall ist ja nicht aus der luft gegriffen.

Wie auch immer - *irgendwo* in einem Dokument (welches moeglicherweise aus vielen einzelnen Seiten besteht) sollte auf jeden Fall eine h1 zu finden sein. Sie ist die Hauptueberschrift, die sagt, worum es in diesem Komplex geht.

Da stimme ich dir mittlerweile zu.

[link:http://www.delorie.com/web/lynxview.html.
Insgesamt sieht mir das nicht wie eine wirkliche Lynx View aus.

Mh, aber im grossen und ganzen ist es schon ähnlich?
Kennst du vieleicht seiten, die einen ähnlichen service bieten?
Naja, eigentlich könnte man sich ja auch mal einen textbrowser installieren.

Gruss, Jan aus Dresden

[Calocybe]

Moin Moin!

Ich verkleiner die schrift ganz bewusst. [...]

Was die Schrift angeht, bist Du ja nun zu 13px uebergegangen, was ich eindeutig als das kleinere Uebel erachte. Eine feste Pixelgroesse orientiert sich immerhin an der Voraussetzung, dass das die meisten Menschen 13px ganz gut lesen koennen, was man imho als "relativ gegeben" betrachten kann (zumindest bei einer sans-serif Schriftart).
(Uebrigens ist das throughout the web anzutreffende <font size=-1> auch nichts anderes als ein generelles -20% auf die eingestellte bevorzugte Schriftgroesse und daher "inhaerent scheisse".)

auch das kann der user wenn er unbedingt _seine_ lieblings schrift haben will, im browser so einstellen, ein anderer findet verdana total schrecklicklich, wie wache ich es ihm recht und ein wenig möchte ich ja schon gestalten und ob tahome unbedingt schlecht lesbar ist, ist auch subjektiv da ich sie als gut lesbar empfinde.

Ich sagte nur schlechter als Verdana, nicht generell schlecht. In der Tat ist sie noch eine der am besten lesbaren Schriftarten. Aber erst font-size:80% und dann noch schlechter lesbare Schriftart einstellen, das war wirklich zu viel.

Das mit dem "Browser so einstellen" stimmt so nicht. Man kann zwar sagen "immer meine Schriftart verwenden", aber "im Fliesstext immer meine Schriftart verwenden, bei Menues und Designelementen aber freie Wahl lassen; ausserdem auf meine Schriftart zurueckschalten, wenn font-size kleiner als 80% meiner bevorzugten font-size" kann man nicht einstellen.

wenn ich nur sans-serif angebe, dann wird bei dir verdana angezeigt, bei anderen vielleicht dann doch tahoma, dass weis man nicht wer so speziell _immer_ seine schriftart sehen will, sollte sich das im browser so einrichten.

Genau, man weiss es nicht. Das ist das Web, so funktioniert es!

Naja, genau darum ist es kein weisser hintergrund sondern ein zartes grau im vergleich wird es sichtbar nur ohne vergleich schlecht, selbst wenn man ein #fafafa nimmt wirkt es ohne den weiss vergleich als weiss ist aber grau und schon besser für die augen.

*lol* Das meinst Du jetzt nicht ernst, oder? Dass es kein 100% Weiss war, hab ich selber im Quelltext gesehen, aber 5 von 256 Intensitaetsstufen weniger macht nicht wirklich einen Unterschied.

Das finde ich keine gut idee, ich persönlich und ich denke auch viele andere bevorzugen als text hintergrund ein weissderivat und dabei wird es auch bleiben.

Weiss nicht, wie die Mehrheitsmeinung dazu ist. Ich kenne jedenfalls ne Menge Leute, denen das Weiss ganz schoen auf den Sack geht, auch weil es nun wirklich allerorten eingesetzt wird, ausser auf Grufti-Seiten und meiner in der Entstehung befindlichen kleinen Site. *g*

Was für andere _wichtige_ gründe könnten von bedeutung sein doch mit h1 zu beginnen ,nich weil w3c sagt das ist falsch und das ohne begründung, damit ich es änder. ich seh es nicht ein und bin nicht immer w3c gläubig (infamie).

Ich hatte nur keine Lust, es zu erklaeren, deswegen hatte ich einfach dorthin verwiesen.
Aber jetzt hat Tim ja schon was dazu gesagt, und anscheinend hat Dir das ausgereicht. *g*

Was die sache mit schrift art und grösse angeht sehe ich nicht wirklich handlungsbedarf da der user diese punkte auch selbst ändern kann wen er es für nötig hält.

Nun ja, mit dieser Argumentation koenntest Du auch rechtfertigen, wenn Du einfach 6px oder 32px Schriftgroesse vorgibst. Man kann es ja einstellen, wenn's einem nicht passt. Aber ich denke doch, man sollte versuchen, dem Besucher so weit wie moeglich entgegenzukommen.

Aber naja, wenn Du Deine Praemissen so setzt, dass Du vor allem einer "tumben Mehrheit" entgegenkommen willst, die zu bloed oder aengstlich ist, ihren Browser zu konfigurieren, obwohl sie mit dem Default-Erscheinungsbild nicht zufrieden sind, und dabei lieber die aufgeklaerte Minderheit vernachlaessigst, dann sind die 13px glaube ich die beste Loesung. Kommt halt auch auf die Zielgruppe an. Die jedoch wuerde ich gerade im universitaeren Umfeld eher in der aufgeklaerten *Mehr*heit sehen.

In einem anderen Posting schreibst Du noch:

ich wünschte nur, eine schriftgrösse vorzugeben, auch schrift gehört zum layout, sollte man nicht vergessen, es geht ja nun auch um gestaltung, die aber bei bedarf angepasst werden kann und das ist scheinbar nicht möglich im ie.

Ich denke, da besteht noch Diskussionsbedarf. "Layout" im klassischen Sinne gibt es in einer Hypertextwelt sowieso nicht, schon allein weil es kein fest vorgegebenes Ausgabeformat gibt. Aber "Gestaltung" einer Website gibt es natuerlich schon. Naja, ist ein Thema, wo man viel reden kann. Wenn Du mal nichts zu tun hast, kannst Du ja mal http://www.cs.tut.fi/~jkorpela/webpub.html und http://www.cs.tut.fi/~jkorpela/styles/harmful.html lesen.

Ach uebrigens: http://selfworld.calocybe.dyndns.org/ftmp/fractatulum00.png
Ich weiss nicht, ob das gerade die alte Version ist, die Du eben ersetzen willst, aber da kommen wirklich hunderte solcher JS-Fehler. Man fuehlt sich fast wie bei alten Netscape-Versionen, wo auch fuer jeden Fehler ein extra Fenster aufgesprungen ist.

So long

[Jan]

Hallo,

[...] kann man nicht einstellen.

Richtig, es geht nur alles oder nichts.
Man könnte natürlich versuchen in einem eigenen stylesheet die elemente die in der regel im fliesstext vorkommen, p, h, usw, für sich zu formatieren und bekommt dann schon ein besseres ergebnis da die navigations elemente seltener in solchen elementen untergebracht sind aber eine wirkliche lösung ist das auch nicht und wer macht sich die arbeit nur weil er internetseiten sehen will.

*lol* Das meinst Du jetzt nicht ernst, oder? Dass es kein 100% Weiss war, hab ich selber im Quelltext gesehen, aber 5 von 256 Intensitaetsstufen weniger macht nicht wirklich einen Unterschied.

Ich mein das wirklich ernst, natürlich denkt man das ist weiss aber wenn der hintergrund wirklich weiss ist, ist es schlechter zu lesen, also, der leicht graue hintergrund ist besser für die lesbarkeit nur merkt man es nicht, ja, klingt doof, man merkt nix aber es gibt trotzdem ein ergebnis, ist aber so.

Was für andere _wichtige_ gründe könnten von bedeutung sein doch mit h1 zu beginnen ,nich weil w3c sagt das ist falsch und das ohne begründung, damit ich es änder. ich seh es nicht ein und bin nicht immer w3c gläubig (infamie).
Ich hatte nur keine Lust, es zu erklaeren, deswegen hatte ich einfach dorthin verwiesen.
Aber jetzt hat Tim ja schon was dazu gesagt, und anscheinend hat Dir das ausgereicht. *g*

Ein wirklich schlüssiger grund ist mir aber immer noch nicht bekannt, kein browser gibt das h1 als solches aus und wenn die erste überschrift mit dem kleinsten in der seite vorkommenden h beginnt ist es von der strucktur her der selbe effekt, warum also doch h1 als erstes, im browser spielt es keine rolle.

[...]"tumben Mehrheit" entgegenkommen [...]aufgeklaerte Minderheit vernachlaessigst [...]

Ja, das ist "rassistisch" aber im zweifelsfall besser als umgekehrt.

Die jedoch wuerde ich gerade im universitaeren Umfeld eher in der aufgeklaerten *Mehr*heit sehen.

Würde ich auch denken, ist aber bei weitem nicht so, wenn man die ausklammert, die sich mit aus studiengründen im weitestem sinne mit der computerthematik beschäftiken, viele, die im biologischen umfeld studieren haben nicht mal einen eigenen computer und nutzen die pools an der uni, trifft jetzt auf die hauptzielgruppe an meiner uni zu.

[...] auch schrift gehört zum layout [...].

Ich denke, da besteht noch Diskussionsbedarf. "Layout" im klassischen Sinne gibt es in einer Hypertextwelt sowieso nicht, schon allein weil es kein fest vorgegebenes Ausgabeformat gibt.

Richtig aber ich denke du weist was ich meinte.

Aber "Gestaltung" einer Website gibt es natuerlich schon. Naja, ist ein Thema, wo man viel reden kann. Wenn Du mal nichts zu tun hast, kannst Du ja mal http://www.cs.tut.fi/~jkorpela/webpub.html und http://www.cs.tut.fi/~jkorpela/styles/harmful.html lesen.

Ich habe die adressen mal gespeichert und werde sie bei gelegenheit besuchen.

Ach uebrigens: http://selfworld.calocybe.dyndns.org/ftmp/fractatulum00.png
Ich weiss nicht, ob das gerade die alte Version ist, die Du eben ersetzen willst...

Ja, genau die soll ersetzt werden.

Danke für deinen beitrag.
Gruss, Jan aus Dresden

[Calocybe]

Re!

Richtig, es geht nur alles oder nichts.
Man könnte natürlich versuchen in einem eigenen stylesheet die elemente die in der regel im fliesstext vorkommen, p, h, usw, für sich zu formatieren und bekommt dann schon ein besseres ergebnis da die navigations elemente seltener in solchen elementen untergebracht sind aber eine wirkliche lösung ist das auch nicht und wer macht sich die arbeit nur weil er internetseiten sehen will.

Na doch, das koennte helfen. <p> ist eines der wenigen Elemente, die selbst auf Seiten mit dem abgefucktesten Frontpage-Kot noch relativ sinnvoll eingesetzt werden. Ich werd's mal in mein UserStylesheet einbauen und ne Weile testen.

Ich mein das wirklich ernst, natürlich denkt man das ist weiss aber wenn der hintergrund wirklich weiss ist, ist es schlechter zu lesen, also, der leicht graue hintergrund ist besser für die lesbarkeit nur merkt man es nicht, ja, klingt doof, man merkt nix aber es gibt trotzdem ein ergebnis, ist aber so.

Schon klar, was Du meinst, aber ich glaube nicht, dass Du recht hast.

Ich hatte nur keine Lust, es zu erklaeren, deswegen hatte ich einfach dorthin verwiesen.
Aber jetzt hat Tim ja schon was dazu gesagt, und anscheinend hat Dir das ausgereicht. *g*
Ein wirklich schlüssiger grund ist mir aber immer noch nicht bekannt, kein browser gibt das h1 als solches aus und wenn die erste überschrift mit dem kleinsten in der seite vorkommenden h beginnt ist es von der strucktur her der selbe effekt, warum also doch h1 als erstes, im browser spielt es keine rolle.

Empfehlung: Oefter mal text-surfen. ;-) Ja ja, denn in Textbrowsern wird die Struktur einer Seite recht deutlich dargestellt. Hier mal Screenshots meiner Seite http://xren.sf.net/ in den Textbrowsern Lynx und Links:
http://selfworld.calocybe.dyndns.org/ftmp/xren.sf.net-lynx.png
http://selfworld.calocybe.dyndns.org/ftmp/xren.sf.net-links.png
Man sieht, wie beide Browser die <h1> mittig als Hauptueberschrift ausgeben. Die <h2>s werden dann aeusserst links plaziert; sie sind die Ueberschriften der einzelnen Hauptabschnitte, oder auch Kapitel. <h3> (nicht mehr im Bild) wird von Links zwei Zeichen eingeruckt (von Lynx leider nicht). Und die Absaetze <p> werden drei Zeichen eingerueckt.

Ausserdem siehst Du rechts oben die Darstellung des <title> und in der zweiten Zeile die <link>-Elemente, die sich im <head> finden (in diesem Fall nur eines). Diese fuer den Hypertextgedanken sehr wichtigen Elemente werden hier also wunderbar visualisiert, besser als in den meisten graphischen Browsern (but things get better in the last time).

Die jedoch wuerde ich gerade im universitaeren Umfeld eher in der aufgeklaerten *Mehr*heit sehen.
Würde ich auch denken, ist aber bei weitem nicht so, wenn man die ausklammert, die sich mit aus studiengründen im weitestem sinne mit der computerthematik beschäftiken, viele, die im biologischen umfeld studieren haben nicht mal einen eigenen computer und nutzen die pools an der uni, trifft jetzt auf die hauptzielgruppe an meiner uni zu.

Na gut, die Biologen ... ;-)

Ich denke, da besteht noch Diskussionsbedarf. "Layout" im klassischen Sinne gibt es in einer Hypertextwelt sowieso nicht, schon allein weil es kein fest vorgegebenes Ausgabeformat gibt.
Richtig aber ich denke du weist was ich meinte.

Du willst auf die Schrift Einfluss nehmen, denn sie ist fuer Dich wesentlicher Bestandteil der Darstellung, so wie Du sie Dir vorstellst. Zwar kann ich das verstehen - ich denke auch nur ungern daran, dass meine Seite in einem unkonfigurierten Browser in 16px Times New Roman dargestellt wird -, aber ich bin trotzdem der Meinung, dass die Schrift eine Sache ist, die dem Besucher zur Entscheidung ueberlassen werden sollte. Gut ja, ich gehe vom idealisierten Bild des muendigen Verbrauchers aus. Aber man kann es auch einfach als "tue keinem anderen an, was Du selbst nicht ertragen willst" formulieren.

So long

[nach Diktat verreist]

[emu]

Hallo!

Also die Schrift ist mir zu klein. Kein Wunder, Du hast sie mit einer Groesse von 0.8em angegeben. Das heisst, du laesst nur 80% der Schriftgroesse zu, die vom Besucher als angenehm lesbar empfunden wird.

Ich fühle mich richtig schuldig...

emu
[...]

[molily]

Hallo, emu,

Also die Schrift ist mir zu klein. Kein Wunder, Du hast sie mit einer Groesse von 0.8em angegeben. Das heisst, du laesst nur 80% der Schriftgroesse zu, die vom Besucher als angenehm lesbar empfunden wird.

Ich fühle mich richtig schuldig...

Naja, bezüglich font-size:0.9em kannst du dich noch auf Verdana und die mangelnde Unterstützung von font-size-adjust herausreden... ups, ist ja nur sans-serif angegeben und ich sehe Verdana aufgrund meiner Einstellungen. Wie auch immer, es ist nicht weniger inkorrekt(TM), dass du XHTML 1.1 als text/html auslieferst... http://www.w3.org/TR/xhtml-media-types/

Mathias
[belangloses Posting]

[emu]

Hallo!

Naja, bezüglich font-size:0.9em kannst du dich noch auf Verdana und die mangelnde Unterstützung von font-size-adjust herausreden...

Das ist wegen den illusorischen, viel zu großen Standardeinstellungen des Internet Explorers.

ups, ist ja nur sans-serif angegeben

Ja, ich kann doch nicht generische Schriftfamilien predigen und gleichzeitig selbst Schriftnamen angeben.

Wie auch immer, es ist nicht weniger inkorrekt(TM), dass du XHTML 1.1 als text/html auslieferst...

...was ich nicht beeinflussen kann und außerdem noch zu allerlei Problemen in verschiedensten Browsern führen würde.

emu
[der sich fragt, ob er em nicht etwas missbraucht]

[molily]

Hallo, emu,

Naja, bezüglich font-size:0.9em kannst du dich noch auf Verdana und die mangelnde Unterstützung von font-size-adjust herausreden...

Das ist wegen den illusorischen, viel zu großen Standardeinstellungen des Internet Explorers.

»Das sagen sie alle!« Auch und vor allem die Pixelschubser. ;)

ups, ist ja nur sans-serif angegeben

Ja, ich kann doch nicht generische Schriftfamilien predigen und gleichzeitig selbst Schriftnamen angeben.

Einerseits argumentieren, dass die Standardeinstellungen der Lesbarkeit nicht zuträglich sind, aber andererseits hässliche serifenlose Standardschriften wie Arial in Kauf nehmen... *fg*

Wie auch immer, es ist nicht weniger inkorrekt(TM), dass du XHTML 1.1 als text/html auslieferst...

...was ich nicht beeinflussen kann und außerdem noch zu allerlei Problemen in verschiedensten Browsern führen würde.

Das sollte auch nicht heißen, dass ich vorschlage, XHTML 1.1 mit application/xhtml+xml zu verwenden - das ist tatsächlich momentan nicht »verantwortbar« im Bezug auf Interoperabilität - sondern XHTML 1.0 Strict mit text/html im Rahmen der Kompatibilitätsrichtlinien, da XHTML 1.1 nur Nachteile bringt und der Code gleichbleiben kann.

Mathias

[Tim Tepaße]

Hallo Mathias,

Das sollte auch nicht heißen, dass ich vorschlage, XHTML 1.1 mit application/xhtml+xml zu verwenden - das ist tatsächlich momentan nicht »verantwortbar« im Bezug auf Interoperabilität - sondern XHTML 1.0 Strict mit text/html im Rahmen der Kompatibilitätsrichtlinien, da XHTML 1.1 nur Nachteile bringt und der Code gleichbleiben kann.

Ich funke mal neugierig dazwischen: Welche Nachteile denn? Und das gerade von euch beiden. :-)

• Tim

[molily]

Hallo, Tim,

Das sollte auch nicht heißen, dass ich vorschlage, XHTML 1.1 mit application/xhtml+xml zu verwenden - das ist tatsächlich momentan nicht »verantwortbar« im Bezug auf Interoperabilität - sondern XHTML 1.0 Strict mit text/html im Rahmen der Kompatibilitätsrichtlinien, da XHTML 1.1 nur Nachteile bringt und der Code gleichbleiben kann.

Ich funke mal neugierig dazwischen: Welche Nachteile denn? Und das gerade von euch beiden. :-)

Wieso »gerade von uns beiden«?
Als XHTML ausgeliefertes XHTML 1.1 wird bekanntermaßen von vielen Browsern, welche nur HTML verstehen, nicht richtig gehandhabt, im schlimmsten Fall wird ein Downloaddialog angezeigt, weil der Medientyp unbekannt ist. Selbst wenn man XHTML 1.1 als text/html ausliefert, besteht das Problem, dass Linkanker über das name-Attribut verboten sind, was dazu führt, dass der Anker in alten Browsern, welche zudem das id-Attribut nicht als anker betrachten, nicht annavigierbar ist. Das lang-Attribut ist auch nicht mehr vorhanden, das dürfte für Screenreader interessant sein. Screenreader wissen nicht mehr, als der Browser weiß beziehungsweise liefert, auf welchem selbiger aufsetzt (meist MSIE, ob der xml:lang versteht und über MSAA zur Verfügung stellt, weiß ich nicht), sodass die Wahrscheinlichkeit sehr hoch ist, dass der Text in einer falschen Sprache vorgelesen wird.

Wie gesagt enthält http://www.w3.org/TR/xhtml-media-types/ die Erklärungen, warum ein Browser ein XHTML-Dokument im Vergleich zu einem HTML-Dokument völlig anders handhabt:
»XHTML documents served as 'text/html' will not be processed as XML, e.g. well-formedness errors may not be detected by user agents. Also be aware that HTML rules will be applied for DOM and style sheets (see C.11 and C13 of respectively).«

C.11 http://www.w3.org/TR/xhtml1/#C_11 beschreibt Unterschiede beim DOM-Zugriff zwischen (als ... ausgelieferten) HTML- und XHTML-Dokumenten, auch bei Stylesheets ist der Zugriff unterschiedlich http://www.w3.org/TR/xhtml1/#C_13, sodass ein Stylesheet unterschiedliche Resultate bei einem XHTML und einem HTML-Dokument erzielen kann.

Das alles steht aber auch in den Kompatibilitätsrichtlinien... http://www.w3.org/TR/xhtml1/#guidelines

In XHTML 1.1 wird nicht ausdrücklich verboten, 1.1-Markup als text/html auszuliefern (oder ich finde es nicht), da es aber keine Kompatibilitätsrichtlinien gibt, vererbt sich wohl das STRONGLY RECOMMENDED beziehungsweise SHOULD im Bezug auf application/xhtml+xml von XHTML 1.0.
Im Grunde kann der Autor das Dokument mit dem Datentyp ausliefern, der ihm beliebt... Ich sehe nur nicht ein, wieso man sich in den Fuß schießen sollte, indem man XHTML 1.1 verwendet, vor allem um es dann wieder der Kompatibilität wegen als HTML auszuliefern, einen Sinn hat das nicht unbedingt...

Grüße,
Mathias

[Tim Tepaße]

Hallo Mathias,

Wieso »gerade von uns beiden«?

Weil eure beiden Seiten zu den kompromißlosesten Seiten im Netz gehören, die ich kenne, was durchaus als Kompliment gemeint ist.

Als XHTML ausgeliefertes XHTML 1.1 wird bekanntermaßen von vielen Browsern, welche nur HTML verstehen, nicht richtig gehandhabt, im schlimmsten Fall wird ein Downloaddialog angezeigt, weil der Medientyp unbekannt ist.

Seufz. Medientypen scheinen immer wichtiger zu werden (bzw. allmählich ihre ihnen zugedachte Wichtigkeit zu erreichen). Wird langsam Zeit für mich, mich mal näher damit zu beschäftigen.

Danke für die Informationen!

• Tim

[molily]

Hallo, Tim,

Wieso »gerade von uns beiden«?

Weil eure beiden Seiten zu den kompromißlosesten Seiten im Netz gehören, die ich kenne, was durchaus als Kompliment gemeint ist.

*g* Wobei zumindest bei mir die technische Kompromisslosigkeit nicht unbedingt mit dem bewussten gestalterischen Minimalismus zu tun hat, oder dessen Wirkungsabsicht in Einheit mit dem Inhalt, es erweckt eher das Klischee der Seite eines als »HTML-Puristen« gebrandmarkten, langweilig und öde und so weiter. Damit kann ich aber leben, da beides eher wenig miteinander zu tun hat. Ich bin nunmal ein Webautor und kein Grafiker, weshalb diese »Kompromisslosigkeit« nicht unbedingt darauf gewachsen ist, dass ich womöglich ansprechend gestaltete Seiten mit starkem Grafikgebrauch nicht mag, ganz im Gegenteil. Ich hielt es nur für meine private Seite nicht adäquat, was nicht ausschließt, dass ich anderweitig waghalsiger gerne mit Farben, Formen und (zugegeben punktuell eingesetzten) Grafiken expermentiere; was aber auch auf meiner Netzseite einsehbar ist, nur eben nicht die Hauptgestaltung prägt.

Danke für die Informationen!

http://www.hixie.ch/advocacy/xhtml ist vielleicht auch interessant (bitte aber nicht alles glauben - einigen Argumenten kann ich absolut nicht zustimmen, ich finde auch, dass der Typ teilweise eine bornierte Sicht hat, zumindest anhand dessen, wie er sich auf der www-html-Liste verhält, in dessen Archiven sic übrigens auch einiges finden lässt).

Leider habe ich noch kein Dokument gefunden, welches die tatsächlichen Unterschiede im Bezug auf JavaScript und CSS anschaulich erläutert (ich weiß nur von dem tbody-Problem, und das mit der Kleinschreibung bei nodeName kann ich auch nicht reproduzieren, vielleicht liegt es an den Browsern, die nicht W3C-genau arbeiten, denn ich bekomme auch bei als XHTML ausgezeichnetem XHTML den Elementnamen in Großbuchstaben, und getElementsByTagNname u.ä. ist scheinbar auch case-insensitive, ich kann mich aber irren).

Grüße,
Mathias

[Calocybe]

Moin moin!

http://www.hixie.ch/advocacy/xhtml ist vielleicht auch interessant

Ist es in der Tat. Zwar habe ich mich bisher schon auf HTML4.01 beschraenkt, schlicht weil ich keinen Vorteil in XHTML1.0 gesehen hatte, doch weiss ich jetzt, warum ich vorerst dabei bleiben sollte.

So long

[Christian Seiler]

Hallo Mathias,

http://www.hixie.ch/advocacy/xhtml

Wie wäre es, wenn man XHTML-Dokumente so filtert, dass wenn in der ACCEPT-Zeile vom UA application/xhtml+xml steht, dann das Dokument "normal" ausgeliefert wird, wenn nicht, dann sollen folgende Aktionen durchgeführt werden:

a) Content-Type: text/html
b) s!<?xml.[^?]?>!!g
c) s! />!>!g
d) s!xml:!!g (primär wg. xml:lang)
e) s!xmlns(?::[^=]*)?="[^"]*"!!g (ist das so überhupt korrekt, als regulärer Ausdruck? - ich meine die 2 Doppelpunkte)
f) s!<[CDATA[!<!--!g
g) s!]]>!-->!g
h) s!<!DOCTYPE[^>]*>!<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">!g (meinetwegen auch Strict - hoffentlich hab' ich da alles richtig)

Somit dürfte das ganze dann auf "normales" HTML 4 runtergestrippt sein. AFAIK senden nämlich nur XHTML-Konforme Browser einen entsprechenden DOCTYPE. Natürlich könnte man die veränderten Dokumente auch Cachen, damit der Server nicht jedes Mal ungeheuer belastet wird. Hab' ich was vergessen? Sonstige Anregungen?

Grüße,

Christian

[molily]

Hallo, Christian,

Wie wäre es, wenn man XHTML-Dokumente so filtert, dass wenn in der ACCEPT-Zeile vom UA application/xhtml+xml steht, dann das Dokument "normal" ausgeliefert wird, wenn nicht, dann sollen folgende Aktionen durchgeführt werden:

Ja, keine schlechte Idee. Für statische Seiten ist es recht einfach zu lösen, für dynamische wäre ein Output Buffer notwendig... sehr umständlich. Mit dutzenden Templates und Includes wird das schnell zum Problem, vor allem wenn die Includes (X)HTML-Code ausgeben anstatt beispielsweise an einem Dokument über das DOM zu werkeln oder den Code abstraktert einbindet. Bei meinen Projekten habe ich nie eine strikte Trennung zwischen Verarbeitung und variablen Daten (Schande), dadurch wäre es mir nicht möglich, ausgelagerte Daten jedes Mal von neuem je nach Accept-Header zu verwenden.

Bei mir sähe das dann momentan folgendermaßen aus:

if ($accept-xhtml)
 echo('<p>foo<br />bar</p>');
else
 echo('<p>foo<br>bar</p>');

Bei ausgelagerten Daten wäre es im Grunde genommen auch nicht besser:

$murks['xhtml']='<p>foo<br />bar</p>';
$murks['html']='<p>foo<br>bar</p>';

und

if ($accept-xhtml)
 echo($murks['xhtml']);
else
 echo($murks['html']);

Dann eher:

echo($murks[$accept-xhtml]);

Doppelte Inhalte wären dennoch von Nöten.

Sonderlich sinnvoll, jedes Markupschnipsel einzeln zu behandeln, ist es auch nicht:

echo(return xhtml-transform($murks));

Immerhin sind die statischen Methoden, welche vordefinierten Code einbinden, welcher jeweils einmal in XHTML und einmal in HTML definiert ist, besser für den Gebrauch auf dynamischen Seiten, welche jedes Mal individuell erzeugt werden und dadurch die Zeit sowieso kritisch ist.

Das Erstellen der jeweils doppelten statischen Inhalte kann natürlich automatisiert werden, hier würde dann das Caching greifen. Falls sich der Timestamp der include-Datei geändert hat, kann das System die Versionen immer noch on-the-fly neu erzeugen.

a) Content-Type: text/html
b) s!<?xml.[^?]?>!!g
c) s! />!>!g

Gibt es eigentlich Unterschiede der DTDs von HTML 4.01 Strict und XHTML Strict gibt, welche XHTML-Markup zu invalidem HTML-Markup machen würden - mir fallen keine ein, man sollte aber darüber nachdenken.

d) s!xml:!!g (primär wg. xml:lang)

Je nach Eingabe müsste man wohl das ganze xml:lang-Attribut streichen, falls das Ausgangsdokument nach den Kompatibilitätsrichtlinien verfasst ist (muss es aber nicht beziehungsweise sollte es nicht, falls man eine Transformation vornehmen will).

e) s!xmlns(?::[^=]*)?="[^"]*"!!g (ist das so überhupt korrekt, als regulärer Ausdruck? - ich meine die 2 Doppelpunkte)

Ich verstehe nichts, ich kenne diese Syntax nicht... Soll das eine lookahead assertation sein...? Wozu zwei Doppelpunkte, der eine für xmlns:[namespace]="..." und der andere für die assertation? Diese Form kenne ich nicht.

Täusche ich mich oder würde folgendes ausreichen:

xmlns(:[^=]+)?="[^"]*"

Es gibt doch keine »verschachtelten« Namespace-Angaben... http://www.w3.org/TR/REC-xml-names/#NT-NSAttName

f) s!<[CDATA[!<!--!g

Du solltest vielleicht andere delimiter verwenden... Es kommt nicht gut, wenn die Delimiter unmaskiert im Ausdruck auftauchen.

g) s!]]>!-->!g

Naja, setzt natürlich voraus, dass CDATA-Bereiche nur in script- und style-elementen verwendet werden,

h) s!<!DOCTYPE[^>]*>!<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">!g (meinetwegen auch Strict - hoffentlich hab' ich da alles richtig)

Siehe oben, Strict sollte aber möglich sein.

Lässt sich das Ganze nicht vereinfachen, indem man eine XSL-Transformation vornimmt, bei welcher nichts geändert wird und die Ausgabe schlichtweg HTML ist...? Die paar RegExps wären vermutlich perfomanter und nicht jeder hat einen XSLT-Prozessor auf dem Server zur Verfügung.

Somit dürfte das ganze dann auf "normales" HTML 4 runtergestrippt sein.

Soweit ich das beurteilen kann, ist die Liste recht vollständig.

AFAIK senden nämlich nur XHTML-Konforme Browser einen entsprechenden DOCTYPE.

Meintest du »Accept«...? Ja, ich denke schon. Momentan wäre es nur Mozilla, welchem XHTML ausgeliefert würde. Bei Amaya und Konqueror weiß ich es nicht.

Natürlich könnte man die veränderten Dokumente auch Cachen, damit der Server nicht jedes Mal ungeheuer belastet wird.

Bei generierten Seiten ist das wie gesagt nicht einfach.

Grüße,
Mathias

[Christian Seiler]

Hallo Mathias,

Sonderlich sinnvoll, jedes Markupschnipsel einzeln zu behandeln, ist es auch nicht:

echo(return xhtml-transform($murks));

Ich persönlich verwende ja sowieso fast ausschließlich Smarty, da könnte man 2 verschiedene Templates verwenden.

Immerhin sind die statischen Methoden, welche vordefinierten Code einbinden, welcher jeweils einmal in XHTML und einmal in HTML definiert ist, besser für den Gebrauch auf dynamischen Seiten, welche jedes Mal individuell erzeugt werden und dadurch die Zeit sowieso kritisch ist.

Da stimme ich Dir zu.

Das Erstellen der jeweils doppelten statischen Inhalte kann natürlich automatisiert werden, hier würde dann das Caching greifen. Falls sich der Timestamp der include-Datei geändert hat, kann das System die Versionen immer noch on-the-fly neu erzeugen.

Smarty besitzt eine sehr gute Caching-Funktion, ich denke, das wird keine Probleme geben.

a) Content-Type: text/html
b) s!<?xml.[^?]?>!!g
c) s! />!>!g

Gibt es eigentlich Unterschiede der DTDs von HTML 4.01 Strict und XHTML Strict gibt, welche XHTML-Markup zu invalidem HTML-Markup machen würden - mir fallen keine ein, man sollte aber darüber nachdenken.

Nein. XHTML 1.0 = HTML 4.01 bis auf die "Sache mit dem XML"[tm]. Zumindest wurde das mir immer gepredigt. ;)

d) s!xml:!!g (primär wg. xml:lang)

Je nach Eingabe müsste man wohl das ganze xml:lang-Attribut streichen, falls das Ausgangsdokument nach den Kompatibilitätsrichtlinien verfasst ist (muss es aber nicht beziehungsweise sollte es nicht, falls man eine Transformation vornehmen will).

Eben, ich denke, man kann prima xml:lang verwenden, das ist kein Problem.

e) s!xmlns(?::[^=]*)?="[^"]*"!!g (ist das so überhupt korrekt, als regulärer Ausdruck? - ich meine die 2 Doppelpunkte)

Ich verstehe nichts, ich kenne diese Syntax nicht... Soll das eine lookahead assertation sein...?

Nein, (hallo) machted hallo, (?:hallo) matched auch hallo, aber der Ausdruck steht dann nicht in $matches bzw. wird nicht einer Variable ($1, $2, etc.) fürs ersetzen zugewiesen. In dem Fall ist es eigentlich egal... (ich weiß aber immer noch nicht, ob die zwei Doppelpunkte valide sind, mal nachschauen)

Wozu zwei Doppelpunkte, der eine für xmlns:[namespace]="..." und der andere für die assertation? Diese Form kenne ich nicht.

Täusche ich mich oder würde folgendes ausreichen:

xmlns(:[^=]+)?="[^"]*"

Man müsste mal einen Benchmark machen, was schneller ist.

Es gibt doch keine »verschachtelten« Namespace-Angaben... http://www.w3.org/TR/REC-xml-names/#NT-NSAttName

f) s!<[CDATA[!<!--!g

Du solltest vielleicht andere delimiter verwenden... Es kommt nicht gut, wenn die Delimiter unmaskiert im Ausdruck auftauchen.

Ähm, ja, ich meinte natürlich s!<[CDATA[!<!--!g ;-)
Das mit den Delimitern ist so eine Sache, ich könnte natürlich so etwas wie ° verwenden, aber dann sehe ich die Trennung nicht mehr so gut - bei einem "großen" Zeichen wie ! oder / sieht man dagegen schon, wo der Ausdruck anfängt aus aufhört - naja, obwohl: preg_replace hat ja zwei Parameter für...

g) s!]]>!-->!g

Naja, setzt natürlich voraus, dass CDATA-Bereiche nur in script- und style-elementen verwendet werden,

Hmm, klar, aber ich kann nicht einfach noch Style/Script-Bereiche abfangen, dann könnte ich das Dokument gleich parsen...

h) s!<!DOCTYPE[^>]*>!<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">!g (meinetwegen auch Strict - hoffentlich hab' ich da alles richtig)

Siehe oben, Strict sollte aber möglich sein.

Naja, je nachdem, in welcher "Sprache" das Dokument ist - eine XHTML-Transitional-Dokument kannst Du nicht in ein HTML-Strict-Dokument umwandeln, zumindest nicht automatisch.

Lässt sich das Ganze nicht vereinfachen, indem man eine XSL-Transformation vornimmt, bei welcher nichts geändert wird und die Ausgabe schlichtweg HTML ist...?

Sicherlich, aber...

Die paar RegExps wären vermutlich perfomanter und nicht jeder hat einen XSLT-Prozessor auf dem Server zur Verfügung.

Genau das ist der Punkt. XSL ist "eleganter", aber langsamer und weniger weit verbreitet. preg_* hat jeder. (bzw. bei Perl ist das eingebaut)

Meintest du »Accept«...?

Ähhh, ja, war wohl schon ein bisschen müde...

Ja, ich denke schon. Momentan wäre es nur Mozilla, welchem XHTML ausgeliefert würde. Bei Amaya und Konqueror weiß ich es nicht.

Konqueror: ACCEPT: text/*, image/jpeg, image/png, image/*, */*
Amaya 6.4: ACCEPT: */*;q=0.1,image/svg+xml,application/mathml+xml,application/xhtml+xml
(über http://www.schroepl.net/cgi-bin/http_trace.pl)

Natürlich könnte man die veränderten Dokumente auch Cachen, damit der Server nicht jedes Mal ungeheuer belastet wird.

Bei generierten Seiten ist das wie gesagt nicht einfach.

Wenn man sowieso Templates verwendet und diese auch noch cached, sehe ich kein Problem.

Grüße,

Christian

[Calocybe]

Hi there!

Natürlich könnte man die veränderten Dokumente auch Cachen, damit der Server nicht jedes Mal ungeheuer belastet wird. Hab' ich was vergessen? Sonstige Anregungen?

Options +Multiviews

Das sucht dann automatisch die richtige Variante von statischen Seiten aus, nachdem Du mit einem entsprechenden Tool alle *.xhtml in *.html umgewandelt hast. Ginge theoretisch auch mit dynamischen Seiten, indem Du die Dateien *.xhtml.php nennst und in *.html.php umwandelst. Dann jedoch muesste Dein Tool so gut sein, die PHP-Bereiche in den Dateien unangetastet zu lassen, und diese Bereiche muessten selbst dafuer sorgen, die richtige Variante auszugeben.

So long

[Sven Rautenberg]

Moin!

Wie wäre es, wenn man XHTML-Dokumente so filtert, dass wenn in der ACCEPT-Zeile vom UA application/xhtml+xml steht, dann das Dokument "normal" ausgeliefert wird, wenn nicht, dann sollen folgende Aktionen durchgeführt werden:
Hab' ich was vergessen? Sonstige Anregungen?

Vergessen hast du etwas die Realität - und die sieht so aus:

IE (5 + 6):
ACCEPT: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoint, */*
(Anmerkung: Sehr spannend - der IE versteht gar kein HTML. Aber das wissen wir ja schon längst... :-> ).

Opera 6.03:
ACCEPT: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*

Mozilla 1.2.1:
ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
(Interessant: Mozilla bevorzugt XHTML).

Es gibt also kaum Browser, die per Content Negotiation XHTML abkriegen würden. Und der IE kriegt eigentlich gar keine Seite zu sehen. Ok, das */* rettet ihn etwas.

- Sven Rautenberg

[Christian Seiler]

Hallo Sven,

IE (5 + 6):
ACCEPT: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/vnd.ms-excel, application/vnd.ms-powerpoint, */*

Ja wo ist denn da das Problem? Der IE kapiert eh' kein XHTML...

Opera 6.03:
ACCEPT: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*

Unterstützt Opera XHTML? Wenn ja, dann ist es Pech, wenn nein, umso besser. (Kanns im Moment nicht nachprüfen, Netzwerkkarte im Eimer)

ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1

Ist doch prima.

Es gibt also kaum Browser, die per Content Negotiation XHTML abkriegen würden.

Es gibt aber auch kaum Browser, die XHTML verstehen, oder?

Und der IE kriegt eigentlich gar keine Seite zu sehen.

Warum nicht? Mir ging es jetzt nur um application/xhtml+xml. Wenn dies nicht vorhanden ist, wird stillschweigend eine text/html-Seite mit HTML4 ausgeliefert, egal, ob text/html im Accept-Header steht, oder nicht. Ich denke, dass ein Browser, der XHTML versteht, das auch dem Server mittelen sollte. Wenn er das nicht tut, ist er selber schuld.

Grüße,

Christian

P.S.: wo ist denn eigentlich mein jüngster Thread? Der wird doch wohl nicht schon im Archiv sein...?

[emu]

Hallo!

Wieso »gerade von uns beiden«?

Weil wir nicht gezwungen sind, Geld mit unseren Seiten zu verdienen und es uns leisten können, HTML und CSS in Reinkultur zu predigen? :-)

Selbst wenn man XHTML 1.1 als text/html ausliefert, besteht das Problem, dass Linkanker über das name-Attribut verboten sind, was dazu führt, dass der Anker in alten Browsern, welche zudem das id-Attribut nicht als anker betrachten, nicht annavigierbar ist.

Ich verwende es nur auf der Hauptseite, die anderen Seiten, bei denen diese Beschränkung relevant ist, sind 1.0.

Das lang-Attribut ist auch nicht mehr vorhanden

Macht sowieso nur Probleme.

sodass die Wahrscheinlichkeit sehr hoch ist, dass der Text in einer falschen Sprache vorgelesen wird.

Gibt es tatsächlicheinen mehrsprachigen Screenreader, der anhand der seiteninternen Sprachangaben vorliest?

Im Grunde kann der Autor das Dokument mit dem Datentyp ausliefern, der ihm beliebt... Ich sehe nur nicht ein, wieso man sich in den Fuß schießen sollte, indem man XHTML 1.1 verwendet, vor allem um es dann wieder der Kompatibilität wegen als HTML auszuliefern, einen Sinn hat das nicht unbedingt...

Ich auch nicht. Keine Ahnung, was ich mir damals gedacht habe, vielleicht ändere ich es einmal.

emu
[...]

[molily]

Hallo, emu,

Wieso »gerade von uns beiden«?

Weil wir nicht gezwungen sind, Geld mit unseren Seiten zu verdienen und es uns leisten können, HTML und CSS in Reinkultur zu predigen? :-)

Exakt, so ist es. Von der grausamen und ernüchternden Realität des Webdesigns[tm] sind wir weit entfernt und protzen mit unseren minimalistischen idealisierten Seiten und stellen zu allem Überfluss Vergleiche an und wollen belehren und missionieren...

Gibt es tatsächlicheinen mehrsprachigen Screenreader, der anhand der seiteninternen Sprachangaben vorliest?

Ja. Oft sind mehrsprachige Wörterbücher vorhanden beziehungsweise auch Texte anderer Sprachen können synthetisiert werden.
Zumindest habe ich dies auf W3C-WAI-DE gelesen. Die von den Zugänglichkeitsrichlinien empfohlenen Techniken zahlen sich widererwartend direkt aus.

Grüße,
Mathias