See also: IRC log
<trackbot> Date: 23 September 2008
<aemmons> trackbot, who is here?
<trackbot> Sorry, aemmons, I don't understand 'trackbot, who is here?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<aemmons> tzakim, ??p1 is lmartine
<anthony> Scribe:
<anthony> Scribe: anthony
DS: Summary of issue
... Reason for this is there is a lot of content out there is
bigger than the view port
... which is reasonable
... there is an expectation from users that it should be
panned
... but instead scroll bars appear
... I guess the question for me is what does most content
need?
... panning or scrolling
... FF essentially does it the way Apple wants it to
ED: I sent a reply to this
thread
... I was reading a webkit bug tracker
... seems they have a similar way of solving the problem
... as we
<ed> http://lists.w3.org/Archives/Member/w3c-svg-wg/2008JulSep/0025.html
AE: It's not just something that
user agent dependent?
... they can choose to do whatever they want?
DS: Apparently browser based UAs do it different to the way it's specified
NH: Not sure if this does affect us
LM: For us the panning is
controlled by the application on top of the SVG Engine
... up to the application
... which makes sens in a browser environment
DS: I've only heard from one
person in the public
... and that was David who agrees with me in general
... I haven't heard from anybody who thinks that it would break
their content
... given that there is a work around and given that the
browsers do this already
... let's go ahead and make the change
AE: And this would be an errata
right?
... because there's no overflow in Tiny 1.2?
DS: Yeah it probably would be an errata
AE: Not sure how you would word
it
... if we don't have it in Tiny we don't have to mention
it
... it is up to the higher level application
DS: Hearing no objections
ED: I agree
NH: I agree
RESOLUTION: Make an errata for 1.1 regarding the initial value for the root overflow property will be visible rather than hidden
ED: Visible is the value in CSS
<scribe> ACTION: Doug to Add to the 1.1 Full errata that the initial value for the root overflow property is scroll rather than hidden [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action01]
<trackbot> Created ACTION-2203 - Add to the 1.1 Full errata that the initial value for the root overflow property is scroll rather than hidden [on Doug Schepers - due 2008-09-30].
<aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0326.html
AE: We could try to get through most of these
animate-elem-86-t.svg
<ed> http://dev.w3.org/SVG/profiles/1.2T/test/svg/animate-elem-86-t.svg
ED: So with this test what does
Bitflash do?
... I know Opera behaves as the test case assumes
LM: With the never box it's
checked which is what the test is testing for
... still discussing how the spec should be interpreted
AE: If this is a test that
doesn't contribute to the coverage
... we should probably drop it back to draft
... and move on
AG: I agree with that
ED: I'd like to review the sections there to make sure
<scribe> ACTION: Erik to Review animate-elem-86-t test [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action02]
<trackbot> Created ACTION-2204 - Review animate-elem-86-t test [on Erik Dahlström - due 2008-09-30].
http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-focus-201-t.svg
<ed> http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-205-t.svg (already fixed)
AE: I need some clarification on
this
... I think the test is testing the fact that top level SVG can
have a Nav_next to tell it which element has focused
NH: When the element comes up shouldn't the document have focus?
AE: You guys have UA focus right?
NH: Yes
... we default focus to the document element always
AE: And once you go through your focus ring you go to the text
LM: We were wondering what it means by the focus should be "offered"
DS: That's bad text
... it's a term that's not defined
... I think we got an LC comment last time
... I think we should find a better term
LM: Makes it ambiguous
DS: I think that could use some rewording
NH: What would the new wording be?
AE: And that's related to that particular test is that the problem?
NH: No that's not the problem here
LM: In our case we don't give the document the initial focus
NH: Then you focus backwards?
LM: Yes
AE: I think both interpretations
of the spec are correct
... but it seems like we should tighten the spec
NH: But this test as another
problem
... [Reads test description]
AE: I'd suggest not un-approving
this test
... because it's a key 1.2 T feature
... something we could figure out this week or at the test
fest
<scribe> ACTION: Nicolas to propose new wording and a change in the test interact-focus-201-t.svg regarding initial focus [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action03]
<trackbot> Sorry, couldn't find user - Nicolas
<scribe> ACTION: Niklas to propose new wording and a change in the test interact-focus-201-t.svg regarding initial focus [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action04]
<trackbot> Created ACTION-2205 - Propose new wording and a change in the test interact-focus-201-t.svg regarding initial focus [on Niklas Hagelroth - due 2008-09-30].
AE: So the next one
media-anim-201-t.svg seems to be a similar issue
... can you take a look at that one when you do your
action?
NH: Ok
http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-class-201-t.svg
AE: I think it's a quick
fix
... it's just making it uDOM friendly
<ed> outputEl.firstChild.nodeValue = classVal; should be perhaps outputEl.textContent = classVal?
DS: Making it uDOM friendly is fine with me
<scribe> ACTION: Nkilas to Make struct-class-201-t uDOM friendly [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action05]
<trackbot> Sorry, couldn't find user - Nkilas
<scribe> ACTION: Niklas to Make struct-class-201-t uDOM friendly [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action06]
<trackbot> Created ACTION-2206 - Make struct-class-201-t uDOM friendly [on Niklas Hagelroth - due 2008-09-30].
http://dev.w3.org/SVG/profiles/1.2T/test/svg/media-audio-212-t.svg
NH: This one is a bit
tricky
... do you pass this test?
LM: The spec seems a bit
ambiguous for the display and visibility for audio
attributes
... display property part disagrees with the table of
values
... so it's not clear whether visibility affects audio
<ed> http://www.w3.org/TR/SVGMobile12/intro.html
ED: I haven't had time to look at
this particular test
... in the intro if you have display none then visual and audio
elements shouldn't be rendered
LM: They work in the Bitflash implementation
<ed> definition for "rendering tree"
ED: It is possible it could be made more clear
NH: When you read about the visibility property it says it only applies to visual elements
<ed> http://www.w3.org/TR/SVGMobile12/painting.html#DisplayProperty
DS: This should be clarified in
the spec
... I'm pretty sure I recall us having long discussions about
this
... and getting LC comments on it
... I think we should clarify the spec
... it is true that the word visibility is bad wording
NH: It just it doesn't make much sense to me
AE: What do you do guys do for video?
NH: Assume it's a graphical
element and assume it's muted
... audio should still be heard
ED: I think that the audio should not be heard
<scribe> ACTION: Anthony to review the wording of visibility relating to audio [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action07]
<trackbot> Created ACTION-2207 - Review the wording of visibility relating to audio [on Anthony Grasso - due 2008-09-30].
http://dev.w3.org/SVG/profiles/1.2T/test/svgstruct-frag-02-t.svg
<ed> http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/struct-frag-02-t.svg
ED: The last change to the test is changing the viewBox on the svg root element
<ed> http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/struct-frag-02-t.svg.diff?r1=1.5&r2=1.6&f=h
<scribe> ACTION: Anthony to fix struct-frag-02-t and 03-t such that the viewBox is added back in [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action08]
<trackbot> Created ACTION-2208 - Fix struct-frag-02-t and 03-t such that the viewBox is added back in [on Anthony Grasso - due 2008-09-30].
http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/interact-event-204-t.svg
ED: I agree we shouldn't be using
SVG sub elements here
... we could use animation elements perhaps
... or get rid of the sub case
AE: Remove the subcase for now
<scribe> ACTION: Emmons to remove the subtest from interact-event-204-t [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action09]
<trackbot> Created ACTION-2209 - Remove the subtest from interact-event-204-t [on Andrew Emmons - due 2008-09-30].
<ed> http://www.w3.org/Graphics/SVG/WG/track/products/11
ED: I responded to Dr Olaf
regarding ISSUE-2059
... we can close that
<aemmons> http://www.w3.org/Graphics/SVG/WG/track/issues/2060
trackbot, ISSUE-2060
<trackbot> Sorry, anthony, I don't understand 'trackbot, ISSUE-2060'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
ISSUE-2060
DS: I introduced a few mistakes
in an example
... one I used id instead of xml:id
... since that's allowed I'd like to leave it as is
... he says more examples needed
... and he's right
... if we have time we'll do it
... should we change all the examples in the spec to have
titles
AE: I think time is the issue and we should revamp them for the next spec
AG: I agree
RESOLUTION: We are not going to change the examples but we will revamp then in the next version of the spec
<scribe> ACTION: Doug to Respond to Dr Olaf regarding the LC comment on the specification examples [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action10]
<trackbot> Created ACTION-2210 - Respond to Dr Olaf regarding the LC comment on the specification examples [on Doug Schepers - due 2008-09-30].
<aemmons> http://www.w3.org/Graphics/SVG/WG/track/issues/2061
<aemmons> http://www.w3.org/Graphics/SVG/WG/track/issues/2057
ISSUE-2057
DS: I made the agreed wording but
she did not agree to that
... I think the best resolution would to say that we don't
specify what happens if there is another value
... the content would be non-conforming if it uses another
value
... but user agents that support CSS are allowed to have other
values
... and I propose we put a section in the spec that says for UA
that support CSS we can say that content can be made
... that is non-conforming but UAs are allowed to behave
according to CSS
ED: As long as it's inline with
SVG Full 1.1
... not sure if make any overrides because of CSS
properties
DS: What would mean for a text
element to be a block element?
... would it wrap at that point
ED: The way I see it SVG doesn't even use block element
DS: What if we had display =
block
... are there any objects with the content being non-conforming
but the UA be conforming
<scribe> ACTION: Doug to propose wording regarding ISSUE-2057 [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action11]
<trackbot> Created ACTION-2211 - Propose wording regarding ISSUE-2057 [on Doug Schepers - due 2008-09-30].
<aemmons> http://www.w3.org/Graphics/SVG/WG/track/issues/2058
ISSUE-2058
AE: [explains issue]
DS: Are the circumstances where the there is no control of the initial direction?
LM: I see that that as an
issue
... if the underlaying implementation doesn't allow this to be
specified
ED: This means that content may look different between a Tiny and a Full agent when dealing with BiDi Text
DS: Can we hold off until Thur
<aemmons> http://www.w3.org/Graphics/SVG/WG/track/issues/2061
ISSUE-2061
DS: There are two different timing interfaces
ED: SVG has inherited SMIL DOM
methods
... and HTML5 don't use SMIL
DS: No I mean we have two
different interfaces, one has start and stop
... and the other has pause and unpause
... if you look at the uDOM and you look at where pause
is
... it has its own interface
AE: It's simply because we're
inheriting SMIL
... this is carry over from 1.1
... we've had this for a long time
... this is simply because of the legacy of supporting
SMIL
... the element time control is beyond our control
DS: Couldn't we add methods to that
AE: Too late to do that
<scribe> ACTION: Emmons to Give a reply on ISSUE-2061 explaining why the methods are the way they are [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action12]
<trackbot> Created ACTION-2212 - Give a reply on ISSUE-2061 explaining why the methods are the way they are [on Andrew Emmons - due 2008-09-30].
<aemmons> http://www.w3.org/Graphics/SVG/WG/track/issues/2062
ISSUE-2062
DS: This may take a bit of time
<aemmons> http://www.w3.org/Graphics/SVG/WG/track/issues/2064
ISSUE-2064
DS: One of the attributes I
introduced
... that's meant for metadata
... I'll talk to the RDFA people and find out how to better
specify this
... my definition was stricter then theirs but could do with
more tightening
... he says xlink:href can be animate but the type can not be
animated
... so if I had a video and I changed the source I couldn't
change the type
... e.g. changing OGG file to AVI and not changing the
type
... so the question is why type cannot be animated
ED: I personally don't see a reason why it shouldn't be animated
NH: I agree type should be animated
DS: So if we agree should we say
something along the lines of we should only change the type if
the xlink:href changes
... you don't want to randomly changing the type
ED: Well if you had a UA that animated the type for pre-loading
DS: Are you sure there is no reason to have it not animatable
ED: We should say that the content be re-evaluated if the type is changed
DS: It should be animatable where it makes sense
<ed> that is: probably not the script element since xlink:href isn't animatable there
<scribe> ACTION: Erik to Make the type attribute animatable for types [recorded in http://www.w3.org/2008/09/23-svg-minutes.html#action13]
<trackbot> Created ACTION-2213 - Make the type attribute animatable for types [on Erik Dahlström - due 2008-09-30].
DS: Do you want me to reply after the change?
ED: Yes, that would be good
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/scroll/visible/ Succeeded: s/on the element/on the svg root element/ Succeeded: s/it's got it's/it has its/ Found Scribe: Found Scribe: anthony Inferring ScribeNick: anthony Scribes: , anthony Default Present: Andrew_Emmons, anthony, Doug_Schepers, lmartine, NH, ed Present: Andrew_Emmons anthony Doug_Schepers lmartine NH ed Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0340.html Found Date: 23 Sep 2008 Guessing minutes URL: http://www.w3.org/2008/09/23-svg-minutes.html People with action items: anthony doug emmons erik nicolas niklas nkilas[End of scribe.perl diagnostic output]