Druckbare Version
Da wir gerade im IRC ne kleine Diskussion zu dem Thema hatten, möchte ich euch einfach mal fragen, was ihr für besser haltet und selbst praktiziert: Gestaltet ihr eure Webseiten so semantisch korrekt wie möglich (<hx> für Überschriften, Texte schön in <p></p> und alles was einer Aufzählung ähnelt [z.B. eine Navigation ;)] als echte Auflistung) oder macht ihr es euch einfach und benutzt für alles <div> und <span> und gestaltet eure Designs hauptsächlich mit Tabellen?
span hab ich noch nie genutz, find ich sinnlos....
Benutze div, p, überschriften, und eigentlich alles so korrekt wie möglich^^
ich versuche es zumindest.
tabellen sucken.
ne, navi mach ich ned als listen, sondern einfach als untereinanderstehende links die alle display:block gedingst werden.
Ich bekenne mich als Tabellen-Benutzer. Ich versuche allerdings <div>s bzw eben die korrekten Tags wie <hx> und Listen da zu benutzen, wo sie auch hingehören und ein bisschen von den Tabellen wegzukommen ;)
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.
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
Das habe ich mir nicht ausgedacht. Entsprechende Fälle sind keine Seltenheit. Freenet bringt es auf 445 <div>s...HTML-Code:<div class="ueberschrift"><span class="kategorie1">Hallo</span> <span class="separator">>></span> <span class="kategorie2">Welt</span> <span class="satzzeichen">!</span>
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.
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.
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
Ich weiß, aber das wäre dann unnötig, da kann man dann gleich <div> Elemente nehmen. ;)Zitat:
Zitat von drunken monkey
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.Zitat:
Zitat von dennis_meckel
Warum soll das besser sein als eine Liste? Listen sind entsprechend formatierbar und im Textbrowser auch als soclche erkennbar.Zitat:
ne, navi mach ich ned als listen, sondern einfach als untereinanderstehende links die alle display:block gedingst werden.
Vermutlich ist gegen eine einzge Tabelle nichts auszusetzen, mein altes Projekt basierte beispielsweise auch auf einer Tabelle und war mit Lynx sehr gut darstellbar.Zitat:
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.
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.
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.Zitat:
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.
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.
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.
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. ;)Zitat:
Zitat von Manni
Es ist bequemer, imo.Zitat:
Warum soll das besser sein als eine Liste? Listen sind entsprechend formatierbar und im Textbrowser auch als soclche erkennbar.
Ich brauche keine Umbrüche, spare Aufwand bei der Formatierung etc.
es ist schon ein unterschied, ob ich
oderHTML-Code:<div class='navi'>
link
link
link
link
</div>
schreiben mussHTML-Code:<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>
edit:
code auf nem roten hintergrund ist scheiße >_> man sollte die standartfarbe ändern...
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 :(Zitat:
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.
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.
Ja, diverse Freeware ist wirklich nicht sehr gut und ist von daher vermutlich auch nicht, mit speziell dafür ausgelegten Programmen vergleichbar.Zitat:
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.
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.
Es ist bequemer, imo.Zitat:
Warum soll das besser sein als eine Liste? Listen sind entsprechend formatierbar und im Textbrowser auch als soclche erkennbar.
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^^
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 />.
Der neuen Führung bereits gemeldet.Zitat:
code auf nem roten hintergrund ist scheiße >_> man sollte die standartfarbe ändern...
Ich frag mich, warum CSS und Tabellen immer als gegensätzlich gesehen werden. Ich kann meine Tabelle doch auch mit CSS formatieren...Zitat:
Zitat von mitaki
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.Zitat:
Ich frag mich, warum CSS und Tabellen immer als gegensätzlich gesehen werden. Ich kann meine Tabelle doch auch mit CSS formatieren...
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?Zitat:
Zitat von mitaki
Weil man außerhalb der Tabelle denken muss :pZitat:
Zitat von Manni
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.
mit entsprechenden stylesheets kann man beides gleich formatieren*.Zitat:
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 />.
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.
Ein weiterer Grund für Divs, sie sind einfacher ;) *erinnere mich, wie ich mich mit solchen problemen abgearbeitet hab*Zitat:
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
* 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)
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.Zitat:
GENAUSO (also von der letzendlichen anzeige) könnte ich sie auch mit listen Formatieren, allerdings hätt ich da imo mehr codeaufwand.
Ich suche mal nach Belegen dafür.
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^^Zitat:
* 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
Aber HTML ist halt eie Auszeichnungssprache die mit semantik im Kopf entwickelt wurde.
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.Zitat:
Zitat von Freierfall
Ja, href und src für alle Elemente.Zitat:
das mit dem href bei li etc ist geil, das brauch ich aber auch bei anderen elementen^^
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.
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
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
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 :pZitat:
Zitat von dennis_meckel
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
In der Hinsicht finde ich Chris Wilsons Statement interessant, nachdem der MIME-Typ erst implementiert wird, wenn XHTML gut verarbeitet werden kann.Zitat:
IE bis einschließlich Version 7 unterstützt application/xhtml+xml nicht, [...]
Meiner Meinung ein Fortschritt für die Software die sich Browser schimpft. Aber das kann man natürlich in alle Richtungen interpretieren.
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:)
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.Zitat:
Zitat von mitaki
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.
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.
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^^:
HTML-Code:<!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>
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:
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.PHP-Code:<?php
header('content-type: application/xhtml+xml; charset=iso-8859-1');
?>
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, die dir genau anzeigt, wann welcher Browser welchen Modus anwendet und ob das Dokument als SGML oder XML Dokument geparst wird.
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.Zitat:
Zitat von mitaki
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...Zitat:
Zitat von mitaki
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:
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^^)Zitat:
Zitat von http://www.webdevout.net/doctype_switching.php
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
Ich bin mir gerade nicht sicher, ob ich richtig nachvollziehe, was du da gesagt hast, ich muss mal was ausprobieren.Zitat:
Zitat von Jesus_666
Äh, wie meinen?Zitat:
Zitat von .Mi
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 :)
Ich würde sagen, das Design ins ziemlich verwirrend^^Zitat:
Zitat von .Mi
Nein, auch Strict kennt "name" und ab XHTML 2 (sprich ab 20xx) werden dann XForms verwendet.Zitat:
Zitat von .Mi
XHTML hat für Autoren jetzt schon einen Vorteil: Man kann die Syntax wesentlich besser überprüfen als mit HTML.Zitat:
Zitat von .Mi
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...
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 zeigt, das tolle CSS Designs auch im Internet Explorer 6 machbar sind :)Zitat:
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
Ü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 :)
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:Zitat:
Zitat von mitaki
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^^)Zitat:
Zitat von mitaki
[Utopie] Hoffen wir auf eine blühende Zukunft, in der sogar endlich der Internet Explorer ordentlich arbeitet.. [/Utopie]
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.Zitat:
Zitat von .Mi
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.Zitat:
Zitat von .Mi
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.
Zur Verwendung von XHTML 1.0 Strict gibt es nur ein "Ja". HTML 4 oder eine Transistional Variante zu verwenden bringt uns nicht weiter.Zitat:
Tja, womit es mehr 'Ja' als 'Nein' währe, denn ich möchte ja niemanden vorschreiben,
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.
Jo danke werds mir mal anschauen. =)
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).Zitat:
Zitat von mitaki
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!Zitat:
Zitat von mitaki
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, 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! :)Zitat:
Zitat von mitaki
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.Zitat:
Zitat von .Mi
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.Zitat:
Zitat von .Mi
Der Unterschied betrifft das Maß Punkt (pt). Die werden intern anders umgerechnet.Zitat:
Zitat von .Mi
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.Zitat:
Zitat von .Mi
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.
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.Zitat:
Zitat von .Mi
Naja... Es gibt einige browserspezifische Eigenarten wie Geckos Probleme mit pixelgenauer Platzierung; außerdem gibt es bei den etwas obskureren CSS-Befehlen Kompatibilitätsunterschiede.Zitat:
Zitat von .Mi
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.Zitat:
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.).
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.
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.Zitat:
Zitat von Surface Dweller
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.
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^^
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...
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^^
Naja, manche Browser wie z.B. der Firefox erlauben es einem, die Standardschriftgröße zu verändern - und damit em.Zitat:
Zitat von .Mi
Jesus_666 ist da besser informiert. Aber ich denke % Angaben bei der Schrift beziehen sich ebenfalls auf die Standardschriftgröße des Browsers.
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).Zitat:
Zitat von mitaki
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.Zitat:
Jesus_666 ist da besser informiert. Aber ich denke % Angaben bei der Schrift beziehen sich ebenfalls auf die Standardschriftgröße des Browsers.
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 ^^
Wenn du damit <input /> Felder meinst: Diese dürfen das name-Attribut laut W3C Validator nochenthalten - wie mir gerade aufgefallen ist.Zitat:
Zitat von .Mi
Jain, mit Punkt und Pixel hast du nicht nur das genannte Win/Mac Problem, sondern - wenn ich mich richtig erinnere - müssten standardkonforme Browser das zoomen dieser Angaben nicht erlauben.Zitat:
Zitat von dead_orc
Meinte ich :) danke für den Tipp, das ist mir nämlich neu.Zitat:
Zitat von mitaki
Also meines Wissens sind Punkte keine relative Größe, dass sollte bei hohen Auflösungen schon was ausmachen...Zitat:
Zitat von mitaki
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?
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.
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.Zitat:
Also meines Wissens sind Punkte keine relative Größe, dass sollte bei hohen Auflösungen schon was ausmachen...
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.Zitat:
Eigentlich müsste aber 1em mit Basisschriftgröße 16 unabhängig von der Zoll-Größe des Bildschirms überall gleich aussehen oder?
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.
Ich kann zwar nicht testen, allerdings empfehle ich dir, die Stilangaben in einer externen Datei zu speichern.Zitat:
Du gehst auf die Seite http:/schattentier.st.ohost.de/Firehorns/?basetype=em
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....
Du packst ein <div> deinen Body und dahinter den Footer (noch ein <div>)
Das formattierst du dann mit CSS:HTML-Code:<div id="content">Body</div>
<div id="footer">Footer</div>
Der Code ist nicht getestet, aber so funktioniert das im Prinzip.Code:#content {
height: 100%;
padding-bottom: 100px;
}
#footer{
height: 100px;
margin-top: 100px;
border: 1px solid green;
background: red;
}
Hier gibt es auch noch Beispiele dafür ;)
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.
Hm, du hast vermutlich einen margin-left Wert bestimmt, wodurch alles nur bis zu diesem Außenabstand positioniert wird.Zitat:
Zitat von Antares
Wenn due die padding/margin Werte selbst bestimmt hast, müsste die Angabe von left: -Xpx; funktionieren.
Welchen Rand meinst du nun? x.xZitat:
Zitat von Antares
Unterer Rand des Elements? Dann versuche 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.
Naja, ich glaube kaum dass es funktioniert, da das Bild quasi als oberster Layer angezeigt werden soll und nicht im HintergrundZitat:
Zitat von mitaki
Nein, so funktioniert das auch nicht, da ich bereits einen Footer mit festen Pixelangaben generiert habe und ich das Bild einfach nur nach links unten bringen will, also quasi über den Rest.Zitat:
Zitat von mitaki
Was ist mit den anderen Alternativen?
Willst du, dass das Bild nun am unteren Rand klebt und sich dahinter alles bewegt, etwa wie man es auf der Erweiterungsseite der Geckos sieht?
Zeige vielleicht mal eine Beispielseite x.x
Nagut, ich habe mal 2 Screenshots gemacht, um das Problem zu verdeutlichen.
Klick
Man sieht den Footerbereich der Webseite.
So, der Footer hat eine feste Höhe von 70px.
Und nun will ich dieses Bild einfach nur nach unten links in die Ecke setzen, da es höher als 70px ist und somit den Footer zerstören würde.
Pack es doch einfach auch noch hinter den Footer und bring es mit entsprechend negativem margin nach oben. Und du kannst auch noch position: absolute; right: 0px; benutzen um es an den rechten Rand zu bekommen ;)
EDIT:
Hm, ich frag mich gerade, wie ich wohl auf rechts gekommen bin :D
Na, dann versuche doch mal das Bild in den Footer zu tun und ihm die Eigenschaft margin-top: -30px; zu geben. Wenn nötig kann man die margins auch noch links anpassen und das ganze notfalls noch floaten lassen.
@Manni: Das Bild soll aber links hin ^^
Also ich bin wirklich beeindruckt.
Negativer Margin, davon hab ich zwar schon gehört, aber der Effekt war mir unbewusst.
Vielen Dank euch beiden, es klappt !
*Edit*
Kann es sein, dass der IE diese Funktion nicht unterstützt?
Denn dort ist das Bild bei einer Höhe von 70px abgeschnitten.
Hat eventuell mit einem Bug des IE zu tun.Zitat:
Zitat von Antares
Versuch mal, dem Bild noch die Eigenschaft position: relative; zu geben.
Hat sich bereits erledigt. Mit "position: absolute; left: 0px;" hats funktioniert.
Trotzdem Danke für die Hilfe.
Nur als Hinweis noch: Bei der Angabe von 0 ist keine Maßangabe notwendig. 0px = 0em = 0ex = 0pt = 0pc = 0in = 0cm = 0mm = 0%.^^
*hihi* mir fällt mal wieder eine Frage zum Thema ein, 'schuldigung ^^
Darauf gebracht hat mich mitaki, der in dem "pupsigen div-frage" thread nebenbei erwähnt hat, dass der Doctype den Browser in standartkonformen Modus bringt. Das wäre ja endlich mal ein ganz praktischer Nutzen des Doctypes, denn bisher schreibe ich ihn im Prinzip nur dahin, weil W3C das so will. Könnt ihr mir da noch mal näher erklären, was das mal von der ganz pratischen Seite aus Sicht des Webdesigners etwas bringt? Ich will gegenüber anderen nicht immer nur argumentieren können, dass es sich eben so gehört, das ist ein wahnsinnig schlechtes Argument...
Gruß, Micha
Noch einmal zum sinnvollen Nutzen: David Hammonds Doctype switching Tabelle.
Im standardkonformen Modus verwendet der IE z.B. das richtige Box-Modell, ab IE7 sind darin auch die Bugfixes und Erweiterungen enthalten.
Der Doctype selbst gibt eben an, nach welcher DTD (Dokumenttyp Definition) das Dokument verarbeitet werden muss.
Wie kannst du dir das vorstellen? Nun HTML Strict kennt im gegensatz zu Transistional das target-Attribut nicht, weil es in der Strict DTD nicht enthalten ist (aus gutem Grund).