[sXBL] Various comments

The definition element: QNames in attribute context - please NO, what's the 
rationale for this, it makes roundtripping of the XML through XML toolkits 
much more complicted - they need to understand the attribute model rather 
than just XML.  What's the rationale for using QNAMES?  (please don't 
mention stupid authors...)

The sentence:
"The definition element defines a presentation and behavior binding. It does 
not define an element's semantics. If an element has no semantics when 
processed alone, then it has no semantics when processed with XBL."

I'm not sure what this is trying to get across, the previous paragraph 
mentions that you don't want sXBL to be a justification for sending markup 
without agreement between the two parties, but that's a ridiculous 
requirement.  We have no mechanism for agreeing XML vocabularies understood 
over HTTP currently, and one of the major motiviations for sXBL is the 
ability to transform a private XML data format into an SVG rendering of 
that.

The myNS:HelloWorld example in the specification is using non-agreed XML 
vocabularies, it's surely not the intention of the TF to not enable this to 
be sent - so what is the intention of the TF?

Implied Content elements - I do not want these in the shadow tree 
automagically, I do not feel it is of particularly concern that the 
flattened shadow tree thingy is not a superset of the original DOM, I would 
be more concerned of the limitation that strange elements that are not 
expected appear in the shadow DOM - ensuring you only add what you want is 
easier than relying on styling to hide content.

5.3 - This references the CSS 3 UI specification for nav-index, but then 
uses the SVG 1.2 proposal in the example - I assume the SVG 1.2 is the 
correct reference, and not CSS 3 UI (or is it in addition?  If so I'd rather 
see the dependencies of SVG/sXBL not increased without good reason.)

I think the sections on binding stylesheets (4.6) are little unclear:
e.g.
"Shadow content nodes must be styled using the stylesheets specified in the 
binding source document"  and indeed the rest, I simply don't understand 
what it's trying to say.  (does #id in CSS match all the instances of that 
id in the flattened tree for example?)  -  I think the thing that's 
confusing me is how external XBL references are catered for with the CSS.

In Event flows (5.2) I'm not completely sure there's not a situation where I 
may want to know about mutation events on a child bound element - consider 
dynamic layout, the container would always need to know the size of the 
children - to do this the childrens mutation events fired as it resizes 
itself would need to make it into the outer container.

Cheers,

Jim.

Received on Sunday, 5 September 2004 14:34:44 UTC