RE: Decouple XBL2 From CSS

Hi, Ian-

Thanks for your prompt reply.

Ian Hickson wrote:
| 
| On Wed, 2 Aug 2006, Doug Schepers wrote:
| > 
| > The XBL2 spec, as it stands, assumes only CSS for binding and for 
| > styling. This is an unnecessarily narrow requirement.  
| There should be 
| > options for other standardized languages as appropriate, 
| such as XSL:FO 
| > for styling and XBL for binding.
| 
| I don't understand how XBL assumes anything for styling. 

The first sentence in the abstract of the spec says, "This specification
describes the ability to map elements to script, event handlers, CSS, and
more complex content models."  The second sentence in the abstract says,
"This can be used to re-order and wrap content so that, for instance, simple
HTML or XHTML markup can have complex CSS styles applied..."  The first
sentence  in the introduction of the spec says, "This specification defines
the XML Binding Language and some supporting DOM interfaces and CSS
features."  It goes on from there.  There are 30 substantive uses of the
initalism "CSS" (not including linked references or code snippets).  There
are explicit error handling rules for dealing with unexpected content in a
CSS context (not bad in itself, but displaying clear bias).  The default
style-type is CSS.  It continues like this through the entire spec.

I cannot imagine a more explicit assumption.


| It's a binding language, not a styling language.

I'm glad we agree.  This is further evidence that it should be decoupled
from a specific styling language.


| It already supports XSL:FO, both in 
| terms of being used from XSL, and in terms of including XSL 
| in bindings.

I see where it has a section on "Attachment using CSS" but I fail to find a
single reference to XSL (or XPath, for that matter).


| > Please revise the specification so that it does not assume 
| that CSS is 
| > integral to XBL2.
| 
| CSS isn't integral to XBL2, though of course XBL2 is designed 
| to integrate tightly with XBL2.

(I'm assuming you meant that XBL2 is designed to integrate tightly with
CSS.)

There is no problem with that, as long as it is designed to work with other
languages as well.


| However, even if it was, that doesn't seme like a problem. 

...to you.  It does seem like a problem to me.


| XBL2 is intended to be a language used on the Web, primarily in Web 
| browsers. The Web is based on HTML, CSS, and JavaScript, 
| so XBL should work tightly with those languages. 
| XSL:FO is never used on the Web, so seems mostly irrelevant in 
| terms of XBL.

I do not agree with your personal definition of "the Web" and will not
accept this as a technical response.  Your definition of the term is
tautological.


| Pragmatism is important; 

I agree.  However, I think that pragmatism includes looking forward at how a
technology will be used, and not placing undue constraints on it.  History
has shown us that the creators of a technology rarely anticipate the extent
to which it will be used in unplanned ways; look at HTML, which was intended
to share technical documents.


| we don't want to run the risk of 
| over-generalising the specification, 

It's not clear who you mean by "we" there.

I'm not asking for over-generalization.  I'm asking for a reasonable amount
of generalization such that XBL works well with other specific XML
technologies, such as XSL:FO and XPath.


| or making it too extensible,

How can something be "too extensible"?  The only manner in which that is
even a rational statement is if great sacrifices to the implementability or
performance of the specification are made in order to achieve that broad
applicability.  Implementation experience in Batik of sXBL indicates that
this is not the case. 


| to the  point where authors don't have a clear 
| picture of how to use the technology,

This is the role of the XBL2 Primer, which I am taking an active hand in
creating.  We intend to clearly show how XBL can be applied to real-world
use cases, starting from a very basic level.


| or to the point where the technology doesn't fit 
| well with their existing content and existing skill set.

I fail to see how a substantial amount of existing Web content is a target
of XBL2 (especially by your definition of Web content as "HTML, CSS, and
JavaScript").  New skills are acquired readily by the logical audience of
this spec, which will likely consist of skilled professionals.

This "requirement" sounds to me like a back-justification tailored to
leverage CSS, rather than as a design goal toward the end of binding and
presenting semantically rich XML.


| That's not to say that we should prevent interaction with other 
| technologies; for example XBL is compatible with XML ID, 
| XLink, XInclude, XML Schema, and a host of other technologies   
| which could hypothetically be used on the Web. 

Leaving aside that some of the technologies are less hypothetically used
than you imply, it's not clear what you mean by "compatible".


| But it does mean we shouldn't design the 
| specification to assume those technologies will be available. 

Your assumption that CSS will be available again shows how inseparable the
XBL2 spec is from CSS at the present time.


| I hope this helps explain the design principles behind XBL2.

I did not ask for an explanation of the design principles, and it is
disingenuous to imply that I did.  What I asked for was a reasonable
alteration of the specification such that it is more broadly applicable. I
will note that the X in XBL unwinds to "extensible", which is a more
pressing design principle in both the long and the short term.

My preference would be that the spec is changed to explicitly describe XPath
as a binding mechanism, and that explicit mention of CSS as a styling option
is tempered with descriptions of other styling options, e.g. XSL:FO or SVG's
presentation attributes.


Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Thursday, 3 August 2006 16:10:00 UTC