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

So on the one hand ‘CSS3 Fonts does not fetch resources’ but the css3-fonts testsuite will need script to test which fetching behavior is in place in order to be able to run its testcases. You’re correct, it is unlikely I will be able to understand how this is a clear improvement over standardizing a single unambiguous behavior. Or why we should not mandate the very requirement every single web author will have to conform to in practice in order for her content to reach all users. Arguing css3-fonts should not require what everyone will need to comply with every time they use @font-face as a result of your own proposed language is absurd.

CSS3 Fonts *must* define the behavior needed to produce two interoperable implementations. Whether a font resource loads by default or not is not an optional side-effect of the feature, it is fundamental to achieving interoperable results across UAs. The latter are the results we are judged against as implementors and as WGs. Specs are a means to achieving interop, no more no less. Defining all the requirements needed for interoperability across more documents than needed has a real cost for all involved that requires justification beyond the sake of theoretical purity.  You’re not providing any substantial argument, however.  Why are font fetching semantics more appropriate in HTML5 ? Why is access policy so obviously a markup language issue ? Why should the ability of a css3-fonts implementation to load a given font resource differ according to whether or not the UA also implemented a specific HTML5 requirement ? Why does making the behavior of a CSS feature depend on HTML in this manner an improvement over defining that behavior in CSS ? More importantly, for *whom* is your proposal an improvement ? Authors ? End-users ? How ?How and why are incompatible implementations – what we have today – better for them than interoperable ones ?

I wish I could at least understand how any of this benefits Samsung. All I can gather after all this confused and contradictory back-and-forth is that the tight coupling of concerns in a given document is more critical to Samsung than achieving actual interop for the web or improving on an incompatible status quo. Your offer is to either mandate the current incompatibility or move the requirement elsewhere without articulating any coherent reason to justify doing so, or why it belongs where you think it does.

In any case, I assume you will file a formal objection with all three WGs concerned. As HTML5 currently depends on css3-fonts to define this behavior and you clearly believe that to be incorrect, you will also object and demand that they define this behavior as part of HTML5, right ?

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Monday, June 27, 2011 10:59 PM
To: Sylvain Galineau
Cc: John Hudson; Levantovsky, Vladimir; liam@w3.org; 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


On Mon, Jun 27, 2011 at 8:01 PM, Sylvain Galineau <sylvaing@microsoft.com<mailto: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.