See also: IRC log
<trackbot> Date: 05 August 2009
<jwatt> hmm
<jwatt> idiot
<jwatt> ack
<scribe> Scribe: anthony
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
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/APIs/DOM APIs/ Succeeded: s/CreateElement/document.createElement/ Succeeded: s/upon/it on/ Succeeded: s/insert before/insertBefore/ Succeeded: s/CreateElement/createElement/ Succeeded: s/CreateChild/createChild/ Succeeded: s/niot/not/ Found Scribe: anthony Inferring ScribeNick: anthony Default Present: [IPcaller], heycam, shepazu, anthony, jwatt, +1.919.824.aaaa, ChrisL Present: [IPcaller] heycam shepazu anthony jwatt +1.919.824.aaaa ChrisL Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0024.html Found Date: 05 Aug 2009 Guessing minutes URL: http://www.w3.org/2009/08/05-svg-minutes.html People with action items: cameron doug[End of scribe.perl diagnostic output]