Maßeinheiten umrechnen px -> em

[Christoph Schnauß]

hallo Forum,

ich darf für einen "Auftraggeber" ein fixes Pixellayout erneuern und habe vorgeschlagen, daß er anstelle von Pixeln dann eine andere Maßeinheit bekommt. Vermutlich eine richtige Idee - nur: wie rechne ich beispielsweise eine bisher fixe Breitenangabe für ein Bild von 43px Breite in em um? Gibt es da einen einigermaßen zuverlässigen Umrechnungsfaktor? Was ich beim W3C finden konnte, beschränkt sich auf http://www.w3.org/TR/REC-CSS2/syndata.html#length-units, und das gibt mir nicht genügend Aufschluß.

Grüße aus Berlin

Christoph S.

[Felix Riesterer]

Lieber Christoph,

diese Frage ist hier wahrlich nicht neu... ;-)

Meine Meinung: Lass es besser bei den Pixeln, wenn Du "nur" den technischen Hintergrund ändern, nicht aber die Gestaltung der Seite komplett neu anfertigen willst. Maße wie em haben nuneinmal die Eigenschaft, dass man "vergrößern" kann. Mit festen Pixelmaßen geht das nicht. Wenn Du aber eh auf ein komplett "flüssiges Layout" umstellst, dann ermittle den Faktor doch durch einfaches Ausprobieren! Vergiss aber bitte nicht, dass Einstellungen des Betriebssystems und des Default-CSS Dir einen gehörigen Strich durch diese Eerfahrungswerte machen können!

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Christoph Schnauß]

hallo Felix,

diese Frage ist hier wahrlich nicht neu... ;-)

Vermutlich nicht, aber die Recherche im Archiv hat mir nichts Verwertbares eingebracht. Und ich schaue gewiß im Archiv nach. Vielleicht treffe ich nicht immer die richtigen Suchbegriffe. Was ich gefunden habe, waren einige Threads, in denen es lediglich um die Frage ging, was unter welchen Umständen für Maßeinheiten zu bevorzugen sind - und an einigen davon war ich sogar beteiligt.

Meine Meinung: Lass es besser bei den Pixeln, wenn Du "nur" den technischen Hintergrund ändern, nicht aber die Gestaltung der Seite komplett neu anfertigen willst.

Zumindest die HTML-Struktur muß ich komplett neu machen - nicht nur, weil sie invalide ist.

Maße wie em haben nuneinmal die Eigenschaft, dass man "vergrößern" kann. Mit festen Pixelmaßen geht das nicht.

Richtig, und genau deswegen möchte ich em einsetzen.

Grüße aus Berlin

Christoph S.

[MudGuard]

Hi,

ich darf für einen "Auftraggeber" ein fixes Pixellayout erneuern und habe vorgeschlagen, daß er anstelle von Pixeln dann eine andere Maßeinheit bekommt. Vermutlich eine richtige Idee - nur: wie rechne ich beispielsweise eine bisher fixe Breitenangabe für ein Bild von 43px Breite in em um?

Das kann nur gehen, wenn Du die font-Größe in Pixeln für das entsprechende Element weißt.

Gibt es da einen einigermaßen zuverlässigen Umrechnungsfaktor?

Ja, die für das entsprechende Element geltende Font-Größe in Pixeln.

cu,
Andreas

[Christoph Schnauß]

hallo Andreas,

Das kann nur gehen, wenn Du die font-Größe in Pixeln für das entsprechende Element weißt.

Die weiß ich - bei Schriften. Bilder haben meines Wissens keine Schriftgröße.

Gibt es da einen einigermaßen zuverlässigen Umrechnungsfaktor?
Ja, die für das entsprechende Element geltende Font-Größe in Pixeln.

Wie meinst du das? Wenn eine Schrift bisher 12 Pixel groß sein soll, sind das nicht gleich 1em. Und bei 20px hohen Eingabefeldern (input) könnten sich solche idiotischen Werte wie 1.81818182em ergeben.

Grüße aus Berlin

Christoph S.

[Manuel B.]

Ich grüsse den Cosmos,

Die weiß ich - bei Schriften. Bilder haben meines Wissens keine Schriftgröße.

Bilder kann der User auch nicht scalieren, Schrift schon, wenn die Angabe in em erfolgt.

Wie meinst du das? Wenn eine Schrift bisher 12 Pixel groß sein soll, sind das nicht gleich 1em.

Das kommt auf den Browser an. Wenn im Browser die Standardgrösse auf 12px steht, ist 12px=1em. Wenn ein Eingabefeld standardmässig 20px hoch ist, ist das 1em usw.
Wenn ich jetzt allerdings schlecht sehe und den Standardwert für Schriften auf 20px stehen hab, ist das auch 1em in diesem Browser.

Zumindest ist es das, wie ich diese Masseinheit verstanden hab, wenn ich falsch liege, bitte ich um Richtigstellung, da ich immer gerne dazulerne ;)

Möge das "Self" mit euch sein

[Christoph Schnauß]

hallo,

Bilder kann der User auch nicht scalieren

Jaaein. "Skalieren" geht tatsächlich nicht, wenn du darunter den vollen Erhalt des Bildinhalts verstehst. Ein ganz schnelles Beispiel: wenn du im IE unter "Ansicht" den Wert "kleiner" wählst wird ein vorhandenes Bild ganz einfach beschnitten, um auf die gewünschte "kleinere" Größe zu kommen. Aber was passiert mit Positionierungsangaben wie "margin"?

Grüße aus Berlin

Christoph S.

[Manuel B.]

Ich grüsse den Cosmos,

Jaaein. "Skalieren" geht tatsächlich nicht, wenn du darunter den vollen Erhalt des Bildinhalts verstehst.

So versthe ich das, also ein verkleinern des gesamten Bildes ;)

Ein ganz schnelles Beispiel: wenn du im IE unter "Ansicht" den Wert "kleiner" wählst wird ein vorhandenes Bild ganz einfach beschnitten, um auf die gewünschte "kleinere" Größe zu kommen.

Ok, was anderes als Skalieren, und ich habs nie ausprobiert, weil ich keinen IE nutze (ausser zum testen) und noch nie nötig hatte, ein Bild im Browser zu beschneiden. meine Monitore waren hisher immer gross genug ;)

Aber was passiert mit Positionierungsangaben wie "margin"?

Gute frage. Keine AHnung. Aber wie ich den IE kenne, einmal so einmal so und beim nächsten Update wieder ganz anders ~g~

Möge das "Self" mit euch sein

[Christoph Schnauß]

hallo,

ich habs nie ausprobiert, weil ich keinen IE nutze

Ich _muß_ das Ding berücksichtigen, da ihn der Auftraggeber für den einzigen relevanten Browser hält.

Grüße aus Berlin

Christoph S.

[Manuel B.]

Ich grüsse den Cosmos,

Ich _muß_ das Ding berücksichtigen, da ihn der Auftraggeber für den einzigen relevanten Browser hält.

Dann ist es deine Hauptaufgabe, deinen Kunden davon zu überzeugen, dass er falsch liegt. Ich kenn das selbst und hab nem Kunden schon ins Gesicht gesagt, wenn er glaubt, er hat mehr Ahnung, wie ich, soll er seine Seite doch selbst machen, bin aufgestanden und gegangen.
10 Minuten später klingelt das Handy und er gab mir freie Hand. Es funktoniert also, das man Kunden überzeugt, auch wenn sie noch so stur sind. Ich bin sturer ;)

Möge das "Self" mit euch sein

[Schuer]

Dann ist es deine Hauptaufgabe, deinen Kunden davon zu überzeugen, dass er falsch liegt.

Du hast deinen Kunden davon überzeugt, dass der IE nicht mehr relevant ist (sei)? Doch hoffentlich nicht, ohne ihm vorher seine Rechte vorzulesen? ;)

Viele Grüße!
_ds

[Manuel B.]

Ich grüsse den Cosmos,

Du hast deinen Kunden davon überzeugt, dass der IE nicht mehr relevant ist (sei)?

Nein, ich hab dem Kunden klargemacht, das der IE nicht _der einzige relevante Browser_ ist.

Möge das "Self" mit euch sein

[Christoph Schnauß]

hallo Manuel,

Dann ist es deine Hauptaufgabe, deinen Kunden davon zu überzeugen, dass er falsch liegt.

Wegen eines popligen Browsers wird er nicht sein gesamtes Intranet mit mehreren tausend Mitarbeitern von einem Tag auf den anderen umstellen. Alle Mitarbeiter nutzen den IE. Schluß.

Grüße aus Berlin

Christoph S.

[Manuel B.]

Ich grüsse den Cosmos,

Wegen eines popligen Browsers wird er nicht sein gesamtes Intranet mit mehreren tausend Mitarbeitern von einem Tag auf den anderen umstellen. Alle Mitarbeiter nutzen den IE. Schluß.

Naja, wenn er mir so argumentieren würde, müsste er sich jemand anderen suchen. Ich mache mir durch solche Aufträge nicht meinen Ruf kaputt.

Denn nur weil ich andere Browser berücksichtige, heisst es ja nicht, das er alles umstellen muss. Und wer mir gegenüber mit nicht existenten Argumenten argumentieren will, soll sich nen Hund kaufen, der hört besser auf sowas :D

Ich halte grundsätzlich solche Aufträge für kontraproduktiv, da sich das eigene Image schwächen und zusätzlich nur Ärger machen (solche Kunden sind nie zufrieden und verlange oft unmögliche Dinge).

Ist aber nicht das eigentliche Thema, daher schliese ich hiermit ;)

Möge das "Self" mit euch sein

[flowh]

Hallo Christoph.

Vielleicht hilft dir ja dieses Tool weiter:
http://www.riddle.pl/emcalc/

flowh

[Christoph Schnauß]

hallo,

Vielleicht hilft dir ja dieses Tool weiter:
http://www.riddle.pl/emcalc/

Das sieht ganz nett aus, und ich kannte das bisher nicht. Das Teil geht aber davon aus (wie auch MadGuards Argumentation), daß ich für <body> eine default-Schriftgröße in Pixeln vorgebe - wenn ich das denn richtig verstehe. Und genau das will ich eigentlich vermeiden. Außerdem rechnet dieses Teil nur zwei Stellen nach dem Komma aus, und das ist nicht genau genug.

Grüße aus Berlin

Christoph S.

[Struppi]

Das sieht ganz nett aus, und ich kannte das bisher nicht. Das Teil geht aber davon aus (wie auch MadGuards Argumentation), daß ich für <body> eine default-Schriftgröße in Pixeln vorgebe - wenn ich das denn richtig verstehe. Und genau das will ich eigentlich vermeiden.

Und genau das ist der Clou von em. Es ist eine relative Größe in Relation zu der  Schriftgröße des Elternelementes. Du kannst kein fixes Layout in em umrechnen, das ist völliger Blödsinn. Und selbst wenn du es auf einen Browser schafftst, mit zigkommastellen es umzurechnen, hat es genau gar keinen Vorteil, sondern nur Nachteile.

Struppi.

[Christoph Schnauß]

hallo Struppi,

Und genau das ist der Clou von em. Es ist eine relative Größe in Relation zu der  Schriftgröße des Elternelementes.

Die "Schriftgröße" bereitet mir keine Kopfschmerzen. Viel wichtiger ist, daß ich es mit einem Lsyout zu tun habe, das (beispielsweise) bisher für den Anzeigebereich des gesamten Inhalt 992px vorsieht. Ich komme _näherungsweise_ hin, wenn ich da nun 80em einsetze - aber eben nur näherungsweise. Und darüberhinaus wird die technische Abteilung meines Auftraggebers gewohnheitsmäßig mit einem Pixellineal nachmessen. Wenn die herausfinden, daß meine 80em auf ihren Monitoren nun 991px oder 993px ergeben, kriege ich eine entsprechende Korrekturanforderung.

Du kannst kein fixes Layout in em umrechnen, das ist völliger Blödsinn.

Das wäre allerdings mein Ansinnen gewesen. Wobei es gar nicht zuerst um Schriftgrößen geht, sondern um die Größen- und Positionierungsangaben von diversen HTML-Elementen; also eben nicht nur Schrift.

Bei allen Debatten, die ich bisher gefunden habe, ging es vorrangig um die Schriftgrößen (gilt übrigens auch für die beiden von Alex verlinkten und mir nicht gänzlich unbekannten Artikel)

Grüße aus Berlin

Christoph S.

[Schuer]

Und darüberhinaus wird die technische Abteilung meines Auftraggebers gewohnheitsmäßig mit einem Pixellineal nachmessen. Wenn die herausfinden, daß meine 80em auf ihren Monitoren nun 991px oder 993px ergeben, kriege ich eine entsprechende Korrekturanforderung.

In diesem Fall würde ich definitiv den Einsatz von px als Maßeinheit beibehalten, denn die von dir gerade genannte Anforderung wirst du nicht einhalten können.

Wenn es auf die Art flexibel sein soll, wie du es dir vorstellst, dann wären die 992px reines Glückspiel (es sei denn, es - das Lineal - würde ausschließlich am IE als angesprochenen Referenzbrowser festgemacht).

Viele Grüße!
_ds

[Struppi]

Die "Schriftgröße" bereitet mir keine Kopfschmerzen.

Du scheinst nicht zu verstehen, es geht nicht um die Schriftgrößen, sondern um die Maßeinheit. em ist eine Maßeinheit in Relation zu der Schiftgröße, was du machen willst ist Blödsinn. Du benutzt das falsche Werkzeug, du möchtest Pixel benutzen, dafür ist diese Maßeinheit. Das man ein Layout für eine Webseite sinnvolerweise mit em macht heißt nicht das man ein fixes Layout damit machen sollte, das wäre Kontraproduktiv.

Struppi.

[Christoph Schnauß]

hallo Struppi,

was du machen willst ist Blödsinn

Wenn du das mit dem "Blödsinn" auf verständliche Weise erläutern könntest, wäre dem Thread sehr geholfen.

du möchtest Pixel benutzen, dafür ist diese Maßeinheit.

Nein, ich _möchte_ eben gerade nicht Pixel benutzen, das war die Grundaussage im OP.

Das man ein Layout für eine Webseite sinnvolerweise mit em macht heißt nicht das man ein fixes Layout damit machen sollte, das wäre Kontraproduktiv.

Du hast es erfaßt - bisher ist das tatsächlich ein "fixes" Layout, und ich will nun keineswegs wieder ein fixes Layout auf der Grundlage einer anderen Maßeinheit bauen, sondern ich will das Layout flexibel machen - allerdings auf eine Weise, daß die Leute, die den bisherigen Zustand der Seite kennen, überhaupt nichts davon merken. Ich will sie von dem Zwang befreien, daß sie ihre Seite immer nur dann in voller Schönheit ohne Scrollbalken bewundern können, wenn sie ihre Browserfenster auf die "volle" Monitorgröße ziehen.

Grüße aus Berlin

Christoph S.

[Struppi]

was du machen willst ist Blödsinn

Wenn du das mit dem "Blödsinn" auf verständliche Weise erläutern könntest, wäre dem Thread sehr geholfen.

Es ist Blödsinn eine relatives Maß für etwas festes nehmen zu wollen. Das wäre wie wenn du versuchst die Menge einer Flasche Holunderwein (die optimale für Maßeinheit für Wein) exakt in einem Gummiballon zu füllen, auch wenn du weiß das normalerweise eine Flasche reinpaßt, kannst du nie sicher sein, ob er nicht platz oder sich so gut dehnt dass du auch zwei Flaschen reinkriegst. Und es ist kein Spaß es zu transportieren.

Das man ein Layout für eine Webseite sinnvolerweise mit em macht heißt nicht das man ein fixes Layout damit machen sollte, das wäre Kontraproduktiv.

Du hast es erfaßt - bisher ist das tatsächlich ein "fixes" Layout, und ich will nun keineswegs wieder ein fixes Layout auf der Grundlage einer anderen Maßeinheit bauen, sondern ich will das Layout flexibel machen -

Du kannst kein fixes Layout flexibel machen

Ich will sie von dem Zwang befreien, daß sie ihre Seite immer nur dann in voller Schönheit ohne Scrollbalken bewundern können, wenn sie ihre Browserfenster auf die "volle" Monitorgröße ziehen.

Das ist durchaus ein seltsames Verhalten was ich immer öfters beobachte das viele Leute ihre Fenster immer maximieren. Nur wenn das Layout genau dafür ausgelegt ist, wirst du das nicht reparieren indem du es 1:1 umrechnest.
Zumal meines Wissen mittlerweile auch der IE 7 Pixelschriften skalieren kann.

Struppi.

[Jonathan]

Hallo Christoph,

ich will das Layout flexibel machen - allerdings auf eine Weise, daß die Leute, die den bisherigen Zustand der Seite kennen, überhaupt nichts davon merken.

Auf die Weise, die du versuchst ist das ziemlich unmöglich. Du kannst ja wahrscheinlich nicht davon ausgehen, dass überall die gleiche Schriftgröße eingestellt ist. Und wenn du's kannst, kannst du auch gleich px verwenden.

Ich will sie von dem Zwang befreien, daß sie ihre Seite immer nur dann in voller Schönheit ohne Scrollbalken bewundern können, wenn sie ihre Browserfenster auf die "volle" Monitorgröße ziehen.

Wieso benutzt du dann keine prozentualen Angaben evtl. in Verbindung mit min- und max-width? Ansonsten hilft hier die Benutztung von em aber auch nichts. Die schriftgröße wird ja nicht automatisch kleiner, mur weil man das Browserfenster bzw. den Viewport verkleinert.

Jonathan

[Christoph Schnauß]

hallo,

Wieso benutzt du dann keine prozentualen Angaben evtl. in Verbindung mit min- und max-width?

Prozentuale Angaben sind eine Option - minimale/maximale Breitenangaben sind es nicht, weil der IE6 die nicht versteht.

Grüße aus Berlin

Christoph S.

[Jonathan]

Hallo Christoph,

minimale/maximale Breitenangaben sind es nicht, weil der IE6 die nicht versteht.

Die kann man notfalls per Javascript-Expression nachbauen, falls benötigt.

Jonathan

[Sven Rautenberg]

Moin!

Und darüberhinaus wird die technische Abteilung meines Auftraggebers gewohnheitsmäßig mit einem Pixellineal nachmessen. Wenn die herausfinden, daß meine 80em auf ihren Monitoren nun 991px oder 993px ergeben, kriege ich eine entsprechende Korrekturanforderung.

Dann führt dein Vorhaben, em zu verwenden, dich direkt in die Katastrophe.

Szenario: Du machst erstmal mit groben em-Werten das Layout, es kommt zu einzelnen Pixelabweichungen.

Die Pixelabweichungen werden moniert und sollen korrigiert werden.

Du korrigierst die konkrete Maßeinheit auf einen Wert mit vielen Nachkommastellen, um unter Standardbedingungen (die hoffentlich im Browser deiner Auftraggeber und Nachmesser auch gelten) die Maße einzuhalten.

Dann kommt eine andere Pixelabweichung, die ebenfalls korrigiert werden muß. Dummerweise im Vererbungsbaum weiter oben.

Das hat wieder Auswirkungen auf die vormals getätigte Korrektur, du rechnest die eklig lange Kommazahl nochmal neu - sofern du dran denkst, und dir nicht die Grafikabteilung erneut die Korrektur aufgibt.

Da diese Größenänderung weiter oben im Vererbungsbaum ansetzte, haben sich aber noch ganz andere Maße verändert, die ebenfalls wieder pixelgenau korrigiert werden müssen.

Und so weiter, und so fort... Ganz grausam wird es, wenn irgendein IE-Browser der Grafikabteilung als relevant betrachtet wird, aber nicht die mittlere Schriftgröße eingestellt hat. Oder der Schriftgrößenstandard verstellt wurde.

Und zu guter letzt wird die Grafikabteilung nicht akzeptieren, dass Pixelgrafiken, vornehmlich Icons, in unzureichender Weise vom Browser skaliert werden - das sieht nämlich, egal wie gut die Algorithmen sind, richtig scheiße aus, und das werden die dir auch sagen.

Mit anderen Worten: Du hast großes Potential, dich mit diesem Auftrag auf Jahre hinaus zu beschäftigen und dabei die meiste Zeit nur Nachkommastellenfeintuning in den em-Werten durchzuführen - dabei aber gegenüber deinem Auftraggeber wie der größte Idiot auszusehen, der es einfach nicht hinbekommt - Validität der Webseite hin oder her. Diejenigen, die das Intranet vorher gemacht haben, die hatten es hinbekommen. Es ist halt nur sehr unwahrscheinlich, dass man dich diese Jahre werkeln läßt.

Du kannst kein fixes Layout in em umrechnen, das ist völliger Blödsinn.

Das wäre allerdings mein Ansinnen gewesen. Wobei es gar nicht zuerst um Schriftgrößen geht, sondern um die Größen- und Positionierungsangaben von diversen HTML-Elementen; also eben nicht nur Schrift.

Die Problematik mit em ist auch der unterschiedliche Bezug:

Wenn man em in font-size verwendet, bezieht sie sich auf die font-size der im HTML übergeordneten Elements.

Wenn man em in irgendeiner anderen Längenangabe verwendet, bezieht sie sich auf die font-size dieses Elements.

Das bedeutet, dass 1em nirgendwo dasselbe (in dargestellten Pixeln) ist. 1em im Body ist die Browserschriftgröße, also vielleicht 16 px. 1em als Border des Body ist dann auch 16px. 0.5em als font-size in einem Absatz wären dann 8px. Und 0.5em Border für diesen Absatz wären dann 4px! Dasselbe gilt, wollte man Grafikgrößen in em angeben. Ein 10px breites Icon ist im Body 0.625em groß. Im Textabsatz müßte man aber 1.25em angeben für die gleiche optische Größe.

Bei diesen ganzzahligen Verhältnissen ist das Spielchen noch einigermaßen durchschaubar - aber wenn die Überschrift dargestellte 13px = 0.8125em sein soll, erfordert darin das 10px-Icon schon 0.769230769230em (der Bruch 10/13 ist periodisch nichtabbrechend - also vermutlich auch ein Horror für die Computermathematik).

Du kannst selbstverständlich gerne den em-Weg wählen. Nur solltest du dir dann vorher schriftlich bestätigen lassen, dass die Grafikabteilung keine Pixel zählen wird. Nur dann hat ein em-Layout eine reelle Chance, in annehmbarer Zeit realisiert werden zu können.

Und selbst dann würde ich persönlich Pixelgrafiken niemals mit em-Größenangaben versehen.

- Sven Rautenberg

[MudGuard]

Hi,

Das Teil geht aber davon aus (wie auch MadGuards

keine Beleidigungen bitte!

Argumentation), daß ich für <body> eine default-Schriftgröße in Pixeln vorgebe

Das habe ich nicht vorgeschlagen. Würde ich auch nicht. Ich habe lediglich gesagt, daß zur Umrechnung von px in em der Umrechnungsfaktor (sprich: die Schriftgröße in Pixeln) bekannt sein muß.

cu,
Andreas

[Christoph Schnauß]

hallo Andreas,

Das Teil geht aber davon aus (wie auch MadGuards
keine Beleidigungen bitte!

Um Gotteswillen! Du wirst doch zwischen einem Tippfehler und einer Beleidigung unterscheiden können ;-)

Argumentation), daß ich für <body> eine default-Schriftgröße in Pixeln vorgebe
Das habe ich nicht vorgeschlagen.

Hm. Wörtlich hast du das nicht, aber ich habe es in diesem Sinn verstanden. Selbstverständlich korrigiere ich jetzt _sofort_ mein Verständnis deiner Aussage.

Grüße aus Berlin

Christoph S.

[Alex]

Hallo,

nur: wie rechne ich beispielsweise eine bisher fixe Breitenangabe für ein Bild von 43px Breite in em um?

Mit umrechnen wirst Du glaube ich nicht glücklich werden. Als Einstieg in das Thema kann ich diesen SELFHTML-Weblog-Artikel (und die Kommentare) empfehlen: (Keine Antwort auf) Die Frage nach der richtigen Schriftgröße.

Fazit: ob nun em besser als px ist, kann man nicht eindeutig sagen. Und wie gut eine Webseite scallierbar ist, hängt letztendlich vom Browser ab. Opera scalliert z.B. auch px.

Mich hat letztendlich dieser Artikel von Ingo Turski überzeugt: »em« nicht nur für Schriftgrößen!. Em macht (nur) sinn, wenn alles in em ausgezeichnet wird, nicht nur die Schriftgrößen.

Alex

[Schuer]

Gibt es da einen einigermaßen zuverlässigen Umrechnungsfaktor?

Die Default-Schriftgröße der meisten Browser dürfte bei 16px liegen. Somit sind 16px für dich 1em, solange keine relativ bemessenen Elternelemente dazwischen liegen. Sollte das der Fall sein, musst du hast vom Elternelement aus mit deiner Umrechnung beginnen.

Manuel mit seinen 20px als default bekäme deine Website also direkt nach oben skaliert.

(Oder hab ich jetzt irgendwie das Problem nicht verstanden?)

Viele Grüße!
_ds

[Christoph Schnauß]

hallo Dirk,

Die Default-Schriftgröße der meisten Browser dürfte bei 16px liegen. Somit sind 16px für dich 1em, solange keine relativ bemessenen Elternelemente dazwischen liegen.

Ja, das ist mir bekannt. Vermutlich habe ich im OP nicht deutlich gemacht, daß ich mit der "Schriftgröße" die allerwenigsten Probleme habe. Weit wichtiger sind Positionierungsangaben, Randbreiten und Breiten von definierten Bereichen (DIVs).

Grüße aus Berlin

Christoph S.

[Schuer]

Ja, das ist mir bekannt. Vermutlich habe ich im OP nicht deutlich gemacht, daß ich mit der "Schriftgröße" die allerwenigsten Probleme habe. Weit wichtiger sind Positionierungsangaben, Randbreiten und Breiten von definierten Bereichen (DIVs).

Wie gesagt: 16px = 1em. Margin: 16px wird zu margin: 1em, border: 8px zu border: 0.5em. Der Rest ist ein schlichter Dreisatz. Liegt eine Vererbung an, musst du nochmal einen Schritt weiter rechnen - Vererbung ist der natürliche Feind der relativen Maßeinheit.

Welche Angaben fehlen dir noch?

Viele Grüße!
_ds

[Christoph Schnauß]

hallo Dirk,

Vererbung ist der natürliche Feind der relativen Maßeinheit.

Schöner Satz.

Welche Angaben fehlen dir noch?

Im Augenblick fallen mir keine ein, da sich der gesamte Thread ja auf sehr vernünftige Weise entwickelt hat und ich _ein paar_ der Vorschläge doch erstmal durchspielen muß, um sie zu prüfen.

Grüße aus Berlin

Christoph S.

[Schuer]

Im Augenblick fallen mir keine ein, da sich der gesamte Thread ja auf sehr vernünftige Weise entwickelt hat und ich _ein paar_ der Vorschläge doch erstmal durchspielen muß, um sie zu prüfen.

Viel Erfolg! Vielleicht noch als Anregung: http://www.l-bank.de.

Viele Grüße!
_ds

[Orlando]

wie rechne ich beispielsweise eine bisher fixe Breitenangabe für ein Bild von 43px Breite in em um?

Gar nicht. Das Bild ist 43px breit und soll es auch bleiben. Handelt es sich um ein Foto, Icon oder dergleichen, bietet nur der Faktor 1 ausreichende Qualität (kennst und kannst du SVG?). Handelt es sich um einen verlaufenden Hintergrund, erstelle ihn so groß, dass er auch hochskalierte Elemente vollständig abdeckt. Handelt es sich um ein Hintergrundbild, das eine Begrenzung darstellt („Tabs“), dann ändere das und verwende nach Möglichkeit die border-Eigenschaft.

Gibt es da einen einigermaßen zuverlässigen Umrechnungsfaktor?

Einigermaßen reicht nicht, da helfen auch die oft genannten 16px nicht weiter. Bitte konkretisiere die Frage anhand eines Beispiels, damit wir uns nicht in naturreligiösen Ansichten verzetteln. Welche Art von Bildern soll skaliert werden?

Was ich beim W3C finden konnte, beschränkt sich auf http://www.w3.org/TR/REC-CSS2/syndata.html#length-units

• CSS3: background-size (Beispiel)

Roland

[Schuer]

Handelt es sich um ein Foto, Icon oder dergleichen, bietet nur der Faktor 1 ausreichende Qualität

Einspruch, euer Tiger. Man neigt inzwischen dazu, den Wert eines nach oben skalierenden Layouts über den eines verwaschenen Bildes zu setzen, sprich: Zoomen ist schöner als Nur-Text-Skalierung.

Opera macht's ja sowieso schon seit einiger Zeit intern, der IE7 hat offiziell nachgezogen und Firefox 3 wird ebenfalls.

Ich bin allerdings der Meinung, dass man als Webentwickler zusätzlich noch die Größe des Viewports mit einbeziehen sollte (Javascript olè!), wenn man vollskalierende Layouts erstellt, und dass man für kleinere Viewports die Defaultschriftgröße des Bodys entsprechend verringern sollte, um den Nutzer nicht vorm Monitor wegzufegen.

Viele Grüße!
_ds

[Orlando]

Handelt es sich um ein Foto, Icon oder dergleichen, bietet nur der Faktor 1 ausreichende Qualität

Einspruch, euer Tiger.

So sage er ihn uns auf!

Man neigt inzwischen dazu, den Wert eines nach oben skalierenden Layouts über den eines verwaschenen Bildes zu setzen

Dass Eleganz nur wenig mit Schönheit zu tun hat, zeigen alle mir bekannten Ergebnisse einer Skalierung durch einen Browser. Nichts davon erreicht auch nur annähernd die Ergebnisse einer Bildbearbeitung. Dass eine gute Skalierung unabdinglich ist, bestreite ich nicht. Dass man diese bei Layout-Grafiken dem Browser überlassen sollte sehrwohl. Denn gerade der Bereich, in dem Textvergrößerung tatsächlich angewandt wird ergibt für Bilder unhandliche Faktoren. Selbst von Photoshop kann man bei 120 % keine Wunder erwarten und enthält die Grafik typischerweise Linien, ist’s mit der Augenschmeichelei ohnehin schnell vorbei. Lediglich bei echten Fotos kaschiert das Auge kleinere Ungereimtheiten.

sprich: Zoomen ist schöner als Nur-Text-Skalierung.

So viel zum gemeinsamen Nenner. Der Spielspaß kommt erst beim Wii.

Ich bin allerdings der Meinung, dass man als Webentwickler zusätzlich noch die Größe des Viewports mit einbeziehen sollte (Javascript olè!),

JavaScript passé, CSS olè!

Bald. Irgendwann. Vielleicht. Bitte! ;-)

Roland

[Schuer]

So sage er ihn uns auf!

Es ist mir leider versagt.

Dass Eleganz nur wenig mit Schönheit zu tun hat, zeigen alle mir bekannten Ergebnisse einer Skalierung durch einen Browser.

Lass dich doch mal ein bisschen einschmeicheln: http://www.l-bank.de

Natürlich schwächelt es bei allen Grafiken/Bildern, die keine Fotos sind, aber die könnte man zurnot auch pixelbasiert einsetzen, wenn es die Logik des Backends und ggfl das Verständnis des Redakteurs erlaubt.

Ich empfinde vollskalierende Seiten, die je nach Beschaffenheit des Layouts ggfls zusätzlich noch umbrechen oder anderweitig gegenwirken, zurzeit (!) als State of the Art. Das kann allerdings ein sehr kurzlebiger Trend sein, denn browserbedingt (IE7, FF3, iPhone) gibt es auch Meinungen/Tendenzen zurück zum rein pixelbasierten Layout inklusive pixelbasierten Schriftangaben -> man möge die Skalierung besser dem Browser überlassen.

Dagegen spricht, dass uns der Leopard demnächst immer mehr Vektoren entgegen brüllen wird und man nicht mehr auf Pixel für die Grafikengine setzt. Und weil hinzukommt, dass moderne Screens immer hochauflösender im Sinne von »enger« - mehr Pixel auf gleichem Raum - werden, ist der gute alte Pixel demnächst nichts mehr wert ;)

Vielleicht gibt es also eine Währungsreform im Web. Vielleicht wird man auch einfach weiter wie gewohnt mit allen möglichen Devisen zahlen.

Viele Grüße!
_ds

[Orlando]

Einspruch
So sage er ihn uns auf!
Es ist mir leider versagt.

Kläglich sogar, aber nicht verzagen.

http://www.l-bank.de

Bei Farbverläufen hat man die Christoph jetzt einholenden Probleme natürlich nicht und gar keine Größe bei Bildern anzugeben war früher einmal verpönt. Das ruckelt ja beim Laden! ;-) Was ich meinte, sind die typischern 90er-Sites, bei denen <table width= … > die Flexibilität im Keim erstickt hat und man sich auf Größenangaben noch verlassen konnte. Was nicht passt, wird mit Scrollbars passend gemacht.

Natürlich schwächelt es bei allen Grafiken/Bildern, die keine Fotos sind, aber die könnte man zurnot auch pixelbasiert einsetzen, wenn es die Logik des Backends und ggfl das Verständnis des Redakteurs erlaubt.

Den Absatz verstehe ich nicht ganz (pixelbasierter Einsatz um auf px zu verzichten?)

Für Christoph noch einmal am Beispiel demonstriert, was ich mit übergroßen Hintergrundbildern meinte: Flexible Grafiken mit CSS.

Ich empfinde vollskalierende Seiten, die je nach Beschaffenheit des Layouts ggfls zusätzlich noch umbrechen oder anderweitig gegenwirken, zurzeit (!) als State of the Art.

Zurzeit sicher. Vieles von dem was ich anpreise ist ja für die breite Masse noch nicht praktikabel (IE und so).

Das kann allerdings ein sehr kurzlebiger Trend sein, denn browserbedingt (IE7, FF3, iPhone) gibt es auch Meinungen/Tendenzen zurück zum rein pixelbasierten Layout inklusive pixelbasierten Schriftangaben -> man möge die Skalierung besser dem Browser überlassen.

Das halte ich für überlegenswert, nicht nur, aber gerade bei mobilen Endgeräten. Denn mit Opera und Safari beherrschen zwei sehr weit verbreitete Browser die bereits genannten Media Queries. Eine Site für kleine Viewports zu optimieren ist damit überhaupt kein Problem. Safari, wie er auf dem iPhone und iPod touch läuft mit angepasstem Stylesheet (193 kb) und einmal ohne (leider ohne MQs, also nur zur Demonstration). Bei Opera, dem oft noch weniger Platz zur Verfügung steht funktioniert die Anpassung nicht ganz so gut, vor allem kann der Viewport auch schwanken, weil er auf unterschiedlichen Geräten läuft. Wie dem auch sei, mit Media Queries bekommt man das relativ schmerzfrei hin.

Dagegen spricht, dass uns der Leopard demnächst immer mehr Vektoren entgegen brüllen wird und man nicht mehr auf Pixel für die Grafikengine setzt.

Ein Vektor-GUI, genau. Sehr geil.

Für Christoph: High DPI Websites und Iconic passen gut zum Thema.

Vielleicht gibt es also eine Währungsreform im Web. Vielleicht wird man auch einfach weiter wie gewohnt mit allen möglichen Devisen zahlen.

Deine Devise lautet wenigstens, dafür Geld zu nehmen. ;-)

Roland

[Christoph Schnauß]

morgens,

Für Christoph

Ich nehme diese wiederkehrenden Hinweise mit einem gewissen unentschiedenen Knurren zu Kenntnis und werde sie studieren.

Vielleicht gibt es also eine Währungsreform im Web.
Deine Devise lautet wenigstens, dafür Geld zu nehmen. ;-)

Meine im Ausgangsfall auch - und sogar viel Geld. Nur sind "große" Firmen, wenn man sie denn mal als Auftraggeber erwischt, ausgesprochen konservativ. Die Entwicklungsabteilung nimmt diverse Vorschläge gerne zur Kenntnis, und ich bewerte es eigentlich als sehr großen Fortschritt, daß sie sich überhaupt um das Problem der "Maßeinheit" mittlerweile Gedanken machen.

Einiges von dem, was in diesem Thread bisher angemerkt wurde, werde ich vermutlich für den "öffentlichen" Bereich umsetzen können. Aber es hängt nun einmal auch das firmeneigene Intranet dran, und da gibts nun einmal Restriktionen. Nur einige ganz wenige Mitarbeiter wissen, daß es außer IE6 noch andere Browser gibt. Und keiner darf sich mal eben schnell als "Update" den IE7 ziehen. Aber alle sollen, egal, ob sie nun die "öffentliche" Darstellung aufrufen oder die Intranetdarstellung exakt dasselbe Layout vorfinden.

Grüße aus Berlin

Christoph S.

[Struppi]

Die Entwicklungsabteilung nimmt diverse Vorschläge gerne zur Kenntnis, und ich bewerte es eigentlich als sehr großen Fortschritt, daß sie sich überhaupt um das Problem der "Maßeinheit" mittlerweile Gedanken machen.

Es gibt kein Problem mit der Maßeinheit.
Wer Pixel nimmt hat ein Layout das eher fixiert ist und nimmt weniger Rücksicht auf die Einstellung des Besuchers (oder braucht es nicht). Das ist legitim und kein Problem.

Das Problem der Barrierefreiheit ist im Zusammenhang mit Pixeln keines mehr, da die meisten Browser die Schrift trotzdem skalieren.

Das einzige Problem bei Pixel ist meiner Meinung, dass eine Seite unharmonisch wird (in Relation des Browserfensters), wenn Größenangaben für Bereiche in Pixel gemacht werden. Aber da ist em auch nicht besser. Alles in allem ist em heutzutage nicht die erste Wahl.

Ein Fortschritt wäre, wenn "die Entwicklungsabteilung" erkennen würde, dass sie nicht für's Papier entwickeln.

Struppi.

[Schuer]

Einspruch
So sage er ihn uns auf!
Es ist mir leider versagt.
Kläglich sogar, aber nicht verzagen.

Zag's bitte nicht weiter.

Den Absatz verstehe ich nicht ganz (pixelbasierter Einsatz um auf px zu verzichten?)

Ich hatte mich undeutlich ausgedrückt. In einem vollskalierenden Layout muss man nicht zwangsläufig alle Bilder skalieren lassen: so könnte man z.B. Icons, die nicht skalieren sollen, einfach pixelbasiert ausgeben, und stattdessen das umschließende Elemente skalieren lassen. Dieses Element wird dann vermutlich ein Hintergrund sein ;)

Ein Vektor-GUI, genau. Sehr geil.

Tanz doch mal ein bisschen ;)

Deine Devise lautet wenigstens, dafür Geld zu nehmen. ;-)

Ich warte noch drauf, dass mich mal jemand mit einem Smart auszahlen möchte ;)

Viele Grüße!
_ds

[Orlando]

Einspruch
So sage er ihn uns auf!
Es ist mir leider versagt.
Kläglich sogar, aber nicht verzagen.
Zag's bitte nicht weiter.

Na komm schon, aber zaggich jetzt!

In einem vollskalierenden Layout muss man nicht zwangsläufig alle Bilder skalieren lassen: so könnte man z.B. Icons, die nicht skalieren sollen, einfach pixelbasiert ausgeben, und stattdessen das umschließende Elemente skalieren lassen. Dieses Element wird dann vermutlich ein Hintergrund sein ;)

Ja, damit hast du Recht. Für landläufige Icons versuche ich, aus dem reichen Unicode-Vorrat zu schöpfen, da findet sich meist etwas. Wobei es noch interessant zu erwähnen ist, dass Opera 9.5 SVG-Grafiken als Hintergrundbilder akzeptiert.

Tanz doch mal ein bisschen ;)

*gg*

Hey, ich bin der Konservative von uns zweien. Sogar mit Kompetenzprothese um den Hals! Dein Anzug scheint mir da mehr Bewegungsfreiheit zu versprechen.

Ich warte noch drauf, dass mich mal jemand mit einem Smart auszahlen möchte ;)

Ah ja, dein geliebtes Ghetto(blaster)mobil!

Roland :-)

[Christoph Schnauß]

hallo Roland,

(kennst und kannst du SVG?)

Öhm - ist diese Nachfrage ernsthaft zu behandeln? Ja, ich _kenne_ SVG, ob ich es tatsächlich _kann_, ist eine andere Frage. Aber für mein Thema völlig irrelevant. Grafiken (Bilder, Icons, Verlaufsgrafiken usw.) erstellt die grafische Abteilung. In ihren Grafikprogrammen (im wesentlichen Photoshop) halten die Kollegen sich an Pixel und viele kennen gar nix anderes.

Gibt es da einen einigermaßen zuverlässigen Umrechnungsfaktor?
Einigermaßen reicht nicht, da helfen auch die oft genannten 16px nicht weiter.

Ja, so weit bin ich mittlerweile auch schon - und das gefällt mir nicht (seufz).

Bitte konkretisiere die Frage anhand eines Beispiels

Geht leider nicht, weil ich eine "Verschwiegenheitserklärung" unterzeichnet habe, das Problem aber nur am bisher veröffentlichten Code wirklich nachvollziehbar dargestellt werden könnte.

Was ich beim W3C finden konnte, beschränkt sich auf http://www.w3.org/TR/REC-CSS2/syndata.html#length-units
• CSS3: background-size (Beispiel)

Danke, das ist Lesestoff. CSS3 kann/muß ich allerdings zur Zeit noch auslassen.

Grüße aus Berlin

Christoph S.

[Orlando]

(kennst und kannst du SVG?)

Grafiken (Bilder, Icons, Verlaufsgrafiken usw.) erstellt die grafische Abteilung. In ihren Grafikprogrammen (im wesentlichen Photoshop) halten die Kollegen sich an Pixel und viele kennen gar nix anderes.

Wie weit reicht dein Spielraum? Hast du freie Hand beim Layout oder sollst du alten Wein in neuen Schläuchen erschaffen? Falls es sich bei den Layoutern um Kistenschieber handelt, bei denen jedes Element seinen von der Photoshop-Logi(sti)k vorgesehenen Platz einnehmen muss, wirst du das Problem nicht lösen können. Gerade das exakte Aneinanderpositionieren von Bereichen/Grafiken muss man zugunsten der Flexibilität opfern. Das Denken in relativen Einheiten erzwingt eine Abkehr von pixelgenauen Umsetzungen in allen Browsern und eröffnet dem Gestalter die Möglichkeit, dem Layout die nötige Luft zu lassen.

Bitte konkretisiere die Frage anhand eines Beispiels

"Verschwiegenheitserklärung"

Dann musst du umso mehr plappern. Ich weiß nämlich immer noch nicht, wobei genau du Probleme hast.

Roland

[Christoph Schnauß]

hallo Roland,

sollst du alten Wein in neuen Schläuchen erschaffen?

Nö. Ich soll neuen Wein in alte Schläuche füllen, aber deren Löcher schließen - ähm, der Vergleich "hinkt" natürlich gewaltig.

Falls es sich bei den Layoutern um Kistenschieber handelt, bei denen jedes Element seinen von der Photoshop-Logi(sti)k vorgesehenen Platz einnehmen muss, wirst du das Problem nicht lösen können.

Och - das ist nun gerade genau _der_ Motivationsschub, den ich _nicht_ gewünscht habe. Grmpf.

Grüße aus Berlin

Christoph S.