SVG Working Group Teleconference -- 20 May 2009

<trackbot> Date: 20 May 2009

<scribe> Scribe: anthony

ISSUE-2271 - Add mechanism for variable stroke width (as in calligraphy)

ISSUE-2271?

<trackbot> ISSUE-2271 -- Add mechanism for variable stroke width (as in calligraphy) -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2271

ED: For us to consider way of doing variable stroke widths
... this is feature that's been requested a couple of times

DS: I pointed to the threads there
... I pointed to my very early proposal
... not sure exactly how we should do it
... may or may not be able to do it with Vector Effects
... it's not hard to do this, it's just had to figure out the right way to specify these things

ED: There is a mention here of one of the inkscape implementers
... have you spoken to him?

DS: No, but he's very supportive of having this
... most Inkscape implementers like the idea
... they've implemented something
... but they just do it as a path
... We should do a little more research into how we could do it

ED: Two things to do
... talk to the Inkscape guys
... and gather use case and requirements on the wiki

<scribe> ACTION: Doug to Contact the Inkscape guys regarding variable stroke width (ideas, requirements) [recorded in http://www.w3.org/2009/05/20-svg-minutes.html#action01]

<trackbot> Created ACTION-2563 - Contact the Inkscape guys regarding variable stroke width (ideas, requirements) [on Doug Schepers - due 2009-05-27].

<heycam> shepazu, when you've uploaded the errata document and test cases could you ping me, and then i'll mail out the notification to www-svg mentioning the changes, thanks.

ISSUE-2015 - Should the svg element provide a duration element?

ISSUE-2015

ISSUE-2015?

<trackbot> ISSUE-2015 -- Should the svg element provide a duration element? -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2015

ED: This is about specifying intrinsic animation have an animation and want to use it in another file
... and you want to specify the duration
... we don't have a way to specify the duration at the moment

AG: Has Opera done anything like this?

ED: I think it would be easy to add a 'dur' attribute to the SVG root element
... I'd be in favour of this
... the question is where would this go
... in the structure chapter perhaps
... we don't have this as a module though
... we could add this to the main module
... or we could split the structure chapter into a module
... or a third option is specify this in a small file
... and stick it somewhere
... it would be useful to have something like this because it would animations much easier to reuse

AG: I agree with putting it on the root element

CL: This is so when an SVG is reference by another SVG element you say what the duration is?

ED: Yes

CL: Why can't you say that in the SVG itself
... on the animation element

ED: You can specify the duration as a dur="media" on the animation element
... it's a good way of saying in the file how long your animation runs for

AG: What about if the intrinsic duration was shorter than an animation in the file?

ED: I guess the intrinsic duration is good for repeats
... may cut off the animation

AG: I don't really have an opinion on it

ED: I could email Julien to see what he thinks and what behaviour he'd expect
... I can also try this out in Opera

<scribe> ACTION: Erik to Email Julien regarding intrinsic animation idea and what behaviour he'd expect [recorded in http://www.w3.org/2009/05/20-svg-minutes.html#action02]

<trackbot> Created ACTION-2564 - Email Julien regarding intrinsic animation idea and what behaviour he'd expect [on Erik Dahlström - due 2009-05-27].

ISSUE-2022 - The activation behaviour of <a> elements should be defined

ISSUE-2022?

<trackbot> ISSUE-2022 -- The activation behaviour of <a> elements should be defined -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2022

ED: I had a look at the Tiny 1.2 spec
... it doesn't say that much
... doesn't have the text wording
... discussed in this issue
... we discussed it but I can't remember why it wasn't included in Tiny 1.2
... It looks like good wording to have

<chrisl> suggested text looks good to me.

CL: Text looks good to me

<chrisl> clarifies, does not change conformance

ED: Would this be ok to add as an errata

<scribe> ACTION: Anthony to Add the wording discussed in ISSUE-2022 to the Tiny 1.2 errata [recorded in http://www.w3.org/2009/05/20-svg-minutes.html#action03]

<trackbot> Created ACTION-2565 - Add the wording discussed in ISSUE-2022 to the Tiny 1.2 errata [on Anthony Grasso - due 2009-05-27].

AG: Category 3?

CL: Yes I think so

ISSUE-2024 - Elements for which "defer" can be used in preserveAspectRatio=""

ISSUE-2024?

<trackbot> ISSUE-2024 -- Elements for which "defer" can be used in preserveAspectRatio="" -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2024

ED: Can have defer inside of a preserveAspectRatio attribute

JW: You can't reference an SVG from the image element?

ED: In Tiny 1.2 you can't
... in Full 1.1 you can
... this is basically 1.2 Tiny errata?
... personally I think it's good to reference SVG images in the image element
... and they be static images
... similar to the img tag in HTML behaves

JW: As similar as possible

CL: SVG Full 1.1 was a bit ambiguous about that
... and didn't really say what happened
... we really need to clarify that as well

ED: This basically splits into two actions
... one for fixing Tiny 1.2
... and one for clarifying 2.0 Full

AG: Should it be an Issue on 2.0 and an action on Tiny 1.2?

<ed> http://www.w3.org/TR/SVGMobile12/coords.html#PreserveAspectRatioAttribute

ED: I think that would be a small fix up
... and I don't think it would effect conformance

CL: So you're saying that it already says you can't reference images?
... which spec?

ED: In the linking chapter

<ed> http://www.w3.org/TR/SVGMobile12/linking.html#ReferenceRestrictions

ED: In the table here
... the Image element is listed here
... won't get any visible results

<ed> a reference to an SVG document in <image> would be an invalid IRI reference, and would mean the element doesn't render

ED: This would be category 2 then

<scribe> ACTION: Anthony to Add an errata item for Tiny 1.2 to remove the mention of "defer" in the image text [recorded in http://www.w3.org/2009/05/20-svg-minutes.html#action04]

<trackbot> Created ACTION-2566 - Add an errata item for Tiny 1.2 to remove the mention of "defer" in the image text [on Anthony Grasso - due 2009-05-27].

<ed> to remove 'image' in the defer wording really, but ok :)

ISSUE-2040 (Related to ISSUE-2045) - Consider adding placeholders or fallback for unresolved resources

ISSUE-2040?

<trackbot> ISSUE-2040 -- Consider adding placeholders or fallback for unresolved resources -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2040

ED: About having a way to fallback when something is unresolved, like an image

CL: Like a broken image icon?

ED: In Tiny 1.2 when the link is broken you get an invalid IRI reference
... and nothing is rendered
... so you don't know it's missing

JW: Could this be done with a CSS property
... it seems like that it's something common with specs

ED: What type of CSS property where you thinking of?

JW: Something new
... dunno what it would be called

CL: The initial value would be the current behaviour
... then do you point to a certain image?
... or a browser broken image picture?
... we should avoid binary values
... what about point to something else in the same file
... where you say draw this if the image doesn't load

JW: I was thinking about the HTML object tag

CL: the object element allows you to have a child that displays the fallback content
... then in SMIL and SVG tend to do that with a switch
... not clear on what the condition would be
... another possibly would to evaluate whether the thing loaded

DS: At one point we had wording in SVG Tiny 1.2
... that talked about what to do for fallback behaviour of raster images
... we took it out

<chrisl> in general we seem to use switch here, so a test attribute looks like good solution

DS: and I can't remember why

JW: That's an interesting suggestion Chris

CL: So this is something that evaluates to True if the IRI reference is resolved
... then obviously you could draw anything you wanted to
... text, image

JW: Like in the object tag
... you can have nested objects
... until you find something that works
... I think it would be a good idea to have a cross spec solution

CL: HTML has multiple ways of doing it
... I think currently if you put child content of an image it wouldn't be used as a fallback

JW: I think that if you put this property in and it's consistent then it's something
... that could be deployed across documents
... I guess I need to come up with a more concrete suggestion

ED: Two problems that we want to solve
... what to rendered if the content didn't specify and fallback and the link is broken
... and if you want some particular fallback behaviour how do you specify that
... the first one is a bit more easy to solve

CL: We already have some of the options here
... At one point opera gives you a checkerboard if an image was broken

ED: We used to

CL: We got one of the options which is don't display anything
... the other two options there is no way to indicate what you want

ED: There is external resources required
... which gives you an indication that something is broken

CL: If we did have that for the switch case
... on the branch of the switch that has an image, you could put on there something says fail silently
... the reason I like the switch idea, is we already do that sort of thing
... we just need a test attribute to say if the link loaded or not

JW: There scenarios?

CL: A.svg points to an image
... only display it if it's completely correct
... option B is you fail silently
... option C is you fail with a visible indication
... don't have a way to specify B or C currently
... I suppose option D is the author provides a fallback and say explicitly what's to happen

<jwatt> so I guess I was thinking of a CSS property something like this: on-failure-display: nothing | children | error-pattern

CL: Error-pattern, would that be a link?

<chrisl> ok so error-pattern means the default browser indication

<jwatt> so I guess rather than error-pattern, you could want two things

<jwatt> an error pattern specified by the spec and supplied by the UA

<jwatt> or a link to another piece of markup in the doc, sort of like a <use>

<jwatt> to provide your own pattern

ED: Might be a way of solving it
... Suggest that the default value works based on what element it is on
... that's slightly different from Chris's idea of switching

JW: It's not impossible to have two and let the user decide which one is better
... going to other groups and figure out their requirements and get feedback

CL: Would you be prepared to write up an email to CSS and HTML with the proposal?
... I think it would be just the CSS group that would have feedback

<chrisl> trackbot, status

<scribe> ACTION: Jonathan to Write up an email proposing the JWatt idea for fallback behaviour [recorded in http://www.w3.org/2009/05/20-svg-minutes.html#action05]

<trackbot> Created ACTION-2567 - Write up an email proposing the JWatt idea for fallback behaviour [on Jonathan Watt - due 2009-05-27].

<scribe> ACTION: Chris to Write up an email proposing the Chris idea for fallback behaviour [recorded in http://www.w3.org/2009/05/20-svg-minutes.html#action06]

<trackbot> Created ACTION-2568 - Write up an email proposing the Chris idea for fallback behaviour [on Chris Lilley - due 2009-05-27].

ED: In the agenda I mention this issues is related to ISSUE-2045
... I'm not completely sure that this is exactly the same ore not
... but we have two that are very similar
... that issue has a note on it
... that comes from Bugzilla

ISSUE-2045?

<trackbot> ISSUE-2045 -- Consider adding fallback behavior -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2045

ED: I'm just wondering if the issues are different in someway or if we can close one of them

AG: They look the same
... could close 2045 and add a note to 2040

ED: Ok, I'll do that

ISSUE-2054 - Consider removing the requirement for @width and @height for <foreignObject>

ISSUE-2054?

<trackbot> ISSUE-2054 -- Consider removing the requirement for @width and @height for <foreignObject> -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2054

CL: If you don't have width and height how do you figure out
... where to put it
... and how big it should be

ED: The thing I was thinking of was use the width and height CSS properties
... allow them to define the size
... this mentions particularly MathML
... if you don't know what the size of the thing you embedded
... like the size of the MathML

CL: Normally when we draw something you say what size it is
... what's the motivation for removing it?
... the audio case is different
... but for something that renders you'd want to say how big it is
... for audio the width and height would be 0

ED: The audio wouldn't be heard

CL: I seem to remember we discussed what was part of the render tree
... and if it was visual only

ED: I do think it would be interesting to see if the width height CSS properties could be used
... such as the case where you have the SVG root element inside an XHTML document
... and you have width and height in CSS
... the size is negotiated
... so it probably be possible to do something with the elements that use width and height
... It would go inline with what Doug was suggesting
... which is make the SVG attributes into properties
... I would personally think that it would be interesting to specify width and height in CSS
... for the case where you have a bunch of images
... would there be any problems with trying to specifying something like this

CL: Depends, I'd like to see how it would work
... need to consider the geometrical layout which is crucial for SVG

<scribe> ACTION: Erik to Draft a proposal to have width and height properties [recorded in http://www.w3.org/2009/05/20-svg-minutes.html#action07]

<trackbot> Created ACTION-2569 - Draft a proposal to have width and height properties [on Erik Dahlström - due 2009-05-27].

ISSUE-2042

ISSUE-2042?

<trackbot> ISSUE-2042 -- Consider adding adding non-NS linking syntax -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2042

ED: This us for consider adopting link:href in svg as href
... there has been a thread going on in SVG www
... I think Robin B seemed to be against it

CL: That's odd in his XML paper he was arguing the other way
... maybe he's saying the change is too much now we already got it

ED: That's the impression I got
... it would be a pretty big change
... to have some kind of alias
... it would be kind of messy at least in a transitional phase

CL: We would need to say what happens if you put in both
... xlink:href and href

ED: Some chases where it is problematic
... HTML uses different names
... for the hrefs on different tags

CL: It's not only href
... there is somethings that give a src vs href functionality
... which mean different things

ED: The question is then, is that more confusing
... ore less confusing

CL: xlink always had an attribute that says whether it's replace or embed

ED: xlink:show maybe?

CL: That's the one

ED: And we probably have about zero tests for that?

CL: Right, but it's providing metadata
... it's telling something that knows about xlink but not about SVG what to do
... of course the number things that understand xlink and not SVG is zero
... this has come up before in discussion
... that if you were going to redesign xlink how would you do it
... they'd be remapped to ref and src

ED: There are three values new, replace, embed

CL: Instead of taking a single attribute that takes the URI, you'd have three ones that would take the URI and tell you what to do with it

<ed> (xlink spec says also 'other' and 'none')

CL: there are other things that xlink does as well
... which xlink:rel
... specifies relationships

ED: If we were to replace or make a new name for the hrefs, which would be?

CL: I'd tend to favour replacing href

ED: And that would be overriding or the same?

CL: It depends on our fallback strategy
... depends on if people want to write content that worked in both
... could have a similar situation with xml:id
... one possibility is you can specify href every where xlink:href can be put
... href takes priority

ED: I'd make content with href and have a script
... that fixes it
... for older implementations
... there are some cases where that doesn't work
... I guess we should the whole thread on www-svg
... together
... then propose something, based on what everyone is saying

<scribe> ACTION: Chris to Go through the www-svg list regarding link:href and make a proposal based on the feedback [recorded in http://www.w3.org/2009/05/20-svg-minutes.html#action08]

<trackbot> Created ACTION-2570 - Go through the www-svg list regarding link:href and make a proposal based on the feedback [on Chris Lilley - due 2009-05-27].

- DRAFT -

SVG Working Group Teleconference

20 May 2009

Attendees

Contents