W3C home > Mailing lists > Public > www-svg@w3.org > August 2009

Minutes, 12 August 2009 SVG telcon

From: Chris Lilley <chris@w3.org>
Date: Wed, 12 Aug 2009 10:11:33 +0200
Message-ID: <1873942974.20090812101133@w3.org>
To: public-svg-wg@w3.org
Hello public-svg-wg,

The minutes of the 12 August SVG telcon are at http://www.w3.org/2009/08/12-svg-minutes.html

and below as text for bots.

                   SVG Working Group Teleconference

12 Aug 2009


      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0040.html

   See also: [3]IRC log

      [3] http://www.w3.org/2009/08/12-svg-irc


          Doug, Chris, Cameron, Anthony, Erik, Jonothan




     * [4]Topics
         1. [5]SVG 1.1 Second Edition progress, tests
         2. [6]Test suite template
         3. [7]Pinned clip module
         4. [8]animVal object identity [www-svg]
         5. [9]MAMA
         6. [10]Platform evolution and attributeType="auto" [www-svg]
     * [11]Summary of Action Items

   <trackbot> Date: 12 August 2009

   <scribe> Scribe: Chris

   <scribe> ScribeNick: ChrisL

   <scribe> Agenda:

     [12] http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0040.html

   <scribe> Meeting: SVG WG

SVG 1.1 Second Edition progress, tests

   CM: Checking up where we are at. Close to finish. Did all my spec
   editing actions and test for my section of erratta
   ... reviewed tests already linked by other people
   ... can pick up one or two other tests from the slackers

   s/.. can/... can/


     [13] http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition

   CL: I will go looking for which tests are needed. Not done yet sorry

   CM: Can't review my own tests
   ... please review tests
   ... Couple of outstanding errata, two from Doug one from JWatt
   ... should we discuss at next weeks telcon?

   DS: Sure
   ... JWatt said he had resewrvations about complicating the model for
   clipping and visibility

   CM: After that, only a couple of admin tasks like building the PDF
   ... but would like to see a couple of items on todays agenda
   resolved before publication
   ... JWatt, we will discuss some of this next week

Test suite template

   CM: Anthony, you had things to discuss? Sections for test
   description section?

   AG: Not sure about which is the best structure

   C: Current template split into descriotion, operator script and pass
   ... automatic conversion put all previous stuff into one of these,
   not eassy to split automatically

   s/C: CM:/

   CM: So we need to split them manually?

   AG: Split some where it was obvious. Others need a bit more work

   CM: How would we use the different sections? ie whats the impact of
   having it all on one bit?

   AG: Its a better organisation, easier to read, and to check

   CL: Splitting may make it easier to see tests that have poor pass

   CM: No impact on actually running the tests though
   ... Status of harness generation scripts?

   AG: For SE its same as the old one, needs to be modified to grab
   stuff from new template. Have not modified the harness
   ... used these scripts for 1.2T testsuite.

   <scribe> ACTION: Anthony to fix up 1.1SE test suite harness for new
   template [recorded in

   <trackbot> Created ACTION-2647 - Fix up 1.1SE test suite harness for
   new template [on Anthony Grasso - due 2009-08-19].

   ED: Are we still going to strip out the test descriptions to do
   svggen like we used to?

   CL: Think svggen is pointless, no need for svggen any more
   ... Same as with 1.2T

   CM: So no revision number problems either

   C: Other thing is that test decription has a test component child,
   what is that for?

   AG: For subtests
   ... but subtests could have separate pass criteria so maybe this is
   not a good idea (looks at template)

   C: I have been writing the pass criteria all in one section, seems
   to be fine

   AG: Should we split up or not in the template?

   CM: Prefer to not split it up. Though difficult to link to multiple
   sections of the spec....

   AG: OK will fix so the script only needs to deal with three sections


   <scribe> ACTION: Anthony edit the test template to remove child
   sections for subtests [recorded in

   <trackbot> Created ACTION-2648 - Edit the test template to remove
   child sections for subtests [on Anthony Grasso - due 2009-08-19].

   AG: I will make the same change to the modules template

   CM: Do any of the modules have tests yet?


   CM: Best to keep it all consistent

Pinned clip module


     [16] http://dev.w3.org/SVG/modules/pinnedclip/publish/

   CM: Notice Doug checked it into public repository

   DS: Alex Danilo sent it to me, so checked it in
   ... in case we need it for SVG2

   CM: Does he plan to work on it?

   DS: Will check
   ... One of the ogg theora people raised the issue offlist, asking if
   SVG talks about pixel orientation, where the pixel starts (top
   left,centre) and pinned clip covers that
   ... asked him to comment on public list

   CL: We really need to decide as different rendering libraries are
   off by 0.5 pixel because of this
   ... Prefer to look at this and decide the majority solution

   ED: Opera does centre

   DS: Should be a SHOULD, but we should pick one

   CL;: Would like to see a test, then picj what most do

   DS: Alex said that top left is assumed, so 0,0 is the top left of
   the top left (quotes from an email)

   CL: Please get permission to forward that email

   DS: And the tests he is talking about

   CL: Would changing be an issue for Opera, is there content that
   relies on centre pixel positioning?


   ED: Don't think so. Made a test ....

   <ed> <line x1="10" y1="10" x2="100" y2="10" stroke="black"/>

   <ed> <line x1="10" y1="20.5" x2="100" y2="20.5" stroke="black"/>

   Safari, Opera and Firefox seem to use pixel centres

   JW: One will give sharp lines, the other gives sharp edges on

   ED: Wonder if shape-rendering affects it

   CM: Shape-rendering set to geometric-precision makes one blurry

   (We find opoosite results on Mac and on Windows)

   (some disagrement vs platform, browser version, lcd type ...)

   macbook vs macbook pro seems tobe different

   ED: Opera versions should be the same on all platforms modulo
   floating point libraries

   ISSUE: Whether a given integer coordinate is pixel centre or pixel
   top-left needs to be determined

   <trackbot> Created ISSUE-2291 - Whether a given integer coordinate
   is pixel centre or pixel top-left needs to be determined ; please
   complete additional details at
   [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2291/edit .

     [17] http://www.w3.org/Graphics/SVG/WG/track/issues/2291/edit

animVal object identity [www-svg]


     [18] http://www.w3.org/mid/65fa1620908061811n4271a4c8nc26993dc529c0852@mail.gmail.com

   <ed> may have been confusing the two things btw, sampling is done in
   the center but the coordinates in the file are top-left I believe

   <ed> (for opera)

   Brian Birtles was asking if animval is writable. Unclear whether
   'same as baseval' is pointer to same object or two copies

   scribe: can change baseval, but can't change animval. Unless they
   are piujnters to same object

   CL: But if they are bing animval, then writing will be overwritten

   JW: Attempts to write to animval should throw

   CM: Think shttas the case
   ... Second issue is about the exception
   ... BB said it would be more consistent to trying to assign to
   .animval if there was no throwing
   ... but animval.value does throw
   ... Thing its normal

   JW: Does webidl fix that?

   CM: It could currently says assigning to readonly is ignored

   JW: Silently failis hard to debug

   CM: Related to strict mode in ecma 5, in strict mode it thows

   JW: Do we currently just reference what ECMA says?

   CM: Currently we point to third edition?

   (fourth edition shall not be mentioned)

   CM: So suggest we resolve the ambiguity by saying its always a
   separate object to baseval
   ... its readonly, cant change, animval.value would throw an
   exception always, not just when there is an animation in progress
   ... Would need special processing to see if baseval is recomputed

   (scribe mayhave misunderstood)


     [19] http://lists.w3.org/Archives/Public/www-svg/2009Aug/0016.html

   CM: tested a bunch of implementations, browser and standalone, they
   always have distinct objects for baseval and animval
   ... Proposal is to make them distinct objects

   JW: Seems fine to me

   Resolved: Clarify that basevaland animval are separate objects

   <scribe> ACTION: Cameron to Clarify that basevaland animval are
   separate objects [recorded in

   <trackbot> Created ACTION-2649 - Clarify that basevaland animval are
   separate objects [on Cameron McCormack - due 2009-08-19].


   ED: Sent mail to guy running MAMA on Opera, some responses
   ... does it run scripts, does it do propoer parsing. Its a static
   analysis, some parsing but they are not run
   ... so script side effects not seen
   ... also asked for stats on svg on the web, so it only does static
   analysis and misses mixed html and svg
   ... pointed him to some frameworks that use svg like dojo and
   ... he could count uses of thise frameworks
   ... asked on stats for methods in SVG DOM used
   ... will send him the details needed to do that. Can do in static
   ... Frequency analysis of svg elements and attributes could be done,
   is not done yet
   ... does not handle inline svg, easy to add
   ... asked about svg and stylesheets, no results yet
   ... many people asking for svg stuff to be added to Mama, david
   story, chaals asked


     [21] http://dev.opera.com/articles/view/mama/

   ED: Still waiting for answers to some questions

Platform evolution and attributeType="auto" [www-svg]


     [22] http://www.w3.org/mid/11e306600908101658q2f1a7efaubcc88a6f04362e32@mail.gmail.com

   <heycam> CL: originally we didn't have attributeType

   <heycam> ... it was assumed the impl would know if it was a
   property, otherwise assume it's an attribute

   <heycam> ... this only makes a difference with external stylesheets

   <heycam> ... if it's a formatting property on an element, it makes
   no difference

   <heycam> ... the only time it makes a difference is if the external
   style sheet is there and has a higher specificity that overrides the
   presentation attribute

   <heycam> ... since most svgs don't have external stylesheets,
   there's no discernable effect

   <ed> <style>rect { fill: red !important }</style> for example

   <heycam> ... the other time it makes a difference is if there's a
   prop and attr of the same name

   <heycam> ... this came up in amaya

   <heycam> ... where it thought width/height attrs on svg were the
   same as the css properties

   <heycam> ... so it would need to keep those distinct

   <heycam> ... and because of that one case, attributeType was

   <heycam> ... if you really happen to know if there's a conflicting
   attribute/property on an element, and you want to decide which, you
   can use attributeType

   <heycam> ... so roc's comment about it limiting extensibility with
   default 'auto' value is true

   <heycam> ... in 99% of cases it makes no difference. but if you had
   to say attributeType="css" for every time you animate a css
   property, it would be annoying

   <heycam> ... so if you we introduce an animatable property in the
   future with the same name as an attribute, then yes it would cause
   trouble for future-compat

   <heycam> ... so we shouldn't do that

   <heycam> DS: how does width/height differ in css?

   <heycam> CL: width/height properties on root svg help decide how
   large the svg is in the containing document

   <heycam> ... if you try to apply the properties to the svg element
   itself it wouldn't do anything

   <heycam> ... it's kind of a corner case

   <heycam> ... 'fill' is another clashing attribute name case

   <heycam> ... from smil, and for the painting property

   <heycam> ... but you can't disambiguate there

   <heycam> CM: and the SMIL fill is never animatable anyway

   <heycam> CL: so the auto value does what you want in 99% of cases

   <heycam> DS: what needs to be done about this?

   <heycam> CL: an explanation about why it's not a problem in practice
   would be my suggestion

   <heycam> CM: so we'll say we won't introduce properties that clash
   in this way

   <scribe> ACTION: Chris to respond to RoC on Platform evolution and
   attributeType="auto" [recorded in

   <trackbot> Created ACTION-2650 - Respond to RoC on Platform
   evolution and attributeType="auto" [on Chris Lilley - due

   DS: This should be clarified in the spec as wel as in an email
   ... so clarify the spec and point him to that

   JW: and hurry, send an interim response if there will be any delay
   because SMIL is being implemented currently
   ... 3.6 will be a short release, should be in 3.7
   ... Daniel Holbert and Brian Birtles working on it
   ... 3.6 is going straight to beta in a week or two
   ... should ship in January (my very rough guess)
   ... smil not enabled by default, as incomplete and buggy but can be
   anabled using about:config
   ... in nightlies, not 3.5

   DS: Could an extension enable the support?

Summary of Action Items

   [NEW] ACTION: Anthony edit the test template to remove child
   sections for subtests [recorded in
   [NEW] ACTION: Anthony to fix up 1.1SE test suite harness for new
   template [recorded in
   [NEW] ACTION: Cameron to Clarify that basevaland animval are
   separate objects [recorded in
   [NEW] ACTION: Chris to respond to RoC on Platform evolution and
   attributeType="auto" [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 Wednesday, 12 August 2009 08:11:46 UTC

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