Ergebnis 1 bis 20 von 67

Thema: Semantisch korrekt oder simpel und leicht

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1

    Users Awaiting Email Confirmation

    Zitat Zitat von mitaki
    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:
    Zitat Zitat von http://www.webdevout.net/doctype_switching.php
    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^^)

  2. #2
    Zitat Zitat von Jesus_666
    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.

    Zitat Zitat von .Mi
    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

    Zitat Zitat von .Mi
    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^^

    Zitat Zitat von .Mi
    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.

    Zitat Zitat von .Mi
    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...

    Zitat 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
    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
    Ü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

    Geändert von mitaki (22.08.2006 um 00:31 Uhr)

  3. #3

    Users Awaiting Email Confirmation

    Zitat Zitat von mitaki
    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

    Zitat Zitat von mitaki
    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^^)
    [Utopie] Hoffen wir auf eine blühende Zukunft, in der sogar endlich der Internet Explorer ordentlich arbeitet.. [/Utopie]

  4. #4
    Zitat Zitat von .Mi
    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.

    Zitat Zitat von .Mi
    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.

    Zitat Zitat
    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.

  5. #5
    Jo danke werds mir mal anschauen. =)

  6. #6
    Zitat Zitat von mitaki
    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).

  7. #7

    Users Awaiting Email Confirmation

    Zitat Zitat von mitaki
    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.).

    Zitat Zitat von mitaki
    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!

  8. #8
    Zitat Zitat von .Mi
    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.

    Zitat Zitat von .Mi
    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.

    Zitat Zitat von .Mi
    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.

    Zitat Zitat von .Mi
    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.

    Zitat Zitat von .Mi
    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.

  9. #9
    Zitat Zitat von .Mi
    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.

    Zitat 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.).
    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.

  10. #10
    Zitat Zitat von Surface Dweller
    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.

  11. #11
    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^^

  12. #12

    Users Awaiting Email Confirmation

    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...

    Geändert von Teelicht (24.08.2006 um 15:41 Uhr)

  13. #13
    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^^

    Zitat Zitat von .Mi
    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.

  14. #14
    Zitat Zitat von mitaki
    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).

    Zitat Zitat
    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.

  15. #15
    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 ^^

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •