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.