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

Hi Martin,

Nice to hear from you, particularly after the recent disasters in JP.

On Sun, Jun 19, 2011 at 8:27 PM, "Martin J. Dürst"
<duerst@it.aoyama.ac.jp>wrote:

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

The correct place to define is in a UA spec that employs HTTP or equivalent.
In fact, HTML5 already does this [1], though it does not mandate (or even
make reference to) support for WOFF or CSS3-FONTS.

[1] http://dev.w3.org/html5/spec/Overview.html#origin-0

For fonts

The origin <http://dev.w3.org/html5/spec/Overview.html#origin> of a
downloadable Web font is equal to the
origin<http://dev.w3.org/html5/spec/Overview.html#origin> of
the absolute URL <http://dev.w3.org/html5/spec/Overview.html#absolute-url> used
to obtain the font (after any redirects).
[CSSFONTS]<http://dev.w3.org/html5/spec/Overview.html#refsCSSFONTS>
Note that I have previously requested that HTML5 actually reference
CSS3-FONTS [2], but the HTML5 authors have declined, stating that [a UA
implementation] "can use CSS without us referencing it".

[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11778


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

A great deal of latitude exists in what is supported by a UA. HTML5 itself
codifies this by:

   - not specifying whether support is required for any image type
   - not specifying whether support is required for any audio or video media
   type
   - not specifying whether support is required for (text of) any language
   - not specifying whether support is required for any specific font
   - not specifying whether support is required for downloadable fonts
   - not specifying whether support is required for any media type (screen,
   page, aural, etc)
   - not specifying whether support is required for CSS, or, if supported,
   whether support is required for any CSS property
   - not specifying whether support is required for any scripting language,
   including JavaScript
   - not specifying whether support is required for any protocol (e.g.,
   HTTP)
   - etc...

Previously, HTML5 did not even require support for either the HTML or XHTML
Syntax (or content types) of HTML5, but eventually was changed to require at
least one of these be supported.

Instead of specifying these details, HTML5 follows the time honored and
successful practice in W3C specs of leaving these matters up to individual
UA implementers.

Samsung believes that the mandate for same-origin policy falls into the
category of features that should be left up to the UA implementer. It is one
thing to define a mechanism, but another to mandate it be used, particularly
when its use is mandated universally.


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

As I'm sure you are well aware, UA implementers often give the end user
choices about the behavior of the UA. For example, whether to allow popups
or not, whether to allow scripted content, whether to use a large or a small
font as a default, etc. The user preferences layer is the term I have
employed to refer to this UA specific process.

I did not propose that W3C standardize such a layer. I just pointed out its
existence. The fact that UA implementers offer a variety of (different)
choices to users about the behavior of the UA can be assumed as a given,
and, if a UA implementer chooses to support same-origin restrictions, then I
foresee them providing a mechanism to allow a user to enable or disable
those restrictions, and if enabled, then perform fine-grain control over the
use of such a mechanism. Further, it may be a matter of a local or
enterprise wide policy, and not just end-user policy, about whether how it
is enforced. Again this is a policy issue that Samsung believes is best left
to the end user or the system administrator provided the UA implements the
basic mechanism, and should not be a requirement in a W3C specification.


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

Samsung is a UA provider (in its many types of devices), and I have no
trouble imagining this.


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

You are reading into this something which I did not imply. I have not said
Samsung "doesn't like" same-origin as such. It is merely a technical
mechanism that can be used in a variety of ways. It is the desire to mandate
its use in an arbitrary UA with which Samsung takes issue.


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

The WHY can be explained by referring to the following principles: (1)
architectural consistency, (2) separation of mechanism and policy, (3)
maximal choice. In these terms, we believe that mandating same-origin
restrictions in WOFF or CSS3-FONTS:

   - *is architecturally inconsistent* with current practice which does not
   impose usage restrictions on content formats or content referencing;
   - *fails to separate mechanism and policy* by defining a content format
   (or referencing mechanism) then mandating specific, restrictive policy on
   its use;
   - *reduces choice* for UA implementers and end-users by imposing
   restrictions on implementation choices and on viewing and access choices;

Samsung believes WOFF and CSS3-FONTS should be consistent with existing
architecture, should separate mechanism and policy, and should permit UA
implementers the choice of supporting and enforcing same-origin
restrictions.

If given this choice, Samsung will very likely support the same-origin
mechanism, and may choose to expose the enablement of that mechanism to the
end user, administrator, or service operator. If not given that choice,
Samsung may choose to ignore the policy mandates prescribed by the current
language.

Samsung proposes a simple and straightforward solution for resolving this in
WOFF and CSS3-FONTS, namely, to replace the current language with the
following:

"If a user agent that makes normative use of this specification includes a
same-origin policy, then that policy, and the mechanisms it uses to enforce
that policy should apply to the loading of fonts via the @font-face
mechanism."



> Regards,   Martin.
>

Regards,
Glenn