W3C home > Mailing lists > Public > www-svg@w3.org > May 2010

Minutes, 10 may 2010 SVG telcon

From: Chris Lilley <chris@w3.org>
Date: Mon, 10 May 2010 18:04:01 +0200
Message-ID: <1536902605.20100510180401@w3.org>
To: www-svg@w3.org
Hello www-svg,

 Minutes at http://www.w3.org/2010/05/10-svg-minutes.html

and below as text for tracker
                   SVG Working Group Teleconference

10 May 2010


      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0063.html

   See also: [3]IRC log

      [3] http://www.w3.org/2010/05/10-svg-irc


          ed, ChrisL, anthony, jwatt, Patrick




     * [4]Topics
         1. [5]Use and CSS selectors
         2. [6]second edition updates
     * [7]Summary of Action Items

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

      [8] http://lists.w3.org/Archives/Public/public-svg-wg/2010AprJun/0063.html

Use and CSS selectors


      [9] http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/struct-use-hover.svg


     [10] 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

   document structure. CSS2 selectors cannot be applied to the

   cloned DOM tree because its contents are not part of the formal


   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

   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

   <ed> ISSUE-2323?

   <trackbot> ISSUE-2323 -- Consider aligning SVG*List interfaces with
   other arraylike types -- RAISED

   <trackbot> [11]http://www.w3.org/Graphics/SVG/WG/track/issues/2323

     [11] 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

   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
   ... Hard to tell when the spec doesn't say or even give advice on

   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

   <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

   <trackbot> Created ACTION-2783 - Write up new list interface
   proposal and submit test cases for SVG 2.0 [on Erik Dahlström - due

second edition updates

   <ed> [14]http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_1.1F2

     [14] 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

   <ChrisL> new test in the last couple of hours


     [15] 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


     [16] 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


     [17] 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


     [18] 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

   <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

Summary of Action Items

   [NEW] ACTION: ed: Create Test Case for Animating
   SVGFragmentIdentifier [recorded in
   [NEW] ACTION: ed: Write up new list interface proposal and submit
   test cases for SVG 2.0 [recorded in
   [NEW] ACTION: patrickd: Write a whitepaper on versioning, future
   proofing, backward compatability and SVG 2.0 [recorded in

   [End of minutes]

 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Monday, 10 May 2010 16:04:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:21 UTC