Re: [css3-fonts] new editor's draft posted

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