- From: Liam R E Quin <liam@w3.org>
- Date: Wed, 09 Mar 2011 19:04:45 -0500
- To: John Daggett <jdaggett@mozilla.com>
- Cc: www-style list <www-style@w3.org>, www-font@w3.org
On Mon, 2011-03-07 at 11:31 -0800, John Daggett wrote: > Last week I committed a new revision of the CSS3 Fonts editor's draft. Some personal comments > Key changes include: > > * Section 6.4 subscript, superscript, ordinal description > http://dev.w3.org/csswg/css3-fonts/#vertical-position-prop > > The 'vertical-position' property now functions as a shorthand for > font-size and vertical-align, user agents that recognize this > property reset font-size and vertical-align so that typographic > subscripts/superscripts don't affect the linebox. This also allows > fallback to CSS2.1 style subscripts/superscripts in older user > agents. I think it's a good idea; is the name still appropriate for vertical scripts? I see it's marked as an issue; fair enough. In section 5, [[ If a font family defined via @font-face rules contains only invalid font data, it should be considered as if a font was present but contained an empty character map; matching a platform font with the same name must not occur in this case. ]] seems to mean that if you have an @font-face rule for an EOT Palatino (say) and your browser doesn't support Palatino, the system Palatino font must never be used as a fallback; that seems suboptimal. 6.3 font-kerning should mention what to do about common-ligatures (and possibly should explain what kerning is :-) ) > * Section 6.9 syntax of the @font-feature-values rule > http://dev.w3.org/csswg/css3-fonts/#font-feature-values > > Adjusted the notation based on the TPAC discussion and added some > better examples of various use patterns. It's good I think, at a cursory glance. > * Section 6.12 font-feature-settings syntax > http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop > > The syntax for access to low-level OpenType features is now more > CSS-like rather than a long string of tag-value pairs. I am not convinced by making all of the hard-coded sub-properties. The stability of the Adobe opentype feature registry isn't clear, and I think having "low-level" and "high-level" access to the same features confusing - you can turn ligatures on with one property and off again with another, they are not orthogonal. In addition, as new features are added from time to time, or for other font formats, CSS would need to be updated. The orthogonal issues, which the draft does seem to capture, are font selection vs. manipulating a font once you've selected it. For individual features, one might want to reset them to the formatter default, or to the inherited value, or turn them on or off without affecting others, or reset the font to some known state and maybe then make a change. One might want to do this only if a given font is used. For XSL-FO I've been working on the idea of a single property which lets you add to or subtract features by prefixing their names with + or -, but the syntax is also not part of the existing language. Some specific suggestions... (1) use ff- instead of otp (i.e. font feature) rather than requiring per-font-format changes to the CSS spec. (2) allow "inherit" and "default" (or "normal") as well as on and off (3) allow any mix of the "friendly" and "unfriendly" feature names in the two properties (for selection and for manipulation) (4) consider a conditional, @when (font-family: "x") { stuff here } or something. Although this is getting to the point where people would use JavaScript in environments where style manipulations are scriptable. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/
Received on Thursday, 10 March 2011 00:04:50 UTC