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

Hi Glenn,

You wrote:
“An existing implementation of @font-face did not "conform" to anything.
Why? Because the @font-face syntax was defined in a working draft.
Conforming to a Working Draft that can be updated at any time isn't
really a meaningful claim.”

Earlier in this discussion (http://lists.w3.org/Archives/Public/www-style/2011Jun/0619.html) you made references to the existing ATSC and ETSI specifications. Both of them mandate the implementation of @font-face syntax that was defined in CSS2, which is a published W3C Recommendation. I couldn’t find any references to CSS3 drafts.

You also wrote:
Actually, you may not have noticed that various industries regularly make normative reference to non-final W3C documents, including PRs, CRs, and WDs (though I haven't seen a normative reference to an editor's draft).

Why is this done? Because the W3C on occasion has taken a great deal of time to complete (or has never completed) some specifications. For example, css3-fonts was first published in July 2001, nearly 10 years ago. CSS TV Profile also comes to mind.

How is this done? By considering any form of published W3C document as a PAS "publicly available specification" [1] with a persistent URL. This is done regardless of the warnings in the status section.

Who is doing this? Well, let's see, the CEA (Consumer Electronics Association), the ATSC (Advanced Television Systems Committee), Cable Laboratories, SCTE (Society of Cable and Television Engineers), ETSI (European Telecommunication Standards Organization), DVB (Digital Video Broadcasting), ITU (International Telecommunications Union), and the list goes on. If I had time, I would happily supply specific instances of such normative references, but I can assure you they are there.

It would actually be very useful for this discussion if you could provide specific instances of such normative references to any of the existing working drafts, I have never seen a normative reference being made to a specification that is has not yet reached a CR (but it doesn’t mean that they do not exist – having a specific reference would definitely be useful).

Thank you,
Vladimir


From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-request@w3.org] On Behalf Of Glenn Adams
Sent: Wednesday, June 29, 2011 1:16 AM
To: liam@w3.org
Cc: StyleBeyondthePunchedCard; public-webfonts-wg@w3.org; www-font@w3.org; Martin J.
Subject: Re: css3-fonts: should not dictate usage policy with respect to origin

Liam, thanks for your prologue expressing good will.

On Tue, Jun 28, 2011 at 9:18 PM, Liam R E Quin <liam@w3.org<mailto:liam@w3.org>> wrote:

>    - Samsung believes the issue is whether an existing implementation of
>    @font-face that does not employ same origin can claim conformance to a
>    final, published REC that wishes to apply the same origin mandate to all
>    implementations, whether new or old;
You can only claim conformance to a W3C Recommendation, of course, not
to a draft.

An existing implementation of @font-face did not "conform" to anything.
Why? Because the @font-face syntax was defined in a working draft.
Conforming to a Working Draft that can be updated at any time isn't
really a meaningful claim.

Actually, you may not have noticed that various industries regularly make normative reference to non-final W3C documents, including PRs, CRs, and WDs (though I haven't seen a normative reference to an editor's draft).

Why is this done? Because the W3C on occasion has taken a great deal of time to complete (or has never completed) some specifications. For example, css3-fonts was first published in July 2001, nearly 10 years ago. CSS TV Profile also comes to mind.

How is this done? By considering any form of published W3C document as a PAS "publicly available specification" [1] with a persistent URL. This is done regardless of the warnings in the status section.

Who is doing this? Well, let's see, the CEA (Consumer Electronics Association), the ATSC (Advanced Television Systems Committee), Cable Laboratories, SCTE (Society of Cable and Television Engineers), ETSI (European Telecommunication Standards Organization), DVB (Digital Video Broadcasting), ITU (International Telecommunications Union), and the list goes on. If I had time, I would happily supply specific instances of such normative references, but I can assure you they are there.

[1] http://en.wikipedia.org/wiki/Publicly_Available_Specification



You thus presumably are not objecting that a new Recommendation will
make implementations fail to conform to something that never existed.

As you point out below, and I have already pointed out in this thread, "there is no compliance certification done by W3C". But that has not prevented non-REC forms of documents being used in the absence of a timely completed REC.

I can't speak for Chris and Bert but right now my understanding would be, Samsung made
some devices or implementations of a very old draft of @font-face and
doesn't want to change those implementations, but wants to say that
Samsung implements @font-face, and is objecting to WOFF going forward
even though their existing implementations presumably won't support
WOFF.

First I was using this as an example of why such a change produces a potential interoperability issue. Secondly, I have never said that I am referring to Samsung devices. In fact, @font-face has been implemented in a variety of products in the consumer electronics industry (including Samsung, LG, Sony, Philips, and others) prior to the current version, based on earlier WDs which have been referenced by published specs (in the CE industry).

Finally, I've pointed out that some of these existing devices, specifically some Samsung devices (I can't speak for future plans for other companies), may be updated to support WOFF format, since it is a straightforward extension of existing sfnt based formats (OTF, TTF). Indeed, merely updating these implementations to a new version of libfreetype.so that supports WOFF may be nearly sufficient to support WOFF, while adding support for same-origin requires a lot more work to core resource fetch and access code.

So I'm making this case not only for Samsung, but for a larger industry, based upon real world implementation and deployment issues.

However, going back to a number of generic points that have been made:

 *   css resource fetches (images, @import, etc) do not mandate use of same origin
 *   usage policy should be defined separately from mechanism
These points by themselves are enough to make Samsung take pause at the proposed requirements, which makes @font-face fetches inconsistent with other css driven fetches, and which merges policy and mechanism. Notwithstanding our concern about these points, we *are* willing to accept mandatory requirements in a fashion that would address our prior expressed concerns, and for which we have offered a number of possible approaches that should be considered carefully by the affected groups.

Regards,
Glenn