See also: IRC log
<trackbot> Date: 03 September 2010
<Cyril_Concolato> scribe: Cyril
<ChrisL> scribenick: Cyril_Concolato
ChrisL: some examples are not in the spec
when specifying a paint you can use all existing options plus currentFill and currentStroke
you can then stroke a path and the markers with the same stroke
I blew off some editorial comments
everything should be animatable
Doug: we should have a look at all of them
ChrisL: couple of cleanups that I
did, the spec has not changed for 2 years
... the need for DOM came up to get an individual primitive or the whole geomrty
... but when the effect is used multiple times, we need to discuss how to do that
ED: the same problem exists with gradients
ChrisL: there was a concern that union/intersection are complex
anthony: there are
... I don't know how fast it could be once animated
ChrisL: why do this in the
language, why not in the authoring tool
... but if it's dynamic it has to be in the client
Doug: also for interchange between authoring tools
CC: our concern was also
complexity but it can be explained in a note
... why currentFill and currentStroke are linked with vector effect
ChrisL: it could be added to the main spec
CC: we also think that vector effect can be used for grouping path semantically but we are concerned with the file size increase
ChrisL: if it's a modest increase in file size it should be acceptable
CC: is adding points to SVG a feature related to vector effects
<ChrisL> Its a good idea but no obvious intersection with vector effects
CC: yes but points may be shared
... and if we want to express that sharing and if we use vector effects to share paths between objects, it might make sense to have points in vector effects
Tav: path along path
... is it insane ?
ChrisL: having a shape repeated along a path was shown in the mapping requirements
Tav: I can show an example of a object being stretched along a path
<tbah> Lizard along path http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffects-PatternAlongPath.html
<ChrisL> and not ties to the subpath positions, like markers are
CC: It could be a way to make variable stroke along a path
<ChrisL> yes that would be very interesting
Tav: in Inkscape you have a
pattern and a path and you can edit them separately
... it would be nice to be able to edit when the positioning of the pattern is active
ChrisL: I want that we agree on any new feature so that I can move on with the spec
CC: we will provide feedback when we have implemented the use of vector effect for our application (superpath)
ED: I don't have the ressources at the moment to work on it
ChrisL: if anyone has an
implementation it would help to move the spec along
... I'll try to get the spec ready for another draft
... the spec does not talk at all about API
... how can it be best done ?
... a method on each graphical element or on the filter ?
DS: having the list of places where an effect is used could be useful for online editors
ChrisL: that could fix the gradient problem
Anthony: didn't we put wording in the spec about that ?
ChrisL: I don't recall
ED: if you have a gradient that use bouding box unit, on the gradient we could have an API to evaluate the gradient on a specific context
<shepazu> that would allow us to evaluate an effect on an element before it's applied, which could be useful, if it's not too expensive
ChrisL: the vector effects don't
change the stroke
... I wonder if it would be better to separate the stroke into two halfs
... inside and outside so that you can manipulate them separately
DS: that should be accessible with a short hand
<shepazu> it would be nice to have 'stroke-width-inner' and 'stroke-width-outer'
<shepazu> and shorthands should be added to the VE spec
<ed> topic: SVG 1.1 Last Call
<ChrisL> scribenick: tbah
<ed> CL: don't check the file in, gets picked up by tracker and linked to every issue
DS: what about the issue with SVG pointer-events on the svg root, esp. used in HTML
<ed> that's ISSUE-2364, right?
<trackbot> ISSUE-2364 -- SVG 1.1 may be ambiguous about the root element acting as a proximal event target -- raised
ChrisL: Don't close issues for last call or they disappear (XSLT doesn't pick it up).
<ChrisL> s/dissapear/dissapear from the autogenerated disposition of comments/
<trackbot> ACTION-2800 -- Chris Lilley to send in and track the media type registration for image/svg+xml -- due 2010-06-24 -- OPEN
ChrisL: Received comment that there should have two different media types for svg and compressed svg.
ChrisL/Cyril: But this isn't necessary since it is handled by content headers.
ChrisL: Please look at registration to see how SVG content is handled by clipboards; does it work?
<ChrisL> Macintosh Universal Type Identifier code:
<ChrisL> org.w3c.svg conforms to public.image and to public.xml
<ChrisL> Windows Clipboard Name:
<ChrisL> "SVG Image"
<ChrisL> don't know for kde or gnome, do they use internet media type?
<ChrisL> tracker, status
<ChrisL> trackbot, status
<ChrisL> ACTION: tavmjong to investigate Inkscape SVG on clipboard usage [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action01]
<trackbot> Created ACTION-2833 - Investigate Inkscape SVG on clipboard usage [on Tavmjong Bah - due 2010-09-10].
<shepazu> I copy-pasted that with FF
tav: Inkscape seems to copy as text the svg file... but will investigate further.
DS: It sounds like ChrisL has done due diligence on established precedents.
<ChrisL> Copy and pasting the text is needed, but is separate from copy pasting an image (for example to drop into a dtp program)
<ChrisL> I checked what MathML did and looked at some documentation for windows and macosx; did not find good docs for linux gnome, or kde
ED: Is there something to specify if the content is gzipped or not?
<trackbot> ACTION-2809 -- Erik Dahlström to investigate ISSUE-2334 and report back -- due 2010-07-06 -- OPEN
ED: Basically done, will write an email.
<trackbot> ACTION-2812 -- Erik Dahlström to find the test case, commit it and make some proposed wording -- due 2010-07-13 -- OPEN
<ChrisL> relates to ISSUE-2335 -- Clarify feConvolveMatrix bias property, specificasly the bias attribute
ED: Finding the test case probably not too hard, but will need to check that it does what people want.
<trackbot> ACTION-2813 -- Chris Lilley to propose wording for ISSUE-2336 to say if it is malformed it doesn't have an effect -- due 2010-07-13 -- OPEN
ChrisL: Change checked in, no comment back from commentor.
<ChrisL> ah, i now see he did agree http://lists.w3.org/Archives/Public/www-svg/2010Jul/0081.html
<trackbot> ACTION-2814 -- Anthony Grasso to add wording to the specification to say that the behaviour is unspecified for those cases in ISSUE-2337 -- due 2010-07-13 -- OPEN
Anthony: Still working on it.
<trackbot> ACTION-2817 -- Chris Lilley to add the promised note relating to ISSUE-2340 -- due 2010-07-13 -- OPEN
ChrisL: Made test case, got different results in different implemenations.
<ChrisL> erik: check animval in the dom to be sure its not cut off at the semicolon
<ChrisL> <animate keytimes="0s, 2.9s" attributeName="xlink:href" values="../images/linkingCircle-f.svg#svgView(viewBox(120,200,40,40));../images/linkingCircle-f.svg#svgView(viewBox(64,227,72,72))"
ED: Try quote marks.
<ChrisL> erik: try quote marks around each uri
DS: Is that allowed?
<ChrisL> <animate keytimes="0s, 2.9s" attributeName="xlink:href" values="'../images/linkingCircle-f.svg#svgView(viewBox(120,200,40,40))';'../images/linkingCircle-f.svg#svgView(viewBox(64,227,72,72))'"
<ChrisL> sowe would then say that inside quotes, ; is not treated as a smil values list separator
<ChrisL> erik: you could use url escaping too
<ChrisL> so %3B would be the escape here
Cyril: Would first split list by ; and then evaluate.
DS: Quoting would be nicer... maybe something for SVG2.
ChrisL: Will still work on this.
<ChrisL> ok so I will make a new test, with percent escaping and check in the dom for animval
<trackbot> ACTION-2818 -- Chris Lilley to investigate ISSUE-2341 and look for previous comments -- due 2010-07-13 -- OPEN
Cyril: Propose to copy 1.2Tiny text.
ChrisL: Will do that if no one objects.
<ChrisL> this text http://www.w3.org/TR/SVGTiny12/animate.html#complexDistances
<trackbot> ACTION-2821 -- Chris Lilley to update the references section for issue-2344 -- due 2010-07-13 -- OPEN
<ChrisL> cyril: need to update 'list of' in types section too
ChrisL: Changed and approved.
<ChrisL> issue is closed, commentor agrees
ED: Need actions for rest of items.
<trackbot> ISSUE-2364 -- SVG 1.1 may be ambiguous about the root element acting as a proximal event target -- raised
<ChrisL> (updated disposition of comments at http://www.w3.org/2010/09/SVG1.1SE-LastCall/dump.html )
DS: If you have an SVG plugin in HTML, and you click on a non-existent backround, should the event be passed through?
Cyril: Answer: It can refuse to handle the event and pass it back to the system, so the containing application will handle it.
<anthony> Scribe: Anthony
<scribe> ScribeNick: anthony
DS: Now all browsers are
consistent for referenced content
... they violate the SVG spec
ED: The point about the reference
... The behaviour would be hard to change
... and violate some security protocols
CC: Looking at
... when you click on inline
... on the bottom
... you get two events
DS: Look at the code
... it's a single event
... but two boxes
... on question is does the event bubble
... bubbles for an inline case
ED: It's never bubbled between documents
CC: I think the inline case is correctly implemented
... it's not in FireFox
AG: Want it to be consistent
DS: Click the background
... which is incorrect
ED: I'd assume that the click goes through transparent areas
CC: We need to agree on behaviours and see if it's correct in the spec
DS: Need to look at use cases and
... so, the argument was raised that treading SVG like a <div> since it has dimensions if you clicked inside that <div>
... it dispatches the event
CC: Even with transparent background?
... so question is have to establish what the default is
... and how do you change it
ED: We had something like
... but we asked to change it
CC: Have to be consistent with SVG in HTML and SVG in SVG
DS: We need to look at the
... currently, Opera and Webkit behave one way with inline SVG
... the SVG root does not intercept events
... it passes them through
CC: Nothing happens in the SVG
... regards to this event
DS: SVG spec is moderately clear on this
CC: IE9 is doing as Opera is doing
DS: I would prefer that inline and referenced SVG behaved the same way
ED: Changing that now
... would be bad for SVG in general
... people have come to expect certain behaviour
All: [16.5 Read through Processing order for user interface events]
DS: Clarify that this section is about hit testing and not propagation
ED: Would be better if there was a graph here
DS: Problem with the section is it confuses hit testing, event propagation and order of processing
ED: It's trying to describe a flowchart or something
DS: Doesn't talk about things
like selecting graphics elements
... when SVG was written we didn't talk about default view or window
ED: How would you change this?
DS: Instead of processing
... I would break it down to a section on hit testing
CC: Something has been hit? something not hit?
DS: Yes, if something hit. Go
through and process actions
... If it has not been hit
... give a context menu
ED: Would be nice to have an SVG
... down the side
... that matches the text
AG: I agree, much easier to read and implement
ED: It's pretty clear what needs to be done
DS: So we are going to do this in SVG 1.1 Full 2nd edition
CC: We have this text in Tiny 1.2
DS: We pulled out the part on pseudo classes
CC: Has this other bit - 13.8 Event dispatching
ED: It's different
... but might need an errata on Tiny 1.2
<scribe> ACTION: Doug to Clarify section 16.5 Processing order for user interface events relating to problems in ISSUE-2364 [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action02]
<trackbot> Created ACTION-2834 - Clarify section 16.5 Processing order for user interface events relating to problems in ISSUE-2364 [on Doug Schepers - due 2010-09-10].
CC: What about key events?
DS: That's another matter
... that's why saying this is about hit testing is relevant
CC: That's a whole different discussion. But at some point someone should investigate this
DS: ED you're saying for security
reasons, you're not going to allow events to pass through in an
... It's the same in object
... and if you change the one
... people would expect the other to change
ED: If you have an <img>
element it's like a static image with no script and no
... so it's the HTML you're getting events on
DS: Do you treat image and object the same?
... I assume object, embed and iframe behave the same
... embed not so much
... object and iframe is mostly the same I think
CC: What about SVG <image>
ED: It's defined in the
... but should behave the way as <img>
DS: I understand why are you
... but for content creation it's a pain
... say you have some SVG and you want to click through on the element and where there isn't SVG content you
... want to get to the HTML
ED: So you if you have
transparency you get the HTML?
... Does the same thing happen for PNG?
... So we treat it the same
DS: I'm talking for object here
ED: Not sure we are talking about the same thing
DS: Look at my example
... We need to have a larger discussion about clicking through the transparent content would be a problem
AG: This would be a good thing to discuss at TPAC
CC: When the SVG is in the document it's behaviour is the same as a <div>
DS: I'm saying for the inline
... Maybe this needs to happen during a telcon
... because we want all browsers to have the correct behaviour
ED: There might be use cases the
... not just having events go through
DS: I said you set pointerEvents
... as I suggested
ED: I just think this is something that goes beyond SVG content
CL: Could probably put that wording in the integration spec
DS: A quick test that mouse move
on an empty SVG document intercepts i.e. the root dispatches
... All the modern browsers I tested
... this is contrary to ASV and seems to be contrary to the spec
... but is consistent with HTML
<scribe> ACTION: Doug to Add a table to the integration document about the embedded and inline SVG with regards to pointer events on the SVG root [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action03]
<trackbot> Created ACTION-2835 - Add a table to the integration document about the embedded and inline SVG with regards to pointer events on the SVG root [on Doug Schepers - due 2010-09-10].
<trackbot> ISSUE-2363 -- Last Call Comment: Reconcile 'stroke' presentation attributes on <image> -- raised
ED: I think Cameron and me have
responded to this on the list
... saying what we have now in the spec
... is a lot better than what was in previous 1.1 spec
... so in the previous 1.1 spec we had DTD to say what attributes where on each element
... so now have something that can be expanded and is more readable and made it more clear
... that presentation attributes can be specified anywhere
... even if they don't apply to the element it's specified on
CL: So specified and applied to are distinguished?
CL: Therefore we should reject
... because it's a no change required
... The issue was raised by Doug
DS: Please show me where it's specified
ED: That's one example
... it clearly says applies to
DS: However if you go to
... And you click on the, presentation attributes, it lists it
CL: That's right
... it doesn't apply to it
DS: I was talking to someone on
IRC and they were trying to do this
... (stroke image element)
... and they go to the presentation attributes they can set on the element
... I think we should change the spec to things that have an effect on the element
CL: So it's currently done the
... for each property it says what it applies to
... this is an argument we've had since the entire life time on the SVG
... then others say somethings should be set only on an element only
... in some cases things would be disallowed because when children
... were placed in the element
... sometimes things apply
DS: Maybe it's the choice on how fine grain things are categorised
CL: This is going against a
decision that was made 2 -3 years ago
... it's a huge change
... to be doing this
DS: Let's be clear
... we all agree it is confusing
CL: It could be confusing
ED: In some cases yes
DS: It has been proven to be
confusing to some people
... including me
CL: Presentation attributes are in the form of properties
CC: As an implementer it reads
... as an author
... it probably doesn't
... what matters at least someone can be confused
ED: What are you suggesting?
DS: Is it work the extra time to do this, to change it
CL: Change how?
DS: So, maybe in this case if we
wanted to do the minimum work if it could some how be styled
... if it has an effect an element
ED: Yes, that would be nice
... make them bold
... if they applied to the element
CC: As long as it is editorial
CL: It will be editorial
... with all the presentation attributes it is a link which takes you to the definition
DS: How is this generated?
ED: It's generated from the XML, IDL
CL: Another thing we could do to
make the spec better
... is to say the difference between applies to and specified on
CC: Adding the new sentence you
said will help
... but changing the style and linking to that
... would at least give a hint that it's not that simple
... having it in bold would say would it apply
... it's precise and it's clear
... but it doesn't speak to most of the people
ED: My objection is don't we have
that sentence somewhere?
... I would not want to have two sentence that say two different things about the same topic
DS: There is a sentence here in
... two links away
ED: Specificity of 0 is in there 6.4
<shepazu> For user agents that support CSS, the presentation attributes must be translated to corresponding CSS style rules according to rules described in Precedence of non-CSS presentational hints ([CSS2], section 6.4.4), with the additional clarification that the presentation attributes are conceptually inserted into a new author style sheet which is the first in the author style sheet collection. The presentation attributes thus will participate in the CSS2 cascade
CL: The section on presentation attributes could have it in there
DS: That would be two links away
DS: could have it here so that
it's one link away
... Could say "Note not all presentation attributes specified on an element will apply to the element. For a list of elements that a property applies to see... blah"
... how hard would it be style them bold or normal?
ED: I think that would be a bit
... I don't think we have a list or things
... adding the sentences here would be less work
DS: In SVG 2. I would like us to re examine if we can have a stroke around the edge of an image?
CL: Wouldn't that be a border?
DS: Depends on if we allow padding around it and borders have different properties to borders
<scribe> ACTION: Chris to Include the above disclaimer about the applicability of presentation attributes on elements [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action04]
<trackbot> Created ACTION-2836 - Include the above disclaimer about the applicability of presentation attributes on elements [on Chris Lilley - due 2010-09-10].
back from break
DS: First we need to agree on the set of tests that make up the SVG 1.1 2nd edition test suite
CL: Previously, the action of building the test suit generated all the files to do the testing
AG: I believe the reporting stuff is working
<scribe> ACTION: Anthony to Check if report generation for the test suite is working and report back [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action05]
<trackbot> Created ACTION-2837 - Check if report generation for the test suite is working and report back [on Anthony Grasso - due 2010-09-10].
AG: So the way the test suite
generation scripts work is you have a list of tests and every
component in the test suite
... is generated according to that list
DS: For all the tests we don't have results on, each implementer can run the tests and report back to us
<scribe> ACTION: Doug to Run the tests on Safari on Mac [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action06]
<trackbot> Created ACTION-2838 - Run the tests on Safari on Mac [on Doug Schepers - due 2010-09-10].
<scribe> ACTION: Chris to Run the tests on Firefox on Windows [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action07]
<trackbot> Created ACTION-2839 - Run the tests on Firefox on Windows [on Chris Lilley - due 2010-09-10].
<scribe> ACTION: Erik to Run the tests on Opera [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action08]
<trackbot> Created ACTION-2840 - Run the tests on Opera [on Erik Dahlström - due 2010-09-10].
<scribe> ACTION: Cyril to Run the tests on GPac [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action09]
<trackbot> Created ACTION-2841 - Run the tests on GPac [on Cyril Concolato - due 2010-09-10].
<scribe> ACTION: Tav to Run the tests on Inkscape [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action10]
<trackbot> Sorry, couldn't find user - Tav
<scribe> ACTION: Tavmjong to Run the tests on Inkscape [recorded in http://www.w3.org/2010/09/03-svg-minutes.html#action11]
<trackbot> Created ACTION-2842 - Run the tests on Inkscape [on Tavmjong Bah - due 2010-09-10].
CL: So that was news to me that you could make a complex path going through a few points
TB: We have a sophisticated
routing than what's proposed. But because the path between
objects can be enhanced
... we wouldn't be losing anything that's already in inkscape
DS: [Demo's current connectors
... Connector goes from centroid to centroid
AG: This could be difficult to
... particularly if you're clipping parts of an object out
CL: Why not the center of the bounding box?
DS: Different possible syntax for
... if you're looking at the bounding box of the parent
... it'd be useful to allow a percentage of the parent bounding box
... A port has a specific role of point
... it is a child of a shape
... point is a non rendering element
... you can style it with a marker
CL: Effectively it's a zero length line
DS: Each node being linked to has
a port that will be preferential to where connection is
... it will always go to the nearest between two ports
TB: Can you specify
... the port?
... I've got a sample implementation and done some work on this
... I want to know if we agree to work on this
CL: Do we agree that this is the direction we should go in?
CC: How would you add it, if you
were to add it?
... a separate module?
... I'd intend for it to be part of SVG 2
... we've had a level of requests for this
TB: We've had requests for this as well
DS: This is a common case I've seen again and again
ED: Not convinced yet
DS: This is does not add, drag and drop, it does not add routing
ED: Does it add any dependencies that you need to resolve?
DS: There are very well defined
... when a shape is moved
... the connection changes
ED: We have to track a lot of
... the less we need to do the faster it will be
... the graph of dependencies grows
... you can do this in script
... just not convinced
DS: Yes, you're right
... it's a common use case that is not easy to do in script
... it doesn't establish the semantics and behaviour
... I think it is a compelling feature that makes SVG very attractive for use
CC: You could do the
... and say this is a line
... and this is connector
... and then put a marker on it
... This could also be done with Cameron's constraints
DS: This is a subsection of
constraints. Gives people a lot of power to build things in
... getting the connector for free gives people something accessible
... and graphics like this will not be accessible without this
CC: Couldn't you do this with a
... and give it a role of connector?
DS: Yes, but it doesn't give the author any reason to do this
ED: Why does it have to be in
... why not stand alone?
... in a completely different spec
... used in other languages
DS: What other languages?
ED: Connect this div to another div
DS: But that is not a visual
... SVG is a visual language
... this would pretty much the highest thing we would have at this level
CC: There are two parts the
rendering constraints and the semantics
... I think we can have either the semantics or the constraints
CL: So I think that he is
... that use <path> instead of <connector>
... point is fine
ED: We should close for the
... and continue discussion later
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/comlex/complex/ Succeeded: s/for authoring exchanges/also for interchange between authoring tools/ Succeeded: s/each effect/each graphical element/ Succeeded: s/How do we treat conflicts with other specs? As last call items?/what about the issue with SVG pointer-events on the svg root, esp. used in HTML/ FAILED: s/dissapear/dissapear from the autogenerated disposition of comments/ Succeeded: s/It sounds like ChrisL has done due diigence on establihed precedents/It sounds like ChrisL has done due diligence on established precedents/ Succeeded: s/Cryil/Cyril/ Succeeded: s/If/DS: If/ Succeeded: s/No/It can refuse to handle the event and pass it back to the system, so the containing application will handle it/ Succeeded: s/apply to it/apply to the element it's specified on/ Succeeded: s/elemnt/element/ Found Scribe: Cyril Found ScribeNick: Cyril_Concolato Found ScribeNick: tbah Found Scribe: Anthony Inferring ScribeNick: anthony Found ScribeNick: anthony Scribes: Cyril, Anthony ScribeNicks: Cyril_Concolato, tbah, anthony WARNING: No "Present: ... " found! Possibly Present: AG All CC CL ChrisL Cyril Cyril_Concolato DS Doug TB anthony ed erik f1lt3r joined scribenick shepazu svg tav tbah trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 03 Sep 2010 Guessing minutes URL: http://www.w3.org/2010/09/03-svg-minutes.html People with action items: anthony chris cyril doug erik tav tavmjong[End of scribe.perl diagnostic output]