- From: Chris Lilley <chris@w3.org>
- Date: Tue, 7 Sep 2010 17:57:51 +0200
- To: www-svg@w3.org
Hello www-svg,
We elected to not go on strike in solidarity with the transport workers, so here are the minutes
http://www.w3.org/2010/09/07-svg-minutes.html
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
Attendees
Present
ChrisL, AnthonyG, Jean-ClaudeD, JWatt, DougS, ErikD
Regrets
Chair
Erik
Scribe
anthony, Chris
Contents
* [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
synchronisation
... 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
[11]http://www.w3.org/2010/09/07-svg-minutes.html#action01]
<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
optional
... 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
[13]http://www.w3.org/2010/09/07-svg-minutes.html#action02]
<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?
<shepazu>
[15]http://lists.w3.org/Archives/Public/www-svg/2010Sep/0048.html
[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
<shepazu>
[17]http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg
_ef.html
[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
<jwatt>
[19]http://lists.w3.org/Archives/Public/www-style/2010Aug/0635.html
[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
<jwatt>
[20]http://lists.w3.org/Archives/Public/www-style/2008Jul/0335.html
[20] http://lists.w3.org/Archives/Public/www-style/2008Jul/0335.html
JW: In there ROC has a link
... to a document
<jwatt>
[21]http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
[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
module
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
<jwatt>
[22]http://lists.w3.org/Archives/Public/www-style/2010Sep/0000.html
[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
languages
... 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
exactly
... 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
content
... only undefined part is whether you get padding
<shepazu> I have an example on my blog:
[23]http://schepers.cc/css-in-svg
[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
bars
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
<img>
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
SVG
... 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
root
JW: It's a bit odd
DS: Why not?
JW: Putting the width and height 100% it's going to give you scroll
bars
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
firefox
... 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
box?
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
foreignObject
... 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
border
... 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/
[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
wide
<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
border
<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
[28]http://www.w3.org/2010/09/07-svg-minutes.html#action04]
<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
[29]http://www.w3.org/2010/09/07-svg-minutes.html#action05]
<trackbot> Created ACTION-2857 - Investigate defining how the
outline property applies on SVG elements [on Doug Schepers - due
2010-09-14].
<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
[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
testcase
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
through
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
[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
<shepazu>
[33]http://www.w3.org/TR/SVG/interact.html#UIEventProcessing
[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
propogation
... (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
testing
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
dragged
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
too
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
tested
... 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
<ed>
[35]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/clicks-on-root-svg
.svg
[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
intuitive
<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
objects
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
implementations
<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
elements
<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
behaviour
... 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
adjourned
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
[37]http://www.w3.org/2010/09/07-svg-minutes.html#action03]
[NEW] ACTION: Doug to Investigate defining the outline property for
use on SVG elements [recorded in
[38]http://www.w3.org/2010/09/07-svg-minutes.html#action05]
[NEW] ACTION: Doug to To add to the integration specification how
border and background properties apply to SVG [recorded in
[39]http://www.w3.org/2010/09/07-svg-minutes.html#action04]
[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
[40]http://www.w3.org/2010/09/07-svg-minutes.html#action02]
[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
[41]http://www.w3.org/2010/09/07-svg-minutes.html#action01]
[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