W3C home > Mailing lists > Public > www-style@w3.org > April 2012

RE: [css3-fonts] font-feature-settings syntax

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Thu, 19 Apr 2012 14:05:37 +0000
To: John Daggett <jdaggett@mozilla.com>, WWW Style <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178290994E39E@TK5EX14MBXC295.redmond.corp.microsoft.com>

[John Daggett:]
> 
> The font-feature-settings in CSS3 Fonts currently has a relatively simple
> syntax, it takes a comma-delimited list of strings with an optional value
> or on/off keyword [1].  The strings represent OpenType tags which are
> defined to be 4-character ASCII strings.
> 
> Example:
> 
>   /* enable small caps and use second swash alternate */
>   font-feature-settings: "smcp", "swsh" 2;
> 
> The spec contains the following wording:
> 
>   The <string> is a case-sensitive OpenType feature tag. For it to
>   match an OpenType feature contained in a font, it must follow the
>   syntax rules for tags. As specified in the OpenType specification,
>   feature tags contain four characters. Tag strings longer than four
>   characters must be ignored, user agents must not use a feature tag
>   created by truncating the string to four characters.
> 
> This doesn't define clearly the behavior for smaller strings and strings
> containing non-ASCII codepoints.  I'd like to tighten this up to make it
> so that only four-character ASCII strings are considered valid, since
> shorter strings or strings with non-ASCII characters won't ever match an
> OpenType font feature and are most likely a typo.
> 
> I propose changing the wording above to:
> 
>   The <string> is a case-sensitive OpenType feature tag. For it to
>   match an OpenType feature contained in a font, it must follow the
>   syntax rules for these tags. As specified in the OpenType
>   specification, feature tags contain four ASCII characters. Tag
>   strings longer or shorter than four characters, or containing
>   characters outside the U+20-7E codepoint range must be treated as
>   invalid.  User agents must not use a feature tag created by
>   truncating or padding the string to four characters.
> 
> The current editor's draft also lists an issue as to whether quotes should
> be required.  I think it would be best to resolve this now and simply
> require quotes. The Webkit-prefixed version of Chrome on Windows doesn't
> require them but the IE10 Preview version does.  I think there was enough
> opposition to unquoted strings during the original discussion of this [2]
> that it would make sense to require quotes and remove the issue from the
> spec.
> 
> Regards,
> 
> John Daggett
> 
> [1] http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop

> [2] http://lists.w3.org/Archives/Public/www-style/2011Mar/0280.html

> 
I support this change (I even believe we already filter for this before
passing it down to the underlying system API). As for requiring quoting,
I believe that is already the case. The current draft [1] does define
<feature-tag-value> thus:

	<string> [ <integer> | on | off ]?

Unlike an ident a string requires single or double quotes. So Chrome's
behavior would be a bug per the current definition.
	



[1] http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop


Received on Thursday, 19 April 2012 14:06:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:52 GMT