- From: Tal Leming <tal@typesupply.com>
- Date: Thu, 27 May 2010 15:04:33 -0400
- To: Sylvain Galineau <sylvaing@microsoft.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>
On May 27, 2010, at 1:54 PM, Sylvain Galineau wrote: > I'm not sure what you're saying. Honestly, I'm having a hard time following you as well. > My proposal defines everything that a > browser will render, including an extension point allowing font vendors > to add their own data to the font info UI. Once I have written rendering > code for such a format, I *am* done. The metadata we have already defined > will render. The conforming metadata you and others add will render too. > All of it. It will work the same in 10 years as it would next week. Okay, so your code would support this abstraction: <metadata> <element attribute="text" /> <element attribute="text"> <childelement attribute="text"> text </childelement> </element> </metadata> This would allow you to support future additions to the spec because you are supporting a structure, not a set of defined elements, right? What if a future version of the spec adds this element? <blahblah> <foo> <bar> <lalala/> </bar> </foo> </blahblah> Given some of what you said before about nesting, I don't know. > What do I do if people don't conform > to these guidelines ? Does it mean I'd effectively parse this unknown data then > check its tree depth and other structural constraints in order to figure out whether > it'll fit in my UI ? Then what if it doesn't ? Up to me ? All of this applies to your proposal as well. We have to answer these questions no matter what direction we go in. Tal
Received on Thursday, 27 May 2010 19:05:13 UTC