See also: IRC log
<trackbot> Date: 20 May 2009
<scribe> Scribe: anthony
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
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?
<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?
<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?
<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?
<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?
<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].
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/implementors/implementers/ Succeeded: s/media/dur="media"/ Succeeded: s/element/element?/ Succeeded: s/img/object/ Succeeded: s/decide which/let the user decide which/ Succeeded: s/:href// Found Scribe: anthony Inferring ScribeNick: anthony Default Present: Doug_Schepers, ed, anthony, jwatt, ChrisL Present: Doug_Schepers ed anthony jwatt ChrisL Regrets: Cameron Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0144.html Found Date: 20 May 2009 Guessing minutes URL: http://www.w3.org/2009/05/20-svg-minutes.html People with action items: anthony chris doug erik jonathan[End of scribe.perl diagnostic output]