See also: IRC log
<trackbot> Date: 10 May 2010
<ed> trackbot, start telcon
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 10 May 2010
<scribe> scribenick: patrickd
<ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0063.html
<ed> http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/struct-use-hover.svg
<ed> http://lists.w3.org/Archives/Public/www-svg/2010May/0006.html
patrickd: in terms of the <use> and css selectors, we see that in the test each browser has a different behavior
ed: spec says that use instances
are not part of the DOM tree
... Would be OK with going with something in SVG 2.0
specification
CSS2 selectors can be applied to the
original (i.e., referenced) elements because they are part of the formal
document structure. CSS2 selectors cannot be applied to the (conceptually)
cloned DOM tree because its contents are not part of the formal document
structure.
patrickd: that part of spec,
indicates that none of the styles should apply to use
instances
... which means that webkit has it right
ed: webskit just appears to have
some refresh bugs perhaps
... Think opera has it implemented as it's specced in SVG 1.1;
Opera is applied to the original but not the shadow
instances
ChrisL: Shadow tree is not
addressable through selectors
... Firefix expands things into place; so things that are there
should not be there
ed: use can sometimes propegate the style into the use tree
patrickd: where would we go with this in SVG 2.0
ed: Add new kind of <use> element, or add attributes controlling whether or not it applies to <use> or shadow trees
ChrisL: It's a change to the
underlying model; if the DOM is there vs. the DOM is not
there.
... Current model is that you cannot select shadow tree
elements; it sounds like extra selectors
patrickd: Or a slector
synta
... What is this for?
ChrisL: A lot of grahics
libraries have symbol libraries; the decision was made that we
weren't going to have pre-built symbols. This was the basic use
case. Re-usable stuff
... The thing that it misses; there is only one instance in the
document tree; you can change the original copy and all of them
change, e.g.
... But you can't but a 'handler' on an instance.
... But these are SVG 2.0 changes
patrickd: How you fix this in SVG 2.0 without backwards compatability
ChrisL: Introcue new element,
replaced in place as reference instead of shadowed.
... A little bit like using XSLT or XBL in place.
patrickd: What I will do is update that test to reflect the spec'd behavior
<ed> ISSUE-2323?
<trackbot> ISSUE-2323 -- Consider aligning SVG*List interfaces with other arraylike types -- RAISED
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2323
<ChrisL> Topic; ISSUE-2323
ed: Was going over making tests
for SVGElementInstance and found some minor inconsistencies on
how we define our list interfaces
... Ify you compare them to the array syntax in ecma script, we
differ quite a bit
... Some of our list interfaces use getItem; while nodeList you
use item; which also allows you to use the array interface
ChrisL: Did this come across because we specified it in IDL and then ecmascript came later?
ed: Probably some historic reason
for it. Just noticed the SVGElementantInstanceList is the same
as NodeList, but all others use getItem.
... No length accessor; etc; there is the number of items; it
makes it harder to use
... Would like to align this with nodeLists for SVG 2.0 and we
alias the numberOfItems property with length
patrickd: So make them consistent within and with ecmascript array
ed: Do we want to keep list
interfaces is the follow on question
... we do have code that will support this and we could put in
place pretty fast
ChrisL: Do you see this a problem
JW: It's a nightmare; I have used this many times in the wrong way
patrickd: What does it mean to have a change vs. a new feature in SVG 2.0?
ChrisL: If it is spec'd accordingly, then both versions will work but it is a higher cost implementing
patrickd: So because you want to
have it work both ways, there may be a higher cost to implement
it
... On the general subject of SVG 2.0, what to do about version
number? Does this control behavior?
ChrisL: We tentatlively tried it but then backed off
<ChrisL> hasFeature is sort-of great
ed: hasFeature is not really
working well?
... There are some slight differences in how far an
implementation actually implement it
ChrisL: Granularity are too coarse and too fine, differently across browsers
ed: e.g. Firefox does support filters, but the hasFeature does not indicate that they do
jwatt: Perhaps we should change
that and just state that it's supported
... Hard to tell when the spec doesn't say or even give advice
on hasFeature
ed: In my experience, when I want
to see if something works, I want to check DOM interface
existance
... hasFeature isn't reliable enough
patrickd: But what about
hasFeature with <switch>
... HTML should potentially incorporate this'
... we need to have the high level SVG 2.0 vision and the high
level backward compatability story first
ed: People will run into more pain without having this new feature than they would otherwise
patrickd: I disagree; because if they discover that it works one way in one browser, they will still have to code it differently for the other browser anyway
ed: In a way you are right; there
will be libraries that cover that small difference
... I think going forward, it will be better to make everything
consistent. It doesn't change what's there, it just adds new
stuff.
ChrisL: I think you need to write a whitepaper on future proofing and backward compat principles
jwatt: Our biggest problem on
identifying change impact, is we don't have any indication of
how much it is use on the web
... It would be great if MIcrosoft had a method of geting
information about usage
patrickd: It would seem that we could contribute there, but we are caught with limitted SVG assets today, vs. what we will see in a year or so
ed: Opera's system should still be available as well
<scribe> ACTION: patrickd: Write a whitepaper on versioning, future proofing, backward compatability and SVG 2.0 [recorded in http://www.w3.org/2010/05/10-svg-minutes.html#action01]
<trackbot> Created ACTION-2782 - Write a whitepaper on versioning, future proofing, backward compatability and SVG 2.0 [on Patrick Dengler - due 2010-05-17].
ed: Still would like to make the change
<scribe> ACTION: ed: Write up new list interface proposal and submit test cases for SVG 2.0 [recorded in http://www.w3.org/2010/05/10-svg-minutes.html#action02]
<trackbot> Created ACTION-2783 - Write up new list interface proposal and submit test cases for SVG 2.0 [on Erik Dahlström - due 2010-05-17].
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_1.1F2
patrickd: I will review the struct-dom tests on the wiki
ed: Anthony, do we have new tests that you reviewed?
<ChrisL> anthony?
<ed> shapes-polyline-02-t.svg
<ChrisL> shapes-polygon-02-t.svg
<ChrisL> shapes-grammar01-f.svg
<ChrisL> shapes-grammar01-f.svg passes in batik, opera - fails in firefox
<ChrisL> new test in the last couple of hours
<ed> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-grammar01-f.svg
patrickd: I will review this one as well
ed: Can we mark the reviewed as accepted?
ChrisL: Yes, I will do it
now
... Those need to get added to the tests, but not the
errata.
... I proposed some wording in email. Link incoming
<ChrisL> http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0064.html
patrickd: All agreed that new language around contentTypeStyle is good, so chrisl will check in
<ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/styling-elem-02-b.svg
ChrisL: Might be easier to remove the test
patrickd: I say remove i
<ChrisL> resolved: remove styling-elem-02-b.svg
ed: New Topic semi-colon separator
<ed> http://www.w3.org/mid/201005061734.12398.Dr.O.Hoffmann@gmx.de
ed: Can SVGFragmentIdentifiers be animated with using semi-column without esacping it
ChrisL: Should modify this such that animated semi-color separated attributes required to be escaped
ed: We should get a proper test case for it
<scribe> ACTION: ed: Create Test Case for Animating SVGFragmentIdentifier [recorded in http://www.w3.org/2010/05/10-svg-minutes.html#action03]
<trackbot> Created ACTION-2784 - Create Test Case for Animating SVGFragmentIdentifier [on Erik Dahlström - due 2010-05-17].
<ChrisL> escape the ; with an NCR and use the same test we use for viewbox meet and slice
patrickd: Cancelling SVG WG Telecon because of holidays
<ChrisL> patrick are you ok witj making minutes and sending them out?
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/as expected/as it's specced in SVG 1.1/ Succeeded: s/ecma/we specified it in IDL and then ecma/ Succeeded: s/anthony/JW/ Succeeded: s/Firefox notes that they do not/Firefox does/ Found ScribeNick: patrickd Inferring Scribes: patrickd WARNING: Replacing list of attendees. Old list: ed ChrisL anthony [Microsoft] jwatt New list: ed ChrisL anthony jwatt Patrick Default Present: ed, ChrisL, anthony, jwatt, Patrick Present: ed ChrisL anthony jwatt Patrick Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0063.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 10 May 2010 Guessing minutes URL: http://www.w3.org/2010/05/10-svg-minutes.html People with action items: ed patrickd WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]