See also: IRC log
<trackbot> Date: 11 May 2009
<scribe> Scribe: anthony
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
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
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
<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
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
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at 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: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0114.html Found Date: 11 May 2009 Guessing minutes URL: http://www.w3.org/2009/05/11-svg-minutes.html People with action items: cameron eric erik[End of scribe.perl diagnostic output]