W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

RE: suggested WOFF changes

From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
Date: Tue, 22 Jun 2010 15:47:49 -0400
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: John Daggett <jdaggett@mozilla.com>, John Hudson <tiro@tiro.com>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, www-font <www-font@w3.org>
Message-ID: <7534F85A589E654EB1E44E5CFDC19E3D03F3DB5498@wob-email-01.agfamonotype.org>
On Tuesday, June 22, 2010 12:03 PM Tab Atkins wrote:
> On Tue, Jun 22, 2010 at 8:00 AM, Levantovsky, Vladimir
> <Vladimir.Levantovsky@monotypeimaging.com> wrote:
> > On Monday, May 10, 2010 10:24 PM John Daggett wrote:
> >>
> >> > User Agents MUST NOT permanently install fonts delivered in a WOFF
> >> > format as system resident fonts, and SHOULD only use downloaded
> >> > fonts to render the content of a webpage that WOFF resources are
> >> > associated with.
> >>
> >> This is redundant, the CSS3 Fonts specification already defines this
> >> behavior for *all* font types, not just WOFF [2].  See section 4.1:
> >>
> >>   "Downloaded fonts are only available to documents that reference
> >> them,
> >>    they must not be made available to other applications or other
> >>    documents."
> >>
> >> The primary reason for this is security, the content of a given page
> >> should not influence content of a different page unless the
> resources
> >> are explicitly shared (i.e. the pages link to the same resource).
> >>
> >
> > I found an interesting discussion where WOFF was mentioned [1], and
> it appears that the UA behavior/requirements specified by CSS spec with
> regard to downloadable fonts may not be supported by some browsers. In
> light of this discussion: taking into account that implementers expect
> to see any relevant requirements clearly mentioned in the spec and that
> the WOFF spec is so far the only web font specification developed by
> W3C - I think it's worth to mention explicitly what the expected UA
> behavior must be when consuming WOFF resource, and appending the
> proposed text to the second paragraph of the Introduction section seems
> to be logical and appropriate.
> >
> > I don’t think it would be a problem reiterating what CSS spec already
> says (and we can also make a reference to CSS spec here to connect the
> dots).
> >
> > Thank you and regards,
> > Vlad
> >
> >
> > [1] http://krijnhoetmer.nl/irc-logs/whatwg/20100303#l-194

> >
> >>
> >> CSS3 Fonts @font-face description:
> >> [2] http://dev.w3.org/csswg/css3-fonts/#font-face-rule

> I think this is a layering violation.  The very concept of an origin
> has no relevance to a font format (this isn't EOT2).  This is entirely
> the responsibility of the API used to access the resource.  For
> example, a specialized program that uses wget to grab a font and
> specifically install it is a User Agent, but one that doesn't want to
> and doesn't need to pay attention to any sort of origin restrictions
> (there may be further legal restrictions dealing with installing or
> using the font, but that's a separate matter).

The proposed language aims to clarify that the font downloaded in a WOFF format is not supposed to be installed as a system font, and can only be used temporarily for a document that it is associated with. It has nothing to do with the origin or origin restrictions to that matter. I can see your point about specialized program being by itself a UA but to be compliant with this requirement it can install a font and remove it later when it's no longer needed.

> @font-face defines how it acts by itself.  That's all we need.  If a
> browser isn't willing to enable same-origin restrictions for
> @font-face in general, they almost certainly won't do it for WOFF
> specifically.

Again, this has nothing to do with same-origin restriction. The CSS description of @font-face rule says that downloaded fonts must not be made available to other applications or other documents - I proposed that WOFF spec should reiterate the same concept, with reference to CSS spec.


Received on Tuesday, 22 June 2010 19:48:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC