RE: css3-fonts: should not dictate usage policy with respect to origin

[Bjoern Hoehrmann:]
> 
> >First, your new tool can load the content as long as the server says it
> >is OK for it to do so using the proper header; which it may already do
> >if the Content it consumes is also served to other UAs; or may entirely
> >be in your control if the solution is entirely custom. Second, if
> >compatibility is far more important for your scenario than conformance
> >then by all means, stay compatible.
> 
> Well, on this list we discuss what future specifications should do and

We discuss what future implementations should do and specify it. Compare
with 'please keep your draft in line with my implementation or else'.

> that some have the option to ignore specific requirements is no argument
> in such discussions, as that does not affect what should be required. 

It seems completely relevant to me, given the problem as stated.

>It is kinda the idea with standardization that you choose the requirements
> very carefully, so you can actually rely on what's required.

This requirement has been chosen very carefully and debated on and off for
nearly 3 years now. It has also been implemented and deployed. 

> 
> Like I said, these discussions tend to be a complete waste of resources.

Yes, you keep saying that.

> The Working Group has essentially been asked to make it possible to con-
> form to the css3-fonts module without implementing any cross-origin re-
> quirements. 

Not even close. The Working Group is being asked to keep the future drafts of
a spec compatible with past drafts of that spec (although the exact starting
point remains unclear). As result of that expectation, the WG is asked to
remove *this* requirement from the next css3-fonts WD. I have yet to see
any reason to assume it will stop at this requirement or this draft.

Just because you believe this requirement to be unsound for other reasons does
not make the motive for *this* objection a legitimate cause for action one
way or the other. 

> The Working Group can either do this, or it will have to ex-
> plain why it's best if the specification does have the requirements, 

And it has done so several times, over several years now. The main 
objection to date has been the use of simple cross-origin requests 
for the purpose of enforcing same-origin on web fonts. There is ample 
evidence that this is being worked on.

> and
> have them apply to any and all implementations, despite dissent, despite
> the common practise to not conflate technologies and such policies.

I expect your standard to apply to both parties i.e. the objector must
explain why his proposal is best. Given that the answer fundamentally contradicts
the w3c standard process I do not believe the word dissent is sufficient to
 describe the issue. The standard process we follow and Glenn's expectation are,
practically speaking, mutually exclusive. That's not dissent, it's a dead-end.

As for conflating technologies and such policies, it is done elsewhere and this
is the very reason it has been suggested to move the requirement to HTML5. So
however common one believes this practice to be thus seems irrelevant to the matter.

> 
> Whether that is "We promised the font vendors to have this" or "HTML5 has
> all sorts of such requirements, so we can we" or whatever else you have in
> mind I do not know, but you are doing a very terrible job at communicating
> the reasoning behind having this requirement for any and all
> implementations.

Since it is not at all my goal in this discussion it's unlikely I should be 
any good at it. We are not asked to remove this requirement on its intrinsic 
merits or lack thereof. We are asked to remove it because it is a breaking 
change from a previous draft. If you cannot tell or do not care about the
difference then we agree: this kind of discussion is a waste of time.

Received on Wednesday, 29 June 2011 22:58:44 UTC