RE: Next step?

> From: [] On
> Behalf Of John Hudson

> Sylvain, can you -- or anyone else -- please explain to me what the
> actual or perceived benefit of an 'any-2-of-4' conformance requirement
> is? I can understand that if it were impossible to come to consensus on
> any one format then such a conformance statement would make sense as a
> compromise to move things forward, but we don't appear to be in that
> situation.

I don't see what the downside is. We all support at least one of these formats so 
If a consensus is so obvious and possible around WOFF then WOFF+1 is what will happen. 

To be clear, what I am stating is that two is better than requiring 3 or 4, given that every 
browser vendor has strong feelings about at least one of the formats on the list. Sure, 
it would be great if we could bypass this and agree on one but I very much doubt 
this will happen over email; and as browser vendors will still support their current
features and browsers upgrade at a different pace, authors still need to deal with 
what's out there.

> I would also like to register that I personally do not like the idea of
> any browser maker being able to cite support for naked font linking *as
> conformance*. I understand that the browsers that have already chosen
> to
> support that format are unlikely to disable such support, but I don't
> think such support should count toward conformance. Other formats such
> as CWT might be contentious for technical or political reasons, but
> naked font linking is contentious because it puts peoples' works and
> livelihood at unrestrained risk. This is another reason why I prefer a
> single, non-contentious format as a conformance requirement and other
> formats, including naked font linking, only as options.

Well, here we go again :) What I would like to register is that I do not like the
idea of the charter keeping open the possibility of arguing about the utility
or desirability or appropriateness of this format vs. that other one unless that argument is 
purely technical in nature. As no one is required to implement a format they have problems 
with, this is not a productive door to leave open. We've been there. Many times. There are four 
formats on the table, each of which is either currently supported or landed in the public build 
of at least one major browser. Two of these formats ought to be formally defined to ensure future 
implementations can interoperate successfully. We then should agree on a simple conformance criteria 
that will get us the rest of the way.

I personally have very limited interest in re-hashing the well-known grievances and disagreements 
around this topic. Raw font support has been implemented by a number of browsers and will remain so.
Two browsers that support this are technically interoperable for this format, however that may conflict
with the existing business models of font designers. The latter should - and, I expect, will - remain 
beyond the scope of such a WG.

So 'yes' to sitting down with John, Roc, and others in the browser, font and author community 
to have a data-driven technical discussion on whether a CWT proposal should include a 
rootstring-capable header or not. Yes to formally specifying WOFF. Yes to discussing wether UAs
should use same-origin policy with access control support for web fonts. Yes to discussing any interesting
technical issues pertaining to web fonts and interop. Yes to requiring 2 out of 4. 

But 'not so much' to setting up another venue to argue the usefulness of CWT on non-technical grounds, the real and perceived harm of raw fonts, whether SVG Fonts should really be dropped in favor of WOFF and what not.

This being said I'd also like to register that I volunteer to help edit any of the submission the charter implicitly
or explicitly requires. (Especially CWT, of course).

Received on Wednesday, 21 October 2009 23:17:09 UTC