- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 27 Jun 2011 17:58:13 -0600
- To: John Hudson <tiro@tiro.com>
- Cc: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>, Sylvain Galineau <sylvaing@microsoft.com>, liam@w3.org, StyleBeyondthePunchedCard <www-style@w3.org>, public-webfonts-wg@w3.org, www-font@w3.org, "Martin J." <duerst@it.aoyama.ac.jp>
- Message-ID: <BANLkTinvUy3eDuSNnaq6hgCK83wvBQeFPg@mail.gmail.com>
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> 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 >
Received on Monday, 27 June 2011 23:59:01 UTC