W3C home > Mailing lists > Public > www-svg@w3.org > August 2009

Minutes, 5 August 2009 SVG WG telcon

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Wed, 05 Aug 2009 18:30:56 +1000
Message-ID: <4A794340.7090006@cisra.canon.com.au>
To: www-svg@w3.org


and below in the tracker nom nom nom format:


       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

05 Aug 2009


       [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


           [IPcaller], heycam, shepazu, anthony, jwatt, +1.919.824.aaaa,




      * [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


       [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

    <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

    <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

    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-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
    ... 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
    ... 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

    <heycam> this works for me in firefox:
    o '+n)};document.createElement('svg')

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

    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
    ... 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

    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

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

    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"

    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
    ... 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

    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
    [NEW] ACTION: Doug to Follow up on ACTION-2645 and assign work to
    the extracted interface and method names [recorded in

    [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

      [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
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:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:18 UTC