- From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Date: Fri, 03 Sep 2004 10:22:04 -0700
- To: www-svg@w3.org
- Message-id: <6.1.1.1.2.20040903094010.03687528@mailsj-v1.corp.adobe.com>
Here are some additional things to consider in the discussion about how <content> elements refer to children of the bound element: 1) (As Robin and Anne have pointed out) Some implementations already have XPath and some implementations already have CSS. To me, it will be hard for the community to reach agreement on whether CSS or XPath is better based on existing implementation arguments. Therefore, I think it is best to resolve the debate along other axes. 2) If is possible to define subsets of both CSS and XPath for use within XBL. For example, you can define a highly restricted subset of CSS selectors and a highly restricted subset of XPath, and only require that XBL implementations support that subset. It looks to me like the most popular selection techniques (e.g., by tagname or by attribute value matching) are available in both syntaxes. Therefore, the ability to subset CSS or XPath is a wash and therefore I think it is best to resolve the debate along other axes. 3) My guess is that the W3C leadership, if asked, would recommend using a subset of XPath rather than a subset of CSS because in their system of standards they would feel that XPath is the appropriate standard for this scenario. The first sentence of the XPath spec says: "XPath is a language for addressing parts of an XML document". This seems to match the functionality we are trying to achieve with the <xbl:content> element. 4) CSS is really only widely used with one content type: flowable markup, where HTML or arbitrary markup is styled and presented according to the CSS box model. This is an important content type, yes, but there are other markup types such as SVG, SMIL, and MathML with different layout and presentation models where CSS either isn't available at all or doesn't provide much value. (Regarding SVG, SVG Full supports CSS as an optional feature. SVG Tiny does not support CSS. Even when people have the option of using CSS with SVG, they usually don't because it doesn't provide much value.) Furthermore, even in the flowable markup world, there is an important workflow where CSS isn't used: when you are doing pure XSL processing (i.e., XSLT transformations into XSL-FO documents). In this scenario, XPath is available (because XSLT includes XPath) but CSS isn't. My analysis is that XPath is a better match for the broad universe of content types than CSS, whose usage today and design center is around flowable markup content types and not the universe of all content types. XPath, on the other hand, was designed to be a common addressing mechanisms applicable to all XML scenarios, not just flowable markup. Jon Ferraiolo Adobe Systems, Inc. ---------------------------------------------- From: Robin Berjon <<mailto:robin.berjon%40expway.fr?Subject=Re%3A%20%5BsXBL%5D%204.2%20Processing%20content%20elements&In-Reply-To=&References=>robin.berjon@expway.fr> Date: Fri, 03 Sep 2004 15:10:36 +0200 Message-ID: <41386D4C.3080308@expway.fr> To: Anne van Kesteren <<mailto:fora%40annevankesteren.nl?Subject=Re%3A%20%5BsXBL%5D%204.2%20Processing%20content%20elements&In-Reply-To=&References=>fora@annevankesteren.nl> Cc: <mailto:www-svg%40w3.org?Subject=Re%3A%20%5BsXBL%5D%204.2%20Processing%20content%20elements&In-Reply-To=&References=>www-svg@w3.org Anne van Kesteren wrote: > XBL could probably be used, eventually, together with XHTML and CSS and > some basic DOM methods on smaller devices. If such a device already has > CSS support to style the markup, it would be redundant to have a > complete XPath specification just for XBL. Yes, but the problem works both ways (which is why it hasn't been resolved): if the device already has XPath it would be redundant to have it implement the complete CSS 3 Selectors just for XBL. -- Robin Berjon
Received on Friday, 3 September 2004 17:22:28 UTC