SVG Working Group Teleconference -- 05 Aug 2009

<trackbot> Date: 05 August 2009

<jwatt> hmm

<jwatt> idiot

<jwatt> ack

<scribe> Scribe: anthony

SVG DOM improvements

CM: DS you just sent an email about this

DS: I did

<heycam> http://www.w3.org/mid/4A791DAB.1020504@w3.org

<shepazu> http://lists.w3.org/Archives/Public/www-svg/2009Aug/0010.html

DS: Occurred to me how can we find out what methods are used
... could look at the libraries Dojo
... and what other libraries think are available to browers
... might give us a clue to the degree of use
... and those libraries would be affected by any changes we make in the DOM
... so we need to look at those
... we need to be careful about what we change
... I think it would be really valuable to make a survey of what DOM methods are implemented
... be useful to figure out interoperability

CM: I opened up a couple of example pages
... and some were pretty impressive

DS: If we can figure out what DOM methods are used and implemented
... we can use that as a starting point
... to figure out what things we change, if we change anything

CM: Figuring out what is implemented is easy and something we can do

DS: Dojo may not code to the lowest common denominator
... so may only be one method to survey what's out there

CM: So if it's not implemented it may be an indication that it's not used out there
... ideally the test suite will test the the features so we can figure out what's implemented

DS: I'm not convinced that the test suite tests all of the interface

CM: How do you want to go about it?

DS: It may be something we can automate
... as a first pass solution we can go through the methods to see if they return something
... and that might be a really fast way of doing it
... as survey
... not testing implementability
... just seeing if it's done
... If people are open to it, I'd like for us to have some actions come out of this

CM: Maybe a good way to go about this is to have a wiki page that has the interfaces
... and assign them to people

DS: Sounds like a good idea

CM: I don't mind being assigned interfaces
... so whoever makes the wiki page can randomly assign them
... are you going to do that [DS]?

DS: I suppose I could

AG: Anyway to use the IDL?

CM: When it builds the spec it creates an XML doc with the method names and the return types
... since I'm familiar with the file
... I could whip something up

<scribe> ACTION: Cameron to Extract the interface and method names from the IDL [recorded in http://www.w3.org/2009/08/05-svg-minutes.html#action01]

<trackbot> Created ACTION-2645 - Extract the interface and method names from the IDL [on Cameron McCormack - due 2009-08-12].

<scribe> ACTION: Doug to Follow up on ACTION-2645 and assign work to the extracted interface and method names [recorded in http://www.w3.org/2009/08/05-svg-minutes.html#action02]

<trackbot> Created ACTION-2646 - Follow up on ACTION-2645 and assign work to the extracted interface and method names [on Doug Schepers - due 2009-08-12].

DS: JWatt you had some issues with what I had worked up with the DOM APIs

JW: That what was a while ago
... I think I can remember changing the names
... so for things like document.createElement
... We have that method on that document interface already
... the suggestion was to add it to the element inteface
... what I was thinking that when you create an element it puts in the name space of the element you just called it on

<ChrisL> that sounds like a useful default

JW: so when you have some SVG element and you want to create some children you don't have to
... specify the name space every time
... the problem with document.createElement is it puts it in the NULL space
... it would be nice if each element could take an object to set the attributes, the main thing I was thinking about
... was getting rid of the name space stuff
... which people seem to find so hard

<ChrisL> element.dwim.createElement :)

JW: then it would have a different behaviour with elements that have name spaces

<heycam> Web DOM Core (zcorpan's DOM Core rewrite) says document.createElement() uses the HTML namespace: http://simon.html5.org/specs/web-dom-core#dom-document-createelement

CL: Someone has done this and use the HTML name space
... see above link

JW: That's in the HTML name space
... Opera and Webkit stick it in the HTML name space
... FF puts it in the NULL name space
... but either way it will still work

<jwatt> JW: not sure about Opera

CL: What they've done is that they've made it easy for HTML and harder for everyone else

JW: Basically we could do the same on other documents
... I was think we could go to the name space of the root element
... and when the document is created it uses the root name space

CM: I think that's a good idea actually

DS: I think this is do-able, I don't think it's enough

JW: By doing that it would no longer be inconsistent
... to make element.CreateElement use the name space of the element on which it's called
... and then hopefully that will simplify things for users

DS: I understand what you are saying
... I think that is a good first stab at implementing something better
... I made a script library
... that does such sorts of things
... I just don't think it goes far enough
... I don't think that's the real thing that makes it hard to use SVG
... I think the real problem the element not being immediately being inserted into the DOM
... I think there is a case for that
... I think there is a case to have a method that inserts and sets the attributes

JW: It makes sense to extend that

DS: That's where I disagree
... I think we'd be overloading CreateElement

JW: You're saying that forget about the name space issues for the moment

<heycam> this works for me in firefox: javascript:HTMLDocument.prototype.createElement=function(n){alert('yo '+n)};document.createElement('svg')

JW: passing in parameters to pass in object literals for attribute values

DS: I can see both sides of this issue
... I personally think it's being overridden in this way
... I don't know what effect it would have on the JavaScript

CM: There is overloading in Java

JW: Default arguments?

CM: No
... effectively you can do something like that

JW: You can get the same effect?

CM: Yes
... To me this passing in attributes to CreateElement to create the element makes sense
... We could pass in a dictionary name of values
... e.g. a map of objects

DS: So when I was talking about adding some methods to SVG
... we were talking about one thing
... but here we are talking about overriding CreateElement
... and this puts us into the same area as the WebApps working group

CM: Is WebApps going to continue to work on DOM Core?

DS: Not sure what's going to happen to that document
... we have talked about taking on WebDOM
... I'm concerned about the length of time it would take to do that
... it something we need to take to the WebApps working group
... I'm not absolutely that they would want to take on these features
... I'm concerned that some of the things we are trying to do here is at odds with what they are doing

JW: To me it's a no-brainer whether it goes through them or not

DS: I've proposed things that I thought were pretty sensible
... and they got caught up
... I can bring this to the WebApps working group and see what they say

CL: Has there been any feedback about it?
... how have they responded?

DS: People like it

CM: I would rather take it to WebApps first
... and if nobody is interested there
... we can work on it ourselves

DS: I guess the other part is I like the insert interface
... which is different to CreateElement
... InsertElement and InsertElementNS would basically need the element name and optionally the name space

<shepazu> Element.prototype.insertElement = function( elementName, attributeObj, index ) {

<shepazu> Element.prototype.insertElementNS = function( namespace, elementName, attributeObj, index ) {

DS: The first one would insert it into the name space
... the second creates the element in the name space you specify
... the index can be left off
... or if there the location of where you want to insert it
... it would be a bit faster and a convenience

<shepazu> Element.prototype.insertAtIndex = function( el, index ) {

DS: Rather than insert before element or insert after element
... have an insert at index
... this is where I want this element

CM: It's odd there is only insertBefore

DS: I think it was an over looked
... so this just solves all the cases
... I'd like to actually propose all of these

JW: It wasn't that it was ideas that I talked about it was that the names were changed
... InsertElement and InsertElementNS
... to me it's like InsertBefore
... I wouldn't be expecting to pass a name
... CreateElement and CreateChild is what I'd like use as the naming sorts

DS: I think CreateChild is a little vague but I'm not going to argue that

JW: It almost makes sense to have just one function
... and just overload it
... to allow it to insert at another index
... It could be a bit of a problem because, if you have an index
... by default you want to create it so it doesn't append
... but you want to also pass something in
... for an index
... or append
... I guess -1 could be the default
... and that would mean do not insert this a child

DS: Please no
... using -1 as a default is not a good idea

<ChrisL> (reminds me of putting -999 into data as a "missing value" value)

AG: Using -1 is a bad idea

CM: Don't think about it as defaults
... think about it as overloaded methods

JW: Lets make it undefined then, it doesn't get inserted

CM: I think it if you don't pass the value in at all

JW: I guess I'm coming at this from the way our implementation works
... you could say passing in a negative number does a prepend

CM: I don't think it's something we need to discuss if it's an implementation detail

DS: We need to define what negative numbers do
... I wouldn't object to overloading CreateElement so much
... but we may constrain what is useful

CM: I think I agree with Doug with the index thing
... I'm happy with overloading with specifying attributes

JW: I'm not as enthusiastic about adding an index to CreateElement as I am to other methods

DS: Having CreateElement and CreateChild makes more sense to me
... then overloading CreateElement

<ChrisL> element.addKid

<jwatt> heh

<jwatt> nice and short

CM: I agree we should have some functionality to create an element and add some attributes

JW: I agree, which is why I thought of having createElement and createChild
... if you guys are happy to have it as two methods then I'm find with that

DS: I think InsertElement at index if you want to insert things at a different location
... I can draft something up

DOMFocusIn, DOMFocusOut, and DOMActivate

DS: In DOM 3 Events we are talkinga bout deprecating DOMFocusIn/Out/Activate

CL: What would use instead?

DS: Focus/Blur/Click
... FocusIn/Out both bubble
... Focus/Blur do not
... FocusIn/FocusOut have been proposed to be deprecated
... If they were in SVG we'd add a note in the errata that these are being deprecated in DOM 3 Events
... we'd just be noting that these things are available
... I don't think that there is a problem with noting that
... I don't know how much content uses them
... I've seen them used though

JW: I've seen them used though
... I don't know Mozilla would get this to fly
... Webkit would probably follow if Mozilla did it
... it seems to me you have a button and it can either be activated by clicking on it or focus and pressing a key

DS: Those things do generate a click event

JW: So click doesn't necessarily mean click
... is this the behaviour of all browsers already?

DS: Yes, I'm pretty sure
... I did a test

JW: There is still a bubble issue then
... can the others be changed?

DS: No
... I think there are uses for the bubbling
... the Xform guys thought there might be a use for bubbling

CM: I guess you're looking for an indication from us
... whether it's ok

DS: I'd like to get your feedback
... I think I'll probably deprecate them, unless I here a really strong argument about it

CM: I agree with the general sense to reduce duplication
... I don't know how much content extists
... but it would be good to move to a common set
... I'm not sure of use case for bubbling

DS: Did my analysis of what we could do for Tiny 1.2 and Full 1.1 seem ok?

CL: It seems reasonable
... I mean we don't really have much of a choice

DS: From a process point of view is it ok?
... I'm interested in making SVG as usable to authors as possible
... on thing I haven't tested is Focus/Blur in SVG
... I suspect in FF and other mainstream browsers it works

- DRAFT -

SVG Working Group Teleconference

05 Aug 2009

Attendees

Contents

SVG DOM improvements

DOMFocusIn, DOMFocusOut, and DOMActivate

Summary of Action Items

Scribe.perl diagnostic output