See also: IRC log
<trackbot> Date: 14 July 2011
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
ED: spec requesting feedback from us
<ed> http://lists.w3.org/Archives/Public/www-svg/2011Jul/0034.html
ED: it's about different
interfaces for getting information about media resources
... a javascript api
VH: are there implementations of the api?
ED: good question, it's a last call working draft
VH: second last call
ED: is there interest in reviewing the spec?
VH: I think at least someone
should take a look and report back to us
... a while back we were trying to get progress events in svg2,
so it sounds related
... or is it for metadata?
ED: it seems to be more fore metadata
VH: not for the loading process?
ED: doesn't look like it, but I haven't done a length review of the document
CM: I'd be curious to see what the HTMLWG thinks of it, given they are probably mainly thinking of HTML video
<vhardy> http://www.w3.org/2008/WebVideo/Annotations/#Implementa
ED: end of the review period is 7 August
VH: shall we put it on the F2F
agenda and see if anyone's had a chance to look at it before
then?
... I've put it on the agenda
<scribe> ACTION: Erik to mail the group list asking for review of the mediaont-api spec [recorded in http://www.w3.org/2011/07/14-svg-minutes.html#action01]
<trackbot> Created ACTION-3064 - Mail the group list asking for review of the mediaont-api spec [on Erik Dahlström - due 2011-07-21].
<ed> http://lists.w3.org/Archives/Public/www-svg/2011Jul/0004.html
VH: someone pointed out the
differences between SVG Tiny 1.2 and 1.1
... I think the argument I made was that <title> was
informative, and the fact that you could display titles as a
tooltip was just a way of dealing with it
... so having tooltip-specific behaviour on <title>
didn't seem right
... Olaf pointed out that 1.2T talked more about tooltips
DS: I think we need to have some
standardised behaviour around tooltips
... I don't care if it's <title> or not
... are you saying that we shouldn't have tooltips around
<title>?
VH: we shouldn't assume that titles were exclusively for tooltips
DS: sure, I agree with that
ED: the 1.2T spec suggests to use role="tooltip" for title elements that are supposed to be tooltips
<ed> http://www.w3.org/TR/SVGTiny12/struct.html#uiTitleDescBehavior
DS: it's a feature people expect
"The title attribute represents advisory information for the element, such as would be appropriate for a tooltip."
(that's in the HTML spec)
DS: it seems the best would be to use a SHOULD to display it as a tooltip
CM: I think for the issue that was brought up, it should just do the same thing as in HTML if you have a descendent element with title="" (empty string) on it
ISSUE: Resolve the <title> tooltip issue for SVG2
<trackbot> Created ISSUE-2414 - Resolve the <title> tooltip issue for SVG2 ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2414/edit .
DS: I came up with an algorithm
for determining the title of an element: every element has a
title. the title text comes from its immediate child
<title>, or its closest ancestor's.
... I think that's the only consistent one I can see being
applied
... we could ask the public list to review the text from
1.1/1.2T, get use cases and requirements from accessibility and
other people
<scribe> ACTION: Doug to ask the public list and a11y people about title/tooltips [recorded in http://www.w3.org/2011/07/14-svg-minutes.html#action02]
<trackbot> Created ACTION-3065 - Ask the public list and a11y people about title/tooltips [on Doug Schepers - due 2011-07-21].
ISSUE: Specify what an empty <title> element means in SVG2
<trackbot> Created ISSUE-2415 - Specify what an empty <title> element means in SVG2 ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2415/edit .
<scribe> ACTION: Doug to make a proposal for ISSUE-2415, empty <title> element [recorded in http://www.w3.org/2011/07/14-svg-minutes.html#action03]
<trackbot> Created ACTION-3066 - Make a proposal for ISSUE-2415, empty <title> element [on Doug Schepers - due 2011-07-21].
<scribe> ACTION: Doug to reply to Klaus on www-svg about empty <title> [recorded in http://www.w3.org/2011/07/14-svg-minutes.html#action04]
<trackbot> Created ACTION-3067 - Reply to Klaus on www-svg about empty <title> [on Doug Schepers - due 2011-07-21].
ED: do we need to do anything there?
DS: Chris or I need to write up a
Director's decision based on the feedback
... did you guys see the feedback from Innovimax?
ED: yes
DS: have we resolved what to do about that?
CM: I don't think we've discussed it
http://www.w3.org/2002/09/wbs/33280/svg11-2011/results
ED: there's no RNG for 1.1, but there's nothing stopping us publishing one later if we want
CM: I agree, there may be that experimental RNG on www.w3.org, but we weren't intending to publish 1.1F2 with one
DS: yes, if we do publish one
going forward we don't need it to be linked from the spec
... plh agreed with me that these kinds of comments were made
too late; they should have been made in PR or LC
... we should say that the rng on www.w3.org/Graphics/SVG/ is
out of date, and it would be better to wait for murata-san's
updated rng
ED: he also comments about
references
... we have discussed this previously and rejected them
DS: I know that in the past certain things had changed from CSS 2.0 to 2.1, so we didn't think it was appropriate to change the reference
<ed> http://lists.w3.org/Archives/Public/www-svg/2011Feb/0034.html
DS: now that 2.1 is a REC, there's nothing stopping us maturity-wise
<ed> http://www.w3.org/TR/SVG11/refs.html
ED: we do already link to CSS 2.1 from the references section
DS: he lists two or three references, what are those?
ED: SMIL 3.0, I think it's not so
easy to reference that
... MathML 3.0, he wants an informative reference
DS: SVG 1.1 Second Edition only
made certain changes, and it wasn't evaluated entirely in terms
of references
... we couldn't confidently change some of these references
ED: we could do the MathML one, it's informative
DS: yeah, so changing that one to MathML 3.0 would be OK
CM: so we reference both SMIL Animation (normative) and SMIL 3.0 (informative). what do we reference SMIL 3.0 for?
ED: just an informative note, I think
DS: I'll leave it to you Cameron to update any references you think are safe, and keep me updated
<scribe> ACTION: Cameron to investigate reference updates per Innovimax's comment [recorded in http://www.w3.org/2011/07/14-svg-minutes.html#action05]
<trackbot> Created ACTION-3068 - Investigate reference updates per Innovimax's comment [on Cameron McCormack - due 2011-07-21].
ED: I made some tweaks to the
test suite, reference image updates
... but I think it's in a good state for publication
CM: did you look any further into how to publish the test suite?
ED: no, and I'd like to verify that the test suite package is generated correctly
<scribe> ACTION: Erik to look into the testsuite package generation/publication [recorded in http://www.w3.org/2011/07/14-svg-minutes.html#action06]
<trackbot> Created ACTION-3069 - Look into the testsuite package generation/publication [on Erik Dahlström - due 2011-07-21].
CM: what is the timing of being able to publish?
DS: I think we should be able to publish next Thursday
DS: I never sent off my email
about that
... I intend on responding to Andreas and others to tell them
what our plan is
... it was interesting that Andreas pointed out another
implementation out there, some GIS thing
... I'm scheduled to meet with an expert on URIs/HTTPs etc. to
talk about the syntax
... one of the problems with Params was that we never settled
on a URL syntax, you can't use a question mark since that would
mean resources aren't cached
... so I'll talk to him about better syntax for that
... there might be conflict between our syntax and the media
fragments
... (Yves Lafon)
... I'm going to try to have an updated ED for the F2F
... so is this meant to be an SVG2 feature? or a separate
module? I don't really care one way or the other.
CM: not sure
DS: we could leave it as a
separate spec for now and consider folding it into SVG2
later
... that way people can implement it now
ED: it's being proposed that for
textPath method="stretch" you warp the glyphs, Israel used the
term "offset mapping"
... so making the glyphs rubbery and stretch them along the
path
... it's not exactly what opera does at the moment; we don't
stretch it out fully like that
VH: but opera does some stretching?
ED: yes
(opera doesn't do an exact scaling of the glyphs, it stretches it into a trapezoid or something)
<ed> http://www.w3.org/TR/SVG11/text.html#TextPathElementMethodAttribute
VH: so he wants silverlight-like effects?
ED: not quite
... he made a couple of different examples
... they're pretty compelling
<ed> http://owl3d.com/svg/tests/boundText/circle_text_ar6.svg
ED: Opera wouldn't behave like
this
... if you take the "Z" character, it wouldn't be following the
inner circle
... it would be positioned on the mid line of the glyph, a
straight baseline
... and the top line of the character wouldn't follow the
circle either
TB: I was playing with some
ligatures with that, it looks a bit ugly
... if you don't follow the curve
... if you have the "ffi", if all three parts of that are on a
straight line, it doesn't look good
VH: is he proposing a solution that explains exactly the processing to do this?
ED: I think sort of, but it's not
100% clear in all parts
... there are some aspects of this proposal that aren't clear,
like how rotate="" would affect this
... I pointed out a few things, where e.g. if you have a very
sharp corner, the behaviour in such cases is not fully defined
either
<ed> http://owl3d.com/svg/tests/boundText/corner_linejoin_round.svg
ED: ^ there is an example of a sharp corner
DS: if we are going to change text path, maybe we might have an attribute that changes modes of how textPath behaves
<ed> http://owl3d.com/svg/tests/boundText/2curves.svg
DS: we have the current backwards compat mode, and we could opt in to this new functionality
ED: also being able to specify
two curves to stretch between
... that's similar to the silverlight one I think
... so it's following the curve and not using straight lines
for the top/bottom of the glyphs
CM: it's a short distance between this and doing it for general shapes
DS: we did talk about a "shapePath", where it treats individual shapes as glyphs
VH: these documents are pregenerated, do we know how he generates it?
<ed> http://owl3d.com/svg/tests/boundText/corner_in_out.svg (that's the non-bendy B)
CM: if he could furnish us with some algorithms that would be a good way forward
VH: is he a Member?
CM: no, a public
VH: I would be concerned if he shared them and wasn't a member
DS: we do allow non-members to give IPR commitments
TB: it should be pretty easy to duplicate
<scribe> ACTION: Tav to experiment with glyph warping text path stuff [recorded in http://www.w3.org/2011/07/14-svg-minutes.html#action07]
<trackbot> Created ACTION-3070 - Experiment with glyph warping text path stuff [on Tavmjong Bah - due 2011-07-21].
TB: I think Inkscape already has something like this for a general path
VH: is it just done with manipulating control points, or does it need to subdivide curves?
TB: just control points
... we have some extensions
<vhardy> http://owl3d.com/svg/tests/boundText/circle_text_B.svg
<vhardy> http://owl3d.com/svg/tests/boundText/2curves_B.svg
<tbah> http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffects-EnvelopeDeformation.html
(discussion about inkscape live path effects)
VH: did Israel have a concretre proposal, or was it more about functionality?
ED: more functionality
... not sure if he wanted something like live path effects, or
just wanting the simple things to work
CM: how might we move forward with this, aside from saying "that's cool"?
VH: for anything like this to go
into the spec, we need a real proposal
... either we do that or we ask him to do it
ED: it would nice to be able to
apply this to any shape
... not just text, textPath
... so it'd be nice if we had something like live path effects
in SVG
VH: should we have something like a rubber band effect? fairly generic, something that would apply to text or shapes
ED: I think one of the use cases mentioned there was railroad tracks, labels on streets, etc.
CM: what I want to know is how
difficult it is to specify and compute
... it's clearly a high value effect, so if we can do it
without too much difficulty, I think we should
VH: we respond saying we could put it in the SVG2 requirements document, ask him to join the group help specify it
ED: yes, if he has algorithms
spec text to contribute
... writing up use cases for the path effects would be nice to
have on the wiki
VH: we have a page for the requirements document, for 2.0?
CM: I think we never came to a
decision on scope for 2.0
... there was a discussion on the list
... a month or two back
DS: I'd said to wait for the
Community group process to be up and running
... and use that to help scope the 2.0 work
... the infrastructure won't be there, though
... are we going to get people to mail to the list? it's work
to collect that.
VH: traditionally you would have
a requirements document, an editor for that document
... we could do it on the wiki
... and then multiple people could collect things from the list
to the wiki
CM: I think we need a page like that for ourselves, at least, whether or not we use it for collecting requirements from the public
VH: we can start a wiki page,
that's a zero cost thing, make this the first entry
... during the meeting we could have someone put things on the
page as we decide on certain features going in there
DS: but that's only stuff that we talk about, not from the public
VH: we could do it like today. we discuss things that come up on the list, and during the meeting we talk about adding it to the req document.
DS: we could split it into high priority items, medium, low, suggested
<vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/form/from/ Found Scribe: Cameron Found ScribeNick: heycam Present: erik vincent cameron doug tav Regrets: chris Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011JulSep/0018.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 14 Jul 2011 Guessing minutes URL: http://www.w3.org/2011/07/14-svg-minutes.html People with action items: cameron doug erik tav[End of scribe.perl diagnostic output]
