SVG Working Group Teleconference -- 11 May 2009

<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, filters
... 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 finished
... 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 level-of-detail

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

<shepazu> 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 classes
... 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 attribute\

<shepazu> parameters="base:green;petal1:white;petal2:lime;heart:lime"

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 attribute
... 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 suitable
... 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 development

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

<heycam> 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 things
... 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> 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 methods
... 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 description

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

<heycam> 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 panel
... 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 http://www.w3.org/2009/05/11-svg-minutes.html#action01]

<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 http://www.w3.org/2009/05/11-svg-minutes.html#action02]

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

<ed> 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 status

<scribe> ACTION: Eric to Move the "Rendering of patterns with overflow="visible" is undefined" errata from Draft to Proposed status [recorded in http://www.w3.org/2009/05/11-svg-minutes.html#action03]

<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 http://www.w3.org/2009/05/11-svg-minutes.html#action04]

<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

- DRAFT -

SVG Working Group Teleconference

11 May 2009

Attendees

Contents