SVG Working Group Teleconference -- 12 Aug 2009

<trackbot> Date: 12 August 2009

<scribe> Scribe: Chris

<scribe> ScribeNick: ChrisL

<scribe> Agenda: 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/

<heycam> 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 criteria
... 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 criteria

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 http://www.w3.org/2009/08/12-svg-minutes.html#action01]

<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

(agreed)

<scribe> ACTION: Anthony edit the test template to remove child sections for subtests [recorded in http://www.w3.org/2009/08/12-svg-minutes.html#action02]

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

(yes)

CM: Best to keep it all consistent

Pinned clip module

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> data:image/svg+xml;charset=utf-8;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIj4NCgk8bGluZSB4MT0iMTAiIHkxPSIxMCIgeDI9IjEwMCIgeTI9IjEwIiBzdHJva2U9ImJsYWNrIi8%2BDQoJPGxpbmUgeDE9IjEwIiB5MT0iMjAuNSIgeDI9IjEwMCIgeTI9IjIwLjUiIHN0cm9rZT0iYmxhY2siLz4NCjwvc3ZnPg%3D%3D

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

Safari, Opera and Firefox seem to use pixel centres

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

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 http://www.w3.org/Graphics/SVG/WG/track/issues/2291/edit .

animVal object identity [www-svg]

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)

<heycam> 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 http://www.w3.org/2009/08/12-svg-minutes.html#action03]

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

MAMA

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 raphael
... 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 analysis
... 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

http://dev.opera.com/articles/view/mama/

ED: Still waiting for answers to some questions

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

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 introduced

<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 http://www.w3.org/2009/08/12-svg-minutes.html#action04]

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

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

- DRAFT -

SVG Working Group Teleconference

12 Aug 2009

Attendees

Contents