SVG Working Group Teleconference -- 10 May 2010

<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

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: 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].

second edition updates

<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?

- DRAFT -

SVG Working Group Teleconference

10 May 2010

Attendees

Contents

Use and CSS selectors

second edition updates

Summary of Action Items

Scribe.perl diagnostic output