RE: [css3-fonts] same-origin restriction definition

I'd like this to remain there as well. And whichever WG the details
belong to, it deserves interoperable specification eventually.

As for incompatibility with the W3C's recommended architecture, I'm
quite puzzled as well, given the existence of specification that *require* 
same-origin restrictions (XMLHttpRequest) or explicitly support setting them
up (CORS). 

I do not understand how this specific section can be interpreted this way. 
Or how it forbids such restrictions in W3C specs. 

But if the W3C's recommended architecture is indeed incompatible with what 
all implementations either already do (script) or will likely do 
(fonts) for reasons that include security (i.e. implementations won't
change) then maybe the architecture needs an edit. 

> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of John Daggett
> Sent: Monday, April 05, 2010 1:19 AM
> To: www-style
> Subject: [css3-fonts] same-origin restriction definition
> 
> Follow-up to Bert's original mail "[css3-fonts] various comments and
> typos"
> 
>   http://lists.w3.org/Archives/Public/www-style/2010Mar/0553.html

> 
> Bert Bos wrote:
> 
> > k) Appendix A doesn't seem to belong in this spec. The "same-origin"
> > restriction is also incompatible with W3C's Recommended Web
> architecture
> > (see, e.g., section 2.5 in "Architecture of the World Wide Web,
> Volume
> > One" at http://www.w3.org/TR/2004/REC-webarch-20041215/#uri-opacity)
> 
> I'm not at all clear why same-origin restrictions are incompatible
> with W3C's Recommended Web architecture.  Same-origin restrictions
> exist for scripts, are you saying those are incompatible also?
> 
> The reason for defining this here is that this spec defines the load
> behavior of @font-face and a same-origin restriction affects that.
> Whether that's required or not is probably an issue to be decided in
> conjunction with the newly-formed Web Fonts group but having the
> description of this in the same spec where @font-face is defined
> certainly makes things easier for authors and implementers.
> 
> John
>

Received on Tuesday, 6 April 2010 05:35:11 UTC