- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Tue, 23 Sep 2008 22:09:12 +1000
- To: W3C SVG Public Working Group <public-svg-wg@w3.org>
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
23 Sep 2008
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0340.html
See also: [3]IRC log
[3] http://www.w3.org/2008/09/23-svg-irc
Attendees
Present
Andrew_Emmons, anthony, Doug_Schepers, lmartine, NH, ed
Regrets
Chair
Andrew Emmons
Scribe
, anthony
Contents
* [4]Topics
1. [5]Overflow issue with CSS and SVG specs
2. [6]Test Suite Comments
3. [7]Last Call Comments
* [8]Summary of Action Items
_________________________________________________________
<trackbot> Date: 23 September 2008
<aemmons> trackbot, who is here?
<trackbot> Sorry, aemmons, I don't understand 'trackbot, who is
here?'. Please refer to [9]http://www.w3.org/2005/06/tracker/irc for
help
[9] http://www.w3.org/2005/06/tracker/irc
<aemmons> tzakim, ??p1 is lmartine
<anthony> Scribe:
<anthony> Scribe: anthony
Overflow issue with CSS and SVG specs
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>
[10]http://lists.w3.org/Archives/Member/w3c-svg-wg/2008JulSep/0025.h
tml
[10] 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
[11]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>
[12]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/032
6.html
[12] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0326.html
Test Suite Comments
AE: We could try to get through most of these
animate-elem-86-t.svg
<ed>
[13]http://dev.w3.org/SVG/profiles/1.2T/test/svg/animate-elem-86-t.s
vg
[13] 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
[14]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].
[15]http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-focus-201-
t.svg
[15] http://dev.w3.org/SVG/profiles/1.2T/test/svg/interact-focus-201-t.svg
<ed>
[16]http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-205-t.svg
(already fixed)
[16] http://dev.w3.org/SVG/profiles/1.2T/test/svg/udom-svg-205-t.svg
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
[17]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
[18]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
[19]http://dev.w3.org/SVG/profiles/1.2T/test/svg/struct-class-201-t.
svg
[19] 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
[20]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
[21]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].
[22]http://dev.w3.org/SVG/profiles/1.2T/test/svg/media-audio-212-t.s
vg
[22] 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> [23]http://www.w3.org/TR/SVGMobile12/intro.html
[23] 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>
[24]http://www.w3.org/TR/SVGMobile12/painting.html#DisplayProperty
[24] 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
[25]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].
[26]http://dev.w3.org/SVG/profiles/1.2T/test/svgstruct-frag-02-t.svg
[26] http://dev.w3.org/SVG/profiles/1.2T/test/svgstruct-frag-02-t.svg
<ed>
[27]http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/struct-frag-
02-t.svg
[27] 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>
[28]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
[28]
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
[29]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].
[30]http://dev.w3.org/cvsweb/SVG/profiles/1.2T/test/svg/interact-eve
nt-204-t.svg
[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
[31]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].
Last Call Comments
<ed> [32]http://www.w3.org/Graphics/SVG/WG/track/products/11
[32] http://www.w3.org/Graphics/SVG/WG/track/products/11
ED: I responded to Dr Olaf regarding ISSUE-2059
... we can close that
<aemmons> [33]http://www.w3.org/Graphics/SVG/WG/track/issues/2060
[33] 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
[34]http://www.w3.org/2005/06/tracker/irc for help
[34] http://www.w3.org/2005/06/tracker/irc
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
[35]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> [36]http://www.w3.org/Graphics/SVG/WG/track/issues/2061
[36] http://www.w3.org/Graphics/SVG/WG/track/issues/2061
<aemmons> [37]http://www.w3.org/Graphics/SVG/WG/track/issues/2057
[37] 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
[38]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> [39]http://www.w3.org/Graphics/SVG/WG/track/issues/2058
[39] 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> [40]http://www.w3.org/Graphics/SVG/WG/track/issues/2061
[40] 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
[41]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> [42]http://www.w3.org/Graphics/SVG/WG/track/issues/2062
[42] http://www.w3.org/Graphics/SVG/WG/track/issues/2062
ISSUE-2062
DS: This may take a bit of time
<aemmons> [43]http://www.w3.org/Graphics/SVG/WG/track/issues/2064
[43] 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
[44]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
Summary of Action Items
[NEW] ACTION: Anthony to fix struct-frag-02-t and 03-t such that the
viewBox is added back in [recorded in
[45]http://www.w3.org/2008/09/23-svg-minutes.html#action08]
[NEW] ACTION: Anthony to review the wording of visibility relating
to audio [recorded in
[46]http://www.w3.org/2008/09/23-svg-minutes.html#action07]
[NEW] 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
[47]http://www.w3.org/2008/09/23-svg-minutes.html#action01]
[NEW] ACTION: Doug to propose wording regarding ISSUE-2057 [recorded
in [48]http://www.w3.org/2008/09/23-svg-minutes.html#action11]
[NEW] ACTION: Doug to Respond to Dr Olaf regarding the LC comment on
the specification examples [recorded in
[49]http://www.w3.org/2008/09/23-svg-minutes.html#action10]
[NEW] ACTION: Emmons to Give a reply on ISSUE-2061 explaining why
the methods are the way they are [recorded in
[50]http://www.w3.org/2008/09/23-svg-minutes.html#action12]
[NEW] ACTION: Emmons to remove the subtest from interact-event-204-t
[recorded in
[51]http://www.w3.org/2008/09/23-svg-minutes.html#action09]
[NEW] ACTION: Erik to Make the type attribute animatable for types
[recorded in
[52]http://www.w3.org/2008/09/23-svg-minutes.html#action13]
[NEW] ACTION: Erik to Review animate-elem-86-t test [recorded in
[53]http://www.w3.org/2008/09/23-svg-minutes.html#action02]
[NEW] ACTION: Nicolas to propose new wording and a change in the
test interact-focus-201-t.svg regarding initial focus [recorded in
[54]http://www.w3.org/2008/09/23-svg-minutes.html#action03]
[NEW] ACTION: Niklas to Make struct-class-201-t uDOM friendly
[recorded in
[55]http://www.w3.org/2008/09/23-svg-minutes.html#action06]
[NEW] ACTION: Niklas to propose new wording and a change in the test
interact-focus-201-t.svg regarding initial focus [recorded in
[56]http://www.w3.org/2008/09/23-svg-minutes.html#action04]
[NEW] ACTION: Nkilas to Make struct-class-201-t uDOM friendly
[recorded in
[57]http://www.w3.org/2008/09/23-svg-minutes.html#action05]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [58]scribe.perl version 1.133
([59]CVS log)
$Date: 2008/09/23 12:05:40 $
_________________________________________________________
[58] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[59] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51
Check for newer version at [60]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[60] 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, e
d
Present: Andrew_Emmons anthony Doug_Schepers lmartine NH ed
Agenda: [61]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSe
p/0340.html
Found Date: 23 Sep 2008
Guessing minutes URL: [62]http://www.w3.org/2008/09/23-svg-minutes.html
People with action items: anthony doug emmons erik nicolas niklas nkila
s
[61] http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0340.html
[62] http://www.w3.org/2008/09/23-svg-minutes.html
End of [63]scribe.perl diagnostic output]
[63] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Tuesday, 23 September 2008 12:09:56 UTC