- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Thu, 21 Jul 2011 00:32:15 +0000
- To: Christoph Päper <christoph.paeper@crissov.de>, "W3C Style" <www-style@w3.org>
[Christoph Päper:] > > Sylvain Galineau: > > Christoph Päper > >> Leave both WOFF and CSS alone, they are simply not the right place. > > > > The right place for what ? > > Any kind of transport layer requirements or restrictions, especially > normative ones. It's not a transport layer restriction; the transport layer doesn't know nor care about fonts. It's a restriction on requests made on behalf of the @font-face src descriptor i.e. it is not orthogonal to css3-fonts it's explicitly *tied* to it. I don't know how to be more specific than 'requests made for the purpose of loading fonts specified by the src descriptor of @font-face' (or equivalent wording). I don't see what in this very specific scoping can be construed as 'this is orthogonal to the feature'. As things stand today, browser A can succeed in loading the specified font and browser B can fail and they're both conformant. I don't see the benefit of separating from css3-fonts a requirement that can result in a very different result when the feature is used. Given the same input, both browsers should fail or succeed for the same reasons. css3-fonts should of course not define the transport layer mechanism by which the policy information is exchanged but from an interoperability standpoint it would be most helpful if it referenced the mechanism that should be used. > > > The right place to define requirements needed to achieve CSS3 Fonts > interop is the CSS3 Fonts spec. > > Sure. > > > It's fine to disagree with the merits of the requirement. > > I don’t necessarily disagree with the default same-origin restriction and > its opt-in cross-origin relaxation for *Web Fonts*, I question its merits > for *CSS Fonts*, because I see none whatsoever. If you don't see the merits of making sure any two browsers interpret and apply the same @font-face rule in a compatible manner then none of this conversation has any purpose. > > The aim is to ship interoperable web fonts implementations, > > Exactly, and the CSS Fonts module is just one part of “web fonts”. Other > parts are supported font formats, e.g. WOFF, and font distribution models, > e.g. HTTP with mandatory CORS/FO. > > CSS Fonts ⊊ Web Fonts We won't agree on that. If the origin of the document had an impact on whether or not a background-image loaded I'd want to see that normatively defined in Backgrounds & Borders as well, even if the actual mechanism is specified elsewhere. To put it another way, the test suite for css3-fonts would, today, entirely fail *by default* in some browsers if the testcases and fonts are hosted at different origins. They would fail because of logic tied to a specific feature defined in the spec i.e. while the policy is exchanged at a layer that is orthogonal to CSS Fonts, the decision to apply that policy is part of the feature. The decision to apply same-origin by default for font requests is not made auto-magically by the transport layer, it's made by the code that carries out @font-face requests.
Received on Thursday, 21 July 2011 00:32:45 UTC