W3C home > Mailing lists > Public > www-style@w3.org > July 2011

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

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>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178292B7FC5@TK5EX14MBXC296.redmond.corp.microsoft.com>

[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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:42 GMT