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

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

From: Glenn Adams <glenn@skynav.com>
Date: Thu, 23 Jun 2011 14:22:09 -0600
Message-ID: <BANLkTimwooZNUU9PDBGYfvyj94AW0f-O2Q@mail.gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: "liam@w3.org" <liam@w3.org>, "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>, StyleBeyondthePunchedCard <www-style@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, "www-font@w3.org" <www-font@w3.org>, "Martin J." <duerst@it.aoyama.ac.jp>
One must recognize that (1) UAs deployed in CE devices are not the same
category as PCs, which can be updated more easily; (2) css3-fonts has been
under development for an inordinately long time and the need for @font-face
implementations has existed since the beginning; (3) UAs *are* deployed that
use @font-face and that do not support HTML5 or same-origin.

These are facts that should be considered, and as a representative of a
company that has deployed such UAs, Samsung will continue to object to a
retroactive requirement on these UAs to support same origin. We do not,
however, have the same position for HTML5 category UAs that are now
appearing in the field.

Of course, a WG is entitled to change a non-final spec in a non-backward
compatible manner, but in doing so should take into account the impact of
such a change. Finally, I did not suggest such a generalization as you state
below.

I am attempting to find compromise language that Samsung can live with. Are
you interested in finding a compromise that can remove our objection or not?

G.

On Thu, Jun 23, 2011 at 2:11 PM, Sylvain Galineau <sylvaing@microsoft.com>wrote:

>  As a *draft* specifications, css3-fonts and WOFF can certainly define new
> requirements for future implementations. Your entire argument would imply
> that once a draft has been implemented future versions of the spec must be
> compatible with those implementations. This is not the way CSS works; no
> implementation that implemented a given draft is guaranteed conformance with
> the next one. The main motive for vendor prefixes is to allow specifications
> to evolve without breaking implementations. That historical implementations
> did not prefix their @font-face implementation should not block us from
> achieving both interoperability and desirable runtime behavior in future
> implementations.****
>
> ** **
>
> ** **
>
> *From:* public-webfonts-wg-request@w3.org [mailto:
> public-webfonts-wg-request@w3.org] *On Behalf Of *Glenn Adams
> *Sent:* Thursday, June 23, 2011 12:59 PM
> *To:* liam@w3.org
> *Cc:* Levantovsky, Vladimir; StyleBeyondthePunchedCard;
> public-webfonts-wg@w3.org; www-font@w3.org; Martin J.
>
> *Subject:* Re: css3-fonts: should not dictate usage policy with respect to
> origin****
>
>  ** **
>
> Samsung supports your suggestion below if it is expressed either as
> "should" or made conditionally mandatory, where the condition is expressed
> as follows or an equivalent:****
>
> ** **
>
> "If the use of WOFF occurs in a context where same origin access
> constraints are *already* present/supported, then that mechanism *must* be
> used to limit access to WOFF fonts; otherwise, such a mechanism *should* be
> provided for such use."****
>
> ** **
>
> We do not want the use of WOFF by itself, or css3-fonts, by itself, to
> trigger a mandatory requirement for same origin processing in contexts that
> don't already support such constraints. For example, in HTML4 or XHTML1
> category UAs that already support @font-face or that wish to support WOFF.
> ****
>
> ** **
>
> We note that the @font-face rule has been defined in css3-fonts since 31
> July 2001, and that a variety of UAs have been fielded in the non-desktop
> environment (e.g., mobile, television, etc), which employ @font-face for
> accessing other non-WOFF fonts, and do so without same origin restrictions.
> This would argue against introducing a non-backward compatible change in
> css3-fonts to mandate same origin processing for prior fielded
> implementations that do not otherwise support same origin. WOFF similarly
> should not by itself trigger mandatory support for same origin in such UAs.
> ****
>
> ** **
>
> G.****
>
> On Thu, Jun 23, 2011 at 11:30 AM, Liam R E Quin <liam@w3.org> wrote:****
>
> The WOFF spec could say in its conformance section (right in the spec,
> not in a separate document) that for use in style sheets (not only CSS)
> an implementation-defined mechanism should (must?) be available to limit
> access to the WOFF resource outside of support for the style sheets, and
> maybe give same-origin as an example.****
>
> ** **
>
Received on Thursday, 23 June 2011 20:23:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 June 2011 20:23:00 GMT