Schriftarten

[G.Bundschuh]

Hallo!

Habe gestern ein wenig an meiner Webseite rumgebastelt
und unter anderem eine Kommentarfunktion hinzugefügt.

Nun möchte ich die Kommetare auch optisch von meinem
eigenen Content abheben und eine andere Schriftart dafür
benutzen. Bisher habe ich eigentlich auf meiner Seite nur
Arial oder Tahoma benutzt.

Jetzt stellt sich mir doch mal grundsätzlich die Frage, welche
Schriftarten denn eigentlich auf jedem System vorhanden sind,
bzw. von welchen Schriftarten man davon ausgehen darf,
dass sie DA sind?

mfg Gerd

[Gert Be]

"G.Bundschuh" <g.bun...@arcor.de> schrieb

Viele halten SelfHtml zwar für überholt; aber für solche grundlegenden
Dinge dürfte es schon noch passen.
Schau z.B. mal hier
<http://de.selfhtml.org/css/eigenschaften/schrift.htm#font_family>

hth
Gert

[Arno Welzel]

G.Bundschuh, 2012-04-19 17:56:

> Habe gestern ein wenig an meiner Webseite rumgebastelt
> und unter anderem eine Kommentarfunktion hinzugefügt.
>
> Nun möchte ich die Kommetare auch optisch von meinem
> eigenen Content abheben und eine andere Schriftart dafür
> benutzen. Bisher habe ich eigentlich auf meiner Seite nur
> Arial oder Tahoma benutzt.

Schlecht. Benutze statt dessen andere Merkmale - Kursiv, Fett,
Einrückung, Farben, Rahmen etc.

> Jetzt stellt sich mir doch mal grundsätzlich die Frage, welche
> Schriftarten denn eigentlich auf jedem System vorhanden sind,
> bzw. von welchen Schriftarten man davon ausgehen darf,
> dass sie DA sind?

Gar keine außer den generischen Varianten "sans-serif", "serif" etc.

Du könntest natürlich mit webfonts deine bevorzugte Schrift vorgeben -
aber auch das wird nicht überall unterstützt.

Deshalb würde ich es einfach gar nicht mit der Schriftart versuchen,
sondern nur mit anderen Merkmalen.


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[Volker Gringmuth]

G.Bundschuh wrote:

> Nun möchte ich die Kommetare auch optisch von meinem
> eigenen Content abheben und eine andere Schriftart dafür
> benutzen.

Wieso andere Schriftart? Nimm eine andere Farbe, eine Hintergrundfarbe,
eine Umrandung, einen anderen Schriftschnitt (kursiv) oder so was.

Schau dir doch mal Nachrichten- oder Blogseiten mit Kommentarfunktion an:
Nehmen die eine eigene Schriftart dafür? Warum nicht? Wie sähe es aus?

> Bisher habe ich eigentlich auf meiner Seite nur
> Arial oder Tahoma benutzt.

Die gibt’s nur auf Windows-Rechnern, sofern sie nicht vom Benutzer
nachträglich installiert wurden. Macs und Linuxe müssen die schon durch eine
ähnliche Schriftart aus dem eigenen Bestand ersetzen. Da klingt das Wort
„benutzt“ schon etwas merckwürzig. „Vorgegeben“ oder „gewünscht“ wäre
treffender.

> Jetzt stellt sich mir doch mal grundsätzlich die Frage, welche
> Schriftarten denn eigentlich auf jedem System vorhanden sind,
> bzw. von welchen Schriftarten man davon ausgehen darf,
> dass sie DA sind?

Du mußt jetzt sehr stark sein: Von überhaupt keinen. Bei Windows ist
Arial die Standard-Sans-Serif-Schrift, auf’m Mac dürfte es Helvetica
sein, bei Linuxen hängt es von der Distribution ab, Nimbus Sans oder Free
Sans als Helvetica-Klone werden hier häufig mitgeliefert.

Deshalb gibt man Schriftfamilien vor (sans-serif etc.) und überläßt es dem
jeweiligen System, welche konkrete Schrift es dafür jeweils nimmt. In
besseren Browsern kann das der Benutzer einstellen, und ich persönlich
finde es äußerst unschön, eine Website in einer IMHO schlecht lesbaren
Schrift präsentiert zu bekommen, nur weil deren Ersteller meint, mir diese
Schrift vorschreiben zu müssen.

Wenn du das Layout selbst festlegen willst, ist HTML das flchsae Werkzeug,
und du solltest PDF nehmen.


vG

[G.Bundschuh]

Volker Gringmuth schrieb:

> Wenn du das Layout selbst festlegen willst, ist HTML das flchsae Werkzeug,
> und du solltest PDF nehmen.

1. Das ist mir jetzt zu katholisch. HTML ist schließlich dazu da,
die Ausgabe zu steuern. Sonst könnte man nämlich auch eine
reine *.txt Datei nehmen, nicht wahr? Ich denke, html liegt irgendwo
zwischen PDF und TXT, gell?

2. Wäre Deine Ansicht die wahre Lehre, würde HTML die
Optionen nicht bieten. Da bin ich mir ganz sicher.

3. Ziehe ich meine Frage zurück. Mich erwartet hier nix.

mfg Gerd

[Alexander - LX - Schmidt]

"G.Bundschuh" <g.bun...@arcor.de> schrieb:

> Nun möchte ich die Kommetare auch optisch von meinem
> eigenen Content abheben und eine andere Schriftart dafür
> benutzen. Bisher habe ich eigentlich auf meiner Seite nur
> Arial oder Tahoma benutzt.

Prinzipiell würde ich wie die anderen Poster auch einfach die
bestehende Schrift variieren oder sonstwie "auszeichnen". Wenn
Du unbedingt eine andere haben möchtest, werfe ich ergänzend
das Thema "Webfonts" in den Raum:
http://de.wikipedia.org/wiki/Webtypografie
http://www.google.com/webfonts

Diese sind, wenn man sie richtig einbindet, auch in älteren
Browsern (selbst IE6 klappt) darstellbar.

Alex.

[Holger Marzen]

* On Thu, 19 Apr 2012 21:50:56 +0200, G.Bundschuh wrote:

> Volker Gringmuth schrieb:
>
>> Wenn du das Layout selbst festlegen willst, ist HTML das flchsae Werkzeug,
>> und du solltest PDF nehmen.
>
> 1. Das ist mir jetzt zu katholisch. HTML ist schließlich dazu da,
> die Ausgabe zu steuern. Sonst könnte man nämlich auch eine
> reine *.txt Datei nehmen, nicht wahr? Ich denke, html liegt irgendwo
> zwischen PDF und TXT, gell?

Jeder hat das Recht, gegen gängige Typographieregeln zu verstoßen. Schau
Dich mal bei google.de/webfonts um. Nur so klappt das mit bestimmten
Fonts. Selbst Arial muss nicht auf jedem Rechner installiert sein,
geschweige denn Tahoma. Beim Ansprechen der Webfonts holt sich der
Browser dagegen die gewünschte Schrift.

[G.Bundschuh]

Holger Marzen schrieb:

> Schau Dich mal bei google.de/webfonts um. Nur so klappt
> das mit bestimmten Fonts.

Danke Holger, danke auch an Arno, der mir ebenfalls
diesen Tip gegeben hat. Wenn sich der Browser aber
erst die Schrift runterladen muss, ist das eher nichts
für mich, wegen der Verzögerung.

Da die Browser ja eine Rückfallebene haben, sprich
einen anderen Font benutzen, falls die geforderte
Schriftart nicht vorhanden sein sollte, fahre ich - glaube
ich - ganz gut damit, die gängigsten Schriften zu
benutzen. Und da bin ich wieder am Anfang meiner
Frage, denn genau danach habe ich gefragt. Warum
diskutiert man immer 'drumherum' so wie Volker?

mfg Gerd

[Volker Gringmuth]

G.Bundschuh wrote:

> ich - ganz gut damit, die gängigsten Schriften zu
> benutzen. Und da bin ich wieder am Anfang meiner
> Frage, denn genau danach habe ich gefragt. Warum
> diskutiert man immer 'drumherum' so wie Volker?

Inwiefern ist es „drumherum“, wenn ich dir auf deine Frage, bei welchen
Schriftarten man davon ausgehen kann, daß sie auf jedem System
installiert sind, ganz geradeaus und wahrheitsgemäß antworte, daß man das
bei überhaupt keinen kann?

Daß es Fallbacks gibt, ist klar, es steht in meiner von dir so furchtbar
gefundenen Antwort übrinx auch drin:

| Macs und Linuxe müssen die schon durch eine ähnliche Schriftart aus dem
| eigenen Bestand ersetzen.

Nochmal ohne Drumherum (stand aber auch schon in meinem letzten Posting):

Arial, Tahoma, Verdana etc. gibts per Default nur auf Windosen.
Helvetica gibts per Default nur auf Macs.
Linux-Distributionen verwenden ganz unterschiedliche Sans-Serif-Schriften
als Default, von Nimbus Sans L über DejaVu Sans bis Ubuntu (ja, das ist auch
eine Schrift).

Es gibt eine freie Schrift namens „Liberation“ mit Arial-gleicher Metrik, so
daß gegenüber Arial keine Umbrüche verrutschen. Aber du kannst nicht davon
ausgehen, daß die Besucher deiner Seite die installiert haben. Sie sieht
IMHO auch furchtbar aus.

Bevor du die Möglichkeiten jetzt alle aufzählst, schreib doch einfach
„font-family:sans-serif“ rein, und Ruhe ist.

Deine Reaktion hat was von „wasch mir den Pelz, aber mach mich nicht naß“.


vG

[Peter Mueller]

G.Bundschuh schrieb am 20.04.2012 08:09:
> Holger Marzen schrieb:
>
>> Schau Dich mal bei google.de/webfonts um. Nur so klappt
>> das mit bestimmten Fonts.
>
> Danke Holger, danke auch an Arno, der mir ebenfalls
> diesen Tip gegeben hat. Wenn sich der Browser aber
> erst die Schrift runterladen muss, ist das eher nichts
> für mich, wegen der Verzögerung.
>
> Da die Browser ja eine Rückfallebene haben, sprich
> einen anderen Font benutzen, falls die geforderte
> Schriftart nicht vorhanden sein sollte, fahre ich - glaube
> ich - ganz gut damit, die gängigsten Schriften zu
> benutzen.

Mit den üblichen Einschränkungen:
http://www.codestyle.org/css/font-family/sampler-WindowsResults.shtml
http://www.codestyle.org/css/font-family/sampler-MacResults.shtml
http://www.codestyle.org/css/font-family/sampler-UnixResults.shtml

Und da bin ich wieder am Anfang meiner
> Frage, denn genau danach habe ich gefragt. Warum
> diskutiert man immer 'drumherum' so wie Volker?

Volker hat das schon richtig dargestellt finde ich. Nimm's dir zu Herzen!

Grüße,

Peter

[Arno Welzel]

Am 19.04.2012 21:50, schrieb G.Bundschuh:

> Volker Gringmuth schrieb:
>
>> Wenn du das Layout selbst festlegen willst, ist HTML das flchsae
>> Werkzeug,
>> und du solltest PDF nehmen.
>
> 1. Das ist mir jetzt zu katholisch. HTML ist schließlich dazu da,
> die Ausgabe zu steuern. Sonst könnte man nämlich auch eine

Nein, CSS ist dazu da. HTML definiert die *Struktur* eines Dokuments.
Wie aber der jeweilige Client die Struktur letzlich darstellt, ist
nirgends vorgeschrieben.

> reine *.txt Datei nehmen, nicht wahr? Ich denke, html liegt irgendwo
> zwischen PDF und TXT, gell?

Es gibt Menschen, die benutzen Screenreader, eben weil sie mit der
schönen Optik so gar nichts anfangen können.

> 2. Wäre Deine Ansicht die wahre Lehre, würde HTML die
> Optionen nicht bieten. Da bin ich mir ganz sicher.

Tut es ja auch nicht. Die Optionen bietet CSS. Und auch CSS ist keine
*zwingende* Vorgabe, sondern eher ein Vorschlag an den Client, dass man
es gerne so hätte - ob das aber dann auch wirklich beachtet wird, ist
ebenfalls nicht garantiert.

Deshalb wohl die Anmerkung "Layout geht nicht mit HTML" - man hat *nie*
eine Garantie dafür, dass die eigenen Layout-Vorstellungen auf jedem
Gerät exakt so umgesetzt werden.

> 3. Ziehe ich meine Frage zurück. Mich erwartet hier nix.

Wieso? Die Information, dass Schriftarten als *wesentliches*
Unterscheidungsmerkmal für unterschiedliche Textabschnitte keine gute
Idee sind, ist doch eine hilfreiche Information?

Stell' Dir mal vor, Du würdest für Fliesstext "Arial" und "Tahoma"
vorgeben und für Kommentare als *einzige* Unterscheidung eine andere
Schriftart, wie z.B. "Verdana".

Nun kommt jemand mit einem Mac, auf dem die Schriften allesamt nicht
existieren - der sieht dann schlicht keinerlei Unterschied, weil alles
einheitlich ohne unterschiedliche Schriften erscheint.

Deshalb mein Hinweis, dass man *statt* unterschiedlicher Schriften
bessere *andere* Unterscheidungsmerkmale verwendet.

[Arno Welzel]

Am 20.04.2012 08:09, schrieb G.Bundschuh:
> Holger Marzen schrieb:
>
>> Schau Dich mal bei google.de/webfonts um. Nur so klappt
>> das mit bestimmten Fonts.
>
> Danke Holger, danke auch an Arno, der mir ebenfalls
> diesen Tip gegeben hat. Wenn sich der Browser aber
> erst die Schrift runterladen muss, ist das eher nichts
> für mich, wegen der Verzögerung.
>
> Da die Browser ja eine Rückfallebene haben, sprich
> einen anderen Font benutzen, falls die geforderte
> Schriftart nicht vorhanden sein sollte, fahre ich - glaube
> ich - ganz gut damit, die gängigsten Schriften zu
> benutzen. Und da bin ich wieder am Anfang meiner

Und es gibt eben nicht die "gängigen" Schriften. Rechne einfach damit,
Schriften schlicht *nie* exakt funktionieren und deshalb nicht als
*wesentliches* Merkmal für optische Kennzeichnung von Textabschnitten taugt.

Wenn Du jetzt z.B. die "gängigen" Schriften von Windows XP bis 7 nimmst
und die von MacOS X und evtl. noch Ubuntu Linux - dann kommt jemand mit
iPad oder einem Android-Tablet und in ein paar Monaten Windows 8. Und
bei Android gibt es nur eine serifenlose Schrift, AFAIK beim iPad auch.

[Wolfgang Bauer]

Holger Marzen schrieb:

> Jeder hat das Recht, gegen gängige Typographieregeln zu verstoßen. Schau
> Dich mal bei google.de/webfonts um. Nur so klappt das mit bestimmten
> Fonts. Selbst Arial muss nicht auf jedem Rechner installiert sein,
> geschweige denn Tahoma.

Warum überhaupt Fonts vorgeben? Welche Fonts der Betrachter auf seinem
System installiert hat oder welche Schriftarten und -größen er bei sich
im Browser eingestellt hat, dementsprechend sieht er die Sites.

Wolfgang
--
Das 40tude Dialog Skript - Archiv! http://kh-rademacher.de/4d/
Die 40tude-Dialog FAQ http://www.wolfgang-bauer.at/4td_faq/
http://www.wolfgang-bauer.at

[Volker Gringmuth]

Wolfgang Bauer wrote:

> Warum überhaupt Fonts vorgeben? Welche Fonts der Betrachter auf seinem
> System installiert hat oder welche Schriftarten und -größen er bei sich
> im Browser eingestellt hat, dementsprechend sieht er die Sites.

Das hab ich ja schon darzustellen versucht, kam nicht besonders gut an.


vG

[Volker Gringmuth]

G.Bundschuh wrote:

> 1. Das ist mir jetzt zu katholisch.

Was heißt das bei dir?

> HTML ist schließlich dazu da, die Ausgabe zu steuern.

Dafür ist eher CSS da.

> Sonst könnte man nämlich auch eine reine *.txt Datei nehmen, nicht wahr?
> Ich denke, html liegt irgendwo zwischen PDF und TXT, gell?

Sorry, wenn ich nicht schon wieder drumherumrede, aber dir fehlen da
gedanklich noch einige Grundlagen.

Das M in HTML steht für „Markup“. Die leicht verunglückte deutsche
Entsprechung dazu lautet „Auszeichnung“. Das bedeutet: An jeden Bestandteil
einer Textdatei wird dabei eine Etikett gehängt, der sagt, was dieser
Bestandteil ist: eine Überschrift, ein Tabelleninhalt, ein Textabsatz oder
sonstwas. Der Grundgedanke von HTML (wie auch jedes anderen SGML-Dialekts)
besteht darin, die Struktur eines Dokumentes abzubilden.

CSS ergänzt diese zunächst abstrakte Strukturierung um konkrete
Gestaltungsvorgaben, deren Umsetzung natürlich vom Ausgabesystem abhängt.
Das ist bewußt so aufgebaut, daß jedes Dokument auf jedem System irnkwie
funktioniert, aber nicht zwangsläufig überall gleich aussehen muß. Denk mal
an Textbrowser, an Monochrombildschirme, an Braillezeilen :-)

PDF macht etwas vollkommen anderes. Dem PDF sind die Funktionen der
jeweiligen Textelemente vollkommen wurscht, es setzt Element für Element
entweder pixelweise oder anhand einer mathematischen Beschreibung
neben- und übereinander, und das so, daß es auf jedem Ausgabesystem
gleich aussieht.

> 2. Wäre Deine Ansicht die wahre Lehre, würde HTML die
> Optionen nicht bieten. Da bin ich mir ganz sicher.

Was für Optionen meinst du? Die Vorgabe einer Schriftfamilie? Inwiefern
widerspricht das meiner Ansicht? Diese Vorgaben verstehen sich als
Vorschlag und sind für das Zielsystem niemals bindend. Ich habe dir daher
gesagt, daß es wenig Sinn hat, konkrete Schriftarten vorzugeben. Diese
Option, die du offenbar suchst, wird von HTML so nicht erfüllt, also kann
man kaum von „bieten“ sprechen.

> 3. Ziehe ich meine Frage zurück. Mich erwartet hier nix.

Wenn du nur deine Ansichten bestätigt und deine Fragen beantwortet haben
willst, dann erwartet dich hier nix.

Wenn du dich aber mit anderen Ansichten auseinandersetzen und eine
für alle Seiten fruchtbare Diskussion führen willst, dann doch.


vG

[Wolfgang Bauer]

Volker Gringmuth schrieb:

Ich kenne mich mit der Materie wirklich nicht gut aus. Was ich aber
begriffen habe, keine festen Vorgaben machen. Keinen Font, kein
font-size.

Andere Werte wie margin, padding, width habe ich so eingerichtet, daß es
bei mir im Browserfenster mit 1024px breite halbwegs paßt. Wie es auf
einem iPod, Ipad oder auf einem maximierten 28 Zoll Monitor aussieht
kann ich nicht beurteilen.

[Helmut Richter]

On Fri, 20 Apr 2012, Arno Welzel wrote:

> Es gibt Menschen, die benutzen Screenreader, eben weil sie mit der schönen
> Optik so gar nichts anfangen können.

So wie ich zum E-Mail-Lesen Alpine verwende, um nicht von der "schönen"
Optik genervt zu werden. Aber das ist wohl atypisch.

> Stell' Dir mal vor, Du würdest für Fliesstext "Arial" und "Tahoma" vorgeben
> und für Kommentare als *einzige* Unterscheidung eine andere Schriftart, wie
> z.B. "Verdana".
>
> Nun kommt jemand mit einem Mac, auf dem die Schriften allesamt nicht
> existieren - der sieht dann schlicht keinerlei Unterschied, weil alles
> einheitlich ohne unterschiedliche Schriften erscheint.
>
> Deshalb mein Hinweis, dass man *statt* unterschiedlicher Schriften bessere
> *andere* Unterscheidungsmerkmale verwendet.

Wenn die Browser typographisch ordentlich arbeiten würden -- was wohl kaum
einer tut --, würden sie zu einer Serifenschrift die dazu *passende*
Sans-serif-Schrift und die *passende* Kursivschrift auswählen, wenn man
nur diese Vorgaben macht. Das kriegt man gar nicht hin, wenn man nicht
weiß, welche Schriften beim Leser vorhanden sind.

Für mich ist das übrigens ein Grund, Serifenschriften als Brotschriften zu
verwenden: dann hat man Kursiv als ordentliche Auszeichnung zur Verfügung,
während die Kursivschrift zu einer Sans-Serif-Schrift oft nur dasselbe ein
wenig schräggestellt ist.

--
Helmut Richter

[Andreas Prilop]

On Fri, 20 Apr 2012, Volker Gringmuth wrote:

> Arial, Tahoma, Verdana etc. gibts per Default nur auf Windosen.
> Helvetica gibts per Default nur auf Macs.

Deine Informationen stammen noch von Mac OS 9.
Sieh Dir mal “Appendix B: Mac OS X Fonts” in
http://images.apple.com/pro/pdf/L311277A_FontTT_v4.pdf
an.

--
 Solange Tölpel wie Hauke ‘?’ Reddmann durchs Usenet stolpern‚
 ist kein Umlaut sicher.                                      

[Arno Welzel]

Am 20.04.2012 13:44, schrieb Wolfgang Bauer:
> Volker Gringmuth schrieb:
>> Wolfgang Bauer wrote:
>
>>> Warum überhaupt Fonts vorgeben? Welche Fonts der Betrachter auf seinem
>>> System installiert hat oder welche Schriftarten und -größen er bei sich
>>> im Browser eingestellt hat, dementsprechend sieht er die Sites.
>
>> Das hab ich ja schon darzustellen versucht, kam nicht besonders gut an.
>
> Ich kenne mich mit der Materie wirklich nicht gut aus. Was ich aber
> begriffen habe, keine festen Vorgaben machen. Keinen Font, kein
> font-size.
>
> Andere Werte wie margin, padding, width habe ich so eingerichtet, daß es
> bei mir im Browserfenster mit 1024px breite halbwegs paßt. Wie es auf
> einem iPod, Ipad oder auf einem maximierten 28 Zoll Monitor aussieht
> kann ich nicht beurteilen.

Deswegen gibt es die CSS-Regel max-width. Hier sollte man möglichst auch
nicht einen px-Wert verwenden, sondern em als Einheit - denn
entscheidend ist nicht die Anzahl der Pixel, sondern die Länge der
Textzeilen. Wenn der Benutzer weniger Platz hat, werden Elemente, die
mit max-width auf eine maximale Breite begrenzt werden, ggf. auch
schmaler, wenn nötig.

[Volker Gringmuth]

Andreas Prilop wrote:

> On Fri, 20 Apr 2012, Volker Gringmuth wrote:
>
> > Arial, Tahoma, Verdana etc. gibts per Default nur auf Windosen.
> > Helvetica gibts per Default nur auf Macs.
>
> Deine Informationen stammen noch von Mac OS 9.
> Sieh Dir mal “Appendix B: Mac OS X Fonts” in
> http://images.apple.com/pro/pdf/L311277A_FontTT_v4.pdf
> an.

Dann ändere ich das in „Helvetica gibt’s per Default nur auf älteren Macs“.
Zufrieden?


vG

[Andreas Prilop]

On Fri, 20 Apr 2012, Volker Gringmuth wrote:

>> http://images.apple.com/pro/pdf/L311277A_FontTT_v4.pdf

>
> Dann ändere ich das in „Helvetica gibt’s per Default nur auf älteren Macs“.
> Zufrieden?

Vollständig befriedigt. :-)

--
Ich habe bei Ikea die Klobrille “Obszøn” gekauft und bin sehr befriedigt.

[Volker Gringmuth]

Andreas Prilop wrote:

> Ich habe bei Ikea die Klobrille “Obszøn” gekauft und bin sehr befriedigt.

Ob’s szøn ist, liegt im Auge (oder auch woanders) des Betrachters.


vG

[Wolfgang Bauer]

Arno Welzel schrieb:

body {
width:60em;
font-size: 100%;
line-height: 1.2em;
margin: auto;
margin: auto;
............;

[Arno Welzel]

Wolfgang Bauer, 2012-04-20 22:11:

> Arno Welzel schrieb:
>> Am 20.04.2012 13:44, schrieb Wolfgang Bauer:
>
>>> Andere Werte wie margin, padding, width habe ich so eingerichtet, daß es
>>> bei mir im Browserfenster mit 1024px breite halbwegs paßt. Wie es auf
>>> einem iPod, Ipad oder auf einem maximierten 28 Zoll Monitor aussieht
>>> kann ich nicht beurteilen.
>
>> Deswegen gibt es die CSS-Regel max-width. Hier sollte man möglichst auch
>> nicht einen px-Wert verwenden, sondern em als Einheit - denn
>> entscheidend ist nicht die Anzahl der Pixel, sondern die Länge der
>> Textzeilen. Wenn der Benutzer weniger Platz hat, werden Elemente, die
>> mit max-width auf eine maximale Breite begrenzt werden, ggf. auch
>> schmaler, wenn nötig.
>
> body {
> width:60em;
> font-size: 100%;
> line-height: 1.2em;
> margin: auto;
> margin: auto;
> ............;
> }

Und wenn der Benutzer ein Gerät benutzt, dass weniger als 60em in der
Breite anzeigen kann, muss er horizontal scrollen.

Ja - barrierefreies Layout mit CSS ist mitunter mühselig. Aber man
sollte immer im Kopf haben, dass man keine bestimmten Auflösungen und
keine bestimmten Schriften oder Schriftgrößen voraussetzen kann.

[Thomas 'PointedEars' Lahn]

Wolfgang Bauer wrote:

> Arno Welzel schrieb:
>> Am 20.04.2012 13:44, schrieb Wolfgang Bauer:
>>> Andere Werte wie margin, padding, width habe ich so eingerichtet, daß es
>>> bei mir im Browserfenster mit 1024px breite halbwegs paßt. Wie es auf
>>> einem iPod, Ipad oder auf einem maximierten 28 Zoll Monitor aussieht
>>> kann ich nicht beurteilen.
>
>> Deswegen gibt es die CSS-Regel max-width. Hier sollte man möglichst auch
>> nicht einen px-Wert verwenden, sondern em als Einheit - denn
>> entscheidend ist nicht die Anzahl der Pixel, sondern die Länge der
>> Textzeilen. Wenn der Benutzer weniger Platz hat, werden Elemente, die
>> mit max-width auf eine maximale Breite begrenzt werden, ggf. auch
>> schmaler, wenn nötig.
>
> body {
> width:60em;

Kann man machen. Sinnvoller: 60ex.

> font-size: 100%;

Bewirkt gar nichts.

> line-height: 1.2em;

Kann man machen.

> margin: auto;
> margin: auto;

Doppeltgemoppelt.

> ............;

Soll'n das?

> }11.62

Weshalb postest Du das?


PointedEars
--
> Einfach die xml Tags durch html Code ersetzen und gut...
Lass es mich so sagen: Die dunkle Seite gewählt Du hast. Den schnellen
Erfolg Du suchst, aber auf die Füsse fallen die Komplexität Dir wird.
Unterschätze nemals die Bugs der dunklen Seite! -- Geggo in fcc

[Martin Schilling]

Moin,

Thomas 'PointedEars' Lahn schrieb:

> Wolfgang Bauer wrote:
>> body {
>> width:60em;
>
> Kann man machen. Sinnvoller: 60ex.

-v bitte.
Ich dachte, ex wäre für senkrechte, em für waagerechte Maße?

Martin.

[Wolfgang Bauer]

Thomas 'PointedEars' Lahn schrieb:
> Wolfgang Bauer wrote:

>> font-size: 100%;
>
> Bewirkt gar nichts.

Na klar bewirkt das etwas. Es zeigt die Schrift in voller Größe an die
der User in seinem Browser eingestellt hat.

>> margin: auto;
>> margin: auto;
>
> Doppeltgemoppelt.

Ist schon lange raus.

>> ............;
>
> Soll'n das?

Da folgen noch weitere Einträge die ich nicht gepostet habe.

>
>> }11.62
>
> Weshalb postest Du das?

Wo habe ich das gepostet?

Mit freundlichen Grüßen
Wolfgang Bauer
--

Die 40tude-Dialog FAQ http://www.wolfgang-bauer.at/4td_faq/

Raady's 40tude-Dialog - Archiv! http://kh-rademacher.de/4d/
http://www.wolfgang-bauer.at

[Susanne Jäger]

öhm ... nein. beides kannst du für alle Richtungen verwenden.

"Relative units are:
em: the 'font-size' of the relevant font
ex: the 'x-height' of the relevant font"
<http://www.w3.org/TR/CSS2/syndata.html#length-units>

wobei ex als ich das letzte Mal getestet habe etwa 1/2 em war -
unabhängig von der tatsächlich verwendeten Schriftart. Ich bin mir nicht
sicher, ob sich da inzwischen was dran geändert hat.

Als Faustregel für Breitenangaben bei Proportionalschriften rechne ich
eigentlich immer mit 1em ~ 2 Zeichen, 1ex ~ 1 Zeichen. Thomas schlägt
also ungefähr eine Halbierung der ursprünglichen Angabe vor. Wobei mir
60ex als feste Breitenangabe für body ebensowenig gefallen würde wie
60em, aber das ist jetzt noch mal eine andere Frage.

Gruß
Susanne

[Thomas 'PointedEars' Lahn]

Wolfgang Bauer wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Wolfgang Bauer wrote:
>>> font-size: 100%;
>> Bewirkt gar nichts.
>
> Na klar bewirkt das etwas. Es zeigt die Schrift in voller Größe an die
> der User in seinem Browser eingestellt hat.

100% ist eine *relative* Grössenangabe. Relativ zur Schriftgrösse, die der
Benutzer in seinem Programm eingestellt hat. Genauer: Relativ zur font-size
des nächsten Vorfahren, für den font-size definiert ist; in der Regel ist
dieser Vorfahre das `HTML'-Element, dessen font-size über das Browser- oder
User-Stylesheet definiert wird.

100% eines Kuchens *sind* der Kuchen. Diese Eigenschaftsdeklaration bewirkt
also *nichts*, genau so wie auch `font-size: 1em'.

<http://www.w3.org/TR/CSS21/fonts.html#propdef-font-size>

>>> ............;
>>
>> Soll'n das?
>
> Da folgen noch weitere Einträge die ich nicht gepostet habe.
>>
>>> }11.62
>>
>> Weshalb postest Du das?
>
> Wo habe ich das gepostet?

Abgesehen von "11.62" (versehentliches Copypaste meinerseits) hast Du das
genau so in <news:200412.221143....@wolfgang-bauer.at> gepostet.


PointedEars
--
Lass es mich so ausdrücken: Eigentlich werde ich keine Zeit haben, aber die
fürs Usenet übliche nehme ich mir. Nähme ich mir noch zusätzlich was vor,
würde ich womöglich das tun, um nicht das, das ich tun sollte, tun zu
müssen.
(Christoph Päper in <darw/> <avl5ul$30fp$1...@ariadne.rz.tu-clausthal.de>)

[Volker Gringmuth]

Wolfgang Bauer wrote:

> >> font-size: 100%;
> >
> > Bewirkt gar nichts.
>
> Na klar bewirkt das etwas. Es zeigt die Schrift in voller Größe an die
> der User in seinem Browser eingestellt hat.

Nein, sondern in 100 Prozent der Größe, die für das übergeordnete Element
festgelegt ist. In diesen Sheets werden die Styles cascadet, also
hintereinandergeschaltet.

Und wenn man es nicht hinschriebe, font-size also gar nicht definierte, in
welcher Größe würde es dann angezeigt?

Richtig: In der Größe, die für das übergeordnete Element festgelegt ist. In
diesen Sheets werden nämlich die Styles cascadet, also
hintereinandergeschaltet.


vG

[Wolfgang Bauer]

Thomas 'PointedEars' Lahn schrieb:
> Wolfgang Bauer wrote:

> 100% ist eine *relative* Grössenangabe. Relativ zur Schriftgrösse, die der
> Benutzer in seinem Programm eingestellt hat.

Ja klar, habe ich doch geschrieben.

> Genauer: Relativ zur font-size des nächsten Vorfahren, für den
> font-size definiert ist; in der Regel ist dieser Vorfahre das
> `HTML'-Element, dessen font-size über das Browser- oder
> User-Stylesheet definiert wird.

Im HTML Element ist keine font-size angegeben. Auch in den stylesheets
nicht. (bei mir jedenfalls)

>
> 100% eines Kuchens *sind* der Kuchen. Diese Eigenschaftsdeklaration

> bewirkt also *nichts*, ...

font-site:100% bewirkt, daß die Schrift in der Größe (Thomas
'PointedEars' Lahn) "die der Benutzer in seinem Programm eingestellt
hat" angezeigt wird.

> ... genau so wie auch `font-size: 1em'.

font-size: 1em ist eine absolute Größe.

>> Wo habe ich das gepostet?
>
> Abgesehen von "11.62" (versehentliches Copypaste meinerseits) hast Du das
> genau so in <news:200412.221143....@wolfgang-bauer.at> gepostet.

Das habe ich wohl schon erklärt. Ich habe aus dem Abschnitt body nur das
in der Antwort auf Arno Welzel relavante geschrieben.

Das
............;
um anzudeuten, daß da noch mehr drin steht und
}

weil das der Abschluß des body Abschnittes ist.

[Wolfgang Bauer]

Volker Gringmuth schrieb:
> Wolfgang Bauer wrote:

>> Na klar bewirkt das etwas. Es zeigt die Schrift in voller Größe an die
>> der User in seinem Browser eingestellt hat.
>
> Nein, sondern in 100 Prozent der Größe, die für das übergeordnete Element
> festgelegt ist.

Du hast recht wenn im übergeordneten Element eine Schriftgröße angegeben
ist. Habe ich in /meinen/ HTML Elementen aber nicht. Für den Betrachter
meiner Sites ist das übergeordnete Element sein Browser bzw. der
Zoomfaktor den er einstellt.

[Volker Gringmuth]

Wolfgang Bauer wrote:

> Du hast recht wenn im übergeordneten Element eine Schriftgröße angegeben
> ist. Habe ich in /meinen/ HTML Elementen aber nicht. Für den Betrachter
> meiner Sites ist das übergeordnete Element sein Browser bzw. der
> Zoomfaktor den er einstellt.

Richtig.

Und wenn du die 100-Prozent-Angabe wegläßt, ist exakt dasselbe der Fall,
da ja, wie du sagst, in den übergeordneten Elementen keine Größe
angegeben wird.


vG

[Wolfgang Bauer]

Volker Gringmuth schrieb:

Beziehen sich aber die 100% nicht auf die Schriftgröße die der
Betrachter in seinem Browser eingstellt hat? Ich habe im Firefox
Schriftgröße 16 eingestellt.

Wenn in der style.css dann font-size: 100% angegeben ist wird bei mir
der Text in Schriftgröße 16 angezeigt. Ein User mir Sehhschwäche hat
vielleicht in seinem Browser Größe 18 eingestellt und sieht die Schrift
dann in Größe 18. Wenn ich keine Schriftgröße in % angebe muß derjenige
den Zoomfaktor bei sich ändern. Oder sehe ich das falsch?

[Volker Gringmuth]

Wolfgang Bauer wrote:

> Beziehen sich aber die 100% nicht auf die Schriftgröße die der
> Betrachter in seinem Browser eingstellt hat?

Nein, wie schon wiederholt gesagt, sondern auf die Schriftgröße des
übergeordneten Elements.


vG

[Wolfgang Bauer]

Volker Gringmuth schrieb:

Ich bin zu sehr gefangen in dem was ich da produziert habe.
Dann kann ich demnach die Angabe der font-size ganz rausnehmen.
(habe ich schon mal gemacht)

[Thomas 'PointedEars' Lahn]

Die CSS-Einheit `em' bezieht sich auf die Breite des Gevierts aus dem
Letterndruck übertragen auf elektronische Schriften. Diese entspricht dort
*ungefähr* der Breite des breitesten Buchstabens eines Schrift (der auf
einer Letter Platz finden muss), i. d. R. des des grossen "M" (daher eben
"em") [1, 2]. (Ungefähr AIUI, weil das gedruckte Zeichen nicht exakt an den
Grenzen des Gevierts endet. CMIIW.)

In einem herkömmlichen Fliesstext gibt es jedoch immer mehr Minuskeln
(Kleinbuchstaben) als Majuskeln (Grossbuchstaben) [3a]; durchschnittlich
gibt es in englischsprachigen Texten etwa zweimal so viele Minuskeln wie
Majuskeln [3b]. Ausserdem kann die tatsächliche Breite von Majuskeln stark
von denen von Minuskeln und anderen Zeichen (z. B. Interpunktionszeichen)
abweichen.

Die Einheit `ex' als "x-height", d. h. die Höhe des kleinen "x", eignet sich
deshalb IMHO besser dafür, eine CSS-Länge (hier: Textbreite) anzugeben, die
sich ungefähr nach der *Anzahl* der Zeichen in einer Zeile bemisst (das
kleine "x" ist zumindest bei für Fliesstext geeigneten Schriftschnitten
ungefähr so breit wie hoch).

Denn durchschnittlich 60 bis 70 Zeichen in einer Zeile Fliesstext ist die
typographische Empfehlung (vgl. Printmedien) [4a] (vgl. [4b, 4c]).
Inzwischen wird die CSS-Einheit `ex' auch weithin unterstützt, so dass man
diese Einheit zumindest für die Maximalbreite von Fliesstext ohne Bedenken
verwenden kann. Für ältere Browser kann (muss aber nicht) ein Fallback
eingebaut werden, z. B.

foo>bar {
width: 30em;
}

bar {
width: auto;
max-width: 60ex;
}

Basierend auf einem Ansatz von Andreas Borutta [5] habe ich das bei der
ECMAScript Support Matrix [6] nur für Abschnitte von Fliesstext (DIV-
Elemente) umgesetzt –

div, ul, ol, th, td {
max-width: 60ex;
}

– (sieht man z. B. im Abschnitt "Foreword and Rationale") und ich finde, es
hat (genau so wie auch der grössere Zeilenabstand) die Lesbarkeit des
Dokuments im Vergleich zu vorher deutlich verbessert. Siehe auch [7].


HTH

PointedEars
___________
[1] [de] <http://de.wikipedia.org/wiki/Geviert_(Typografie)>
[2] [en] <http://en.wikipedia.org/wiki/Em_(typography)>
[3a] <http://www.volcanokit.com/volcanokit3/ligCounter/>
[3b] Jones, M. und Mewhort, D. (2004). “Case-sensitive letter and bigram
frequency counts from large-scale English corpora”. In: Behavior
Research Methods 36(3). S. 388–396. New York: Springer.
ISSN: 1554-351X. DOI: 10.3758/BF03195586.
URL: <http://dx.doi.org/10.3758/BF03195586> (abgerufen: 2012-04-25).
[4a] <news:hjdc0g$r1v$1...@news.m-online.net>
[4b] Koeberlin, C. (2012). Typefacts – Typografie verstehen.
Zeilenlänge (Satzbreite).
<http://typefacts.com/artikel/grundlagen/zeilenlaenge>
(abgerufen: 2012-04-25).
[4c] Bier, C. (2009). typokurz – Einige wichtige typografische Regeln.
Version 1.7. S. 7.
<http://zvisionwelt.files.wordpress.com/2012/01/typokurz.pdf>
(abgerufen: 2012-04-25).
Siehe auch: <http://zvisionwelt.wordpress.com/downloads/#typokurz>.
[5a] <news:3051258.a...@PointedEars.de>, BTW auch sonst ein
interessanter Thread; einiges von dem dort Diskutierten könnte man
inzwischen mit CSS Media-Queries [5b] lösen.
[5b] <http://www.w3.org/TR/2010/CR-css3-mediaqueries-20100727/>
[6] <http://PointedEars.de/es-matrix> (2012-03-08T20:24:41+00:00)
[7] <news:2981914.S...@PointedEars.de>
--
Wenn Dein Browser apply nicht kennt, dann mußt Du den Browser wechseln.
Man kann den Appendix nicht mit dem Bulldozer operieren und sich dann
über ausgefranzte Narben beklagen, obwohl bekannt ist, daß dafür
chirurgisches Besteck erforderlich ist. -- Georg Maaß in dcljs

[Thomas 'PointedEars' Lahn]

Wolfgang Bauer wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Wolfgang Bauer wrote:
>> 100% ist eine *relative* Grössenangabe. Relativ zur Schriftgrösse, die
>> der Benutzer in seinem Programm eingestellt hat.
>
> Ja klar, habe ich doch geschrieben.
>
>> Genauer: Relativ zur font-size des nächsten Vorfahren, für den
>> font-size definiert ist; in der Regel ist dieser Vorfahre das
>> `HTML'-Element, dessen font-size über das Browser- oder
>> User-Stylesheet definiert wird.
>
> Im HTML Element ist keine font-size angegeben. Auch in den stylesheets
> nicht. (bei mir jedenfalls)

Was genau heisst "bei [Dir]"?

>> 100% eines Kuchens *sind* der Kuchen. Diese Eigenschaftsdeklaration
>> bewirkt also *nichts*, ...
>
> font-site:100% bewirkt, daß die Schrift in der Größe (Thomas
> 'PointedEars' Lahn) "die der Benutzer in seinem Programm eingestellt
> hat" angezeigt wird.

Ja. Und wenn Du die Angabe weglässt, ändert sich genau nichts an der
Darstellung, weil 100% vom Kuchen nun einmal der ganze Kuchen sind.

>> ... genau so wie auch `font-size: 1em'.
>
> font-size: 1em ist eine absolute Größe.

Nein, es ist eine *relative* Längenangabe, siehe die bereits referenzierte
CSS-2.1-Spezifikation. Konkret: 1em == 100%.

>>> Wo habe ich das gepostet?
>>
>> Abgesehen von "11.62" (versehentliches Copypaste meinerseits) hast Du das
>> genau so in <news:200412.221143....@wolfgang-bauer.at>
>> gepostet.
>
> Das habe ich wohl schon erklärt.

Wo?

> Ich habe aus dem Abschnitt body nur das in der Antwort auf Arno Welzel
> relavante geschrieben.

Ich kann aber keine Relevanz darin erkennen. Arno hat über `max-width'
geschrieben; Du postest daraufhin CSS-Code, der keine `max-width'-
Deklaration enthält.

> Das
> ............;
> um anzudeuten, daß da noch mehr drin steht […]

… ist überflüssig (da hier irrelevant) bzw. sollte wenn überhaupt mit
Kommentaren (und optimal einem Auslassungszeichen statt drei Punkten)
angedeutet werden:

/* … */

Andernfalls ist das gepostete Stylesheet syntaktisch ungültig und kann nicht
zum Testen ohne weitere (fehlerträchtige) Anpassung verwendet werden.

[Susanne Jäger]

Wolfgang Bauer wrote:
> Volker Gringmuth schrieb:
>> Wolfgang Bauer wrote:
>>
>>> Beziehen sich aber die 100% nicht auf die Schriftgröße die der
>>> Betrachter in seinem Browser eingstellt hat?
>>
>> Nein, wie schon wiederholt gesagt, sondern auf die Schriftgröße des
>> übergeordneten Elements.

und wenn es das nicht gibt (<html>) auf den Ausgangswert (initial value)
und das ist in diesem Fall die im Browser eingestellte Schriftgröße,
zumindest praktisch gilt das auch für body.

> Ich bin zu sehr gefangen in dem was ich da produziert habe.
> Dann kann ich demnach die Angabe der font-size ganz rausnehmen.
> (habe ich schon mal gemacht)

Wobei ich nicht verstehe, warum sich einige hier so über ~20 Zeichen
aufregen. Heutzutage ist es vermutlich wirklich egal, ob man font-size:
100% für body oder html spezifiziert oder nicht, wenn du keine weiteren
Schriftgrößen ableitest (für Überschriften, Bildunterschriften oder was
auch immer). Historisch gesehen war es durchaus sinnvoll html, body
{font-size: 100%;} explizit ins CSS zu schreiben , weil ältere IEs auf
das Fehlen einer %-basierten font-size Angabe als Bezugsgröße mit Chaos
- meist mikroskopisch kleine Schriften reagieren konnten. Ich schreibe
es routinemäßig immer noch rein, schaden tut es sicher nicht.

Gruß
Susanne

[Thomas 'PointedEars' Lahn]

Susanne Jäger wrote:

> Wolfgang Bauer wrote:
>> Volker Gringmuth schrieb:
>>> Wolfgang Bauer wrote:
>>>> Beziehen sich aber die 100% nicht auf die Schriftgröße die der
>>>> Betrachter in seinem Browser eingstellt hat?
>>> Nein, wie schon wiederholt gesagt, sondern auf die Schriftgröße des
>>> übergeordneten Elements.
>
> und wenn es das nicht gibt (<html>) auf den Ausgangswert (initial value)
> und das ist in diesem Fall die im Browser eingestellte Schriftgröße,
> zumindest praktisch gilt das auch für body.

"Die im Browser eingestellte Schriftgrösse" definiert üblicherweise
(mindestens seit dem Release von IE 5) die Deklaration im User-Agent-
Stylesheet für das HTML/html- oder BODY-/body-Element. Sie kann noch durch
Benutzer-Stylesheets (z. B. userContent.css) überlagert werden und bildet
dann die Berechnungsbasis für Autoren-Stylesheets.

Die Deklarationen in diesen (teilweise dynamischen) Stylesheets kann man
sich mindestens in den Chromium/Chrome Developer Tools (Menü "Tools" oder
F12), Firebug (Menü oder F12) und den IE Developer Tools (IE 6+; Toolbar-
Icon oder F12) teilweise ansehen (in Chromium findet man leider keine
Angaben zur `font-size').

>> Ich bin zu sehr gefangen in dem was ich da produziert habe.
>> Dann kann ich demnach die Angabe der font-size ganz rausnehmen.
>> (habe ich schon mal gemacht)
>
> Wobei ich nicht verstehe, warum sich einige hier so über ~20 Zeichen
> aufregen.

^^^^^^^^
Du solltest nicht von Dir auf andere schliessen.

> […] Historisch gesehen war es durchaus sinnvoll html, body

> {font-size: 100%;} explizit ins CSS zu schreiben , weil ältere IEs auf
> das Fehlen einer %-basierten font-size Angabe als Bezugsgröße mit Chaos
> - meist mikroskopisch kleine Schriften reagieren konnten.

Mir ist das in 12 Jahren Webauthoring mit diversen Schriftarten, -grössen
und IE-Versionen noch nicht passiert. Was mache ich fchsal?

> Ich schreibe es routinemäßig immer noch rein, schaden tut es sicher nicht.

Redundante Angaben läppern sich auch zusammen. Sie machen das Stylesheet
unübersichtlicher und erhöhen die Wahrscheinlichkeit für Fehler bei der
Bearbeitung desselben.

Mir fällt grundsätzlich auf Anhieb kein Beispiel ein, wo Redundanz in der
Software-Entwicklung (Web-Entwicklung zähle ich dazu, Webauthoring als
Teildisziplin davon) einen positiven oder zumindest keinen negativen Effekt
hätte.


PointedEars
--
Von "funktionieren" kann also hier keine Rede sein. Ursache für Deinen
Irrtum ist wohl, dass auch Du annimmst, dass Ausprobieren von Spaghetticode
auf einem System oder wenigen Systemen ein sinnvoller Ersatz für saubere
Syntax und richtige Tests sei. -- Dietmar Meier in dcljs

[Stefan Froehlich]

On Wed, 25 Apr 2012 23:54:49 Thomas 'PointedEars' Lahn wrote:
> Mir fällt grundsätzlich auf Anhieb kein Beispiel ein, wo Redundanz in der
> Software-Entwicklung (Web-Entwicklung zähle ich dazu, Webauthoring als
> Teildisziplin davon) einen positiven oder zumindest keinen negativen
> Effekt hätte.

Kommentare?

SCNR,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Die Lust zu sein! Stefan, Trost in den Stunden des Zorns!
(Sloganizer)

[Volker Gringmuth]

Susanne Jäger wrote:

> weil ältere IEs auf das Fehlen einer %-basierten font-size Angabe als
> Bezugsgröße mit Chaos - meist mikroskopisch kleine Schriften reagieren
> konnten.

Dagegen hat man aber AFAIK 101% reingeschrieben, 100% war ihm zu wenig :-)


vG

[Susanne Jäger]

nee, die 101% waren AFAIK gegen einen Bug in irgendwelchen alten
Opera-Versionen und später wurden die dann wegen eines inzwischen wohl
auch ausgestorbenen Safari-Bugs zu 100.1%. Aber ich habe gerade nochmal
gesucht. Den IE-Bug gabs scheinbar bis Version 7, da bin ich mit meiner
überkommenen Vorsichtsmaßnahme doch nicht ganz so antiquiert wie ich
selbst schon befürchtet hatte. ;-)

<http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/EM-font-resizing-bug.html>
Zu der Opera/Safari-Arithmetik finde ich auf die Schnelle nur
unspezifische, aber durchweg ältere Randbemerkungen, ich bin mir aber
relativ sicher, dass diese Bugs inzwischen wirklich ausgestorben sind.

Gruß
Susanne

[Arno Welzel]

Wolfgang Bauer, 2012-04-25 16:47:

> Thomas 'PointedEars' Lahn schrieb:
>> Wolfgang Bauer wrote:
>
>>> font-size: 100%;
>>
>> Bewirkt gar nichts.
>
> Na klar bewirkt das etwas. Es zeigt die Schrift in voller Größe an die
> der User in seinem Browser eingestellt hat.

Das tut der Browser auch so - ganz ohne Vorgabe.

[Susanne Jäger]

Stefan Froehlich wrote:
> On Wed, 25 Apr 2012 23:54:49 Thomas 'PointedEars' Lahn wrote:
>> Mir fällt grundsätzlich auf Anhieb kein Beispiel ein, wo Redundanz in der
>> Software-Entwicklung (Web-Entwicklung zähle ich dazu, Webauthoring als
>> Teildisziplin davon) einen positiven oder zumindest keinen negativen
>> Effekt hätte.
>
> Kommentare?

Auch wenn das sicher theoretisch ist, fallen mir aus dem CSS-Bereich
spontan ein paar Beispiele ein, wo ich solche Redundanz bewusst einsetze
um bekannten Browserbugs nebenwirkungsfrei vorzubeugen.

* Das hier auslösende font-sizing Problem, inzwischen habe ich ja auch
eine Beschreibung gefunden. font-size: x%; wenn ich es kontrollieren
kann 100% für html oder body setze ich eigentlich immer ein.
<http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/EM-font-resizing-bug.html>

* display: inline; für Floats um dem double-margin-bug des IE
vorzubeugen. Häufig für Layouttragende Floats, sofern es kein spezielles
IE-Stylesheet gibt.
<http://positioniseverything.net/explorer/doubled-margin.html>

Beide sind für standardkonforme Browser nebenwirkungsfrei, vermeiden
aber Bugs, die schwer zu orten sind. Deswegen empfehle ich sie gerade
für weniger erfahrenen Autoren.

Etwas weiter gefasst könnte man auch noch zoom:1; (und das ist auch noch
nicht standardkonform) gegen das hasLayout-Problem in die Reihe packen.
Wobei man das wirklich nur gezielt einsetzen sollte, weil auch das
Vorhandensein von hasLayout negative Folgen haben kann.
<http://www.satzansatz.de/cssd/onhavinglayout.html>

Gruß
Susanne

[Thomas 'PointedEars' Lahn]

Susanne Jäger wrote:

> Stefan Froehlich wrote:
>> On Wed, 25 Apr 2012 23:54:49 Thomas 'PointedEars' Lahn wrote:
>>> Mir fällt grundsätzlich auf Anhieb kein Beispiel ein, wo Redundanz in
>>> der Software-Entwicklung (Web-Entwicklung zähle ich dazu, Webauthoring
>>> als Teildisziplin davon) einen positiven oder zumindest keinen negativen
>>> Effekt hätte.
>>
>> Kommentare?
>
> Auch wenn das sicher theoretisch ist, fallen mir aus dem CSS-Bereich
> spontan ein paar Beispiele ein, wo ich solche Redundanz bewusst einsetze
> um bekannten Browserbugs nebenwirkungsfrei vorzubeugen.
>
> * Das hier auslösende font-sizing Problem, inzwischen habe ich ja auch
> eine Beschreibung gefunden. font-size: x%; wenn ich es kontrollieren
> kann 100% für html oder body setze ich eigentlich immer ein.
> <http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/EM-font-resizing-
bug.html>

Interessant, danke. Ich werde das bei Gelegenheit überprüfen.

> * display: inline; für Floats um dem double-margin-bug des IE
> vorzubeugen. Häufig für Layouttragende Floats, sofern es kein spezielles
> IE-Stylesheet gibt.
> <http://positioniseverything.net/explorer/doubled-margin.html>
>
> Beide sind für standardkonforme Browser nebenwirkungsfrei, vermeiden
> aber Bugs, die schwer zu orten sind. Deswegen empfehle ich sie gerade
> für weniger erfahrenen Autoren.
>
> Etwas weiter gefasst könnte man auch noch zoom:1; (und das ist auch noch
> nicht standardkonform) gegen das hasLayout-Problem in die Reihe packen.
> Wobei man das wirklich nur gezielt einsetzen sollte, weil auch das
> Vorhandensein von hasLayout negative Folgen haben kann.
> <http://www.satzansatz.de/cssd/onhavinglayout.html>

Deine Logik ist fehlerhaft. Angaben, die etwas bewirken, sind gerade
_nicht_ redundant.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> […] Für ältere Browser kann (muss aber nicht) ein Fallback eingebaut

> werden, z. B.
>
> foo>bar {
> width: 30em;
> }
>
> bar {
> width: auto;
> max-width: 60ex;
> }

Das ist *so* natürlich Unfug; ausgenutzt werden soll hier der Umstand, dass
ältere Layout-Engines in älteren Browsern (konkret: MSHTML < 7 in z. B.
IE < 7 [1]), die `max-width' nicht unterstützen, auch den `>'
(Kind-)Selektor (ohne umgebenden Whitespace) nicht unterstützen. Richtig
ist daher:

bar {
width: 30em;
}

foo>bar {
width: auto;
max-width: 60ex;
}

______
[1] <http://caniuse.com/#cats=CSS>
--
PointedEars

[Gustaf Mossakowski]

Thomas 'PointedEars' Lahn schrieb:

> Susanne Jäger wrote:
>> [...] Historisch gesehen war es durchaus sinnvoll html, body

>> {font-size: 100%;} explizit ins CSS zu schreiben , weil ältere IEs
>> auf das Fehlen einer %-basierten font-size Angabe als Bezugsgröße
>> mit Chaos - meist mikroskopisch kleine Schriften reagieren konnten.
>
> Mir ist das in 12 Jahren Webauthoring mit diversen Schriftarten, -grössen
> und IE-Versionen noch nicht passiert. Was mache ich fchsal?

Wenn man noch keins deiner Postings gelesen hätte sondern stattdessen
nur deine Website angeguckt, könnte man sagen: mangelnde Erfahrung ;-)
Dort ist die Schrift auf meinem System (Mac OS X) ziemlich unleserlich.

http://www.koenige.org/temp/pointedears-de.png

Grüße, Gustaf

[Susanne Jäger]

Thomas 'PointedEars' Lahn wrote:

> Susanne Jäger wrote:

>> Beide sind für standardkonforme Browser nebenwirkungsfrei, vermeiden
>> aber Bugs, die schwer zu orten sind. Deswegen empfehle ich sie gerade
>> für weniger erfahrenen Autoren.

> Deine Logik ist fehlerhaft. Angaben, die etwas bewirken, sind gerade
> _nicht_ redundant.

Die genannten Angaben sind (gerade) für unerfahrene Autoren auch dann
sinnvoll, wenn sie (noch) nichts bewirken, sondern nur als
Vorsichtsmaßnahme zur Absicherung zukünftiger Erweiterungen dienen.

Gruß
Susanne

[Thomas 'PointedEars' Lahn]

Das ändert nichts daran, dass sie verwendet werden, weil sie bekanntermassen
etwas bewirken (werden). Somit ist das keine Redundanz. Bitte Logikmodul
justieren.

[Susanne Jäger]

Thomas 'PointedEars' Lahn wrote:
> Susanne Jäger wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Susanne Jäger wrote:
>>>> Beide sind für standardkonforme Browser nebenwirkungsfrei, vermeiden
>>>> aber Bugs, die schwer zu orten sind. Deswegen empfehle ich sie gerade
>>>> für weniger erfahrenen Autoren.
>>
>>> Deine Logik ist fehlerhaft. Angaben, die etwas bewirken, sind gerade
>>> _nicht_ redundant.
>>
>> Die genannten Angaben sind (gerade) für unerfahrene Autoren auch dann
>> sinnvoll, wenn sie (noch) nichts bewirken, sondern nur als
>> Vorsichtsmaßnahme zur Absicherung zukünftiger Erweiterungen dienen.
>
> Das ändert nichts daran, dass sie verwendet werden, weil sie bekanntermassen
> etwas bewirken (werden). Somit ist das keine Redundanz. Bitte Logikmodul
> justieren.

Hm? heißt Redundanz nicht eigentlich nur mehrfache Information?
<http://de.wiktionary.org/wiki/Redundanz> Die Wertung - ist *immer*
falsch, kann gar nicht nötig sein hast du ins Spiel gebracht.

gruß
Susanne

[Peter J. Holzer]

On 2012-04-25 20:01, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> Die CSS-Einheit `em' bezieht sich auf die Breite des Gevierts aus dem
> Letterndruck übertragen auf elektronische Schriften. Diese entspricht dort
> *ungefähr* der Breite des breitesten Buchstabens eines Schrift (der auf
> einer Letter Platz finden muss), i. d. R. des des grossen "M" (daher eben
> "em") [1, 2]. (Ungefähr AIUI, weil das gedruckte Zeichen nicht exakt an den
> Grenzen des Gevierts endet. CMIIW.)

Das ist eine umständliche und irreführende Vorstellung.

1. Umständlich: Ein Geviert (alter Ausdruck für Quadrat) ist per
definitionem gleich hoch wie breit. Die Breite des Gevierts ist also
gleich der Höhe und die Höhe wiederum ist/war im Bleisatz die
Kegelhöhe. Statt dem ganzen Absatz, den Du da oben geschrieben hats,
kann man sehr viel einfacher schreiben „1em ist die Kegelhöhe“.

2. Irreführend: „entspricht *ungefähr* der Breite des breitesten
Buchstabens ... i. d. R. des des grossen "M"“ impliziert, dass 1em
bei schmallaufenden Schriften kleiner sei als bei breitlaufenden.
Das ist aber nicht der Fall. Das sieht man am einfachsten, wenn man
zwei Schriften aus der gleichen Schriftfamilie vergleicht. Bei Arial
ist ein M 1706/2048 em breit, bei Arial Narrow hingegen nur
1399/2048 em. In beiden Schriftarten ist das M natürlich gleich hoch:
1466/2048 em. Das muss auch so sein, damit die Schriften
zusammenpassen, wenn man beide in der gleichen Schriftgröße setzt.
Bei z.B. 16pt ist so ein M in beiden Schriften 11.5pt hoch, aber in
der Arial Narrow schmaler (10.9pt) also in der Arial (13.3pt). Würde
sich ein em an Breite des M orientieren, wäre das M in beiden Fällen
gleich breit (16pt), aber in der Arial Narrow deutlich höher (16.8pt)
als in der Arial (13.7pt).

Elektronische Schriften haben natürlich keinen „Kegel“ und ein em
entspricht nicht notwendigerweise irgendeiner messbaren Eigenschaft der
Schrift: Bei den meisten Schriften ist es so gewählt, dass der vertikale
Abstand zwischen der Unterkante des (lateinischen) Kleinbuchstabens mit
der kleinsten Unterlänge und der Oberkante des Kleinbuchstabens mit der
größten Oberlänge etwas kleiner als ein em ist (klar - im Bleidruck
mussten die ja beide auf den Kegel passen). Aber über den gesamten Font
ist die Summe aus größter Oberlänge und kleinster Unterlänge meistens
deutlich über 1em und bei manchen Fonts trifft das schon bei "ganz
normalen" Buchstaben zu.

Zusammenfassend: 1em ist ein grobes Maß für die Höhe der Schrift, nicht
für die Breite. Technisch ist es einfach ein Skalierungsfaktor, den der
Font-Designer so wählen sollte, dass die Schrift bei gleicher em-Größe
etwa gleich groß wie andere Schriften erscheint.

> Die Einheit `ex' als "x-height", d. h. die Höhe des kleinen "x", eignet sich
> deshalb IMHO besser dafür, eine CSS-Länge (hier: Textbreite) anzugeben, die
> sich ungefähr nach der *Anzahl* der Zeichen in einer Zeile bemisst (das
> kleine "x" ist zumindest bei für Fliesstext geeigneten Schriftschnitten
> ungefähr so breit wie hoch).

Das erscheint auf den ersten Blick sinnvoll, da sich „ex“ als Einheit
auf eine echte Eigenschaft des Fonts bezieht und kein willkürlich
gewähltes Maß ist wie „em“.

Auf den zweiten Blick bin ich mir da nicht so sicher: Angenommen, ich
habe einen Font mit sehr kleinen Unter- und Oberlängen und einen mit
sehr großen. Dann sind wahrscheinlich bei nominell gleicher Größe beim
ersten die Kleinbuchstaben größer als beim zweiten, was nach Deiner
Methode zu einer längeren Zeilenlänge führen würde. Ich bezweifle aber,
dass das sinnvoll ist - das sieht dann wahrscheinlich sehr gedrängt aus,
während beim Font mit den großen Unter- und Oberlängen die Zeilen
deutlicher voneinander getrennt sind. Sinnvoll wäre es wahrscheinlich,
die Zeilenlängen vom Zeilenabstand abhängig zu machen, aber dafür gibt
es in CSS kein Maß - und umgekehrt den Zeilenabstand in Abhängigkeit von
ex anzugeben erscheint mir auch gefährlich, solange man keine Kontrolle
über den verwendeten Font hat.

hp

--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org