- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Wed, 05 Aug 2009 18:30:56 +1000
- To: www-svg@w3.org
http://www.w3.org/2009/08/05-svg-minutes.html
---
and below in the tracker nom nom nom format:
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
05 Aug 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0024.html
See also: [3]IRC log
[3] http://www.w3.org/2009/08/05-svg-irc
Attendees
Present
[IPcaller], heycam, shepazu, anthony, jwatt, +1.919.824.aaaa,
ChrisL
Regrets
Chair
Cameron
Scribe
anthony
Contents
* [4]Topics
1. [5]SVG DOM improvements
2. [6]DOMFocusIn, DOMFocusOut, and DOMActivate
* [7]Summary of Action Items
_________________________________________________________
<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> [8]http://www.w3.org/mid/4A791DAB.1020504@w3.org
[8] http://www.w3.org/mid/4A791DAB.1020504@w3.org
<shepazu>
[9]http://lists.w3.org/Archives/Public/www-svg/2009Aug/0010.html
[9] 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
[10]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
[11]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:
[12]http://simon.html5.org/specs/web-dom-core#dom-document-createele
ment
[12] 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('y
o '+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
Summary of Action Items
[NEW] ACTION: Cameron to Extract the interface and method names from
the IDL [recorded in
[13]http://www.w3.org/2009/08/05-svg-minutes.html#action01]
[NEW] ACTION: Doug to Follow up on ACTION-2645 and assign work to
the extracted interface and method names [recorded in
[14]http://www.w3.org/2009/08/05-svg-minutes.html#action02]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [15]scribe.perl version 1.135
([16]CVS log)
$Date: 2009/08/05 08:08:11 $
_________________________________________________________
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[16] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [17]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[17] 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.82
4.aaaa, ChrisL
Present: [IPcaller] heycam shepazu anthony jwatt +1.919.824.aaaa ChrisL
Agenda: [18]http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSe
p/0024.html
Found Date: 05 Aug 2009
Guessing minutes URL: [19]http://www.w3.org/2009/08/05-svg-minutes.html
People with action items: cameron doug
[18] http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0024.html
[19] http://www.w3.org/2009/08/05-svg-minutes.html
End of [20]scribe.perl diagnostic output]
[20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Wednesday, 5 August 2009 08:31:44 UTC