Re: [sXBL] 4.2 Processing content elements

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