Re: css3-fonts: should not dictate usage policy with respect to origin

On 29 Jun 2011, at 21:27, Bjoern Hoehrmann wrote:

> CSS 2.0 was the last specification for font loading from style sheets
> with community support. As far as I am aware it did not prohibit re-
> referencing fonts across "origins" and it did not require support for
> "CORS". If you want to prohibit font references across origins and re-
> quire "CORS", then you have to persuade the community that that's the
> way to go.

"The community" is a rather vague concept, but I would venture to suggest that a broad spectrum of "the community" has been involved in reaching the consensus that is reflected by the current WOFF and CSS3-Fonts drafts.

> If you need something specific, let's say I have a little tool that
> implements css3-fonts and some other CSS features

How can your tool "implement css3-fonts" when that standard is still an evolving draft? More specifically, if your tool implements whatever snapshot of the evolution of css3-fonts happened to be current at some point in the past, how can you possibly expect it to continue to conform to all future drafts or the final css3-fonts recommendation, unless you are prepared to make changes including potentially some that affect existing behavior in significant, perhaps breaking, ways?

> and a markup language
> and it renders the styled documents into a bitmap. Has all sorts of
> limitations, for instance, it only supports UTF-8 even though browsers
> do support many other character encodings and the only font format my
> tool supports is not supported by any browser. My tool does currently
> load cross-origin fonts and supports HTTP of course.
> 
> If I change my tool so it no longer loads cross-origin fonts then that
> might break stuff for my existing users when they upgrade. Seems I have
> more work and my users more problems. I could also implement the CORS
> specification, but that is even more work for me and more work for my
> users because they have to change their servers and so on.

Or you could leave your tool exactly as it is, and it will continue to behave exactly as it does today. And it will continue to be just as "compliant" as ever with whatever draft you chose to implement. I don't think you have any right to demand that the final css3-fonts recommendation must be constrained in such a way that your pre-existing tool will be compliant with it.

If you accept that your hypothetical tool has "all sorts of limitations" (compared, for example, to typical Web browsers), why should you care precisely how much of css3-fonts it does or does not implement?

> The question isn't what kind of use cases I have in mind, the question
> is rather why my tool cannot be css3-fonts compliant if I don't feel
> like making these adjustments

The question that intrigues me is why you think there is any basis whatsoever to expect that _any_ preexisting implementation will magically be compliant with a future recommendation. That seems to me to impose an unacceptable straitjacket on the standardization process.

JK

Received on Wednesday, 29 June 2011 20:56:44 UTC