sXBL feedback and proposals

Some responses to solicitations in the XBL draft for comment,
better words, and ideas.

[ warning long email ]

§1.4 Loading External resource

Proposed words:

"A document that refers to an XBL external resource retrieves
exactly one instance of that resource. Unlike images retrieved using
CSS styles, XBL resources are stateful and scriptable. To mitigate
security concerns, all documents that refer to an XBL external
resource seperately retrieve one instance of that resource. This
means that if part of a document is another whole document, then
the resource instance of the greater document will not be shared with
the part document. An example follows.

Suppose an XHTML+SVG document exploits XBL and contains an <iframe>.
The parent document has five references to an XBL external resource
R and the <iframe> content has two references to R. The parent
document will retrieve one instance of R and re-use it four times.
The <iframe> document will retrieve one instance of R and re-use
it once."

§2.2 The definition element

Proposed words:

"An XBL binding cannot change the nature of a bound element, it can
only change the element's implementation. A binding that is poorly
conceived could pervert the intent of an XML element, but that is
merely a use-case showing ignorance of the spirit of XML."

§4.2 Processing content elements

Feedback:

{on sorting}

To me, sorting only serves to complicate this 1.0 spec.
The purpose of XBL 1.0 is to provide two mapping transforms:
one from XML to XML, one from DOM to DOM. In particular
the XML mapping is a transform from a grove of trees
(bindings + explicit content) to a single tree.

To introduce sorting is to introduce a further
transform that should really be applied after the merging
of XML content has been achieved, possibly from outside XBL.

{on includes=}

I think also there is little support for complex include
options. This choice could be put off until XBL 2.0 by the
use of a type= attribute that specifies the include=
syntax. When there is more implementation experience, a
default could be specified in a later draft/version/edition
of XBL.

I would point to two examples of the limited popularity of
this kind of feature:

1. includes= in the Mozilla codebase's XBL has been deprecated
    as a feature.

2. A similar feature in the Mozilla codebase is a filtering
    system for command observers. There, the filtering system
    has never been completed, because there has never been a
    pressing need. All of the Mozilla work has managed very well
    without it.

For me, option 5. or 6 is more than sufficient for includes=
until experience points to clearly urgent needs. I
would hope for an XHTML class= syntax solution at most.

{on disposition of non-matching explicit content}

A starting point is to observe that there are many useful
XBL bindings that contain no content. They contain only
handler code. Such bindings very conveniently augment the
default actions and scriptable APIs of the bound tag.

Such bindings should never damage explicit content in the
bound tag, since that is all the content of the bound tag.
That content should be displayed without modification, at
least until the binding chooses to do something with an event.

Because of this common case, there is no argument for
deleting explicit content, and so we are stuck with finding
a way to resolve the final destination of that content.
More complex cases should follow the spirit of the simple
case, which is to display what the SVG author was at pains
to provide in the first place.

The Mozilla implementation of XBL has rather awkward
merging arrangements. The Mozilla implementation of a
similar merging technology - overlays - has a far neater
arrangement. It uses a hint system based on attributes.

I propose that a similar hint system be used for XBL to
resolve merging strategies in comple cases. Here are
proposed syntax options, starting with the easiest.

(as before). The SVG author is lazy or requires only a simple
result. No explicit content contains id's, no XBL binding
content. That explicit content is simply used in the flattened tree.

(as before). The SVG author puts id's on all the explicit content.
The binding <content> tags merge all that explicit content into
the flattened tree as described by the spec.

(new). Instead of leaving the content merge entirely up to
the merge algorithm, the SVG author adds hints to the
explicit content, controlling the merge. The XBL
merging code must detect these hints. Here is an
example:

<bind-me>
   <foo xbl:merge="start"/>
   <bar/>
   <baz xbl:merge="end"/>
   <fred xbl:merge="none"/>
   <nerk id="merge-id"/>
</bind-me>

Use of namespaces is inconvenient, but warranted for
an advanced use such as this. That inconvenience
burdens two existing features of the Mozilla XBL
implementation (attribute substitution and inheritence)
and has proved practical and workable in both cases.

A proposed algorithm that caters for hints is:

a. merge all id-matching content with the shadow content.
b. move all content with merge hints to the hinted spots.
    Where two hints are the same, preserve the ordering of
    the tags in the explicit content ("stable relocation").
c. treat all non-id-matching, non-hinted content as though it
    had merge="end".

Justification for merge="end" as the default:

A very common use of XBL will be to supply figures, tables,
charts and images with an accompanying title. It is very
common for titles to appear below the figure, title or chart,
especially in printed matter and also in formal electronic
documents.

An example:

<figure datasource="xy.csv" type="box-diagram">
   <title>Figure 2-3: Missing exposition of shadow scopes</title>
</figure>

With <figure> bound, it is desirable that the title follow along
at the end of the figure, hence the proposed default.

§4.4.2 Selectors and Shadow Scopes

This section is very forward-looking. There is no mechanism
described in this spec for mapping CSS information in a
binding to CSS information in a flattened, rendered context.
The spec only describes mappings of XML to XML and DOM to DOM.

AFAICT, any style information in a binding specification
will be treated dumbly as XML. Even the odd cases of
shadow content that is <link> or XSLT related will be copied
across to the flattened tree as XML before anything else
happens.

I can't see any case where the CSS context of the flattened
tree would jump across the barrier to the un-transformed
shadow information. Perhaps I'm not imaginative enough.
The observations highlighted in green do not provide an
example where that jump would be required, either. I think
it is enough to say that the non-flattened content does not
exist for the purposes of CSS. AFAICT, the only backdoor
into XBL shadowland is a secret interface method or
property or two, with no effect on CSS.

I therefore can't see the use of this section, unless the
following can of worms is opened: what is the CSS context
of an XBL binding that is not yet bound? I would hope there isn't
one, since such a binding is "detached" from all presentation
detail (I would have thought).

What IS good about this section, though:

I suspect bindings might mature into a "resource bundle" for
XBL 2.0, in which case the resource bundle may have a "data fork"
containing image and/or CSS resource refs. This isn't 2.0
though. If you want a "data fork" for 1.0, then you need
to add more tags. You would definitely have to express how
CSS content in the binding was mapped to the CSS context
of the bound tag then.

regards, Nigel.

-- 
---------------------------------------------------------------------
Nigel McFarlane                                   nrm@kingtide.com.au
Services:                   Analysis, Programming, Writing, Education	
Expertise:            Software, Telecommunications, Internet, Physics
"Rapid Application Development with Mozilla" / www.nigelmcfarlane.com

Received on Sunday, 17 October 2004 13:24:56 UTC