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

inline

On Thu, Jun 23, 2011 at 3:30 PM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotypeimaging.com> wrote:

> Glenn,****
>
> ** **
>
> Thank you for further clarifying your position and for your willingness to
> work towards finding a mutually acceptable solution. I understand your
> concerns regarding UA implementation in CE devices that may not have the
> same update / release cycle as PC-based products, and where new features
> take time to implement.****
>
> ** **
>
> I am wondering what is the current status of @font-face support by this
> class of UAs. Do you know if @font-face is fully supported by a majority of
> CE-based clients, or do most still support only a subset of @font-face
> command?
>

I'm not sure what you mean by "fully", or whether this is a relevant
question.

I do know that a number of interactive television standards include and
require support for the @font-face rule, as defined in CSS2. See, for
example, ATSC DASE-1 Part 2 Section 5.2.1.5 [1] and ETSI TS 102 727
(DVB-MHP) Section 8.8.6 [2]. This mechanism was implemented by devices
deployed in a number of countries in digital television broadcasting,
satellite, and cable, including the US, Korea, and Europe.

[1] http://www.atsc.org/cms/standards/a100/a_100_2.pdf
[2]
http://www.etsi.org/deliver/etsi_ts/102700_102799/102727/01.01.01_60/ts_102727v010101p.pdf


> Until recently it was highly unusual for many CE user agents to support
> downloadable font (via @font-face-src) due to various constraints, and those
> that did support downloadable fonts in general would do so using various
> delivery mechanisms (such as e.g. DSM-CC object carousel in broadcast TV
> environments).
>

The delivery mechanism is independent of the referencing mechanism and font
file formats., So this isn't relevant.


> Once delivered, a font could then be used the same way as resident fonts,
> so it would essentially be considered a local resource that is not subject
> to any origin restrictions.
>

Of course, this is true for both CE devices and desktop UAs. However, using
fonts in this fashion was certainly not implemented in CE devices even
though it was technically possible.


> If most of CE-based UAs do not currently support @font-face-src attribute,
> then maybe an easier way to find an agreeable compromise would be to make it
> clear that same-origin restriction is only applicable to downloadable fonts
> loaded via HTTP using @font-face rule.
>

I'm not sure what you mean by "@font-face-src attribute". If you are
referring to the src descriptor as used with @font-face, then support for
this descriptor is required by the standards I cited above, and therefore,
implemented by devices that support those standards.

These implementations do not support same origin restrictions, as the
definition of same origin did not exist at the time those standards were
published.


> Those clients that do not support this loading behavior (or when a
> downloadable font is loaded using other mechanisms) need not be concerned
> with same origin restrictions. Would this be an acceptable way to find a
> compromise solution that would eliminate the grounds for your objection?
>

If some compromise language can be found that does not require UAs that do
not otherwise implement same origin to use WOFF or CSS3-FONTS without adding
same origin, then Samsung will support that language and drop our objection.

Any language that requires an HTML4 or XHTML1 class UA that does not
implement same origin but wishes to support use of WOFF or CSS3-FONTS and by
the mere inclusion or use of these two specs requires the addition of same
origin restrictions will remain a problem for Samsung. If a device
implementer that uses such a UA wishes to support same origin restrictions,
that is up the the implementer; however, mandating that mere support of WOFF
requires same origin in such UAs will not work for us.

That is why we propose language that requires a UA to use same origin with
WOFF only for those UAs that already do or would support same-origin for
other means.

So, to reiterate what we can agree to:

   1. if UA already implements same origin (for whatever reason), then same
   origin *must* apply to @font-face fetches;
   2. otherwise, if UA implementer wishes to support same origin on
   @font-face fetches, then they may do so;
   3. otherwise, UA implementer need not support same origin on @font-face.

We also would be willing to agree to new conformance language on @font-face
fetches that requires all UAs to take reasonable steps to prevent local,
persistent storage of such font resources other than in the UA's cache, and,
if cached, to take reasonable steps to prevent copy or use access to those
resources by other applications or the end user.

G.



> Thank you,****
>
> Vladimir****
>
> ** **
>
> ** **
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Thursday, June 23, 2011 4:22 PM
> *To:* Sylvain Galineau
> *Cc:* liam@w3.org; 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****
>
> ** **
>
> 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.****
>
>  ****
>
> ** **
>