- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Tue, 25 May 2010 21:45:54 +0000
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, HÃ¥kon Wium Lie <howcome@opera.com>
- CC: "robert@ocallahan.org" <robert@ocallahan.org>, Christopher Slye <cslye@adobe.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, "www-font@w3.org" <www-font@w3.org>
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On > Behalf Of Levantovsky, Vladimir > The purpose of this sentence is to provide specify recommended behavior, > "MAY" has a completely different meaning. "MAY" is appropriate. The vast, vast majority of browser users will *never* look at this information. Ever. I don't think browser vendors should have to justify not implementing such a specialized metadata feature, yet SHOULD implicitly requires them to do just that since it is recommended. Fonts will still carry your metadata. Web authors will still want to access it. Browser vendors should be free to expose it in whatever way they wish, be it as a built-in dialog or an API exposed for applications and add-ons, or both. Most importantly for the format's adoption, they should be able to implement this *when* they wish. Summary: 1) this block is optional, 2) the invalidity of its content has no effect on the runtime use of the font data thus 3) recommending a UI mechanism here is toothless in practice, which means that 4) making this a SHOULD will likely result in most browsers being both non-conformant and interoperable. I don't think that's an interesting result from a standardization standpoint. If the metadata format is simple and extensible, we're definitely interested in supporting this eventually. But that is unlikely to be a priority in the first release that supports WOFF i.e. whether the lack of font metadata info UI makes us non-conformant with respect to WOFF will be up to web authors. That would make it a MAY.
Received on Tuesday, 25 May 2010 21:47:12 UTC