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