- From: Dirk Schulze <dschulze@adobe.com>
- Date: Mon, 11 Mar 2013 11:09:53 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: Richard Schwerdtfeger <schwer@us.ibm.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "www-dom@w3.org" <www-dom@w3.org>, "www-svg@w3.org" <www-svg@w3.org>
On Mar 11, 2013, at 10:01 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Mar 11, 2013 at 2:14 PM, Dirk Schulze <dschulze@adobe.com> wrote: >> It would need a lot of clarifications how this is supposed to work on SVG. And it doesn't even seem to be implemented this way broadly. A cleaner solution seems to be to move the necessary methods and attributes to DOM and let all XML languages use it. MathML would be another candidate where it could make sense. > > This is already the case, it just happens to be that HTML defines some > of these members for now. Moving things between specifications is what > we've been doing to some extent, e.g. for compatMode, characterSet, > contentType, but it's not entirely clear what the benefit is while the > cost is somewhat significant. We do not want SVG viewers (non-browsers) to implement HTML and I do not think that we want SVG viewers to implement methods that do not make sense for SVG. On the other hand, HTML implementations do not want the supplementals of SVG that do not make sense in an HTML context. I agree that it is not ideal to move IDL definitions across specifications. However, it is not a clean solution to keep everything that should be in DOM in HTML because of the reasons above. Otherwise there would not be a need for the DOM specification at all. All other specifications could pick what ever they want from HTML and we could merge DOM and HTML. Greetings, Dirk > > > -- > http://annevankesteren.nl/
Received on Monday, 11 March 2013 18:12:13 UTC