Re: sXBL draft comments

On Thursday, September 2, 2004, 5:15:09 AM, Cameron wrote:


Hey Cameron,

CM> Some comments about the sXBL draft.

CM> 4.2 Processing content elements

CM> Full XPath makes sense to me.  If you are already going to have XPath
CM> support from DOM 3 XPath, you may as well use it.  What is a "predefined
CM> XPath profile"?

CM> But I guess it's the issue of dependency tracking that is the problem.
CM> I have done it for full XPath, so it is possible.  (Well I didn't handle
CM> the following and preceding axes, but who ever uses those. ;))

Hence the 'defined subset' :)

CM> Regarding sorting, I hadn't really considered it.  I guess it is
CM> certainly possible authors will want to sort the elements differently.
CM> xsl:sort?  How close to XSLT do you want this template to become?

It should draw from it, certainly, if there are established ways of
doing things.

Since you mention XSLT, its important to note a big difference between
XSLT and sXBL. In XSLT, its a one-shot, batch-like transform. If any
changes are made to the result, they have no effect on the source and do
not cause the transform to re-run; similarly if there are changes to the
source they do not affect the result and do not cause the transform to
re-run. Its certainly possible to imagine a continuously looping XSLT
process triggered by mutation events (at least, for source changes) but
its hard to iimagine event flow in the result tree continuing
uniinterrupted in that case.

CM> It is mentioned with the second proposal for handling content elements
CM> which match no nodes that it keeps the flattened tree to be a superset
CM> of the original DOM tree.  Why is that important?

I believe it is for implementation efficiency, but perhaps Ian Hickson
has more details on why that is seen as desirable. I agree the spec
should explain the value of keeping it a superset.

CM>  If there are elements
CM> which I don't want to include in the rendering, it seems silly that they
CM> would have to be there with a display: none.  I vote for proposal 1.

CM> 6 DOM Interfaces

CM> Will there be an interface for the xbl:content element as it appears in
CM> the shadow tree?  Just like the SVGElementInstance interface.

Interesting suggestion, need to think about that one.

CM> 6.1 The NodeXBL Interface

CM> The element versions of firstChild, nextSibling etc. are nice.  It'll
CM> save me writing little functions to skip over whitespace and comments.

We figured that was the common task and tried to make it easier.

CM> 6.2 The Event Interface

CM> If you are worried about modifying Event from DOM Events, why not just
CM> have a new interface (e.g. ForwardableEvent or something) and have all
CM> of the events which are generated by SVG implement that interface too?

Yes. I think the idea though is that implementatiions of sXBL modify all
their events so that they have a consistent, enlarged, interface.

CM> 6.3 The XBLTemplateElement Interface

CM> getElementById on XBLTemplateElement: good idea. :-)

CM> About the note mentioning id attributes having to be of type ID, it
CM> seems annoying that I would have to write some DTD just to allow my
CM> custom elements to have id attributes that work with getElementById.
CM> But I don't like DTDs anyway.

Nor do we. Please see
 http://www.w3.org/2001/tag/doc/xmlIDsemantics-32.html
 http://www.w3.org/TR/xml-id-req/
 http://www.w3.org/TR/2004/WD-xml-id-20040407/


CM> More comments later, perhaps!

Look forward to them.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Thursday, 2 September 2004 08:44:12 UTC