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

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.****
>
> ** **
>