IRC log of svg on 2010-09-07

Timestamps are in UTC.

08:25:10 [RRSAgent]
RRSAgent has joined #svg
08:25:10 [RRSAgent]
logging to http://www.w3.org/2010/09/07-svg-irc
08:25:12 [trackbot]
RRSAgent, make logs public
08:25:12 [Zakim]
Zakim has joined #svg
08:25:14 [trackbot]
Zakim, this will be GA_SVGWG
08:25:14 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
08:25:15 [trackbot]
Meeting: SVG Working Group Teleconference
08:25:15 [trackbot]
Date: 07 September 2010
08:25:33 [anthony]
Zakim, remind me in 8 hours that I'm awesome
08:25:33 [Zakim]
ok, anthony
08:26:30 [anthony]
Chair: Erik
08:27:41 [anthony]
Present: ChrisL, AnthonyG, Jean-ClaudeD, JWatt, DougS, ErikD
08:27:52 [anthony]
Scribe: anthony
08:27:57 [anthony]
ScribeNick: anthony
08:28:11 [anthony]
Topic: Media Access Events
08:29:10 [anthony]
CL: This came up at SVG Open
08:29:19 [anthony]
... people trying to sync with video
08:29:30 [anthony]
... and found there were not sufficient events
08:30:11 [anthony]
DCD: Ericsson said they were happy with it as it is
08:30:17 [anthony]
... Ikivo were happy with it as well
08:30:40 [anthony]
CL: The next question is if we start standardising it, it needs to work with HTML
08:31:18 [anthony]
JCD: I think to bring it (HTML) video up SVG you need to add syncronisation
08:31:42 [anthony]
... I think MAE is completely orthogonal to sync
08:31:48 [anthony]
ED: There are buffering events
08:31:54 [anthony]
CL: The next thing we need to do
08:31:57 [anthony]
... is draw up a table
08:32:07 [anthony]
... of what HTML has what MEA has
08:32:13 [anthony]
DS: Don't forget the progress events
08:32:16 [anthony]
... which HTML 5 uses
08:32:28 [anthony]
... the way progress events are defined is you can change some the semantics around
08:32:35 [anthony]
CL: Does HTML 5 use that?
08:32:36 [anthony]
DS: Kind of
08:32:42 [anthony]
... and so does XHR
08:32:52 [anthony]
CL: So XHR uses the progress events? to use different things?
08:33:00 [anthony]
ED: I thought it was XHR 2
08:33:11 [anthony]
CL: It strikes me if we want to pick this up again
08:33:20 [anthony]
... we need to do a comparison of what is around
08:33:23 [anthony]
... and explain the use case
08:33:27 [anthony]
... of why this is needed
08:33:38 [anthony]
... show why it is useful for HTML 5 to have these
08:33:41 [ed]
http://www.w3.org/TR/html5/video.html#mediaevents
08:34:11 [anthony]
s/DCD/JCD/
08:35:56 [anthony]
DS: Before we try to push this any further with SVG
08:36:03 [anthony]
... we should communicate with the other groups
08:36:39 [anthony]
... Web Apps WG, HTML WG, Media Annotations WG, Media Fragments WG
08:36:45 [anthony]
... and that we are moving forward on this spec
08:36:54 [anthony]
... based on need in markets and implementer experience
08:37:13 [anthony]
... and it would be nice to synchronise our efforts
08:37:21 [anthony]
... and hopefully benefit from our efforts
08:37:56 [cyril]
CC: you should also indicate that it is somehow implemented (GPAC has a bit of them)
08:37:57 [anthony]
... oh and the public FX taskforce
08:38:21 [anthony]
s/syncronisation/synchronisation/
08:38:53 [shepazu]
s/and hopefully benefit from our efforts/and hopefully other groups and technologies could benefit from this spec as well/
08:40:18 [anthony]
ED: Who is going to communicate with all the groups
08:40:23 [ChrisL]
ChrisL has joined #svg
08:40:25 [anthony]
... what is the message we are going to send out
08:40:49 [anthony]
JCD: I need to go through and try to understand what's happening
08:41:15 [anthony]
... Before I can say anything, I need to spend some time alone to go through it
08:41:25 [ChrisL]
tracker, status
08:41:47 [ChrisL]
trackbot, status
08:42:41 [anthony]
ACTION: Jean-Claude to Go through the MAE spec and the HTML 5 spec for video events and report back to the SVG WG
08:42:41 [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].
08:44:42 [anthony]
Topic: SVG 2 with CSS
08:45:18 [anthony]
CL: In SVG 1.1 the properties and the inheritance mechanism are mandatory using the attribute syntax
08:45:31 [anthony]
... but external syntax, style sheets and style attribute are optional
08:45:38 [anthony]
... but now days it's being used more often
08:46:00 [anthony]
... so I think for SVG 2 we should make external CSS mandatory
08:46:08 [anthony]
... why make it optional?
08:46:54 [anthony]
DS: I have no problem with that
08:47:11 [anthony]
CL: For SVG only UAs, you don't require the box model
08:48:14 [anthony]
DS: We should have a better method for referencing external sheets than XML processing instructions
08:48:49 [anthony]
CL: Technically we have a mechanism for linking to style sheets
08:49:06 [anthony]
DS: I was thinking we should get agreement that we should make CSS mandatory in SVG 2
08:49:33 [anthony]
AG: Will you require the box model?
08:50:40 [ChrisL]
s/external syntax, style sheets/external style sheets, style element/
08:51:19 [anthony]
CL: No, so you will be required to support external style sheets and style element and style attribute all with CSS syntax
08:51:41 [anthony]
... SVG only UAs will not be required to support the box model but SVG and HTML UAs will (since they already do)
08:51:48 [anthony]
... is that clear what I'm suggesting?
08:53:32 [anthony]
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
08:54:31 [anthony]
Resolution: SVG 2 will mandate the support for external style sheets, style element and style attributes all with CSS syntax
08:59:51 [anthony]
ED: So we had some more things to discuss on this topic
09:00:17 [anthony]
... we should make sure that the current CSS properties that don't apply should be investigated
09:00:24 [anthony]
... we should go through all of them
09:00:28 [anthony]
... see if they apply to SVG
09:00:39 [anthony]
CL: So for text shadow that is a direct alias for a canned filter
09:00:47 [anthony]
... what do we do there?
09:00:56 [anthony]
... I don't know how tightly they define it
09:02:48 [anthony]
DS: We should be able to find out what they are defining
09:04:25 [anthony]
ED: We need to go through the CSS 3 and 2.1
09:05:28 [ChrisL]
action-2854?
09:05:28 [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
09:05:28 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/actions/2854
09:05:40 [anthony]
ACTION: Erik, Chris to Go through the CSS 2.1 and 3 specs to see which properties for SVG 2 might be applicable
09:05:40 [trackbot]
Sorry, couldn't find user - Erik,
09:06:02 [anthony]
ACTION: Chris to Go through the CSS 2.1 and 3 specs with Erik to see which properties for SVG 2 might be applicable
09:06:03 [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].
09:08:09 [anthony]
ED: One other thing that I know which is implemented already is CSS 3 color syntax for fill and stroke
09:08:26 [anthony]
... we need to define it for SVG
09:08:53 [anthony]
... because it's a bit more complicated than just going through and see what applies
09:11:59 [anthony]
Topic: element() syntax
09:12:06 [anthony]
ED: Is there a spec for that JWatt?
09:12:45 [shepazu]
http://lists.w3.org/Archives/Public/www-svg/2010Sep/0048.html
09:12:50 [shepazu]
ROC mentions it here, looks like a great idea
09:14:33 [anthony]
JW: It was Marcus that is doing the work
09:14:59 [anthony]
s/Marcus/Marcus Stange/
09:15:03 [jwatt]
https://developer.mozilla.org/en/CSS/-moz-element
09:15:27 [anthony]
JW: Other than that there is the blog posts that ROC linked to in the email
09:15:34 [anthony]
DS: But no spec?
09:15:49 [anthony]
JW: I guess, I don't know if there is a proposal to the CSS WG yet
09:15:52 [anthony]
... but there should be
09:15:53 [shepazu]
http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html
09:15:58 [jwatt]
http://hacks.mozilla.org/2010/08/mozelement/
09:16:00 [anthony]
DS: Here he writes it up a bit more
09:17:18 [shepazu]
-moz-element(#elementID)
09:17:35 [anthony]
ED: I think this a good idea
09:17:41 [jwatt]
there's a thread on www-style about it
09:17:43 [anthony]
... it would be nice to have something like this
09:17:43 [jwatt]
http://lists.w3.org/Archives/Public/www-style/2010Aug/0635.html
09:17:50 [anthony]
DS: I don't think SVG should standardise it
09:17:56 [anthony]
... I think CSS should
09:18:00 [anthony]
... but we should support it
09:18:07 [anthony]
... part of FX work maybe
09:18:18 [anthony]
... SVG 2 should use this
09:20:59 [anthony]
JW: There is a proposal
09:21:04 [jwatt]
http://lists.w3.org/Archives/Public/www-style/2008Jul/0335.html
09:21:27 [anthony]
JW: In there ROC has a link
09:21:29 [anthony]
... to a document
09:21:38 [jwatt]
http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html
09:24:00 [anthony]
CL: This post dates EDs work on the Filters module
09:24:08 [jwatt]
that's from 2008 though
09:24:24 [anthony]
... is there anything in that draft that's not in your module
09:24:37 [anthony]
ED: element()
09:25:18 [anthony]
CL: In particular the terminology I want to make sure that it is clear in your spec
09:25:22 [anthony]
ED: That wording is not yet in
09:25:41 [anthony]
... I do have an action from FX taskforce
09:25:49 [anthony]
... to move the filters module to the common workspace area
09:25:57 [anthony]
CL: We need to start those calls again after the summer
09:26:01 [jwatt]
s/that's/that thread is/
09:26:15 [anthony]
... In the terminology section there is some useful wording
09:27:00 [ChrisL]
definition of "bounding box" of a CSS-formatted element, for example
09:27:29 [anthony]
ED: Any response from the CSS WG?
09:27:39 [anthony]
CL: No
09:27:56 [anthony]
ED: Guess we should just discuss that in the XF telcon
09:34:15 [jwatt]
note that the Aug www-style discussion continues in Sept
09:34:24 [jwatt]
http://lists.w3.org/Archives/Public/www-style/2010Sep/0000.html
09:48:30 [anthony]
CL: So it was recently agreed to extend the hash syntax
09:48:45 [anthony]
... so there is a 4 and 6 figure RGB
09:48:53 [anthony]
... way to define colour
09:51:07 [anthony]
... Apart from that there has been recent work it the taking up of vertical text
09:51:25 [anthony]
... the idea is to change one property and the text goes vertical
09:51:31 [anthony]
... and the properties all make sense
09:52:23 [anthony]
... also W3C got representation from the Indian office about Indian languages
09:52:27 [anthony]
... one of them was vertical
09:52:58 [anthony]
... they are still doing stuff about borders and backgrounds
09:54:04 [anthony]
ED: There was some discussion on whether to slice up the viewbox
09:54:10 [anthony]
CL: You can do it with a viewbox
09:54:16 [anthony]
ED: That's not defined?
09:54:35 [anthony]
CL: Not yet, individual image formats need to say what happens exactly
09:54:47 [anthony]
... Doug, is the integration spec cover CSS as well?
09:54:54 [anthony]
DS: Yes, trying to make it fairly general
09:55:23 [anthony]
CL: So one thing to put in there is, if SVG is used as a CSS border image - how the required slices are generated
09:58:43 [anthony]
CL: [Draws diagram on board]
10:02:54 [anthony]
JW: What happens with the edges when you're repeating and it doesn't fit the exact multiple?
10:03:05 [anthony]
CL: Up do you to design an image that works properly
10:03:21 [anthony]
... it's designed to be used for an image that has been created for that purpose
10:03:28 [anthony]
JW: There's going to be cases where that doesn't work
10:03:57 [anthony]
JW: [Adds to drawing]
10:04:24 [anthony]
CL: It stretches and repeats
10:04:37 [anthony]
JW: In certain cases you'd want it to space evenly
10:04:47 [anthony]
CL: In it's current state it's getting ready for CR
10:05:00 [anthony]
... this one of the ones that's expected to go to Rec fairly quickly
10:05:06 [anthony]
... and it's a good time for us to define it for SVG
10:05:14 [anthony]
ED: It is a bit more work for SVG
10:05:19 [anthony]
... I'm sure it looks good
10:05:38 [ed]
s/I'm sure it looks good/to make sure it looks good/
11:14:21 [ed]
[back from lunchbreak]
11:18:19 [anthony]
Topic: Borders and Background for root SVG
11:18:44 [anthony]
CL: The SVG inside the HTML has an outside and an inside edge
11:18:52 [anthony]
... and the box model applies to the outside edge
11:19:07 [anthony]
... and the SVG formatting model applies to the inside, i.e. the content
11:19:18 [anthony]
... only undefined part is whether you get padding
11:20:09 [shepazu]
I have an example on my blog: http://schepers.cc/css-in-svg
11:20:28 [anthony]
JW: It's formatting is defined by the replaced element
11:20:31 [anthony]
... for the purposes of CSS
11:20:41 [anthony]
CL: Is replaced element anything that doesn't use the box model
11:20:57 [anthony]
DS: I think your definition makes sense
11:21:06 [anthony]
... it's something where the normal CSS rules don't apply
11:21:14 [anthony]
... for where the rules don't apply that's replaced conent
11:23:18 [anthony]
... I have a blog post you'd like to look at
11:24:27 [anthony]
... if you scroll down to the bottom
11:24:38 [anthony]
... the two pictures
11:24:58 [anthony]
... both of those are the correct geometry as the SVG says it is
11:25:22 [anthony]
... The border should be clipped
11:27:02 [anthony]
DS: [Projects blog post]
11:27:12 [anthony]
... The top image has the width and height declared in the SVG
11:27:23 [anthony]
... same width and height is encoded in the object
11:27:39 [anthony]
CL: The area that SVG believes it has been given
11:27:43 [anthony]
... is the area it should render it
11:28:07 [anthony]
... If the CSS gave it a massive big top border which changed the aspect ratio it should render into that
11:28:20 [anthony]
DS: If I do 100% and 100% in the SVG width and height
11:28:24 [anthony]
... it does exactly the same thing
11:29:08 [ChrisL]
ChrisL has joined #svg
11:29:25 [anthony]
... and all the browsers as I tested
11:29:27 [anthony]
... did it this way
11:29:36 [anthony]
... to me this border should be clipped
11:29:53 [anthony]
... it should be as if overflow="hidden"
11:30:25 [anthony]
CL: This is why people use raster images because you get the scroll bars
11:30:36 [anthony]
ED: This is one of the reasons to have SVG work in the <img> tag
11:30:40 [anthony]
... you wouldn't get scroll bars
11:30:51 [ChrisL]
having scroll bars obscuring the content in svg, especially for small images, makes people use animated gif or flash instead
11:30:58 [anthony]
DS: Sure <img> is convenient but you don't want script to work in <img>
11:31:08 [anthony]
CL: This is something you should be able to control
11:31:27 [anthony]
... you should be able to elect to have scroll bars
11:31:37 [anthony]
JW: This case is a bit weird
11:31:41 [ChrisL]
s/to have/to not have/
11:31:49 [ChrisL]
rrsagent, here
11:31:49 [RRSAgent]
See http://www.w3.org/2010/09/07-svg-irc#T11-31-49
11:32:38 [anthony]
... I don't see what people would want to put a border on the SVG
11:32:45 [anthony]
ED: You'd put a border on an iFrame
11:32:48 [anthony]
... that's what I'd do
11:33:02 [anthony]
JW: I'd be tempted say that on the root element border and stuff like that doesn't apply
11:33:09 [anthony]
ED: Unless it's inline
11:33:27 [anthony]
JCD: The problem is half of it is inside and half of it is outside
11:33:34 [anthony]
DS: We have to specify this anyway
11:33:49 [anthony]
... I can see that people want to put a border around SVG
11:33:59 [anthony]
... so that it has one no matter where it shows up
11:34:48 [anthony]
JW: I want the iFrame to take on the aspect ratio of the SVG
11:35:00 [anthony]
.. but I want the SVG to take on the dimensions of the iFrame
11:35:07 [anthony]
DS: That's not where the box model is being applied here
11:35:12 [anthony]
... it's being applied to the SVG content
11:35:30 [anthony]
... it's not being declared on the object that is referencing the SVG
11:35:36 [anthony]
... it's being applied to the SVG content
11:35:41 [anthony]
JW: What do you think should be applied
11:35:50 [anthony]
DS: The border should not have geometry per say
11:35:57 [anthony]
... it shouldn't add to the amount of space that the SVG takes up
11:36:02 [anthony]
... it's purely stylistic
11:36:08 [anthony]
... SVG doesn't follow the box model
11:36:34 [anthony]
... Something needs to be specified
11:36:42 [anthony]
... I'm arguing that are two different cases
11:36:46 [anthony]
... for border and background
11:36:50 [anthony]
... then there are for stroke and fill
11:36:59 [anthony]
... I think they are different characteristics
11:37:10 [anthony]
... I can see people wanting to use border and background on the SVG root
11:37:24 [anthony]
JW: It's a bit odd
11:37:29 [anthony]
DS: Why not?
11:37:48 [anthony]
JW: Putting the width and height 100% it's going to give you scroll bars
11:37:56 [anthony]
DS: Lets say that people want to have a border on their SVG
11:38:11 [anthony]
... I actually think this is a legitimate use case
11:38:28 [anthony]
... it's easier to have a border and background if they are familiar to CSS
11:38:46 [anthony]
CL: This is exactly why we put viewport fill
11:39:02 [anthony]
... so the thing that people are already familiar with doesn't let people zoom out
11:40:10 [anthony]
DS: I would expect the background would be a flat fill
11:40:50 [anthony]
AG: I'd expect the border to operate like the vector effect for non scaling object
11:40:57 [anthony]
... where the border is always resized when zooming
11:41:11 [anthony]
... I'd expect maybe the same thing could work with background
11:43:06 [anthony]
JW: This is being parsed by the HTML parser
11:43:13 [anthony]
... you're served this as Text/HTML
11:43:38 [anthony]
... so I think what's happening here is in the current version of firefox
11:43:46 [anthony]
... it was being parsed with the old version of the parser
11:44:03 [anthony]
... but now it's being parsed with the new HTML parse
11:44:23 [anthony]
ED: I see something slightly different in Safari
11:44:31 [anthony]
... doesn't look the same as in FireFox
11:44:46 [anthony]
JW: This is to do with parser rather than the CSS model
11:44:56 [anthony]
CL: Beta 6 shows the same as Beta 4
11:45:02 [anthony]
DS: It looked different
11:45:34 [anthony]
JW: According to the SVG parsing rules it's implicitly creating a second appearance
11:45:51 [anthony]
s/SVG parsing rules/HTML with SVG parsing rules/
11:45:59 [anthony]
DS: I think I figured it out
11:46:04 [anthony]
... I think it's my blog
11:47:45 [anthony]
DS: [Fixes blog]
11:47:48 [anthony]
JW: That looks better
11:48:30 [anthony]
ED: How are borders applied in CSS, do they go outside the content box?
11:48:32 [anthony]
CL: Yes
11:48:40 [anthony]
DS: In the second example I'm using padding
11:48:47 [anthony]
... in the first case I'm just using border
11:49:08 [anthony]
CL: It's just wrong. If I want a border around my SVG I'd expect it to be on the outside
11:51:50 [anthony]
... so you say in your post that some things should apply
11:51:57 [anthony]
DS: Yes
11:52:14 [anthony]
CL: In that case that's ok
11:53:40 [anthony]
DS: I was specifically call out things that would make sense to have
11:54:04 [ChrisL]
s/apply/apply, do you mean them as examples or as an exhaustive list?/
11:54:28 [ChrisL]
s/DS: Yes/DS: As a list of all that apply/
11:57:12 [anthony]
ED: If you put a border on something inside the root of a foreignObject
11:57:19 [anthony]
... would it be bigger?
11:57:50 [anthony]
CL: I'd expect the line to go all the way around the foreignObject
11:59:24 [anthony]
JW: [Draws different scenarios on board]
12:00:36 [anthony]
... my suggestion would be to set this property for SVG elements
12:00:54 [anthony]
... and it automatically just works for elements
12:02:23 [anthony]
... I think what will happen is the content area size is reduced
12:02:32 [anthony]
... which is the effectively the viewport size of the SVG
12:03:28 [ChrisL]
scribe: Chris
12:03:34 [ChrisL]
scribenick: ChrisL
12:03:51 [ChrisL]
DS: (draws on board)
12:04:24 [ChrisL]
JW:In all cases it stays at 100% 100%.
12:04:44 [ChrisL]
DS: OK if we don't show the border. It might apply
12:04:54 [ChrisL]
... what if they zoom out, then it shows.
12:05:02 [ChrisL]
JW: Huh?
12:05:12 [ChrisL]
ED: That is a strange behaviour
12:05:28 [ChrisL]
DS: Dont want the size of the SVG to be affected by the size of the border
12:05:45 [ChrisL]
... dont want box model to apply to svg in that way
12:06:11 [ChrisL]
... only the border and background, not the rest of the box model. and the padding
12:07:12 [ChrisL]
DS: Chris you are right, viewport-fill and background are different, for svg
12:07:54 [ChrisL]
JW: (still searching for the property that says whether width applies to content box, padding box or border box)
12:08:51 [jcdufourd]
jcdufourd has joined #svg
12:08:55 [ed]
https://developer.mozilla.org/en/CSS/box-sizing
12:09:27 [jwatt]
http://www.w3.org/TR/css3-ui/#box-sizing
12:09:29 [ChrisL]
http://dev.w3.org/csswg/css3-ui/
12:09:50 [ChrisL]
Name: box-sizing
12:09:50 [ChrisL]
Value: content-box | border-box | inherit
12:10:06 [ChrisL]
ED: Does this solve the examples on your blog, Doug?
12:13:00 [ChrisL]
CL (reads from spec) so you got this legacy behaviour as the editors not describes
12:13:49 [ChrisL]
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
12:17:42 [ChrisL]
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 9especially zooming out)
12:18:13 [ChrisL]
... otherwise, having the sema property but behaving differently is more confusing than having two properties which do different things
12:18:17 [anthony]
s/9especially/(especially/
12:18:40 [jcdufourd]
s/ sema / same /
12:18:59 [ChrisL]
DS: Most designers would expect background fills entire viewport regardless of zoom
12:19:10 [ChrisL]
CL: OK, but does the background spec say that?
12:19:24 [shepazu]
s/Most designers/I suspect that most designers/
12:20:12 [anthony]
AG: I agree with what Doug thinks. That's just my opinion
12:20:51 [anthony]
CL: My point is that how the backgrounds behaves is described in terms on the box model
12:21:04 [anthony]
... so when they add transforms they will describe what happens with the boxes
12:21:47 [anthony]
... but it's only defined for the box model, so saying we want a background for our non-defined box model is undefined
12:23:29 [anthony]
JW: The problem I see is
12:23:38 [anthony]
... say I have a content area
12:23:45 [anthony]
... and there is area without anything in it
12:23:57 [anthony]
... setting the CSS background property will fill just the content area
12:24:04 [anthony]
... where as viewport fill would fill the whole area
12:24:12 [anthony]
... including the area without anything
12:25:02 [anthony]
CL: If it was 400 wide I would not have said it was 200 wide
12:25:08 [anthony]
... I would've said it was 50%
12:25:13 [anthony]
... and use Xmin and Ymin
12:25:25 [anthony]
... that's how I would design that case
12:25:37 [anthony]
DS: We have viewport fill and viewport fill opacity
12:26:11 [anthony]
... even though it would make sense for designers to use border
12:26:36 [anthony]
... they would find it doesn't work they way they expect
12:27:02 [anthony]
ED: Viewport fill and viewport fill opacity already work for all SVG elements that establish a viewport
12:27:37 [anthony]
AG: so 1.1 has a couple of elements where that applies?
12:27:48 [anthony]
ED: Yeah, anything that establishes a viewport
12:39:49 [anthony]
DS: Are people completely closed to the idea of having border and background on individual SVG elements?
12:40:10 [anthony]
... it's incredibly useful to be able to see the bounding box of an element for debugging
12:40:42 [anthony]
... would much be nice to have a dashed border that changes with the size of the shape
12:40:59 [anthony]
JW: There is another property that does a line around the object without all the box model stuff
12:41:07 [anthony]
ED: outline?
12:41:22 [anthony]
DS: Does it have all the characteristics
12:41:36 [anthony]
JW: We could define it to apply to the bounding box
12:42:20 [jwatt]
http://www.w3.org/TR/css3-ui/#outline
12:43:04 [jwatt]
I'd be much happier to consider making the outline properties apply to SVG rather than border
12:49:17 [anthony]
CL: In principle it sounds reasonable
12:49:43 [anthony]
... it gives you the ability to give you a rectangle around something that encompasses the object
12:52:01 [anthony]
Resolution: We will define how border and background apply to SVG
12:52:17 [anthony]
Resolution: We will keep viewport fill and viewport fill opacity
12:52:56 [anthony]
s/We will keep viewport fill and viewport fill opacity/We will keep viewport fill and viewport fill opacity for zoom/
12:53:22 [shepazu]
s/viewport fill and viewport fill opacity/viewport-fill and viewport-fill-opacity/
12:53:33 [anthony]
Resolution: We will investigate defining the outline property for use on SVG elements
12:54:33 [anthony]
ACTION: Doug to To add to the integration specification how border and background properties apply to SVG
12:54:33 [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].
12:54:51 [anthony]
ACTION: Doug to Investigate defining the outline property for use on SVG elements
12:54:52 [trackbot]
Created ACTION-2857 - Investigate defining the outline property for use on SVG elements [on Doug Schepers - due 2010-09-14].
12:55:07 [ChrisL]
s/defining the outline property for use/defining how the outline property applies/
13:18:06 [ed]
[work on actions]
13:18:20 [ed]
http://www.w3.org/Graphics/SVG/WG/track/
14:18:35 [ChrisL]
scribe: chris
14:18:41 [ChrisL]
scribenick: ChrisL
14:18:48 [ChrisL]
topic: pointer events
14:19:56 [ChrisL]
ED: Root svg element gets clicks if its inline
14:20:18 [shepazu]
example: http://www.schepers.cc/svg/blendups/overlay/test/overlap.xhtml
14:20:59 [ed]
s/Root svg element gets clicks if its inline/Root svg element should let clicks through to the underlying content if its inline in html/
14:21:13 [ChrisL]
embeded svg capures the clic and the surrounding context does not get it
14:22:52 [ChrisL]
CL does not surprise me that we don't get two events in the first testcase
14:23:09 [ChrisL]
DS: Spec is ambiguous.
14:23:38 [ChrisL]
ED: Firefox behaves differently from Webkit and Opera. IE9 not tested ast time we discussed this
14:24:49 [ChrisL]
CL: CSS Pointer events extends out pointer events spec to add box model stuff
14:25:04 [ChrisL]
DS: Some CSS developers love being able to use ponter events
14:25:55 [ChrisL]
... case where there is svg referenced with object, image the transparent parts should click through.
14:26:34 [ChrisL]
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
14:26:42 [ChrisL]
DS: That stops all interaction
14:26:52 [ChrisL]
JW: No, you can overide it for the children
14:27:31 [ChrisL]
DS: where is it specified?
14:27:54 [ChrisL]
JW: Not clear, jus went for consistency with how HTML is implemented
14:29:08 [ChrisL]
ED: Feedback says that is not what we want, inefficient, so we allow clicks through the unpainted area
14:29:46 [ChrisL]
CL: Same issue with a PNG image with transparency surely
14:29:57 [ChrisL]
ED: People want the stuff underneath to get clicks
14:30:24 [ChrisL]
JW: On bugzilla i was arguing to have events go through, but final decision was to block them
14:30:42 [ChrisL]
ED: target the comon case first. Mostly people want the events to go through
14:31:20 [ChrisL]
DS: SVG spec assumes (though poorly worded) that SVG root doesn't intercept pointer events on unpainted areas
14:34:01 [ChrisL]
CL: Do you have the same behaviour as Firefox for HTML/CSS pointer events on transparent background?
14:34:51 [ChrisL]
ED: Yes. But for SVG people expect different things.
14:35:10 [ChrisL]
ED: Background does not affect it
14:35:30 [ChrisL]
JCD: So even if transparent it captures events?
14:35:40 [ChrisL]
ED: yes
14:38:22 [ChrisL]
(discussion on security, and same-domain and overflow on embedded objects to capture events)
14:39:32 [ed]
just for reference, search for "hit" in the minutes from day 1, where we discussed this topic: http://www.w3.org/2010/09/03-svg-minutes.html
14:40:19 [ChrisL]
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
14:41:00 [ChrisL]
ED: Cyril tested IE9 and it has the same behaviour as Webkit and Opera. Would Mozilla be willing to chenge here?
14:41:11 [ChrisL]
JW: Personally yes but not my call here
14:41:33 [shepazu]
http://www.w3.org/TR/SVG/interact.html#UIEventProcessing
14:41:51 [ChrisL]
JW: (reads from spec on 'painted area' which is all about grahics elements not containers)
14:42:32 [ChrisL]
DS: This could be improved, it mixes hit testing and event propogation
14:44:03 [ChrisL]
DS: (projects above link, points out errors)
14:44:43 [ChrisL]
DS: first bullet is about hit testing. next 3 are about order of actions for things that have been hit tested
14:45:00 [ChrisL]
... and failing that, text selection starts
14:45:27 [ChrisL]
... final sections ays, if hit testing failed, do any UI events like context menu it what what happen normally
14:45:41 [ChrisL]
... this was before there was a clear concept of window.
14:46:09 [ChrisL]
... it not about event propogation at all. its a consequence of hit testing
14:46:55 [ChrisL]
CL: This is a very traditional CG model from 1970s, 80s
14:47:26 [ChrisL]
JW; Read it as all five bullets apply to all elements
14:47:54 [ChrisL]
s/JW;/JW:/
14:49:34 [ChrisL]
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
14:49:53 [ChrisL]
... assuming you hit a graphics element. container elements dont get events in this way
14:50:13 [ChrisL]
JW: Spec does not say explicitly that container elements cant be the target of an event
14:50:23 [ChrisL]
ED; pointer events apply only to graphic elements
14:50:32 [ChrisL]
s/;/:/
14:50:48 [ChrisL]
ED: Can despatch an event to any element
14:51:15 [ed]
s/despatch/dispatch/
14:51:37 [ChrisL]
DS: (quotes "The target element is the topmost graphics element whose relevant graphical content is under the pointer at the time of the event")
14:52:17 [ChrisL]
DS: Important to clarify this now CSS is adding pointer events
14:53:05 [ChrisL]
JW: If you set a viewport fill it gets no events and can't be dragged
14:53:30 [ChrisL]
DS: Yes. You would need to draw a rect to do that
14:55:39 [ChrisL]
DS: Its clear for inline. Opera used to have the behaviour JWatt was describing but has changed, Webkit/Chrome/IE9 have that behaviour too
14:55:58 [ChrisL]
JW: What is the target if there is no content?
14:56:07 [ChrisL]
ED: The window or the document.
14:57:18 [ChrisL]
... or the document element, and I'm not sure which. needs to be tested
14:58:15 [ChrisL]
ED: Onclick handler on root svg, do you expect it ever to be called?
14:58:42 [ChrisL]
JW: If its still inside the viewport, if there is viewport fill it should get events
14:58:50 [ChrisL]
ED: (drops in testcase)
15:00:04 [ChrisL]
ED: Do we have wording for where the listener is defined?
15:00:16 [ChrisL]
ED: Think html body element is special
15:00:32 [ChrisL]
JW: Quite likely. registers it on window I think
15:01:27 [shepazu]
ISSUE-2364
15:01:38 [shepazu]
ISSUE-2364?
15:01:38 [trackbot]
ISSUE-2364 -- Last Call Comment: SVG 1.1 may be ambiguous about the root element acting as a proximal event target -- raised
15:01:38 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2364
15:02:20 [ChrisL]
JW: We have bugs on our behaviour in bugzilla
15:03:02 [ed]
http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/clicks-on-root-svg.svg
15:03:06 [ChrisL]
DS: More common case with mixed SVG and HRML, people do not want a giant bbox they can't click through
15:04:17 [jwatt]
s/have bugs on our behavior in bugzilla/have had bugs asking for pointer events to target <svg> instead of letting them through/
15:04:21 [jwatt]
https://bugzilla.mozilla.org/show_bug.cgi?id=338279
15:05:42 [ChrisL]
DS: For the inline case, try to select teext in the overlap. It doesn't work as the SVG captures the event
15:09:16 [ChrisL]
CL: I agree that unpainted areashould not capture events
15:09:20 [ChrisL]
AG: I agree
15:09:27 [anthony]
s/teext/text/
15:09:35 [ChrisL]
DS: SVG 1.1 is clear, browsers all do that apart from Firefox
15:09:39 [anthony]
s/areashould/area should/
15:10:25 [ChrisL]
ED: Confirm IE9 has the SVG 1.1 behaviour
15:10:47 [shepazu]
s/SVG 1.1 is clear/SVG 1.1 is clear that only graphics elements dispatch pointer events/
15:11:46 [ChrisL]
DS: I think HTML folks would prefer to see this behaviour too, for irregular shaped graphics. They are not boxes
15:12:03 [ChrisL]
CL: And can alway have pointer events bbox anyway if that is wanted
15:12:55 [ChrisL]
CL: Need to make sure the CSS guts know about thet value btw its a late addition
15:13:32 [ChrisL]
JW: (example, scribe missed)
15:14:32 [ChrisL]
JW: in both cases its inconvenient because you need an encosing g element to set pointer events on
15:14:54 [ChrisL]
DS; Pointer events section should have explicitly mentioned groups. Needs to be very clear in SVG 2
15:15:05 [anthony]
s/;/:/
15:15:14 [ChrisL]
s/guts/guys/
15:16:10 [ChrisL]
DS: Easier to change one browser than five ....
15:17:19 [ChrisL]
AG: If i have a rect that is stroked and filled, clicking the middle gets no event
15:17:29 [ChrisL]
CL: Correct, default is visiblePainted
15:18:17 [ChrisL]
AG: vector effects needs to be clear here if the result is a path or a stroke, for purposes of pointer events
15:19:08 [ChrisL]
s/and fill/and not fill/
15:22:17 [jwatt]
I'm not comfortable with saying that <svg> can't be the target of events for a few reasons:
15:22:18 [jwatt]
for many people coming from HTML I don't think it's intuitive
15:22:20 [jwatt]
if you want the reverse behaviour (<svg> being an event target) you still need the child <g> reseting pointer-events
15:22:21 [jwatt]
if you have 'background' or 'viewport-fill' on <svg>, I'd expect events to be able to target it
15:23:05 [jwatt]
having said that, I do sympathize with and accept that there are many people who don't expect or like mozilla's behavior
15:23:17 [ChrisL]
but neither viewport fill nor background are painted graphical objects
15:24:01 [ChrisL]
JW: Not painted but its visible and people expect to be able to interact with it
15:24:47 [ChrisL]
DS: OK so we esatablished correct behaviour for *inline* svg, bt that was not really the issue
15:25:53 [jwatt]
I'd note that SVG 1.1 as it currently stands does not allow <svg> to be the target of an event, period
15:25:58 [ChrisL]
ED: when svg is standalone, and click outside painted area, event is captured and target is the sv element in three tested implementations
15:26:10 [jwatt]
as Doug says, you'd need a rect filling the viewport to get events anywhere
15:26:23 [ChrisL]
... firefox 4.0b6pre, Opera 10.60 and Safari 5
15:27:16 [ChrisL]
CL: At al, even if pointer events are changed?
15:27:18 [ChrisL]
JW: Yes
15:27:37 [ChrisL]
ED: Spec not consistent with that
15:28:52 [ChrisL]
DS; Maybe the pointer events should be extended to include a background value
15:32:58 [ChrisL]
DS: Those comments not withstanding, SVG 1.1 spec has intuitive behaviour that is widely implemened so we should keep it
15:34:25 [ChrisL]
action doug to clariify the behaviour of pointer events on container elements
15:34:25 [trackbot]
Created ACTION-2858 - Clariify the behaviour of pointer events on container elements [on Doug Schepers - due 2010-09-14].
15:40:29 [ed]
s/the sv element in three tested implementations/the svg element in four tested implementations/
15:40:35 [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
15:42:33 [ChrisL]
DS: Microsoft has been pretty clear that they want this pass-through behaviour
15:42:34 [ed]
s/firefox 4.0b6pre, Opera 10.60 and Safari 5/firefox 4.0b6pre, Opera 10.60, Safari 5, IE9 platform preview 4/
15:43:35 [ChrisL]
DS: Want consistent behaviour in browsers
15:43:49 [ChrisL]
JW: Will talk to Roc about this
15:47:38 [ChrisL]
Resolution: the svg 1.1 spec is clear that pointer events only fire on graphi elements and this intuitive behaviour is widely implemented so for the inline case we will keep the same behaviour that the spec defines
15:48:03 [ChrisL]
JW: Okay, will go along with the ajority here but uncomfortable with whether this is the right thing
15:48:28 [ChrisL]
s/ajor/major/
15:48:39 [anthony]
s/graphi/graphic/
15:49:10 [ChrisL]
DS: For externaly referenced content, its not settled yet
15:49:25 [ChrisL]
s/fire/target/
15:49:37 [ChrisL]
s/graphi/graphic/
15:51:25 [ChrisL]
AG: In all cases, if something is visible and it could be targetted
15:51:54 [jwatt]
s/will go along with the ajority here/will not stand in the way right now/
15:52:29 [jwatt]
as stated above, I think 'intuitive' depends on who you are - if you come from SVG, sure
15:52:29 [ChrisL]
adjourned
15:52:41 [ChrisL]
trackbot, end telcon
15:52:41 [trackbot]
Zakim, list attendees
15:52:41 [Zakim]
sorry, trackbot, I don't know what conference this is
15:52:42 [trackbot]
RRSAgent, please draft minutes
15:52:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2010/09/07-svg-minutes.html trackbot
15:52:43 [trackbot]
RRSAgent, bye
15:52:43 [RRSAgent]
I see 5 open action items saved in http://www.w3.org/2010/09/07-svg-actions.rdf :
15:52:43 [RRSAgent]
ACTION: Jean-Claude to Go through the MAE spec and the HTML 5 spec for video events and report back to the SVG WG [1]
15:52:43 [RRSAgent]
recorded in http://www.w3.org/2010/09/07-svg-irc#T08-42-41
15:52:43 [RRSAgent]
ACTION: Erik, Chris to Go through the CSS 2.1 and 3 specs to see which properties for SVG 2 might be applicable [2]
15:52:43 [RRSAgent]
recorded in http://www.w3.org/2010/09/07-svg-irc#T09-05-40
15:52:43 [RRSAgent]
ACTION: Chris to Go through the CSS 2.1 and 3 specs with Erik to see which properties for SVG 2 might be applicable [3]
15:52:43 [RRSAgent]
recorded in http://www.w3.org/2010/09/07-svg-irc#T09-06-02
15:52:43 [RRSAgent]
ACTION: Doug to To add to the integration specification how border and background properties apply to SVG [4]
15:52:43 [RRSAgent]
recorded in http://www.w3.org/2010/09/07-svg-irc#T12-54-33
15:52:43 [RRSAgent]
ACTION: Doug to Investigate defining the outline property for use on SVG elements [5]
15:52:43 [RRSAgent]
recorded in http://www.w3.org/2010/09/07-svg-irc#T12-54-51