Specs font shorthand

[Dieter Raber]

Hallo,

in den CSS Specs steht fuer die font shorthand

[[<'font-style'>||<'font-variant'>||<'font-weight'>]?[...]

Fuer mein Problem ist alles hinter font-weight irrelevant, deshalb habe ich das weggelassen. Man kann jetzt entweder einen, zwei oder drei Werte fuer die Kombination style variant weight haben. Bei einem und drei Werten ist die Zuordnung klar, ebenso, wenn man zwei Werte hat und diese sind zB. small-caps bold oder aber normal normal, bzw. inherit inherit. Was aber passiert, wenn die Shorthand font: normal inherit [...] lautet? Werden dann alle Werte auf normal oder inherit gesetzt oder passiert was voellig anderes?

Danke fuer die Hilfe

Dieter

[Beat]

in den CSS Specs steht fuer die font shorthand

[[<'font-style'>||<'font-variant'>||<'font-weight'>]?[...]

http://www.w3.org/TR/2009/CR-CSS2-20090908/fonts.html#font-shorthand

Zitat: http://www.w3.org/TR/2009/CR-CSS2-20090908/about.html#value-defs
A double bar (||) separates two or more options: one or more of them must occur, in any order.

Das gibt einem Parser Freiheiten. Abweichende Wertzuordnung kann vorkommen.

Subjectiv:
Shorthands sind schlechter Stil.

mfg Beat

[Der Martin]

Hallo,

Subjectiv:
Shorthands sind schlechter Stil.

Subjektiv:
Shorthands sind eine feine Sache und fördern die Übersichtlichkeit - sobald sie mehrdeutig sind, würde ich sie jedoch meiden.

Ciao,
 Martin

[Beat]

Subjectiv:
Shorthands sind schlechter Stil.

Subjektiv:
Shorthands sind eine feine Sache und fördern die Übersichtlichkeit - sobald sie mehrdeutig sind, würde ich sie jedoch meiden.

Sie sind überhaupt nicht übersichtlich.
Jetzt willst du alle Werte zu einer Eigenschaft ändern. Zu blöd, mit deinen Shorthands kannst du nicht mal den Wert zweifelsfrei matchen.

Für die CSS Entwicklung sind sie so böse wie ein Modul, das sich Parameter als Liste namenloser Werte übergeben lässt.

Wenn Shorthand, dann würde ich sie mir für Selektoren wünschen
@selector #some-id .someclass{
  /* alle Regeln gelten im Tree unterhalb #some-id .someclass */
  p {porp:val;}
  /* same as
     #some-id .someclass p{}
  */
}

Und wenn schon übersichtlich, dann brauchen Wir Variablen um Werte zu speichern.
@variable $regular-font-face='"DejaVuSans", Helvetica, sans-serif'
@variable $regular-background-color='#e7e9e0'

mfg Beat

[Gunnar Bittersmann]

@@Beat:

nuqneH

[Shorthands] sind überhaupt nicht übersichtlich.

Doch, sind sie.

Ich wüsste nicht, was an 'foo { background: #F00 url(foo) repeat-y -42px top }' unübersichtlich wäre.

Und wenn schon übersichtlich, dann brauchen Wir Variablen um Werte zu speichern.

Variablen in CSS? Sicher einen Gedanken wert.

@variable $regular-font-face='"DejaVuSans", Helvetica, sans-serif'

Aber Variblen mit einem vorangestelltem '$' kennzeichnen? So etwas hat keine vernünftige Programmiersprache nötig.

Qapla'

[Felix Riesterer]

Lieber Gunnar,

Ich wüsste nicht, was an 'foo { background: #F00 url(foo) repeat-y -42px top }' unübersichtlich wäre.

bist Du Dir der Reihenfolge sicher? Meines Wissens steht die repeat-Anweisung als letztes (falls keine Angabe zu "fixed" steht)... aber siehe selbst.

Liebe Grüße,

Felix Riesterer.

[Der Martin]

Hallo,

Ich wüsste nicht, was an 'foo { background: #F00 url(foo) repeat-y -42px top }' unübersichtlich wäre.

bist Du Dir der Reihenfolge sicher? Meines Wissens steht die repeat-Anweisung als letztes (falls keine Angabe zu "fixed" steht)... aber siehe selbst.

wenn Beat richtig recherchiert hat, gilt hier dasselbe wie bei Dieters Beispiel zu font: Die Angaben, die in der Spec in eckigen Klammern und mit || getrennt notiert sind, dürfen in beliebiger Reihenfolge auftreten - selbst wenn es dadurch zu Mehrdeutigkeiten kommt.

So long,
 Martin

[Felix Riesterer]

Lieber Martin,

wenn Beat richtig recherchiert hat, gilt hier dasselbe wie bei Dieters Beispiel zu font: Die Angaben, die in der Spec in eckigen Klammern und mit || getrennt notiert sind, dürfen in beliebiger Reihenfolge auftreten - selbst wenn es dadurch zu Mehrdeutigkeiten kommt.

dann muss man sich also nicht wundern, wenn die Werte für left und top in unerwarteter Reihenfolge angenommen werden. Anscheinend gilt bei den beiden "erst x dann y" - immerhin sind die Angaben im identischen Format (numerischer Wert oder "bottom|center|top")...

Liebe Grüße,

Felix Riesterer.

[Der Martin]

Hallo Felix,

Die Angaben, die in der Spec in eckigen Klammern und mit || getrennt notiert sind, dürfen in beliebiger Reihenfolge auftreten - selbst wenn es dadurch zu Mehrdeutigkeiten kommt.
dann muss man sich also nicht wundern, wenn die Werte für left und top in unerwarteter Reihenfolge angenommen werden.

ähm, kommt drauf an. Die Spec sieht hier background-position als *einen* Parameterblock, der seinerseits die einzelnen Parameter wieder in der Reihenfolge "erst x, dann y" erwartet. Werden beide Werte als Schlüsselwort angegeben, können left/center/right und top/center/bottom wieder in beliebiger Reihenfolge auftreten, was aber nur bei center potentiell mehrdeutig sein kann, im Kontext aber trotzdem noch eindeutig bleibt: "If only one value is specified, the second value is assumed to be 'center'".
Nicht erlaubt ist jedenfalls, die background-position-Angabe aufzutrennen, also zwischen x- und y-Angabe etwas anderes hineinzumischen.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

ähm, kommt drauf an. Die Spec sieht hier background-position als *einen* Parameterblock, der seinerseits die einzelnen Parameter wieder in der Reihenfolge "erst x, dann y" erwartet. Werden beide Werte als Schlüsselwort angegeben, können left/center/right und top/center/bottom wieder in beliebiger Reihenfolge auftreten

Öhm, da hab ich letztens erst einen „Fehler“ korrigiert und aus "top left" "left top" gemacht, und jetzt kommst du und sagst, dass dies gar kein Fehler war‽

Dennoch ist es wohl eine gute Empfehlung, bei zwei Schlüsselwörten auch die Reihenfolge einzuhalten, wie sie bei zwei numerischen Werten oder einem numerischen Wert und einem Schlüsselwort vorgeschrieben ist.

Qapla'

[Der Martin]

Hallo Gunnar,

Öhm, da hab ich letztens erst einen „Fehler“ korrigiert und aus "top left" "left top" gemacht, und jetzt kommst du und sagst, dass dies gar kein Fehler war‽

'tschuldigung, ich kann doch nix dafür, das steht da so ... ;-)

Dennoch ist es wohl eine gute Empfehlung, bei zwei Schlüsselwörten auch die Reihenfolge einzuhalten, wie sie bei zwei numerischen Werten oder einem numerischen Wert und einem Schlüsselwort vorgeschrieben ist.

Ja, das sehe ich auch so.

Ciao,
 Martin

[Tim Tepaße]

@variable $regular-font-face='"DejaVuSans", Helvetica, sans-serif'
Aber Variblen mit einem vorangestelltem '$' kennzeichnen? So etwas hat keine vernünftige Programmiersprache nötig.

Es geht weniger darum eine Grammatik für Menschen wie in Perl einzuführen, sondern darum, die Macro-Expansions-Deklarationen für ältere Clients wegen gewünschter Abwärtskompabilität invalid zu machen. Die beiden Vorschläge für CSS-Konstanten haben demnach auch jeweils eine Syntax für die gewünschte Invalidität: var(name) und [name](http://fantasai.inkedblade.net/style/specs/constants/) (eher ein beliebiges anderes diakritisches Zeichen als "").

[Struppi]

Aber Variblen mit einem vorangestelltem '$' kennzeichnen? So etwas hat keine vernünftige Programmiersprache nötig.

Dafür darf man dann in einer vernüftigen Sprache keine Schlüsselwörter als Variabelnamen benutzen, was dann in Javascript z.b. dazu führt, dass man u.a. CSS Eigenschaften anders benennen muss, als sie eigentlich (in CSS) heißen (z.b. float).

Es hat alles seine Vor- und Nachteile, was aber in dem Fall vernünftiger ist, läßt sich nur schwer sagen.

Struppi.

[Gunnar Bittersmann]

@@Dieter Raber:

nuqneH

Man kann jetzt entweder einen, zwei oder drei Werte fuer die Kombination style variant weight haben. Bei einem und drei Werten ist die Zuordnung klar

Da || ja wie gesagt „in any order“ bedeutet, ist bei dreien auch nichts klar, wenn es 2× "normal" und 1× "inherit" oder 1× "normal" und 2× "inherit" sind.

Die Spec sollte schon festlegen, wie dies zu verarbeiten ist. Ist vielleicht an der Stelle nicht ganz bis zum Ende durchdacht.

Ist überall, wo „Ian Hickson“ draufsteht, ein bisschen „nicht ganz bis zum Ende durchdacht“ drin? >;-> SCNR.

Magst du das Problem mal dem Editor der [CSS3-FONTS]-Spec schildern?

Qapla'