See also: IRC log
<trackbot> Date: 28 February 2011
<heycam> tbah, you can call in now with code 26633
<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?
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
... 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
... 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?
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
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 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
... dont much like trandform origin
... ac currently written its an overall wrap on the series
roc: we are kinda locjed into it
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
... 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: lets fgo through the list
ChrisL: so this is about live vs snapshot copy?
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
ed: so is thys a terse syntax
... 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
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: 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
removing that multi call performance overhead
... 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
ed: this belongs in dom core
shepazu: thatwas my
... also some things specific tosvg, in addition
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,
... 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)
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?
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].
ed: really handy
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
<trackbot> ISSUE-2323 -- Consider aligning SVG*List interfaces with other arraylike types -- raised
jwatt: concerned about relationof
constructors to HTML
... can we do better?
heycam: otoh this is a small and
... combination of array indexes and constructors works well
<heycam> mySVGLengthList = 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
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].
<trackbot> ACTION-2976 Draft on global constructors for selected dom objects notes added
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
... 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> 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
ChrisL: text selection tests on bidi would be ahred to instrument
<shepazu> WAI focus definitions to consider http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100823/#glossary
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
... 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?
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
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
... 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?
ED: so could we make SVG 2 'onactivate' listen for e.g click?
DS: sure, or whatever has the
... 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?
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?
... 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
... 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
DS: motivation is that we
sometimes want to modify some aspect of an existing svg
... 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
... 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
... 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
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,
... 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
... 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?
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
JW: the type infromation should be provided by the resource
DS: could be both
roc: don't think you'd want to do that
JW: roc, you wanted to run the transitions in the top document, affecting the resource document?
JW: didn't we talked about an api to access the parameters, right?
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
... 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
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].
ED: what's the plan for this?
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
... IE9 has this proposal implemented
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
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
... that's up to the referencing spec, e.g CSS or for SVG2
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
... 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
... 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,
... 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
... 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
... 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
... 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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at 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(...) rotate(...) 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 having 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 Roc Patrick Tbah Found Date: 28 Feb 2011 Guessing minutes URL: http://www.w3.org/2011/02/28-svg-minutes.html People with action items: ds heycam jwatt shepazu[End of scribe.perl diagnostic output]