- From: Erik Dahlström <ed@opera.com>
- Date: Wed, 12 Jul 2006 13:11:23 +0200
- To: www-svg@w3.org
Ian wrote:
> On Sun, 19 Feb 2006, Jon Ferraiolo wrote:
> >
> > We agree that the term "alias" is insufficiently defined and have now
> > added an explanation for the term in the specification:
> >> --------------
> > The event aliases described in this section allow the use of an
> > alternate event type when registering an event listener. For example,
> it
> > is possible to register an event listener for the resize event (i.e.,
> > {"http://www.w3.org/2001/xml-events", "resize"}) using the alias
> {"http://www.w3.org/2001/xml-events", "SVGResize"}.
> > --------------
>Given that this new text has no normative content, this does not in any
> way resolve my issue. (The text above consists of a statement of fact --
> something allows something else, without saying how -- and an example,
> neither of which are testable normative conformance criteria that
> implementors could use to actually do anything with.)
>Please make the spec normatively state what the above means.
We have removed the use of the term "alias" from the interactivity chapter.
There is some new wording in the table, for example the "SVGLoad" event:
"This event is sent at the same time as the 'load' event, but the 'load'
event must be sent before the 'SVGLoad' event."
The same kind of wording also exists for "SVGResize" and "SVGScroll".
The table now has one row for the "SVGLoad" event and one row for the
"load" event, to make clear that they are separate events. Again, it's the
same for "SVGResize" and "SVGScroll".
The events in the table are no longer namespaced, and all new events added
by SVGT12 have been prefixed "SVG".
> If it is the intent of the specification to make, as Bjoern asked in a
> separate e-mail, the following two statements to be equivalent:
> element.addEventListener('resize', handler, false);
> element.addEventListener('SVGResize', handler, false);
>...then that is absolutely not acceptable to me. The SVG spec cannot
> change the behaviour of DOM Events implementations, that is highly
> inappropriate. Nor would scoping such a change to the SVG spec make any
> sense given the existence of mixed SVG/HTML/MathML/XUL/etc user agents
> that have a single DOM Events implementation and a single scripting
> model.
The statements are not equivalent, and we hope it is clear from the
changes made in the spec.
/Erik, on behalf of the SVG WG
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Received on Wednesday, 12 July 2006 11:13:31 UTC