Minutes, SVG f2f meeting Tuesday (strike day) 7 Sept

Hello www-svg,

We elected to not go on strike in solidarity with the transport workers, so here are the minutes


and below as text 

                   SVG Working Group Teleconference

07 Sep 2010

   See also: [2]IRC log

      [2] http://www.w3.org/2010/09/07-svg-irc


          ChrisL, AnthonyG, Jean-ClaudeD, JWatt, DougS, ErikD


          anthony, Chris


     * [3]Topics
         1. [4]Media Access Events
         2. [5]SVG 2 with CSS
         3. [6]element() syntax
         4. [7]Borders and Background for root SVG
         5. [8]pointer events
     * [9]Summary of Action Items

   <trackbot> Date: 07 September 2010

   <anthony> Scribe: anthony

   <scribe> ScribeNick: anthony

Media Access Events

   CL: This came up at SVG Open
   ... people trying to sync with video
   ... and found there were not sufficient events

   JCD: Ericsson said they were happy with it as it is
   ... Ikivo were happy with it as well

   CL: The next question is if we start standardising it, it needs to
   work with HTML

   JCD: I think to bring it (HTML) video up SVG you need to add
   ... I think MAE is completely orthogonal to sync

   ED: There are buffering events

   CL: The next thing we need to do
   ... is draw up a table
   ... of what HTML has what MEA has

   DS: Don't forget the progress events
   ... which HTML 5 uses
   ... the way progress events are defined is you can change some the
   semantics around

   CL: Does HTML 5 use that?

   DS: Kind of
   ... and so does XHR

   CL: So XHR uses the progress events? to use different things?

   ED: I thought it was XHR 2

   CL: It strikes me if we want to pick this up again
   ... we need to do a comparison of what is around
   ... and explain the use case
   ... of why this is needed
   ... show why it is useful for HTML 5 to have these

   <ed> [10]http://www.w3.org/TR/html5/video.html#mediaevents

     [10] http://www.w3.org/TR/html5/video.html#mediaevents

   DS: Before we try to push this any further with SVG
   ... we should communicate with the other groups
   ... Web Apps WG, HTML WG, Media Annotations WG, Media Fragments WG
   ... and that we are moving forward on this spec
   ... based on need in markets and implementer experience
   ... and it would be nice to synchronise our efforts
   ... and hopefully other groups and technologies could benefit from
   this spec as well

   <cyril> CC: you should also indicate that it is somehow implemented
   (GPAC has a bit of them)

   DS: oh and the public FX taskforce

   ED: Who is going to communicate with all the groups
   ... what is the message we are going to send out

   JCD: I need to go through and try to understand what's happening
   ... Before I can say anything, I need to spend some time alone to go
   through it

   <ChrisL> tracker, status

   <ChrisL> trackbot, status

   <scribe> ACTION: Jean-Claude to Go through the MAE spec and the HTML
   5 spec for video events and report back to the SVG WG [recorded in

   <trackbot> Created ACTION-2854 - Go through the MAE spec and the
   HTML 5 spec for video events and report back to the SVG WG [on
   Jean-Claude Moissinac - due 2010-09-14].

SVG 2 with CSS

   CL: In SVG 1.1 the properties and the inheritance mechanism are
   mandatory using the attribute syntax
   ... but external style sheets, style element and style attribute are
   ... but now days it's being used more often
   ... so I think for SVG 2 we should make external CSS mandatory
   ... why make it optional?

   DS: I have no problem with that

   CL: For SVG only UAs, you don't require the box model

   DS: We should have a better method for referencing external sheets
   than XML processing instructions

   CL: Technically we have a mechanism for linking to style sheets

   DS: I was thinking we should get agreement that we should make CSS
   mandatory in SVG 2

   AG: Will you require the box model?

   CL: No, so you will be required to support external style sheets and
   style element and style attribute all with CSS syntax
   ... SVG only UAs will not be required to support the box model but
   SVG and HTML UAs will (since they already do)
   ... is that clear what I'm suggesting?

   JCD: I don't like optional. If the support is inside and outside, it
   doesn't make sense to mandate one and not th other

   Resolution: SVG 2 will mandate the support for external style
   sheets, style element and style attributes all with CSS syntax

   ED: So we had some more things to discuss on this topic
   ... we should make sure that the current CSS properties that don't
   apply should be investigated
   ... we should go through all of them
   ... see if they apply to SVG

   CL: So for text shadow that is a direct alias for a canned filter
   ... what do we do there?
   ... I don't know how tightly they define it

   DS: We should be able to find out what they are defining

   ED: We need to go through the CSS 3 and 2.1

   <ChrisL> action-2854?

   <trackbot> ACTION-2854 -- Jean-Claude Moissinac to go through the
   MAE spec and the HTML 5 spec for video events and report back to the
   SVG WG -- due 2010-09-14 -- OPEN

   <trackbot> [12]http://www.w3.org/Graphics/SVG/WG/track/actions/2854

     [12] http://www.w3.org/Graphics/SVG/WG/track/actions/2854

   <scribe> ACTION: Erik, Chris to Go through the CSS 2.1 and 3 specs
   to see which properties for SVG 2 might be applicable [recorded in

   <trackbot> Sorry, couldn't find user - Erik,

   <scribe> ACTION: Chris to Go through the CSS 2.1 and 3 specs with
   Erik to see which properties for SVG 2 might be applicable [recorded
   in [14]http://www.w3.org/2010/09/07-svg-minutes.html#action03]

   <trackbot> Created ACTION-2855 - Go through the CSS 2.1 and 3 specs
   with Erik to see which properties for SVG 2 might be applicable [on
   Chris Lilley - due 2010-09-14].

   ED: One other thing that I know which is implemented already is CSS
   3 color syntax for fill and stroke
   ... we need to define it for SVG
   ... because it's a bit more complicated than just going through and
   see what applies

element() syntax

   ED: Is there a spec for that JWatt?


     [15] http://lists.w3.org/Archives/Public/www-svg/2010Sep/0048.html

   <shepazu> ROC mentions it here, looks like a great idea

   JW: It was Marcus Stange that is doing the work

   <jwatt> [16]https://developer.mozilla.org/en/CSS/-moz-element

     [16] https://developer.mozilla.org/en/CSS/-moz-element

   JW: Other than that there is the blog posts that ROC linked to in
   the email

   DS: But no spec?

   JW: I guess, I don't know if there is a proposal to the CSS WG yet
   ... but there should be


     [17] http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html

   <jwatt> [18]http://hacks.mozilla.org/2010/08/mozelement/

     [18] http://hacks.mozilla.org/2010/08/mozelement/

   DS: Here he writes it up a bit more

   <shepazu> -moz-element(#elementID)

   ED: I think this a good idea

   <jwatt> there's a thread on www-style about it

   ED: it would be nice to have something like this


     [19] http://lists.w3.org/Archives/Public/www-style/2010Aug/0635.html

   DS: I don't think SVG should standardise it
   ... I think CSS should
   ... but we should support it
   ... part of FX work maybe
   ... SVG 2 should use this

   JW: There is a proposal


     [20] http://lists.w3.org/Archives/Public/www-style/2008Jul/0335.html

   JW: In there ROC has a link
   ... to a document


     [21] http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html

   CL: This post dates EDs work on the Filters module

   <jwatt> that's from 2008 though

   CL: is there anything in that draft that thread is not in your

   ED: element()

   CL: In particular the terminology I want to make sure that it is
   clear in your spec

   ED: That wording is not yet in
   ... I do have an action from FX taskforce
   ... to move the filters module to the common workspace area

   CL: We need to start those calls again after the summer
   ... In the terminology section there is some useful wording

   <ChrisL> definition of "bounding box" of a CSS-formatted element,
   for example

   ED: Any response from the CSS WG?

   CL: No

   ED: Guess we should just discuss that in the XF telcon

   <jwatt> note that the Aug www-style discussion continues in Sept


     [22] http://lists.w3.org/Archives/Public/www-style/2010Sep/0000.html

   CL: So it was recently agreed to extend the hash syntax
   ... so there is a 4 and 6 figure RGB
   ... way to define colour
   ... Apart from that there has been recent work it the taking up of
   vertical text
   ... the idea is to change one property and the text goes vertical
   ... and the properties all make sense
   ... also W3C got representation from the Indian office about Indian
   ... one of them was vertical
   ... they are still doing stuff about borders and backgrounds

   ED: There was some discussion on whether to slice up the viewbox

   CL: You can do it with a viewbox

   ED: That's not defined?

   CL: Not yet, individual image formats need to say what happens
   ... Doug, is the integration spec cover CSS as well?

   DS: Yes, trying to make it fairly general

   CL: So one thing to put in there is, if SVG is used as a CSS border
   image - how the required slices are generated
   ... [Draws diagram on board]

   JW: What happens with the edges when you're repeating and it doesn't
   fit the exact multiple?

   CL: Up do you to design an image that works properly
   ... it's designed to be used for an image that has been created for
   that purpose

   JW: There's going to be cases where that doesn't work
   ... [Adds to drawing]

   CL: It stretches and repeats

   JW: In certain cases you'd want it to space evenly

   CL: In it's current state it's getting ready for CR
   ... this one of the ones that's expected to go to Rec fairly quickly
   ... and it's a good time for us to define it for SVG

   ED: It is a bit more work for SVG
   ... to make sure it looks good

   <ed> [back from lunchbreak]

Borders and Background for root SVG

   CL: The SVG inside the HTML has an outside and an inside edge
   ... and the box model applies to the outside edge
   ... and the SVG formatting model applies to the inside, i.e. the
   ... only undefined part is whether you get padding

   <shepazu> I have an example on my blog:

     [23] http://schepers.cc/css-in-svg

   JW: It's formatting is defined by the replaced element
   ... for the purposes of CSS

   CL: Is replaced element anything that doesn't use the box model

   DS: I think your definition makes sense
   ... it's something where the normal CSS rules don't apply
   ... for where the rules don't apply that's replaced conent
   ... I have a blog post you'd like to look at
   ... if you scroll down to the bottom
   ... the two pictures
   ... both of those are the correct geometry as the SVG says it is
   ... The border should be clipped
   ... [Projects blog post]
   ... The top image has the width and height declared in the SVG
   ... same width and height is encoded in the object

   CL: The area that SVG believes it has been given
   ... is the area it should render it
   ... If the CSS gave it a massive big top border which changed the
   aspect ratio it should render into that

   DS: If I do 100% and 100% in the SVG width and height
   ... it does exactly the same thing
   ... and all the browsers as I tested
   ... did it this way
   ... to me this border should be clipped
   ... it should be as if overflow="hidden"

   CL: This is why people use raster images because you get the scroll

   ED: This is one of the reasons to have SVG work in the <img> tag
   ... you wouldn't get scroll bars

   <ChrisL> having scroll bars obscuring the content in svg, especially
   for small images, makes people use animated gif or flash instead

   DS: Sure <img> is convenient but you don't want script to work in

   CL: This is something you should be able to control
   ... you should be able to elect to not have scroll bars

   JW: This case is a bit weird
   ... I don't see what people would want to put a border on the SVG

   ED: You'd put a border on an iFrame
   ... that's what I'd do

   JW: I'd be tempted say that on the root element border and stuff
   like that doesn't apply

   ED: Unless it's inline

   JCD: The problem is half of it is inside and half of it is outside

   DS: We have to specify this anyway
   ... I can see that people want to put a border around SVG
   ... so that it has one no matter where it shows up

   JW: I want the iFrame to take on the aspect ratio of the SVG
   ... but I want the SVG to take on the dimensions of the iFrame

   DS: That's not where the box model is being applied here
   ... it's being applied to the SVG content
   ... it's not being declared on the object that is referencing the
   ... it's being applied to the SVG content

   JW: What do you think should be applied

   DS: The border should not have geometry per say
   ... it shouldn't add to the amount of space that the SVG takes up
   ... it's purely stylistic
   ... SVG doesn't follow the box model
   ... Something needs to be specified
   ... I'm arguing that are two different cases
   ... for border and background
   ... then there are for stroke and fill
   ... I think they are different characteristics
   ... I can see people wanting to use border and background on the SVG

   JW: It's a bit odd

   DS: Why not?

   JW: Putting the width and height 100% it's going to give you scroll

   DS: Lets say that people want to have a border on their SVG
   ... I actually think this is a legitimate use case
   ... it's easier to have a border and background if they are familiar
   to CSS

   CL: This is exactly why we put viewport fill
   ... so the thing that people are already familiar with doesn't let
   people zoom out

   DS: I would expect the background would be a flat fill

   AG: I'd expect the border to operate like the vector effect for non
   scaling object
   ... where the border is always resized when zooming
   ... I'd expect maybe the same thing could work with background

   JW: This is being parsed by the HTML parser
   ... you're served this as Text/HTML
   ... so I think what's happening here is in the current version of
   ... it was being parsed with the old version of the parser
   ... but now it's being parsed with the new HTML parse

   ED: I see something slightly different in Safari
   ... doesn't look the same as in FireFox

   JW: This is to do with parser rather than the CSS model

   CL: Beta 6 shows the same as Beta 4

   DS: It looked different

   JW: According to the HTML with SVG parsing rules it's implicitly
   creating a second appearance

   DS: I think I figured it out
   ... I think it's my blog
   ... [Fixes blog]

   JW: That looks better

   ED: How are borders applied in CSS, do they go outside the content

   CL: Yes

   DS: In the second example I'm using padding
   ... in the first case I'm just using border

   CL: It's just wrong. If I want a border around my SVG I'd expect it
   to be on the outside
   ... so you say in your post that some things should apply, do you
   mean them as examples or as an exhaustive list?

   DS: As a list of all that apply

   CL: In that case that's ok

   DS: I was specifically call out things that would make sense to have

   ED: If you put a border on something inside the root of a
   ... would it be bigger?

   CL: I'd expect the line to go all the way around the foreignObject

   JW: [Draws different scenarios on board]
   ... my suggestion would be to set this property for SVG elements
   ... and it automatically just works for elements
   ... I think what will happen is the content area size is reduced
   ... which is the effectively the viewport size of the SVG

   <ChrisL> scribe: Chris

   <ChrisL> scribenick: ChrisL

   DS: (draws on board)

   JW: In all cases it stays at 100% 100%.

   DS: OK if we don't show the border. It might apply
   ... what if they zoom out, then it shows.

   JW: Huh?

   ED: That is a strange behaviour

   DS: Dont want the size of the SVG to be affected by the size of the
   ... dont want box model to apply to svg in that way
   ... only the border and background, not the rest of the box model.
   and the padding
   ... Chris you are right, viewport-fill and background are different,
   for svg

   JW: (still searching for the property that says whether width
   applies to content box, padding box or border box)

   <ed> [24]https://developer.mozilla.org/en/CSS/box-sizing

     [24] https://developer.mozilla.org/en/CSS/box-sizing

   <jwatt> [25]http://www.w3.org/TR/css3-ui/#box-sizing

     [25] http://www.w3.org/TR/css3-ui/#box-sizing


     [26] http://dev.w3.org/csswg/css3-ui/

   Name: box-sizing

   Value: content-box | border-box | inherit

   ED: Does this solve the examples on your blog, Doug?

   CL (reads from spec) so you got this legacy behaviour as the editors
   not describes

   JW: So ok to do this but only on the outer svg element for inline
   content, as the outside of it is in the box model

   CL: OK to deprecate viewport-fill in favour of background, if and
   only if it behaves the same way including under dynamic modification
   or user interaction (especially zooming out)
   ... otherwise, having the same property but behaving differently is
   more confusing than having two properties which do different things

   DS: I suspect that most designers would expect background fills
   entire viewport regardless of zoom

   CL: OK, but does the background spec say that?

   <anthony> AG: I agree with what Doug thinks. That's just my opinion

   <anthony> CL: My point is that how the backgrounds behaves is
   described in terms on the box model

   <anthony> ... so when they add transforms they will describe what
   happens with the boxes

   <anthony> ... but it's only defined for the box model, so saying we
   want a background for our non-defined box model is undefined

   <anthony> JW: The problem I see is

   <anthony> ... say I have a content area

   <anthony> ... and there is area without anything in it

   <anthony> ... setting the CSS background property will fill just the
   content area

   <anthony> ... where as viewport fill would fill the whole area

   <anthony> ... including the area without anything

   <anthony> CL: If it was 400 wide I would not have said it was 200

   <anthony> ... I would've said it was 50%

   <anthony> ... and use Xmin and Ymin

   <anthony> ... that's how I would design that case

   <anthony> DS: We have viewport fill and viewport fill opacity

   <anthony> ... even though it would make sense for designers to use

   <anthony> ... they would find it doesn't work they way they expect

   <anthony> ED: Viewport fill and viewport fill opacity already work
   for all SVG elements that establish a viewport

   <anthony> AG: so 1.1 has a couple of elements where that applies?

   <anthony> ED: Yeah, anything that establishes a viewport

   <anthony> DS: Are people completely closed to the idea of having
   border and background on individual SVG elements?

   <anthony> ... it's incredibly useful to be able to see the bounding
   box of an element for debugging

   <anthony> ... would much be nice to have a dashed border that
   changes with the size of the shape

   <anthony> JW: There is another property that does a line around the
   object without all the box model stuff

   <anthony> ED: outline?

   <anthony> DS: Does it have all the characteristics

   <anthony> JW: We could define it to apply to the bounding box

   <jwatt> [27]http://www.w3.org/TR/css3-ui/#outline

     [27] http://www.w3.org/TR/css3-ui/#outline

   <jwatt> I'd be much happier to consider making the outline
   properties apply to SVG rather than border

   <anthony> CL: In principle it sounds reasonable

   <anthony> ... it gives you the ability to give you a rectangle
   around something that encompasses the object

   <anthony> Resolution: We will define how border and background apply
   to SVG

   <anthony> Resolution: We will keep viewport-fill and
   viewport-fill-opacity for zoom

   <anthony> Resolution: We will investigate defining the outline
   property for use on SVG elements

   <anthony> ACTION: Doug to To add to the integration specification
   how border and background properties apply to SVG [recorded in

   <trackbot> Created ACTION-2856 - To add to the integration
   specification how border and background properties apply to SVG [on
   Doug Schepers - due 2010-09-14].

   <anthony> ACTION: Doug to Investigate defining the outline property
   for use on SVG elements [recorded in

   <trackbot> Created ACTION-2857 - Investigate defining how the
   outline property applies on SVG elements [on Doug Schepers - due

   <ed> [work on actions]

   <ed> [30]http://www.w3.org/Graphics/SVG/WG/track/

     [30] http://www.w3.org/Graphics/SVG/WG/track/

   <scribe> scribe: chris

   <scribe> scribenick: ChrisL

pointer events

   ED: Root svg element should let clicks through to the underlying
   content if its inline in html

   <shepazu> example:

     [31] http://www.schepers.cc/svg/blendups/overlay/test/overlap.xhtml

   embeded svg capures the clic and the surrounding context does not
   get it

   CL does not surprise me that we don't get two events in the first

   DS: Spec is ambiguous.

   ED: Firefox behaves differently from Webkit and Opera. IE9 not
   tested ast time we discussed this

   CL: CSS Pointer events extends out pointer events spec to add box
   model stuff

   DS: Some CSS developers love being able to use ponter events
   ... case where there is svg referenced with object, image the
   transparent parts should click through.

   JW: In HTML a transparent background can still be targetted by
   events. So if inline SVG is just another element in the box model,
   it behave the same. opt-out is pointer events none

   DS: That stops all interaction

   JW: No, you can overide it for the children

   DS: where is it specified?

   JW: Not clear, jus went for consistency with how HTML is implemented

   ED: Feedback says that is not what we want, inefficient, so we allow
   clicks through the unpainted area

   CL: Same issue with a PNG image with transparency surely

   ED: People want the stuff underneath to get clicks

   JW: On bugzilla i was arguing to have events go through, but final
   decision was to block them

   ED: target the comon case first. Mostly people want the events to go

   DS: SVG spec assumes (though poorly worded) that SVG root doesn't
   intercept pointer events on unpainted areas

   CL: Do you have the same behaviour as Firefox for HTML/CSS pointer
   events on transparent background?

   ED: Yes. But for SVG people expect different things.
   ... Background does not affect it

   JCD: So even if transparent it captures events?

   ED: yes

   (discussion on security, and same-domain and overflow on embedded
   objects to capture events)

   <ed> just for reference, search for "hit" in the minutes from day 1,
   where we discussed this topic:

     [32] http://www.w3.org/2010/09/03-svg-minutes.html

   CL: So Doug was saying to not hit-test on unpainted background, and
   Firefox says to set pointer events to get that behaviour that the
   spec already says

   ED: Cyril tested IE9 and it has the same behaviour as Webkit and
   Opera. Would Mozilla be willing to chenge here?

   JW: Personally yes but not my call here


     [33] http://www.w3.org/TR/SVG/interact.html#UIEventProcessing

   JW: (reads from spec on 'painted area' which is all about grahics
   elements not containers)

   DS: This could be improved, it mixes hit testing and event
   ... (projects above link, points out errors)
   ... first bullet is about hit testing. next 3 are about order of
   actions for things that have been hit tested
   ... and failing that, text selection starts
   ... final sections ays, if hit testing failed, do any UI events like
   context menu it what what happen normally
   ... this was before there was a clear concept of window.
   ... it not about event propogation at all. its a consequence of hit

   CL: This is a very traditional CG model from 1970s, 80s

   JW: Read it as all five bullets apply to all elements

   DS: So first you see if you are on a graphics element, then it
   propogates, then you do the actions, failing that then you do zoom
   and pan etc
   ... assuming you hit a graphics element. container elements dont get
   events in this way

   JW: Spec does not say explicitly that container elements cant be the
   target of an event

   ED: pointer events apply only to graphic elements
   ... Can dispatch an event to any element

   DS: (quotes "The target element is the topmost graphics element
   whose relevant graphical content is under the pointer at the time of
   the event")
   ... Important to clarify this now CSS is adding pointer events

   JW: If you set a viewport fill it gets no events and can't be

   DS: Yes. You would need to draw a rect to do that
   ... Its clear for inline. Opera used to have the behaviour JWatt was
   describing but has changed, Webkit/Chrome/IE9 have that behaviour

   JW: What is the target if there is no content?

   ED: The window or the document.
   ... or the document element, and I'm not sure which. needs to be
   ... Onclick handler on root svg, do you expect it ever to be called?

   JW: If its still inside the viewport, if there is viewport fill it
   should get events

   ED: (drops in testcase)
   ... Do we have wording for where the listener is defined?
   ... Think html body element is special

   JW: Quite likely. registers it on window I think

   <shepazu> ISSUE-2364

   <shepazu> ISSUE-2364?

   <trackbot> ISSUE-2364 -- Last Call Comment: SVG 1.1 may be ambiguous
   about the root element acting as a proximal event target -- raised

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

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

   JW: We have bugs on our behaviour in bugzilla


     [35] http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/clicks-on-root-svg.svg

   DS: More common case with mixed SVG and HRML, people do not want a
   giant bbox they can't click through

   <jwatt> s/have bugs on our behavior in bugzilla/have had bugs asking
   for pointer events to target <svg> instead of letting them through/

   <jwatt> [36]https://bugzilla.mozilla.org/show_bug.cgi?id=338279

     [36] https://bugzilla.mozilla.org/show_bug.cgi?id=338279

   DS: For the inline case, try to select text in the overlap. It
   doesn't work as the SVG captures the event

   CL: I agree that unpainted area should not capture events

   AG: I agree

   DS: SVG 1.1 is clear that only graphics elements dispatch pointer
   events, browsers all do that apart from Firefox

   ED: Confirm IE9 has the SVG 1.1 behaviour

   DS: I think HTML folks would prefer to see this behaviour too, for
   irregular shaped graphics. They are not boxes

   CL: And can alway have pointer events bbox anyway if that is wanted
   ... Need to make sure the CSS guys know about thet value btw its a
   late addition

   JW: (example, scribe missed)
   ... in both cases its inconvenient because you need an encosing g
   element to set pointer events on

   DS: Pointer events section should have explicitly mentioned groups.
   Needs to be very clear in SVG 2
   ... Easier to change one browser than five ....

   AG: If i have a rect that is stroked and not filled, clicking the
   middle gets no event

   CL: Correct, default is visiblePainted

   AG: vector effects needs to be clear here if the result is a path or
   a stroke, for purposes of pointer events

   <jwatt> I'm not comfortable with saying that <svg> can't be the
   target of events for a few reasons:

   <jwatt> for many people coming from HTML I don't think it's

   <jwatt> if you want the reverse behaviour (<svg> being an event
   target) you still need the child <g> reseting pointer-events

   <jwatt> if you have 'background' or 'viewport-fill' on <svg>, I'd
   expect events to be able to target it

   <jwatt> having said that, I do sympathize with and accept that there
   are many people who don't expect or like mozilla's behavior

   but neither viewport fill nor background are painted graphical

   JW: Not painted but its visible and people expect to be able to
   interact with it

   DS: OK so we esatablished correct behaviour for *inline* svg, bt
   that was not really the issue

   <jwatt> I'd note that SVG 1.1 as it currently stands does not allow
   <svg> to be the target of an event, period

   ED: when svg is standalone, and click outside painted area, event is
   captured and target is the svg element in four tested

   <jwatt> as Doug says, you'd need a rect filling the viewport to get
   events anywhere

   ED: firefox 4.0b6pre, Opera 10.60, Safari 5, IE9 platform preview 4

   CL: At al, even if pointer events are changed?

   JW: Yes

   ED: Spec not consistent with that

   DS; Maybe the pointer events should be extended to include a
   background value

   DS: Those comments not withstanding, SVG 1.1 spec has intuitive
   behaviour that is widely implemened so we should keep it

   action doug to clariify the behaviour of pointer events on container

   <trackbot> Created ACTION-2858 - Clariify the behaviour of pointer
   events on container elements [on Doug Schepers - due 2010-09-14].

   <jwatt> I'd also note that if events go "through" <svg>, then the
   "put a 100% x 100% <rect> in to capture events doesn't work in the
   face of viewBox

   DS: Microsoft has been pretty clear that they want this pass-through
   ... Want consistent behaviour in browsers

   JW: Will talk to Roc about this

   Resolution: the svg 1.1 spec is clear that pointer events only
   target on graphicc elements and this intuitive behaviour is widely
   implemented so for the inline case we will keep the same behaviour
   that the spec defines

   JW: Okay, will go along with the majority here but uncomfortable
   with whether this is the right thing

   DS: For externaly referenced content, its not settled yet

   AG: In all cases, if something is visible and it could be targetted

   <jwatt> s/will go along with the ajority here/will not stand in the
   way right now/

   <jwatt> as stated above, I think 'intuitive' depends on who you are
   - if you come from SVG, sure


   trackbot, end telcon

Summary of Action Items

   [NEW] ACTION: Chris to Go through the CSS 2.1 and 3 specs with Erik
   to see which properties for SVG 2 might be applicable [recorded in
   [NEW] ACTION: Doug to Investigate defining the outline property for
   use on SVG elements [recorded in
   [NEW] ACTION: Doug to To add to the integration specification how
   border and background properties apply to SVG [recorded in
   [NEW] ACTION: Erik, Chris to Go through the CSS 2.1 and 3 specs to
   see which properties for SVG 2 might be applicable [recorded in
   [NEW] ACTION: Jean-Claude to Go through the MAE spec and the HTML 5
   spec for video events and report back to the SVG WG [recorded in

   [End of minutes]

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Tuesday, 7 September 2010 15:57:52 UTC