W3C home > Mailing lists > Public > www-style@w3.org > June 2011

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

From: Glenn Adams <glenn@skynav.com>
Date: Mon, 27 Jun 2011 23:58:56 -0600
Message-ID: <BANLkTikYry9b-pOsMptyjBBumuhXCGghUw@mail.gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: John Hudson <tiro@tiro.com>, "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>, "liam@w3.org" <liam@w3.org>, 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>
On Mon, Jun 27, 2011 at 8:01 PM, Sylvain Galineau <sylvaing@microsoft.com>wrote:

>
> ****
>
> >However, in the interest of compromise, we are willing to drop the
> objection if the language is changed to require same-origin only in the **
> **
>
> >case that the UA already requires it (due to other requirements).****
>
> As pointed out earlier – and, of course, ignored by you – such language is
> normatively meaningless and untestable.
>

Wrong. It is both meaningful and easily tested.

(1) determine if UA implements same origin restriction on a non-WF resource
known to be subject to same origin restriction (as normatively mandated by
the spec to which UA claims conformance), e.g., a JS resource fetched when
processing a script element on an HTML5 UA; easily tested by using a cross
origin reference with restrictive headers; if access succeeds, then record
as 0 (no restriction), otherwise 1 (restriction applied);

(2) determine if UA implements same origin restriction on a WF resource,
e.g., use a cross-origin reference on a WF, recording success (no
restriction) as 0, otherwise 1 (restriction applied);

(3) using following truth table, assess whether or not UA implements
conditional mandatory requirement to support same origin  on WF fetch
predicated on existing support for same origin on non-WF fetch:

Step 1   Step 2
  0        0        // conforming behavior
  0        1        // conforming behavior (note 1)
  1        0        // non-conforming behavior (note 2)
  1        1        // conforming behavior

Note 1: permissible for UA to enforce same origin on WF fetch even in
absence of enforcement on non-WF fetch;
Note 2: this is a direct affect of the alternative language I proposed,
i.e., that same origin must apply for WF fetch if UA already supports WF,
the violation of which would result in non-conformance;



> In order to achieve a compromise one needs a defensible position that is at
> least understandable by others. Until you’ve been able to make at least some
> members of the WG reach a level of understanding and agreement about the
> issue you’re trying to resolve, offers of compromise are only helpful when
> they clarify your position. When the compromise is to say ‘css3-fonts does
> not define whether and how @font-face loads fonts and leaves it to HTML5
> which shall allow all the incompatible behaviors currently implemented’, it
> seems we don’t have any actionable compromise.
>

CSS3 Fonts does not fetch resources any more than CSS @import and CSS
background="url(...)" do not fetch resources. These mechanisms define how
resources are referenced. A UA which employs and supports CSS does the
fetching and defines fetch semantics. CSS does not define how fetch works or
how access control works in conjunction with fetching. Or at least, CSS does
not do so outside of the proposed language being discussed here.

If you can't follow this logic, then I'm not sure how I can improve your
understanding of the position I am representing.

G.
Received on Tuesday, 28 June 2011 05:59:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:41 GMT