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

Re: sXBL feedback and proposals

From: Robin Berjon <robin.berjon@expway.fr>
Date: Mon, 18 Oct 2004 14:56:46 +0200
Message-ID: <4173BD8E.4080409@expway.fr>
To: Nigel McFarlane <nrm@kingtide.com.au>
Cc: www-svg@w3.org

Nigel McFarlane wrote:
> In practical terms, though, will hurried authors turn to
> the construction or addition of element definitions each time
> they find no tag perfect for their imagined binding? I doubt it.
> They will hack something in, or use a generic tag as a container.
> So the above "rule" is functionally only guidance. Oh well.

This is a debate that IIRC the TF has had already, regarding earlier 
wording that went along the lines of "sXBL cannot change the semantics 
of an element".

In the end we dropped it because we didn't feel like getting bogged down 
in definitions of who or what defined an element's semantics and when do 
you start breaking them.

I understand (and, in theory at least, support) your concern but I would 
be worried about dispensing advice that we cannot fully back. If I 
render <shoe> as "<shoe>", on which you can click to see its attributes 
and children am I breaking the semantics? If I render it as a pink bunny 
to entice shoe fetishists am I breaking the semantics? If I render it as 
a tombstone to protest anti-personnel mines am I breaking the semantics? 
If I render it as a pink edelweis because I'm a crazy artist from the 
International Non-Cabal of Associated Dahut And Shiny Donkey Worshippers 
am I breaking the semantics?

Neither CSS nor XSLT come with such warnings, I think all we can do here 
is to hope users won't be too stupid, knowing that inevitably sometimes 
they will :) Also, people that will read the spec are people that won't 
make that sort of mistake in the first place, while those that are 
likely to abuse sXBL are also people that won't read it.

Robin Berjon
Received on Monday, 18 October 2004 12:57:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:03 UTC