- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Mon, 11 May 2009 18:17:26 +1000
- To: public-svg-wg@w3.org
http://www.w3.org/2009/05/11-svg-minutes.html
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
11 May 2009
[2]Agenda
[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
Attendees
Present
ed, shepazu, heycam, anthony
Regrets
Chair
Cameron
Scribe
anthony
Contents
* [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,
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>
[12]http://dev.w3.org/SVG/modules/param/master/SVGParam.html
[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
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>
[13]http://dev.w3.org/SVG/profiles/1.1F2/publish/escript.html
[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
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> [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
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>
[15]http://lists.w3.org/Archives/Public/www-svg/2009May/0033.html
[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
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
[16]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
[17]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>
[18]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#pattern_o
verflow
[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
status
<scribe> ACTION: Eric to Move the "Rendering of patterns with
overflow="visible" is undefined" errata from Draft to Proposed
status [recorded in
[19]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
[20]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
Summary of Action Items
[NEW] ACTION: Cameron to Write a proposal for the Implementers panel
[recorded in
[21]http://www.w3.org/2009/05/11-svg-minutes.html#action02]
[NEW] ACTION: Eric to Move the "Rendering of patterns with
overflow="visible" is undefined" errata from Draft to Proposed
status [recorded in
[22]http://www.w3.org/2009/05/11-svg-minutes.html#action03]
[NEW] ACTION: Erik to Move the "Rendering of patterns with
overflow="visible" is undefined" errata from Draft to Proposed
status [recorded in
[23]http://www.w3.org/2009/05/11-svg-minutes.html#action04]
[NEW] ACTION: Erik to Write the proposal for the Working Group panel
[recorded in
[24]http://www.w3.org/2009/05/11-svg-minutes.html#action01]
[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
/scribe/
[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
n/0114.html
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