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

It’s not clear you understand either the current same-origin implementations or the new From-Origin proposal. In both cases the restriction is based on a the value of a response header. A new implementation running against an existing page that requests a font from a different origin will fail unless the latter returns the proper header.

>However, from a forward compatibility perspective, the introduction of mandatory same origin presents a problem for fielded implementations with
>respect to claims of conformance. While prior implementations could have claimed conformance on the basic features of css3-fonts, they no longer >can claim conformance for css3-fonts+mandatory-same-origin without retrofitting.
First, this is true for all breaking changes made for css3-fonts since that implementation fielded. Second, the impact on existing content, web authors and end-users is exactly zero. Existing implementations will load existing content the way they always have ensuring there is no impact on the web. It’s not clear why the non-conformance of an *experimental* implementation should matter.

To quote the latest CSS snapshot [1]:

“Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental.”

Thus your implementation is no less experimental than others before or since. The status of the document has always stated:

“Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.”

In order to be taken seriously, your objection should at least address these explicit and longstanding disclaimers.

[1] http://www.w3.org/TR/css-2010/#experimental


>In our view, the published spec needs to serve multiple purposes that span a significant amount of time. One purpose, and I would argue the primary
>purpose of css3-fonts is: to advance the state of affairs from what was defined in CSS2 in 1998. The other purpose, which has been introduced of late,
>is to introduce same origin. I expect css3-fonts to treat both of these cases and do so without necessarily introducing requirements from the second
>purpose into the primary purpose.
Your view is that the age of the draft should be significant. That claim may of course be convenient but has no basis. A draft is no more than that: a draft. It certainly is not and shouldn’t be a goal for any draft to accommodate a decade’s worth of experimental implementations when there are no way to even assess their actual level of conformance with any part of the specification. As pointed out in all CSS specs, it is inappropriate to refer to these drafts as nothing more than a work in progress.

We may however consider existing content e.g. when it is known that existing content depends on historical unprefixed implementations. As pointed out several times before, existing content designed for same-origin UAs will load as-is in cross-origin UAs. Existing content intended to load across origins will continue to load in those UAs that supported cross-origin font requests.

>As to the comment below, yes, I wish to allow for new browsers that do not require same origin. I would note, however, that as presently defined,
>HTML5 does require same-origin on web font resource access along with other resource types. We are fine with that position, and we continue to >argue that placing a same-origin restriction in css3-fonts or WOFF is architecturally unsound and inconsistent with existing CSS specs.
HTML5 depends on css3-fonts for this requirement as explicitly pointed out by the inline reference in the prose. But if you’re fine with HTML5 requiring same-origin, how does that fit with your desire to allow new browsers to support cross-origin?

Your entire argument so far had been based on compatibility with your existing installed base; now we’re talking about future browsers that would allowed to be incompatible with HTML5? I’m sorry Glenn, but at this point I have no idea what ‘position’ you are ‘fine’ with as you’re leaving us with an awfully confused and contradictory muddle.

Asserting that something is architecturally unsound does not make it so. You must elaborate on why you believe that to be the case as well as the harm that would result for implementors of said architecture. Same for the inconsistency with other CSS specs; given that @font-face is only defined in one module, inconsistency with the rest of CSS says little that is meaningful or actionable. Why should the required runtime behavior of the src descriptor of @font-face be defined outside css3-fonts ?

>At this point, I've repeated my same arguments over and over about three or more times, so I'm becoming rather tired of restating the same points
Not really. You’ve repeated several times this breaks backward compatibility with existing implementations. Now the issue is forward compatibility with future ones; but while you’re OK with HTML5 requiring same-origin for fonts you also want to allow browsers to not require it, which, to be honest, amounts to little that makes any practical sense.

What is indeed tiresome is your complete and persistent glossing over any facts or countervailing argument that is inconvenient to the credibility of your case e.g.:

-          Two major browsers (IE9, Firefox) already implement this requirement; as such, you should be able to demonstrate forward compatibility issues and/or impact of this change with real-world examples. Likewise for other UAs which are thus non-conformant.

-          You have been asked to explain why and how your proposal improves the web for authors and end users. You have also been asked whether and how the proposed change harms end users or web authors. No substantial answer has been provided beyond arm-waving about conformance; except we no longer can tell whether it’s conformance with past or future implementations.

Most importantly, it has been pointed out that pages built for same-origin UAs will run fine in browsers that do not enforce same-origin restrictions. As long as the former browsers exist authors will enforce this restriction on their content in order to reach all users. By proposing language that endorses either behavior based on arbitrary ill-defined criteria, you are offering to standardize the status quo; same-origin browsers conform and will stick to what they do. Other browsers will do the same. This means the best practice for authors will be to conform to the exact requirement you’re formally objecting to. It thus seems Samsung deems it critical to *not* standardize what every author will *have* to do.

>I will just conclude that Samsung will continue to maintain a formal objection to the current language in css3-fonts and WOFF drafts.
If Samsung objects to this language then you should also object to HTML5.

>We believe the correct course for both of these specs is to NOT specify *any* mandatory requirements related to access control, and to leave that up
>to the definers of UA specs, such as HTML5
So you are saying that HTML5 should define font loading behavior, thus creating a dependency from css3-fonts on HTML5. An explanation on how that is architecturally sounder than the current setup would be helpful and, in all likelihood, will be required of you as this progresses.

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





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

First, I must correct the term I had previously used. Speaking more precisely, it is forward compatibility, and not backward compatibility that is the issue. Clearly, a newer implementation with same-origin will not apply restrictions in the absence of an Origin header, so, sensu stricto, there isn't a backward compatibility issue for new same-origin based processing.

However, from a forward compatibility perspective, the introduction of mandatory same origin presents a problem for fielded implementations with respect to claims of conformance. While prior implementations could have claimed conformance on the basic features of css3-fonts, they no longer can claim conformance for css3-fonts+mandatory-same-origin without retrofitting.

If css3-fonts had been published in a more reasonable period of time, instead of dragging on for ten years, then it is likely there would be an existing spec that did not have same origin restrictions, since this was added only recently. In such a case, those earlier implementations might continue to claim conformance with such a hypothetical (pre-same-origin) spec. However, this will not be possible with a css3-fonts+mandatory-same-origin spec.

In our view, the published spec needs to serve multiple purposes that span a significant amount of time. One purpose, and I would argue the primary purpose of css3-fonts is: to advance the state of affairs from what was defined in CSS2 in 1998. The other purpose, which has been introduced of late, is to introduce same origin. I expect css3-fonts to treat both of these cases and do so without necessarily introducing requirements from the second purpose into the primary purpose.

I would also note that none of the other CSS specs that entails referencing of resources, e.g., via @import, image references, replaced content references, etc., require or even make reference to same-origin semantics. Having css3-fonts be an exception is not consistent with existing CSS specs practice, particularly when css3-fonts is intended to reference more than just WOFF fonts.

As to the comment below, yes, I wish to allow for new browsers that do not require same origin. I would note, however, that as presently defined, HTML5 does require same-origin on web font resource access along with other resource types. We are fine with that position, and we continue to argue that placing a same-origin restriction in css3-fonts or WOFF is architecturally unsound and inconsistent with existing CSS specs.

At this point, I've repeated my same arguments over and over about three or more times, so I'm becoming rather tired of restating the same points. I will just conclude that Samsung will continue to maintain a formal objection to the current language in css3-fonts and WOFF drafts. We believe the correct course for both of these specs is to NOT specify *any* mandatory requirements related to access control, and to leave that up to the definers of UA specs, such as HTML5. 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).

Regards,
Glenn
On Mon, Jun 27, 2011 at 3:18 PM, John Hudson <tiro@tiro.com<mailto:tiro@tiro.com>> wrote:
Glenn wrote:
This is why I offered alternative language that would permit those existing implementations to remain conformant while requiring new implementations (e.g. HTML5 UAs which otherwise require same origin) to implement same origin to be conformant.

As I understand your suggestion, Glenn, it does more than permit existing implementations to remain conformant. It seems to leave open the door to new implementations not supporting same origin for webfonts if they do not support same origin for other purposes.

JH