minutes, SVG WG Auckland F2F, day 2

Minutes from day 2 of the Auckland F2F:


and as text below:


       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

28 Feb 2011

    See also: [2]IRC log

       [2] http://www.w3.org/2011/02/28-svg-irc


           Heycam, Shepazu, DHolbert, Birtles, Jun, Chris, Anthony,
           JWatt, Erik, Roc, Patrick, Tbah

           Erik, Heycam

           ChrisL, ed


      * [3]Topics
          1. [4]CSS transforms 2d and 3d
          2. [5]svg2 dom
          3. [6]performance issues
          4. [7]array getters/setters
          5. [8]Global ECMAScript constructors
          6. [9]svg 1.1 se testsuite status
          7. [10]DOMActivate deprecation and SVG 2.0
          8. [11]SVG Parameters
          9. [12]Draft with the href resolutions
         10. [13]SVG integration
      * [14]Summary of Action Items

    <trackbot> Date: 28 February 2011

    <heycam> tbah, you can call in now with code 26633

CSS transforms 2d and 3d

    <ChrisL> scribenick: ChrisL

    <pdengler> If you are asking about any other topics, my main topic
    today is animations/transitions on SVG

    <pdengler> Within this, Cameron and I have had a few threads on this
    that I used to update the working group yesterday

    <pdengler> Yes and no

    anthon_nz: at tpac the two groups agreed to use the same spec, and i
    saw simon frazer mad a commit, but i have not done much recently
    ... this is in the fx repository
    ... cam you wanted to add a property?

    heycam: want the sytax to allow all the things that the svg syntax
    ... rotate lacks cx and cy for example
    ... they have a transform-origin instead, not clear how that works
    with multiple transforms

    jwatt: thought it was for each individual rotate and scale

    heycam: that makes more sense for me

    ed: think these are stillprefixed

    heycam: so there is room for changes

    ed: did we not already agre to align syntax?

    <heycam> [15]http://dev.w3.org/csswg/css3-2d-transforms/

      [15] http://dev.w3.org/csswg/css3-2d-transforms/

    anthon_nz: simon and i both have actions for this spec. in
    particular the idl, using two different matrices

    heycam: who has the action to propose that?

    anthon_nz: need to look back in the tracker

    jwatt: neither of those is very satisfactory
    ... dont want the same origin for a setries of transforms
    ... want a next-origin() command e.g. transform="...
    next-origin(...) rotate(...) next-origin(...) scale(...) ..."

    heycam: whats wrong with having them in the transform itself?

    jwatt: interferes with 2d to 3d expansion

    anthon_nz: simon has an actionto investigate the issue with matrix
    definitins for the dom

    heycam: are the property names different too
    ... we have abcdef hope theirs are in the same order

    <jwatt> RRSAgent: make minutes

    ChrisL: is this a row major vs column major issue?

    heycam: hope not

    <ed> [16]http://www.w3.org/2010/03/11-fx-minutes.html#item02 (there
    are some resolutions there to align the syntax)

      [16] http://www.w3.org/2010/03/11-fx-minutes.html#item02

    anthon_nz: another action on transitions, moved to css transitions

    <CGI556> I can find out

    <pdengler> Let me check real quick

    anthon_nz: has john jensen made teests for css transforms?

    <pdengler> Can I ask the stupid question in the meantime?

    <jwatt> yup

    yes, you may

    <pdengler> Is the biggest problem with 2d the center of origin?

    <pdengler> Or only problem?

    also, you can even unmute before asking it :)

    <pdengler> shouldn’t CSS transform just be a property that override
    to SVG Transform and unless the origin is specified, the default is
    the default (i.e, 0,0 in SVG).

    its one problem, given the anonymous list of parameters. 3d has one
    more param

    <pdengler> So as soon as you throw in 3d yes?

    heycam: first step is to get a list of the differences inthe syntax

    <pdengler> Have we decided that 3D is interesting to SVG fragments?
    Seems like a big perf nightmare, I don't care who you are ;)

    ed: already discussed in fx telcons, just need to look at minutes.
    sometimes minutes with no corresponding action, so need to review
    and assign them

    action anthony to harvest fx minutes looking for missed actions

    <trackbot> Created ACTION-2973 - Harvest fx minutes looking for
    missed actions [on Anthony Grasso - due 2011-03-07].

    ed: skew is one thing that was different and i posted a link to the
    resolution to align them

    anthon_nz: css property overides the svg?

    ed: yes we made it a presentastion attribute

    anthon_nz: need to add that note to explain the override

    <pdengler> If we keep the SVG OM different from the CSS OM, would we
    be OK?

    ChrisL: becauser the style rule has higher specificity

    heycam: would it break if we keep both object models

    shepazu: dont want any differences. people trip over them and it
    puts them off svg

    <pdengler> I agree with you, that is why if I always use CSS OM, it
    just works, right?

    heycam: .transform on elements, maybe property would dissapear. have
    not discussed

    ed: not the only place. getCTM etc

    ChrisL: concerned to ensure the transforms from styling are
    reflected in the dom

    heycam: get computed style

    <heycam> heycam: whenever we consider changing an animated attribute
    into a property, we'll need to consider what to do with the
    SVGAnimatedBlah property on the element

    <heycam> heycam: having the SVGAnimatedBlah still exist, and reflect
    the computed style, is kind of different from what they all do

    ChrisL (explains attributeType)

    jwatt: (explains that everyone does something different)

    shepazu: smil says that animation model is different to css obect
    model. but we can change that going forward

    heycam: what is the different syntax in smil?

    <pdengler> my animation proposal says that CSS animations always
    work on SVG as expected in CSS; that is that animVal is not

    shepazu: i believe we should fork from SMIL which is no longer being
    developed.more important to align with css and keep the element
    based approach

    <dholbert> pdengler, (but that doesn't allow you to animate
    non-presentational attributes, like 'x' and 'width', right?)

    <dholbert> pdengler, (not that that's necessarily an issue, just
    making sure I understand you)

    heycam: .baseval and .animval was our addition, but reflecting into
    the overide stylesheet of elements is from smil

    shepazu: if we find stuff in smil that gives implementaion hassles
    or performance issues or is hard for authors we should simplify and
    clarify it

    jwatt: on a case by case basis

    shepazu: clearly

    roc: we need to decide how we to animations before we can decide how
    todo transforms

    ed: we split the topics this way to allow dino to join later

    anthon_nz: we also decided to move the animation part out of
    transforms into the css animations spec

    heycam: which explains how to interpolate animations

    shepazu: comes down to priorities, which one of css and attribute
    takes priority

    ChrisL: css already says how. presentation attributes have
    specificity zero

    roc: need to discuss how different engines implement it. there are a
    lot of issues

    shepazu: that attributeType has no value and is widely misunderstood
    so we should drop it

    heycam: so anthony has the action to trawl minutes looking for
    missed actions

    anthon_nz: have started do ing that. not had an fx tf discussion in
    a while

    ed: spec has nothing oin transform origin



    jwatt: (points to what heycam posted)

    <shepazu> issue: consider dropping @attributeType, since it it is
    widely misunderstood and doesn't have a lot of value; perhaps add
    priority/specificity/importance property instead

    <trackbot> Created ISSUE-2402 - Consider dropping @attributeType,
    since it it is widely misunderstood and doesn't have a lot of value;
    perhaps add priority/specificity/importance property instead ;
    please complete additional details at
    [18]http://www.w3.org/Graphics/SVG/WG/track/issues/2402/edit .

      [18] http://www.w3.org/Graphics/SVG/WG/track/issues/2402/edit

    jwatt: why is there still a css spec? is it being updated as well as
    the fx one?



    ed: this is the current spec

    last mod date on the css one is May 2010, fx one is December 2010

    heycam: fx one does have trotate with centrepoint
    ... dont much like trandform origin
    ... ac currently written its an overall wrap on the series

    roc: we are kinda locjed into it

    heycam: prefixed?

    roc: yes, but

    heycam: prefer having the origin right there in the rotate

    roc: dont know wht it was not inthe rotate. it rotates about the

    heycam: we discussed having a 3d excplicitly in the name

    ChrisL: we need the distinct names to aboid clashes with anonymous
    property lists

    anthon_nz: need to move to 3d. easier to do 2d first

    jwatt: this stuff looks well aligned with the svg stuff

    ed: need to publish it, needs agreement of bothgroups

    heycam: all the values are plain numbers not lengths

    roc: they are lengths in css

    ChrisL: so you require units?

    roc: yes. scale factors are noth lengths, but translates do

    heycam: svg does not suppout units in translates

    anthon_nz: allow percentages too?

    heycam: in the dom they are floats

    jwatt: they are svgnumbers

    heycam: they are flaots in the css one to o so the units need to be
    factored out

    <shepazu> issue: consider adding scale around specific point

    <trackbot> Created ISSUE-2403 - Consider adding scale around
    specific point ; please complete additional details at
    [20]http://www.w3.org/Graphics/SVG/WG/track/issues/2403/edit .

      [20] http://www.w3.org/Graphics/SVG/WG/track/issues/2403/edit

    anthon_nz: should discuss at fx telcon

    ed: has not been brought up. need to collect these discussion topics

    heycam: want to see a list of what is decided already and what is
    not discussed

    ed: anthon_nz please make a wiki page as part of your action-2973

    <heycam> dino, ^

    ed: interesting cssmatrix and svgmatrix interfaces both have floats
    so they already loose info on whatever units were originally

    heycam: really need that before deciding

    ed: we could do animval baseval here

    heycam: had discussed with birtles the need to specify the centre
    ... as long as svg can to rotate around a centre

    anthon_nz: what happens if you define it both ways/

    heycam; sounds like transform origin is just an initial shift to
    move the origin and sa shift back after the entire list of transform

    anthon_nz: will overshoot the rotation. can say to ignore tranform
    origin if centre of rotation is siupplied

    birtles: centrepoint on bbox is just 50% 50%

    heycam: css can say things like right-5px
    ... wonder about calc()

    roc: yes you can put calc anywhere there is a length

    resolved: svg wants to allow rotation about centrepoint in svg, t
    align with css. sysntax not yet decided

    RESOLUTION: svg wants to allow rotation about centrepoint in svg, to
    align with css. sysntax not yet decided

    birtles: want to make sure that functionality is also available for
    animate Transform

    heycam: peicewise interpolation of all the matrix components

    ed: any more to say on this topic?


    <ed> [21]http://dev.w3.org/SVG/profiles/1.1F2/publish/filters.html

      [21] http://dev.w3.org/SVG/profiles/1.1F2/publish/filters.html

    <roc> [22]http://people.mozilla.com/~roc/LitCircles.svg

      [22] http://people.mozilla.com/~roc/LitCircles.svg

    <roc> ed: [23]http://people.mozilla.com/~roc/LitCircles.xml

      [23] http://people.mozilla.com/~roc/LitCircles.xml

svg2 dom

    ed: lets fgo through the list

    <heycam> [24]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM

      [24] http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM

    tear off


    ChrisL: so this is about live vs snapshot copy?

    heycam: yes

    ed: its not read-only. you can write to them
    ... cant change the type of a path segment. can replace them though

    ChrisL: seems cleaner to add and remove path segments

    ed: not sure what the tearoff ise is in general

    jwatt: who wrote this

    (it was jwatt)

    jwatt: so the idea is a lightweight internal structure created on
    demand can be thrown away when not referenced
    ... not clear of the impact of some of the spec on tearoffs

performance issues



    ed: so is thys a terse syntax issue?
    ... number of proposalsaround this. setting multiple attrs at once.
    alias things to get float values directly

    shepazu: microdom was one attempt to do that

    heycam: was that a performance gain

    ed: was more efficient and also the code size as a lot smaller
    compared to 1.1 dom. less objects than 1.1 dom
    ... and they are live which adds complexity. udom is typed, one shot

    heycam: is typed dom a premature optimisation, javascript is getting
    faster and better optimised

    ed: simpler to maintain the udom

    heycam: live objects is part of the complexity

    (discussion on 'with' in ES5)

    ed: aliases, c.cx for example

    heycam: not a good way to go as other objects dont work like that
    ... incosistent if its an object or a number depending on context
    ... some generic dom core improvements could help here. like setting
    multiple atrs at once

    shepazu: yes, but that is not what is being worked on in that effort

    ed: we want to make the svg dom simplert and easier

    shepazu; put together a proposal

    ChrisL: fixing the code dom means other languages can benefit too

    <shepazu> [27]http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API

      [27] http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API

    shepazu: this is a json-like approach. name value pairs in attr
    ... can be done in script libraries, gets the readability
    improvement but no performance improvement

    heycam: javascript engines are removing that multi call performance
    ... i always write functions to take lists of attr values

    shepazu: also propose an insertAtIndex



    heycam: thats a really simple improvement

    shepazu: also create with initialise


      [29] http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API#createChild

    ed: this belongs in dom core

    shepazu: thatwas my intention
    ... also some things specific tosvg, in addition

    <shepazu> [30]http://schepers.cc/w3c/svg/api/cog.svg

      [30] http://schepers.cc/w3c/svg/api/cog.svg

    shepazu: view source. uses svg and canvas the same way
    ... learning one api for svg and canvas helps
    ... so two things, once specific to graphics and one generic

    ed: css om also has longwinded access

    heycam: anne was supposed t be dealing with that

    ed: still somehwat verbose, but acceptable

    shepazu: we need editors that wil follow through and get this done
    ... one, general dom stuff
    ... two, things soecific tographics apis
    ... three, styling and css apis

    heycam: there could be improvements that are not graphics specific
    but that we want, like constructors
    ... need a fully worked out proposal

    shepazu: its not a complete list

    jwatt: useful, but a wiki page does not get external review

    <scribe> ACTION: shepazu to draw up a spec around simple dom core
    api [recorded in

    <trackbot> Created ACTION-2974 - Draw up a spec around simple dom
    core api [on Doug Schepers - due 2011-03-07].

    ed: makes sense to do in the webapps space rather thsan here

    heycam: can be a set of improvements

    jwatt: dom streamlining

    (back to tearoffs)

    (apparently blame due to anthony)

    <scribe> (dropped)

array getters/setters



    ed: array lengths
    ... and indexing

    jwatt: nice one

    ed: shuld enure all our lists and arrays done like this. needs spec

    jwatt: so added length, array indexing ... splice?

    ed no

    jwatt: good

    birtles can we deprecate number of items etc

    jwatt: yes for new content but imps need to support
    ... deprecate getItem

    action erik to spec out lenght and array indexing for svg list types

    <trackbot> Created ACTION-2975 - Spec out lenght and array indexing
    for svg list types [on Erik Dahlström - due 2011-03-07].

Global ECMAScript constructors



    ed: really handy

    birtles: yes



    ed: polluting globalnamespace?

    jwatt: mozilla has them already

    heycam: opera exposes them?

    ed: not currently. not much work to expose constructors

    jw: can override, not immutable

    heycam: mostly straightforward. datatype ones are overloaded so no
    params does the current one , or list of params, or string

    birtles any other types that need to be added, like for making a

    heycam: cant create pathe data objects

    jwatt: they are read-only. what would you do with it

    heycam; expose path data as a string and have it writable

    birtles: same as setAttr then

    <heycam> ed: do we use SVGAnimatedPathData / pathSegList as a
    separate object? or is it mainly for reading/writing for <path>

    <heycam> ... do we need a constructor for that?

    <heycam> heycam: we don't, so maybe we don't need it

    <heycam> ... or even an SVGPathData.asString property

    <heycam> ... unlike SVGPoint/SVGMatrix which are useful
    independently of an element

    birtles: want more use cases. we made a function to make paths from
    an array of floats
    ... and the segment type. make s asies all of the same type

    heycam: join "C" with the list

    heycam; have discussed before, geometry operations on path data,
    have not gone anywhere

    ed: lets get some resolutions

    RESOLUTION: add array style indexing and .length and .item to svg
    list types


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

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

      [35] http://www.w3.org/Graphics/SVG/WG/track/issues/2323



    jwatt: concerned about relationof constructors to HTML
    ... can we do better?

    heycam: otoh this is a small and useful change
    ... combination of array indexes and constructors works well

    <heycam> mySVGLengthList[$1\47] = new SVGLength("2em")

    jwatt: why would i want to do that, I'd rather just assign the

    heycam; getter can only return one thing

    <heycam> while we could overload the setter to allow assigning a
    string or an SVGLength

    ed: can override getters and setters in ES5

    jwatt: can i concatenate an object and a string to get a string

    heycam: moved away from that idea because the conveson does not take
    place everywhere, specifically the not operator

    jwatt: is the ! operator the main reason?

    heycam: its one of them
    ... == also, as I said to you in 2009
    ... in html there are a couple of legacy constructors


    heycam: new specs are taking advantage of constructors
    ... no issue of scope collision

    RESOLUTION: We will draft on global constructors for selected dom

    ACTION heycam to draft on global constructors for selected dom

    <trackbot> Created ACTION-2976 - Draft on global constructors for
    selected dom objects [on Cameron McCormack - due 2011-03-07].



    <trackbot> ACTION-2976 Draft on global constructors for selected dom
    objects notes added


svg 1.1 se testsuite status

    jwatt: looked through our tests to look for interactivity
    ... ton of pointer event usagesoe require kbd events
    ... for accesskey

    ed: some need focus too

    jwatt: history back and forward
    ... history is from dom zero

    roc: html5 also has it

    jwatt: moving focus around, html has .focus so we need to add it

    ed; tiny1.2 has methods for managing focus on the SVGSVGElement





    <jwatt> jwatt: .svg version doesn't work for anyone

    shepazu: a11y folks have done some stuff there
    ... we should check back with the a11y folks and be sure we have met
    all their requirements for focus setting

    jwatt: some tests check text is selectable

    <shepazu> [40]http://www.w3.org/TR/UAAG20/

      [40] http://www.w3.org/TR/UAAG20/

    ChrisL: text selection tests on bidi would be ahred to instrument

    jwatt: getSelection





    <shepazu> WAI focus definitions to consider

      [43] http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100823/#glossary


      [44] http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100823/#def-focus

    jwatt: there work in IE svg and in webkit. not in opera or mozilla
    ... at least visually



    roc: that could be done with a reftest,

    ChrisL: its not defined what the text selection looks like, so you
    cant do a reference image but you can do a reftest

    ed: need to test copy paste as well

    jwatt: so far all of this needs no special secirity priveledge

    roc: copy paste would be an issue though

    jwatt: using zoom and pan
    ... can use svgsvgelement currentscale and currenttranslate except
    they are read only

    ed;: no they are not

    jwatt: ok the property is but the value is not
    ... last one is hover tests to check cursor

    roc: even platforms dont have apos to tel you that consistently

    (that one would need to be manual)

    roc: its not even in the framebuffer



    jw: garbageCollect is used for when we crash, like garbage collect
    things we should not have

    <jwatt> jw: it could also be useful for object identity

    heycam: safer to say this only works with command line option, not
    via an add-on for example

    jwatt: so these are sufficient, added some extra stuff that I
    anticipate we will eant later as we add more tests

    roc: we should have a mode that allows css history sniffing instead
    of having this new API
    ... we already have a testing mode

    jwatt: erik can you do that as a mode?

    ed: not sure if we have that at the moment, can find out

    pdengler: we have a lot of assets in this area, tracking down what
    we have
    ... totally get what we are after here, like it

    roc: lots of browser bugs are a change of page state that does not
    propogate correctly
    ... so we need to be able to test these invalidation bugs
    ... we have reftests, page does dynamic stuff, compare to a final
    static page that is the same
    ... browsers tend tocache anf coalesce updates. so we miss some bugs
    ... so we have a reftest which does not complete, when it loads we
    set an event listener for a moz-invalidate event.
    ... browsers renders it and then fires the event once the buffer is
    ... so the script waits for that to make its updates
    ... similar to using a time, but this is much faster
    ... lots of combinations to test. not sure if it makes sense to add
    thse to the svg test suite
    ... do you have mousover tests?

    ChrisL: yes

    jwatt: when is moz-invalidate fired?

    <heycam> mouseover tests where something changes appearance, where
    you want to synthesize the mouse events *after* the initial painting
    has happened

    roc: after the first unsupressed paint of the window
    ... see definition of load event in HTML5
    ... should be impleentable, dont fire if ther eare pending updates


    <ed> scribeNick: ed

DOMActivate deprecation and SVG 2.0

    DS: deprecated bnecause it wasn't used and not implemented correctly
    ... not very useful, leads to more complicated coding
    ... when it was concieved click wasn't accessible at all
    ... like for keyboard enter you didn't get a click
    ... but browsers have since changed
    ... there may be a new activate event coming out of the web events
    WG, as part of a higher level set of events
    ... because of touch events and gestures
    ... we'll have to see

    CM: would this new activate mean the same as the old DOMActivate?

    DS: not really

    CL: order of events wasn't specified and so on

    DS: people want things to work on mobiles and on other devices
    ... svg uses DOMActivate now
    ... talks about activation behavior

    CM: is that distinct from the DOMActivate event?

    DS: yes, links for example can be activated
    ... it's sometimes specific to an element
    ... so activation and DOMActivate are not the same
    ... svg has an 'onactivate' attribute that registers a listener for
    the DOMActivate event
    ... there would be a conflict if we defined it to listen for some
    activation behavior
    ... doesn't impact svg very much

    CM: you're not proposing to drop it from SVG 1.1?

    DS: no

    ED: so could we make SVG 2 'onactivate' listen for e.g click?

    DS: sure, or whatever has the activation behavior
    ... in svg we should talk about activation of links, and the
    different states of elements
    ... svg doesn't have very many activatable elements
    ... animations, links etc

    CM: there are some tests in the testsuite DOMActivate activates a
    ... did we decide to drop that test from the testsuite?



    ED: the test is in the approved category, ie9 and batik passes

    DS: if something has an event handler, should it be activable?
    ... if activate is equivalent to click, is the event handler in
    itself making it activatable?
    ... so if you have a click handler is it activatable?

    ED: yes, that's how tiny12 defines if an element is focusable (which
    is similar to activatable)

    JW: so you've a conviniecne event? so if you had focus and pressed
    enter, you would get the activation behavior?

    DS: yes
    ... making something that looks like a button, in a webapp
    ... in ARIA, role=button, that's a button
    ... an a11y user agent would say that's a button

    ISSUE: define state and activatability for elements in SVG 2

    <trackbot> Created ISSUE-2404 - Define state and activatability for
    elements in SVG 2 ; please complete additional details at
    [48]http://www.w3.org/Graphics/SVG/WG/track/issues/2404/edit .

      [48] http://www.w3.org/Graphics/SVG/WG/track/issues/2404/edit

    JW: forget the word activate for a moment, call it "foo" event
    ... people don't want to have to have separate listeners for
    keyboard events and click events like for a custom button

    CM: the general idea is fine i think

    DS: the old definition of DOMActivate was a bit handwavy
    ... having a foo thing that handles tap, screentouch, and pen tablet
    event and a keyboard event, having a higher level abstraction makes
    sense (because the intent is to activate something)

    CM: we shouldn't make everything activatable, but we should define
    when and how elements are activatable
    ... like tiny12 has done
    ... for the script-handle test, i'd be happy to drop this from the

    ED: yes, i agree

    RESOLUTION: drop script-handle-02-t.svg from the testsuite

    <scribe> ACTION: heycam to drop script-handle-02-t from the SVG
    1.1F2 testsuite [recorded in

    <trackbot> Created ACTION-2977 - Drop script-handle-02-t from the
    SVG 1.1F2 testsuite [on Cameron McCormack - due 2011-03-08].

    <heycam> trackbot, close ACTION-2977

    <trackbot> ACTION-2977 Drop script-handle-02-t from the SVG 1.1F2
    testsuite closed

SVG Parameters

    DS: motivation is that we sometimes want to modify some aspect of an
    existing svg image
    ... e.g chaning the color of something, for reuse, a button in three
    different colors for example
    ... some things are possible to do in css, but not everything
    ... having a way to do this would be useful
    ... (presents the syntax from
    [50]http://www.w3.org/TR/2009/WD-SVGParamPrimer-20090430/ )

      [50] http://www.w3.org/TR/2009/WD-SVGParamPrimer-20090430/

    roc: the object syntax a bad example
    ... don't follow that
    ... it's bad because if you're doing incremental parsing
    ... it can stall on loading the param elements
    ... and we can't show the object before all the param elements are
    ... so we have to hack around this, slows things down
    ... don't recommend doing that
    ... the frameElement works only on same-origin content
    ... the url parameters one, if you use the questionmark syntax, the
    hashtag could work though
    ... in html if you have an iframe with a hashtag link then it will
    scroll to that element
    ... in svg it's overloaded for some things like panning to an

    CM: and xpointer, and view syntax

    DS: if we can find a way to pass them in like this that would be

    <ChrisL> that is hardly overloading. the use of bare fragments to
    mean "move the eleement with this id into view" is the same in html
    and svg

    roc: for css you want the parameters to be first-class css
    ... for transitions you might want params to be transitionable

    DS: i did add a parameters object to give access to the parameters
    passed in

    roc: you could have extra attributes in html to pass in attributes
    as the parameterlist

    CM: we could have something on the object tag for simple access to
    those also
    ... one thing which is good with the querystring syntax
    ... is that it works in existing css

    roc: can you talk about the syntax?
    ... string substitution?

    DS: if one of the things you're trying to parameterize is text...

    roc: so the example is using is reaching into the parent document to
    read out the parameters

    (short break)

    roc: when you're animating you know the type and so on, with
    parameters you don't always know in advance

    DS: if each param had like a shadowtree?

    roc: xbl only allows shadownodes, not shadowattributes
    ... you can inherit attributes
    ... maybe this should be fixed in xbl2

    DS: (continues showing the params primer examples)

    roc: if you allow urls that has some security issues
    ... suppose you hacve an image on good.com
    ... and it takes a parameter that gets used as a url in that image,
    you can make it make a request to evil.com
    ... and fooling the users of good.com

    DS: isn't that a thing for CORS?

    roc: no, not really relevant
    ... it's a bit dangerous to be able to pass in urls

    CM: so we need to be a bit more careful with those cases

    roc: if we typed it then we could e.g restrict it (failing urls
    based on the type)

    DS: it's going to be more work for users to specify the type of the

    roc: how does scoping work?
    ... nevermind


      [51] http://www.w3.org/TR/2009/WD-SVGParam-20090430/#ref-element

    DS: (describes the ref element)

    roc: one idea is to avoid having to have mandatory type, default
    would be string
    ... the strings could be reparsed as whatever you neeeded
    ... if you wanted to you could add the type information, which could
    provide interpolation for example
    ... if you wanted to use this from CSS you'd have to have value-pair
    ... name-value-pairs

    JW: the type infromation should be provided by the resource

    DS: could be both

    roc: don't think you'd want to do that


      [52] http://dev.w3.org/SVG/modules/param/master/SVGParam.html

    JW: roc, you wanted to run the transitions in the top document,
    affecting the resource document?

    roc: yes

    JW: didn't we talked about an api to access the parameters, right?

    DS: yes

    roc: can you have an api that can request arbitraty params, or just
    for the resource document?

    ds: just what's passed in
    ... you still have access to params that aren't used
    ... but it's not typed
    ... by default
    ... it might be useful to do that

    JW: the resource generally knows what the params are for

    ds: you could pass in and even animate something, that's when the
    type information is useful
    ... animating it where it's used

    JW: we need some markup to specify the type

    CM: the types are going to be declared in the resource document

    DS: having the ref thing is useful for this
    ... where do we want to go with this?

    roc: we could have contextual parameterization, differnt for css and
    for html
    ... parameter values change depending on the context, we need to
    define the syntax
    ... agree that the funcationality is useful

    JW: what about dtd entities?

    CM: theyre' not animatable?
    ... true, people have been using entities for paramlike behavior

    roc: it would be hairy, with entity expansion

    DS: has to work at the DOM level, not at the parser level
    ... what are the problems with entities? we'd need to solve the
    ever-expanding entity problem

    CM: probably wouldn't work because html doesn't have internal dtd
    subset like xml does

    jw: what happens with calc?
    ... what happens on the dom side, getcomputedstyle?

    BB: gives the computed value

    JW: element.style.calc?

    roc: gives you the string

    DS: there should be a way to get the value before the computed ...

    JW: there's no specila interface for calc, so you can't get a
    highlevel objkect representing the calc

    CM: for widht and height, how do those get exposed?

    DS: there should be away to get the epxression before the params
    expansion happened

    <scribe> ACTION: jwatt to follow up with roc and to provide feedback
    on the svg params spec [recorded in

    <trackbot> Created ACTION-2978 - Follow up with roc and to provide
    feedback on the svg params spec [on Jonathan Watt - due 2011-03-08].

    <shepazu> [54]http://www.w3.org/Graphics/SVG/WG/wiki/Href

      [54] http://www.w3.org/Graphics/SVG/WG/wiki/Href

Draft with the href resolutions

    ED: what's the plan for this?

    DS: svg2

    AG: yes, svg2, not in svg integration

    DS: this is one of the first things i would like to add to SVG2

    RESOLUTION: in svg2 href will not be in xlink namespace
    ... for the details see

      [55] http://www.w3.org/Graphics/SVG/WG/wiki/Href

    CM: the issues here are they adressed?

    DS: yes, just leading up to the resolution
    ... IE9 has this proposal implemented

    CM: cool

SVG integration

    DS: originally started as a spec for different referencing modes for
    ... for different environments, for use as an icon format etc
    ... then took in a list of all attributes and elements in svg
    ... some are things that the svg spec should talk about
    ... on thursday i want to outline the set of issues for svg


      [56] http://www.w3.org/Graphics/SVG/WG/wiki/Features/SVG-as-image

    JW: started this page with some thoughts on svg-in-img
    ... relates to the svg integration spec

    <jwatt> s/on svg-in-img/the specific case of svg-in-img/

    DS: svg integration doesn't make any requirements, like for what's
    allowed in svg for a specific scenario
    ... that's up to the referencing spec, e.g CSS or for SVG2


      [57] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

    JW: the svg integration doesn't list all things in

      [58] http://www.w3.org/Graphics/SVG/WG/wiki/Features/SVG-as-image

    CL: have you heard of from-origin?
    ... got brought up in the context of fonts

    DS: like a declarative variant of CORS

    DH: for some scenarios, you want to enforce restrictions, like for
    allowing people to upload svg avatars to a server
    ... we're interested in protecting those use-cases with the
    same-domain restriction

    DS: scenario 1: A.com and B.com
    ... can A.com pull in content from B.com?
    ... are there scenarios where we don't want both parties to opt in?
    ... i could have a whitelist for what domains can hotlink content

    DH: tracking external resources, like you could track users using
    content from your site
    ... like pingbacks
    ... download of stylesheet or image
    ... plenty of sites allow usercontrolled images

    <ChrisL> from-origin

      [59] http://annevankesteren.nl/2011/02/from-origin

    CM: so in firefox all external resources are is restricted in the
    cases of svg-in-img and svg used from css

    DS: issues: hotlinking, security, user tracking
    ... what is the problem with fetching security files, whitelists?
    ... why don't browsers do that?

    JW: we have the headers that do that

    DS: i'm talking about a file

    DH: disabling external resources in svg-in-img would default to
    being secure

    DS: so if the file for this file was found it could use it,
    otherwise could allow external references

    CM: know that flash has this thing for crossdomain access

    DS: it's only one side of this

    CM: this seems to allow sharing content between sites, but not for
    arbitrary users

    DS: you could have an "everyone can use this"

    JW: i like blacklists

    DS: you could have both whitelists and blacklists

    DH: where would this all be defined?

    DS: we could start with defining the security model of the use

    CM: so firefox supports use with external content, but with
    same-origin restrictions

    <scribe> ACTION: DS to write a proposal for external reference
    restrictions, with whitelists and blacklists [recorded in

    <trackbot> Created ACTION-2979 - Write a proposal for external
    reference restrictions, with whitelists and blacklists [on Doug
    Schepers - due 2011-03-08].

    CM: it might be bad to require fetching of the well-known uri's

    JW: could be done as part of fetching the svg perhaps

    BB: event-based timing for svg-in-img
    ... for using animations triggered by events, firefox doesn't allow
    that now for svg-in-img

    JW: img tags are single units, events don't go into them, there're
    atomic, ui events don't go into them
    ... so the svg-in-img never sees the ui events there

    ED: so the only event that might be useful is repeatEvent, but it
    might also be a win for performance to just not handle eventbase in
    svg-in-img at all

    BB: yes, it would be easier and probably better for performance

    DS: so we have img, and iframe and object
    ... which are the things that we might want to restrict for
    different scenarios
    ... we need another mode that dont allow script but allows ui events

    BB: are there examples, e.g what's expected for external banner ads

    DS: would be good to explain what the modes are useful for

    DH: so how do author for that?

    CL: the spec that wants a particular mode needs to make those
    restrictions, svg integration doesn't require that

    DS: i think for iframe a noscript attribute would be useful

    CM: isn't there something like that in html5?

    ED: the sandbox attribute maybe

    DS: the referenceing mode for iframe with noscript would be this new
    refernceing mode

    JW: probably just animated mode, with some restrictions
    ... the mode to restrict "can-have-external-references" would be
    useful, to allow the avatar usecase
    ... it's a handy thing, because it would make svg's similar to
    rasters that don't have external referecnes

    DS: having referenceing modes for html would also be useful
    ... want the textcontent and content of an iframe, but i don't want
    it to execute any scripts

    iframe-element.html#attr-iframe-sandbox -- the "sandbox" attribute


    <scribe> ACTION: DS to add examples to each referencing mode in svg
    integration [recorded in

    <trackbot> Created ACTION-2980 - Add examples to each referencing
    mode in svg integration [on Doug Schepers - due 2011-03-08].

    <scribe> ACTION: DS to add another referencing mode for the banner
    ad use-case, noscript but with interactivity [recorded in

    <trackbot> Created ACTION-2981 - Add another referencing mode for
    the banner ad use-case, noscript but with interactivity [on Doug
    Schepers - due 2011-03-08].

    DS: would it be better to say "specifications" instead of "host

    JW: doesn't need to be restricted to svg even, could be useful for
    other resources too

    DS: what other things are missing from svg integration?
    ... tav raised some points in his button examples
    ... write something down about seamless murrmurrrumm?

    CM: so the seamless attribute, the author is in control
    ... can disallow scripts etc

    ED: doesn't seamless introduce some security issues, with inheriting
    style into the referenced content, similar to what was raised as a
    concern for the svg parameters spec?

    trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: DS to add another referencing mode for the banner ad
    use-case, noscript but with interactivity [recorded in
    [NEW] ACTION: DS to add examples to each referencing mode in svg
    integration [recorded in
    [NEW] ACTION: DS to write a proposal for external reference
    restrictions, with whitelists and blacklists [recorded in
    [NEW] ACTION: heycam to drop script-handle-02-t from the SVG 1.1F2
    testsuite [recorded in
    [NEW] ACTION: jwatt to follow up with roc and to provide feedback on
    the svg params spec [recorded in
    [NEW] ACTION: shepazu to draw up a spec around simple dom core api
    [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [70]scribe.perl version 1.135
     ([71]CVS log)
     $Date: 2011/03/01 04:49:33 $

      [70] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [71] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [72]http://dev.w3.org/cvsweb/~checkout~/2002

      [72] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/CSS Animations/CSS transforms 2d and 3d/
Succeeded: s/patrick/Microsoft/
Succeeded: s/command/command e.g. transform="... next-origin(...) rotat
e(...) next-origin(...) scale(...) ..."/
Succeeded: s/tocss/to css/
Succeeded: s/css matrixc interface/cssmatrix and svgmatrix interfaces/
Succeeded: s/drop/loose info on/
Succeeded: s/afterwards/after the entire list of transform items/
Succeeded: s/right /right-/
Succeeded: s/t align/to align/
Succeeded: s/lve/live/
Succeeded: s/wored/worked/
Succeeded: s/dome resolutions/some resolutions/
Succeeded: s/? justassign a/do that, I'd rather just assign the/
Succeeded: s/ nd/ and/
Succeeded: s/not/the ! operator/
Succeeded: s/(lunch)/(hunger)/
Succeeded: s/tiny1.2 has that/tiny1.2 has methods for managing focus on
  the SVGSVGElement interface/
Succeeded: s/this is/garbageCollect is/
Succeeded: s/heycam/jwatt/
Succeeded: s/you would need a/we should have a/
Succeeded: s/css history sniffing/css history sniffing instead of havin
g this new API/
Succeeded: s/sae/same/
FAILED: s/on svg-in-img/the specific case of svg-in-img/
Found ScribeNick: ChrisL
Found ScribeNick: ed
Inferring Scribes: ChrisL, ed
Scribes: ChrisL, ed
ScribeNicks: ChrisL, ed

WARNING: Replacing list of attendees.
Old list: +1.649.363.aaaa tbah [Microsoft]
New list: +1.649.363.aaaa +1.425.868.aabb

Default Present: +1.649.363.aaaa, +1.425.868.aabb
Present: Heycam Shepazu DHolbert Birtles Jun Chris Anthony JWatt Erik R
oc Patrick Tbah
Found Date: 28 Feb 2011
Guessing minutes URL: [73]http://www.w3.org/2011/02/28-svg-minutes.html
People with action items: ds heycam jwatt shepazu

      [73] http://www.w3.org/2011/02/28-svg-minutes.html

    End of [74]scribe.perl diagnostic output]

      [74] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Tuesday, 1 March 2011 04:50:41 UTC