- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Wed, 29 Jun 2011 06:02:03 +0000
- To: Glenn Adams <glenn@skynav.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: <3C4041FF83E1E04A986B6DC50F0178290BCB31@TK5EX14MBXC297.redmond.corp.microsoft.co>
Glenn, You’ve formally objected before making any substantial attempt to present a coherent point of view and obtain a group consensus for or against your preferred course of action. Negotiating after preemptively slamming the biggest door in the room is no easier than building consensus under threat. Attempting both at the same time was a significant tactical blunder on your part. Your mistake. "If a user agent that makes normative use of this specification includes a same-origin policy, then that policy, and the mechanisms it uses to enforce that policy should apply to the loading of fonts via the @font-face mechanism." In general, this proposal is somewhat nonsensical since neither css3-fonts nor WOFF ever suggested the same-origin policy should apply to anything but fonts loaded by @font-face. As such, it only reiterates the current requirement stated in the css3-fonts ED: User agents must implement a same-origin restriction when loading fonts via the @font-face mechanism. [1] Second, it has been pointed out that making this behavior optional is what we already have in the marketplace: some browsers do this, some do not. The aim of this WG is to resolve this incompatibility. As such, proposals to entrench the problem are understandably of little interest. The real world demonstrates nothing needs to be done to achieve that outcome ! "move same-origin requirements from WOFF and CSS3-FONTS to HTML5 or another definition of a UA that actually performs access functions" You have to explain how moving the problem around fixes or improves anything. Since you raised issues of separation of concerns and architectural soundness, you also have to argue why this belongs to HTML more than it does in css3-fonts, the runtime interoperability of which is fundamentally impacted by whether or not a UA does or doesn’t load a specified font resource. Be that as it may, no css3-fonts FO you file could automatically result in this requirement moving to HTML5 without the HTML WG’s approval, as far as I know. No one here stops you from proposing this to the HTML WG. Until you do so and get a response, this suggestion is entirely theoretical. "If the use of WOFF occurs in a context where same origin access constraints are *already* present/supported, then that mechanism *must* be used to limit access to WOFF fonts; otherwise, such a mechanism *should* be provided for such use." This is really a variation on the first one i.e. making what you don’t want optional so you don’t have to care about it. "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)." As you point out, this is a reiteration. It’s clear you believe those to be more than variations on the same theme. On the receiving end and for my part, not really. Regarding: * why is it unacceptable to define these requirements solely in HTML5 or another (new) UA specification? * why is it unacceptable to allow existing UAs that do not implement same origin to choose to not implement same origin except to merely be compliant with a mandatory same origin requirement that applies *only* to @font-face fetches? The first one of these has been addressed multiple times. To name but two: 1. Whether this can be required in HTML5 is not up to this WG or the CSSWG but the HTML WG. You’re asking the wrong group. 2. The burden is on you to establish why it would be better to move this requirement elsewhere vs. specifying it where it matters most. As this behavior has a very direct impact on @font-face interop you must explain why we – this WG, the CSS WG, implementors, authors etc – are better off moving it away from css3-fonts. You’ve been asked several times why having css3-fonts implementations differ at runtime based on their level of HTML5 support was helpful. No substantive answer that I could find. The second question is both quite puzzling and very interesting. The proposal, all along, has been to scope the same-origin restriction requirement to those requests originating from the src descriptor of @font-face rules [1]. Nothing more. There *never* was any expectation that same-origin would apply outside this context. So you’re asking why our own plan and draft are unacceptable!? I’m cautiously hoping this means you’ve misunderstood the actual scope of this feature all along but that also seems far too easy. It’d be great though. [1] http://dev.w3.org/csswg/css3-fonts/#same-origin-restriction From: Glenn Adams [mailto:glenn@skynav.com] Sent: Tuesday, June 28, 2011 9:37 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 Tue, Jun 28, 2011 at 8:13 PM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote: It’s good that you’re not fixated on a particular objective but, fwiw, that is the exact perception you have created i.e. you are here to achieve your own ends and screw what others think. First, by appearing to show up for the purpose of formally objecting, as pointed out above. I don’t think it’s unreasonable for a relative stranger to get a different reception from as strong a signal as a FO vs. a regular, known contributor. Second, by using the word compromise a lot and never appearing to try finding one. Compromise starts with making a proposal but it doesn’t end there. It requires listening to feedback, addressing that feedback, adjusting the proposal iteratively through a two-way conversation. Instead, you made a proposal, almost immediately labeled it a compromise and generally stuck to it not only in the face of genuine issues but in the absence of any support for it from anyone else. Thus the message you sent was that your first proposal was also your final one i.e. ‘take it or leave it’. The overall substance and tone of your position being that you will not give anything away: either we bend, or you object. In my initial comment in this thread [1], I expressed an objection to *any* policy specified in css3-fonts w.r.t. mandating same-origin in the css3-fonts spec. [1] http://lists.w3.org/Archives/Public/www-style/2011Jun/0476.html I then proposed alternative language at [2] that permitted a *should* requirement in css3-fonts: "If a user agent that makes normative use of this specification includes a same-origin policy, then that policy, and the mechanisms it uses to enforce that policy should apply to the loading of fonts via the @font-face mechanism." [2] http://lists.w3.org/Archives/Public/www-style/2011Jun/0478.html I then offered a number of additional procedural options in [3] that would remove our objection, including one that would move the existing requirements to HTML5 but maintain them as stated: "move same-origin requirements from WOFF and CSS3-FONTS to HTML5 or another definition of a UA that actually performs access functions" [3] http://lists.w3.org/Archives/Public/www-style/2011Jun/0488.html I then offered another alternative expression (of the basic WOFF restriction) in [4] that would mandate same origin restriction in existing or new UAs that already support same origin: "If the use of WOFF occurs in a context where same origin access constraints are *already* present/supported, then that mechanism *must* be used to limit access to WOFF fonts; otherwise, such a mechanism *should* be provided for such use." [4] http://lists.w3.org/Archives/Public/www-style/2011Jun/0612.html I reiterated this position in a somewhat broader context at [5]: "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)." [5] http://lists.w3.org/Archives/Public/www-style/2011Jun/0668.html It is quite clear to any casual reader that I have been attempting to find language that would satisfy this group's position. I started with a hard position (no reference to same-origin) and ended up with a much softer position (permit conditional mandatory requirement to remain in these specs). If this is not an attempt to reach a compromise, then I don't know what is. Now, what has the group's response been? It has been to repeatedly fail to seriously consider any of these proposed alternatives, without much more explanation than saying: i'm unreasonable, i'm inconsistent, i don't care about the interests of authors, users, implementers, i'm trying to break the group's progress, etc. When the group actually takes up one of my proposed alternative and considers it seriously, then perhaps I will feel the group has done due diligence on this issue. But I do not get that sense at this time. All I get is a sense that I'm an outsider whose position, because it appears to be contrary to what the group had previously thought settled, is not worth considering and should be dismissed out of hand. For example, * why is it unacceptable to define these requirements solely in HTML5 or another (new) UA specification? * why is it unacceptable to allow existing UAs that do not implement same origin to choose to not implement same origin except to merely be compliant with a mandatory same origin requirement that applies *only* to @font-face fetches? Now, if I may go back to the language cited by John Huston, viz. <quote> The Webfonts working group chartered deliverables include, in addition to the WOFF spec, a WebFont conformance specification This specification will reference the font formats in existing use (OpenType, WOFF, SVG, and EOT), the font referencing and linking specifications (in both CSS and XML serialisations), access policies such as same-origin and CORS, and define which linking mechanisms, policies and formats are required for compliance. WOFF will be the required format for compliance, the others being optional. The Working Group will decide whether to make the formats and linking mechanisms normative references or, on the other hand, produce a document citable by other specifications (CSS3 Fonts, XSL, SVG) when claiming conformance. </quote> I do not see any mandate in this description for same origin. I see a statement that the WG will "define which ... policies ... are required for compliance". I do not see a charter derived mandate for a specific policy. If the WG has previously made a determination to mandate universal application of same-origin policy, then it need not have done so, at least from the perspective of this charter language. That means that a proposal such as Samsung's, to use a fractionally weaker policy, should be possible as well. I also note that the above charter foresees the possibility of "on the other hand, produce a document citable by other specifications (CSS3 Fonts, XSL, SVG) when claiming conformance". I indicated in my prior comments [3] that Samsung could accept: "move same-origin requirements from WOFF and CSS3-FONTS to a third "WebFonts Conformance Specification" Again, this proposal does not appear to have been seriously considered either. Of course, if this last option were used, we would still like (but not insist) on an exception for pre-existing, non-same-origin UIs as expressed in [5] as cited above. But we could live with this scenario, and it would give us our original desired position of moving such requirements out of css3-fonts and woff specs. I have offered a number of softer solutions to my original comment. I consider these to be compromises on Samsung's part in order to reach some form of closure. I suggest that instead of discussing this matter further in this thread, that the respective groups go consider these proposals at their face value and determine if a solution is possible that resolves our objection and that can still meet the needs of the groups. Regards, Glenn From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>] Sent: Tuesday, June 28, 2011 5:13 PM To: Sylvain Galineau Cc: John Hudson; Levantovsky, Vladimir; liam@w3.org<mailto:liam@w3.org>; StyleBeyondthePunchedCard; public-webfonts-wg@w3.org<mailto:public-webfonts-wg@w3.org>; www-font@w3.org<mailto:www-font@w3.org>; Martin J. Subject: Re: css3-fonts: should not dictate usage policy with respect to origin Well Sylvain, you are at least consistent in mis-attributing incorrect intentions to the position I represent. To be clear: * Samsung has no interest in blocking the work of the WG, and fully supports the group's work; * Samsung has no interest in preventing font authors or font providers from protecting access to their intellectual property; we note there are various ways of achieving content protection and digital rights management; * Samsung is not fixated on a specific result from the group, and is willing to consider any reasonable option that addresses our concern; * Samsung believes the issue is whether an existing implementation of @font-face that does not employ same origin can claim conformance to a final, published REC that wishes to apply the same origin mandate to all implementations, whether new or old; the issue of whether such an old implementation is "experimental" or merely "early" is unrelated to our concern, since it is desirable to (finally) have a complete and final specification for @font-face that can be referenced by industry compliance testing and compliance certification processes; * if the group can find a way to effectively address this concern, then we will be happy to remove our objection; G. On Tue, Jun 28, 2011 at 5:46 PM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote: Well, if we have fallen into ad-hominem – and your opening paragraph seems to indicate we have indeed - then I am confident the sum of all your positive and constructive contributions to this WG will prove you to be the innocent victim of my unfairness. “Unless I observe a change in position” In other words, unless the group does what you want you will take action to block progress of their work. Given that you’ve made a single proposal and essentially ignored all substantive questions or issues that were raised, should you be surprised by the lack of progress ? You aim to force a group to comply with your demand for no other reason that you’ll formally object if it doesn’t. I give you credit for clarity, at least: you don’t waste any time pretending to care about anything or anyone else. It’s certainly one way to participate in the standard process but please, let’s at least have the decency to not act bothered when it causes some friction, as if formal objections never caused any heated exchanges. (Although the heated disagreements usually lead to the FO, not the other way around, so maybe this constitutes innovation). As a new draft would not force any existing implementations to support same-origin restrictions, your objection remains without basis. Same-origin support would only be required for a new implementation that also wants to conform with the latest draft.…until the next draft makes it non-conformant in some other way. Since working draft implementations are experimental, that is expected and normal. (At least for active CSSWG members and implementors). Last, since css3-fonts is under the CSSWG charter may I suggest your register your objection through the CSSWG mailing list at www-style@w3.org<mailto:www-style@w3.org> ? Not everyone in the latter follows the Fonts WG mailing list. Thank you. From: public-webfonts-wg-request@w3.org<mailto:public-webfonts-wg-request@w3.org> [mailto:public-webfonts-wg-request@w3.org<mailto:public-webfonts-wg-request@w3.org>] On Behalf Of Glenn Adams Sent: Tuesday, June 28, 2011 3:18 PM To: Sylvain Galineau Cc: John Hudson; Levantovsky, Vladimir; liam@w3.org<mailto:liam@w3.org>; StyleBeyondthePunchedCard; public-webfonts-wg@w3.org<mailto:public-webfonts-wg@w3.org>; www-font@w3.org<mailto:www-font@w3.org>; Martin J. Subject: Re: css3-fonts: should not dictate usage policy with respect to origin Sylvain, This thread appears to be spiraling into ad hominem. It is clear that you believe yourself the self-appointed spokesman for the entire web in these matters, that you believe you can read my mind and announce my intentions, and that you must have the last word no matter what. It is also clear that you are not interested in considering any form of compromise to accommodate our position. It would be pointless to respond further, so, unless I observe a change in position, I will maintain Samsung's objection to mandating same-orign requirements in css3-fonts and/or woff for UAs that do not otherwise implement same origin access controls. Glenn On Tue, Jun 28, 2011 at 3:43 PM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote: My bad for taking a point you made earlier and extrapolating from that css3-fonts reference (“I would note, however, that as presently defined, HTML5 does require same-origin on web font resource access along with other resource types.” in http://lists.w3.org/Archives/Public/www-style/2011Jun/0668.html). But since HTML5 does *not* define any origin policy for fonts and you argue that is where it should be interoperably defined, how is that going to happen without raising the issue with the HTML WG ? As the spec is heading for Last Call it would seem important to raise the issue soon. (Although a formal objection would not indeed seem necessary if HTML5 does not require this, despite your original claim). Given that your sole contribution to this mailing list and WG has been to show up to throw a sudden formal objection by making a series of incoherent and self-contradictory arguments – as if to see which one could stick, really - given that you are actively opposed to the consensus and goals of this WG, given that you haven’t even once bothered to show interest about the impact of your approach on the WG’s work, on other members, on the web, web authors or users, you have precious few grounds to expect the position you represent to be welcomed as a positive and meaningful contribution. In addition, given that you have persistently evaded or ignored others on those issues they care about, given that I have no concrete reason to believe as of yet that your goal is to contribute in a manner that is meaningful and positive for the work of the group, I have been as civil as I feel justified under the circumstances. Were you expecting a thank you note ? From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>] Sent: Tuesday, June 28, 2011 11:26 AM To: Sylvain Galineau Cc: John Hudson; Levantovsky, Vladimir; liam@w3.org<mailto:liam@w3.org>; StyleBeyondthePunchedCard; public-webfonts-wg@w3.org<mailto:public-webfonts-wg@w3.org>; www-font@w3.org<mailto:www-font@w3.org>; Martin J. Subject: Re: css3-fonts: should not dictate usage policy with respect to origin On Tue, Jun 28, 2011 at 11:22 AM, Sylvain Galineau <sylvaing@microsoft.com<mailto:sylvaing@microsoft.com>> wrote: 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 ? Again, you are wrong. HTML5 only refers to css3-fonts once, in the following: For fonts The origin<http://dev.w3.org/html5/spec/Overview.html#origin> of a downloadable Web font is equal to the origin<http://dev.w3.org/html5/spec/Overview.html#origin> of the absolute URL<http://dev.w3.org/html5/spec/Overview.html#absolute-url> used to obtain the font (after any redirects). [CSSFONTS]<http://dev.w3.org/html5/spec/Overview.html#refsCSSFONTS> This says nothing about using css3-fonts to define same origin behavior. You know Slyvain, I don't know you, but I have not impugned your knowledge or reasonableness in this thread. On the other hand, every contribution of yours to this thread has been expressed to one degree or another in an ironic and frankly, a contemptuous tone. You should try being civil for a change. G.
Received on Wednesday, 29 June 2011 06:02:47 UTC