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

On Thu, Jul 21, 2011 at 3:04 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> JFTR, I also find it strange that CSS says this about relative URIs in ‘url()’:
>
>  For CSS style sheets, the base URI is that of the style sheet, not that of the source document.
>
> but the Fonts module ED has this text:
>
>  The origin of the stylesheet containing @font-face rules is not used when deciding
>  whether a font is same origin or not, only the origin of the containing document is used.

These aren't necessarily in conflict.  The base url and the origin are
distinct concepts.  The origin of a resource hasn't been important in
CSS so far.  I expect that as more resources with origin-important
behavior become usable in CSS, we'll remain consistent with what the
Fonts spec is saying.


On Thu, Jul 21, 2011 at 8:59 AM, David Singer <singer@apple.com> wrote:
> On Jul 21, 2011, at 12:04 , Christoph Päper wrote:
>> This is what your concerns sound like to me: “We adhere to commercial font vendor demands, whether they’re sound or not. This results in complications for authors and users which don’t happen with competing browsers. To level the field, we want to require everyone to follow those restrictions. To make that more probable, we want the requirement in a specification that the others want to comply to anyway.”
>
> It's by no means clear that the sharing of support resources without the serving site's permission should ever work. Putting any kind of support resource (by which I mean something that's needed for my site's operation but does not by itself result in visible output) so as to make my site work, is not permission for you to filch bandwidth from me by using it to support your site as well.
>
> For historical reasons, this has not been an issue until now.  But fonts are both 'large' and often 'valuable'. Setting a mechanism in place so that fonts can be restricted so you can't filch from me is reasonable.

To put a finer point on it: fonts are the first large resource that
doesn't have too much legacy hot-linking behavior already for us to
clamp down on it.  Many browser implementors (and I as well) would
*love* if we could go back in time and make images SOR (obviously we
would need to take CORS back with us on the time machine as well).  We
*just barely* missed the boat on <video> and <audio>, which is
terribly sad.  (Though, I'd suggest that we apply SOR to video or
audio resources linked through CSS, however that is done.)

~TJ

Received on Thursday, 21 July 2011 16:10:21 UTC