- From: Liam R E Quin <liam@w3.org>
- Date: Thu, 23 Jun 2011 13:30:01 -0400
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>
- Cc: StyleBeyondthePunchedCard <www-style@w3.org>, public-webfonts-wg@w3.org, "www-font@w3.org" <www-font@w3.org>, Glenn Adams <glenn@skynav.com>, "Martin J." Dürst <duerst@it.aoyama.ac.jp>
This situation is similar in many ways to that of XPath in the XML specification: XPath doesn't stand alone, because XPath is an embedded language, but we can't put constraints on the language that embeds XPath. So, we put constraints on the way in which XPath is used when embedded. What might this mean for WOFF? The WOFF spec could say in its conformance section (right in the spec, not in a separate document) that for use in style sheets (not only CSS) an implementation-defined mechanism should (must?) be available to limit access to the WOFF resource outside of support for the style sheets, and maybe give same-origin as an example. (It would also presumably also say in tta section that WOFF fonts are not intended to be used directly for document and style-sheet creation, but are instead a delivery format). Then a Web browser, or an SVG renderer, or an XSL-based typesetting system, in order to claim support for WOFF, would need to document the particular mechanism that they supported; CSS, XSL, SVG, HTML would not need to say anything specific. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ I am away in June + most of July and answer mail only spasmodically
Received on Thursday, 23 June 2011 17:30:20 UTC