- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Fri, 28 May 2010 01:19:18 +0000
- To: Tal Leming <tal@typesupply.com>
- CC: Jonathan Kew <jfkthame@googlemail.com>, Vladimir Levantovsky <Vladimir.Levantovsky@MonotypeImaging.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: Tal Leming [mailto:tal@typesupply.com] Sent: Thursday, May 27, 2010 5:51 PM > Will you ignore the blahblah element because it is not in the spec? Yes. If you want it rendered in the info pane, you follow the format defined in the spec. >What if it is part of a new version of the spec that was released after your code was written and the browser shipped? Show it? Discard it? Then the next release may show it. But I'd like to avoid any future revs by defining a way to extend the metadata that will cover most needs I'd expect for something as basic as file metadata. > If your answer is "it will ignore the elements that are not part of the spec", how does your code know what is in the spec and what isn't? Because the spec tells me what's defined ? Because I'm looking for certain elements with certain names and certain attributes to fill in my UI and ignore the rest ? > Do you update it each time the spec is bumped? Isn't that what we're trying to avoid? I don't want to bump the spec and write new code every time someone somewhere needs a new bit of metadata. Hence the extension point. But if extensions *can* be any arbitrary XML then don't waste your time telling me what the format of the metadata block is. I have no way of knowing whether the information my user cares most about for the font they're looking at is going to be in the well-known XML defined by the WOFF spec or the unknown XML the font vendor put in the block. So I should really try to offer my best-guess/generic/boring rendering of the entire block to make sure they get what they want rather than hide it from them. Or force them to look at gobs of raw XML with dozens of localized elements. But if I can render any arbitrary XML in some reasonable manner, then this same code can also render whatever format you specify in whatever version it may be. So I'll just render *everything* using the exact same generic code path. And if I and other UAs do that, then tool vendors don't need to bother generating metadata in the format you specify either since browsers will render whatever comes their way. Bottom line: either you specify a format or anything goes. It'd be simplest if we picked one instead of implying UAs are expected to write one code path for the XML that's specified and maybe another for the random XML any font vendor can add.
Received on Friday, 28 May 2010 01:19:57 UTC