Re: DRAFT: WebFonts WG liaison to CSS WG

Ideally, loading behavior would be described consistently in another spec such that we could refer to that spec.  But it really doesn't, just as after all these years we're only now talking about a client-side mechanism to prevent cross-site linking.

I still think a very large part of the "let's put this in another spec" is motivated not by the desire to carefully delineate functionality in a modular way but as a mechanism to ignore it entirely.  George talked a lot about his desire as part of an outside consortium (set-top box group?) to refer to specs piecemeal.  Clearly, his reasoning was that if this was off in another spec his group could simply ignore it.  But for the web that doesn't resolve the problem at all, it just spreads the solution out in a larger number of specs.  Modularity is great when things are loosely coupled but if you're talking about the internals of how @font-face functions, I think it's important to keep that definition in one place.  Without that a test suite will be a tangled mess of conditional tests ("if UA supports Y, run tests A, B, C").

If we are going to resolve to ignore origin restrictions (I'm not recommending that!), a consensus or a majority of the group should advocate that and stop with the "push it out to another spec" dodge around the issue.  I think the CSS group will need to vote on this, since I don't see a consensus opinion emerging.  I thought we were close based on the discussions surrounding the From-Origin header but it seems like Opera is now pushing more strongly for the "separate spec" approach.

Cheers,

John


----- Original Message -----
From: "Sylvain Galineau" <sylvaing@microsoft.com>
To: "Vladimir Levantovsky" <Vladimir.Levantovsky@MonotypeImaging.com>, "3668 FONT" <public-webfonts-wg@w3.org>
Sent: Friday, June 24, 2011 3:30:31 AM
Subject: RE: DRAFT: WebFonts WG liaison to CSS WG




Yes, I should have read the minutes before commenting J 



There are many areas where HTML5 needs to define the behavior of the underlying platform (it’s hard not to when you describe APIs). For a CSS module to define this kind of low-level access policy is more unusual so we should expect more questions in this area. It can certainly be argued that if it is important for CSS3 Fonts implementation to interoperate then it ought to be in the spec. And while the feature natively supports fallback through a number of font formats and thus doesn’t need to mandate any format over another, there is no such fallback for SOR. An @font-face rule pointing to a set of cross-origin resources would either completely work or completely fail however valid it may be. Interoperability-wise, this is unattractive. 



I remain more concerned about objections to the default same-origin behavior we want to specify – or complete indifference to it – than those about which spec it lands into. If implementors do agree to enforce same-origin by default then we will converge wherever the normative requirement eventually gets written; IE and Firefox have already converged in this respect with no standard document requiring them to do so, for one. But given the philosophical nature of some of the arguments, I doubt we’ll obtain interop by spec fiat on this. So I suggest we keep working on agreeing as to what we want to write, as in: a plurality of implementors do agree to implement it in their UA, and then worry about where the prose lands, in that order. 






From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-request@w3.org] On Behalf Of Levantovsky, Vladimir 
Sent: Thursday, June 23, 2011 10:18 AM 
To: Sylvain Galineau; 3668 FONT 
Subject: RE: DRAFT: WebFonts WG liaison to CSS WG 



Thank you, Sylvain. 



I agree that WebFonts conformance specification is needed and would be the right place to define what the “conformant WebFonts UA” is including any requirements that involve multiple external specifications. I am not sure though that this would be the right place to define the loading behavior of @font-face rule, it seems logical that this would be defined in the same place where the rule itself is defined – in CSS3 Fonts module. We talked about it yesterday during the telcon, and it seems consistent with the current practice of e.g. how a loading behavior for images is defined in HTML5 spec ( http://dev.w3.org/html5/spec/embedded-content-1.html#attr-img-crossorigin ). I would expect that a similar description should be appropriate (and even necessary) part of CSS3 Fonts module for a resource embedded using @font-face-src attribute. 



Thoughts? 
Thank you, 

Vlad 








From: Sylvain Galineau [mailto:sylvaing@microsoft.com] 
Sent: Wednesday, June 22, 2011 5:28 PM 
To: Levantovsky, Vladimir; 3668 FONT 
Subject: RE: DRAFT: WebFonts WG liaison to CSS WG 



Again, my apologies for missing the call today. No excuses :( 



As you know the CSS WG did discuss this and it does seem awkward for CSS3 Fonts to define a specific protocol-level mechanism to handle this. Moreover, our charter [1] included a conformance specification that covered ‘access policies such as same-origin and CORS’, a deliverable that was separate from CSS3 Fonts. 



I understand that for all intent and purposes this WG only cares about WOFF and other formats loaded through @font-face so requiring same-origin in CSS3 Fonts does seem attractive. But I’m not sure protocol-level access policy is any more the scope of CSS3 Fonts than file formats ever were, or should be. 



I think of Web Fonts conformance as a superset of CSS3 Fonts i.e. conformance with the latter is necessary but not sufficient. Just like we agreed long ago it’s not OK to only support SVG fonts, one must support WOFF: this not something CSS3 Fonts can mandate either. Our conformance spec was also supposed to address this exact agreement (‘WOFF will be the required format for compliance, the others being optional’). 



From-Origin or CORS, WOFF and CSS3 Fonts: conformance with all three pieces cannot really be required by any of the three; they are and should imo remain orthogonal to each other. Doesn’t this WG define how these three, or four or however many specs define a conformant web fonts UA ? 



[1] http://www.w3.org/2009/08/WebFonts/charter.html 






From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-request@w3.org] On Behalf Of Levantovsky, Vladimir 
Sent: Wednesday, June 22, 2011 8:59 AM 
To: 3668 FONT 
Subject: DRAFT: WebFonts WG liaison to CSS WG 



Hello WG, 



Please see below the draft text of the liaison. I would like to discuss this today during the telcon, your comments are very much appreciated. 



Thank you, 

Vlad 





WebFonts WG would like to thank the CSS WG for allocating the time for a detailed discussion of same-origin restriction during the most recent CSS WG meeting ( http://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html ). 



WebFonts WG has been working hard to finalize the text of the WOFF 1.0 specification, where the requirement for same-origin restriction was originally placed according to the group charter. The WG has agreed that same-origin restriction is a very useful feature that plays an important role in advancing the state of the art typography on the web, and that it also facilitates the use of high quality fonts by helping authors to comply with most typical web font license conditions without any additional overhead. As part of the original WOFF specification work, the same-origin restriction is also believed to be a significant factor that influenced a wide-spread offering of commercial fonts for web use. 



Even though the WG reached a consensus on same origin restriction and the use of CORS[2] as a way to relax it, the discussion continued as new proposals (such as “From-Origin” proposal from Anne van Kesteren [3]) and other considerations [4] were brought up. As a result, we strongly believe that these features are indeed useful and necessary but will be best addressed in the CSS3 Font module. We believe that same-origin restriction would be easier to implement if it is defined as a use-based (or link-specific) restriction by way of applying it to any resource that is linked via @font-face (as opposed to it being either format or media type specific), and this is actually the way all existing implementations support it today. The WG also believes that “From-Origin” header proposal is a better, more generic way to control resource sharing. 



The WebFonts WG asks the CSS WG to support the changes introduced in the most recent version of the Editor’s draft of the CSS3 Fonts module and include a normative requirement for same-origin restriction be applied for resources linked via @font-face mechanism. The WG believes that this solution would be most beneficial for the majority of authors by providing them with a way to use web fonts with no additional work, especially in those circumstances where the server configuration headers cannot be modified by authors, or where other solutions (e.g. referrer checking) would be required to comply with font licenses. 





[1] http://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html 

[2] http://www.w3.org/TR/cors/ 

[3] http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html 

[4] http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Feb/0048.html

Received on Friday, 24 June 2011 01:03:06 UTC