Semantisch korrekt oder simpel und leicht [Archiv]

mitaki

10.08.2006, 19:40

Eines vorweg, mit deiner Überschrift implizierst du, sematisch korrektes HTML sei nicht simpel und leicht.

h1, p, blockquote, ul, ol und wie sie nicht alle heißen sind alle bereits mit Formatierungen ausgestattet. Das erlaubt es graphischen Browsern, ohne weitere Stylesheetangaben ein Dokument so darzustellen, dass man Überschriften und Absätze voneinander unterscheiden kann.

Im Gegensatz dazu wäre eine div/span Suppe a la

<div class="ueberschrift"><span class="kategorie1">Hallo</span> <span class="separator">>></span> <span class="kategorie2">Welt</span> <span class="satzzeichen">!</span>
Das habe ich mir nicht ausgedacht. Entsprechende (http://www.hr-online.de/website/index.jsp) Fälle (http://www.db.de/site/bahn/de/start.html) sind (http://www.freenet.de/freenet/) keine (http://www.cnn.com/) Seltenheit (http://www.aol.de/). Freenet bringt es auf 445 <div>s...
Wenn das nicht kompliziert ist?

Ich selbst gehe so gut wie möglich semantisch vor. Die Überschriften erster und zweiter Ordnung verstecke ich, da sie nur für Textbrowser relevant sind. Die anderen verwende ich je nach Bedarf.
Ich verwende kein <b> und kein <i> (<u> sowieso nicht), stattdessen verwende ich <em> und <strong>. Halt mag jetzt jemand sagen, semantisch etwas falsch verwenden ist doch böse.
Das ist richtig, aber indem ich nur <em> und <strong> verwende zwinge ich mich selbst immer wieder nachzudenken, ob dieses Wort wirklich betont werden muss. Nicht selten bin ich dann zur Entscheidung der Nichtnotwendigkeit gekommen.
Auch verwende ich Listen, dank Stylesheets sieht man es ihnen aber nicht an, man hat eben künstlerische Freiheit :)

Sematisches Auszeichnen mit HTML macht viel Sinn:

Nicht-graphische Browser (Braille, Speaker, etc.) sprechen keinen langen Fließtext, sondern Überschriften und Absätze mit entsprechender Betonung.
Suchmaschienen können korrektes HTML besser Verarbeiten und weisen ihm mehr bedeutung zu. Das bezieht sich teilweise auf die strengere XHTML Syntax.

Maisaffe

10.08.2006, 21:14

Auflistungen meist in Listenelementen, Menü's vielleicht demnächst in Listenelementen (habe schonmal ein Versuch mit CSS gestartet und es war garnichtmal so übel).
Gegen Tabellenwebseiten habe ich nicht's einzuwenden, propagandiere jedoch lieber CSS Webseiten, da diese "komplizierter" umsetzbar sind und viele Leute sich von einfachen Betitelungen wie "Kann jeder Benutzer lesen oder vorlesen lassn, geniale Barrierefreiheit, bla..." begeistern lassen - auch wenn die Seiten der Leute garnicht für diese kleinere Gruppe von Menschen gemacht sein sollte/ müsste. :D

Im Grunde ist es mir Schnuppe wie jemand seine Seite erstellt, aber ich lege Wert auf selbstgeschriebenen Code (von mir aus auch per PHP verunstaltet in der "schönen" Form - sprich Einrückungen usw.).

Wenn ich für jemand ein Design slicen soll verwende ich auch nur CSS, wenn ich ein Slice ausbessern soll das auf Tabellen bassiert kommt es auf die Tabelleneinteilung an, erstelle jedoch meist auch wieder auf CSS basierende Enddateien (aber auch nur wenn ich mit dem Tabellenzeug das ich geliefert bekomme nicht allzuviel anfangen kann ohne mich groß damit zu beschäftigen [habe kein WYSIWYG Editor - will auch nur selten einen ;)] - die finde ich einfach schöner. :o

Zu Texten: Ich verwende meist <div> Elemente für Texte, ich verstehe die <p> Elemente nicht so richtig wegen Ihrer äußeren Formatierung - und deren Abständen - aber ich habe mich auch noch nie richtig mit ihnen beschäftigt.

drunken monkey

11.08.2006, 10:43

Ich habe nie Tabellen für Layouts verwendet, würde mich da auch erstmal einarbeiten müssen, daher bleibe ich sicher bei der <div>-Variante. Überschriften kennzeichne ich auch immer mit entsprechenden <h*>-Tags und verwende für Absätze in letzter Zeit auch meistens <p>-Elemente.
Den ganz radikal korrekten Kurs mit <strong>, <em> und Listen bei der Navigation habe ich allerdings nicht eingeschlagen, kommt aber vielleicht noch, wenn ich mal eine komplett neue Site machen sollte. Grundsätzlich finde ich nämlich schon, dass man Elemente so verwenden sollte, wie sie vorgesehen sind, das W3C bestimmt das ja nicht aus Willkür oder zum Spaß. o_O

@ Dennis: Die Abstände bei <p>-Elementen bekommst du doch ganz einfach mit "padding: 0px; margin: 0px;" weg. o_O

Maisaffe

11.08.2006, 11:45

@ Dennis: Die Abstände bei <p>-Elementen bekommst du doch ganz einfach mit "padding: 0px; margin: 0px;" weg. o_O
Ich weiß, aber das wäre dann unnötig, da kann man dann gleich <div> Elemente nehmen. ;)

Manni

11.08.2006, 13:33

Ich weiß, aber das wäre dann unnötig, da kann man dann gleich <div> Elemente nehmen. ;)

Eben nicht. Es geht ja gerade um die Vorformatierung, die zB in Textbrowsern bzw bei fehlendem CSS ihre Wirkung zeigt. Und es geht ums Prinzip: <div>s sind nichtssagende Tags, die keine besondere Bedeutung haben, sondern eben einfach nur zur Formatierung benutzt werden können. <p>s sind Absätze, sie haben also eine sinnvolle Bedeutung innerhalb des Textes.

mitaki

11.08.2006, 13:50

ne, navi mach ich ned als listen, sondern einfach als untereinanderstehende links die alle display:block gedingst werden.
Warum soll das besser sein als eine Liste? Listen sind entsprechend formatierbar und im Textbrowser auch als soclche erkennbar.

Wobei ich Tabellendesigns nicht so schlimm finde, wie die meisten anderen hier im Forum Tabellen sind halt einfach praktisch. Und ob divs mit display: inline-table oder sowas wirklich besser sind - Ich glaubs nicht.
Vermutlich ist gegen eine einzge Tabelle nichts auszusetzen, mein altes Projekt basierte beispielsweise auch auf einer Tabelle und war mit Lynx sehr gut darstellbar.

Tatsache ist aber, dass sich mit Stylesheets wesentlich mehr herausholen lässt, und das, obwohl einige werwirrte Leute noch eine bestimmte Software als Browser misverstehen.

Gegen Tabellenwebseiten habe ich nicht's einzuwenden, propagandiere jedoch lieber CSS Webseiten, da diese "komplizierter" umsetzbar sind und viele Leute sich von einfachen Betitelungen wie "Kann jeder Benutzer lesen oder vorlesen lassn, geniale Barrierefreiheit, bla..." begeistern lassen - auch wenn die Seiten der Leute garnicht für diese kleinere Gruppe von Menschen gemacht sein sollte/ müsste.
CSS ist nicht komplizierter. Der HTML Code lässt sich bei standardnahen Designs besser Warten als mit unzählich verschachtelten Tabellen. Sicher werden dann mehr als 4 <div>s gebraucht, mit denen ich z.B. in meinem aktuellem Projekt auskomme.
Aber du darfsst gutes CSS Design nicht mit meinen Negativbeispielen oben verwechseln.

Zum Vorlesen: Ich selbst und viele meiner Bekannten lassen sich Internetseiten vorlesen, obwohl unsere Augen noch sehr gut sehen. Von daher sollte man nicht ausgehen, dass nur blinde Menschen sich was vorlesen lassen.

Bezüglich Barrierefreiheit: Ist dir schon mal in den Sinn gekommen, dass immer mehr Mobiltelefone und Handhelds (Tragbare PDAs, die PSP, Nintendo DS) im internet surfen können? Wie sollen diese Geräte deine Seiten darstellen? Und besitzer dieser Geräte können durchaus zu deiner Zielgruppe gehören!
Gerade deshalb ist es auch wichtig <p> statt <div> zu verwenden!
<p> sagt einem graphischen Browser dass ein Absatz von einem anderem unterschieden werden kann. Dies trifft auch ohne formatierung auf Textbrowser zu.
Verwendest du dagegen <div> Sieht man nur lauter zusammengeklebte Textblöcke und ich tu mich schwer, dem Text dann entsprechend Bedetung zuzurdnen, so geht es sicher auch manchen Suchmaschinen.

Maisaffe

11.08.2006, 14:09

Ich habe komplizierter extra in Anführungszeichen gesetzt. ;)

Zu den Zielgruppen und den alternativ Geräten (vor allem Nintendo DS dürfte so gut wie keine Probleme mit Tabellendesigns haben, da man auf dem unteren Bildschirm im Normalmodus ja die Seite sieht undmit dem Stylus "befährt" um auf dem Topscreen das ganze größer zu betrachten): Das ist mir schon klar, aber so viele Menschen verwenden diese Geräte (noch) nicht (oder noch nicht richtig).
Bandwebseiten z.B. beinhalten meist nicht wirklich informatives auser den Tourdaten und vielleicht ein oder 2 interessante Geschichtchen über die Band, der Rest besteht meist aus irgendwelchem Vorzeige MP3s oder die Seite ist komplett aus Flashelementen, solche Seiten bekommt man schwer auf die mobilen Geräte - da hat man meist nur eine spezielle Seitenversion als Alternative auf HTML Basis mit wenig Schnick- Schnak. Die sollte dann natürlich angepasst sein an die Mobile Geräte.

Nocheinmal zu der <div> und <p> Geschichte: Ich verwende meist nur ein <div> und darin kommt der gesamte Inhalt (mit <br /> Absätzen) - macht da ein Vorlesebrowser/ Programm wirklich so große Unterschiede (wenn 2x <br /> statt <p>)?

Was für ein Programm/ Browser verwendest Du für das vorlesen? Ich habe bis jetzt nur schlechte Erfahrung mit diesen Anwendungen gesammelt, sprich: Texte waren schlecht verständlich von der Stimme.

Eben nicht. Es geht ja gerade um die Vorformatierung, die zB in Textbrowsern bzw bei fehlendem CSS ihre Wirkung zeigt. Und es geht ums Prinzip: <div>s sind nichtssagende Tags, die keine besondere Bedeutung haben, sondern eben einfach nur zur Formatierung benutzt werden können. <p>s sind Absätze, sie haben also eine sinnvolle Bedeutung innerhalb des Textes.
Ich erwirke aber das selbe Ergebnis wenn ich 2 <br /> verwenden statt <p> Elemente. Aber ich werde mich mal näher damit befassen wenn Du sagst das die so wichtig sind. ;)

11.08.2006, 15:07

Warum soll das besser sein als eine Liste? Listen sind entsprechend formatierbar und im Textbrowser auch als soclche erkennbar.

Es ist bequemer, imo.
Ich brauche keine Umbrüche, spare Aufwand bei der Formatierung etc.
es ist schon ein unterschied, ob ich

<div class='navi'>
link
link
link
link
</div>

oder

<div class='navi'>
<ul>
<li> link </li> <br />
<li> link </li> <br />
<li> link </li> <br />
<li> link </li> <br />
<li> link </li> <br />
<li> link </li> <br />
</div>

schreiben muss

edit:
code auf nem roten hintergrund ist scheiße >_> man sollte die standartfarbe ändern...

mitaki

11.08.2006, 15:08

Bandwebseiten z.B. beinhalten meist nicht wirklich informatives auser den Tourdaten und vielleicht ein oder 2 interessante Geschichtchen über die Band, der Rest besteht meist aus irgendwelchem Vorzeige MP3s oder die Seite ist komplett aus Flashelementen, solche Seiten bekommt man schwer auf die mobilen Geräte - da hat man meist nur eine spezielle Seitenversion als Alternative auf HTML Basis mit wenig Schnick- Schnak. Die sollte dann natürlich angepasst sein an die Mobile Geräte.
Ich sehe das eher als Kritikpunkt der Band. Aber das ist ein verbreitetes Problem, offizielle Seiten sind so oft so derartig schlecht, das mal am liebsten losheulen möchte :(
Flash ist natürlich eine Ausgeburt der Hölle XD Vor allem wenn "Skip intro" innerhalb der Flashanimation steht :rolleyes: Aber das ist wieder ein ganz anderes Thema.

Was für ein Programm/ Browser verwendest Du für das vorlesen? Ich habe bis jetzt nur schlechte Erfahrung mit diesen Anwendungen gesammelt, sprich: Texte waren schlecht verständlich von der Stimme.
Ja, diverse Freeware ist wirklich nicht sehr gut und ist von daher vermutlich auch nicht, mit speziell dafür ausgelegten Programmen vergleichbar.
Seit kurzem habe ich das Vergnügen auch OS X testen zu dürfen, das über eine eigene Sprachausgabe verfügt.

Was mir bei <br /> auffällt ist, dass die Pause dazwischen relativ kurz ist, was ich persönlich als nervig empfinde. Es sind zwar englische Stimmen, aber das sollte in diesem Fall keine Rolle spielen.

11.08.2006, 15:08

Warum soll das besser sein als eine Liste? Listen sind entsprechend formatierbar und im Textbrowser auch als soclche erkennbar.

Es ist bequemer, imo.
Ich brauche keine Umbrüche, spare Aufwand bei der Formatierung etc.
es ist schon ein unterschied, ob ich
<div class='navi'>
link
link
link
link
</div>

oder
<div class='navi'>
<ul>
<li> link </li> <br />
<li> link </li> <br />
<li> link </li> <br />
<li> link </li> <br />
<li> link </li> <br />
<li> link </li> <br />
</ul>
</div>

schreiben muss

edit:
code auf nem roten hintergrund ist scheiße >_> man sollte die standartfarbe ändern...

edit: *[-tt-]* benutz^^

mitaki

11.08.2006, 15:15

Deine beiden Beispiele entsprechen zwei verschiedenen Anzeigemethoden, was willst du denn nun?
Listenpunkte kannst du sowohl nebeneinander als auch untereinander mit Abstand anzeigen, geht mit Stylesheets viel einfacher als mit <br />.

code auf nem roten hintergrund ist scheiße >_> man sollte die standartfarbe ändern...
Der neuen Führung bereits gemeldet.

Manni

11.08.2006, 16:05

Vermutlich ist gegen eine einzge Tabelle nichts auszusetzen, mein altes Projekt basierte beispielsweise auch auf einer Tabelle und war mit Lynx sehr gut darstellbar.

Tatsache ist aber, dass sich mit Stylesheets wesentlich mehr herausholen lässt, und das, obwohl einige werwirrte Leute noch eine bestimmte Software als Browser misverstehen.

Ich frag mich, warum CSS und Tabellen immer als gegensätzlich gesehen werden. Ich kann meine Tabelle doch auch mit CSS formatieren...

mitaki

11.08.2006, 16:20

Ich frag mich, warum CSS und Tabellen immer als gegensätzlich gesehen werden. Ich kann meine Tabelle doch auch mit CSS formatieren...
Es geht darum, das ich die Tabelle als Designmittel missbraucht habe, unabhängig davon, ob sie mit CSS formatiert wurde oder nicht. Das ist das einzige was an Tabellen kritisiert wird: Dass sie als Gestaltungsmittel und nicht für tabellarische Daten verwendet werden - obwohl Spaltendesigns schon lange mit CSS möglich sind.

Sicher stimmst du mir zu, dass Spalte 1 Menü und Spalte 2 Inhalt weitaus weniger bezug zueinander hat als eine tabellarische Auflistung der Threads in diesem Forum mit entsprechenden Tabellenüberschriften.

Manni

11.08.2006, 16:22

Es geht darum, das ich die Tabelle als Designmittel missbraucht habe. Das ist das einzige was an Tabellen kritisiert wird: Dass sie als Gestaltungsmittel und nicht für tabellarische Daten verwendet werden - obwohl Spaltendesigns schon lange mit CSS möglich sind.

Sicher stimmst du mir zu, dass Spalte 1 Menü und Spalte 2 Inhalt weitaus weniger bezug zueinander hat als eine tabellarische Auflistung der Threads in diesem Forum mit entsprechenden Tabellenüberschriften.

Wenn mein Design eine Tabelle ist, warum soll ich mir unnötig mit <div>s einen abkrampfen?

mitaki

11.08.2006, 16:50

Wenn mein Design eine Tabelle ist, warum soll ich mir unnötig mit <div>s einen abkrampfen?

Weil man außerhalb der Tabelle denken muss :p

Ich weis beispielsweise nicht, welche col/rowspan Mischung ich schreiben muss um eine Tabelle zu erhalten, die eine Kopfzeile hat, in der linken Spalte zwei zellen und in der rechten drei.
In der Praxis bleit es daher aus Erfahrung nicht bei einer Tabelle.

Ein Design ohne Tabelle ist dagegen wesentlich flexibler und kann besser angepasst werden. Der Quelltext wird nicht stark aufgebläht und man findet sich daher relativ schnell gut zurecht.

11.08.2006, 17:04

Deine beiden Beispiele entsprechen zwei verschiedenen Anzeigemethoden, was willst du denn nun?
Listenpunkte kannst du sowohl nebeneinander als auch untereinander mit Abstand anzeigen, geht mit Stylesheets viel einfacher als mit <br />.

mit entsprechenden stylesheets kann man beides gleich formatieren*.
im oberen beispiel würd ich halt einfach auf alle <a> elemente in dem div ein display:block oder wie des heißt (dreamwaver macht faul... :P) legen, und sie wären hübsch untereinander. GENAUSO (also von der letzendlichen anzeige) könnte ich sie auch mit listen Formatieren, allerdings hätt ich da imo mehr codeaufwand.
Ich benut listen eigentlich nur zum Auflisteon von Zutaten, INhaltsverzeichnissen etc.

Ich weis beispielsweise nicht, welche col/rowspan Mischung ich schreiben muss um eine Tabelle zu erhalten, die eine Kopfzeile hat, in der linken Spalte zwei zellen und in der rechten drei.
In der Praxis bleit es daher aus Erfahrung nicht bei einer Tabelle

Ein weiterer Grund für Divs, sie sind einfacher ;) *erinnere mich, wie ich mich mit solchen problemen abgearbeitet hab*

* Eigentlich kann man dank CSS jedes Tag stellvertretend für jedes andere Verwenden (außer das bei manchen [leider] manche attribute nicht möglich ist)
Wenn für h1 z.b. alle attribute erlauft wären wie für div, könnte man ne ganze page nur mit h's stylen 8)

mitaki

11.08.2006, 17:40

GENAUSO (also von der letzendlichen anzeige) könnte ich sie auch mit listen Formatieren, allerdings hätt ich da imo mehr codeaufwand.
Die Praxis hat gezeigt, das eine allgemeine Standardisierung von Webseites mehr Traffic spart als verursacht ;) Auch wenn manche Sachen erstmal etwas mehr Brauchen. In XHTML 2 kann man daher praktischerweise gleich dem <li> ein href verpassen.
Ich suche mal nach Belegen dafür.

* Eigentlich kann man dank CSS jedes Tag stellvertretend für jedes andere Verwenden (außer das bei manchen [leider] manche attribute nicht möglich ist)
Wenn für h1 z.b. alle attribute erlauft wären wie für div, könnte man ne ganze page nur mit h's stylen
Im moment fallen mir da auch nur href für Verwesie und spezielle Inputattribute ein, ansonnsten könnte man alles nur mit einem einzigen Element machen (Bilder mit Hintergrundbildern^^). BTW: src (von <img />) kann man in XHTML 2 auch jedem Element geben^^

Aber HTML ist halt eie Auszeichnungssprache die mit semantik im Kopf entwickelt wurde.

11.08.2006, 19:34

mitaki

11.08.2006, 19:41

wie meinst du das mit dem scr von anderen elementen?
(werd mir die sachen zu xhtml 2 mal durclnesen müssel, klingt ja alles ganz lecker, nur werden wir wohl noch bis ie 8 warten müssen, um das allen webbenutzern zur verfügung zu stellen :p )
das mit dem href bei li etc ist geil, das brauch ich aber auch bei anderen elementen^^
(link-tabellenzeilen, link-divs etc^^

In XHTML 2 ist das src-Attribut nicht mehr an das <img /> Element gebunden. Man kann stattdessen z.B. <h1 src="titel.bild">Titel der Webseite</h1> schreiben. Ist das Bild nicht verfügbar wird die Überschrift ganz normal angezeigt.

das mit dem href bei li etc ist geil, das brauch ich aber auch bei anderen elementen^^
Ja, href und src für alle Elemente.

Was IE angeht, ich hoffe, MS lässt die Entwickler weiterhin so gut arbeiten, wie sie es im moment tun. Dann kann man mit positiven Änderungen in der Zukunft rechnen.

Ravana

11.08.2006, 21:39

hab frueher nur tabellen benutzt, dann ne weile voellig ohne tabellen und nur mit divs das spaltendesign und bin dann aus eigentlich unerklaerlichen gruenden, wieder zu tabellen zurueck, allerdings jetzt nur ne sehr grundlegende aufteilung mit tabellen, keine so extrem verschachtelten dinger mehr. nur die grundaufteilung, der rest wird mit css gemacht, ist auch alles w3c-validiert, wenn auch nur transitional.
haette eigentlich lust, alles wieder ordentlich zu machen ohne tabellen, aber hab keinen bock, die ganze seite neuzuschreiben -.- naja, die naechste dann wieder :D

wie man daran sieht, dass ich tabellen benutze, mach ichs nicht ganz streng, navigation ist zb auch keine liste. ueberschriften mach ich nicht mit h, weil mich bei h stoert, dass es dann automatisch nen absatz gibt, daher ist mir das unsympathisch ^^ klar, kann man wegmachen.. mag <h> trotzdem nicht.
meine seiten laufen auf ie, ff und opera, mir reichts, wennd die breite masse der normalinternetnutzer zurecht kommt. sie sind sowieso nicht dafuer gedacht, dass jemand sich die dinger aufm handy ansieht, und ein blinder hat auf meiner fotoseite eh nicht viel spass :D
die seiten sehen einigermassen aus, kommen beim validator gut durch, haben ein externes stylesheet und laufen auf den gaengigsten browsern - fuer mich passts :D

dead_orc

11.08.2006, 22:19

Da ich inzwischen wiederholt Kritik daran erhalten habe, dass semantisch korrekt != komplex/kompliziert/whatever ist, möchte ich hier einmal sagen dass ich mit "simpel und leicht" so Aussagen wie

Ich weiß, aber das wäre dann unnötig, da kann man dann gleich <div> Elemente nehmen. ;)
meinte. Da hat man die Wahl zwischen etwas mehr Aufwand mit <hx>, das dafür korrekt wäre, oder viel weniger Aufwand mit <div> (ist nur minimal, da man nur padding und margin anpassen müssen sollte, aber naja). Aber da Dingsi ja nun Mod ist kann er sich ja einen besseren Titel ausdenken :p

Jesus_666

15.08.2006, 14:40

Ich möchte nur kurz zur XHTML-Diskussion anmerken, daß - wie F² schon angemerkt hat - bis zur übernächsten IE-Version (frühestens) alle IE-User keinen richtigen XHTML-Support haben. XHTML wird, sofern es nicht mit dem MIME-Typ application/xhtml+xml ausgeliefert wird, über den HTML-Parser geparst (das schreibt das W3C so vor). IE bis einschließlich Version 7 unterstützt application/xhtml+xml nicht, was bedeutet, daß die Seiten als text/html ausgeliefert werden müssen, womit weder XHTML 1.1 noch XHTML 2.0 sinnvoll verwendet werden können (sie werden wie HTML 4.01 behandelt, haben aber im Gegensatz zu Version 1.0 eine zu HTML 4.01 inkompatible Syntax).

Wenn man schon XHTML benutzt sollte man XHTML 1.0 Strict benutzen und auf HTML-Kompatibilität achten. Oder man sperrt alle IE-User aus der Seite aus (oder man verwendet eine Browserschranke, was aber selten wirklich gut funktioniert).

Wenn ich noch mal eine öffentliche Seite mache werde ich wohl folgende Richtlinien befolgen:
- HTML 4.01 Strict mit CSS1 und Teilen von CSS2 verwenden (als Abwärtskompatibilität zu IE6/IE7); als Encoding UTF-8 verwenden
- Falls die Navigation auf Listen aufbaut diese ans Ende des Dokuments legen und dann per CSS nach oben positionieren; so müssen Textbrowser sich den Müll nicht immer ansehen
- Semantische Korrektheit da einsetzen, wo sie Sinn macht. Das Semantische Web ist tot und die meisten Textbrowser stellen Überschriften ohnehin nicht groß anders dar
- Kein AJAX verwenden, zumindest nicht für Funktionen irgendwelcher Relevanz. AJAX = JavaScript = in ernsthaften, auf Kompatibilität ausgelegten Seiten nur für Spielereien zu verwenden

mitaki

15.08.2006, 15:19

IE bis einschließlich Version 7 unterstützt application/xhtml+xml nicht, [...]
In der Hinsicht finde ich Chris Wilsons Statement (http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx) interessant, nachdem der MIME-Typ erst implementiert wird, wenn XHTML gut verarbeitet werden kann.
Meiner Meinung ein Fortschritt für die Software die sich Browser schimpft. Aber das kann man natürlich in alle Richtungen interpretieren.

rgb

16.08.2006, 16:29

Ich habe früher für meine Designs auch noch Tabellen benutzt, das Design meiner neusten Website erstelle ich mit <div>'s, auch wenn ich da teilweise arge probleme mit habe, meistens sind es irgendwelche Pixelränder, die bei Browser A auftauchen, bei Browser B aber nicht, und die alternative geht dann bei B wieder nicht.

Naja ist wohl eine Sache der Übung:)

Jesus_666

17.08.2006, 20:40

In der Hinsicht finde ich Chris Wilsons Statement (http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx) interessant, nachdem der MIME-Typ erst implementiert wird, wenn XHTML gut verarbeitet werden kann.
Meiner Meinung ein Fortschritt für die Software die sich Browser schimpft. Aber das kann man natürlich in alle Richtungen interpretieren.
Die Frage ist dann, warum der IE so großspurig mit seinem achsotollen CSS2-Support daherkommt... Jetzt mal ehrlich: In allen anderen Bereichen ist Microsoft "wird schon irgendwie funktionieren" auch genug.

Naja, ich betrachte XHTML ehrlich gesagt als relativ tot. Bis der IE XHTML2 unterstützt wird der Rest der Welt sich einen anderen, zu HTML kompatiblen Standard gesucht haben. Vielleicht bleiben wir auch einfach noch ein paar Jahre bei HTML 4.01 stehen.

Naja, lassen wir das. Webdesign ist keine exakte Wissenschaft und früher oder später wird sich schon der nächste permanente ad hoc-Standard finden.

mitaki

17.08.2006, 21:19

Wie gesagt, die Meinungen gehen hier sicher sehr weit auseinander.

Allerdings empfinde ich den IE7 als Tropfen auf den heißen Stein. Nun, ich bin weisgott kein MS Fan, aber IE7 behebt einige Fehler - nervige Fehler. Attributselektoren und der abbr-Tag sind endlich verfügbar.

Ich muss aber auch gestehen, dass ich XHTML2 nicht viel Zukunft zugestehe, wenn ich den momentanen Stand so sehe. Wenn der IE mit dem nächsten Schritt genug Marktanteile erhält werden wir vermutlich doch mit verkapptem XHTML weitermachen müssen.

Teelicht

20.08.2006, 23:52

Also ich benutze div's, vielleicht sogar zuviel... auf eine einwandfreie W3C Validierung komme ich trotzdem nicht immer, obwohl ich mir dafür redlich Mühe geben. Aber für Php brauch ich ab und zu einen name-Attribut, ich kenne bisher keine Alternative dazu... :(

Ansonsten bemühe ich mich bei meinen Seiten um den Grundsatz von NetBSD: "Of course it runs!" - ich lege also wert darauf, dass meine Seiten möglichst überall laufen, egal, ob Internet Explorer, FireFox, Opera, Netscape, Windows, Linux, 1024x768, 1600x1200. Einziger Haken ist, dass ich nicht alles testen kann, zur Zeit nur die "großen" Browser (IE, NN, Opera, Firefox) und bequem nur auf Windows mit 1024x768 und 800x600. Letztere Auflösung wird selten von mir unterstützt, da ich es kaum schaffe, 800x600 UND 1600x1200 zu unterstützen und der Trend ja Richtung größere Auflösungen geht. Mac OS X, Safari und OmniWeb kommen hoffentlich bald ins Testspektrum dazu.

Technisch versuche ich mich natürlich weitestgehend an den W3C Standart zu halten, damit es eben überall läuft, mit den üblichen id-Tricks für Internet Explorer... Man kennt ja die Probleme, die er hervorruft. Aber ich komme ganz gut klar...

Sagt mal, es behaupten immer alle, ein xHtml Dokument könne im Internet Explorer 7 nicht korrekt angezeigt werden, wenn es mit "application/xhtml+xml" geschickt wird - warum funktioniert es dann bei mir? Hab ich einen einmaligen Internet Explorer 7 oder mach ich etwas falsch? Folgender Code wird problemlos von Internet Explorer 7 angezeigt, IE 6 kann ich nicht testen, weil ich den erst mal wiederbekommen muss^^:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" />
<title>Hallo Welt mit xHtml 1.1</title>
</head>

<body>

Ein herzliches »Hallo Welt« mit xHtml 1.1!

</body>
</html>

mitaki

21.08.2006, 02:12

Hm, ich vermute du bist so einfrig und verwendest XHTML 1.1. Davon ist allgemein abzuraten, da der IE den dafür benötigten MIME Typ ja nicht kennt.
Das name Attribut ist in XHTML 1.0 noch in allen Varianten enthalten. Dokumente dieser Art dürfen auch als text/html ausgeliefert werden. -- Mehr dazu in meinem gepinnten Thread.

Zu deiner Frage:
Wenn ein Browser eine HTML Datei herunterläd sagt ihm meist der Server per HTTP Header, wie er die Datei verarbeiten muss.
Der Server liefert HTML Dateien mit dem MIME Typ text/html aus. Daraus folgt, dass der Browser den HTML Parser verwendet.
Was du meinst ist lediglich die meta Angabe, die ist zwar ebenfalls sehr wichtig, aber die Browser gehen nach dem HTTP-Header.

Versuch mal, folgenden PHP Befehl am anfang der Datei einzufügen:

<?php
header('content-type: application/xhtml+xml; charset=iso-8859-1');
?>
Nun wird der der Internet Explorer die Datei zum download anbieten, anstatt sie zu verarbeiten, denn der Server sendet die Datei als application/xhtml+xml aus.
Standardkonforme Browser schalten damit automatisch in den Full Standard Compilance Modus und verwenden einen XML Parser. Dadurch werden Fehler in der Syntax sofort erkannt und angezeigt.

David Hammond hat eine Tabelle erstellt (http://www.webdevout.net/doctype_switching.php), die dir genau anzeigt, wann welcher Browser welchen Modus anwendet und ob das Dokument als SGML oder XML Dokument geparst wird.

Jesus_666

21.08.2006, 04:12

Was du meinst ist lediglich die meta Angabe, die ist zwar ebenfalls sehr wichtig, aber die Browser gehen nach dem HTTP-Header.
Tatsächlich würde der <meta>-Tag so wie er da steht zu Problemen führen, weil einige Browser in einr HTML-Datei das Encoding nur dann aus dem Tag extrahieren können, wenn als MIME-Typ auch text/html angegeben ist. In deinem Fall würden einige Browser also das Encoding verwenden, das der Webserver im Header angibt - egal, was du in dem <meta> angegeben hast.

Teelicht

21.08.2006, 22:53

Nun wird der der Internet Explorer die Datei zum download anbieten, anstatt sie zu verarbeiten, denn der Server sendet die Datei als application/xhtml+xml aus.

Tatsächlich, Recht hast du^^ Danke für die Erklärung! Wobei ich mich dann ja langsam frage, warum ich den Typ überhaupt noch angeben muss... genauso wie das mit dem Schriftencoding - können diese dusseligen Browser das nicht einfach automatisch aus der Datei entnehmen? Naja, egal...

Auf jedenfall mag ich den Internet Explorer immer weniger... veraltete Techniken, langsam, das Design ist zwar gegenüber IE6.0 verbessert worden, aber immernoch um sehr deutlich verbesserungswürdig, die Favoritenverwaltung ist nach wie vor grottenschlecht und Opera bietet immernoch mehr Funktionen... *wuuuäääääähhhhh* ich werd ganz schnell wieder zum Opera wechseln *hilfe*

Das XHTML 1.0 das name-Attribut kennt, ist mir neu! Ich dachte immer, das sei nur in Transitional akzeptiert und in Strict rausgeschmissen! Na gut, dann ist das mit dem Standart ja kein Problem mehr, auf zum Validator! ^^

Aber um dann doch noch mal ne dumme Frage zu stellen:

A document sent with the text/html content type and an XHTML doctype will still be treated as an HTML document, but with some "custom" differences in elements and attributes
Da stellt sich doch für mich als Webdesigner die Frage, was für Vorteile XHTML jetzt zu diesem Zeitpunkt schon bietet!? Wenn es sowieso als HTML interpretiert wird.... Ich mag zwar XHTML mehr, aber das ist ja nun ein sehr vager Grund... Die Erweiterbarkeit von XHTML kann man - nehme ich mal stumpf an - im Moment sowieso vergessen, weil das bestimmt eh noch kaum ein Browser unterstützt, oder? Also: was ist der JETZTIGE Vorteil von XHTML gegenüber HTML? Das in Zukunft alles nur noch für XHTML spricht, ist mir klar, aber die Zeit ist lang und die Zukunft weit (um mal das russische Sprichwort etwas verunglückt zu modifizieren^^)

Blakkeight

21.08.2006, 23:03

Nabend,

ich bin grade dabei zu ueberlegen ob ich auf XHTML umsteige aber aus euren Beitraegen ist nicht ersichtlich ob es nun gut oder schlecht ist.

Was wuerdet ihr bei dem derzeitigen Stand der "Technik" empfehlen?

HTML x.xx oder XHTML x.xx?
CSS1, CSS2 oder auf CSS3 warten?

greetz jay

mitaki

22.08.2006, 00:25

Tatsächlich würde der <meta>-Tag so wie er da steht zu Problemen führen, weil einige Browser in einr HTML-Datei das Encoding nur dann aus dem Tag extrahieren können, wenn als MIME-Typ auch text/html angegeben ist. In deinem Fall würden einige Browser also das Encoding verwenden, das der Webserver im Header angibt - egal, was du in dem <meta> angegeben hast.
Ich bin mir gerade nicht sicher, ob ich richtig nachvollziehe, was du da gesagt hast, ich muss mal was ausprobieren.

Tatsächlich, Recht hast du^^ Danke für die Erklärung! Wobei ich mich dann ja langsam frage, warum ich den Typ überhaupt noch angeben muss... genauso wie das mit dem Schriftencoding - können diese dusseligen Browser das nicht einfach automatisch aus der Datei entnehmen? Naja, egal...
Äh, wie meinen?
Die meta Angabe ist normal dazu da, damit auf dem PC gespeicherte HTML Dateien richtig erkannt werden. Bei XHTML zählt aber die XML Deklaration, wobei standardmäßig UTF8 als Kodierung angenommen wird.
Am besten Header, Meta und Deklaration :)

Auf jedenfall mag ich den Internet Explorer immer weniger... veraltete Techniken, langsam, das Design ist zwar gegenüber IE6.0 verbessert worden, aber immernoch um sehr deutlich verbesserungswürdig, die Favoritenverwaltung ist nach wie vor grottenschlecht und Opera bietet immernoch mehr Funktionen... *wuuuäääääähhhhh* ich werd ganz schnell wieder zum Opera wechseln *hilfe*
Ich würde sagen, das Design ins ziemlich verwirrend^^

Das XHTML 1.0 das name-Attribut kennt, ist mir neu! Ich dachte immer, das sei nur in Transitional akzeptiert und in Strict rausgeschmissen! Na gut, dann ist das mit dem Standart ja kein Problem mehr, auf zum Validator! ^^
Nein, auch Strict kennt "name" und ab XHTML 2 (sprich ab 20xx) werden dann XForms verwendet.

Da stellt sich doch für mich als Webdesigner die Frage, was für Vorteile XHTML jetzt zu diesem Zeitpunkt schon bietet!? Wenn es sowieso als HTML interpretiert wird.... Ich mag zwar XHTML mehr, aber das ist ja nun ein sehr vager Grund... Die Erweiterbarkeit von XHTML kann man - nehme ich mal stumpf an - im Moment sowieso vergessen, weil das bestimmt eh noch kaum ein Browser unterstützt, oder? Also: was ist der JETZTIGE Vorteil von XHTML gegenüber HTML? Das in Zukunft alles nur noch für XHTML spricht, ist mir klar, aber die Zeit ist lang und die Zukunft weit (um mal das russische Sprichwort etwas verunglückt zu modifizieren^^)
XHTML hat für Autoren jetzt schon einen Vorteil: Man kann die Syntax wesentlich besser überprüfen als mit HTML.
HTML kennt z.B. <title/Hier der Titel/ als gültigen Tag, aber diese und zahlreiche weitere Möglichkeiten werden von den Browsern verschieden/fehlerhaft dargestellt.
XHTML dagegen muss "wohlgeformt" sein: <title> wird mit </title> beendet und auch richtig verschachtelt sein.
Das bedeutet: Mit XHTML kannst du besser auf Barierefreiheit dieser Art setzen.

Und jain, die XML Fähighkeit von XHTML ist erheblich eingeschränk aber das liegt hauptsächlich am Internet Explorer, der es bis heute nicht geschafft hat, XHTML richtig zu unterstützen. Firefox und Opera können damit richtig umgehen und gewinnen Marktanteile, womit dem IE Team Feuer unterm Hintern gemacht wird - hoffentlich...

Nabend,

ich bin grade dabei zu ueberlegen ob ich auf XHTML umsteige aber aus euren Beitraegen ist nicht ersichtlich ob es nun gut oder schlecht ist.

Was wuerdet ihr bei dem derzeitigen Stand der "Technik" empfehlen?

HTML x.xx oder XHTML x.xx?
CSS1, CSS2 oder auf CSS3 warten?

greetz jay
XHTML 1.0 in der Variante Strict. Gestaltung mit CSS 2.1. Du wirst zwar auf ein paar Grenzen stoßen, aber z.B. der CSS zen garden (http://www.csszengarden.com/) zeigt, das tolle CSS Designs auch im Internet Explorer 6 machbar sind :)
Überprüfen solltest du die XHTML Syntax aber nicht nur mit dem W3C Validator, sondern dem XML Schema Validator/Proxy von Christoph Schneegans, siehe in meinen Thread dazu :)

Teelicht

22.08.2006, 01:34

XHTML hat für Autoren jetzt schon einen Vorteil: Man kann die Syntax wesentlich besser überprüfen als mit HTML.

Mh, ja, bei der Fehlersuche hilft er... ansonsten ist der Vorteil nicht besonders groß, denn die Anzeige in Browsern (mind. den gängigsten) muss man ja doch immer überprüfen, einmal allgemein wegen dem Layout (zumal seltsamerweise 100px nicht immer gleich 100px sind, oder ist mein Auge so furchtbar?... bei Prozent ist es noch komplizierter) und zum anderen wegen unserem guten, alten Freund, dem Internet Explorer - ich fange an, richtig aktiv zu denken, dass die Welt ohne Internet Explorer einfacher wäre :rolleyes:

Und jain, die XML Fähighkeit von XHTML ist erheblich eingeschränk aber das liegt hauptsächlich am Internet Explorer, der es bis heute nicht geschafft hat, XHTML richtig zu unterstützen. Firefox und Opera können damit richtig umgehen und gewinnen Marktanteile, womit dem IE Team Feuer unterm Hintern gemacht wird - hoffentlich...

Tja, womit es mehr 'Ja' als 'Nein' währe, denn ich möchte ja niemanden vorschreiben, welchen Browser oder welche Auflösung er zu verwenden hat. ;) Allerdings kann ich dazu dann nur noch sagen: I love my Opera 9! (ich klau immer soviel.. aber der Threadtitel war gerade so passend^^)
Hoffen wir auf eine blühende Zukunft, in der sogar endlich der Internet Explorer ordentlich arbeitet..

mitaki

22.08.2006, 02:08

Mh, ja, bei der Fehlersuche hilft er... ansonsten ist der Vorteil nicht besonders groß
Dieser Vorteil ist nicht zu unterschätzen. Denk mal an Suchmaschienen, die sind sicher nicht darauf optimiert, jeden Tippfehler als solchen zu erkennen. Die haben wichtigere Aufgaben.

denn die Anzeige in Browsern (mind. den gängigsten) muss man ja doch immer überprüfen
Das hat aber nichts mit HTML zu tun. <h1> ist und bleibt eine Überschrift. Das ist in allen Browsern so. Und entsprechend sollen HTML Dokumente auch strukturiert werden.

Das Design das mit Stylesheets gemacht wird muss in den Browsern getestet werden. An sich reicht es, einen (standardkonformen) Browser deiner Wahl (die meisten unterscheiden sich nicht wesentlich) und einen Internet Explorer zu verwenden. Ja, du wirst im IE auf grenzen stoßen. css Garden zeigt dir, dass gutes Design dennoch möglich ist.

Tja, womit es mehr 'Ja' als 'Nein' währe, denn ich möchte ja niemanden vorschreiben,
Zur Verwendung von XHTML 1.0 Strict gibt es nur ein "Ja". HTML 4 oder eine Transistional Variante zu verwenden bringt uns nicht weiter.
Ja, IE parst XHTML noch mit einem HTML Parser. Aber das sollte uns nicht davon abhalten, "normales", oder einfach nur XHTML zu schreiben und mit Stylesheets zu designen. Denn im moment reicht er dazu trotz allen Einschränkungen. Und wenn man dem DevTeam glauben darf, wird es in Zukunft besser mit dem alten Explodierer.

Blakkeight

22.08.2006, 12:44

Jo danke werds mir mal anschauen. =)

Jesus_666

22.08.2006, 13:15

Zur Verwendung von XHTML 1.0 Strict gibt es nur ein "Ja". HTML 4 oder eine Transistional Variante zu verwenden bringt uns nicht weiter.
Ja, IE parst XHTML noch mit einem HTML Parser. Aber das sollte uns nicht davon abhalten, "normales", oder einfach nur XHTML zu schreiben und mit Stylesheets zu designen. Denn im moment reicht er dazu trotz allen Einschränkungen. Und wenn man dem DevTeam glauben darf, wird es in Zukunft besser mit dem alten Explodierer.
Wichtig ist, daß man sich an die HTML-Kompaitiblitätsrichtlinien hält. Bis Microsoft im IE 12 XHTML 1.0 unterstützt ist HTML-kompatibles XHTML 1.0 Strict (ggf. mit IE-spezifischen nonstandard-Hacks).

Teelicht

22.08.2006, 13:30

Das Design das mit Stylesheets gemacht wird muss in den Browsern getestet werden. An sich reicht es, einen (standardkonformen) Browser deiner Wahl (die meisten unterscheiden sich nicht wesentlich) und einen Internet Explorer zu verwenden.

Das meinte ich :). Mh, das mit dem Unterschied der standartkonformen Browser muss ich mal ausprobieren, denn die Anzeigeflächen sind unterschiedlich groß. Aber bei Verwendung von Prozentangaben, die ich bei neuen Seiten bevorzugt verwende, sollte dies eigentlich kein Problem mehr darstellen... Ich werd es mal probieren!

Da fällt mir gerade ein (endschuldigt, dass ich so viele Fragen stelle): Meine Designs basieren immer mehr auf Prozentangaben, bei Schriftgrößen Pixelangaben (natürlich xHtml+Css, das ist sowieso klar^^) - war da nicht irgendein Problem mit Windows vs. Macintosh? Bei Pixel weiß ich, dass es da Unterschiede gibt, meine aber mal gehört zu haben, dass die Pixelangabe für Schriftarten das beste verfügbare sei (oder war es doch em? Gute Frage), es geht mir um Größenangaben (Höhe und Breite) meiner div's, die die Bereiche meiner Homepage darstellen ( ein div für Navigation, eins für Inhalt etc.).

Ja, du wirst im IE auf grenzen stoßen. css Garden zeigt dir, dass gutes Design dennoch möglich ist.
Ja, Grenzen gibt es immer^^ selbst mit Css kann man ja nicht alles machen, da es nicht für alles geschaffen ist und ansonsten gibt es ja noch langsame/schlechte/standartferne Softwareentwickler von Microsoft. Aber damit kann ich leben, das ist nicht das Problem :) css Garden hab ich mir schon angeschaut, sieht sehr gut aus! (Ich wusste schon vorher, dass man mit Css schöne Dinge designen kann, deshalb ist das nicht mein Problem^^) Das Design hängt schließlich meist eher an den Grafiken, mit Css selbst macht man häufig eher das Layout, obwohl man sogar mit Css allein schöne Designs erstellen kann! :)

mitaki

22.08.2006, 14:12

Mh, das mit dem Unterschied der standartkonformen Browser muss ich mal ausprobieren, denn die Anzeigeflächen sind unterschiedlich groß.
Meinst du den Viewport, d.h. der Bereich, der die Webseite letztendlich anzeigt? Der unterscheidet sich (im maximierten Modus) in der Breite doch nur wenige Pixel. Etwas mehr in der Höhe, aber daran sollte kein Design scheitern.

Meine Designs basieren immer mehr auf Prozentangaben
Der CSS Validator könnte dir ankreide, dass dein Stylesheet an Konsistenz verliert, wenn du zu viele Prozentangaben verwendest. Ich selbst arbeite so gut wie nie mit Prozentangaben.

bei Schriftgrößen Pixelangaben (natürlich xHtml+Css, das ist sowieso klar^^) - war da nicht irgendein Problem mit Windows vs. Macintosh?
Der Unterschied betrifft das Maß Punkt (pt). Die werden intern anders umgerechnet.

meine aber mal gehört zu haben, dass die Pixelangabe für Schriftarten das beste verfügbare sei (oder war es doch em? Gute Frage)
Meiner Meinung nach em, aber über das richige Maß wird man sich wohlnoch lange streiten. Letztendlich wird es wohl immer Benutzer geben, die mit dem Design des Erstellers nicht zufrieden sind, aber man ist schon in der Lage das gröbste zu vermeiden.

Ein Beispiel wie ich em verwende:
Ich habe eine Liste als menü, die Listenpunkte sind 11em breit, das reicht, um alle Listenpunkte mit Text zu füllen (Schriftgröße 1em). Dadurch kommt es bei sehr starker vergrößerung oder verkleinerung kaum zu Problemen, z.B. das Text abgeschnitten wird oder herausspringt.

es geht mir um Größenangaben (Höhe und Breite) meiner div's, die die Bereiche meiner Homepage darstellen ( ein div für Navigation, eins für Inhalt etc.).
Am besten einfach Testen, was passiert, wenn man die Webseite zoomt. Hier kommt wieder zum Tragen, dass IE, Fx und Opera auf verschiedene Weisen zoomen.

Jesus_666

22.08.2006, 20:09

Das meinte ich :). Mh, das mit dem Unterschied der standartkonformen Browser muss ich mal ausprobieren, denn die Anzeigeflächen sind unterschiedlich groß. Aber bei Verwendung von Prozentangaben, die ich bei neuen Seiten bevorzugt verwende, sollte dies eigentlich kein Problem mehr darstellen... Ich werd es mal probieren!Naja... Es gibt einige browserspezifische Eigenarten wie Geckos Probleme mit pixelgenauer Platzierung; außerdem gibt es bei den etwas obskureren CSS-Befehlen Kompatibilitätsunterschiede.

Da fällt mir gerade ein (endschuldigt, dass ich so viele Fragen stelle): Meine Designs basieren immer mehr auf Prozentangaben, bei Schriftgrößen Pixelangaben (natürlich xHtml+Css, das ist sowieso klar^^) - war da nicht irgendein Problem mit Windows vs. Macintosh? Bei Pixel weiß ich, dass es da Unterschiede gibt, meine aber mal gehört zu haben, dass die Pixelangabe für Schriftarten das beste verfügbare sei (oder war es doch em? Gute Frage), es geht mir um Größenangaben (Höhe und Breite) meiner div's, die die Bereiche meiner Homepage darstellen ( ein div für Navigation, eins für Inhalt etc.).Vermeide px. Eine 12 Pixel hohe Schrift mag mit 1024x768 gut aussehen, mit 1800x1350 tut es das nicht mehr. Außerdem sind Seiten, die sich nicht an die Uservorgaben zur Basisschriftart halten, nicht gerade ergonomisch. Slashdot benimmt sich seit dem letzten Redesign auch so und ist mit hohen Auflösungen definitiv augenunfreundlich.
Bei Schriftarten kannst du % oder em verwenden, aber bitte nicht px. Mit px stellst du sicher, daß deine Seite auf irgendeiner Auflösung schlecht aussieht.

Jesus_666

23.08.2006, 22:08

Ich habe schon oft gehört dass em bevorzugt werden sollen, aber ich stimme dem absolut nicht zu. Bei gewerblichen Seiten die einen großen Funktionsumfang haben, hat man mit em nur Probleme. Hat zu Beispiel der Elterntag eines Tags eine Schriftgröße in em, ist sie nicht relativ zur im Browser eingestellten Schriftgröße sondern zur Schriftgröße die im Elterntag definiert ist. Wird diese Schriftart nun irgendwo außerhalb des Elterntags verwendet, hat sie eine Unterschiedliche Größe. Das ist schon ärgerlich wenn man z.B. eine Standardtext-Klasse auf einmal innerhalb einer Klasse verwenden muss, wo eine kleinere Schrift benötigt wird.

Px ist nicht das beste - keine Frage, aber auf Bildschirmen kann sich jeder was darunter vorstellen. Die beste Lösung ist meines Erachtens nach, eine Möglichkeit anzubieten, die Schriftgröße der Seite (z.B. durch Laden eines alternativen Stylesheets) anzupassen, dabei aber weiterhin px als Größe anzugeben. Hätte nebenbei noch den Vorteil dass das Layout nicht zerstört wird (wie es bei den Vergrößerungsmöglichkeiten des Browsers der Fall ist)
Hmm, weißt du, wie es mit % aussieht? Wie gesagt, ich halte Angaben in px für Designprobleme (zumindest, wenn der Wert unter 11 liegt), weil sie eben dazu neigen, nicht zu skalieren.

Alternative Stylesheets haben das Problem, daß man eine Browserweiche oder eine Splashseite verwenden muß. Letzteres nervt und ersteres funktioniert oft nicht richtig... Und irgendwie ist es doch etwas merkwürdig, daß man sich auf Techniken verlassen muß, die eigentlich seit 2000 tot sein sollten. Gut, man kann auch den Leuten sagen, daß sie von Hand umschalten sollen, das ist aber auch nicht gerade benutzerfreundlich.

24.08.2006, 13:40

das umstellen des stlyesheets geht auch mit einem lustigen php auswahlmenü. das kann man dann noch in nen cookie oder so schreiben, (also die einstellung) und der benutzer freut sich beim erneuten betreten der seite, das seine einstellugnen noch gültig sind^^

Teelicht

24.08.2006, 15:18

Mit Pixeln als Schriftgröße habt ihr wohl recht, hab ich bei meinem aktuellen Auftrag im Test auf hohen Auflösungen gerade gesehen^^

Allerdings hab ich das noch nicht ganz mit den Alternativen verstanden. 'em' ist mir sowieso noch ein Rätsel, ich habe mal probiert, das Seitendesign komplett auf em umzustellen und war nicht sehr zufrieden. Einerseits musste man für die selbe Länge auf dem Bildschirm öfters unterschiedliche em-Werte eingeben und andererseits weiß ich nicht, wie ich ein div an Position xem|yem beginnen lassen kann und dann den Rest des Bildschirms bis unten ausfüllen lassen kann (ihr versteht, was ich meine?). Bei Angaben wie 100% ist em total aufgeschmissen, aber das wäre ja nicht schlimm, das Problem eben ist das richtige Problem mit em.

Also dachte ich mir: Hey, Prozentangaben für die Schriftgröße! Klingt zwar irgendwie verrückt, aber cool! Gut, gesagt, getan. Das Ergebnis lässt sich allerdings nicht sehen! Die Prozentangaben beziehen sich bei der Schriftgröße offenbar nicht auf den Anzeigebereich (oder von mir aus Viewport) des Browsers, sondern auf die Basisschriftgröße. o.O Wie soll ich denn dann bitte relativen Schriftgrößen angeben?? Wenn ich 100% angebe, ist das die normale Schriftgröße im Browser, bei 150% lässt es sich auch auf irgendsoner höheren Auflösung auch gut sehen (aber ist für 1024x768 zu groß) und bei 200% ist es bei 1600x1200 gut lesbar, aber bei 1024x768 viel zu groß!

Mh, bisherige Lösung ist leider immernoch die Schriftgrößenwahl des Benutzers, aber eigentlich lehne ich sowas ab, denn einen Computer sollte man doch dazu bringen können, abhängig von der Bildschirmgröße die Schriftgröße zu wählen* - nur wie???

*damit meine ich kein JavaScript!

[EDIT] Scheiße, ich glaube, mir ist gerade der Fehler in meinem Gedankengang aufgefallen: Ich habe 2 Bildschirme, meinen 15" TFT des Notebooks und eine alte 17" CRT Röhre... Bei wieviel Zoll benutzt man eigentlich Auflösungen wie 1600x1200? Gibt es da Unterschiede zwischen der Darstellung von 100% Schriftgröße zwischen 15", 17", 20" usw.? Wirkt so eine Schrift auf großen Bildschirmen irgendwie größer?? Denn auf meinem CRT Bildschirm kann man bei 1600x1200 von den Menüs etc. kaum etwas ohne Anstregung lesen, ist das auf größeren Bildschirmen anders? Gut, die Frage klingt doof, aber ich weiß es eben nicht, ich hab noch nie einen großen Bildschirm vor mir gehabt...

mitaki

24.08.2006, 17:14

em hat schon was an sich^^

Em bedeutet die Breite des Buchstabens M. Wenn ich meine Standardinstallation vom Firefox betrachte ist ein em 16 Pixel breit (und hoch) ausgehend von <html> bzw. <body>.

Wenn man das weis kann man schon ganz gut nach vorne rechnen. So ist es auch erklärbar, wie 10em verschiedene Pixelgrößen haben können.
Von daher hat der Surface Dweller schon recht, für tief verschachtelte Projekte ist em nicht allzugut geeignet. Allerdings sollte man auch gar nicht so tief verschachteln^^

Mh, bisherige Lösung ist leider immernoch die Schriftgrößenwahl des Benutzers, aber eigentlich lehne ich sowas ab, denn einen Computer sollte man doch dazu bringen können, abhängig von der Bildschirmgröße die Schriftgröße zu wählen* - nur wie???
Naja, manche Browser wie z.B. der Firefox erlauben es einem, die Standardschriftgröße zu verändern - und damit em.

Jesus_666 ist da besser informiert. Aber ich denke % Angaben bei der Schrift beziehen sich ebenfalls auf die Standardschriftgröße des Browsers.

Jesus_666

24.08.2006, 19:32

Naja, manche Browser wie z.B. der Firefox erlauben es einem, die Standardschriftgröße zu verändern - und damit em.
Exakt. Interessanterweise verwende ich sowohl auf dem iBook (1024x768) als auch unter Linux (~1800x1350) eine Basisgröße von 16, was an sich recht gut lesbar ist. Und beide Füchse arbeiten mit 96 DPI (auch wenn ich unter Linux eigentlich über 120 DPI habe; mit 96 sehen die Menüs aber besser aus).

Jesus_666 ist da besser informiert. Aber ich denke % Angaben bei der Schrift beziehen sich ebenfalls auf die Standardschriftgröße des Browsers.
Ich bin mir nicht sicher, aber ich glaube, man konnte auch irgendwie über <meta> die Basisschrift für das Dokument angeben. Bin mir aber echt nicht sicher.

dead_orc

24.08.2006, 21:26

Was ich interessant finde ist, dass hier gar nicht pt zur Sprache gekommen ist. Ist das absolut falsch oder wie ist das damit? Ich bin leider kein Mensch mit so viel Geld und habe deshalb keinen Monitor auf dem ich eine Auflösung von >1024x768 anzeigen kann und daher weiß ich nicht, wie Schriftarten bei hohen Auflösungen aussehen ^^

mitaki

25.08.2006, 23:00

Aber für Php brauch ich ab und zu einen name-Attribut, ich kenne bisher keine Alternative dazu...
Wenn du damit <input /> Felder meinst: Diese dürfen das name-Attribut laut W3C Validator nochenthalten - wie mir gerade aufgefallen ist.

Was ich interessant finde ist, dass hier gar nicht pt zur Sprache gekommen ist. Ist das absolut falsch oder wie ist das damit? Ich bin leider kein Mensch mit so viel Geld und habe deshalb keinen Monitor auf dem ich eine Auflösung von >1024x768 anzeigen kann und daher weiß ich nicht, wie Schriftarten bei hohen Auflösungen aussehen ^^
Jain, mit Punkt und Pixel hast du nicht nur das genannte Win/Mac Problem (http://aktuell.de.selfhtml.org/artikel/css/fontsize/index.htm), sondern - wenn ich mich richtig erinnere - müssten standardkonforme Browser das zoomen dieser Angaben nicht erlauben.

Teelicht

25.08.2006, 23:27

Wenn du damit <input /> Felder meinst: Diese dürfen das name-Attribut laut W3C Validator nochenthalten - wie mir gerade aufgefallen ist.
Meinte ich :) danke für den Tipp, das ist mir nämlich neu.

Jain, mit Punkt und Pixel hast du nicht nur das genannte Win/Mac Problem (http://aktuell.de.selfhtml.org/artikel/css/fontsize/index.htm), sondern - wenn ich mich richtig erinnere - müssten standardkonforme Browser das zoomen dieser Angaben nicht erlauben.
Also meines Wissens sind Punkte keine relative Größe, dass sollte bei hohen Auflösungen schon was ausmachen...

Jesus_666: Nur mal aus Neugierde: Wieviel Zoll hat dein "Linux-Bildschirm"? Denn das ist ja immer noch das, worüber ich mir nicht ganz im Klaren bin: Eigentlich müsste aber 1em mit Basisschriftgröße 16 unabhängig von der Zoll-Größe des Bildschirms überall gleich aussehen oder? Oder sind Pixel bei großen Bildschirmen irgendwie größer? :confused: Die Frage klingt etwas dumm, aber ich kann nicht verstehen, dass ich bei 17" und 1600x1200 mein 1em nur schwer lesen kann. Vielleicht liegt es ja doch nur an der Gewohnheit oder an meinen doofen 60Hz bei 1600x1200? Außerdem stört es mich beim Layout schon, dass der Text bei 1024x768 schön ca. 1/3 des Bildschirms füllt, während er bei 1600x1200 (und 1em) nur so ein paar Pixel füllt :(

Wenn du mir den Gefallen tun würdest, können wir ja mal einen kleinen Test machen: Du gehst auf die Seite http:/schattentier.st.ohost.de/Firehorns/?basetype=em (noch nicht fertig, aber is ja erst mal egal) und machst mir mit deinem Linuxbildschirm mal einen Screenshot... Hab jetzt halt nur die Schriftgröße auf em umgestellt, alles andere läuft noch auf Nummer Sicher mit Pixeln. Anmerkung: Wenn ihr unten Rechts die Schriftgröße verändert, müsst ihr nochmal ein &basetype=em an die URL hängen, um es als em-Werte zu testen..

ok, Basisschriftgröße kann man verändern, das müsste ja dann heißen, dass alle 1600x1200-und-höher-Nutzer entweder die Schriftgröße verändern oder freiwillig so klein lassen und gar nicht größer haben wollen? Ist das richtig?

Jesus_666

26.08.2006, 00:07

Der Test muß warten, bis mein neues Mainboard angekommen und eingerichtet und dann die Festplatte von den Schäden, die der Versuch, NForce4 und Linux zu mischen, dort hinterlassen hat, befreit werden. Das dürfte bis Dienstag oder Mittwoch dauern, wenn alles glatt geht.

Der Bildschirm ist ein 21"er CRT, den ich mit knapp 1800x1350 fahre. An sich müßte ich den Text mit >120 DPI anzeigen lassen, aber der Fx wendet das dann auch auf die Menüs an, wo der Text dann blöde groß wird, weshalb der Fx auf 96 DPI eingestellt ist.

mitaki

27.08.2006, 00:26

Also meines Wissens sind Punkte keine relative Größe, dass sollte bei hohen Auflösungen schon was ausmachen...
Jain, 1 Punkt sollte 1/72 eines Inches, d.h. Zoll entsprechen. Wenn ich keinen Zahlendrehen habe also 2,54/72 entspricht 0,352777 mm.

Eigentlich müsste aber 1em mit Basisschriftgröße 16 unabhängig von der Zoll-Größe des Bildschirms überall gleich aussehen oder?
Nein. Was dir eventuell nicht klar ist: Eine Auflösung z.B. 1024x748 gibt das Pixelverhältnis an, d.h. 1024 Pixel ist der Anzeigebereich breit und 748 Pixel ist er hoch.
Entsprechend ist ein Pixel bei einer höhereren Auflösung aber gleich großem Monitor kleiner.

Damit ist der Sinn von em leicht zu erkennen. Stellt man seine Standardgröße im Browser höher, weil die Bildschirmgröße es erfordert, so vergrößert sich auch em.

Du gehst auf die Seite http:/schattentier.st.ohost.de/Firehorns/?basetype=em
Ich kann zwar nicht testen, allerdings empfehle ich dir, die Stilangaben in einer externen Datei zu speichern.

Antares

27.08.2006, 02:17

Nunja, zum Thema fällt mir gerade ein, dass ich doch sehr oft in letzter Zeit mit Position: Absolute arbeite, wenn ich es wirklich nicht hinbekomme eine grafik ordentlich zu positionieren, wobei ich hier von einigen IE Fehlern spreche, die manchen bekannt sein dürften.
Da passiert es mir manchmal, dass sich das entsprechende Bild nicht genau am Rand befindet, obwohl ich doch float: left; und padding-left: 0px; benutze,.
Und gerade bei solchen Fehler greife ich öfter zum Position: Absolute Attribut.

Wobei ich nicht sagen kann, ob das denn eine gute Technik ist oder nur eine sture Ausweichalternative..
Wie geht es euch dabei?

Hm un wo wir schon bei Thema sind, nutze ich den Thread gerade mal für eine Frage:
Wie schaffe ich es, dass sich ein Objekt (Bild) direkt unten am Rand befindet?
Mit "Position: absolute; bottom: 0px;" funktioniert es leider nicht, da sich das Bild dann lediglich am unteren Bildschirmrand befindet.
Wenn man die Seite allerdings scrollen kann....

Manni

27.08.2006, 08:58

Du packst ein <div> deinen Body und dahinter den Footer (noch ein <div>)

<div id="content">Body</div>
<div id="footer">Footer</div>
Das formattierst du dann mit CSS:

#content {
height: 100%;
padding-bottom: 100px;
}

#footer{
height: 100px;
margin-top: 100px;
border: 1px solid green;
background: red;
}
Der Code ist nicht getestet, aber so funktioniert das im Prinzip.
Hier (http://www.themaninblue.com/experiment/footerStickAlt/) gibt es auch noch Beispiele dafür ;)

Antares

27.08.2006, 12:45

Danke Manni, aber so klappt es direkt für einen Footer.
Mir reicht es aber schon, dass es nur für ein Bild klappt, naja und mit dieser Technik bekomme ich es nicht hin.
Gibt es nicht noch eine andere Möglichkeit ein Bild an den unteren Rand der Seite zu bringen?
Am besten natürlich mit Position: Absolute.

mitaki

27.08.2006, 14:47

Da passiert es mir manchmal, dass sich das entsprechende Bild nicht genau am Rand befindet, obwohl ich doch float: left; und padding-left: 0px; benutze,.
Hm, du hast vermutlich einen margin-left Wert bestimmt, wodurch alles nur bis zu diesem Außenabstand positioniert wird.
Wenn due die padding/margin Werte selbst bestimmt hast, müsste die Angabe von left: -Xpx; funktionieren.

Hm un wo wir schon bei Thema sind, nutze ich den Thread gerade mal für eine Frage:
Wie schaffe ich es, dass sich ein Objekt (Bild) direkt unten am Rand befindet?
Mit "Position: absolute; bottom: 0px;" funktioniert es leider nicht, da sich das Bild dann lediglich am unteren Bildschirmrand befindet.
Wenn man die Seite allerdings scrollen kann....
Welchen Rand meinst du nun? x.x
Unterer Rand des Elements? Dann versuche background-position (http://de.selfhtml.org/css/eigenschaften/hintergrund.htm#background_position).
Unterer Rand der Seite: Dann einfach als Letztes Element aufführen.
Wenn du es aber immer am Unteren Rand des Anzeigebereiches angezeigt haben möchtest, ist vermutlich position: fixed; hilfreich, damit kann der IE6 aber nur mit Hacks umgehen, soweit ich weis.