W3C home > Mailing lists > Public > www-svg@w3.org > March 2011

minutes, SVG WG Auckland F2F, day 5

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 4 Mar 2011 17:19:27 +1300
To: public-svg-wg@w3.org
Message-ID: <20110304041927.GA22898@wok.mcc.id.au>
http://www.w3.org/2011/03/03-svg-minutes.html

   [1]W3C

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

                               - DRAFT -

                   SVG Working Group Teleconference

03 Mar 2011

   See also: [2]IRC log

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

Attendees

   Present
          +1.649.363.aaaa

   Regrets
   Chair
          Cameron

   Scribe
          Anthony, Cameron

Contents

     * [3]Topics
         1. [4]CSS 3D Object Position
         2. [5]Accessibility
         3. [6]z-index
         4. [7]Text over-flow
         5. [8]Next F2F
         6. [9]buffered-rendering
         7. [10]Connectors
         8. [11]SVG Integration
         9. [12]pointer-events processing and security
        10. [13]rechartering
     * [14]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 03 March 2011

   <tbah> OK, thanks.

   <anthony_nz> Scribe: Anthony

   <anthony_nz> ScribeNick: anthony_nz

CSS 3D Object Position

   ED: Ties into the discussion yesterday about images and aspect ratio
   ... CSS 3 has the new object fit properties
   ... they effect how images are hard positioned and extended in the
   image tag
   ... it offers more than preserveAspectRatio in SVG
   ... because you can position the image inside where ever you want
   ... use Calc even
   ... not sure how this will effect the decisions made yesterday
   ... it will definitely effect the case for img

   DH: In SVG there is the override for perserveAspectRatio if object
   fit is specified

   <ed> [15]http://testsuites.opera.com/object-fit/README

     [15] http://testsuites.opera.com/object-fit/README

   ED: This is what Opera is doing at the moment
   ... this is how we've implemented it so far
   ... There are two things here
   ... do we want to have object fit and object position in SVG
   ... and perhaps get rid of preserveAspectRatio

   CM: Not sure about getting rid of
   ... I mean we should have the properties apply to where
   preserveAspectRatio applies

   ED: Positioning inside a viewport is nice
   ... for other things it's mostly the same
   ... the difference being it's a property and not an attribute

   DS: Does it solve all the same cases that preserveAspectRatio solves
   or are there still uses for preserveAspectRatio?

   CM: How you can specify preserveAspectRatio defer for an external
   document

   ED: In most cases I think it is more useful to have it as a property
   and not an attribute

   DS: That would let us deprecate an attribute that is not very well
   understood and not often used

   AG: defer is not defined very well

   ED: Yes, and I've hardly seen anyone use it

   DS: So we can do everything with image-fit
   ... except for defer behaviour in preserveAspectRatio

   CM: We could ask the CSS Working Group if they could add this
   functionality into object-fit properties

   <ed> [16]http://dev.w3.org/csswg/css3-images/#object-fit

     [16] http://dev.w3.org/csswg/css3-images/#object-fit

   ED: For the image element in HTML it will have an effect because the
   default value for object-fit will be "fill"
   ... That means it will fill the entire element
   ... That is the same as preserveAspectRatio "none"
   ... I don't think that is a change from the tests we did yesterday

   CM: That's not the default behaviour of preserveAspectRatio

   ED: If you have an HTML img element and you reference an image with
   preserveAspectRatio set
   ... it's not clear what happens
   ... I think that object-fit should override

   CM: In your proposal it seems like you want to add a new value
   "auto" to preserveAspectRatio

   JW: In CSS you don't have the knowledge that value is specified. The
   user should have to actively do something to say that the preserve
   aspect ratio is kept
   ... by using defer
   ... Without doing anything and saying that this overrides
   ... All reference SVG content will have their preserve aspect ratio
   will be overridden

   CM: You want existing content that doesn't have preserveAspectRatio
   defined to render the same as if "none" is specified

   JW: Seems to me we might need a value of "auto

   DH: We might have to insert something to say override object-fit

   DS: There are circumstances that an author would want to change the
   original document

   <ed> [17]http://testsuites.opera.com/object-fit/

     [17] http://testsuites.opera.com/object-fit/

   DS: It would be nice to override what the document thinks the
   display is

   CM: Even without SVG this object fit could effect how raster images
   are sized

   DH: Raster images don't react to their viewport where as SVG does

   JW: Having object-fit work on the SVG element the interaction there
   are even more complicated
   ... because you have an actual value and it is unclear when it would
   override
   ... which is why you'd want an "auto" value

   CM: I agree, I think we need an "auto" value

   ED: The argument that was made was you can set different defaults
   depending on the context it was used
   ... for the Video element it has one default value, where as the
   default is different for SVG

   JW: It still doesn't solve the problem that I want to defer

   DS: So "auto" would be "defer" or "fill"

   CM: "auto" would mean just do whatever do what preserveAspecrRatio
   means in SVG currently

   DH: I'd like to have "auto" be like "fill" or preserveAspectRatio
   "none"

   <ed> [18]http://testsuites.opera.com/object-fit/

     [18] http://testsuites.opera.com/object-fit/

   ED: Here is the link to the test suite which has object-fit with SVG
   and some other test cases; Video, etc
   ... if you have feedback on this, I'd be happy to hear about it

   CM: Does that mean that "auto" should be proposed?

   ED: If we think "auto" is useful we should go back to the CSS
   Working Group with that
   ... The other issue I want to see resolved is to have the support
   for object-fit in SVG 2

   JW: I still find some of these values not intuitively obvious about
   that they do

   CM: Do we need to talk to them about "none" - was it dropped?

   ED: It says it is controversial
   ... would need a good argument about why it is needed

   ROC: I'm a bit worried about it because image sizing is already
   complicated as it is. It is easy to see how to use it for raster
   images
   ... but once you apply it to SVG images it starts getting
   complicated

   ED: I'd say it's easier to use than preserveAspectRatio

   ROC: If it's just an override it's not so bad

   RESOLUTION: SVG 2 will require object-fit and object-position

   <scribe> ACTION: JWatt to Gather up issues regarding object-fit and
   it's applied to SVG and email CSS Working Group [recorded in
   [19]http://www.w3.org/2011/03/03-svg-minutes.html#action01]

   <trackbot> Created ACTION-3001 - Gather up issues regarding
   object-fit and it's applied to SVG and email CSS Working Group [on
   Jonathan Watt - due 2011-03-10].

   <heycam> roc,
   [20]http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_
   matrix.svg

     [20] http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.svg

Accessibility

   DS: SVG should be accessible but is not accessible
   ... problems are inconsistency between implementations and the lack
   of normative behaviour of content
   ... There are different kind of accessibility needs
   ... [Goes through presentation]
   ... my proposal is that we undertake to have an SVG Accessibility
   document that talks about how SVG can be authored
   ... for accessibility
   ... We wouldn't be starting from scratch we will be engaging people
   that already have knowledge and are already working in the field
   ... There is an Australian thing call NVDA who would be interested
   in working with us

   CM: NVDA is open source

   DS: It was installed on every library in New Zealand

   CM: Do you see us collaborating with the accessibility groups on
   this

   DS: We'd talk with the people doing ARIA
   ... I think we should start a different mailing list for SVG
   accessibility

   AD: If a lot of CAD drawings and other schematics go to SVG
   ... they're going to need to be accessible

   ROC: SVG is not semantic and HTML has that same problem with Canvas

   DS: SVG is semantic in the sense withing the realm of mathematics.
   Outside that it's not.

   CM: We should take the top 10 types of graphics - information
   graphics
   ... and define ARIA roles for them
   ... Also include guidelines to say when doing a certain type of
   document uses certain roles and don't do certain things

   DS: It would be good to define how to make accessible graphics

   CM: What sort of things?

   DS: Colour choices
   ... I feel making a general accessibility document would be good.
   Perhaps the first thing to do is make one for SVG
   ... then extract that out
   ... I've seen cases where different tones were played for the a bar
   chart to indicate the overall trend in the graph

   CM: Sonification

   RESOLUTION: We will start an accessibility document for SVG

   AG: So you'll be the editor Doug?

   DS: Yes, I can be one of the editors. I would like to bring in other
   people who know the field more deeply

   CM: I would like to get in the expertise

z-index

   AD: Your proposal solves some of the problems
   ... if you do enable-background="new" what do with the z-index
   ... the concept of the stacking context solves this problem

   <jwatt> [21]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/z-index

     [21] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/z-index

   AD: main problem is how it would fit in the rendering model
   ... If you introduce a stacking context when a z-index is specified
   ... it solves the problem just fine

   ED: I haven't read all of the details
   ... I think it makes sense to add z-index support rather than
   layered-g

   AD: If you don't specify z-index then your performance impact is
   nothing really. Only if you specify z-index you need to walk the
   tree twice which isn't too bad

   DS: It's better from an authoring perspective

   AD: I wouldn't bother putting any note in until it's shown to be a
   problem
   ... or a performance hit
   ... but I wouldn't expect there to be a performance hit

   DS: This is an SVG 2 thing right?

   JW: Yes

   CM: If there are technical details we can work them out when we are
   writing up SVG 2

   RESOLUTION: We will add Jonathan Watt's z-index proposal to SVG 2

   JW: From what I remember CSS talks about how to deal with the
   background
   ... and we're not going to get stroke and fill on different levels

   CM: The syntax of the property is just the same as CSS?

   JW: Yes
   ... same definition, but with simplified instructions of how it
   works

   <scribe> ACTION: JWatt to Add z-index proposal to SVG 2 [recorded in
   [22]http://www.w3.org/2011/03/03-svg-minutes.html#action02]

   <trackbot> Created ACTION-3002 - Add z-index proposal to SVG 2 [on
   Jonathan Watt - due 2011-03-10].

   DS: Would be good to have a diagram showing the layers
   ... for example showing a document without z-index and then a
   document with z-index
   ... this would be good for authors to illustrate how the layers work
   in the document

   JW: applying a filter to an element cause it to create a new
   stacking context

Text over-flow

   <ed>
   [23]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Text-ov
   erflow

     [23] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Text-overflow

   ED: Some proposed wording for text-overflow in SVG
   ... It's basically saying if my text is too long clip it or flow it
   ... This property is defined in CSS 3
   ... It's not defined there for SVG
   ... but it is something we could apply to SVG elements
   ... My proposal is to add to SVG text element and SVG textArea (in
   Tiny 1.2)

   ROC: It wouldn't take effect if you just had a clipping thing that
   contains text
   ... If it doesn't have a width it doesn't do anything
   ... HTML 5 Canvas Text has something useful
   ... What they do is they say here's the text and here's the width.
   If it's too big shrink the width
   ... and increase the height

   ED: You can already do that with textLength attribute
   ... This is different
   ... one of the differences is this is for blocks of text

   CM: What would happen with tspans and absolute position of glyphs

   ED: Good question
   ... this proposal doesn't solve all of the issues
   ... I have at least 10 that I could think of
   ... So we would need to solve these
   ... I don't have any strong opinion on how we solve these

   CM: With the CSS one what happens when you get selection range?

   ROC: Do you talk about the placement of the glyphs with BiDi

   ED: Yes, I did
   ... same as CSS

   ROC: I'm not so happy with the behaviour, but it is the same between
   the two
   ... CSS and SVG

   ED: In order to get the ellipsis you need to specify overflow

   CM: I still think that SVG does need some sort of layout things in
   it
   ... SVG as it is don't need to worry about overflow property

   ED: I think the ellipsis thing is the one thing people want

   AD: There is high demand for it in the IPTV world

   ED: textArea might be a bit simpler because it already has width and
   height

   AD: It's really ugly to do this in script

   CM: You can imagine all different types of ways squashing the text
   in
   ... I would like to see font size adjustment to fit things

   ED: That would be more a textLength thing

   CM: What happens when you have both textLenght specified and width?

   ED: If the textLength is longer than the width you'd get ellipsis I
   guess

   CM: I was thinking the other way
   ... to ellipsis replacement first
   ... so you'll never get overflowing text using textLength?

   ED: No, it will just squash it up

   CM: In CSS what happens with styling of the ellipsis?

   ROC: In CSS it's either you use the style of the block which
   declares the overflow but it may have changed

   CM: It seems like you want to do closest common ancestor
   ... but we don't need to solve these issues now

   ED: I'd like to see if this can be place in SVG 2

   AD: In textArea it should wrap so you don't show an ellipsis. But
   we've had feedback from editors that it is really ugly
   ... they want a character by character horizontal scroll
   ... For the simple case where you have a login box which just does a
   character by character scroll we never did that
   ... We had to word wrap it and they had to live with it
   ... It really restricts the textArea as an editable control

   CM: Why not have the functionality on text?

   AD: textArea was suppose to be flow container
   ... that allowed glyphs etc.
   ... The whole chapter is defined
   ... we defined all the algorithms for it
   ... and it was reviewed by the experts in Indesign and they liked
   the model

   DS: This is something that a lot of people want solved

   AD: I'm strongly in favour of text-overflow

   RESOLUTION: We will add text-overflow in SVG 2

   <scribe> ACTION: Erik to Add text-overflow in SVG 2 [recorded in
   [24]http://www.w3.org/2011/03/03-svg-minutes.html#action03]

   <trackbot> Created ACTION-3003 - Add text-overflow in SVG 2 [on Erik
   Dahlström - due 2011-03-10].

   CM: The whitespace property, does that have any effect on us?

   ED: No

   CM: Can we move away from using XML whitespace and use the
   whitespace property?

   ED: That would be nice

   DS: How about we say that XML space doesn't do what it did in SVG
   1.1

   ROC: So drop support for xml:space?
   ... how much content will break?

   CL: None

   ROC: Can we remove it from the test suite?

   RESOLUTION: We drop xml:space from SVG 2 and remove the relating
   tests from the SVG 1.1. test suite

   ROC: Should warn authors that in SVG 1.1 that this is being
   deprecated

   <scribe> ACTION: Chris to Remove the tests from the SVG 1.1 tests
   suite that relate to xml:space [recorded in
   [25]http://www.w3.org/2011/03/03-svg-minutes.html#action04]

   <trackbot> Created ACTION-3004 - Remove the tests from the SVG 1.1
   tests suite that relate to xml:space [on Chris Lilley - due
   2011-03-10].

   <scribe> ACTION: JWatt to Draft a proposal to use CSS whitespace in
   SVG 2 [recorded in
   [26]http://www.w3.org/2011/03/03-svg-minutes.html#action05]

   <trackbot> Created ACTION-3005 - Draft a proposal to use CSS
   whitespace in SVG 2 [on Jonathan Watt - due 2011-03-10].

   <pdengler> I haven't seen any activity here, are you still out to
   dinner

   <roc> we just got back --- from lunch

   <heycam> Scribe: Cameron

   <heycam> ScribeNick: heycam

Next F2F

   <roc> I booked nine single-person kayaks, the tide is in the morning
   so we need to be there at 9:30am :
   [27]http://www.puhoirivercanoes.co.nz/puhoi_river_kayak_trips.htm

     [27] http://www.puhoirivercanoes.co.nz/puhoi_river_kayak_trips.htm

   <roc> I told them it might only be eight people in the end

   [28]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Next_F2
   F

     [28] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Next_F2F

   CM: jun mailed the list about meeting at the same time/place as
   csswg in tokyo, in june
   ... I think we should meet then

   AG: google offered meeting space just on the same dates as the csswg
   meeting
   ... for the remaining days, canon or kddi can host

   DS: maybe some csswg people can stay on for extra days to have
   meetings with us, rather than eat into their meeting time

   <scribe> ACTION: Chris to tell CSSWG that we want to meet them! In
   Tokyo in June. [recorded in
   [29]http://www.w3.org/2011/03/03-svg-minutes.html#action06]

   <trackbot> Created ACTION-3006 - Tell CSSWG that we want to meet
   them! In Tokyo in June. [on Chris Lilley - due 2011-03-11].

   DS: we have colocated in the past with LGM

   CL: which is in montreal this year

   DS: with SVG Open, which is in Boston

   CL: SVG Open is late this year, and in Boston.
   ... two weeks later is TPAC

   AG: there's one week gap between them

   DS: I think the Thursday is the workshop, for SVG Open

   CL: maybe we could have part of the F2F before SVG Open, then part
   of it on Thursday/Friday after
   ... so we can concentrate on feedback we get from SVG Open

   DS: one other thing with SVG Open, is that W3C is thinking about
   having a night, like in Paris
   ... where there'll be some presentations on teaching SVG, showcasing
   it, to the general public
   ... so that's probably going to happen the evening before SVG Open
   ... I imagine either MS or W3C would be able to provide meeting
   space there
   ... while LGM is a good opportunity to touch place with the open
   source community, and is fun, I'm not sure is as critical as SVG
   Open
   ... how many meetings are we planning on having?

   CL: we are meant to attend TPAC
   ... wht aabout Thursday Friday in Boston, after SVG Open
   ... then 2 days at TPAC

   [discussion about Tokyo meeting days]

   CL: we could meet on Fri June 3 with CSS WG, take the weekend off,
   then have our normal 5 day meeting on the following week

   <scribe> ACTION: Anthony to coordinate with Fujisawa-san to organise
   hosting for Tokyo SVG F2F [recorded in
   [30]http://www.w3.org/2011/03/03-svg-minutes.html#action07]

   <trackbot> Created ACTION-3007 - Coordinate with Fujisawa-san to
   organise hosting for Tokyo SVG F2F [on Anthony Grasso - due
   2011-03-11].

   AG: how about the late year F2F?

   CL: go to SVG Open, Mon-Wed, do Thurs-Fri SVG WG meeting
   ... then the week in between is free
   ... following week is TPAC

   AG: I probably can't make the final Friday of the Tokyo F2F

   DS: let's just make it Mon-Thurs on that week then

   <scribe> ACTION: Chris to liaise with MS for the F2F meeting around
   SVG Open [recorded in
   [31]http://www.w3.org/2011/03/03-svg-minutes.html#action08]

   <trackbot> Created ACTION-3008 - Liaise with MS for the F2F meeting
   around SVG Open [on Chris Lilley - due 2011-03-11].

   <pdengler> Could we consider the week of the 26th for the Face to
   Face in ENgland?

   <shepazu> pdengler: we are planning to have 2 days after SVG Open,
   then the next 2 days at TPAC a week later

   <shepazu> could microsoft host the F2F after SVG Open?

   <shepazu> pdengler: the problem is, we really need to meet at TPAC

buffered-rendering

   <jwatt>
   [32]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/User_controlled
   _caching_of_rendering

     [32] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/User_controlled_caching_of_rendering

   JW: we discussed this a bit, roc alex and myself
   ... everyone decided that some sort of user control of off screen
   caching would just end up being misused, or used improperly
   ... and we'd need to disable it or not recognise it anyway
   ... implementations can generally detect when things are moved
   around in a way that would benefit from caching
   ... so caching would be automatic

   <pdengler> I will look into hosting the f2f yes,

   JW: one thing that will be an issue is animations, where the start
   of the animation is immediate and smooth
   ... that's always going to be a problem with an automatic caching
   mechanism that detects motion and decides to cache
   ... if you do some gesture on a webpage that should animate things
   on the screen quickly, you want it to react immediately
   ... the whole purpose of using offscreen caching is beause you need
   responsiveness
   ... but you might have a couple of frames where it's sluggish
   ... we used it in a previous job, but in that situation we were able
   to correct misuses of buffered-rendering because this was a closed
   system
   ... in general I think user control of offscreen caching we
   shouldn't do, at this stage

   DH: sounds like your situation where it would be slow initially, on
   animation start, since it's declarative animation you could detect
   this

   JW: sometimes, but if your begin is something.click, so in response
   to a user interaction, and if you have lots of these things in the
   document, and you don't want to cache them all, you still have this
   issue

   AD: also if it's all script

   DH: for declarative, you could render the offscreen rendering on the
   very first sample of the animation
   ... we currently recompute the world on every sample

   JW: there are two parts that make it slow
   ... there are the first 1 or 2 paints, when ou figure out it's
   moving, which you can avoid if the animation is declarative
   ... and the other one is the slow rendering into the offscreen
   buffer, which you can't avoid even with declarative animation

   CM: because these are complex objects you want to buffer?

   JW: yes

   AD: you could have a limit, say 1 or 2 buffered-renderings in the
   document, or a certain MB of cache

   ED: we've implemented it, and already seen misuse of it
   ... it says in the spec that if you update the subtree, it says you
   should rerender it, but it doesn't say when
   ... there's a bit of free room there for experimenting
   ... i think it will be hard to harmonize implementations there

   AD: what was the motivation for proposing this?

   JW: i occasionally hear people requesting it
   ... I wanted it for one document I was writing

   ED: I think it's fine for closed systems, but not sure it's good for
   the web as a whole

   RESOLUTION: We won't add buffered-rendering to SVG 2 unless
   implementor feedback indicates that it is needed

Connectors

   DS: [presents some slides]
   ... connectors would be a straight line between two nodes
   ... you can style their appearance
   ... there would be a list of connectors for navigation purposes
   ... they wouldn't dynamically position nodes in the graph
   ... no concept of weighting on edges
   ... it wouldn't do line routing
   ... it wouldn't allow automatic drag-and-drop

   [rest of the presentation]

   DH: seems useful

   RO: it seems like a step towards graph layout
   ... and edge routing

   DS: you can draw the lines yourself, the straight line is the
   default

   CM: the part I like the most is the automatic connection to the
   closest point on a shape
   ... the semantic part I'm not sure about, without having a whole
   aria vocab

   JW: regarding routing, how about having routing points?
   ... yes you can have polylines

   CM: would it be a separate connector element? how about just
   sticking some attributes on a <path>?

   DS: i like the syntax of a separate element

SVG Integration

   DS: I'll give you a brief overview of the document as it stands

   <birtles>
   [33]http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

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

   DS: we have "referencing modes for svg"
   ... they are ways for specifications to say they are using svg in
   particular contexts
   ... e.g. css might use a particular referencing mode for images
   ... html might use one for image and another for iframe
   ... it describes svg in terms of some specific capabilities --
   animation, external references, [...]
   ... we've talked about having one or two more, but i won't go into
   the individual referencing modes

   RO: why not define those flags as independent things? you might want
   a combination of flags that's not one of the preset modes.

   DS: we could. i did it this way because people in the past have
   asked "how do I reference SVG, what's a handy name for a set of
   common flags"
   ... so we can say it's using "secure animated modes"

   CL: you could do both

   RO: or you could make the flags normative, and the modes informative

   DS: yes, well the modes would be normative, but yes
   ... network admins, once they understand animated script-less svg is
   safe for them, they don't have to think about it any more

   [shows examples from the spec]

   scribe: it also talks about foreign content in svg
   ... how you can comine -- we don't explicitly talk about using html
   in foreignObject, in the svg spec
   ... in SVG Integration we decided we'd actually talk about that
   ... talking to implementors about considerations about that

   DH: might be good to mention plugins and scripts
   ... i think you can only have plugins in foreignObject in svg
   ... maybe in the "no script" mode it would mean no plugins

   DS: also talks about svg in foreign content
   ... it also talks about how to extend svg
   ... this was so that OASIS/ODF would know how best to integrate SVG
   as a first class citizen
   ... then we wanted to have a list of all
   elements/attributes/properties in SVG
   ... which could be referenced by HTML
   ... that's all that's in there now. we've talked about other things,
   compound document scenarios that Tav's talked about
   ... e.g. svg as a button in an HTML page, or in an img, etc.
   ... tav will help me draw up some of that
   ... maybe much of that should be defined by html, it seems it's not
   addressing that at the moment
   ... it's worth pointing out specific modes if we think they are
   useful, e.g. a mode that we know should be used for css backgrounds,
   we should predefine it

   DH: audio/video also

   DS: individually, since audio is more annoying

   DH: and it's also a subset of video, since video comes with audio

   DS: earlier on we talked about how filters would be used in html
   content, etc.
   ... but those are in their own specifications at this point

   CM: and I think that's going to work fine

   DS: I agree
   ... ultimately I don't know if this should be a part of SVG 2
   ... I think it might be worth maintaining on its own

   CL: I agree
   ... it's an interface document
   ... we should publish a FPWD

   DS: i'd like to add the flag idea from roc and the
   audio/video/plugins comments from daniel, first
   ... i'd estimate probably by the end of the month it'd ready for
   publication

   RESOLUTION: We will publish SVG Integration after Doug addresses
   feedback

   BB: [some comments about whether to allow TimeEvents to be
   dispatched in animations in SVG-as-img mode]

pointer-events processing and security

   RO: [summarises the issue raised a while ago]
   ... we need to have something around pointer-events
   ... we do need to be able to have pointer events, make things
   transparent when alpha=0
   ... but in a controlled way
   ... so maybe pointer-events should consider to intersect the entire
   <image> when the image is cross origin
   ... so elementFromPoint would always return that element, if the
   coordinates were within the bounds of that image
   ... there is also the properites on SVGUseElement, if you are doing
   cross origin using
   ... you want to block those

   this is ISSUE-2071

   ISSUE: SVG2 should block cross origin SVGUseElement property access

   <trackbot> Created ISSUE-2407 - SVG2 should block cross origin
   SVGUseElement property access ; please complete additional details
   at [34]http://www.w3.org/Graphics/SVG/WG/track/issues/2407/edit .

     [34] http://www.w3.org/Graphics/SVG/WG/track/issues/2407/edit

rechartering

   DS: I've been working on the charter document
   ... addressed some comments from Cameron

   <shepazu> [35]http://www.w3.org/Graphics/SVG/WG/charter/2010/

     [35] http://www.w3.org/Graphics/SVG/WG/charter/2010/

   <anthony_nz> Thank you Mozilla for hosting a productive meeting!

   trackbot, end telcon

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 4 March 2011 04:20:09 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:47 GMT