SVG Working Group Teleconference -- 28 Feb 2011

<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 allows
... 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> 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> http://www.w3.org/2010/03/11-fx-minutes.html#item02 (there are some resolutions there to align the syntax)

anthon_nz: another action on transitions, moved to css transitions spec

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

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 affected.

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

<heycam> http://dev.w3.org/csswg/css3-2d-transforms/#transform-origin-property

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 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> http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html

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 centre

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

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 items

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?

(break)

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

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

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

svg2 dom

ed: lets fgo through the list

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

tear off http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#.22tear_off.22_issues

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

http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#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 objects

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> http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API

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

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

shepazu: also propose an insertAtIndex

http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API#insertAtIndex

heycam: thats a really simple improvement

shepazu: also create with initialise

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> 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 http://www.w3.org/2011/02/28-svg-minutes.html#action01]

<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

http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Array_getters_and_setters

ed: array lengths
... and indexing

jwatt: nice one

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

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

http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Global_ECMAScript_constructors

ed: really handy

birtles: yes

http://www.w3.org/Graphics/SVG/WG/wiki/Global_ECMAScript_Constructors

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

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

<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

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

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Global_ECMAScript_Constructors

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[2] = new SVGLength("2em")

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

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

newImage

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

RESOLUTION: We will draft on global constructors for selected dom objects

ACTION heycam to draft on global constructors for selected dom objects

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

action-2976: http://www.w3.org/Graphics/SVG/WG/wiki/Global_ECMAScript_Constructors

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

(hunger)

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 interface

<jwatt> http://svgwg.jwatt.org/tests/interactive/focus-using-element.focus.html

<jwatt> http://svgwg.jwatt.org/tests/interactive/focus-using-element.focus.svg

<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> http://www.w3.org/TR/UAAG20/

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

jwatt: getSelection

<jwatt> http://svgwg.jwatt.org/tests/interactive/selection-using-getSelection.html

<jwatt> http://svgwg.jwatt.org/tests/interactive/selection-using-getSelection.svg

<shepazu> WAI focus definitions to consider http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100823/#glossary

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

<ed> http://www.w3.org/TR/SVG11/text.html#__svg__SVGTextContentElement__selectSubString

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

<jwatt> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Automated_testing_support_API

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 complete
... 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

(lunch)

<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 circle
... did we decide to drop that test from the testsuite?

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini/script-handle-02-b.html

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

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 http://www.w3.org/2011/02/28-svg-minutes.html#action02]

<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 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 parsed
... 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 element

CM: and xpointer, and view syntax

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

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

roc: how does scoping work?
... nevermind

<shepazu> 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 syntax
... 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

<shepazu> 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 http://www.w3.org/2011/02/28-svg-minutes.html#action03]

<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> 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 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 svg
... 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 integration

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

<dholbert> http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

JW: the svg integration doesn't list all things in 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 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 element

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 http://www.w3.org/2011/02/28-svg-minutes.html#action04]

<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

<heycam> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox -- the "sandbox" attribute

<scribe> ACTION: DS to add examples to each referencing mode in svg integration [recorded in http://www.w3.org/2011/02/28-svg-minutes.html#action05]

<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 http://www.w3.org/2011/02/28-svg-minutes.html#action06]

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

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

- DRAFT -

SVG Working Group Teleconference

28 Feb 2011

Attendees

Contents