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

Hello Glenn,

Having followed this list for a few years as a bystander, I have some 
questions similar to those from Tab
("Do you have a concrete reason why they shouldn't be specified as they 
are (perhaps you're implementing CSS in a non-web context and don't 
believe the restrictions are useful in your context), or are you 
objecting on theoretical purity concerns?")


On 2011/06/19 7:31, Glenn Adams wrote:
> I understand your argument, but Samsung does not agree with it:
>
>     1. we don't believe that mandating same-origin rules in a UA w.r.t. font
>     loading will encourage more widespread availability or use of webfonts; in
>     contrast, we do believe that completing WOFF and CSS3-FONTS and their rapid
>     adoption by UA implementers in a consistent, interoperable manner will
>     encourage more widespread use;

It's very possible that different people and companies have different 
opinions here, but that ultimately seems to be a judgment call.


>     2. we don't believe (and are in fact strongly opposed) to defining such
>     rules in either WOFF or CSS3-FONTS, for the simple reason that neither of
>     these mechanisms define a proceses for accessing font resources; i.e., they
>     have no {FETCH,ACCESS}-RESOURCE primitive;

The HTTP spec has such primitives, but it doesn't look like the right 
location for saying what applies to fonts in particular (but may not 
apply to images or scripts or whatever else). A third spec (e.g. a Web 
Fonts Conformance spec) would be a good place, but doesn't contain such 
a primitive either.

>     3. we do believe that it would be useful to define the *optional* use of
>     same-origin mechanisms in those specifications that do define a
>     {FETCH,ACCESS}-RESOURCE primitive, such as in the HTML5 specification, where
>     by *optional* we mean optional at two layers: (a) at the UA implementation
>     layer, and (b) at the UA's user preferences layer; that is, a UA implementer
>     should be able to decide whether or not to support same-origin, and if
>     supported, a user should be able to opt-out or, conversely, opt-in to
>     same-origin restrictions at a level of granularity determined by UA
>     implementer;

I don't see how making this optional for general browsers is a good idea 
(it may just mean no browser will implement it), and I can't think about 
any kinds of UAs where it would make sense to make an exception. If you 
can think of such UAs, then telling us about these would help.

Also, I don't understand the idea of trying to specify UA details like 
'user preference layer'. In case the thing is optional in the first 
place, then sure some UAs might delegate this optionality to the user, 
but that should be their own decision, and doesn't need any wording in 
the spec.

If I were a UA provider, I'd have a hard time imagining that the user 
would go and change this setting on his/her own. The situation is way 
different e.g. from "mojibake" that results from wrong 'charset' 
information.

Also, this additional 'user preference layer' would just make 
implementation more tedious, which would mean less UA providers would 
implement it. So at least for the moment, it looks to me like you are 
saying "We don't like this, so we want it to be optional, and to make 
sure UA providers do not implement it, we'll add some additional 
requirements in case it's implemented that don't make much sense in the 
first place."

Of course, there may be good reasons behind your proposal/position that 
I just missed, but in that case, it might be helpful if you could 
explain in more detail.


> At this point, I believe I've stated the Samsung position clearly, and there
> is no need to further elaborate. I will await the WGs' resolution of this
> matter, and will be available for any teleconference or meeting that wishes
> to discuss further.

I think you have made very clear WHAT Samsung wants. But at least for me 
as a bystander, quite some questions about the WHY remain. I think it 
would be very helpful for the WG (and maybe later for the Director) to 
get more information on the WHY.

Regards,   Martin.

Received on Monday, 20 June 2011 02:28:32 UTC