W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2009

Minutes, 11 May 2009 SVG WG telcon

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Mon, 11 May 2009 18:17:26 +1000
Message-ID: <4A07DF16.7010203@cisra.canon.com.au>
To: public-svg-wg@w3.org



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

                                - DRAFT -

                    SVG Working Group Teleconference

11 May 2009


       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0114.html

    See also: [3]IRC log

       [3] http://www.w3.org/2009/05/11-svg-irc


           ed, shepazu, heycam, anthony




      * [4]Topics
          1. [5]Libre Graphics Meeting
          2. [6]Param Spec
          3. [7]Update on SVG 1.1 Second Edition
          4. [8]Method for server push via Never-ended documents
          5. [9]SVG Open 2009
          6. [10]Errata review
      * [11]Summary of Action Items

    <trackbot> Date: 11 May 2009

    <scribe> Scribe: anthony

Libre Graphics Meeting

    DS: Went well I think
    ... content is available online
    ... I talked to Intel about reviewing our specs 3D Transforms,
    ... good to get a H/W perspective
    ... I presented on the SVG scrubber

    <heycam> scour

    DS: I talked to the Inkscape guys and Scribus guys
    ... they had concerns about SVG in HTML
    ... I encouraged them to bring the concerns up on the mailing list

    CM: Outside of the Inkscape guys how much interest do you think
    there is in SVG

    DS: Quite a lot
    ... in the open graphics community
    ... there is a fair amount of discussion about SVG
    ... I also spoke to some designers
    ... and got their perspective on SVG
    ... they said they'd join the SVG mailing list
    ... we really need to start driving the Use Case and Requirements
    from a designer perspective
    ... I explained to the perspective thing
    ... they thought it was very useful
    ... it took a bit of explaining
    ... I've been working on my library for that
    ... and made edits to the spec
    ... I have a major change I want to make to it

    CM: Did you want to talk about it today?

    DS: That would be good

    CM: What was the general feel from that conference
    ... regarding linking to true type fonts?

    DS: There were mixed feelings
    ... many of them feel they want to link to them
    ... I do think there are few people there who were in favour of
    other types
    ... EOT
    ... I might type up a short report
    ... there were definitely interests
    ... on SVG Fonts from the perspective of complex glyphs

    CM: How about the print people, where they interested in following
    the SVG Print stuff?

    DS: People came up and asked me about it
    ... Jon Cruz from Inkscape presented on Colour Management
    ... I explained how we split out Colour Management and Pagination
    ... there was a lot of interest in Pagination
    ... I think we really need to make progress on both these specs

    CM: Given that there is a fair few people that want to see this
    ... and that there is little work left to be done
    ... we should move on that

    DS: There were some people that were interested in multi-image
    ... and level of detail
    ... we should put something in a spec for multi-image and

    CM: We should make a list of things that are in that draft
    ... that are not in Tiny

    DS: I think that is about it, unless you guys have questions?

    CM: Sounds like it was worth going to

    DS: Definitely

Param Spec

    DS: I uploaded a new spec

    <scribe> ... new draft of the spec


      [12] http://dev.w3.org/SVG/modules/param/master/SVGParam.html

    DS: The more I thought about it
    ... the less I liked the <ref/> element
    ... I guess my question is
    ... What do we think about the name 'param'
    ... is it the right name?

    CM: I think 'param' sounds good enough
    ... and describes what it is going to reference
    ... If it was going to reference something different
    ... I think the name would be different

    DS: I think you're right
    ... It's probably best to keep the name as what they do
    ... I added a content value for text elements
    ... and it actually does insert content into the DOM
    ... One thing I want to fix is accessibility rules
    ... I want stuff to be put in the DOM
    ... I added a param element that was similar to the param element
    from HTML
    ... I talk about how it should be available on animateObject, Image
    and Use
    ... and can be used on Audio, Script and Video
    ... haven't defined what happens there yet
    ... I cleaned up the IDL def
    ... they're still not done completely
    ... As I was explaining params to designers
    ... I used CSS as an analogy
    ... I can still see an argument that this should be done with
    ... and not params

    CM: If in the end that most things can be defined in properties then
    maybe this param value
    ... should be value that you can use in CSS property values

    DS: What can this do that you couldn't do with CSS
    ... assuming some attributes where properties
    ... I mean CSS doesn't have access to somethings like query strings
    for example
    ... I could see it being used where a class is placed on an element

    CM: So this idea would be
    ... from the outer referencing element

    DS: I'm still thinking of implications of that

    CM: Pushing styles in instead of pulling param values in

    DS: There is another property we could define
    ... and that is parameters
    ... Currently object param elements and URL query strings
    ... Instead of having child-param elements you have a parameters


    AG: I can see the argument why you're considering CSS

    DS: You can make that apply to multiple elements at the same time
    ... maybe a GPS device could have access to the parameter values
    ... then CSS should also have a way to affect the parameters
    ... we don't want to be defining something if there is maybe a way
    to do it in CSS
    ... I'm still thinking through if this is the right way
    ... I think that getting the parameters could be covered by CSS. You
    could do some of the effects using CSS not all of them
    ... but some of them

    CM: But then on the other hand if we didn't do it for all of them
    ... there might still be away to reference it form the XML attribute
    ... I guess that one disadvantage of the parameters
    property/attribute is that you have them all as one list on the
    ... it's a bit hard to change

    DS: The iFrame can't take elements as children instead iFrame
    content is treated as a text node
    ... I'm wondering if this would be useful as an '@' rule

    CM: Which way? I mean having things for an iFrame might not be
    ... you know how you wanted to have the defaults there
    ... so maybe an '@' rule would be useful if you wanted to keep those
    default things

    DS: I fixed it up in my implementation
    ... I fixed up some corner cases
    ... so that it emulates the use element

    CM: I think it's useful to have this scripting alongside the spec

    DS: It's very useful prototyping it
    ... because it raises questions
    ... then if I had just written a spec
    ... I'm working on the Primer
    ... another thing that's nice about prototyping
    ... is it gives you a way to explain the functionality

Update on SVG 1.1 Second Edition

    CM: Last week I said I had it pretty much all building
    ... I forgot a chapter
    ... but now it really is all building
    ... I haven't got to diffing the spec yet
    ... I have made some updates
    ... that are worth mentioning


      [13] http://dev.w3.org/SVG/profiles/1.1F2/publish/escript.html

    CM: I changed quite radically, what the ECMA script binding language
    looks like
    ... In 1.1 1st edition
    ... it's an auto generated thing
    ... because this is the way it had been written for other DOM specs
    ... it's not particularly useful
    ... because SVG doesn't use any square brackets to do any tricky
    ... basically it's a lot of overhead for something simple which is
    what we need
    ... So I've changed it
    ... and I want to check if people think it's ok

    <heycam> [14]http://www.w3.org/TR/SVG11/ecmascript-binding.html

      [14] http://www.w3.org/TR/SVG11/ecmascript-binding.html

    ED: The 1st Edition doesn't have much just a link right?

    CM: Yes
    ... I mean another issues with that appendix in the 1st edition
    ... is that it's pretty imprecise about objects it's talking about
    ... in the future we want to use Web IDLs
    ... for conformance requirements
    ... the requirements I've written
    ... is a very small subset
    ... it doesn't specify things in great detail
    ... it's more so loose requirements

    ED: That's ok
    ... are you saying we should completely remove the full list of
    ... and just have an IDL?

    CM: A couple of problems are it's very repetitive
    ... you don't have to list everything for every possible property
    ... I think we could do a way with the full list and just have the

    ED: So seeing how the language binding is not normative
    ... in 1.1
    ... I don't see the point in keeping the additional list here

    CM: that point about the appendix being normative or not
    ... I raised it on the mailing list
    ... it doesn't make sense to keep it informative
    ... which is to say I think it should be normative
    ... so at the very least
    ... all the tests in the test suite that use script
    ... I think you can't say that those tests need to be passed
    ... in the conformance requirements part

    <heycam> "The viewer must have complete support for an ECMAScript
    binding of the SVG Document Object Model."

    CM: I guess that doesn't mean a particular binding that's in the
    binding appendix
    ... if we don't require a particular binding in script
    ... then there is no normative thing that those test relies on
    ... to claim those tests need to be passed
    ... do you agree ED?

    ED: I guess
    ... might be a bit loose at the moment
    ... so I don't mind having the binding normative
    ... it seems to be normative already
    ... but we should make it explicit
    ... I think we should state for each appendix we have
    ... whether it is normative

    CM: I agree
    ... it would be good to make it clear

    ED: Just need to add a statement at the top of each

    AG: I agree

    CM: Given that the appendix is informative you don't mind dropping
    that big list?

    ED: If we make it normative
    ... the IDL is also normative
    ... having a statement saying you have to implement this IDL
    ... I don't see the point in repeating
    ... it's just another place where things can go wrong

    CM: If there are one or two things with special behaviour
    ... we are likely to miss it
    ... even if it is auto generated\
    ... so in terms of what I'm doing at the moment
    ... I'm getting the filters module building
    ... the tricky thing is
    ... there are no references to other specs
    ... I noticed in the build script
    ... that you put in <spec> elements
    ... so I want the script to import it
    ... with out an special work

    ED: So in the filters spec, I need to reference both parts in 1.2
    Tiny and parts from 1.1 or perhaps what will be 1.2 Full
    ... there's no place to link to
    ... that's why I'm still linking to 1.1
    ... and I have special mark up
    ... to quickly switch links

    CM: So what 1.1 things did you need to link to?

    ED: DOM things
    ... clipping, masking
    ... it might be possible to remove some of the dependencies
    ... or make them optional in some way

    CM: At the moment I think the definitions file that I have building
    ... that will mostly work for referencing the 1.1 1st edition
    ... for Tiny at the moment I'm writing up a definitions file

    ED: I guess the other modules we have in progress now
    ... could have the same problem

    CM: Yes
    ... need to be careful about elements defined in both
    ... I think it should work when I'm done

    ED: On thing I thought about
    ... was how many changes have you made to the filters chapter?

    CM: Dunno if I've made any changes
    ... when I get around to doing the diffs
    ... I'll find out

    ED: We will probably need to sync up to errata items

    CM: So will the extended filter primitives extend 1.1?
    ... or Tiny?
    ... I guess one of the differences is the DOM

    ED: That's one thing I hadn't got to yet

    CM: It's just extending the trait table?
    ... not much element specific DOM properties

    ED: Maybe one type that isn't in
    ... the rest of it is just basic types
    ... I will get to listing those properties an attributes
    ... for uDOM access as well

    CM: I suppose we will just say
    ... these IDL fragments that apply for 1.1
    ... also apply for 1.2

Method for server push via Never-ended documents


      [15] http://lists.w3.org/Archives/Public/www-svg/2009May/0033.html

    CM: Got a mail on mailing list asking about
    ... a feature for streaming data
    ... I think he wants to stream some extra document content/data
    ... and have it displayed in the document
    ... he draws the comparison to progressive rendering
    ... given we've got that and the discard element
    ... I think we can support what he wants to do

    ED: I think progressive-rendering should already cover this use case
    ... does it saying anything about some particular thing missing

    CM: It sounds like he wants this more for HTML
    ... but says this could also apply to SVG
    ... not sure if he realises this is already in SVG
    ... so maybe I'll point that out to him

SVG Open 2009

    ED: We got a mail from David Daley asking us to maybe make some
    proposals for SVG Open panel sessions
    ... previously we've had implementers panel and Working Group panel
    ... I still think it would be still good to have the Working Group
    ... I think we should propose that
    ... as for implementers
    ... I don't know
    ... people seem to be interested in hearing what implementers are
    doing currently
    ... I'm not sure if it's worth having a joint panel
    ... or if it's worth having them separate

    CM: Not sure
    ... it'd be worth finding out
    ... who's not on the WG
    ... that would want to be on the implementers panel

    ED: I guess if we want to go forward with that

    <shepazu> inkscape isn't on the WG, nor is Google

    ED: I could write up a proposal

    <shepazu> but we could have a joint panel anyway

    ED: There should be previous proposals from previous years
    ... So it shouldn't be too hard
    ... to draft something up

    CM: Anyone doing papers?

    ED: I'll probably submit one

    <shepazu> I plan on doing an accessibility presentation

    AG: I'll probably do one

    <scribe> ACTION: Erik to Write the proposal for the Working Group
    panel [recorded in

    <trackbot> Created ACTION-2555 - Write the proposal for the Working
    Group panel [on Erik Dahlström - due 2009-05-18].

    <scribe> ACTION: Cameron to Write a proposal for the Implementers
    panel [recorded in

    <trackbot> Created ACTION-2556 - Write a proposal for the
    Implementers panel [on Cameron McCormack - due 2009-05-18].


      [18] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#pattern_overflow

Errata review

    ED: This is adding a sentence at the end there
    ... "if the 'overflow' property is set to visible the rendering
    behaviour for the pattern is undefined."
    ... the action is still open
    ... because I haven't raised the issue
    ... and I still need to respond to Dr. Hoffmann

    CM: May want to change the spelling of "behaviour" to "behavior"

    AG: We should do a run through of the entire document
    ... to check for cases like that

    CM: Is this a category 3?
    ... I think it could be 2
    ... it doesn't change non conforming implementations to be
    conforming and vice-versa

    ED: It does change non conforming implementations to be conforming
    ... if you don't do overflow

    CM: I guess so if you don't do the overflow

    ED: I'm probably more comfortable as keeping it category 3
    ... any objections to moving to proposed?

    All: None

    RESOLUTION: We will move the "Rendering of patterns with
    overflow="visible" is undefined" errata item from Draft to Proposed

    <scribe> ACTION: Eric to Move the "Rendering of patterns with
    overflow="visible" is undefined" errata from Draft to Proposed
    status [recorded in

    <trackbot> Sorry, couldn't find user - Eric

    <scribe> ACTION: Erik to Move the "Rendering of patterns with
    overflow="visible" is undefined" errata from Draft to Proposed
    status [recorded in

    <trackbot> Created ACTION-2557 - Move the "Rendering of patterns
    with overflow="visible" is undefined" errata from Draft to Proposed
    status [on Erik Dahlström - due 2009-05-18].

    CM: In the errata file there are still a few that need work on them
    ... I don't think that is going to hold up the publication of the
    errata document
    ... the things I'm worried about is changes that get made that
    aren't published
    ... I don't mind keeping the things that are currently in the
    document in there
    ... and if they don't get done for 2nd edition
    ... we might want to keep them around for the next edition

    ED: Just looking at the process document
    ... I guess we could see the edited recommendation as an errata
    ... but we definitely have to announce it
    ... it would be good to give people time to comment on it
    ... before we publish the final doc

    CM: Maybe when we publish the errata we can announce the other
    changes we've made

    ED: It's a bit time consume to edit it two places

Summary of Action Items

    [NEW] ACTION: Cameron to Write a proposal for the Implementers panel
    [recorded in
    [NEW] ACTION: Eric to Move the "Rendering of patterns with
    overflow="visible" is undefined" errata from Draft to Proposed
    status [recorded in
    [NEW] ACTION: Erik to Move the "Rendering of patterns with
    overflow="visible" is undefined" errata from Draft to Proposed
    status [recorded in
    [NEW] ACTION: Erik to Write the proposal for the Working Group panel
    [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [25]scribe.perl version 1.135
     ([26]CVS log)
     $Date: 2009/05/11 08:04:16 $

      [25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [26] 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 [27]http://dev.w3.org/cvsweb/~checkout~/2002

      [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/designs/designers/
Succeeded: s/the/linking to/
Succeeded: s/... that point/CM: that point/
Succeeded: s/thinks/things/
Succeeded: s/yers/years/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: ed, shepazu, heycam, anthony
Present: ed shepazu heycam anthony
Agenda: [28]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJu
Found Date: 11 May 2009
Guessing minutes URL: [29]http://www.w3.org/2009/05/11-svg-minutes.html
People with action items: cameron eric erik

      [28] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0114.html
      [29] http://www.w3.org/2009/05/11-svg-minutes.html

    End of [30]scribe.perl diagnostic output]

      [30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Monday, 11 May 2009 08:18:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC