SVG WG Telecon Meeting Notes 5/10/2010

*** patrickd [836b0057@128.30.52.43] has joined #svg
*** Topic is: SVG WG: SVG supported in every major browser
*** Topic set by shepazu [Tue Mar 16 19:18:13 2010]
*** patrickd ed Zakim RRSAgent ChrisL karl shepazu ed_work anthony trackbot 
*** Channel created on Wed Feb 10 12:29:22 2010
<patrickd> scribenick: patrickd
<ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0063.html
<ChrisL> Topic: Use and CSS selectors
<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> patrickd: in terms of the <use> and css selectors, we see that in the test each browser has a different behavior
<patrickd> ed: spec says that use instances are not part of the DOM tree
<patrickd> ed: Would be OK with going with something in SVG 2.0 specification
<patrickd> CSS2 selectors can be applied to the  
<patrickd> original (i.e., referenced) elements because they are part of the formal  
<patrickd> document structure. CSS2 selectors cannot be applied to the (conceptually)  
<patrickd> cloned DOM tree because its contents are not part of the formal document  
<patrickd> structure.
<patrickd> patrickd: that part of spec, indicates that none of the styles should apply to use instances
<patrickd> patrickd: which means that webkit has it right
<patrickd> ed: webskit just appears to have some refresh bugs perhaps
<patrickd> ed: Think opera has it implemented as expected; Opera is applied to the original but not the shadow instances
<patrickd> ChrisL: Shadow tree is not addressable through selectors
<ed> s/as expected/as it's specced in SVG 1.1/
<patrickd> ChrisL: Firefix expands things into place; so things that are there should not be there
<Zakim> +[IPcaller]
*** jwatt [roslea@81.159.34.41] has joined #svg
<jwatt> Zakim, who's on the call?
<Zakim> On the phone I see ed, ChrisL, anthony, [Microsoft], [IPcaller]
<patrickd> ed: use can sometimes propegate the style into the use tree
<jwatt> Zakim, IP is me
<Zakim> sorry, jwatt, I do not recognize a party named 'IP'
<jwatt> Zakim, IPcaller is me
<Zakim> +jwatt; got it
<patrickd> patrickd: where would we go with this in SVG 2.0
<patrickd> ed: Add new kind of <use> element, or add attributes controlling whether or not it applies to <use> or shadow trees
<patrickd> ChrisL: It's a change to the underlying model; if the DOM is there vs. the DOM is not there.
<patrickd> ChrisL: Current model is that you cannot select shadow tree elements; it sounds like extra selectors 
<patrickd> patrickd: Or a slector synta
<patrickd> patrickd: What is this for?
<patrickd> 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
<patrickd> ChrisL: 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.
<patrickd> ChrisL: But you can't but a 'handler' on an instance.
<patrickd> ChrisL: But these are SVG 2.0 changes
<patrickd> patrickd: How you fix this in SVG 2.0 without backwards compatability
<patrickd> ChrisL: Introcue new element, replaced in place as reference instead of shadowed.
<patrickd> ChrisL: A little bit like using XSLT or XBL in place. 
<patrickd> patrickd: What I will do is update that test to reflect the spec'd behavior
<ed> ISSUE-2323?
* trackbot getting information on 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
<patrickd> ed: Was going over making tests for SVGElementInstance and found some minor inconsistencies on how we define our list interfaces
<patrickd> ed: Ify you compare them to the array syntax in ecma script, we differ quite a bit
<patrickd> ed: Some of our list interfaces use getItem; while nodeList you use item; which also allows you to use the array interface
<patrickd> ChrisL: Did this come across because ecmascript came later?
<ChrisL> s/ecma/we specified it in IDL and then ecma/
<patrickd> ed: Probably some historic reason for it.  Just noticed the SVGElementantInstanceList is the same as NodeList, but all others use getItem.
<patrickd> ed: No length accessor; etc; there is the number of items; it makes it harder to use 
<patrickd> ed: Would like to align this with nodeLists for SVG 2.0 and we alias the numberOfItems property with length
<ChrisL> zakim, list attendees
<Zakim> As of this point the attendees have been ed, ChrisL, anthony, [Microsoft], jwatt
<ChrisL> zakim, Microsoft holds Patrick
<Zakim> +Patrick; got it
<patrickd> patrickd: So make them consistent within and with ecmascript array
<patrickd> ed: Do we want to keep list interfaces is the follow on question
<patrickd> ed: we do have code that will support this and we could put in place pretty fast
<patrickd> ChrisL: Do you see this a problem
<patrickd> anthony: It's a nightmare; I have used this many times in the wrong way
<ed> s/anthony/JW/
<patrickd> patrickd: What does it mean to have a change vs. a new feature in SVG 2.0?
<patrickd> ChrisL: If it is spec'd accordingly, then both versions will work but it is a higher cost implementing
<patrickd> patrickd: So because you want to have it work both ways, there may be a higher cost to implement it
<patrickd> patrickd: On the general subject of SVG 2.0, what to do about version number? Does this control behavior?
<patrickd> ChrisL: We tentatlively tried it but then backed off
<ChrisL> hasFeature is sort-of great
<patrickd> ed: hasFeature is not really working well?
<patrickd> ed: There are some slight differences in how far an implementation actually implement it
<patrickd> ChrisL: Granularity are too coarse and too fine, differently across browsers
<patrickd> ed: e.g. Firefox notes that they do not support filters, but the hasFeature does not indicate that they do
<patrickd> jwatt: Perhaps we should change that and just state that it's supported
<ed> s/Firefox notes that they do not/Firefox does/
<patrickd> jwatt: Hard to tell when the spec doesn't say or even give advice on hasFeature 
<patrickd> ed: In my experience, when I want to see if something works, I want to check DOM interface existance
<patrickd> ed: hasFeature isn't reliable enough
<patrickd> patrickd: But what about hasFeature with <switch>
<patrickd> patrickd: HTML should potentially incorporate this'
<patrickd> patrickd: we need to have the high level SVG 2.0 vision and the high level backward compatability story first
<patrickd> ed: People will run into more pain without having this new feature than they would otherwise
<patrickd> 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
<patrickd> ed: In a way you are right; there will be libraries that cover that small difference
<patrickd> ed: I think going forward, it will be better to make everything consistent. It doesn't change what's there, it just adds new stuff.
<patrickd> ChrisL: I think you need to write a whitepaper on future proofing and backward compat principles
<patrickd> jwatt: Our biggest problem on identifying change impact, is we don't have any indication of how much it is use on the web
<patrickd> jwatt: It would be great if MIcrosoft had a method of geting information about usage
<patrickd> 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
<patrickd> ed: Opera's system should still be available as well
*** f1lt3r [f1lt3r@64.119.159.231] has joined #svg
* ed quietly wonders wth finder needs to use 100% cpu even though I'm not doing anything in it really :P
<patrickd> action: patrickd: Write a whitepaper on versioning, future proofing, backward compatability and SVG 2.0
* trackbot noticed an ACTION. Trying to create it.
* RRSAgent records action 1
<trackbot> Created ACTION-2782 - Write a whitepaper on versioning, future proofing, backward compatability and SVG 2.0 [on Patrick Dengler - due 2010-05-17].
* ChrisL suspects finder is using flash
<patrickd> ed: Still would like to make the change
<patrickd> action: ed: Write up new list interface proposal and submit test cases for SVG 2.0
* trackbot noticed an ACTION. Trying to create it.
* RRSAgent records action 2
<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].
<ChrisL> Topic: second edition updates
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_1.1F2
<patrickd> patrickd: I will review the struct-dom tests on the wiki
<patrickd> ed: Anthony, do we have new tests that you reviewed?
<ed> Zakim, who's here?
<Zakim> On the phone I see ed, ChrisL, anthony, [Microsoft], jwatt
<Zakim> [Microsoft] has Patrick
<Zakim> On IRC I see f1lt3r, jwatt, patrickd, ed, Zakim, RRSAgent, ChrisL, karl, shepazu, ed_work, anthony, trackbot
<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> patrickd: I will review this one as well
<patrickd> ed: Can we mark the reviewed as accepted?
<patrickd> ChrisL: Yes, I will do it now
<patrickd> ChrisL: Those need to get added to the tests, but not the errata. 
<patrickd> ChrisL: I proposed some wording in email.  Link incoming
<ChrisL> http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0064.html
<patrickd> 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
<patrickd> ChrisL: Might be easier to remove the test
<patrickd> patrickd: I say remove i
<ChrisL> resolved: remove styling-elem-02-b.svg
* ed will be staying here: http://www.ichotelsgroup.com/h/d/HI/1/en/direction/brubr?cm_mmc=EmailLink-_-WEBEmail-_-BRUBR-_-Local_Maps
<patrickd> ed: New Topic semi-colon separator
<ed> http://www.w3.org/mid/201005061734.12398.Dr.O.Hoffmann@gmx.de
<patrickd> ed: Can SVGFragmentIdentifiers be animated with using semi-column without esacping it
<patrickd> ChrisL: Should modify this such that animated semi-color separated attributes required to be escaped
<patrickd> ed: We should get a proper test case for it
<patrickd> action: ed: Create Test Case for Animating SVGFragmentIdentifier
* trackbot noticed an ACTION. Trying to create it.
* RRSAgent records action 3
<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> patrickd: Cancelling SVG WG Telecon because of holidays

Received on Monday, 10 May 2010 16:01:50 UTC