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

[Bjoern Hoehrmann:]
> 
> * Sylvain Galineau wrote:
> >It would certainly be helpful to discuss specific examples and
> >use-cases in order to understand where the issue concretely lies vs.
> abstract generalities like 'devices'
> >or 'implementations' which guarantee people will think of those
> >implementations and devices they *know*. But it seems I'm crazy for
> >thinking we should have a chance to discuss such specifics and use-cases
> *before* we get to the FO stage.
> 
> 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.
> 
> If you need something specific, let's say I have a little tool that
> implements css3-fonts and some other CSS features 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.
> 
> 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, and so far I've seen no reason for that.
> 
> If you cannot explain why all css3-fonts implementations must do this,
> then you will have a hard time convincing The Director to keep the re-
> quirement for all implementations as it is.
> 
> (I actually do offer tools like that and do get regular user feedback
> about web fonts not working for one reason or another, they are just not
> quite as limited as in the example above, and don't really matter in this
> discussion.)

First, your new tool can load the content as long as the server says it is 
OK for it to do so using the proper header; which it may already do if the 
Content it consumes is also served to other UAs; or may entirely be in your
control if the solution is entirely custom. Second, if compatibility is
far more important for your scenario than conformance then by all means, 
stay compatible. IE's document modes are there for the exact scenario you 
outline: a corporate  customer will not deploy a browser revision that can't 
breaks the internal payroll app just because that is the conformant thing to do. 
If they want to stick to the compatible behavior, they can do so. If they want 
the conformant behavior they can get that too. How that is delivered is ultimately 
a UA decision, as you point out ('if I don't feel like...'). What you do or do not 
feel like is your call and need not involve the Director. Conformance is still 
defined by a REC, not a draft. Allowing draft implementations to block progress 
defeats the purpose of standardization. 

Last, I would like Glenn to elaborate on the specific issues and use-cases
underlying his objection. We are imo more likely to achieve real progress
by looking into those vs. imaginary tools. At the very least, since this 
requirement has been successfully implemented and deployed for some time, 
there should be ample evidence of all the issues and unintended consequences 
it causes. Note that I'm not saying there isn't any such evidence; as an 
implementor I do give higher priority to actual implementation and deployment 
experience over contrived imaginary scenarios.

Received on Wednesday, 29 June 2011 20:59:42 UTC