W3C home > Mailing lists > Public > www-svg@w3.org > October 2004

Re: sXBL feedback and proposals

From: Jim Ley <jim@jibbering.com>
Date: Mon, 18 Oct 2004 01:11:52 +0100
To: www-svg@w3.org
Message-ID: <ckv1o1$uia$1@sea.gmane.org>


"Nigel McFarlane" <nrm@kingtide.com.au> wrote in message 
news:4173025C.3000409@kingtide.com.au...
> "Suppose an SVG document exploits XBL and contains an <image> that is also 
> SVG. The parent document has five references to an XBL external resource R 
> and the <image> content has two references to R. The parent document will 
> retrieve one instance of R and re-use it four times. The <image> document 
> will retrieve one instance of R and re-use it once."

I think that's better, cheers.

> > I agree that the original paragraph is very strange,
> > but I don't think this has particularly improved it.
>
> "An sXBL binding cannot change the nature of a bound element,
> it can only change the element's implementation

My problem with this is that elements don't have a nature, XML doesn't have 
a spirit - XML elements have a concrete definition defined however (it 
depends on the XML vocabulary of course)  That definition is concrete, a 
rendering _cannot_ change it, so I don't see why the spec is attempting to 
make that forbidden, when it's simply a fact.

> A binding that is poorly conceived could
> pervert the intent of an XML element,

How?  It's a rendering - sure I could render a square circular using XBL, 
but that hasn't changed the square.  The same as I can render an important 
heading in tiny footnote sized text placed at the end of a document in CSS - 
CSS doesn't have this peculiar warning - I'm not sure what's different in 
this situation, or why it needs to be highlighted in what is to me a 
complicated and superflouis manner.

> There's no spec writable
> that can legislate against or demark that philosophical problem.
> All we can do is warn against bad practice.

It's a specification, not a best practice document, and I just don't see how 
complicated sentances really clear anything up, especially as it's something 
that doesn't need clearing up for implementation.

Cheers,

Jim. 
Received on Monday, 18 October 2004 00:11:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:55 UTC