RE: WOFF and extended metadata

> -----Original Message-----


> On 26 May 2010, at 23:18, Sylvain Galineau wrote:
> > Or we can let each browser vendor figure out whether and how they'll
> > render the unknown arbitrarily deep XML they might come across. By
> now
> > it's painfully clear which approach I believe to be most likely to
> > result in solid, complete, working implementations so I'll stop :)
> 
> Is this really so hard? I don't speak XSLT...

Me neither - OK, maybe a little - but if rendering font metadata for the
1/10,000 users that do care about it does require me to run XSLT transforms 
or an equivalent algorithm to account for all the unpredictable markup people 
might throw at me then it's *very* unlikely I'm going to bother implementing 
this for quite some time, if ever. The range of possible inputs is now infinite,
for one; browsers already have to deal with quite a bit of that as it is. Adding 
one more source of input entropy for the metadata of a specific resource type seems 
highly unnecessary. There is a big difference between a format being extensible vs. 
open-ended. We seem to want the former, but because open-ended is also extensible 
we assume it's the same thing in the end. I disagree. Open-ended is not a feature 
here: it' a burden on implementors out of proportion with the very narrow benefit 
we aim to achieve imo.

The cost of implementing 'about this font' ought to be as minimal as it can be or
no one will bother. Whatever seems to be hackable with a quick script and works great 
with the two examples you and I just made up is not necessarily a good indication of 
what it'll cost in a real shipping product that, for this particular feature, probably 
has more malicious attackers poking at it than there are people who will use said feature 
on a regular basis.

Received on Wednesday, 26 May 2010 22:58:37 UTC