- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 27 Jun 2011 23:58:56 -0600
- 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>
- Message-ID: <BANLkTikYry9b-pOsMptyjBBumuhXCGghUw@mail.gmail.com>
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 UTC