- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Mon, 24 May 2010 18:53:48 +0000
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, "robert@ocallahan.org" <robert@ocallahan.org>
- CC: Jonathan Kew <jfkthame@googlemail.com>, Adam Langley <agl@google.com>, John Daggett <jdaggett@mozilla.com>, Christopher Slye <cslye@adobe.com>, "www-font@w3.org" <www-font@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
> From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg- > request@w3.org] On Behalf Of Levantovsky, Vladimir > Sent: Monday, May 24, 2010 6:00 AM > Persuasion is exactly what I am doing here. Well, persuasion is what I am looking for. I keep asking what such a validation requirement is for and am not getting any concrete answers. > To summarize the current status of the discussion: > - I believe we have already reached a consensus that browsers are *not* > required to validate the metadata in a WOFF file in order to render a > font packaged in it. > - WOFF file and the unpacked font should *not* be rejected because of > the invalid XML metadata. > - Metadata content will only be displayed to a user if the user wants > to see it and is asking for it (e.g. by selecting "View font info", > "Page info" or a similar option provided by a browser). Good. > - Browsers already have the ability to present XML data to a user, and > displaying WOFF metadata upon user's request would not introduce any > additional implementation complexity. I don't think the spec cannot require UI. I can't imagine forcing phone browsers to provide a font info UI. Like Hakon, I don't think we should make arbitrary exceptions for these UAs but not others. If we're OK with only showing this info when the user wants to see it, then we're OK with letting browser vendors decide how and when to implement this based on user feedback. I'm pretty sure web authors will want this and desktop browsers will be happy to oblige. If the font will work regardless of the presence of XML metadata, its validity or the browser's ability to make sense of the actual metadata format stored by the font maker then all we can say is that browsers should provide a means to access it. As for rendering it, a browser can always display raw XML but that's not very friendly. The alternative is for us to specify a schema; that is not an undertaking I am comfortable with either. Let's just say UAs may not be willing to wait for this format to settle in order to add support for WOFF. My personal preference would be to forgo XML here and use a flat property bag/name-value pair format no more complex than JSON. We'd define a basic set of common property names e.g. font name, authors, copyright, version, vendor URL etc. and let font makers add whatever else they wish. It will be far easier to create, edit and extend; and browser vendors will be able to provide a generic UI control to show all the properties. It could be that I missed the reason to use XML e.g. maybe we want to nest things hierarchically. Since Firefox is the first implementation out there, I'm curious to hear about what they have done in this respect, or what their plans are ?
Received on Monday, 24 May 2010 18:54:34 UTC