See also: IRC log
<trackbot> Date: 17 October 2008
trackbot, code?
<trackbot> Sorry, anthony, I don't understand 'trackbot, code?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
trackbot, pass code?
<trackbot> Sorry, anthony, I don't understand 'trackbot, pass code?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<ed_work> heh
NH, you there?
<NH> Sorry I wont be able to join before ~12.30 CET
ahh ok - no worries
http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement
<ed_work> http://dev.w3.org/SVG/profiles/1.2T/publish/script.html#HandlerElement
ISSUE-2055?
<trackbot> ISSUE-2055 -- Define 'evt'/'event' relationship more formally -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2055
<ed_work> http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0160.html
<ed_work> http://www.w3.org/Graphics/SVG/WG/track/actions/2306
<ed_work> time for another telcon round?
<ed_work> trackbot, start telcon
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 17 October 2008
Hey ed_work, is this too wordy for ISSUE-2098?
If a script within the <a href='#ScriptElement'><span class='element-name'>'script'</span></a> element causes
the element to be removed, the script must continue to be execution as normal.
I have come up with shorter wording
<ed_work> Modifying or removing the script content (or element) after the script has started its execution has no effect on the script execution.
<ed_work> isn't there something similar to that already?
<ed_work> perhaps "must have no effect"
ok, looks fine to me
I couldn't see anything in the scripting chapter about this
<ed_work> I have a draft response to cyril on ISSUE-2134 now, but maybe we should go through it before I send it off
sure
other than looking in the scripting chapter is there anywhere else you can think of that I should check?
<ed_work> impl. requirements? intro?
<ed_work> conformance?
check those... nothing
I'll add your wording into the scripting chapter
<ed_work> time for another telcon then
<NH> ok
<scribe> scribe: anthony
<ed_work> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0183.html (sorry, missed to put in the issue/action)
<ed_work> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0182.html
ED: Those issues were done
ISSUE-2134?
<trackbot> ISSUE-2134 -- Ambiguities in the 'use' element -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2134
ED: Wording taken from 1.1 for
the first bit
... I would prefer not to change anything
... wording is simplified
... almost all of the use element is taken from 1.1
... I think the first paragraph is a high level
description
... at least that's how I read it
... I'd prefer to leave it in
AE: I think it make sense keeping
it as it is
... it's not a major issue
ED: Second paragraph of the
issue
... is it's not according to the spec
... I think it's just a miss reading
... the Third paragraph
... is this strange half sentence
... and it was added in response to our last LC
... it's suppose to be joined to the bullet point list
AG: I think we should merge that last bit with the bullet point
<ed_work> "A 'use' element has the same visual effect as if the 'use' element were replaced by the following generated content" + "except for resolution of relative IRI references as noted above and until the referenced elements are modified."
DS: As noted above should be as noted below
ED: The XML resolving base is still above
<ed_work> xml:base resolving
ED: about 4/5 paragraphs above
AE: If could just get rid of the "as noted above"
DS: And say as noted
... I'd suggest edit to remove that sentence above
... make it into one sentence
ED: [Suggests change]
... next thing that is being asked for is clarification of
examples
... and he's asking what's happening with id's and
xml:id's
... I'd prefer to leave the example as is
... I think it would be very confusing showing the cloning of
ids
... because that doesn't really happen anyway
AE: I agree
... it's just a shadow tree anyway
ED: In any case I'd prefer to
leave the examples as they are
... Image use base had some errors
... so I removed those
... the last part is find the process xml is transfered
AE: linking-refs-205
... I'd review it first before putting it into your
response
ISSUE-2094?
<trackbot> ISSUE-2094 -- accessing rules for traitAccess -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2094
ED: Just need to decide on what
to do with traitAccess on animation elements
... currently we throw exceptions if your try to modify traits
on animation elements
... only if they are in the tree already
AE: I think it's significantly
simplified the UA
... but it's not just the ID it's all the attributes of the
animation
... sure the xml:id is just one, but I do believe it simplifies
it
<ed_work> http://lists.w3.org/Archives/Public/www-svg/2008Oct/0055.html
AE: removing it will change what implementations have to do
ED: I would disagree with his last comment
AE: There are many other attributes on the animation element
ED: I got to the bit about
changing the document while it's parsed
... and I'm not sure it's stated anywhere when you evaluate or
re-evaluate an attribute
... I'm pretty sure it says once it's been resolved you can't
change it
DS: I think it does
ED: It's an edge case, and I wouldn't count on it working
DS: What's the minimum thing we can do to resolve this?
ED: Say that it's forbidden for good reasons
AE: His question is why do we have the restrictions
RESOLUTION: We will not change the animation restrictions
RATIONAL: Implementation experience shows that it simplifies implementations even when considering xml:id
<scribe> ACTION: Emmons to Reply to ISSUE-2094 [recorded in http://www.w3.org/2008/10/17-svg-minutes.html#action01]
<trackbot> Created ACTION-2316 - Reply to ISSUE-2094 [on Andrew Emmons - due 2008-10-24].
ISSUE-2089?
<trackbot> ISSUE-2089 -- animateTransform and underlying value -- OPEN
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2089
DS: We could say this behavior is
not defined so don't use it
... it leaves it open to being defined in the future
<shepazu> [[
<shepazu> The 'problem' with the underlying value for
<shepazu> animateTransform is none, if the sentence is
<shepazu> simply skipped. If required, one can replace
<shepazu> it with the sentence, that currently the behaviour
<shepazu> for to-animateTransfrom is explictly unspecified.
<shepazu> Then the reader is informed about the remaining
<shepazu> problem and will not start to write tough
<shepazu> tests as I did.
<shepazu> ]]
<shepazu> [[
<shepazu> [[
<shepazu> Therefore, if critical things are specified to be
<shepazu> 'unspecified', implementors do not have to change
<shepazu> the current behaviour of programs currently and
<shepazu> authors are at least warned, that they must not
<shepazu> rely on anything for these remaining issues.
<shepazu> It cannot be expected, that all problems are
<shepazu> perfectly solved already now, but it is no use to
<shepazu> leave it in an unconsistent state to make sketchy
<shepazu> readers believe, that the work is already done ..
<shepazu> ]]
DS: You can't specify every
behavior
... there are cases where we leave things up to the
implementers
... we're not saying that an implementation can't do it
AG: If we remove the sentence then we have to remove the bullet points I think
http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement
DS: Say instead, this behavior is unspecified in Tiny 1.2 and will be defined in a later specification
ED: If we remove the sentence we should say it's undefined and we will define it later
DS: Before you make the change
and say we will take his advice and say that this behavior is
unspecified
... and say it means removing this entire section and let us
know if that's the case
... and quote the section
http://www.w3.org/TR/SVGMobile12/animate.html#AnimationAttributesAndProperties
ED: It has a note for additive in
that table already
... at least in the working draft that was published
... we already have a not in the table there
... he's suggesting to mention the underlying value in that
sentence
ISSUE-2055?
<trackbot> ISSUE-2055 -- Define 'evt'/'event' relationship more formally -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2055
ED: I did some changes to the spec
<ed_work> http://dev.w3.org/SVG/profiles/1.2T/publish/script.html#HandlerElement
ED: I removed the wording saying
this keyword was bound
... it was an old action on Cameron
... so it's removed now
... and I also added in the aliasing explicitly in the
example
... I think this is closer to what people are doing
... in implementations are doing currently
... not sure if everyone treats it as function either
... I know we don't
AE: You mean the 'this' keyword
ED: Correct
DS: If there is no 'this' key word aren't we moving away from HTML?
ED: HMTL doesn't do events
... we have tests for both arguments and this
... there were not passes
... one thing to not here, is Opera doesn't currently handle it
as a function
... you can't break out of the function
... I'd like to brainstorm how to reword this
... for thus it's like script content block but with the evt
and event available
... but I'm not sure how to describe that accurately
AE: How is the script element described
ED: Probably not very much I'd
guess
... I read the thread there and all the discussion
... and I didn't agree with the more ECMA script
equivalent
... I couldn't get that to work and it wasn't any more
clear
AE: Could we say it's conceptually like a function object
NH: We have it as a function
ED: Which is why I'd like to have it as a smallest subset possible
AE: Maybe say "Conceptually behave as if"
DS: I agree with Andrew
... and we could say in the reply that we realise that this may
not be complete but we will work
... with webaps and HTML to define it better
ED: Another change we could make
is we don't require access to the arguments property
... and in a later spec say we do require it
NH: Will this give us better conformance to the test suite?
DS: Problem is this is a real
problem with SVG, it's incompatible with other specs
... we need to resolve it in a way that allows better
integration later on
ED: I did make another change
there
... and said that the event object is the event and evt is an
alias
NH: Why take it out this release and put it in the next version?
ED: Because implementations fail
the tests
... I think at this point we should make it easy for
implementations to pass
AE: What ED said there about not
having the args available
... for Tiny
... we should add that wording
ED: Ikivo would still be conform
<ed_work> so, resolution is to change this sentence:
<ed_work> In ECMAScript, the contents of the 'handler' element behave as if they are the contents of a new Function object, created as shown:
<ed_work> to this:
<ed_work> In ECMAScript, the contents of the 'handler' element behave conceptually as if they are the contents of a new Function object, created as shown:
DS: Does that resolve the issue?
ED: The issue itself is asking for a more formal way of defining event and event variables
<ed_work> http://lists.w3.org/Archives/Public/www-svg/2008Sep/0061.html
ED: In the email he says to do
what I've pretty much done there
... so I think he'll be satisfied with this change
... I will fix the conceptually there and respond to the
original commenter
<shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0156.html
ISSUE-2083?
<trackbot> ISSUE-2083 -- Paced animation and complex types -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2083
<shepazu> [[
<shepazu> Current problems with paced animation were
<shepazu> introduced mainly with some funny formulas in
<shepazu> SVGT 1.2, not before.
<shepazu> If SVGT1.2 implementors do not want to change their
<shepazu> current implementations, one can simply
<shepazu> 1) remove the formulas for lists and path-data
<shepazu> 2) note, that the behavior is explictly unspecified
<shepazu> 3) discourage authors from using calcMode paced for
<shepazu> other constructions than scalars and colors currently,
<shepazu> because due to nonsense in SVG1.1 and in
<shepazu> some implementations, the behavior is unpredictable,
<shepazu> which also applies for animateTransform, if backwards
<shepazu> compatibility is important.
<shepazu> 4) encourage authors to calculate keyTimes for
<shepazu> calcMode linear for the critical unspecified cases,
<shepazu> to get a predictable behavior, because this is
<shepazu> always possible to get the behavior that they would expect that 'paced'
<shepazu> might mean in their specific case.
<shepazu> This has the big advantage, that readers are warned
<shepazu> and do not start to use the wrong formulas or even
<shepazu> worse to waste their time to understand, how they
<shepazu> are related to calcMode paced, as I did.
<shepazu> ]]
AE: Removing the formulas for
list and path data
... is subtle way of fixing some of the issues
DS: This is very sensible
... we should at least warn authors
<scribe> ACTION: Anthony to make changes as suggested by DOH [recorded in http://www.w3.org/2008/10/17-svg-minutes.html#action02]
<trackbot> Created ACTION-2317 - Make changes as suggested by DOH [on Anthony Grasso - due 2008-10-24].
<shepazu> http://www.w3.org/Graphics/SVG/WG/track/issues/2084
DS: I have an action on it
... I have some more input on it
... Dr Hoffmann didn't like the extended syntax thing
... When he says extended syntax I think he's talking about the
trailing semicolon
<shepazu> http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#ValueAttributes
<shepazu> [[
<shepazu> For compatibility with existing content, SVG extends the syntax of this attribute to allow a trailing semicolon (with optional surrounding whitespace) without creating a new value in the list. Thus, for example, "10; 20; 30;" has the same meaning as "10; 20; 30" and specifies a list of three values. Note that a zero-length string is a valid value for IRIs, which means that to use such a value as the final value in a 'values' attribute an addition semicolon i
<shepazu> ]]
<shepazu> [[
<shepazu> For compatibility with existing content, SVG extends the syntax of this attribute to allow a trailing semicolon (with optional surrounding whitespace) without creating a new value in the list. Thus, for example, "10; 20; 30;" has the same meaning as "10; 20; 30" and specifies a list of three values. Note that a zero-length string is a valid value for IRIs, which means that to use such a value as the final value in a 'values' attribute an addition semicolon i
DS: What if we replaced with something like
<ed_work> trackbot, close ACTION-2303
<trackbot> ACTION-2303 Take over the scope-chain removal action from heycam and address ISSUE-2055 closed
<shepazu> "For compatibility with existing content, a user agent may allow a trailing semicolon... . In later specifications, this behavior may be more strictly defined, so authors and content generation tools are discouraged from using trailing semicolons."
DS: Instead of mandating that
this is the case we'll say the above
... but we might change this later on
RESOLUTION: We will change the trailing semicolon syntax to allow but not mandate the trailing semicolon and discourage its use
<shepazu> ACTION: shepazu to change the trailing semicolon syntax to allow but not mandate the trailing semicolon and discourage its use, per ISSUE-2084 [recorded in http://www.w3.org/2008/10/17-svg-minutes.html#action03]
<trackbot> Created ACTION-2318 - Change the trailing semicolon syntax to allow but not mandate the trailing semicolon and discourage its use, per ISSUE-2084 [on Doug Schepers - due 2008-10-24].
<shepazu> ISSUE-2093?
<trackbot> ISSUE-2093 -- 16.2.9 by 'identity' -- OPEN
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2093
DS: I can follow up with him on this
ED: Seems like an easy change
<shepazu> [[
<shepazu> The 'problem' with the by animation is none for
<shepazu> the future, because this is already clarified in
<shepazu> SMIL3, therefore any comments about this can
<shepazu> be completely skipped in SVG, especially because
<shepazu> in SMIL 2 and 3 it is precisely described, that and how
<shepazu> from-to, from-by and by animations are equivalent
<shepazu> to the related values animations.
<shepazu> ]]
<scribe> ACTION: Doug to Follow up on ISSUE-2093 [recorded in http://www.w3.org/2008/10/17-svg-minutes.html#action04]
<trackbot> Created ACTION-2319 - Follow up on ISSUE-2093 [on Doug Schepers - due 2008-10-24].
<shepazu> http://www.w3.org/Graphics/SVG/WG/track/products/11
ISSUE-2130?
<trackbot> ISSUE-2130 -- Basic Data Types section needs clarifications -- OPEN
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2130
<shepazu> ISSUE-2134?
<trackbot> ISSUE-2134 -- Ambiguities in the 'use' element -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2134
<shepazu> ISSUE-2137?
<trackbot> ISSUE-2137 -- Add clarification about begin time for canvas negotiation -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2137
ED: I don't think it happens on
parse time
... but I could be wrong
DS: So it would happen on rendering?
ED: Before rendering
DS: Why don't we say that Tiny doesn't specify this but we will clarify this in later specification
ED: Sure
RESOLUTION: The negotiation time is implementation specific
<shepazu> ACTION: shepazu to reply to ISSUE-2137 saying this is implementation-specific [recorded in http://www.w3.org/2008/10/17-svg-minutes.html#action05]
<trackbot> Created ACTION-2320 - Reply to ISSUE-2137 saying this is implementation-specific [on Doug Schepers - due 2008-10-24].
ISSUE-2139?
<trackbot> ISSUE-2139 -- Add note regarding eRR attribute and prefetch element -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2139
DS: Was discussed to days ago
<shepazu> ISSUE-2140?
<trackbot> ISSUE-2140 -- Ambiguities in mediaSize -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2140
AG: I had a quick look at this
DS: I think what we mean is with regards to file size of the media
AG: Change required?
<shepazu> Clarify this means that ""Defines how much of the media to fetch in bytes with regards to the file size of the media."
<scribe> ACTION: Doug to Clarify the meaning function in ISSUE-2140 [recorded in http://www.w3.org/2008/10/17-svg-minutes.html#action06]
<trackbot> Created ACTION-2321 - Clarify the meaning function in ISSUE-2140 [on Doug Schepers - due 2008-10-24].
<shepazu> ISSUE-2145?
<trackbot> ISSUE-2145 -- Clarify media timeline and document timeline -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2145
<shepazu> ISSUE-2147?
<trackbot> ISSUE-2147 -- Section on externally referenced documents confusing -- OPEN
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2147
<shepazu> ISSUE-2149?
<trackbot> ISSUE-2149 -- Paced interpolation of polygons -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2149
<shepazu> ISSUE-2150?
<trackbot> ISSUE-2150 -- Clarify 'required' attribute -- OPEN
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2150
<scribe> ACTION: Doug to Respond to ISSUE-2149 [recorded in http://www.w3.org/2008/10/17-svg-minutes.html#action07]
<trackbot> Created ACTION-2322 - Respond to ISSUE-2149 [on Doug Schepers - due 2008-10-24].
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/evt/evt and event/ Succeeded: s/whoever raised the issue initially/the original commenter/ Succeeded: s/... doing number 1 suggestion is the best way to go// Succeeded: s/onit/on it/ Found Scribe: anthony Inferring ScribeNick: anthony Default Present: ed_work, NH, Doug_Schepers, [IPcaller], anthony, aemmons Present: ed_work NH Doug_Schepers [IPcaller] anthony aemmons Found Date: 17 Oct 2008 Guessing minutes URL: http://www.w3.org/2008/10/17-svg-minutes.html People with action items: anthony doug emmons shepazu[End of scribe.perl diagnostic output]