RE: DRAFT: WebFonts WG liaison to CSS WG



[John Daggett:]
> 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.  

I agree. "If you want to make it invalid, do so in a spec that is not on my
web standard shopping list" is exactly the vibe I'm getting. Why that's better
for everyone else certainly seems secondary, if it matters at all. 

> George 
You mean Glenn ?

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

I noticed that. But this implies future work yet he complains about introducing a
breaking change or 'retro-active requirement'. Weren't other changes made that were 
breaking for an older implementation e.g. the mapping of weight values ?

I also don't understand how requiring same-origin for new implementation breaks an older 
implementation that loads fonts cross-origin. And that is the other thing that is odd 
here: this objection does not include any use-case or scenario affecting end-users.


> But for the web that doesn't resolve the problem at all, it just spreads the 
> solution out in a larger number of specs.  

Very true.

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

Since we have in fact agreed in previous discussions that this behavior applies 
not to font resources but to resources loaded by the src descriptor of @font-face,
I have to agree. This behavior is tightly coupled to this specific part of the
feature. Some will argue this requirement shouldn't exist because there shouldn't
be such a tight coupling between CSS and protocol-level things, of course. But I 
think you're right: the specification of the feature should define this or it will
be treated as if it wasn't there. Since it already is ignored by some implementors
there are no reasons to believe it will be better respected if it were in some
other document.

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

As you said, the 'where it is specified' argument seems to be a way to route
Around the hard issue, which remains the default value of the From-Origin reader 
for those responses to src descriptor requests that don't include one. 

> 
> 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 Saturday, 25 June 2011 00:47:04 UTC