- From: Erik Dahlstrom <ed@opera.com>
- Date: Tue, 01 Mar 2011 17:49:56 +1300
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes from day 2 of the Auckland F2F:
http://www.w3.org/2011/02/28-svg-minutes.html
and as text below:
[1]W3C
[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
Attendees
Present
Heycam, Shepazu, DHolbert, Birtles, Jun, Chris, Anthony,
JWatt, Erik, Roc, Patrick, Tbah
Regrets
Chair
Erik, Heycam
Scribe
ChrisL, ed
Contents
* [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
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> [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
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>
[17]http://dev.w3.org/csswg/css3-2d-transforms/#transform-origin-pro
perty
[17]
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
[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>
[19]http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTrans
forms.html
[19]
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
[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
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> [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
[25]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#.22tear_off.22_
issues
[25]
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
[26]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Performance_iss
ues
[26]
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> [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
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
[28]http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API#insertAtIn
dex
[28]
http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API#insertAtIndex
heycam: thats a really simple improvement
shepazu: also create with initialise
[29]http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API#createChil
d
[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
[31]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
[32]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Array_getters_a
nd_setters
[32]
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
[33]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Global_ECMAScri
pt_constructors
[33]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Global_ECMAScript_constructors
ed: really handy
birtles: yes
[34]http://www.w3.org/Graphics/SVG/WG/wiki/Global_ECMAScript_Constru
ctors
[34]
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> [35]http://www.w3.org/Graphics/SVG/WG/track/issues/2323
[35] http://www.w3.org/Graphics/SVG/WG/track/issues/2323
<ed>
[36]http://www.w3.org/Graphics/SVG/WG/wiki/Global_ECMAScript_Constru
ctors
[36]
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[$1\47] = 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:
[37]http://www.w3.org/Graphics/SVG/WG/wiki/Global_ECMAScript_Constru
ctors
[37]
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>
[38]http://svgwg.jwatt.org/tests/interactive/focus-using-element.foc
us.html
[38]
http://svgwg.jwatt.org/tests/interactive/focus-using-element.focus.html
<jwatt>
[39]http://svgwg.jwatt.org/tests/interactive/focus-using-element.foc
us.svg
[39]
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> [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
<jwatt>
[41]http://svgwg.jwatt.org/tests/interactive/selection-using-getSele
ction.html
[41]
http://svgwg.jwatt.org/tests/interactive/selection-using-getSelection.html
<jwatt>
[42]http://svgwg.jwatt.org/tests/interactive/selection-using-getSele
ction.svg
[42]
http://svgwg.jwatt.org/tests/interactive/selection-using-getSelection.svg
<shepazu> WAI focus definitions to consider
[43]http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100823/#glossary
[43] http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100823/#glossary
<shepazu>
[44]http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100823/#def-focus
[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
<ed>
[45]http://www.w3.org/TR/SVG11/text.html#__svg__SVGTextContentElemen
t__selectSubString
[45]
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>
[46]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Automated_testi
ng_support_API
[46]
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>
[47]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
/script-handle-02-b.html
[47]
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
[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
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
[49]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
[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
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>
[51]http://www.w3.org/TR/2009/WD-SVGParam-20090430/#ref-element
[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
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>
[52]http://dev.w3.org/SVG/modules/param/master/SVGParam.html
[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
[53]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> [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
[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
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>
[56]http://www.w3.org/Graphics/SVG/WG/wiki/Features/SVG-as-image
[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
<dholbert>
[57]http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
[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
[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
[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
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
[60]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>
[61]http://www.whatwg.org/specs/web-apps/current-work/multipage/the-
iframe-element.html#attr-iframe-sandbox -- the "sandbox" attribute
[61]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox
<scribe> ACTION: DS to add examples to each referencing mode in svg
integration [recorded in
[62]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
[63]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
Summary of Action Items
[NEW] ACTION: DS to add another referencing mode for the banner ad
use-case, noscript but with interactivity [recorded in
[64]http://www.w3.org/2011/02/28-svg-minutes.html#action06]
[NEW] ACTION: DS to add examples to each referencing mode in svg
integration [recorded in
[65]http://www.w3.org/2011/02/28-svg-minutes.html#action05]
[NEW] ACTION: DS to write a proposal for external reference
restrictions, with whitelists and blacklists [recorded in
[66]http://www.w3.org/2011/02/28-svg-minutes.html#action04]
[NEW] ACTION: heycam to drop script-handle-02-t from the SVG 1.1F2
testsuite [recorded in
[67]http://www.w3.org/2011/02/28-svg-minutes.html#action02]
[NEW] ACTION: jwatt to follow up with roc and to provide feedback on
the svg params spec [recorded in
[68]http://www.w3.org/2011/02/28-svg-minutes.html#action03]
[NEW] ACTION: shepazu to draw up a spec around simple dom core api
[recorded in
[69]http://www.w3.org/2011/02/28-svg-minutes.html#action01]
[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
/scribe/
[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:51:44 UTC